自律的に動くAIエージェントほど、先に権限設計が要る理由

あらかじめ決めた手順をそのままなぞるだけの自動化と、状況に応じて次の一手を自分で選ぶ自律型のエージェントは、性質が違います。手順通りに動くだけなら、実行される操作もあらかじめ全て把握できます。一方で自律的に判断するエージェントは、想定していなかった操作を、想定していなかったタイミングで実行してしまう余地を持ちます。

この余地に対して「都度、人が確認すればよい」という運用にすると、確認する人自身がボトルネックになり、自律化によって得られるはずの速さが失われます。かといって「基本的に全部任せる」という方針にすると、想定していなかった操作まで無確認で通ってしまいます。どちらの側に振っても運用は長く続きません。だからこそ、最初の設計段階で「何を無確認で実行させ、何を必ず人の承認で止めるか」を、その場の判断ではなく規則として先に決めておく必要があります。

許可規則（許可リスト）が抱える3つの構造的な罠

権限設計というと、ひとまず許可リストを作れば終わりだと考えられがちです。しかし許可リストは一度作って終わりではなく、機能を追加するたびに規則を足していく運用の中で、次のような形で崩れていきます。

  • 過剰許可の罠。特定の操作だけを許可するつもりで規則を書いたはずが、似た操作をまとめて許可する書き方になってしまい、想定していなかった操作まで規則の範囲に含まれてしまいます。
  • 規則の重複による無効化。複数の規則を積み重ねていくうちに、後から追加した緩い規則が、最初に設定した厳しい規則を実質的に上書きしてしまいます。規則同士の優先順位や重なりを都度確認していないと、意図した制限が効かなくなります。
  • 不可逆な操作の混入。削除・送信・課金・公開のような取り消せない操作が、下書き作成や一時保存のような取り消せる操作と同列に、許可リストへ並んでしまいます。

いずれも、悪意のある設定や単純な入力ミスというより、機能ごとに規則を足していく作業を積み重ねた結果として自然に発生します。だからこそ、規則を書く時点での注意だけでなく、後から見直す仕組みが必要になります。

操作を分類する2つの軸 — 取り消せるかどうか、外に出るかどうか

権限を分類する基準はいくつかありますが、実務で最初に効くのは「その操作は取り消せるかどうか」という一点です。

  • 取り消せる操作の例として、下書きの作成、社内向けの通知、ファイルの一時保存、集計や分析の実行などが挙げられます。結果が気に入らなければ、やり直しや破棄がききます。
  • 取り消せない、または扱いを重くすべき操作の例として、外部への送信や公開、データやファイルの削除、決済や契約に関わる操作、復元手段のない外部システムへの書き込みなどが挙げられます。

もう一つ、見落とされやすい軸があります。それは「読み取りだけの操作」と「外に出る操作」を同じ土俵で扱わないという軸です。ファイルを読む、状況を集計する、内部の下書きを作るといった操作は、外部から見える結果を一切生みません。失敗しても影響は自分たちの内側にとどまります。一方で送信・公開・課金のように外部の相手や外部のシステムに結果が届く操作は、取り消しがきくかどうかとは別に、間違った内容がそのまま相手に届いてしまうという固有のリスクを持ちます。読み取り系の操作まで承認の対象に含めてしまうと、承認の数が増えるだけで実質的な安全性は上がらず、次に説明する粒度の設計にも影響します。

この見分けを、実行のたびにエージェント自身の判断に委ねると、確認の手間も判断のばらつきも増えます。操作の種類ごとにあらかじめ分類し、その分類を許可規則そのものに組み込んでおく方が、運用として長く続けやすくなります。

許可規則の「粒度」をどう決めるか

許可規則は、どの単位で許可を切るかによっても効き方が変わります。コマンド単位で許可すると規則の数は少なく済みますが、そのコマンドの中に危険な使い方も安全な使い方も両方含まれている場合、危険な使い方まで一緒に許可してしまいます。逆に、サブコマンドや引数の値まで細かく指定して許可すると、危険な操作だけを狙って除外できますが、規則の数が増え、少し違う操作をするたびに新しい規則を追加するか、承認を求める場面が発生します。

