ログイン

トップ

アウェアネス

PhishAI

AI SOC

株式会社ヤグラ

サービス一覧

会社概要

記事

ホワイトペーパー

セミナー

用語集

ニュース

インシデント速報

お問い合わせ

資料ダウンロード

株式会社ヤグラ

Insight

防衛サプライチェーンのセキュリティ基準（防衛省新基準・NIST SP 800-171）とSOC要件

迎 健太

防衛省の情報セキュリティ基準が、保護すべき情報を扱う元請・下請・孫請企業に求めるログ・監視・事象対応の要件を整理します。NIST SP 800-171 Rev.3も参考に、SOC運用への反映、証跡・報告の作成支援、準備のロードマップを解説します。

防衛サプライチェーンのセキュリティ基準とSOC要件

防衛装備品の製造や役務に関わる企業では、防衛省が定めた情報セキュリティ基準への対応が契約の条件となる場合があります。2023年4月1日以降の防衛省との調達契約のうち、保護すべき情報の取扱いを含む契約が対象です。該当情報を扱う下請・孫請企業にも、特約条項に基づく対策が求められます。部品メーカーや加工業者、ソフトウェア開発会社など、これまで「自社は防衛産業ではない」と考えてきた中堅・中小企業も、扱う情報と契約条件を確認する必要があります。

背景には、サプライチェーンを経由した攻撃の常態化があります。IPA（情報処理推進機構）が2026年1月に公表した「情報セキュリティ10大脅威 2026」では、組織向け脅威の第2位に「サプライチェーンや委託先を狙った攻撃」が選出され、8年連続の選出となりました（IPA, 2026）。守りの弱い取引先を踏み台にして本来の標的に到達する手口は、機微な情報が多層の企業間を流れる防衛分野で特に警戒されています。

本記事では、防衛省の情報セキュリティ基準の要求事項を整理し、参考としてNIST SP 800-171 Rev.3も取り上げます。「ログ・監視・インシデント対応・監査」の要件を原文に沿って読み解き、SOC（Security Operations Center）の運用にどう反映するかを解説します。あわせて、中堅製造業が直面する人材・コストの課題、AI SOCの活用、準備のロードマップまでを扱います。

防衛省「防衛産業サイバーセキュリティ基準」の概要

一般に「防衛産業サイバーセキュリティ基準」や「防衛省新基準」と呼ばれているものの正式名称は、「装備品等及び役務の調達における情報セキュリティ基準」です。防衛装備庁の公開ページによれば、この基準はサイバー攻撃等のリスク増大に対応するため2022年3月に整備され、契約に基づき企業において取り扱われる「保護すべき情報」の管理に適用されます（防衛装備庁, 2025）。防衛省と特約条項が付された契約を締結した企業は、この基準に基づく対策の実施が必要になります。

適用時期について、防衛装備庁のFAQは「令和５年４月１日以降の装備品等及び役務の調達にかかる防衛省との契約のうち、保護すべき情報の取扱いが含まれるすべての契約が適用の対象です」と説明しています（防衛装備庁 FAQ, 2024）。つまり2023年4月1日以降の契約のうち、保護すべき情報を取り扱う契約について、新基準への対応が求められてきたことになります。従前の基準からの経過措置については、同FAQで「規則上は経過措置の廃止される令和10（2028）年３月末まで」としつつ、ほとんどの防衛関連企業では1〜2年の間に切換えを完了する予定であるとも述べられています。

保護対象と NIST SP 800-171 との関係

基準が守る対象である「保護すべき情報」は、「装備品等及び役務の調達に関する情報のうち、防衛省の『部内限り』又は『注意』に該当する情報で、情報セキュリティ指定書において、官により指定された情報」と定義されています。秘、特定秘密、特別防衛秘密といった「秘密等」は別の枠組みで扱われるため、この基準の対象外です。裏を返せば、秘密指定を受けていない設計情報や調達情報であっても、指定書で指定されれば基準の対象になるという点が、多くの取引先企業にとって実務上の要点です。

