―NIST IR 8477が示す「Concept Mapping」の実践―

複雑化するサイバー規制に企業はどう効率的に対応すべきか

  • 2026-09-10

1.はじめに

企業に求められるサイバーセキュリティの要求は、単一の法令への対応や国際標準への準拠だけでは完結できなくなっています。事業を展開する国・地域、業界、製品、顧客との関係に応じて、NIST Cybersecurity Framework、ISO/IEC 27001、NIST SP 800-171、TISAX(Trusted Information Security Assessment Exchange)、各国の法令・監督ガイドラインなど、目的や対象、抽象度の異なる複数の基準への対応が同時に求められています。

これら複数の規制等への対応を個別に管理すると、類似する統制への重複対応、部門ごとの解釈のばらつき、証跡の分散、対応状況の不透明化が生じやすくなります。規制対応の中心的な課題は、管理対象が増えることだけではなく、異なる文書に記載された要求事項間の関係をどのように説明し、それぞれを既存の統制や証跡に結び付けるかにあります。

NIST IR 8477は、この課題に対し、標準、規制、フレームワークおよびガイドラインに含まれる「概念」の関係を特定し、記録するConcept Mappingのアプローチを示しています。重要なのは、二つの要求事項を単に「関連あり」と結び付けるのではなく、両者がどのような関係にあるのかを明確にし、その判断根拠とともに記録することです。

本稿では、NIST IR 8477を読み解きながら、企業がConcept Mappingを規制対応の共通基盤として活用し、規制等ごとの「個別管理」から、共通統制を軸とした「統合管理」へ転換するための考え方と実務上のアクションを整理します。

2.なぜサイバー規制対応は「個別対応」から抜け出せないのか

2.1 規制等ごとに目的、構造および粒度が異なる

サイバー規制対応の難しさは、対応すべき法令やガイドラインの数が増えていることだけではありません。それぞれの文書が、異なる目的、対象、用語、構造および粒度で要求事項を示している点にあります。さらに、要求事項によって、組織全体、事業、拠点、業務プロセス、システム、製品など、適用・評価すべき単位も異なります。例えば、ある文書は経営レベルのガバナンスや達成すべき成果を示し、別の文書は個別システムに実装すべき管理策や技術要件を示します。同じ「アクセス管理」を扱っていても、アカウント管理、認証、権限付与、職務分離、アクセスレビューなど、要求のまとめ方や深さ、評価対象は一様ではありません。

NIST IR 8477は、サイバーセキュリティおよびプライバシー領域の概念には、管理策、要求事項、推奨事項、成果、技術、機能、プロセス、手法、役割、スキルなど多様な種類があると説明しています。概念の種類や階層を考慮せず、表面的なキーワードだけで対応付けると、マッピング結果の意味が曖昧になり、関連性を過大評価するおそれがあります。

2.2 規制横断の共通化は、すでに実務上の課題となっている

複数の規制等を共通の枠組みで扱おうとする動きは、Concept Mappingの公表以前から実務上の課題として現れていました。例えば金融分野では、Cyber Risk Institute(CRI)が、金融機関に適用される複数の規制・ガイドラインを踏まえた共通の評価枠組みとしてCRI Profileを整備しています。これは、規制ごとに重複する評価を繰り返すのではなく、共通の基準を通じてサイバーリスク管理を整理しようとする取り組みの一例です。

CRI Profile自体はConcept Mappingの手法そのものではありませんが、複数の規制等を横断して整理する共通の物差しを持つという発想は、Concept Mappingの方向性とも整合します。ただし、共通フレームワークを採用しても、個々の法令への準拠が自動的に証明されるわけではない点に留意が必要です。規制等ごとの適用条件、追加要件、要求水準および粒度を確認し、共通部分と固有の差分を説明可能な形で管理する必要があります。NIST IR 8477の意義は、この関係をどのように定義し、記録するかを体系化した点にあります。

2.3 単純な対応表だけでは、実務判断に必要な情報が不足する

複数の規制等を比較する際、一般に「要求事項Aと要求事項Bは関連している」という対応表が作られることがあります。しかし、この情報だけでは、二つの要求事項が同一なのか、一方が他方を包含するのか、一方が他方の達成を支援するにとどまるのかを判断できません。

