このページの要点
- 納品物は別表で一覧にする。プロンプトや設定は著作権で守りにくい部分があり、契約と秘密の管理で補う（著作権法2条1項1号・10条3項、不正競争防止法2条6項）。
- 帰属と利用許諾は別の軸。権利を移す型では翻案権等（27条・28条）を特掲し、著作者人格権は不行使の約束で補う（61条2項・59条）。
- 商用利用と第三者提供の禁止は、誰が使うか・どの事業で使うか・何を渡すかの三つの軸で書き分ける。利用権の譲渡には承諾が要る（63条3項）。
- 受託者の再利用は汎用部分に限り、秘密保持条項との優先関係を決める。クラウド環境の名義、引渡し、終了後の削除まで納品物の一部として書く。
結論：納品物の「誰のものか」と「どこまで使えるか」は別の取り決め。一覧にして一つずつ決める
AIの導入支援や開発の成果物は、文章や図面のように一目で完成品と分かるものばかりではありません。AIに指示を出すための文章（プロンプト）、サービスの動きを決める設定、繰り返し使うひな形（テンプレート）、複数の作業をつなぐ自動化の流れ（ワークフロー）、クラウド上の作業環境、使い方の手順書。こうしたものが「納品物」として渡されます。形がはっきりしないぶん、「納品したのだから依頼者のもの」とも、「作ったのは受託者だから受託者のもの」とも、当然にはいえません。
揉めやすいのは、権利の帰属と利用の範囲を一文に押し込んでしまうときです。たとえば「納品物の著作権は受託者に帰属する」と書くだけでは、依頼者がそれを自社の業務でどこまで使えるのかが分かりません。逆に「依頼者は商用で自由に利用できる」と書きながら、別の条で「第三者への提供を禁止する」と書くと、依頼者が自社の顧客向けのサービスの中で使うことが許されるのか、読む人によって答えが分かれます。
このページは、条文と一般的な契約実務にもとづく整理で、特定の契約や納品物への当てはめではありません。実際の取引では、納品物の中身、契約の型（請負か準委任か）、外部のサービスの利用条件によって結論が変わります。導入支援の基本契約の全体の組み立てはAI導入研修・導入支援・保守サポートの基本契約と個別契約で、開発契約でデータを渡す側と預かる側の約束はAI開発を依頼するとき・受けるときのデータの約束と納入後の運用で扱います。ここでは、納品物そのものの権利に絞ります。
結論を先に並べます。
- 納品物は、契約書の中で一覧にする。「その他一切の成果物」とだけ書くと、プロンプトや設定のどこまでが含まれるのかが後から争いになる。
- 帰属と利用許諾は、別々の軸で決める。受託者に権利を残して依頼者に利用を許諾する型と、依頼者に権利を移す型がある。どちらでも、依頼者が何をできるかを同じ条に書く。
- 権利を移す型では、翻案権等（著作権法27条・28条）を特掲する。特掲がないと、譲渡した側に留保されたものと推定される（同法61条2項）。著作者人格権は譲渡できない（同法59条）ので、不行使の約束で補う。
- 「商用利用できる」と「第三者提供の禁止」は、線引きの軸を決めてから書く。誰が使うか、どの事業で使うか、何を渡すか、の三つで線を引く。
- 受託者が他の顧客に使い回す場合は、依頼者の情報を含まない部分に限る。汎用部分と依頼者固有の部分を、契約の中で分けておく。
- クラウド環境やアカウントの名義、終了後の利用と削除まで、納品物の一部として決める。
納品物の権利を決める前に、手元に置くもの
- 納品物の一覧（種類、数量、形式、納品の方法）と、それぞれを作る人（受託者本人か、再委託先か）
- 納品物に依頼者の文章・資料・データが入るかどうか（入る場合は、その範囲）
- 外部のAIサービスやクラウドの利用条件（アカウントの名義変更、第三者への提供の可否）
- 依頼者の想定する使い方（自社の業務だけか、顧客向けのサービスに組み込むか、グループ会社で使うか）
- 受託者の想定する再利用（同じひな形を他の顧客にも使うか）
納品物を六つに分けて数える：著作物にあたるものと、あたりにくいもの
権利の話を始める前に、納品物の中身を種類ごとに分けておきます。種類によって、著作権で守られるかどうかが違うからです。著作権法で守られる「著作物」とは、思想又は感情を創作的に表現したものであって、文芸、学術、美術又は音楽の範囲に属するものです（著作権法2条1項1号）。長い文章で表現に工夫があれば著作物にあたり得ますが、短い定型句、事実の羅列、単なる設定値は、著作物にあたらないことがあります。あたるかどうかは、個々の内容で判断されます。
納品物の種類ごとの、権利の考え方の目安
| 納品物 | 著作物にあたり得る場合 | 著作権で守りにくい部分 | 契約で先に決めること |
|---|---|---|---|
| プロンプト（AIへの指示文） | 長い指示文で、文章の構成や表現に工夫があるとき（言語の著作物） | 短い命令文や定型句、指示の発想そのもの | 帰属、利用範囲、複製・改変の可否、秘密としての扱い |
| システム設定（設定値、権限、連携の指定） | まれ。設定を説明する文書は別に著作物となり得る | 設定値の並びは、一般に創作的表現とはいいにくい | 引渡しの方法、改変の可否、秘密情報としての扱い |
| テンプレート（文書・表・入力フォームのひな形） | 文章や図表の構成に創作性があるとき | 一般的な様式、ありふれた項目立て | 帰属、受託者の再利用、依頼者の改変 |
| 自動化フロー（作業をつなぐ設定） | プログラムとして記述されているとき（プログラムの著作物） | 解法（指令の組合せの方法）は、著作権法の保護が及ばない（同法10条3項） | ソースの開示、改変、保守の担当 |
| クラウド環境（作業用のアカウントやフォルダ） | 環境そのものは著作物ではない | アカウントの利用は、外部サービスとの契約上の地位 | 名義、管理者権限、費用、終了時の引渡し |
| マニュアル・教材 | 文章・図表・画像は著作物となり得る | 操作手順の事実そのもの | 帰属、複製して配る範囲、更新の担当 |
表のとおり、プロンプトや設定のように、著作権で守りにくい納品物があります。ここで大切なのは、「著作権で守れないなら自由に使われてもやむを得ない」と考えるのではなく、「契約と秘密の管理で守る」と組み立てることです。不正競争防止法は、秘密として管理されている生産方法、販売方法その他の事業活動に有用な技術上又は営業上の情報であって、公然と知られていないものを「営業秘密」と定めています（同法2条6項）。受託者のノウハウを含む納品物も、依頼者の業務情報を含む納品物も、この枠組みで守られる可能性があります。そのためには、秘密として扱う旨を契約に書き、実際にも共有の範囲を絞って管理することが前提になります。
もう一つ、プログラムの著作物に対する保護は、プログラム言語、規約及び解法には及びません（著作権法10条3項）。自動化フローが同じ結果を出す別の書き方で作り直された場合、「解法」にあたる部分は、著作権では止められません。作り直しを禁止したいなら、リバースエンジニアリングや同種のサービスの提供を禁止する条項（後の節で扱います）と、秘密情報としての管理で補うことになります。
契約書には、この六種類を別表の一覧にして載せておくと、後の議論が楽になります。一覧には、納品物の名前、形式、納品の方法（ファイルで渡すのか、環境へのアクセス権を渡すのか）、作成者を書きます。「その他受託者が作成した一切の成果物」という包括の文言を残す場合は、一覧にないものの帰属も同じ扱いになるのか、別に決めるのかを、一文で書き分けます。
帰属の型は二つ：受託者に残して許諾する型と、依頼者に移す型
納品物の著作権の置き場所は、大きく二つの型に分かれます。一つは、権利を受託者に残し、依頼者には利用を許諾する型です。もう一つは、権利を依頼者に譲渡する型です。どちらが正しいということはなく、納品物の性質と、両者の事業の形で選びます。
二つの型の比較
| 観点 | 受託者に残して許諾する型 | 依頼者に移す型 |
|---|---|---|
| 権利の持ち主 | 受託者が著作権を持ち、依頼者は許諾を受けて使う | 依頼者が著作権を持つ |
| 依頼者ができること | 許諾の範囲内（目的、期間、改変の可否）で利用する | 複製、改変、他者への許諾まで自由に行える |
| 受託者ができること | 同種の納品物を他の顧客にも使える（秘密情報を除く） | 従前から持つ部分や汎用部分を除き、使い回しに制限がかかる |
| 向いている場面 | 受託者の汎用的なひな形やノウハウが中心のとき | 依頼者の事業に固有の内容が中心のとき |
| 契約で特に書くこと | 許諾の範囲、期間、改変物の扱い、許諾の終了 | 特掲する権利、除外する部分、著作者人格権の不行使 |
どちらの型でも、「従前から保有するもの」と「第三者のもの」を除くと書いておくのが一般的です。受託者が以前から持っているひな形や、外部のサービスが提供している機能は、今回の納品で動くものではありません。除外を書かないと、受託者が自分の既存の資産まで依頼者に渡したことになり、あるいは依頼者が第三者の権利まで取得したことになりかねません。
条文例第○条（納品物の権利と利用許諾）：受託者に残す型の例
- 本件納品物に関する著作権（著作権法第27条及び第28条に規定する権利を含む。）その他の知的財産権は、委託者又は第三者が従前から保有していたものを除き、受託者に帰属する。
- 受託者は、委託者に対し、本件納品物を、委託者の○○のために、○○の期間、非独占的に利用することを許諾する。
- 委託者は、前項の範囲内で、本件納品物を複製し、及び改変することができる。改変により生じたものについては、別表に定める取扱いとする。
- 委託者及び受託者は、相手方及び相手方から正当に利用を認められた者に対し、本件納品物について著作者人格権を行使しない。
括弧内の「○」は、実際の取引で埋める。期間や範囲の具体的な数字は、納品物の性質で変わる。
依頼者に移す型では、条文の特掲が重要です。著作権を譲渡する契約で、翻案権等（著作権法27条）と二次的著作物の利用に関する原著作者の権利（同法28条）が譲渡の目的として特掲されていないときは、これらの権利は譲渡した者に留保されたものと推定されます（同法61条2項）。依頼者が納品物を改変して使い続ける前提なら、27条・28条の権利を含めて移す旨を、条文の中に書いておきます。また、著作者人格権は著作者の一身に専属し、譲渡することができません（同法59条）。改変や氏名表示をめぐる争いを避けるため、著作者人格権を行使しない旨の約束を添えるのが一般的です。
書き方の例（一般的な例） 帰属の条文
帰属と利用範囲
理由帰属と利用範囲が別々の条にあると、片方だけを読んだ人が「自由に使える」「使えない」と誤解しやすい。
移す型の書き方
理由特掲がなければ27条・28条の権利は留保されたと推定される（同法61条2項）。人格権は譲渡できない（同法59条）。
納品物の範囲
理由包括の文言だけだと、何が帰属・許諾の対象かが争いになる。
利用範囲：商用利用の許諾と、第三者提供・再販売・同種サービスの禁止の境界
導入支援の契約でよく見る組み合わせは、次の二つです。一つは「委託者は納品物を自己の業務で、商用目的でも利用できる」という許諾。もう一つは「委託者は納品物を第三者に提供、販売、再配布してはならず、納品物をもとに同一または類似のサービスを第三者に提供してはならない」という禁止です。どちらも、それだけを読めば自然な条文です。ところが、二つを並べると、依頼者が納品されたプロンプトを自社の顧客向けのサービスの中で動かすとき、それが「自己の業務での商用利用」なのか、「類似のサービスの第三者への提供」なのかが、条文だけでは決まりません。
この矛盾は、禁止と許諾を二つの軸で書き分けることで解けます。誰が使うか、どの事業で使うか、何を相手に渡すかの三つを軸にして、使い方の類型ごとに「許す」「許さない」「別に許諾を受ければ許す」を書き込みます。
使い方の類型ごとの書き分けの例
| 使い方 | 許すか | 書き方のポイント |
|---|---|---|
| 依頼者本人が、自社の業務の中で使う | 許す（商用でも） | 「自己の業務」とは何かを定義する。顧客に有償で提供する業務を含むかを書く |
| 依頼者が、自社の顧客向けサービスの中でAIを動かし、出力だけを顧客に渡す | 契約ごとに決める | 納品物そのものを渡さないこと、顧客が納品物を取り出せないことを条件にする |
| 納品物（プロンプトや設定の文面そのもの）を、顧客・外部に渡す | 原則許さない | 事前の書面による許諾を要する、と書く。許諾の条件（対価、範囲）を別に決める |
| 納品物をもとに、同種のサービスを他社に提供・再販売する | 許さない | 「同種」「類似」の範囲を定義する。範囲があいまいだと、通常の事業まで止まる |
| グループ会社が使う | 範囲を決めて許す | 対象の会社を列挙するか、判定の基準を書く。使った会社の責任を依頼者が負う旨を添える |
| 委託先・外部の制作者が使う | 依頼者の業務のために必要な範囲で許す | 秘密保持を負わせること、委託先の行為の責任を依頼者が負うことを書く |
「同種のサービス」の禁止は、依頼者の側から見ると事業の自由を縛る条項です。範囲を広く書きすぎると、依頼者の通常の営業まで止めかねません。受託者の側から見ても、範囲を決めずに書くと、後で「どこまでが禁止か」を説明できなくなります。たとえば「納品物を利用して、受託者の提供するサービスと実質的に同一のサービスを提供すること」と書き、さらに「依頼者が従前から行っている事業は影響を受けない」と書き添えると、禁止の範囲が読み取りやすくなります。
許諾を受けた者が持つ利用の権利は、著作権者の承諾を得ない限り、譲渡することができません（著作権法63条3項）。依頼者が事業を他社に譲渡したり、組織を再編したりするとき、納品物の利用許諾がどう扱われるかは、契約で決めておかないと、承諾の要否が争いになります。事業の承継を見込む依頼者は、承継があったときに利用を続けられる旨を、あらかじめ書いておくとよいでしょう。
確認の問いと理由利用範囲の条文を書く前に、自分に投げる問い
納品物を、依頼者は誰の業務のために使うのか。
自己の業務という言葉だけでは、顧客向けのサービスに組み込む使い方が入るか分からないため。
出力（結果）だけを外に出すのか、納品物そのものを外に出すのか。
禁止の対象を「納品物そのもの」にするか「納品物を利用した出力」まで含めるかで、許諾の広さが変わる。
「同種」「類似」のサービスとは、具体的に何を指すのか。
範囲を決めないまま禁止すると、依頼者の通常の営業や、受託者の他の取引まで巻き込む。
グループ会社や委託先が使う場面があるか。
許諾の主体が依頼者本人だけだと、実際の運用と合わなくなる。
事業の譲渡や組織再編で、許諾の地位は動くのか。
利用権の譲渡は、著作権者の承諾が原則として要る（著作権法63条3項）。
受託者が他の顧客に再利用する条件：汎用部分と依頼者固有の部分を分ける
受託者の側から見ると、AIの導入支援は、同じ型の仕事を複数の依頼者に提供して成り立つことが多くあります。ある依頼者のために作ったひな形を、別の依頼者にも提供できなければ、事業として成立しにくいでしょう。一方、依頼者の側から見ると、自社の業務の内容を反映した納品物が他社に渡ることには抵抗があります。この二つを両立させる鍵は、納品物を層に分けて、層ごとに帰属と再利用の可否を決めることです。
層ごとの帰属と再利用の考え方
| 層 | 中身の例 | 帰属の考え方 | 受託者の再利用 |
|---|---|---|---|
| 受託者が従前から持つ部分 | 以前から使っているひな形、手順の型 | 受託者に残る。納品物に含まれても除外する | 自由（依頼者の情報を含まない限り） |
| 汎用部分 | 誰が使っても同じ構成の指示文、一般的な設定 | 契約で型を選ぶ（受託者に残す型が多い） | 許す。依頼者名や固有情報を含めない |
| 依頼者固有の部分 | 依頼者の業務、用語、顧客対応の内容を反映した部分 | 依頼者の秘密情報として扱う。移す型や許諾の対象にする | 許さない |
| 共同で作った部分 | 双方が内容を出し合って作った部分 | 契約で、帰属または共有の持分と、使える範囲を決める | 範囲を決めて許す |
層を分けるには、納品の段階で、どの部分が汎用で、どの部分が依頼者固有かを記録しておく必要があります。契約書の条文だけでは区別できないことが多いため、別表や納品時の説明書に、「ここから先は依頼者固有」と分かる形で線を引いておきます。区別が曖昧なまま納品すると、受託者が再利用したつもりのものに依頼者の情報が混じっていて、秘密保持違反を主張されることがあります。
秘密保持条項との関係も整理が要ります。秘密保持条項で「本契約に関連して知り得た一切の情報」を秘密情報と定めつつ、別の条で受託者の再利用を認めると、二つの条が衝突します。再利用を認める部分は秘密情報から除く、あるいは、再利用は秘密情報を含まない範囲に限る、と書いて、優先関係をはっきりさせます。
依頼者から受託者に出された提案や改善案（フィードバック）を、受託者が無償で利用できると定める条項もよく見ます。この条項は、利用の範囲を汎用的な改善への反映に限り、依頼者の秘密情報、個人情報、依頼者を特定できる情報を含めないと書き添えておくと、秘密保持条項との衝突を避けられます。
書き方の例（一般的な例） 受託者の再利用
再利用の許可
理由「自由に」は、依頼者固有の部分まで含む読み方を許す。範囲を絞るほうが、受託者にとっても説明しやすい。
フィードバック
理由秘密保持条項と衝突させないため。
秘密保持との関係
理由二つの条が並ぶと、どちらが優先するかで争いになる。
クラウド環境・アカウント・外部AIの出力：名義と引渡しを納品物の一部として決める
導入支援では、作業用のクラウド環境、AIサービスのアカウント、共有フォルダ、連携用のアクセス権などが、実際の「納品物」になることがあります。ここで先に確かめるのは、誰の名義で契約するのかです。受託者名義のアカウントに依頼者が相乗りする形だと、契約が終わったときに依頼者が環境へ入れなくなり、データを取り出せなくなるおそれがあります。依頼者名義で契約して受託者が管理者として作業する形だと、費用や責任が依頼者に直接かかり、受託者が作業を終えた後の権限の返却が論点になります。
外部のAIサービスやクラウドのアカウントは、その事業者の利用規約の下で提供されます。アカウントの名義変更や第三者への提供、再販売、他の組織での共用が許されているかは、サービスごと・プランごとに違います。契約前に原文で確かめ、許されていない形を前提にした条文を書かないようにします。外部サービスの規約を下流へ引き継ぐ書き方は外部のAIモデル・APIに依存するサービスの規約で扱っています。
プロンプトを外部のAIに入力して得られた出力の取扱いも、納品物の権利と地続きの論点です。出力の権利、入力データの保存や学習への利用は、外部事業者の規約と、依頼者・受託者の契約の両方で決まります。受託者が検証のために依頼者の業務情報をプロンプトに入れる場合、その情報がどこへ送られ、どれだけ保存されるのかを、依頼者が知っている必要があります。個人情報を含む場合は、委託や外国にある第三者への提供の整理が加わります。
環境の引渡しの流れ（受託者名義で始めた場合の例）
- 1. 名義と費用の確認誰の名義で契約しているか、費用を誰が負担しているかを、契約書の別表に書く。
- 2. 管理者権限の付与依頼者の指定する担当者に、管理者の権限を付ける。付与の時期を、検収または支払の時期と結びつける。
- 3. 認証情報の更新共有していた認証情報（パスワード、アクセスキー）を、引渡し時に新しいものへ変える。
- 4. 費用の切替請求先を依頼者へ移す日を決める。日割りの扱いも書く。
- 5. 受託者側の権限の削除受託者の側に残ったアクセス権を削除し、削除した旨を通知する。
外部サービスが名義の変更を認めていない場合は、新しい環境を作って内容を移す方法に切り替える。
契約が終わったあとの利用と削除：納品物は返すのか、使い続けるのか
契約が終了したとき、納品物の扱いは三通りに分かれます。許諾の型であれば、期間が終われば利用の許諾も終わります。移す型であれば、依頼者のものとして使い続けられます。ただし、どちらの型でも、契約の途中解除があった場合は別の整理が要ります。請負として納品物の完成を約束した契約で、請負が仕事の完成前に解除されたとき、請負人が既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるなら、その部分を仕事の完成とみなして、請負人は、注文者が受ける利益の割合に応じて報酬を請求できます（民法634条）。納品済みの部分の権利の帰属と、報酬の支払を結びつけるかどうかは、契約で決めておくと混乱が減ります。
終了後に決めておく事項を、問いの形で並べます。
確認の問いと理由契約の終了後について、先に決めておく問い
許諾の型では、終了後に納品物を使い続けてよいか。
許諾が終わると、依頼者は納品物を使えなくなる。事業への影響が大きい場合は、終了後の一定期間の利用や、買取りの選択肢を書く。
支払が終わらないうちに解除されたとき、権利はどう動くか。
対価の支払と権利の移転を結びつけるかどうかで、未払いの扱いが変わる。
受託者の手元に残る控えやコピーは、どうするか。
依頼者の情報を含む控えを残すと、秘密保持の対象が終了後も続く。削除と、削除したことの通知を書く。
依頼者が改変して作った派生物は、誰のものか。
許諾の型では、改変物の権利と利用範囲を別表で決めておかないと、終了後に争いになる。
秘密保持の義務は、終了後いつまで続くか。
期間を区切るのか、情報の性質によって使い分けるのかを決める。営業秘密として守りたい情報は、期間を限らないことが多い。
受託者が依頼者の環境に入って作業していた場合は、終了時にアクセス権の返却と削除の確認を行います。受託者の側に残った認証情報、ダウンロードしたファイル、作業用のメモに依頼者の情報が含まれていれば、これらも削除の対象です。削除の方法と、削除したことを文書で通知する手順を、契約の終了条項に書いておくと、後から「消したはずだ」「確認していない」という食い違いが生じにくくなります。
起きがちなこと：納品の場面で現れる食い違い
納品物の権利は、契約書を作るときよりも、納品の後に問題になります。次の場面は、よく見られる食い違いの型です。
場面ごとの、起きがちなことと先に決めておくこと
依頼者が納品された指示文を、そのまま顧客向けの資料に載せた
起きがちなこと依頼者は「自己の業務での商用利用」と考えているが、受託者は「納品物の第三者への提供にあたる」と考える。
先に決めておくこと納品物そのものを外に出す場合の許諾の条件を決めておく。出力だけを渡す使い方との違いを、条文か別表で示す。
受託者が、別の依頼者向けに同じ設定を使い回していたと知った
起きがちなこと依頼者は自社の業務を反映した設定が他社に渡ったと受け取る。受託者は汎用部分だと考えている。
先に決めておくこと汎用部分と依頼者固有の部分を、納品時の説明書に記録しておく。再利用は秘密情報を含まない範囲に限る。
契約が終わる日に、依頼者がクラウド環境に入れなくなった
起きがちなことアカウントが受託者の名義で、依頼者は管理者権限を持っていなかった。データの取り出しも契約に書かれていなかった。
先に決めておくこと名義と管理者権限、引渡しの手順、データの取り出しの期限を、契約の別表に書く。
依頼者が納品物を改変して、別の事業に使い始めた
起きがちなこと改変物の権利が誰にあるか、許諾の範囲を超えていないかで争いになる。
先に決めておくこと改変の可否、改変物の権利と利用範囲を、帰属の条で決めておく。
依頼者が事業を他社へ譲渡し、納品物も一緒に使わせたいと言い出した
起きがちなこと許諾の地位が移るかどうかが決まっておらず、受託者の承諾の要否で争いになる。
先に決めておくこと事業の承継の場合の取扱いを、あらかじめ書く（利用権の譲渡には承諾が要るのが原則）。
陥りがちな点
- 「その他一切の成果物」と書いて、納品物の一覧を作っていない
- 「商用利用可」と「第三者への提供禁止」「同種サービスの提供禁止」を並べ、線引きの軸を書いていない
- 著作権の譲渡で、27条・28条の権利を特掲していない
- 著作者人格権の不行使を書いていない
- 再利用を認める条と、秘密保持の条の優先関係が決まっていない
- 外部サービスの利用規約で名義変更や第三者への提供が許されない形を、前提に書いてしまった
- 「納品物」の定義が複数の条に分かれて置かれ、範囲が食い違っている
以上のとおり、AI導入支援や開発の納品物は、形が見えにくいぶん、契約書の側で輪郭を与えておく必要があります。一覧にして、帰属と利用許諾を分け、利用範囲を軸で書き分け、再利用を層で分け、名義と終了後の扱いを決める。この順に決めていくと、納品後の食い違いは大きく減ります。
よくあるご質問
プロンプトは、著作権で守られる「著作物」になりますか。
長い指示文で、文章の構成や表現に創作性があれば、言語の著作物にあたり得ます（著作権法2条1項1号）。短い命令文、定型句、指示の発想そのものは、著作物にあたらないことがあります。あたるかどうかは個々の内容で判断されるので、著作権だけに頼らず、契約で利用範囲を定め、秘密として管理することで守る組み立てにします。秘密として管理された有用な情報で、公然と知られていないものは、営業秘密として保護の対象になり得ます（不正競争防止法2条6項）。
受託者に著作権を残す契約だと、依頼者は納品物を使い続けられなくなりますか。
権利を受託者に残しても、依頼者に利用を許諾する条項があれば使えます。許諾の目的、期間、地域、改変の可否を書いておくのが一般的です。許諾を受けた者の利用権は、著作権者の承諾がなければ譲渡できないので（同法63条3項）、事業の譲渡や組織再編があるときの取扱いも、あらかじめ決めておきます。
「商用利用可」と「第三者への提供禁止」は、同じ契約に書いても矛盾しませんか。
線引きの軸を書かないまま並べると、読む人によって結論が分かれます。誰が使うか、どの事業で使うか、納品物そのものを渡すのか出力だけを渡すのか、の三つで類型ごとに書き分けると両立します。「同種のサービス」の範囲も定義しておきます。
納品したプロンプトや設定を、受託者が他の依頼者にも使ってよいですか。
契約で再利用を認めているなら、使えます。ただし、依頼者の秘密情報や固有の情報を含まない汎用部分に限るのが一般的です。納品時に汎用部分と依頼者固有の部分を記録しておくと、後の争いを避けられます。秘密保持条項との優先関係も、条文で明らかにしておきます。
クラウド環境やAIサービスのアカウントは、誰の名義にするのがよいですか。
決まった正解はありません。依頼者が継続して使うなら、依頼者名義で契約して受託者が管理者として作業する形が、終了時の引渡しの手間が少なくなります。受託者名義で始める場合は、管理者権限の付与、認証情報の更新、費用の切替、受託者側の権限の削除という手順を、契約に書いておきます。外部サービスの規約で名義変更が認められているかは、契約前に原文で確認が必要です。
あわせて読みたいページ
本ページは一般的な情報提供です。個別の取引への当てはめは、サービスの仕組みや契約の内容によって異なることがあります。条文は e-Gov法令検索（法令API）で確認しています（最終確認日：2026年10月21日）。参考: e-Gov法令検索 / 個人情報保護委員会 / 消費者庁 / 経済産業省 / 総務省 / 内閣府
