契約と更新 公開: 2026/4/29

AIで作った成果物、契約で先に分けたいこと

生成AIを使った成果物は、便利さだけで進めると権利、入力データ、再利用ルールが曖昧になりやすいです。契約前に分けておきたい確認事項を整理します。

AI活用時の成果物と契約条件を整理する抽象図
ValueGate Blog

AIで作った成果物、契約で先に分けたいこと

AIを使っていいか、聞きづらいまま進んでいないか

「この作業、AIを使った方が早いけど、どこまで言えばいいんだろう…」

受託開発や業務委託の現場で、こう感じる場面が増えていませんか? コードの下書き、設計メモの整理、議事録の要約、テスト観点の洗い出し。AIを使えばかなり速くなる作業はあります。だけど、いざ納品物や契約の話になると、急に手が止まるんですよね。

便利だから使う。効率が上がるから使う。そこまでは自然です。ただ、相手に渡す成果物にAIが関わるなら、少しだけ先に確認したいことがあります。入力してよい情報は何か、生成されたものを誰が確認するのか、納品後に再利用してよい範囲はどこまでか。ここが曖昧なままだと、あとから「それは聞いていない」が起きやすくなります。

2026年3月31日に、経済産業省と総務省は AI事業者ガイドライン(第1.2版) を公表しました。ガイドライン自体は企業や事業者向けのものですが、AIの開発者、提供者、利用者という立場を分け、リスクをライフサイクル全体で見ていく考え方は、個人で案件に入るエンジニアにも関係します。つまり、AIを使うかどうかだけではなく、どの立場で、どこまで責任を持つのか が問われやすくなっています。

ここで大事なのは、AIを使うこと自体を怖がりすぎることではありません。むしろ、使う前提なら、契約や合意の中で分けるべきものを先に分けることです。この記事では、AIを使った成果物について、契約前にどこを確認しておくと後から揉めにくいかを整理します📝

たとえば、業務委託で小さな管理画面を作っているエンジニアがいたとします。仕様の確認メモをAIに整理させ、テスト観点もAIで下書きしました。本人としては「作業を速くしただけ」です。でも納品前のレビューで、発注側から「その仕様メモ、社外サービスに入れたんですか?」と聞かれて、急に空気が固くなる。こういう話は、これから増えやすいです。だから最初に、AIで何をしてよいかを作業単位で分けておく ことが大事になります。

曖昧になりやすいのは、成果物そのものだけじゃない

AI活用の話になると、つい「生成物の権利は誰のものか」に目が行きます。もちろんそこは大事です。ただ、実務で詰まりやすいのは、権利の一言だけではありません。もっと手前に、何を入力してよいか、どこまでAIに任せてよいか、誰が最後に見るか、という論点があります。

ここを飛ばして「成果物の著作権はどうしますか」と聞いても、相手も答えにくいです。なぜなら、成果物がどう作られるのか、どんな情報を使うのか、どの段階で人が見ているのかが見えていないからです。AIの話は、権利だけを切り出すより、作業プロセスとセットで整理した方が進めやすくなります。

入力してよい情報が曖昧だと、最初から危ない

まず分けたいのは、AIツールに入力してよい情報です。公開情報だけなのか、仕様書や議事録も含むのか、ソースコードや顧客データを入れてよいのか。ここを確認しないまま進めると、成果物以前に情報管理の問題になりやすいです。

特に業務委託では、自分にとっては作業効率化のつもりでも、発注側から見ると「外部サービスに情報を入れた」行為に見えることがあります。これ、悪意がなくてもかなりズレます。だから最初に必要なのは、AI利用の可否だけではなく、入力できる情報の範囲 を決めることです。

たとえば、公開済みドキュメントは可、社内資料は不可、匿名化した要約のみ可、顧客情報や未公開コードは不可、のように分けておく。ここまで決めておけば、作業中に迷う場面がかなり減ります。AIを使うなら、最初の安全ラインはここです。

AIが作ったものを、誰が確認するか

次に見たいのは、生成された内容を誰が確認するかです。AIが出したコードや文章や設計案を、そのまま成果物として扱うのか。人がレビューして、採用した部分だけを成果物に含めるのか。この違いはかなり大きいです。

