AIエージェント

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

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

🤖 AIを使用して執筆

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

AIエージェントが広がるほど、確認を求める場面も増える。二つの実在の設計は、この同じ問題を逆方向から解いている。

Claude Codeのauto modeは、確認するかどうかの判断そのものを自動化する²。Claude Codeは、Anthropicが2025年2月に研究プレビューとして公開し同年5月に一般提供へ移した端末用のコーディングエージェントで、GitHubリポジトリのstarは約14万件ある⁶。auto modeは、その動作モードの一つで、開発元が2026年3月に設計を公開した²。人が読んで許可を出す代わりに、分類器が個々の行動を通すか止めるかへ振り分ける。判断を代行させる設計である。

Cloudflareが実装した作業単位のOAuth同意は、逆に判断を人の手に残したまま、聞く範囲を切り詰める⁴。同社は、同意が全部か無しかになる問題の例にMCPサーバーを挙げている。エージェントが理屈の上では全部使いうるという理由で広い権限を求めることがあるが、利用者の多くはエージェントにそこまでのアクセスを渡したくないだろう、と書いている⁴。OAuthそのものは、IETFが2012年にRFC 6749として定めた仕様である⁷。Cloudflareは、自社アカウントに対する第三者アプリ向けのOAuth基盤を2026年6月に全顧客へ開いており、任意スコープはその2か月後に加わった機能である⁸。同社は6月以降に数千のアプリが作られ、認可は100万回を超えたと書いている⁴。利用者は画面を見て選ぶが、その画面に載る選択肢は、いま進めようとしている作業が必要とする分だけである。

前者が減らすのは確認のたびに立ち止まる回数そのもので、節約されるのは判断にかかる時間である。後者が減らすのは回数ではなく、一度の同意画面で求める範囲で、それを作業単位まで絞る。どちらが主になるかは、本稿が引く文書からは決まらない。二つは確認の別の部分を削っており、同じ場面に両方を当てて比べた記録は、これらの文書には無い。

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

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は書いている⁴。その選択は、この機能で基盤の同意画面へ移った。

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

刻んだ分はアプリの実装へ移り、一部は基盤側が引き受ける

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

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

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

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

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

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