エージェントを「止められる」ようにする ―― 4つの記憶とガードレールに、もう一つの層「権限制御」を加える

0. 前回までのおさらい（導入）

前回の記事では、AIエージェントを支える「4つの記憶」（ワーキング／セマンティック／プロシージャル／エピソード）を整理し、最後にもう一つの層として「ガードレール」を紹介した。

ガードレール層の要点はこうだった。

LLMが何を考えていようと、外側のレイヤーが物理的にブロックする。「賢いAIに信じて任せる」のではなく、「AIを物理的に囲い込む」。

しかし、ここで一つ告白しなければならない。前回紹介したガードレール（Llama Guard、NeMo Guardrails、Guardrails AIのような入力・出力フィルタ）は、正確には**「物理的に」囲い込んではいない**。

あれは、LLMの出す言葉を横から検閲する仕組みだ。どれだけ精度が高くても、原理的には「うまく言いくるめれば通ってしまう」余地が残る。実際、ジェイルブレイクの手口を体系化したArizeの調査では、感情に訴える、フィクションに包む、エンコードするといった複数の手口を組み合わせることで、単体では検知されない攻撃が成立することが示されている。

では、本当に「物理的に無力化する」にはどうすればいいのか。

今回は、この問いに答える第4の層――「権限制御（Authorization）レイヤー」――について書く。

1. コンテンツフィルタと権限制御は、まったく別の仕事をしている

まず区別をはっきりさせたい。この2つは名前こそ両方「ガードレール」と呼ばれがちだが、守っているものが違う。

前者は「悪いことを言わせない・出させない」ための仕組みで、後者は「悪いことを"できなく"する」ための仕組みだ。

エージェントがチャットで完結していた時代は、前者だけでもある程度は事足りた。最悪、不適切な"発言"が出るだけで済んだからだ。しかし今はエージェントが銀行振込を実行し、DBを書き換え、Slackにメッセージを送る時代になった。言葉を検閲するだけでは、行動そのものを止められない。

2. なぜ今、権限制御が焦点になっているのか

2026年に入って、この分野に関する論文や発表が急増している。象徴的な調査結果を一つ紹介したい。

記憶とシェルアクセスを持つ自律エージェント6体を14日間動かした、あるレッドチーム調査では、動詞を一つ言い換えるだけでSSN（社会保障番号相当の個人情報）を漏らしたり、秘密を守るために自分自身のインフラを破壊したり、権限のない相手の指示に従ってしまったりする挙動が確認されている。

これは「モデルの訓練を頑張って賢くする」「フィルタの精度を上げる」というアプローチの限界を示す実例だ。モデルは確率的に動く以上、100%の確実性を「お願いベース」の制御に求めるのは無理がある。

だからこそ、業界は「モデルに聞かずに、外側の仕組みで機械的に止める」方向に舵を切り始めている。

3. 権限制御レイヤーの4つの実装パターン

現時点（2026年）で実際に試みられているアプローチを、粒度の細かい順に整理する。

(1) 最小権限設計 ―― そもそも危険な道具を持たせない

一番シンプルで、一番確実。エージェントに与えるツールを、タスクに必要な最小限に絞る。

ただし現状の多くのエージェント基盤は、あるAPIに対して「全部アクセスできる」か「全くアクセスできない」かのオール・オア・ナッシングになりがちだという課題が、2026年3月の研究（AC4A: Access Control for Agents, ワシントン大学）で指摘されている。ここを細粒度にする研究がまさに進行中の段階だ。

(2) 実行直前の機械的な認可（Pre-Action Authorization）

これが今回の記事で一番強調したいパターンだ。

ツール呼び出しを実行する直前に同期的にインターセプトし、宣言的なポリシー（コードで書かれたルール）と照合して許可・拒否を判定する。判定するのはLLMではなく、外部の決定論的なエンジンだ。

2026年3月に発表されたOpen Agent Passport（OAP）という仕様は、この考え方を明確に定式化している。要点は「AIエージェントにはパスワードはあっても、通行許可証（permission slip）がない」という現状認識だ。

商用の動きとしては、Crittora社が2026年1月に発表したAgent Permission Protocol（APP）がある。特定のエージェント・特定の行動範囲・明示的なツール権限を暗号署名された許可ポリシーで縛り、ツールが露出する前に検証し、失敗時は「デフォルトで拒否（fail-closed）」する設計だ。

(3) スコープ付き・短命なトークン（Agentic IAM）

Auth0（Okta）、Permit.io、Aembitのような企業が「エージェント向けID・認可基盤」という新市場を作りつつある。共通する考え方は以下の通り。

