Column

AIエージェントを「許可・禁止・義務」で縛る——義務論的ガバナンスとは何か

LLMエージェントへの認証・アクセス制御だけでは不十分だと指摘する研究がarXivで公開されました。許可・禁止・義務という義務論的制約をリアルタイムで適用するフレームワークが、CISO・法務・GRC部門のAIガバナンス設計に示す具体的な含意を解説します。

2026 / 06 / 21 5 分で読める English version →

AIエージェントの行動に対して許可・禁止・義務のルールが動的に適用される様子を表した抽象的なフラットイラスト

こんにちは。Affectosphere Group の井下です。

「AIエージェントに権限を与えてしまったら、あとはどう制御するか」という問いが、いま企業のセキュリティ・コンプライアンス部門で切実になってきています。

メールを送り、APIを叩き、社内システムを更新するAIエージェントは、もはや実験段階ではありません。現場に入ってきているシステムです。そこで課題になるのが、「認証を通過した後」の話です。

2026年6月にarXivで公開された研究（Anupam Joshi、Tim Finin、Karuna Pande Joshi、Lalana Kagal; arXiv:2606.19464）は、この問題を「義務論的ポリシー（deontic policies）」という視点から整理しています。許可（permission）・禁止（prohibition）・義務（obligation）という3種類の制約をLLMエージェントの実行時に適用する仕組み、AgenticReiの提案です。

認証の世界では「誰が何にアクセスできるか」を管理します。でもエージェントが自律的に動き出した後に「何をしてよいか、してはいけないか、しなければならないか」を制御するには、それだけでは足りない——という問題意識から始まる研究です。

今日の3点

認証・アクセス制御だけでは、自律的に行動するAIエージェントを制御しきれない。
許可・禁止・義務の義務論的制約を実行時に適用する AgenticRei が提案されている。
CISO・法務・GRC部門にとって、EU AI Act対応やSOC2監査の設計に直結する知見がある。

① 認証を「通過した後」が問題になる

従来のシステムセキュリティは、「誰が入れるか」の管理が中心です。

XACML（eXtensible Access Control Markup Language）やRegoといったアクセス制御言語がその代表で、エンタープライズのシステムに広く使われています。Cedarも同様の役割を担います。

ただ、これらは「認証・認可フェーズ」の仕組みです。エージェントがログインして動き出してしまった後に、「今この瞬間この行動はしてよいか」を動的に判断する用途には適していません。

この研究が指摘するのはその空白です。LLMベースのエージェントは、一度認証されると複数のツールを連鎖的に呼び出し、他のエージェントと協調しながら作業を進めます。その過程で発生する個々のアクション、一つひとつに対してポリシーを適用する仕組みが、既存のツールには不足しています。

さらに既存のXACML・Rego・Cedarでは表現できない機能として、この研究は次の4点を挙げています。義務のライフサイクル管理（いつ義務が発生し、いつ消えるか）、ポリシーの競合解消、免除（dispensation）の仕組み、オントロジー推論です。後で詳しく触れますが、これらはコンプライアンス対応の現場では馴染みのある概念ばかりです。

② AgenticRei が解決しようとすること

この研究が提案するのが AgenticRei です。

OWL（Web Ontology Language）のReiフレームワークを使ってAIエージェントのガバナンスを実装する設計です。特徴は、LLMの「外部」に高性能な論理推論エンジンを置く点にあります。

LLM自身にルールを覚えさせるのではなく、外部の推論エンジンがリアルタイムにポリシーを評価します。エージェントがツールを呼び出す前、エージェント間で情報をやりとりする前に、「この行動は許可されているか、禁止されているか、義務として課されているか」を判定する構造です。

許可（permission）は「できること」を定義します。禁止（prohibition）は「してはいけないこと」を防ぎます。義務（obligation）は「しなければならないこと」を保証します。