例えば、「アクセスログを一定期間保管する」という要求と、「重要システムのログを定期的に監査する」という要求が「関連あり」とされていても、ログ保管だけで監査要件まで満たすことにはなりません。関係と判断根拠が記録されていなければ、後任者や監査人は原文を読み直し、同じ判断をやり直すことになります。

規制等ごとに管理体系、評価手続および証跡を分けたまま運用すると、次のような課題が生じる可能性があります。

  • 同一または類似する統制に対する重複した調査、評価および文書整備
  • 部門や評価者ごとの解釈のばらつき
  • 法令別・認証別に分散する証跡
  • 要求事項間の差分や未対応領域の把握困難
  • 改定時の影響範囲特定に要する負荷
  • 経営層から見た全社的な対応状況の不透明化

3.NIST IR 8477が示すConcept Mappingの進め方

3.1 Concept Mappingとは何か

NIST IR 8477におけるConcept Mappingとは、異なる文書に含まれる概念同士の関係を特定し、その内容を記録するアプローチです。このアプローチはNIST文書に限らず、法令、標準、フレームワーク、ガイドラインなど、さまざまな文書に適用できます。主な対象は、機械的に一意に判定できる設定値ではなく、要求事項や管理策のように、文脈を踏まえた人の解釈が必要な概念です。

NIST IR 8477は、Concept Mappingの基本的な進め方を、次の3つのステップで説明しています。

Step 1|マッピングのユースケースを特定し、文書化する。

マッピングを行う前に、想定利用者、利用目的、対象とする概念タイプ、マッピングの方向性および網羅性に関する前提を整理し、ユースケースとして文書化します。

Step 2|目的に適した概念関係スタイルを選択する。

文書化したユースケースと前提を踏まえ、Concept Crosswalk、Supportive Relationship Mapping、Set Theory Relationship Mapping、Structural Relationship Mappingなどから、目的に適したスタイルを選択します。

Step 3|選択したスタイルで関係を判定し、根拠を記録する。

Step 2で選択したスタイルを実際の要求事項や管理策へ適用し、二つの概念がどの関係に該当するかを判定します。その上で、判定結果、参照箇所および判断根拠を記録します。

これらのステップは、NISTコンテンツを含む既存のマッピングプロセスを補強するものであり、完全な開発ライフサイクルを示すものでも、組織の既存手法を置き換えるものでもありません。以下、3.2~3.4で各ステップの実務上の要点を確認します。

3.2 Step 1|マッピングのユースケースを特定し、文書化する

NIST IR 8477は、対象とする文書を選定した後、実際のマッピングに着手する前に、前提条件を一つ以上のユースケースとして文書化するよう求めています。ユースケースはマッピングの文脈を示し、利用しやすさと透明性を高めます。具体的には、次の観点を整理します(図表1)。

図表1:マッピングのユースケースを文書化する際の確認事項

観点

確認事項

想定利用者

誰が利用するか。利用者に期待する知識やスキルも含める。

利用目的

なぜマッピングを作成し、どのような判断に用いるか。

対象とする概念タイプ

要求事項、管理策、成果、技術、役割など、何を比較するか。

方向性

概念Aから概念Bを見るのか、逆方向または双方向で確認するのか。

網羅性

全項目を対象とするのか、重要で直接的な関係に絞るのか。

概念タイプを選ぶ際には、ユースケースとの関連性、概念の粒度、比較する文書間の概念的な関係を考慮します。最小粒度での網羅的なマッピングが常に有用とは限りません。意図した利用者に必要な粒度を選び、強く直接的な関係を優先することが重要です。

3.3 Step 2|目的に適した概念関係スタイルを選択する

ユースケースを文書化した後、概念間の関係をどのような形式で表現するかを選択します。NIST IR 8477では、主に次の4つの概念関係スタイルが示されています(図表2)。

図表2:4つの概念関係スタイルと主な利用場面

スタイル

何を表すか

適した利用場面

Concept Crosswalk
(関連あり型)

二つの概念に関係があることのみを示す。関係の性質までは示さない。

