海外子会社への技術データ提供と外為法対応

１　事案の概要

IT・ソフトウェア開発企業から、海外開発拠点との技術データ共有について相談を受けた事例です。

同社は、ベトナムとインドに開発子会社を持ち、日本本社と海外拠点の間で、ソースコード、設計資料、暗号関連技術、仕様書、開発ノウハウなどを日常的にやり取りしていました。また、日本人エンジニアが現地へ出張し、海外子会社のエンジニアに対して設計思想や実装方法を指導することもありました。

ところが、同社の担当者が参加したセミナーで、「海外子会社へのメール送信やクラウド共有も、外為法上の技術提供として許可が必要になる場合がある」と聞き、これまでの運用が法令違反に当たるのではないかと不安になり、相談に来られました。

 ２　海外子会社へのメール・クラウド共有も「技術提供」になり得る

外為法上の輸出管理は、物を海外へ送る場合だけの問題ではありません。一定の技術を外国で提供する取引、非居住者に提供する取引、電子データを外国へ送信する行為なども、規制対象となり得ます。

経済産業省の資料では、技術提供の例として、メール、電話、Web会議システム、クラウドサービス等が挙げられています。また、技術とは、貨物の設計・製造・使用に必要な特定の情報をいい、技術データまたは技術支援の形態により提供されるものとされています。

そのため、「同じグループ会社だから自由に送ってよい」「相手は子会社だから輸出ではない」「メールやクラウドなので物の輸出ではない」と考えるのは危険です。

特に、海外子会社にクラウド上の技術データへのアクセス権を付与する場合には、海外子会社への技術提供として外為法上の確認対象になります。クラウドサービスに関する解説でも、海外子会社にアクセス権を付与して技術等のやり取りを行う場合、海外子会社への技術提供となり、外為法25条の対象となるとされています。

 ３　相談時点での主なリスク

同社では、開発現場のスピードを優先し、海外子会社との技術共有がエンジニア主導で行われていました。法務部門や輸出管理担当者による事前確認は限定的で、過去に送信したデータの範囲も一元管理されていませんでした。

 ４　弁護士の対応1：現状のリスク診断

まず、過去の技術提供の実態を把握するため、メール送信履歴、共有サーバーのアクセスログ、クラウドストレージの権限設定、技術資料の分類、海外出張時の指導内容を確認しました。

調査では、次の観点からリスクを整理しました。

安全保障貿易管理では、輸出や技術提供を行う前に、該非判定、取引審査、出荷・提供管理を行うことが基本です。経済産業省の資料でも、輸出管理の流れとして、該非判定、取引審査、出荷管理が示されています。

調査の結果、同社が扱う技術の多くは汎用的なソフトウェア開発情報でしたが、一部に暗号機能やセキュリティ関連の技術が含まれ、リスト規制該当性を慎重に検討すべきものがありました。

 ５　弁護士の対応2：過去分の整理と自主申告

過去の技術提供については、リスクの高いデータを抽出し、提供先、提供時期、提供方法、技術内容を整理しました。そのうえで、法令違反のおそれがあるものについて、当局への相談・自主申告の要否を検討しました。

外為法等に違反した場合または違反のおそれがある場合には、速やかに報告し、再発防止措置を講じることが輸出管理内部規程上も重要な要素とされています。経済産業省の資料でも、輸出管理内部規程において、違反時の報告・再発防止、子会社等への指導、教育、文書管理などが主要項目として位置付けられています。

本件では、一部の技術提供について許可要否の検討が不十分だったことが確認されたため、過去分を整理したうえで自主的に事情を説明しました。その結果、悪質な隠蔽や故意の無許可提供ではなく、社内体制未整備による管理不足と評価され、再発防止策の実施を前提に、指導レベルで収束しました。

 ６　弁護士の対応3：特別一般包括許可の取得支援

次に問題となったのは、今後の開発体制です。

