固定見積もりが難しくなった本当の理由
Claude Code を日常的に使うようになって、工数見積もりが以前より難しくなったと感じているフリーランスエンジニアの方は多いのではないでしょうか。私自身、個人で十数年アプリ開発を続けるなかで、ここ数年で見積もりの前提が大きく崩れました。
かつては「このボリュームなら 3 人日」と経験則で即答できた案件が、今は「Claude Code を使えば半日で終わるかもしれないし、仕様の揺れ次第で 5 日かかるかもしれない」と、分散が大きくなっています。生成 AI の登場で生産性の上限は上がりましたが、同時に「見えにくい工数」の正体も変わりました。
ここでは固定見積もり（いわゆるフィックス案件）で請ける前提のフリーランスが、Claude Code 時代にどう料金を組み立てれば赤字を避けて利益を残せるかを、原価計算・リスクバッファ・契約条項の三層に分けて整理します。単なる「時間単価 × 日数」ではなく、案件の性格に応じてバッファを科学的に盛り込む設計工学としてご紹介します。
時間単価のまま生成AI案件を請けると赤字になる仕組み
最初に認識しておきたいのは、Claude Code を使える開発者ほど、時間単価で請けると利益率が悪化しやすいという逆説です。なぜなら、工数短縮のメリットがすべてクライアント側に流れてしまうからです。
従来であれば 40 時間かかる画面実装が Claude Code で 15 時間に縮むと、時間単価 1 万円のまま請けた場合、売上は 40 万円から 15 万円に減ります。クライアント視点ではコスト削減ですが、フリーランス側は工数短縮分の価値を何も回収できていません。短縮に費やした学習コストや、過去に積み上げたプロンプト資産がすべて無償で提供されている状態です。
このひずみを放置すると、Claude Code を使いこなせる開発者ほど月商が下がるという倒錯した現象が起きます。固定見積もりに踏み切る最大の動機は、ここにあります。工数ではなく成果物に値段をつけることで、工数短縮の果実をフリーランス側にも取り戻せるわけです。
原価モデルを「時間単価×実稼働率×リスク係数」に分解する
固定見積もりを出すときに、いきなり「この案件は 50 万円です」と決め打ちしてしまうと、根拠が薄いため交渉で値切られやすくなります。私は次の三層に分けて原価を組み立てることをおすすめします。
第一層は「基礎工数」です。Claude Code を最大限に使った場合の、最短で完了する想定時間をまず見積もります。ここでは楽観ケースの工数を素直に置きます。たとえば管理画面の CRUD 一式で基礎工数 20 時間、といった具合です。
第二層は「実稼働率」の補正です。基礎工数は「開発作業に完全に集中できた理想時間」ですが、現実には打ち合わせ、仕様調整、PR レビュー対応、Slack のやり取りが発生します。経験上、受託案件の実稼働率は 60〜70% 程度になりがちです。基礎工数 20 時間を 0.65 で割ると、実際には 30.8 時間が必要となります。
第三層は「リスク係数」です。生成 AI 案件特有のリスク、たとえば仕様揺れ・終わらないデバッグ・Claude のモデル更新で挙動が変わるリスク・クライアント支給 API の仕様不明瞭などを、係数として加味します。私は案件の不確実性に応じて 1.2〜1.8 のレンジで係数を当てています。新規ドメインで支給資料が少ない案件なら 1.8、継続案件で仕様が枯れているなら 1.2、という感覚です。
まとめると、見積もり工数 = 基礎工数 ÷ 実稼働率 × リスク係数、という式になります。基礎 20 時間、稼働率 0.65、係数 1.5 なら、46.2 時間が本来必要な工数です。これに時間単価（たとえば 1 万 2,000 円）を掛けて、55.4 万円という固定見積もりが立ちます。
時間単価そのものを「実力×希少性×責任」で再設計する
固定見積もりに移行するときに多くの方が見落とすのが、時間単価そのものの見直しです。Claude Code を使いこなしている開発者の時間単価は、そうでない開発者の時間単価と同じで良いはずがありません。
私が使っている時間単価の再設計フレームは三要素です。実力、希少性、責任です。
実力は、そのスキルセットで過去に再現できた成果物の難易度で測ります。Claude Code を活用して Next.js 16 + Cloudflare Workers のフルスタック SaaS を 2 週間で立ち上げられるなら、これは 5 年前のシニアエンジニアの仕事量に相当します。単価もそのレンジに置くのが妥当です。
希少性は、同じ仕事を他のフリーランスに代替してもらえる難易度です。Claude Code のカスタム Skills や MCP サーバーを自作できる開発者は、2026 年時点ではまだ希少です。希少性プレミアムとして 20〜40% の上乗せを正当化できます。
責任は、その成果物が本番で動くか、失敗したときに誰がリカバリするかの範囲です。エンドユーザーが直接触れる課金システム、決済、認証などは責任が大きいため、単価を上げて当然の領域です。
この三要素を掛け合わせて、Claude Code を使いこなすフリーランスの時間単価は、従来の 1.3〜2.0 倍に再設定するのが自然です。時間単価 8,000 円だったエンジニアが、Claude Code 前提案件で 1.5 万円を提示しても、成果物の完成速度と品質を考えれば十分に合理的です。
見積書で必ず書き分けるべき「範囲」と「境界」
固定見積もりの最大の敵は、スコープの滲み出しです。クライアントに悪意はなくても、「ついでにこれもお願い」が積み重なって、当初の見積もり工数を 1.5 倍に押し上げる現象は非常によくあります。
これを防ぐために、見積書の「作業範囲」欄は二段構成にすることをおすすめします。一段目は「含まれるもの」、二段目は「含まれないもの」です。
「含まれるもの」には、具体的な成果物を箇条書きにします。画面 A・B・C の実装、認証機構の組み込み、ステージング環境へのデプロイ、というように、数えられる粒度で書きます。曖昧な「管理機能一式」という表現は避け、「ユーザー一覧・検索・編集・削除の 4 画面」と明示します。
「含まれないもの」には、クライアントが誤解しがちな周辺作業を先回りして明記します。本番環境の構築、運用監視の設定、仕様書の作成、他ベンダーとの連携調整、SSL 証明書の取得、独自ドメインの取得代行、といった項目です。これらは「追加料金で対応可能」と添え書きしておくと、後から依頼された場合にスムーズに追加見積もりに移行できます。
境界を明示することは、クライアントを信頼していないという意味ではなく、お互いの期待値を揃える誠実な作業です。むしろ境界が曖昧な見積書の方が、最終的にトラブルの種になります。
仕様揺れに備える「変更管理条項」の具体的な書き方
固定見積もりで赤字になる最大の原因は、仕様揺れです。契約書に変更管理条項（Change Request 条項）を入れておくことで、仕様変更が発生したときに追加料金の交渉をスムーズに進められます。
私が使っているテンプレートはおおむね次の構造です。「本契約の成果物は、別紙の仕様書に記載された機能に限定します。仕様書に記載されていない機能の追加、または記載された機能の大幅な変更（概ね工数 2 時間以上の追加作業が発生するもの）は、変更依頼書（CR）の発行を経て、別途見積もりを提示のうえ書面合意するものとする」。
重要なのは、変更の閾値を「工数 2 時間」のように具体的な数値で定義することです。「軽微な変更」という曖昧な表現だと、クライアントの解釈次第で広がってしまいます。
さらに、CR の処理フローも明文化します。具体的には、クライアントからの変更依頼を受けた時点で、フリーランス側が追加見積書を提示し、クライアントの書面合意（メールでも可）を得てから着手する、という流れです。合意前の着手は原則行わない、と明記することで、口頭での巻き込み作業を防げます。
この条項を入れると、クライアント側も変更を気軽にリクエストしなくなります。結果として要件が早期に固まり、開発の手戻りが減り、双方にとって利益があります。
固定見積もりでも請けてはいけない案件の見分け方
すべての案件を固定見積もりで請けるのは危険です。私は次の三つのシグナルがある案件は、時間単価制（準委任契約）を提案するか、そもそも断る判断をしています。
一つ目は、ステークホルダーが 5 人以上関わる案件です。意思決定者が多いほど仕様の合意形成に時間がかかり、仕様揺れが大きくなります。とくにエンドクライアント・元請け・実装ベンダー・フリーランスという 4 層構造の案件は、中間層の伝言ゲームで仕様が歪みやすく、固定見積もりには向きません。
二つ目は、参考情報（既存システムの仕様書、データベース定義、API ドキュメント）が提供されない、あるいは「動くものを見て判断してほしい」と言われる案件です。リバースエンジニアリングから始まる案件は工数の見積もり精度が極端に低くなります。このタイプは時間単価制で、最初の 1 週間を調査フェーズとして切り出し、それが終わってから後半の固定見積もりを出す、という二段構えが安全です。
三つ目は、「とりあえず着手して、追加は後日」と言われる案件です。着手後の追加作業に料金を乗せにくくなり、結果として無償作業が増えます。着手前に総額の合意を得てから動く、という原則は崩さない方が良いです。
これらを見抜いて丁寧に断る、あるいは条件を再設計する勇気が、長期的には利益を守ります。
既存クライアントへの段階的な価格改定の進め方
すでに時間単価制で継続案件を抱えている場合、いきなり固定見積もりに全面移行するのは現実的ではありません。段階的な移行が摩擦を減らします。
第一段階は、新規機能の追加だけを固定見積もりに切り出すことです。既存の継続案件は時間単価のまま維持し、「機能 X の追加」を別発注として固定見積もりで提示します。これなら既存契約を崩さずに、新しい料金形態の実績を作れます。
第二段階は、四半期ごとの大規模アップデートを固定見積もりのパッケージとして提案することです。「四半期リリースパッケージ 3 ヶ月 80 万円」のような単位で合意できれば、実質的に成果物単価に移行できます。
第三段階で、既存の継続案件そのものを「月額保守パッケージ」として成果物ベースに再定義します。対応する作業範囲（バグ修正、軽微な機能追加、月次レポート）を明文化し、範囲外は追加見積もりで対応する、という形にします。
価格改定のタイミングは、契約更新月や年度の切り替えが自然です。改定の理由として、「Claude Code を用いた生産性改善に伴い、工数ではなく成果物単位での契約に移行したい」と率直に伝えると、納得を得やすいです。
交渉の場で使える「価値の説明スクリプト」
クライアントから「なぜその金額なのですか」と聞かれたときに、時間単価で答えるのは避けるのが基本です。時間単価で答えた瞬間、交渉は「その時間は妥当か」という微細な議論に引き込まれます。
私は次のスクリプトをベースにして、案件に応じてカスタマイズしています。
「この金額は、作業時間ではなく、完成した成果物の価値に対して設定しています。具体的には、御社がこの機能をリリースすることで見込まれる売上貢献・コスト削減額を基準にしています。また、Claude Code を使えば一般的な実装期間の 40% 短縮を想定しており、短縮分は御社のリリースタイミングを早める価値として還元される設計です。仮に想定外のトラブルで工数が膨らんだ場合でも、固定見積もりなので追加料金は発生しません。このリスクは私が引き受ける契約形態です」。
ポイントは、成果物の価値、納期短縮という付加価値、リスクの引き受けという三つの論点をセットで提示することです。時間単価の議論に引き込まれず、「価値に対する対価」としてのフレームを保ちます。
見積もり精度を高めるための「案件日記」の運用
固定見積もりの精度は、経験則からしか積み上がりません。そして経験則は、正しく記録されていないと意外と早く薄れていきます。
私は案件ごとに「案件日記」をつけています。項目は、見積もり工数・実工数・差分の原因・Claude Code の貢献度合い・仕様揺れの発生回数と種類・クライアントの意思決定速度、などです。フォーマットは自由ですが、見積もりの精度を上げる目的なので、数値で残すことを優先しています。
三ヶ月に一度、この日記を見直すと、自分のリスク係数の設定が甘い／厳しい傾向が見えてきます。たとえば「新規ドメイン案件はリスク係数 1.5 で見積もっていたが、実工数は 1.8 倍になっている」と分かれば、次回から係数を 1.8 に引き上げる判断ができます。
案件日記は、時間をかけずに書ける粒度で続ける点が肝心です。詳細に書こうとすると続きません。案件完了時に 10 分だけ振り返って、数値と一文コメントを残すだけで十分です。
次のアクション
ここまで読んでくださってありがとうございます。実務で使う場合は、まず一つだけ、次の新規案件で基礎工数 ÷ 実稼働率 × リスク係数の式で原価を出し直してみてください。時間単価 × 日数で慣れた見積もり感覚と、どこがどれくらいズレるかを確認することが、この料金設計工学を身につける一番の近道です。案件日記と合わせて三ヶ月続ければ、見積もりの精度と利益率の両方が測定可能な形で改善していくはずです。