関連情報への参照、初期調査、詳細評価前の候補整理。

Supportive Relationship Mapping
(支援関係型)

一方の概念が、他方の達成をどのように支援するかを示す。

規制要求と統制・実装施策の関係整理。

Set Theory Relationship Mapping
(包含・重複型)

同一、包含、部分的な重複など、概念間の共通範囲を示す。

規格の新旧版比較、類似基準間の差分分析。

Structural Relationship Mapping
(階層構造型)

親概念と子概念など、文書に内在する階層構造を示す。

機能、カテゴリ、サブカテゴリなどの構造整理。

スタイルは、マッピングの目的に応じて選択します。単純な参照関係を示す場合はConcept Crosswalk、達成への寄与を示す場合はSupportive Relationship Mapping、共通範囲を比較する場合はSet Theory Relationship Mapping、文書の階層を示す場合はStructural Relationship Mappingが適しています。必要に応じて、同じ概念ソースに複数のスタイルを組み合わせることもできます。

3.4 Step 3|選択したスタイルで関係を判定し、根拠を記録する

Step 3では、Step 2で選択した概念関係スタイルを、実際の要求事項や管理策の組み合わせへ適用します。ここで行うのは、単に「関係がある」と印を付けることではありません。選択したスタイルの定義に従い、二つの概念がどの関係タイプに該当するかを判定し、その理由を記録します。

Concept Crosswalk(関連あり型)を選択した場合

Concept Crosswalkでは、二つの概念に関係があることだけを記録します。関係の強さや方向までは示さないため、ユースケースが関係の意味を理解するための主要な文脈になります。

Supportive Relationship Mapping(支援関係型)を選択した場合

Supportive Relationship Mappingでは、一方の概念が他方の達成をどのように支援するかを判定します。NIST IR 8477では、次の6つの関係タイプが定義されています(図表3)。

図表3:Supportive Relationship Mappingにおける6つの関係タイプ

Supportive Relationship Mappingにおける6つの関係タイプ

SupportsまたはIs supported byを用いる場合は、支援する概念が支援される概念の達成においてどのような位置付けにあるかという関係の性質をさらに区別しています(図表4)。

図表4:支援関係の性質を示す3つの関係タイプ

関係タイプ

意味

Example of

支援する概念が、支援される概念を全部または一部達成する一つの方法・実装例である。

Integral to

支援する概念が、支援される概念を達成するために必要な構成要素である。

Precedes

支援する概念を先に達成する必要があり、支援される概念の前提条件となる。

例えば、概念Aの要求事項が概念Bの要求事項の達成に役立つものの、それだけでは概念Bを満たさない場合はSupportsとして整理します。その上で、概念Aが実装例に当たるのか、不可欠な構成要素なのか、前提条件なのかを判定します。

Set Theory Relationship Mapping(包含・重複型)を選択した場合

Set Theory Relationship Mappingは、二つの概念の論理的な共通性を集合として表します。また、関係タイプだけでなく、どの観点から二つの概念を比較したかを示すRationale(判定観点)を記録します(図表5)。

図表5:Set Theory Relationship Mappingにおける3つの判定観点

判定観点

意味

Syntactic

二つの概念を表す文言がどの程度類似しているかを、言語の解釈を加えず、語句単位で比較する。

Semantic

二つの概念の意味がどの程度類似しているかを、各概念の文言を一定程度解釈して比較する。

Functional

二つの概念を実装、実行または実施した場合に得られる結果がどの程度類似しているかを比較する。

関係タイプは、判定観点と組み合わせて解釈します。例えば、二つの要求事項の文言に一部違いがある場合、SyntacticではIntersects withとなっても、文脈上の意味が同じであればSemanticではEqualとなることがあります。したがって、Equalなどの関係タイプだけを記録するのではなく、Syntactic、SemanticまたはFunctionalのいずれの観点で判定したかを併記することが重要です(図表6)。

図表6:判定観点による関係タイプの違い

判定観点による 関係タイプの違い

Structural Relationship Mapping(階層構造型)を選択した場合