海外子会社との技術データ共有のたびに個別許可申請が必要となれば、開発スピードが大きく落ちてしまいます。そこで、同社には、一定範囲の取引について個別申請を不要にできる包括許可制度の活用を提案しました。

包括許可制度は、リスト規制により経済産業大臣の許可が必要となる場合でも、一定の範囲の取引について一括して許可を行う制度です。包括許可が適用できる場合、有効期限内であれば個別の許可申請は不要となります。ただし、キャッチオール規制には適用できず、輸出管理内部規程の届出等、一定の要件を満たす必要があります。

同社の取引実態を踏まえ、特別一般包括許可の取得を目指すことにしました。特別一般包括許可は、非ホワイト国向けを含む一定の仕向地・品目の組み合わせについて、貨物・技術の機微度が比較的低いものを包括的に許可する制度とされています。

 ７　弁護士の対応4：輸出管理内部規程（ICP）の策定

特別一般包括許可を取得するためには、輸出管理内部規程（ICP）の整備が重要になります。

輸出管理内部規程とは、輸出や技術提供に関する一連の手続を定め、安全保障貿易管理関係法令を遵守し、違反を未然に防ぐための内部規程です。経済産業省への届出制度があり、規程の内容が適切であれば受理票が発行されます。また、CP受理票が発行されている者は、毎年7月に輸出者等概要・自己管理チェックリストを提出する必要があり、適切な管理が実施されていれば包括許可制度を活用できます。

本件では、同社の業務実態に合わせて、ソフトウェア開発企業向けのICPを一から整備しました。

特別一般包括許可の申請者には、輸出管理内部規程の整備、CP受理票・チェックリスト受理票の交付、実施状況調査、内部審査実績などが要件として求められます。

そのため、単に規程文書を作るだけではなく、実際に運用できる承認フロー、記録様式、チェックリスト、監査手順まで整備しました。

 ８　弁護士の対応5：エンジニア向け研修と運用定着

包括許可は、取得すれば終わりではありません。許可条件に従った運用、記帳管理、用途・需要者確認、社内監査、教育が継続的に必要になります。

そこで、弁護士が講師となり、エンジニア、プロジェクトマネージャー、海外拠点担当者向けの社内研修を実施しました。

研修では、法律用語だけを説明するのではなく、日常業務で起こりやすい場面に落とし込みました。

特に重視したのは、「開発を止めるための規制」ではなく、「安心して海外開発を続けるための手続」として理解してもらうことです。

 ９　解決結果

同社は、ICPの整備、社内フローの構築、当局対応、必要書類の整備を経て、特別一般包括許可を取得しました。

その結果、対象範囲内の海外子会社への技術提供について、都度の個別許可申請を行わずに運用できるようになり、開発スピードを落とさずにコンプライアンスを確保する体制が整いました。

さらに、輸出管理体制を整備したことで、同社は大手クライアントからのセキュリティ・コンプライアンス審査にも対応しやすくなりました。結果として、海外開発体制を維持しながら、受託開発案件の拡大にもつながりました。

 １０　弁護士のコメント

IT・ソフトウェア企業では、技術のやり取りが日常業務に溶け込んでいます。メール、チャット、クラウド、Gitリポジトリ、Web会議、画面共有、現地指導など、あらゆる場面で技術提供が発生し得ます。

特に海外子会社とのやり取りは、「グループ内だから大丈夫」と考えられがちですが、外為法上は、子会社であっても海外にいる非居住者に対する技術提供として許可要否を確認する必要があります。

もっとも、輸出管理は、必ずしもビジネスのブレーキではありません。包括許可制度を適切に活用し、ICPを整備すれば、適法性を確保しながら、海外開発のスピードを維持することができます。

重要なのは、エンジニアに過度な負担をかけることではなく、日常業務の中で自然にチェックと記録が残る仕組みを作ることです。法務・輸出管理部門が現場を止めるのではなく、現場が安心して開発を進められるようにすることが、実効的なコンプライアンス体制の目的です。

この記事と関連するコラム