AIエージェントへの「全許可」をやめた理由——権限は最小に、承認は要所に

AIエージェントに強い権限を渡すほど、日々の作業は速くなりますが、事故が起きたときの被害も同時に大きくなります。 この2つはトレードオフの関係にあり、「便利さ」と「安全さ」のどちらかに寄せるのではなく、操作の種類ごとに線を引く必要があります。私たちは複数プロダクトの日次運用をAIエージェントに任せていますが、初期に使っていた「全操作を一括で許可する設定(いわゆるYOLOモード)」を撤去し、操作の性質によって承認の要否を分ける設計に切り替えました。この記事では、その切り替えに至った理由と、実際に引いている線を一次体験として公開します。

権限設計とは何を決めることか

AIエージェントの権限設計とは、エージェントがどの操作を確認なしに実行してよく、どの操作は人間の承認を経るべきかを、あらかじめ線引きしておくことです。モデルの性能や指示の丁寧さの話ではなく、操作そのものの取り返しのつきやすさに注目する設計です。

線引きが曖昧なままだと、便利さを優先して結局すべてを許可してしまうか、逆に安全を優先してすべてに確認を求め、エージェントに任せる意味がなくなるかのどちらかに振れやすくなります。

なぜ最初は「全許可」にしたくなるのか

AIエージェントを使い始めた頃、毎回の確認プロンプトは素直に面倒でした。読み取り専用の操作にまで確認を求められると、結局は「はい」を押すだけの作業が増え、エージェントに任せている実感が薄れていきます。この摩擦を消したいという動機は自然なもので、全許可の設定に手が伸びるのは合理的な反応です。

問題は、この摩擦回避の判断が、操作の中身を見ずに一括で下されることです。ファイルの中身を読むだけの操作と、外部にファイルを送信したり削除したりする操作が、同じ「確認なし」の扱いになります。人間側は「面倒な確認を減らしたい」だけのつもりでも、実際に減らしているのは取り返しのつく操作への確認ではなく、取り返しのつかない操作への確認も含めた全部です。

権限を分けずに運用していた時期に起きかけたこと

全許可に近い設定で運用していた時期、意図していなかった書き込み系の操作が、確認なしに実行されかけた場面がありました。実害には至らず気づいて止められましたが、その場面で初めて「確認なしで実行できる操作の範囲を、自分で正しく把握できていなかった」ことに気づきました。 便利さを優先して線引きを飛ばしたことのツケが、まさにその線引きが必要な場面で表面化した形です。

この経験から見直したのが、次に挙げる「最小権限の原則」の考え方です。

最小権限の原則を、確認要否の線引きに使う

情報セキュリティの分野には古くから「最小権限の原則(principle of least privilege)」という考え方があります。システムやユーザーには、その時点で必要な権限だけを与え、それ以上は与えないという設計思想で、1975年のSaltzerとSchroederによる古典的なセキュリティ論文以来、繰り返し参照されてきた原則です。

AIエージェントの運用でも、この発想はそのまま使えます。「便利かどうか」ではなく「取り返しがつくかどうか」で操作を分類し、取り返しのつかない操作にだけ人間の確認を残すという線引きです。

この3段階のうち、常時許可してよいのは一番上の「読み取り専用かつ繰り返し使うもの」だけに絞ります。一度きりの操作は、たとえ読み取り専用でも毎回確認する側に残すのが安全側の判断です。

権限を分けたことで変わった3つのこと

この3原則を運用に組み込んでから、確認のたびに感じていた摩擦は減りました。理由は単純で、確認を求められる回数そのものは減らなくても、「なぜここで確認を求められているのか」が毎回説明できる状態になったからです。理由の分からない確認は煩わしく感じますが、理由が分かる確認は、必要なコストとして受け入れやすくなります。

責任の所在との関係

権限をどこまで渡すかという設計は、AIエージェントが実行した操作の責任を誰が負うのかという論点ともつながっています。この点は以前の記事「AIエージェントが「勝手に」やったことの責任は誰が取るのか」で、法的な観点から整理しました。権限設計は、その責任を実際に負う人間が、事後ではなく事前に負担をコントロールするための手段だと捉えています。

よくある質問

Q. 権限を絞ると、AIエージェントに任せる意味が薄れませんか。 A. 薄れません。減らすべきなのは確認の回数ではなく、確認すべき場面で確認が抜け落ちるリスクです。読み取り系の操作を広く許可すれば、日々の作業速度はほとんど落ちません。

Q. どの操作を「破壊的」と判断すればよいですか。 A. 目安は、後から元の状態に戻せるかどうかです。ファイルの削除・外部への送信・公開・課金のように、一度実行すると取り消せない、または外部に影響が及ぶ操作は、破壊的な側に分類しています。

Q. 一度許可した操作は、次回から確認なしにしてよいですか。 A. 操作の性質によります。私たちの運用では、繰り返し使う読み取り専用の操作だけを常時許可の対象にし、書き込みや対外的な操作は、過去に許可したことがあっても毎回内容を確認する側に残しています。

Q. この設計は特定のツールに限った話ですか。 A. いいえ。ここで挙げた分類と線引きは、権限を持つAIエージェント全般に当てはまる設計上の論点です。使うツールが変わっても、読み取り・書き込み・破壊的操作という分類軸自体は流用できます。

私たちJurisCode.AIは、AI×法律×心理学を掛け合わせ、AIに任せる範囲を精神論ではなく設計で線引きするという考え方を軸にプロダクトをつくっています。JurisCode.AI公式サイト(新しいタブで開く)でブランドの考え方とプロダクト群を紹介しています。

本記事は特定のツールの権限設定を推奨するものではなく、個人開発における運用ルールの一次体験を一般化して整理したものです。