AI開発でコードとプロンプトは誰のものか。契約で分ける5つの権利

AI 開発の見積書に、権利の話はほとんど出てこない。「納品物: ソースコード一式」と書かれていれば十分に見えるし、契約書にも「本件成果物の著作権は乙から甲に移転する」という一文が入っていることが多い。

それでも、2 年後に開発会社を替えるとき、あるいは内製へ切り替えるときに、必ず同じところで止まる。コードはあるのに、プロンプトが手元にない。評価用のデータが相手の環境にしかない。追加学習したモデルを持ち出せない。「成果物」という一語でまとめたせいで、中身が誰のものか決まっていなかったからである。

この記事では、権利を 5 つに分けて、それぞれ契約で何を決めるかを整理する。契約書そのものの確認項目はAI開発の契約書で確認すべき12項目にまとめてあるので、ここでは権利の帰属と使ってよい範囲に絞る。

5つに仕切られた木箱と、印鑑・契約書

権利は「成果物」とひとまとめにしない

AI 開発で後から取り合いになるものは、大きく 5 つある。性質がそれぞれ違うので、まとめて 1 行で処理すると必ずどれかが漏れる。

対象	決めること	決めていないと起きること
ソースコード	著作権の帰属／利用許諾の範囲／第三者部品の扱い	改修を他社に頼めない。公開範囲が分からない
プロンプト・システム指示	納品物に含めるか／開示の範囲	中身を知らないまま運用する。乗り換え時に精度が再現しない
評価データ・テストセット	誰が作り、誰が保有するか	次の会社で「同じ基準での比較」ができない
学習済みモデル・追加学習の結果	重みの持ち出し可否／再利用の範囲	学習にかけた費用が引き継げない
ログ・入出力履歴	保持期間／学習・分析への利用可否	自社データが他社の改善に使われる。開示請求に答えられない

以下、1 つずつ見ていく。

1. ソースコード — 「帰属」より「何をしてよいか」

コードの権利は、契約書で最も書かれている項目である。ただし「著作権は発注者に帰属する」と書いてあっても、実務では次の 3 点が曖昧なまま残りやすい。

第三者の部品（OSS ライブラリ、購入したコンポーネント）は譲渡の対象外になる。どのライセンスのものが何個入っているか、一覧が納品されるか
開発会社の汎用部品（他案件でも使う共通処理）は「乙に留保する」と書かれることが多い。留保される場合、発注者はそれを使い続けられるのか、改変できるのか
改修を他社に依頼してよいか。譲渡されていれば当然に見えるが、汎用部品が留保されていると、そこだけ他社が触れないことがある

つまり、確認すべきは帰属の一語ではなく、**「誰が・何を・どこまでしてよいか」**である。見積依頼の段階で「共通部品として留保する範囲の一覧」を出してもらえば、後から揉めにくい。

2. プロンプト・システム指示 — 実は精度の本体

生成 AI を使った開発では、品質の相当部分がプロンプト（システム指示・入力の組み立て方・出力形式の定義）に乗っている。ところがこれは開発会社にとってノウハウでもあるため、「納品物」に入っていないことがある。

分けて考えるのが現実的である。

区分	例	扱いの目安
業務固有の指示	自社の業務ルール・禁止表現・回答の型	発注者側に帰属させる。自社の業務知識そのもの
汎用の技法	出力を安定させる書き方、検証の手順	開発会社に留保されても実害は小さい

そのうえで、最低限「稼働中のシステムで実際に使われているプロンプトの全文を、いつでも参照・取得できる」ことを契約に書く。中身を見られない状態は、ハルシネーションの原因を調べることも、出力の妥当性を説明することもできないという意味で、運用上のリスクでもある。

なお、プロンプトに何を書いたかはプロンプト設計とはで扱ったとおり出力を大きく変える。乗り換え時に精度が落ちる典型が、プロンプトを引き継がずにコードだけ移したケースである。

3. 評価データ・テストセット — いちばん価値が残る資産

「この入力なら、この出力が正解」という組を集めたものが評価データである。地味だが、AI 開発でいちばん長く価値が残る資産はこれだと考えている。

理由は 2 つある。1 つは、自社の業務判断が凝縮されているから。もう 1 つは、会社を替えても同じ物差しで比較できるから。評価データが手元にあれば、次の会社の提案を「うちの正解データで何点出ますか」と検証できる。無ければ、また一から作ることになる。作成の考え方はAI開発のデータ準備とAIの精度をどう評価するかで扱った。

契約で決めることは次の 3 点である。

評価データの作成費用がどこに計上されているか（「別途」になりやすい費用の代表格）
完成した評価データの保有者は誰か（発注者側に置くのが原則）
開発会社が他案件に転用してよいか

4. 学習済みモデル・追加学習の結果 — 基盤モデルの規約に縛られる

自社データで追加学習（ファインチューニング）した場合、その結果物の扱いは、コードほど単純ではない。土台となる基盤モデルの利用規約が上にかぶさるからである。

