はじめに

CMMCを初めて聞いた日本企業の反応は、多くの場合こうです。

「米国防総省の制度なら、日本企業には直接関係ないのではないか。」

この問いは自然です。しかし、防衛産業の実務では、契約、設計、製造、試験、保守、ソフトウェア、クラウド、IT運用が国境を越えて接続されています。CMMCは米国政府の制度ですが、対象になる情報とシステムが国境を越えるため、日本企業にも要求が流れてきます。さらに、日本企業にとっては、米国プライムや米国子会社だけでなく、在日米軍基地・米軍施設案件という日本国内発の経路もあります。これは意外と盲点です。

結論

日本企業がCMMC対応を求められる理由は、米国DoD契約に関連するFCIまたはCUIが、サプライチェーンを通じて日本企業のシステム、担当者、外部サービスに流れる可能性があるからです。これには、米国プライムからの下請ルート、米国子会社ルート、MSP/ESPルートに加えて、日本国内の在日米軍基地・米軍施設に関する工事、設計、保守、設備、サービス案件から流れてくるルートも含まれます。32 CFR Part 170は、CMMC要求がプライム契約企業だけでなく、FCIまたはCUIを処理・保存・送信する下請企業にもサプライチェーン全階層で適用されることを定めています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

つまり、CMMCの対象判断は「米国法人か日本法人か」ではなく、DoD契約に関係するFCI/CUIを、どの情報システムが扱っているかで考える必要があります。

日本企業にCMMCが流れてくる典型パターン

1. 米国プライムの下請として技術情報を扱う場合

最もわかりやすいのは、米国プライム企業や米国防衛企業から、設計図、仕様書、試験データ、解析結果、製造条件、ソフトウェア、ソースコード、技術レポートなどを受け取るケースです。

これらがDoD契約に基づく情報であり、CUIまたはControlled Technical Informationに該当する場合、日本企業がその情報を保存するファイルサーバー、クラウドストレージ、メール、CAD環境、PLM、開発端末はCMMC上の論点になります。NARAのCUI Registryでは、Controlled Technical Informationは、軍事または宇宙用途を持ち、アクセス、使用、複製、修正、表示、開示、配布などが制限される技術情報として説明されています。参考: NARA CUI Registry – Controlled Technical Information

2. 米国子会社を日本本社が支援している場合

日本本社が米国子会社のITを統合管理しているケースも重要です。たとえば、Microsoft 365テナント、Entra ID、EDR、SIEM、バックアップ、ヘルプデスク、SOC、管理者アカウントを日本本社が運用している場合、米国子会社のCUI環境を日本側が実質的に支えている可能性があります。

この場合、日本本社がCUIを直接読むかどうかだけで判断してはいけません。CMMCでは、CUI Assetだけでなく、CUI環境を保護するSecurity Protection Assetもスコープ上の重要な資産になります。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

3. 日本企業がMSPまたはESPとして関与する場合

CMMCではExternal Service Provider、つまりESPの扱いが重要です。CUI環境に対してID管理、監視、脆弱性管理、ログ管理、EDR運用、SIEM運用、ヘルプデスク、バックアップなどのサービスを提供する場合、そのサービスは単なる外部委託ではなく、CMMC要求の実装に関わる保護機能として扱われる可能性があります。

32 CFR Part 170は、ESPを使う場合、サービスの内容、OSAとの関係、Customer Responsibility MatrixなどをSSPに文書化することを求めています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

4. クラウド上でCUIを処理・保存・送信する場合

クラウドを使う場合も、日本企業には注意が必要です。CMMC Level 2 C3PAO評価においてCUIをクラウドで扱う場合、CSPのサービスはFedRAMP Moderate以上、またはそれと同等の要件を満たすことが求められる構造があります。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

