システム開発のNDA（秘密保持契約）｜いつ結ぶ・何を守る・条項の要点

システム開発を外部に頼むとき、多くの人が意識するのは見積もりや契約書ですが、その手前で交わしておきたいのが**NDA（秘密保持契約）**です。相談の段階で、実現したいアイデア・顧客データ・社内の業務の中身を相手に伝えることになるからです。この記事では、NDAがなぜ必要か、いつ結ぶか、どんな条項を盛り込むか、そしてNDAだけでは守れないことまで、中小企業が実務で押さえるべき点を分かりやすく解説します。

※本記事は秘密保持契約の一般的な考え方の解説です。実際の契約は個別の事情や業種によって異なります。重要な契約は弁護士など専門家にご確認ください。

NDA（秘密保持契約）とは何か

NDAは「Non-Disclosure Agreement」の略で、日本語では秘密保持契約と呼びます。ひとことで言えば、「あなたに渡した情報を、外に漏らさず、決めた目的以外に使わない」と約束してもらう契約です。

システム開発では、発注側が相手に多くの情報を渡します。たとえば次のようなものです。

• 実現したいサービスやアプリのアイデア・企画
• 顧客リスト・取引先・売上などのデータや数字
• 日々どう仕事を回しているかという業務の手順やノウハウ
• 既存システムの構成や、社内でしか知らない運用ルール

これらは、いったん外に出れば取り返しがつきません。情報は物と違って、コピーされても手元から減らないため、「返してもらえば済む」ものではないからです。NDAは、そうした情報を渡す前に「守ります」という約束を書面にしておくものだと考えてください。口約束でも約束は約束ですが、書面にしておくことで、何を守るのか・いつまで守るのかがはっきりし、万一のときに義務の範囲を示せるようになります。

NDAは、後で結ぶ開発契約（請負・準委任）とは役割が違います。開発契約が「何をいくらで作るか」を決めるのに対し、NDAはその手前の「話す・見せる」段階で情報を守る入口の契約です。

なぜシステム開発でNDAが必要なのか

「まだ正式に発注していないから大丈夫」と考えて、NDAを結ばずに込み入った相談をしてしまうケースは少なくありません。しかし、守りたい情報の多くは相談・見積もりの段階ですでに相手に渡っています。

NDAが守るものを整理すると、次の3つに分けられます。

守るもの	具体例	漏れたときのリスク
アイデア・企画	新規事業の構想、独自の仕組み	似たサービスを先に出される・競合に流れる
顧客データ・個人情報	会員リスト、購買履歴	顧客への信用失墜、法令上の問題
業務情報・ノウハウ	独自の業務フロー、価格の決め方	競争力の源泉が外部に流出する

特にアイデア段階の新規事業では、「話した内容そのもの」が価値を持ちます。契約前でも、企画書や画面イメージを見せた時点で情報は渡ってしまうため、話し始める前にNDAを結ぶことに意味があります。アイデアそのものは法律で自動的に守られるわけではないため、「聞いた内容を使わない」という約束を書面にしておくことが、実質的な防御になります。

また、顧客データや個人情報を渡す場合は、万が一の漏えい時に自社が顧客や取引先に対して責任を問われることもあります。NDAは、相手に守る義務を課すと同時に、「きちんと情報管理に配慮していた」という自社側の姿勢を示すことにもつながります。取引先や監査で「委託先とどんな取り決めをしているか」を問われたとき、NDAがあることが説明の裏づけになる場面もあります。守る側・守られる側の両面で、NDAは意味を持つ契約だと考えてください。

NDAはいつ結ぶのがよいか

タイミングの基本は、**自社の情報を渡す「前」**です。順番を意識すると分かりやすくなります。

• 初回の問い合わせ：ざっくりした相談だけなら、まだ具体的な秘密情報は出ないことも多い
• 詳しい打ち合わせ・ヒアリング：ここで業務の中身やデータの構造を話す＝NDAを結んでおきたい段階
• 見積もり・要件のすり合わせ：機能や仕様を具体的に詰める＝秘密情報が本格的に渡る
• 開発契約の締結：ここでようやく請負・準委任の契約を結ぶ

つまり、遅くとも「詳しい打ち合わせ」に入る前にNDAを締結しておくのが安全です。多くの開発会社はNDAの締結に慣れているため、「詳しい話をする前にNDAをお願いしたい」と伝えれば、スムーズに応じてくれるのが一般的です。逆に、NDAの依頼に難色を示したり、内容の説明があいまいだったりする会社は、情報の扱いに慣れていない可能性があるため、一つの見極めの材料にもなります。

紙の書面でなくても、内容が明確であれば電子契約サービスなどで締結しても構いません。大切なのは形式よりも、「守りたい情報を渡す前に、守る約束が成立している」状態を作っておくことです。

