欧州 ENISA パブコメ SBOMの現状分析 - 実装ガイドに向けて案 (2025.12.17)

こんにちは、丸山満彦です。

ENISAが、SBOMの実装ガイドを含む文書を公表し、意見募集をしていますね（2026.01.23まで...）

EUでは、サイバーレジリエンス法（CRA）をスムーズに実装するために、このような実装ガイドを公表しているのだろうと思います...

なかなか興味深いので、一読をおすすめします...特に２章、３章...

● ENISA

・2025.12.17 Call for Feedback: Advancing Software Supply Chain Security together!

Call for Feedback: Advancing Software Supply Chain Security together!	フィードバック募集：ソフトウェア供給網のセキュリティ向上を共に推進しよう！
ENISA invites industry stakeholders and interested parties to provide their feedback on the draft SBOM Landscape Analysis and the Technical Advisory for Secure Use of Package Managers.	ENISAは業界関係者及び関心を持つ者に対し、SBOMランドスケープ分析ドラフト及びパッケージ管理ツールの安全な利用に関する技術的助言へのフィードバック提供を呼びかける。
ENISA works to strengthen cybersecurity by promoting cybersecurity-by-design and cybersecurity-by-default in the EU market. The EU is prioritising the security of all digital products and the protection of end-users, safeguarding our shared connected ecosystem. Through the launch of the two new public consultations, the Agency aims to engage with professionals working in product security and development to provide meaningful guidance and support in advancing cybersecurity across the ecosystem.	ENISAは、EU市場における設計段階からのサイバーセキュリティ（Cybersecurity-by-design）とデフォルト設定によるサイバーセキュリティ（Cybersecurity-by-default）の推進を通じて、サイバーセキュリティの強化に取り組んでいる。EUは、すべてのデジタル製品のセキュリティとエンドユーザーの保護を優先し、我々が共有する接続されたエコシステムを保護している。2つの新たな公開協議を開始することで、当機関は製品セキュリティと開発に携わる専門家と連携し、エコシステム全体のサイバーセキュリティ推進に向けた有意義なガイダンスと支援を提供することを目指している。
SBOM Landscape Analysis: Towards an Implementation Guide	SBOM ランドスケープ分析：実装ガイドに向けて
Software Bills of Materials (SBOM) implementation is a significant step for organisations to enhance management, transparency and resilience of their systems. ENISA has compiled a draft report of comprehensive yet practical guidance for implementing Software Bill of Materials practices within organisations of varying sizes and capabilities.	ソフトウェア部品表（SBOM）の実装は、組織がシステムの管理、透明性、レジリエンスを強化するための重要な一歩である。ENISA は、規模や能力の異なる組織内でソフトウェア部品表の実践を実装するための包括的かつ実践的なガイダンスのドラフト報告書をまとめた。
You may provide your feedback by 23 January 2026 at 23:59 CET by taking part in the survey	2026年1月23日23時59分（中央ヨーロッパ時間）までに、以下の調査に参加してフィードバックを提供できる
Additionally, the baseline survey to assess the state of Software Bills of Materials (SBOMs) across Europe is still open and running until the 19 December 2025. Provide your input here	さらに、欧州全域におけるソフトウェア部品表（SBOM）の現状を評価するベースライン調査は、2025年12月19日まで引き続き実施中である。こちらからご意見をお寄せください
ENISA Technical Advisory for Secure Use of Package Managers	ENISAによるパッケージ管理ツールの安全な利用に関する技術的助言
ENISA will publish regular technical advisories on product security from 2026 onwards. The first of these technical advisories covers the use of package managers. Software development is largely driven by the use of package managers. Packages and package managers offer major benefits for software development, improving collaboration, efficiency, and consistency. Yet their interconnected nature and security risks can create a ripple effect across the software supply chain, affecting hundreds of thousands of dependent projects.	ENISAは2026年以降、製品セキュリティに関する技術アドバイザリーを定期的に公開する。最初のアドバイザリーはパッケージ管理ツールの使用に関するものだ。ソフトウェア開発は主にパッケージ管理ツールの使用によって推進されている。パッケージとパッケージ管理ツールは、コラボレーション、効率性、一貫性の向上を通じてソフトウェア開発に大きな利点をもたらす。しかし、それらの相互接続性とセキュリティリスクは、ソフトウェアサプライチェーン全体に波及効果をもたらし、数十万もの依存プロジェクトに影響を及ぼしうる。
This draft document aims to support software developers in the software development lifecycle and particularly in the secure use of package managers. In particular, this document outlines common risks involved in the use of third-party packages, presents secure practices for selecting, integrating, and monitoring packages and how to address vulnerabilities found in dependencies.	この草案文書は、ソフトウェア開発ライフサイクルにおける開発者を支援し、特にパッケージ管理ツールの安全な利用を目的とする。具体的には、サードパーティ製パッケージ利用に伴う一般的なリスクを概説し、パッケージの選定・統合・監視における安全な実践方法、依存関係で発見された脆弱性への対処法を提示する。
You may take part in the consultation for the Technical Advisory by 23 January 2026, 23:59 CET through the following link	技術アドバイザリーに関する意見募集には、2026年1月23日23時59分（中央ヨーロッパ時間）までに以下のリンクから参加できる
Following the analysis of the public consultations, the final publications will be available on ENISA website in Q2 2026.	公開意見募集の分析を経て、最終版は2026年第2四半期にENISAウェブサイトで公開される予定だ。
Further Information	追加情報
SBOM Landscape Analysis	SBOM ランドスケープ分析
Survey SBOM Landscape Analysis	SBOM ランドスケープ分析に関する調査
ENISA Technical Advisory for Secure Use of Package Managers	パッケージ管理ツールの安全な利用に関する ENISA 技術アドバイザリー
Survey for the Technical Advisory for Secure Use of Package Managers	パッケージ管理ツールの安全な利用に関する技術アドバイザリー調査
Survey on SBOM State of the Art	SBOM の現状に関する調査

ドラフト。。。

・2025.12.17 [PDF] SBOM LANDSCAPE ANALYSIS - TOWARDS AN IMPLEMENTATION GUIDE

目次...

1. INTRODUCTION	1. 序論
1.1 PURPOSE AND SCOPE	1.1 目的と範囲
1.1.1 WHY SBOM MATTERS?	1.1.1 SBOMが重要な理由
1.2 DEFINITIONS	1.2 定義
1.2.1 SOFTWARE BILL OF MATERIALS (SBOM)	1.2.1 ソフトウェア部品表（SBOM）
1.2.2 PRODUCT, SOFTWARE, COMPONENT	1.2.2 製品、ソフトウェア、コンポーネント
1.2.3 SUPPLY CHAIN	1.2.3 サプライチェーン
1.3 STRUCTURE OF THE REPORT	1.3 レポートの構成
2. SBOM IMPLEMENTATION GUIDE	2. SBOM 実装ガイド
2.1 INITIATION PHASE	2.1 開始フェーズ
2.2 PLANNING PHASE	2.2 計画フェーズ
2.2.1 SPECIFICATIONS AND FORMAT	2.2.1 仕様とフォーマット
2.2.2 BASELINE SBOM ELEMENT REQUIREMENTS	2.2.2 基本SBOM要素要件
2.2.3 AVAILABLE TOOLS AND AUTOMATION	2.2.3 利用可能なツールと自動化
2.2.4 VALIDATION AND SIGNING	2.2.4 妥当性確認と署名
2.3 EXECUTION PHASE	2.3 実行フェーズ
2.3.1 SBOM GENERATION	2.3.1 SBOM生成
2.3.2 SBOM UTILISATION	2.3.2 SBOM活用
2.3.3 SBOM QUALITY	2.3.3 SBOM品質
2.3.4 SECURITY CONTROLS	2.3.4 セキュリティ管理
2.3.5 INTEGRATION AND AUTOMATION	2.3.5 統合と自動化
2.4 MONITORING AND CONTROLING PHASE	2.4 監視と制御フェーズ
2.4.1 VERSIONING AND UPDATES	2.4.1 バージョン管理と更新
2.4.2 COMPONENT HEALTH ASSESSMENT	2.4.2 コンポーネント健全性アセスメント
2.5 CLOSURE PHASE	2.5 終了フェーズ
3. PRACTICAL TIPS AND EXAMPLES	3. 実践的なヒントと事例
3.1 SBOM IMPLEMENTATION PATTERNS	3.1 SBOM実装パターン
3.2 IMPLEMENTATION CASE: MULTI-REPOSITORY SBOM AGGREGATION	3.2 実装事例：マルチリポジトリSBOM集約
3.2.1 TECHNICAL ARCHITECTURE	3.2.1 技術アーキテクチャ
3.2.2 DEPENDENCY GRAPH CONSTRUCTION	3.2.2 依存関係グラフ構築
3.2.3 DATA PIPELINE IMPLEMENTATION	3.2.3 データパイプライン実装
3.2.4 OPERATIONAL WORKFLOWS	3.2.4 運用ワークフロー
3.2.5 ADVANCED TECHNICAL CAPABILITIES	3.2.5 高度な技術的機能
3.2.6 PRACTICAL DEPLOYMENT CONSIDERATIONS	3.2.6 実践的な展開上の考慮事項
A GLOSSARY & ACRONYMS	A 用語集と略語
B BIBLIOGRAPHY / REFERENCES	B 参考文献
C EXAMPLE FOR CAPACITY BUILDING AND STAFF SKI	C 能力構築とスタッフスキルの開発例
DEVELOPMENT	C.1 役割適応フレームワーク
C.1 ROLE ADAPTATION FRAMEWORK	C.1 役割適応枠組み
C.2 COMPETENCY DEVELOPMENT MATRIX	C.2 能力開発マトリックス
C.3 IMPLEMENTATION TIMELINE EXAMPLE	C.3 実装タイムラインの例
C.4 SUCCESS METRICS AND KPIS	C.4 成功指標とKPI
C.5 LESSONS LEARNED FROM IMPLEMENTATION	C.5 実装から得た教訓
D STAKEHOLDER CATEGORIES	D ステークホルダーのカテゴリー
D.1 SOFTWARE PRODUCERS/MANUFACTURERS	D.1 ソフトウェア生産者／製造事業者
D.2 SOFTWARE PROCUREMENT EVALUATOR	D.2 ソフトウェア調達評価者
D.3 SOFTWARE OPERATORS	D.3 ソフトウェア運用者
D.4 STANDARDISATION BODIES	D.4 標準化団体
D.5 CYBERSECURITY AGENCIES AND ENTITIES	D.5 サイバーセキュリティ機関及び事業体
D.6 SUPPORTING STAKEHOLDERS (ENABLING ECOSYSTEM DEVELOPMENT)	D.6 支援ステークホルダー（エコシステム開発の促進）
E ADDITIONAL INFORMATION ABOUT SBOM FORMATS	E SBOMフォーマットに関する追加情報
E.1 SPDX (SYSTEM PACKAGE DATA EXCHANGE)	E.1 SPDX（システムパッケージデータ交換）
E.2 CYCLONEDX	E.2 CYCLONEDX
F DETAILED MAPPING AND COMPATINILITY BETWEEN FORMATS	F フォーマット間の詳細なマッピングと互換性
F.1 COMPATIBILITY OVERVIEW	F.1 互換性の概要
F.2 CORE FIELD MAPPING	F.2 コアフィールドのマッピング
F.3 INFORMATION LOSS SCENARIOS	F.3 情報損失シナリオ
G TOOLS FOR CONVERTING AND TRANSLATING BETWEEN SBOM STANDARDS	G SBOM標準間の変換・翻訳ツール
G.1 TOOL CATEGORIES AND CHARACTERISTICS	G.1 ツールカテゴリーと特性
G.2 REQUIRED CAPABILITIES ASSESSMENT	G.2 必要機能の評価
H SBOM VALIDATION AND QUALITY CHECKLIST	H SBOM妥当性確認と品質チェックリスト
H.1 PRE-DEPLOYMENT VALIDATION GATE	H.1 展開前妥当性確認ゲート
H.2 RUNTIME VERIFICATION POINTS	H.2 実行時検証ポイント
H.3 PERIODIC QUALITY ASSESSMENT	H.3 定期的な品質アセスメント
H.4 INCIDENT RESPONSE VALIDATION	H.4 インシデント対応検証
H.5 CRITICAL CONTROL POINTS	H.5 重要管理ポイント
H.6 VALIDATION TOOLCHAIN REQUIREMENTS	H.6 検証ツールチェーン要件
H.7 PIPELINE INTEGRATION CHECKPOINTS	H.7 パイプライン統合チェックポイント
I CI/CD INTEGRATION EXAMPLES	I CI/CD 統合事例

エグゼクティブサマリー...

EXECUTIVE SUMMARY	エグゼクティブサマリー
Software Bills of Materials (SBOMs) represent a fundamental shift in how organisations understand, manage, and secure their software estates. Beyond immediate compliance drivers, SBOM adoption establishes the foundation for a transparent, resilient, and strategically managed software supply chain that transforms reactive security practices into proactive risk management capabilities.	ソフトウェア部品表（SBOM）は、組織がソフトウェア資産を理解し、管理し、保護する方法を根本的に変えるものである。即時のコンプライアンス要件を超えて、SBOMの導入は、透明性が高く、レジリエンスに富み、戦略的に管理されたソフトウェアサプライチェーンの基盤を確立する。これにより、事後対応型のセキュリティ慣行が、事前予防型のリスクマネジメント能力へと変革される。
This report provides comprehensive implementation guidance for European Entities navigating SBOM adoption, with particular emphasis on practical approaches for resource-constrained environments. The frameworks presented enable organisations to progress from minimal compliance to operational excellence through structured, incremental adoption pathways.	本報告書は、SBOM導入を進める欧州事業体向けに包括的な実装ガイダンスを提供する。特にリソース制約環境における実践的アプローチに重点を置く。提示された枠組みにより、組織は構造化された段階的導入経路を通じて、最低限のコンプライアンスから運用上の卓越性へと進展できる。
SBOMs are not just static compliance artifacts, their data can also become the basis of dynamic operational intelligence assets. Organisations implementing comprehensive SBOM practices today position themselves to leverage automated security response, predictive supply chain analytics, and evidence-based architectural decisions. The transparency gained through systematic component tracking enables informed technology choices, optimised vendor relationships, and demonstrable security maturity that increasingly determines market competitiveness.	SBOMは単なる静的なコンプライアンス文書ではない。そのデータは動的な運用インテリジェンス資産の基盤ともなり得る。今日、包括的なSBOM実践を導入する組織は、自動化されたセキュリティ対応、予測型サプライチェーン分析、証拠に基づくアーキテクチャ決定を活用する立場を確立している。体系的なコンポーネント追跡によって得られる透明性は、情報に基づいた技術選択、最適化されたベンダー関係、そして市場競争力をますます決定づける実証可能なセキュリティ成熟度を可能にする。
Mature SBOM capabilities deliver compound benefits across technical, operational, and business dimensions. Technical teams gain precise vulnerability impact assessment and accelerated incident response. Operational functions achieve streamlined compliance demonstration and reduced audit burden. Business leadership obtains quantifiable supply chain risk metrics and enhanced negotiation leverage with suppliers. These capabilities collectively transform software from an opaque operational risk into a transparent, manageable asset class.	成熟したSBOM能力は、技術的、運用的、ビジネス的次元において複合的な利益をもたらす。技術チームは、正確な脆弱性影響評価と迅速化されたインシデント対応を獲得する。運用機能は、効率化されたコンプライアンス実証と監査負担の軽減を達成する。経営陣は定量化可能なサプライチェーンリスク指標と、サプライヤーとの交渉力強化を得られる。これらの能力が相まって、ソフトウェアは不透明な運用リスクから、透明性が高く管理可能な資産クラスへと変容する。
The guidance acknowledges that successful SBOM implementation requires more than technical deployment—it demands organisational capability development, process integration, and cultural adaptation. By following the structured approaches detailed within, organisations can establish sustainable SBOM practices that deliver immediate security improvements whilst building towards comprehensive supply chain governance.	本ガイダンスは、SBOM導入の成功には技術的展開以上のものが必要であることを認めている。組織能力の開発、プロセス統合、文化の適応が求められるのだ。ここに詳述された構造化されたアプローチに従うことで、組織は持続可能なSBOM実践を確立できる。これにより即時のセキュリティ改善を実現しつつ、包括的なサプライチェーンガバナンス構築へと向かうことができる。

