2026年4月14日 Eduardo Gomes James Royal Ann Ming Samborski 8分で読める
Cloudflareには数千の内部アプリがあります。自分たちで構築したものもあれば、他の企業が構築したソフトウェアの自己ホスト型インスタンスもあります。ほぼすべての人が使用するビジネスクリティカルなアプリから、サイドプロジェクトやプロトタイプまで様々です。これらのアプリはすべてCloudflare Accessで保護されています。しかし、エージェントの使用と構築を開始した時、特にコード作成以外の用途では、壁にぶつかりました。ユーザーはAccessの背後にあるアプリにアクセスできましたが、エージェントはできませんでした。
問題: エージェントはAccessの背後にアクセスできない
Accessは内部アプリの前に配置されます。ポリシーを定義すると、Accessは認証されていないユーザーをログインページに送信して、認証方法を選択させます。
このフローは人間にとっては素晴らしく機能しました。しかし、エージェントが見ることができたのは、対応できないログインページへのリダイレクトだけでした。
一時的な解決策
内部アプリデータへのアクセスをエージェントに提供することは非常に重要だったため、私たちは自社の内部使用のために即座に応急処置を実装しました。OpenCodeのウェブフェッチツールを変更して、特定のドメインに対してcloudflared CLIをトリガーして、JWT(JSON Web Token)を取得するための認可フローを開きました。このトークンをリクエストに追加することで、内部エコシステムへの安全で即座なアクセスを実現しました。
本格的な解決策: マネージドOAuth
この一時的な解決策は私たち自身のジレンマへの答えでしたが、今日、この回避策を廃止し、すべての人のためにこの問題を修正しています。
オープンベータで利用可能になった、すべてのAccessアプリケーションはマネージドOAuthをサポートしています。Accessアプリに対してワンクリックで有効にすると、OAuth 2.0に対応したエージェントは認証方法を簡単に発見でき(RFC 9728)、ユーザーを認可フローに送信し、認可トークン(初期ソリューションと同じJWT)を受け取ることができます。
これで、フローは人間とエージェントの両方でスムーズに機能します。
Cloudflare Accessは寛大な無料ティアを提供しています。また、新しく導入されたOrganizationsベータを活用することで、Cloudflareアカウント全体でアイデンティティプロバイダーをブリッジできるようになります。
マネージドOAuthの仕組み
Cloudflare Accessで保護された特定の内部アプリに対して、マネージドOAuthをワンクリックで有効にします。
マネージドOAuthが有効になると、Cloudflare Accessは認可サーバーとして機能します。www-authenticateヘッダーを返し、認可されていないエージェントに認可トークンを取得する方法に関する情報をどこで検索するかを指示します。エージェントはhttps://<your-app-domain>/.well-known/oauth-authorization-serverでこれを見つけます。
この指示を備えたエージェントは、OAuth標準に従うことができます:
- エージェントは自身をクライアントとして動的に登録します(Dynamic Client Registration — RFC 7591)
- エージェントはPKCE(Proof Key for Code Exchange)認可フロー(RFC 7636)を通じてユーザーを送信します
- ユーザーがアクセスを承認すると、エージェントがユーザーに代わって認証されたリクエストを行うために使用できるトークンが付与されます
認可フローは以下のようになります:
この認可フローに見覚えがあれば、それはModel Context Protocol(MCP)が使用するものだからです。私たちは元々、MCPサーバーポータル製品にこのサポートを構築しました。これは多くのMCPサーバーへのアクセスをプロキシして制御し、ポータルがOAuthサーバーとして機能できるようにします。今、私たちはこれをすべてのAccessアプリに提供しているため、エージェントは認可が必要なMCPサーバーだけでなく、ウェブページ、ウェブアプリ、REST APIにもアクセスできます。
内部アプリを大規模にエージェント対応にアップグレード
内部ソフトウェアの長い尾部をエージェントと連携するようにアップグレードすることは、困難な作業です。原則として、エージェント対応にするために、すべての内部および外部アプリは理想的には発見可能なAPI、CLI、よく作られたMCPサーバー、および多くの新興エージェント標準を採用する必要があります。AI採用は、すべてが改造されるのを待つことはできません。ほとんどの組織は、多くの年にわたって構築されたアプリの大きなバックログを持っています。多くの内部「アプリ」は、エージェントによって単純なウェブサイトとして扱われるときに素晴らしく機能します。
内部ウィキのようなものの場合、必要なのはMarkdown for Agentsを有効にし、マネージドOAuthをオンにするだけで、エージェントは保護されたコンテンツを読むために必要なものを持っています。
最も広いセットの内部アプリケーション全体で基本を機能させるために、マネージドOAuthを使用します。Accessを内部レガシーアプリの前に配置することで、エージェント対応を即座に実現します。コード変更なし、改造なし。代わりに、即座の互換性です。
ユーザーのエージェント。サービスアカウントとトークンは不要
エージェントは組織内のユーザーに代わって行動する必要があります。私たちが見た最大のアンチパターンの1つは、人々がエージェントとMCPサーバーのためにサービスアカウントをプロビジョニングし、静的認証情報を使用して認証することです。これらは単純なユースケースと迅速なプロトタイプに適しており、Cloudflare Accessはこの目的のためにサービストークンをサポートしています。しかし、サービスアカウントアプローチは、きめ細かいアクセス制御と監査ログが必要な場合、すぐに限界を示します。
エージェントが実行するすべてのアクションは、それを開始した人間に簡単に帰属可能である必要があり、エージェントはその人間のオペレーターが同様に認可されているアクションのみを実行できる必要があると考えています。サービスアカウントと静的認証情報は、帰属が失われるポイントになります。すべてのアクションをサービスアカウント経由で処理するエージェントは、混乱した代理人の問題の影響を受けやすく、監査ログがエージェント自体から発信されているように見えます。
セキュリティと説明責任のために、エージェントはこのユーザー-エージェント関係を表現できるセキュリティプリミティブを使用する必要があります。OAuthは、第三者へのアクセスをリクエストして委譲するための業界標準プロトコルです。これにより、エージェントはユーザーに代わってAPIと通信する方法を提供し、ユーザーのアイデンティティにスコープされたトークンを使用して、アクセス制御が正しく適用され、監査ログがエンドユーザーにアクションを正しく帰属させることができます。
標準の勝利: エージェントがウェブフェッチツールでRFC 9728をどのように採用できるか、そして採用すべきか
RFC 9728は、エージェントが認証する場所と方法を発見することを可能にするOAuth標準です。この情報がどこに存在し、どのように構造化されているかを標準化します。このRFCは2025年4月に公式になり、Model Context Protocol(MCP)によってすぐに採用されました。MCPは現在、MCPサーバーとクライアントの両方がそれをサポートすることを要求しています。
しかし、MCP以外では、エージェントはさらに本質的なユースケースのためにRFC 9728を採用すべきです: OAuthの背後で保護されているウェブページへのリクエストを行い、プレーンなREST APIへのリクエストを行うこと。
ほとんどのエージェントは、ウェブページへの基本的なHTTPリクエストを行うためのツールを持っています。これは一般的に「ウェブフェッチ」ツールと呼ばれています。JavaScriptのfetch() APIの使用に似ていますが、レスポンスに対する追加の後処理があります。これにより、URLをエージェントに貼り付けて、エージェントにコンテンツを検索させることができます。
今日、ほとんどのエージェントのウェブフェッチツールはURLが返すwww-authenticateヘッダーで何もしません。基礎となるモデルは、レスポンスヘッダーを内省して、これを自分で理解することを選択するかもしれませんが、ツール自体はwww-authenticateに従わず、/.well-known/oauth-authorization-serverを検索し、OAuthフローのクライアントとして機能しません。
しかし、できます。そして、私たちはそうすべきだと強く信じています!
エージェントは既にこれを行ってリモートMCPクライアントとして機能します。これを実証するために、Opencodeのウェブフェッチツールを適応させるドラフトプルリクエストを作成しました。これはこれを実行中に示しています。
リクエストを行う前に、適応されたツールは最初に既に認証情報を持っているかどうかをチェックします。持っている場合は、それらを使用して初期リクエストを行います。ツールがwww-authenticateヘッダー付きの401または403を取得した場合、サーバーのOAuthフローを通じて送信することに同意するようユーザーに求めます。
OAuthフローの仕組みは以下の通りです。
OAuthで保護され、RFC 9728に準拠しているURLをエージェントに提供する場合、エージェントは認可フローを開くことに同意するよう人間に促します:
...人間をログインページに送信します:
...その後、人間にエージェントへのアクセスを許可するよう促す同意ダイアログに送信します:
人間がエージェントへのアクセスを許可すると、エージェントは受け取ったトークンを使用して認証されたリクエストを行います:
CodexからClaude CodeからGooseなど、すべてのエージェントはこれを実装でき、Cloudflareに固有のものは何もありません。すべてOAuth標準を使用して構築されています。
このフローは強力であり、RFC 9728のサポートは基本的なウェブフェッチリクエスト以上のエージェントを支援できると考えています。REST APIがRFC 9728をサポートしている場合(エージェントも同様)、エージェントは認証されたリクエストをそのAPIに対して行い始めるために必要なすべてを持っています。REST APIがRFC 9727をサポートしている場合、クライアントはREST APIエンドポイントのカタログを自分で発見でき、追加のドキュメント、エージェントスキル、MCPサーバー、またはCLIなしでさらに多くのことを行うことができます。
これらはそれぞれエージェントで重要な役割を果たします — Cloudflare自体はCloudflare API用のMCPサーバー(Code Modeを使用して構築)、Wrangler CLI、Agent Skills、およびPluginを提供しています。しかし、RFC 9728のサポートは、これらのいずれかが事前にインストールされていない場合でも、エージェントが明確な前進経路を持つことを保証するのに役立ちます。エージェントが信頼されていないコードを実行するためのサンドボックスを持っている場合、人間が許可したAPIを呼び出すコードを書いて実行することができます。
Cloudflareの独自のAPI用にこれをサポートするために取り組んでいます。これにより、エージェントはCloudflareの使用方法を理解するのに役立ちます。
近日公開: 多くのCloudflareアカウント全体で1つのアイデンティティプロバイダー(IdP)を共有
Cloudflareでは、独自の内部アプリは数十の異なるCloudflareアカウントにデプロイされており、すべてOrganization(管理者が多くのCloudflareアカウント全体でユーザー、構成を管理し、分析を表示する新しく導入された方法)の一部です。
多くの顧客と同じ課題がありました: 各Cloudflareアカウントは、Cloudflare Accessがアイデンティティプロバイダーを使用するように、IdPを個別に構成する必要があります。これが組織全体で一貫していることが重要です — 1つのCloudflareアカウントが、シングルサインオン(SSO)経由の認証を要求するのではなく、単にワンタイムPINでサインインすることを誤って許可したくありません。
これを解決するために、現在、Cloudflareアカウント全体でアイデンティティプロバイダーを共有することを可能にするために取り組んでいます。これにより、組織は組織内のすべてのアカウントで使用するための単一のプライマリIdPを指定する方法を提供します。
組織内に新しいCloudflareアカウントが作成されると、管理者はプライマリIdPへのブリッジをワンクリックで構成でき、アカウント全体のAccessアプリケーションは1つのアイデンティティプロバイダーで保護できます。これにより、アカウントごとにIdPを手動で構成する必要がなくなり、多くのチームと個人がそれぞれのアカウントを操作している組織ではスケーリングしないプロセスです。
次は何か
企業全体で、あらゆる役割とビジネス機能の人々がエージェントを使用して内部アプリを構築しており、エージェントが内部アプリからコンテキストにアクセスできることを期待しています。内部ソフトウェア開発のこのステップ関数の成長に対応するために、Workers PlatformとCloudflare Oneをより良く連携させています。これにより、Cloudflareで内部アプリを構築および保護しやすくなります。
以下を含む、近日中にさらに多くのことが予想されます:
- JWTを検証したり、特定のWorkerが公開されている多くのルートのどれを覚えたりする必要なく、Cloudflare AccessとCloudflare Workersの間のより直接的な統合
- wrangler dev --tunnel — 新しいものを構築していて、デプロイする前に他の人と共有したい場合に、ローカル開発サーバーを他の人に公開する簡単な方法
- Cloudflare AccessおよびCloudflare API全体のCLIインターフェース
- Agents Week 2026中のさらなるアナウンスメント
Cloudflare Accessの背後にある内部アプリのマネージドOAuthを有効にする
マネージドOAuthは現在、オープンベータで、すべてのCloudflareカスタマーが利用できます。Cloudflareダッシュボードに移動して、Accessアプリケーションに対して有効にしてください。Cloudflare Workers上に構築されたアプリであろうと、他の場所でホストされているアプリであろうと、任意の内部アプリに対して使用できます。Workers Platformで内部アプリを構築していない場合、チームが迅速に進むための最速の方法です。