重要なのは義務のライフサイクル管理です。たとえば「個人情報を処理した場合は、処理完了後24時間以内に監査ログを提出しなければならない」というルールがあるとします。このルールは「個人情報を処理する」というイベントが起きた時点で発生し、「監査ログを提出する」というアクションが完了した時点で消える義務です。この発生・持続・消滅のサイクルを管理する機能が、既存ツールにはありませんでした。

免除（dispensation）も実務上の重要な概念です。通常は禁止されている行動を、特定の条件下・特定の主体に限って許可する仕組みです。たとえば「顧客データへのアクセスは禁止だが、インシデント対応中のセキュリティ担当者には例外的に許可する」といったルールを表現できます。

ポリシーの競合解消も現場課題です。「プライバシー保護のため顧客データは送信禁止」と「コンプライアンス報告のため当該データを規制機関に送付する義務」が同時に存在するとき、どちらを優先するか。AgenticReiはオントロジー推論を使ってこの矛盾を解消します。

③ CISO・法務・GRC部門はどう試せるか

では現場でどう活用するか、具体的に考えてみます。

まずEU AI Actへの対応という文脈で使えます。

EU AI Act（2026年より本格適用）では、高リスクAIシステムに対してリスク管理・ログ記録・透明性確保が義務づけられています。「AIエージェントが何をしてよくて、何をしてはいけないか」をポリシーとして明示的に定義し、実行時に適用・記録する仕組みは、まさにこれらの要件に対応するアーキテクチャです。

AgenticReiのような外部推論エンジンを使うアプローチは、「AIの判断をAI自身に委ねない」という監査上の重要な性質を持ちます。外部エンジンが形式的なポリシーを機械的に評価するため、規制当局への説明可能性という観点で大きな強みになります。

SOC2監査対応でも同様のロジックが使えます。SOC2のセキュリティ基準では、アクセス制御・変更管理・監視の証跡が求められます。エージェントの行動にポリシーが適用された記録、免除が発動したケースのログ、義務の発生と完了の記録——これらをAgenticRei的なアーキテクチャで取得しておくと、監査証跡の品質が上がります。

具体的なユースケースとして、社内の文書生成エージェントを例に挙げます。

許可ポリシー: 社内ナレッジベースへのアクセス
禁止ポリシー: 顧客の個人情報を含む文書の外部送信
義務ポリシー: 外部APIを呼び出した場合は必ず呼び出しログを記録する

この3種類のポリシーをLLM外部のエンジンで管理すると、エージェントの行動がプロンプトの書き方に左右されず、形式的なルールに基づいて制約されます。「プロンプトインジェクション攻撃によって禁止ポリシーが回避された」というリスクを構造的に下げられます。

KPIとして追うとすれば、「エージェント起因のポリシー違反件数」と「ポリシー適用によって未然防止されたインシデント件数」の両方を見ることです。前者だけを見ていると、ガバナンスが機能していることの証拠が見えません。

「認証を通過した後」の制御が、次のセキュリティ課題

AIエージェントのセキュリティは、「誰を信頼するか」という認証の問題から、「信頼したエージェントに何をさせるか」という行動制御の問題へと移行しています。

この変化は、CISOにとっては攻撃面の変化でもあります。プロンプトインジェクション・ツール呼び出しの誤用・エージェント間通信の悪用は、認証層では防げません。

AgenticReiが提案するアーキテクチャ——LLM外部に高性能な論理推論エンジンを置き、許可・禁止・義務の制約をリアルタイムで適用する——は、このシフトへの一つの回答です。

研究レベルの提案ではありますが、GRC部門がAIエージェントのガバナンスポリシーを設計するときの思考フレームとして、いまから取り入れる価値があります。「ウチのエージェントには何を禁止して、何を義務として課しているか」という問いに答えられるかどうか、確認してみてください。

では！

参考論文

Anupam Joshi, Tim Finin, Karuna Pande Joshi, Lalana Kagal (2026). Deontic Policies for Runtime Governance of Agentic AI Systems. arXiv preprint.

※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。