【オフショア開発】「海外だから関係ない」は逆です。サイバー対処能力強化法の影響は国境を越えます

    2026/7/24

    この記事の著者

    代表取締役社長CEO

    金築 敬晃

    2025年5月に成立した、いわゆる「サイバー対処能力強化法」(正式名称:重要電子計算機に対する不正な行為による被害の防止に関する法律)の官民連携部分が、2026年10月に施行されます。直接の義務を負うのは、経済安全保障推進法に基づいて指定された基幹インフラ15分野・257者の「特定社会基盤事業者」です。名前を見るかぎり、ベトナムやフィリピンで開発チームを回しているオフショア開発の現場には縁遠い法律に思えるかもしれません。

    しかし、この法律の効き方を丁寧に追うと、影響はむしろ委託構造の末端に向かって流れていくことがわかります。指定事業者に課されるのは「自社システムの届出と報告」ですが、そのシステムを実際に開発し、運用しているのは誰でしょうか。

    金融、通信、電力といった基幹インフラの周辺システムの開発が、国内SIerを経由してオフショア拠点に流れているケースは珍しくありません。本稿では、オフショア開発の発注側・受託側それぞれの視点から、この法律が「案外他人事ではない」理由を整理します。

    法律のおさらい:届出とインシデント報告が義務になります

    指定された特定社会基盤事業者に、強化法は大きく2つの義務を課します。1つは、基幹業務に関わる情報システムのうち「特定重要電子計算機」に該当するものについて、ベンダー名や製品情報などのシステム資産を政府に届け出ること。

    もう1つは、サイバー攻撃を受けた際のインシデント報告です。届出義務に違反して監督官庁の是正命令に従わない場合は200万円以下の罰金、資料提出などの求めに応じない場合は30万円以下の罰金が規定されています。

    報告は二段階です。インシデントを認知したら速やかに「速報」を出し、30日以内に「詳報」を提出します。報告対象は不正アクセスなどの「特定不正行為」の痕跡だけでなく、それに繋がる事象、つまり予兆段階も含まれます。

    また、SaaSや(ミドルウェア・OSに係る)PaaSの場合は、クラウド事業者から通知があった時点で「認知」とみなされる設計です。

    ここで注目したいのは、届出の対象範囲です。社会システムを担う特定重要設備だけでなく、サイバー攻撃を受けると設備の停止や機能低下につながる周辺機器も届出・報告の対象に含まれます。そして専門家からは、システムの構成によっては対象機器の運用の委託先が保有する機器も該当しうること、基幹インフラ事業者と取引している企業にも間接的に波及する可能性が指摘されています。

    なぜオフショア開発に波及するのか:3つの経路

    経路1:届出書類に「あなたの会社」が載る

    届出には、特定重要電子計算機のベンダー名や製品情報が含まれます。指定事業者のシステム開発を国内SIerが受注し、その開発実務をオフショア拠点や海外パートナー企業が担っている場合、委託構造そのものが政府への説明対象になりえます。

    これは経済安全保障推進法の事前審査制度からの地続きの話で、同法の枠組みでは、金融機関の基幹システム開発を海外のオフショア拠点に業務委託するようなケースは導入前の審査で厳しくチェックされることが以前から予想されていました。強化法の施行は、この「委託構造の可視化」を導入時だけでなく運用フェーズにまで広げるものと捉えるべきです。

    経路2:「認知」の起点が委託先になる

    インシデント報告の時計は「認知」から動き出します。そして基幹システムの運用や保守を委託している構造では、異常に最初に気づくのは委託先、つまりオフショア側の運用チームであることが少なくありません。

    ベトナムの深夜帯に検知されたアラートが、現地チームの判断で「様子見」になり、日本側への報告が翌営業日の定例まで持ち越される、つまり平時なら許容されてきたこの運用が、施行後は発注元の法定報告期限を直接脅かします。時差、言語、そして「これは報告すべき事象か」の判断基準のズレ。オフショア開発が本質的に抱えるコミュニケーションの摩擦が、そのまま法令遵守上のリスクに変換されるのです。

    経路3:選定から外れるリスク

    近年、サイバー防御が比較的手薄な取引先企業を踏み台にして大企業を狙う「サプライチェーン攻撃」が増加しており、中小規模のベンダーやサービスプロバイダーが標的になる傾向が指摘されています。

    この前提に立てば、指定事業者やその一次請けが、インシデント通知体制を説明できないオフショアベンダーを選定から外していく流れは自然な帰結です。日経クロステックが「取引先から排除のリスク」と報じたのは、まさにこの構図です。

    オフショアならではの急所:「通知の受け口」と再委託の深さ

    金融機関やカード会社にとっての急所が委託構造の深さであるのと同様に、オフショア開発の急所は、その構造が国境と言語をまたぐことです。具体的に点検すべきポイントを挙げます。

    • 契約の通知条項

      委託契約やSLAに、セキュリティインシデント・その予兆を検知した際の通知義務、通知期限(「速やかに」ではなく時間で)、通知先、通知言語が定められているか。ラボ型契約で現地に検証環境や運用端末を置いている場合、それらの機器で起きた事象も通知対象に含まれているか。再委託がある場合、同等の条項が再委託先まで貫通しているか。

    • 時差を織り込んだエスカレーション設計

      「認知から速報まで」の時計は日本の制度で動きます。現地の夜間・休日に検知された事象を、誰が、何時間以内に、日本側のどの窓口に届けるのか。通知先が退職者のメールアドレスや、返信のない共有アドレスのままになっていないか。地味ですが、報告義務を果たせるかどうかは事実上ここで決まります。

    • 報告様式の言語ギャップ

      2025年10月からはDDoS攻撃やランサムウェアに関する統一報告様式の運用が先行して始まっており、報告受付システムの一元化も進められる予定です。

      当然ながら様式は日本語です。現地チームの英語のインシデントレポートを、期限内に日本の様式へ正確に変換する役割を、平時のうちに決めておく必要があります。「機密情報」や「インシデント」の定義ひとつとっても日本と海外で認識ギャップが生じることは、セキュリティ実務では以前から指摘されてきた点です。

    もうひとつの急所:マルチクライアント構造の「責任分界」と「影響範囲」

    オフショア開発企業の実態に、もう一歩踏み込みます。多くのオフショア開発企業は、複数のクライアントの案件を同時並行で回しています。

    ラボ型で専任チームを分けていても、オフィス、ネットワーク、認証基盤、CI/CD環境、社内の情報システムといったレイヤーでは、案件をまたいで共有されているものが少なくありません。この構造には、強化法の時代に表面化する2つの弱点があります。

    1つ目は、クライアント側で何かが起きたときに、自社の責任範囲を即答できるかという問題です。あるクライアントのシステムでインシデントが検知されたとき、発注元から最初に飛んでくる質問は「御社の作業範囲・アクセス権限はどこからどこまでか」「御社側の環境が原因の可能性はあるか」です。

    契約書上の業務範囲、実際に付与されているアクセス権、現地メンバーが触れる環境の一覧が案件ごとに整理されていなければ、「調べます」から数日かかることになります。しかし前述のとおり、発注元の速報の時計はすでに動いています。責任範囲の線引きが曖昧なまま時間が経つほど、疑いは委託先に向かい、原因ではなかったとしても「説明できなかった」という事実だけが残ります。

    2つ目は逆向きで、自社起因のインシデントが起きたときに、どの案件まで影響が及ぶかを即座に特定できるかという問題です。社内の開発端末がマルウェアに感染した、共有の認証基盤が侵害された、退職者のアカウントが残っていたとき「その端末・アカウント・環境から、どのクライアントのどのシステムに到達できたか」を答えられなければ、影響範囲は論理的に「全クライアント」になります。

    実際には1案件で閉じていたとしても、案件ごとの資産・アクセス経路のマッピングがなければそれを証明できず、全クライアントへの通知と、複数の発注元それぞれの法定報告フローを同時に走らせる事態になりかねません。

    どちらも、平時にやることは同じです。案件ごとに、担当メンバー、貸与・持込機器、アクセス権限、共有している基盤を台帳化し、変更のたびに更新する。強化法が指定事業者に求める「特定重要電子計算機の棚卸しと届出」のミニチュア版を、受託側も案件単位で持っておく、と考えるとわかりやすいでしょう。発注元から届出のための情報提供を求められたとき、この台帳がそのまま回答になります。

    発注側・受託側、それぞれの施行前チェックリスト

    発注側(国内SIer・事業会社)がまずやるべきは、案件の棚卸しです。自社が受けている案件の発注元を遡ったとき、特定社会基盤事業者に行き着くものはどれか。その案件のうち、オフショアに出している範囲はどこまでか。

    該当案件については、契約の通知条項と実際のエスカレーション経路を突き合わせ、ギャップを埋めます。そのうえで、現地チームからの障害・侵害通知を受けて日本側の報告判断が動く訓練を、一度でいいので回してみることです。訓練をすると、通知テンプレートがない、翻訳に3時間かかる、日本側の判断者が深夜に捕まらない、といった具体的な穴が必ず見つかります。

    受託側(オフショア開発企業)にとって、この法律は脅威であると同時に差別化の機会です。インシデント検知から日本側への通知までのフローを文書化し、通知SLAを契約でコミットできる体制は、施行後の日本市場では明確な営業資産になります。逆に、ここを説明できないベンダーは、単価やスキルの勝負以前に候補から外れていきます。セキュリティ意識の高い委託先が日本や欧米の案件を獲得するために対策と教育に注力する傾向はすでに現れており、強化法はこの選別を制度面から加速させることになるでしょう。

    共通して効いてくるのが、記録の一元化です。強化法の速報・詳報に加え、個人情報保護委員会への報告、発注元経由での監督当局報告、契約上の顧客通知と、報告先は増える一方です。現地チームのチャットログ、検知時刻、対応の時系列を「一度記録すれば各報告に展開できる」形で残す仕組みがあるかどうかで、有事の負荷は桁違いに変わります。

    そこでIncident Lake

    ここまで見てきたとおり、オフショア開発が絡むインシデント対応の難所は、国境と言語をまたいだ「認知から報告まで」の速度、そして複数クライアントを抱える構造の中で「責任範囲と影響範囲」を即座に切り分ける力です。

    現地で検知された異常を、時差を越えて日本側の報告判断に乗せ、どの案件・どのクライアントに影響が及ぶかを特定し、期限付きの速報・詳報に、矛盾なく展開していく。この一連の流れを人手とチャットの往復だけで回すのは、正直なところ限界があります。

    Incident Lakeは、この流れを支えるインシデント管理プラットフォームです。インシデント発生時の報告から復帰までの対応、レポートの作成や管理までを自動化し、現地と日本、双方の担当者が本来集中すべき「被害を止め、サービスを復旧させること」に時間を使えるようにします。

    速報・詳報という期限付きの報告制度が動き出す今だからこそ、国境をまたぐ報告と記録の仕組みを、人の頑張りに頼らない形に変えておくことをおすすめします。

    なお、法律の細部は施行までに政省令や運用ルールで詰められていく部分が残っています。最新の情報は、内閣府(サイバー安全保障担当・経済安全保障担当)および各監督官庁の公表資料でご確認ください。


    参考資料

    この記事の著者

    代表取締役社長CEO

    金築 敬晃

    株式会社SIGQ 代表取締役

    筑波大学大学院修了、専門はデータベースと分散システム。
    AI時代に必須となる、運用データという非構造化・リアルタイムな情報を扱うエンジニア。
    新卒で株式会社マネーフォワードに入社。ベトナム拠点への出向を含め、海外を含む開発現場でマネジメントや開発に従事。
    2022年に株式会社プレイドに入社し、Platform Engineeringを担当。大規模分散データシステムの開発に携わる。
    2024年に株式会社SIGQを設立。

    この記事をシェア

    facebookシェアボタンXシェアボタン
    keyboard_backspace

    お役立ち記事一覧