基準の水準について、FAQは「NIST SP800-171と同等のセキュリティ要求事項となっています」と明記しています（防衛装備庁 FAQ, 2024）。また防衛装備庁のページには、新基準では「検知」「対応」「復旧」を追加して制定したという注記があります。従来の情報管理が「持ち出さない・漏らさない」という予防と管理に重心を置いていたのに対し、新基準は侵入や不正を前提に、それを検知し、対応し、復旧するまでの能力を企業に求めています。この「検知・対応・復旧」の部分こそ、SOCの機能と直接重なる領域です。

サプライチェーンへの適用範囲も明確です。防衛装備庁のページは「元請負者から『保護すべき情報』を取り扱う業務を請け負う企業についても、同基準に基づく対策の実施が必要です」と述べ、FAQでも「特約条項で下請負企業にも適用することを規定しています。また、孫請け以降の企業がいる場合にも適用されます」と説明されています。なお、基準は改定が続いており、最新版である令和7年版（防装庁（事）第137号）は2025年7月1日から適用され、2025年9月1日以降に提出する書類は新様式の使用が求められています。対応にあたっては常に最新版を参照する必要があります。

基準の構造

令和7年版の基準本体は、第一部と付紙「システムセキュリティ実施要領」で構成されています。第一部は、趣旨、定義、対象に続いて、情報セキュリティ基本方針等、組織のセキュリティ、保護すべき情報の管理、情報セキュリティ教育及び訓練、物理的及び環境的セキュリティ、保護システムについての管理策、情報セキュリティ事故等への対応、情報セキュリティ事故等発生時の対応、リスク査定、セキュリティ監査、防衛省による監査という14の章からなります。付紙は、システムセキュリティ実装計画書、構成管理、保護システムの基本的防御、アクセス制御、識別及び認証、通信制御、システム監視、システムログ、脆弱性スキャン等、バックアップ、システムメンテナンス等の技術的要件を定めています。

このうちSOCの運用と関係が深いのは、第一部の「情報セキュリティ事故等への対応」「情報セキュリティ事故等発生時の対応」「セキュリティ監査」「防衛省による監査」の各章と、付紙の「システム監視」「システムログ」「脆弱性スキャン等」の各章です。具体的な要求内容は後述します。

NIST SP 800-171 Rev.3 の構造と、監視・監査・インシデント対応の要件ファミリー

NIST SP 800-171 は、米国国立標準技術研究所（NIST）が発行する文書で、正式名称は "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations" です。CUI（Controlled Unclassified Information。秘密指定はされていないものの管理を要する政府情報）が連邦政府以外の組織のシステムに置かれる場合に、その機密性を守るための推奨セキュリティ要件を定めています。現行の Rev.3 は2024年5月に公開され、2021年1月版の Rev.2 を置き換えました（NIST, 2024）。米国の防衛調達で取引先に求められる基準として知られていますが、日本の防衛省基準が「同等」と位置づけている参照元でもあります。

Rev.3 の要件は NIST SP 800-53 の中程度（moderate）ベースラインの管理策から導出され、連邦政府側の責任に属するものやCUIの機密性に関係しないものを除く形で調整されています。要件は17のファミリーに整理され、それぞれ 03.01 から 03.17 までの番号が付いています。また Rev.3 の特徴として、要件文の中に ODP（Organization-Defined Parameter、組織定義パラメータ）と呼ばれる可変部分があり、ログをレビューする頻度やインシデントを報告する期限などの具体値は、要件を適用する組織や発注者が定める仕組みになっています。日本企業が「同等」基準に対応するうえでも、頻度や期間の設計が自社に委ねられる部分があることは押さえておくべき点です。

なお、防衛省の基準は2022年3月に整備されており、Rev.3 の公開はその後の2024年5月です。FAQは同等とする SP 800-171 の版を特定していません。実務上は防衛省基準の原文と特約条項に従うのが大前提であり、NIST の文書は要件の背景を理解し、自社の対策を点検する際の参照軸として使うのが現実的です。以下では、SOC運用に関わるファミリーを取り上げます。

03.03 監査と責任追跡性（Audit and Accountability）

