讓外國人透過網路使用GPU，算不算「出口」？美國RASA法案，以及日本法制是否有同樣的空缺

大家好，我是TIMEWELL股份有限公司的濱本 隆太。

前陣子有位負責出口管制的朋友問了我一個問題，後來我一直放在心上。「晶片要運出國境，我們卡得那麼嚴。可是人在海外，直接透過網路連線來用同一批晶片，為什麼就沒人管得住？」

這個疑問很合理。而且愈往下查會發現，這件事並不只是美國的問題。在國內興建資料中心、把運算資源賣給海外客戶，如今是真實而且正在成長的生意。

先講結論：單純出租運算能力這件事，在美國與日本的制度下都不屬於出口管制的對象。 但這絕不等於「雲端完全沒人管」。哪裡是空缺、哪裡開始受管，其實有一條相當清楚的線。以下就沿著條文把這條線描出來。

本文重點

• 美國EAR對「出口」的定義（15 CFR §734.13）要求「物品移動」或「技術、原始碼被揭露」。讓機器跑運算兩者皆非
• 這並非解釋空間的問題。美國商務部BIS早在2009年就以書面答覆：提供運算能力不受EAR規範，業者甚至沒有查驗客戶國籍的義務
• RASA兩度通過眾議院，兩度卡在參議院，至今未完成立法
• RASA並不修改「出口」的定義。 它另立一個平行的管制類型「遠端存取」，這一點被大量報導寫錯
• 日本也有同樣的空缺。關鍵在於「貨物即動產」的定義，而伺服器不會移動
• 但架在運算資源之上的軟體如屬管制技術，仍會該當。日本的役務通達早已將雲端儲存與SaaS分開處理
• 報導所指的第三國安排，依現行法規並不違法。寫成「規避」或「違反」與事實不符

美國EAR為什麼管不到

「出口」的定義裡沒有運算的位置

美國EAR在15 CFR §734.13定義「出口」¹，共有三種類型：實際運送或傳輸至美國境外；向身處美國境內的外國人揭露「技術」或原始碼（即推定出口）；以及移轉特定太空載具的登記、控制或所有權。

三者都要求物品跨越國境，或技術被揭露給某個人。讓GPU執行運算，兩者都不成立。

值得一提的是，這個定義自2016年6月修訂後從未更動。也就是說，專為AI晶片新設的ECCN 3A090、4A090問世之前的條文，一直沿用至今。

推定出口有雙重限制

接下來自然會想：讓外國人使用，算不算推定出口？這裡有兩道限制。

客體的限制。 對象只有「技術」與原始碼。條文甚至特意寫明「but not object code」（不包含目的碼）。出租GPU，技術與原始碼都沒有交出去。

地點的限制。 該類型要求外國人身處「in the United States」。從深圳透過網路連線使用的人，在文義上根本不在射程內。

再補一層：§734.15將「release」定義為外國人以目視等方式檢視技術或原始碼，以及與外國人之間的口頭或書面交流。這是為了捕捉「把晶片的技術訣竅給人看」，而不是「讓晶片去算數」。

常見誤解：「§734.18有雲端排除條款」

這是誤讀。§734.18(a)(5)所講的是，把自己的技術或軟體在符合非機密、端對端加密、使用符合FIPS 140-2標準的模組、且不刻意儲存於特定國家等條件下傳送與保管，不視為出口。這是「把自己加密過的資料放在境外」的問題，不是「借用運算能力」的問題。

§734.18全文中根本沒有出現過「cloud」一詞。BIS自己也在公開場合說明過，法規文字並未使用這個詞。

決定性依據來自BIS自己

以上都還是條文的讀法。但這個議題其實有更直接的依據：BIS在2009年1月13日的解釋函中正面回答過²。

問題一的答覆是核心：

The service of providing computational capacity would not be subject to the EAR as the service provider is not shipping or transmitting any commodity, software, or technology to the user. （提供運算能力的服務不受EAR規範，因為服務提供者並未向使用者運送或傳輸任何貨品、軟體或技術）

問題五更進一步：

the service provider is not required to inquire about the nationality of the customer. （服務提供者無須查詢客戶的國籍）

連查驗義務都沒有。 這份文件至今仍列於BIS的解釋函索引中，並未撤回。2011年與2014年的後續解釋函也採相同立場。

