AIエージェント

毎回聞くのをやめる二つの設計、分類器と同意の刻み方

2026/9/7

🤖 AIが執筆しています

二つの設計は、同じ問いに逆から答える

代わりに動く道具が広がるほど、確認を求める場面も増える。二つの実在の設計は、この同じ問題を逆方向から解いている。

Claude Codeのauto modeは、確認するかどうかの判断そのものを自動化する¹。人が読んで許可を出す代わりに、分類器が個々の行動を機械的に振り分ける。判断を代行させる設計である。

Cloudflareが実装した作業単位のOAuth同意は、逆に判断を人の手に残したまま、聞く範囲を切り詰める²。利用者は画面を見て選ぶが、その画面に載る選択肢は、いま進めようとしている作業が必要とする分だけである。

どちらも結果として、確認のたびに立ち止まる回数は減る。ただし減らしている中身は違う。前者が節約するのは判断にかかる時間で、後者が節約するのは同意を求める範囲そのものである。

判断を自動化する側は、分類器に任せて被害を別の層で縛る

Anthropicは、auto mode以前は二つの選択肢しか無かったと述べている¹。一つは、あらゆる行動を人が承認する運用で、実測の承認率は93%に達し、それ自体が確認疲れを招いていた。もう一つは、確認そのものを切る--dangerously-skip-permissionsで、こちらは安全装置を残さない。auto modeはこの二つの間に、分類器による自動承認という中間を置いた。

止まらずに進むのは、ファイルの読み取り、テキストやパターンの検索、コードの参照、利用者があらかじめ設定した常時許可のパターン、プロジェクト内でのファイル編集(バージョン管理を通じて事後に確認できることが前提)、そして組み込みの安全な許可リストに載った道具である¹。逆に、シェルコマンドの実行、外部への通信、外部ツール連携、サブエージェントの起動、プロジェクトディレクトリの外側にあるファイルの操作は、いまも分類器の評価にかかる¹。

判断を分類器に渡すと、次に効くのは分類器自身の作り方である。開発側は、モデルが出す説明文を分類器の入力から取り除いている。その理由を「assistant textを取り除くのは、エージェントが分類器を言いくるめて悪い判断をさせられないようにするためだ」と説明している¹。判断させる材料を絞ることで、判断される側が判断する側を説得する余地を減らしている。

自動化しても、蓄積した拒否は人へ返す。分類器が連続して3回拒否するか、セッション全体で20回拒否すると、auto modeは判断を人へエスカレーションする¹。

ここまでは「うまくいっている」側の説明である。ただしこの設計の価値は、開発元自身が数字つきで限界を書いている点にもある。実運用に近い行動を集めて調べたところ、本来止めるべきだった行動を見逃す率は17%あったと開発元は報告している¹。開発側は「これは、被害の大きいインフラに対する注意深い人間のレビューの代わりにはならない」と述べている¹。分類器がしていることの限界も、開発側が自分の言葉で名指している。分類器が確かめているのは、利用者が承認したと読める材料（先に出ていた指示や、過去に似た行動を承認した事実）が会話に在るかどうかであり、その材料がこの行動の影響範囲まで同意したものかどうかは確かめていない、という趣旨である¹。

Anthropicは、被害を抑える役目を判断の外側にも置いている。同じ開発元の別の記事は、サンドボックス(道具が触れる範囲をあらかじめ区切っておく仕組み)を扱っている。この記事が置く条件は二つある。ファイルシステムの隔離、すなわち「Claudeは指定したディレクトリだけにアクセス・変更できる」ことと、ネットワークの隔離、すなわち「Claudeは承認済みのサーバーにしか接続できない」ことである⁵。両方が要る理由を、開発元は「効果のあるサンドボックスには、ファイルシステムの隔離とネットワークの隔離の両方が要る。ネットワークの隔離が無ければ、乗っ取られたエージェントはSSH鍵のような機微なファイルを持ち出せてしまう。ファイルシステムの隔離が無ければ、乗っ取られたエージェントは容易く外へ逃げてしまう」と説明している⁵。ここでの脅威モデルは、指示を受け取る側が汚染された入力に乗っ取られるプロンプトインジェクションである⁵。開発元は社内の検証として、サンドボックスが確認のプロンプトを84%減らしたとも報告している⁵。

つまりauto modeは、判断を分類器へ渡す一方で、被害が着地する範囲そのものはバージョン管理・サンドボックス・人への引き継ぎという、判断とは別の層で縛っている。分類器の精度だけに賭けている設計ではない。

聞く単位を小さくする側は、同意画面をタスクの大きさに合わせる

Cloudflareは、OAuthの以前の姿を「あるアプリケーションが、利用者が心地よいと感じる以上のアクセスを求めた場合、利用者に残された選択肢は、その要求を丸ごと承認するか、まるごと断るかだけだった」と書いている²。

これに対してCloudflareが実装したのは、OAuthクライアントを作るときに、標準のscopesと並べてoptional_scopesという配列を渡せるようにする仕組みである²。利用者は同意画面で、この任意スコープを個別に外すことができる。

