システム開発を外注するときのNDA(秘密保持契約)。中小企業が確認すべきポイント

開発会社に見積もりを依頼する前段階で、「まずNDA(秘密保持契約)を締結しましょう」と言われて、サンプルの契約書PDFを渡されたことはないでしょうか。読んでみても、条文は難しくないのに「これは自社にとって不利な内容ではないか」「そもそも何を確認すればいいのか」が分からず、とりあえず言われるまま押印してしまった、という担当者は少なくありません。

NDAは、外注の一番最初、まだ見積もりも取っていない段階で登場する契約です。ひとり情シス・総務兼任の担当者にとっては、正式な契約書に触れる最初の関門でもあります。ここで確認すべきポイントを押さえておかないと、自社の顧客データや業務フローといった機密情報が、想定より広い範囲で外部に開示されてしまうリスクがあります。

結論から言うと、NDAで最低限確認すべきポイントは次の5つです。

• 秘密情報の定義: 何が「秘密情報」として保護されるのか、範囲が広すぎたり狭すぎたりしないか
• 目的外使用の禁止: 開示された情報を、契約目的(見積もり検討)以外に使わないと明記されているか
• 開示範囲・再委託の扱い: 開発会社がさらに別の会社やフリーランスに再委託する場合、秘密保持義務が引き継がれるか
• 双務性: 自社だけが秘密保持義務を負う片務的な内容になっていないか
• 契約期間・存続条項: 契約終了後も一定期間、秘密保持義務が続く設計になっているか

ただし、ここで一つ注意点があります。NDAを結んだからといって、それだけで情報が安全に守られるわけではありません。この「NDAを結んでも守れない部分」については、記事の後半で詳しく触れます。

この記事で分かること

NDAという言葉は知っていても、実際に契約書を読んで判断する機会は多くありません。この記事では、次の疑問に順番に答えていきます。

• NDAは法律でどう位置づけられている契約なのか
• 不正競争防止法の「営業秘密」とNDAはどう関係するのか
• 一般的なNDAにはどんな条項が含まれているのか
• システム開発の外注に特有の論点は何か
• 中小企業がNDAで陥りがちな失敗は何か
• 公的機関が提供している雛形はあるのか
• NDAと、この後結ぶことになる業務委託契約書はどう役割分担するのか
• 実際にNDA案を受け取ったとき、どこを確認すればいいのか

一つずつ、順を追って見ていきます。

NDAとは何か。法律上の位置づけを確認する

NDA(Non-Disclosure Agreement、秘密保持契約)は、取引の過程で知り得た相手の秘密情報を、契約の目的以外に使わない・第三者に開示しないことを当事者間で約束する契約です。NDA（秘密保持契約）という略称はよく使われますが、実は法律上「NDAとはこういう契約である」と定めた条文は存在しません。請負契約(民法第632条)や準委任契約(民法第643条)のように、民法に規定された典型契約とは異なり、NDAは契約自由の原則にもとづいて当事者が内容を自由に決められる契約です。

これは「法律で決まった書式がないから適当に作ってよい」という意味ではありません。むしろ逆で、法律に頼れない分、契約書に書かれた条文の内容そのものが、自社の情報を守れるかどうかを直接左右します。雛形をそのまま使うのではなく、自社の状況に照らして一つひとつ確認する必要があるのはこのためです。

• 請負契約・準委任契約: 民法に条文があり、当事者が何も特約しなくても法律のデフォルトルールが適用される
• NDA(秘密保持契約): 民法上の典型契約ではなく、当事者が条文で定めた内容がそのまま権利義務になる

この違いを理解しておくと、「NDAの条文を丁寧に読む理由」が腑に落ちるはずです。契約書に書かれていないことは、原則として約束されていないのと同じだからです。

不正競争防止法の「営業秘密」とNDAの関係

NDAと合わせて理解しておきたいのが、不正競争防止法上の「営業秘密」という概念です。不正競争防止法第2条第6項は、営業秘密を次のように定義しています。

