オフショア開発の契約とNDA｜知的財産の扱い

01はじめに｜この記事でわかること

要点： この記事は、オフショア開発の契約を法律の解説ではなく、どの書類にどの条項を置くかの順で整理します。NDAで守れる範囲、著作権を確実に自社へ移す書き方、成果物の一覧の作り方までを並べます。

「ベトナムの会社に見積りをもらいました。契約書は先方の雛形でいいと言われたのですが、そのまま進めて大丈夫でしょうか」。オフショアの相談では、この質問が最初に出てきます。

2000年創業のWeb制作・システム開発会社ZenWeb Japanでは、ベトナムオフショア開発のご相談で、まず契約書を3つに分けるところから始めます。1枚にまとめようとすると、必ずどこかが抜けるためです。

条文そのものの当否は弁護士の領域です。ここで扱うのはその一歩手前、開発の実務で起きることを契約のどこに書いておくかという整理になります。個別の判断は専門家にご確認ください。

秘密保持の考え方そのものは、次の動画が下地になります。

02契約書は3つに分けると整理できます

要点： オフショア開発の契約は、NDA・基本契約・個別契約の3本で組みます。NDAは相談段階、基本契約は取引全体の共通ルール、個別契約は案件ごとの納期と金額を担当します。役割を分けると、あとから足す作業が軽くなります。

1本にすべて詰め込むと、次の案件で作り直しになります。3つに分けておけば、2件目以降は個別契約だけで動けます。

• NDA（秘密保持契約）。 見積りの相談を始める前に結びます。仕様書や顧客データを渡す時点で、もう秘密情報のやり取りが始まっています。
• 基本契約（取引基本契約）。 著作権の帰属、再委託、損害賠償の上限、準拠法など、案件をまたいで変わらないルールをここに置きます。
• 個別契約（発注書・注文請書）。 案件ごとの成果物、納期、金額、検収の期限を書きます。基本契約を引用する1〜2枚の書類で足ります。

この3本立ては国内のシステム開発でも標準的な組み方です。条項の並べ方は、IPAが公開している情報システム・モデル取引・契約書（第二版）が参考になります。どちらにも偏らない中立の雛形なので、先方の書式を読むときの物差しに使えます。

オフショアだから特別な契約が要るわけではありません。オフショア開発の基本的な進め方を押さえ、国をまたぐことで増える項目を足していく順番です。

03NDAで必ず決める5項目

要点： NDAで決めるのは、秘密情報の範囲・目的外利用の禁止・開示できる相手・有効期間・終了後の返還または消去の5つです。海外の相手と結ぶときは、開示できる相手の欄に再委託先と現地の個人事業主を書き足します。

NDAは短い書類ですが、抜けやすい欄は決まっています。次の5つを埋めれば実務で困りません。

1. 秘密情報の範囲。 口頭で伝えた内容を含めるかどうかを決めます。含めるなら「口頭開示後14日以内に書面で特定する」といった手順もあわせて書きます。
2. 目的外利用の禁止。 受け取った情報を、本件の開発以外に使わせないための条項です。他社向けの流用や、社内の学習用データへの転用もここで止めます。
3. 開示できる相手。 相手方の従業員だけでなく、再委託先、現地の個人事業主、親会社まで書き出します。オフショアでは実質ここが一番効きます。
4. 有効期間。 契約期間と、秘密保持義務が続く期間は別物です。義務の側は契約終了後3〜5年で設定する例が多く見られます。
5. 終了後の返還・消去。 ソースコード、テストデータ、社内チャットの履歴まで対象に含め、消去の完了報告を求める形にします。

NDAだけで守れる範囲には限りがあります。オフショア開発の失敗事例と対策でも触れたとおり、問題が起きたときは証拠が残っているかで結果が変わります。誰に何を渡したかの記録を残す運用まで含めて、はじめて機能します。

04契約項目別｜あとから交渉になった割合

要点： 契約書の書き方が曖昧だったために、開発の途中や納品後に交渉が発生した項目を集計しました。もっとも多いのは著作権・知的財産の帰属で、全体の4割を超えます。次いで仕様変更時の追加費用です。

上位3つは、いずれも着手前に文章にできる項目です。実際に揉めるのは、日々の作業に直結する手前の部分でした。

交渉になった項目の上位3つは、すべて着手前に1ページで書ける内容でした。

会社を選ぶ段階で契約書を見せてもらうと、この差が見えます。オフショア開発会社の選び方の比較項目に、契約書の開示を1つ足しておきましょう。

05請負と準委任｜オフショアでの選び分け

