トップ > 脅威モデリング > 「Threat-composer AI」で脅威モデリングを自動標準化しよう（構成図も自動作成！）

「Threat-composer AI」で脅威モデリングを自動標準化しよう（構成図も自動作成！）

脅威モデリング threat-composer セキュリティ 構成可視化
記事タイトルとURLをコピーする

垣見です。

セキュリティ対策を検討する際、「とりあえずWAFを入れる」「ポートを閉じる」といった場当たり的な対応になっていませんか？ システムの全体像を把握し、どこにどのようなリスクがあるのかを構造的に理解するための手法が「脅威モデリング（Threat Modeling）」です。

Well-Architectedフレームワークにも、SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付けるで「やらない場合のリスクレベル：高」として載っています。

今回は、この脅威モデリングの考え方と、AWSが公開しているOSSツール「Threat-composer」、特にその中でも脅威モデル自動生成機能を活用した効率化について解説します。

そもそも「脅威モデリング」とは何か？

  • 脅威モデリング（Threat Modeling）：価値あるものを保護する状況において、脅威とその緩和策を特定し、伝達して理解する取り組み
  • 脅威モデル（Threat Model）：脅威モデリングを行うことで生まれるドキュメントのこと

※脅威：望ましくない影響を生じさせ、システムのセキュリティに悪影響を及ぼす恐れのある、偶発的または意図的なアクションや事象（攻撃、事故など）

つまり、あるワークロードに対して、想定されるセキュリティ脅威、脆弱性を事前に洗い出し、それらに対する緩和策をまとめた図（脅威モデル）を作るプロセスのことです。
想定脅威に対する具体的な緩和策の「実施」にまでは重きを置いておらず、脅威と緩和策の洗い出しまでが主なスコープです。（もちろん、その後緩和策の実施をできたほうが望ましいです）

重要なのは、「実装の前にやる」ことです。設計段階でリスクを洗い出すことで、後からの手戻りや、致命的な脆弱性の見落としを未然に防ぐことができます。

考え方・目的

これを実施しておくことで、何かあったときや、外部から「セキュリティは大丈夫か？」と聞かれたときに、「何の対策ができていて、何ができていないのか」を答える根拠になります。
また、セキュリティや脆弱性への対策の第一歩としても、まず体系的な洗い出しができていることで、限られたリソースを優先度の高い脅威への対策に使えるようになります。

やらないとどうなるか

アンチパターンとして書き出してみました。

  • セキュリティや脆弱性対策はやっているはずであるものの、手当たり次第に実施に取り組み、重大な脅威への対策を見落とす
  • 「そのシステムで考えられるリスクは何か」「もれなく対策ができているかどうか」がわからない
  • 外部や新規参入者に既存の脅威と「何にどこまで対策しているのか」を説明できず、退職者が出るなどで知識が途絶え、結果的に新規開発時の脆弱性などにつながる
  • 脅威モデリングは実施したものの、ワークロードのアップデートを反映する仕組みができておらず、現状に即していない

誰がやるべき？→「開発チーム自身」

脅威モデルの作成を担当する中央担当者または部門を設けることは、長期的にはうまくいきません。これらの中央組織はボトルネックとなり、人員を追加することでしか拡張できません。
さらに、所有権を集中化することで、ワークロードの機能を実際に設計および実装する担当者に権限を与えることができません。
脅威モデル化へのアプローチ方法より抜粋

開発者自身が脅威モデリングを行うことで、次のリソースで同じような脅威が生まれにくくなります。また、脅威モデル更新が現場の仕様変更に付いていくには、現場レベルでの実施が大切です。

理想は、すべての開発チームが、自分たちの開発フローの中で自主的に脅威を考慮できる体制を築くことです。

脅威モデリングの一般的な進め方

具体的にどう進めるべきか、標準的なフローをまとめました。
なお、やり方の座学的なところでは、AWSのワークショップがおすすめです。

①準備とゴール設定

  1. 概念の理解： チーム全体で「何のためにやるか」を合意します。AWS公式ワークショップの活用が近道です。
  2. 必要性の判断： 現状のリスク管理で不足している点（Well-Architected診断での指摘事項など）を明確にします。
  3. KPIの設定： 「実施ワークロード数」や「組織への浸透度」など、達成基準を決めます。

