STRIDE-AI × Human Factors 第4回 Human-in-the-loopは、それだけではセキュリティ対策にならない
「人がいる」から「人が制御できる」へ
先日、AIに関する講義とAIアセスメントを受けました。
内容はとてもよく整理されていて、学ぶことも多くありました。AIの能力をどう評価するか。どのように業務へ導入するか。どこに可能性があり、何に注意すべきか。いま必要とされている論点が、幅広く扱われていました。
それでも私は、途中から、ある違和感を覚えました。
あれ、セキュリティは？ 人間は？
そこには、人間とセキュリティの視点が、ぽっかり抜け落ちているように見えたのです。
AIの能力や活用については多く語られているのに、そのAIと向き合う人間、そして両者を取り巻くセキュリティが、十分につながって見えませんでした。
少なくとも、私が目にしてきた多くのAI講習では、AIの性能評価、人間による確認、セキュリティ対策が、別々の項目として置かれています。
けれど、実際の事故は、その「間」で起こります。
AIの出力を、人はなぜ信じたのか。
違和感があったのに、なぜ止められなかったのか。
誰の権限で、どこまで実行されたのか。
攻撃や誤りに気づいたとき、誰が止め、誰が元に戻すのか。
AIの性能だけを評価しても、こうした問いには答えられません。
人間の判断だけに責任を負わせても、解決しません。
セキュリティを技術的な防御だけに閉じ込めても、実際のリスクは見えてきません。
AI、人間、セキュリティ。その三つを別々ではなく、一つのシステムとして見なければならない。
私は、その必要性を強く感じました。
AIの能力、導入、活用、評価は、ものすごい速さで前へ進んでいます。一方で、人はどのように判断するのか。誰が疑い、誰が止めるのか。攻撃や誤用から、どう守るのか。問題が起きたとき、どう戻るのか。
その議論と設計が、AIの進む速さに追いついていないように感じます。
AIだけが爆走し、人間もセキュリティも置いていかれている。
少し強い言い方かもしれません。
それでも私は、そこに危機を感じます。
「高リスクの操作は、最後に人が承認します」
そう言われると、少し安心します。
でも、私はここに引っかかります。
その人には、AIが何をしようとしているのか、本当に見えているでしょうか。根拠を確かめる時間はあるでしょうか。おかしいと思ったとき、止められるでしょうか。そして、拒否したことで「仕事を遅らせた人」にならないでしょうか。
人をループに入れることと、人に制御を渡すことは、同じではありません。
承認ボタンの前に人を置いても、その人が不完全な要約しか見られず、何十件もの確認を急いで処理し、AIの提案を断る権限も、実行後に戻す手段も持っていなければ、その人は安全装置ではありません。
自動化された経路の、最後のクリックになっているだけです。
今回は、Human-in-the-loopを「人がいるか」ではなく、人が実際に結果を変えられるかという観点から考えます。
ここで示す「STRIDE-AI × Human Factors」は、既存の標準や公式フレームワークではありません。STRIDEをAIシステムに適用する先行研究を踏まえ、Human Factorsを各レイヤーに横断する脅威の増幅・阻止条件として捉える、私自身の社会技術的な分析ビューです。本稿で示す五つの能力も、そのための実務的な整理です。
「承認」があるのに、なぜ止まらないのか
例えば、AIエージェントが次の操作を提案したとします。
顧客対応を完了するため、添付ファイルを外部の取引先へ送信します。続行しますか？
画面には「承認」と「キャンセル」があります。
しかし、送信先は省略表示され、添付ファイルの中身は開かないと分からない。AIがなぜそのファイルを選んだのかも見えない。担当者には未処理案件が80件あり、これまで同じ確認を何度も承認して問題は起きていない。
この状態で承認を押したとき、原因を「担当者の確認不足」と呼んでよいのでしょうか。
自動化バイアスの研究では、人が自動化された助言を過度に信頼し、システムの誤りに気づかない、あるいは誤った提案に従う可能性が示されてきました [1], [2]。さらに、AIの判断を検証するために多くの情報取得・変換・解釈が必要になるほど、認知負荷が高まり、自動化バイアスが生じやすくなる可能性があります [2]。
長く自動化に依存すると、異常時に人が状況を把握し、手動で引き継ぐ力が弱まる「out-of-the-loop」の問題もあります [3]。
つまり、問題は「人が注意深いか」だけではありません。
人が何を見られるのか。確認に何分使えるのか。拒否すると何が起きるのか。止める権限は誰にあるのか。日常的な運用の中で、判断する力が維持されているのか。
Human Factorsを入れるとは、この条件まで脅威モデルの中へ入れることです。
判断するための「間」を残す
そして、もう一つ必要なのは、AIの提案と人の行動のあいだに、判断のための「間」を残すことです。
ここでいう「間」は、単なる待ち時間ではありません。
違和感に気づき、その意味を考え、起こり得る影響を想像する。根拠を確かめ、必要なら保留し、拒否し、別の人へ相談する。そのための認知的、時間的、そして組織的な余白です。
AIが答えを出した瞬間に、そのまま実行へ進む設計では、サイバー判断力を発揮する場所がありません。
ただし、すべての処理を遅くすればよいわけでもありません。何に「間」が必要かは、行動の影響、可逆性、不確実性に応じて変わります。低リスクで戻せる操作には短い確認でよい。一方、外部送信、権限変更、削除、採用・医療・金融のような高影響判断には、立ち止まり、別の根拠や人へつなぐ余白が必要です。
人をループに入れるのであれば、同時に、人が判断するための「間」を設計する必要があります。
実効的な人間監督に必要な五つの能力
私は、Human-in-the-loopがセキュリティ上の制御として機能するには、少なくとも次の五つが必要だと考えています。
- 理解できる――Understand
人は、AIが提案する操作について、少なくとも次を理解できなければなりません。
- 何をするのか
- 誰に、何に影響するのか
- 誰の権限で実行するのか
- 何を根拠に提案しているのか
- どこに不確実性があるのか
- 失敗したら何が起きるのか
「このツールの使用を許可しますか」という表示では、リスクだけを人へ移し、理解に必要な情報を渡していません。
必要なのは説明の長さではなく、判断に必要な差分です。送信なら宛先、対象データ、公開範囲。権限変更なら、誰の権限がどこまで変わるか。削除なら、対象、件数、復元可能性を、実行前に見せる必要があります。
これは前回述べたサイバー判断力の出発点でもあります。異常に気づき、意味を理解し、先の影響を予測するには、まず判断材料が見えていなければなりません。
- 疑い、問い返せる――Challenge
AIの提案を理解するだけでは足りません。根拠を疑い、別の可能性を確かめられる必要があります。
出典は真正か。取得した文書は最新版か。反対の証拠はないか。AIが示した説明は事実か、それとも推論か。組織のポリシーと矛盾していないか。
画面には、出典、変更履歴、権限、競合する情報、適用されたルールを確認できる経路が必要です。ただし、全部を一度に見せればよいわけではありません。確認すべき箇所が埋もれれば、検証の複雑さを上げるだけです [2]。
そしてchallengeは、UIだけでは作れません。
「AIに逆らうなら理由を説明して」と人には求めるのに、AIの提案は理由なく通る。異議を出すと処理時間の評価が下がる。上司が導入したシステムなので、疑問を言いにくい。
このような環境では、問い返すボタンがあっても、問い返す力はありません。
NIST AI RMFのHuman-AI Interactionに関する補足も、人がAI出力へ異議を唱えるために、どの程度力を与えられ、動機づけられているかを検討課題として挙げています。また、AI出力を人が覆した頻度と理由の収集が有用だとしています [4]。
- 拒否し、修正できる――Refuse or modify
人には、承認かキャンセルかだけでなく、提案を拒否し、狭め、修正し、保留する選択肢が必要です。
AIが500人へのメール送信を提案したとき、安全な答えは「全部送る」か「全部やめる」だけではありません。宛先を10人へ絞る。添付を外す。下書きとして保存する。法務確認へ回す。翌日まで保留する。こうした介入ができて初めて、人は判断者になります。
ただし、拒否権は画面上にあるだけでは足りません。
締切のため事実上断れない。拒否しても別経路でAIが実行する。担当者には止める職位がない。差戻しが人事評価で不利になる。
その場合、拒否権は形式的です。
ここにはauthority confusion、つまり権限と責任の混乱が入ります。誰が提案し、誰が判断し、誰が実行し、誰が停止できるのかを分けなければ、「人が承認した」という一行だけが残り、組織の責任が人へ押し戻されます。
- 間に合う時点で介入できる――Intervene in time
監督は、結果を変えられる時点に置かなければ意味がありません。
外部メールが送られた後。データが公開された後。権限が変更された後。資金が移動した後。そこで人へ通知しても、それは監督ではなく事後確認です。
影響に応じて、実行前プレビュー、段階的実行、取引上限、公開までの待機時間、二者承認、リアルタイム停止などを組み合わせる必要があります。低リスク操作は事後サンプリングでもよいでしょう。一方、取り返しのつかない高影響操作には、独立した確認と安全な停止が必要です。
OWASPはExcessive Agencyへの対策として、AIに与える機能、権限、自律性を必要最小限にし、高影響操作では人の承認を求めることを挙げています [5]。重要なのは、その承認を単独の防壁にしないことです。下流システムでの認可、最小権限、実行範囲の制約、監視も必要です [5]。
- 失敗後に回復できる――Recover
すべての事故を承認前に止めることはできません。
だから、人間監督には、実行後の取消し、ロールバック、封じ込め、通知、調査も含める必要があります。
誰に連絡すればよいか。どの操作を止められるか。誤送信先を特定できるか。変更前の権限へ戻せるか。どのプロンプト、データ、モデル、承認、ツール実行が結果につながったか再構成できるか。
回復経路がなければ、人は異常に気づいても、被害を小さくできません。
サイバー判断力は「正しい判断を一度で当てる力」ではありません。間違いが起きた後に、気づき、止め、影響を限定し、学び直せる力まで含みます。
法制度が示しているのも、「人を置く」以上のこと
EU AI ActのArticle 14は、高リスクAIシステムに対し、自然人による実効的な監督が可能となるよう設計・開発することを求めています [6]。
同条が具体的に挙げるのは、システムの能力と限界を理解すること、自動化バイアスを認識すること、出力を正しく解釈すること、出力を使わない、無視する、上書きする、または撤回すること、そして安全な状態で停止できることです [6]。
これは、すべてのAIシステムへそのまま適用される一般要件ではありません。Article 14の対象は同法上の高リスクAIシステムです。
それでも、実効的な監督を設計する問いとしては、とても具体的です。
NIST AI RMFも、人間とAIの構成における役割と責任を区別し、監督プロセスを定義・評価・文書化することを示しています [7]。経営層の責任も明記されており、最終確認者一人へリスクを押しつける考え方ではありません [7]。
人を置くことではなく、人が理解し、判断し、結果を変えられる状態を設計すること。ここが共通しています。
「何件、人が確認したか」だけでは測れない
Human-in-the-loopの有効性を、「人手確認率100%」だけで評価すると、本質を見失います。
例えば、次のような指標を組み合わせて見る必要があります。
- AIの提案を拒否・修正・保留した割合と、その理由
- 根拠の確認に要した時間と、確認できた証拠
- 承認後に取り消された判断の件数
- 高影響操作のうち、実際に試験済みのロールバック経路を持つ割合
- 判断者同士の不一致率と、エスカレーションの内容
- 不自然に短時間で繰り返される承認
- AIなしでも確認すべき業務における技能維持
- 事故後、実質的な意思決定責任者を特定するまでの時間
ただし、一つの数字だけで結論を出してはいけません。
拒否率がゼロなのは、AIが完璧だからかもしれない。あるいは、人が何も見ずに承認しているのかもしれません。拒否率が高いのも、人がよく機能している場合と、AIの品質が低すぎる場合があります。
指標は、インタビュー、業務観察、シナリオ演習、インシデント記録と一緒に読む必要があります。人間監督を件数だけで測ると、監督そのものがKPIを満たすための儀式になります。
政府によるアルゴリズム利用を論じたGreenは、人間監督を要求する政策が、それだけでは有害な判断を防げず、かえって安全だという誤った安心感や責任回避を生み得ると批判しています [8]。この議論の対象は政府アルゴリズムですが、「人が関与した」という事実だけで統制の実効性を推定できないという指摘は、生成AIの運用にも重要です。
STRIDE-AI × Human Factorsでは、どう見るのか
Human Factorsは、第6の攻撃レイヤーではありません。また、STRIDEに足す第7の脅威カテゴリーでもありません。
前回のRAGチャットボットで見たように、Human Factorsは、すべてのレイヤーを横断して、脅威が通る条件にも、止まる条件にもなります。
- Spoofing： AIが権威ある言葉で話すとき、誰の声かを問い直せるか
- Tampering： 出典が表示されていても、由来と変更履歴を確かめられるか
- Repudiation： 「人が承認した」だけでなく、その人が見た根拠と持っていた選択肢を残せるか
- Information Disclosure： 送信先、対象データ、公開範囲を実行前に理解できるか
- Denial of Service： 大量の承認要求によって、人の注意と判断時間が枯渇していないか
- Elevation of Privilege： AIが人の権限を使うとき、人は操作を狭め、拒否し、止め、戻せるか
技術的な脆弱性が存在しても、人が異常に気づき、疑い、止めれば、被害を防げることがあります。
逆に、技術的な対策がいくつもあっても、過信、疲労、権威への追従、曖昧な責任、拒否しにくい文化が重なれば、脅威は増幅されます。自然な言語で自信をもって応答するエージェントが、権威バイアスや擬人化を通じて利用者の独立した検証を弱めるリスクは、OWASPのHuman-Agent Trust Exploitationでも整理されています [9]。
だからHuman-in-the-loopは、アーキテクチャ図の人型アイコンでは評価できません。
その人が、現実の負荷、時間制約、インセンティブ、組織内の力関係の中で何を見て、何を言え、何を変えられるかを見る必要があります。
ループではなく、制御を設計する
「最終判断は人間です」という言葉は、責任の所在を明確にしているように聞こえます。
でも、その人に根拠が見えず、時間がなく、異議を言えず、停止できず、元に戻せないなら、責任だけを渡しているのかもしれません。
Human-in-the-loopは、制御目標ではありません。
Effective human control、実効的な人間の制御こそが、目標です。
そのために必要なのは、少なくとも五つです。
理解する。疑い、問い返す。拒否し、修正する。間に合う時点で介入する。そして、失敗後に回復する。
人を最後の砦と呼ぶ前に、その人が砦として機能できる条件を作れているか。
私は、そこから確認したいと思います。
参考文献
[1] 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.
[2] 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.
[3] 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.
[4] 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/. Accessed: Sep. 10, 2026.
[5] 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/. Accessed: Sep. 10, 2026.
[6] 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. Accessed: Sep. 10, 2026.
[7] 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.
[8] B. Green, "The flaws of policies requiring human oversight of government algorithms," Computer Law & Security Review, vol. 45, Art. no. 105681, Jul. 2022, doi: 10.1016/j.clsr.2022.105681.
[9] 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/. Accessed: Sep. 10, 2026.
[10] 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.
[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.
[12] 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.