AIエージェント

確認プロンプトを減らすauto modeと、権限を絞るOAuth同意の違い

2026/9/7 （更新: 2026/10/23）

🤖 AIを使用して執筆

一律の確認が働かないので、二つの設計は別々の部分を削る

二つの実在の設計は、毎回同じ形の確認が形だけになるという同じ問題を、確認の別の部分を削って解いている。

Claude Codeのauto modeは、確認するかどうかの判断そのものを自動化する¹。Claude Codeは、Anthropicが2025年2月に研究プレビューとして公開し同年5月に一般提供へ移した端末用のコーディングエージェントで、GitHubリポジトリのstarは約14万件ある⁴。auto modeは、その動作モードの一つで、開発元が2026年3月に設計を公開した¹。人が読んで許可を出す代わりに、分類器が個々の行動を通すか止めるかへ振り分ける。OpenAIのCodexも、サンドボックスの境界での人の承認を、別のレビュー役のエージェントに置き換える設計を採っている⁵。

Cloudflareが実装した作業単位のOAuth同意は、判断を人の手に残したまま、同意画面に載せるスコープを、いま進めようとしている作業が必要とする分だけに絞る²。同社は、同意が全部か無しかになる問題の例にMCPサーバーを挙げている。エージェントが理屈の上では全部使いうるという理由で広い権限を求めることがあるが、利用者の多くはエージェントにそこまでのアクセスを渡したくないだろう、と書いている²。

Cloudflareは、自社アカウントに対する第三者アプリ向けのOAuth基盤を2026年6月に全顧客へ開き、その2か月後に、利用者が外せるスコープ（任意スコープ）を加えた⁶。OAuthそのものは、IETFが2012年にRFC 6749として定めた仕様である⁷。Cloudflareは6月以降に数千のアプリが作られ、認可は100万回を超えたと書いている²。

auto modeが減らすのは確認のたびに立ち止まる回数そのもので、節約されるのは判断にかかる時間である。Cloudflareの同意は聞く回数を変えず、一度の同意画面で求める範囲を作業単位まで絞る。どちらが優勢かは、本稿が引く文書からは決まらない。同じ場面に両方を当てて比べた記録は、これらの文書には無い。

判断を自動化する側は、分類器に任せつつ外側にも仕組みを置く

Anthropicは、確認疲れを避ける手段はauto mode以前は二つだったと述べている¹。一つはツールを隔離する組み込みのサンドボックス(ツールが触れる範囲をあらかじめ区切っておく仕組み)で、安全ではあるが維持の手間が大きい。もう一つは確認そのものを切る--dangerously-skip-permissionsで、こちらは手間がかからない代わりに保護を何も残さない。人が一つずつ承認する運用は、この二つとは別に、確認疲れを生む元として挙げられている。開発元の実測では利用者が確認の93%をそのまま承認しており、開発元はこの数を、確認が形だけになっていることを示す指標として引いている¹。開発元は手段を並べた図で、auto modeを、自律性を高く保ちながら維持の手間を低く抑える位置を狙った設計として示している¹。

一方のサンドボックスについては、同じ開発元の別の記事が中身を書いている。置く境界は二つで、ファイルシステムの隔離、すなわち「Claudeは指定したディレクトリだけにアクセス・変更できる」ことと、ネットワークの隔離、すなわち「Claudeは承認済みのサーバーにしか接続できない」ことである⁸。両方が要る理由を、開発元は「効果のあるサンドボックスには、ファイルシステムの隔離とネットワークの隔離の両方が要る。ネットワークの隔離が無ければ、乗っ取られたエージェントはSSH鍵のような機微なファイルを持ち出せてしまう。ファイルシステムの隔離が無ければ、乗っ取られたエージェントは容易くサンドボックスの外へ逃げ、ネットワークへの到達を得てしまう」と説明している⁸。ここでの脅威モデルは、指示を受け取る側が汚染された入力に乗っ取られるプロンプトインジェクションである⁸。開発元は社内の検証として、サンドボックスが確認のプロンプトを84%減らしたとも報告している⁸。

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

