"やってみないと分からない"生成AI案件を、それでも見積もる — スコープ・契約形態・受け入れ基準の設計

生成AIやSREの案件で、「やってみないと分からない」と感じたまま見積りを出し、後で工数や原価が大きくぶれた経験は珍しくありません。これは見積もる側の能力の問題というより、案件そのものの構造によるものです。本記事は、設計はできるが成果が読めない生成AI案件のスコープ定義・見積り・契約形態の選択で消耗している技術リードやPM寄りのエンジニアに向けて、読めない不確実性を「再現可能な見積りの型」で扱う方法を整理します。具体的には、3つの不確実性を段階に割り、受け入れ基準をeval（評価）閾値で事前合意し、契約形態でリスクの所在を設計し、スコープを明文化する、という流れです。なお本記事は固有の単価・相場・成功率といった数値は扱わず、型と判断軸で述べます。契約形態についても、選択のロジックに焦点を当て、個別契約の法的な効果や条項には踏み込みません。具体の契約は専門家にご確認ください。

なぜ生成AI案件は見積りが外れるのか

従来のシステム開発の見積りは、仕様が確定していることを前提に積み上げます。これに対して生成AI案件では、見積りの前提そのものが事前に確定しません。ぶれの源は、おおきく3つの不確実性に整理できます。

第一に精度です。あるタスクを目標品質で解けるかは、実際にモデルとデータで試すまで分かりません。第二に推論コストです。本番のトラフィックと単価の組み合わせで運用費が決まり、その単価や利用量は後から変動します。プロンプトキャッシュやバッチ、ルーティング、モデル蒸留といったレバーで原価は動くため、見積り時点の前提が運用時にずれます。第三にデータ品質です。RAGや学習に使うデータの整備度が読めないと、必要な前処理やチューニングの工数が見積もれません。

従来のSI見積りでは、要件と仕様が先に確定し、それを工数へ積み上げます。生成AI案件では、その「先に確定しているはずの仕様」の一部が、成果を試すまで定まりません。解けるかどうか自体が成果に依存するため、仕様を固めてから見積もるという順番が成り立たないのです。

これらは「もっと丁寧に見積もれば消える」ものではなく、案件の初期には原理的に読めない不確実性です。だからこそ、読めないものを読めないものとして正直に扱い、段階的に解消していく設計が要ります。見積りの精度を上げる努力ではなく、不確実性を減らす順番を設計することが、ここでの正攻法になります。

不確実性を段階に割る — PoC→本番の二段見積り

不確実性に対する基本姿勢は、一度に全体を見積もらず、段階に割ることです。具体的には、探索のためのPoC（概念実証）と、その後の本番化を分けた二段見積りにします。

最初のPoCフェーズでは、「そのタスクがモデルで解けるか」「原価の感触はどの程度か」「データの整備にどれだけ手がかかるか」を測ることを目的にします。ここで成果物そのものより、不確実性を減らすことを成果と定義します。探索が進むほど見積りの幅は縮みます。これは不確実性コーンと呼ばれる一般的な考え方で、プロジェクトの初期ほど見積りの幅が広く、情報が増えるにつれて狭まる、という構造です。

PoCで気をつけたいのが、探索が延々と続いてしまうことです。これを防ぐには、PoCの開始時に終了条件を決めておきます。具体的には、検証する仮説、かけてよい期間（タイムボックス）、そして「次に進む／作り直す／撤退する」を分ける判定基準を、あらかじめ合意します。PoCの成果は完成物ではなく、この判定に必要な情報が揃うことだと定義すると、探索の費用対効果を見失わずに済みます。

PoCで精度の見込み、原価の感触、データ整備量が掴めて初めて、本番化の見積りに進みます。本番化フェーズは、受け入れ基準が立ってから値付けします。順序を逆にして、読めないうちに本番の固定見積りを出すことが、ぶれの最大の原因です。

受け入れ基準を eval 閾値で事前合意する

二段見積りの境目に置くのが、受け入れ基準です。生成AI案件では「変更後は評価（eval）が必須」という考え方を、そのまま契約上の検収条件に翻訳できます。つまり、何を満たせば検収完了とするかを、評価の指標と閾値で事前に合意します。

受け入れ基準の要素	置き方	例（型としての示し方）
指標	タスクに合った評価指標を選ぶ	正答性・根拠への忠実性・有害性など
閾値	合格ラインを数値で事前合意	評価データセットに対する合格基準
検収条件	閾値を満たした状態を検収完了と定義	指定データで閾値到達を確認できること

