オフショア開発のセキュリティ対策【2026年版】リスク6類型と5層の対策、発注前チェック20項目

「海外の開発会社に自社のソースコードや顧客データを見せて、本当に大丈夫なのか」——オフショア開発を検討している方から、こうした問いをよく受けます。役員会で「情報が海外に出るのは危険ではないか」と差し戻された、顧客企業のセキュリティチェックシートに再委託先の所在国を書けない、提案書に「ISMS取得」とあるが実効性が分からない。どれも、答えに困る問いです。

結論から言うと、オフショア開発のセキュリティリスクは6類型に整理できます。情報漏えい、ソースコードの流出、不正アクセス、再委託先からの漏えい、退職者や交代メンバーの持ち出し、法規制違反の6つです。そしていずれも「海外だから」起きるのではありません。過去の大きな事故を見ると、共通しているのは「正規の権限を持つ委託先の人が、監視の穴から持ち出した」という構造で、国内外に差はありません。

だから対策も、場所ではなく構造に打ちます。契約・人・環境・運用・法規制の5層で組めば、リスクは管理できる範囲に収まります。逆に、NDAを1通結んだだけで安心してしまうのは失敗のもとです。そして、どうしても海外に出せない機密データがあるなら、無理に出さず「データは国内に置き、処理だけ委託する」設計を選べばよい、というのが当社の考え方です。

本記事では、リスク6類型と実際に起きた事故の構造、対策5層の中身と日本・ベトナムの法規制、ISO27001(ISMS)やPマークの見方、発注前に確認するチェックリスト20項目、機密データを出せない案件の設計、よくある質問の順に解説します。表とチェックリストは、そのまま社内の稟議書や委託先への質問票に使える形にしました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。現場で「これは危ういな」と感じるのは、いつも決まった3つのパターンです。この記事を読み終えるころには、自社の案件でどこまで対策すべきか、委託先に何を聞けばよいかが判断できるはずです。なお、法規制の記述は公開情報に基づく一般的な整理であり、法的助言ではありません。

オフショア開発のセキュリティリスク6類型と、実際に起きた事故

オフショア開発のセキュリティを議論するとき、最初につまずくのは「何が危ないのかが漠然としている」ことです。「情報漏えいが心配」では対策も稟議も書けません。まずはリスクを6つの類型に分け、それぞれ「何が起きるか」「どこから起きるか」を押さえてください。ここを整理すると、後の対策が驚くほど機械的に組めるようになります。

リスク6類型の一覧表(何が起きるか・どこから起きるか)

オフショア開発のセキュリティを扱う解説記事の多くが挙げるリスクは「機密情報・ソースコードの流出」と「コスト優先で対策が不足する」の2つに集約されており、4〜6の類型まで整理した記事は多くありません。しかし実務で稟議が止まるのは、たいてい4(再委託)と6(法規制)です。この2つを説明できるかどうかが分かれ目になります。

事例1: 村田製作所(2021年)——再委託先の社員が業務用PCへ無断ダウンロードし個人クラウドへ

村田製作所は2021年8月5日、外部委託先(日本アイ・ビー・エム)の再委託先である中国法人IBM Dalian Global Delivery の社員が、同社の会計システム更新プロジェクトの管理データを業務用パソコンへ許可なくダウンロードし、中国国内のクラウドストレージの個人アカウントへアップロードしていたと発表しました。対象は72,460件(取引先情報30,555件、従業員関連情報41,905件)で、会社名・住所・氏名・電話番号・メールアドレス・銀行口座などが含まれていました。

注目すべきは経緯です。6月28日にダウンロードが行われ、6月30日に再委託先の社内監視システムがセキュリティアラートを検知し、7月4日に事実を確認しています。つまり、監視の仕組みは機能していました。一方で、発注元である村田製作所へ報告が届いたのは7月20日です。委託先の先で何が起きているかは、契約の連鎖をたどらないと見えません。再委託を許すかどうかが、セキュリティ設計の分岐点になる理由がここにあります。