Structural Relationship Mappingは、通常、一つの文書に内在する概念の階層構造について、親概念と子概念の階層関係を記録します。ただし、親子関係は子概念が親概念の一部であることを示すにとどまり、子概念が親概念の達成に必須か任意かまでは示しません。必要に応じて、別のスタイルによるマッピングで補足します。

3.5 代表サンプルによる検証とレビュー

NIST IR 8477は、最初から全件をマッピングするのではなく、代表的なサンプルを任意の形式で作成することを推奨しています。サンプルを用いて、ユースケースやスタイルの選択に見直しが必要かを確認し、他の専門家によるレビューを通じて個人の偏りや不整合を抑えます。また、各関係の参照箇所と判断根拠を記録し、利用者がマッピングの意味を理解できる状態にします。

3.6 実務上の留意点

Concept Mappingは、二つの要求事項の関係を説明するものであり、法令や標準への準拠を自動的に証明するものではありません。同一、包含、支援、重複などの関係を区別し、適用条件や固有要件を別途確認する必要があります。

4.Concept Mappingを企業の規制対応にどう活用するか

NIST IR 8477は、異なる文書に含まれる概念の関係を、一貫した方法と用語で記録するアプローチを示しています。本章では、その考え方を企業の規制対応に応用し、要求事項の共通点や違いを整理する方法と、マッピング結果の活用ポイントを紹介します。なお、共通する管理目的や統制単位に関連付けた統合管理モデル(図表7)は、Concept Mappingの考え方を企業実務向けに発展させた当社独自の提案です。

4.1 複数の要求事項を共通の管理単位で整理する

企業が複数の規制等を管理する場合、文書同士を個別に結び付けるだけでは、対応関係が増えるほど全体像を把握しにくくなります。そこで、各文書の要求事項を「アクセス管理」「脆弱性管理」「インシデント対応」などの共通する管理目的や統制単位に関連付ける方法が考えられます。

図表7:共通する管理目的や統制単位に関連付けた統合管理モデルの構造

共通する管理目的や統制単位に関連付けた 統合管理モデルの構造

共通の管理単位を介して整理することで、複数の文書に共通する要求、文書ごとに要求水準が異なる部分、特定の文書に固有の要求を区別しやすくなります。さらに、共通統制に社内規程・業務・システムおよび評価手続・証跡を関連付ければ、外部要求と社内の対応状況を同じ構造で確認できます。

ただし、概念間に関係があることは、一方の要求への対応によって他方の要求も満たすことを意味しません。3.4で示した関係スタイルと判断根拠を用い、同一、包含、支援、部分的な重複など、関係の性質を区別することが重要です。

4.2 マッピング結果を規制対応の判断に活用する

マッピングの価値は、対応表を作成すること自体ではなく、概念間の関係を説明可能にする点にあります。NIST IR 8477が指摘するように、関係の意味、目的、前提、判断根拠が明示されていないマッピングでは、利用者が原文を読み直し、関係性を再評価しなければなりません。Concept Mappingを活用することで、従来の個別管理に生じやすい課題を、次のように見直すことができます(図表8)。

図表8:個別管理とConcept Mapping活用後の比較

観点

従来型

Concept Mapping活用後

判断活用への効果

要求事項の管理

要求事項を文書単位で個別管理

共通概念を介して整理・統合

共通対応と追加対応を整理しやすい

判断根拠

対応関係の理由が分かりにくい

関係性と判断根拠を記録

判断内容を説明・検証しやすい

規制改定への対応

改定時は広範囲の見直しが必要

変更箇所から影響範囲を特定

優先的に確認すべき領域を把握できる

判断の一貫性

個人の経験や解釈に依存

共通定義とレビュー基準を活用

評価結果のばらつきを抑制できる

利用目的の明確化

利用範囲や前提条件が不明確

ユースケースと適用範囲を文書化

結果の誤解や誤利用を防止できる

この整理により、利用者は、

  • ある要求への対応が別の要求をどの程度支援するのか
  • どの部分が不足しているのか
  • どの判断がどの前提に基づいているのか

を確認しやすくなります。また、標準の改定時には、変更された概念と関連するマッピングを起点として、再確認すべき範囲を絞り込むことができます。