要点： 仕様が固まっているなら請負、動かしながら決めるならラボ型（準委任）が向きます。オフショアでは、要件定義を準委任、製造を請負に分ける組み方もよく使われます。契約形態で追加費用の出方が変わります。

契約形態の違いは、責任の重さではなく「変更をどう受け止めるか」の違いです。

• 請負契約。 完成した成果物を納めることが約束の中身です。仕様が確定していれば金額が読めます。反面、途中の変更はそのつど見積り直しになります。
• 準委任契約（ラボ型）。 決まった人数のチームを一定期間確保します。優先順位の入れ替えが利き、仕様が動く前提のプロジェクトに向きます。
• 混合型。 要件定義と設計を準委任、製造とテストを請負にします。決めきれない部分と決まった部分を、契約の側で切り分ける形です。

それぞれの中身はシステム開発の契約形態｜請負と準委任の違いに、ラボ型の費用の考え方はラボ型開発の解説にまとめています。

どちらを選んでも、契約書に書く項目は大きく変わりません。変わるのは変更が起きたときの手続きです。次の集計にその差が出ています。

06契約形態別｜仕様変更が起きたときの扱い

要点： 同じ規模の仕様変更でも、契約形態によって追加費用の発生率と納期の遅れが変わります。請負では6割を超える案件で追加費用が出ましたが、ラボ型では2割程度にとどまりました。

数字だけ見るとラボ型が有利ですが、そう単純でもありません。ラボ型は月額の枠で優先順位を入れ替えているので、追加費用が出ないかわりに後回しの機能が残ります。総額の考え方はオフショア開発の費用相場と人月単価とあわせて見てください。

07著作権は「譲渡する」と書かないと移りません

要点： 開発を発注しただけでは、成果物の著作権は自社に移りません。契約書に譲渡の条項が必要です。しかも「第27条および第28条の権利を含む」と明記しないと、改修や転用にかかわる権利が相手側に残ります。

ここがオフショアに限らず、システム開発でもっとも取り返しがつかない部分です。納品を受けても、契約書に譲渡の一文がなければ、著作権は作った側に残ります。

やっかいなのは、「著作権を譲渡する」と書くだけでは足りない点です。翻案（第27条）と二次的著作物の利用（第28条）にかかわる権利は、明記しないかぎり譲渡した側に残ります。文化庁の著作権テキストでも、すべての権利を譲り受けるには第27条・第28条を含める旨の明記が必要だと説明されています。

この一文の有無は、改修のたびに効いてきます。翻案権が相手に残ると別の会社に改修を頼めない状態が起こりえます。次のように書き分けます。

• 譲渡の対象。 「本件成果物に関する著作権（著作権法第27条および第28条の権利を含む）は、代金の支払い完了をもって甲に移転する」と書きます。
• 著作者人格権。 人格権は譲渡できません。「乙は甲に対し著作者人格権を行使しない」という不行使の条項で対応します。
• ベンダー側の既存資産。 相手が以前から持つライブラリや共通部品は、譲渡ではなく利用許諾が現実的です。範囲と期間を書きます。
• OSSの扱い。 使ったオープンソースの一覧とライセンスの提出を、納品物の1つとして求めます。

権利がどう分かれるかという論点は、Webサイトでも同じ構図です。ホームページの著作権｜制作会社と発注者の権利もあわせてご覧ください。

08成果物はソースコード以外も一覧にします

要点： 成果物の欄に「ソースコード一式」とだけ書くと、設計書やテスト結果は付いてきません。個別契約の別紙に、書類・環境・アカウントまで並べた一覧を付けておきます。

納品後に「あれがない」と気づく資産は決まっています。契約時に一覧にしておけば、追加でお願いする手間が消えます。

• 設計にかかわる書類。 要件定義書、基本設計書、画面設計、ワイヤーフレーム、データベース定義書。改修時にもっとも効く資産です。
• テストにかかわる書類。 テスト仕様書と実施結果。品質の根拠を後から示すために要ります。
• 環境とアカウント。 構築手順書、サーバーの設定値、ドメインやクラウドの管理者アカウント。名義が相手のままだと、契約終了後に困ります。
• 運用にかかわる書類。 操作マニュアル、障害時の連絡フロー、定期作業の手順。

この一覧はオフショア開発の要件定義で認識ズレを防ぐ書き方とセットで作ると早く進みます。要件定義の成果物が、そのまま納品物の一覧になるためです。基本の考え方は要件定義の進め方にまとめました。

09条項の有無別｜納品後に受け取れた割合

要点： 契約書に明記した場合と、していない場合で、納品時に実際に受け取れた資産の割合を比べました。ソースコードの差は小さい一方、設計書や環境の情報は明記の有無で大きく開きます。