事例2: ベネッセ(2014年)——正規の権限を持つ委託先の元社員が私物のスマートフォンで持ち出し

もう1件は国内の事例ですが、構造を理解するうえで欠かせません。ベネッセコーポレーションでは2014年、グループ会社のシステム開発・運用を担う業務委託先の元社員が顧客情報を不正に取得し、約3,504万件分を名簿業者3社へ売却しました。実態の漏えい件数は約2,895万件と推計されています。

この元社員は、業務の必要性から正規のアクセス権を与えられており、顧客情報を業務用パソコンに抽出したうえで私物のスマートフォンを介して持ち出していました。同社の発表によれば、外部メディアへの書き出し制御が一部の新機種に対応していなかったこと、大容量データのアラート設定の対象に当該データベースが含まれていなかったこと、アクセスログを定期的にチェックしていなかったことが重なっていました。悪意を持った内部者に対して、権限・端末・ログの3点に穴があったわけです。

海外か国内かは、この構造にほとんど関係しません。「正規の権限を持つ人が、監視の穴から持ち出す」。これがオフショア開発でも起きる事故の基本形で、だからこそ対策は「国」ではなく「権限・端末・ログ・契約」に打つべきだ、というのが私の考えです。

私が現場で危ういと感じる3つ——個人PC、共有アカウント、退職者の権限

2018年からホーチミンで約100社の開発体制を見てきましたが、「これは危ういな」と感じる場面はほぼ3つに絞られます。1つ目は、エンジニアが個人所有のパソコンで開発しているケース。端末の中に何が残っているかを誰も把握できません。2つ目は、開発メンバーが共有アカウントでサーバーやリポジトリに入っているケース。誰が何をしたかがログから追えず、事故が起きても特定できません。3つ目は、退職したメンバーのアカウントが残っているケースです。

3つとも、高価なツールを入れなくても直せます。支給端末に統一する、アカウントを個人単位にする、入退場の手続きを月次で棚卸しする。それだけで、リスク1・2・5はかなり小さくなります。では残りのリスクも含めて、どう体系立てて対策を組めばよいのか。次章では、契約・人・環境・運用・法規制の5層に分けて整理します。

セキュリティ対策は5層で組む——契約・人・環境・運用・法規制

対策を一覧で並べると、どうしても抜けが出ます。前章のリスク6類型に一つずつ手当てしていくのではなく、「契約・人・環境・運用・法規制」の5層で組んでください。層が違えば効き方が違うので、1層だけを厚くしても穴は塞がりません。逆に言えば、5層それぞれに最低限の手を打てば、費用をかけすぎずにリスクを管理できる水準に届きます。

対策5層の一覧表(層・目的・具体策・確認方法)

5層のうち、日本企業が手薄になりがちなのは「人」と「運用」です。契約書は法務が作り、環境は情報システム部門が用意しますが、誓約書の締結単位や権限の棚卸しは誰の担当かが曖昧なまま始まることが多い。ここが空くと、前章の村田製作所・ベネッセの構造がそのまま再現されます。

契約と人: NDAは企業間だけでは足りない——個人の誓約、再委託の制限、知財帰属、準拠法

「NDAを結んだから大丈夫」という説明を受けることがありますが、企業間のNDA1通では足りないのが実情です。実際に情報に触れるのは会社ではなく個人なので、参画するエンジニア一人ひとりと秘密保持の誓約を交わし、着任時に何が機密かを具体的に説明する必要があります。

契約で必ず押さえたいのは4点です。第1に再委託の扱いで、原則禁止か事前承諾制にし、承諾する場合も同等の義務を再委託先に負わせる旨を書きます。第2に知的財産の帰属で、ソースコードや成果物の権利が発注側に移る時期を明記します(詳しくは「システム開発 知的財産 帰属」の記事で解説しています)。第3に準拠法と裁判管轄です。相手が海外法人だと、紛争時に現地の裁判所で現地法に基づいて争うことになり、実務上のハードルが上がります。第4に事故時の報告期限で、「発見から何時間以内に誰へ報告するか」を数字で決めておきます。