「秘密として管理されている生産方法、販売方法その他の事業活動に有用な技術上又は営業上の情報であって、公然と知られていないもの」(不正競争防止法第2条第6項)

この定義に該当する情報として法的な保護を受けるには、次の3つの要件をすべて満たす必要があるとされています。

経済産業省は、この3要件の考え方を整理した「営業秘密管理指針」(平成15年1月30日策定、令和7年3月31日最終改訂)を公表しています。この指針では、秘密管理性を満たすための具体的な管理措置(紙媒体・電子媒体それぞれの場合の対応、複数の法人間で情報を共有する場合の考え方など)が詳しく解説されています。

ここで重要なのは、NDAを締結すること自体は、営業秘密の3要件を自動的に満たすものではないという点です。NDAは秘密管理性を裏付ける有力な証拠のひとつにはなりますが、それだけで法的保護が確定するわけではありません。逆に言えば、NDAを結んだからといって社内の情報管理を怠ってよいわけではなく、契約と実際の管理体制の両輪が必要ということになります。

実務上の視点: 「秘密管理性」の要件は、社内でその情報にアクセスできる人を絞り、かつ「これは秘密情報です」と分かる形で管理していることを求めています。たとえば、社内の誰もが自由にアクセスできる共有フォルダに顧客データを置いたままでは、たとえNDAを結んでいても、秘密管理性が認められにくくなる可能性があります。NDAの締結と、社内のアクセス権限の見直しはセットで考える必要があります。

NDAに一般的に含まれる条項

NDAの具体的な条文は契約ごとに異なりますが、実務上よく見られる条項にはある程度共通のパターンがあります。ここでは、代表的な条項を一つずつ確認していきます。

秘密情報の定義

まず確認すべきは、「何が秘密情報として扱われるのか」という定義条項です。定義が広すぎると自社が開示する情報のほとんどが縛られてしまい、逆に狭すぎると肝心の情報が保護対象から漏れてしまいます。

• 開示の形式(書面・口頭・データファイルなど)を問わず対象にするのか、書面化されたものに限定するのか
• 「秘密である旨を明示した情報のみ」に限定する条項になっていないか(明示を忘れると保護対象外になってしまう)
• 公知の情報、開示前から自社が保有していた情報など、除外事由が適切に定められているか

口頭での打ち合わせ中に開示した情報も対象に含めたい場合、「口頭で開示した情報については、開示後一定期間内(例:2週間以内)に書面で秘密情報である旨を通知したものに限る」といった条件が付いていることがあります。この条件を見落とすと、打ち合わせで話した内容の多くが実は保護対象外だった、という事態になりかねません。

目的外使用の禁止と開示範囲の制限

開示された秘密情報を、見積もり検討や要件定義といった契約目的以外に使わないことを定める条項です。あわせて、情報を知ることができる人の範囲(開発会社側の担当役員・従業員に限定する、業務上必要な者に限定する等)も定められます。

ここで確認しておきたいのが、再委託先への扱いです。中小企業がシステム開発を発注する場合、開発会社がさらに別のフリーランスや協力会社に一部の作業を再委託するケースは珍しくありません。自社と直接NDAを結んだ相手が守っても、その先の再委託先が同水準の秘密保持義務を負っていなければ、実質的に情報は保護されません。NDAの条文に「再委託先にも本契約と同等の秘密保持義務を課すこと」という条項が入っているかどうかは、必ず確認すべきポイントです。

• 再委託を行う場合、事前に発注者(自社)の承諾を得る必要があるか
• 再委託先にも本契約と同等の秘密保持義務を課す義務が、開発会社側にあるか
• 再委託先が義務に違反した場合、元の開発会社が責任を負うと明記されているか

これらが条文に入っていない場合、「開発会社は守っているつもりでも、外部のフリーランスから情報が漏れた」というケースに対応できません。見積もり段階で、実際にどこまで自社で対応し、どこから外部に委託する体制なのかを確認しておくことも有効です。

返還・破棄義務