下にいくほど差が開きます。ソースコードは黙っていても付いてきますが、環境の設定値やアカウントの名義は書かなければ動きません。開発会社は自社の運用資産だと考えているためです。引き継ぎまで見据えた進め方はWebシステム開発のページにまとめています。

10再委託と担当者の入れ替わりを縛る条項

要点： 再委託は原則禁止にしたうえで、事前の書面承諾があれば認める形にします。あわせて、承諾した再委託先にも同じ秘密保持義務を負わせる条項を入れます。担当者の交代は、事前通知と引き継ぎ期間で対応します。

オフショアでは、契約した会社がそのまま作るとはかぎりません。現地の別会社やフリーランスに一部を回す運用は珍しくないためです。禁止するより見える形にするほうが現実的です。

• 事前承諾の形。 「乙は甲の書面による事前の承諾なく、本件業務の全部または一部を第三者に再委託してはならない」を基本に置きます。
• 再委託先への義務の連鎖。 承諾した場合も、再委託先に本契約と同等の義務を負わせ、その履行について相手が責任を持つ、と続けます。
• 担当者の交代。 主要メンバーの交代は事前通知とし、2週間程度の引き継ぎ期間を置く形が実務的です。
• 作業場所の限定。 開発を行う拠点を特定し、私物端末での作業や社外持ち出しを禁止します。

条項で縛るだけでは運用が追いつきません。誰が何をしているかが週次で見えていれば、条項を持ち出す場面自体が減ります。日々の進め方はオフショア開発のコミュニケーション対策に、体制の見方はベトナムオフショア開発の強みにまとめました。

11個人情報を渡すなら越境移転の手当てが要ります

要点： 本番データを海外の開発会社に渡す場合、個人情報保護法の「外国にある第三者への提供」に当たります。本人の同意を取るか、契約で相当措置を確保する体制を整えるかのどちらかが必要です。まず検討すべきは、渡さずに済ませる方法です。

テストのために本番データをそのまま渡す。よくある場面ですが、ここは慎重に進めます。海外の会社に個人データを提供するときは、国内の委託とは別のルールがかかるためです。

個人情報保護委員会のガイドライン（外国にある第三者への提供編）では、本人の同意を得る方法のほか、提供先が必要な体制を整えていれば同意によらない方法も示されています。この体制は、提供元と提供先の契約や覚書といった「適切かつ合理的な方法」で確保することが想定されています。

ベトナムには2023年に個人データ保護の政令が施行され、越境移転にも規制があります。相手国の制度は、同委員会が外国制度（ベトナム社会主義共和国）として公開しています。

実務としては、次の順で検討すると落ち着きます。

1. まず、渡さない方法を探す。 氏名・電話番号・メールアドレスをダミーに置き換えたテストデータを用意します。多くの案件はこれで足ります。
2. それでも必要なら、範囲を絞る。 件数と項目を最小にし、期間を区切って渡します。
3. 契約で体制を確保する。 委託契約や覚書で、利用目的・安全管理措置・再委託・返還と消去までを取り決めます。
4. 社内の説明も残す。 プライバシーポリシーの記載と、社内の承認記録を整えておきます。

体制が整っているかは、見ればわかります。判断の材料はオフショア開発の品質は管理体制で決まるにまとめました。

12検収と契約不適合責任｜期間はどう決めるか

要点： 検収は「合格の基準」と「みなし合格までの日数」の2つを書きます。納品後の不具合対応は契約不適合責任の条項で決め、期間は6か月から1年で設定する例が多く見られます。無償の範囲もあわせて書きます。

検収の条項でよくあるのは「納品後14日以内に検査し、期間内に通知がなければ合格とみなす」という形です。日数に目が行きがちですが、効いてくるのは合格の基準のほうです。

• 合格の基準。 テスト仕様書に沿って全項目が通ること、といった判定できる形にします。「問題なく動くこと」では判断できません。
• 検査の期間。 自社側の確認体制を考えて決めます。担当者が1人なら14日は短く、30日程度が現実的です。
• 不合格時の手続き。 是正して再納品する回数と期限を書いておきます。
• 契約不適合責任の期間。 検収合格後に見つかった不具合をいつまで無償で直すか。開発の規模に応じて6か月から1年で設定します。

ここでよく起きるのが不具合と仕様変更の線引きです。要件定義書と違えば不具合、書いていない要望なら変更。この基準を検収の条項に添えると、あとの議論が短くなります。

納品後の運用まで含めた費用の見方は、システム保守・運用費用の相場と契約の中身にまとめています。

13準拠法と紛争解決｜どこで決着させるか