このファミリーは、ログ（監査レコード）の生成・保護・分析に関する要件を定めています。Rev.3 では、03.03.01 イベントロギング、03.03.02 監査レコードの内容、03.03.03 監査レコードの生成、03.03.04 監査ログ処理の障害への対応、03.03.05 監査レコードのレビュー・分析・報告、03.03.06 監査レコードの縮約とレポート生成、03.03.07 タイムスタンプ、03.03.08 監査情報の保護、の8つの要件が置かれています（NIST, 2024）。

SOCの観点で中核となるのは 03.03.05 です。原文は "Review and analyze system audit records [Assignment: organization-defined frequency] for indications and the potential impact of inappropriate or unusual activity." であり、組織が定めた頻度でシステムの監査レコードをレビュー・分析し、不適切または異常な活動の兆候とその潜在的影響を把握することを求めています。ログを「取っておく」だけでは要件を満たさず、「見て、分析して、報告する」運用が必要であることを示す要件です。03.03.04 のログ処理障害への対応や、03.03.08 の監査情報の保護は、ログが途切れたり改ざんされたりしない状態を維持することを求めており、ログ基盤の設計に直結します。

03.06 インシデント対応（Incident Response）

インシデント対応のファミリーには、03.06.01 インシデントハンドリング、03.06.02 インシデントの監視・報告・対応支援、03.06.03 インシデント対応のテスト、03.06.04 インシデント対応の訓練、03.06.05 インシデント対応計画、の5つの要件があります。03.06.01 の原文は "Implement an incident-handling capability consistent with the incident response plan including preparation, detection and analysis, containment, eradication, and recovery." であり、準備、検知と分析、封じ込め、根絶、復旧という一連の段階を含むインシデントハンドリング能力を、計画と整合する形で実装することを求めています（NIST, 2024）。03.06.02 は、インシデントを追跡・記録し、組織が定めた期限内に報告することを要求しており、ここでも報告期限は ODP として組織側で定義します。

03.14 システムと情報の完全性、03.12 セキュリティ評価と監視

「システムと情報の完全性」のファミリーには、03.14.01 欠陥の修正、03.14.02 悪意のあるコードからの保護、03.14.03 セキュリティアラート・アドバイザリ・指令、03.14.06 システム監視、03.14.08 情報の管理と保持などが含まれます。SOCに最も近い 03.14.06 の原文は "Monitor the system to detect attacks and indicators of potential attacks, unauthorized connections, and unauthorized use." で、攻撃と攻撃の兆候、不正な接続、不正な利用を検知するためにシステムを監視することを求めています。03.14.02 はシステムの入口・出口での悪意のあるコードの検知と除去、03.14.03 は外部組織からのセキュリティアラートやアドバイザリを継続的に受け取ることを要求しており、EDRや脅威情報の運用に対応します（NIST, 2024）。

「セキュリティ評価と監視」のファミリーには、03.12.01 セキュリティ評価、03.12.02 行動計画とマイルストーン、03.12.03 継続的監視、03.12.05 情報交換があります。03.12.03 は "Develop and implement a system-level continuous monitoring strategy that includes ongoing monitoring and security assessments." として、継続的な監視とセキュリティ評価を含むシステムレベルの継続的監視戦略を策定・実施することを求めています。また Rev.3 には、サプライチェーンリスク管理（03.17）のファミリーも含まれており、取引先を含めたリスク管理が要件体系の一部として位置づけられています。

防衛省基準が具体的に求めるログ・監視・事故対応・監査

それでは、防衛省基準の原文は何を求めているのでしょうか。令和7年版の基準本体と関連通知から、SOC運用に関わる要件を抜き出します（防衛装備庁, 2025）。

システムログの取得・分析・保管