②分析と対策

  1. システムの可視化： データフロー図（DFD）、全体構成図を作成し、データの動きと対象ワークロードの定義を可視化します。
  2. 脅威の特定（STRIDE）： 先ほど作ったデータの流れのなかで、データをやり取りしている部分について、それぞれ以下の6つの観点でブレインストーミングを行い、脅威をリスト化します。（STRIDEというのは脅威モデリングの1手法です。他にもいろいろな手法があります）
    • Spoofing（なりすまし）
    • Tampering（改ざん）
    • Repudiation（否認）
    • Information disclosure（情報漏洩）
    • Denial of service（サービス拒否）
    • Elevation of privilege（権限昇格）
  3. 緩和策の検討： 特定した脅威に対し、以下のような戦略で緩和策、対策を書き出していきます。
    • 避ける： リスクの原因となる機能を実装しない。
    • 軽減緩和： 予防・検出・是正策を講じる（例：ログ取得の徹底）。
    • 移行： マネージドサービスの利用により、責任の一部をAWS側へ移す。
    • 受け入れる： コスト対効果を考慮し、リスクを許容する（理由の記録が必須）。

③運用と改善

  1. 設計への反映： 優先度に従って実際の設計・実装を更新します。
  2. プロセスのレビュー： 実施したプロセスが効果的だったか振り返り、次回の質を高めます。
  3. ライフサイクルの継続： システム変更のたびにモデルを更新し、常に「最新の脅威モデル」を維持します。

その他注意点など

脅威の特定に関するブレインストーミングは、ビジネスペルソナ、開発者ペルソナ、敵対者役ペルソナ、セキュリティ対策担当ペルソナ、脅威モデリング実施自体の責任者ペルソナ、など、複数の視点から考えることが重要と述べられています。
実際に日常的な運用としては、開発者が複数の視点で書く→チーム内レビュー、のような形が現実的だと思います。

また、最初のうちは脅威モデリングに慣れた人の手助けや、セキュリティに詳しい人の視点が必要になってくるかと思います。 ただ、忙しい開発チームに強制的な慣れない脅威モデリングの実行を強いると、スピード的にも気持ち的にも停滞してしまいます。

そこで、簡単に脅威モデルのたたきを作ることができるのが、 AWS公式（awslabs）が公開しているOSS Threat-composer です。

Threat-composerについて

Threat-composerとは？

脅威モデリング支援ツールです。脅威モデルの実体であるJSONファイルを統一した記載方法で用意でき、それをブラウザ・VSCode上・AWSアカウント上のセルフホスト静的ウェブサイトとして確認できるような機能が用意されています。

頻繁にアップデートされているようなので、詳細はREADMEもご覧ください。 github.com

また、皆さんが触ることが可能なライブデモも用意されています。ぜひまずはイメージをつかむために試してみてください。（英語ですがこの後日本語化の方法を紹介します）

主な特徴とメリット

  • 脅威文法の標準化： 「[誰が] [どんな条件下で] [何をすると] [どうなる]」という構文（「脅威文法」）を埋めるだけで、標準化された脅威記述が可能です。
  • ダッシュボード機能： 対応状況や優先度を視覚的に管理できます。統一されたダッシュボードがあることで、一定の記載方法の統一効果や閲覧時の認知負荷削減が見込めます。
  • 100% ローカル保存： データはブラウザのローカルストレージにのみ保存されます。
    • ※チームで共有する場合は、JSON形式でエクスポートしてGit等で管理する運用が必要です。
  • *脅威モデルの自動作成： 拡張機能である threat-composer-ai** を使うことで、Bedrockがソースコードを自動で読み取って最初の脅威モデル作成を自動化してくれます。（2025年12月に追加された新しい機能のようです）

今回は、AWS公式の脅威モデリング支援ツール Threat-composer の拡張機能である threat-composer-ai を使い、ソースコードをスキャンして「脅威モデルを自動生成」する方法を解説します。

  1. ディレクトリ解析： READMEや template.yaml (SAM) を読み取り、アプリの目的を理解。
  2. アーキテクチャ・データフロー生成： 構成からデータの流れを推論し、図解用コードを生成。
  3. STRIDE分析： 20件以上の現実的な脅威を自動特定。
  4. 緩和策の提案： 40件以上の具体的な実装レベルの対策案を提示。

