AI開発の契約前に決める3論点 — 精度・データ・権利

AIを組み込んだ業務システムの受注開発で、後から揉めるポイントはだいたい決まっています。「思っていた精度が出ない」「学習や検証に使ったデータはどちらのものか」「出来上がったプロンプトやモデルを他社にも使われるのか」。この3つです。

いずれも、契約書を交わす前の打ち合わせで言葉にしておけば、ほとんどが防げます。逆に、ここを曖昧にしたまま「とりあえず走りながら決めましょう」で進むと、検収の段階で発注側と受託側の認識が正面からぶつかります。

この記事は法的な助言ではありません。契約書の条文例を示すものでも、「こう書けば安全」と断定するものでもありません。発注側と受託側が、契約の前にどんな論点を話し合っておくべきかという整理のための記事です。実際の条文化は、必ず弁護士など専門家に相談してください。

なぜAI開発では「普通のシステム開発の契約感覚」がずれるのか

従来の業務システムなら、仕様書に書いた機能が動けば完成です。「取引先マスタを登録できる」は、動くか動かないかで判定できます。

ところがAI機能は、同じ入力でも出力が揺れることを前提とした部品です。請求書を読み取るAIが100枚中97枚を正しく処理できたとき、それは完成なのか未完成なのか。この問いに、契約の前に答えを用意しておく必要があります。

さらに、AI機能の品質は受託側の技術力だけでは決まりません。発注側が提供するデータの質、業務ルールの明確さ、使っている外部モデルの仕様変更。どれも結果に影響します。結果に対する責任の所在が、従来型の開発より分散している——ここがずれの根本です。

参考として、経済産業省が公表している「AI・データの利用に関する契約ガイドライン」、および総務省・経済産業省による「AI事業者ガイドライン」が、この領域の論点整理として公開されています。契約そのものの雛形ではありませんが、何を論点として扱うべきかの地図としては目を通しておく価値があります。

論点1：精度を「何で測るか」を先に合意する

最も揉めるのがここです。そして揉める原因の多くは、数値の高低ではなく測り方が決まっていなかったことにあります。

話し合っておきたいのは、次のような項目です。

• 評価に使うデータ：誰が、いつ、何件用意するのか。本番で実際に流れるデータの分布を反映しているか
• 正解の定義：誰が「これが正解」と判定するのか。判定者によってブレる業務なら、ブレ自体をどう扱うか
• 測定のタイミング：開発完了時の1回だけか、運用開始後も定期的に測るのか
• 間違いの重さの区別：全部同じ1件と数えるのか、見逃してはいけない誤りを別枠で扱うのか

特に4つ目は実務で効きます。たとえば次のような場面です。請求書読み取りで「取引先名の表記ゆれ」と「金額の桁違い」を同じ1件の誤りとして数えると、現場の感覚と合いません。金額の誤りはゼロでなければ使えないが、表記ゆれは人が直せばよい、という区別があるはずです。

この考え方については、AIの検収は「正解率一本」では書けない — 必達条件と目標値の二段構えで合否を決めるでも整理しています。「絶対に満たすべき条件」と「目指す水準」を分けて置くと、合否の議論が現実的になります。

また、評価用データそのものを誰が作って誰が保管するのかも、意外と抜けます。AI の「良くなった気がする」を卒業する — 評価データセットの作り方と運用で触れたように、評価データは運用フェーズでも使い続ける資産です。契約期間が終わった後にどちらの手元に残るのかは、先に決めておきたい項目です。

論点2：データの流れを一枚で書き出す

AI開発では、発注側のデータが複数の場所を通ります。それぞれについて、扱いを決めておきます。

個人情報を含む場合は個人情報保護法、取引先から預かった情報が含まれる場合は不正競争防止法上の営業秘密の扱いなど、関係する法律の名称を押さえたうえで、具体的な適用は専門家に確認する——この順序が安全です。この記事で断定できるのは「論点として必ず扱うべき」という点までです。