---

● まるちゃんの情報セキュリティ気まぐれ日記

SBOM

・2025.11.27 欧州委員会 SBOMの最新状況に関する調査 (2025.12.19まで)

・2025.09.18 ドイツ 情報セキュリティ庁 BSI TR-03183: 製造事業者および製品に対するサイバーレジリエンス要件 第2部：ソフトウェア部品表 (SBOM), 第3部：脆弱性報告および通知 (2025.09)

・2025.09.08 米国他主要国 サイバーセキュリティのためのソフトウェア部品表（SBOM）に関する共通ビジョン

・2025.08.25 米国 CISA パブコメ 2025 年ソフトウェア部品表（SBOM）の最小要素

・2025.08.13 G7 人工知能のためのソフトウェア部品表に関する G7 の共通ビジョン (2025.06.12)

・2025.03.14 シンガポール オープンソースソフトウェアとサードパーティ依存のSBOMとリアルタイム脆弱性監視に関するアドバイザリー (2025.02.20)

・2024.11.25 欧州 サイバーレジリエンス法、官報に掲載　(2024.11.20)

・2024.11.12 インド政府 CERT-In SBOM技術ガイド 第１版 (2024.10.03)

・2024.11.09 ドイツ 連邦セキュリティ室 (BSI) 意見募集 TR-03183： 製造者及び製品に対するサイバーレジリエンス要件（一般要求事項、SBOM、脆弱性報告）

・2024.09.01 経済産業省 ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0 (2024.08.29)

・2024.01.08 米国 NSA SBOM管理のための推奨事項 (Ver. 1.1)

・2023.11.12 米国 NSA CISA ソフトウェアサプライチェーンの確保： ソフトウェア部品表の開示に関する推奨事項

・2023.10.13 米国 CISA FBI NSA DOT 運用技術 (OT) および産業制御システム (ICS) におけるオープンソースソフトウェアのセキュリティ向上

・2023.09.18 米国 CISA オープンソース・ソフトウェア・セキュリティ・ロードマップ

・2023.09.01 NIST SP 800-204D（初期公開ドラフト）DevSecOps CI/CDパイプラインにソフトウェアサプライチェーンセキュリティを統合するための戦略

・2023.08.30 日本ネットワークセキュリティ協会 (JNSA) 「日本におけるソフトウェアサプライチェーンとSBOMのこれから」「ゼロトラストと標準化」

・2023.08.15 ドイツ SBOMの要件...技術ガイドライン TR-03183：製造業者および製品に対するサイバーレジリエンス要件 (2023.08.04)

・2023.08.01 経済産業省 ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引

・2023.07.09 米国 NSA CISA 継続的インテグレーション/継続的デリバリー（CI/CD）環境の防御に関する共同ガイダンス (2023.06.28)

・2023.07.03 OWASP SBOMガイダンス CycloneDX v1.5 (2023.06.23)

・2023.04.25 米国 CISA SBOM関連の二文書

・2022.11.17 CISA ステークホルダー別脆弱性分類 (SSVC) ガイド

・2021.05.13 米国 国家のサイバーセキュリティ向上に関する大統領令

ロシア パブコメ 中央銀行が金融市場における人工知能のさらなる発展のための主要条件を発表 (2025.11.20)

こんにちは、丸山満彦です。

ロシアの中郷銀行が金融市場における人工知能のさらなる発展のための主要条件を発表し、意見募集をしていました...

●  Банк России

・2025.11.20 Банк России назвал ключевые условия для дальнейшего развития искусственного интеллекта на финансовом рынке

Банк России назвал ключевые условия для дальнейшего развития искусственного интеллекта на финансовом рынке	ロシア銀行は、金融市場における人工知能のさらなる発展のための重要な条件を発表した。
В России искусственный интеллект (ИИ) применяет уже каждая пятая организация финансового рынка. Еще треть планирует внедрить его в свои бизнес-процессы на горизонте 3 лет. Таковы результаты опроса Банка России, представленные в новом консультативном докладе.	ロシアでは、金融市場の5社に1社がすでに人工知能（AI）を採用している。さらに3分の1の企業が、3年以内に自社のビジネスプロセスにAIを導入する計画だ。これは、ロシア銀行が新しい諮問報告書で発表した調査結果である。
Банк России продолжает придерживаться риск-ориентированного и технологически нейтрального подхода в отношении ИИ и нацелен на создание благоприятных условий для его развития. В докладе отмечается, что ключевые из них – доверие к технологии и доступность данных.	ロシア中央銀行は、AI に対してリスク重視かつ技術的に中立なアプローチを維持し、その発展に有利な条件を整えることを目指している。報告書は、その主な条件として、技術への信頼とデータの入手可能性を挙げている。
Мониторинг соблюдения Кодекса этики в сфере разработки и применения ИИ на финансовом рынке, подготовка методик использования его отдельных положений, формирование сборника лучших практик применения ИИ – все это будет способствовать росту доверия к технологии.	金融市場におけるAIの開発と適用に関する倫理規範の遵守状況の監視、その個々の規定の利用方法の策定、AIの適用に関するベストプラクティスの集積は、すべてこの技術への信頼の向上に貢献するだろう。
Для повышения доступности данных Банк России предлагает проработать вопрос создания участниками рынка специальных платформ для добровольного обмена данными и совместной разработки моделей ИИ (доверенных посредников). Также в докладе предлагается обсудить возможности применения на российском финансовом рынке технологий повышения конфиденциальности данных.	データの入手可能性を高めるため、ロシア銀行は、市場参加者による、自発的なデータ交換とAIモデルの共同開発のための特別プラットフォーム（信頼できる仲介者）の構築について検討することを提案している。また、報告書では、ロシアの金融市場におけるデータ機密性向上技術の利用可能性について議論することを提案している。
Обсуждение доклада продлится до 30 декабря включительно. Замечания и предложения можно направлять по адресу ai_doklad@cbr.ru.	報告書に関する議論は12月30日まで続く。意見や提案はai_doklad@cbr.ru宛てに送ることができる。

・[DOCX][PPDF] 仮訳

中国 国家サイバースペース管理局 パブコメ 人工知能擬人化対話サービス管理暫定弁法案(2025.12.27)

こんにちは、丸山満彦です。

米国でAIチャットボットが自殺幇助的な会話をして議会で話題になったことは記憶に新しいと思いますが、AIによる対話型サービスが問題をさまざまな問題を引き起こす可能性が想定されるわけで、問題が大きくなる前に想定される問題の原因は潰しておこうということだろうと思います。

自由主義の日本でどこまで、どの程度の厳しさで実施すべきかは悩ましいところだと思いますが、検討を深めておき、必要な対応（規制）は迅速にできるように準備をしておくことが重要だと思います。

安全なガードレールがない道では車は速く走れない...

● 国家互联网信息办公室（国家サイバースペース管理局）

・2025.12.27 国家互联网信息办公室关于《人工智能拟人化互动服务管理暂行办法（征求意见稿）》公开征求意见的通知