当社の場合、契約と支払いは日本国内法人・日本法準拠で、海外送金も不要です。準拠法と管轄が日本にあるというだけで、法務部門の確認事項はかなり減ります。契約の全体像は「業務委託契約とは」の記事も参考にしてください。

環境と運用: アクセス権限の最小化、本番データを渡さない、Gitとログで見える化

環境で最も効くのは、地味ですが「支給端末に統一する」ことです。他の解説記事の多くが「開発用パソコン・OSは日本側で用意する」を挙げているのは、端末を握れば持ち出し経路の大半を塞げるからです。加えて、VPNや仮想デスクトップ経由にして手元にデータを残さない、USBや私物端末の接続を制御する、といった構成を取ります。入退室管理や専用の開発ルームも有効ですが、これは一定の規模がないと費用対効果が合いません。

運用で欠かせないのは3つです。アカウントを個人単位にして権限を最小化すること、Gitのプルリクエストを必須にしてマージできる人を限ること、アクセスログを「定期的に人が見る」こと。ベネッセの事例が示すとおり、ログは取っているだけでは機能しません。当社は日本人PMの設計レビューとGitプルリクエストによるコードレビューを標準化しており、誰がどのコードを書き、誰が承認したかが履歴として残ります。セキュリティは品質管理の仕組みの一部として運用するのが現実的です。

そして本番データです。個人情報を含む本番データを開発環境に持ち込まず、マスキングやダミーデータで開発する。これだけでリスク1と6の大部分が消えます。要注意なのは、テスト用と称して一時的に本番データを渡し、そのまま残ってしまうケースです。

法規制: 日本の個人情報保護法25条・28条と、ベトナムのPDPL・サイバーセキュリティ法

法規制は2方向から見ます。日本側は個人情報保護法で、委託先の監督(25条)と、外国にある第三者への提供の制限(28条)が中心です。個人データを海外の委託先に渡す場合、原則として本人の同意を得るか、提供先が「個人情報取扱事業者が講ずべき措置に相当する措置」を継続的に講ずる体制を整えていることが求められます。個人情報保護委員会のガイドライン(外国にある第三者への提供編)は令和7年12月に一部改正されており、同意取得時の情報提供や、相当措置の継続的な実施を確保するための措置まで細かく定められています。

ベトナム側は、2026年1月1日に個人データ保護法(PDPL・法律91/2025/QH15)が施行され、それまでの政令13号(13/2023/ND-CP)を引き継いでいます。実務で影響が大きいのは3点です。越境データ移転については当局への評価書の提出義務があり、個人データの漏えい時にも当局への通知義務があります。どちらも期限が定められていますが、条文の細部は施行後の運用で詰まっていく段階にあるため、越境移転を伴う体制では契約前に現地の最新の取り扱いを確認してください。罰則も強化され、ジェトロによれば、越境移転規制に違反した場合は前年の売上高の5%または30億ドン(ジェトロの換算で約1,800万円)のいずれか高い方の罰金が科されます。さらに2026年7月1日には2025年サイバーセキュリティ法(法律116/2025/QH15)が施行され、情報システムを重要度に応じて5段階に分類する枠組みが導入されました。分類は、システムが侵害された場合に国家の安全や社会の秩序、組織・個人の権利にどれだけの損害が及ぶかに応じて決まります。施行細則(政令)の内容によって求められる対策が変わるため、金融や重要インフラに関わるシステムを扱う場合は、公布状況とあわせて現地で確認してください。

ここは専門家の領域なので、記事の記述は公開情報に基づく一般的な整理にとどめます。実際の案件では、個人データを渡す前に法務・専門家へ確認してください。

ISO27001(ISMS)・Pマークの見方——認証は前提条件、評価軸は運用実態

提案書に「ISO/IEC 27001取得」(現行版はISO/IEC 27001:2022)とあると安心しがちですが、認証は「体系的な管理の仕組みを作り、審査を受けている」ことの証明であって、個々の案件が安全であることの保証ではありません。見るべきは3点です。認証の範囲(どの法人・どの拠点・どの事業が対象か)、更新と審査の状況、そして前掲の5層が実際に回っているかどうかです。

