このページの要点
- ソースコード、アルゴリズム、ライブラリの組合せ方を秘密情報に入れ、一般に周知された技術は外す。解法は著作権では守られない。
- 再委託・再々委託は『通知』でなく『承諾』にし、情報の管理責任者を決めさせる。法令による開示だけは通知にとどめる。
- 成果物の権利や第三者の権利侵害の責任はNDAに混ぜず主契約に置く。リポジトリとAPIキーは自社名義で管理する。
- 履歴やクラウド、学習済みモデルに残る情報を前提に返還・削除を組み、汎用ひな形は固定する条と差し替える欄に分ける。
結論：ソースコードと「組合せ方」を秘密情報に入れ、再委託は承諾制にし、成果物の権利は別の契約に任せる
ソフトウェアやアプリの開発を請けて、その一部を別のエンジニアや会社に任せる。事業が広がれば、再委託はごく自然に出てきます。そのとき渡す情報は、取引先から預かったソースコード、まだ公表されていない製品の仕様、顧客の個人データなど、漏れた影響の大きいものばかりです。このページは、開発の再委託をする側（情報を出す側）が、秘密保持契約書（NDA）に何を書くかを整理します。
事務所の書類から見える結論は五つです。①ソースコード、アルゴリズム、ライブラリの組合せ方を秘密情報に入れ、世の中に広く知られた一般的な技術は外すこと。②再委託と再々委託を、「通知」ではなく「承諾」で縛り、情報の管理責任者を決めさせること。③成果物の知的財産権や第三者の権利侵害の責任は、NDAに混ぜず、主となる契約に置くこと。④ソースコードの管理システムの履歴、クラウド、学習済みのモデルなど、削除しきれない場所があることを前提に、返還・削除の条を組むこと。⑤案件ごとに差し替える欄と、固定しておく条を分けて、汎用のひな形を作ること。
委託先に再委託を認めるときの一般的な書き方は目的外利用と開示の範囲、生成AIへの入力は生成AIへの入力で整理しています。このページは、その先の、ソフトウェア開発という場面に固有の論点を扱います。
何を秘密情報に入れるか：コードとアルゴリズムと、組合せ方
開発のNDAでは、守りたいものが書類や数字ではなく「技術そのもの」であることが少なくありません。ソースコード、アルゴリズム、どのライブラリをどう組み合わせて動かしているか。形のあるファイルだけでなく、頭の中にあるノウハウまで含まれます。
ここで知っておきたいのが、著作権法の線引きです。プログラムは著作物として保護されますが（著作権法10条1項9号）、その保護は、プログラムを作成するために用いるプログラム言語、規約及び解法には及びません（同条3項）。解法とは、プログラムにおける、電子計算機に対する指令の組合せの方法のことです（同項3号）。つまり、コードそのものは著作権で守られても、コードの背後にある手順や組合せ方（アルゴリズム）は、著作権では守られません。これを守るのは、秘密情報として守る約束、つまりNDAと、条件を満たす場合の営業秘密の保護です。「コードを渡さなければ大丈夫」ではなく、「組合せ方を渡すこと自体を秘密にする」ように定義を組みます。
開発の再委託で秘密情報に入れる類型
| 類型 | 具体例 | 扱いの要点 |
|---|---|---|
| コード・設計 | ソースコード、設計書、画面遷移、データベース設計、APIの仕様 | 複製と持出しを制限。派生物も同じ扱い |
| 技術・組合せ | アルゴリズム、ライブラリの組合せ方、設定値、処理の手順、開発中に見聞きした技術情報 | 一般に周知されている技術は含めない、と明記 |
| 認証情報 | リポジトリやクラウドのアカウント、APIキー、管理者の権限、接続情報 | 自社名義で管理。外注先の名義では発行させない |
| データ | テストデータ、顧客データ、提供資料（紙と電子データの両方） | 個人情報は表示を問わず秘密情報。本番の個人データをテストに使わない |
| 未公開の情報 | 発表前の製品の内容、自社が取引先から預かった情報 | 取引先から課された条件と同じ強さを外注先にかける |
| 契約の存在 | 取引の事実、条件、報酬 | 実績としての公表を制限 |
事務所が作成した、プログラマー向けの汎用ひな形の定義では、秘密情報の例として、個人情報、開発において見聞きした技術情報、プログラミング技術（ライブラリ、アルゴリズム）、開発するために提供した資料、特許、著作物を挙げ、『プログラミング技術には、一般に周知されている技術は含まない』と添えています。
「一般に広く知られた技術」を外す理由は、実務的でもあります。世の中で当たり前に使われている手法まで秘密だと書けば、相手は次の仕事で同じやり方も使えなくなり、約束として無理が出ます。守るのは、自社や取引先に固有の情報です。守りたい技術は具体的に拾い、もともと世に出ている技術ははっきり外す。この「広すぎず、狭すぎず」が、技術を渡すNDAの肝です。
事務所の改訂例 秘密情報の定義：指定方式と例示の食い違い
定義の向き
第1項が『指定したもの』に限る一方、第2項が口頭で見聞きした技術情報まで含めており、どちらが優先するかが読み取れない。指定の有無を問わない包括の形に統一する。
営業秘密（秘密として管理されている事業活動に有用な情報で、公然と知られていないもの。不正競争防止法2条6項）との関係も押さえておきます。ソースコードやアルゴリズムは、営業秘密になり得ますが、NDAを結んだだけで自動的に営業秘密になるわけではありません。アクセス権限を絞る、秘密である旨が分かる管理をする、といった実態を伴って初めて、法律の保護が働きます。差止めの請求は同法3条に根拠があります。契約と運用をそろえることで、契約上の保護と法律上の保護が重なります（差止め・事故報告と営業秘密）。
再委託・再々委託：通知で足りるか、承諾が要るか、誰が管理するか
開発の再委託で、いちばん怖いのは、渡した相手の先です。頼んだ相手も忙しいので、一部をさらに別のエンジニアに振る。すると、取引先から預かったコードや個人データが、会ったこともない「その先の人」に届きます。多くのひな形は「自分」と「頼んだ相手」の二人だけの約束として書かれていて、相手の社内（役員や従業員）に見せる範囲までは書いてあっても、相手がさらに外に頼む場面が抜けています。
開発の再委託で情報が流れる段
各段で、上の段に負っている義務と同じ強さの約束を、下の段にかけます。
最初に決めるのは、再委託の手続を「通知」にするか「承諾」にするかです。通知は「知らせればよい」、承諾は「許可をもらわなければならない」という意味で、まったく違います。「事前に通知する」としか書いていないと、相手は知らせるだけで開示できてしまいます。守りを固めたいなら、承諾を求める書き方のほうが強くなります。ただし、法令や裁判所の命令によって出さざるを得ない場面では、相手の許可を条件にできないので、「できるだけ早く知らせる」が落としどころになります。普段の開示は承諾制、法令による開示だけは通知、と場面で書き分けます。
再委託の管理の強さ上ほど強く縛る書き方
- 個別の承諾制＋通知事項開示する内容、日、方法、場所、相手の名前を書面で通知させ、承諾を得てから開示する。相手には同等の義務を負わせ、連帯して責任を負わせる個人データや認証情報を含む、重い案件
- 包括承認＋一覧の管理使ってよい再委託先、保存先、条件をまとめて示す。それ以外は個別に承諾を得る再委託先が固定的で、案件が多い継続的な取引
- 事前の通知のみ再委託する前に知らせれば足りる。承諾までは求めない公開情報に近い、軽い案件。ただし開示を止める手段は持てない
- 再委託の禁止再委託も再々委託も認めない。上流が二次委託を禁じている場合は、これに合わせる上流の取引先が二次委託を禁じている案件
事務所のAI開発のNDAでは、承諾を得て第三者に開示するとき、提供する内容、提供日、提供方法、提供場所、提供の相手方を事前に通知させ、その第三者が違反したときは連帯して責任を負う形にしています。
第○条（再委託及び情報管理責任者）
１乙は、甲の事前の書面又は電磁的方法（その内容が記録として残る方法に限る。）による承諾なく、秘密情報を再委託先その他の第三者に開示してはならない。
２乙は、前項により秘密情報を開示するときは、提供する秘密情報の内容、提供日、提供方法及び相手方を、事前に甲に通知する。
３乙は、再委託先に対し、本契約と同等以上の義務を課し、再委託先の行為について自己の行為と同一の責任を負う。再委託先がさらに第三者に委託する場合も同様とし、甲が書面で承諾した場合を除き、再々委託は認めない。
４乙は、秘密情報の管理責任者を定め、その役職及び氏名を甲に通知する。管理責任者に変更があったときは、遅滞なく甲に通知する。
５甲が第三者に対し再委託を禁じられているときは、甲は乙にその旨を通知し、乙は再委託を行わない。
第5項は、上流の取引先が二次委託を禁じているのに、自社が下に流してしまう事態を防ぐための条です。
管理責任者を決めさせるのは、運用面の備えです。誰が情報を預かり、管理しているのかが見えていれば、事故の連絡や対応がスムーズになります。組織として情報を扱う以上、「誰が責任を持つか」を見える形にしておく意味は大きいといえます。なお、相手が会社ではなく個人のエンジニアなら、「役員又は従業員」という書き方は当てはまらないので、署名欄も、会社なら会社名と代表者、個人なら本人の氏名と住所というように整えます。
成果物の権利と第三者の権利侵害の責任は、NDAに混ぜない
外注の不安をすべて一枚のNDAに詰め込みたくなるのは、自然なことです。たとえば「外注先が仕事の中で、他人の権利をうっかり侵害したときに、自分が責任を問われないようにしたい」という要望はとても多いのです。けれども、これは秘密情報の取扱いではなく、仕事や成果物そのものの話です。秘密の話はNDAに、仕事の中身は主となる契約に、と振り分けたほうが、契約書どうしの役割がはっきりして、読みやすく、揉めにくくなります。
どの書類に何を書くか（開発の再委託）
| 項目 | 置き場所 | 理由 |
|---|---|---|
| 秘密情報の定義、目的外利用の禁止、複製、返還・削除 | NDA | 秘密保持の中身。契約の終了後も働く |
| 認証情報の名義と、管理者権限の保持 | 主契約の運用条とNDAの認証情報の条の両方 | 名義は運用の取決め。他人に使わせない義務はNDAでも担保する |
| 成果物の著作権の帰属、利用の許諾 | 主契約 | 帰属は仕事の成果の問題。NDAに書くと主契約と二重になり、食い違う |
| 第三者の知的財産権を侵害した場合の責任 | 主契約 | 仕事の過程の責任の分担で、秘密情報の取扱いとは別 |
| 外部のオープンソースを組み込むときの事前説明とライセンスの遵守 | 主契約 | 成果物の品質と権利に関わる |
| 開示した情報を使って得た発明や技術的成果の通知 | NDA | 秘密情報の利用の結果。帰属が決まるまで秘密情報として扱う |
| 損害賠償の上限 | 主契約（ただし秘密保持違反と個人情報の漏えいは上限の外に置く） | 仕事全体の責任の枠と、漏えいの責任は別に考える |
事務所がAIエンジニアの業務委託で書類一式を整えたときも、成果物の帰属は業務委託契約に包括的に規定し、重複による解釈のずれを避けるため、NDA側には重ねて記載しない整理にしました。
NDAの中に知的財産の帰属の条を置く書き方もあります。業務の過程で得られた発明やノウハウは、それを行った者が属する当事者に帰属し、共同で行った場合は委託者に帰属する、という内容です。条文としては成り立ちますが、主契約にも成果物の帰属の定めがあると、二つの条が食い違いかねません。NDAには「開示された情報を利用して得た技術的成果は、直ちに報告し、帰属は協議、協議が整うまでは秘密情報とみなす」という橋渡しだけを置き、帰属の本体は主契約に任せる、と分けるのが整理しやすい形です。
成果物の権利を主契約に書くときは、著作権の譲渡の条に、翻案権と二次的著作物の利用に関する権利（著作権法27条・28条）を特掲しておく必要があります。これらの権利が譲渡の目的として特掲されていないと、譲渡した者に留保されたものと推定されるからです（同法61条2項）。この点を、NDAではなく主契約で確実に押さえます。
ソースコードの管理者、APIキーの名義、監査：運用までNDAと主契約で支える
NDAに「厳重に管理する」と書いても、実際にコードがどこにあり、誰が鍵を持っているかが外注先任せでは、守れません。事務所がAIエンジニアの業務委託で、委託者の依頼を反映して整えた書類では、次のような運用面の条を置きました。
- 成果物のソースコードは、委託者が所有する組織のアカウントやプライベートのリポジトリなどで管理し、所有者を委託者とする。外注先は必要最小限の権限だけを持つ。
- 外部のサービスやAPIのアカウント、APIキーは、すべて委託者の名義で取得・管理し、外注先の名義では発行しない。管理者の権限と所有者の権限は委託者が保有する。
- 外注先が委託者のデータ（案件情報、見積り、原価、顧客情報、業務フロー）を、他社向けのAIの学習、テンプレート、営業資料の作成に転用することを禁止する。
- 外部のAIサービスの学習利用に関する承諾から、委託者の営業秘密を明示的に除外する。
- 漏えいや目的外利用の疑いに相当の理由があるとき、委託者が、秘密情報の利用状況、保存場所、アクセス権限、消去状況の報告を求め、確認（監査）できる。
- 成果物及びソースコードを、定期的に、委託者の名義の保存先に保存する（機器の故障などによる滅失の防止）。
最後の項目は主契約に置く条ですが、「どこに、誰の名義で置くか」が決まっていることが、NDAの返還・削除の条を実効性のあるものにします。保存先が委託者の管理下にあれば、契約が終わるときの権限の削除も、委託者が自分でできるためです。
第○条（認証情報の名義及び監査）
１乙は、本業務のために外部のサービス又はAPIのアカウント、APIキー、リポジトリその他の認証情報を取得するときは、甲の名義で取得し、乙の名義では取得しない。管理者権限及び所有者権限は、甲が保有する。
２乙は、前項の認証情報を、第三者に使用させ、共有し、又は転送してはならない。
３甲は、秘密情報の漏えい又は目的外利用の疑いに相当の理由があるときは、乙に対し、秘密情報の利用状況、保存場所、アクセス権限及び消去の状況について、報告を求め、又は確認することができる。
監査は、『疑いに相当の理由があるとき』に限り、報告の請求から始める形にすると、相手の受け入れやすさと実効性のバランスがとれます。
返還・削除の限界：履歴、クラウド、学習済みモデル、渡したデータの派生
電子データの返還・削除は、紙とは違って、「消したつもり」がいくらでも起こります。ソースコードの管理システムには、過去の版が履歴として残ります。クラウドのストレージには、バックアップや同期のコピーがあります。外部のAIサービスに入力した情報は、事業者の側に残る可能性があります。さらにAI開発では、渡したデータを使って学習したモデルに、情報が残る場合があります。事務所が受け取る側のレビューをしたときにも、AIの学習済みモデルに情報が残る点が論点として挙がりました。
ヒヤリングで確かめること消しきれない場所を前提にした返還・削除の設計
- 管理システムの履歴・バックアップ・キャッシュは、どう扱うか削除に代えて、秘密情報として管理を続け、業務の目的以外で復元・利用しないことを義務にする。保存を続ける旨と範囲を通知させる
- 法定の保存が必要な書類はあるか法定の保存義務の範囲に限って保持を認め、その間も秘密保持の義務を続ける
- AIの学習に使ってよいデータ、使ってはいけないデータは何か削除できないものは、入力させないことで守る。事前承諾と、承諾があっても入力できない情報（個人情報、営業秘密）を決める
- 渡したデータから作った派生データやモデルは、誰のものかAI開発では、開示の目的を特定し、データから得た成果は通知させ、帰属は協議、協議が整うまで秘密情報とみなす
- 終了時、アクセス権限はいつ消すか返還・削除の期限と同じ日までに、自社側でアカウントの権限を削除できる状態にしておく
個人データがテスト用のデータとして渡されることもあります。個人情報取扱事業者は、個人データの取扱いの全部又は一部を委託する場合、委託を受けた者に対して必要かつ適切な監督を行わなければなりません（個人情報保護法25条）。利用目的の達成に必要な範囲内で取扱いを委託する場合の提供を受ける者は、第三者提供の規制との関係で第三者に該当しないものとされています（同法27条5項1号）が、これは監督を免れるという意味ではありません。本番の個人データを、そのまま開発やテストに使わせない、という運用の取決めを、NDAの個人情報の条や主契約に置いておきます。詳しい返還・削除の期限や証明書の書き方は返還・廃棄・証明で整理しています。
汎用のひな形をつくる：固定する条と、案件ごとに差し替える欄
再委託のたびに契約書を一から作るのは手間がかかり、内容にもばらつきが出ます。そこで、案件が変わっても使い回せる汎用のひな形を一通そろえておく、という方法があります。ただ、汎用にするほど、抽象的で当たり障りのない内容になりがちです。汎用性と、自分たちの実態に合っているかの両立が課題です。
汎用ひな形で固定する条と差し替える欄
| 区分 | 内容 | 理由 |
|---|---|---|
| 差し替える欄 | 当事者の名称・住所、対象業務、契約の日付、有効期間、存続の年数、管理責任者、再委託の可否の選択肢、無期限にする情報の類型 | 案件・相手によって変わる |
| 固定する条 | 秘密情報の定義の構造と除外事由、目的外利用の禁止、複製の制限、事故時の報告と費用の負担、返還・削除、差止め、反社会的勢力の排除、協議、管轄 | どの相手でも同じ水準で守らせたい |
| 相手によって選ぶ条 | 再々委託の可否、個人データの扱い、生成AIの利用、監査の有無、認証情報の名義 | 扱う情報の重さで変わる |
扱う情報の性質が大きく変わるときは、定義と義務の範囲を見直します。土台は汎用に、肝心なところだけ案件ごとに微調整するのが、いちばん現実的です。
ひな形を点検するときは、似た約束が二重に入っていないかを確かめます。一般のひな形には、「秘密保持義務」の条と「守秘義務」の条が別々に並び、片方にだけ例外があり、片方にだけ期間の定めがある、という作りのものが見られます。見つけたら一つにまとめて、例外と期間を一か所に揃えます。もう一つは、返還と廃棄です。「破棄する」の条と「返還する」の条が両方あってちぐはぐなときは、紙などの実物は返還、電子データは関係者全員の端末から削除、と分けて、具体的に書きます。
漏えいが起きたときの条も、汎用ひな形に固定しておきます。事故に気づいたら直ちに報告し、後始末は漏らした側の費用で行う、という二つです。損害賠償の条だけでは、最初にどう動くのかが決まっていません。被害が広がってから知らされても、打てる手は限られます。存続期間については、取引先が定める期間のほうが長ければ、それに合わせる書き方もあります（存続期間の設計）。
ヒヤリングで確かめること、起きがちなこと
ヒヤリングで確かめること開発の再委託のNDAで、最初に確かめること
- 渡すのは、ソースコード、設計書、個人データ、認証情報のどれか類型ごとに、複製の制限、保存場所、返還・削除の方法を決める
- 取引先との契約で、再委託や二次委託は許されているか再委託の可否と手続（承諾制か、禁止か）を取引先の条件に合わせる
- 相手は個人のエンジニアか、会社か。さらに誰かに任せるか再々委託の可否、管理責任者、署名欄の整え方を決める
- リポジトリやAPIキーは、誰の名義で作るか自社名義、管理者権限の保持、終了時の権限の削除を決める
- 生成AIや外部のサービスに、コードやデータを入れるか事前承諾、入力できない情報、学習への利用の禁止を決める
- 成果物の権利や、第三者の権利侵害の責任は、主契約にどう書いてあるかNDAには重ねず、橋渡しの条（成果の通知と協議）だけを置く
よくあるご質問
プログラムの著作権があれば、NDAは要りませんか？
要ります。プログラムは著作物として保護されますが、プログラム言語、規約及び解法には保護が及びません（著作権法10条3項）。解法は、指令の組合せの方法のことで、アルゴリズムに当たります。コードの複製は止められても、手順や組合せ方を他の案件で使うことは、著作権では止められないため、NDAで秘密情報として守る約束が必要です。
再委託の条は、通知で足りますか。承諾にしたほうがよいですか？
通知は『知らせれば足りる』、承諾は『許可をもらわなければならない』という意味で、守る力が違います。取引先から預かったコードや個人データを含むなら、承諾制が基本です。法令や裁判所の命令による開示だけは、許可を条件にできないので、通知にとどめます。
外注先が作った成果物の権利は、NDAに書いておくべきですか？
NDAには書かず、主契約に置くのが整理しやすい形です。NDAには、開示された情報を使って得た技術的成果を報告させ、帰属は協議、協議が整うまで秘密情報とみなす、という橋渡しだけを置きます。主契約で著作権を譲渡するときは、翻案権などを特掲しないと、譲渡した者に留保されたものと推定されます（著作権法61条2項）。
契約が終わったら、ソースコードを全部削除させればよいですか？
削除の指示だけでは、管理システムの履歴、バックアップ、クラウドの同期に残る場合があります。消せないものは、秘密情報として管理を続け、目的以外で復元・利用しないことを義務にします。そもそも、ソースコードは自社名義の保存先に置き、外注先の手元に残る範囲を小さくしておくのが有効です。
汎用のNDAのひな形を、どの相手にもそのまま使ってよいですか？
土台は汎用でよいのですが、当事者、対象業務、期間、存続の年数、管理責任者、再委託の可否などは、案件ごとに差し替えます。扱う情報の重さによって、生成AIの利用や監査の条を加えるかも変わります。相手が個人か会社かでも、署名欄や『役員又は従業員』という書き方を整えます。
あわせて読みたいページ
本ページは一般的な情報提供です。個別の契約への当てはめは、取引の内容や相手の立場によって結論が変わることがあります。事務所の改訂例・ご相談の事例として紹介している内容は、アトラス行政書士法人が作成・レビューしてきた秘密保持契約書（NDA）、守秘義務契約書、業務上の守秘義務誓約書、秘密保持を内包した業務委託契約書、共同研究契約書・覚書、試験委託のNDA、PoCの覚書などを、個別の事業者や案件が特定できない形に整理したものです。条文は e-Gov法令検索で確認しています（最終確認日：2026年10月20日）。参考: e-Gov法令検索 / 個人情報保護委員会
