開発会社が本開発フェーズを請負契約にしたいと強く主張してきた場合、どう判断すればよいですか？

精度目標が未達だった場合の対応（改善作業を継続するのか、契約を再協議するのか）が条項として明記されているかを判断基準にしてください。明記があれば請負でも許容範囲ですが、曖昧なままであれば準委任または成果連動型への変更を求めるべきです。

修正依頼テンプレを送っても開発会社が条項の変更に応じない場合、どうすればよいですか？

拒否された論点が精度基準やLLM API費用負担など金銭的リスクの大きい項目であれば契約自体の見送りを含めて再検討し、知財の要素別区分のような影響が限定的な項目であれば代替の緩和条項で妥協できないか社内で判断してください。

顧問弁護士がAI開発契約に詳しくない場合、どのように相談すればよいですか？

契約書ドラフトに加えて、開発会社から受け取った提案書・見積書（使用予定のLLMプロバイダ名、API従量課金の単価表など技術的背景が分かる資料）を一緒に渡してください。条文の文言だけでは伝わらない前提が補われ、弁護士が論点を把握しやすくなります。また、精度未達時に許容できる対応（改善継続で妥協するか、契約再協議まで求めるか）や月額API費用の上限予算など、社内でどこまで強く修正を求めるかの優先順位をあらかじめ整理しておくと、限られた相談時間で的確な助言を得やすくなります。

PoCのみの小規模な発注でも5項目すべてを確認する必要がありますか？

予算規模によらず必ず確認すべきは精度目標値とLLM API費用負担の2項目です。知的財産権の要素別帰属やモデル更新対応の優先度は、契約金額や本開発フェーズへの継続見込みに応じて調整して構いません。

自社に評価データとして使える業務データがない場合、契約書ではどう対応すればよいですか？

受託者側で評価データを用意してもらう前提とし、そのデータが自社の実業務データとどの程度類似しているか（提供元・件数・データの性質）を確認できる開示条項を契約書に追加してもらうよう依頼してください。

AIエージェント開発契約の注意点｜発注前に確認すべき5つのチェック

「AI エージェントで社内問い合わせ対応を自動化したい」「営業支援を AI エージェントに任せたい」——経営層からの指示を受け、外部の開発会社から見積と契約書ドラフトを取得したものの、いざ契約書を読み込むと違和感を覚える発注者担当者が増えています。「精度は事前合意した基準に従う」「API 費用は乙が負担する」といった条項が、従来の受託開発契約書と何かが違う気がする——けれど、その違和感の正体をうまく言語化できない、というケースです。

AI エージェント開発は、従来のスクラッチ Web システム開発と同じ感覚で契約すると、契約後に「思っていた成果物が出てこない」「月次コストが想定の 3 倍」「半年で作り直し」といった事態に陥りやすい領域です。理由は、AI エージェント特有の 3 つの性質——精度を完成義務として保証できない・LLM API という外部依存で費用が変動する・基盤モデルの更新で成果物が陳腐化する——が、普通のシステム開発契約書ではカバーされていないためです。

とはいえ、社内法務や顧問弁護士も AI 契約に詳しくない場合が多く、「どの条項をどう確認すればよいか」の判断軸を発注者側で持てないまま契約に至ってしまうと、後から修正するのは容易ではありません。契約前の段階で、AI 開発特有の落とし穴を条文レベルで把握しておくことが、後悔しない契約の第一歩となります。

本記事は「契約書ドラフトを前にした発注者が、1 時間で条項をスキャンして Yes/No 判定できる注意点」を、5 つのチェックポイントに絞って提示することを目的にしています。契約類型の選び方・精度合意の設計論・モデル更新条項の詳細設計といった「契約書をゼロから設計する側」の深掘り解説は、姉妹記事のAIエージェント開発の業務委託契約｜精度保証・モデル更新に備える条項と発注判断に譲り、本記事は各論点について「契約書ドラフトのこの箇所にこの文言があるか」を短時間で確認できる形式に振り切ります。契約書レビューの前段として本記事を、条項設計そのものを深く検討したい場合は姉妹記事を、と使い分けてください。

Contents — 目次

AIエージェント開発の契約は「普通のシステム開発」と何が違うのか
契約前に必ずチェックすべき5つの注意点
契約書に潜む落とし穴と回避のポイント
契約前に発注者側で準備しておくべきこと
契約後・運用フェーズで見落としがちな注意点
まとめ｜AIエージェント開発を契約するときの最終確認5項目

