Wrangler と Cloudflare API MCP server が任意 OAuth スコープに対応 — エージェントに渡す権限を認可の時点で削れるようになった

要約

Cloudflare が 2026-08-22 の changelog で、Wrangler CLI と Cloudflare API MCP server の OAuth 認可に「任意スコープ（optional scopes）」を導入したと発表しました。認可時の同意画面に権限を編集する導線が追加され、クライアントが要求するスコープのうち任意のものを個別にオン / オフできます。

これまでは、各クライアントが要求するスコープをまとめて承認するしかありませんでした。つまり「そのツールが求める全権限を渡すか、そのツールを使わないか」の二択です。今回の変更で、その中間が生まれました。必須スコープは選択されたまま外せませんが、任意スコープは自分のワークフローに必要な分だけに絞れます。

見た目は同意画面の UI 変更です。ただ、changelog のタグが Agents と Workers になっている点、そして対象に Cloudflare API MCP server が含まれている点を合わせて読むと、意味が変わってきます。MCP server は AI エージェントが Cloudflare のアカウントを操作するための入口です。そこに渡す権限を、人間が認可の時点で削れるようになったというのが本件の実質です。

運用面の設計も公式に示されています。付与しなかったスコープが必要なコマンドやツール呼び出しに当たった場合は、クライアントを再認可してそのスコープを付与する。これは「最小で始めて、詰まったら足す」という進め方が公式に想定されているということです。事前に必要な権限を完全に洗い出してから認可する必要はありません。

なお、どのスコープが必須でどれが任意なのかという一覧は、changelog 本文には掲載されていません。公式は参照先として wrangler login のドキュメントと「Edit optional permissions」を挙げています。実際のスコープ構成は認可時の同意画面で確認することになります。

何が変わったか

• Wrangler CLI と Cloudflare API MCP server の OAuth 認可が、任意スコープに対応
• 認可時の同意画面に、付与する権限を編集する導線が追加された
• 任意スコープは個別にオン / オフできる。必須スコープは選択が固定され外せない
• 任意スコープを絞ると、そのツールがアクセスできる範囲が絞られる
• 付与しなかったスコープが必要になった場合は、クライアントを再認可して個別に追加する
• 対象は changelog のタグ上 Agents と Workers の2製品
• スコープ名の具体的な一覧は changelog に記載がない（同意画面および wrangler login のドキュメント側）

業務インパクト（一般企業向け）

エージェントに本番インフラを触らせる構成を検討している組織にとって、これは判断材料が1つ増えた変更です。 MCP server 経由で Cloudflare のアカウントを操作させる場合、これまでは要求される全権限を渡すことが前提でした。読み取りだけさせたいのに、設定変更や削除の権限まで一緒に付いてくる。この構造が理由で導入を見送っていた組織は少なくないはずです。任意スコープが入ったことで、「渡せる範囲まで渡して使う」という選択肢が生まれました。

まず決めるべきは、誰が同意画面を操作するかです。 任意スコープは認可する人間が選びます。開発者が自分の判断で全部オンにすれば、変更前と何も変わりません。権限を絞れる機能は、絞る運用を決めて初めて意味を持ちます。 具体的には、Cloudflare アカウントに対する MCP 接続を誰が認可してよいか、どのスコープを標準で外すか、例外を認める場合の承認経路はどうするか。この3点を先に決めてから展開してください。

再認可の運用も設計に含めてください。 「足りなくなったら再認可する」は、裏を返せば作業の途中で認可フローに戻されるということです。開発者が急いでいるときに再認可を求められれば、次からは最初に全部オンにするようになります。これを防ぐには、よく使う操作に必要なスコープの組み合わせを社内で標準化し、「この用途ならこのセット」と示せる状態にしておくことです。最小権限は、都度考えさせると必ず形骸化します。

監査の観点では、認可時点の記録が残るかどうかを確認しておく価値があります。 どのクライアントにどのスコープを渡したかは、インシデント時に真っ先に確認する情報です。MCP クライアントは開発者のローカル環境で動くことが多く、組織側から見えにくい領域でもあります。認可の判断をローカルに閉じたままにしないための記録の残し方を、あわせて決めておいてください。

この変更は Cloudflare 固有ですが、構図としては他のベンダーにも波及していく話です。 エージェントに API を触らせる需要が増えれば、「全権限を渡すか使わないか」の二択はどこでも問題になります。今のうちに権限設計の考え方を社内で作っておくと、次に別のツールで同じ選択を迫られたときに使い回せます。

副業・個人活用視点

Cloudflare を使った開発や運用を請けている立場なら、これは提案材料になります。 クライアントの環境に MCP 接続を持ち込むとき、「必要な権限だけを渡す構成にできます」と言えるかどうかで、話の通りやすさが変わります。特に、情シスが AI エージェントの導入に慎重な組織では、権限を絞れること自体が導入可否の分かれ目になります。

個人で Wrangler を使っている場合も、認可を一度やり直す価値はあります。 これまでに認可したクライアントは、当時の仕様で全スコープを持ったままです。今の自分のワークフローに必要な範囲を確認して、再認可で絞り直しておくと、ローカル環境が侵害されたときの被害範囲が変わります。手元の作業だから、で済ませない方がよい領域です。

研修や教材の題材としても使いやすい変更です。 「最小権限の原則」は概念としては誰でも知っていますが、実際に手を動かして体験する機会は多くありません。同意画面でスコープを絞り、足りなくなって再認可する。この一往復を実際にやってみると、最小権限が理想論ではなく運用コストとのトレードオフであることが体感できます。MCP やエージェント運用の研修を組む場合、実機で試せる題材として組み込む価値があります。

MCP まわりの権限設計を語れること自体が、当面は差別化になります。 エージェントに何をさせるかの議論は多いのに、何をさせないかの議論は追いついていません。Cloudflare のこの変更のように、ベンダー側が権限を細かく切れる仕組みを出し始めた今が、「権限をどう設計するか」を提案の軸に据えるタイミングです。