LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

米国の防衛関連の調達に、情報セキュリティの水準を契約の条件として持ち込む枠組みがあります。CMMC——Cybersecurity Maturity Model Certification です。米国の企業だけの話ではありません。日本の製造業や商社が部品や機器、ソフトウェアを供給する立場にあるなら、取引先から要求が降りてくる可能性があります。

米国防衛調達規則（DFARS）の関連条項では、契約担当官は要求されたCMMCレベルの現在のステータスを有しない応札者に対して契約や発注を行ってはならないとされています*1。水準を満たしていないことが、そのまま案件を失う理由になるという構造です。

本記事では、供給側の立場でこの要求に向き合う情報システム部門と、その環境構築を受託する立場に向けて、公表されている規則をもとに、何が求められ、どこから手を付けるべきかを整理します。制度の解釈が要る部分は最新の公式資料と取引先の指示で確かめながら進めてください。

枠組みの骨格——三つのレベルと、二種類の情報

この枠組みを理解するうえで、まず二種類の情報の区別を押さえます。連邦契約情報（FCI）と、管理対象非機密情報（CUI）です。機密指定を受けた情報ではありませんが、扱いに配慮が求められる情報という位置づけです。

そのうえで、求められる水準が三つのレベルに分かれています。扱う情報の性質と案件の重要度に応じて、どのレベルが要求されるかが決まる仕組みです。要求されるレベルは、プログラムオフィスまたは要求活動が決定し、契約担当官が調達の条件に含めるとされています*1。

枠組みの詳細——定義や評価の基準——は、米国の連邦規則集（32 CFR part 170）に置かれています。調達側の規則（DFARS Subpart 204.75）は、その規則を参照する形で契約の条件を定めています*1。二つの規則が組み合わさって動く構造です。

CUIを扱う段階の要件の土台になるのが、NIST SP 800-171です。この文書の正式な題は「Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations」——非連邦のシステムおよび組織におけるCUIの保護——であり、Revision 3が2024年5月に公表されています*2。連邦政府のシステムではなく、民間側のシステムに向けた要件を扱う文書だという点が重要です。

契約でどう効いてくるか——落選の理由になる

調達規則の書き方を見ると、この枠組みの性格がはっきりします。

契約担当官は、要求されたCMMCレベルの現在のステータスを有しない応札者に対して、契約、タスクオーダー、デリバリーオーダーを行ってはならないとされています*1。加えて、契約者は契約期間の全体を通じて、要求されたレベル以上の現在のステータスを維持する必要があります*1。

取得して終わりではない、というところが実務上の負担になります。一度整えた環境を維持し、状態を保ち続ける運用が求められるということです。

レベルによって扱いが違う部分もあります。レベル2とレベル3については、一定の条件付きのステータスで契約が可能とされる場合があるいっぽう、レベル1については最終のステータスが必要とされています*1。詳細は規則の該当箇所と取引先の指示で確かめる必要があります。

適用の範囲は段階的に広がる設計になっています。調達規則では、2028年11月10日以後は、FCIまたはCUIを処理・保存・送信するシステムを用いる場合に条項が適用される旨が示されています*1。いま要求が来ていない企業も、将来的に対象になる可能性を見ておく必要があります。

この構造は、日本の供給側にとっては「取引先から要求される要件」として現れます。米国の元請から下請へ、さらにその先へ——要求が連鎖する形です。ソフトウェアのサプライチェーンをめぐる管理で扱うような、取引の連鎖を通じて要件が伝わる構図と同じ性格を持ちます。

NIST SP 800-171が求める領域

CUIを扱う段階の土台になるNIST SP 800-171は、要件をいくつかのファミリーに分けて整理しています。Revision 3では、アクセス制御、意識向上と訓練、監査と説明責任、評価・認可・監視、構成管理、識別と認証、インシデント対応、保守、媒体の保護、物理環境の保護、計画、人的セキュリティ、リスク評価、システムとサービスの調達、システムと通信の保護、システムと情報の完全性、サプライチェーンリスク管理——といった領域が並びます*2。

情報セキュリティの管理体系に馴染みのある担当者なら、見覚えのある構成でしょう。既存の枠組みを整えている企業なら、土台として使える部分があります。

この見立てからわかるのは、既存の認証があれば足りるという話ではないという点です。情報セキュリティマネジメントの認証を持っている企業でも、対象範囲の切り方や記録の粒度は別途詰める必要があります。

実装の勘どころ——境界を引くことが最初の設計

この種の要求に向き合うとき、いちばん重みのある判断は「範囲をどう切るか」です。全社の情報基盤を対象にすると、費用も期間も膨らみます。

第一に、対象情報の在り処を洗い出すことです。取引先から受け取る図面、仕様書、試験データ。それが社内のどこに置かれ、誰が触り、どこへコピーされているか。現状を把握しないまま設計に入ると、後から想定外の経路が出てきます。

第二に、扱う範囲を切り出すことです。専用のネットワーク区画、専用の共有領域、専用の端末。既存環境から分ける形にすれば、要件を満たす範囲が限定されます。分けずに全体へ適用しようとすると、既存業務への影響が大きくなります。

第三に、出入口を絞ることです。切り出した範囲に、どこから入れるか。外部との受け渡しはどの経路を通るか。この二つを明示的に設計しておくと、監査でも説明しやすくなります。