「例：新しい予約サービスを作りたい飲食チェーンのケース」では、店舗数・客単価・予約の取り方といった数字を伝えないと正確な見積もりが出せません。こうした数字を出す前にNDAを結んでおけば、複数社に相談して比較する場合でも、それぞれの会社に安心して情報を渡せます。

NDAに盛り込む主な条項

NDAは短い契約書ですが、押さえるべき項目は決まっています。ひな形を受け取ったら、次の条項が入っているか確認しましょう。

条項	何を決めるか	見るポイント
秘密情報の定義	何を「秘密情報」とするか	口頭で伝えた内容も含むか、範囲が狭すぎないか
目的外利用の禁止	受け取った情報を何に使ってよいか	「本件の検討・開発のため」に限定されているか
第三者への開示禁止	外部に漏らさない義務	再委託先・協力会社への扱いはどうなるか
返還・破棄	契約終了時に情報をどうするか	返すのか、消すのか、証明を求められるか
有効期間	いつまで守る義務が続くか	契約終了後も一定期間続くか
損害賠償	違反したときの責任	賠償の範囲が現実的か

とくに実務で差が出やすいのが、次の3点です。

• 秘密情報の定義：「書面で秘密と明示したものだけ」と狭く定義されていると、口頭で話した内容が守られないことがあります。打ち合わせで多くを口頭で伝えるなら、口頭の情報も含める書き方になっているか確認します。
• 目的の限定：受け取った情報を「本件の検討・開発の目的にのみ使う」と限定しておくと、目的外の流用を防げます。
• 返還・破棄と期間：プロジェクトが終わったあと、渡したデータをどう処理するか、義務がいつまで続くかを決めておきます。

なお、どんなNDAでも「秘密情報にあたらないもの」を定めた例外条項が入っているのが一般的です。たとえば「もともと公開されている情報」「相手が独自に知っていた情報」「NDAと関係なく後から公になった情報」などは、守る対象から外れます。これは相手を過度に縛らないための当然の取り決めなので、例外があること自体は問題ありません。ただし、例外の範囲が広すぎると守る情報が実質的に減ってしまうため、書き方は確認しておきましょう。

条項の文言は難しく見えますが、「誰が・何を・いつまで・どう守るか」を具体的にしているかという視点で読むと、抜けが見つけやすくなります。細かな法律用語よりも、この4点がはっきりしているかどうかが実務では重要です。

一方向NDAと相互NDA・片務と双務

NDAには「誰が義務を負うか」で種類があります。ここを理解しておくと、提示された契約書が自社に不利になっていないか判断しやすくなります。

種類	中身	向いている場面
一方向（片務）NDA	一方だけが秘密を守る義務を負う	発注側だけが情報を渡すとき
相互（双務）NDA	双方が互いに守る義務を負う	双方が情報を出し合うとき

システム開発では、発注側がアイデアやデータを渡す一方で、開発会社も見積もりの根拠・技術的な工夫・過去事例などを開示することがあります。双方が情報を出し合うなら相互NDAにしておくと、どちらの情報も等しく守られます。

注意したいのは、相手から提示されたひな形が開発会社側だけに有利な一方向NDAになっていないかです。たとえば「発注側は開発会社の情報を守る」とだけ書かれ、逆向きの義務が薄いような場合、自社のアイデアやデータが十分に守られないことがあります。義務が一方に偏っていないか、双方向で対等になっているかを確認しましょう。片務・双務という言葉は難しく聞こえますが、要は「守る約束をするのが片方だけか、お互いか」という違いです。自社が渡す情報の量と、相手から受け取る情報の量を見比べて、実態に合った形を選べば問題ありません。

NDAだけでは守れないこと

ここが最も誤解の多いところです。NDAは「情報を漏らさない」契約であって、完成したシステムやソースコードの権利までは決めません。

たとえば、次のようなことはNDAの守備範囲の外です。

• 完成したシステムのソースコードを誰が持つか（著作権の帰属）
• 他社に乗り換えたときに、自社でシステムを改修できるか
• 納品物にバグがあったときの修正責任（契約不適合責任）
• 作業の進め方・支払いのタイミング

これらは、NDAとは別に、請負契約や準委任契約の中で定める必要があります。とくに成果物の権利は重要です。契約に「著作権を発注側へ譲渡する」と書かれていないと、原則として権利は開発会社に残り、後から他社へ乗り換えたり自社で改修したりしにくくなります。これはベンダーロックインの原因にもなります。

NDAと開発契約の役割を整理すると、次のようになります。

