オフショア開発のセキュリティ対策と情報管理

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

要点： この記事は「海外に出して大丈夫か」ではなく、発注する側が何を決めておけばよいかを扱います。守る対象の分け方、渡すデータの作り方、アカウントの配り方、契約と法律、委託先に聞く項目を順に並べます。

「ベトナムに開発を出したいのですが、情報が漏れませんか」。オフショア開発のご相談で、費用の次によくいただく質問です。

2000年創業のWeb制作・システム開発会社ZenWeb Japanは、ベトナムに自社の拠点を持ち、日本人SEが窓口に立つ形でベトナムオフショア開発をお受けしています。その立場から言えば、危ないかどうかは国では決まりません。発注する側がどこまで決めて渡したかで決まります。

委託先経由のリスクは国内でも重く見られています。IPA（情報処理推進機構）の情報セキュリティ10大脅威 2026では、「サプライチェーンや委託先を狙った攻撃」が組織向けの2位に入り、8年連続の選出となりました。

委託先まで含めた脅威の全体像は、次の動画がわかりやすい下地になります。

02危ないのは持ち出しより「決めていない初期設定」です

要点： 実際の案件で見つかる問題のほとんどは、悪意で持ち出した跡ではありません。決めていなかったために既定のまま残った設定です。本番データのコピー、生きたままのアカウント、共有された認証情報の3つに集まります。

ご相談の場で語られる不安は、たいてい劇的です。ソースコードを丸ごと持って行かれる、顧客名簿が売られる。ところが環境を点検すると、出てくるのは地味な話ばかりです。

• 本番データのコピーが開発環境に残っている。 移行テストで一度入れたデータが、消されずに残ります。
• 退場したメンバーのアカウントが生きている。 追加はすぐ行われますが、停止は後回しになります。
• 認証情報がチャットに貼られている。 急ぎの一時共有が、検索できる形でずっと残ります。

どれも、契約書に「厳重に管理すること」と書くだけでは防げません。誰が何をしてよいかを決めていないので、現場が一番早い方法を選んだ結果です。オフショア開発の失敗事例と対策と、原因の形はよく似ています。

03守る対象を3つに分けて考えます

要点： 「情報を守る」とひとまとめにすると手が止まります。本番データ・成果物・アカウントと環境の3つに分けてください。守り方も、困りごとの中身も、決める人も違います。

3つに分けると、どこから手を付けるかが決まります。

軽く見られるのが真ん中の成果物です。ワイヤーフレームや画面設計は、そのまま業務の設計図になります。渡すときは資産を預けている感覚を持ってください。

3つとも、決めるタイミングはオフショア開発の要件定義と同じです。あとから足すと環境ごと作り直しになります。

04種類別｜見つかった事象と気づくまでの日数

要点： 着手前の点検で最も多く見つかるのは、退場後も有効なアカウントです。ただし気づくまでの日数が長いのは、分散した成果物と開発環境に残った本番データでした。危ないのは頻度ではなく、気づけない期間です。

頻度と危なさは一致しません。気づくまでの日数が長い事象ほど、監視ではなく棚卸しで見つかっています。誰かが定期的に一覧を眺めない限り、見つからないまま続きます。

05本番データは渡さずに済ませます

要点： オフショア開発で本番データそのものを渡す必要は、ほとんどありません。氏名や連絡先を別の値に置き換え、件数と偏りだけ本番に近づければ、テストの精度は落ちません。守る手間より、作る手間のほうが軽く済みます。

「本物のデータでないとテストにならない」と言われます。必要なのは中身ではなく、同じ形と量です。次の4点を押さえれば、加工したデータで足ります。

• 個人を特定できる列だけを置き換える。 氏名・住所・電話番号を仮の値にします。桁数と文字種は本番に合わせてください。
• 件数と偏りは本番に近づける。 100件で動いたものが10万件で止まります。量を減らすと性能の問題が見えません。
• 例外データこそ作る。 空欄、旧字体、半角と全角の混在、締め日をまたぐ取引。バグはここに出ます。
• 受け渡しの経路を1本にする。 共有ストレージを1か所に決め、メール添付は禁止します。経路が増えるほど消し忘れも増えます。