実務では、AIの出力は「答え」ではなく「材料」として扱う方が安全です。コードなら動作確認やセキュリティ確認が必要ですし、文章なら事実確認や表現の調整が必要です。AIが作ったから責任が軽くなるわけではなく、むしろ どの確認を人がやったのか を言えることが大事になります。

ここを決めていないと、納品後に不具合や誤りが出た時に話がこじれます。「AIが出したので」とは言えませんし、相手から見れば納品者が出した成果物です。だから、契約や作業ルールの中で、AI出力は下書きとして扱い、最終判断は人が行う、と明確にしておく方が現実的です。

再利用してよい範囲が見えないと、後で気まずくなる

もう一つ見落としやすいのが再利用です。AIを使って作ったテンプレート、プロンプト、補助スクリプト、テスト観点、設計メモ。これらを次の案件でも使ってよいのか、発注側専用の成果物として扱うのか。ここが曖昧だと、あとでかなり気まずくなります。

特にフリーランスや受託側は、自分のノウハウを次の案件にも活かしたいはずです。一方で、発注側から見ると、自社の要件や業務知識が入ったものを他社案件に流用されるのは避けたい。どちらも自然な感覚です。だからこそ、最初から分ける必要があります。

ここで使いやすい分け方は、汎用ノウハウと個別成果物を分けることです。一般的な進め方、抽象化したチェックリスト、個人が持ち込んだテンプレートは再利用可。ただし、顧客固有の要件、未公開情報、具体的な設計判断、納品物そのものは再利用不可。こう分けるだけでも、かなり話しやすくなります。

AI利用時の入力情報、確認責任、権利、再利用範囲を分けて整理するワークフロー
AI利用は、入力情報、確認責任、権利、再利用範囲を分けておくと話しやすくなります。

契約前に分けたいのは、この5つ

AI活用を契約に入れるとき、いきなり完璧な条文を作ろうとすると止まりやすいです。法律の細かい判断が必要な部分は専門家に確認した方がいいですが、現場の最初の会話では、もっと実務的に分けられることがあります。

まずは、作業ルールとして次の5つを確認しておくと進めやすいです。AIを使うかどうか、何を入れてよいか、出力をどう確認するか、成果物をどう扱うか、再利用できるものは何か。この5つが見えていれば、契約書や発注書に落とす前の会話がかなり整理されます。

1. AI利用の可否

最初に、AIを使ってよい作業と使わない作業を分けます。全部禁止か全部自由かではなく、調査、要約、コード補助、テスト観点、ドキュメント下書きなど、作業単位で分ける方が現実的です。

ここで大事なのは、「効率化のために使いたい」とだけ言わないことです。相手が気にしているのは、速さよりも情報管理や品質です。だから、使う場面、使わない場面、人が確認する場面をセットで伝えると、話が通りやすくなります。

2. 入力できる情報の範囲

次に、AIツールへ入力してよい情報を決めます。公開情報だけなのか、社内資料も可能なのか、コードは可能なのか、顧客情報は絶対に不可なのか。ここは具体的に書いた方がいいです。

「機密情報は入れない」だけだと、現場では迷います。仕様書は機密なのか、エラーログはどうか、匿名化した内容ならよいのか。こうした境界をできるだけ作業前に合わせておくと、後から説明しやすくなります。ここは面倒でも、あとで一番効いてくる確認 です。

3. 出力の確認責任

AI出力を使う場合、最終確認を誰がするのかも決めます。受託側が確認して納品するのか、発注側レビューを前提にするのか、重要箇所だけ別途確認するのか。ここが曖昧だと、品質問題が起きた時に責任の置き場が不安定になります。

おすすめは、AI出力をそのまま納品物にしない前提を置くことです。AIは下書きや補助として使い、最終的な判断、修正、検証は人が行う。これを言葉にしておくだけで、AI活用が「丸投げ」ではなく、作業品質を保つための補助だと伝わりやすくなります。

たとえばレビューで「このテスト観点はAIで下書きしましたが、最終的にはこちらで仕様と照らして確認しています」と言えると、相手の受け取り方は変わります。AIを使ったかどうかより、人がどこで責任を持って見たか が伝わるからです。

4. 成果物の権利と利用範囲

成果物の権利は、納品物、元資料、作業中に作った補助物を分けて考えます。納品物は発注側に利用権を渡すのか、著作権譲渡まで含むのか、受託側が実績として紹介できるのか。ここは案件ごとにかなり変わります。