実務上の落とし穴は、外部AIサービスの利用規約が開発途中で変わることです。入力データの学習利用に関する条件や、保存期間の扱いは、提供事業者の方針変更で動きます。契約時点の規約内容をそのまま前提に固定するのではなく、変更があった場合に誰がどう通知して、どう判断するかを決めておくほうが現実的です。

加えて、送ってはいけないデータを送らないための仕組みをどちらが実装するのかも論点です。AIに渡せない入力を止める手順 — 判定・遮断・案内の設計で扱ったような遮断の仕組みは、「あれば安心」ではなく、要件として最初から含めるかどうかの判断が必要です。

論点3：成果物の権利は「部品ごと」に分けて考える

AI業務システムの成果物は、一枚岩ではありません。少なくとも次のような層に分かれます。

• アプリケーションのソースコード
• プロンプト（AIへの指示文とその設計）
• 学習データ、評価データ
• 追加学習したモデルや、その設定値
• 業務知識を整理したドキュメント、用語集

「全部まとめて発注側に帰属」とすると受託側の汎用技術まで縛ることになり、「全部受託側に帰属」とすると発注側は自社の業務知識を取り返せません。層ごとに扱いを変えるのが実務的です。

特に議論になりやすいのがプロンプトです。プロンプトには、発注側の業務ルールや判断基準が濃く書き込まれます。同時に、受託側が蓄積した設計の型も入っています。どこまでが業務知識でどこからが汎用ノウハウか、きれいに切れないことが多い。だからこそ、切れないという前提で、どの範囲なら受託側が他案件に転用してよいかを言葉にしておく必要があります。

また、AIが生成したコードの著作権の扱いは、著作権法の解釈として議論が続いている領域です。ここで断定的な結論を書くことはできません。確実に言えるのは、「生成AIを開発工程で使うかどうか」「使う場合にどのツールをどの範囲で使うか」を、契約の前に双方が把握しておくべきだということです。AI受託開発の見積書と契約書は何が変わったかでも触れましたが、この申告は近年の受託開発では標準的な確認事項になりつつあります。

見落としやすい第4の論点：モデルが変わった日の扱い

精度・データ・権利の3つに加えて、もう一つ決めておきたいのが外部モデルの仕様変更が起きたときの責任分担です。

外部のAIモデルは、提供事業者の判断で更新され、旧バージョンの提供が終了することがあります。更新によって出力の傾向が変わり、今まで通っていた処理が通らなくなる可能性があります。これは受託側の瑕疵ではありませんが、発注側にとっては業務が止まる事態です。

話し合っておく内容としては、次のようなものが考えられます。

• モデル更新の情報を誰が監視するのか
• 更新後の再評価を誰が実施し、費用をどう扱うのか
• どの程度の変化なら保守の範囲内で、どこからが別見積もりか
• 旧モデル提供終了までの移行猶予をどう確保するか

この費用の見方については、AI機能の保守費は「モデルが変わる日」を先に見積もるで詳しく扱っています。保守契約の金額だけを見比べるのではなく、「何が保守に含まれるか」の定義のほうが重要です。

まとめ：契約書を書く前に、打ち合わせの議事録を作る

ここまで挙げた論点を整理します。

おすすめしたい進め方は単純です。契約書の起案に入る前に、この4項目について双方の認識を議事録として文章にすること。議事録の段階で意見が割れるなら、それは契約書に落とし込んでも割れます。逆に、議事録で合意できていれば、条文化は専門家に任せても大きくずれません。

AI開発の契約が難しいのは、法律が特殊だからではなく、「完成」の定義が従来型より曖昧だからです。曖昧さを契約書の文言で消そうとするより、曖昧さの所在を双方で特定して、どう扱うか先に決める。そのほうが、結果的に両者にとって安全な進め方になります。

なお、本記事で触れた法令やガイドラインの具体的な適用については、個別の事情によって判断が変わります。実際の契約にあたっては、弁護士など専門家への相談を前提としてください。