注意点
実体は「ソースコードを任意のアカウントのBedrockで分析する」というものなので、任意のアカウントでAPI実行コスト（Bedrock利用料）がかかります。
2026年3月現在、デフォルトではClaude Sonnet 4global.anthropic.claude-sonnet-4-20250514-v1:0が使われるようです。

脅威モデリング実施の人的コストと比較してご検討ください。

見られるようになるもの

まずはどんなものが見られるの？ということで、先に結果を添付します。

実際に後述の日本語化を実施した後、こちらのワークショップ用ソースコードの/MachineLearning/3_Inferenceについて脅威モデリングを実行してみました。

AWS Toolkit拡張機能を使えばVSCode上でもGUIにて見ることができます。（右クリック→エディタを再度開くアプリケーションの選択→テキストエディタ、でJSONファイル原文も確認できます）

github.com

実行後、ソースコードに.threat-composerが追加されます
threatmodel.tc.jsonを開くと全体画面が出ます。ダッシュボード画面です。
Application info画面。どんなシステムかが自動で読まれます
Architecture画面。なんとロゴ入りの構成図も自動で作られます。
同じくArchitecture画面。文字でもきちんと詳細表示されます。
Dataflow画面。図も出ます。
Assumption（仮定）。ソースコードではわからないが前提とされる情報
脅威書き出し。「脅威の文法」に沿って書かれる。
Mitigations。緩和策が書き出されている
Threat model。これまでの概要や構成図・データフロー、脅威などを一覧化したもの。特に脅威・緩和策周りは専用ページと違いテーブル形式で表現されている
ダークモード切替、マークダウンコピーなども可能。なお、生成AIによる出力なので、同じスキャン対象ファイルでも表現は実行毎に微妙に異なる。

Threat-composer AI利用と日本語化を試してみた

実際に「Threat Composer AI 」を使ってみました。
筆者はVSCodeでUbuntu環境（WSL等）を用意して実行しています。macOSやRHELなどの場合はthreat-composer/docs/AI-CLI-MCP.mdを見て読み替えてください。

CLIツールとしてターミナルから直接利用する方法と、CLIツールを内包したMCPサーバーとしてKiro、Cline、Claude DesktopなどのAIコーディングアシスタント経由で利用する方法があるようです。
両方とも「同じ基盤となるワークフローを使用し、同一の出力を生成」するとのことなので、今回は前者のCLIツールを試してみます。

github.com

また、ウェブアプリケーションをセルフホストする方法も紹介されていますが、今回は実行せず、VSCode上での実行とします。

準備：ツールのインストール

まず、アーキテクチャ図とデータフロー図を生成するための描画エンジンとして graphviz をインストールします。

# 描画用エンジンのインストール
sudo apt-get install graphviz

# Graphvizが利用可能であることを確認
dot -V

threat-composer-aiツール本体をインストールします。
まずは公式GitHub経由でのインストールを行っていますが、後述の日本語化やその他カスタマイズしたthreat-composer-aiツールを利用する際にはローカルのソースコードを指定したり、自身の持つGitHubを指定したりしてください。

# threat-composer-ai のインストール (uvツールを使用)
uv tool install --from "git+[https://github.com/awslabs/threat-composer.git#subdirectory=packages/threat-composer-ai](https://github.com/awslabs/threat-composer.git#subdirectory=packages/threat-composer-ai)" threat-composer-ai

実行：ソースコードを解析させる

AWSの認証情報をセット（BedrockのClaudeモデルへのアクセス権限が必要です）します。 aws loginなどを使って、以下を実行したときに使いたいアカウントの使いたい認証情報が返ってくるような状態にしておいてください。

aws sts get-caller-identity

blog.serverworks.co.jp

脅威モデリング対象のプロジェクトディレクトリパスを指定して実行します。

# 脅威モデリングを実施したいプロジェクトを指定してCLIを実行
threat-composer-ai-cli <脅威モデリングを実施したいプロジェクトのパス>

実行すると、AIエージェントが自律的に動き出します。Strands Graph を介して連携する 8 つの専用エージェントが存在するそうです。

