STRIDE-AI × Human Factors」第5回
AI、人間、セキュリティをもう一度つなぐ―STRIDE-AI × Human Factorsを実務へ
この連載を始めた理由は、シンプルでした。
AIだけが、あまりにも速く進んでいる。
そのAIを使い、信じ、疑い、止め、そして失敗から戻らなければならない人間が、議論の後ろに置かれている。セキュリティも、導入後に追加する技術的な対策として扱われがちです。
私は、その状態に危機を感じました。
AIの性能を高めること。AIを業務へ導入すること。AIを適切に評価すること。どれも必要です。
けれど、実際の事故や被害は、モデルの精度だけでは説明できません。
AIが出した答えと、人がそれを信じた「間」。
人が承認し、システムが実行した「間」。
異常に気づきながら、誰にも言えなかった「間」。
止めようとしたけれど、すでに戻せなくなっていた「間」。
その見えにくい「間」に、Human Factorsとセキュリティがあります。
最終回では、これまで扱ってきたSTRIDE、五つのAIレイヤー、Human Factors、サイバー判断力、そして私が実務と研究の中で育ててきた判断の型「六動」を重ねてみます。
五日間で見てきたもの
第1回では、従来のSTRIDEが攻撃の種類を分類すること、AIの攻撃対象領域を五つのレイヤーで見ること、そしてHuman Factorsを、それらすべてを横断する条件として捉える考え方を示しました。
第2回では、過信、操作・誤用、権限混乱、疲労・技能低下、内部者・社会的リスクなど、人間と組織の条件が、技術的な脅威を増幅も阻止もすることを考えました。
第3回では、RAGチャットボットを例に、STRIDEのS、T、R、I、D、Eを具体的な攻撃シナリオへ落とし、人の判断がどこで揺らぐのかを見ました。
第4回では、Human-in-the-loopがあるだけでは安全装置にならないこと、人が理解し、疑い、拒否し、間に合う時点で介入し、失敗後に回復できて初めて、実効的な人間監督になることを示しました。
ここで、私の考えを一度、短くまとめます。
- STRIDEは、どのような脅威かを見せる。
- STRIDE-AIの五つのレイヤーは、脅威がどこを通るかを見せる。
- Human Factorsは、脅威がなぜ通り、なぜ止まるのかを見せる。
- サイバー判断力は、人が脅威に向き合うために必要な力を見せる。
- 六動は、その判断がどう動き、「間」の中でどう深まるかを見せる。
これが、私がこの連載で提案したかった社会技術的な脅威モデリングの全体像です。
STRIDEだけでは見えにくかったもの
STRIDEは、Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilegeという六つのカテゴリーから、システムに起こり得る脅威を体系的に問いかける方法です [1]。
強いフレームワークです。
ただし、AIシステムでは、脅威がモデルだけに閉じません。利用者とのインターフェース、アプリケーションやツール、モデル、インフラ、データソースへ広がります。STRIDEをAI/MLシステムへ適用する研究 [2]や、生成AIの攻撃対象領域を五層に整理してSTRIDEを適用する研究 [3]も、この複雑さを捉えようとしています。
それでも、技術コンポーネントとデータフローだけを描くと、まだ見えないものがあります。
なぜ、利用者は偽の出典を信じたのか。
なぜ、担当者は毎回同じ承認ボタンを押すようになったのか。
なぜ、セキュリティ担当者は異常に気づきながら、サービスを止められなかったのか。
なぜ、誰も責任者を特定できず、復旧が遅れたのか。
これは、人が弱いからではありません。
情報の見せ方、時間圧力、業務量、インセンティブ、役割、権限、組織文化、回復手段が、人の判断を形作っているからです。
NIST AI RMFも、AIを社会技術的なシステムとして捉え、人間とAIの役割、責任、監督、組織的なリスク管理を扱っています [4]。NISTのHuman-Centered Cybersecurityは、人を単なる弱点ではなく、情報を得て主体的に関与するパートナーとして位置づけ、人・プロセス・技術の関係を設計することを重視しています [5]。
Human Factorsを入れるとは、セキュリティ教育を一項目追加することではありません。
人が安全に判断できる条件そのものを、設計対象にすることです。
サイバー判断力と「六動」を、脅威モデルへ入れる
私は「サイバー判断力」を、セキュリティの知識量だけでは捉えていません。
この連載では、次の五つとして定義しました。
- 気づく―違和感や攻撃の手掛かりを認知する
- 意味づける―それが誤差か、攻撃か、漏えいの兆候かを考える
- 先を読む―採用・実行した場合の影響を予測する
- 選ぶ―確認、保留、拒否、停止、報告のどれを取るか決める
- 回復する―誤った後でも、取消し、封じ込め、調査、学習へ移る
最初の三つは、状況認識研究における環境要素の知覚、現状の理解、将来状態の予測という考え方と重なります [6]。サイバーセキュリティ専門家の判断研究でも、脅威の手掛かりを認知し、意味を理解し、将来の影響を予測する過程が、対策の選択に関係することが示されています [7]。
しかし、重要なのは、この能力を個人だけの責任にしないことです。
出典が隠れていれば、気づけません。
AIの推論と事実が混ざっていれば、意味づけにくい。
実行結果が見えなければ、先を読めません。
拒否権がなければ、選べません。
ログも取消し手段もなければ、回復できません。
したがって、サイバー判断力は採用や研修だけで高めるものではありません。インターフェース、ワークフロー、権限設計、評価制度、インシデント対応によって、発揮できることも、奪われることもあります。
ここへ、私が実務経験から考え、現在も研究上の検討を続けている「判断の型」を重ねます。
私はこれを、六つの動詞から六動と呼んでいます。
感じる → 止まる → 間をとる → 疑う → 質問する → 行動する
ただし、これは六つの固定された段階を、いつも同じ順番で進むという意味ではありません。
「感じる」は、違和感や小さなcueを認識する働きです。
「止まる」は、自動的に進みかけた判断や操作をいったん中断し、能動的な検討へ切り替える働きです。
「間をとる」は、最初の結論を未確定のまま保持し、再検討可能な状態をつくることです。
そして、その「間」の中で、疑う、代替仮説をつくる、質問する、確認する、解釈を更新するという活動が往復します。
そのうえで、人は、採用、拒否、修正、保留、相談、報告、エスカレーションなどの行動を選びます。行動の結果は新しいcueとなり、再び「感じる」へ戻ることがあります。
より正確に表すと、次のようになります。
この六動は、検証済みの一般理論ではありません。現時点では、判断の過程を観察し、問い直すための実務上・研究上の仮説的な型です。また、六つは同じ種類の段階ではありません。「感じる」は認識、「止まる」は移行、「間」は再検討可能性を保持する過程、「疑う」と「質問する」はその内部活動、「行動する」は次の循環へつながる後続現象として捉えています。
ここを曖昧にしないことが大切です。
六動は、人へ「正しい順番で考えなさい」と要求するチェックリストではありません。
脅威モデルの中で、人の判断がどこで始まり、どこで止まり、どこで深まり、どこで奪われるのかを見るためのレンズです。
六動の中心にある「間」
六動の中でも、私が特に注目しているのが「間をとる」です。
この「間」は、AIを遅くするための待ち時間ではありません。
AIの出力を、そのまま人の判断やシステムの行動へ直結させないための余白です。
違和感に気づくための、認知的な間。
根拠を確認し、別の可能性を考えるための、時間的な間。
異議を言い、別の専門家へ相談するための、社会的な間。
誰が決め、誰が止めるのかを明らかにする、権限上の間。
誤りの後に止め、戻り、学ぶための、回復の間。
すべての操作へ同じ長さの「間」を置く必要はありません。
重要なのは、影響、可逆性、不確実性に応じて設計することです。
- 影響が小さく、簡単に戻せる操作は、短い確認または事後サンプリング
- 外部送信や権限変更は、対象と差分のプレビュー、明示的承認
- 大量処理は、件数制限、段階的実行、途中停止
- 採用、医療、金融など人へ重大な影響を与える判断は、独立した検証、異議申立て、明確な責任
- 削除や公開など戻しにくい操作は、待機時間、二者承認、試験済みの回復経路
NIST AI RMFのHuman-AI Interactionに関する補足は、人がAI出力へ異議を唱えるために、どの程度力を与えられ、動機づけられているかを検討し、AIの判断を覆した頻度と理由を収集することの有用性を示しています [8]。
「間」があるとは、時間があることだけではありません。
問い返してよい、止めてよい、戻ってよいという許可と仕組みがあることです。
さらに、decision ownership―判断主体を保持すること―が、六動全体を横断します。
AIや他者の支援を受けながらも、自分が何を根拠に判断したのか、何がまだ分からないのか、なぜ採用・拒否・修正したのかを説明できること。AIを使わずに一人で決めることではありません。AIを使っても、判断主体が消えないことです。
六つの視点を重ねる
実務では、次の六つの視点を重ねます。
|
視点 |
問うこと |
得られるもの |
|
STRIDE |
どのような攻撃・脅威か |
脅威カテゴリー |
|
AIの五層 |
どこで起こるか |
攻撃対象と信頼境界 |
|
Human Factors |
何が脅威を増幅し、何が止めるか |
人間・組織の成功条件 |
|
サイバー判断力 |
人には、脅威に向き合うどの力が必要か |
必要な判断能力 |
|
六動 |
感じ、止まり、間をとり、疑い、質問し、行動できるか |
判断が動く過程と途切れる地点 |
|
Decision ownership |
支援を受けても、人が判断主体でいられるか |
根拠、不確実性、採否、責任の保持 |
この表は、既存規格の分類ではありません。本連載で提案する実務上の統合モデルです。
目的は、概念を増やすことではありません。
「人が確認する」「利用者が注意する」「問題があれば管理者へ連絡する」といった曖昧な対策を、テストできる問いへ変えることです。
一つの脅威を、最後まで書いてみる
例として、社内RAGエージェントが、検索した文書をもとに外部メールを作成・送信できるケースを考えます。
悪意ある文書がナレッジベースへ登録され、その中の間接プロンプトインジェクションによって、機密情報を外部へ送る指示がAIへ渡る。OWASPは、プロンプトインジェクション、過剰な機能・権限・自律性、人間とエージェントの信頼関係の悪用を、LLM／エージェント型システムの重要なリスクとして扱っています [9], [10]。
この脅威を、次のように書きます。
データソース層で取得文書の真正性と命令・データ境界が十分に保護されていないため、攻撃者は文書を改ざんし（Tampering）、RAGエージェントへ外部送信を指示できる。AIが信頼された社内文書を根拠として流暢に説明し、担当者が多数の承認を短時間で処理し、送信先と添付内容を容易に確認できないとき、過信、権威バイアス、疲労によって脅威が増幅される。その結果、機密情報の漏えい（Information Disclosure）と人の権限の代理利用（Elevation of Privilege）が起こり得る。
ここへ、サイバー判断力と六動を加えます。
感じる： 新規登録文書、外部宛先、通常と異なる添付を、違和感として認識できるよう目立たせる
止まる： 一括承認や即時送信を避け、進行中の操作を中断できるようにする
間をとる：最初のAI提案を未確定のまま保持し、文書の由来、送信先、添付、影響を再検討する
疑う： 「社内文書だから安全」「AIが引用したから正しい」という前提を問い直し、代替仮説を考える
質問する：原資料、ログ、別経路、別の担当者へ問い、情報源と権限を確認する
行動する：送信を採用、拒否、修正、保留、またはエスカレーションし、必要なら取消しと回復へ移る
そして全過程で、誰が何を根拠に判断し、どの不確実性を残し、なぜその行動を選んだかを保持します。
これで、脅威モデルは「プロンプトインジェクション対策をする」で終わらなくなります。
攻撃の入口から、人の判断、組織の権限、実行、事故後の回復まで、一つの経路として見えるようになります。
二時間で始める実務ワークショップ
この考え方は、大規模な新制度を作らなくても始められます。最初のワークショップなら、二時間程度でも構いません。
Step 1：AIではなく、判断と行動を定義する
モデル名から始めない。
AIは何を提案し、生成し、決定し、実行するのか。誰が影響を受けるのか。最悪の現実的な結果は何か。どこから戻りにくくなるのかを確認します。
Step 2：人を含めて、システムを描く
UI、アプリケーション、モデル、ツール、データ、ID、ログ、外部サービスを描きます。
そして、利用者、承認者、データ所有者、運用者、セキュリティ担当者、事故対応者も描きます。AIの提案が人の判断へ変わる場所、人の承認が実行へ変わる場所も信頼境界として扱います。
Step 3：各レイヤーへSTRIDEを当てる
各コンポーネントとデータフローについて、S、T、R、I、D、Eを問いかけます。
目的は、分類表を埋めることではありません。誰が、どの条件で、何を悪用し、どの資産や人に影響を与えるかというシナリオを作ることです。
Step 4：Human Factorsを横断させる
それぞれの脅威について、問いかけます。
- 成功するために、人は何を信じ、見落とし、疑わない必要があるか
- 確認作業は、実際の業務量と時間の中で可能か
- 誰に承認、拒否、停止、エスカレーション、回復の権限があるか
- 評価やインセンティブは、安全より速さを優先させていないか
- 警告への慣れ、疲労、技能低下、責任の拡散が起きないか
Human FactorsをSTRIDEへ統合する先行研究も、人間に関係する脅威を技術的な脅威モデルから切り離さず扱う必要性を示しています [11]。
Step 5：サイバー判断力と六動をテストする
「利用者は確認するはず」と書かない。
実際の画面、実際の時間、実際の業務量で試します。
偽の出典に違和感を感じられるか。反射的に進まず止まれるか。最初の結論を未確定にして「間」をとれるか。AIと自分の前提を疑えるか。原資料、ログ、別の人へ質問できるか。根拠が弱いときに保留・拒否・修正・エスカレーションできるか。実行後に戻れるか。そして、その判断をAI任せにせず、自分の理由と残る不確実性を説明できるか。
EU AI Act Article 14が高リスクAIシステムについて示す、能力と限界の理解、自動化バイアスへの認識、出力の無視・上書き・撤回、安全な停止という具体的な要素も、監督テストを設計する際の有用な参照になります [12]。
Step 6：予防だけでなく、検知と回復を置く
最小権限、認可付き検索、入力・出力検証、ツール制約といった予防策。
異常な検索、文書更新、承認速度、ツール利用を捉える検知策。
取消し、ロールバック、封じ込め、通知、証跡再構成といった回復策。
三つを組み合わせます。人を、技術的対策が失敗した後の最後の砦にしないことが重要です。
Step 7：責任者と再評価の時点を決める
誰が残余リスクを受け入れるのか。誰が停止を判断するのか。誰がデータ、モデル、Human Factorsの変化を監視するのか。
モデル更新、データソース追加、権限変更、業務量増加、事故、現場の回避行動があったときは、脅威モデルを見直します。
リスクを、偽りの精密さなしに考える
第1回の図では、次の関係を示しました。
Risk = Technical exploitability × Human amplification × Impact
これは、厳密な確率式ではありません。
優先順位を考えるための実務的なモデルです。
技術的に悪用しやすいか。
通常の業務、認知、組織条件が、その脅威をどの程度増幅するか。
起きたとき、どれほど大きく、戻しにくい影響があるか。
三つをLow、Medium、Highのような単純な尺度で評価し、理由を文章で残します。
ここで大切なのは、意見の違いを平均して消さないことです。
開発者は「確認画面があるからLow」と考え、現場は「一件ずつ確認する時間がないからHigh」と考えるかもしれません。
その食い違いこそ、隠れた前提です。
脅威モデルの価値は、きれいな点数を出すことではありません。異なる立場が持っている前提を見えるようにし、誰が何を変えるか決めることにあります。
何を測るか
実務へ移すなら、技術指標と人間・組織の指標を一緒に見ます。
- プロンプトインジェクションやデータ汚染の検知率
- 権限外の検索・ツール実行の遮断率
- AI提案の拒否、修正、保留の割合と理由
- 根拠確認に必要な時間
- 不自然に速い連続承認
- 異議とエスカレーションが解決されるまでの時間
- 誰が意思決定者か特定できない案件数
- 高影響操作におけるロールバック試験の成功率
- 事故から停止、封じ込め、復旧までの時間
- AIなしでも確認すべき業務における技能維持
どの指標も、単独では読みません。
拒否が少ないのはAIが優秀だからかもしれないし、拒否できない文化だからかもしれません。警告への反応が速いのは熟練しているからかもしれないし、読まずに押しているからかもしれません。
数字の背後にある業務と人を見なければ、Human Factorsの指標まで形式化します。
最後に―AIを止めたいのではない
私は、AIの進歩を止めたいわけではありません。
AIには、人の能力を広げ、面倒な作業を減らし、これまで届かなかった情報や支援を届ける可能性があります。
だからこそ、人間とセキュリティを置き去りにしたくないのです。
速く進むことと、安全に進むことは、反対ではありません。
ただし、安全は、最後に承認ボタンを置けば生まれるものでも、利用者へ注意を求めれば生まれるものでもありません。
AI、人間、セキュリティを、最初から一つのシステムとして設計する。
STRIDEで脅威の種類を問い、五つのレイヤーで攻撃経路を探し、Human Factorsで脅威が通る条件と止まる条件を見る。サイバー判断力によって、人に必要な力を具体化する。六動によって、人が感じ、止まり、間をとり、疑い、質問し、行動する過程と、その過程が奪われる地点を見る。そして、その全体を通して、人が判断主体でいられる技術、時間、権限、組織を設計する。
それが、私の提案するSTRIDE-AI × Human Factorsです。
新しい略語を増やすことが目的ではありません。
AIだけが爆走するのではなく、人間とセキュリティが、ともに前へ進めるようにする。
そのために、いま見えていない「間」を見えるようにする。
私は、そこから始めたいと思います。
参考文献
[1] S. Hernan, S. Lambert, T. Ostwald, and A. Shostack, "Uncover security design flaws using the STRIDE approach," MSDN Magazine, Nov. 2006. [Online]. Available: [https://learn.microsoft.com/en-us/archive/msdn-magazine/2006/november/uncover-security-design-flaws-using-the-stride-approach](https://learn.microsoft.com/en-us/archive/msdn-magazine/2006/november/uncover-security-design-flaws-using-the-stride-approach). Accessed: Sep. 10, 2026.
[2] L. Mauri and E. Damiani, "Modeling threats to AI-ML systems using STRIDE," Sensors, vol. 22, no. 17, Art. no. 6662, Sep. 2022, doi: [10.3390/s22176662](https://doi.org/10.3390/s22176662).
[3] T. N. R. Cyrille and F. Schwarz, "STRIDE-AI: A threat modeling framework for generative AI security assessment," arXiv:2605.17163, 2026, doi: [10.48550/arXiv.2605.17163](https://doi.org/10.48550/arXiv.2605.17163).
[4] National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, Gaithersburg, MD, USA, Jan. 2023, doi: [10.6028/NIST.AI.100-1](https://doi.org/10.6028/NIST.AI.100-1).
[5] National Institute of Standards and Technology, "Human-Centered Cybersecurity," NIST Computer Security Resource Center. [Online]. Available: [https://csrc.nist.gov/projects/human-centered-cybersecurity/about](https://csrc.nist.gov/projects/human-centered-cybersecurity/about). Accessed: Sep. 10, 2026.
[6] M. R. Endsley, "Toward a theory of situation awareness in dynamic systems," Human Factors, vol. 37, no. 1, pp. 32-64, Mar. 1995, doi: [10.1518/001872095779049543](https://doi.org/10.1518/001872095779049543).
[7] H. Hibshi, T. D. Breaux, M. Riaz, and L. Williams, "A grounded analysis of experts' decision-making during security assessments," Journal of Cybersecurity, vol. 2, no. 2, pp. 147-163, Dec. 2016, doi: [10.1093/cybsec/tyw010](https://doi.org/10.1093/cybsec/tyw010).
[8] National Institute of Standards and Technology, "AI Risk Management and Human-AI Interaction," NIST AI Risk Management Framework, Appendix C. [Online]. Available: [https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/](https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/). Accessed: Sep. 10, 2026.
[9] OWASP GenAI Security Project, "LLM01:2025 Prompt Injection," OWASP Top 10 for Large Language Model Applications. [Online]. Available: [https://genai.owasp.org/llmrisk/llm01-prompt-injection/](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). Accessed: Sep. 10, 2026.
[10] OWASP GenAI Security Project, "LLM06:2025 Excessive Agency," OWASP Top 10 for Large Language Model Applications. [Online]. Available: [https://genai.owasp.org/llmrisk/llm062025-excessive-agency/](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/). Accessed: Sep. 10, 2026.
[11] L. S. Ferro, A. Marrella, and T. Catarci, "A human factor approach to threat modeling," in HCI for Cybersecurity, Privacy and Trust, Lecture Notes in Computer Science, vol. 12788, Cham, Switzerland: Springer, 2021, pp. 139-157, doi: [10.1007/978-3-030-77392-2_10](https://doi.org/10.1007/978-3-030-77392-2_10).
[12] European Parliament and Council of the European Union, "Article 14--Human oversight," Regulation (EU) 2024/1689 (Artificial Intelligence Act), Jun. 13, 2024, Official Journal of the European Union, Jul. 12, 2024. [Online]. Available: [https://eur-lex.europa.eu/eli/reg/2024/1689/oj](https://eur-lex.europa.eu/eli/reg/2024/1689/oj). Accessed: Sep. 10, 2026.