—Free Download / 資料ダウンロード

システム開発における基本契約書の雛形

この資料でわかること

システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。

こんな方におすすめです

システム開発を発注する際にどのような基本契約を結ぶのか興味がある
システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
システム開発を発注する側にどのような義務が生ずるのか気になる

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

入力いただいたメールアドレスにPDFをお送りします。

AIエージェント開発の契約は「普通のシステム開発」と何が違うのか

契約書ドラフトのチェックに入る前に、まず「なぜ AI エージェント開発では従来型の契約書がそのままでは通用しないのか」を短く押さえておきます。ここが腑に落ちていないと、続くチェックリストで「なぜこの条項を確認するのか」の判断がぶれるためです。深掘りは姉妹記事に譲り、本セクションは前提の共有に留めます。

AIエージェントとは何か・従来のシステム開発と範囲がどう違うか

AI エージェントとは、大規模言語モデル（LLM）を中核とし、プロンプト（指示文）・ツール連携（外部 API 呼び出し・データベース参照など）・評価（出力品質のモニタリング）を組み合わせて、特定業務を自律的に遂行するソフトウェアの総称です。従来の Web システム開発が「決められた仕様どおりに動く画面と API を作る」ことをゴールとするのに対し、AI エージェント開発は「LLM の非決定的な出力を、業務要件を満たすレベルまで作り込む」ことをゴールとします。

構成要素の内訳と、それぞれが契約論点に与える影響についての詳細な解説は姉妹記事にまとめています。本記事の以降のセクションでは、この違いを「契約書のどこを見ればよいか」という具体的な視点に落として扱います。

契約書に効く3つの特殊性

AI エージェント開発が従来の受託開発と契約上異なる点は、以下の 3 つに集約できます。契約書ドラフトのチェックポイントは、いずれもこの 3 つのどれかに紐づいています。

精度の非保証性: LLM は同じ入力に対しても出力が変動する非決定的な仕組みで、開発時点で高精度でも本番運用の実データでは精度が下がることが珍しくありません。「仕様どおりの完成物を納品する完成義務」を精度に対して負わせるのは技術的に困難です。この点は、公的機関・法律事務所の解説でも「AI 開発は請負より準委任契約が親和的」とされる根拠になっています（伊藤海法律事務所：AI開発委託契約の特徴・ポイント、IP BASE（特許庁）：AI開発を受託する際の契約方式の選び方）
LLM API の外部依存による費用変動: AI エージェントは LLM API を呼び出すたびに従量課金が発生します。実務系解説でも、月額 API 費用が数十万円から 100 万円規模になるケースが報告されています（ripla：AIエージェント開発の契約書で確認すべき5つのこと）。契約書で「API 費用は乙が負担する」と包括的に書かれている場合、受託者が費用を吸収しきれず後日の追加請求・契約見直し交渉の火種になります
基盤モデル更新による成果物の陳腐化: OpenAI・Anthropic 等の LLM プロバイダは、モデルの終了予告・価格改定・仕様変更を継続的に行っています。納品時点で最適だったモデルが、数ヶ月後には非推奨扱いになったり、価格改定で費用構造が変わったりするのが常態です

これら 3 点の背景をより深く知りたい方は姉妹記事のAIエージェント開発の業務委託契約｜精度保証・モデル更新に備える条項と発注判断を参照してください。本記事では以降、これら 3 つの特殊性が契約書のどの条項にどう表れるかを、Yes/No でチェックできる形式に落として整理していきます。

契約前に必ずチェックすべき5つの注意点

ここからが本記事の中核です。契約書ドラフトを受け取った発注者が「この条項がなかったら要注意」「この文言があったら発注者に不利」と判断できる 5 つのチェックポイントを、各項目について「①契約書のどこを見るか」「②Yes/No 判定基準」「③問題がある場合の修正依頼テンプレ」の 3 点セットで提示します。条項設計そのものの深掘り解説は姉妹記事に譲り、本セクションは「読みながら Yes/No チェックを進められる」ことを優先します。

チェック1: 契約形態が開発フェーズと合っているか

どこを見るか: 契約書のタイトル、第 1 条（目的）、第 2 条（業務内容）、および PoC と本開発のフェーズ分けに関する条項。

Yes/No 判定基準:

Yes: PoC フェーズは「準委任契約」または「善管注意義務」の表現で書かれ、本開発フェーズも準委任または成果連動型（マイルストーンごとの合意）で構成されている
No: 本開発フェーズが単一の「請負契約」として書かれており、精度目標値が「合意した基準を満たすこと」といった曖昧な完成義務として括られている

