AIエージェントに権限を渡すとき、人間は何を保留するか

読むAIから、実行するAIへ

少し前まで、AIの仕事は読むことだった。要約し、答え、コードを提案する。いまは読んだ先で実行する。フォームを送信し、予約を取り、買い物をし、リポジトリに書き込む。読む権限と実行する権限は、まったく別のものだ。

実行するAIは、人間の代わりにアカウントを使う。そのアカウントが業務用なら、失敗の影響は本人で終わらない。顧客のデータ、会社の評判、他のサービスとの契約にまで及ぶ。

読む、書く、払う

権限は三つの層に分けて考えると見通しがよい。読む。ページを開き、文書を読み、データを取る。書く。フォームを送信し、設定を変え、ファイルを更新する。払う。決済を実行し、契約を結び、課金を発生させる。

読む権限は比較的広く渡せる。書く権限は対象と範囲を絞る。払う権限には人間の承認を残す。この三つを分けずに、ひとつの「エージェント用アカウント」へまとめて渡すと、事故のときにどこで止めるべきだったのかが分からなくなる。

事故の型

事故にはいくつか型がある。目的の取り違え。「入れて」と言われたアプリを「買って」と解釈する。過剰な権限。読むだけのつもりが、書く権限まで持っている。記録の不在。何をしたか分からないから戻せない。取り消し不能。送ったメール、通した決済、公開した投稿は、あとで消しても完全には戻らない。

どれも、モデルの性能を上げれば消えるものではない。権限の設計と、人間の承認点の問題だ。

設計の原則

原則は四つ。最小権限。その仕事に要る範囲だけ渡す。承認点。払う、公開する、削除する、外へ送る。戻せない操作の前に人間の確認を置く。取り消し可能性。実行を取り消せる単位に切る。記録。誰が、いつ、何を、どの権限でしたかを残す。

承認点は多いほど安全だが、多すぎると使われなくなる。すべてを確認するのではなく、戻せない操作に絞る。決済、公開、削除、権限の変更。この四つだけでも、事故の大半は防げる。

事例から

ブンリンAIラボの特集では、ブラウザAIを権限主体として扱う問題、Codexが有料アプリを買った一件、AIの事故を誰が記録するかを扱った。共通するのは、AIの判断そのものより、その判断にどんな権限が付いていたかという点だ。権限が大きければ、小さな取り違えが大きな損害になる。

自動化を進めるとき、最初に決めるのは「何をさせるか」ではなく「何を戻せなくするか」だ。戻せない操作に人間の承認を残し、戻せる操作から自動化する。この順序を守るかぎり、能力が上がっても被害は抑えられる。