私の経験では、認証がなくても「支給端末、個人アカウント、権限の棚卸し、退職時の手続き、事故時の連絡体制」を具体的に説明できる会社は信頼できます。逆に、認証はあるのに「その運用はプロジェクトごとに違います」としか答えられない会社は要注意です。認証の有無で足切りをするのではなく、認証を入口にして運用実態を聞く。これが委託先を見極めるうえでの教訓です。次章では、その「聞くべきこと」をチェックリストの形にまとめます。

発注前チェックリスト20項目と、機密データを海外に出せない案件の設計

ここまでの5層を、発注前に委託先へ投げる質問の形に落とします。20項目すべてに満点の回答が返ってくる必要はありません。大事なのは「即答できるか」「記録を見せられるか」で、言葉を濁す項目があればそこが弱点です。社内の稟議や、顧客企業から求められるセキュリティチェックシートへの回答にもそのまま使えます。

発注前に確認する20項目(契約5・人4・環境4・運用4・法規制3)

20項目のうち、回答が曖昧になりやすいのは2(再委託)、9(交代・離職)、16(ログの確認者)、17(権限剥奪の期限)です。他の解説記事でも「再委託をしている企業」「エンジニアの離職率が高い企業」「実績を開示しない企業」がリスクの高い委託先の特徴として挙げられており、私の実感とも一致します。

機密データを海外に出せない案件は「出さない設計」にする——4つのやり方

どれだけ対策を積んでも、社内規程や顧客との契約上、本番の個人情報を海外に出せない案件はあります。その場合は無理に出さず、出さない設計に切り替えてください。方法は4つです。第1に、データは日本国内に置き、処理や実装だけを委託する。第2に、開発・テストはマスキングしたデータかダミーデータで行う。第3に、本番環境へのアクセス権は日本側の担当者だけが持ち、リリースと障害対応は日本側で実施する。第4に、どうしても本番データを見る必要がある作業は、画面共有や仮想デスクトップ越しに日本側の立ち会いのもとで行う。

この設計にすると、個人データの越境そのものが発生しないか、極めて限定されます。開発のスピードは多少落ちますが、稟議は通ります。対策の強弱は案件のデータ区分で決めるもので、全案件を最高水準にする必要はない、というのが私の持論です。

当社の体制——再委託が構造的に発生しない、日本国内法人・日本法準拠、Gitプルリクエスト

当社の答え合わせもしておきます。当社は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインする形を取っているため、協力会社や紹介経由の仲介が入らず、再委託が構造的に発生しません。チェックリストの2番と9番、つまり再委託とメンバーの入れ替わりについては、誰がどの案件に入っているかを当社が直接把握しています。契約と支払いは日本国内法人・日本法準拠で、海外送金も不要です。

運用面では、日本人PMの設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを品質管理の3点セットとして回しています。クラウドの権限設計やログ設計についてはAWS認定11冠のメンバーが自社で説明できる体制です。介護記録SaaSのCareViewerでは日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、週次で優先順位を判断しながら開発を継続しています。体制は1名から組め、増員は約1週間、縮小と交代は1か月単位です。なお、ISO27001などの認証の取得状況については、個別にご確認ください。

向く案件と向かない案件——対策の強弱は案件のデータ区分で決める

正直に書きます。オフショア開発が向くのは、開発対象が自社サービスや業務システムで、本番データを渡さずに進められる案件、継続的に改修や機能追加がある案件、そして社内に優先順位を判断する担当者を置ける案件です。この条件なら、5層の対策は追加費用をほとんど生みません。

逆に向かないのは、本番の個人情報や機微情報を見ないと作業が成立しない案件、顧客との契約で再委託や国外処理が全面的に禁止されている案件、数週間で終わる単発の作業です。最後のものは、対策の整備に時間を取られて費用対効果が合いません。自社の案件はどちらに近いでしょうか。判断がつかないときは、扱うデータの区分から逆算すると答えが見えてきます。

オフショア開発のセキュリティでよくある質問