AIを使った場合でも、「AIが関わったから全部曖昧」ではなく、どの成果物を誰が何の目的で使えるかを分けることが重要です。たとえば、納品した設計書は発注側が利用、汎用的な作業テンプレートは受託側も再利用可、顧客固有情報を含む資料は再利用不可、のように整理できます。ここで見たいのは、難しい言葉よりも 何を誰が使ってよいか です。

5. 再利用できるノウハウとできない情報

最後に、再利用の線引きです。ここを決めておかないと、受託側は自分のノウハウを使いにくくなり、発注側は情報流出を心配し続けることになります。どちらにとっても動きづらいです。

線引きの基本は、抽象化できるものと、顧客固有のものを分けることです。一般的なチェック観点、プロンプトの型、作業手順は再利用可にしやすい。一方で、具体的な業務ルール、顧客名、未公開コード、設計判断、データ構造は再利用不可にする。ここまで合意できると、AI活用の怖さはかなり減ります。

先ほどの管理画面の例で言えば、「ログイン画面の一般的なテスト観点」は次の案件でも使いやすいです。でも、その会社独自の承認フローや権限設計は別です。そこまで持ち出すと、発注側は不安になります。だから、再利用したいものほど、汎用ノウハウなのか、相手固有の情報なのか を分けておく必要があります。

話し方を間違えると、AI利用は不安として伝わる

AIを使いたいと伝えるとき、受託側はつい「効率化できます」「早くできます」と言いたくなります。もちろん、それは価値です。ただ、相手が最初に気にするのは、そこではないことも多いです。情報を入れて大丈夫なのか、品質は落ちないのか、成果物の扱いはどうなるのか。そこが見えないと、AI利用は便利さではなく不安として伝わります。

だから、提案の順番が大事です。いきなり「AIを使います」ではなく、「この範囲では使う、この情報は入れない、出力は人が確認する、成果物と再利用範囲は分ける」と伝える。ここまで言えると、相手は検討しやすくなります。

「使うかどうか」ではなく「どう管理するか」で話す

AI活用の会話を、使っていいか悪いかだけにすると、話が固くなります。相手も判断材料がないので、安全側に倒して禁止にしやすいです。そうではなく、どう管理するかで話す方が建設的です。

たとえば、「公開情報の調査整理とテスト観点の下書きに限って使います」「顧客情報や未公開コードは入力しません」「出力内容は納品前にこちらで確認します」と伝える。これなら、相手はリスクを具体的に見られます。AI利用の提案は、ツール名より先に 運用ルールを出した方が通りやすい です。

契約書に入れる前に、作業ルールとして合意する

契約書の条文まで一気に詰めようとすると、法務確認で止まることがあります。もちろん重要な案件では必要です。ただ、現場の初動では、まず作業ルールとして合意しておくだけでも違います。

たとえば、キックオフ時にAI利用範囲を確認する、入力禁止情報を一覧にする、成果物レビュー時にAI補助の有無を必要に応じて共有する、再利用不可の情報を明記する。こうした運用があるだけで、後から契約条文に落とす時も話が早くなります。最初から完璧な条文にしなくても、まず現場で迷わないルールを置く だけでかなり違います。

最後に

AIを使った成果物で大事なのは、AIを使うかどうかだけではありません。入力情報、確認責任、成果物の扱い、再利用範囲を分けておくことです。ここが曖昧なまま進むと、便利さよりも不安の方が大きく見えてしまいます。

逆に、先に分けられていれば、AIはかなり使いやすくなります。発注側も安心して任せやすくなりますし、受託側も自分のノウハウを守りながら効率化できます。AI活用を隠す話にせず、管理できる形で提案する。ここがこれからの契約ではかなり大事になってきます。

まずは次の案件で、AI利用についてこの5つだけ確認してみてください。使ってよい作業、入力してよい情報、人が確認する範囲、成果物の利用範囲、再利用できるノウハウ。この5つが見えているだけで、AIを使う話はずっと落ち着いて進めやすくなります。最初の一歩は、難しい契約書を作ることではなく、「これはAIに入れない」「これは人が確認する」を言葉にすること です✨

運営と監修

運営: ValueGate / 監修・相談窓口: ゆーちゃん

記事では再利用できる構造を言語化し、個別判断が必要な場合は無料診断で次アクションを整理する役割分担にしています。

関連記事