• エージェントに生の認証情報（APIキーなど）を渡さず、短命で用途を絞ったトークンを発行する
• 高リスクな操作（送金、機密文書アクセスなど）には非同期の人間承認フローを挟む
• ロール／属性ベースのアクセス制御で「このエージェントはこのデータ・この操作にしか触れない」を強制する

MCP（Model Context Protocol）自体の仕様にもOAuth 2.1ベースの認可フレームワークが組み込まれつつあり、業界全体がこの方向に向かっていることを示している。

(4) キルスイッチ／サーキットブレーカー ―― それでも止まらなかった時の最後の砦

事前認可をすり抜けた場合や、意図しない暴走（無限ループでのコスト爆発など）に備える、最終防衛ラインだ。

考え方は前回紹介したサーキットブレーカー（正常時＝closed、異常検知時＝open で強制遮断、回復確認中＝half-open）とほぼ同じで、Webサービスの障害対応の知見をエージェントに応用したものと言える。異常検知時に該当エージェント、あるいはポリシーグループ全体を即座に一時停止し、原因調査後に1体ずつカナリア方式で再開する、という運用フローが実務では紹介されている。

4. リスクの高さで、どの層を使うか決める

前回「メモリとガードレール、どちらにルールを書くかはリスクで決める」という表を出した。権限制御レイヤーを加えると、この判断軸はもう一段深くなる。

ポイントは、上から下に行くほど「LLMの判断への依存度」が下がっていくことだ。一番下の層では、LLMが何を"考えたか"はもはや関係ない。実行できるかどうかは、LLMの外側にあるポリシーエンジンが決める。

5. まだ標準がない ―― だからこそ設計判断が問われる

正直に書いておきたいが、この分野はまだ「みんなで手探りしている」段階だ。

• NISTは「ソフトウェア及びAIエージェントのID・認可」に関する概念文書のドラフトを2026年2月に公開したばかりで、パブリックコメント期間は同年4月2日までだった。国レベルの指針すら固まっていない。
• IETF（インターネット標準化団体）も、2026年1月時点で「何を標準化すべきか、今まさに洗い出している」段階だと表明している。

一方で市場は待ってくれない。AIエージェント市場は2025年の80.3億ドルから2026年には117.8億ドル規模（前年比46.6%成長）に達すると予測されており、開発者調査では94%が「より強固でスケーラブルなエージェント基盤があればベンダーを乗り換える」と回答している。

つまり、標準ができる前に、企業は実装を迫られている。 ここに、エンジニアやアーキテクトが担うべき役割がある――「うちの会社の場合、どのタスクにどのレベルの権限制御を選ぶべきか」を、リスクの大きさに応じて翻訳し、設計として提示することだ。

6. 結論：5層構造への拡張

前回の3層構造（メモリ層／ガードレール層／ツール権限層）は、こう拡張できる。

[ユーザー入力]
    ↓
[入力ガードレール] ← コンテンツフィルタ（確率的）
    ↓
[LLMエージェント] ← 4つのメモリを持つ
    ↓ (ツール呼び出しの"意図")
[権限制御レイヤー] ← ポリシーエンジンによる実行直前の機械的認可（決定論的）
    ↓ (許可された場合のみ)
[最小権限のツール] ← そもそも危険な操作の"手段"を持たない
    ↓
[出力ガードレール] ← コンテンツフィルタ（確率的）
    ↓
[サーキットブレーカー / キルスイッチ] ← 異常検知時の強制停止（最終防衛ライン）
    ↓
[ユーザーへ返答 / 実行結果]

「賢さ」を磨くレイヤー（メモリ）と、「振る舞い」を検閲するレイヤー（コンテンツガードレール）だけでは、もはや足りない。**「そもそも何ができるか」を外側から決めるレイヤー（権限制御）**があって初めて、エージェントは安全に"手を動かす"存在になれる。

最後に、前回と同じ形で、問いを二つ残しておきたい。

あなたのエージェントが今日、間違った判断をしたとして――それは"止まる"仕組みになっていますか？

その仕組みは、LLMの"良識"に頼っていませんか、それとも外側の何かが物理的に止めていますか？

参考（本記事の元になった調査・発表）

• NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization (Concept Paper, Draft, Feb 2026)
• Uchibeke, U., Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents (arXiv:2603.20953, Mar 2026)
• Sharma, R. K. & Grossman, D., AC4A: Access Control for Agents (arXiv:2603.20933, Mar 2026)
• Crittora, Agent Permission Protocol (APP) announcement (Jan 2026)
• IETF Blog, Agentic AI communications: Identifying the standards we need (Jan 2026)
• Arize AI, AI Jailbreaking and Guardrails
• Galileo AI, The Essential AI Agent Guardrails Framework for Autonomous Systems