はじめに

CMMCを「米国のサイバーセキュリティ認証」とだけ理解すると、実務ではほぼ必ず迷います。なぜなら、CMMCの中心にあるのは、証明書そのものではなく、防衛契約に関係する情報を、どの組織が、どのシステムで、どの責任のもとで保護しているのかを検証可能にすることだからです。

このサイトでは、CMMCを単なる制度名としてではなく、CUI Boundary、責任分界、外部サービス、ゼロトラスト、クロスボーダー運用をつなぐ実務構造として扱います。

結論

CMMCとは、米国防総省の契約に関係する企業が、FCIまたはCUIを適切に保護しているかを確認するための評価制度です。32 CFR Part 170では、CMMC Programは、防衛契約企業の情報システム上で処理・保存・送信されるFCIおよびCUIを適切に保護していることを確認するための制度とされています。2026年6月1日時点では、CMMCの段階的実装はすでに始まっており、DoD CIOはPhase 1を2025年11月10日から2026年11月9日まで、主にLevel 1およびLevel 2自己評価に焦点を当てる期間として案内しています。参考: DoD CIO – About CMMC, 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

つまり、CMMCは「将来いつか来る制度」ではありません。すでに契約実務に入り始めている制度です。

CMMCは何を守ろうとしているのか

CMMCが守ろうとしているのは、米国政府や国防総省のために扱われる非公開の非機密情報です。ここで重要なのは、CMMCの対象が「秘密指定された classified information」だけではない点です。むしろCMMCの主戦場は、classifiedではないが、公開してよいわけでもない情報です。

代表的には、FCIとCUIがあります。

FCIは、政府契約のもとで提供または生成される、公開を意図していない契約情報です。FAR 52.204-21では、FCIは政府のために製品やサービスを開発・提供する契約において、政府から提供される、または政府のために生成される非公開情報として定義されています。参考: FAR 52.204-21 – Basic Safeguarding of Covered Contractor Information Systems

CUIは、法律、規則、政府全体方針により保護または配布制限が求められる非機密情報です。これは単なる「機密っぽいファイル」ではなく、根拠を持った保護対象です。参考: 32 CFR Part 2002 – Controlled Unclassified Information, NARA – About Controlled Unclassified Information (CUI)

CMMCを理解する第一歩は、会社全体を守ることではありません。FCIまたはCUIが、どこで処理・保存・送信されているかを特定することです。

CMMCの3つのレベル

CMMCにはLevel 1、Level 2、Level 3があります。

Level 1は、主にFCIを対象とした基本的な保護です。要求はFAR 52.204-21に基づきます。これは「最低限の衛生管理」に近いものですが、軽く見てよいという意味ではありません。Level 1ではPOA&Mが認められず、全要求を満たす必要があります。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program, FAR 52.204-21 – Basic Safeguarding of Covered Contractor Information Systems

Level 2は、CUIを扱う環境を対象とします。CMMC規則上、Level 2の要求はNIST SP 800-171 Rev.2に基づきます。ここでは、SSP、CUIデータフロー、資産分類、アクセス制御、監査ログ、暗号化、インシデント対応、外部サービスの責任分界が重要になります。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program, NIST SP 800-171 Rev. 2 – Protecting CUI in Nonfederal Systems and Organizations

Level 3は、より高度な脅威を想定したCUI保護で、Level 2を前提に、NIST SP 800-172の選択要求が追加されます。日本企業の多くが最初に直面するのはLevel 1またはLevel 2ですが、防衛技術や高機微なサプライチェーンに深く関わる場合は、Level 3の考え方も無視できません。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

評価制度としてのCMMC

CMMCで混乱しやすいのは、「要求事項」と「評価制度」が混ざって語られることです。

NIST SP 800-171は、CUIを保護するためのセキュリティ要求事項です。一方、CMMCは、その要求が実際に実装されているかを、自己評価、C3PAO評価、DIBCAC評価などで確認する制度です。これは、自己申告だけではなく、契約上確認できる状態にするという意味を持ちます。