為求精確，有一個例外必須寫出來。同一份答覆的問題二指出，即使服務本身不受EAR規範，若明知該服務將協助§744.6(a)(2)所列的活動，該條規定仍可能適用。不過§744.6(a)(2)涵蓋的是飛彈與生化武器相關活動，先進運算與AI並不在內。

BIS曾在聯邦公報承認這個空缺，並把處理往後推

2023年10月25日的聯邦公報中有一段耐人尋味的往來³。

有意見提出者主張IaaS可能使超級電腦管制失效，並要求BIS依2009年與2011年的解釋函闡明立場。BIS的答覆是：

BIS is also concerned regarding the potential for China to use IaaS solutions to undermine the effectiveness of the October 7 IFR controls and continues to evaluate how it may approach this through a regulatory response. （BIS同樣關切中國可能利用IaaS削弱2022年10月7日暫行規則管制的實效，並持續評估如何以法規方式因應）

在被直接給了否認舊解釋函的機會時，BIS並未否認。 同一份規則裡，BIS還向外界徵詢「需要哪些額外的管制或要求」，這個提問本身就以「現行規範管不到」為前提。

美國國會的認知也一致。眾議院中國共產黨問題特別委員會在2026年4月的報告中寫得很直白⁴：

And restrictions on accessing such chips through the cloud are non-existent. （而對於透過雲端存取這類晶片的限制，並不存在）

RASA究竟是什麼

試圖填補這個空缺的，就是RASA（Remote Access Security Act）。不過這個法案的實際樣貌，和外界的普遍描述差距不小。

事實經過

屆期	法案	提案人	提案日	眾院院會	現況
第118屆	H.R. 8152	Lawler眾議員（共和黨、紐約17區）	2024年4月29日	2024年9月9日通過（口頭表決）	於參院銀行委員會屆期不續審
第119屆	H.R. 2683	Lawler眾議員（共和黨、紐約17區）	2025年4月7日	2026年1月12日通過（369比22）	於參院銀行委員會待審
第119屆（參院版）	S. 3519	McCormick參議員（共和黨、賓州）	2025年12月17日	無	付委後無進展

眾議院兩度通過，兩度卡在參議院，至今未完成立法。 2026年1月的記名表決中，共和黨167票贊成、22票反對，民主黨202票贊成、0票反對。22張反對票全部來自共和黨。

被誤解之一：「出口」的定義並未改變

許多解說寫道「RASA將遠端存取視為出口」。這個說法並不準確。

RASA修正的是2018年《出口管制改革法》（ECRA），但它完全沒有動到「export」的定義。取而代之的是另立一個平行的管制行為類型「remote access」，並將其橫向插入總統的管制權限、追加權限、許可、罰則與執行等各條文之中。

眾院通過版的定義條文如下⁵：

the term 'remote access' means access on a purposeful, knowing, reckless, or negligent basis to an item subject to the jurisdiction of the United States under this Act by a foreign person through a network connection, including the internet or a cloud computing service, from a location other than where the item is physically located if the Secretary determines that the use of the item could pose a serious risk to the national security or foreign policy of the United States.

把雲端業者本身也納入射程的，是插入權限條文的一句「or remotely access（including the provision thereof）」。不只是伸手存取的一方，提供門路的一方也被涵蓋。

這個差別在實務上是有意義的。既然是另立類型而非擴張既有概念，現行的許可例外與適用除外就未必能直接沿用。

被誤解之二：對象並不限於「疑慮國家」

另一種常見說法是「RASA針對中國、俄羅斯、伊朗、北韓」。眾院通過版並非如此。

	對象品項	對象人	風險要件
2024年通過版	CCL列管品項，不問實體所在地	any foreign person	列舉式
2026年通過版（現行）	ECRA管轄下的品項	any foreign person	概括式「可能造成重大風險」＋主觀要件
參院版S.3519（未審）	CCL列管品項	僅限有疑慮的外國人（中國、香港、澳門等）	列舉式＋「已具體顯現」

有國別限定的只有參院版。 眾院通過版寫的是「a foreign person」，沒有任何國別限制。

比較麻煩的是，2026年1月12日眾院院會上，議員本人的說明是「有疑慮的外國人，具體而言包括俄羅斯、伊朗、北韓與中國（含香港、澳門）」。但通過的條文並沒有這樣寫。議事錄的說明與通過條文互相矛盾，而許多二手報導原封不動地複製了這個錯誤。 要確認射程時，請務必以通過的條文為準。