ただし、ここで重要なのは「GCC Highを使うかどうか」という単純な製品選定ではありません。まず、CUIがどのサービスに入り、どのIDでアクセスされ、どの国・どの管理者・どのログ・どの鍵管理で運用されるのかを整理する必要があります。

5. 在日米軍基地・日本国内の米軍施設案件に関わる場合

見落とされやすいもう一つの経路が、日本国内にある米軍基地・米軍施設の工事、設計、保守、設備、サービス案件です。

CMMCというと、米国プライム企業から日本企業へ技術情報が流れてくる場面や、米国子会社を通じて要求が来る場面を想像しがちです。しかし、日本に所在する米軍施設に関する案件も、発注主体や契約構造によってはDoD契約の一部です。したがって、そこでFCIまたはCUIを処理・保存・送信する場合、日本国内の建設会社、設計事務所、設備会社、保守会社、ITベンダーにもCMMC要求が現れ得ます。

特に重要なのは、USACE Japan Districtのように日本国内で工事・設計・施設関連案件を扱う調達窓口です。USACE Japan Districtの公式ページでは、2025年11月10日以降に発行されるすべての入札公告についてBasic、つまりLevel 1以上の認証を要求する予定であり、Level 1以上がなければ契約締結資格を得られない旨が案内されています。参考: USACE Japan District – Doing Business with the Japan District

同じページでは、USACE Japan DistrictのContract Opportunitiesに掲載される工事およびサービス案件は通常、日本国内の業者を対象とすること、local sourcesとは日本に物理的に所在し、日本で事業を行う権限を持つ業者であることも説明されています。参考: USACE Japan District – Doing Business with the Japan District

ここで注意すべきなのは、すべての建設案件が自動的にLevel 2になるという意味ではないことです。Level 1かLevel 2かは、扱う情報で決まります。FCIのみであればLevel 1が中心になります。一方、基地施設の図面、仕様、通信・電気・燃料・警備・防災設備に関する情報、配置・導線・脆弱性に関わる情報、その他CUIとして指定される設計・施工情報を扱う場合は、Level 2が現実的な論点になります。

さらに、入札・契約・評価結果の実務では、SAM.gov、UEI、CAGE / NCAGE、SPRSといった登録・識別情報も無視できません。CAGE / NCAGEはCMMCレベルを決めるものではありませんが、CMMC Assessment Scopeに関係する情報システムや評価結果を米国防衛調達の実務に接続するための基礎情報になります。詳しくは CAGE Code / NCAGE Codeとは何か で整理します。

つまり、建設業界にとってのCMMCは、サイバー企業だけの話ではありません。現場説明会、RFI、変更図、施工図、材料承認、工程表、完成図、BIM/CAD、写真、検査記録、ファイル共有、メール、クラウドストレージの中に、FCIまたはCUIが含まれるかどうかが問題になります。

CMMCは契約で流れてくる

CMMCは、理念として流れてくるのではありません。契約条項として流れてきます。

DFARS 252.204-7021は、契約企業が契約期間中、要求されたCMMCレベル以上のcurrent CMMC statusを維持すること、FCI/CUIを要求レベルのCMMC statusを持つ情報システムでのみ処理・保存・送信すること、さらに適切なCMMCレベルを下請契約にもflow downすることを求めています。参考: DFARS 252.204-7021 – Contractor Compliance with CMMC Level Requirements

また、DFARS 252.204-7025は、募集段階でどのCMMCレベルが必要かを示し、FCIまたはCUIを処理・保存・送信する各情報システムについて、契約 award 前にSPRS上のcurrent CMMC statusと継続的準拠のaffirmationが必要になる構造を示しています。参考: DFARS 252.204-7025 – Notice of CMMC Level Requirements

したがって、日本企業が見るべきものは、技術仕様書だけではありません。契約条項、購買条件、サプライヤーセキュリティ要件、情報保護付属書、NDA、輸出管理条項、米国子会社とのサービス契約も見る必要があります。

日本企業が最初に確認すべきこと