セキュリティの相談で繰り返し聞かれる質問を5つにまとめました。社内説明や委託先との初回打ち合わせの前にご確認ください。

Q1. NDAは海外の会社が相手でも有効ですか?

契約としては有効ですが、実効性は準拠法と裁判管轄で大きく変わります。相手が海外法人で現地法・現地裁判所が指定されていると、紛争時の負担は重くなります。日本法人と日本法準拠で契約できるか、エンジニア個人の誓約書まで取っているか、再委託先にも同じ義務が及ぶかの3点を確認してください。

Q2. ISO27001(ISMS)を取得している会社なら安心ですか?

認証は前提条件であって、保証ではありません。認証範囲がどの法人・拠点・事業までかを確認し、そのうえで支給端末・個人アカウント・権限の棚卸し・退職時の手続き・事故時の連絡体制という運用実態を質問してください。認証がなくてもこれらを具体的に説明できる会社はあります。

Q3. ソースコードの流出はどう防げばよいですか?

Gitのリポジトリ権限を個人単位で最小化し、プルリクエストとレビューを必須にしたうえで、マージできる人を限定します。加えて、支給端末に統一してローカルのクローンを管理し、離任時には最終稼働日にアカウントを停止する手順を決めておくことです。契約では成果物と著作権の帰属時期を明記します。

Q4. 個人情報を含むデータを海外の委託先に渡してよいですか?

渡せないわけではありませんが、日本の個人情報保護法28条(外国にある第三者への提供の制限)の要件と、委託先国の法制への対応が必要です。実務上は、本番データを渡さずマスキングしたデータで開発し、本番環境へのアクセスは日本側に限る設計のほうが早く安全です。個別の可否は法務・専門家にご確認ください。

Q5. 再委託の有無はどう確かめればよいですか?

契約書の再委託条項を確認したうえで、「今回の案件に入るメンバーは全員貴社の所属か」「協力会社やフリーランスは含まれるか」を具体的に質問してください。当社は2,000名以上の人財データベースから直接アサインするため再委託が発生しない構造で、契約は日本国内法人・日本法準拠、体制は1名から、交代は1か月単位での対応。

まとめ: リスクは6類型、対策は5層、委託先は運用実態で選ぶ——出せないデータは出さない設計に

オフショア開発のセキュリティリスクは、機密情報・個人情報の漏えい、ソースコードの流出、不正アクセス、再委託先からの漏えい、退職者や交代メンバーの持ち出し、法規制への抵触の6類型に整理できます。村田製作所(2021年)も、ベネッセ(2014年)も、「正規の権限を持つ委託先の人が、監視の穴から持ち出した」という同じ構造でした。危ないのは海外という場所ではなく、権限・端末・ログ・契約の緩さです。

対策は、契約・人・環境・運用・法規制の5層で組んでください。契約では再委託の制限と知財の帰属、準拠法と管轄、事故時の報告期限を決める。人ではエンジニア個人の誓約と教育。環境では支給端末への統一と、本番データを渡さない設計。運用では個人アカウント、Gitのプルリクエスト、ログの定期確認、離任時の権限剥奪。法規制では日本の個人情報保護法25条・28条と、ベトナムの個人データ保護法(2026年1月1日施行)・2025年サイバーセキュリティ法(2026年7月1日施行)の要件を押さえます。ISO27001などの認証は入口の前提条件で、評価軸はあくまで運用実態です。発注前チェックリスト20項目のうち、再委託・メンバーの交代・ログの確認者・権限剥奪の期限に即答できるかを見てください。

当社は2,000名以上のIT人財データベースから直接アサインするため再委託が構造的に発生せず、契約と支払いは日本国内法人・日本法準拠、開発は日本人PMの設計レビューとGitのプルリクエストによるコードレビューを標準化しています。一方で、本番の個人情報を海外に出せない案件では、データを国内に置いてマスキングしたデータで開発する「出さない設計」をお勧めしています。関連してオフショア開発の失敗パターンと業務委託契約の再委託もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、どこまでの対策が必要かの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。