.threat-composer/20260313-0742/config/run-metadata.jsonを見ると、利用トークンや実行時間なども判ります。 今回の検証では、約66万トークン（入力44万/出力3万/プラスその他のキャッシュ類プロンプト）を処理し、8分ほどで脅威モデルが生成されました。

項目 トークン数
入力トークン 443,886
出力トークン 30,529
合計トークン 660,412

その他の実行情報：

  • 実行時間: 約469秒（約7分50秒）
  • モデル: デフォルト（Claude Sonnet）

生成された結果の活用

実行が完了すると、出力ディレクトリに以下のファイルが生成されます。

  • architectureDiagram.svg / dataflowDiagram.svg（構成図）
  • threats.tc.json（脅威リスト）
  • mitigations.tc.json（緩和策リスト）
  • threatmodel.tc.json（すべてを統合したモデルファイル）

この threatmodel.tc.json はVSCode上で確認（AWS Toolkit拡張機能が必要です）したり、Threat-composer（Web UI版） にインポートしてブラウザ上で見たりすることが可能です。

Toolkitの場合はファイルを開くだけで見ることができます。ブラウザ等で見る場合、jsonファイルをインポートしてあげる必要があります。

見た目のイメージは上記「見られるようになるもの」の章や、ライブデモをご確認ください。

※リソースの脆弱性を示した文書になるため、公開範囲等の取り扱いには十分ご注意ください。

生成結果が日本語になるようにする

デフォルトでは、threatmodel.tc.jsonの各説明文は英語で生成されます。

そこで、packages/threat-composer-ai/src/threat_composer_ai/agents/ 配下のすべてのファイルにおいて、prompt_textを日本語化し、かつ「すべての出力を日本語で生成してください。」という指示を冒頭に追加しました。
（kiro-cliを使って簡単に変更できました。）

また、threats.py のAI生成時のstatement文法パターンも忘れずに日本語対応させてください。 これにより、デフォルトでは英語に対応している脅威の文法（参考）を、日本語のものに変更します。

# 変更前 変更後
1 A/an [source] [prereq] can [action] [source]は、[prereq]、[action]できる
2 ...can [action], which leads to [impact] ...できる。これにより、[impact]が生じる

※こちら、VSCode上でAWS Toolkitを使って画面表記をする場合、コピーのボタンを押下した際にユーザーに渡される文章の部分（statementフィールド）は日本語化されますが、AWS Toolkit の threat-composer ビューアは 独自にバンドルされたUIを使っており、日本語化できません。気になる場合はブラウザで開いたり、ローカルでビルドしたアプリを使う方法を利用してください。

その他UIで気になる点があれば、ハードコードでコードを書き換えてあげる必要があります。

なお、今回日本語化したのはthreat-composer-ai/配下のプロンプトです。もしthreat-composer側の機能を書き換えたい場合はそちらのファイルも書き換えてあげてください。

では、先ほどインストールしたthreat-composer-aiのインストールを、github経由ではなく、ローカルの書き換えた日本語ファイル経由に置き換えます。

uv tool install </threat-composer/packages/threat-composer-aiのパス>

これで、再度aws-login等でAWSの認証情報をセットし、threat-composer-ai-cli を実行すると、各記載が日本語で返るようになります。

# 脅威モデリングを実施したいプロジェクトを指定してCLIを実行
threat-composer-ai-cli <脅威モデリングを実施したいプロジェクトのパス>

まとめ

「何に対してどこまで対策しているか」を言語化しておくことは、外部への説明責任を果たすだけでなく、チームに新しく入ったメンバーへの引き継ぎ資料にもなります。

しかし、「脅威モデリングをしろ」「一度やって終わりにするな」と言うのは簡単でも、実行は難しいです。

Threat-composer aiを使えばその部分をAIにお任せすることができます。 また、構成図・データフロー作成自動化にも役立つ、結構便利な機能だと思います。

このブログが誰かのお役に立てれば幸いです。

垣見(かきみ)(執筆記事の一覧)

2023年新卒入社　エンタープライズクラウド部所属　2025 Japan AWS Jr.Champions

図解するのが好き。「サバワク」のアイキャッチ作成も担当しています