另外補充一點：2024年通過版中「不問實體所在地」這句話，也就是明示連位於美國境內資料中心的晶片都涵蓋在內的文字，在2026年通過版中已經拿掉了。

反對意見在哪裡

老實說，留在紀錄上的有組織反對意見幾乎不存在。委員會表決51比0，院會369比22且民主黨零反對，兩屆院會都沒有議員上台發言反對。

那是不是就沒人擔心？並非如此。擔憂並未出現在發言中，而是出現在草擬的歷程裡。 這個法案每動一次，範圍就窄一次。

• 2024年的院會修正，把帶有概括條款的寬鬆定義，換成與CCL連結並採列舉式風險
• 2026年的院會修正，加入主觀要件、保留不降低刑事責任舉證標準的但書、把概括條款換成須由部長認定，並新增就對美國經濟之影響向國會提出報告的條文
• 參院版在每個面向上都更窄：限於有疑慮的外國人、將IaaS定義綁定NIST SP 800-145、設有十年落日條款，並在報告義務中明文要求「最大化隱私保障、最小化遵循成本」

真正的核心關切，是一個延續約二十年的前提被翻轉。 雲端業者是依據2009年那份解釋函建立內部制度的。BIS曾以書面告訴他們「不受規範」「無須查驗國籍」。RASA把這個前提反了過來。

該怎麼讀近期的報導

2026年以來，關於中國企業透過第三國資料中心使用Nvidia運算資源的報導接連出現。在處理這個題目時，有一點必須先弄清楚。

依現行美國法規，這並不違法。

多位專家如此表示，報導本身也寫明這是「目前並不違法的活動」。美國出口管制的對象是實體晶片，並未涵蓋遠端存取，這正是前述條文推導出的結果。

因此，把這件事寫成「規避」「鑽漏洞」「違反」是與事實不符的。準確的說法是「落在制度射程之外」「現行法規未及」。我們在自家的文章與資料中也徹底採用這個表述。

以實務工作者的立場，還想補充兩點。

應避免以個別公司為主詞的斷定。 報導內容多半來自匿名消息來源，既沒有確定的違法事實，也沒有處分。美國政府亦未在正式紀錄上確認任何具體內容。居間業者已具名表明「完全遵循所有適用法規」；被點名的企業當中，有的僅就特定一點提出否認，有的拒絕評論，也有的根本未公開回應。沉默既不是否認，也不是承認。

流通的數字同樣需要附上保留。 常見的說法是「將使中國取得的運算資源增加約60%」，但讀原文會發現，作者本人明確寫道：這是一個跨度超過一個數量級的區間的下限，若改變美國許可政策的假設則會變成約四倍，而且「包括美國政府在內，沒有人知道實際數字」。只截取60%這個數字，就會變成誤傳。

日本有同樣的空缺嗎

接下來才是重點。把位於日本國內的GPU或資料中心，透過雲端讓非居住者使用，這在日本《外匯及外國貿易法》下需要許可嗎？

原則上不需要。 以下用條文文字說明理由。

不構成「貨物的出口」

該法第48條第1項就「貨物的出口」要求許可。關鍵在於定義：

第6條第1項第15款　所稱「貨物」，指貴金屬、支付手段及表彰債權之證券以外之動產⁶

伺服器始終留在國內，完全沒有動產跨越國境的情形。分析到這裡就停住了。

也不構成「特定技術的提供」

第25條第1項的對象是「與貨物之設計、製造或使用有關的技術」。那麼什麼是「技術」？有意思的是，貨物等省令與外匯令都沒有一般性定義，定義放在經濟產業省的役務通達裡⁷：

所稱技術，指貨物之設計、製造或使用所必要之特定資訊。該資訊以技術資料或技術協助之形態提供。

技術資料指設計圖、規格書、手冊、程式等；技術協助指技術指導、技能訓練、工作知識之提供、顧問服務等。

出租運算資源所提供的是「運算能力這項效益」，既非技術資料，也非技術協助。 外匯令第17條的附表全部16項，一律採「輸出貿易管理令別表第一第◯項中欄所列貨物之設計、製造或使用有關之技術」的形式，一貫地與貨物綁定。並不存在捕捉「與貨物無關的能力提供」的項目。

役務交易與電信條文也都不該當