なぜ問題か（背景）: AI エージェントの精度は前セクションで整理したとおり完成義務として保証できないため、本開発フェーズを従来型の請負契約で締結すると、受託者は防衛的な見積となって費用が跳ね上がるか、検収時に「仕様どおり動いています」と主張する余地を残す形で契約せざるを得なくなります。特許庁 IP BASE の解説でも、AI 開発は「性能保証が困難な領域では準委任型が親和的である」と整理されています（IP BASE：AI開発を受託する際の契約方式の選び方）。

修正依頼テンプレ:

本開発フェーズについて、AI エージェントの精度は評価データに対する定量指標で継続改善する性質があるため、完成義務を負う請負契約ではなく、善管注意義務を負う準委任契約への変更をご検討いただけないでしょうか。もしくは、成果連動型（マイルストーンごとの合意）に修正できないかご相談させてください。

契約類型そのものの選び方（PoC = 準委任、機能開発 = 請負＋成果物定義、継続改善 = 準委任の混合設計）を深掘りしたい方は、姉妹記事のAIエージェント開発の業務委託契約｜精度保証・モデル更新に備える条項と発注判断を参照してください。

チェック2: 精度目標値・検収基準の定義

どこを見るか: 精度・品質に関する条項、検収条項、および別紙・仕様書の評価基準セクション。

Yes/No 判定基準:

Yes: 精度目標値そのもの（例: 「テストデータセット X に対する分類精度 85% 以上」）、評価データセットの定義（誰が用意するか・件数・データの性質）、精度未達時の対応（改善作業継続 or 契約再協議）が明記されている
No: 「精度は事前合意した基準に従う」「実用に耐えうる品質を担保する」等の曖昧表現のみで、具体的な指標・データセット・未達時対応が別紙にもない

なぜ問題か（背景）: 「精度 XX% 以上」という単一の SLA 型合意は、AI エージェント開発ではほぼ機能しません。開発時点の評価データと本番運用データの分布が異なる場合、事前合意した精度基準を満たせなくなるためです。契約書に「精度は事前合意した基準に従う」と書かれているだけで具体的な握り方が定義されていない場合、検収時に「基準を満たしていない」「いや、この評価データでは達成している」という水掛け論に発展します。

修正依頼テンプレ:

精度基準について、評価データセットの定義（誰がどの件数を用意するか）と、対象指標（例: 分類精度・応答時間）を契約書別紙で明示させていただけないでしょうか。また、精度未達時の対応（改善サイクルの継続 or 契約再協議）についても条項化を希望します。

「保証ではなく評価データセットの受入基準で握る」握り方の設計論と、運用フェーズの改善義務の書き方は姉妹記事にまとめています。

チェック3: LLM API費用の負担者・上限・変動時の対応

どこを見るか: 費用・報酬に関する条項、および運用フェーズの月額費用に関する条項。

Yes/No 判定基準:

Yes: LLM API 費用の負担者（発注者・受託者・折半）・月次または年次の想定利用量および費用上限・想定超過時の対応（協議による見直し・追加請求のルール）がいずれも明記されている
No: 「API 費用は乙が負担する」のみで、想定量・上限・変動時対応が書かれていない

なぜ問題か（背景）: LLM API 費用は AI エージェント開発の総保有コスト（TCO）で最大の変動要因になります。契約書で費用負担が曖昧なまま契約すると、運用開始後に想定の 2〜3 倍の消費が発生した際に、誰が超過分を負担するかで揉めます。月額 API 費用が数十万円から 100 万円規模になるケースも報告されています（ripla：AIエージェント開発の契約書で確認すべき5つのこと、LASSIC：AI開発委託外注の進め方と注意点）。

費用負担のパターンは主に 3 つあり、それぞれ契約書での握り方が異なります。

発注者負担: 発注者が LLM プロバイダと直接契約し、API キーを受託者に貸与する形式。費用の可視性は高いが、キー管理・上限設定の運用負荷が発注者側に発生します
受託者負担: 受託者が代行して LLM API 契約を持ち、月額固定費に費用を織り込む形式。運用は楽だが、想定超過時に受託者が吸収しきれず追加請求になるリスクがあります
折半・段階制: 想定利用量までは受託者負担、超過分は発注者負担、といった段階制。契約書での定義が最も重要になるパターン

修正依頼テンプレ:

