エージェントに「してよいこと」を実行時に縛る：AgenticRei論文を読む
今日の1本
今日は、2026年6月19日のarXiv新着から、エージェント型AIのガバナンスに関する論文を取り上げます。タイトルは “Deontic Policies for Runtime Governance of Agentic AI Systems”。LLMエージェントがツールを呼び出し、データを操作し、ソフトウェアを入れ、さらに他のエージェントと連携するようになると、単なる「アクセス許可」だけでは統制が足りない、という問題意識から出発しています。論文は、IEEE Symposium on Agentic Servicesでの発表予定とされ、提案システムとして AgenticRei を示しています。(arxiv.org)
何が問題なのか
これまでの多くの権限管理は、ざっくり言えば「許可するか、禁止するか」を判定する仕組みでした。たとえば、あるユーザーやサービスが、あるデータにアクセスしてよいか。あるツールを実行してよいか。これはもちろん重要です。
ただ、エージェントの場合は少し事情が変わります。エージェントは一回の操作で終わらず、状況を見ながら複数の行動を連鎖させます。たとえば、顧客データを検索し、要約し、別の部署のエージェントに送信し、必要ならチケットを作り、管理者に通知する。ここで必要なのは「許可・禁止」だけではありません。
論文が強調するのは、次のようなルールです。
- ある操作をしたら、必ず監査ログを残す
- 特定の条件では、CISOや管理者へ通知する
- 通常は禁止だが、インシデント対応時だけ例外を認める
- 複数のポリシーが衝突したとき、どちらを優先するか決める
- 医療、金融、セキュリティのような領域固有の分類体系を使って判断する
つまり、エージェントに必要なのは「ドアを開けるか閉めるか」ではなく、「開けた後に何をしなければならないか」まで含む統制です。
AgenticReiの考え方
AgenticReiは、こうしたルールを deontic policy、つまり義務・許可・禁止・免除といった概念で表すアプローチです。ベースになっている Rei は、OWL-Lite上でポリシーを記述する仕様で、permission、prohibition、obligation、dispensation といった概念を扱えるよう設計されています。さらに、ポリシー衝突の解決やメタポリシーも扱える点が特徴です。(userpages.cs.umbc.edu)
ここで重要なのは、判断をLLMのプロンプト内に閉じ込めないことです。
「あなたは社内規定を守ってください」とシステムプロンプトに書いても、エージェントが複雑なツール列を実行する場面では限界があります。AgenticReiの発想では、LLMの外側に高性能なロジックエンジンを置き、ツール呼び出しやエージェント間メッセージを実行時に検査します。論文は、この仕組みがツール実行だけでなく、Agent-to-Agent、つまりエージェント同士の通信にも適用できると説明しています。(arxiv.org)
これはかなり大事な設計思想です。LLMを「判断者」にしすぎない。LLMは候補行動を提案する。しかし、実際に通すか、止めるか、追加義務を発生させるかは、外部の検証可能なポリシー層が決める。エージェント時代の安全設計は、この分業に向かっているように見えます。
既存のポリシーエンジンとの違い
論文は、XACML、Rego、Cedarのような既存のポリシー技術にも触れています。たとえばCedarの基本は、ポリシーがリクエストを permit するか forbid するかを評価し、明示的なDenyがAllowを上書きする、という考え方です。これはアクセス制御として非常に明快です。(docs.cedarpolicy.com)
しかし、エージェントの行動統制では、「許可した後に発生する義務」が重要になります。たとえば、顧客情報を分析すること自体は許可されるが、その結果を外部エージェントに渡すなら追加承認が必要になる。あるいは、緊急対応では通常ルールを一時的に免除できるが、その場合は事後報告が必須になる。
AgenticReiが狙っているのは、このような「行動の前後関係」を含む統制です。
なぜ今この論文が重要なのか
背景には、エージェント同士が相互運用される流れがあります。A2A、つまりAgent2Agent Protocolは、異なるベンダーやフレームワークで作られたエージェントが、能力を発見し、タスクを管理し、情報を交換するためのオープン標準として位置づけられています。仕様では、エージェントが互いの内部状態やツールに直接アクセスせずに協調できることが目標にされています。(google-a2a.github.io)
この世界では、ひとつのエージェントを安全に作るだけでは足りません。自社のエージェントが、取引先のエージェント、クラウド上の専門エージェント、社内の別部門のエージェントとやり取りする。そのとき、どの情報を出してよいのか、どの依頼を受けてよいのか、どの操作には人間の承認が必要なのかを、実行時に判断し続ける必要があります。
つまり、エージェントの普及は「モデル性能」の問題だけでなく、「統制面」の問題を前面に押し出します。
慎重に見るべき点
もちろん、この論文は実運用で広く検証された製品発表ではなく、研究提案として読むべきです。課題はいくつもあります。
第一に、ポリシーを書くコストです。deontic policyは表現力が高い一方で、現場の管理者が正しく書けるか、保守できるかは別問題です。
第二に、実行時性能です。エージェントのツール呼び出しやメッセージを毎回検査するなら、遅延やスケーラビリティが問題になります。
第三に、行動の意味をどう正しく表現するか。ポリシーエンジンが判断するには、「このツール呼び出しは何をしようとしているのか」が構造化されていなければなりません。LLMの自然言語説明だけに頼ると、ここでも曖昧さが残ります。
まとめ
今回の論文のポイントは、エージェント安全性を「もっと賢いLLMに任せる」方向ではなく、LLMの外側にある実行時ガバナンス層で支える方向に置いていることです。
これからのAIエージェントは、単に文章を返す存在ではなく、組織内外のシステムをまたいで行動する存在になります。そのとき問われるのは、「このモデルは何点か」だけではありません。
この行動は許されるのか。
許されるとして、何を記録すべきか。
誰に通知すべきか。
例外はどこまで認められるのか。
ポリシー同士が衝突したら、どちらを優先するのか。
AgenticReiは、その問いをかなり正面から扱っています。派手なモデルリリースではありませんが、エージェントを本当に業務に入れるなら、こうした制御層こそが次の主戦場になるはずです。