Cloudflare OSのマネージド・エージェント・ワークスペース、オープンソースからウェイトリスト制サービスへ移行

Cloudflareは、基盤プラットフォームをオープンソースとして公開してからわずか1か月後、初の完全マネージド型Cloudflare OSエージェント・ワークスペースのウェイトリストを開始した。この変更によりCloudflare OSは、企業が自ら運用するプロジェクトから、Cloudflareが企業に代わって管理することを目指すサービスへと移行する。

これは一般的なホステッド版のようにも聞こえるが、Cloudflareはより大きな役割を狙っている。同社は、各従業員に対し、社内手順を理解し、承認済みシステムをまたいで行動できる永続的なワークスペースを提供したい考えだ。このワークスペースは情報を調査し、文書を作成し、コードを修正し、繰り返し発生する作業をアプリケーションへと変換できる。

この動きは、すでに企業向けエージェント・プラットフォームを販売しているMicrosoft、Google、その他のクラウドプロバイダーに圧力をかける。これらの製品は、オフィススイートやクラウドアカウント内での強固な立場を生かしている。Cloudflareは、ID管理、ネットワーク制御、モデルルーティング、隔離実行が、職場向けエージェントにとって同様に重要な基盤になり得ると見込んでいる。

Cloudflare OSのマネージド・エージェント・ワークスペース、ウェイトリスト段階へ

Cloudflareは一般提供を発表したわけではない。運用負担なしにオープンソース・プラットフォームを利用したい企業の需要を検証している。

Cloudflareは2026年10月1日、マネージド型の選択肢を発表した。組織はウェイトリストに登録できるが、同社は提供開始日、サービスレベルのコミットメント、利用可能リージョンの一覧、商用条件を明らかにしていない。

この違いは重要だ。オープンソース版はすでに利用可能である。企業は自社のCloudflareアカウント内に導入し、インターフェースをカスタマイズし、社内リソースへ接続できる。ただし、その導入環境の構成、運用、更新、保護も自ら担わなければならない。

Cloudflareは現在、異なる責任分担を提案している。顧客は認可ユーザー、企業コンテキスト、組織スキル、接続先システム、カスタムドメイン、関連するアクセス・ポリシーを選択する。Cloudflareは、残る導入および運用作業を担う。

マネージド版の発表によると、組織は導入環境で使用するAI Gatewayも選択する。AI Gatewayはワークスペースとモデルプロバイダーの間に位置し、ルーティング、ロギング、ポリシー制御を適用できる。

Cloudflareによれば、オープンソース公開後の1か月間で、数千の組織がCloudflare OSの利用を開始したという。この数値はCloudflareによるもので、独立した検証は受けていない。同社は、稼働中、実験段階、あるいは組織全体で利用されている導入環境がそれぞれどれほどあるかを明らかにしていない。

それでも、ウェイトリストはオープンソース公開から得られた具体的な教訓を反映している。コードを公開すれば、ライセンスやカスタマイズの障壁は下がるが、導入作業がなくなるわけではない。企業は依然として、IDルールの策定、システム接続、認証情報の保護、アップグレードのテスト、障害調査を行う必要がある。

マネージド・サービスは、この導入上の隔たりに対するCloudflareの回答だ。各顧客がプラットフォーム向けに専用の運用プロセスを整備しなくても、企業がカスタマイズを行えるようにする。

このタイミングは、Cloudflareが想定する市場も示している。Cloudflare OSは、ソフトウェアチーム向けのエージェント開発キットとしてだけ位置付けられているわけではない。同社は、営業、財務、サポート、オペレーション、エンジニアリングの従業員を対象としたワークスペースとして説明している。

顧客との会議を例にすると、その範囲が分かる。従業員はエージェントに、アカウント記録の確認、サポートチケットの調査、製品利用状況の分析、プレゼンテーションの準備を依頼できる。このタスクは複数のシステムを横断し、短いチャット応答ではなく編集可能な成果物を生み出す。

Cloudflareは最初の1か月間にもプラットフォームを更新した。ユーザーはGitHubリポジトリを接続し、エージェントにコードの調査、ファイル編集、コミット作成、プルリクエストのオープンを依頼できるようになった。これらの機能により、当初はより幅広いナレッジワークを中心に提示されていた製品へ、ソフトウェア開発が組み込まれる。