付紙第9「システムログ」は、「防衛関連企業は、保護システムにおける不正な操作や通信を探知するため、次に掲げる事項に係る記録をシステム上で自動的に取得するものとする」と定め、取得対象として「保護すべきデータへの動作の内容」と「保護システム利用者ごとの操作内容」を挙げています。分析については「保護システム担当者は、定期的にシステムログの分析を実施するものとし、分析を行う場合は、保護システム構成要素から取得したシステムログを集約し、全体的かつ横断的な分析を行うものとする」と規定しており、分析結果を記録した文書は速やかに総括者や保護システム管理者などに報告することが求められます。保管については「システムログを、文書により保管する場合は、施錠したロッカー等により、データで保存する場合には、暗号化により、必要な期間保管又は保存するものとする」とされています。基準本体に保存期間の具体的な年数は示されておらず、「必要な期間」を自社で定義することになります。

ここで注目したいのは、「集約し、全体的かつ横断的な分析」という表現です。端末、サーバ、認証基盤、ネットワーク機器が個別に出すログを個別に眺めるのではなく、集めて突き合わせることが求められています。これは SIEM によるログの相関分析そのものであり、NIST の 03.03.05 と同じ方向を指しています。

システム監視

付紙第8「システム監視」は、まず「防衛関連企業は、保護システムにおける不正なアクセス及び変更、アカウント及び権限の不正な使用、不正な通信並びに悪意のあるコード等（以下「不正なアクセス等」という。）の検知に必要な情報の収集を行うための機器の設置、ソフトウェアのインストール等を実施し」と定めています。そのうえで、監視の実施にあたっては「システム上の挙動を常時監視するとともに、第９第１項の規定により作成されたシステムログの分析結果を利用するものとする」と規定し、監視方法、不正なアクセス等を検知した際の対応、監視により取得した情報の利用及び保管についても項目を置いています。「常時監視」と「ログ分析結果の利用」が明文で求められている点は、SOC体制を検討する際の出発点になります。

事故等への備えと発生時の報告

第一部の「情報セキュリティ事故等への対応」では、「経営者等は、情報セキュリティ事故及び情報セキュリティ事象の発生に備え、情報セキュリティ事故等対処計画を定めるものとする」とし、計画に定める事項として「事故等に係る証拠の保存及び原因の究明」や「事故等からの復旧」を挙げています。さらに「情報セキュリティ事故等対処計画の有効性を検証し、潜在的な弱点又は欠陥を発見するため、情報セキュリティ事故等対処テストを定期的に実施するものとする」と、計画の定期的なテストも求めています。NIST の 03.06.03（テスト）や 03.06.05（計画）と対応する要求です。

発生時の報告については、「総括者は、前項第１号に掲げる情報セキュリティ事故等の報告を受けた場合は、適切な措置を講じるとともに、直ちに把握し得る限りの全ての内容を、その後速やかにその詳細を防衛省に報告するものとする」と規定されています。把握できた内容を「直ちに」、詳細を「速やかに」という二段構えです。防衛省側の受付手順を定めた通知（装装保第4239号）には報告様式が示されており、会社名、連絡先、速報の内容のほか、「現時点でわかっていることの詳細」「これまでにとった対応」「影響のある主な契約」といった項目が含まれています。また同通知は、下請負者からの報告は防衛省と直接契約を締結している防衛関連企業を通じて行うよう周知することを定めており、下請企業は元請企業経由の報告経路を事前に確認しておく必要があります。

自社監査と防衛省による監査

第一部「セキュリティ監査」では、「総括者は、１年に１回以上及び自社の情報セキュリティに重大な変化が生じた場合など必要と認めた場合に、監査部門にセキュリティ監査を実施させるものとする」と定め、監査部門には原則として被監査部署以外の者を最低1名含めることを求めています。これに加えて、防衛省が指定する監査官による監査があります。監査実施要領（装装保第4210号）は、初回監査に続く「維持監査」を「初回監査の翌年度以降、年１回以上定期的に特約条項の遵守状況及び情報セキュリティ基本方針等の有効性及び遵守状況を確認する監査」と定義しています（防衛装備庁, 2025）。