API 費用について、月次の想定利用量と想定費用の上限を契約書に明記いただけないでしょうか。また、想定を X% 以上超過した場合の協議・追加請求のルールについても条項化を希望します。

なお、契約前に AI エージェントの費用相場・内訳を体系的に把握したい場合は、AIエージェント費用の相場と内訳やAIエージェント外注費用を抑える方法といった関連記事も参考にしてください。マルチモデル前提でベンダーロックを避ける設計論は姉妹記事で扱っています。

チェック4: 知的財産権の帰属

どこを見るか: 知的財産権に関する条項、成果物の定義に関する条項、および契約終了後の権利処理に関する条項。

Yes/No 判定基準:

Yes: 「成果物」の定義に、ソースコード・プロンプト・評価データセット・カスタムモデル・ログデータそれぞれが含まれ、各要素の権利帰属（甲/乙/共有）と契約終了後の複製・再利用可否が明記されている
No: 「成果物の著作権は甲に帰属する」のみで「成果物」の内訳定義がない

なぜ問題か（背景）: AI エージェント開発では、成果物として発生する権利対象が従来のシステム開発よりも複雑になります。ソースコードだけでなく、プロンプト・評価データセット・カスタムモデル（ファインチューニング成果物）・出力データそれぞれについて、権利の帰属が異なる合意になっている場合があります。「成果物の著作権は甲に帰属する」と一括で書かれていても、プロンプトや評価データが「成果物」の定義に含まれていないと、契約終了後に受託者側に流出したり再利用されたりする余地が残ります（伊藤海法律事務所：AI開発委託契約の特徴・ポイント）。

修正依頼テンプレ:

「成果物」の定義について、ソースコード・プロンプト・評価データセット・カスタムモデル（ファインチューニング済みモデル）・ログデータそれぞれを明示し、対象ごとに権利帰属を条項化いただけないでしょうか。特にプロンプトと評価データは業務ノウハウの中核となるため、当社帰属を希望します。

権利帰属の交渉ポイント（開発会社の汎用ノウハウとの線引き・撤退時の可搬性確保）や、入力データの第三者 LLM への送信ルール・秘密保持・再委託時の取扱いは、姉妹記事の同名セクションでより詳しく整理しています。

チェック5: モデル変更・API仕様変更時の対応

どこを見るか: 保守・運用フェーズに関する条項、モデル・API 変更対応に関する条項、および追加費用の取扱い条項。

Yes/No 判定基準:

Yes: モデル終了予告・価格改定・仕様変更が発生した場合の通知・対応義務、対応期限（例: プロバイダの終了予告日から X 営業日以内に代替案を提示）、追加費用が発生する場合の負担ルールが条項化されている
No: 「モデル変更時は別途協議」のみで、期限・費用負担のルールが定められていない

なぜ問題か（背景）: OpenAI・Anthropic 等の LLM プロバイダは、モデルの終了予告・価格改定・API 仕様変更を継続的に実施しています。契約書に「モデル変更時は別途協議」とだけ書かれている場合、期限が定められていないため、実際にプロバイダ側から終了通知が来た際に対応が後手に回るリスクがあります。「協議」の期限・費用負担・対応スコープが定義されていないと、緊急対応が必要になった際に発注者・受託者双方が身動きしにくい状態になります。

修正依頼テンプレ:

LLM プロバイダのモデル終了・価格改定・仕様変更が発生した場合について、通知義務・対応期限・追加費用負担のルールを条項化いただけないでしょうか。特にモデル終了予告から本番切り替えまでの期限は、プロバイダの通知期間（一般に 6〜12 ヶ月）を踏まえて事前に握っておきたいと考えています。

再評価トリガー（モデル変更時に評価データセットで再評価する義務化）や、マルチモデル前提でベンダーロックを避ける成果物要件の設計は、姉妹記事の「モデル更新・切替に対応する条項」セクションを参照してください。

契約書に潜む落とし穴と回避のポイント

先ほどの 5 つのチェックポイントは「あるべき条項の型」を扱いましたが、実際の契約書ドラフトには「一見問題なさそうだが後で揉める」表現がしばしば含まれます。ここでは、契約書ドラフトをスキャンする際に「見つけたら要修正」と判断できる 3 つの頻出パターンをまとめます。

曖昧な精度・品質条項の見抜き方

契約書ドラフトによく登場する曖昧表現は、以下のようなものです。

「精度は事前合意した基準に従う」
「実用に耐えうる品質を担保する」
「業界標準の水準を満たす」