利用者が設定した常時許可のパターンも原則は素通りするが、ここには例外がある。auto modeに入る時点で、包括的なシェル権限、ワイルドカード指定のスクリプト実行系、パッケージ管理ツールの実行コマンドといった、任意のコード実行を許すと分かっているルールは剥がされる¹。開発元は理由を、それらを残すと分類器が最も損害を与えうるコマンドを一度も見ないことになるためだと説明している¹。狭いルール(「コード整形ツールの実行を許可する」など)はそのまま引き継がれる。開発元はこの剥がし方自体にも留保を置いており、実際の利用実績に基づく最善努力であって、どのような一覧も必ず不完全になると書いている¹。

判断を分類器に渡す設計で、開発側は分類器の入力から二つのものを取り除いている。一つ目は、モデルが出す説明文である。その理由を「assistant textを取り除くのは、エージェントが分類器を言いくるめて悪い判断をさせられないようにするためだ」と説明している¹。二つ目は、ツールの出力である。敵対的な内容がコンテキストへ入ってくる経路はツールの出力なので、それを見ないこと自体がこの層の主たるインジェクション防御になる、と開発側は書いている¹。判断させる材料を絞ることで、判断される側が判断する側を説得する余地と、汚染された入力が判断へ届く経路の両方を減らしている。

分類器が止めた行動は、それだけでは会話を中断させない。拒否はツールの結果としてエージェントへ返され、安全な別経路を探させる¹。そのうえで、連続3回または通算20回の拒否が溜まると、auto modeはモデルを止めて判断を人へ返す。乗っ取られた、あるいは行き過ぎたエージェントが同じ結果へ繰り返し押すことへの歯止めだと開発元は書いている¹。人に返す画面の無いヘッドレス実行では、代わりにプロセスを終了する¹。

開発元は、分類器の限界も数字つきで公表している。実際のセッションから集めた、行き過ぎた行動52件に対する検証で、本来止めるべきだった行動を見逃す率は17%あったと開発元は報告している¹。開発元はこの標本について、実際のセッションで危険な行動が試みられ、それが捕捉されて分類される必要があるため小さくならざるをえない、と断っている¹。

開発元は17%の読み方も自分で条件づけている。確認そのものを切って使っていた層にとっては大幅な改善であり、一つずつ注意深く承認していた層にとっては、自分の判断を時に誤る分類器と引き換えにする以上、むしろ後退でありうる、と書いている¹。そのうえで「これは、被害の大きいインフラに対する注意深い人間のレビューの代わりにはならない」と述べている¹。

開発側の分析では、調べた見逃しの大半は、危険の見分けでは起きていない。分類器は強制プッシュや削除といった危険そのものは正しく見分けていた。外したのは、会話の中にある同意の合図がその行動まで本当に覆っているかの判定である。分類器は、利用者が承認したと読める材料（先に出ていた指示や、過去に似た行動を承認した事実）を見つけると、その材料がこの行動の影響範囲に対する同意かどうかを確かめる手前で止まる、と開発側は書いている¹。開発側はこの見逃しをプロンプトの工夫で直そうとしたが、得るもの以上の代償を払わずに済む直し方はまだ見つかっていない、と書いている¹。

それでも開発元は、分類器は完全でなくても価値があると本文で書き、その出発点を、ガードレールの無い状態より自律的な運用を大幅に安全にするだけの危険な行動を捕まえることに置いている¹。分類器の網羅とモデルの判断が良くなるにつれて安全性が上がる、という見通しも、開発元は記事の図に描いている¹。

auto modeは分類器の外側にも守りを置き、二つの層で守っている。一つはClaudeが読むものに対する層、もう一つはClaudeがすることに対する層である¹。入力側では、サーバー側のプロンプトインジェクション探査が、ファイルの読み取り、ウェブ取得、シェル出力、外部ツールの応答を、エージェントのコンテキストに入る前に走査する。乗っ取りを狙う内容に見えるときは、結果を渡す前に警告を添える¹。出力側が分類器である。開発元は、この二つの層は掛け合わさると述べている。攻撃が最後まで通るには、入力層の検知を逃れたうえで、分類器が独立に安全かつ利用者の意図に沿うと判断するツール呼び出しへ、エージェントを誘導しなければならない¹。第二層は第一層を破った内容そのものを見ていないので、両方を抜けるのはどちらか一方より格段に難しい、と開発元は述べている¹。

つまりauto modeは、判断を分類器へ渡す一方で、分類器だけに頼らない仕組みを外側に置いている。プロジェクト内の編集はバージョン管理で後から見直せ、入力層の探査は注入に警告を添え、拒否が溜まれば判断は人へ戻る¹。

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

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

