システム開発を外注する際、開発会社との商談が進むと「では先にNDA（秘密保持契約）を締結しましょう」と雛形のPDFやWordが送られてくる場面があります。受け取ったご担当者の多くが、「双方の機密情報を保護する」「損害賠償の責任を負う」といった条文に目を通したあと、「これにサインして本当に大丈夫だろうか」と手が止まるのではないでしょうか。
社内に法務専任がいなければ、最終的なリスクは現場のマネージャーが背負うことになります。とくに気をつけたいのは、NDAは「締結した瞬間に守ってくれる」ものではなく、「書き方によっては発注者が一方的に不利になる」契約でもあるという事実です。開発会社が用意する雛形は当然、開発会社の立場で作られています。発注者側で読み返さなければ、不利な条項に気づかないままサインしてしまう可能性があります。
本記事では、システム開発を外注する発注者の方を対象に、NDAの基本から締結タイミング・条項ごとの危険な書き方と修正依頼の例文・締結後の情報管理までを、社内議論に持ち帰れる粒度で整理しました。法律の専門家ではなくても、提示された雛形を自分の目で読み返し、「ここは修正をお願いしたい」と発注者の立場から伝えられるようになることを目的としています。
雛形が必要な方は、秋霜堂株式会社が提供するシステム開発における秘密保持契約書（NDA）の雛形もあわせてご活用ください。
システム開発における秘密保持契約書(NDA)の雛形
この資料でわかること
BtoB取引において必須とも言える秘密保持契約書(NDA)の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのようなNDAを結ぶのか興味がある
- システム開発会社がきちんとNDAを取り交わしているのか不安
- 通常のNDAと違いがあるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
NDA（秘密保持契約）とは｜3分でわかる基本
NDAと機密保持契約は同じ意味か
「NDA」「秘密保持契約」「機密保持契約」「守秘義務契約」という言葉を目にしたことがあるかもしれません。これらはほぼ同義で使われており、いずれも「相手に開示した秘密情報を他者に漏らさないこと、また目的外に使わないことを約束する契約」を指します。
NDAは英語の "Non-Disclosure Agreement"（非開示契約）の略で、日本語では「秘密保持契約」または「機密保持契約」と訳されます。ビジネスの文脈でこれらの言葉が混在していても、基本的には同じ意味合いで使われていると考えてよいでしょう。雛形の名称が違っても、その点で構える必要はありません。
NDAを締結する目的
NDAを締結する主な目的は、「相手に開示した情報が意図せず第三者に渡ることを法的に防ぐ」ことです。
「口約束でも十分では？」と思う方もいるかもしれませんが、口頭の約束では後から「そんな約束はしていない」と言われてしまうリスクがあります。NDAを書面で結んでおくことで、もし情報漏洩が起きた場合に「約束違反があった事実」「損害があった事実」を証明する根拠になります。
なお、日本には「不正競争防止法」という法律があり、一定の要件を満たした情報は法律によっても保護されます。ただし、保護される範囲は限定的で、「営業秘密」として認められるには秘密管理性・有用性・非公知性の3要件を満たす必要があります（不正競争防止法 第2条第6項）。NDAを締結することで、この法的保護を補完し、より広い範囲の情報を守ることができます。
システム開発でやりとりされる「秘密情報」の具体例
システム開発では、想像以上に多様な情報が開発会社に渡ります。NDA上の「秘密情報」が具体的に何を指すのかをイメージしておくと、後述する「秘密情報の定義」条項を読むときに違和感を察知しやすくなります。
情報の種類 | 具体例 |
|---|---|
業務情報 | 要件定義書・業務フロー図・社内マニュアル・組織図 |
技術情報 | ソースコード・データベース設計書・API仕様書・インフラ構成図 |
顧客情報 | 顧客リスト・顧客IDや属性データ・取引履歴（個人情報を含む場合あり） |
営業・経営情報 | 売上データ・原価情報・新規事業計画・人事情報 |
とくに顧客情報については、個人情報保護法上、発注者は委託元としての監督責任を負います。NDAだけでなく、個人情報の取り扱いに関する別途の覚書が必要になるケースもありますが、まずNDAの段階で「顧客データを含む情報を渡す」という前提を整理しておきましょう。
システム開発でNDAが特に重要な理由
システム開発の外注では、プロジェクトを進める過程で多くの機密性の高い情報を開発会社と共有することになります。業務フロー・業務ルールは自社の競合優位性の源泉になっていることがありますし、顧客データ・取引先情報は個人情報保護の観点からも厳重な管理が必要です。技術ノウハウやシステム設計方針には独自の仕組みが含まれることも多く、流出リスクが高まります。
さらに注意が必要なのは、システム開発では開発会社がさらに下請けや外注先に業務を委託するケースが多いことです。情報が「自社→開発会社→下請け」と段階的に渡る中で、どこかから漏洩するリスクも考えておく必要があります。NDAには「下請けへの再委託制限」や「同等の秘密保持義務を課す義務」を盛り込むことで、このリスクに備えられます。
「NDAを結べば安全」とは限らない理由
NDAは契約書ですので、内容次第で発注者が不利な立場に置かれることもあります。たとえば次のような書き方が雛形に紛れていれば、形式的にはNDAを結んでいても、実態として発注者が守られていない状態になりえます。
- 「書面で『秘密』と明示した情報のみが対象」と限定されており、口頭で共有した経営情報が保護対象外になっている
- 「再委託は受託者の判断で自由に行える」と書かれており、孫請けや海外オフショアに情報が流れても止められない
- 損害賠償条項が「発注者は受託者に対し損害を賠償する」とだけ書かれ、受託者側の責任に触れていない
本記事の中心となる「危険条項のチェックポイント」は、この前提のもとで読み進めていただくと、より具体的に判断できるはずです。
どのタイミングでNDAを締結すべきか
要件定義の前に締結する（最重要）
NDA締結で最も重要なタイミングは「要件定義を始める前」です。要件定義では、自社の業務フロー・課題・システム化したいポイントなど、多くの機密情報を開発会社と共有することになります。この段階より前に締結しておかなければ、最も重要な情報開示がNDAの保護なしに行われてしまいます。
一点注意が必要です。NDAの効力は原則として「契約締結後」から発生します。つまり、締結前に開示した情報はNDAでは保護されません。もし先に情報を開示してしまった場合は、NDAに「本契約は〇年〇月〇日に遡って適用する」という遡及適用の条項を設けることで対処できます。
複数ベンダーへの見積もり相談時
相見積もりのために複数の開発会社に同じ情報を開示する場面でも、NDAの締結が必要です。「まだ正式な依頼ではないから」「軽い相談だから」と感じて省略しがちですが、見積もりに必要な情報には業務フローや既存システムの構成など、機密性の高いものが含まれることがほとんどです。結果的に1社にしか発注しない以上、提案段階で情報を渡した他社にもNDAで縛りをかけておく必要があります。
複数社から相見積もりを取る際に確認すべき視点については、システム開発会社の種類比較もあわせてご参照ください。
業務委託契約の中に秘密保持条項を入れる方法
実務では、独立したNDA文書を作成するのではなく、業務委託契約書の中に「秘密保持条項」を設ける形が一般的です。これは、開発を正式に依頼する際に業務委託契約や請負契約を締結するタイミングで、秘密保持に関する条項をその中に組み込む方法です。
一方、開発着手の前段階（提案・要件定義の相談フェーズ）では、まだ業務委託契約を結ぶ段階ではありません。この場合は独立したNDAを先行して締結することが適切です。
システム開発における契約形態（請負契約と準委任契約）の使い分けについては、システム開発の請負契約と準委任契約の違いと選び方も参考にしてください。
発注者が確認すべきNDAの条項と危険な書き方
ここからが本記事の中心です。NDAに最低限入っているべき条項を列挙しつつ、各項目で発注者に不利な書き方の例（危険条項）と、修正依頼の例文をワンセットで提示します。雛形を手元に置きながら、項目ごとに対応する条文を探して読み比べてみてください。
秘密情報の定義
確認の目的: NDAで保護される「秘密情報」の範囲を明確にする条項です。これが曖昧だと、後で「その情報は秘密ではない」と主張されかねません。
危険な書き方の例:
- 「書面に『秘密』と明示して相手方に開示した情報に限る」——口頭で共有した経営情報・打ち合わせで話した業務フロー・画面共有で見せた顧客データなどが対象外になります
- 「公知の情報、独自に開発した情報、第三者から正当に取得した情報は除く」とだけが除外規定で、十分な定義がない——「公知」の判断基準が曖昧で、後から開発会社側が「これは公知だった」と主張する余地が残ります
- 逆に「両当事者間で授受される一切の情報」と広すぎる——範囲が広すぎて、開発会社が一般的な技術情報まで秘密として扱う義務を負うため、開発会社の修正要求を受けやすく交渉が長引きます
修正依頼の例文:
第◯条（秘密情報の定義）について、書面・口頭・電磁的方法を問わず開示された情報を秘密情報の対象としてください。口頭で開示した情報については、開示後◯日以内に開示者が書面で秘密である旨を確認する手続きを設けるという形でも構いません。
利用目的の限定（目的外利用禁止）
確認の目的: 受領した秘密情報を、何のために使ってよいかを限定する条項です。「第三者への開示を禁止する」だけでは不十分で、目的外利用の禁止を明示しないと、開発会社が他案件の参考資料として流用する余地が生まれます。
危険な書き方の例:
- 「本契約および両当事者の事業のため」——「両当事者の事業」という表現が広すぎ、開発会社の他案件への流用を正当化する余地があります
- 「本件業務の検討・遂行その他必要な範囲」——「その他必要な範囲」の解釈次第で目的が無限に広がります
修正依頼の例文:
第◯条（目的）について、「本件業務（=具体的な案件名やRFPで定義する範囲）の検討・実施に必要な範囲に限る」と明示してください。「両当事者の事業のため」のような広い表現は削除をお願いします。
第三者開示の制限と再委託の扱い
確認の目的: 受領した秘密情報を、開発会社が下請け・孫請け・コンサルタント・海外オフショア拠点などに開示してよいかを制御する条項です。システム開発では再委託が一般的であるため、ここを白紙委任すると、発注者の知らないところで情報が拡散します。
危険な書き方の例:
- 「受託者は業務の遂行上必要な範囲で再委託することができる」——事前承諾が不要で、開発会社の判断のみで再委託先に情報が渡ります
- 再委託先の秘密保持義務について何も書かれていない——再委託先から漏洩しても、発注者は直接の責任追及がしづらくなります
修正依頼の例文:
第◯条（第三者への開示）について、再委託を行う場合は事前に書面（メールを含む）で発注者の承諾を得ること、および再委託先には本契約と同等以上の秘密保持義務を課すことを明記してください。
有効期間と残存条項
確認の目的: NDAの有効期間（契約期間）と、契約終了後も守秘義務が残る期間（残存条項）を確認します。期間が短すぎると、開発完了後すぐに情報が漏れても咎められません。
危険な書き方の例:
- 「本契約の有効期間は締結日から1年とし、終了後の守秘義務は1年とする」——システムの寿命は数年〜十数年に及ぶため、開発から数年後に過去の情報が流出しても、発注者は責任を問えない状態になります
- 「秘密情報は永久に開示してはならない」——逆に無期限の縛りは現実的でなく、開発会社側の反発を受けて交渉が長引きます
- 「本契約の有効期間はシステム納品日まで」——システム開発では納品後の保守・運用フェーズで継続的に業務データや設計情報にアクセスする場面が続くため、納品で守秘義務を終わらせると運用フェーズでの漏洩リスクをカバーできません
修正依頼の例文:
第◯条（有効期間）について、契約終了後の秘密保持義務の存続期間を◯年（例: 5年）に延長してください。また、業務委託関係が終了した日から起算する旨を明記し、運用フェーズもカバーできる形に修正をお願いします。
業界・案件の性質によりますが、システム開発の場合は契約終了後3〜5年程度の残存期間を確保するのが一つの目安です。
契約終了時の情報の返還・破棄
確認の目的: 契約終了時に、開発会社が保有する秘密情報を返還または破棄させる条項です。これがないと、開発完了後も開発会社のサーバーに要件定義書やソースコードが残ったままになります。
危険な書き方の例:
- 返還・破棄に関する条項がそもそもない
- 「受託者は秘密情報を破棄するものとする」とだけ書かれ、報告義務がない——本当に破棄されたか発注者は確認できません
修正依頼の例文:
第◯条（契約終了時の措置）を追加し、契約終了後または発注者の請求があったときは速やかに秘密情報を返還または破棄し、その結果を書面で発注者に報告することを明記してください。
損害賠償・違反時の責任
確認の目的: NDA違反があった場合の責任範囲・賠償額を定める条項です。発注者だけが重い責任を負う「片務的」な書き方になっていないか確認します。
危険な書き方の例:
- 「発注者は本契約違反により受託者に生じた損害を賠償する」とのみ記載され、受託者側の責任が書かれていない——典型的な片務型の書き方です
- 「いかなる場合も、賠償額は本契約に定める委託料相当額を上限とする」——上限設定自体は妥当ですが、NDAは見積もり前に締結することが多く「委託料」が未確定の段階では実質的な賠償が困難になります
- 「逸失利益・間接損害は対象外とする」が一方の損害だけに限定されている——双方に適用するか、削除を求めるのが穏当です
修正依頼の例文:
第◯条（損害賠償）について、賠償義務を双方に課す表現に修正してください。また、賠償額の上限は別途協議で定める旨に変更するか、上限設定自体を削除いただけますと幸いです。
なお情報漏洩による損害は金額換算が難しく、裁判で認められる損害額が実損よりもはるかに低くなるケースも少なくありません。重要度の高い案件では、双方合意のもとで違約金（違約罰の予定額）を設定することも選択肢です。ただし暴利行為にならない範囲に設定する必要があるため、ここは弁護士相談を推奨します。
知的財産権の帰属がNDAに紛れ込んでいないか
確認の目的: 本来、ソースコードや成果物の著作権は開発契約本体（請負契約・準委任契約）で定めるべき項目です。NDAに「成果物の著作権は受託者に帰属する」と書かれていれば、それはNDAの本来の役割を超えています。
危険な書き方の例:
- NDA内に「秘密情報に基づいて受託者が開発した成果物の知的財産権は受託者に帰属する」と書かれている
- 「秘密情報の使用によって生じる発明・考案その他の知的財産権は受託者に帰属する」
修正依頼の例文:
第◯条に知的財産権の帰属に関する記載がありますが、当該事項は別途締結予定の開発契約で定めるものとし、本NDAでは削除いただけますでしょうか。なお、契約形態（請負・準委任）の選定とあわせて、開発契約で改めて協議させてください。
NDAではなく開発契約本体で契約形態を選定し、それに合わせて著作権の帰属や責任範囲を整理するのが望ましい流れです。著作権の帰属の論点についてはシステム開発の著作権は誰のもの？発注者が知っておきたい権利帰属と契約のポイントもご覧ください。
システム開発における秘密保持契約書(NDA)の雛形
この資料でわかること
BtoB取引において必須とも言える秘密保持契約書(NDA)の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのようなNDAを結ぶのか興味がある
- システム開発会社がきちんとNDAを取り交わしているのか不安
- 通常のNDAと違いがあるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
相互NDA（双務型）と片側NDA（片務型）の使い分け
ここまでの個別チェックポイントとあわせて、契約全体の「対称性」も確認しておきましょう。NDAには大きく「双務型（相互NDA）」と「片務型（片側NDA）」があり、システム開発の発注では原則として双務型が望ましいとされます。
双務型と片務型の違い
種類 | 構造 | 主な用途 |
|---|---|---|
双務型（相互NDA） | 両当事者が互いに秘密情報を開示し、双方が守秘義務を負う | システム開発の発注・業務提携・M&A検討 |
片務型（片側NDA） | 片方のみが秘密情報を開示し、受領側のみが守秘義務を負う | 採用面接・社外講演者への情報共有 |
システム開発では双務型が原則の理由
システム開発では、発注者が業務情報を渡し、開発会社が技術情報やノウハウ、見積もりロジック、提案内容を開示します。実態として双方向に情報が動くため、片務型では一方が守られない非対称な契約になります。開発会社から提示された雛形が片務型の場合は、双務型への変更を依頼するのが基本です。
「双務に見えて実は片務」のパターン
書式上は双務型に見えても、実態が片務に近いケースがあります。気をつけたいパターンを2つ挙げます。
パターン1: 秘密情報の定義が一方に偏っている
「秘密情報とは、本件業務において発注者が受託者に開示する技術情報・経営情報をいう」のように、発注者側の情報のみが秘密情報として定義されているケースがあります。この場合、開発会社側の情報（提案内容・見積もりロジック）は守られないため、相互には見えても実態は片務型です。
パターン2: 損害賠償条項が片務的
「受託者が本契約に違反した場合、受託者は発注者に対し損害を賠償する」のように、受託者の責任のみが書かれているケースもあります（こちらは発注者に有利な片務型ですが、開発会社からは反発が出るため、双方適用の表現に揃えるのが現実的です）。
「双務か片務か」は、用語そのものよりも「秘密情報の定義」と「責任条項」の両方を見て対称性を判断することがポイントです。
発注者がよく陥るNDA締結の失敗例3つ
ここで、発注者が実際にやりがちな失敗パターンを3つ紹介します。雛形レビューの観点に加え、運用面のミスもあわせて押さえておきましょう。
失敗例1: 締結を後回しにして要件定義を始めた
最も多い失敗です。「まず概要の話をしてから」「正式依頼が決まってから締結しよう」という感覚で、要件定義フェーズに入ってから締結するケースがあります。この場合、締結前に開示した情報（業務フローの説明、システム要件の共有など）はNDAの保護対象外になります。後から遡及適用の条項を入れても、相手側が同意しない場合はカバーできません。
対処法: 「最初の詳細な打ち合わせ前にNDAを締結する」をルールにしましょう。最初の商談は「会社紹介・概略説明」程度に抑え、詳細な業務情報の開示前に必ずNDA締結を完了させてください。
失敗例2: 秘密情報の定義を「一切の情報」と広く設定した
発注者側が安心しようとして「開示したすべての情報を秘密情報とする」という広すぎる定義を設けてしまうことがあります。一見すると安全に見えますが、これは実務上問題を起こしやすい定義です。受領した開発会社側が「どこまでが秘密情報か分からない」と感じ、かえって形骸化するリスクがあります。また、本来は秘密にしなくてよい公知の情報や、開発会社が独自に開発した情報まで「秘密」と扱うことになり、運用に摩擦が生じます。
対処法: 「秘密と明示したもの」または「一定の除外事項を設けた上での全情報」という形で、除外事項を明確にした定義を採用しましょう。
失敗例3: 有効期間をシステム納品で終わらせてしまった
「開発が完了したらNDAも終わり」という認識で、有効期間を「システム納品日まで」と設定してしまうケースがあります。しかしシステム開発後も、保守・運用フェーズで継続的に自社の業務データや設計情報にアクセスする場面が続きます。納品後の秘密保持が担保されていないと、運用フェーズでの情報漏洩リスクをカバーできません。
対処法: 有効期間を「業務委託関係の終了後3〜5年」と設定し、サービス運用期間を含めてカバーしましょう。
発注者向けNDA締結前チェックリスト
ここまでの内容を、社内議論に持ち帰れる粒度で表にまとめました。雛形を手元に置きながら、条項ごとに「OK／NG」を判定してみてください。
締結前チェックリスト（条項別）
確認項目 | OKの判断基準 | NGだった場合の対処 |
|---|---|---|
秘密情報の定義 | 書面・口頭・電磁的方法を問わず開示された情報が対象。口頭は事後書面確認のルール明記 | 「書面で秘密と明示したものに限る」とあれば、修正依頼 |
利用目的 | 「本件業務の検討・実施に必要な範囲」と限定的に記載 | 「両当事者の事業のため」など広い表現は具体化を依頼 |
第三者開示・再委託 | 再委託は事前書面承諾。再委託先に同等以上の義務を課す旨が明記 | 「受託者の判断で再委託可」とあれば、事前承諾制への変更を依頼 |
有効期間 | 契約期間と残存条項が別に明示。残存期間は3〜5年以上 | 残存1年以下、納品日終了などなら延長を依頼 |
返還・破棄 | 契約終了時の返還・破棄ルールと書面報告義務が明記 | 規定がなければ追加を依頼 |
損害賠償 | 双方に責任が課される双務型。上限設定は協議事項に | 一方のみに責任が課されていれば、双務型への修正を依頼 |
知的財産権 | NDAには知財帰属の規定がない（開発契約本体で定める） | 知財条項が紛れ込んでいれば、NDAからは削除を依頼 |
双務性 | 秘密情報の定義・損害賠償の両方が双方適用 | 片務的な定義があれば、双務型への修正を依頼 |
準拠法・管轄 | 日本法、原則として発注者所在地の裁判所 | 受託者所在地のみ指定なら、協議または発注者所在地への変更を依頼 |
個人情報 | 顧客の個人情報を渡す場合、個情法を踏まえた条項または別途覚書 | 個人情報の取扱に触れていなければ、別途覚書を依頼 |
自社で判断できる範囲と、専門家に相談すべきライン
本記事のチェックリストで対応できるのは、「条項の漏れ」「明らかな片務性」「典型的な不利な書き方」など、雛形レベルの判定です。次のような場合は、社内の法務担当者や顧問弁護士に確認することをおすすめします。
- 委託する業務に個人情報・マイナンバー・医療情報・金融情報など、規制業種特有のセンシティブな情報が含まれる場合
- 開発会社から英文NDAまたは準拠法が日本法以外のNDAが提示された場合
- 想定される損害額が大きく、賠償額の上限設定や違約金条項を慎重に詰める必要がある場合
- 海外オフショア拠点への再委託が想定されている場合（越境データ移転の論点を含む）
- 雛形が改訂版で送られ、前回との差分を確認する余裕がない場合
NDAは「サインしてしまえば、後から不利な条項を覆すのは難しい契約」です。社内に法務担当がいなくても、契約レビューに対応するサービスや弁護士のスポット相談は活用できますので、判断に迷う条項があれば外部の力を借りるのも有効です。
なお、フリーランスエンジニアと直接NDAを締結する場合は、法人開発会社と異なる論点（個人での履行能力・個人情報の取扱・契約終了時の対応など）があります。詳細はフリーランスエンジニアとのNDA締結ガイドをご参照ください。
NDA締結後の情報管理｜契約を機能させる実務
NDAは締結した瞬間に効力を発揮しますが、運用が伴わなければ実態として機能しません。締結後の実務として、最低限押さえておきたい3点を紹介します。
自社の情報管理ルール
NDAで発注者側が秘密情報を渡す立場である場合、自社の情報管理体制も問われます。開発会社からの監査要求や、自社内での情報統制の観点で、次の点を整えておきましょう。
- アクセス権限の限定: プロジェクトに関与しない社員が秘密情報にアクセスできる状態を避ける
- 関係者への周知: NDAの存在と、対象となる情報の範囲を関係者に共有する
- 保管方法の整理: 開発会社から受領した提案書・見積書・サンプルコードは、社内の指定ストレージに集約する
開発会社の再委託・情報管理状況の継続確認
NDAで再委託の事前承諾を取り付けても、開発の途中で追加の再委託が発生することはあります。月次の進捗会議などで、再委託先の有無を継続的に確認するのが望ましい運用です。
- 「現時点で再委託している作業はありますか」と定期的に確認する
- 開発会社の情報セキュリティ体制（ISMS認証・Pマーク等）を確認する
- 重要なフェーズ（顧客データを扱う実装期間など）では、作業者リストの提示を求める
開発完了時の情報返還・破棄の実行確認
開発完了後、NDAの条項通りに情報の返還・破棄が行われたかを確認します。書面での報告を求める旨をNDAに入れていれば、契約終了時に報告書の提出を依頼してください。
- 受領した情報の返還または破棄の報告書を受領する
- 開発会社のサーバー・バックアップから秘密情報が削除されたことを確認する
- 開発に関連した個人情報については、削除完了の証跡を別途確保する
NDAが形骸化する典型パターンは、「締結したまま誰もフォローせず、開発完了後に情報がそのまま残る」というものです。締結時に決めた運用ルールを、節目で点検する仕組みを作っておきましょう。
まとめ｜発注者のためのNDAレビュー3つの軸
システム開発のNDAは、「締結すれば安全」な契約ではなく、「内容次第で発注者にも不利になる」契約です。本記事のチェックリストを使って、提示された雛形を一度ご自身の目で読み返していただくと、修正を依頼すべきポイントが具体的に見えてくるはずです。
とくに確認したいのは次の3点に集約されます。
- 秘密情報の定義が広すぎず・狭すぎないか（口頭情報が抜けていないか・一方に偏っていないか）
- 再委託の事前承諾と、再委託先への同等義務が明記されているか
- 損害賠償が一方的に発注者だけに重く設定されていないか（双務型になっているか）
雛形のまま受け入れるのではなく、「ここは修正をお願いしたい」と発注者の立場から伝えることは、信頼できる開発パートナーかどうかを見極める機会にもなります。誠実な開発会社であれば、双務性の確保や再委託制限の追記は前向きに対応してくれます。
その上で、個人情報を多く扱う案件・賠償上限の設定・英文NDA・海外オフショアが絡む案件などは、社内の法務担当者または弁護士に相談するのが安全です。NDAは「サインしたら戻れない」契約だからこそ、締結前の一手間を惜しまずに進めていきましょう。
雛形をすぐに使いたい方へ: 秋霜堂株式会社では、システム開発における秘密保持契約書（NDA）の雛形を無料でダウンロードいただけます。発注者・受注者両方の視点を踏まえた実用的な雛形をご活用ください。
システム開発における秘密保持契約書（NDA）の雛形をダウンロードする
システム開発における秘密保持契約書(NDA)の雛形
この資料でわかること
BtoB取引において必須とも言える秘密保持契約書(NDA)の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのようなNDAを結ぶのか興味がある
- システム開発会社がきちんとNDAを取り交わしているのか不安
- 通常のNDAと違いがあるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