Google Workspaceとの統合も拡張された。Cloudflareによると、エージェントはGmailスレッドを調査し、下書きを作成し、メッセージを送信し、接続済みのDriveリソースを使用できる。管理者はDrive全体、フォルダ、または個別の文書を公開できる。

ワークスペースは、文書やデータをExcelファイル、CSV、PDF、Markdown、HTMLとしてエクスポートできる。WordおよびPowerPointへのエクスポートは計画されているが、Cloudflareが発表を公開した時点では利用できなかった。

これらの追加機能は、製品が対象とする業務を広げる。同時に、リスク領域も広げる。メールを読み、ファイルへアクセスし、コードを変更し、メッセージを送信できるエージェントには、テキストの下書きだけを作成するチャットボットよりも厳格な制御が必要となる。

この緊張関係は、Cloudflareの主要な訴求点へ直結する。同社はマネージド運用を販売しているが、より大きな主張は企業データへのガバナンスの効いたアクセスに関するものだ。

真の製品はガバナンスの効いた実行レイヤー

Cloudflare OSは、従業員向けワークスペースと、エージェントが閲覧、実行、保持、共有できる対象を制御するインフラストラクチャを組み合わせている。

ワークスペースには、会話、ファイル、出力、権限、タスク、スケジュールイベントが保存される。通常のチャットセッションとは異なり、ユーザーがブラウザを閉じた後も状態を維持できる。この永続性により、複数のセッションにまたがって継続するプロジェクトを支援する。

Cloudflareのリファレンス・アーキテクチャでは、WorkersとAgents SDKがオーケストレーション層に配置されている。Durable Objectsが状態を維持し、Dynamic Workersとサンドボックス・コンテナがコードを必要とするタスクを実行する。

AI Gatewayは、承認済みモデルへのアクセスを制御する。Model Context Protocolポータルは、ワークスペースを企業ツールに接続する。MCPは、エージェントが利用可能なツールを検出し、その操作を呼び出すための標準インターフェースである。

このアーキテクチャでは、モデルを認証情報とポリシー施行から分離している。この分離は重要である。なぜなら、言語モデルが企業データを必要とするたびに、広範な権限を持つAPIキーを受け取るべきではないからだ。

Cloudflareは、Cloudflare OSと外部システムの間にGatekeepersと呼ばれるサービスを使用する。各Gatekeeperは、対象サービス、利用可能なリソース、許可される操作、関連する組織ポリシーを理解する。

GitHub Gatekeeperは、アカウント全体を公開せずに単一のリポジトリを公開できる。ソースコードは隠したまま、issueへのアクセスを許可することもできる。また、エージェントがプルリクエストをマージする前に人間の承認を求めることも可能だ。

エージェントには、基盤となる認証情報ではなく、制限されたプログラミング・インターフェースが見える。Cloudflareによると、認証情報は生成されたコードから隔離されたままである。サーバーサイドのコードも、管理者が承認済みの機能を提供しない限り、外部ネットワークへのアクセスを無効にした状態で実行される。

このモデルは、アクセス権なしの状態から始まる。エージェントまたは生成されたアプリケーションは、使用する各リソースについて権限を受け取る必要がある。この構造は、割り当てられたタスクに必要なリソースだけにIDの権限を限定する最小権限の原則に従っている。

Cloudflareは、エージェントが参照したリソースを追跡することでさらに踏み込んでいる。エージェントが制限付きデータセットを読み込み、ダッシュボードを作成した場合、そのダッシュボードはそのソースとの関係を維持する。

別の従業員がその出力を開くと、Gatekeepersは、その従業員が参照されたリソースへアクセスできるか確認できる。目的は、生成された出力が元データに付随する権限を迂回することを防ぐことにある。

この問題は、企業向けエージェントにとって中心的な課題となっている。従来の認可では、ユーザーがファイルを開けるか、アプリケーションを照会できるかが問われる。エージェント型システムは複数のリソースから情報を組み合わせ、新たな成果物を生み出すことができる。

新たな成果物には、元のシステムのアクセス制御を保持しないまま、機密性の高い事実が含まれる可能性がある。要約、グラフ、アプリケーション、メールの下書きが、データ境界を迂回する間接的な経路となり得る。