監査の確認項目には「定めた手順に従い、保護システムのシステムログが適切に取得、分析、保存又は保管されていること」が含まれ、実地監査は目視、閲覧、質問、観察、試行による確認を組み合わせて行われます。指摘事項は速やかに是正して報告することが求められ、再監査により改善状況が確認されます。下請負者については、元請企業が確認した下請負者の情報セキュリティ対策確認書を届け出させ、監査官がその内容を確認する仕組みです。つまり元請企業は、自社の対策だけでなく、下請企業の対策状況についても説明責任を負う立場に置かれます。

これらの要件をSOC運用でどう満たすか

SOCとは、組織のシステムやネットワークを監視し、脅威を検知・分析して対応につなげる専門組織や機能のことです（役割や体制の基本は「SOCとは？役割・Tier体制・24時間365日運用の基本と限界」で解説しています）。防衛省基準と NIST SP 800-171 は「何を満たすべきか」を定めていますが、「どのような体制と手順で回すか」は企業側の設計に委ねられています。ここでは要件をSOC運用に翻訳します。

ログ収集・保全の設計

まず、保護システムの構成要素を洗い出し、基準が求める「保護すべきデータへの動作の内容」「保護システム利用者ごとの操作内容」を、どの機器・サービスのどのログで証明できるかを対応づけます。ファイルサーバやCAD／PLMシステムのアクセスログ、認証基盤の認証成否、端末のEDRログ、ファイアウォールやプロキシの通信ログ、クラウドサービスの操作ログなどが典型です。それらを SIEM に集約することで、「全体的かつ横断的な分析」の前提が整います。

次に、ログの欠落と改ざんへの備えです。NIST の 03.03.04 が想定するように、ログの転送が止まったり保存容量が枯渇したりしたときに気づける仕組みを用意します。時刻同期（03.03.07）がなければ横断分析は成立しません。保存は基準どおり暗号化し、アクセス権を分析担当者に限定します（03.03.08）。保存期間は基準に数値がないため、契約条件、監査での説明のしやすさ、自社のリスク査定に基づいて定義し、文書化しておくことが重要です。これは ODP を自社で埋める作業と本質的に同じです。

「常時監視」を人と仕組みで成立させる

基準の「常時監視」は、監視機器を設置しソフトウェアを導入すれば自動的に満たされるものではありません。検知の仕組みが出したアラートを、誰かが見て、真の脅威かどうかを判断し、必要なら対応につなげる運用が伴わなければ、監査の場で「取得はしているが分析していない」と受け取られかねません。常時監視と、検知時の確認・対処を継続できる体制が必要です。対象システムと契約条件に応じて、監視・対応体制を設計します。重大事象を総括者や保護システム管理者へ引き渡す経路についても、夜間・休日の対応を含めて整理します。

多くの中堅製造業では、これを自社要員だけの交代勤務で実現するのは現実的ではありません。内製、外部委託、あるいは自動化の組み合わせをどう選ぶかは、要員数と費用と対応スピードのバランスで決まります。判断の枠組みは「SOC構築の費用とステップ：中堅企業が24時間監視体制を作る現実的な方法」で詳しく整理しています。

インシデント対応手順と報告の整備

事故等対処計画には、基準が求める「証拠の保存及び原因の究明」「復旧」を含め、NIST 03.06.01 の「準備、検知と分析、封じ込め、根絶、復旧」の段階に沿って、SOCが担う範囲と総括者・CSIRTが担う範囲を明確にします。一般に、SOCはインシデントの検知と初期分析、端末の隔離やアカウントの停止といった初動の封じ込めまでを担い、事故等としての認定、防衛省への報告判断、取引先への連絡は総括者を中心とする体制が判断します。

報告の実務では、第一報の様式に含まれる「現時点でわかっていることの詳細」「これまでにとった対応」「影響のある主な契約」を、発見から短時間で書き出せる状態を目指します。そのためには、SOCの調査記録に、影響を受けた端末・アカウント・データの範囲と、実施済みの対処が時系列で残っていることが前提になります。下請企業の場合は、元請企業を経由する報告経路と連絡先を契約ごとに整理し、計画のテストの中で実際に連絡が通るかを確認しておくべきです。検知から封じ込めまでの具体的な手順は「インシデント初動対応とSOCの連携：検知から封じ込めまでの実務ランブック」で扱っています。