第四に、記録の設計です。アクセスの記録、持ち出しの記録、構成変更の記録。どの粒度で、どれだけの期間残すか。要件を確かめてから決めます。監査ログの考え方で扱うような、後から追える形での記録が求められます。

第五に、構成の管理です。何が動いているのかを把握し、基準からの差分を検知する。台帳が実態と合っていない状態では、要件を満たしているとは言えません。SBOMによる構成情報の管理で扱うような、部品表としての把握が土台になります。

ここで注意したいのは、クラウドサービスの使い方です。要件を満たす環境として使えるかどうかは、サービスの提供形態や取引先の指示によって変わります。「クラウドだから駄目」でも「クラウドなら大丈夫」でもなく、個別に確かめる領域です。

供給側の日本企業が押さえておくこと

日本の企業が供給側として関わる場合、いくつか固有の論点があります。

要求の出所を確かめることです。取引先から「CMMCに対応してほしい」と言われたとき、その根拠が契約条項なのか、取引先の社内方針なのかで話が変わります。まず要求の文書を見せてもらい、どのレベルが求められているのかを確認します。

対象の情報を特定することです。取引の中で受け取る情報のうち、どれが対象なのか。すべてが対象とは限りません。範囲を特定できれば、必要な備えの規模も見えてきます。

他の制度との重なりを整理することです。防衛関連の取引に関わる企業は、輸出管理の枠組みにも触れます。輸出管理の該非判定で扱うような管理と、情報の扱いに関する管理は、対象が重なることがあります。担当部署が別々に管理していると、同じ情報を二重に扱う手間が生じます。

言語と体制の問題です。要件の原文は英語であり、取引先とのやり取りも英語になります。技術の内容と契約の内容の両方を英語で扱える担当が要るのか、翻訳を介するのか。体制の設計に関わってきます。

時間軸を見ることです。適用の範囲は段階的に広がる設計になっており、2028年11月10日という区切りが調達規則に示されています*1。現時点で要求が来ていなくても、取引の継続を考えるなら準備の時間を見込んでおく価値があります。

受託・委託で進めるときの要点

この種の環境構築を外部と進める場合の要点を挙げます。

第一に、現状調査を独立した工程にすることです。対象情報がどこにあり、どの経路で動いているかの洗い出しは、それ自体に工数がかかります。調査の結果によって構築の範囲が変わるため、調査と構築を分けて発注する形が合理的です。

第二に、要件の解釈の担い手を決めることです。規則の読み方や取引先との調整は、法務や調達の領域です。開発側は決まった要件を実装する役割に集中し、解釈の窓口を分けておきます。

第三に、証跡の作り方を最初に決めることです。要件を満たしていることを示す資料——構成の記録、手順書、教育の記録、試験の記録。これらを後からまとめるのは大きな負担になります。構築と並行して残す形にしておきます。

第四に、運用の担い手を決めることです。契約期間中の維持が条件になるため、構築後の運用が続きます。監視、パッチの適用、権限の棚卸し。誰が担うのかを決めずに構築だけ進めると、状態を保てなくなります。

第五に、委託先自身の扱いを整理することです。委託先の要員が対象情報に触れるのか、触れずに済む構成にできるのか。触れる場合は、委託先側にも同等の管理が求められる可能性があります。契約の段階で確かめておきます。

体制としては、情報セキュリティの管理体系と、実際のインフラ構築の両方を扱える要員が入れるかが分かれ目になります。文書だけを整える体制では実態が伴わず、構築だけの体制では証跡が残りません。両方を同じ場で進められるかを、委託先を選ぶ観点に入れておくとよいでしょう。

まとめ：CMMC対応で押さえる3つの視点

CMMCは、米国の防衛関連調達において情報セキュリティの水準を契約の条件として扱う枠組みです。押さえたい視点は三つです。第一に、契約担当官は要求されたレベルの現在のステータスを有しない応札者に発注できないとされ、しかも契約期間の全体を通じて維持することが求められるため、取得して終わりではなく状態を保つ運用が前提になること。第二に、CUIを扱う段階の土台はNIST SP 800-171——非連邦システムにおけるCUIの保護を扱う文書——であり、アクセス制御から監査、構成管理、媒体の保護、サプライチェーンまで広い領域を含むため、既存の認証だけでは埋まらない部分が残ること。第三に、実装では全社を対象にするのではなく、対象情報の在り処を洗い出して扱う範囲を切り出し、出入口と記録を設計するところが最初の勘どころになることです。まずは取引先からの要求の根拠と求められるレベルを確かめ、対象情報の現状調査から着手するのが堅実でしょう。

よくある質問

出典

1. *1　参考：Acquisition.gov「DFARS Subpart 204.75 – Cybersecurity Maturity Model Certification」（https://www.acquisition.gov/dfars/subpart-204.75-cybersecurity-maturity-model-certification）。契約担当官の発注可否、契約期間中の維持、レベルの決定、条項の適用時期、32 CFR part 170の参照の一次情報として（2026年8月確認）
2. *2　参考：NIST「SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations」（https://csrc.nist.gov/pubs/sp/800/171/r3/final）。文書の正式名称・公表時期・対象範囲および要件のファミリー構成の確認として（2026年8月確認）

Tweet