追加学習の結果（重み・アダプタ）をエクスポートして別環境で動かせるかは、使った基盤モデルとサービスの規約で決まる。契約書に「発注者に帰属」と書いても、規約上取り出せないものは取り出せない
したがって決めるべきは所有権の宣言ではなく、「乗り換えるときに何を持ち出せるか」の事実確認である
学習に使ったデータセットの保有者も別に決める（多くの場合、これは発注者側のデータである）

そもそも追加学習が必要かどうかはRAGとファインチューニングで比較した。持ち出せない資産に費用をかける前に、RAG で足りないかを先に検討したほうがよいというのは、費用面だけでなく権利面から見ても成り立つ。

5. ログ・入出力履歴 — 誰の改善に使われるか

運用が始まると、入力と出力の履歴が貯まる。ここには顧客の問い合わせ内容や社内の文書がそのまま入る。決めるのは 3 点。

保持期間と保存場所（国内か国外か、誰がアクセスできるか）
開発会社が改善目的で利用してよいか。よい場合、どの範囲まで（自社案件のみか、他案件にも及ぶか）
契約終了時に削除するか、引き渡すか

外部 API を経由する場合は、その提供元の規約も重なる。どのデータを外に出してよいかの整理はAIシステムのセキュリティ設計と生成AIの著作権・法的リスクで扱った。

「著作権はすべて発注者に帰属」で終わらない 3 つの理由

ここまでを踏まえると、契約書の一文だけでは処理しきれない理由がはっきりする。

第三者の権利が混ざっている。 OSS も外部 API も、提供元の条件が優先する。譲渡の意思表示では上書きできない
著作権の対象にならないものがある。 評価データの収録内容やログの扱いは、著作権ではなく契約上の取り決めで決まる部分が大きい
「持っていること」と「使えること」が別。 重みを受け取っても動かせる環境がなければ意味がない。引き継ぎで必要なものはAI開発の引き継ぎの 12 項目で確認する

具体的な条文の当てはめは案件ごとに違うため、最終的な文言は自社の法務や専門家に確認してほしい。経済産業省が「AI・データの利用に関する契約ガイドライン」と「AI の利用・開発に関する契約チェックリスト」を公開しているので、社内の検討の土台として使える。

権利を広く取るほど、見積もりは上がる

もう 1 つ、費用の話をしておく。権利をどこまで取るかは、そのまま価格に跳ねる。 開発会社から見ると、汎用部品を他案件で使えないこと、同業他社に同種のシステムを提供できないことは、事業上の制約だからである。

段階を付けて考えるとよい。

取り方	内容	費用への影響
A. 利用許諾のみ	発注者は使えるが、権利は開発会社	最も安い。ただし乗り換えが難しい
B. 譲渡（非独占）	発注者に帰属。汎用部品は開発会社が他でも使う	標準的。多くの案件はここで足りる
C. 譲渡＋競合提供の制限	同業他社への提供を一定期間禁止	上がる。競争優位が本当に必要な案件だけ

3 社の見積もりが割れる理由の 1 つがここにある。A で見積もった会社と C で見積もった会社を、金額だけで比べても意味がない。 だから相見積もりを取るときは、権利の取り方を先に条件として指定しておく必要がある。条件をそろえる 12 項目は相見積もりで条件を揃える12項目にまとめた。

内製化を視野に入れているなら、B 以上は事実上の前提になる。判断の分かれ目はAI開発、内製と外注はどちらが安いかで整理している。

見積依頼に書く一文（例）

長い条文は不要である。見積依頼や案件票の備考に、次の程度を書いておけば各社の前提がそろう。

成果物の権利について、次の前提で見積もりをお願いします。 (1) ソースコードは当社帰属。貴社の共通部品を留保する場合は、その範囲の一覧を提示ください (2) 業務固有のプロンプト・システム指示は納品物に含め、稼働中の内容をいつでも参照できるようにしてください (3) 評価データは当社保有とし、他案件への転用は不可とします (4) 追加学習を行う場合は、成果物を当社環境へ持ち出せるかどうかを明記ください (5) 入出力ログの保持期間・保存場所と、貴社が改善目的で利用する範囲を明記ください

この 5 行を入れるだけで、返ってくる見積もりの比較しやすさが変わる。同じ条件で複数社に出すことが目的なので、内容は自社の事情に合わせて調整してよい。条件を揃えた案件票で相見積もりを取りたい場合は、無料の相見積もりから案件票を作れる。

まとめ

権利は「成果物」とまとめず、コード・プロンプト・評価データ・学習済みモデル・ログの 5 つに分ける
確認するのは帰属の一語ではなく、誰が・何を・どこまでしてよいか
評価データとプロンプトは、乗り換え・内製化のときに最も効く。ここを手元に置く
追加学習の結果は、契約より基盤モデルの規約が先に効く。持ち出せるかを事実として確認する
権利を広く取るほど費用は上がる。先に条件として指定してから相見積もりを取る

参考

経済産業省「AI・データの利用に関する契約ガイドライン 1.1 版」: https://www.meti.go.jp/policy/mono_info_service/connected_industries/sharing_and_utilization/20200619002.pdf
経済産業省「AI の利用・開発に関する契約チェックリスト」: https://www.meti.go.jp/press/2024/02/20250218003/20250218003.html