監査で「証跡」を示せる状態にする

監査官が確認するのは、ログが「定めた手順に従い」取得・分析・保管されているかです。したがって証跡として求められるのは、手順書そのものに加えて、分析を実施した記録、分析結果を総括者等に報告した文書、保管状況の記録です。SOCの運用では、アラートごとの調査記録と判断理由、対応履歴、日次・月次のレポートが、そのまま基準の要求する文書になります。年1回以上の自社監査と、毎年の維持監査に耐える形で、これらを継続的に蓄積し、いつでも取り出せる状態を保つことが運用設計のゴールです。

中堅製造業が直面する課題

要件を運用に落とし込む段階で、中堅・中小の製造業が共通して直面する課題が三つあります。

  • 人材：セキュリティ専任者がいないか、情報システム部門の1〜2名が兼任している企業が多く、アラートの一次判定を夜間・休日まで人手で回すことは難しいのが実情です。ログ分析の専門知識を持つ人材の採用・育成も容易ではありません。

  • コスト：SIEM や EDR の導入費に加え、監視・分析の運用費が毎年続きます。防衛関連の売上が全体の一部にとどまる企業ほど、契約規模に対して負担感が大きくなります。

  • 多層サプライチェーン：元請企業は下請企業の対策確認書を確認して届け出る立場にあり、下請の水準が自社の監査に影響します。一方で下請企業は、複数の元請から異なる様式・時期で確認を求められ、対応が分散しがちです。

加えて、時間軸の変化があります。基準の整備から数年が経ち、FAQが述べるように多くの企業が1〜2年で新基準への切換えを進めてきた結果、今後の課題は「初回の対応を終えること」から「維持監査に毎年耐える運用を続けること」に移っています。新基準で追加された「検知」「対応」「復旧」は、文書を整えるだけでは満たせず、日々の運用が回っているかどうかが監査の場で問われます。運用の実態が文書に追いついていない状態は、この領域で最も露見しやすい弱点です。

AI SOCによる証跡・報告の自動化と人的工数の圧縮

こうした課題に対して、近年選択肢に加わっているのが AI SOC です。AI SOC は、EDR や SIEM が出すアラートを、AIエージェントが一流アナリストの調査手法を再現して自律的に調査・対処する仕組みで、人手の一次判定を前提としてきた従来型SOCとは構造が異なります（仕組みの詳細は「AI SOCとは？仕組み・従来型SOCとの違い・導入メリットをわかりやすく解説」を参照してください）。防衛省基準との関係では、次の点で運用要件の実効性を支えます。

第一に、「常時監視」の実効性です。ヤグラAI SOCでは、EDR・SIEMのアラートを24時間365日、AIエージェントが調査し、担当者の一次調査を支援します。実際に調査できる範囲や未調査の件数は、連携先と取得できる情報によって変わります。自社環境で調査率を確認し、監視の対象範囲と実施状況を説明できることが重要です。

第二に、証跡の自動生成です。AI SOC では一般に、AIエージェントがどのログを突き合わせ、何を根拠に判定したかが調査記録として残ります。調査の過程と結論を文書化することで、基準が求める「分析結果を記録した文書」と「総括者等への報告」を、運用の副産物として継続的に蓄積できます。散在するログを一元集約し、日次のセキュリティレポートを自動生成するヤグラAI SIEMと組み合わせれば、「定期的な分析」の証跡も揃います。

第三に、報告と対応のスピードです。AIが整理した調査記録は、第一報に必要な「現時点でわかっていることの詳細」「これまでにとった対応」を確認する材料になります。報告に必要な情報がそろうまでの時間と、対処完了までの時間を自社環境で測定します。第四に、人的工数です。一次調査の支援によって兼任担当者の負担をどこまで減らせるかを検証し、事故等対処計画の更新、対処テスト、監査対応に必要な時間も確保することが重要です。