Cloudflareのアプローチは、情報の来歴を認可の一部として扱う。プラットフォームはエージェントが見たものを記憶し、その履歴を利用して誰がその作業にアクセスできるかを判断しようとする。

これは単なるコネクタ・フレームワークではない。エージェントがデータを変換した後も、そのデータをガバナンスの対象とする試みである。

オープンソース版のローンチ記事は、Cloudflareがこの要件を中心にプラットフォームを再構築した理由を説明している。同社の最初の社内版はプライベート・ワークスペースをサポートしていたが、コラボレーションにより共有アプリケーションや出力に関するリスクが明らかになった。

Cloudflareは、MCPツールへのアクセスだけでは、そのツールを通じて参照されたすべての基盤リソースを把握できないと結論付けた。そのため、ワークスペースのインターフェースより下のレイヤーで機能する制御を追加した。

この設計は、決定論的な作業とモデル推論も分離している。エージェントは、繰り返し発生する手順をコードへ変換し、判断が必要な場面でのみモデルを使用できる。

サポート・ダッシュボードを考えてみよう。ソフトウェアは、モデルにこうした手順を繰り返し実行させることなく、チケット数の取得、記録のグループ化、グラフの描画を行える。モデルは、通常と異なるケースの分類や、推奨回答の下書き作成に利用できる。

この分離により、不必要な推論を減らし、より予測可能なワークフローを作れる可能性がある。また、反復可能な操作は標準コードが処理するため、出力の検査も容易になる。

Cloudflareによると、同社のチームはこのパターンを社内チケット報告に使用した。エージェントがチケットデータに接続されたアプリケーションを作成し、従業員は下書きされた回答に対するレビュー権限を保持した。

これは依然として、独立した性能調査ではなく、企業が報告した事例である。しかし、この例はプラットフォームが目指す進展、すなわち会話、再利用可能なワークフロー、永続的なアプリケーションを示している。

同社のソースリポジトリにも、明確な早期アクセスに関する警告が記載されている。バージョン2は完全な書き直しであり、未解決の粗さが残っていると説明されている。この警告は、マネージド・サービスを評価する際にも考慮すべきだ。

ホステッド導入は運用を簡素化できるが、未完成のソフトウェアを重要なワークフローに自動的に適したものへ変えるわけではない。購入者は、インフラストラクチャ管理とアプリケーションの成熟度を区別する必要がある。

MicrosoftとGoogleがアプリを握る一方、Cloudflareはコントロールプレーンを狙う

Cloudflareの主な課題は、別のエージェントを構築することではない。従業員がすでに働く場所を支配している競合をどう乗り越えるかだ。

Microsoftは、Microsoft 365、Teams、SharePoint、Dynamics、Power Platformの中にエージェントを配置できる。Googleは、エージェントをWorkspace、Cloud、Drive、Gmail、組織内検索に接続できる。

こうした立場は導入時の摩擦を減らす。従業員は使い慣れたアプリケーション内でエージェントに触れられ、管理者は既存のID、コンプライアンス、データ制御を再利用できる。

Microsoftのエンタープライズ・エージェント計画は、ローコード・ツール、マネージド・ランタイム、コネクタ、開発者サービスにまたがる。Copilot Studioはビジネスチームを支援し、Microsoft Foundryは、よりカスタマイズされたシステムを構築する開発者向けだ。

Googleも同様のプラットフォーム戦略を採用している。同社の企業向け製品は、従業員向けインターフェース、モデルへのアクセス、検索、コネクタ、エージェント作成、集中管理を組み合わせている。

Cloudflareは主要な生産性スイートを所有していない。従業員がすでにCloudflareの文書エディタ、受信トレイ、スプレッドシート、コラボレーション・アプリケーションの中で一日を過ごしているとは想定できない。

むしろ、Cloudflare OSはそれらのシステムの上位に位置付けられている。ワークスペースは既存のツールに接続し、Cloudflareが実行、ネットワーク、ID適用、モデルガバナンスを提供する。

これはコントロールプレーン戦略である。コントロールプレーンはポリシーを設定し、リソースを調整する一方、接続されたアプリケーションは記録の基幹システムとして存続する。