これらは一見発注者に有利に見えますが、「事前合意」「実用に耐えうる」「業界標準」の定義がないため、検収時に受託者から「合意した基準は満たしている」と主張されれば反論の根拠がありません。契約書レビューでは、これらの曖昧表現を発見したら、必ず別紙・付帯資料で具体的な指標（データセット・指標・目標値）を握る形に修正を依頼します。

再委託・下請け条項の確認ポイント

AI エージェント開発では、LLM プロバイダとの直接契約に加えて、プロンプトエンジニアリング・評価データ作成・アノテーション等の作業を第三者に再委託するケースがあります。契約書に「再委託は乙の判断で行うことができる」と書かれている場合、無制限に再委託が可能となり、機密情報の取扱いや品質責任の所在が不明確になります。確認したいポイントは以下です。

再委託に発注者の事前承諾が必要か
再委託先の情報開示義務があるか（会社名・作業範囲）
再委託先の品質・機密保持について、受託者が発注者に対して責任を負う旨が明記されているか

特にプロンプトや評価データは業務ノウハウそのものであるため、これらを再委託先が扱う場合は、発注者側の承諾を必須とする条項に修正しておきます。

契約解除・成果物引き渡し条項の落とし穴

AI エージェント開発は継続的な運用・改善が前提となるため、契約途中で解除する場合の成果物引き渡しルールも重要です。契約書に「契約解除時は解除日までに完成した成果物を引き渡す」とだけ書かれている場合、「完成」の定義が曖昧なため、プロンプト・評価データ・学習ログといった「開発途中の中間成果物」が引き渡されないリスクがあります。確認したいポイントは以下です。

契約解除時に引き渡す対象に、ソースコードだけでなくプロンプト・評価データ・ログが含まれているか
引き渡し形式（ソースコード形式・ドキュメント形式・データベースダンプ形式）が明記されているか
引き渡し後の受託者側でのデータ削除義務が明記されているか

「引き渡す」だけでは不十分で、「何をどの形式で、いつまでに、削除も含めてどうするか」まで書き込んでおくことが望ましいです。

契約前に発注者側で準備しておくべきこと

契約書は発注者・受託者の合意事項を書面化したものであり、そもそも発注者側の準備不足が原因で契約後トラブルに発展するケースも少なくありません。本セクションでは、契約書レビューと並行して発注者側で整えておきたい 3 つの準備項目に絞って紹介します。

ユースケース・成功基準の言語化

AI エージェントで「何を」「どのレベルまで」自動化したいのかを、発注前に言語化しておく必要があります。曖昧なまま契約すると、開発会社ごとに解釈が異なり、見積・契約書の中身も比較しにくくなります。最低限、次の 3 点は文書化しておきます。

ユースケース: 誰が、いつ、何をするために使うのか（例: カスタマーサポート担当が問い合わせメールを受信した時に、一次回答案を自動生成する）
成功基準（定性）: 何ができれば「成功」と判断するのか（例: 一次回答案の 7 割を担当者がそのまま送信できる状態）
成功基準（定量）: どんな数値目標を追うのか（例: 一次回答生成の応答時間 5 秒以内、担当者が承認・送信するまでの平均時間を現状の 50% に短縮）

ここが曖昧なまま「精度 XX% 以上」といった数字だけで契約に進むと、実運用で目標と数字が乖離する原因になります。

評価データセットの準備と契約への反映

AI エージェントの精度を測定するためには、評価データセット（テストデータ）が必須です。業務データに近い評価データほど精度測定の信頼性が高くなるため、発注者側で用意した業務データを匿名化して提供するのが理想です。契約前に次の点を整理しておきます。

評価データの提供者（発注者 or 受託者）
提供するデータの件数・期間
匿名化・機密情報マスキングの責任範囲

契約書には、この評価データセットの取扱いを含めた条項（提供義務・機密保持・契約終了後の削除）を組み込みます。

社内体制（窓口・意思決定者）の明確化

AI エージェント開発は、PoC 期間中に業務担当者からのフィードバック・追加要望が頻発します。窓口担当者・意思決定者が明確でないと、受託者が誰の指示を優先すべきか判断できず、開発が停滞します。契約前に次の役割を社内で決めておきます。

窓口担当者: 受託者との日常的なやり取りを担う（週次定例の主催・追加要望の一次受付）
意思決定者: 予算追加・スケジュール変更・スコープ変更を承認する権限を持つ
業務ユーザー代表: 実際にエージェントを使う現場担当者から代表を選出（PoC 期間中のフィードバックを提供）