契約終了時、または開示者からの請求があった場合に、受領した秘密情報を記載した資料やデータを返還・破棄することを定める条項です。紙の資料だけでなく、メールに添付したファイルやクラウドストレージに保存したデータ、打ち合わせで使ったオンラインホワイトボードの内容まで含まれているかを確認しておくと安心です。近年はオンライン会議の録画データや議事録の共有ドキュメントに秘密情報が残ることも多く、破棄の範囲を「書面」に限定していると、これらが対象から漏れてしまいます。

契約期間・存続条項

NDAには有効期間が定められますが、あわせて「契約が終了した後も、秘密保持義務は一定期間(たとえば3年、5年など)存続する」という存続条項が置かれるのが一般的です。この存続条項がないと、契約終了と同時に秘密保持義務も消滅してしまい、プロジェクトが終わった直後から情報が保護されなくなるおそれがあります。

見積もり段階のNDAでは有効期間を1〜2年程度の短期に設定し、実際に発注が決まって本契約(業務委託契約)を結ぶ段階で、あらためてより長期のNDA条項を本契約に組み込む、という2段階の運用も実務上よく見られます。見積もり止まりで発注に至らなかった場合でも、短期のNDAで一定期間は情報が保護される設計にしておくと安心です。

損害賠償・管轄裁判所

秘密保持義務に違反した場合の損害賠償に関する条項、および万一紛争になった場合にどの裁判所で争うかを定める管轄条項です。中小企業側からすると、自社の所在地から遠い裁判所が指定されていると、実際に紛争が起きた際の負担が大きくなる点にも注意が必要です。損害賠償額の上限をあらかじめ低く設定する条項が入っている場合、実際に情報漏えいで損害が発生しても、その上限までしか請求できない可能性がある点も見落としやすいポイントです。

システム開発特有の論点

一般的な取引のNDAと比べて、システム開発の外注では次のような特有の論点があります。

ソースコード・設計書の扱い

システム開発では、開発の過程で作成されるソースコードや設計書自体が「技術上の秘密情報」として扱われることが一般的です。発注前の段階でも、自社の既存システムの仕様やデータベース構造を開発会社に開示することがあり、これらも秘密情報の定義に含めておく必要があります。あわせて、開発会社が納品後に類似のシステムを他社に転用しないよう、リバースエンジニアリング(逆コンパイル・逆アセンブル等による解析)を禁止する条項が加えられることもあります。

個人情報保護法との関係

自社の顧客データや従業員データを開発会社に開示する場合、NDAだけでは不十分な場合があります。個人情報を第三者(委託先)に提供する場合、個人情報保護法上は委託先に対する必要かつ適切な監督義務を委託元(自社)が負うことになるため、安全管理措置の内容や再委託の可否、監査権の有無といった論点は、NDAとは別に業務委託契約側で規定するのが実務上一般的です。NDAで秘密保持を約束させるだけで満足せず、個人情報を扱う場合は契約全体の設計を専門家に確認することをおすすめします。

• 本番同等のデータ(実際の顧客名・住所等)を開発・テスト環境に渡す必要が本当にあるか、まず検討する
• どうしても実データが必要な場合は、氏名や連絡先をダミー値に置き換える(マスキング・匿名化)対応ができないか開発会社に相談する
• 実データを渡す場合は、委託先の安全管理措置の内容(アクセス制限、保存期間、返却・削除のタイミング)を契約書で確認する

これらは技術的な相談内容になるため、ひとり情シス担当者だけで判断せず、必要に応じて開発会社側の技術担当者に「本当にこのデータが必要か」を確認する姿勢が重要です。

中小企業が陥りがちな失敗

NDAをめぐって中小企業が陥りやすい失敗には、次のようなパターンがあります。