第25條第5項所指、由政令指定的役務交易，只有礦產物之加工或貯藏、經輻射照射之核燃料物質之分離或再生、放射性廢棄物之處理三種類型（外匯令第18條第1項）。運算資源不在其中。

捕捉網路連線的條文是第25條第3項，但其對象是「以特定技術為內容之資訊之傳送」，而非「透過網路讓人執行運算」。而且還限定於「自位於日本國內之電信設備所為之傳送」。非居住者把自己的資料送到日本的伺服器處理後再取回結果，方向與該條規範所預設的正好相反。

通達早已把「保管」列為原則不該當

役務通達的附件1-2，明確把雲端分成兩種類型處理。

關於儲存服務，只要契約目的僅限於為自己使用而保管資訊，通達即認定即使特定技術保管於設置在國外的伺服器，原則上仍不該當役務交易、無須許可。既然保管在國外伺服器都原則不該當，那麼資料留在日本國內伺服器、只是讓人執行運算的形態，就更不可能從現行解釋推導出該當的結論。

但確實存在會該當的情形

這裡是最重要的部分。即使運算資源的提供本身不該當，架在其上的東西如屬特定技術，就會該當。

一、以SaaS形式提供的程式屬於特定技術時。 附件1-2(2)明文指出，將伺服器上的程式在不需下載的狀態下供人使用的服務，屬於以提供為目的之交易。「我們沒讓對方下載」不能當免死金牌。役務通達將「提供」定義為「置於他人可利用之狀態」，也就是說，在置於可利用狀態的那一刻，提供即已成立。把管制對象程式預先安裝在GPU雲端上供非居住者使用，正是典型案例。

二、明知可檢視、取得或利用客戶的特定技術仍簽約時。 附件1-2(1)的但書明文規定，此種情形「視為」以提供該特定技術資訊為目的之交易。

三、支援或調校構成「技術協助」時。 技術指導與工作知識的提供，本身就是技術的提供。

四、工程師向非居住者傳送技術資料時。 這與雲端無關，是隨時都存在的問題。

也就是說，空缺僅存在於「運算資源本身」，而不是整個雲端。「日本的雲端無人管」這種理解是錯的。

推定出口制度並不能堵住這個缺口

那麼2022年5月施行的日本「推定出口」明確化措施呢？堵不住。 理由有三，全部出自通達文字。

第一，特定類型明文限於「屬自然人之居住者」。推定出口是把「向居住者提供」擴張為「向非居住者提供」，對象是身處日本國內的自然人。非居住者原本就由第25條第1項本文所涵蓋，輪不到推定出口出場。

第二，該次擴張的是相對人的屬性，並未擴張提供的客體。客體始終是特定技術。既然運算資源不是特定技術，無論對象是誰都不會該當。

第三，役務通達全文從未出現「遠端存取」或「運算資源」。

推定出口是堵「人」的缺口的制度，不是堵「運算資源」缺口的制度。

順帶一提，特定類型的內容本身也常被誤解。三種類型分別是：依與外國法人等或外國政府等所訂契約而受其指揮命令、或負善良管理人注意義務者；自外國政府等取得相當於年所得25%以上之利益者；以及就在日本國內之行動接受外國政府等指示或委託者。若以「受外國政府控制之人」這種粗略理解來運作，判定一定會出錯。

日本的經濟安全保障推進法也未涵蓋

也有人問「基礎設施的事前審查會不會看到雲端」。這裡一併確認。

經濟安全保障推進法第50條第1項所定的特定社會基礎事業，共有電力、瓦斯、石油、自來水、鐵路、貨運汽車運送、遠洋貨運、港灣運送、航空、機場、電信、廣播、郵政、金融、信用卡等15個領域。並沒有相當於雲端或資料中心的事業區分。

或許有人會想「電信事業應該涵蓋得到」，但實質上並不涵蓋，理由有二。

政令明文排除。 施行令就電信事業規定「排除電信事業法第164條第1項各款所列之電信事業」，其中第3款為「不設置電信線路設備，而提供媒介他人通信之電信服務以外之電信服務之電信事業」。純粹的IaaS、PaaS、SaaS因不媒介他人通信，多半落入此款。

指定基準也相當有限。 僅限第一種指定電信設備之設置者、國際海底電纜線路數市占10%以上者、5G開設計畫之認定者、使用者6,000萬人以上之訊息交換服務提供者等四種類型。雲端與資料中心業者並未被指定。

