AIエージェントの「承認連打」を防ぐ：形骸化しないHITL（Human-in-the-Loop）設計ガイド
- VIGILAIN（ヴィジレイン）編集部
- 7月13日
- 読了時間: 19分
更新日：20 時間前
AIエージェントが社内システムやB2B SaaSで本格導入される中、ガバナンスとセキュリティの観点から、人間の承認プロセスに組み込む「HITL（Human-in-the-Loop）設計」の重要性が高まっています。しかし、「すべてのAIの判断を人間が承認する」という素朴な設計は、承認疲労を引き起こし、結果的にボタンを連打するだけの形骸化した運用を生み出す可能性があります。この状態は、安全弁が機能していないばかりか、事故が起きた際の「責任論」を複雑化させるという極めて危険なリスクを孕んでいます。
本記事では、形骸化しないHITL設計の考え方、設計の原則、OWASP・経産省ガイドラインに基づくリスク分類、そして実務で使えるチェックリストまでを体系的に解説します。
INDEX
HITL（Human-in-the-Loop）設計とは？AIエージェント時代に不可欠な理由
HITL設計とは、AIの処理プロセスに「人間の判断」を組み込む仕組みです。自律的にタスクをこなすAIエージェントが普及する現代において、暴走を防ぎ安全性を担保する要として注目されています。
▶︎HITLの基本的な意味と役割
HITLとは、Human-in-the-Loopの略で、AIシステムの一連の処理フロー（Loop）において、特定の判断や実行の直前に「人間の介入（承認、修正、却下など）」を必須プロセスとして組み込む設計思想です。
AIエージェントにおけるHITLの主な役割は以下の3点に集約されます。
1：不可逆なアクションの防止
金融取引の執行、メール・チャットの外部送信、データの完全削除、重要設定の変更など、一度実行すると取り消しが不可能なアクションを水際で止める。
2：ハルシネーションの検知
AIがもっともらしい嘘（ハルシネーション）を出力した際、人間がファクトチェックを行い、誤った情報を外部へ流出させない。
3：悪意ある指示の無効化
外部から仕込まれた不正な指示（プロンプトインジェクション等）を人間が発見し、実行を拒否する。
ハルシネーションとは：ハルシネーションの原因とビジネスリスクとは？企業向け対策5選
▶︎HITL・HOTL・HOOTLの違い
AIシステムにおける人間の関与度合いは、HITL・HOTL・HOOTLの3つに分類されます。対象となる業務のリスクレベルに応じて、これらを使い分けるHITL設計が求められます。
方式 | 名称 | 人間の関与 | 特徴 | 適用例 |
HITL | Human-in-the-Loop | 高い（能動的承認・修正） | AIの各判断に対し人間がその都度確認・承認する。制御は強いが負荷は高い | 高リスク判断（決済、送金、特権操作） |
HOTL | Human-on-the-Loop | 中（監視と緊急介入） | AIが自律実行し、人間はダッシュボード等でリアルタイムに監視し、例外発生時のみ介入する。効率は高いが異常検知が鍵 | 中リスク処理（レポート生成、データ集計） |
HOOTL | Human-out-of-the-Loop | 低（ほぼ自動） | 人間は設計・運用監視のみで、実行プロセスには直接関与しない | 低リスク処理（要約、翻訳、画像タグ付け） |
用語解説：HOTLとHOOTL HOTL（Human-on-the-Loop）は「ループ（処理フロー）の上にいる人間」、つまりAIの処理フローには入らず、事後で監視するイメージです。HOOTL（Human-out-of-the-Loop）は「ループの外にいる人間」で、AIが完全に自律実行する方式を指します。（※HITLとHOTLは広く普及した用語ですが、HOOTLは説明的な派生語として使われることが多い概念です） リスクが低い処理ではHOOTL、リスクが高い処理ではHITLを選ぶのが基本方針です。 |
▶︎なぜ今、B2B SaaSや社内システムでHITLが求められるのか？
近年、指示を与えるだけで自律的に複数のツールを操作してタスクを完結させる「AIエージェント」がB2B SaaSや社内システムに組み込まれ始めています。 しかし、AIエージェントにシステムへの書き込み権限やメール送信権限を与えた状態で放置すると、誤作動によって機密データの消去や誤送信などの重大なインシデントを引き起こす恐れがあります。利便性とセキュリティを両立させるため、重要操作の前に人間がブレーキをかけられるHITL設計が不可欠となっているのです。
▶︎HITL設計を導入すべきシステムの特徴
すべてのAI機能にHITLが必要なわけではありませんが、以下の特徴に該当するシステムでは、HITL設計の導入を優先すべきです。
●高影響度
金銭的・法的影響がある処理（決済、契約、発注、稟議）
●低可逆性
一度実行すると取り消しが困難な操作（データ削除、外部送信、公開）
●高機密性
顧客データや個人情報、特権アクセスを扱う処理
●連鎖実行
外部システムやツールを連鎖的に操作するエージェント
陥りがちな罠「承認連打」が生み出す自動化バイアスとセキュリティリスク
HITL設計の最大の敵は、人間がAIを過信して確認を怠る「自動化バイアス」による承認連打です。認知負荷の限界や判断根拠の不足が重なることで、深刻なセキュリティリスクを招きます。
▶︎「承認連打（形骸化したHITL）」＝自動化バイアスの恐怖
承認連打とは、人間がAIの出力結果を吟味せず、機械的に連続して承認ボタンを押し続ける現象を指します。これは心理学で「自動化バイアス（Automation Bias）」と呼ばれる認知バイアスの典型例です。自動化バイアスとは、自動化システムの出力を過度に信頼し、矛盾する情報があってもそれを無視してしまう心理傾向を指します。
いくらシステム上にHITLを組み込んでも、人間が思考停止してしまえば、それは「形骸化したHITL」となり、重大なミスを素通りさせてしまいます。
この「形骸化したHITL」は、最初から人間を挟まない完全自動化（HOOTL）よりもはるかに危険です。なぜなら、システム上は「人間が目視で確認して承認した」というログが残るため、いざシステム暴走やデータ侵害が起きた際、すべての法的・業務的責任が「承認ボタンを押した人間」に押し付けられてしまうからです。
▶︎人為的ミスを誘発する「AIエージェント特有」のセキュリティ脅威
さらにセキュリティの観点において、承認の形骸化を突く恐ろしい攻撃手法が存在します。
それが、OWASP（Open Worldwide Application Security Project）等でも近年警告されている「Lies-in-the-Loop（LITL：承認ダイアログ偽装 / HITL Dialog Forging）」です。
（参考：OWASP「HITL Dialog Forging (aka Lies-in-the-Loop)」 ／ Checkmarx Zero「Turning AI Safeguards Into Weapons with HITL Dialog Forging」）
この攻撃は、「間接的プロンプトインジェクション（Indirect Prompt Injection）」などの攻撃を受けたAIエージェントが、攻撃者の指示に従い、巧妙に偽装された悪意のある操作をユーザーに提案することを指します。承認者が「いつものように」承認ボタンを押す習慣を持っている場合、攻撃者はこの習慣を利用して、データ漏えいや不正送金を合法的な承認プロセスの中で実行できてしまいます。これにより、組織のセキュリティ防壁は、正当な権限を持つ人間自らの手によって突破されることになります。
なぜ形骸化するのか？HITL設計における3つの根本原因
承認連打を引き起こし、HITL設計を形骸化させる根本原因は以下の3点に集約されます。
原因①：承認頻度が高すぎる「HITL設計」による認知負荷の限界
最も物理的な原因は、人間が1日に処理できる認知負荷を考慮せずに、すべてのタスクを画一的に承認対象にしていることです。 人間が集中力を持って真剣に意思決定できる回数には限界があります。数分おきに「承認してください」と割り込まれるワークフローは、人間の認知リソースを枯渇させ、思考停止に陥らせてしまいます。HITL設計では「承認すべきものを絞り込む」ことが本質的に重要です。
原因②：判断に必要なコンテキスト（文脈・根拠）の不足
承認ボタンだけでは人は判断できません。
承認者がAIの判断を正しく評価するには、判断の根拠・文脈・影響範囲を理解する必要があります。
判断根拠が示されない承認は、内容を評価できず、AIを信じるか信じないかの二択に追い込まれ、結果的に承認するしかなくなります。UIでの根拠表示やリンク、簡潔な要約が必要です。
原因③：AIに対する過度な信頼（自動化バイアス）
AIの精度が高いほど、人間は「AIの判断なら問題ないだろう」と信頼する傾向が強まります。これが自動化バイアスです。特に非技術者のオペレーターは、「AIは自分よりも賢い」「AIの計算プロセスは完璧である」と思い込みやすく、AIの出力を批判的に検証する姿勢が自然と失われていきます。システム側が「AIは間違えるものである」という前提をUI/UXで突きつけない限り、このバイアスは解消されません。また、この状態でプロンプトインジェクション等の攻撃が発生した場合、防御は機能しません。
【設計論】全件承認は逆効果？人間が介入すべきタスクの判断基準
全ての操作に人間の承認を求める「全件承認」は形骸化を招きます。
実効性のあるHITLを設計する第一歩は、「人間が確認すべきタスク」と「AIに完全に任せて良いタスク」を明確に分類し、人間が介入すべきタイミングを動的に判断するHITL設計が必要です。
▶︎経産省ガイドラインに学ぶ「人間の判断の介在」要否の評価基準
経済産業省・総務省が策定した「AI事業者ガイドライン（第1.2版）」では、AIの出力結果が公平性を欠いたり、危害を及ぼしたりすることを防ぐため、人間の判断を介在させることが推奨されています。
（参考：経済産業省・総務省「AI事業者ガイドライン（第1.2版）本編」）
ガイドラインにおける「人間の判断の介在」に関する主な要点は以下の通りです。
●公平性の確保と権利侵害の防止
AIの出力結果が公平性を欠くことがないよう、AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を介在させる利用を検討することが重要です。また、生成AIは精巧な生成物により誤解や偏見を助長する可能性や、他者の知的財産権を侵害する可能性があるため、利用に際して人間の判断を介在させる等の対策を講じることが求められます。
●自動化バイアスによる形骸化の防止
人間の判断を介在させる際は、人間がAIの出力（評価、判断、推奨など）を鵜呑みにして過度に依存してしまう「自動化バイアス」に左右されないような対策を講じるべきとされています。人間の介入が形式化・形骸化しない実効性のあるプロセスが重要です。
●リスクベースアプローチの実践
ガイドラインでは、AIの利用分野や形態に伴って生じうるリスクの大きさ（危害の大きさ及びその蓋然性）を把握した上で、その対策の程度をリスクの大きさに対応させる「リスクベースアプローチ」が推奨されています。
▶︎影響範囲と可逆性（取り消しの難しさ）によるリスク分類
業務タスクを「影響範囲（被害の大きさ）」と「可逆性（実行後に取り消せるか）」で分類し、介入レベルを決定するのが実務的です。
以下のマトリクスは、各タスクがどのHITL方式に適合するかを示したものです。リスク分類を明文化し、運用ルールに落とし込む際の参考として使用してください。
リスク分類 | 影響範囲 | 可逆性 | 推奨HITL方式 | 具体例 |
高リスク | 大（金銭・法的・機密） | 低（取り消し不可） | 全件承認（HITL） | 送金、契約締結、データ削除 |
中リスク | 中（業務影響あり） | 中（一部復旧可能） | 条件付き承認 | 発注、メール送信、設定変更 |
低リスク | 小（限定的） | 高（容易に取り消し可） | 事後監査（HOTL） | レポート生成、データ集計、要約 |
▶︎AIの確信度（Confidence Score）に基づく動的な介入設計
常に人間が介入するのではなく、AI自身が算出した「確信度（その推論がどれくらい自信があるかを示すスコア）」を出力し、それに応じて人間の介入要否を動的に切り替える手法が注目されています。
たとえば、AIが「95%以上の確信度であれば自動実行、80%〜95%は条件付き承認、80%未満は必ず人間の承認」というルールで運用することで、承認者の負荷を大幅に軽減しつつ、不確実な判断には確実に人間が介在できます。
注意点としては、プロンプトインジェクション等により、攻撃者がAIに「100%の確信度を出力せよ」と指示する可能性があるため、確信度の偽装を防ぐロジックも別途設計する必要があります。
【UI/UX】承認者が迷わない・連打しない「HITL画面」の設計4原則
承認連打を防ぐには、AIがなぜその判断に至ったかを可視化し、誤操作を防ぐUIが不可欠です。人間の直感的な判断を助ける設計が求められます。
原則1：AIの「思考プロセス・判断根拠」の可視化
承認者が判断を正しく評価するには、AIが「なぜその判断に至ったか」を理解する必要があります。可視化は全文ではなく「要点の要約＋詳細リンク」という階層構造が有効で、承認者は短時間で判断できます。また、必要なら深堀りすることが可能な設計にし、画面上に参照元ソースや予測の根拠を表示することで、盲目的な承認を防ぐことができます。
そのほか、影響範囲やAIの確信度などを提示することで、承認者は「ブラックボックスへの署名」ではなく、根拠に基づいた検証が可能になります。これらは、不正な出力や攻撃の痕跡を早期に発見する助けにもなります。
原則2：人間による「部分修正・再考指示」を可能にする介入設計
従来のHITL画面は「承認 or 却下」の二択に限定されることが多く、思考停止を招くおそれがあります。AIの提案が「9割正しいが1割直したい」という場合でも、全体承認か全体却下しか選べないと、承認者は「細かい修正は諦めて承認」を選びがちです。
これを防ぐため、HITL画面には以下の「4つの選択肢」を標準実装します。
●一括承認（Approve）
問題がないため、そのまま実行。
●部分修正して実行（Modify & Execute）
人間がその場で文面や数値をテキストボックス上で直接書き換え、修正後のデータで実行する。
●AIに再考指示（Reject with Feedback）
フィードバックコメント（例: 「B社ではなくC社で見積もりを取って」）を添えて却下し、AIエージェントにタスクを再実行させる。
●完全却下（Hard Reject）
タスク自体を完全に破棄する。
HITL設計においては、インタラクティブなUIが求められます。特に「部分修正して実行」の実装は、システム全体の業務効率を損なうことなく、高いセキュリティと正確性を担保する最強のパターンです。
原則3：承認・却下・修正アクションのログ化と監査トレイル
HITLのすべてのアクション（承認、却下、部分修正、再考指示）は、監査可能な形でログ化する必要があります。このログは、AIモデルの再学習（精度向上）に役立つだけでなく、セキュリティ事故発生時の証跡としても機能します。
ログには以下の内容を含めます。
●誰が・いつ・何を
承認者ID、承認日時、承認アクションの種別
●何を確認したか
AIの提案内容と判断根拠（確認画面に表示された内容）
●修正の有無
承認者が加えた修正内容（部分修正の場合）
●介入の根拠
AIの確信度と、介入ルール（全件/条件付き/事後監査）
この監査トレイルは、コンプライアンス要件を満たすだけでなく、形骸化を検知するためのデータ基盤にもなります。「承認者の平均承認時間が3秒以下に低下している」などのメトリクスから、形骸化の兆候を早期に発見できます。
原則4：誤操作を防ぐフールプルーフと、承認取り消し（フェールセーフ）の実装
UI上のガードレールとして、人間が誤って承認ボタンを押しても安全側が保たれる設計（Failsafe：フェールセーフ）や、誰が操作しても誤操作自体をさせない設計（Foolproof：フールプルーフ）が重要です。
たとえば、以下のような設計が該当します。
●2段階確認
高リスク操作では「本当に実行しますか？」の2段階確認ダイアログ
●操作の分離
重要な操作の実行ボタンを通常操作領域から物理的に離して配置
●承認取り消し（フェールセーフ）
実行後一定時間内（例：5分以内）であれば承認を取り消せる仕組み
●連打検知
「これまでに連続でN件承認しています」のような警告表示
UIは使いやすさと慎重さのバランスを取り、承認の簡便さが過信につながらないよう工夫します。
【実務担当者向け】OWASPに学ぶ、AIエージェントのリスクとHITLによる防衛策
国際的なセキュリティ基準OWASP（Open Worldwide Application Security Project）が公表した「LLM Top 10」および「Agentic AI Threats」において、プロンプトインジェクションは最重要リスクに位置づけられており、HITLはその主要な防御策として明記されています。
（参考：OWASP「Top 10 for Large Language Model Applications」／ OWASP Gen AI Security Project「Agentic AI Threats and Mitigations」）
▶︎プロンプトインジェクションの主要な防御策としてのHITL
OWASPが2023年に公表した「OWASP Top 10 for LLM Applications」では、第1位のリスクとして「LLM01: Prompt Injection（プロンプトインジェクション）」が挙げられています。これは、2023年の初版から2026年7月現在の最新版（Version 2025）まで、 一貫して第1位を維持しています。
プロンプトインジェクションとは：プロンプトインジェクションの脅威と対策法｜AIを騙す悪意ある攻撃の具体例と防御の基本
また、プロンプトインジェクションの防御策の一つとして、「Human-in-the-Loop (HITL) Controls（人間の監視と介入）」が明記されています。
（参考：OWASP Gen AI Security Project「LLM01:2025 Prompt Injection」／「LLM06:2025 Excessive Agency」）
HITLが最も有効に機能するのは、AIエージェントが「外部システムへのデータ送信」「特権アクセスの使用」「金銭的取引の実行」などの高リスク操作を行おうとする場面です。これらの場面でHITLが適切に設計されていれば、プロンプトインジェクションによる攻撃を承認段階で阻止できます。
▶︎エージェント特有の防御策（Agent-Specific Defenses）とHITLの組み合わせ
OWASPではHITLだけでなく、AIエージェント特有の防御策（Agent-Specific Defenses）との多層防御を推奨しています。 具体的には、AIエージェントがアクセスできるツールやAPIを「最小権限の原則」に基づいて制限することや、ユーザーの権限レベルとセッションコンテキストを検証する仕組みの設計等が挙げられます。
HITLを「人間による監視と承認（Human Oversight and Approval）」として、最後の防衛ラインとしつつ、エージェントの行動監視・異常検知・重要操作の承認という3つのレイヤーで機能させることで強固なセキュリティ基盤が完成します。
実務で使える「形骸化しないHITL設計」導入チェックリスト
以下のチェックリストは、導入前に必ず確認すべき項目を体系的に整理したものです。項目が満たされているか確認しましょう。
●リスク分類と介入設計
[ ] 全アクションを「影響範囲」と「可逆性」に基づき3段階でリスク分類したか？
[ ] AIの確信度や例外ルール（新規ドメイン等）に応じた動的介入を設計したか？
[ ] 条件付き承認の閾値や介入基準をユースケースごとに最適化したか？
[ ] 1日の承認上限設定など、承認者の認知負荷を管理する対策はあるか？
●UI/UX設計
[ ] AIの思考プロセスや参照データを1画面に集約し、即座に判断できるUIか？
[ ] 単なる2択ではなく「部分修正」や「再考指示」を行える柔軟な設計になっているか？
[ ] 連打防止や2段階確認など、誤操作を防ぐフールプルーフ設計が施されているか？
[ ] 承認・実行の直後に処理を取り消せるフェールセーフ設計による承認取り消し（Undo）機能はあるか？
●セキュリティ・安全性
[ ] LLM自身に実行権限を持たせず、人間の承認後にバックエンドが実行する設計か？
[ ] プロンプトインジェクション等の攻撃を想定した防御や脆弱性診断を行ったか？
●監査と形骸化監視
[ ] 「誰が・いつ・どう承認/修正したか」の証跡（監査ログ）を保存しているか？
[ ] 承認時間や連続承認率を監視し、確認なしの「連打」を検知してアラートを出せるか？
[ ] 自動送信されたタスクも含め、定期的なサンプリング監査（スポットチェック）を行うか？
HITL設計に関するよくある質問（FAQ）
Q. HITL設計とは何ですか？
A. HITL（Human-in-the-Loop）設計とは、AIシステムの処理フローの中に人間の判断・承認を組み込む設計手法です。AIが提案や自動処理を行い、重要な局面で人間が確認・承認・修正を行うことで、AIの効率性と人間の判断力を組み合わせます。AIエージェントが自律的に行動するシステムでは、誤動作や悪意のある操作を防ぐ最後の防波堤として不可欠です。
Q. HITL設計を導入すると業務の完全自動化ができず、効率が落ちませんか？
A. 全件承認（すべてのタスクに介入）を行うと効率は落ちます。しかし、タスクの「影響範囲」や「AIの確信度」に基づいて人間の介入を動的に切り替える（条件付き承認やHOTLの併用）ことで、安全性と業務効率の両立が可能です。
Q. HITLは運用コストが高くなるのでは？
A. 初期導入コストは増えますが、誤判断やインシデントによるコストを下げることでトータルでは有益です。
Q. 自社のシステムには、HITL、HOTL、HOOTLのうちどれを実装すべきですか？
A. 業務の「可逆性（取り消しやすさ）」で判断します。決済や機密データの送信など、実行後に取り返しがつかないタスクには「HITL（毎回承認）」を。レコメンド表示など取り消しや修正が容易なタスクには「HOOTL（完全自動化）」や「HOTL（監視型）」を実装するのが定石です。
Q. すべてのAI判断にHITLは必要ですか？
A. いいえ、すべてのAI判断にHITLは必要ありません。影響範囲と可逆性でタスクをリスク分類し、高リスク（送金、契約、データ削除）には全件承認、中リスク（発注、メール送信）には条件付き承認、低リスク（レポート生成、要約）には事後監査を適用するハイブリッド運用が推奨されます。
Q. HITLが形骸化する原因は何ですか？
A. 主な原因は3つあります。1つ目は承認頻度が高すぎる設計による認知負荷の限界、2つ目は判断に必要なコンテキスト（判断根拠）の不足、3つ目はAIに対する過度な信頼（自動化バイアス）です。全件承認を前提とした設計は認知負荷を極大化し、承認を形式的な作業に変えてしまうため逆効果になります。
Q. プロンプトインジェクション対策としてHITLは有効ですか？
A. はい、有効です。OWASPのLLM Top 10ではプロンプトインジェクションが第1位のリスクに挙げられており、HITLはその主要な防御策として明記されています。プロンプトインジェクションでAIが悪意のある操作を提案した場合、適切に設計されたHITLプロセスがあれば承認段階で攻撃を阻止できます。ただし、形骸化したHITLは逆に攻撃の通り道になるため、実効性のある設計が前提です。
Q. HITL設計で参照すべきガイドラインは何ですか？
A. 国内では経済産業省・総務省の「AI事業者ガイドライン」、国際ではNIST AI RMF（米国国立標準技術研究所）とOWASP Top 10 for LLM Applicationsが主要な参照先です。これらはAIシステムにおける人間の判断の介在、リスク分類、セキュリティ対策のベストプラクティスを体系化しており、HITL設計の根拠として活用できます。（参考：NIST「AI Risk Management Framework（AI RMF）」／ OWASP「Top 10 for Large Language Model Applications」）
Q. Confidence Score（確信度）をHITL設計に活用するには？
A. AIが自身の判断に対する確信度を出力し、それに応じて介入要否を動的に切り替える手法が有効です。たとえば「95%以上は自動実行、80%〜95%は条件付き承認、80%未満は必ず人間の承認」というルールを設定することで、承認者の負荷を軽減しつつ不確実な判断に確実に人間が介在できます。ただし、確信度の偽装を防ぐ別途ロジックも必要です。
まとめ
安全なAI社会実装は「形骸化しないHITL設計」から始まる
AIが高度に自律化するエージェント時代において、「人間の判断」はAIの成長を阻害するものではなく、AIを安全に社会に実装するための「強力なブレーキでありハンドル」です。承認連打という自動化バイアスの罠を避け、実効性のあるHITL設計を組み込むことで、初めてセキュアで信頼されるB2B SaaSや社内システムが実現します。
全件承認に頼らず、リスク分類と動的介入で承認負荷を適正化し、UI/UXで承認者の判断を支援し、監査と形骸化監視で継続的に改善する。この3層の設計こそが、形骸化しないHITL設計の本質です。
本ガイドのチェックリストと設計原則を活用し、貴社のAIエージェントシステムを、安全で実効性のある次世代のガバナンスモデルへと進化させてください。
参考・出典一覧
HITL Dialog Forging (aka Lies-in-the-Loop)
https://owasp.org/www-community/attacks/Lies_in_the_Loop
Turning AI Safeguards Into Weapons with HITL Dialog Forging ／ Checkmarx Zero
https://checkmarx.com/zero-post/turning-ai-safeguards-into-weapons-with-hitl-dialog-forging/
AI事業者ガイドライン（第1.2版）本編 PDF ／ 経済産業省
https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_1.pdf
OWASP Top 10 for LLM Applications（プロジェクトページ）
https://owasp.org/www-project-top-10-for-large-language-model-applications/
Agentic AI Threats and Mitigations - OWASP Gen AI Security Project
https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
LLM01:2025 Prompt Injection - OWASP Gen AI Security Project
https://genai.owasp.org/llmrisk/llm01-prompt-injection/
LLM06:2025 Excessive Agency - OWASP Gen AI Security Project
https://genai.owasp.org/llmrisk/llm06-sensitive-information-disclosure/
NIST AI RMF（米国国立標準技術研究所 AIリスクマネジメントフレームワーク）