• NDAを結ばずに詳細な要件を話してしまう: 「まだ正式発注ではないから」という理由で、初回の打ち合わせで自社の業務フローや売上データを詳しく話してしまい、後からNDAを結ぼうとしても手遅れになっているケース
• 相手の雛形をそのまま受け入れる: 開発会社側が用意したNDA雛形をそのまま押印し、自社の実情(たとえば自社の技術・ノウハウを開発会社に開示する場面もあるかどうか)に合っているかを確認しないケース
• 片務的な内容に気づかない: 自社だけが秘密保持義務を負い、開発会社側には同等の義務が課されていない片務的な契約になっているケース
• 秘密情報の範囲を広げすぎる: 「念のため全部秘密情報にしておこう」と考え、公知の情報や業界の一般的な知見まで秘密情報に含めてしまい、後から開発会社側に「この条件では通常業務にも支障が出る」と指摘されるケース

実務上の視点: NDAは開発会社側が用意することが多いため、「相手が用意したものだから専門的で問題ないはず」と思い込みがちです。しかし、開発会社側が用意する雛形は、開発会社にとって有利な内容になっていることも珍しくありません。契約書は「誰が作ったか」ではなく「何が書かれているか」で判断する必要があります。

双務性の確認が重要な理由

中小企業庁が公表している「知的財産取引に関するガイドライン・契約書のひな形」では、秘密保持契約書のポイントとして「一方当事者(例:中小企業)のみが秘密保持義務を負うのではなく、両当事者が公平に秘密保持義務を負う」ことが明記されています。同ガイドラインは令和6年10月に改正され、発注者側が受託側の中小企業に一方的に不利益を転嫁する契約が確認された事例を踏まえ、注意すべきポイントがより詳細に解説されるようになりました。あわせて令和8年1月には、下請代金支払遅延等防止法及び下請中小企業振興法の一部改正の施行に伴い、ガイドライン内の「下請」等の用語の見直しも行われています。

システム開発の発注では、自社(発注者)が開発会社(受注者)よりも立場が強いと考えられがちですが、NDAに関しては発注者側にも開示する秘密情報(業務フロー・売上データ・自社の技術情報)があります。双方が公平に義務を負う内容になっているかを確認することは、発注者・受注者どちらの立場でも重要です。

• 「秘密保持義務を負う」という条文の主語が、一方の当事者だけに限定されていないか(「甲は」のみで「乙は」が抜けていないか、契約書全文を通して確認する)
• 損害賠償・解除条項が、一方にだけ厳しい内容になっていないか

公的機関が提供している雛形

NDAの内容を一から検討するのが難しい場合、公的機関が公開している雛形を出発点にする方法があります。

• 経済産業省「営業秘密管理指針」: NDAそのものの雛形ではありませんが、秘密情報の管理体制をどう整えるべきかの考え方が整理されています
• 中小企業庁「知的財産取引に関するガイドライン・契約書のひな形」: 秘密保持契約書・共同開発契約書等の雛形が公開されており、中小企業が取引で不利益を受けないための注意点がガイドラインとしてまとめられています

これらの雛形は、あくまで一般的な取引を想定した参考資料です。前述のとおり、自社の状況(何を開示するのか、再委託が発生するのか等)に照らして、必要な修正を加えたうえで使うことが前提になります。雛形をそのまま使って終わりにしないという意識が重要です。

NDAと業務委託契約書、どちらで何を約束するか

見積もり段階でNDAを結んだ後、実際に発注が決まると、あらためて業務委託契約書(請負契約または準委任契約)を結ぶことになります。ここで担当者が混乱しやすいのが、「NDAで約束したことと、業務委託契約書で約束することの違い」です。

NDAはあくまで情報の取り扱いに関する契約であり、報酬や納期、成果物の品質については何も定めません。逆に、業務委託契約書は仕事の内容や対価を定めるものであり、秘密保持義務については簡易な条項が1〜2行入っているだけ、というケースも多く見られます。

実務上は、次の2つの進め方のいずれかになります。

1. 見積もり段階で単独のNDAを結び、発注決定後に別途、業務委託契約書を結ぶ(業務委託契約書側にも秘密保持条項を入れることが多い)
2. 見積もり段階ではNDAを結ばず、発注が決まった業務委託契約書の中に秘密保持条項をまとめて入れる

