脅威モデリングを活用した顧客ヒアリングのススメ

本記事は、脅威モデリング未経験のコンサルタントや事業会社セキュリティ担当者向けに脅威モデリングを活用したヒアリング手法を整理したものです。

1. はじめに

セキュリティの仕事をしていると、事業会社であれコンサルファームであれ、顧客（他の会社や部門）にヒアリングに行く機会が多いと思います。これはシステムや業務プロセスを理解し、適切なセキュリティ対策を検討するためです。

しかし、開発チームや業務部門に何度ヒアリングをしても、次のような課題にぶつかったことはないでしょうか。

• 説明を受けても、どのシステムやデータがどう連携しているかイメージが湧かない
• 会話が抽象的になり、「どこがリスクか」判断できない
• 資料を読んでも、構成が実際と違っていることが多い

結局、いくら話を聞いても「全体のつながり」が頭の中に描けない。 つまり、情報を“集める”ことと、“構造として理解する”ことの間には、大きな溝があるのです。

私も日々、業務プロセスやシステムのヒアリングをする中で、口頭での会話やドキュメントだけでは全体像を掴めず、担当者との対話も断片的になってしまいました。当時は複数のチームとの共通言語がなく、「どの部分がクラウドで、どの部分が社内にあるのか」を理解するだけでも時間がかかりました。

そんな中で役立ったのが、脅威モデリングです。脅威モデリングというと「攻撃手法を洗い出す専門的な分析手法」というイメージが強いかもしれませんが、実際にはその前段 モデリング = システム構造を共通言語で描くことこそが最初の一歩です。

私はこの「モデリング」だけを切り出し、ヒアリングと業務やシステム可視化のためのフレームワークとして使いました。その結果、直接業務やシステムに触らない立場でも短時間で全体像を整理し、「何を守るべきか」の焦点を明確にできました。

本記事では、その具体的なやり方を紹介します。難しい専門知識は不要です。「図を描いて会話する」だけで、脅威モデリングの本質を体験できます。 私は業務プロセス理解とシステム理解、どちらにも活用しています。しかし、この記事では話を簡単にするために、システム理解に絞って話を進めていきます。

2. よくある「システム理解」の手法とその限界

事業会社のセキュリティ担当者やコンサルがシステムを理解しようとするとき、最初に思い浮かぶのは次のような方法ではないでしょうか。

手法	よく使われる場面	メリット	限界
① 設計書や構成図を読む	開発チームから資料をもらうとき	体系的に整理されている	実際の運用や設定との差異が多い／更新されていない
② ヒアリングシートでヒアリング	コンサル案件やリスク評価で定番	抜け漏れなく質問できる	設問が形式的で、関係性や前提が伝わらない
③ アーキテクチャ図を再作成する	既存資料を整理し直す	構成を俯瞰できる	「なぜこの構成なのか」がわからない
④ 担当者への個別インタビュー	開発・運用担当者に直接聞く	現場の実態を知れる	情報が人依存で、全体像に統合しづらい

これらはどれも有効な手法です。
しかし、実際の現場では次のような問題に直面します。

1. 「静的な情報」に偏りやすい
   設計書や構成図はあくまで 一時点のスナップショットです。クラウドやSaaSが前提の今は、サービス構成や通信経路が日々変化しており、図面上の情報はすぐに古くなります。結果として、リスク分析の出発点である「現状把握」が、すでに現実とずれてしまうのです。

2. 「構造」ではなく「要素」を集めてしまう

多くのヒアリングシートは、

• どんなシステムがありますか？
• 認証はどうしていますか？

といった点（要素）単位の質問で構成されています。

しかし、セキュリティで重要なのは、「どの要素が、どこに、どうつながっているのか」という 線（関係性） です。要素の一覧を集めても、構造が見えない限り、脅威やリスクの推論はできません。

3. 「認識のズレ」がそのままリスクになる
   開発チームは「サービスの動作」を中心に話しますし、業務チームは「普段の個別業務」を中心に話します。しかし、セキュリティ担当は「全体像やリスクの所在」を中心に聞きます。この目的の違いから、同じ言葉を使っていても指している範囲が違うことが多いのです。

例えば――開発者が「外部API」と言ったとき、

• それが“社内ネットワーク外のSaaS”なのか、
• あるいは“自社クラウド上の別サービス”なのか、