それでも本番データを使わざるを得ない場面はあります。その場合は期間を区切り、作業を国内側の環境に閉じてください。

06アカウントは人ではなく役割に配ります

要点： 権限を人ごとに付けていくと、要員が入れ替わるたびに設定が積み重なります。開発者・テスター・管理者といった役割を先に作り、人はそこへ入れてください。停止も、役割から外すだけで済みます。

オフショア開発の現場は、国内より人の出入りが多くなります。1人増えるたびに個別に権限を付けると、半年後には誰が何を見られるのかわからなくなります。次の5点を最初に決めてください。

• 役割を3〜5個に絞る。 開発者・テスター・ブリッジSE・管理者で足ります。細かく分けるほど運用が続きません。
• 共有アカウントを作らない。 誰が操作したかが残らず、何かあったときに追えません。
• 入退場を1つの台帳にまとめる。 参加日と離任日を同じ表に書き、停止の作業はここから出します。
• 停止は離任の当日に行う。 「あとでまとめて」は残ります。日付が来たら止める、と先に約束してください。
• 月に一度、一覧を突き合わせる。 台帳と実際のアカウント一覧を並べるだけ。30分で終わります。

要員が固定されるラボ型開発は、この点でも有利です。窓口をブリッジSEに一本化すれば、誰が申請して誰が承認するかも自然に決まります。

07権限管理の方式別｜離任30日後に残っていた割合

要点： 役割ベースで配り、月に一度棚卸しをしている案件では、離任30日後に残っていたアカウントは4%でした。個別付与で台帳もない案件では71%です。差を生むのは技術ではなく、月1回の突き合わせでした。

役割ベースにしただけでも17%まで下がり、そこに月30分の棚卸しを足すと4%になります。費用のかかる仕組みではなく、30分の習慣が効いています。一番下の行は、何が残っているかすら集計できませんでした。

08拠点・回線・端末は現地の運用まで確認します

要点： 物理面の対策は、設備があるかではなく運用されているかで見ます。区画・入退室記録・端末・印刷とUSB・在宅勤務の扱い。この5点を質問すれば、規程が動いているかがわかります。

現地を見学できるなら、設備より人の動きを見てください。難しければ次の5点を質問し、答えの具体性で判断します。

• 執務エリアが区画されているか。 案件ごとに区切るか、全社で1つの島かで、見える情報の範囲が変わります。
• 入退室の記録が残るか。 カードで入れることと、記録を後から出せることは別の話です。
• 端末は会社支給か。 支給端末に統一されているか、私物の利用を認めているかを確認します。
• 印刷とUSBが止められているか。 技術的に止まっているのか、禁止と書いてあるだけなのか。
• 在宅勤務のときどうするか。 一番あいまいになりやすい部分です。回線と場所の条件まで聞いてください。

写真と見取り図、社内規程の現物を出してもらえれば実態は見えます。比べ方はオフショア開発会社の選び方にまとめました。

09契約とNDAには守り方まで書きます

要点： 「機密を厳重に管理する」とだけ書かれたNDAは、実務ではほとんど働きません。再委託の可否、保管の場所と期間、終了時の消去、事故の連絡時間、監査の受入れ。この5点を条文にしてください。

秘密保持契約は結んだのに、いざというとき何も決まっていない。埋めておきたいのは次の5点です。

• 再委託を認めるか。 認めるなら事前承諾を必須にし、再委託先にも同じ義務を負わせます。空欄だと見えない先ができます。
• データをどこに置くか。 保管する国とサービス、保持期間を書きます。「開発期間中のみ」では終わりの日が決まりません。
• 終了時にどう消すか。 返還か消去か、証明書を出すのかまで決めます。バックアップの扱いも書いてください。
• 事故のとき何時間で連絡するか。 時差があるので日本時間で書き、第一報の期限を数字で入れます。
• こちらから確認できるか。 年1回の書面確認や記録の提出を条文にすれば、毎回交渉せずに済みます。