自社の情報をどのタイミングでどこまで開示するかによって、どちらが適切かが変わります。要件定義の段階で詳細な業務フローや顧客データを開示する必要がある場合は、見積もり段階の単独NDAを結んでおく方が安全です。

NDA案を受け取ったときの確認フロー

ここまでの内容を踏まえて、実際にNDA案を受け取ったときに確認する手順を整理します。

1. 秘密情報の定義を確認する: 自社が開示する情報が過不足なくカバーされているか、逆に自社が知り得た相手の情報まで不要に縛られていないか
2. 双務性を確認する: 秘密保持義務が両当事者に公平に課されているか
3. 再委託先への扱いを確認する: 開発会社がさらに別会社・フリーランスに委託する可能性がある場合、再委託先にも同等の義務が課される条項があるか
4. 存続条項を確認する: 契約終了後も一定期間、秘密保持義務が続く設計になっているか
5. 返還・破棄義務を確認する: 契約終了時にデータや資料をどう扱うかが明記されているか
6. 個人情報を扱う場合は契約全体を見直す: NDAだけで完結させず、業務委託契約側での安全管理措置の規定も確認する

この6項目は、専門家でなくても契約書を読みながらチェックできる内容です。ただし、内容に疑問がある場合や、自社にとって明らかに不利な条項が見つかった場合は、無理に自己判断せず、弁護士や商工会議所の相談窓口に確認することをおすすめします。

内容修正を求めるときの伝え方

NDA案を確認した結果、修正してほしい条項が見つかった場合、「開発会社に修正を頼んでも角が立つのではないか」と遠慮してしまう担当者は少なくありません。しかし、NDAの段階で対等な関係を築いておくことは、その後の発注全体の関係性にも影響します。

修正を依頼する際は、次のような伝え方を意識すると角が立ちにくくなります。

• 「不信感」ではなく「社内ルール」として伝える: 「御社を疑っているわけではないのですが、社内の情報管理ルール上、この条項は双方の義務にしていただけますでしょうか」といった伝え方であれば、相手も対応しやすくなります
• 具体的な修正案をセットで提示する: 「この条項がおかしい」と指摘するだけでなく、「◯◯という文言を追加していただけますか」まで提示すると、やり取りの往復が減ります
• 優先順位をつける: すべての懸念点を一度に指摘するのではなく、双務性や再委託の扱いなど、特に重要な項目から優先的に伝える

まっとうな開発会社であれば、双務性の確保や再委託先への義務の明記といった常識的な修正依頼を拒否することはまれです。逆に、こうした基本的な修正依頼にも難色を示す相手であれば、その後の発注プロセス全体でも同様に一方的な進め方をされるリスクがあると捉えることもできます。NDAの交渉は、いわば発注前の「お試し」の機会でもあります。

弁護士に確認すべきかどうかの判断基準

すべてのNDAについて弁護士に確認を依頼する必要はありません。ただし、次のようなケースでは、専門家への相談を検討する価値があります。

• 開示する情報に、自社の重要な技術・ノウハウ、あるいは多くの個人情報が含まれる場合
• 契約金額(想定される発注規模)が大きく、情報漏えい時の影響が大きい場合
• NDA案の内容が複雑で、自社だけでは条文の意味を正確に読み取れない場合
• 損害賠償の上限額や、管轄裁判所の指定など、紛争時の対応に直結する条項に違和感がある場合

商工会議所や自治体の中小企業支援窓口では、契約書に関する無料相談を受け付けている場合があります。顧問弁護士がいない中小企業でも、こうした公的な窓口を一次相談先として活用する選択肢があることは覚えておいて損はありません。

よくある誤解: 「NDAを結べば情報は安全」ではない

NDAを結ぶこと自体は、情報漏えいを未然に防ぐ「約束」であって、情報管理の実態そのものを保証するものではありません。冒頭で触れた「NDAを結んでも守れない部分」がここにあたります。次のようなリスクは、NDAとは別に考える必要があります。