このアプローチは、混在環境に潜在的な利点をもたらす。多くの組織はMicrosoftアプリケーション、Googleサービス、GitHub、Salesforce、社内データベース、複数のモデルプロバイダーを利用している。中立的なワークスペースは、理論上、こうした境界をまたげる。

Cloudflare OSでは、顧客がAI Gateway経由でアクセスするモデルを選択することもできる。この設計は、ワークスペースのインターフェースを特定のモデルファミリーに縛り付けない。ただし、利用可能な統合機能やマネージドサービスの条件は依然として不明確だ。

このアーキテクチャは、企業ネットワークとアプリケーションセキュリティにおけるCloudflareの既存の立ち位置と一致している。顧客はすでに、IDを認識したアプリケーション入口としてCloudflare Accessを、あるいはモデルトラフィックを制御するためにAI Gatewayを利用している可能性がある。

こうした組織にとって、Cloudflare OSは確立済みのポリシーレイヤーを従業員向けエージェントへと拡張できる。顧客が周辺サービスをすでに設定している場合、販売上の訴求力はより強くなる。

ただし、中立性にはコストも伴う。MicrosoftとGoogleは、それぞれのスイート内でより深いネイティブ動作を提供できる。Cloudflareは、Gatekeepersと外部APIを通じて、こうした操作を再現または仲介しなければならない。

統合が増えるごとに、保守作業も増加する。APIの挙動は変わり、認証フローは進化し、エンタープライズ権限はテナントごとに異なる。マネージド製品を単一のワークスペースのように感じさせるには、Cloudflareがこれらの接続を信頼性の高い状態に保つ必要がある。

このプラットフォームは、クラウドプロバイダーが提供するマネージドなエージェント基盤とも競合しなければならない。AmazonのAgentCore runtimeは、デプロイされたエージェントのスケーリング、セッション処理、インフラ、分離を管理する。

AgentCoreはエージェントアプリケーションの実行により直接的に焦点を当てる一方、Cloudflare OSには従業員向けインターフェースと、永続的な作業成果物を生み出すためのツールが含まれる。ユーザー体験が異なっていても、両製品はマネージド実行レイヤーで重なり合う。

この競争は、市場が複数のレイヤーに分かれつつあることを示している。モデルプロバイダーは推論システムを提供し、クラウドプラットフォームはエージェントを実行し、生産性スイートはユーザー向けの画面を提供し、統合サービスはエンタープライズツールを接続する。

Cloudflareは、その下層にあるアプリケーションを所有せずに、これら複数のレイヤーをまとめてパッケージ化しようとしている。その差別化は、ガバナンスとシステム横断の実行能力が、スイートネイティブなエージェントの利便性を上回るかどうかに左右される。

そのため、調達の文脈が決定的になる。Microsoft 365に標準化された企業は、既存の管理環境を選好するかもしれない。異種システムを抱える組織は、モデル中立かつアプリケーション中立のワークスペースにより大きな価値を見いだす可能性がある。

開発者も同様の選択に直面する。個別の業務に向けて別々のエージェントを構築するか、ニーズの発生に応じてツールを作成できる共有ワークスペースを従業員に提供するかである。

ワークスペースモデルは、断片化を減らせる可能性がある。従業員は一つのエージェント履歴、一組の承認済み機能、一つの組織スキルライブラリを維持できる。チームは、タスクごとにプロンプトを作り直すのではなく、手順を共有できる。

一方で、リスクを集中させる可能性もある。多くのシステムに接続された単一のワークスペースは、重要なセキュリティ境界となる。設定ミスや欠陥のある統合があれば、一つの限定的なエージェントではなく、複数のワークフローに影響を及ぼしかねない。

このトレードオフこそ、マネージド版が重要である理由を説明する。Cloudflareは、単にWebインターフェースのホスティングを任せるのではなく、機密性の高いシステムをまたぐワークスペースの運用を自社に委ねるよう顧客に求めている。

マネージド運用では信頼の問題は解決しない

ウェイトリストは導入作業の一部を減らすが、Cloudflareはセキュリティ、信頼性、導入に関する疑問を解消するだけの十分な証拠をまだ示していない。

