Cloudflareはすべての開発者に対して自己管理型OAuthを開放し、手動審査による参加を不要にすると発表した。背景には、AIエージェントツール（AI Agent）による認可委任需要の爆発的増加と、1.3億件のデータ行移行を伴う基盤エンジンの世代交代がある。 （前情提要：Cloudflareのデータ：インターネット上のトラフィックの34%は人間ではなく、AIクローラーは8倍の速度で成長中） （背景補足：UBS、TD Cowenが同日にArmの目標株価を475ドルに引き上げ、理由は自社開発CPUによる将来収益）
本文目次
Toggle
世界のインターネットトラフィックの20%を管理するCloudflareは、今週、重要な決定を下した。すべての開発者が自らOAuthクライアントを作成・管理できるようにし、個別の手動審査による登録を不要にしたのだ。この背後には、AIエージェントツールによる「委任認可」への膨大な需要がある。AIモデルがユーザーに代わってCloudflareリソースにアクセスする必要がある場合、これまではAPIトークンに依存せざるを得なかったが、この方法は管理が難しく、明確な同意範囲を必要とするエージェントワークフローには適していない。
CloudflareはOAuthの初心者ではない。開発者がWrangler CLIツールを使用したり、PlanetScaleなどのパートナーサービスと連携する際、OAuthはすでにバックグラウンドで静かに動作していた。しかし、これらの統合はすべて「手動登録」のクローズドなモードであり、サードパーティの開発者は標準的なOAuthフローを自ら構築することができなかった。
Cloudflareは公式ブログで、過去1年間にわたって初期のパートナーを段階的に導入し、同意メカニズム、取り消しプロセス、セキュリティモデルを継続的に改善してきたと述べている。しかし、開発者プラットフォームの規模拡大と、AIエージェントツールによる委任アクセス需要の急増に伴い、「すべてのユーザーへのOAuth開放」はプラットフォーム成功のための必須条件となり、選択肢ではなくなった。
自己管理型OAuthにより、開発者は標準的な認可フローを提供できる。ユーザーは直接スコープ制限付きのアクセス権を付与し、アプリケーションは自分が何を許可されているかを把握でき、ユーザーはいつでも取り消すことができる。これは、SaaS統合、内部開発者プラットフォーム、およびあらゆる種類のAIエージェントツールを構築する上で、APIトークンよりもクリーンな基盤アーキテクチャとなる。
しかし、OAuthをスケーラブルに開放するためには、Cloudflareはまずエンジニアリング上の問題を解決しなければならなかった。基盤となる認可エンジンHydraが耐えられなくなっていたのだ。
HydraはオープンソースのOAuthエンジンであり、Cloudflareは数年前にこれを導入してプラットフォームのOAuthインフラを支えていた。使用量が限られていた時期には安定して動作していたが、開発者プラットフォームの拡大とAIワークフローの普及により、オリジナルのHydraではパフォーマンスのボトルネックと機能制限が顕著になってきた。
アップグレード計画は2つのフェーズに分けて実施された。第1フェーズはHydra 1.Xバージョンへのアップグレードで、エンジニアはマイナーバージョンの移行であってもデータベースの構造変更の規模が侮れないことを発見した。彼らはSQL移行スクリプトを書き直し、CREATE INDEX CONCURRENTLYなどの書き込みをロックしない技術を採用し、Hydraのビルドバージョンをカスタマイズして、従来のSELECT *クエリを明示的なフィールド指定に置き換え、不要なデータ転送を削減した。
第2フェーズはHydra 2.Xへのブルーグリーンデプロイメントである。ブルーグリーンデプロイメントとは、新旧両方のシステムを同時に稼働させ、トラフィックは新しいシステムの安定が確認された後に段階的に切り替え、いつでも即座にロールバックできるようにすることで、システム停止のリスクをほぼゼロに抑える手法だ。Cloudflareは、このフレームワークの下で、Cloudflare Queuesに基づくキューシステムを構築し、取り消しイベントを新旧システム間で正しく同期できるようにしたと述べている。
データベース移行全体の規模は相当なものだった。合計1.325億件のデータ行を更新し、1.147億件の新しいデータ行を挿入し、136.97 GBの一時データを生成した。
ブルーグリーン切り替え完了後、監視データに予期しないシグナルが現れた。refresh tokenのエラー率が上昇したのだ。
原因を調査したところ、新しいバージョンのHydraではrefresh tokenの再利用に対してより厳格な無効化メカニズムが採用されており、同じrefresh tokenの再利用が検出されると、アクセストークンとrefresh tokenのセット全体が一緒に取り消されることが判明した。
これはWranglerやMCPクライアントにとって問題となった。なぜなら、これらのツールはネットワークが不安定な状況や同時リクエストが発生するシナリオで、refresh tokenの再利用を引き起こす可能性があったからだ。
解決策は、OAuthトラフィックをルーティングするWorkerに「refresh token統合メカニズム」を追加することだった。同一トークンに対する複数の更新リクエストが同時に流入した場合、システムはそれらを単一のリクエストに統合して処理し、連鎖無効化ロジックがトリガーされるのを防ぐ。この修正により、MCPクライアントの統合動作は正常な状態に戻った。
このエピソードは、AIエージェントツールの認可行動パターンが、従来の手動操作によるOAuthフローとは構造的に異なるという現実を明らかにした。エージェントツールは短時間に大量の同時トークン更新リクエストを発行する可能性があり、従来のOAuth実装はこのような使用シナリオ向けに設計されていない。
アップグレード完了後、各パフォーマンス指標の改善幅は顕著だった。API P95レイテンシは185ミリ秒から101ミリ秒に低下し、45%の削減。メモリ常駐使用量は888MBから763MBに減少し、14%削減。Goヒープメモリ割り当ては449MBから271MBに減少し、40%削減。Goroutine数は4,015から3,076に減少し、23%削減。CPU使用量は1.07コアから0.67コアに減少し、37%の節約となった。
Cloudflareは、自己管理型OAuthの開放により、開発者はユーザーの同意範囲がより透明で、取り消しが容易な統合ソリューションを構築できるようになり、これはAIエージェントツールのエコシステムの健全性にとって特に重要であると述べている。AIモデルが人間に代わってサービスを操作する場合、「このエージェントは何をする権限があるのか」と「そのアクセスをどのように取り消すのか」は、トラストフレームワークにおいて避けられない問題となる。
1.53M 人気度
35.28K 人気度
63.43K 人気度
317.54K 人気度
521.65K 人気度
Cloudflare が OAuth の全面的な制限解除を発表、AI Agent 開発者は手動審査が不要に
Cloudflareはすべての開発者に対して自己管理型OAuthを開放し、手動審査による参加を不要にすると発表した。背景には、AIエージェントツール（AI Agent）による認可委任需要の爆発的増加と、1.3億件のデータ行移行を伴う基盤エンジンの世代交代がある。
（前情提要：Cloudflareのデータ：インターネット上のトラフィックの34%は人間ではなく、AIクローラーは8倍の速度で成長中）
（背景補足：UBS、TD Cowenが同日にArmの目標株価を475ドルに引き上げ、理由は自社開発CPUによる将来収益）
本文目次
Toggle
世界のインターネットトラフィックの20%を管理するCloudflareは、今週、重要な決定を下した。すべての開発者が自らOAuthクライアントを作成・管理できるようにし、個別の手動審査による登録を不要にしたのだ。この背後には、AIエージェントツールによる「委任認可」への膨大な需要がある。AIモデルがユーザーに代わってCloudflareリソースにアクセスする必要がある場合、これまではAPIトークンに依存せざるを得なかったが、この方法は管理が難しく、明確な同意範囲を必要とするエージェントワークフローには適していない。
なぜ今開放するのか？
CloudflareはOAuthの初心者ではない。開発者がWrangler CLIツールを使用したり、PlanetScaleなどのパートナーサービスと連携する際、OAuthはすでにバックグラウンドで静かに動作していた。しかし、これらの統合はすべて「手動登録」のクローズドなモードであり、サードパーティの開発者は標準的なOAuthフローを自ら構築することができなかった。
Cloudflareは公式ブログで、過去1年間にわたって初期のパートナーを段階的に導入し、同意メカニズム、取り消しプロセス、セキュリティモデルを継続的に改善してきたと述べている。しかし、開発者プラットフォームの規模拡大と、AIエージェントツールによる委任アクセス需要の急増に伴い、「すべてのユーザーへのOAuth開放」はプラットフォーム成功のための必須条件となり、選択肢ではなくなった。
自己管理型OAuthにより、開発者は標準的な認可フローを提供できる。ユーザーは直接スコープ制限付きのアクセス権を付与し、アプリケーションは自分が何を許可されているかを把握でき、ユーザーはいつでも取り消すことができる。これは、SaaS統合、内部開発者プラットフォーム、およびあらゆる種類のAIエージェントツールを構築する上で、APIトークンよりもクリーンな基盤アーキテクチャとなる。
1.3億件のデータ行を伴う基盤エンジンの置き換え
しかし、OAuthをスケーラブルに開放するためには、Cloudflareはまずエンジニアリング上の問題を解決しなければならなかった。基盤となる認可エンジンHydraが耐えられなくなっていたのだ。
HydraはオープンソースのOAuthエンジンであり、Cloudflareは数年前にこれを導入してプラットフォームのOAuthインフラを支えていた。使用量が限られていた時期には安定して動作していたが、開発者プラットフォームの拡大とAIワークフローの普及により、オリジナルのHydraではパフォーマンスのボトルネックと機能制限が顕著になってきた。
アップグレード計画は2つのフェーズに分けて実施された。第1フェーズはHydra 1.Xバージョンへのアップグレードで、エンジニアはマイナーバージョンの移行であってもデータベースの構造変更の規模が侮れないことを発見した。彼らはSQL移行スクリプトを書き直し、CREATE INDEX CONCURRENTLYなどの書き込みをロックしない技術を採用し、Hydraのビルドバージョンをカスタマイズして、従来のSELECT *クエリを明示的なフィールド指定に置き換え、不要なデータ転送を削減した。
第2フェーズはHydra 2.Xへのブルーグリーンデプロイメントである。ブルーグリーンデプロイメントとは、新旧両方のシステムを同時に稼働させ、トラフィックは新しいシステムの安定が確認された後に段階的に切り替え、いつでも即座にロールバックできるようにすることで、システム停止のリスクをほぼゼロに抑える手法だ。Cloudflareは、このフレームワークの下で、Cloudflare Queuesに基づくキューシステムを構築し、取り消しイベントを新旧システム間で正しく同期できるようにしたと述べている。
データベース移行全体の規模は相当なものだった。合計1.325億件のデータ行を更新し、1.147億件の新しいデータ行を挿入し、136.97 GBの一時データを生成した。
MCPクライアントにおけるrefresh tokenの連鎖無効化問題
ブルーグリーン切り替え完了後、監視データに予期しないシグナルが現れた。refresh tokenのエラー率が上昇したのだ。
原因を調査したところ、新しいバージョンのHydraではrefresh tokenの再利用に対してより厳格な無効化メカニズムが採用されており、同じrefresh tokenの再利用が検出されると、アクセストークンとrefresh tokenのセット全体が一緒に取り消されることが判明した。
これはWranglerやMCPクライアントにとって問題となった。なぜなら、これらのツールはネットワークが不安定な状況や同時リクエストが発生するシナリオで、refresh tokenの再利用を引き起こす可能性があったからだ。
解決策は、OAuthトラフィックをルーティングするWorkerに「refresh token統合メカニズム」を追加することだった。同一トークンに対する複数の更新リクエストが同時に流入した場合、システムはそれらを単一のリクエストに統合して処理し、連鎖無効化ロジックがトリガーされるのを防ぐ。この修正により、MCPクライアントの統合動作は正常な状態に戻った。
このエピソードは、AIエージェントツールの認可行動パターンが、従来の手動操作によるOAuthフローとは構造的に異なるという現実を明らかにした。エージェントツールは短時間に大量の同時トークン更新リクエストを発行する可能性があり、従来のOAuth実装はこのような使用シナリオ向けに設計されていない。
アップグレード完了後、各パフォーマンス指標の改善幅は顕著だった。API P95レイテンシは185ミリ秒から101ミリ秒に低下し、45%の削減。メモリ常駐使用量は888MBから763MBに減少し、14%削減。Goヒープメモリ割り当ては449MBから271MBに減少し、40%削減。Goroutine数は4,015から3,076に減少し、23%削減。CPU使用量は1.07コアから0.67コアに減少し、37%の節約となった。
Cloudflareは、自己管理型OAuthの開放により、開発者はユーザーの同意範囲がより透明で、取り消しが容易な統合ソリューションを構築できるようになり、これはAIエージェントツールのエコシステムの健全性にとって特に重要であると述べている。AIモデルが人間に代わってサービスを操作する場合、「このエージェントは何をする権限があるのか」と「そのアクセスをどのように取り消すのか」は、トラストフレームワークにおいて避けられない問題となる。