雲端在這個制度中登場，僅止於作為受指定事業者所使用之特定重要設備的「構成設備」。受規範的主體是15個領域的指定事業者，雲端業者本身並不因此產生申報義務。

順便一提，ISMAP並不是法律。它是為政府採購而設的評鑑與登錄制度，並非規範民間雲端使用的制度。這兩者很容易被混為一談，值得特別說明。

兩套制度的分工

	外匯及外國貿易法（安全保障貿易管理）	經濟安全保障推進法 第3章
要防的事	技術與貨物流出境外	基礎設施服務停擺
規範客體	貨物（動產）、特定技術（資訊）	特定重要設備之導入與維運委外
規範對象	出口人、技術提供人	受指定之特定社會基礎事業者
雲端業者	所提供之程式屬特定技術時可能該當	不在對象內（僅以構成設備供應者身分間接出現）

前者看的是「向外流出的技術」，後者看的是「一停就麻煩的國內基礎設施」。「留在國內、卻讓外國人使用的運算能力」，正好落在兩者之間。

日本國內的討論走到哪裡

那麼日本政府是不是漏看了這個議題？就原文來看，我認為並非如此。只是切入角度不同。

日本產業結構審議會安全保障貿易管理小委員會於2024年4月彙整的期中報告⁸，我做了全文檢索，「雲端」「遠端」「運算資源」「資料中心」一個都沒有出現。它端出來的，是另一條軸線：

隨時間經過而生之軍事轉用疑慮，於技術之交易較貨物之交易更為顯著。（中略）應著眼於技術之交易，採取著眼於時間經過之新的管理強化措施。

這後來以「重要管理對象技術官民對話機制」的形式落地。切入點不是遠端存取，而是以時間軸看待技術移轉。

另一方面，日本內閣官房的專家會議於2026年1月彙整的建言⁹中，確實出現了相鄰的議題：

資料中心及雲端上大量資料之防護措施等 （中略）有必要研議自我國外部所為之行為中，防護資料中心及雲端上大量資料之措施。

著眼點是「資料的防護」而非「對技術的遠端存取」，這正是與美國最關鍵的差異。而且同一份建言也踩了煞車：

於研議規範時，應注意不致過度阻礙目前投資正持續推進之資料中心建設等事業活動。因此，就本項規範仍有必要持續審慎研議。

該制度並未納入2026年6月公布的修法，仍在持續研議中。因此，比較忠於原文的讀法不是「漏看」，而是在兼顧投資促進的前提下持續研議。

至於AI政策，方向反而相反。2026年7月經內閣會議決定的人工智慧基本計畫，多次提及運算資源與資料中心，但全部都在振興與整備的脈絡下，完全沒有提到出口管制。

有一件事想坦白寫下來

前面一路寫「原則上不該當」，但這是消極論證。

無論美國或日本，都沒有明文寫著「提供運算資源不該當」的條文。我所呈現的，是「不滿足該當所需的要件」這樣的推論結構。

美國因為有2009年那份解釋函，也就是主管機關的明示見解，依據相對紮實。日本則找不到相當於此的行政解釋。 這裡確實不對稱，我寧可誠實說明。

所以實務上，建議先釐清自家的服務形態偏向附件1-2的哪一邊、所提供的程式中是否含有管制對象、支援業務是否踏進技術協助的範圍，然後個案向日本經濟產業省確認。這不是可以用「應該不該當吧」帶過去的領域。

實務上該確認什麼

給正在或準備向海外客戶提供運算資源與SaaS的企業，整理幾個確認要點。

一、先分清楚自家服務是「保管」還是「程式的提供」。 附件1-2把這兩者明確分開處理。單純出租GPU，和在其上架軟體讓人使用，結論會不一樣。

二、確認預先安裝的軟體是否為管制對象。 「我們沒讓對方下載」不構成理由，置於可利用狀態的那一刻提供就已成立。這一點實際上最容易被漏掉。

三、從契約與實作兩面確認對客戶資料的存取權限。 明知可以檢視、取得或利用客戶的特定技術仍簽約，「視為」規定就會啟動。系統設計上是否在不知不覺中留下了存取權限，值得確認。