一方、マッピング結果は、対象文書、ユースケース、概念の粒度および評価者の判断に依存します。そのため、結果を固定的な正解として扱うのではなく、利用目的に照らしてレビューし、前提条件や文書の変更に応じて更新する運用が必要です。

4.3 代表的な領域で試行し、継続的に更新する

3.5で確認したとおり、NIST IR 8477は代表サンプルによる検証を推奨しています。企業がConcept Mappingを実務に導入する際も、最初からすべての規制等や統制領域を対象とするのではなく、利用目的が明確で関係者の合意を得やすい領域から試行することが有効です。試行を通じて、概念の粒度、関係タイプの定義、判断根拠の記録方法について合意を形成し、その基準を他の領域へ順次展開します。

また、マッピングを継続的な情報資産として維持するためには、各関係の判断根拠と参照箇所を記録するだけでなく、規制等の改定や利用目的の変化に応じて定期的に見直す運用体制を整備する必要があります。こうした更新プロセスを組み込むことで、マッピングを作成時点の静的な比較表にとどめず、規制対応の意思決定を継続的に支える基盤として活用できます。

5.日本企業が取り組むべきアクション

企業には、増加・複雑化する規制等を個別に管理するのではなく、相互の関係を説明可能な形で整理し、継続的に維持できる管理基盤へ転換することが求められます。例えば、日本企業においても、個人情報保護法やサイバーセキュリティ経営ガイドラインなどの国内法令・ガイドラインに加え、NIST CSFやISO/IEC 27001といった国際標準、さらに海外顧客との取引に伴う契約上のセキュリティ要求が並行して求められる場面が増えており、共通の管理基盤の必要性は一層高まっています。

NIST IR 8477が示す、マッピングの目的と前提条件の明確化、関係の表現方法の選択、判断根拠の記録という考え方を踏まえると、企業として優先すべき取り組みは次の3点に整理できます。

  1. 規制等の要求事項をインベントリとして整備する
    自社に適用される要求を把握し、対象文書、利用目的、対象範囲および更新状況を共通の観点で整理します。
  2. 要求事項を集約して全社共通の統制を策定する
    文書ごとの要求事項を、共通する管理目的や統制単位に関連付け、共通部分と固有の差分を把握できる構造を整備します。
  3. 関係、粒度、方向性、判断根拠およびレビュー方法を標準化する
    マッピングの品質を組織として維持するため、概念間の関係を判断する基準、記録項目、レビューおよび更新の方法を定めます。

これらの取り組みにより、規制等ごとの共通点と差分を一貫した基準で把握し、新たな要求や改定が生じた際にも、既存の統制との関係を確認しやすくなります。重要なのは、網羅的な対応表を作成すること自体を目的とせず、組織として利用目的、判断基準および維持方法を定め、規制対応の意思決定に活用できる状態を構築することです。

6.おわりに

NIST IR 8477が示すConcept Mappingの要点は、異なる規制等の要求事項を単に対応付けるのではなく、マッピングの目的と前提を明確にした上で、概念間の関係とその判断根拠を一貫した方法で記録することにあります。これにより、マッピングを一時点の対応表ではなく、要求事項の共通点と差分を把握し、規制対応に関する判断を支える情報として活用できます。

規制等が増加し、改定も継続する中、文書ごとの個別対応だけで全体を管理することは難しくなっています。企業には、自社に適用される要求を把握するとともに、共通する管理目的や統制との関係を整理し、前提条件や原文の変更に応じてマッピングを見直せる仕組みを整えることが求められます。

まずは、利用目的が明確で関係者の合意を得やすい領域を選び、代表的な要求事項を用いてConcept Mappingを試行することが有効です。その結果を踏まえて、関係タイプ、判断根拠、レビュー方法および更新方法を組織として標準化し、対象領域を段階的に広げることが、複雑化する規制対応を継続的に管理するための現実的な第一歩となります。

執筆者

山本 直樹

パートナー, PwCコンサルティング合同会社

Email

道輪 和也

ディレクター, PwCコンサルティング合同会社

Email

脇田 典午

マネージャー, PwCコンサルティング合同会社

Email

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}

本ページに関するお問い合わせ