PoC契約で決めておくこと

PoCの契約書は、本開発の契約書を流用して作られることがよくあります。金額が小さいので細かいところは詰めない、という判断も見かけます。しかしPoCには本開発とは違う論点があり、特にAIを使う検証では、データとプロンプトの扱いが後から問題になりやすいところです。

本記事では、PoCを外部に委託する際に着手前に決めておく論点を整理します。契約書の文言そのものではなく、何を決めておく必要があるかという観点でまとめます。

なぜ準委任が原則になるのか

請負契約は、完成した成果物の引き渡しに対して対価を払う契約です。何を作るかが決まっていることが前提になります。

PoCは、この前提と噛み合いません。検証の目的は「うまくいくかを確かめること」であり、うまくいかないという結論も正当な成果です。請負契約でこれをやろうとすると、「精度が出なかったので完成していない」という理屈が成り立ってしまい、受注側は成果を出すために検証条件を有利に調整する動機を持ちます。それは検証として本末転倒です。

準委任契約は、成果物の完成ではなく専門家としての業務の遂行に対価を払う形です。PoCではこちらが原則になります。契約形態の一般的な違いについてはアジャイル開発と契約で扱っているので、ここではPoC固有の点に絞ります。

例外として、請負が成立する場合もあります。「既製のAIツールを既存システムに接続する」など、作業内容が確定していて結果が読める場合です。この場合は検証というより導入作業に近く、請負で問題ありません。自社のPoCがどちらの性質かを意識して選んでください。

成果物を「判断に使える情報」として定義する

準委任だから成果物を定めなくてよい、というわけではありません。むしろ準委任のほうが、何を受け取るかを具体的に書く必要があります。「PoCの実施及び報告」とだけ書かれた契約は、報告の中身が薄くても契約違反になりません。

成果物として定めておきたいのは、次のような項目です。

• 検証した条件（使用したデータの範囲と件数、使用したAIサービスとその設定）
• 検証の結果（達成できたこと、達成できなかったこと、その理由）
• 本番化する場合の構成案と、費用の概算（一回あたりの処理費用と想定される月額の規模）
• 本番化にあたって未解決の論点
• 検証で作成したプログラム一式（該当する場合）

三つ目と四つ目が書かれていない報告書は、社内の判断材料になりません。契約の時点で項目として挙げておくと、報告の質が安定します。報告書に何を書くべきかはPoC報告書に何を書くべきかで詳しく扱っています。

提供するデータの扱い

AIのPoCでは、ほぼ必ず自社のデータを外部に渡します。ここが本開発との最大の違いで、かつ最も見落とされる点です。決めておくべきことを分解すると、次のようになります。

どこに置くか。 受注側の開発環境なのか、自社が用意した環境なのか。受注側の環境の場合、そこにアクセスできる人の範囲を確認します。再委託先がいる場合は、その先まで確認が必要です。

外部のAIサービスに送られるか。 これが核心です。OpenAI、Anthropic、Googleなどが提供するAPIを使う場合、入力したデータはそれらの事業者のサーバーに送られます。多くの事業者は、API経由の入力をモデルの学習に使わない方針や設定を用意していますが、契約プランや設定によって扱いが変わります。どのサービスのどのプランを使い、学習利用がどう設定されているかを、PoCの開始前に確認してください。

いつ消すか。 検証終了後、提供したデータと、そこから作られた中間データをいつ消去するか、消去したことをどう確認するかを決めます。「終了後速やかに」という文言だけでは、実際には消されないまま残ることがあります。

個人情報が含まれるか。 含まれる場合は、個人情報保護法上の委託の位置づけになるのが一般的で、委託先に対する監督責任が発注側に生じます。可能であれば、個人を識別できる情報を落としたデータで検証してください。PoCの目的が精度の確認であれば、氏名や連絡先が必要になることはあまりありません。この領域の一般的な実務はスタートアップのセキュリティと個人情報保護も参考になります。

プロンプトとコードの権利

既存のAIサービスを使う開発では、成果の多くがプロンプト（AIへの指示文）に蓄積されます。何度も試して調整したプロンプトは、その業務における実質的なノウハウです。

ここで問題になるのは、プロンプトの扱いが従来の契約書の想定に入っていないことです。「本件成果物の著作権は委託者に帰属する」という条項があっても、プロンプトが成果物に含まれるのか、そもそも著作物として保護されるのかは一律には決まりません。

実務的には、権利の帰属を争うより、利用条件として書くほうが確実です。具体的には、発注側がそのプロンプトを制限なく使用し、改変し、他の事業者に開示できることを明記します。あわせて、受注側が他社の案件で同じプロンプトを使うことを認めるかどうかも決めます。汎用的な指示文まで禁止すると受注側が受けられなくなるので、「自社の業務固有の記述を含む部分」に限定するのが落としどころになりやすい点です。

コードについても同様です。PoCのコードをそのまま本番に使うことは少ないものの、本番を別の会社に頼む可能性がある以上、引き渡しを受けられる形にしておいてください。

中止したときの扱い

PoCは、途中で「これ以上続けても判断は変わらない」と分かることがあります。むしろ、それが早く分かるのは良い検証です。

しかし契約に中途終了の定めがないと、当初の期間と金額を消化することになります。これは双方にとって無駄です。次の二点を入れておくと、判断を止めずに済みます。

• 一定の予告期間をもって、いずれからも終了できること
• 終了時点までの稼働に応じて精算し、その時点での記録と成果物の引き渡しを行うこと

「早く終わったら安く済む」という形になっていると、途中での軌道修正が議論しやすくなります。中止の判断そのものについてはPoCを中止する判断の下し方で扱っています。

契約は、判断を妨げないために結ぶ

PoCの契約で決めるべきことを並べましたが、目的は受注側を縛ることではありません。検証の途中で「やめよう」「方向を変えよう」という判断が出たときに、契約が邪魔をしないようにすることです。

準委任で進め、成果物を情報として定義し、データとプロンプトの扱いを先に決める。この三点が押さえられていれば、PoCの期間中に何が起きても判断を優先できます。

弊社はAI活用開発およびWebシステム開発として、既存のAIサービスを組み込んだシステムの実装をお引き受けしています。検証の段階からご一緒する場合も、ここで挙げた論点は着手前に整理してお伝えしています。お問い合わせからご相談ください。

本記事は一般的な情報であり、個別の契約・個人情報の取り扱いに関する事案は弁護士等の専門家にご確認ください。