を正確に把握できないまま議論が進むこともあります。このような前提のずれが、設計やリスク評価の誤りにつながります。

4. 「対話の共通図」がない
   ヒアリングやレビューの場では、担当者の頭の中にある“構成イメージ”を口頭で聞き取るしかありません。しかし、口頭の説明だけでは、参加者全員が同じイメージを共有するのは難しいです。

このとき有効なのが、「図」を使った対話ですが、一般的なアーキテクチャ図は “技術者向けの設計資料” であり、セキュリティやリスクを議論するには情報が過多で、会話のツールとしては扱いづらいのです。

5. 従来手法の“限界線”
   従来の手法は「正確な情報を集める」ことには長けていますが、「全員が同じ構造を理解する」ことには向いていません。

セキュリティコンサルやセキュリティ担当者が求めているのは、システムを“動き”として理解し、リスクを対話できる構造を描くこと。これを補うために、次章で紹介する「脅威モデリングのモデリング工程」を取り入れると、聞くだけでは見えなかった“つながり”が自然に浮かび上がってきます。

3. 脅威モデリングで“構造を理解する”メリット

前章で触れたように、従来の方法では「情報は集まるが、構造が見えない」という課題が残ります。
そこで役立つのが、 脅威モデリングの“モデリング工程 です。

脅威モデリングというと、「攻撃者の手口を洗い出す」「STRIDEやDREADでリスクを定量化する」といった専門的な手法を思い浮かべるかもしれません。

しかし、実務でまず効くのはその前段階―― システムを要素と関係性で整理し、全員が同じ構造を理解する ことです。この視点に立つだけで、ヒアリングの質が劇的に変わります。

会話が「要素」から「構造」へ変わる

脅威モデリングでは、「何が」「どこに」「どうつながっているか」を線で描きながら話します。
これにより、単なるQ&A型のヒアリングから、 図を見ながら考える対話 に変わります。

たとえば――
「ログはどこに保存していますか？」という質問に対して、口頭ではなく、図上で「この矢印の先がログ保存先ですよね？」と指しながら確認します。これだけで、会話の認識ズレがほぼなくなるのです。

設計図やアーキテクチャ図は、どうしても開発者視点の情報量になります。一方で脅威モデリングのモデリング工程は、 利用者とデータの動き を中心に描くため、専門知識がなくても理解しやすいです。

つまり、非技術者でも“構造の骨格”を掴める可視化手法になります。コンサルやリスクマネジメント担当が議論の主導権を持てるようになるのも大きな利点です。

「リスクを探す」より「守るものを明確にする」

脅威モデリングという名前のせいで「脅威」に注目しがちですが、最初に描くべきは「守るべき資産」と「その流れ」です。

この順序で考えると、
「何を守るか → どこを通るか → どこで脅威にさらされるか」
という自然なストーリーになります。

結果的に、「何を優先して守るべきか」が会話の中で明確になります。

顧客・関係者と“共に描ける”ことで合意形成が早まる

ヒアリングの場で一緒に図を描くと、開発・セキュリティ・業務・経営層が同じキャンバス上で議論できます。
この“共創的モデリング”の効果は想像以上に大きく、

• 「うちのチームがここを管理していたのか」
• 「この部分、他部署に依存していたんだ」
• 「こんな業務をこの部署がやっていたんだ」

といった“見落とし”が自然に浮かび上がります。

共通図を見ながら対話すること自体が、すでにリスクアセスメントの第一歩なのです。

メリットをまとめると以下のようになります。

観点	従来のヒアリング	モデリングを活用したヒアリング
会話の軸	質問リスト（要素中心）	図を使った対話（構造中心）
理解対象	各システム単体	システム間の関係と流れ
参加者の理解	技術者偏重	非技術者も巻き込める
成果物	メモ・資料	可視化された構造図
目的の明確化	リスク洗い出し中心	守るべき価値を明確化

💡 要するに
脅威モデリングを“ヒアリングの補助”として使うと、「情報を聞く」から「構造を描いて共有する」へと会話の質が変わる。これが、初心者でも実感できる最大のメリットです。

長くなってきたので、いったんここでまでにして、次の記事では具体的な活用ステップと私の業務活用事例をお話しようと思います。