ヤグラAI SOC は自社開発のサービスで、EDR・SIEM・ID管理製品など100以上のセキュリティ製品と連携します。Microsoft Sentinelなどの既存製品を活かした導入が可能です。コンテキストメモリにより自社環境を学習し、調査精度が向上していく点も、環境ごとに構成の異なる製造業の現場に適しています。ヤグラは防衛サプライチェーンの製造業を主要な顧客層の一つとしています。ただし、AIが総括者の判断を代替するわけではありません。事故等の認定や防衛省への報告は人が行うものであり、基準が求める総括者・保護システム管理者などの体制は変わりません。AI SOC は、その体制が「常時監視」「横断分析」「証跡の保全」を現実的な工数で維持するための基盤と位置づけるのが適切です。

準備のロードマップ

最後に、基準対応とSOC体制の整備を進める順序を整理します。すでに対応を終えている企業も、維持監査と改定への追従という観点で見直しに使えます。

  1. 契約と対象の棚卸し：特約条項が付された契約、情報セキュリティ指定書で指定された保護すべき情報、それを扱う保護システムの範囲を確定します。下請・孫請への情報の流れも図示します。

  2. ギャップ分析：基準本体の第一部・付紙の各章と、NIST SP 800-171 Rev.3 の 03.03、03.06、03.12、03.14 を参照軸に、文書・技術・運用の三層で現状を評価します。特に「運用が回っている証跡があるか」を確認します。

  3. ログ・監視基盤の整備：取得対象、保存期間、分析頻度を定義し、SIEM への集約、時刻同期、暗号化と改ざん防止、欠落検知を実装します。

  4. 24時間監視体制の決定：内製、外部委託、AI SOC、またはその組み合わせを、要員・費用・対応スピードの観点で選択し、エスカレーション経路を総括者まで含めて定義します。

  5. 事故等対処計画と報告経路の整備：第一報様式の項目を短時間で埋められる手順、元請経由を含む報告経路、証拠保全と復旧の手順を計画に落とし、定期的な対処テストで検証します。

  6. 監査サイクルの確立：年1回以上の自社監査、維持監査に向けた証跡の整理、指摘事項の是正と再監査、令和7年版のような改定への追従を年間計画に組み込みます。

まとめ

防衛省の「装備品等及び役務の調達における情報セキュリティ基準」は、2023年4月1日以降の防衛省との調達契約のうち、保護すべき情報の取扱いを含む契約が対象です。該当情報を扱う下請・孫請企業にも、特約条項に基づく対策が求められます。NIST SP 800-171 と同等の水準を掲げ、ログの自動取得と横断分析、常時監視、事故等対処計画と迅速な報告、年1回以上の監査を規定しています。常時監視と、検知時の確認・対処を継続できる体制を、対象システムと契約条件に応じて設計することが重要です。

これらの要件は、機器や文書を整えるだけでは満たせません。アラートを見て判断し、分析の結果を記録し、報告できる状態を、夜間・休日を含めて維持し続けることが問われます。人材とコストに制約のある中堅製造業にとって、AIエージェントによる調査の自動化と証跡の自動生成は、この運用を現実的な工数で回すための有力な選択肢になりつつあります。自社の契約と対象範囲の棚卸しから始め、運用の証跡が残る体制へと段階的に整備していくことをお勧めします。

関連サービス：EDR・SIEMのアラートをAIエージェントが24時間365日自律的に調査・対処し、防衛省基準が求める常時監視と分析証跡の維持を支える「ヤグラAI SOC」の詳細はこちら。

参考・出典

ヤグラAIセキュリティ

丸わかり資料を

無料でダウンロード

生成AI時代に求められるサイバー環境の変化や

サービスの概要資料についてお送りいたします。

Yaguraの全貌がわかる

資料ダウンロード

ヤグラAIセキュリティ

丸わかり資料を

無料でダウンロード

生成AI時代に求められるサイバー環境の変化やサービスの概要資料についてお送りいたします。

Yaguraの全貌がわかる

資料ダウンロード

ヤグラAIセキュリティ

丸わかり資料を

無料でダウンロード

生成AI時代に求められるサイバー環境の変化やサービスの概要資料についてお送りいたします。

Yaguraの全貌がわかる

資料ダウンロード