CMMCでは、評価結果をSPRSに記録し、一定のタイミングで継続的な準拠をaffirmationすることが求められます。32 CFR Part 170は、Affirming Officialが評価後および毎年、継続的準拠をSPRSで表明する構造を定めています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

ここがCMMCの重要な転換点です。CMMCは「チェックリストを満たしたか」だけではなく、誰が組織としてその状態を維持すると表明するのかを問います。

日本企業にとっての意味

CMMCは米国制度ですが、日本企業にも関係します。米国DoD案件のサプライチェーンは国境を越えます。日本企業が直接DoDと契約していなくても、米国プライム、米国子会社、共同開発先、製造委託元、試験機関、IT運用支援会社として関わることがあります。

32 CFR Part 170は、CMMC要求がプライムだけでなく、FCIまたはCUIを処理・保存・送信する下請に対して、サプライチェーン全階層で適用されることを明記しています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

したがって、日本企業が最初に問うべきなのは「当社は米国企業ではないが対象か」ではありません。問うべきは次です。

  • DoD契約に関連する情報を扱っているか
  • その情報はFCIか、CUIか
  • その情報をどのシステムで処理・保存・送信しているか
  • 日本本社、米国子会社、MSP、クラウド、SOCのどこが保護機能を担っているか
  • 契約上、どのCMMCレベルと評価タイプが要求されているか

CMMC対応とは、この問いを契約・IT・セキュリティ・法務・輸出管理の間で整合させる作業です。

システム設計として見るCMMC

CMMC対応を「全社のセキュリティを強化する活動」として始めると、範囲が広がりすぎます。逆に、「CUIだけ隔離すればよい」と考えると、保護機能を担うID基盤、ログ基盤、EDR、SIEM、管理端末、外部サービスを見落とします。

CMMCの設計で重要なのは、CUI Assetだけではありません。CUIを直接扱わなくても、CUI環境を守るSecurity Protection Assetはスコープに入ります。例えば、IdP、EDR、SIEM、脆弱性管理、バックアップ、管理者端末などです。32 CFR Part 170のスコープ規則は、CUI Asset、Security Protection Asset、Contractor Risk Managed Assetなどの資産分類を定めています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

CMMCとは、CUIファイルの保護ではなく、CUIが存在する環境全体の保護状態を説明する制度です。

よくある誤解

最も多い誤解は、「CMMCは認証を取れば終わり」というものです。実際には、CMMCは一定期間ごとの評価、毎年のaffirmation、スコープ変更への対応、POA&Mの期限管理、外部サービスの責任分界まで含みます。

次に多い誤解は、「Microsoft 365やクラウド製品を導入すればCMMC対応になる」というものです。製品は構成要素にすぎません。どのテナントで、どのライセンスで、どのID制御で、どのログを、誰が運用し、CUIをどこに置くかが決まっていなければ、CMMC上の保護状態は説明できません。

もう一つの誤解は、「日本側はCUIを見ていないから関係ない」というものです。日本側がCUI環境のID管理、監視、EDR、SIEM、ヘルプデスク、管理者権限を担う場合、CUIを直接処理していなくても保護機能の一部になる可能性があります。

本質

CMMCの本質は、防衛サプライチェーンにおける信頼を、自己申告から検証可能な構造へ移すことです。

セキュリティは努力ではなく設計です。CMMCは、その設計がどこまで実装され、どこまで証跡で説明でき、誰が継続的に責任を持つのかを問います。

まとめ

CMMCは、米国防衛契約におけるサイバーセキュリティ評価制度です。しかし、本質的には、FCI/CUIを扱う組織、システム、外部サービス、責任者を明確にし、防衛サプライチェーン全体で保護状態を検証できるようにする制度です。

日本企業がCMMCを理解するには、認証取得の手順から入るのではなく、まずCUI Boundary、責任分界、データフロー、外部サービス、契約条項を構造的に整理する必要があります。

次の記事

次は「日本企業がCMMC対応を求められる理由」です。CMMCがなぜ日本企業にも流れてくるのかを、契約・サプライチェーン・米国子会社・クロスボーダー運用の観点から整理します。

参考資料