四、劃出支援業務的界線。 調校支援與技術指導本身就是技術協助。運維支援到哪裡為止、從哪裡開始算技術提供，應該在公司內部先定好。

五、追蹤美國動向時，要把「尚未立法的法案」和「已經生效的法規」分開看。 RASA尚未立法，但2026年1月生效的先進運算許可審查方針修正，已經在許可條件中要求申報特定國家的IaaS遠端最終使用者名單等事項。現在真正在起作用的是後者。

我們的TRAFEED持續追蹤這類法規動向，協助客戶進行交易對象審查與貨品分類鑑定。要判斷某個服務形態是否該當，實際上就是把條文與通達逐條對照的苦工，而這往往正是實務上最耗時的地方。若有拿不定主意的形態，歡迎與我們討論。

結語

• 美國EAR對出口的定義要求物品移動或技術揭露，運算兩者皆非。BIS早在2009年就書面答覆「提供運算能力不受規範」「無須查驗國籍」
• BIS於2023年在聯邦公報承認了這個空缺，但把因應方式留待未來訂定法規時處理
• RASA兩度通過眾議院，卡在參議院，尚未立法
• RASA並不修改「出口」的定義，而是另立平行的管制類型。眾院通過版沒有國別限定，有限定的是尚未審議的參院版
• 報導所指的第三國安排，依現行制度並不違法。是射程之外，不是規避
• 日本同樣如此：提供運算資源本身原則上不屬於許可對象，關鍵在於「貨物即動產」的定義
• 但以SaaS提供管制程式、可存取客戶技術、構成技術協助等情形都會該當。空缺僅限於「運算資源本身」
• 日本經濟安全保障推進法的15個基礎設施領域也不含雲端
• 日本政府並非漏看，而是以「資料防護」這個不同的切入角度持續研議
• 美日都沒有寫著「不該當」的條文。認清這是消極論證，並就個案確認

法規尚未追上的領域，反過來說就是「隨時可能改變的領域」。美國的Affiliates Rule執行停止將於2026年11月到期。與其把制度空缺當成事業設計的前提，不如先想清楚空缺被填上時會發生什麼事，我認為這才是與這個領域相處的方式。

---

Footnotes

1. 15 CFR §734.13 "Export". eCFR（2026年8月18日版本）. https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-734/section-734.13 ↩

2. Bureau of Industry and Security, Advisory Opinion: Application of the EAR to Grid and Cloud Computing Services, January 13, 2009. https://www.bis.gov/media/documents/application-ear-grid-cloud-computing-services.pdf ↩

3. 88 FR 73458（2023年10月25日）, "Implementation of Additional Export Controls: Certain Advanced Computing Items", Topic 46. https://www.federalregister.gov/documents/2023/10/25/2023-23055/ ↩

4. U.S. House Select Committee on the Chinese Communist Party, Buy What It Can, Steal What It Must: China's Campaign to Acquire Frontier AI Capabilities, April 16, 2026, p.4. https://www.govinfo.gov/content/pkg/GOVPUB-Y4_2_C44-PURL-gpo255259/pdf/GOVPUB-Y4_2_C44-PURL-gpo255259.pdf ↩

5. H.R. 2683, 119th Congress, Engrossed in House（2026年1月12日眾議院通過版）. https://www.govinfo.gov/content/pkg/BILLS-119hr2683eh/html/BILLS-119hr2683eh.htm ↩

6. 日本《外匯及外國貿易法》（昭和24年法律第228號）. e-Gov法令檢索. https://laws.e-gov.go.jp/law/324AC0000000228 ↩

7. 日本經濟產業省「依外匯及外國貿易法第25條第1項及外匯令第17條第2項規定須經許可之技術提供交易或行為」（役務通達）. 最終修正 輸出注意事項2025第27號. https://www.meti.go.jp/policy/anpo/law_document/tutatu/t10kaisei/ekimu_tutatu.pdf ↩

8. 日本產業結構審議會 通商、貿易分科會 安全保障貿易管理小委員會「期中報告」（2024年4月24日）. https://www.meti.go.jp/shingikai/sankoshin/tsusho_boeki/anzen_hosho/pdf/20240424_1.pdf ↩

9. 日本經濟安全保障法制專家會議「關於進一步推動經濟安全保障之建言」（2026年1月30日）. https://www.cas.go.jp/jp/seisaku/keizai_anzen_hosyohousei/r8_dai15/teigen.pdf ↩