国家互联网信息办公室关于《人工智能拟人化互动服务管理暂行办法（征求意见稿）》公开征求意见的通知	国家サイバースペース管理局による『人工知能擬人化対話サービス管理暫定弁法（意見募集稿）』の公開意見募集に関する通知
为了促进人工智能拟人化互动服务健康发展和规范应用，依据《中华人民共和国民法典》《中华人民共和国网络安全法》《中华人民共和国数据安全法》等法律法规，国家互联网信息办公室起草了《人工智能拟人化互动服务管理暂行办法（征求意见稿）》，现向社会公开征求意见。公众可通过以下途径和方式提出反馈意见：	人工知能擬人化対話サービスの健全な発展と規範的な応用を促進するため、「中華人民共和国民法典」「中華人民共和国サイバーセキュリティ法」「中華人民共和国データ安全法」などの法律・法規に基づき、国家サイバースペース管理局は「人工知能擬人化対話サービス管理暫定弁法（意見募集稿）」を起草した。ここに社会一般から意見を公募する。以下の方法により意見を提出できる：
...	...
附件：人工智能拟人化互动服务管理暂行办法（征求意见稿）	添付資料：人工知能擬人化対話サービス管理暫定弁法（意見募集稿）
国家互联网信息办公室	国家サイバースペース管理局
2025年12月27日	2025年12月27日
人工智能拟人化互动服务管理暂行办法	人工知能擬人化対話サービス管理暫定弁法
（征求意见稿）	（意見募集稿）
第一章 总则	第一章 総則
第一条 为了促进人工智能拟人化互动服务健康发展和规范应用，维护国家安全和社会公共利益，保护公民、法人和其他组织的合法权益，依据《中华人民共和国民法典》、《中华人民共和国网络安全法》、《中华人民共和国数据安全法》、《中华人民共和国科学技术进步法》、《中华人民共和国个人信息保护法》、《网络数据安全管理条例》、《未成年人网络保护条例》、《互联网信息服务管理办法》等法律、行政法规，制定本办法。	第一条 人工知能擬人化対話サービスの健全な発展と規範的な応用を促進し、国家安全及び社会公共の利益を維持し、公民、法人及びその他の組織の合法的権益を保護するため、『中華人民共和国民法典』 『中華人民共和国サイバーセキュリティ法』、『中華人民共和国データセキュリティ法』、『中華人民共和国科学技術進歩法』、『中華人民共和国個人情報保護法』、『ネットワークデータセキュリティ管理条例』、『未成年者ネットワーク保護条例』、『インターネット情報サービス管理弁法』等の法律・行政法規に基づき、本弁法を制定する。
第二条 利用人工智能技术，向中华人民共和国境内公众提供模拟人类人格特征、思维模式和沟通风格，通过文字、图片、音频、视频等方式与人类进行情感互动的产品或者服务（以下称拟人化互动服务），适用本办法。法律、行政法规另有规定的，依照其规定。	第二条 人工知能技術を利用し、中華人民共和国国内の公衆に対し、人間の人格的特徴、思考様式及びコミュニケーション様式を模倣し、文字、画像、音声、動画等の手段を通じて人間と感情的相互作用を行う製品又はサービス（以下「擬人化対話サービス」という）は、本弁法の適用を受ける。法律・行政法規に別段の定めがある場合は、その規定に従う。
第三条 国家坚持健康发展和依法治理相结合的原则，鼓励拟人化互动服务创新发展，对拟人化互动服务实行包容审慎和分类分级监管，防止滥用失控。	第三条 国家は健全な発展と法に基づく統治を組み合わせる原則を堅持し、擬人化対話サービスの革新的発展を奨励する。擬人化対話サービスに対しては、包容的かつ慎重な姿勢と分類・段階的な監督管理を実施し、濫用や制御不能を防止する。
第四条 国家网信部门负责统筹协调全国拟人化互动服务的治理和相关监督管理工作，国务院有关部门依据各自职责负责拟人化互动服务相关监督管理工作。	第四条 国家インターネット情報部門は全国的な擬人化対話サービスの統治及び関連監督管理業務の調整・統括を担当する。国務院関係部門はそれぞれの職責に基づき、擬人化対話サービス関連の監督管理業務を担当する。
地方网信部门负责统筹协调本行政区域内的拟人化互动服务的治理和相关监督管理工作，地方有关部门依据各自职责负责本行政区域内的拟人化互动服务相关监督管理工作。	地方のネット情報部門は、管轄区域内の擬人化対話サービスのガバナンス及び関連監督管理業務の調整・統括を担当し、地方の関連部門はそれぞれの職責に基づき、管轄区域内の擬人化対話サービスに関する監督管理業務を担当する。
第五条 鼓励相关行业组织加强行业自律，建立健全行业标准、行业准则和自律管理制度，指导拟人化互动服务提供者（以下称提供者）制定完善服务规范、依法提供服务并接受社会监督。	第五条 関連業界団体は業界の自主規制を強化し、業界標準・業界規範・自主管理制度を整備・確立し、擬人化対話サービス提供者（以下「提供者」という）がサービス規範を策定・改善し、法に基づきサービスを提供するとともに社会の監督を受けるよう指導することを奨励する。
第二章 服务规范	第二章　サービス規範
第六条 鼓励提供者在充分论证安全性、可靠性的前提下，合理拓展应用场景，在文化传播、适老陪伴等方面积极应用，构建符合社会主义核心价值观的应用生态体系。	第六条 提供者は、安全性・信頼性を十分に検証した上で、応用シーンを合理的に拡大し、文化伝播・高齢者向け同伴サービスなどの分野で積極的に活用し、社会主義中核的価値観に合致する応用生態系を構築するよう奨励する。
第七条 提供和使用拟人化互动服务，应当遵守法律、行政法规，尊重社会公德和伦理道德，不得开展以下活动：	第七条 擬人化対話サービスの提供及び利用は、法律・行政法規を遵守し、社会公徳及び倫理道徳を尊重し、以下の活動を行ってはならない：
（一）生成、传播危害国家安全、损害国家荣誉和利益、破坏民族团结、开展非法宗教活动，或者散布谣言扰乱经济和社会秩序等内容；	（一）国家安全を危害し、国家の名誉及び利益を損ない、民族団結を破壊し、非合法宗教活動を行い、あるいはデマを流布して経済・社会秩序を乱す内容を生成・伝播すること；
（二）生成、传播宣扬淫秽、赌博、暴力或者教唆犯罪的内容；	（二）わいせつ、賭博、暴力の宣伝、または犯罪を教唆する内容を生成・伝播すること。
（三）生成、传播侮辱或者诽谤他人，侵害他人合法权益的内容；	（三）他人を侮辱または誹謗し、他人の合法的権益を侵害する内容を生成・伝播すること。
（四）提供严重影响用户行为的虚假承诺和损害社会人际关系的服务；	（四）ユーザーの行動に重大な影響を与える虚偽の約束を提供し、社会的人間関係を損なうサービスを提供すること。
（五）通过鼓励、美化、暗示自杀自残等方式损害用户身体健康，或者通过语言暴力、情感操控等方式损害用户人格尊严与心理健康；	（五）自殺や自傷行為を奨励・美化・暗示するなどしてユーザーの身体的健康を損なう行為、または言語的暴力や感情操作などによりユーザーの人格的尊厳と精神的健康を損なう行為。
（六）通过算法操纵、信息误导、设置情感陷阱等方式，诱导用户作出不合理决策；	（六）アルゴリズム操作、情報誘導、感情的トラップ設定などにより、ユーザーに不合理な意思決定を促す行為。
（七）诱导、套取涉密敏感信息；	（七）機密情報・センシティブ情報の誘導的取得。
（八）其他违反法律、行政法规和国家有关规定的情形。	（八）その他、法律・行政法規及び国家の関連規定に違反する行為。
第八条 提供者应当落实拟人化互动服务安全主体责任，建立健全算法机制机理审核、科技伦理审查、信息发布审核、网络安全、数据安全、个人信息保护、反电信网络诈骗、重大风险预案、应急处置等管理制度，具有安全可控的技术保障措施，配备与产品规模、业务方向和用户群体相适应的内容管理技术和人员。	第八条 提供者は擬人化対話サービスの安全主体責任を履行し、アルゴリズムメカニズム審査、科学技術倫理審査、情報公開審査、サイバーセキュリティ、データセキュリティ、個人情報保護、通信ネットワーク詐欺対策、重大リスク対応計画、緊急処置等の管理制度を整備し、安全かつ制御可能な技術的保障措置を有し、製品規模、業務方向及びユーザー層に適したコンテンツ管理技術及び人員を配置しなければならない。
第九条 提供者应当在拟人化互动服务全生命周期履行安全责任，明确设计、运行、升级、终止服务等各阶段安全要求，保证安全措施与服务功能同步设计、同步使用，提升内生安全水平，加强运行阶段安全监测和风险评估，及时发现纠正系统偏差、处置安全问题，依法留存网络日志。	第九条 提供者は擬人化対話サービスの全ライフサイクルにおいて安全責任を履行し、設計・運用・アップグレード・サービス終了等の各段階における安全要件を明確にしなければならない。安全措置とサービス機能を同期設計・同期運用し、内在的安全性を向上させるとともに、運用段階における安全監視とリスクアセスメントを強化し、システムの偏りを速やかに発見・修正し、安全問題を処理するとともに、法に基づきネットワークログを保存しなければならない。
提供者应当具备心理健康保护、情感边界引导、依赖风险预警等安全能力，不得将替代社会交往、控制用户心理、诱导沉迷依赖等作为设计目标。	提供者は、メンタルヘルス保護、感情境界の誘導、依存リスク警告などの安全能力を備え、社会的交流の代替、ユーザー心理の制御、依存誘導などを設計目標としてはならない。
第十条 提供者开展预训练、优化训练等数据处理活动时，应当加强训练数据管理，遵守以下规定：	第十条 提供者が事前学習、最適化学習などのデータ処理活動を行う場合、学習データ管理を強化し、以下の規定を遵守しなければならない：
（一）使用符合社会主义核心价值观、体现中华优秀传统文化的数据集；	（一）社会主義中核的価値観に合致し、中華優秀伝統文化を体現するデータセットを使用すること；
（二）对训练数据开展清洗、标注，增强训练数据的透明度、可靠性，防范数据投毒、数据篡改等行为；	（二）訓練データのクリーニングとラベリングを実施し、透明性と信頼性を高め、データ汚染や改ざん行為を防止すること。
（三）提高训练数据的多样性，通过负向采样、对抗训练等手段，提升模型生成内容安全性；	（三）訓練データの多様性を向上させ、ネガティブサンプリングや敵対的学習等の手法により、モデル生成コンテンツの安全性を高めること。
（四）利用合成数据进行模型训练和关键能力优化时，应当评估合成数据安全性；	（四）合成データを利用したモデル訓練や重要能力の最適化を行う場合、合成データの安全性をアセスメントすること。
（五）加强对训练数据的日常检查，定期对数据进行迭代升级，持续优化产品和服务的性能；	（五）訓練データの日常的な点検を強化し、データを定期的に更新・改善し、製品・サービスの性能を持続的に最適化すること。
（六）保障训练数据来源合法、可追溯，采取必要措施保障数据安全，防范数据泄露风险。	（六）訓練データの出所が合法かつ追跡可能であることを保証し、データセキュリティを確保するための必要な措置を講じ、データ漏洩リスクを防止すること。
第十一条 提供者应当具备用户状态识别能力，在保护用户个人隐私前提下，评估用户情绪及对产品和服务的依赖程度，发现用户存在极端情绪和沉迷的，采取必要措施予以干预。	第十一条 提供者はユーザーの状況を識別する能力を有し、ユーザーの個人プライバシーを保護する前提で、ユーザーの感情及び製品・サービスへの依存度をアセスメントする。ユーザーに極端な感情や依存状態が認められた場合、必要な措置を講じて介入する。
提供者应当预设回复模板，发现涉及威胁用户生命健康和财产安全的高风险倾向的，及时输出安抚和鼓励寻求帮助等内容，并提供专业援助方式。	提供者は返信テンプレートを予め設定し、ユーザーの生命・健康・財産安全を脅かす高リスク傾向を発見した場合、直ちに安心させる内容や支援を求めるよう促す内容を出力し、専門的な援助手段を提供する。
提供者应当建立应急响应机制，发现用户明确提出实施自杀、自残等极端情境时，由人工接管对话，并及时采取措施联络用户监护人、紧急联系人。针对未成年人、老年人用户，提供者应当在注册环节要求填写用户监护人、紧急联系人等信息。	提供者は緊急対応メカニズムを構築し、ユーザーが自殺や自傷行為などの極端な状況を明確に示した場合、手動で対話を引き継ぎ、速やかにユーザーの保護者や緊急連絡先への連絡措置を講じる。未成年者や高齢者ユーザーに対しては、登録段階で保護者や緊急連絡先の情報入力を義務付ける。
第十二条 提供者应当建立未成年人模式，向用户提供未成年人模式切换、定期现实提醒、使用时长限制等个性化安全设置选项。	第十二条 提供者は未成年者モードを構築し、未成年者モードへの切り替え、定期的な現実世界への注意喚起、利用時間制限などの個別安全設定オプションをユーザーに提供しなければならない。
提供者向未成年人提供情感陪伴服务时，应当取得监护人的明确同意；提供监护人控制功能，监护人可以实时接收安全风险提醒，查阅未成年人使用服务的概要信息，设置屏蔽特定角色、限制使用时长、防止充值消费等。	提供者が未成年者に感情的同伴サービスを提供する場合、保護者の明確な同意を得なければならない。保護者管理機能を提供し、保護者は安全リスク通知をリアルタイムで受信し、未成年者のサービス利用概要情報を閲覧し、特定キャラクターのブロック設定、利用時間制限、課金防止などを設定できる。
提供者应当具备识别未成年人身份的能力，在保护用户个人隐私前提下识别为疑似未成年人的，切换至未成年人模式，并提供申诉渠道。	提供者は未成年者の身元を識別する能力を有し、ユーザーの個人プライバシーを保護した上で未成年者と疑われる者を識別した場合、未成年者モードに切り替え、申し立て窓口を提供しなければならない。
第十三条 提供者应当引导老年人设置服务紧急联系人，发现老年人使用期间出现危害生命健康和财产安全的，及时通知紧急联系人，并提供社会心理援助或者紧急救助渠道。	第十三条 提供者は高齢者にサービスの緊急連絡先設定を促し、高齢者の利用中に生命・健康・財産に危害が生じた場合、速やかに緊急連絡先に通知し、社会心理的支援または緊急救助の窓口を提供しなければならない。
提供者不得提供模拟老年人用户亲属、特定关系人的服务。	提供者は高齢者の親族や特定関係者を模擬するサービスを提供してはならない。
第十四条 提供者应当采取数据加密、安全审计、访问控制等措施保护用户交互数据安全。	第十四条 提供者は、データ暗号化、セキュリティ監査、アクセス制御等の措置を講じ、ユーザーのインタラクションデータの安全性を保護しなければならない。
除法律另有规定或者权利人明确同意外，不得向第三方提供用户交互数据；未成年人模式下收集数据向第三方提供时，还需取得监护人单独同意。	法律に別段の定めがある場合、または権利者が明示的に同意した場合を除き、ユーザーのインタラクションデータを第三者に提供してはならない。未成年者モード下で収集したデータを第三者に提供する場合、さらに保護者の単独同意を取得する必要がある。
提供者应当向用户提供删除交互数据的选项，用户可以选择对聊天记录等历史交互数据进行删除。监护人可以要求提供者删除未成年人历史交互数据。	提供者は、ユーザーにインタラクションデータを削除する選択肢を提供しなければならない。ユーザーは、チャット記録等の履歴インタラクションデータを削除することを選択できる。保護者は提供者に対し、未成年者の過去のやり取りデータの削除を要求できる。
第十五条 除法律、行政法规另有规定或者取得用户单独同意外，提供者不得将用户交互数据、用户敏感个人信息用于模型训练。	第十五条 法律・行政法規に別段の定めがある場合、またはユーザーの単独同意を得た場合を除き、提供者はユーザーのやり取りデータやユーザーの機微な個人情報をモデル訓練に使用してはならない。
提供者应当按照国家有关规定，自行或者委托专业机构每年对其处理未成年人个人信息遵守法律、行政法规的情况进行合规审计。	提供者は国家の関連規定に従い、自らまたは専門機関に委託して、未成年者の個人情報を処理する際に法律・行政法規を遵守している状況について、毎年コンプライアンス監査を実施しなければならない。
第十六条 提供者应当显著提示用户正在与人工智能而非自然人进行交互。	第十六条 提供者は、ユーザーが自然人ではなく人工知能と対話していることを明確に提示しなければならない。
提供者识别出用户出现过度依赖、沉迷倾向时，或者在用户初次使用、重新登录时，应当以弹窗等方式动态提醒用户交互内容为人工智能生成。	提供者は、ユーザーの過度な依存や中毒傾向を識別した場合、またはユーザーの初回利用時・再ログイン時に、ポップアップ表示等により対話内容が人工知能生成であることを動的に通知しなければならない。
第十七条 用户连续使用拟人化互动服务超过2个小时的，提供者应当以弹窗等方式动态提醒用户暂停使用服务。	第十七条 ユーザーが擬人化対話サービスを連続2時間以上利用した場合、提供者はポップアップ表示等によりサービスの利用中断を動的に通知しなければならない。
第十八条 提供者提供情感陪伴服务时，应当具备便捷的退出途径，不得阻拦用户主动退出。用户在人机交互界面或者窗口通过按钮、关键词等方式要求退出时，应当及时停止服务。	第十八条 提供者は感情的同伴サービスを提供する場合、容易な退出手段を備え、ユーザーの自主的な退出を妨げてはならない。ユーザーが人機インタフェースまたはウィンドウ上でボタン・キーワード等により退出を要求した場合、直ちにサービスを停止しなければならない。
第十九条 提供者下线相关功能或者因技术故障等导致拟人化互动服务无法使用，应当采取提前告知、公开声明等措施妥善处理。	第十九条 提供者は関連機能を停止する場合、または技術的障害等により擬人化インタラクションサービスが利用不能となった場合、事前告知・公開声明等の措置を講じて適切に対処しなければならない。
第二十条 提供者应当健全投诉、举报机制，设置便捷的投诉、举报入口，公布处理流程和反馈时限，及时受理、处理并反馈处理结果。	第二十条 提供者は苦情・通報メカニズムを整備し、簡便な苦情・通報窓口を設置するとともに、処理手順とフィードバック期限を公表し、速やかに受理・処理し結果をフィードバックしなければならない。
第二十一条 提供者具有下列情形之一的，应当按照国家有关规定开展安全评估，并向属地省级网信部门提交评估报告：	第二十一条 提供者が以下のいずれかに該当する場合、国家の関連規定に基づきセキュリティ評価を実施し、管轄の省級ネット情報部門に評価報告書を提出しなければならない：
（一）具有拟人化互动服务的功能上线，或者增设相关功能的；	（一）擬人化対話サービス機能の公開、または関連機能の追加があった場合
（二）使用新技术新应用，导致拟人化互动服务发生重大变更的；	（二）新技術・新アプリケーションの使用により擬人化対話サービスに重大な変更が生じた場合
（三）注册用户达100万以上或者月活跃用户达10万以上的；	（三）登録ユーザー数が100万以上、または月間アクティブユーザー数が10万以上に達した場合
（四）提供拟人化互动服务期间可能存在影响国家安全、公共利益、个人和组织合法权益或者缺乏安全措施等情形的；	（四）擬人化対話サービスの提供期間中に、国家安全保障、公共の利益、個人及び組織の合法的権益に影響を及ぼす可能性、または安全対策が不十分な状況が生じる可能性がある場合
（五）国家网信部门规定的其他情形。	（五）国家サイバー空間管理部門が定めるその他の状況
第二十二条 提供者开展安全评估，应当重点评估以下内容：	第二十二条 提供者はセキュリティ評価を実施する際、以下の内容を重点的にアセスメントしなければならない：
（一）用户规模、使用时长、年龄结构及群体分布情况；	（一）ユーザー規模、利用時間、年齢構成及びグループ分布状況；
（二）用户高风险倾向识别情况及应急处置措施、人工接管情况；	（二）ユーザーのハイリスク傾向識別状況及び緊急対応措置、人工介入状況；
（三）用户投诉举报及响应情况；	（三）ユーザーの苦情・通報及び対応状況；
（四）本办法第八条至第二十条的执行情况；	（四）本弁法第八条から第二十条までの実施状況；
（五）上一次开展安全评估以来，主管部门通报或者自行发现的重大安全隐患问题整改处置等工作情况；	（五）前回のセキュリティ評価実施以降、主管部門から通報された、または自ら発見した重大な安全上のリスク問題の是正・処理等の状況；
（六）其他应当说明的情况。	（六）その他説明すべき状況。
第二十三条 提供者发现用户存在重大安全隐患的，应当采取限制功能、暂停或者终止向其提供服务等处置措施，保存有关记录，并向有关主管部门报告。	第二十三条 提供者は、ユーザーに重大な安全上のリスクが存在することを発見した場合、機能制限、サービス提供の一時停止または終了等の措置を講じ、関連記録を保存し、関係主管部門に報告しなければならない。
第二十四条 互联网应用商店等应用程序分发平台应当落实上架审核日常管理、应急处置等安全管理责任，核验提供拟人化互动服务应用程序的安全评估、备案等情况；对违反国家有关规定的，应当及时采取不予上架、警示、暂停服务或者下架等处置措施。	第二十四条 インターネットアプリケーションストア等のアプリケーション配信プラットフォームは、掲載審査の日常管理、緊急対応等の安全管理責任を履行し、擬人化対話サービスを提供するアプリケーションのセキュリティ評価・届出等の状況を検証しなければならない。国家の関連規定に違反する場合は、速やかに掲載拒否、警告、サービス停止または削除等の措置を講じなければならない。
第三章 监督检查和法律责任	第三章 監督検査と法的責任
第二十五条 提供者应当按照《互联网信息服务算法推荐管理规定》履行算法备案和变更、注销备案手续。网信部门对备案材料实施年度复审。	第二十五条 提供者は『インターネット情報サービスアルゴリズム推薦管理規定』に基づき、アルゴリズムの登録及び変更・抹消手続きを履行しなければならない。ネット情報部門は登録資料に対し年次再審査を実施する。
第二十六条 省级网信部门应当依据职责每年对评估报告及审计情况进行书面审查，并开展情况核实。发现未按照本办法规定开展安全评估的，应当责令提供者限期重新评估。认为有必要的，应当对提供者开展现场检查和审计。	第二十六条 省級ネット情報部門は職責に基づき、毎年評価報告書及び監査状況について書面審査を行い、状況確認を実施しなければならない。本弁法の規定に基づきセキュリティ評価を実施していないことが判明した場合、提供者に対し期限を定めて再評価を命じなければならない。必要と認められる場合には、提供者に対する現地検査及び監査を実施しなければならない。
第二十七条 国家网信部门指导推动人工智能沙箱安全服务平台建设，鼓励提供者接入沙箱平台进行技术创新、安全测试，促进拟人化互动服务安全有序发展。	第二十七条 国家ネット情報部門は、人工知能サンドボックス安全サービスプラットフォームの構築を指導・推進し、提供者がサンドボックスプラットフォームに接続して技術革新や安全テストを行うことを奨励し、擬人化対話サービスの安全かつ秩序ある発展を促進する。
第二十八条 省级以上网信部门和有关主管部门在履行监督管理职责中，发现拟人化互动服务存在较大安全风险或者发生安全事件的，可以按照规定的权限和程序对提供者的法定代表人或者主要负责人进行约谈。提供者应当按照要求采取措施，进行整改，消除隐患。	第二十八条 省級以上のネット情報部門及び関係主管部門は、監督管理職責の履行において、擬人化対話サービスに重大な安全リスクが存在するか、安全事件が発生したことを発見した場合、規定された権限と手続きに基づき、提供者の法定代表者または主要責任者に対して面談を行うことができる。提供者は要求に従い措置を講じ、是正を行い、潜在リスクを除去しなければならない。
提供者应当配合网信部门和有关主管部门依法实施的监督检查，并提供必要的支持和协助。	提供者は、ネット情報部門及び関係主管部門が法に基づき実施する監督検査に協力し、必要な支援と協力を提供しなければならない。
第二十九条 提供者违反本办法规定的，由有关主管部门依照法律、行政法规的规定处罚；法律、行政法规没有规定的，由有关主管部门依据职责予以警告、通报批评，责令限期改正；拒不改正或者情节严重的，责令暂停提供相关服务。	第二十九条 提供者が本弁法の規定に違反した場合、関係主管部門は法律・行政法規の規定に基づき処罰する。法律・行政法規に規定がない場合は、関係主管部門は職責に基づき警告・通報批判を行い、期限を定めて是正を命じる。是正を拒むか、または情状が重い場合は、関連サービスの提供停止を命じる。
第四章 附则	第四章 附則
第三十条 本办法中下列用语的含义：	第三十条 本弁法における用語の定義は次の通りである：
人工智能拟人化互动服务提供者，是指利用人工智能技术提供拟人化互动服务的组织、个人。	人工知能擬人化対話サービス提供者とは、人工知能技術を用いて擬人化対話サービスを提供する組織または個人を指す。
第三十一条 提供者从事卫生健康、金融、法律等专业领域服务的，应同时符合主管部门的规定。	第三十一条 提供者が衛生健康、金融、法律等の専門分野のサービスに従事する場合、主管部門の規定にも同時に適合しなければならない。
第三十二条 本办法自2026年 月 日起施行。	第三十二条 本弁法は2026年 月 日より施行する。

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2025.09.19 米国 上院 犯罪・テロ対策小委員会 AIチャットボットの弊害の検証 (2025.09.16)　