契約	主に決めること	タイミング
NDA	渡した情報を守る義務	相談・見積もりの前
開発契約（請負・準委任）	何を・いくらで作るか、権利、責任	発注が固まった段階

つまり、NDAで入口を守り、開発契約で中身と成果物を守るという二段構えになります。NDAを結んだからといって安心しきってしまい、開発契約で権利や責任の取り決めを曖昧にしてしまうと、完成後に「ソースコードをもらえない」「他社で直せない」といった問題が起きかねません。入口の契約と本体の契約は、どちらも欠かせないものだと理解しておきましょう。契約形態の詳しい違いはシステム開発の契約｜請負と準委任の違いで、発注全体の進め方はシステム開発の発注の流れで解説しています。

個人情報を渡すときの注意点

顧客名簿・会員データ・購買履歴など、個人情報を含むデータを開発会社に渡す場合は、NDAに加えて配慮が必要です。個人情報は、漏れたときに自社だけでなく顧客本人にも影響が及ぶためです。

実務で押さえたい点を挙げます。

• 本当に本物のデータを渡す必要があるかを検討する。テストなら、名前や連絡先をダミーに置き換えた（マスキングした）データで足りることも多い
• 渡す場合は、渡す範囲を必要最小限にする（全件でなく一部、項目も必要なものだけ）
• 開発会社が再委託先に渡す可能性を確認し、再委託先にも同じ守秘義務が及ぶようにする
• 契約終了時に、渡したデータを確実に破棄してもらう取り決めをしておく

個人情報の取り扱いには法令上のルールもあります。委託先に個人データを預ける場合は、委託元がその管理状況を適切に把握しておくことが一般的に求められます。詳しい対応は扱うデータの内容によって変わるため、心配な場合は専門家に相談するのが確実です。まずは「不要な個人情報はそもそも渡さない」という姿勢が、いちばんの防御になります。開発の初期段階では、実データの代わりに件数や項目だけを共有し、本番のデータを渡すのは開発が固まってからにする、といった段階的な進め方も有効です。

NDAのひな形はどう用意するか

NDAのひな形（テンプレート）の入手先には、大きく2つの考え方があります。

• 自社で用意する：公的機関や業界団体が公開しているモデル契約書などを土台に、自社用のひな形を用意しておく。毎回同じ様式で結べるので、比較や管理がしやすい
• 相手が提示するものを確認する：開発会社がNDAのひな形を持っていることも多い。その場合は、内容が自社に不利になっていないかを確認したうえで結ぶ

どちらでも構いませんが、相手提示のものをそのまま鵜呑みにしないことが大切です。前述のとおり、秘密情報の定義が狭すぎないか、義務が一方に偏っていないか、有効期間や返還のルールが妥当かを確認しましょう。

内容に不安がある場合は、金額の大きい案件や重要なデータを渡す案件では、契約前に専門家に目を通してもらうと安心です。ひな形をそろえておけば、複数の会社に相談して相見積もりを取るときも、同じ条件で安心して情報を渡せます。

発注前のNDAチェックリスト

提示された契約書を読むときの手引きとして、結ぶ前に確認したい点をまとめます。

• 秘密情報の定義は十分に広いか（口頭で伝えた内容も含むか）
• 受け取った情報を目的以外に使わないと限定されているか
• 第三者・再委託先への開示の扱いが決まっているか
• 契約終了時の返還・破棄のルールがあるか
• 有効期間は妥当か（終了後も一定期間続くか）
• 違反時の責任の範囲が現実的か
• 双方が情報を出すなら相互（双務）NDAになっているか
• 義務が一方に偏っていないか
• 個人情報を渡すなら、範囲を最小限にできているか

これらを一つずつ確認するだけで、入口段階での情報リスクは大きく減らせます。

まとめ

NDA（秘密保持契約）は、システム開発の相談・見積もりで自社の情報を渡す「前」に結ぶ、入口の契約です。守るのは、アイデア・顧客データ・業務ノウハウといった、いったん漏れると取り返しのつかない情報です。ポイントを整理します。

• NDAは話す・見せる前に結ぶのが基本
• 盛り込む条項は、秘密情報の定義・目的外利用の禁止・第三者開示の禁止・返還/破棄・有効期間・損害賠償
• 双方が情報を出すなら相互（双務）NDAにする
• NDAだけでは成果物の権利は守れない。ソースコードの権利や改修のしやすさは、請負・準委任の開発契約で別途定める
• 個人情報を渡すときは、範囲を最小限にし、必要ならダミーデータで代替する

NDAと開発契約という二つの契約を正しく使い分ければ、情報を守りながら安心して複数社に相談し、納得のいく発注ができます。「どこまで契約書を確認すればいいか分からない」「発注の進め方から相談したい」という方は、無料相談からお気軽にお問い合わせください。