なぜ「速くなったから安くする」が間違っているのか
見積書のテンプレートを開いたまま、小一時間ほど手が止まった夜があります。前の月に1週間と見積もった機能が、実際には丸一日で片づいておりました。その実績を素直に次の見積もりに反映すれば、金額は5分の1になる——そこまで考えて、数字を打ち込む指が止まりました。
一見、クライアントに誠実な判断に見えます。私も最初のうちは、速くなったぶんを素直に値引きへ回しておりました。結果は芳しくありませんでした。時間単価は半分以下になり、件数を増やして埋め合わせようとするほど、レビューと運用に割く体力だけが削られていったのです。
いま取っているのは、価格は据え置いたまま、納品の中身と速度を引き上げ、空いた時間を次の案件へ向けるという形です。生産性の向上分は、値引きではなく納品物の密度でお返しします。 この線引きに切り替えられるかどうかが、向こう数年の持続可能性を決めると感じています。ここから、提案・見積・納品の順に、実際に使っている手順をお伝えします。
工数ベース見積から価値ベース見積へ
最初に変えるべきなのは、見積もりの考え方そのものです。
工数ベース見積（時給×想定時間）の世界では、生産性が上がるとそのまま売上が下がります。「30時間かかると思っていた作業を10時間で終わらせたら、請求は3分の1」という素直な計算をしてしまうからです。Claude Code 時代に持ちこたえる見積もりはこれではありません。
私が現在使っているのは、価値ベース見積（Value-Based Pricing） の考え方です。クライアントにとっての成果物の価値、つまり「この機能が動くと、月いくらの売上が増えるか／工数がいくら削減できるか」を起点に価格を組み立てます。
たとえば、ECサイトのチェックアウトフローを最適化する案件を見積もるとします。工数ベースなら「フロント改修30時間×6,000円＝18万円」となります。価値ベースなら、こう考えます。
現状チェックアウト離脱率: 65% 改善目標: 50%（業界平均水準） 月間カート投入数: 5,000件 平均購入単価: 8,000円 改善による売上増加見込み: 5,000 × (0.65 - 0.50) × 8,000 = 600万円/月 ここで一つ、正直にお伝えしておきたいことがあります。この月600万円は上限の試算 であって、そのまま価格の根拠にはできません。私も最初のうちは、この数字をそのまま提案書の一行目に載せておりました。提案は通らず、あとから「机上の計算ですよね」と言われて、返す言葉がありませんでした。
いまは、次の順に割り引いてから価格帯を出しています。
月間売上増（上限試算） 600万円 × 粗利率 25% → 月間粗利 150万円 × この改修への寄与率 30% → 月間 45万円 （離脱の原因すべてが UI ではないため保守的に置く） × 立ち上がりを見て初年度は9ヶ月分 → 初年度の粗利貢献 405万円 × 15〜30% → 提示価格 60万〜120万円 工数ベースの18万円と比べれば3倍以上ですが、上限試算の600万円からは二桁下がっています。この落差を、クライアントに指摘される前に自分から見せること——それが、価値ベース見積をただの吹っかけに見せないための条件です。粗利率も寄与率も業種でまるで変わりますので、数字そのものより割り引く段を省かない ことのほうが大事だと感じています。
価値ベース見積に切り替えるために、私が提案書に必ず入れている要素は3つです。
第一に、現状の数値の可視化 。実装に入る前のヒアリングで「現状の離脱率は？」「月間トランザクション数は？」「現状の障害頻度は？」を必ず聞きます。クライアント側でもデータを持っていないことがあるので、その場合は計測の仕組みを作るところから提案します。
第二に、実装後の期待値の明示 。「改修後はこの数字をこの水準まで持っていきます」と書面で示します。控えめに、しかし達成見込みのある数字を出します。
第三に、達成貢献額のレンジ提示 。「この水準まで改善できれば、年間2,000万円〜4,000万円の売上増が見込めます」と数字で示します。これがあると、自分が提示する価格が「妥当な投資」として位置づけられます。
提案書に「成果物以外」を盛り込む
価値ベースで価格を上げても、納品物が「コードのzip」だけだと、クライアントは「割高だ」と感じます。Claude Code 時代の単価維持で大事なのは、コード以外の納品物の充実 です。
私が標準で納品するものは、こうなっています。
1. ソースコード一式（Git ヒストリー保持） 2. 設計判断ログ（なぜこの実装を選んだか） 3. 自動テスト（ユニット + E2E） 4. CI/CD パイプライン（GitHub Actions等） 5. 運用ドキュメント（デプロイ手順・障害時対応） 6. オンボーディング動画（5〜10分、社内引き継ぎ用） 7. 1ヶ月の質問対応サポート（Slack/メール） これらを Claude Code を活用して効率的に作成すると、追加の工数はほとんどかかりません。設計判断ログは Claude に「実装した内容と判断理由を Markdown でまとめて」と指示するだけで土台ができます。テストは Claude に書かせれば、人間が書くより網羅率が高いです。オンボーディング動画は、実装が終わってからデモを録画し、ナレーションを書き起こさせて整形してもらうだけです。
クライアントから見ると、納品物のリッチさが「この単価は妥当」という納得感に直結します。コード以外の納品物のうち、実は最もクライアントに刺さるのが「設計判断ログ」です。後で別の開発者が引き継いだときに、なぜこの実装を選んだのかを最後まで辿れるからです。これがあるかないかで、保守性に対する信頼が大きく変わります。
クライアントに「Claude Code 利用」を伝えるべきか
たまに聞かれる質問です。「AI でコードを書いていることを、クライアントに開示すべきか？」
私の答えは、透明にする です。ただし、伝え方を工夫します。
NG な伝え方:
「最近は Claude Code というAIで書いています」
OK な伝え方:
「私の開発スタイルは、Claude Code というAIエージェントとペアプログラミングする形を取っています。これにより、初稿の生成は高速になり、私自身は『設計判断・テスト戦略・コードレビュー・本番運用設計』に時間を集中できる構造を作っています。最終的なコードはすべて私が責任を持って検証し、納品します。」
後者は、AI を使っている事実は同じでも、「自分の付加価値はどこにあるのか」を明示しています。これがあるとクライアントは安心するし、価格交渉でも有利になります。
「AIが書いたものを納品されるなら、自分でやればいい」と考えるクライアントは確かにいます。ただ、そういうクライアントは結局自社内で実装してみて、AIを使いこなすこと自体が職人技だと気づきます。1〜2ヶ月後に「やっぱりお願いしたい」と戻ってくるパターンを、私は何度も経験しています。
並行案件管理を Claude Code で回す
単価が上がっても、案件1本にかかる総時間が長いと、月の収入は伸びません。Claude Code 時代の収益最大化は、並行案件管理の質 で決まります。
私が現在運用しているのは、週20〜25時間で月3〜5件の並行案件を回す体制です。これを支える3つの仕組みを共有します。
スラッシュコマンドで案件ごとの「型」を作る
各案件には、独特のコーディング規約・ライブラリ選好・テスト方針があります。これを毎回頭の中で切り替えていると、生産性が落ちます。
私は案件ごとに .claude/commands/ 以下にスラッシュコマンドを定義し、案件固有のコンテキストをコマンド経由で呼び出せるようにしています。
# .claude/commands/project-a-context.md このプロジェクトの規約: - TypeScript strict mode - React Server Components 優先 - 状態管理は Zustand のみ - スタイリングは Tailwind v4 のみ、styled-components 禁止 - テストは Vitest + Testing Library - コミットメッセージは conventional commits 形式
実装時は必ずこの規約を守ってください。 これを案件開始時に /project-a-context で呼び出すだけで、Claude Code が案件の世界観に即座に入ります。コードレビュー時も同じコンテキストを使えるので、規約違反の見落としが目に見えて減ります。
サブエージェントで案件横断の知見を蓄積する
Claude Code のサブエージェント機能を使うと、案件横断の専門知識を再利用可能な形で蓄積できます。私が常用しているサブエージェントの例:
security-reviewer: SQLインジェクション・XSS・CSRF・認証バイパスの観点でコードレビューperformance-auditor: N+1 クエリ・不要な再レンダリング・キャッシュ漏れの観点でレビューaccessibility-auditor: WCAG準拠・キーボード操作・スクリーンリーダー対応の観点でレビューtest-writer: 与えられたコードに対するユニットテスト・統合テストの自動生成
これらは案件Aで作って案件Bでも使えます。一度作ってしまえば、新案件でも一定品質の自動レビューを必ず通せる体制になります。クライアントから見ると、「この人にお願いすると、必ずセキュリティとパフォーマンスのレビューが入って納品される」という品質保証になります。
Hooks で案件横断の品質ゲートを自動化する
ここは私自身がひと晩溶かした場所なので、設定ファイルの形まで書き残します。
Hooks はコミットに反応する仕組みではありません。Claude Code がツールを呼ぶ瞬間 に発火する仕組みです。イベント名も pre-tool-use のようなハイフン区切りではなく、PreToolUse／PostToolUse／Notification とパスカルケースで書きます。私は最初ここを取り違えたまま、「設定したのに何も起きない」画面を延々と睨んでおりました。
実際に効いている定義は、こういう形です。
// .claude/settings.json { "hooks" : { "PostToolUse" : [ { "matcher" : "Edit|Write" , "hooks" : [ { "type" : "command" , "command" : "${CLAUDE_PROJECT_DIR}/.claude/hooks/typecheck.sh" } ] } ] } } matcher はツール名に対する指定で、Edit|Write のように縦棒で並べれば両方に一致します。一方で Stop や UserPromptSubmit のように matcher を受け付けないイベントもあり、そこに matcher を書いてもエラーにならず黙って無視されます 。動かない設定を睨み続ける前に、イベント名と matcher の対応を確かめるほうが早いです。
そして、ここが最も費用のかかる一点でした。チェックを失敗させて手を止めたいなら、終了コードは 1 ではなく 2 です。 公式の Hooks reference には、標準出力に有効な JSON を書いていない限り終了コード 1 は「ブロックしないエラー」として扱われ、処理はそのまま進むと明記されています。Unix の習慣どおり 1 を返していると、リンタが落ちているのにエージェントは何事もなく次のファイルを書き始めます。私はこれを、納品ブランチまで生き延びた型エラーというかたちで知りました。
#!/usr/bin/env bash # .claude/hooks/typecheck.sh if ! npx tsc --noEmit 2> /tmp/tsc.log ; then head -20 /tmp/tsc.log >&2 # stderr の内容がブロック理由として扱われます exit 2 # 2 以外では止まりません fi exit 0 並行案件を回しているときに最も怖いのは、案件Aの修正が案件Bに紛れ込むことです。人間の注意力は案件数に比例して薄まりますが、終了コード 2 は薄まりません。
案件タイプ別の単価相場と Claude Code 適性
すべての案件が Claude Code で生産性が3倍になるわけではありません。案件タイプによって、AI が効くポイントと効かないポイントがあります。ここを見極められると、得意な案件タイプに集中できます。
高Claude Code 適性（生産性3〜5倍）
新規Webアプリ・SaaS の MVP 開発 : 規約が固まっていない段階で、設計判断と実装を並行して進められます。Claude Code が真価を発揮する代表的な領域です。私の体感では、人間が単独でやる場合の3〜5倍の速度で MVP まで持っていけます。単価は工数ベースで200〜500万円規模の案件が、生産性向上分を価値ベースで取り込むと300〜800万円規模で受けられます。
既存コードベースの大規模リファクタリング : コードベース全体を読ませて整合性を保ちながら変更できるのは、AI ペアプロの強みです。リファクタは工数見積もりが難しく、クライアントも結果が見えにくい領域なので、価値ベース（保守工数の削減見込み）で提案するのが効きます。
API 設計と OpenAPI スキーマ整備 : 仕様書とコードを同時に整合させながら作る作業は、Claude Code が得意です。スキーマの一貫性をレビューする部分も自動化できます。
中Claude Code 適性（生産性1.5〜2倍）
既存システムへの機能追加 : コンテキストを把握する時間が必要なため、生産性向上は限定的です。案件単価は工数ベース見積もりに、設計判断ログ等の付加価値を載せて維持します。
バグ修正・障害対応 : 原因特定までの時間は、人間がほぼ単独で考える領域です。Claude Code は修正案の検証と再現テストの作成で力を発揮します。
低Claude Code 適性（生産性向上は限定的）
ステークホルダー多数の要件定義 : 人と人のコミュニケーション領域は AI ではほぼ短縮できません。コンサル的な工数として正面から見積もることが大事です。
インフラ構築の現場対応 : 物理機器の手配・SLA交渉・障害時の人的対応など、現場性の高いタスクは AI 適性が低いです。
これらを分類しておくと、自分の得意分野に注力する戦略が立てやすくなります。私自身は「新規Web/SaaS MVP」と「リファクタリング」を主戦場にしており、要件定義が複雑な案件は積極的には受けないようにしています。
単価交渉で使える具体的なフレーズ
提案・見積の場面で、クライアントから「もう少し下がりませんか？」と言われたときに、慣れていないと反射的に値引きしてしまいます。これを防ぐための、実戦で使える返し方を3つ紹介します。
「価値の確認に戻す」
「ご予算が厳しいとのこと、承知しました。いったん価格の前に、この機能が動いたとき、御社にとって月いくらの売上増／工数削減に相当するか、再度確認させていただけますか？それが見えると、適正な投資額の議論ができると思います。」
これで議論が「価格そのもの」から「価値に対する投資」に戻ります。多くの場合、この時点でクライアント側も冷静になり、「確かに月数百万円のリターンがあるなら、この価格は妥当だ」と納得が進みます。
「スコープ調整を提案する」
「予算枠を変えずに進めるとしたら、スコープを調整する形が現実的です。具体的には、◯◯機能を初回リリースから外し、△△機能までに絞ることで、ご予算内に収まります。◯◯機能は2フェーズ目で別途お見積りでも可能です。」
これは値引きではなくスコープ縮小なので、自分の時間単価は下がりません。クライアントから見ると、選択肢を提示してくれた誠実さを感じます。
「保守契約を組み合わせる」
「初回開発費は◯◯万円で、リリース後の3ヶ月保守を月△万円のサブスクで含めるプランも可能です。保守には機能改善も含むため、ローンチ後の小さな改善を都度発注いただく必要がなくなります。」
月額サブスクは、フリーランスにとって最も価値ある収益形態です。初回開発で利益率が下がっても、12ヶ月の保守契約が取れれば、年間トータルで見れば十分な収益になります。
トラブル時にこそ Claude Code を頼る
受託開発で最も収益を毀損するのは、納品後の障害対応です。本来なら次の案件に向けるべき時間が、過去案件の火消しに溶けます。ここを Claude Code でどう守るかは、長期的な単価維持に直結します。
障害対応プロセスを Markdown 化しておく
各案件の納品時に、運用ドキュメントの一部として「障害発生時のトリアージ手順」を Markdown で残しておきます。Claude にコードベースを読ませながら作ると、想定される障害シナリオと一次切り分け手順が網羅的に出てきます。
## 障害発生時のトリアージ 1. ステータスページで影響範囲を確認 2. ログ集約システム（Datadog/CloudWatch）で直近1時間のエラー率を確認 3. データベース接続プール枯渇を確認（最頻パターン） 4. 外部API（Stripe/SendGrid等）の障害情報を確認 5. それでも原因不明な場合: 直近のデプロイをロールバック これがあると、深夜の障害連絡を受けたときに、ゼロから状況把握する必要がなくなります。Claude Code に「このプロジェクトの障害対応手順を読み込んで、現在のエラーログから原因候補を3つ挙げて」と聞けば、即座に切り分け仮説が手に入ります。
月額保守契約を「実費請求 + 固定基本料」設計にする
完全固定の月額保守は、障害頻発時にこちら側が無償で残業する構造になります。逆に完全実費請求はクライアントが嫌います。
私が落ち着いた設計は、「月額3万円の基本料（軽微な質問対応・月次メンテナンス含む）+ 障害対応は時間単価1.5万円で実費請求」 の組み合わせです。月数件の質問は基本料に含み、深夜障害や大規模対応は時間単価で別途請求します。クライアントから見ても「使った分だけ払う」明朗会計になります。
危険な操作は「権限」で止め、Hooks には理由を残させる
以前の私は、本番デプロイの瞬間に発火する Hook を書こうとして半日を使いました。結論から申し上げると、そのようなイベントは存在しません。Hooks が見ているのは Claude Code 自身のライフサイクルとツール呼び出しだけで、外部の CI やデプロイパイプラインには手が届かないのです。
では git push をまったく捕まえられないかというと、間接的には捕まえられます。PreToolUse を Bash ツールに当て、if でコマンドの形を絞る書き方です。
{ "hooks" : { "PreToolUse" : [ { "matcher" : "Bash" , "hooks" : [ { "type" : "command" , "if" : "Bash(git push *)" , "command" : "${CLAUDE_PROJECT_DIR}/.claude/hooks/pre-push-audit.sh" } ] } ] } } ただしこれは「エージェントが push しようとしたとき」にだけ効きます。私がターミナルから自分の手で push する場合には発火しません。公式ドキュメントも、if によるコマンド判定は best-effort であり、確実に許可・拒否したいなら権限設定を使うようにと明記しています。さらに PreToolUse の hook がタイムアウトで打ち切られた場合、そのツール呼び出しは止まらずに通常の権限フローへ進みます 。止まってくれることを前提に設計してはいけない、ということです。
止めたい操作は権限と CI で、Hooks は理由を残す側に。 案件をまたいで使い回せたのは、この線引きを守って書いた設定だけでした。「品質保証の仕組みごと納品します」とクライアントに言えるのは、その仕組みが実際に効いているときだけなのだと思います。
「Claude Code を使えるエンジニア」のブランド構築
最後に、長期的な単価維持の話をします。
短期的には、提案書の品質と納品物の充実度で単価を維持できます。しかし2〜3年スパンで見ると、「Claude Code を使えるエンジニア」自体がコモディティ化していきます。多くの人が同じツールを使えるようになるからです。
そのとき差別化要素になるのは、自分の「実績」と「発信」を結びつけたブランド です。
私自身は、claudelab.net などの技術発信サイトを運営することで、「この人は Claude Code の運用を体系的に語れる人だ」というポジショニングを作っています。これがあると、案件問い合わせ時点で価格交渉の主導権を取りやすくなります。「Twitter で見て知りました」「ブログを読んで信頼感が湧きました」と言ってくれるクライアントは、価格に対して柔軟です。
ブランド構築のためにやることは、難しくありません。週1〜2本、自分の現場で起きたこと・解決した問題・選んだ技術判断を書く。これを2〜3年続けると、徐々に検索流入とソーシャル経由の問い合わせが増え、自分から営業しなくても案件が来る状態に近づきます。
高い単価を支えるのは、納品そのものの中身です
提案や交渉で価格の前提を整えても、それを最後に裏づけるのは要件定義と実装の中身です。ここで「この人は他と違う」と感じてもらえると、次回以降の単価交渉はほとんど不要になります。私自身、個人開発で自作アプリやいくつかのサイトを回しながら受託にも関わってきましたが、価格を支えてくれたのは提案の上手さよりも、要件定義と実装での地味な詰めでした。Claude Code を前提にした進め方を、この二つのフェーズに分けて整理します。
要件定義フェーズで差をつける — AI エージェント前提の設計
要件定義フェーズは、単価に最も大きな影響を与えるステップです。ここで「この人は他と違う」と思ってもらえるかどうかで、後の交渉が全く別物になります。Claude Code を使いこなしている人にしかできない要件定義の進め方がいくつかあり、それらを意識的に積み重ねるだけで、単価の前提が変わります。
一つ目は、既存コードベースを短時間で俯瞰してみせることです。通常、初回打ち合わせの前にリポジトリを読むには数時間かかりますが、Claude Code を使えば大規模なコードベースでも1〜2時間でアーキテクチャ図とボトルネックリストを手元に置けます。初回の打ち合わせで「御社のシステムは A 層と B 層の結合が強く、ここがスケール時のボトルネックになります」と具体的に語れると、それだけで相場の倍は払う価値があると認識されます。
二つ目は、リスクとエッジケースの洗い出しです。Claude Code に「このシステムで運用上問題になりそうなエッジケースを列挙してください」と指示すると、通常の要件定義では出てこない観点が大量に出てきます。決済のリトライ周り、日時のタイムゾーン処理、バッチの冪等性、認可キャッシュの整合性、監査ログの改ざん検知、そういった運用レベルのリスクまで拾えます。
claude code
> このシステムで本番運用時に発生し得る障害パターンを20個挙げて、 > 発生確率と影響度で分類してください。 > 発生源は「アプリケーションコード」「インフラ」「外部API」「人的ミス」 > の4カテゴリに分けてください。 三つ目は、ドキュメント粒度の引き上げです。要件定義書の完成度は、単価の正当性を説明する実用的な材料になります。Claude Code で仕様書のドラフトを短時間で仕上げ、それを自分でレビューしながら詰めていくと、1人日で従来3日分の密度のドキュメントが作れます。この密度差を見せるだけで「ここまで考えてくれているなら高くても仕方ない」という空気が生まれます。
四つ目は、実装前のプロトタイプ提示です。本当に単価を跳ね上げたければ、提案フェーズの段階で動くプロトタイプを用意します。Claude Code を使えば半日で主要画面の動くモックが作れるので、競合が提案書だけで戦っている中で「実際に触れる画面がある提案」で差をつけられます。私はこのアプローチに切り替えてから、受注率が明確に上がりました。
実装フェーズの標準化 — 品質を落とさず速度を出す
実装フェーズは、Claude Code の真価が問われる場面です。ただし、ここで品質を落とすと次の案件が来なくなるので、速度と品質の両立が不可欠です。単価を上げ続けたいなら、品質管理プロセスを標準化して、案件ごとにブレが出ない体制を作る必要があります。
私が全案件で徹底しているのは、最初のセッションで「開発ルール」をテキストに書き出し、それを Claude Code に読ませてから実装を始めることです。コーディング規約・命名規則・ディレクトリ構造・テスト方針・レビュー観点・セキュリティ制約を1ファイルにまとめておくと、Claude Code の出力が常に一定の品質レンジに収まります。
# プロジェクト直下に .claude/rules.md を置く # その内容を最初のセッションで読ませる
claude code
> .claude/rules.md を読み込んで、以降の実装はこのルールに従ってください。 > ルールに違反しそうな提案をする場合は、必ず事前に警告してください。 もう一つ徹底しているのが、実装前のタスク分解です。いきなり実装を始めると、Claude Code の文脈が膨らんで指示が通りにくくなります。私は必ず事前に「このチケットをサブタスク10個以内に分解し、それぞれの完了条件と動作確認方法を書いてください」と指示してから、1サブタスクずつ進めます。この段取りだけで品質のブレが半減します。
自動テストは Claude Code 任せにせず、自分で観点を指示します。「このエンドポイントのテストを書いてください」ではなく、「以下の8観点でこのエンドポイントのテストを書いてください: 正常系、認証なし、権限なし、入力バリデーション失敗、重複リクエスト、レート制限、DB エラー時の挙動、タイムアウト時の挙動」と具体化します。テストは納品物の一部であり、単価を正当化する最大の武器です。
レビューは Claude Code に最終チェックをさせ、自分でも再レビューする二段構えにしています。Claude Code に「このプルリクエストを本番で動かす前提でレビューしてください。特にセキュリティとデータ整合性の観点でリスクを列挙してください」と依頼すると、自分が見落としていた観点を10個以上返してきます。ただし、AI の指摘には誤検知も多いので、そのままクライアントに共有せず、自分の判断を通してから反映します。
次の一歩
ここまで読んでいただき、ありがとうございます。
具体的に動き始めるなら、まず今受けている案件のうち1件を選び、価値ベース見積に書き換えてみてください。「現状の数値・改善目標・達成貢献額」の3要素を整理した瞬間、自分の仕事の価格に対する解像度が一気に上がります。
そのうえで、納品物に「設計判断ログ」と「オンボーディング動画」を加えるところから始めてみてください。Claude Code でこの2つを作るのは、想像より遥かに簡単です。クライアントの反応が変わる手応えが、きっと得られると思います。