最初の不確実性は、製品の完成度に関するものだ。Cloudflare OSは依然としてオープンソースの早期アクセスソフトウェアであり、マネージドサービスの提供開始日は発表されていない。

ウェイトリストは、Cloudflareが容量やサポートリソースを確約する前に関心を測ることができる。同時に、購入者が最終的な契約、サービス境界、運用モデルをまだ評価できないことも意味する。

Cloudflareは、データレジデンシー、バックアップポリシー、インシデント対応、アップグレードスケジュール、復旧目標、対応統合機能を対象とするマネージドサービスの詳細を公表していない。これらの詳細は、導入の手軽さ以上に重要になる。

二つ目の不確実性は、認可の正確性に関するものだ。観測されたリソースを追跡することはデータ漏洩への配慮ある対応だが、実際のエンタープライズ権限は複雑である。

アクセスルールは、役割、所在地、プロジェクト、デバイスの状態、レコードのフィールド、法的保全、または一時的な例外に依存する場合がある。Gatekeeperは、読み取り時と共有時の両方で、これらの制約を正しく解釈しなければならない。

生成されたアプリケーションは、さらに別のレイヤーを加える。アプリはデータを保持し、フィールドを変換し、結果をキャッシュし、複数のユーザーからの入力を受け付けることができる。ポリシー適用は、こうしたすべての遷移を通じて維持されなければならない。

Cloudflareによれば、Gatekeepersは観測を記録し、作業が共有される際にアクセスを確認する。独立したテストでは、このモデルがあらゆる変換、権限取り消し、間接的推論をどのように扱うかはまだ確立されていない。

特に注意すべきは権限取り消しだ。エージェントが出力を作成した後に従業員がソースへのアクセスを失った場合、その従業員が派生した資料を保持できるかどうかをシステムは判断しなければならない。

管理者には、理解可能な監査記録も必要になる。調査担当者がどのレコードが出力に影響したのかを判断できないなら、エージェントがツールを呼び出したことだけを示すログでは不十分だ。

三つ目の不確実性は、生成コードに関するものだ。Cloudflare OSでは、エージェントが隔離環境内でソフトウェアを書き、実行できる。分離は露出を抑えるが、生成コードには依然としてロジックエラーが含まれ得る。

ワークフローが誤ったレコードを選択したり、フィルターを誤適用したり、不完全なレポートを送信したり、意図しない操作を実行したりする可能性がある。こうした失敗は、サンドボックスから脱出しなくても起こり得る。

承認管理は、有害な副作用を抑えることができる。しかし、意味のある操作すべてに人間の確認が必要であれば、恒常的なレビュー作業も生み出しかねない。

組織は、タスクごとに異なる自律性レベルを必要とする。承認済み文書の閲覧は、メール送信、ソースコード変更、顧客レコード更新よりもリスクが低い。

四つ目の不確実性は、統合の深さに関するものだ。CloudflareはGitHubとGoogle Workspaceを強調しているが、ほとんどの企業は他にも多くのシステムに依存している。マネージドワークスペースは、そのコネクタが実際の業務に合致して初めて有用になる。

システムを接続するだけでは不十分だ。統合は細かな権限を理解し、安定した認証を維持し、障害を処理し、エージェントが安全に利用できる形で操作を公開しなければならない。

五つ目の不確実性は、導入に関するものだ。すべての従業員にエージェントを与えても、従業員がそれを中心に業務を再設計する保証にはならない。

従業員には、信頼できる組織スキル、明確な事例、レビューの実務、サポートが必要だ。チームには、どの出力に検証が必要かについての合意も必要になる。

Cloudflareによれば、数千人の従業員が社内プラットフォームを利用し、チームは数千のツールを作成している。これらの数字は社内活動を示すが、自社環境からの企業独自の推計にとどまる。

Cloudflareの従業員は、製品を構築する人々に通常とは異なるほど直接アクセスできる。外部顧客は、異なるオンボーディング、サポート、コンプライアンス、変更管理の条件に直面する可能性がある。

マネージド導入はインフラ作業を減らせる。しかし、企業知識を整理したり、不明確な手順を解消したり、どのワークフローを自動化すべきかを決めたりすることはできない。

