「出口」から決める ― 成果物とIPの持ち物
契約書のレビューは、つい報酬額や納期といった「入口」の条件に目が行きがちです。しかしトラブルの大半は、プロジェクトが終わる局面、あるいは途中で止める局面で起きます。うまくいっている時は誰も出口を気にしませんが、うまくいっていない時ほど出口が要るのです。だからこそ、始める前に終わり方を決めておく必要があります。
その第一歩が、成果物を「システム一式」のような曖昧な言葉で済ませず、具体的に列挙して合意することです。AI開発の成果物には、動くシステム本体だけでなく、次のような「持ち物」が含まれます。
- 本体とソースコード ― 動作するアプリケーションと、その改修に必要なソース一式。
- プロンプトと設定 ― AIの振る舞いを決めるプロンプトやパラメータ。ここにノウハウが凝縮される。
- 評価データセットと判定基準 ― 品質を測るための問題集と合否ライン。運用改善の資産になる。
- 設計ドキュメントと運用手順 ― 引き継ぎ・監査・内製改修に不可欠な文書。
IP(知的財産)の帰属を考えるとき、「所有権が誰にあるか」だけを議論すると交渉が硬直しがちです。実務で本当に重要なのは、帰属そのものより「できること」― 将来、社内で改修できるか、別のベンダーへ引き継げるか、他の用途に展開できるか、という利用の自由度です。ベンダーが持ち込む汎用部品やライブラリまで発注側に渡すのは現実的ではないため、案件固有の部分(プロンプト・評価セット・業務ロジック・設定)は発注側に、汎用部品は永続的な利用許諾という形で切り分けるのが、双方の飲める着地の一例です。第三者ライセンスとの整合を誰が確認するかの責任も、あわせて明記しておきます。
後から揉めるのは決まって「終わり方」と「持ち物」。中途解約・終了時に、その時点の成果物・ドキュメント・データをどう返還／引き渡すかを先に決めておく。納品後に言い値の交渉をしないためにも、保守フェーズの条件も開発契約の段階で枠組みだけは合意しておくのが安全です。
AI特有の4つの合意事項
従来のシステム開発契約の考え方に加えて、AIならではの合意が必要になります。これらを曖昧にしたまま始めると、検収の局面で「言った・言わない」の争いになります。
1. 精度の期待値と評価基準
AI開発の契約で最もつまずくのがここです。生成AIの出力は入力や状況によって揺れるため、「精度◯%を保証する」を請負の完成条件にするのは原理的に難しく、不毛な争いを生みます。代わりに、評価データセット・評価方法・合格基準を両者で合意し、その基準に基づく判定を検収条件にするのが現実的です。何をもって「正しい答え」とするかを定義できるのは発注側なので、SME(業務に精通した有識者)の協力義務も体制として明記します。
2. データの取扱い
提供するデータの範囲・保管場所・保持期間・返還/削除の条件を定めます。とりわけAI案件で重要なのがモデル学習への利用禁止で、ベンダー自身による学習だけでなく、外部AIサービスを経由した学習利用の両方を対象に含めておく必要があります。個人情報を含む場合の委託の整理は、法務との確認が前提です。
3. 非決定性の共有
出力が揺れること、運用のなかで継続的に改善していくことが前提であることを、契約の前提認識として文書化しておきます。これが後の検収や瑕疵(かし)の議論の土台になります。「保証しろ」でも「保証できないから曖昧に」でもなく、評価の合意で挟むという発想です。
4. 第三者サービスへの依存
利用するモデルやAPIは外部サービスであることが多く、仕様変更・値上げ・提供終了が起こり得ます。そうした事態が生じたときに、誰が・どの費用負担で対応するのかの考え方を、あらかじめ共有しておきます。
フェーズ分割と契約形態の使い分け
不確実性の高いAI開発を、全フェーズ一括の請負で「完成品」として待つのは危険です。バッファ分だけ割高になり、前提が崩れたときの変更協議も難航します。原則はフェーズに分け、各フェーズに出口基準を置いて、進む／止まる／方向転換を判断しながら進むこと。各フェーズの出口基準は、始める前に決めておきます。
| フェーズ | 向く契約形態の考え方 | 出口基準の例 |
|---|---|---|
| Phase 0 診断・評価設計 | 準委任的(稼働・専門役務) | データの実態把握・評価基準の合意・実現性の見立て |
| Phase 1 PoC | 準委任的＋成果物定義 | 事前定義した基準を超えたら本開発へ／超えなければ原因分析と撤退を含む判断 |
| Phase 2 本開発 | 請負的、または反復型準委任＋節目検収 | 中間レビューと評価の継続実施、フェーズゲートでの正式判定 |
| Phase 3 パイロット→本番 | 準委任的(月額・SLA)＋改修は都度 | 実利用者での確認を経て全社へ展開 |
評価基準がすでに合意できていれば本開発を請負的にすることも可能で、アジャイルで進めるならスプリント単位の準委任に、フェーズ出口での正式判定を組み合わせます。ここで大切なのは、日々のスプリントでの成果確認と、フェーズ出口での正式なゲート判定を分けること。日々の柔軟さと、節目の規律を両立させる設計です。診断段階では「調べた結果、難しいと分かった」という報告も価値ある成果として支払う設計にしておくと、ベンダーが正直に悪い報告をできるようになります。
「PoCは成功でした」で終わらせないこと。PoCの出口には、技術的な達成度だけでなく本番化の予算枠と運用体制の判断までを含めます。ここを詰めておくことが、「誰も本番化を決めないまま立ち消える」というありがちな失敗を防ぐ条項になります。
発注側の責務 ― 「丸投げしない」の中身
AI開発は、発注側が果たすべき責務を果たさないと、どんなに優れたベンダーと組んでも失敗します。契約書に発注側の責務を明記し、計画に組み込んでおくことが「共同で育てる調達」の実装です。
- SMEの時間を出す。正解を定義できる人の稼働(週数時間から)を期間中確保する。評価データ作成・業務目線でのレビュー・例外ケースの提供は、発注側にしかできない。
- データを出す。実データを、決めた期日に決めた形で提供する。「データ提供の遅れ」は遅延原因の定番で、その責任は発注側にある。
- 意思決定を速くする。仕様の判断や方向性の選択を滞留させない。判断者(業務オーナー)と期限を計画に組み込む。
- 現場を巻き込む。利用者への説明、パイロット協力者の確保、フィードバック収集。チェンジマネジメントは外注案件でも発注側の仕事。
- 学ぶ人を置く。ナレッジ移転は受け取る人がいて初めて成立する。将来の運用担当となる「学ぶ担当」を最初から同席させる。
RACIで役割を分担する
これらの責務は、精神論ではなくRACI(実行=R・責任=A・相談=C・報告=I)の形で役割に落とし込みます。体制の雛形は、経営スポンサー・業務オーナー・SME・情シス・学ぶ担当・ベンダーの6役。ポイントは2つで、仕様判断の最終責任(A)を業務オーナーが持つこと(情シスでもベンダーでもない)、そして学ぶ担当が実装フェーズに相談役(C)として常時同席することです。週次の定例は評価指標の数字から始め、意思決定事項とリスク・前提の変化をその場で顕在化させます。
まとめ ― 署名できる粒度まで落とす
AI開発の契約は、抽象的な合意で終わらせず、両者が署名できる粒度まで落とし込むことが肝要です。例えばあるモデルケース(架空の社内FAQ案件)では、PoC開始前に「SMEが作成した100問(正答すべき80問＋答えるべきでない20問)を当社環境で3回実行し、正答率80%以上・不適切回答0件・権限越境0件・応答時間p95で3秒以内・概算運用費が月◯万円以内、をすべて満たせば本開発へ進む。未達なら原因分析報告を成果物とし、再PoC／縮小して本開発／撤退のいずれかを1ヶ月以内に経営スポンサー出席の場で決める」といった出口基準書に両者が署名します。この粒度まで具体化しておくことが、投資のゼロ回収を防ぎます。契約交渉でも、発注側が「精度を保証しろ」と迫らない誠実さを持つことが、対等で良いプロジェクトの初日になります。