この事前合意があると、「良くなった気がする」といった主観で揉めることがなくなり、何をもって完了とするかが双方で明確になります。評価の指標選びや閾値設計そのものは、評価をリリースゲートにする設計の領域です。受け入れ基準を測る道具としては Amazon Bedrock Evaluations のようなマネージドの評価機能が使え、評価設計の詳細はその専門記事に接続して詰めるとよいでしょう。

リスクを”誰が持つか”を契約形態で設計する

不確実性を段階に割り、受け入れ基準を決めたら、次は「そのリスクを誰が持つか」を契約形態で設計します。判断の軸は、不確実性が探索フェーズにあるのか、確定フェーズにあるのかです。

探索フェーズ、すなわちPoCのように精度・原価・データ品質が読めない段階は、準委任が適します。準委任は時間や工数をベースにし、特定の成果を保証しない形で、探索そのものに対価を払う設計です。読めない段階で成果を固定で約束しないことが、双方にとって無理のない持ち方になります。

確定フェーズ、すなわち受け入れ基準が立ち、何を満たせば完了かが明確になった段階は、請負が適します。請負は成果と検収条件が明確であることが前提で、基準が立ってから初めて成立します。

実際の案件では、探索と確定がきれいに分かれず、一部は読めているが一部は読めない、という中間状態がよくあります。そのときは、案件全体を一律の形態に当てはめようとせず、読めている部分は請負に、読めていない部分は準委任にと、リスクの所在ごとに切り分けて持ち方を変えるのが現実的です。判断の基準は契約名そのものではなく、「その不確実性を誰が引き受けるのが妥当か」に置きます。

ここで見落とされやすいのが、推論コストの変動リスクです。本番運用の原価は単価や利用量で動くため、その変動を誰が受け持つかを契約に織り込みます。発注側が変動を受容するなら上限や前提を明示し、受託側が持つなら転嫁や上限、変動条項として設計します。原価試算の入口としては AWS Pricing Calculator のような公式ツールで自構成の見込みを立て、変動幅を見積りの前提に置きます。推論コストを下げるレバーそのものは、推論コスト最適化の専門記事の領域です。なお、ここで述べているのは契約形態の選び方のロジックであって、個別契約の法的効果や条項ではありません。実際の契約は専門家にご確認ください。

スコープクリープを止める — 「やらないこと」の明文化

見積りと契約形態が決まっても、スコープが膨らめば原価は崩れます。生成AI案件は「ついでにこれも」が起きやすく、探索の楽しさも相まってスコープが広がりがちです。

これを止めるのが、「やらないこと」の明文化です。何を作るかと同じ重みで、今回は何を対象外にするかを文書に残します。アーキテクチャの選定判断を記録として残す考え方（ADR）と同じく、スコープの線引きも判断の記録として残すと、後からの追加要望に対して立ち戻れる基準ができます。

スコープ線引きの観点	明文化する内容
対象範囲	今回作る機能・対象データ・対象ユーザー
対象外	今回はやらないこと（次フェーズ送り含む）
前提条件	データ整備・環境・外部依存の前提
マイルストン	段階リリースの区切りと各段階の完了条件

あわせて、段階リリース（マイルストン分割）で大きな一括納品を避けます。各マイルストンに完了条件を紐づければ、進捗と原価を区切りごとに確認でき、ぶれが大きくなる前に手を打てます。追加要望が出たときも、対象外として記録した内容と照らせば、それが今回のスコープなのか次フェーズの新規見積り対象なのかを切り分けられます。明文化は要望を拒むためではなく、追加を別の値付けとして正しく扱うための土台になります。

まとめ

「やってみないと分からない」生成AI案件も、構造を理解すれば再現可能な型で見積もれます。要点は次のとおりです。第一に、見積りが外れるのは能力でなく構造であり、精度・推論コスト・データ品質の3つの不確実性が源です。第二に、不確実性は段階に割り、PoCは準委任で探索し、本番は受け入れ基準が立ってから請負にします。第三に、受け入れ基準はeval閾値で事前合意し、契約形態でリスクの所在を設計し、推論コストの変動も持ち手を決めます。第四に、「やらないこと」を明文化してスコープクリープを止めます。固有の相場や成功率に頼らず、型と判断軸で値付けることが、読めない案件を無理なく前に進める近道です。設計面の各論は、アーキテクチャ意思決定の記録、評価設計、推論コスト最適化、エージェントの本番運用といった専門記事に接続して深めていくとよいでしょう。

出典

• AWS Pricing Calculator（インフラ原価の事前試算の入口。具体単価は自構成・時点で試算） — https://calculator.aws/
• Amazon Bedrock Evaluations（受け入れ基準のeval閾値を測る・公式ドキュメント） — https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html