• 開発会社側の社内体制の不備(アクセス権限の管理不足、私物端末での作業等)による漏えいリスク
• NDAを結んでいても、実際に紛争が起きた際に損害の立証が難しいという実務上の限界
• 自社側の情報管理(誰が・どの範囲まで開発会社に情報を渡してよいかのルール)が整っていないことによるリスク

NDAは「万一の際に法的な根拠を持てる」という位置づけの契約であり、日々の情報の取り扱いを安全にするのは、自社・開発会社双方の実務上の管理体制です。この点を混同せず、NDAの締結と並行して、自社が開発会社に渡す情報の範囲(本当に必要な情報だけを渡しているか)も見直しておくと、より安心です。御社が扱う情報の中に、顧客の個人情報や未公表の経営情報が含まれる場合は、NDAの条文を確認するだけでなく、実際に渡すデータの範囲を絞り込むことも並行して検討する価値があります。

よくある質問

Q. NDAには印紙税がかかりますか?

一般的なNDA(秘密保持契約書)は、印紙税法上の課税文書に該当しないケースが多いとされていますが、契約書の内容によっては該当する場合もあります。正確な判断は契約書の具体的な文言によって変わるため、心配な場合は税務署や税理士に確認することをおすすめします。

Q. NDAを結ばずに口頭で「ここだけの話」として伝えた情報も保護されますか?

契約書に「口頭で開示した情報も対象に含む」旨の条項がなければ、口頭で伝えただけの情報は秘密情報として扱われない可能性があります。前述のとおり、口頭開示については書面での事後通知を条件とする条項が多いため、重要な情報を口頭だけで伝えるのは避け、必ず書面(メール等)でも残すようにしてください。

Q. 見積もりを複数社から取る場合、NDAは各社と個別に結ぶ必要がありますか?

はい、原則として相見積もりを取る各社それぞれと個別にNDAを結ぶ必要があります。1社と結んだNDAが他社にも自動的に適用されることはありません。複数社に同じ情報を開示する場合は、事務作業の手間はかかりますが、各社との契約内容(特に秘密情報の定義や存続期間)にばらつきがないか確認しておくと管理がしやすくなります。

Q. NDAの有効期間が切れた後、開発会社は自社の情報を自由に使ってよいのですか?

存続条項が正しく設定されていれば、契約の有効期間そのものが終了した後も、秘密保持義務は存続条項で定めた期間(例:契約終了後3年間)は継続します。存続条項がない、または存続期間が極端に短いNDAの場合は、契約終了後すぐに秘密保持義務がなくなってしまうため、締結前に必ず確認しておくべき項目です。

まとめ: この記事で持ち帰れること

ここまでの内容を踏まえて、今日から実践できることを整理します。この記事を読み終えたことで、次のことが判断できるようになっているはずです。

• NDA案を受け取ったとき、どの条項を優先的に確認すればいいかの判断基準
• 「相手が用意した雛形だから安心」という思い込みを外し、自社の状況に照らして双務性・再委託・存続条項を自分で確認する視点
• NDAだけで情報が守られるわけではなく、自社の情報管理体制もあわせて必要だという理解

まずは、今お手元にある(あるいは過去に結んだ)NDAを1枚取り出して、この記事で挙げた6項目のチェックリストと照らし合わせてみてください。10分程度あれば一通り確認できるはずですし、それだけでも、自社の契約がどの程度整っているかの手がかりになります。

NDAを結んだ後は、いよいよ本格的な発注準備に進みます。要件をどうまとめて開発会社に伝えるかについては要件のまとめ方: 開発会社に伝わる資料の作り方を、契約形態の選び方に迷ったら請負契約と準委任契約の違い:システム開発の契約形態はどちらを選ぶべきかをあわせてご覧ください。また、NDA以降の本契約全体で確認すべき権利関係については発注前チェックリスト（契約・権利・データ・保守）も参考になります。