CloudflareがセルフマネージドOAuthを全開発者へ開放 — APIトークンの時代が終わり、AIエージェント連携の標準基盤になる理由
はじめに
2026年6月3日、Cloudflareは「セルフマネージドOAuth」をすべての開発者に公開しました。これまで一部の認定パートナーだけに許されていたOAuth連携が、どのCloudflareアカウントでも申請不要で使えるようになったという発表です。一見すると地味なアップデートに見えますが、その本質は「APIトークンに依存してきた連携の作法を、AIエージェント時代にふさわしい委譲アクセス（delegated access）へ刷新する」ことにあります。この記事では、何が変わったのか、なぜAIエージェント・MCPの文脈で重要なのか、そして開発者が実際にどう使うのかをエンジニア視点で掘り下げます。
何が公開されたのか — パートナー限定の終わり
これまでCloudflareでOAuthによる委譲アクセスを提供できたのは、Cloudflareが手動で承認した一握りの統合パートナー（WranglerやPlanetScaleなど）に限られていました。それ以外の開発者は、ユーザーに手作業でAPIトークンを発行してもらい、それを預かるしかありませんでした。
今回の変更で、誰でもダッシュボードの「Manage account > OAuth clients」から自前のOAuthアプリケーションを登録できるようになります。アプリは「private（自アカウント内のみ）」と「public（ドメイン所有者として検証済みなら第三者にも公開）」を選べ、付与できるスコープは既存のAPIトークンの権限体系に対応します。つまり、ユーザーがCloudflareアカウントへのアクセスを「同意画面」を通じて、必要な範囲だけ許可できるようになったわけです。
ここがAPIトークンとの決定的な違いです。byteiotaの分析が端的に指摘しているように、「APIトークンは同意画面なしに認証情報を丸ごと渡してしまう。ユーザーはそのアプリが何をしようとしているのか見えない」。OAuthであれば、要求されている権限が明示され、ダッシュボードからいつでも失効（revoke）でき、どのアプリがアクセスしているかを所有者が把握できます。OAuthフィッシング対策として同意体験そのものも刷新されました。
技術的な背景 — 1.3億行の無停止マイグレーション
この開放の裏側には、認可基盤の大規模な作り替えがありました。CloudflareはOAuthエンジンとしてオープンソースの「Ory Hydra」を数年前から運用していますが、利用規模の拡大に伴い1.X系から2.X系へのアップグレードが必要になりました。
最大の難所はデータベース移行です。Hydra 1.X系はスキーマ変更時にテーブルの排他ロックを取得してしまい、その間ユーザー操作が止まる設計でした。Cloudflareは CREATE INDEX CONCURRENTLY を使うなど標準SQLを書き換え、SELECT * を明示的なカラム選択に変えることでデシリアライズ問題も解消。1億3,250万行のデータをブルーグリーン方式で無停止移行しました。
無停止を成立させた工夫も学びが多い箇所です。アップグレード中の新規トークン発行を減らすためトークン有効期限を一時的に延長し、移行中に発生する失効イベントはCloudflare Queuesに退避して後から再生。Wranglerなどのクライアントからのリフレッシュトークンリクエストはキャッシュしてコアレッシング（合体）し、リトライによる無効化を防ぎました。副産物としてAPIのP95レイテンシは185ms→101ms（約45%改善）、CPU使用率は37%減という性能向上も得ています。「認可は止められない基盤」という前提でゼロダウンタイムを設計しきった点が、本番運用の参考になります。
エンジニアへの影響 — MCPとAIエージェント連携の本命
2026年の文脈で最も重要なのは、AIエージェントとMCP（Model Context Protocol）サーバーが「ちゃんとした委譲アクセスモデル」を手に入れたことです。エージェントがユーザーのCloudflareアカウントを操作する際、共有のサービストークンを使い回すのではなく、ユーザーがスコープを限定して同意したOAuthトークンで動けるようになります。これはエージェント自動化におけるセキュリティの基本部品です。
ここで混同しやすいので整理すると、関連するピースは3つあります。
- セルフマネージドOAuth（今回の発表）: 自分のアプリが「Cloudflareの API を呼ぶ側」になるためのもの。
- workers-oauth-provider ライブラリ: 逆に、自分が「OAuthプロバイダになる側」のためのもの。Cloudflare Workers上でOAuth 2.1（PKCE対応）プロバイダを実装するTypeScriptライブラリで、
parseAuthRequest()/lookupClient()/completeAuthorization()といったAPIを提供します。MCPサーバーをWorkersで建てる際、このライブラリが認可フロー全体を肩代わりし、開発者はAPIハンドラと認証ロジックだけを書けば済みます。機密情報はハッシュのみ保存、propsはトークンで暗号化されるため、ストレージ全漏洩時もシークレットが守られる設計です。 - Managed OAuth for Access: 社内アプリをワンクリックでエージェント対応にする別系統の機能。
実務的な指針はシンプルです。個人の自動化やCIで自分のアカウントを叩くだけならAPIトークンで十分。第三者やAIエージェントにアクセスを委譲させたいなら、OAuthへ移行する。リモートMCPサーバーを公開するなら workers-oauth-provider が最短ルート、という棲み分けになります。
まとめ
- CloudflareがセルフマネージドOAuthを全アカウントに開放し、パートナー承認の壁がなくなった。
- APIトークンと違い、同意画面・スコープ限定・失効管理が標準で備わり、セキュリティとUXが向上する。
- 裏側では1.3億行の無停止マイグレーションがあり、ゼロダウンタイム設計の好例になっている。
- AIエージェント／MCPにとっては「正しい委譲アクセス」を実現する本命の基盤であり、workers-oauth-providerと組み合わせるとWorkers上でMCPサーバーを安全に公開できる。
APIトークンの「全権委任」から、OAuthの「最小権限＋同意」へ。AIエージェントが人のアカウントを代理操作する場面が当たり前になる2026年において、この移行はもはやセキュリティの必須要件になりつつあります。