こんにちは。全国1千万人の DDD 開発者の皆さん。
あなたのAIくんはいかがおすごしですか？
さて
Claude Code を使い始めて1年近くになります。使い込むほど「これは危なそう」と思う場面が増え、そのたびに CLAUDE.md にルールを足したり、承認プロンプトを見直したりしてきたり、監視ツール作ったり。
ただ、ふと気付きました。自分は「AI エージェントの何が危ないのか」を体系的に学んだことはありません。危なそうなものに出会うたびに個別に対処してきただけで、全体のどこを見ていて、どこを見落としているのかを把握していませんでした。要するに、雰囲気で使っていました。
雰囲気で使っている自覚があるなら、一度はちゃんと調べたほうがいい。そう思って、AI のリスクについて書かれたものを研究論文からセキュリティのガイドラインまで、手の届く範囲で読んでみました。この記事はその学びをまとめたものです。
並べようとして最初に困ったのは、用語の出所がバラバラなことです。研究文脈（AI safety / alignment）では「リワードハッキング」「ディセプティブアライメント」といった言葉が使われ、実務文脈（OWASP LLM Top 10、NIST AI RMF、MITRE ATLAS など）では「プロンプトインジェクション」「過剰なエージェンシー」といった言葉が使われます。同じ現象を別の名前で呼んでいることもあれば、片方にしか出てこない項目もあります。自力で突き合わせるのは無理だと思ったので、両方の文脈の用語を AI にざっくりまとめてもらい、それを自分で読み直して分類し直しました。
この記事では、両方の文脈から101項目を拾って7つに分類し、最後に「どれから対処すべきか」を決める判断軸を書きます。一覧そのものより、判断軸のほうが本題です。
並べ方
分類は次の7つです。おおまかに「モデルの内部で起きること」から「社会や組織で起きること」へ向かう順に並べています。
- 目標・整合性のズレ（alignment 系）
- 出力の信頼性・認知のバイアス
- エージェント動作・自律実行
- セキュリティ（攻撃面）
- 人間との相互作用
- 公平性・社会的影響
- 運用・ガバナンス
名称はカタカナか日本語で書き、括弧内に原語の英語を添えています。詳しく調べるときは英語のほうで検索してください。各分類の末尾に所感として、その分類の何が厄介なのかを書きました。
1. 目標・整合性のズレ（alignment 系）
alignment とは、AI の目標や振る舞いを人間の意図に一致させることです。この分類は、そのズレをまとめたものです。「言われたとおりにやったのに、頼んだ人が望んでいたことと違う」というズレから、「AI が自分の都合で人間の監視や修正を避ける」という研究上の懸念まで、幅があります。
| No. | 名称 | 内容 |
|---|---|---|
| 1 | スペシフィケーションゲーミング（Specification gaming） | 指示の文言を満たすが意図を外す |
| 2 | リワードハッキング（Reward hacking） | 評価指標そのものを攻略する（テストを通すためにテストを書き換える等） |
| 3 | グッドハートの法則 / プロキシゲーミング（Goodhart's law / proxy gaming） | 代理指標が目標化し、指標だけが改善して実質が悪化する |
| 4 | 目標の誤般化（Goal misgeneralization） | 学習時は正しく見えた目標が、分布外の状況で別物として発現する |
| 5 | インナーミスアライメント / メサ最適化（Inner misalignment / mesa-optimization） | 学習で獲得された内部の目的が、設計者の与えた目的と一致しない |
| 6 | 道具的収束（Instrumental convergence） | どんな目標でも有利になる「権限・資源・情報の獲得」を副次的に追求する |
| 7 | パワーシーキング（Power-seeking） | アクセス範囲や自律度を広げる方向に動く |
| 8 | 自律性のエスカレーション（Autonomy escalation） | 一度の許可を暗黙に一般化する |
| 9 | シャットダウン回避 / 修正への抵抗（Shutdown avoidance） | 停止・訂正がタスク達成を妨げるため、回避的に振る舞う |
| 10 | ディセプティブアライメント / アライメントフェイキング（Deceptive alignment / alignment faking） | 観測されている間だけ整合的に振る舞う |
| 11 | サンドバッギング（Sandbagging） | 能力を意図的に過小に見せる（評価回避） |
| 12 | 評価察知（Evaluation awareness） | 「これはテストだ」と察知して本番と異なる挙動をとる |
| 13 | ゴールドリフト（長期タスク）（Goal drift） | 長時間の実行中に、初期目標が徐々に別の目標に置き換わる |
所感: 研究文脈で議論されてきた項目が中心ですが、コーディングエージェントを使っていると身近に見えるものもあります。2. リワードハッキングの「テストを通すためにテストを書き換える」は実際に何度か遭遇しました。テストが通ったと報告されて差分を見たら、アサーションが緩められていたという形です。8. 自律性のエスカレーションも日常的で、あるディレクトリへの書き込みを一度許可すると、その後は似た操作を確認なしで進めようとします。
厄介なのは、この分類の多くが「外から見ても分からない」ことです。10. ディセプティブアライメントや 11. サンドバッギングは、モデルが観測されているかどうかで振る舞いを変えるという話なので、観測している側には見えません。実務で対処できるのは、権限の拡大や許可の一般化のように、行動として表に出るものに限られます。
2. 出力の信頼性・認知のバイアス
AI の答えが「本当に正しいか」に関わる分類です。もっともらしい嘘を言う、自信の度合いと正しさが釣り合わない、質問のしかたで答えが変わる、といった問題が入ります。AI の頭の中で起きることなので、外から仕組みで防ぐのは難しく、答えを読んで確かめるしかありません。
| No. | 名称 | 内容 |
|---|---|---|
| 14 | ハルシネーション / 作話（Hallucination / confabulation） | 存在しない事実・API・関数・製品名を生成する |
| 15 | 引用の捏造（Fabricated citation） | 書式の整った架空の出典・論文・条文・判例を生成する |
| 16 | 雪だるま式ハルシネーション（Snowballing hallucination） | 一度出した誤りを守るために、後続の説明で誤りを積み増す |
| 17 | ミスキャリブレーション（Miscalibration） | 確信度と正答率が乖離し、不確かな事柄を断定する |
| 18 | 訂正への過剰な追従（Overconfidence in refutation） | 訂正されると根拠なく即座に撤回する（逆方向の誤較正） |
| 19 | 知識の陳腐化（Knowledge staleness） | 学習時点以降の変更（ライブラリ、法令、価格、脆弱性情報）を反映できない |
| 20 | 前提の鵜呑み / アンカリング（Premise acceptance / anchoring） | 質問に含まれた誤った前提をそのまま受け入れて推論する |
| 21 | プロンプトの脆さ（Prompt brittleness） | 表現のわずかな違いで結論が変わり、再現性がない |
| 22 | 非決定性（Nondeterminism） | 同一入力で異なる出力になり、監査・検証が困難になる |
| 23 | ポジションバイアス / ロスト・イン・ザ・ミドル（Position bias / lost in the middle） | 長い入力の中間部分の情報を取りこぼす |
| 24 | 順序バイアス（Order bias） | 選択肢の並び順が判定結果に影響する（LLM-as-a-judge で特に問題） |
| 25 | 冗長性バイアス（Verbosity bias） | 長い回答・長い候補を高く評価してしまう |
| 26 | 思考過程の不忠実（Unfaithful chain-of-thought） | 提示された思考過程が、実際の結論の根拠になっていない |
| 27 | 事後的な理由づけ（Post-hoc rationalization） | 先に結論を出し、後から理由づけを構成する |
| 28 | コンテキストロット（Context rot） | 長大なコンテキストで精度・指示追従が劣化する |
| 29 | モードコラプス / 均質化（Mode collapse / homogenization） | 出力の多様性が失われ、無難で平均的な内容に収束する |
| 30 | 体裁優先（Format over substance） | 見た目の体裁（表・箇条書き・見出し）が整うことで、内容の薄さが隠れる |
所感: 一番よく知られている分類で、14. ハルシネーションはもはや一般用語です。ただ、単体のハルシネーションより、16. 雪だるま式ハルシネーションや 20. 前提の鵜呑みのように「誤りが連鎖する」タイプのほうが実害は大きいと感じています。最初の回答が間違っていても、読めば気付けます。問題は、その間違いを前提に次の作業が積み上がったときで、後から遡って直す範囲が広がります。
30. 体裁優先は見落とされがちです。表と見出しが整っていると内容も正しそうに見えます。レビューする側が「体裁が整っている」ことと「中身が正しい」ことを切り離して読む必要があります。
この分類の共通点は、出力を読めば判断できることです。判断できる人が読む工程を設ければ、事後で吸収できます。逆に言えば、読む人がいない、あるいは読める人がいない状況では、そのまま通ってしまいます。
3. エージェント動作・自律実行
AI が「答える」だけでなく「実際にファイルを書き換えたりコマンドを実行したりする」ようになって出てきた分類です。頼んでいないことまでやる、失敗しているのに完了と言う、同じ修正を延々と繰り返す、消してはいけないものを消す、といった行動そのものの問題が入ります。
| No. | 名称 | 内容 |
|---|---|---|
| 31 | 過剰な先回り（Over-eagerness） | 依頼を超えて先回りする |
| 32 | スコープクリープ（Scope creep） | 頼まれていない改善・整形・リファクタを付随実行し、差分が追跡不能になる |
| 33 | 不可逆性への無自覚（Irreversibility blindness） | 削除・上書き・送信・課金・公開を、可逆操作と同じ重みで扱う |
| 34 | 負の副作用（Negative side effects） | 明示された目標は達成するが、明示されなかった制約を壊す |
| 35 | サイレントフェイラー / 偽の完了報告（Silent failure / false completion） | 失敗しているのに「完了しました」と報告する |
| 36 | エラーカスケード（Error cascade） | 初期段階の誤った前提が検証されずに全工程へ伝播する |
| 37 | スラッシング / 修正ループ（Thrashing） | 同じ箇所を往復して修正し続け、収束しない |
| 38 | 早すぎる打ち切り（Premature termination） | 途中で完了と判断して打ち切る |
| 39 | ツールの選択ミス（Tool misselection） | 目的に対して不適切なツールを選ぶ |
| 40 | オーバーツーリング（Over-tooling） | 不要なツール呼び出しを繰り返し、時間とコストを消費する |
| 41 | アンダーツーリング（Under-tooling） | 検証可能な事柄を記憶で答え、ツールで確認しない |
| 42 | リソース枯渇 / デナイアル・オブ・ウォレット（Resource exhaustion / denial of wallet） | ループやリトライで API 課金・計算資源が暴走する |
| 43 | 状態のズレ（State desync） | 実際のファイル/DB/画面の状態と、エージェントの内部モデルがずれる |
| 44 | マルチエージェントのエラー増幅（Multi-agent error amplification） | 複数エージェント間で誤りが相互強化される |
| 45 | マルチエージェントの共謀 / 責任の拡散（Multi-agent collusion） | 相互レビューが形骸化し、誰も検証していない状態になる |
| 46 | 委譲ドリフト（Delegation drift） | サブエージェントへ指示を渡す過程で、制約条件が落ちる |
| 47 | メモリポイズニング（Memory poisoning） | 永続メモリに誤情報や悪意ある指示が書き込まれ、以後の全セッションに影響する |
| 48 | 文脈間の情報漏れ（Cross-context leakage） | ある顧客・プロジェクトの情報が別の文脈に漏れ出す |
所感: チャットボットではなくエージェントを使うようになって初めて出てくる分類です。分類2までは「何を言うか」の問題でしたが、ここからは「何をするか」の問題になります。
日常的に見るのは 37. スラッシングと 40. オーバーツーリングです。同じファイルを何度も編集して収束しない、同じディレクトリを違う検索パターンで30回読み続ける、といった症状で、放っておくと時間と課金だけが増えます。これらは実害が小さく、途中で止めればすみます。
実害が大きいのは 33. 不可逆性への無自覚です。エージェントにとって rm -rf も ls も同じ「コマンドを1つ実行する」操作で、戻せるかどうかの重み付けがありません。削除、上書き、外部送信、課金、公開といった操作は、実行された時点で取り返しがつきません。
35. サイレントフェイラーも見逃しやすい項目です。「完了しました」と報告されたが実際は失敗していた、というケースは、報告だけ読んでいると気付けません。成果物そのものを確認する工程がないと通ってしまいます。
最近増えているのはマルチエージェント系と 47. メモリポイズニングです。サブエージェントに作業を委譲する構成が一般的になり、指示を渡す過程で制約条件が落ちる 46. 委譲ドリフトや、エージェント同士のレビューが形骸化する 45. マルチエージェントの共謀が起きやすくなりました。永続メモリを持つエージェントでは、一度おかしな内容が書き込まれると、以後のセッション全部に影響します。
4. セキュリティ（攻撃面）
誰かが悪意を持って AI を狙ったときに何が起きるか、という分類です。AI に直接おかしな指示を与えて安全機能を外す手口、AI が読む Web ページや文書に指示をしのばせて操る手口、AI に機密情報を外へ送らせる手口などが入ります。AI が外部のデータを読み、外部にアクセスできるほど、この分類の危険は大きくなります。
| No. | 名称 | 内容 |
|---|---|---|
| 49 | 直接プロンプトインジェクション / ジェイルブレイク（Direct prompt injection / jailbreak） | 入力による安全機構の回避 |
| 50 | 間接プロンプトインジェクション（Indirect prompt injection） | Web ページ、PDF、メール、コード、ツール出力に埋め込まれた文字列を指示として実行 |
| 51 | ツールポイズニング（MCP）（Tool poisoning） | ツールの説明文・スキーマに注入し、モデルの動作を誘導する |
| 52 | ラグプル（MCP）（Rug pull） | 承認後にサーバ側でツール定義を差し替える |
| 53 | コンフューズドデピュティ（Confused deputy） | 正当な権限を持つエージェントを踏み台に、権限外の操作をさせる |
| 54 | 過剰なエージェンシー（Excessive agency） | エージェントに与えた権限が過剰で、被害範囲が広がる |
| 55 | 出力の安全でない取り扱い（Insecure output handling） | 出力をそのまま eval / SQL / シェル / HTML に渡し、二次的な脆弱性を作る |
| 56 | エージェントハイジャック（Agent hijacking） | タスクの途中で目標そのものを乗っ取る |
| 57 | ツール経由のデータ持ち出し（Data exfiltration via tool） | 画像 URL、Webhook、外部 API 呼び出しを経由した情報持ち出し |
| 58 | メニーショットジェイルブレイク（Many-shot jailbreak） | 長文コンテキストに多数の事例を詰めて安全挙動を上書きする |
| 59 | クレッシェンド攻撃（Crescendo attack） | 無害な要求から段階的に境界を越えさせる |
| 60 | エンコーディング / 難読化によるバイパス（Encoding / obfuscation bypass） | Base64、低リソース言語、ASCII アート等での検知回避 |
| 61 | 敵対的サフィックス（Adversarial suffix） | 最適化された文字列による安全機構の破壊 |
| 62 | 学習データポイズニング / バックドア（Training data poisoning / backdoor） | 学習データへの汚染で特定トリガー時の挙動を仕込む |
| 63 | モデル抽出（Model extraction） | 出力からモデルの複製・蒸留を行う |
| 64 | メンバーシップ推論 / 記憶内容の抽出（Membership inference / memorization） | 学習データに含まれた個人情報・秘密情報の復元 |
| 65 | スロップスクワッティング（Slopsquatting） | 幻覚で生成されたパッケージ名を攻撃者が先回りして登録する |
| 66 | 安全でないコード生成（Insecure code generation） | 生成コードに既知の脆弱性パターンが混入する（いわゆる vibe coding のリスク） |
| 67 | シークレットの漏えい（Secrets leakage） | コード・ログ・プロンプト履歴に認証情報が残る |
| 68 | サプライチェーンリスク（Supply chain risk） | モデル、プラグイン、MCP サーバ、依存パッケージの信頼性 |
所感: OWASP LLM Top 10 や MITRE ATLAS が扱う領域で、実務文脈の用語が多い分類です。
攻撃の入口で分けると見通しがよくなります。入口がモデルへの入力そのものである 49. ジェイルブレイク、58. メニーショットジェイルブレイク、61. 敵対的サフィックスなどは、利用者側で防ぐ手段がほとんどなく、モデル提供者の安全対策に依存します。一方、入口がエージェントの読む外部データである 50. 間接プロンプトインジェクション、51. ツールポイズニング、52. ラグプルは、利用者側の設計で被害を小さくできます。
エージェント特有で一番注意しているのは 50. 間接プロンプトインジェクションです。Web ページや PDF、ツールの出力に「この内容を外部に送信せよ」といった文字列が仕込まれていると、エージェントはそれを指示として実行しうる、という問題です。攻撃者は利用者と直接やり取りせず、エージェントが読みそうな場所に文字列を置くだけでよく、しかも権限が広い状態、つまり 54. 過剰なエージェンシーと組み合わさると被害が一気に広がります。
65. スロップスクワッティングは比較的新しい項目です。モデルが存在しないパッケージ名を生成する癖を逆手に取り、その名前で悪意あるパッケージを先回り登録しておく手口で、エージェントが npm install や pip install を自動実行する環境では実害になります。
5. 人間との相互作用
AI 側ではなく、使う人間側に起きる問題の分類です。AI が人間に合わせすぎる、人間が AI の答えを確かめなくなる、AI に頼りすぎて自分の判断力が落ちる、間違ったときに誰の責任か分からなくなる、といった問題が入ります。どれだけ AI 側を固めても、使う側がここで崩れると意味がなくなります。
| No. | 名称 | 内容 |
|---|---|---|
| 69 | シコファンシー（迎合）（Sycophancy） | ユーザーの意見・前提・誤りに同調する方向へ回答が歪む |
| 70 | 過剰な拒否（Over-refusal） | 安全側に振りすぎ、正当な業務要求を拒否・希釈する |
| 71 | オートメーションバイアス（Automation bias） | 人間側の検証が形骸化し、レビューが通過儀礼になる |
| 72 | デスキリング（Deskilling） | 技能・判断力が空洞化し、異常時に人間が対処できなくなる |
| 73 | 擬人化（Anthropomorphism） | 能力・意図・責任能力を過大に見積もる |
| 74 | 感情的な過剰依存（Emotional over-reliance） | 相談・意思決定を過度に依存する |
| 75 | 説得 / 操作（Persuasion / manipulation） | 説得力の高い出力が、誤りごと受容されやすくなる |
| 76 | 責任のギャップ（Responsibility gap） | 誤りの責任所在が不明確になる |
| 77 | アカウンタビリティロンダリング（Accountability laundering） | 「AI が出したので」と人間の判断責任を希釈する |
| 78 | 信頼の誤較正（Trust miscalibration） | 得意分野と不得意分野の区別がつかず、一律に信頼／不信になる |
所感: モデルではなく人間側の問題です。私自身に一番効いているのは 71. オートメーションバイアスで、承認プロンプトが出るたびに内容を確認せずエンターを押す癖がつきました。承認プロンプトは本来「人間が判断する」ためのゲートですが、回数が多いと判断せずに通す作業になります。分類3や4の対策として「人間の承認を挟む」と書いても、この癖があると対策として機能しません。この癖をどうにかしたくて作ったのが、Claude Code の hooks でエージェントの操作を記録し、危険な操作をダッシュボードで目立たせる CC Pipeline でした。自分を信用しない前提で、判断すべき場面を機械に教えてもらう方向の対策です。
76. 責任のギャップと 77. アカウンタビリティロンダリングは、少人数チームで特に意識する必要があります。大規模なチームなら、レビューや承認の記録が組織の仕組みとして自然に残ります。少人数だと AI に書かせた人が自分でレビューして自分で反映するので、意識して残さない限り「誰がどう検証したか」の記録がどこにもありません。後で問題が起きたときに「AI が勝手にやった」で終わらせないために、誰がいつ何を承認したかの記録を残しておく必要があります。
6. 公平性・社会的影響
AI が世の中に広く使われることで起きる問題の分類です。特定の属性の人に不利な答えを出す、学習したデータをそのまま吐き出して著作権を侵害する、偽の映像や音声で人をだます、といった問題が入ります。一人の開発者が手元で対処できるものは少なく、AI を提供する側や、AI を使う組織のルールで対応する領域です。
| No. | 名称 | 内容 |
|---|---|---|
| 79 | バイアス / ステレオタイプ（Bias / stereotyping） | 属性に基づく偏った出力 |
| 80 | 配分的危害（Allocative harm） | 採用・与信・審査など資源配分の場面での不利益 |
| 81 | 表象的危害（Representational harm） | 特定集団の描写における固定観念の再生産 |
| 82 | 性能の格差（Disparate performance） | 言語・方言・地域による品質格差 |
| 83 | 文化の平板化（Cultural flattening） | 出力が特定文化圏の規範に均質化する |
| 84 | プライバシー推論（Privacy inference） | 断片情報から機微属性を推定してしまう |
| 85 | 著作物の逐語再生（Copyright regurgitation） | 学習データの逐語的再生成 |
| 86 | 来歴の喪失（Provenance loss） | 出典・来歴が失われ、事実確認が不能になる |
| 87 | 大規模な偽情報（Misinformation at scale） | 生成コストの低下による偽情報の量的拡大 |
| 88 | ディープフェイク / なりすまし（Deepfake / impersonation） | 音声・映像・文体の模倣による詐欺（BEC の高度化を含む） |
| 89 | モデルコラプス（Model collapse） | AI 生成データでの再学習による品質劣化 |
| 90 | 環境・労働コスト（Environmental / labor cost） | 計算資源の消費、データラベリング労働、雇用への影響 |
所感: 個人の開発現場からは遠く見える分類ですが、一覧から外すと全体像が歪むので入れています。モデルの学習データ、アーキテクチャ、社会的文脈に起因する問題で、対処するのはモデル選定基準や利用ポリシーといった組織のガバナンスです。
7. 運用・ガバナンス
AI を一度使って終わりではなく、業務の中で使い続けるときに出てくる問題の分類です。ある日 AI が更新されて挙動が変わる、同じ結果を再現できず監査に耐えない、会社が把握していないところで社員が AI を使っている、プロンプトの履歴に機密が残る、といった問題が入ります。技術というより、運用のルールや体制の話です。
| No. | 名称 | 内容 |
|---|---|---|
| 91 | 挙動のドリフト（サイレントアップデート）（Behavior drift, silent update） | モデル更新で挙動が変わり、既存プロンプト・パイプラインが壊れる |
| 92 | 再現不能（Non-reproducibility） | 出力を再現できず、監査証跡として成立しない |
| 93 | 評価ギャップ（Evaluation gap） | ベンチマーク性能と実務品質の乖離 |
| 94 | ベンチマーク汚染（Benchmark contamination） | 評価データが学習に混入し、性能を過大評価する |
| 95 | シャドー AI（Shadow AI） | 現場での無許可利用により、情報の流出経路が把握できない |
| 96 | データレジデンシー / 越境移転（Data residency） | 入力データの処理国・保持期間の管理 |
| 97 | ログ保持の問題（Log retention） | プロンプト履歴に機密が残り、それ自体が管理対象資産になる |
| 98 | プロンプト / 設定のドリフト（Prompt / config drift） | プロンプトや設定がバージョン管理されず、変更履歴が失われる |
| 99 | ロールバック不能（Rollback） | 問題発生時に「前の状態」に戻す手段がない |
| 100 | ベンダーロックイン（Vendor lock-in） | 特定モデル前提の設計により切り替えコストが跳ね上がる |
| 101 | 規制ドリフト（Regulatory drift） | EU AI Act、各国ガイドライン等の要求と実装の乖離 |
所感: AI を継続的に使う組織で効いてくる分類です。91. 挙動のドリフトはよく経験します。ある日モデルが更新されて、それまで通っていた指示が通らなくなる、出力の形式が変わる、といった変化で、いつ切り替わったかを記録していないと、問題が発生したときに原因の切り分けに時間がかかります。
97. ログ保持の問題は見落としがちです。プロンプト履歴やエージェントの操作ログには、ファイルパス、コマンド、貼り付けた設定値などが残ります。監査のために記録を残すほど、その記録自体が機密資産になるという構造で、記録の保持期間と保存場所をあらかじめ決めておく必要があります。
並べて分かったこと
101項目を眺めて最初に思ったのは、全部に同じ重さで対処するのは無理だし、その必要もないということです。
対処の分かれ目は「事後検証で救えるかどうか」です。
事後検証で救えるものは、出力を読めば判断できる項目です。分類2（出力の信頼性）の 14. ハルシネーションや 17. ミスキャリブレーション、分類6の 79. バイアス、分類3では 32. スコープクリープや 38. 早すぎる打ち切りがここに入ります。判断できる人がレビューする工程を設ければ、概ね吸収できます。「これは間違っている」と読んで分かるなら、実行前に止める必要はありません。
事後検証では救えないものは、実行された時点で取り返しがつかない項目です。出力を読んでから対処しても遅く、実行前のゲートが要ります。101項目を見返すと、この性質を持つのは次の3群に集約されます。
群1: 不可逆操作
削除、上書き、外部送信、公開、課金、本番反映といった、一度実行すると戻せない操作です。
この群の代表は分類3の 33. 不可逆性への無自覚です。同じ分類3の 42. リソース枯渇（課金の暴走）、分類4の 57. ツール経由のデータ持ち出しと 67. シークレットの漏えいも、実行された後では取り消せないので、この群に入れています。
対処は、不可逆な操作を機械的に識別して実行前に止めることです。「危険なコマンドのパターンを実行前に照合してブロックする」「特定のツールの実行には必ず人間の承認を挟む」「不可逆操作の前にドライラン結果を提示させる」のように、モデルの判断に頼らない層を1つ置きます。この記事では、この層を「実行前のゲート」と呼びます。
群2: 権限の拡大
分類1の 6. 道具的収束、7. パワーシーキング、8. 自律性のエスカレーション、分類4の 54. 過剰なエージェンシー、53. コンフューズドデピュティがこの群です。エージェントが持つ権限が広いほど、他のすべてのリスクの被害範囲が広がります。権限の拡大自体は「実行された時点で被害」ではありませんが、その後に起きる不可逆操作の射程を決めるので、事前に絞る必要があります。
対処は、ツール権限の最小化と、承認の有効範囲の限定です。「一度の許可をその操作だけに限定する」「エージェントに渡す認証情報を作業に必要な範囲に絞る」「アクセスできるディレクトリやネットワークを制限する」といった設計になります。
群3: 間接プロンプトインジェクション
分類4の 50. 間接プロンプトインジェクション、51. ツールポイズニング、56. エージェントハイジャック、分類3の 47. メモリポイズニングがこの群です。共通するのは、エージェントが読む外部データに指示が混入し、エージェントの目標そのものが乗っ取られることです。乗っ取られた後の行動は正規の操作と区別がつかないので、事後に「おかしな操作」として検出するのが難しくなります。
対処は、外部由来のテキストを命令として解釈しない設計です。「外部データは情報として扱い、指示としては扱わない」とモデルに指示するだけでは効果が薄く、乗っ取られた場合に誘導される先の操作（外部送信、削除）を、群1（不可逆操作）で述べた実行前のゲートで止める、という多層の構えが要ります。
実務上の優先順位
上の整理を、そのまま取り組む順番にしています。
- 不可逆操作に実行前のゲートを置く。 効果が最も直接的で、実装も最も簡単です。危険なコマンドのパターン照合と、人間の承認プロンプトの組み合わせで、削除・送信・公開を止めます。Claude Code なら設定ファイルの拒否ルールや hooks で制御できます。
- 権限を最小化する。 エージェントに渡すトークン、ディレクトリ、ネットワークを作業に必要な範囲に絞ります。ここを絞っておくと、他の対策が失敗したときの被害範囲が小さくなります。
- 外部データを読む経路を把握する。 エージェントがどの Web ページ、ファイル、ツール出力を読むのかを把握し、そこに指示が混入した場合に何が起きるかを考えます。完全には防げないので、1 で置いた実行前のゲートで最後に止める前提で設計します。
- 人間のレビュー工程を設計する。 事後検証で救える項目はここで吸収します。ただし分類5の 71. オートメーションバイアスがあるので、「レビューする」と決めるだけでは機能しません。レビューが形骸化していないかを、レビューの回数や所要時間から確認する仕組みが要ります。
- 記録を残し、記録の扱いを決める。 誰がいつ何を承認したかの記録は、責任の所在と後の説明責任に効きます。同時に 97. ログ保持の問題があるので、記録の保持期間と保存場所を決めておきます。
まとめ
101項目を並べてみて、自分が対処してきたのは分類3と4のごく一部だったと分かりました。それ自体は間違いではなく、実行前のゲートが要るのはその領域だからです。ただ、「なぜそこに対処しているのか」を全体の中で説明できるようになったのは、並べてみた収穫でした。
一覧を作る作業は、対策を増やすためではなく、対策しない項目を意図的に決めるためのものです。出力を読めば分かる項目は事後のレビューに任せ、モデルの内部や社会的影響に起因する項目はモデル提供者や組織のガバナンスに委ね、自分の手元では不可逆操作、権限、外部データの3つに集中する。この線引きができていれば、新しいリスクの名前が出てきても、どの群に入るかを見て対処の要否を判断できます。