STRIDE-AI × Human Factors 第1回
AIセキュリティは、技術だけを見ていても足りない―STRIDE-AIにHuman Factorsを掛け合わせてみる
STRIDEの攻撃類型、STRIDE-AIの5層、そして脅威の成立を左右するHuman Factorsを重ねた、社会技術的な脅威モデリングの提案。
STRIDE-AIの考え方は、とてもよくできています。ただ、読みながら、どうしても一つだけ引っかかることがありました。
攻撃の種類は整理できる。攻撃される場所も整理できる。それでも、実際の事故がなぜ起きるのかを、最後まで説明できていないのではないか。
生成AIの事故は、モデルやシステムが技術的に破られたからだけで起きるわけではありません。人がAIの回答を信じた。確認を省いた。大量の承認に疲れて、いつものように「許可」を押した。AIが提案し、人が承認し、システムが実行したものの、結局誰が責任を持つのか分からなくなった。
こうしたことは、脅威モデルの外側にある「運用上の注意点」ではありません。技術的な脅威が、攻撃の成功や現実の事故へつながるかどうかを左右する中心的な条件です。
そこで私は、STRIDE-AIにHuman Factorsを掛け合わせて考えてみることにしました。
ただし、Human Factorsを「第7の脅威」や「第6のレイヤー」として付け足すわけではありません。人間要因は一つの場所に収まるものではなく、UI、アプリケーション、モデル、インフラ、データのすべてに入り込んでいるからです。
なお、ここで提示するSTRIDE-AI × Human Factorsは、現時点で確立された標準ではありません。Microsoft、NIST、OWASP、あるいはSTRIDE-AI論文の著者が定めた公式フレームワークでもありません。これは、AIセキュリティを人・組織・技術のつながりとして捉えるために、私が提案する一つの見方です。
図1．社会技術的な脅威モデリング・ビューとしての「STRIDE-AI × Human Factors」 古典的なSTRIDEは攻撃の種類を分類し、STRIDE-AIの5層は攻撃対象領域の位置を示す。Human Factorsは、脅威が認識されるか、増幅されるか、常態化するか、あるいは阻止されるかを左右する横断的条件として作用する。
STRIDEは、今でも強い
STRIDEは、Spoofing（なりすまし）、Tampering（改ざん）、Repudiation（否認）、Information Disclosure（情報漏洩）、Denial of Service（サービス拒否）、Elevation of Privilege（権限昇格）の頭文字を取った脅威分類です。
Microsoftの脅威モデリング実務の中で発展・普及し、Microsoft Threat Modeling Toolにも「STRIDE per Element」という形で組み込まれています［1］。
私は、この枠組みの強さは問いがシンプルなことにあると思っています。
誰かになりすませないか。データを書き換えられないか。操作を後から否認できないか。情報を盗み出せないか。サービスを止められないか。本来持っていない権限を得られないか。
技術が変わっても、これらの問いは古くなりません。ただ、生成AIでは、その現れ方が大きく変わります。
AIシステムは、モデルだけではない
生成AIアプリケーションを「モデルへの入力と出力」だけで考えると、かなりの部分を見落とします。
実際には、チャット画面があり、システムプロンプトがあり、検索やRAGがあり、外部文書が入り、プラグインやツールが動きます。その裏にはID、権限、ログ、データベース、クラウド基盤があります。自然言語で書かれた命令と、単なる参照データが同じコンテキストに入ることもあります。
OWASP GenAI Security Projectの2025年版Top 10には、Prompt Injection、Sensitive Information Disclosure、Data and Model Poisoning、Excessive Agency、Vector and Embedding Weaknesses、Misinformation、Unbounded Consumptionなどが挙げられています［2］。どれも、モデルだけを守れば解決する問題ではありません。
2026年5月に公開された論文 "STRIDE-AI: A Threat Modeling Framework for Generative AI Security Assessment" は、こうしたAIの攻撃対象領域を、ユーザーインターフェース、アプリケーション、モデル、インフラストラクチャ、データソースの5層に分けています［3］。
この整理を使うと、例えばTamperingはコード改ざんだけでなく、訓練データやRAG文書の汚染まで含めて考えられます。Information Disclosureは、モデル反転やプロンプトを介した秘密抽出としても現れます。同論文はElevation of Privilegeを、従来の管理者権限取得だけでなく、ガードレールの回避を含む形で再解釈しています。エージェント型システムでは、これにツール権限の越権利用も重ねて検討できます［3］。
ここは明確にしておきたいところです。STRIDEはMicrosoftの実務に由来しますが、STRIDE-AI論文はMicrosoftの公式フレームワークではありません。 著者はTsafac Nkombong Regine CyrilleとFranziska Schwarzであり、独立研究として提案されたものです［3］。論文自体も、現時点の検証は単一のサンドボックス事例に基づき、一般化には追加研究が必要だと限界を記しています。
それでも、まだ足りないと思った
STRIDE-AIを使うと、「どの種類の脅威が、どこにあるか」は見えやすくなります。
けれども、私はそこでもう一歩、聞きたくなります。
その脅威は、なぜ通ってしまうのか。
例えば、社内のRAGチャットボットが、検索先の文書に埋め込まれた悪意ある命令を読み込み、外部へのデータ送信を提案したとします。技術的には、間接的プロンプトインジェクション、出力処理、ツール権限などの問題として分析できます。
しかし、実際に被害が出るまでには、人間側の条件もあります。
利用者が、自然で自信に満ちた文章を正しいと思った。開発者が「社内文書だから安全」と考えていた。承認者が確認作業に疲れ、内容を読まず許可した。AIの提案に異議を唱えると仕事が遅れるため、誰も止めなかった。
このとき、壊れたのはモデルやフィルターだけではありません。人間とAIの関係そのものが、うまく設計されていなかったのだと思います。
NIST AI Risk Management Frameworkは、AIに関わる人の役割と責任、人間による監督、担当者の能力や認知バイアスを考慮する必要性を示しています［4］［5］［6］。ここで大事なのは、「人が見れば安全」という話ではなく、どのような人間とAIの構成なら本当に危険を止められるのか、という問いです。
Human Factorsは、全部の層を横切っている
Human Factorsを7番目のSTRIDE項目にすると、攻撃の種類と、攻撃が成功する条件を同列に置くことになります。第6レイヤーにすると、人間要因が特定の場所だけにあるように見えてしまいます。
私は、どちらも少し違うと考えています。
人はUIを見てAIを信頼します。アプリケーション上で承認します。モデルの説明を解釈します。インフラの例外操作を行います。データを登録し、更新し、時には間違えます。つまりHuman Factorsは、全部の層を横断しています。
そこで、三つの軸を次のように分けます。
- STRIDEは、攻撃の種類を分類する。
- 5つのAIレイヤーは、攻撃対象の位置を示す。
- Human Factorsは、その脅威がなぜ成立し、増幅され、常態化し、あるいは阻止されるのかを説明する。
Human Factorsを加える目的は、AIリスク全般を一つの図で網羅することではありません。技術的な脅威が、人間と組織を通じて現実のインシデントへ変わる経路を、脅威モデルの中に戻すことです。
ここでいうHuman Factorsには、AIへの過信、心理的操作、意図的・偶発的な誤用、責任と権限の混乱、監視疲労や技能低下、内部者や組織文化の問題などが含まれます。
ただし、これは「人間が一番弱い」という話ではありません。
検証しにくいUIを作っていないか。確認できない量の承認を人に投げていないか。拒否権があっても、実際には使えない職場になっていないか。責任だけを人に負わせ、判断に必要な情報や権限を渡していないのではないか。
Human Factorsとは、人を責めるためではなく、人が現実にどう判断するかを前提に、システムと組織を設計し直すための視点です。
Human-in-the-loopだけでは足りない
AIの安全性を説明するとき、「最後は人が確認します」という言葉をよく聞きます。
でも、私はこの言葉をそのまま安全策として受け入れないほうがよいと思っています。
承認者に根拠が見えない。確認に時間がかかり過ぎる。警告が多過ぎる。拒否すると業務が止まる。実行後に元へ戻せない。そのような状況では、人は安全装置ではなく、攻撃者が突破すべき最後のボタンになってしまいます。
必要なのは、単に人をループに置くことではありません。人がAIの提案を疑えること、拒否できること、止められること、そして失敗から回復できることです。
だから脅威モデルには、「承認者あり」と書くだけでは足りません。その人は、現実の業務環境で異常に気づけるのか。判断に必要な情報と時間があるのか。拒否しても不利益を受けないのか。実際に結果を変えられるのか。そこまで確認する必要があります。
技術的な弱点が、現実の被害に変わるまでを見る
私が考えるSTRIDE-AI × Human Factorsを、一文で表すとこうなります。
技術的に破られるリスクだけでなく、人がAIを誤信し、誤用し、あるいは悪用し、組織の役割、権限、インセンティブ、疲労、沈黙によって脅威が現実の被害へ変わる条件まで扱う、社会技術的な脅威モデリング・ビュー。
これは、STRIDE-AIの代わりになるものではありません。STRIDE-AIによって見えてくる攻撃類型と攻撃対象を、現実に人が働いている組織へつなげるための補助線です。
「プロンプトインジェクションは可能か」だけでなく、利用者はそれを見抜けるか。「人が承認するか」だけでなく、その人には本当に拒否する力があるか。「ログがあるか」だけでなく、事故後に誰の判断とどの処理が結果を生んだのか追跡できるか。そして失敗したとき、止めて、封じ込めて、元に戻せるか。
AIセキュリティは、モデルの内側だけを見ても完成しません。
技術上の弱点が、人間の信頼、疲労、権限配置、責任構造の中で、どのように現実の事故へ変わるのか。そこまで見えるようにすることが、この試みの出発点です。
参考文献
［1］Microsoft, ["Microsoft Threat Modeling Tool"](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool), Microsoft Learn（最終更新2022年8月25日、2026年9月7日閲覧）．
［2］OWASP GenAI Security Project, ["Top 10 for LLM and GenAI"](https://genai.owasp.org/initiatives/top-10-for-llm-and-genai/), 2025 edition（2026年9月7日閲覧）．
［3］Tsafac Nkombong Regine Cyrille and Franziska Schwarz, ["STRIDE-AI: A Threat Modeling Framework for Generative AI Security Assessment"](https://arxiv.org/abs/2605.17163), arXiv:2605.17163v1, May 16, 2026. 本稿では特にSection III、Section IV-A、Section VIを参照．
［4］National Institute of Standards and Technology, ["Artificial Intelligence Risk Management Framework (AI RMF 1.0)"](https://doi.org/10.6028/NIST.AI.100-1), NIST AI 100-1, January 2023.
［5］NIST AI Resource Center, ["Appendix 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/)（2026年9月7日閲覧）．
［6］NIST AI Resource Center, ["AI RMF Core"](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)（2026年9月7日閲覧）．