粗すぎる粒度は、後から振り返ったときに「そこまで許可するつもりはなかった」操作が含まれている状態を作ります。細かすぎる粒度は、日常的な操作のたびに承認を求められる状態を作り、結果として「とりあえず許可を広げておく」という運用に流れやすくなります。どちらの極端も、最終的には権限が広がる方向に働くという点で同じ問題に行き着きます。

実務での落としどころは、操作を先に説明した2つの軸（取り消せるか、外に出るか）で分類したうえで、内側で完結し取り消しがきく操作はコマンド単位でまとめて許可し、外部に結果が届く操作や取り消せない操作は、対象・宛先・金額といった引数のレベルまで指定して許可を絞る、という使い分けです。全ての操作を同じ粒度で扱おうとしないことが、規則を運用し続けられる形に保つ鍵になります。

AIに任せる範囲と、人が必ず判断する範囲の線引き

実務でもっとも曖昧になりやすいのが、この線引きです。任せてよい側と、必ず人が判断する側に分けて整理します。

  • AIに任せてよい領域は、取り消せる操作で、影響範囲が狭く、結果を人が事後に確認できる操作です。失敗しても損失が小さいことが前提になります。
  • 人が必ず判断する領域は、取り消せない操作、金銭・契約・公開に関わる操作、そして権限規則そのものを変更する操作です。

最後に挙げた「権限規則そのものを変更する操作」を人の判断領域に含めておくことは、特に見落とされやすい点です。エージェントが自分自身の許可範囲を自分で広げられる状態を作ってしまうと、最初にどれだけ厳密に線引きをしても、その線引き自体が後から崩される可能性が残ります。

この線引きが崩れやすいもう一つの場面が、作業のために許可を一時的に広げたときです。特定の作業を進めるために、普段は人の承認を必要とする操作を一時的に無確認で通せるようにすることは珍しくありません。問題は、その作業が終わったあとに、広げた許可を元の状態へ戻す作業が、承認を追加するときほど注目されないことです。追加は目的とセットで記憶に残りますが、解除は目的が終わった後の後始末なので忘れられやすくなります。一時的に広げた許可には、戻す期限か戻すきっかけをあらかじめ決めておき、期限が来たら自動的に対象から外れるようにしておくと、広げたままの状態が積み重なるのを防げます。

承認を求められた時、人は何を見て判断するか

承認の仕組みを用意しても、承認する側が画面に出てきた確認を毎回同じように読み流してしまうと、承認は形だけのものになります。特に、日中に何度も同じような確認が届くようになると、内容を読む前に反射的に許可してしまう「承認疲れ」が起こりやすくなります。これは人の注意力の問題であると同時に、確認の出し方の設計の問題でもあります。

承認のたびに人が実際に確認すべきなのは、細かい実行ログの全文ではなく、次の3点に絞られます。対象は何か（どのデータ・どの相手・どの金額か）、その操作は取り消せるか、そしてこれは普段の許可規則の範囲内か、それとも一時的に広げた範囲での実行かという点です。この3点だけを毎回同じ形式で示すようにしておくと、確認する側の負担が減り、読み流しも起きにくくなります。逆に、確認の都度フォーマットが変わったり、情報量が多すぎたりすると、承認は形骸化していきます。

運用を続けていると、新しい機能を試すたびに許可を1つずつ足していくことは自然に起こりますが、逆に許可を外す機会は、意識して作らない限り訪れません。結果として、許可規則は増える方向にしか動かない非対称な運用になりやすくなります。この非対称性に対して、棚卸しを人の記憶やレビュー会議だけに頼ると、規則の数が増えるほど見落としが出やすくなります。棚卸しを「思い出して確認する作業」ではなく、規則の一覧を機械的に洗い出し、過剰な許可範囲・規則同士の重複・不可逆操作の混入・戻し忘れた一時許可がないかを検出する仕組みとして持たせておくと、増え続ける規則の中でも見落としに気づきやすくなります。

relmeaでは、Claude Code上で102体のエージェントと50本のコマンドを運用しており、許可規則の棚卸しを定期的なコマンドとして持たせています。これは特別な仕組みというより、許可規則が放っておけば増え続けるという前提に立った上で、増える側にしか動かない運用に、外部から見直しを差し込む手段を用意しているだけのものです。