CMMC対応の出発点は、製品導入ではありません。現状把握です。

最初に確認すべき問いは、次の順番です。

  1. 自社または子会社はDoD契約、米国プライム案件、在日米軍基地・米軍施設案件に関係しているか
  2. その契約にFCIまたはCUIが含まれるか
  3. CUIのマーキング、配布制限、契約条項、CUI Registry上のカテゴリを確認したか
  4. CUIを処理・保存・送信するシステムはどれか
  5. そのシステムを保護するID、端末、ログ、EDR、SIEM、バックアップ、管理者端末はどれか
  6. 日本本社、米国子会社、MSP、CSP、SOCの責任分界は文書化されているか
  7. 契約上求められるCMMCレベルと評価タイプは何か

この順番を飛ばして「どのクラウドがよいか」「どのツールがCMMC対応か」から始めると、設計が必ずぶれます。

クロスボーダーで起きる本当の問題

日本企業にとってCMMCが難しいのは、米国制度そのものよりも、クロスボーダー運用の責任分界です。

たとえば、CUIは米国子会社のクラウドに保存されている。しかし、ID管理は日本本社が行っている。EDRの検知はシンガポール拠点のSOCが見ている。バックアップは別のクラウドにある。管理者アカウントはグローバル共通である。こうした構造は珍しくありません。

このとき、CMMC上の問いは「CUIはどこにあるか」だけでは足りません。

  • 誰がCUIにアクセスできるのか
  • 誰がCUI環境を変更できるのか
  • 誰がログを見ているのか
  • 誰がインシデント時に判断するのか
  • 誰が継続的準拠をaffirmationできるのか

CMMCは、地理的な所在地だけではなく、アクセス権、管理権限、保護機能、責任者を含めて設計しなければ成立しません。

よくある誤解

第一の誤解は、「日本にデータがあるから米国制度は関係ない」というものです。CMMCは、DoD契約に関連するFCI/CUIを処理・保存・送信する contractor information system を対象にします。所在地だけで対象外になるわけではありません。

第二の誤解は、「当社は下請だから要求は軽い」というものです。32 CFR Part 170は、サプライチェーン全階層で、扱う情報に応じたCMMC要求が流れる構造を定めています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

第三の誤解は、「CUIを直接見ていなければ関係ない」というものです。保護機能を提供する資産や外部サービスは、CUIを直接保存していなくてもスコープや責任分界の論点になります。

第四の誤解は、「法務が契約を見て、ITがツールを入れればよい」というものです。CMMCでは、契約、CUI識別、システム境界、運用証跡、責任者のaffirmationが一体です。部門別に分断すると、評価時に説明できない構造になります。

本質

日本企業にとってCMMCは、米国制度への対応であると同時に、国境を越えた防衛サプライチェーンにおける責任構造の明確化です。

CMMCは、どこか一つの部署が担当するチェックリストではありません。CUIを誰が扱い、誰が守り、誰が運用し、誰が表明するのかを、契約とシステムの両方で揃える作業です。

まとめ

日本企業がCMMC対応を求められる理由は、米国DoD契約に関連するFCI/CUIがサプライチェーンを通じて日本企業に流れるからです。その経路は、米国プライム、米国子会社、MSP/ESP、クラウドだけではありません。日本国内の米軍基地・米軍施設に関する工事、設計、保守、設備、サービス案件から流れてくることもあります。対象になるかどうかは、法人の国籍や業種ではなく、扱う情報、契約条項、システム境界、外部サービス、管理権限によって決まります。

日本企業は、まず「CMMCが必要か」を抽象的に議論するのではなく、CUIデータフロー、米国子会社との関係、MSP/CSP/SOCの責任分界、契約上のflowdownを整理する必要があります。

次の記事

次は「CUIとは何か」です。CMMCの中心概念であるCUIを、ファイル名ではなく保護状態として整理します。

参考資料