STRIDE-AI × Human Factors 第2回
AI脅威を成功させるHuman Factors
STRIDE-AIの各層を横断し、技術的脅威が現実の事故へ変わる条件を、Human Factorsの6つの分析軸から考える。
過信、操作、誤用、権限混乱、疲労、内部者リスク
前回、私はSTRIDE-AIにHuman Factorsを掛け合わせる、という考え方を提示しました。今回は、そのHuman Factorsとは具体的に何なのかを考えてみたいと思います。
ここで最初に、明確にしておきたいことがあります。
Human Factorsは、「人は間違えるから教育しましょう」という話ではありません。人の認知、仕事量、権限、インセンティブ、組織文化、そしてシステムの設計が、互いにどう影響し合うのかを見るための視点です。
NIST AI Risk Management Framework（AI RMF）は、AIシステムを本質的に社会技術的なものとして捉えています。また、人間とAIの役割・責任を明確に区別する必要性、人間の認知バイアスがAIライフサイクル全体に入り得ること、同じAI出力でも人によって理解のされ方が異なることを示しています [1]。サイバーセキュリティのHuman Factors研究でも、個人だけでなく、組織と技術の関係を一緒に分析する必要性が指摘されています [2], [3]。
つまり、問題を「不注意なユーザー」に閉じ込めてしまうと、むしろ本当の原因を見失います。
本連載では、STRIDE-AIの各層を横断して確認するためのHuman Factorsを、次の6つに整理します。
- Overtrust / Overreliance（過信・過度な依存）
- Manipulation（心理的操作）
- Misuse（意図的・偶発的な誤用）
- Authority Confusion（権限・責任の混乱）
- Fatigue / Skill Decay（疲労・技能低下）
- Insider / Social Risk（内部者・社会的リスク）
この6分類は、既存の規格や先行研究にそのまま存在する公式分類ではありません。NIST、Human Factors研究、サイバーセキュリティ研究、OWASPの知見をもとに、STRIDE-AIの中で使える実務的な分析軸として私が再構成したものです。
1．Overtrust / Overreliance―もっともらしさを、正しさだと思ってしまう
生成AIの回答は、間違っていても自然です。文章は整い、説明には一貫性があり、自信があるように見えます。
人は、毎回すべてを疑って使うわけではありません。何度か役に立つ回答を得ると、その後の回答にも信頼を広げていきます。やがて、AIが示した結論を自分で検討するより、AIが見落としていないことを前提に仕事を進めるようになります。
これはautomation biasとして長く研究されてきた問題です。Goddardらのシステマティックレビューは、自動化された意思決定支援への過度な依存によって、システムが生み出す新しい誤りを人が見逃し得ることを整理しています [4]。
ここで重要なのは、「確認してください」と書けば解決するわけではないことです。
LyellとCoieraは、システムの判断が正しいかを確かめる作業の複雑さをverification complexityと呼びました。検証に多くの情報取得、変換、解釈が必要になるほど、人は自動化の誤りを発見しにくくなります [5]。
例えば、AIの回答を検証するために、引用された10個の文書を開き、それぞれの版、権限、作成日、前提条件を確認しなければならないとします。この状態で「最終確認は人が行う」と言っても、その確認は現実には成立しにくいでしょう。
問うべきなのは、利用者が注意深いかどうかだけではありません。
このシステムは、人が本当に検証できる形で情報を提示しているか。
2．Manipulation―AIは、判断を助けるだけでなく、判断を動かす
生成AIは情報を提示するだけではありません。言葉を選び、理由を組み立て、相手に合わせた説得を行えます。
攻撃者は、組織らしい文体、上司らしい指示、緊急性を感じさせる説明を大量に生成できます。RAGやエージェントでは、悪意ある文書やメッセージがAIの出力に取り込まれ、その出力を通じて人間の判断が誘導される可能性もあります。
OWASPの2026年版 Top 10 for Agentic Applications は、ASI09としてHuman-Agent Trust Exploitationを挙げています。自然な言語、知的に見える説明、擬人化、権威らしさなどが人間の信頼を生み、その信頼が意思決定の誘導や機密情報の取得、危険な操作の承認に悪用され得るとしています [6]。
これは単なるフィッシングの自動化ではありません。
人が「誰に説得されているのか」を見失う問題です。画面上ではAIと会話していても、その根拠に攻撃者が用意した文書が混ざっているかもしれない。説明はAIが生成していても、進む方向は悪意ある入力によって決められているかもしれない。
だからManipulationでは、禁止語を検出するだけでなく、根拠の出所、生成文と検証済み事実の区別、確信を過度に演出する表現、擬人化されたUIまで検討する必要があります。
3．Misuse―正規ユーザーでも、システムを危険にできる
AIセキュリティでは、外部の攻撃者ばかりを想像しがちです。しかし、正規のアカウントと正規の機能を使った行為でも、危険は生まれます。
社員が顧客情報をプロンプトへ貼り付ける。便利だからという理由で、本来は人が判断すべき処理を大量に自動化する。禁止された用途を別の言い方で試す。AIエージェントに与えられたツールを、想定されていない目的で使う。
こうしたMisuseには、意図的な悪用と、意図しない誤用の両方があります。
ただし、ここでも「ルールを守らない人」という説明で止めるべきではありません。安全な方法が極端に面倒で、危険な方法が最短経路になっていないか。生産性だけを評価し、慎重な確認を不利益にしていないか。機密情報を入力せずに目的を達成できる代替手段が用意されているか。
Misuseは、個人の意図だけでなく、システムが何を簡単にし、組織が何に報いるかによっても生まれます。
4．Authority Confusion―AIが提案し、人が押したとき、誰が決めたのか
AIが判断を支援し、別のシステムが実行するようになると、権限と責任の境界が曖昧になります。
AIが候補を作った。担当者が承認した。上司は「AIの推奨だった」と考えた。開発者は「最終判断は利用者だった」と説明した。ベンダーは「出力の利用方法は顧客の責任だ」と主張した。
こうして、全員が関わっているのに、誰も決めていないような状態が生まれます。
NIST AI RMF Coreは、Human-AI構成における役割と責任を定義し、区別するための方針と手続きを整えることを示しています。また、AIの開発・導入に伴うリスクについて、経営層が責任を担うことも明記しています [7]。
必要なのは、「Human-in-the-loop」と書くことではありません。
誰が提案するのか。誰が判断するのか。誰の権限で実行されるのか。誰が結果を監視するのか。誰が残余リスクを受け入れるのか。事故後に誰が説明するのか。
この線を引けないシステムでは、承認ログがあっても、責任は追跡できません。
5．Fatigue / Skill Decay―確認する人が、確認できなくなる
人を承認フローに入れると、安全性が高まったように見えます。しかし、同じような確認を何十回、何百回と求められれば、承認は判断ではなく反射になります。
さらに、自動化へ依存する時間が長くなると、異常を見抜くための状況認識や、必要なときに手動で対応する技能そのものが弱くなる可能性があります。EndsleyとKirisは、これをout-of-the-loop performance problemとして研究し、自動化によって受動的な情報処理へ移ることが、状況認識や障害発生後の対応能力を低下させ得ることを示しました [8]。
生成AIでも同じ問いが必要です。
AIが正常に動いている時間が長いほど、人は監視を弱めないか。説明を読む技能、原典を確認する習慣、AIなしで判断する能力が失われないか。異常時に引き継ぐ人は、最後にいつ自分でその作業を行ったのか。
教育は必要です。しかし、疲労と技能低下を教育だけで解決しようとするのは無理があります。承認件数、作業時間、インターフェース、権限分離、休止、ローテーション、演習まで含めて設計する必要があります。
6．Insider / Social Risk―組織の内側にある信頼と沈黙
AIシステムのデータ、プロンプト、設定、評価、アクセス権限は、人によって管理されています。
内部者は、必ずしも明確な悪意を持つ人物とは限りません。作業を早く終えるために認証情報を共有する。例外設定を戻し忘れる。未検証の文書をRAGへ登録する。問題に気づいても、責任を問われることを恐れて報告しない。
Human Factorsを扱うサイバーセキュリティ研究は、心理、ストレス、認知負荷だけでなく、組織文化、リーダーシップ、社会的圧力、内部者リスクを技術的対策と一緒に扱う必要性を指摘しています [2], [3]。
ここで見なければならないのは、個人の道徳性ではありません。
誰がデータを登録できるのか。誰がその変更を承認するのか。例外操作は監査されるのか。問題を報告した人は守られるのか。AIの判断に異議を唱えることが、チームの中で歓迎されるのか。
沈黙を生む組織では、ログに何も異常がなくても、リスクはすでに増幅しています。
Human Factorsは、脅威であると同時に、脅威を止める力でもある
ここまで読むと、Human Factorsを新しい脆弱性の一覧のように感じるかもしれません。
しかし、人はリスクを増幅するだけではありません。
文脈の不自然さに気づく。AIが参照していない背景知識を持ち込む。規則どおりに処理すると危険になる例外を見抜く。説明できない提案を拒否する。予想外の事故に対して即興的に対応する。
Human Factorsを分析する目的は、人間をシステムから排除することではありません。人の弱さだけでなく、人が持つ回復力や異議申し立ての能力を、どうすれば実際に機能させられるかを考えることです。
そのため、各Human Factorは、二方向から問う必要があります。
- この条件は、脅威をどのように成立・増幅させるのか。
- 同じ人間と組織の力を、検知・拒否・封じ込め・回復へどう使えるのか。
「注意してください」から、設計可能な問いへ
6つのHuman Factorsを並べる目的は、チェックリストを増やすことではありません。
過信が問題なら、利用者へ注意を促すだけでなく、検証コストを下げる。心理的操作が問題なら、文章だけでなく、出所と権威の見せ方を設計する。誤用が問題なら、安全な方法を最短経路にする。権限混乱が問題なら、提案・判断・実行・監督の責任を分ける。疲労が問題なら、人が処理できる量に承認を絞る。内部者リスクが問題なら、権限と監査だけでなく、異議を安全に言える文化を作る。
つまり、Human Factorsを入れることで、脅威モデルの問いが変わります。
「人は注意したか」ではなく、注意できるように設計されていたか。
「人が承認したか」ではなく、理解し、拒否し、結果を変えられる承認だったか。
「教育したか」ではなく、現実の仕事量と権限の中で、安全な行動を取り続けられたか。
AIセキュリティにHuman Factorsを入れるということは、人をもう一つの脅威として加えることではありません。
技術的な弱点が人と組織を通じて被害へ向かう経路と、人と組織がその経路を断ち切る可能性を、同じ脅威モデルの中で見ることです。
参考文献
[1] 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).
[2] A. Pollini et al., "Leveraging human factors in cybersecurity: An integrated methodological approach," Cognition, Technology & Work, vol. 24, pp. 371-390, 2022, doi: [10.1007/s10111-021-00683-y](https://doi.org/10.1007/s10111-021-00683-y).
[3] K. Khadka and A. B. Ullah, "Human factors in cybersecurity: An interdisciplinary review and framework proposal," International Journal of Information Security, vol. 24, Art. no. 119, 2025, doi: [10.1007/s10207-025-01032-0](https://doi.org/10.1007/s10207-025-01032-0).
[4] K. Goddard, A. Roudsari, and J. C. Wyatt, "Automation bias: A systematic review of frequency, effect mediators, and mitigators," Journal of the American Medical Informatics Association, vol. 19, no. 1, pp. 121-127, Jan.-Feb. 2012, doi: [10.1136/amiajnl-2011-000089](https://doi.org/10.1136/amiajnl-2011-000089).
[5] D. Lyell and E. Coiera, "Automation bias and verification complexity: A systematic review," Journal of the American Medical Informatics Association, vol. 24, no. 2, pp. 423-431, Mar. 2017, doi: [10.1093/jamia/ocw105](https://doi.org/10.1093/jamia/ocw105).
[6] OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications 2026, "ASI09: Human-Agent Trust Exploitation," pp. 33-35, 2026. [Online]. Available: [https://genai.owasp.org/download/52117/](https://genai.owasp.org/download/52117/). Accessed: Sep. 8, 2026.
[7] NIST AI Resource Center, "AI RMF Core," National Institute of Standards and Technology. [Online]. Available: [https://airc.nist.gov/airmf-resources/airmf/5-sec-core/](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/). Accessed: Sep. 8, 2026.
[8] M. R. Endsley and E. O. Kiris, "The out-of-the-loop performance problem and level of control in automation," Human Factors, vol. 37, no. 2, pp. 381-394, Jun. 1995, doi: [10.1518/001872095779064555](https://doi.org/10.1518/001872095779064555).