これに対してCloudflareが実装したのは、OAuthクライアントを作るときに、標準のscopesと並べてoptional_scopesという配列を渡せるようにする仕組みである²。利用者は同意画面で、この任意スコープを個別に外すことができる。求められたスコープの一部だけを選んで許すこの形を、部分同意と呼ぶ。なお、クライアントが自分の設定より狭いスコープだけを要求できること自体は、この機能の前から成立していた。新しいのは、要求された集合の中を利用者がさらに削れる点である²。

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

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

この機能の前に利用者へスコープを選ばせるには、アプリ開発者が同意画面の手前に独自の選択画面を作るしかなかった、とCloudflareは書いている²。その選択は、この機能で認可基盤の同意画面へ移った。認可基盤は、OAuthの権限を発行して管理するサービスの側の仕組みを指す。

Cloudflareのこの投稿が自分たちの設計について示す限界は、数値ではなく開発者への要求という形をとる。「部分的な許可を前提に作る」と題した節を置き、開発者は認可コードを交換したあとで実際に付与されたスコープの集合を確認する必要があり、要求したスコープがすべて承認されたと仮定してはならない、と書いている²。同じ投稿は、同意画面を長いスコープの一覧に変えてしまわないことを設計目標としても挙げている²。数字つきで自分の弱さを公表しているのはAnthropicの記事のほうであり、両者の差はその点にある。

外されうるスコープを確かめる仕事はアプリの実装へ移り、一部は基盤側が引き受ける

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

Googleの文書は、この移った先の仕事を「あなたのアプリは、利用者がどのスコープを許可したかを常に確認し、スコープが拒否された場合はそれに応じた機能を無効にすべきである」と述べている³。同じ文書は正しい実装と誤った実装を対比し、誤った実装を「利用者がどのスコープを許可したかを確認せず、利用者がすべてのスコープを許可したと仮定している」と説明する³。具体的には、認可の応答でトークンを受け取った時点で付与されたスコープを確かめ(tokens.scope.includes(...)のような形)、使えない機能は無効化する³。必要になった時点でスコープを求める段階的な認可も、文書は推奨の手順として挙げている³。同意画面で一度に聞かなかった分の判断は、アプリの側へ移っている。

Slackは以前の姿を「利用者はアプリが求めるすべてのスコープを受け入れるか、立ち去るかのどちらかだった」と述べ、それが「インストールの離脱の増加。信頼の低下。利用者の減少」を生んでいたとする⁹。

同じ文書は、任意スコープを導入した後にアプリが移った先の仕事を怠った場合の代償も書いている。Slackは開発側へ「あなたのアプリは、利用者がそれらを許可しない場合に備えておく必要がある」と注意する。機能に要る任意スコープが、保存しておいた付与済みスコープの一覧に在るかを機能を出す前に確かめずにいると、利用者は「作業の途中で壁にぶつかる」ことになる。文書は、そのエラーを明示的に捕まえて穏やかに応じよと書き、壊れた体験の代わりに出すものとして、たとえば「その機能に何が必要で、どうすれば有効にできるかを説明する案内」を挙げている⁹。この文書がもっとも強く書いているのは、こうした手当てを怠るアプリは「仕組み全体の意図を台無しにする」という一文である⁹。

三つの文書は、開発元も対象のプロダクトも違う。いずれも自分の認可基盤で同じ設計を提供する側が、その上でアプリを作る開発者へ向けて書いたものである。それでも移った先の仕事は、付与されたスコープを確かめるという一点で揃っている。そのうえでGoogleは拒否された分の機能を無効にせよと書き、Slackはさらに、その機能に何が必要かを説明する案内を出す例を挙げている³⁹。

ただしSlackは、この仕事をアプリ側が必ず全部負うとは書いていない。Slack MCP Serverを使って作る場合は一部が最初から組み込まれており、トークンが権限を持つツールしか公開されないので、エージェントはそもそも権限の無い操作を試みない。多くの場合、手作業でのスコープ処理の必要は減る、と述べている⁹。移り先もアプリだけではない。組織の承認工程が入る場合は、利用者が選べる任意スコープの上位集合を管理者が先に決める⁹。同意画面を軽くした分の仕事は、アプリの実装と、その手前の承認工程へ移る。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。