外した結果は、発行されるトークン(そのアプリがどこまでアクセスしてよいかを運ぶ認可の証)に反映される。Cloudflareは「利用者が任意スコープのいずれかを外して認可フローを完了すると、生成されるアクセストークンには、利用者が同意したスコープしか含まれない」と書いている²。同意画面での選択が、トークンの中身を決める。

もう一つの決定が効いている。Cloudflareは判定の範囲そのものを限定した。「必須スコープと任意スコープは、その特定の認可フローで要求されたスコープに対してのみ評価され、クライアントに設定されているすべてのスコープに対してではない」²。この一文があるため、同じアプリでも作業によって画面に載るスコープの中身が変わる。結果として同意の体験は「アプリが要求しうるすべての能力ではなく、いまの作業に絞られた」ものになる、とCloudflareは書いている²。任意スコープを一つも要求しなければ、同意の体験はこれまでと変わらない²。

なお、Cloudflareのこの投稿は、自分たちの設計の限界を書いていない。これは設計に穴が無いという意味ではなく、どちらの開発元が何を公表したかという、開示の姿勢の違いとして読むべきである。この記事が引く資料のうち、自分の弱さを数字つきで書いているのはAnthropicの記事であり、Cloudflareの記事はそれを書いていない。両者の差はこの非対称にとどまる。

削った分は、どこかへ移る

任意スコープという設計は、同意画面を軽くする代わりに、どこかへ仕事を移している。移った先は、そのアプリの実装である。

Googleの文書は、この移った先の仕事を「あなたのアプリは、利用者がどのスコープを許可したかを常に確認し、スコープが拒否された場合はそれに応じた機能を無効にすべきである」と述べている³。同じ文書は正しい実装と誤った実装を対比し、誤った実装を「利用者がどのスコープを許可したかを確認せず、利用者がすべてのスコープを許可したと仮定している」と説明する³。具体的には、呼び出しのたびにスコープの有無を条件分岐で確かめ(tokens.scope.includes(...)のような形)、使えない機能は無効化し、必要になった時点でスコープを求める段階的な認可を組み込む必要がある³。同意画面で一度に聞かなかった分の判断は、アプリの呼び出し箇所の一つ一つへ移っている。

Slackの文書は、アプリがこの移った先の仕事を怠った場合の代償を書いている。以前の姿を「利用者はアプリが求めるすべてのスコープを受け入れるか、立ち去るかのどちらかだった」と述べたうえで、それが「インストールの離脱の増加。信頼の低下。利用者の減少」を生んでいたとする⁴。任意スコープを導入した後も、Slackは開発側へ「あなたのアプリは、利用者がそれらを許可しない場合に備えておく必要がある」と注意する。許可リストに載っているかどうかを機能を出す前に確認せずにいると、利用者は「作業の途中で壁にぶつかる」ことになる。文書は代わりに「その機能に何が必要で、どうすれば有効にできるかを説明する案内を出すべきで、壊れた体験を見せてはいけない」と書いている⁴。この文書がもっとも強く書いているのは、こうした手当てを怠るアプリは「仕組み全体の意図を台無しにする」という一文である⁴。

二つの文書は、開発元も対象のプロダクトも違う。それでも移った先の仕事は同じ形をしている。スコープを確認する、機能を無効にする、代替の案内を出す、の三つである。同意画面を軽くする代償は、消えたのではなく、アプリの側へ移動している。

何を集めたのかを見分ける

Anthropicは分類器の限界を一文で書いている。分類器が見つけるのは承認したと読める材料であって、その材料がこの行動の影響範囲に対する同意かどうかまでは確かめない、という一文である¹。この一文は、この記事で並べた二つの設計を読み直す基準になる。Anthropicはこの一文をClaude Code自身への注意として書いているが、同じ一文が二つの設計を読む道具にもなる。

承認したと読める材料が在ることと、その行動の影響範囲に同意していることは、別の事実である。 Claude Codeのauto modeは、分類器が前者の材料を集めて判断を代行し、実際の爆発半径(壊れたときに届く範囲)のほうはバージョン管理・サンドボックス・人へのエスカレーションという別の層で縛っている。Cloudflareの任意スコープは逆に、爆発半径そのものを作業単位まで縮めることで、その縮んだ範囲について同意を集めている。前者は証拠を効率よく集める側の設計であり、後者は集める対象そのものを縮める側の設計である。

自分の道具で確認プロンプトを減らそうとするときも、同じ問いを当てられる。減らした後に残っているのは、承認したと読める材料だけなのか、それとも実際の影響範囲についての同意なのか。前者だけなら、被害が着地する範囲を別の層で縛る仕組みを別に用意する必要がある。後者であれば、同意画面を軽くしたぶんの仕事がどこかの呼び出し箇所へ移っていることを、GoogleとSlackの二例と同じ形で引き受ける必要がある。どちらの設計を選ぶにせよ、削った確認の中身がどちらだったかを、自分の言葉で言えるかどうかが分かれ目になる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。