AIで脅威モデルを下書きする方法｜STRIDE対応プロンプトとレビュー手順
このプロンプトは、Webサービスや社内システムの設計情報から、脅威・攻撃経路・対策候補を整理した脅威モデルの初稿を作るためのものです。セキュリティ担当者だけでなく、設計レビューを準備する開発者、プロジェクトマネージャー、プロダクト担当者にも使えます。
AIに任せるのは、あくまで論点の洗い出しと文書化です。最終的なリスク評価や対策の採否は、システムを理解する担当者が確認してください。
この記事で分かることは次のとおりです。
- STRIDEを使ったコピペ用プロンプト
- AIへ渡す設計情報と、渡してはいけない機密情報
- 脅威、根拠、対策、残存リスクを分けて出力させる方法
- 曖昧な回答を減らす改善例
- 設計レビューでの具体的な使い方
このプロンプトで作るもの
完成イメージは、設計レビューの出発点になるMarkdown形式の脅威モデルです。
脅威モデリングは、攻撃側と防御側の観点からシステムを検討するリスク評価の一種です。OWASPは、次の4つの問いを基本にしています。
- 何を作っているのか
- 何が起こり得るのか
- それに対して何をするのか
- 十分に検討できたか
脅威を考える際は、次の6分類から成るSTRIDEを使います。
- Spoofing（なりすまし）：盗まれた認証情報などで別人を装う
- Tampering（改ざん）：通信、設定、保存データを書き換える
- Repudiation（否認）：操作記録が不足し、実行者を追跡できない
- Information Disclosure（情報漏えい）：許可されていないデータを取得する
- Denial of Service（サービス拒否）：大量の要求などで利用不能にする
- Elevation of Privilege（権限昇格）：本来より強い権限を得る
OWASPのThreat Modeling Cheat Sheetでは、システムを理解するために、外部エンティティ、処理、データストア、データフロー、信頼境界を明確にすることが示されています。プロンプトにも、この5項目を入力欄として含めます。
ここがポイント: AIに「脅威モデルを作って」とだけ頼むのではなく、システムの境界、守る資産、データの流れ、既存対策を先に渡します。入力が不足している場合は、推測で埋めず質問させます。
コピペ用の脅威モデル作成プロンプト
以下は、ChatGPT、Claude、Geminiなどの汎用LLMで使える形式です。2026年7月時点の特定サービス機能には依存していません。
あなたは、ソフトウェア設計レビューを支援するセキュリティ分析担当者です。
以下の情報を基に、STRIDEを使った脅威モデルの初稿を作成してください。
# 目的
設計段階で想定できる脅威を洗い出し、開発チームが対策の要否と優先順位をレビューできる状態にする。
# 対象システム
- システム名: {システム名}
- 用途: {利用目的}
- 利用者: {一般利用者、管理者、外部事業者など}
- 公開範囲: {インターネット公開／社内限定／その他}
- 想定する攻撃者: {未認証の外部者、一般利用者、内部者など}
# 構成要素
{ブラウザ、API、アプリケーションサーバー、データベース、クラウドサービスなどを列挙}
# データフロー
{誰が、どの経路で、どのデータを、どこへ送るか}
# 信頼境界
{インターネットと内部ネットワークの境界、サービス間、テナント間など}
# 守る資産
{個人情報、認証情報、決済情報、業務データ、監査ログなど}
# 認証・認可
{ログイン方式、ロール、権限判定を行う場所}
# 外部連携
{外部API、SaaS、Webhook、メール、ストレージなど}
# 既存のセキュリティ対策
{暗号化、アクセス制御、入力検証、レート制限、監視など}
# 前提・制約
{利用クラウド、法令、予算、可用性要件、対象外とする範囲など}
# 分析手順
1. 最初に、分析対象、外部エンティティ、処理、データストア、データフロー、信頼境界を要約する。
2. 情報不足や矛盾がある場合は、脅威を作る前に「確認が必要な事項」として質問する。
3. 各構成要素と信頼境界に対し、STRIDEの6分類を順番に検討する。
4. 脅威は「攻撃者が、どの入口から、何を行い、どの資産に何が起こるか」が分かる文章にする。
5. 入力情報から確認できる事実と、分析上の仮定を分ける。未知の構成や既存対策を推測で断定しない。
6. 各脅威について、既存対策、追加対策、検証方法、残存リスクを示す。
7. 同じ原因と影響を持つ重複項目は統合する。
8. 最後に、担当者がレビューすべき未確認事項を列挙する。
# 優先度
影響度と発生可能性をそれぞれ「高・中・低」で仮評価する。
入力情報だけでは判断できない場合は「要確認」とし、根拠のない点数を付けない。
優先度は次の順で決める。
- 最優先: 影響度が高く、既存対策がない、または有効性が未確認
- 優先: 影響度か発生可能性が高く、追加対策が必要
- 通常: 既存対策があり、検証または監視が必要
- 保留: 情報不足で判断できない
# 出力形式
Markdownで、次の順に出力する。
## 1. 対象と前提
- 対象範囲
- 対象外
- 守る資産
- 想定する攻撃者
- 仮定
## 2. システムモデル
- 外部エンティティ
- 処理
- データストア
- データフロー
- 信頼境界
## 3. 確認が必要な事項
質問を重要度順の箇条書きで示す。
質問が分析を左右する場合は、ここで一度停止する。
## 4. 脅威一覧
各脅威を次の書式で記載する。
### [脅威ID] {短い脅威名}
- STRIDE分類:
- 対象要素:
- 攻撃者:
- 入口・前提条件:
- 攻撃シナリオ:
- 影響を受ける資産:
- 想定される影響:
- 影響度: 高／中／低／要確認
- 発生可能性: 高／中／低／要確認
- 優先度: 最優先／優先／通常／保留
- 評価の根拠:
- 既存対策:
- 追加対策:
- 検証方法:
- 残存リスク:
## 5. 優先対応
最優先・優先の項目だけを、対応順と依存関係が分かる箇条書きで示す。
## 6. レビュー時の未解決事項
設計担当者、インフラ担当者、セキュリティ担当者に確認すべき内容を担当別に示す。
# 禁止事項
- 実在しない構成、脆弱性、事故、法的要件を事実として追加しない。
- 入力に含まれない既存対策を「実装済み」と扱わない。
- CVE番号や規格への適合を、根拠なく記載しない。
- セキュリティ上の最終判断やリスク受容を代行しない。
入力時に変える部分
精度を最も左右するのは、データフローと信頼境界です。 コンポーネント名だけでなく、どのデータが境界を越えるのかまで書いてください。
必ず変更する項目
{システム名}：分析結果を識別できる名称{利用目的}：利用者がシステムで実行する業務{利用者}：一般利用者、管理者、運用担当者などの役割{構成要素}：画面、API、サーバー、データベース、外部サービス{データフロー}：送信元、送信先、データ、通信経路{信頼境界}：認証状態、ネットワーク、組織、テナントが切り替わる場所{守る資産}：漏えい、改ざん、停止を避けたい情報や機能
たとえば「ブラウザからAPIへデータを送る」だけでは、認証状態やデータの重要度が分かりません。次のように具体化します。
一般利用者のブラウザは、インターネット経由で公開APIへHTTPSリクエストを送る。
リクエストにはセッショントークンと注文IDが含まれる。
APIは利用者の所有権を確認した後、注文データベースから対象レコードを取得する。
管理者画面は同じAPIを利用するが、別の管理者ロールを要求する。
これならAIは、トークンの窃取、注文IDの変更、所有権確認の欠落、管理者権限の誤用といった検討箇所を、対象要素と結び付けられます。
固定した方がよい条件
次の指示は、案件ごとに削らず残すのがおすすめです。
- 不明点を推測で埋めない
- 事実と仮定を分ける
- 各脅威に攻撃者、入口、資産、影響を含める
- 対策だけでなく検証方法を書く
- 判断できない優先度は「要確認」にする
- 最終判断を人へ戻す
AIへ入力する前に機密情報を取り除く
脅威モデルに必要なのは構造と関係であり、本物の秘密情報ではありません。
外部のAIサービスへ入力する場合は、所属組織の利用規程、契約、データ保持設定を確認してください。少なくとも、次の値はそのまま貼り付けず、ダミー値や抽象名へ置き換えます。
- APIキー、アクセストークン、秘密鍵、パスワード
- 実在する顧客の氏名、メールアドレス、住所、決済情報
- 本番環境の接続文字列や完全な内部URL
- 未公開の脆弱性情報や、悪用に直結する設定値
- セキュリティ監視を回避できる具体的な条件
たとえば、本番ホスト名は internal-api.example、APIキーは {API_KEY}、顧客データは {個人情報を含む注文データ} と置き換えます。置換後も、認証方式、通信方向、権限関係、データ分類は残してください。
対象システムにLLM機能が含まれる場合は、通常のSTRIDE分析に加え、プロンプトインジェクションも個別に検討します。OWASPのPrompt Injection解説は、意図しない動作、機密情報の開示、接続機能の不正利用などを影響として挙げています。
失敗しやすい指示と改善例
短い依頼は入力しやすい一方、一般論の一覧になりがちです。
NG例：対象が見えない
新しいWebサービスの脅威モデルを作ってください。
危険なところと対策を一覧にしてください。
この指示では、AIは利用者、資産、境界、認証方式を判断できません。「SQLインジェクションに注意する」「暗号化する」といった、対象箇所や検証方法が分からない回答になりやすくなります。
改善例：脅威をデータフローに結び付ける
会員が注文履歴を確認するWebサービスをSTRIDEで分析してください。
構成:
- 会員ブラウザ
- 公開API
- 認証サービス
- 注文データベース
データフロー:
- ブラウザはセッショントークンと注文IDを公開APIへ送る
- 公開APIは認証サービスでトークンを検証する
- 公開APIは会員IDと注文IDを使って注文データを取得する
守る資産:
- 会員の個人情報
- 注文内容
- セッショントークン
各脅威について、攻撃者、対象要素、入口、攻撃シナリオ、影響、既存対策、追加対策、検証方法を示してください。
情報不足なら推測せず、先に質問してください。
改善したのは、単に文章を長くした点ではありません。AIが脅威を検討する単位を、実在する構成要素とデータの移動に固定した点が重要です。
出力を安定させる3つのコツ
脅威の件数を増やすことより、レビュー可能な根拠を残すことを優先します。
1. 脅威の書式を固定する
「脅威名」だけでは、対策の担当者やテスト方法を決められません。脅威ID、攻撃者、入口、影響資産、既存対策、追加対策、検証方法を毎回同じ順番で出力させます。
Markdownの小見出し形式なら、WordPress、GitHub Issue、設計書へ移しやすく、長い攻撃シナリオも読みやすくなります。管理ツールへ取り込む場合は、出力をJSONへ変更しても構いません。
脅威一覧のみ、次のJSON配列で出力してください。
JSON以外の説明文は付けないでください。
[
{
"threat_id": "T-001",
"title": "{脅威名}",
"stride": "{STRIDE分類}",
"component": "{対象要素}",
"scenario": "{攻撃シナリオ}",
"affected_asset": "{影響を受ける資産}",
"impact": "high | medium | low | needs_review",
"likelihood": "high | medium | low | needs_review",
"mitigation": ["{追加対策}"],
"verification": ["{検証方法}"],
"assumptions": ["{分析上の仮定}"]
}
]
2. 優先度の根拠を要求する
「高・中・低」だけを出力させると、判断基準が見えません。影響を受ける資産、攻撃に必要な条件、既存対策の有無を根拠欄に書かせます。
発生可能性を判断する材料がなければ「要確認」とする方が実務的です。見かけ上きれいな評価表を作るために、根拠のない点数を埋めてはいけません。
3. 1回で完成させない
最初の出力は、次の3段階でレビューします。
- システムモデルの確認：構成要素、データフロー、信頼境界に誤りがないか
- 脅威の確認：攻撃シナリオが対象システムで成立するか
- 対策の確認：実装可能か、既存対策と重複しないか、テストできるか
OWASPは脅威モデルを一度作って終わる成果物ではなく、システムとともに更新・改善するものと位置付けています。設計変更、新しい外部連携、認証方式の変更があったときは、同じプロンプトへ差分を入力して再検討します。
活用例：設計レビューを3つの役割に分ける
AIの出力をそのまま承認資料にせず、担当者ごとの確認事項へ変換すると使いやすくなります。
開発者が確認すること
- 入力検証、認可判定、エラー処理を実装できるか
- 攻撃シナリオを自動テストや結合テストにできるか
- 提案された対策が既存機能と競合しないか
インフラ・運用担当者が確認すること
- ネットワーク境界、IAM、秘密情報の管理が実構成と一致するか
- レート制限、監視、アラート、バックアップで検知・復旧できるか
- クラウド事業者と利用者側の責任分担が明確か
セキュリティ担当者が確認すること
- 想定する攻撃者と保護対象に抜けがないか
- リスクの優先順位と受容判断に根拠があるか
- 対策後の残存リスクを誰が承認するか
NIST IR 8397でも、脅威モデリングは設計レベルのセキュリティ問題を探す手法として挙げられています。ただし、静的解析、動的テスト、ファジングなどを置き換えるものではありません。脅威モデルで見つけた論点を、具体的な検証項目へつなげる必要があります。
実行前後のチェックリスト
最後に、プロンプトを使う前後で次を確認してください。
- [ ] 対象範囲と対象外を分けた
- [ ] 外部エンティティ、処理、データストアを列挙した
- [ ] データフローと信頼境界を書いた
- [ ] 守る資産と想定する攻撃者を指定した
- [ ] APIキーや個人情報などの機密情報を除いた
- [ ] AIが追加した仮定を事実と混同していない
- [ ] 各脅威に攻撃者、入口、資産、影響がある
- [ ] 優先度に根拠がある
- [ ] 対策に検証方法と担当者を割り当てた
- [ ] 設計担当者とセキュリティ担当者が最終確認した
最初に見直すべきなのは、AIが挙げた脅威の数ではありません。システムモデルに誤りがないか、情報不足を仮定で埋めていないかです。ここが曖昧なら、対策案を増やす前にデータフローと信頼境界を修正してください。