要点： 海外の会社と直接契約するなら、準拠法を日本法、紛争解決を日本での仲裁または東京地方裁判所と定めるのが基本です。日本法人と契約する形にすれば、この論点自体が小さくなります。

先ほどの集計で、準拠法をめぐる交渉は8%でした。多くはありませんが、問題が起きたときの負担は大きい項目です。

• 準拠法。 どの国の法律で契約を解釈するかを決めます。日本法を指定するのが基本です。
• 紛争解決の方法。 裁判所か仲裁かを選びます。国をまたぐ場合、判決の執行のしやすさから仲裁を選ぶ考え方もあります。
• 使用する言語。 契約書を日英で作るなら、どちらを正本とするかを書きます。
• 通貨と為替。 支払い通貨と、為替の変動をどちらが負担するかを決めます。

もっとも、国内の会社と契約し、その会社が海外拠点で開発する形なら、これらの論点は大きく縮みます。契約相手が国内法人なら、準拠法も裁判管轄も日本の枠で完結するためです。委託先の形の違いはニアショアとオフショアの比較で整理しています。

14工程別｜NDAから開発着手までの日数

要点： NDAの締結から開発の着手までは、あわせて3〜6週間ほどかかります。時間がかかるのは基本契約の条項調整で、著作権と再委託の2項目で往復が発生しやすくなります。

2件目以降は個別契約だけで動くので、5〜10日で着手できます。時間がかかるのは1件目だけだと考えて、スケジュールに1か月分の余白を置いておくと安心です。

金額の妥当性もあわせて見たい場合は、システム開発の見積もりの見方｜人月単価と工数の仕組みを先に読むと、条項の調整と並行して進められます。

15まとめ｜決める順番

要点： NDAを先に結び、基本契約で著作権と再委託を固め、個別契約で成果物と検収を書く。この順で進めれば、あとから戻る作業がほとんどなくなります。

オフショア開発の契約を決める順番

ここまでの内容を、手を動かす順番に並べ直しました。

1. NDAを結ぶ。 仕様書を渡す前に締結します。開示できる相手の欄に、再委託先と現地の個人事業主を書き足します。
2. 契約形態を決める。 仕様が固まっていれば請負、動かしながら決めるならラボ型を選びます。
3. 基本契約で著作権を固める。 「第27条および第28条の権利を含む」を入れ、著作者人格権の不行使もあわせて定めます。
4. 再委託の条項を入れる。 原則禁止・事前承諾・義務の連鎖の3点をセットで書きます。
5. 成果物の一覧を別紙にする。 書類・環境・アカウントの3列で洗い出し、個別契約に添付します。
6. 検収の基準と期間を書く。 判定できる基準にし、自社の確認体制に合った日数を設定します。
7. 個人データの扱いを決める。 ダミーデータで足りるかを先に検討し、必要なら契約で安全管理措置まで取り決めます。

この7つのうち、あとから直せないのは3番目の著作権だけです。ほかは運用で補えます。時間をかける場所は、それだけはっきりしています。

体制ごとの向き不向きは、ベトナムオフショア開発のサービスページにまとめています。

16よくある質問

要点： オフショア開発の契約について、ご相談の場でよくいただく質問をまとめました。契約書の言語、NDAの有効期間、雛形の使い方など、着手前に確認しておきたい点を並べています。

1. 契約書は英語で作る必要がありますか

相手が海外法人なら英語または日英併記が一般的です。併記するときは、どちらを正本とするかを必ず書いてください。日本法人と契約する形なら日本語のみで問題ありません。オフショア開発の基本もご確認ください。

2. NDAの有効期間はどれくらいが適切ですか

契約期間は1年程度でも、秘密保持義務は契約終了後3〜5年続く形にする例が多く見られます。ソースコードや顧客データのように時間がたっても価値が落ちない情報なら、長めに設定しておくと安心です。

3. 相手の雛形をそのまま使っても問題ありませんか

読んだうえで足りない条項を追記するなら差し支えありません。とくに確認したいのは、著作権の譲渡に第27条・第28条が含まれているか、成果物の一覧が別紙になっているか、再委託の扱いが書かれているかの3点です。

4. 契約書を作るのに費用はかかりますか

基本契約の雛形を弁護士に作成・確認してもらう場合は費用が発生します。金額は内容と分量で変わるため、事前に見積りを取ってください。ZenWeb Japanの料金は案件ごとの見積り制で、契約準備の進め方もあわせてご相談を承ります。

5. 途中で開発会社を変えることはできますか

著作権の譲渡と成果物の一覧が契約に入っていれば可能です。逆にどちらも書かれていないと、設計書がないまま引き継ぐことになり、費用が膨らみます。失敗事例と対策で具体的な場面を紹介しています。