知的財産の帰属や準拠法はオフショア開発の契約とNDA｜知的財産の扱いで整理しています。セキュリティの条項は契約書の中に散らばりやすいので、一覧にしてから条文に落としてください。

10要件を決めた時期別｜追加費用と工期への影響

要点： セキュリティ要件を提案依頼の段階で決めた案件では、追加費用は開発費の2%以内でした。検収前に決めた案件では18〜27%かかり、工期も26日延びています。同じ対策でも、決める時期で費用が10倍以上変わります。

やることの中身は、どの行でもほとんど変わりません。変わるのは、作られたものをどれだけ触るかです。あとから決めるほど、作り直す範囲が広がります。セキュリティは要件定義と同じ時期に決めてください。

11個人情報を海外に渡す前に決めること

要点： 個人データを外国の事業者に扱わせる場合、個人情報保護法では原則として本人の同意が必要です。委託でも同じです。同意を取らずに進めるなら、契約などで相当措置を確保する体制を整え、継続的に確認する必要があります。

ここは法律の話なので、正確に押さえます。個人情報保護委員会のガイドライン（外国にある第三者への提供編）によると、外国にある第三者へ個人データを提供するときは、法第28条により原則として本人の同意が必要です。国内の委託なら同意が要らない場面でも、相手が外国の法人なら同じには扱えません。

同意以外の道は2つです。1つは、日本と同等の水準と認められた国にある場合で、ガイドラインではEUと英国が挙げられています。ベトナムは含まれません。もう1つが、提供先が相当措置を継続的に講ずる体制を整えている場合で、委託なら契約や覚書で担保する形が示されています。

実務では、次の3点を先に決めておくと迷いません。

• そもそも個人データを渡すか。 加工して渡せるなら、この論点は小さくなります。
• 渡すなら、同意か契約か。 契約で担保する場合は、法第28条第3項により相当措置が続いているかを確認します。年1回の確認を運用に入れてください。
• 委託先の監督を誰が担うか。 法第25条の委託先の監督は、委託した側の義務です。担当者を決めないと実行されません。

公表の考え方は個人情報保護法のWebサイト対応にまとめました。判断に迷う場合は、弁護士など専門家にご確認ください。

12委託先に確認する8つの項目

要点： 委託先の見極めは、認証を持っているかより、資料をすぐ出せるかで判断できます。運用が回っている会社は、権限一覧も入退室記録の規程も既にあるので数日で出てきます。

提案の段階で、次の8点を聞いてください。答えの内容と同じくらい、返る早さが参考になります。

1. 秘密保持契約の雛形。 自社の雛形を持っているか、こちらの雛形に応じられるか。
2. アクセス権限の一覧。 現在の案件でどう配っているかを、形式だけでも見せてもらいます。
3. 入退室と持ち込みの規程。 文書があるか、更新日はいつかを確認します。
4. 認証の取得状況。 ISO/IEC 27001などの有無と、対象となる拠点の範囲。
5. 再委託先の一覧。 使っている場合、どこまで開示できるか。
6. 過去のインシデントと対応。 あったかどうかより、どう動いたかを聞きます。
7. データの保管場所。 どの国のどのサービスに置くか。
8. 終了時の消去手順。 証明書を出せるかどうかまで。

この8点は、そのまま比較表の列になります。体制の見方はオフショア開発の品質は低い？管理体制で決まる、公開後の費用はシステム保守・運用費用の相場をご覧ください。

13確認項目別｜提示を受けられた割合と日数

要点： 秘密保持契約の雛形はほぼ全社が出せますが、再委託先の一覧は39%、過去のインシデント対応の記録は22%でした。出るまでに日数がかかる項目のほうが、運用の弱い場所を教えてくれます。

認証の欄に注目してください。取得は47%と半数を切りますが、提示は2日と短めです。証書を1枚送るだけだからです。一方、権限一覧や入退室規程は日々の運用そのものなので、ない会社は数日かけても出てきません。見極めにはこちらがよく効きます。

14開発中に効く小さな運用ルール

要点： 大がかりな仕組みがなくても、日々の約束事で防げます。資料の置き場を1つにする、パスワードをチャットに貼らない、生成AIに貼る範囲を決める。この3つだけでも事故の芽は減ります。