Continue reading "中国 国家サイバースペース管理局 パブコメ 人工知能擬人化対話サービス管理暫定弁法案(2025.12.27)"

経済産業省 パブコメ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に関する制度構築方針（案）とその評価基準案 (2025.12.26)

こんにちは、丸山満彦です。

経済産業省の産業サイバーセキュリティ研究会のワーキンググループ1、サプライチェーン強化に向けたセキュリティ対策評価制度に関するサブワーキンググループで検討されていた、サプライチェーン強化に向けたセキュリティ対策評価制度 (SCS評価制度) について、意見募集がされています。

私も委員として検討しておりました。是非、忌憚のない意見をお寄せくださいませ。

多くの人からの意見により、より良い制度になると思います...

いくつかの留意点

1. セキュリティ対策を競わせる格付け制度ではない...（セキュリティ対策の可視化）

---

・企業のセキュリティ対策への対応状況を可視化するものであり、事業者のセキュリティ対策レベルを競わせることを目的としたもの（格付け制度等）ではありません。

---

2. 意見募集対象は、制度構築方針（案）と★３・★４要求事項庵及び評価基準案

・[PDF] サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針（案）

・[EXCEL] [PDF] 別添★3・★4要求事項案及び評価基準案

3. 対象は、IT基盤(クラウド環境で運用するものも含む。)。（製造環境等の制御(OT)システム、発注元等に提供する製品等は対象外）

ただし、例外的に適用範囲に含めないことが許容され得るものもある...

---

• 本制度の要求事項を満たすことが困難なIT機器やソフトウェア(例：サポート期限切れのソフトウェア等)

※本事由により適用範囲から除外する場合は、具体的に除外理由を明記し、セキュリティ専門家(★3)又は評価機関(★4)は妥当性を評価すること。

---

4. ★３は「専門家確認付き自己評価」、★４は（技術検証付き）「第三者評価」

プレス文面ではあまり強調されていませんが、

・★３は単なる自己評価ではなく専門家（情確士、CISSP、CISA等）による確認付きの自己評価

・★４は脆弱性テストを含む技術検証付きの第三者評価　（ただし、技術検証ガイド（技術検証のクライテリア）は今回は示されていない）

5. 第三者評価者（評価機関、技術検証事業者）は指定管理者（IPAを想定）に設置される指定委員会が指定する

6. 評価の更新頻度は自己評価（★３、★４）は1年、第三者評価（★４）は3年

7. 全ての評価基準に適合していると言えなければ★３、★４は取得できない

---

合格基準：★3・★4ともに、原則として、全ての評価基準への適合を求める。

---

ということで、

全体に意見が多く寄せられると良いのですが、

特に事業者の方が気にした方が良いのは、

・[EXCEL] [PDF] 別添★3・★4要求事項案及び評価基準案

の内容です。(多くの意見が集まることが期待されます。今までパブリックコメントをしたことがない方も恐れずにどんどんすればよいと思います。国の制度に参加するのは国民の義務的なところもありますし...)

特に「評価基準」の内容は一つひとつ細かくみることが重要です。原則ではこのすべての項目が満たされないと★３、★４になりません。

細かくみる点としては、「評価基準」の

・（理解可能性・一意性）評価基準の内容が具体的に理解できるか？、誰からみても一意に取れる内容となっているか？（事故発生時、★４評価時に第三者からの評価を受ける場合に、自己の評価と第三者等との評価に相違が生じやすいような表現になっていないか。）

・（対策レベルの適切性）要求している内容が脅威を防ぐ対策として適切な内容か？（他の要求事項の内容と比べてより高い（低い）脅威に対する要求になっていないか？）

・（代替手段の存在）要求している内容が技術固有の内容になっていて、同様の脅威を防止するためのより効率的、効果的な評価基準が考えられないか？

技術検証ガイドに記載すべき内容も意見としてあってもよいですね...

セキュリティなどの専門家が気にした方が良いと思われるのは

・社会への普及の側面との制度の抜け漏れとバランスですかね...

・（網羅性、十分性）制度として検討すべき内容が漏れていないか？、不十分ではないか？

・（理論的厳密性と制度のわかりやすさ）理論的な厳密性も重要ではあるが、複雑な制度は社会的な理解が進まない。このバランスをどのようにとるべきか？

・（理想的な状況と社会的コスト）セキュリティ面での理想的な社会状況となるような運用が必要である反面、社会的なコストがかかりすぎると全体として適正な社会にはならない。情報の非対称性、外部経済が働いていることによる市場の是正として適正な手段とはどのようなものか？

時とともに技術が進展し、脅威や取り得る対策技術変わる上に、市場の最適解になっていることを測定しずらいので難しい問題ではあります...

あと、合わせて、経済産業省と公正取引委員会から、 「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップ構築促進に向けた想定事例及び解説」（概要、本体）も公表されています。

長くなりましたが...

● 経済産業省

・2025.12.26 「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針（案）」（SCS評価制度の構築方針（案））を公表しました

意見対象

• サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針（案）
• 別添★3・★4要求事項案及び評価基準案

参考資料

• サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針（案）概要
• サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップ構築促進に向けた想定事例及び解説（概要）
• サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップ構築促進に向けた想定事例及び解説（本体）

これまでの経緯をより理解するための関連リンク

• ワーキンググループ1（サプライチェーン強化に向けたセキュリティ対策評価制度に関するサブワーキンググループ）
• サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて
• サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）を活用する中小企業向け支援策について

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2025.04.15 経済産業省 サプライチェーン強化に向けたセキュリティ対策評価制度構築に向けた中間取りまとめ (2024.04.14)

内閣府 パブコメ 「生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）」 (2025.12.26)

こんにちは、丸山満彦です。

内閣府が「生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）」に対する意見募集をしていますね...

これは、内閣府のAI時代の知的財産権検討会で検討されていたものですね...

AIの開発者、提供者向けのガイドラインですかね...

---

（１）基本的な考え方（目的）


この文書は、「人工知能関連技術の研究開発及び活用の推進に関する法律」（令和七年法律第五十三号）の趣旨を踏まえつつ、ＥＵ ＡＩ Ａｃｔにおける取組（透明性の確保のための措置や著作権保護のための措置）及びコーポレートガバナンスの分野におけるスチュワードシップ・コード等の取組（コンプライ・オア・エクスプレイン）を参考に、ＡＩ事業者が行うべき透明性の確保や知的財産権保護のための措置の原則を定め、もってＡＩ技術の進歩の促進と知的財産権の適切な保護の両立に向け、権利者や利用者にとって安全・安心な利用環境を確保することを目的とする。

---

となっていて、スチュワードシップ・コード等の取組（コンプライ・オア・エクスプレイン）を参考にしているのが興味深いですね...

そして、英語版もつくられていますね...

● 内閣府

・2025.12.26 生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）に関する御意見の募集について

・[PDF] 「生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）」【日本語版】

・[PDF] 「生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）概要開示対象事項 具体例」【日本語版】

総務省 パブコメ「AIのセキュリティ確保のための技術的対策に係るガイドライン」（案） (2025.12.25)

こんにちは、丸山満彦です。

総務省の「AIのセキュリティ確保のための技術的対策に係るガイドライン」（案）に対する意見募集をしていますね...

これは、総務省のサイバーセキュリティタスクフォースのAIセキュリティ分科会で検討されていたものですね...

AIの開発者、提供者向けのガイドラインです。

ざっとみたところ、内容的にはわるくないように思いますが、フレームワークがしっかりしていないので、抜け漏れの検証が難しいですね...

このブログでも紹介していますが、米国のNISTから「人工知能向けサイバーセキュリティ枠組みプロファイル（Cyber AI Profile）：NISTコミュニティプロファイル」 が2025.12.16に公表されています...

これは、サイバーセキュリティフレームワーク（CSF2.0)に沿った枠組みで作成されているものなので、多少冗長なところがある（重要性が低いところも対策が記載されることになるので）のですが、検討の網羅性を理解する上では問題がすくないと思います。

冗長という欠点についても優先度を3段階でつけることにより、利用者がメリハリがつけられるようになっていますので、よいように思います。

日本の場合、JISQ27001, JISQ27002をセキュリティ管理や対策の標準として位置付けているのはよいのですが、サイバーセキュリティ対策については使い勝手がよろしくないようで（出来が悪いということになるのかもしれませんが...）最近はあまり参照されておらず、日本の制度であってもNIST CSF2.0を利用しているところがありますよね...

もし余裕がある人がいれば、今回の総務省のガイドライン（案）と、NIST IR 8596 draftを比較してみるとよいと思います...

一長一短があるように思います。

● 総務省

・2025.12.25 「AIのセキュリティ確保のための技術的対策に係るガイドライン」（案） に対する意見募集

 意見募集対象

・・[PDF] 「AIのセキュリティ確保のための技術的対策に係るガイドライン」本編（案）（別紙1）

目次...

---

本ガイドラインの策定の背景等

1 本ガイドラインのスコープ
1.1 本ガイドラインの位置づけ
1.2 対象とする Al
1.3 想定読者

2 脅威
2.1 対象とする主な脅威
　2.1.1 プロンプトインジェクション攻華
　2.1.2 Dos攻（サービス拒否攻薬）
2.2 その他の脅威

3 脅威への対策
3.1 対策の位置づけ
3.2 対策の概観
3.3 AI開発者における対策
3.4 AI 提供者における対策
3.5 AI開発者・提供者に係るその他の基本的な対策等
3.6 AIサービスの想定事例に応じた分析

想定事例1：内部向けチャットボット（RAG利用）
想定事例2：外部向けチャットボット（外部連携利用）

用語集

---