組織は、この準備をナレッジマネジメントのプロジェクトとして扱うべきだ。信頼できるチームナレッジベースには、所有者、アクセスルール、最新の資料、古くなったガイダンスを修正するプロセスが必要である。

Cloudflare OSは、整理されたコンテキストと再利用可能なスキルに依存する。これらの入力が矛盾したり古くなったりすれば、エージェントは誤った手順をより効率的に実行してしまう。

したがって、マネージドサービスは二つのことを証明しなければならない。Cloudflareは技術プラットフォームを信頼性高く運用する必要があり、同時に顧客はエージェントに有用な指示を与える組織レイヤーを維持しなければならない。

どちらの責任も、わずかな導入クリックの裏に消えるわけではない。

Cloudflare OSがエンタープライズ基盤になれるかを示す三つのシグナル

次の段階は、サービスの詳細、本番環境での証拠、そしてCloudflareのガバナンスモデルが自社組織の外でも機能するという証明にかかっている。

最初のシグナルは、定義されたマネージドサービスのリリースだ。Cloudflareは、提供開始時期、対応リージョン、統合範囲、管理機能、責任境界を公表する必要がある。

それらの詳細を欠くリリースは、インフラとしての主張を弱める。文書化された運用モデルは、特に長期利用を評価するセキュリティチームやコンプライアンスチームにとって、その主張を強化するだろう。

購入者は、データの所在、モデルルーティング、ログ、バックアップ、インシデント処理、アップグレード、テナント分離について明確な回答を求めるべきだ。また、マネージド導入が顧客運用のインストールとどう異なるかも検討すべきである。

二つ目のシグナルは、独立した本番導入だ。数千の組織に関するCloudflareの説明は初期の関心を示すが、継続的な利用を明らかにするものではない。

より強い証拠には、実名の顧客、明確に定義されたワークフロー、導入規模、管理者のフィードバック、測定されたエラー率が含まれる。ケーススタディでは、組織が権限と人間によるレビューをどのように扱ったかを説明すべきだ。

利用の深さは、ウェイトリストの規模より重要である。サンプルのプレゼンテーションを作成するパイロットと、運用システムに接続されたワークスペースでは、その意味合いが異なる。

Cloudflareは、アクティブユーザーと登録ユーザーも区別すべきだ。プラットフォームの価値は、反復的な作業、再利用可能なアプリケーション、共有される組織スキルに依存する。

三つ目のシグナルは、Microsoft、Google、Amazonがワークスペースモデルにどう対応するかである。各社の製品はすでに周辺機能の多くをカバーしており、より緊密な統合によって差を埋めることができる。

主要プラットフォームがより強力なシステム横断のプロベナンスと可搬性のある組織スキルを追加すれば、Cloudflareのガバナンス面での差別化は狭まる。各社が自社スイート中心のままであれば、Cloudflareの中立的な立場はより価値を増す。

Cloudflareは、オープンソース版とマネージド版がともに前進できることも示す必要がある。オープンコードはカスタマイズと精査を呼び込む一方、ホスト型サービスは安定性への圧力を生む。

顧客がプラットフォームを検査し、統合を制御し、運用モデル間を移行できるなら、この組み合わせは利点になり得る。リリースの変化が速すぎて企業が検証できない場合は、負債となる。

したがって、Cloudflare OSのマネージドエージェントワークスペースは、単なるホスティング発表以上の意味を持つ。これは、従業員が既存システムを横断して調査、作成、コーディング、自動化を行える、一つの統制された環境を企業が望むかどうかを試すものだ。

Cloudflareは、その環境に向けた信頼できるアーキテクチャを提示している。しかし、完成したマネージド製品や、このモデルが多様な企業で機能することを示す独立した証拠は、まだ提示していない。

ウェイトリストを検討する組織は、限定的で元に戻せるワークフローから始めるべきだ。必要なデータ、許可される操作、人間による承認ポイント、組織スキルの所有者を特定すべきである。

最も有用な問いは、すべての従業員がエージェントを受け取るべきかどうかではない。一つの統制されたワークスペースが、増え続ける切り離されたエージェント実験の集まりを安全に置き換えられるかどうかである。

Cloudflareは今、マネージド運用、きめ細かなアクセス制御、永続的な作業成果物によって、その問いに本番環境で答えられることを証明しなければならない。