これらの体制図を契約書別紙として添付できると、責任分界が明確になります。

契約後・運用フェーズで見落としがちな注意点

契約締結後から運用フェーズまでには、契約書だけではカバーしきれない実務上の注意点があります。本セクションでは、契約後に発注者側で意識したい 3 つのポイントに絞って紹介します。

PoCから本開発への移行時の注意点

PoC 契約と本開発契約を分けている場合、PoC で得た知見（有効だったプロンプト・失敗したアプローチ・想定と異なった業務データの特性）が本開発フェーズに正しく引き継がれることが重要です。PoC の最終報告書に次の項目を含めるよう、契約書または業務仕様書レベルで合意しておきます。

PoC で試したプロンプトの全パターンとその評価結果
有効だったツール連携・データソースの特定
想定と乖離した業務データの特性・改善が必要な範囲
本開発フェーズでの追加投資が必要な項目

本開発契約を結ぶ際に、これらの知見を反映した精度目標値・費用見積・スコープ定義になっているかを確認します。なお、PoC 契約そのものの基本概念についてはプロトタイプ開発とPoCの違いも参考になります。

検収基準の運用と再評価

契約前に合意した精度目標値・評価データセットは、実運用開始後に「実データでの精度」と乖離することがあります。契約書に「検収は評価データセットに対する定量指標で行う」と定めていても、その評価データが実業務データと大きく異なる場合、検収は通っても実運用で問題が発覚します。運用開始後には、次のような再評価サイクルを組み込むことが望ましいです。

運用開始 1 ヶ月・3 ヶ月時点で、実データに基づく精度再測定を実施
再測定結果と初期評価データの結果を比較し、乖離があれば改善対応を協議
評価データセット自体を実データで更新するプロセスを組み込む

これらは契約書の中では「継続改善条項」「運用フェーズ支援」等の項目として盛り込みます。

運用開始後のAPI費用モニタリングとモデル更新対応

運用開始後は、LLM API 費用の実消費量を定期モニタリングし、想定と乖離していないかを確認します。想定超過が発生した場合の対応（プロンプトの短縮・キャッシュ導入・より安価なモデルへの切替）を、あらかじめ受託者と合意しておきます。

また、LLM プロバイダから発表されるモデル終了予告・価格改定・仕様変更のニュースは、契約書に定めた通知義務にかかわらず、発注者側でも定期的にフォローするのが安全です。プロバイダの終了予告は 6〜12 ヶ月前に出されるのが一般的ですが、その期間内に代替モデルへの切り替え・再評価・再検収を完了させる必要があるため、早期に情報をキャッチして受託者と対応スケジュールを握ります。

まとめ｜AIエージェント開発を契約するときの最終確認5項目

ここまでの内容を踏まえ、契約書ドラフトを受け取った発注者が Yes/No で答えられる形の最終チェックリストにまとめます。開発会社との交渉・社内稟議・顧問弁護士への相談時に、そのままお使いいただけます。

契約前チェックリスト5項目（Yes/No形式）

チェック 1: 契約形態が開発フェーズと合っているか

Yes: PoC は準委任、本開発は準委任または成果連動型として明確に分離されている
No: 本開発が請負契約になっており、精度に完成義務を負わせる書き方になっている

チェック 2: 精度目標値・検収基準が具体的に定義されているか

Yes: 評価データセット（提供者・件数）と定量指標（精度・応答時間など）が明記されている
No: 「事前合意した基準に従う」等の曖昧表現で、具体的な指標が別紙にもない

チェック 3: LLM API 費用の負担者・上限・変動時対応が明記されているか

Yes: 費用負担者・想定利用量の上限・想定超過時の協議ルールが条項化されている
No: 「API 費用は乙が負担する」のみで、想定量・上限・変動時対応が書かれていない

チェック 4: 知的財産権の帰属が要素ごとに明記されているか

Yes: ソースコード・プロンプト・評価データ・カスタムモデル・ログそれぞれの帰属が明示されている
No: 「成果物の著作権は甲に帰属する」のみで「成果物」の定義がない

チェック 5: モデル変更・API 仕様変更時の対応が期限付きで定められているか

Yes: 通知義務・対応期限・追加費用負担のルールが条項化されている
No: 「モデル変更時は別途協議」のみで期限や費用ルールがない

5 項目すべてが Yes であれば、AI エージェント開発契約として最低限の骨格は整っている状態です。1 項目でも No があれば、契約前に開発会社への修正依頼・条項追加を検討します。