開発が始まると、守れる形のルールでないと続きません。負担の軽いものから入れてください。

• 資料の置き場を1つに決める。 共有フォルダを1か所にして、そこ以外は使わない約束にします。
• パスワードをチャットに貼らない。 期限付きの共有機能を使い、使い終わったら消します。チャットは全文検索できます。
• スクリーンショットも同じ扱いにする。 本番データが写った画像は、データそのものと変わりません。
• 生成AIに貼ってよい範囲を決める。 コードの断片は可、顧客データと認証情報は不可、という線を最初に引きます。
• 週に一度、アクセスの記録を眺める。 深夜や休日の接続がないかを見るだけです。5分で終わります。

技術面の基礎はWebシステムのセキュリティ対策｜脆弱性の基本にまとめました。特別なことをするというより、国内でもやるべきことを書き出して共有する、という順番です。

15まとめ｜セキュリティ要件を決める順番

要点： 決める順番は、扱うデータの棚卸しから始めて、渡す形、権限、契約、確認項目へと進みます。この順なら提案依頼の時点でほぼ固まり、作り直しが出ません。

オフショア開発のセキュリティ要件を決める順番

次の7ステップを、提案依頼を出す前に一度通してください。1〜2日で終わります。

1. 扱うデータを洗い出す。 個人情報・取引情報・社内資料を書き出し、海外に渡す必要があるかを判断します。
2. 渡す形を決める。 渡さない、加工して渡す、国内環境に閉じて扱う。この3つから選びます。
3. 環境を分ける。 開発・テスト・本番のどこまで委託先が触れるかを線引きします。
4. 役割と権限を決める。 役割を3〜5個作り、停止の手順と棚卸しの頻度も決めます。
5. 契約とNDAに落とす。 再委託・保管場所・消去・連絡時間・監査の5点を条文にします。
6. 法律面を確認する。 個人データを渡す場合、本人の同意か体制整備かを選び、確認の頻度を決めます。
7. 確認項目を提案依頼に入れる。 委託先に出してもらう資料を先に伝え、比較表の列にします。

飛ばされやすいのは2番目と4番目です。成果物が増えないため後回しになりますが、費用と手直しに最も効くのはこの2つです。

体制ごとの向き不向きはベトナムオフショア開発のサービスページ、はじめての委託ならオフショア開発とは？メリットと失敗しない進め方もご覧ください。

16よくある質問

要点： オフショア開発のセキュリティについて、ご相談の場でよくいただく質問をまとめました。本番データの扱い、認証の必要性、事故のときの責任など、契約前に決めたい点を並べます。

1. 本番データをどうしても渡す必要がある場合はどうしますか

期間と対象を区切ってください。移行テストの数日間だけ、必要な範囲だけに絞ります。作業を国内側の環境に閉じ、画面共有で進める方法もあります。終わったら消去し、記録を残してください。

2. 委託先にISO/IEC 27001の認証は必須ですか

必須ではありません。認証は仕組みを整えた証明ですが、日々の運用まで保証するものではないためです。認証に加えて、権限の一覧や入退室記録の規程を実際に出してもらうほうが実態はよくわかります。

3. 情報が漏れたとき、責任はどちらが負いますか

契約の定め方によります。ただし個人情報保護法上の委託先の監督義務は、委託した側にあります。賠償を求められるかとは別に、お客様や個人情報保護委員会への対応は自社で行います。だからこそ、渡す範囲を最初に絞る意味があります。

4. ベトナムは情報管理の面で不安がありませんか

国名だけでは判断できません。同じ国でも、拠点ごとに運用は大きく違います。見るべきは、権限をどう配っているか、入退室の記録を出せるか、再委託があるかどうかです。国ではなく、その会社の運用を見てください。

5. 小規模な開発でも、ここまで決める必要がありますか

規模が小さいほど、決めるのは簡単です。扱うデータが少なければ、渡さないという選択がそのまま取れます。逆に省いたまま拡張すると、あとから環境ごと作り直しになります。最初の1回だけ、時間を取ってください。