このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
Cloudflareには数千の内部アプリがあります。当社が構築したものもあれば、他の人が構築したソフトウェアのセルフホスト型インスタンスもあります。ほぼすべての人が利用するビジネスクリティカルなアプリから、サイドプロジェクトやプロトタイプまで、多岐にわたります。
これらのアプリはすべてCloudflare Accessによって保護されています。しかし、エージェント（特にコードを書くこと以外の目的）を使い始めた時、壁に突き当たりました。ユーザーはAccessの背後にあるアプリにアクセスできましたが、エージェントはアクセスできませんでした。
Accessは、内部アプリの前に位置します。ポリシーを定義すると、Accessは未認証ユーザーをログインページに送り、認証方法を選択します。
Cloudflare Accessログインページの例
このフローは人間にとって非常にうまく機能しました。しかし、すべてのエージェントが見えたのは、行動できないログインページへのリダイレクトでした。
エージェントが社内アプリデータにアクセスできるようにすることは非常に重要であるため、すぐに社内利用のための一時的な保護を導入しました。OpenCodeのWebフェッチツールを変更して、特定のドメインに対して、cloudflared CLIをトリガーして認証フローを開き、JWT（JSON Webトークン）を取得するようにしました。このトークンをリクエストに追加することで、内部エコシステムへの安全かつ即時のアクセスが可能になりました。
このソリューションは、当社自身のジレンマに対する一時的な解決策でしたが、本日、この回避策を廃止し、すべての人に対して、この問題を解決することとしました。現在、オープンベータ版では、すべてのAccessアプリケーションがマネージドOAuthをサポートしています。ワンクリックでAccessアプリに対して有効になり、OAuth 2.0を使用するエージェントは、認証方法（RFC 9728）を簡単に見つけ、ユーザーに認証フローを通過させ、承認トークン（最初のソリューションから同じJWT）を受け取ることができるようになります。
現在では、このフローは人間とエージェントの両方にとってスムーズに機能するようになりました。Cloudflare Accessには充実した無料枠があります。新たに導入されたOrganizationsベータ版を基に、Cloudflareアカウント間でIDプロバイダーを間もなくブリッジできるようになります。
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サーバーだけでなく、Webページ、Webアプリ、REST APIにもアクセスできるようになります。
社内アプリを大量アップグレードしてエージェント対応に
エージェントと連携するために、社内ソフトウェアのロングテールをアップグレードするのは、大変な作業です。基本的に、エージェントに対応できるようにするには、すべての内部および外部アプリが検出可能なAPI、CLI、およびMCPサーバーを持ち、多くの新しいエージェント基準を採用していることが理想的です。
AIの導入は、すべてが後付けされることを待つべきではありません。ほとんどの企業では、何年もかけて構築されたアプリの大量のバックログを抱えています。また、多くの社内「アプリ」は、エージェントがシンプルなWebサイトとして扱うとうまく機能します。社内Wikiのようなものでは、本当に必要なのはエージェント向けMarkdownを有効にし、マネージドOAuthを有効にするだけで、エージェントは保護されたコンテンツを読むのに必要な情報を得ることができます。
さまざまな内部アプリケーションで基本を機能させるためには、マネージドOAuthを使用しています。レガシー内部アプリの前面にAccessを設置することで、即座にエージェント対応になります。コード変更や後付けは不要です。代わりに、すぐに互換性を持つことができます。
ユーザーのエージェントです。サービスアカウントとトークンは不要
エージェントは、組織内のユーザーの代わりに行動する必要があります。私たちが見ている最大のアンチパターンの1つは、エージェントやMCPサーバーのサービスアカウントを、静的な認証情報を使用して認証する人です。これらは、単純なユースケースや迅速なプロトタイプに使われており、Cloudflare Accessはこの目的のためにサービストークンをサポートしています。
しかし、サービスアカウントのアプローチは、きめ細かいアクセス制御や監査ログが必要な場合、すぐに限界を示します。私たちは、エージェントが実行するすべてのアクションは、それを開始した人間によるものであると簡単に帰属できる必要があり、エージェントは人間のオペレーターが行うことを許可された行動のみを実行できなければならないと考えています。サービスアカウントと静的認証情報は、属性を失う点となります。サービスアカウントを通じてすべてのアクションをロンダリングするエージェントは、confused deputy problems の影響を受けやすく、エージェント自体から発信されたように見える監査ログが作成されます。
セキュリティと説明責任を確保するため、エージェントは、ユーザーとエージェントの関係を表現できるセキュリティプリミティブを使用する必要があります。OAuthは、サードパーティへのアクセスをリクエストし、委任するための業界標準プロトコルです。これにより、エージェントはユーザーに代わってAPIと対話する方法を提供します。ユーザーのIDに対応するトークンを使用するため、アクセス制御が正しく適用され、監査ログがエンドユーザーにアクションを正しく結びつけます。
RFC 9728は、エージェントが認証する場所と方法を検出できるようにするOAuth標準です。この情報がどこにあるのか、どのように構造化されているのかを標準化します。このRFCは2025年4月に公式になり、すぐにモデルコンテキストプロトコル（MCP）に採用され、現在ではMCPサーバーとクライアントの両方がサポートすることが義務付けられています。
しかし、MCP以外では、エージェントはRFC 9728を採用する必要があります。つまり、OAuthの背後で保護されているWebページにリクエストを行うことや、通常の古いREST APIにリクエストを行うことです。
ほとんどのエージェントは、Webページに基本的なHTTPリクエストを行うためのツールを持っています。これは一般に「Webフェッチ」ツールと呼ばれます。これはJavaScriptでfetch() APIを使用する場合に似ており、多くの場合、レスポンスにいくつかの追加の後処理が含まれます。エージェントにURLを貼り付け、エージェントにコンテンツを検索してもらうことができるものです。
現在、ほとんどのエージェントのWebフェッチツールは、URLが返すwww-authenticateヘッダーに関しては何もしません。基礎となるモデルは、応答ヘッダーを調査し、独自でこれを達成することを選択するかもしれませんが、ツール自体は www-authenticate に従うわけではなく、/.well-known/oauth-authorization-server を検索し、OAuthフローでクライアントとして機能することもありません。しかし、実現は可能であり、実現すべきだと私たちは強く信じています！エージェントはすでに、リモートMCPクライアントとして機能します。
これを実証するために、OpencodeのWebフェッチツールを適合させて実際の動作を示すプルリクエスト草案を作りました。リクエストをする前に、適応されたツールはまず資格情報が既にあるかどうかをチェックします。一致する場合は、それらを使用して最初のリクエストを行います。ツールが、www-authenticateヘッダーとともに401または403を返すと、サーバーのOAuthフローを通じて送信されることに同意を求めます。
OAuthフローの仕組みは次のとおりです。OAuthで保護され、RFC 9728に準拠したURLをエージェントに与えると、エージェントは認証フローを開くように人間の同意を求めます。
…人間をログインページに送信：
...そして、人間がエージェントへのアクセスを許可するよう促す同意ダイアログがあります。
人間がエージェントへのアクセスを許可すると、エージェントは受け取ったトークンを使用して認証済みリクエストを行います。
CodexからClaude Code、Gooseなど、あらゆるエージェントがこれを実装でき、Cloudflareに特化したものはありません。これはすべてOAuth標準を使用して構築されています。
このフローは強力で、RFC 9728をサポートすることで、エージェントは基本的なWebフェッチリクエスト以外にも可能になると考えています。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の使用方法を理解できるように取り組んでいます。
近日公開：1つのIDプロバイダー（IdP）を複数のCloudflareアカウントで共有
Cloudflareでは、独自の内部アプリを数十の異なるCloudflareアカウントにデプロイしています。これらはすべて組織の一部です。組織とは、管理者が多くのCloudflareアカウントにわたってユーザー、構成を管理し、分析を表示するための新たに導入された方法です。多くのお客様と同じ問題を抱えていました。各CloudflareアカウントはIdPを個別に設定する必要があるため、Cloudflare Accessは当社のIDプロバイダーを使用しています。これが組織全体で一貫していることは非常に重要です。シングルサインオン（SSO）で認証することを要求するのではなく、1つのCloudflareアカウントが誤ってワンタイムPINだけでサインインできるようにすることはあってはなりません。
これを解決するために、現在、Cloudflareアカウント間でIDプロバイダーを共有できるように取り組んでおり、組織内の全アカウントで使用するために単一のプライマリIdPを指定する方法が提供されています。
1つの組織内で新しいCloudflareアカウントが作成されると、管理者は1回のクリックでプライマリIdPへのブリッジを設定できるため、1つのIDプロバイダーによってアカウント間のAccessアプリケーションを保護することができます。これにより、アカウントごとにIdPアカウントを手動で設定する必要性がなくなります。これは、多くのチームや個人がそれぞれ独自のアカウントを運用している組織にとっては大規模なプロセスではありません。
企業全体で、あらゆる役割や業務機能を持つ人がエージェントを使用して社内アプリを構築しており、エージェントが社内アプリからコンテキストにアクセスできることを期待しています。WorkersプラットフォームとCloudflare Oneの連携を改善することで、社内ソフトウェア開発におけるこの段階的な機能の増加に対応しており、Cloudflare上で社内アプリをより簡単に構築・安全に保つことができるようになっています。
以下のような新機能が近日中に発表されます：
Cloudflare AccessとCloudflare Workersの間のより直接的な統合。JWTを検証したり、特定のWorkerが公開されている多くのルートを記憶する必要はありません。
wrangler dev --tunnel — 新しいものを構築し、デプロイする前に他のユーザーと共有したい場合に、ローカル開発サーバーを他のユーザーに公開する簡単な方法
Cloudflare AccessとCloudflare API全体用のCLIインターフェース
Agents Week 2026中のさらなる発表
Cloudflare Accessの背後にある内部アプリのマネージドOAuthを有効化
マネージドOAuthは、現在すべてのCloudflareのお客様に、オープンベータ版でご利用いただけます。「Cloudflareダッシュボードにアクセスして、Accessアプリケーションで有効にしてください。」社内アプリでも、Cloudflare Workers上に構築されたものでも、他の場所でホストされているものでも、ご利用いただけます。また、Workers Platformでまだ内部アプリを構築していない場合、チームがゼロから本番環境にデプロイ（および保護）されるための最速の方法です。