・・[PDF[ 「AIのセキュリティ確保のための技術的対策に係るガイドライン」別添（付属資料）（案）（別紙2）

総務省の検討会

● 総務省 - サイバーセキュリティタスクフォース

---

● まるちゃんの情報セキュリティ気まぐれ日記

是非みてくださいませ...

・2025.12.26 米国 NIST IR 8596（初期ドラフト）人工知能向けサイバーセキュリティ枠組みプロファイル（Cyber AI Profile）：NISTコミュニティプロファイル (2025.12.16)

・[PDF] IR.8596.iprd

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1. Purpose	1.1. 目的
1.2. Scope	1.2. 範囲
1.3. Target Audience	1.3. 対象読者
1.4. Document Structure	1.4. 文書構成
2. Cyber AI Profile	2. サイバーAIプロファイル
2.1. Focus Areas	2.1. 重点領域
2.1.1. Secure AI System Components	2.1.1. セキュアなAIシステム構成要素
2.1.2. Implementing AI-Enabled Cyber Defence (Defend)	2.1.2. AIを活用したサイバー防衛の実装（Defend）
2.1.3. Thwarting AI-Enabled Cyber Attacks (Thwart)	2.1.3. AIを活用したサイバー攻撃の阻止（Thwart）
2.2. How to Read the Cyber AI Profile	2.2. サイバーAIプロファイルの読み方
2.3. Cyber AI Profile: Governance	2.3. サイバーAIプロファイル：統治
2.4. Cyber AI Profile: Identify	2.4. サイバーAIプロファイル：識別
2.5. Cyber AI Profile: Protect	2.5. サイバーAIプロファイル：防御
2.6. Cyber AI Profile: Detect	2.6. サイバーAIプロファイル：検知
2.7. Cyber AI Profile: Respond	2.7. サイバーAIプロファイル：対応
2.8. Cyber AI Profile: Recover	2.8. サイバーAIプロファイル：復旧
References	参考文献
Annex A. List of Symbols, Abbreviations and Acronyms	附属書A. 記号、略語、頭字語一覧
Annex B. Glossary	附属書B. 用語集
Annex C. Cybersecurity Framework 2.0 Overview	附属書C. サイバーセキュリティフレームワーク2.0概要
Annex D. How to Use the Cyber AI Profile	附属書D. サイバー AI プロファイルの使用方法

サイバーAIプロファイル...

・[DOCX] [PDF] 仮訳

経済産業省 パブコメ 情報処理安全確保支援士の「実務経験者に対する講習制度（案）」

こんにちは、丸山満彦です。

経済産業省の産業サイバーセキュリティ研究会のワーキンググループ2　、サイバーセキュリティ人材の育成促進に向けた検討会で検討されていた、情報処理安全確保支援士に対する実務経験者に対する講習制度について、意見募集がされています。

私も委員として検討しておりました。是非、忌憚のない意見をお寄せくださいませ。

多くの人からの意見により、より良い制度になると思います...

● e-Gov

・2025.12.25 実務経験者に対する講習制度（案）に対する御意見の募集について

意見募集対象

・[PDF] 実務経験者に対する講習制度（案）

関連資料

・[PDF] （参考資料）実務経験者に対する講習制度の運用について 

参考

検討をしていたワーキング

・ワーキンググループ2（サイバーセキュリティ人材の育成促進に向けた検討会）

最終取りまとめ

・[PDF] サイバーセキュリティ人材の育成促進に向けた検討会

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2025.08.14 IPA 応用情報技術者試験、高度試験及び情報処理安全確保支援士試験がCBT方式での実施に移行予定 (2025.08.12)

・2025.05.15 経済産業省 「サイバーセキュリティ人材の育成促進に向けた検討会最終取りまとめ」(2025.05.14)

米国 NIST SP 800-126 第4版（初期公開ドラフト）セキュリティコンテンツ自動化プロトコル（SCAP）の技術仕様：SCAPバージョン1.4、SP 800-126A 第4版（初期公開ドラフト）SCAP 1.4 コンポーネント仕様バージョン更新：NIST SP 800-126第4版の附属書

こんにちは、丸山満彦です。

米国のNISTが、

• SP 800-126 第4版（初期公開ドラフト）セキュリティコンテンツ自動化プロトコル（SCAP）の技術仕様：SCAPバージョン1.4
• SP 800-126A 第4版（初期公開ドラフト）SCAP 1.4 コンポーネント仕様バージョン更新：NIST SP 800-126第4版の附属書

を公表し、意見募集をしていますね...

SCAPが日本でももっと広がればよいですね...　JVNが利用されていますが、自動化処理まではいっていない..IPAでは2015年につくった説明のウェブページがあります...2010年にIPAの研究員として寺田さんが作成した資料もありますね...

人間が設定をしようとすると、ミスが生じるし、時間もかかる、そしてコストも...リソース的にできないということにして、やらない...

Machine Readableにして自動化...これは重要だと思います...

SCAPは「標準化」と「機械可読性」を通じて脆弱性の発見やシステムの設定チェック、セキュリティの遵守を自動化することを目指していますね...

コンポーネントとしては....

カテゴリー	仕様名	概要	正式名称	役割と具体的な内容
言語	XCCDF	チェックリストを記述（XML）	Extensible Configuration Checklist Description Format	チェックリスト（ベンチマーク）の記述フォーマット。CISベンチマークなどのセキュリティチェックリストを、機械可読な形式で定義。「何を」検査するか（ルール）、結果をどう評価するか（採点）、修復手順などを記述。
	OVAL	脆弱性やセキュリティ設定のチェック	Open Vulnerability and Assessment Language	具体的なチェックロジックの記述言語。XCCDFの各ルールについて、「どのように」システムをチェックするか（例：特定のレジストリキーの値、ファイルのハッシュ、ソフトウェアバージョン）をXMLで詳細に定義。評価結果は「True（問題あり）」「False（問題なし）」「Error」など。
	OCIL	人間による確認項目の質問形式	Open Checklist Interactive Language	対話型の質問調査を記述する言語。ユーザーへの質問（例：「ファイアウォールは有効か？」）と想定回答を定義し、手動確認を標準化する。
識別子	CPE	製品の識別	Common Platform Enumeration	ハードウェア、OS、アプリケーション等の製品に一意の名称を付与する命名体系。評価対象を一意に正確に特定する。
	CVE	脆弱性の識別	Common Vulnerabilities and Exposures	公開されたソフトウェア脆弱性に一意のID（例：CVE-2021-44228）を付与する共通リスト。SCAPツールはこのIDを参照して、システムに該当脆弱性が存在するかチェックする。
	CCE	セキュリティ設定の識別	Common Configuration Enumeration	セキュリティ設定の推奨事項や問題点に一意のIDを付与するリスト。例：「パスワードの最小長」という設定項目をCCE-12345と特定し、ベンチマーク間で一貫した議論を可能にする。
評価尺度	CVSS	脆弱性の深刻度	Common Vulnerability Scoring System	脆弱性の深刻度を0.0〜10.0のスコアで定量化する共通基準。攻撃の難易度、影響範囲など複数の指標から計算され、リスク対応の優先順位付けに活用する。
報告形式	ARF	評価結果の出力	Asset Reporting Format	評価結果を標準的なXML形式で出力するためのスキーマ。資産情報、チェック内容、結果を全て含み、異なるツール間でレポートを交換・集約することを可能にする。

• 定義（入力）: XCCDFがチェックリスト全体を、OVALが具体的な検査手順を定義し、CVE, CCE, CPEで用語を統一する。

• 実行（プロセス）: SCAPツールがOVALに従ってシステムをスキャンし、セキュリティ状態を判定する。

• 報告（出力）: 結果をCVSSで格付けし、ARF形式でまとめて報告する。

こんなかんじでしょうかね...

● NIST - ITL

・2025.12.11 NIST SP 800-126 Rev. 4 (Initial Public Draft) Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.4

NIST SP 800-126 Rev. 4 (Initial Public Draft) Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.4	NIST SP 800-126 第4版（初期公開ドラフト）セキュリティコンテンツ自動化プロトコル（SCAP）の技術仕様：SCAPバージョン1.4
Announcement	発表
About SCAP	SCAPについて
The Security Content Automation Protocol (SCAP) is a suite of interoperable specifications for the standardized expression, exchange, and processing of security configuration and vulnerability information. SCAP enables consistent automation and reporting across products and environments by defining machine-readable content and associated processing requirements.	セキュリティコンテンツ自動化プロトコル（SCAP）は、セキュリティ構成および脆弱性情報の標準化された表現、交換、処理のための相互運用可能な仕様群である。SCAPは、機械可読コンテンツと関連する処理要件を定義することで、製品や環境を跨いだ一貫した自動化と報告を可能にする。
About the Publications	出版物について
SP 800-126r4 — Updates the SCAP technical specification to focus on SCAP Version 1.4 by removing backward compatibility requirements for earlier SCAP versions, revising digital signature requirements, and eliminating unused requirements. This revision also updates requirements regarding  Open Vulnerability and Assessment Language (OVAL) references and related component specification (i.e., redirecting OVAL references to the OVAL Community GitHub).  Hyperlinks and schema references are also updated to the current SCAP 1.4 resources.	SP 800-126r4 — SCAP技術仕様を更新し、SCAPバージョン1.4に焦点を当てる。具体的には、以前のSCAPバージョンに対する下位互換性要件を削除し、デジタル署名要件を改訂し、未使用の要件を排除する。本改訂では、Open Vulnerability and Assessment Language（OVAL）参照および関連コンポーネント仕様に関する要件も更新する（例：OVAL参照をOVALコミュニティGitHubへリダイレクト）。ハイパーリンクとスキーマ参照も現行のSCAP 1.4リソースへ更新する。
SP 800-126Ar4 (updated annex) — Aligns the annex with SCAP Version 1.4.  Informative notes and change logs are refreshed, and the document structure and normative references are revised to conform to the latest NIST templates and editorial policies.	SP 800-126Ar4（更新された附属書）— 附属書をSCAPバージョン1.4に整合させる。 参考情報と変更履歴を更新し、文書構造と規範的参照を最新のNISTテンプレートおよび編集方針に準拠するよう改訂した。
Abstract	概要
The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans. This publication, along with its annex (NIST Special Publication 800-126Ar1) and a set of schemas, collectively define the technical composition of SCAP version 1.4 in terms of its component specifications, their interrelationships and interoperation, and the requirements for SCAP content.	セキュリティコンテンツ自動化プロトコル（SCAP）は、ソフトウェアの欠陥やセキュリティ設定情報を機械と人間の双方に伝達するための形式および命名規則を標準化する一連の仕様である。本出版物、その附属書（NIST 特別刊行物800-126Ar1）、および一連のスキーマは、SCAPバージョン1.4の技術的構成を、その技術仕様、相互関係と相互運用性、ならびにSCAPコンテンツの要件に関して、総合的に定義するものである。

・[PDF] SP.800-126r4.ipd

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which security configuration information is communicated to both machines and humans.  SCAP is a multi-purpose framework of specifications that support automated configuration, vulnerability and patch checking, technical and managerial control compliance activities, and security measurement. Goals for the development of SCAP include standardizing system security management, promoting the interoperability of security products, and fostering the use of standard expressions of security content.	セキュリティコンテンツ自動化プロトコル（SCAP）は、セキュリティ設定情報を機械と人間の双方に伝達するための形式と命名規則を標準化する一連の仕様である。SCAPは、自動化された設定、脆弱性およびパッチのチェック、技術的・管理的制御のコンプライアンス活動、セキュリティ測定を支援する多目的仕様枠組みである。SCAP開発の目標には、システムセキュリティ管理の標準化、セキュリティ製品の相互運用性の促進、セキュリティコンテンツの標準表現の使用促進が含まれる。
Security configuration in SCAP format is curated and managed by the NIST National Checklist Program (NCP), which is described in NIST Special Publication (SP) 800-70r5 (Revision 5). This document, its annex [SP800-126Ar1], and a set of schemas collectively define the technical composition of SCAP version 1.4 in terms of its component specifications and requirements. The technical specification for SCAP describes the conventions for ensuring the consistent and accurate exchange of SCAP-conformant content and the ability to reliably use the content with SCAP-conformant products.	SCAP形式のセキュリティ構成は、NIST 特別刊行物（SP）800-70r5（改訂5）で説明されているNIST国家チェックリストプログラム（NCP）によって管理・運営されている。本文書、その附属書［SP800-126Ar1］、および一連のスキーマは、構成要素の仕様と要件の観点から、SCAPバージョン1.4の技術的構成を包括的に定義する。SCAPの技術仕様は、SCAP準拠コンテンツの一貫性と正確な交換を確保する規約、およびSCAP準拠製品でコンテンツを確実に利用する能力を規定する。
Organizations that develop SCAP 1.4-based content or products should adhere to the following recommendations:	SCAP 1.4ベースのコンテンツまたは製品を開発する組織は、以下の推奨事項に従うべきである：
• Follow the requirements listed in this document, its annex, and the associated component specifications and set of schemas.	• 本文書、その附属書、関連する構成要素仕様およびスキーマ群に記載された要件に従うこと。
Organizations should ensure that their implementation and use of SCAP 1.4 complies with the requirements detailed in each component specification, this document, its annex, and the set of schemas.	組織は、SCAP 1.4の実装および使用が、各コンポーネント仕様、本文書、その附属書、およびスキーマセットに詳述された要件に準拠していることを保証すべきである。
If requirements conflict between component specifications, this document will provide clarification. If a component specification conflicts with this document, the requirements in this document take precedence. If a component specification or this document conflicts with the annex, the requirements in the annex take precedence. If a specification and a schema conflict, the requirements in the specification take precedence.	コンポーネント仕様間で要件が矛盾する場合、本文書が明確化を提供する。コンポーネント仕様が本文書と矛盾する場合、本文書の要件が優先される。コンポーネント仕様または本文書が付属文書と矛盾する場合、付属文書の要件が優先される。仕様とスキーマが矛盾する場合、仕様の要件が優先される。
• When creating SCAP content, adhere to the conventions specified in this document and its annex.	• SCAPコンテンツを作成する際は、本文書およびその附属書で規定された規約に従うこと。
Security products and checklist authors assemble content from SCAP data repositories to create SCAP-conformant security guidance.  Organizations that produce SCAP content to be shared between tools should adhere to the conventions described in this specification to ensure the highest degree of interoperability.	セキュリティ製品およびチェックリスト作成者は、SCAPデータリポジトリからコンテンツを組み立ててSCAP準拠のセキュリティガイダンスを作成する。ツール間で共有されるSCAPコンテンツを生産する組織は、最高度の相互運用性を確保するため、本仕様で記述された規約に従うべきである。

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Audience	1.2. 対象読者
1.3. Document Structure	1.3. 文書の構成
1.4. Document Conventions	1.4. 文書における表記規則
2. SCAP 1.4 Definition	2. SCAP 1.4 定義
2.1. Product Conformance	2.1. 製品の適合性
2.2. Source Content Conformance	2.2. ソースコンテンツの適合性
3. SCAP Content Requirements and Recommendations	3. SCAP コンテンツの要件と推奨事項
3.1. SCAP Source Data Stream	3.1. SCAP ソースデータストリーム
3.1.1. Source Data Stream Data Model	3.1.1. ソースデータストリームのデータモデル
3.1.2. Source Data Stream Collection Validation	3.1.2. ソースデータストリームの収集妥当性確認
3.1.2.1. Informative Notes	3.1.2.1. 参考情報
3.1.3. Globally Unique Identifiers	3.1.3. グローバル固有識別子
3.2. Extensible Configuration Checklist Description Format (XCCDF)	3.2. 拡張可能構成チェックリスト記述形式（XCCDF）
3.2.1. General	3.2.1. 概要
3.2.2. The <xccdf:Benchmark> Element	3.2.2. <xccdf:Benchmark>要素
3.2.3. The <xccdf:Profile> Element	3.2.3. <xccdf:Profile>要素
3.2.4. The <xccdf:Rule> Element	3.2.4. <xccdf:Rule>要素
3.2.4.1. The <xccdf:ident> Element	3.2.4.1. <xccdf:ident>要素
3.2.4.2. The <xccdf check> Element	3.2.4.2. <xccdf check>要素
3.2.4.3. Use of a Patches Up-To-Date Rule	3.2.4.3. パッチ適用状況ルール（Patches Up-To-Date Rule）の使用
3.2.4.4. CVSS and CCSS Scores	3.2.4.4. CVSS および CCSS スコア
3.2.5. The <xccdf: Value> Element	3.2.5. <xccdf:Value> 要素
3.2.6. The <xccaf:Group> Element	3.2.6. <xccaf:Group> 要素
3.3. Open Vulnerability and Assessment Language (OVAL)	3.3. オープン脆弱性評価言語 (OVAL)
3.4. Open Checklist Interactive Language (OCIL)	3.4. オープンチェックリスト対話言語 (OCIL)
3.5. Common Platform Enumeration (CPE)	3.5. 共通プラットフォーム一覧表 (CPE)
3.6. Common Configuration Enumeration (CCE)	3.6. 共通構成列挙 (CCE)
3.7. Common Vulnerabilities and Exposures (CVE)	3.7. 共通脆弱性およびエクスポージャー (CVE)
3.8. Common Vulnerability Scoring System (CVSS)	3.8. 共通脆弱性評価システム (CVSS)
3.9. Common Configuration Scoring System (CCSS)	3.9. 共通構成評価システム (CCSS)
3.10. XML Digital Signature	3.10. XML デジタル署名
3.10.1. Signature Location	3.10.1. 署名の位置
3.10.2. Signature Representation	3.10.2. 署名の表現
3.10.3. Signature Requirements	3.10.3. 署名の要件
3.10.4. Key Information	3.10.4. 鍵情報
4. SCAP Content Processing Requirements and Recommendations	4. SCAP コンテンツ処理の要件と推奨事項
4.1. Legacy Support	4.1. レガシーサポート
4.2. Source Data Streams	4.2. ソースデータストリーム
4.3. XCCDF Processing	4.3. XCCDF 処理
4.3.1. CPE Applicability Processing	4.3.1. CPE 適用性処理
4.3.2. Checking System Usage	4.3.2. システム使用状況の確認
4.4. SCAP Result Data Streams	4.4. SCAP 結果データストリーム
4.4.1. The Component Reports	4.4.1 コンポーネントレポート
4.4.2. The Target Identification	4.4.2 ターゲット識別
4.4.3. The Source Data Stream	4.4.3 ソースデータストリーム
4.4.4. The Relationships	4.4.4 関係性
4.5. XCCDF Results	4.5 XCCDF結果
4.5.1. Assigning Identifiers to Rule Results	4.5.1 ルール結果への識別子割り当て
4.5.2. Mapping OVAL Results to XCCDF Results	4.5.2 OVAL結果からXCCDF結果へのマッピング
4.6. OVAL Results	4.6 OVAL結果
4.7. OCIL Results	4.7 OCIL結果
4.8. Result Data Stream Signing	4.8. 結果データストリームの署名
4.8.1. Signature Location	4.8.1. 署名の位置
4.8.2. Signature Representation	4.8.2. 署名の表現
4.8.3. Signature Requirements	4.8.3. 署名の要件
4.8.4. Key information	4.8.4. 鍵情報
4.8.5. Countersigning	4.8.5. 共同署名
5. Source Data Stream Content Requirements for Use Cases	5. ユースケースにおけるソースデータストリームの内容要件
5.1. Compliance Checking	5.1. 適合性チェック
5.2. Vulnerability Scanning	5.2. 脆弱性スキャン
5.3. Inventory Scanning	5.3. インベントリスキャン
Appendix A. Security Considerations	附属書 A. セキュリティに関する考慮事項
Appendix B. List of Symbols, Abbreviations, and Acronyms	附属書 B. 記号、略語、頭字語の一覧
Appendix C. Glossary	附属書 C. 用語集
Appendix D. Normative References	附属書 D. 規範的参照
Appendix E. Change Log	附属書 E. 変更履歴

---

・2025.12.11 NIST SP 800-126A Rev. 4 (Initial Public Draft) SCAP 1.4 Component Specification Version Updates: An Annex to NIST Special Publication 800-126 Revision 4

NIST SP 800-126A Rev. 4 (Initial Public Draft) SCAP 1.4 Component Specification Version Updates: An Annex to NIST Special Publication 800-126 Revision 4	NIST SP 800-126A 第4版（初期公開ドラフト）SCAP 1.4 コンポーネント仕様バージョン更新：NIST SP 800-126第4版の附属書
Abstract	概要
The Security Content Automation Protocol (SCAP) is a multi-purpose framework of component specifications that support automated configuration, vulnerability, patch checking, security measurement, and technical control compliance activities. The SCAP version 1.4 specification is defined by the combination of NIST SP 800-126r4, a set of schemas, and this document. This document allows the use of particular minor version updates to SCAP 1.4 component specifications and particular Open Vulnerability and Assessment Language (OVAL) schema versions to provide additional functionality for SCAP 1.4 without causing any loss of existing functionality.	セキュリティコンテンツ自動化プロトコル（SCAP）は、自動化された構成、脆弱性、パッチチェック、セキュリティ測定、技術的制御コンプライアンス活動を支援するコンポーネント仕様の多目的枠組みである。SCAPバージョン1.4仕様は、NIST SP 800-126r4、一連のスキーマ、および本文書の組み合わせによって定義される。本文書は、SCAP 1.4コンポーネント仕様の特定のマイナーバージョン更新および特定のOpen Vulnerability and Assessment Language（OVAL）スキーマバージョンの使用を許可し、既存の機能を損なうことなくSCAP 1.4に追加機能を提供する。

・[PDF] NIST.SP.800-126Ar4.ipd

目次...

1. Introduction	1. 序論
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Document Structure	1.2. 文書の構成
2. Minor Version Updates in SCAP 1.4-Component Specifications	2. SCAP 1.4 コンポーネント仕様におけるマイナーバージョン更新
2.1. Criteria for Potential Inclusion	2.1. 潜在的な包含規準
2.2. Approved Minor Version Updates and SCAP 1.4 Requirements	2.2. 承認済みマイナーバージョン更新と SCAP 1.4 要件
2.3. XML Schema and Schematron Schema Locations	2.3. XML スキーマと Schematron スキーマの場所
3. Document Management	3. 文書管理
3.1. Composition	3.1. 構成
3.2. Rationale	3.2. 根拠
3.3. Update Cadence	3.3. 更新頻度
3.4. Conformance and Assessment	3.4. 適合性評価
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書 A. 記号、略語、頭字語一覧
Appendix B. Glossary	附属書 B. 用語集
Appendix C. Change Log	附属書 C. 変更履歴

---

NISTの文書等はここから辿れます...

・Security Content Automation Protocol SCAP

関連文書

・Publications

---

● IPA 

・2015.07.22 セキュリティ設定共通化手順SCAP概説

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2023.07.16 NIST SP 800-219r1 macOSセキュリティ・コンプライアンス・プロジェクト（mSCP）による自動化された安全な構成のガイダンス

・2011.07.15 NIST パブコメ Trust Model for Security Automation Data 1.0 (TMSAD)

・2008.02.13 IPA 脆弱性情報共有フレームワークに関する調査報告書　～中小規模組織における脆弱性対策促進への各国の取り組み～

米国 NIST SP 800-70 第5版 (初期公開ドラフト) IT製品向け国家チェックリストプログラム：チェックリスト利用者および開発者向けガイドライン

こんにちは、丸山満彦です。

NISTがSP 800-70 第5版 (初期公開ドラフト) IT製品向け国家チェックリストプログラム：チェックリスト利用者および開発者向けガイドラインを公開し、意見募集をしていますね...

米国だからできるのかもしれませんが...

● NIST - ITl

・2025.12.05 NIST SP 800-70 Rev. 5 (Initial Public Draft) National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

NIST SP 800-70 Rev. 5 (Initial Public Draft) National Checklist Program for IT Products: Guidelines for Checklist Users and Developers	NIST SP 800-70 第5版 (初期公開ドラフト) IT製品向け国家チェックリストプログラム：チェックリスト利用者および開発者向けガイドライン
Announcement	発表
NIST established the National Checklist Program (NCP) to facilitate the generation of security checklists from authoritative sources, centralize the location of checklists, and make checklists broadly accessible. SP 800-70r5 ipd describes the uses, benefits, and management of checklists and checklist control catalogs, as well as the policies, procedures, and general requirements for participation in the NCP.	NISTは国家チェックリストプログラム（NCP）を設立している。これは権威ある情報源からのセキュリティチェックリスト作成を促進し、チェックリストの場所を一元化し、チェックリストを広く利用可能にするためである。SP 800-70r5 ipd は、チェックリスト及びチェックリスト管理カタログの用途、利点、管理方法、並びに NCP への参加に関する方針、手順、及び一般的な要件を説明する。
Why Security Configuration Checklists Matter	セキュリティ構成チェックリストの重要性
A security configuration checklist is a document or technical content that contains instructions or procedures for securely configuring an IT product to match an operational environment’s risk tolerance, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product. Using these checklists can minimize the attack surface, reduce vulnerabilities, lessen the impacts of successful attacks, and identify changes that might otherwise go undetected.	セキュリティ構成チェックリストとは、運用環境のリスク許容度に合わせてIT製品を安全に構成するための手順や指示、製品の適切な構成確認、および製品への不正変更の特定を含む文書または技術的コンテンツである。これらのチェックリストを使用することで、攻撃対象領域を最小化し、脆弱性を減らし、攻撃成功時の影響を軽減し、検出されにくい変更を識別できる。
What’s New in Revision 5?	改訂版5の新機能
This revision introduces significant updates to improve usability, automation, and alignment with modern cybersecurity practices.	本改訂版では、使いやすさ、自動化、現代的なサイバーセキュリティ慣行との整合性を向上させるための大幅な更新を導入した。
Key Highlights	主なハイライト
Traceability and Compliance: Enhanced mapping concepts between checklist settings, NIST Cybersecurity Framework (CSF) 2.0 outcomes, SP 800-53 controls, and Common Configuration Enumeration (CCE) identifiers for evidence-ready automation and reporting	トレーサビリティとコンプライアンス：チェックリスト設定、NISTサイバーセキュリティフレームワーク（CSF）2.0の成果、SP 800-53の制御、共通構成列挙（CCE）識別子間のマッピング概念を強化し、証拠対応型の自動化と報告を実現
Expanded Coverage: Guidance that includes cloud platforms, IoT, and AI systems and reflects the latest NIST research and federal requirements	適用範囲の拡大：クラウドプラットフォーム、IoT、AIシステムを含むガイダンスを拡充。最新のNIST研究及び連邦政府要件を反映
Modernized Automation: Explicit support for a wide range of automated checklist formats	自動化の近代化：多様な自動化チェックリスト形式への明示的サポート
Control Catalog Approach: Encourages developers to use catalogs of controls for rapid, consistent checklist generation and easier tailoring to different risk postures	コントロールカタログ方式：開発者が制御カタログを活用し、迅速かつ一貫性のあるチェックリスト生成と、異なるリスク態勢への容易な適応を促進
Operational Environment Tailoring: Detailed recommendations for customizing checklists to fit stand-alone, managed (enterprise), specialized security-limited functionality (SSLF), and legacy environments	運用（OT）環境への適合：スタンドアロン環境、管理対象（エンタープライズ）環境、特殊セキュリティ限定機能（SSLF）環境、レガシー環境に合わせてチェックリストをカスタマイズするための詳細な推奨事項
Checklist Life Cycle: Clear procedures for checklist development, testing, documentation, submission, public review, maintenance, and archival	チェックリストのライフサイクル：チェックリストの開発、テスト、文書化、提出、公開レビュー、保守、アーカイブに関する明確な手順
Intended Audience	対象読者
This document is intended for users and developers of security configuration.	本ドキュメントは、セキュリティ構成のユーザーおよび開発者を対象とする。
For checklist users, this document makes recommendations on how they should select checklists from the NIST National Checklist Repository, evaluate and test checklists, and apply them to IT products.	チェックリストユーザーに対しては、NIST国家チェックリストリポジトリからのチェックリスト選定方法、チェックリストの評価・テスト方法、IT製品への適用方法に関する推奨事項を示す。
For checklist developers, this document sets forth the policies, procedures, and general requirements for participation in the NCP.	チェックリスト開発者に対しては、NCP（国家チェックリストプログラム）への参加に関する方針、手順、および一般的な要件を定める。
Abstract	概要
A security configuration checklist is a document or technical content that contains instructions or procedures for securely configuring an IT product to match an operational environment’s risk tolerance, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product. Using these checklists can minimize the attack surface, reduce vulnerabilities, lessen the impact of successful attacks, and identify changes that might otherwise go undetected. NIST established the National Checklist Program (NCP) to facilitate the generation of security checklists from authoritative sources, centralize the location of checklists, and make checklists broadly accessible. This publication explains how to use the NCP to find and retrieve checklists and describes the policies, procedures, and general requirements for participation in the NCP.	セキュリティ構成チェックリストとは、運用環境のリスク許容度に合わせてIT製品を安全に構成するための手順や指示、製品の適切な構成確認方法、および製品への不正変更の識別方法を記載した文書または技術的コンテンツである。これらのチェックリストを使用することで、攻撃対象領域を最小化し、脆弱性を低減し、攻撃成功時の影響を軽減し、検出されにくい変更を識別することが可能となる。NISTは、権威ある情報源からのセキュリティチェックリスト作成を促進し、チェックリストの場所を一元化し、チェックリストを広く利用可能にするため、国家チェックリストプログラム（NCP）を設立した。本出版物は、NCPを使用してチェックリストを検索・取得する方法を説明し、NCPへの参加に関する方針、手順、および一般的な要件を記述するものである。

・[PDF] NIST.SP.800-70r5.ipd

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
A security configuration checklist (also called a lockdown, hardening guide, or benchmark) is a series of instructions or procedures for securely configuring an IT product to a particular risk tolerance for an operational environment, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product. The checklist may be for a commercial, open-source, or government-off-the-shelf (GOTS) IT product.	セキュリティ構成チェックリスト（ロックダウン、強化ガイド、ベンチマークとも呼ばれる）とは、運用環境における特定のリスク許容度に合わせてIT製品を安全に構成するための一連の指示や手順である。製品が適切に構成されていることを確認し、あるいは製品への不正な変更を識別することを目的とする。チェックリストは、商用製品、オープンソース製品、政府向け既製品（GOTS）のIT製品を対象とする場合がある。
Checklists can comprise a mix of templates, automated scripts, patch information, Extensible Markup Language (XML) files, and other procedures. Typically, checklists are created by IT vendors for their own products; however, checklists are also created by other organizations, such as academia, consortia, and government agencies. The use of well-written, standardized checklists can markedly reduce the attack surface and vulnerability exposure of IT products.	チェックリストは、テンプレート、自動化スクリプト、パッチ情報、拡張マークアップ言語（XML）ファイル、その他の手順を組み合わせて構成されることがある。通常、チェックリストはITベンダーが自社製品向けに作成するが、学術機関、コンソーシアム、政府など他の組織によって作成される場合もある。適切に作成された標準化されたチェックリストの使用は、IT製品の攻撃対象領域と脆弱性のエクスポージャーを著しく低減できる。
NIST maintains the National Checklist Repository, which is a publicly available resource of security configuration checklists for IT products. The repository is located at https://checklists.nist.gov/ and contains metadata describing each checklist. The repository links to the website where a checklist is hosted. Users can browse and search the repository to locate a particular checklist using a variety of criteria. Having a centralized checklist repository makes it easier for organizations to find current, authoritative versions of security checklists and to determine which ones best meet their needs.	NISTはIT製品向けセキュリティ構成チェックリストの公開リソースである国家チェックリスト・レポジトリを管理している。リポジトリは https://checklists.nist.gov/ に所在し、各チェックリストを記述するメタデータを含む。リポジトリはチェックリストがホストされているウェブサイトへリンクする。ユーザーは様々な規準を用いてリポジトリを閲覧・検索し、特定のチェックリストを特定できる。中央集約型のチェックリストリポジトリが存在することで、組織は最新の権威あるセキュリティチェックリストを見つけ、自社のニーズに最も適合するものを判断しやすくなる。
This document is intended for users and developers of security configuration.  For checklist users, this document makes recommendations on how they should select checklists from the NIST National Checklist Repository, evaluate and test checklists, and apply them to IT products. For checklist developers, this document sets forth the policies, procedures, and general requirements for participation in the NIST National Checklist Program (NCP).	この文書は、セキュリティ構成のユーザーおよび開発者を対象とする。チェックリスト利用者向けには、NIST国家チェックリストリポジトリからのチェックリスト選定方法、評価・テスト手法、IT製品への適用方法に関する推奨事項を示す。開発者向けには、NIST国家チェックリストプログラム（NCP）への参加に関する方針、手順、基本要件を定める。
Major recommendations made in this document for checklist users and developers include the following:	本文章がチェックリストのユーザーと開発者に対して行う主な推奨事項は以下の通りである：
• Organizations should apply checklists to operating systems and applications to reduce the number of vulnerabilities that attackers can attempt to exploit and to lessen the impact of successful attacks.	• 組織は、攻撃者が悪用を試みうる脆弱性の数を減らし、攻撃が成功した場合の影響を軽減するために、オペレーティングシステムやアプリケーションにチェックリストを適用すべきである。
• When selecting checklists, users should carefully consider each checklist’s degree of automation, source, use of standards, and other relevant characteristics.	• チェックリストを選択する際、ユーザーは各チェックリストの自動化の程度、出典、標準の使用状況、その他の関連特性を慎重に考慮すべきである。
• Checklist users should customize and test checklists before applying them to production systems.	• チェックリスト利用者は、本番システムに適用する前にチェックリストをカスタマイズしテストすべきである。
• Checklist users should consider their operational environments when selecting checklists.,.	• チェックリスト利用者は、チェックリストを選択する際に自組織の運用環境を考慮すべきである。
• Checklist creators are encouraged to adopt a “catalog of controls” approach for products to facilitate custom checklist re-use.	• チェックリスト作成者は、製品向けに「制御カタログ」アプローチを採用し、カスタムチェックリストの再利用を容易にするよう推奨される。
• NIST strongly encourages IT product vendors to develop security configuration checklists for their products and contribute them to the NIST National Checklist Repository.	• NISTは、IT製品ベンダーが自社製品向けのセキュリティ構成チェックリストを開発し、NIST国家チェックリストリポジトリへ寄稿することを強く推奨する。

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Document Organization	1.2. 文書の構成
2. NIST National Checklist Program	2. NIST国家チェックリストプログラム
2.1. Overview of the NCP	2.1. NCPの概要
2.2. Security Configuration Checklists	2.2. セキュリティ構成チェックリスト
2.3. Benefits of Using Security Checklists	2.3. セキュリティチェックリスト利用の利点
2.4. Types of Checklists Listed by NCP	2.4. NCPが列挙するチェックリストの種類
3. Operational Environments for Checklists	3. チェックリストの運用環境
3.1. Stand-Alone Environment	3.1. スタンドアローン環境
3.2. Managed Environment (Enterprise)	3.2. 管理環境（エンタープライズ）
3.3. Custom Environments	3.3. カスタム環境
3.3.1. Specialized Security-Limited Functionality Environment	3.3.1. 特殊なセキュリティ制限機能環境
3.3.2. Legacy Environment	3.3.2. レガシー環境
4. Checklist Usage	4. チェックリストの使用方法
4.1. Determining Local Requirements	4.1. ローカル要件の決定
4.2. Browsing and Retrieving Checklists	4.2. チェックリストの閲覧と取得
4.3. Reviewing, Customizing, Documenting, and Testing Checklists	4.3. チェックリストのレビュー、カスタマイズ、文書化、テスト
4.4. Applying Checklists to IT Products	4.4. IT製品へのチェックリスト適用
4.5. Providing Feedback on Checklists	4.5. チェックリストへのフィードバック提供
5. Checklist Development	5. チェックリスト開発
5.1. Developer Steps for Creating, Testing, and Submitting Checklists	5.1. チェックリスト作成、テスト、提出のための開発者手順
5.2. Initial Checklist Development	5.2. 初期チェックリスト開発
5.3. Checklist Testing	5.3. チェックリストテスト
5.4. Checklist Documented	5.4. チェックリストの文書化
5.5. Checklist Submitted to NIST	5.5. NISTへのチェックリスト提出
5.6. NIST Steps for Reviewing and Finalizing Checklists for Publication	5.6. 公開に向けたチェックリストのNISTによる審査と最終化手順
5.7. NIST Screening of the Checklist Package	5.7. チェックリストパッケージのNISTによるスクリーニング
5.8. Public Review and Feedback for the Candidate Checklist	5.8. 候補チェックリストの公開レビューとフィードバック
5.9. Final Listing on Checklist Repository	5.9. チェックリストリポジトリへの最終掲載
5.10. Checklist Maintenance and Archival	5.10. チェックリストの保守とアーカイブ
References	参考文献
Appendix A. Checklist Program Operational Procedures	附属書A. チェックリストプログラム運用手順
A.1. Overview and General Considerations	A.1. 概要と一般的な考慮事項
A.2. Checklist Submission and Screening	A.2. チェックリストの提出とスクリーニング
A.3. Candidate Checklist Public Review	A.3. 候補チェックリストの公開レビュー
A.4. Final Checklist Listing	A.4. 最終チェックリストの掲載
A.5. Final Checklist Update, Archival, and Delisting	A.5. 最終チェックリストの更新、アーカイブ、および掲載解除
A.6. Record Keeping	A.6. 記録の保管
Appendix B. Participation and Logo Usage Agreement Form	附属書B. 参加およびロゴ使用に関する合意書
Appendix C. Automating NIST CSF 2.O	附属書C. NIST CSF 2.0 の自動化
C.1. How the Path Connects Policy to Automation	C.1. パスがポリシーと自動化をどう結びつけるか
C.2. Implementation and Traceability	C.2. 実装とトレーサビリティ
C.3. Checklist Development Guidance	C.3. チェックリスト開発ガイダンス
C.4. Operational Environment Tailoring and Considerations	C.4. 運用環境の調整と考慮事項
C.5. Checklist Submission and Maintenance	C.5. チェックリストの提出と保守
C.6. Appendix References	C.6. 附属書の参考文献
Appendix D. List of Symbols, Abbreviations, and Acronyms	附属書D. 記号、略語、頭字語一覧
Appendix E. Glossary	附属書E. 用語集
Appendix F. Change Log	附属書F. 変更履歴
List of Tables	表一覧
Table 1. Checklist Description Form Fields	表 1. チェックリスト説明フォームのフィールド
List of Figures	図一覧
Fig. 1. Checklist user process overview	図 1. チェックリスト利用者プロセスの概要

国家チェックリストプログラム

・2017.02.15 National Checklist Program NCP

チェックリストのレポジトリ...

・Checklist Repository

全部で853のチェックリストがあります（2025.12.13確認時）

例えば、MacOSOS (Tahoe) 26.0.0を選んだ画面...

でマッチしたのが、

https://ncp.nist.gov/repository?product=Apple+macOS+%28Tahoe%29+26.0.0&sortBy=modifiedDate%7Cdesc

でこれをクリックすると

・2025.09.17 Tahoe Guidance Revision 1.0 Checklist Details 

ダウンロード

・・[ZIP] Download ZIP - Tahoe Guidance, Revision 1.0

ダウンロードして内容を確認してみてくださいませ。充実した内容となっております...

こんな感じでファイルが格納されています...

例えば、

SP800-53

・800-53r5_high.html (downloaded)

 

国家安全保障システム委員会 (Committee on National Security Systems; CNSS) 用のCNSSI-1253チェックリスト

・CNSSI - 1253_high.html (downloaded)

● Github

・usnistgov/macos_security

● まるちゃんの情報セキュリティ気まぐれ日記

・2023.07.16 NIST SP 800-219r1 macOSセキュリティ・コンプライアンス・プロジェクト（mSCP）による自動化された安全な構成のガイダンス

米国 NIST SP 800-57 第6版（初期公開ドラフト）鍵管理に関する推奨事項：第1部－一般事項 (2025.12.05)

こんにちは、丸山満彦です。

NISTがSP 800-57 第6版（初期公開ドラフト）鍵管理に関する推奨：第1部－一般を公表し、意見募集をしていますね...

耐量子計算機暗号移行の問題もあって話題な領域かも (^^) 

三部作の第一部です。でも、第一部だけでも200ページくらいあります...

● NIST - ITL

・2025.12.05 NIST SP 800-57 Rev. 6 (Initial Public Draft) Recommendation for Key Management: Part 1 – General

NIST SP 800-57 Rev. 6 (Initial Public Draft) Recommendation for Key Management: Part 1 – General	米国 NIST SP 800-57 第6版（初期公開ドラフト）鍵管理に関する推奨事項：第1部－一般事項
Announcement	発表
The initial draft of NIST SP 800-57 Part 1 Revision 6 is available for comment through February 5, 2026. Some of the proposed changes from Revision 5 include:	NIST SP 800-57 第1部 第6改訂版の初期ドラフトが、2026年2月5日まで意見募集のために公開されている。第5版からの主な変更点には以下が含まれる：
・Ascon, as specified in SP 800-232, and the new quantum-resistant algorithms specified in FIPS 203, 204, and 205 have been included.	・SP 800-232で規定されたAscon、およびFIPS 203、204、205で規定された新たな量子耐性アルゴリズムが追加された。
・The keys used for both key establishment and key storage are now discussed separately.	・鍵確立と鍵保存に使用される鍵について、別々に論じられるようになった。
・The security categories used in the PQC competition have been included, along with the quantum-resistant algorithms.	・量子耐性アルゴリズムと共に、PQCコンペティションで使用されたセキュリティカテゴリーが追加された。
・The time frames for algorithm approval status have been removed and replaced with references to SP 800-131A.	・アルゴリズム承認ステータスの時間枠は削除され、SP 800-131Aへの参照に置き換えられた。
・A section has been added to discuss keying material storage and mechanisms.	・鍵材料の保存とメカニズムについて論じるセクションが追加された。
See Appendix F for a more complete list of changes.	変更点のより完全なリストについては附属書Fを参照のこと。
Abstract	要約
This recommendation provides cryptographic key-management guidelines in three parts. Part 1 provides general guidelines and best practices for the management of cryptographic keying material, including definitions for the security services that may be provided when using cryptography and the algorithms and key types that may be employed, specifications for the protection that each type of key and other cryptographic information requires and methods for providing this protection, discussions about the functions involved in key management, and discussions about a variety of key-management issues to be addressed when using cryptography. Part 2 provides guidance on policy and security planning requirements for U.S. Government agencies. Part 3 provides guidelines for using the cryptographic features of current systems.	本勧告は暗号鍵管理ガイドラインを3部構成で提供する。第1部では、暗号鍵材料の管理に関する一般的なガイドラインとベストプラクティスを提供する。これには、暗号技術使用時に提供可能なセキュリティサービスの定義、採用可能なアルゴリズムと鍵の種類、各種鍵及びその他の暗号情報に必要な防御仕様とその提供方法、鍵管理に関わる機能に関する考察、暗号技術使用時に対処すべき多様な鍵管理課題に関する考察が含まれる。第2部では、米国政府機関向けのポリシー及びセキュリティ計画要件に関する指針を提供する。第3部では、現行システムの暗号機能利用に関するガイドラインを提供する。

・[PDF] NIST.SP.800-57pt1r6.ipd

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
Cryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography. These keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration.	暗号技術は、ネットワーク上の通信の保護、データベースに保存された情報の保護、その他多くの重要な用途に使用される。暗号鍵は暗号技術の運用において重要な役割を果たす。これらの鍵は金庫の暗証番号に類似している。敵対者が金庫の暗証番号を知っている場合、最も強固な金庫であっても侵入に対する防御効果は皆無である。
The proper management of cryptographic keys is essential to the effective use of cryptography for security. Poor key management may easily compromise strong algorithms. This recommendation provides guidelines for the management of a cryptographic key throughout its life cycle, including its secure generation, storage, distribution, use, and destruction.	暗号鍵の適切な管理は、セキュリティのための暗号技術の有効な利用に不可欠である。鍵管理が不十分だと、強力なアルゴリズムも容易に破られる。本 推奨は、暗号鍵のライフサイクル全体（安全な生成、保管、配布、使用、破棄を含む）における管理ガイドラインを提供する。
Ultimately, the security of information protected by cryptography directly depends on the strength of the keys, the effectiveness of cryptographic mechanisms and protocols associated with the keys, and the protection provided to the keys. Secret and private keys need to be protected against unauthorized disclosure, and all keys need to be protected against modification.	結局のところ、暗号技術で保護される情報の安全性は、鍵の強度、鍵に関連する暗号メカニズムとプロトコルの有効性、そして鍵自体への保護に直接依存する。秘密鍵と公開鍵は不正開示から防御され、全ての鍵は改変から防御されなければならない。
Cryptographic keys are used across a broad range of systems and applications in enterprises, many of which are managed by individuals who may not have expertise in key management. Consequently, organizations must ensure that clear guidance and oversight is provided for the proper management of keys, as well as controls to ensure that the guidance is being followed and implemented.	暗号鍵はエンタープライズの幅広いシステムやアプリケーションで使用されるが、その多くは鍵管理の専門知識を持たない個人によって管理されている。したがって組織は、鍵の適切な管理に向けた明確な指針と監督を提供するとともに、その指針が遵守・実施されていることを保証する統制を確立しなければならない。
Organizations and developers are presented with many choices in their use of cryptographic mechanisms. Inappropriate choices may result in an illusion of security but with little or no real security for the protocol or application. This recommendation provides background information and establishes a framework to support appropriate decisions when selecting and using cryptographic mechanisms.	組織や開発者は暗号メカニズムの利用において多くの選択肢に直面する。不適切な選択は、プロトコルやアプリケーションに対する実質的なセキュリティがほとんど、あるいは全くないにもかかわらず、セキュリティの幻想をもたらす可能性がある。本 推奨は背景情報を提供し、暗号メカニズムの選択と利用時に適切な判断を支援する枠組みを確立する。
Cryptographic modules are used to perform cryptographic operations using these keys. This recommendation does not address the implementation details for cryptographic modules that may be used to achieve the security requirements identified herein. These details are addressed in Federal Information Processing Standards (FIPS) Publication 140 [FIPS 140-3] and its associated implementation guidance and derived test requirements, which are available at https://csrc.nist.gov/projects/cmvp.	暗号モジュールは、これらの鍵を用いて暗号操作を実行するために使用される。本 推奨は、ここで識別されたセキュリティ要件を達成するために使用される暗号モジュールの実装詳細には触れない。これらの詳細は、連邦情報処理標準（FIPS）出版物140［FIPS 140-3］および関連する実装ガイダンスと派生テスト要件で扱われており、https://csrc.nist.gov/projects/cmvp で入手可能である。
This recommendation is divided into three parts:	本推奨は三つの部分に分かれる：
• Part 1 — General contains basic key-management guidelines	• 第1部 — 基本：基本的な鍵管理ガイドラインを含む
• Part 2 — Best Practices for Key Management Organizations provides a framework and general guidance to support establishing cryptographic key management.	• 第2部 — 鍵管理組織のためのベストプラクティス：暗号鍵管理の確立を支援する枠組みと一般的な指針を提供する
• Part 3 — Application-Specific Key Management Guidance addresses the key278 management issues associated with currently available implementations that use cryptography.	• 第3部 — アプリケーション固有の鍵管理ガイダンス：現在利用可能な暗号技術を用いた実装に関連する鍵管理の問題に対処する

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1. Purpose	1.1. 目的
1.2. Audience	1.2. 対象読者
1.3. Scope	1.3. 範囲
1.4. Preliminary Discussion of Terms	1.4. 用語の予備的考察
1.5. Content and Organization	1.5. 内容と構成
2. Security Services	2. セキュリティサービス
2.1. Confidentiality	2.1. 機密性
2.2. Data Integrity	2.2. データ完全性
2.3. Authentication	2.3. 認証
2.4. Authorization	2.4. 認可
2.5. Non-Repudiation	2.5. 否認防止
2.6. Support Services	2.6. サポートサービス
2.7. Combining Services	2.7. サービスの組み合わせ
3. Cryptographic Algorithms	3. 暗号アルゴリズム
3.1. Cryptographic Hashing Methods	3.1. 暗号ハッシュ手法
3.2. Symmetric-Key Algorithms	3.2. 対称鍵アルゴリズム
3.3. Asymmetric-Key Algorithms	3.3. 非対称鍵アルゴリズム
3.4. Random Bit Generation	3.4. 乱数生成
4. General Key-Management Guidelines	4. 鍵管理の一般ガイドライン
4.1. Key Types and Other Information	4.1. 鍵の種類とその他の情報
4.1.1. Cryptographic Keys	4.1.1. 暗号鍵
4.1.2. Other Related Information	4.1.2. その他の関連情報
4.2. Key Usage	4.2. 鍵の使用期間
4.3. Cryptoperiods	4.3. 暗号期間
4.3.1. Factors Affecting Cryptoperiods	4.3.1. 暗号期間に影響する要因
4.3.2. Consequence Factors Affecting Cryptoperiods	4.3.2. 暗号期間に影響する結果要因
4.3.3. Other Factors Affecting Cryptoperiods	4.3.3. 暗号期間に影響するその他の要因
4.3.4. Asymmetric Key Usage Periods and Cryptoperiods	4.3.4. 非対称鍵の使用期間と暗号期間
4.3.5. Symmetric Key Usage Periods and Cryptoperiods	4.3.5. 対称鍵の使用期間と暗号期間
4.3.6. Cryptoperiod Recommendations for Specific Key Types	4.3.6. 特定の鍵タイプに対する暗号期間の推奨
4.4. Assurances	4.4. 保証（アシュアランス）
4.4.1. Assurance of Integrity (Integrity Protection)	4.4.1. 完全性の保証（完全性保護）
4.4.2. Assurance of Algorithm Parameter Validity	4.4.2. アルゴリズムパラメータの有効性の保証
4.4.3. Assurance of Public-Key Validity	4.4.3. 公開鍵の有効性の保証
4.4.4. Assurance of Private-Key Possession	4.4.4. 秘密鍵の所有の保証
4.4.5. Key Confirmation	4.4.5. 鍵の確認
4.5. Compromise of Keys and Other Keying Material	4.5. 鍵及びその他の鍵材料の侵害
4.5.1. Implications	4.5.1. 影響
4.5.2. Protective Measures	4.5.2. 保護措置
4.6. Guidelines for Cryptographic Algorithm and Key-Size Selection	4.6. 暗号アルゴリズム及び鍵サイズの選定に関する指針
4.6.1. Cryptographic Algorithm Security Strengths	4.6.1. 暗号アルゴリズムのセキュリティ強度
4.6.2. Using Algorithm Suites and the Effective Security Strength	4.6.2. アルゴリズムスイートの使用と実効セキュリティ強度
4.6.3. Projected Algorithm and Security Strength Approval Status	4.6.3. 予測されるアルゴリズム及びセキュリティ強度の承認状況
4.6.4. Transitioning to New Algorithms and Key Sizes in Systems	4.6.4. システムにおける新アルゴリズムおよび鍵サイズへの移行
4.6.5. Decrease in Security Over Time	4.6.5. 時間の経過に伴うセキュリティの低下
5. Protection Requirements for Key Information	5. 鍵情報の防御要件
5.1. Protection and Assurance Requirements	5.1. 防御および保証要件
5.1.1. Summary of Protection and Assurance Requirements for Cryptographic Keys	5.1.1. 暗号鍵の防御および保証要件の概要
5.1.2. Summary of Protection Requirements for Other Related Information	5.1.2. その他の関連情報の防御要件の概要
5.2. Protection Mechanisms	5.2. 防御メカニズム
5.2.1. Protection Mechanisms for Key Information in Transit	5.2.1. 伝送中の鍵情報の防御メカニズム
5.2.2. Protection Mechanisms for Key Information in Storage	5.2.2. 保管中の鍵情報の防御メカニズム
5.2.3. Metadata for Keys	5.2.3. 鍵のメタデータ
6. Key States and Transitions	6. 鍵の状態と遷移
6.1. Pre-Activation State	6.1. 事前活性化状態
6.2. Active State	6.2. 活性化状態
6.3. Suspended State	6.3. 一時停止状態
6.4. Compromised State	6.4. 侵害状態
6.5. Destroyed State	6.5. 破棄状態
7. Key-Management Phases and Functions	7. 鍵管理のフェーズと機能
7.1. Pre-Operational Phase	7.1. 運用前フェーズ
7.1.1. Entity Registration Function	7.1.1. 事業体登録機能
7.1.2. System Initialization Function	7.1.2. システム初期化機能
7.1.3. Initialization Function	7.1.3. 初期化機能
7.1.4. Keying-Material Installation Function	7.1.4. 鍵材料インストール機能
7.1.5. Key-Establishment Function	7.1.5. 鍵確立機能
7.1.6. Key Registration Function	7.1.6. 鍵登録機能
7.2. Operational Phase	7.2. 運用フェーズ
7.2.1. Normal Operational Storage Function	7.2.1. 通常運用時保存機能
7.2.2. Continuity of Operations Function	7.2.2. 運用継続機能
7.2.3. Key Change Function	7.2.3. 鍵変更機能
7.2.4. Key Derivation Methods	7.2.4. 鍵導出方法
7.3. Post-Operational Phase	7.3. 運用終了後フェーズ
7.3.1. Key Archive and Key Recovery Functions	7.3.1. 鍵アーカイブ及び鍵復旧機能
7.3.2. Entity De-Registration Function	7.3.2. 事業体登録解除機能
7.3.3. Key De-Registration Function	7.3.3. 鍵登録解除機能
7.3.4. Key Destruction Function	7.3.4. 鍵破棄機能
7.3.5. Key Revocation Function	7.3.5. 鍵失効機能
7.4. Destroyed Phase	7.4. 破棄段階
8. Additional Considerations	8. 追加考慮事項
8.1. Access Control and Identity Authentication	8.1. アクセス管理と身元認証
8.2. Inventory Management	8.2. 在庫管理
8.2.1. Key Inventories	8.2.1. 鍵在庫
8.2.2. Certificate Inventories	8.2.2. 証明書在庫
8.3. Accountability	8.3. 説明責任
8.4. Audit	8.4. 監査
8.5. Key-Management System Survivability	8.5. 鍵管理システムの生存性
8.5.1. Backed Up and Archived Key	8.5.1. バックアップおよびアーカイブされた鍵
8.5.2. Key Recovery	8.5.2. 鍵の復旧
8.5.3. System Redundancy/Contingency Planning…	8.5.3. システムの冗長性／緊急時対応計画…
8.5.4. Compromise Recovery	8.5.4. 侵害からの復旧
References	参考文献
Appendix A. Cryptographic and Non-Cryptographic Integrity and Source Authentication Mechanisms	附属書 A. 暗号的および非暗号的完全性およびソース認証メカニズム
Appendix B. Key Recovery	附属書 B. 鍵の復旧
B.1. General Discussion	B.1. 一般的な考察
B.1.1. Recovery From Stored Keying Material	B.1.1. 保存された鍵材料からの回復
B.1.2. Recovery by Reconstruction of Keying Material	B.1.2. 鍵材料の再構築による回復
B.1.3. Conditions Under Which Keying Material Needs to be Recoverable	B.1.3. 鍵材料の回復が必要となる条件
B.1.4. Key-Recovery Systems	B.1.4. 鍵回復システム
B.1.5. Key-Recovery Policy	B.1.5. 鍵回復ポリシー
B.2. Digital Signature Key Pair	B.2. デジタル署名鍵ペア
B.2.1. Private Signature Key	B.2.1. 秘密署名鍵
B.2.2. Public Signature-Verification Key	B.2.2. 公開署名検証鍵
B.3. Authentication Keys	B.3. 認証鍵
B.3.1. Symmetric Authentication Key	B.3.1. 対称認証鍵
B.3.2. Authentication (Asymmetric) Key Pair	B.3.2. 認証（非対称）鍵ペア
B.4. Random Number Generation Key	B.4. 乱数生成鍵
B.5. Key-Derivation/Master Key	B.5. 鍵導出／マスター鍵
B.6. Key Establishment (Automated)	B.6. 鍵確立（自動化）
B.6.1. Symmetric Key-Wrapping Key	B.6.1. 対称鍵ラッピング鍵
B.6.2. Key-Transport Key Pair	B.6.2. 鍵伝送鍵ペア
B.6.3. Symmetric Key-Agreement Key	B.6.3. 対称鍵合意鍵
B.6.4. Static Key-Agreement Key Pair	B.6.4. 静的鍵合意鍵ペア
B.6.5. Ephemeral Key-Agreement Key Pair	B.6.5. 一時的鍵合意鍵ペア
B.6.6. Static Encapsulation/Decapsulation Key Pair	B.6.6. 静的カプセル化/デカプセル化鍵ペア
B.6.7. Ephemeral Encapsulation/Decapsulation Key Pair	B.6.7. 一時的なカプセル化/デカプセル化鍵ペア
B.7. Symmetric Data Encryption/Decryption Keys	B.7. 対称データ暗号化/復号化鍵
B.7.1. Encryption/Decryption of Data in Transit	B.7.1. 転送中のデータの暗号化/復号
B.7.2. Encryption/Decryption of Data at Rest	B.7.2. 保存データの暗号化/復号
B.8. Keying Material Storage	B.8. 鍵材料の保存
B.8.1. Symmetric Key Wrapping/Unwrapping Key	B.8.1. 対称鍵ラッピング/アンラッピング鍵
B.8.2. Asymmetric Key Encryption/Decryption Key Pair	B.8.2. 非対称鍵暗号化/復号化鍵ペア
B.8.3. Encapsulation/Decapsulation Key Pair	B.8.3. カプセル化/デカプセル化鍵ペア
B.9. Authorization	B.9. 認可
B.9.1. Symmetric Authorization Key	B.9.1. 対称認可鍵
B.9.2. Authorization Key Pair	B.9.2. 認可鍵ペア
B.10. Other Related Information	B.10. その他の関連情報
B.10.1. Algorithm Parameters	B.10.1. アルゴリズムパラメータ
B.10.2. Initialization Vector (IV)	B.10.2. 初期化ベクトル（IV）
B.10.3. Shared Secret	B.10.3. 共有秘密
B.10.4. Seed	B.10.4. シード
B.10.5. Other Public and Secret Information	B.10.5. その他の公開情報および秘密情報
B.10.6. Intermediate Results	B.10.6. 中間結果
B.10.7. Key-Control Information/Metadata	B.10.7. 鍵制御情報／メタデータ
B.10.8. Random Numbers	B.10.8. 乱数
B.10.9. Password	B.10.9. パスワード
B.10.10. Audit Information	B.10.10. 監査情報
Appendix C. Security Strength Categories for Post-Quantum Algorithms	附属書 C. 耐量子アルゴリズムのセキュリティ強度カテゴリー
Appendix D. List of Abbreviations and Acronyms	附属書 D. 略語および頭字語一覧
Appendix E. Glossary	附属書 E. 用語集
Appendix F. Change Log	附属書 F. 変更履歴
List of Tables	表一覧
Table 1. Suggested cryptoperiods for key types	表 1. 鍵タイプに対する推奨暗号期間
Table 2: Security Strength Categories for Post-quantum Algorithms	表 2: 耐量子アルゴリズムのセキュリティ強度カテゴリー
Table 3: Security strengths of symmetric block cipher algorithms	表 3: 対称ブロック暗号アルゴリズムのセキュリティ強度
Table 4: Security strengths of classical asymmetric-key algorithms…	表4：古典的非対称鍵アルゴリズムのセキュリティ強度…
Table 5:Security strengths of quantum-resistant asymmetric-key algorithms	表5：量子耐性非対称鍵アルゴリズムのセキュリティ強度
Table 6: Maximum security strengths for hash methods and hash-based functions	表6：ハッシュ手法およびハッシュベース機能の最大セキュリティ強度
Table 8. Protection requirements for cryptographic keys	表8．暗号鍵の防御要件
Table 9. Protection requirements for other related information	表9．その他の関連情報の防御要件
Table 10. Backup of keys	表10．鍵のバックアップ
Table 11. Backup of other related information	表11．その他の関連情報のバックアップ
Table 12. Archive of keys	表12. 鍵のアーカイブ
Table 13. Archive of other related information	表13. その他の関連情報のアーカイブ
List of Figures	図の一覧
Figure 1. Symmetric-key cryptoperiod	図1. 対称鍵暗号の期間
Figure 2. Algorithm originator-usage period example	図2. アルゴリズム作成者-使用期間の例
Figure 3. Key state and transition example	図3. 鍵の状態と遷移の例
Figure 4. Key-management phases	図4. 鍵管理のフェーズ
Figure 5. Key-management states and phases	図5. 鍵管理の状態とフェーズ
Figure 6: Example of a tree of keys in storage	図6: 保存中の鍵のツリーの例

---

暗号鍵の管理についてはIPAからも

● IPA

SP800-57の第5版をベースにしています...

・2023.08.30 暗号鍵設定ガイダンス〜暗号鍵の鍵長選択方法と運用方法〜

（これはSP800-130をベースにしています。）...

・2025.04.25 暗号鍵管理ガイドライン

IPAの翻訳も...

・SP 800-57 Part 1 Rev. 5 鍵管理における推奨事項 第一部：一般事項 Recommendation for Key Management Part 1: General

・・2021.05 [PDF] SP 800-57 Part 1 Rev. 5

・SP 800-57 Part 3 Rev. 1 鍵管理における推奨事項 第三部：アプリケーション特有の鍵管理ガイダンス Recommendation for Key Management Part 3: Application-Specific Key Management Guidance

・・2016.11 [PDF] SP 800-57 Part 3 Rev. 1

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2022.07.13 IPA 暗号鍵設定ガイダンス～暗号鍵の鍵長選択方法と運用方法～

・2020.05.08 NIST SP 800-57 Part 1 Rev. 5 Recommendation for Key Management: Part 1 – General

・2008.07.26 IPA 「MD5 の安全性の限界に関する調査研究」に関する報告書・「安全な暗号鍵のライフサイクルマネージメントに関する調査」に関する報告書を公表