Cloudflare OS とは？業務改善に使う AI ワークスペースの全体像と進め方

Cloudflare OS とは何か

Cloudflare OS は、Cloudflare が 2026 年 8 月 4 日 (米国時間) に公開した、オープンソースの AI ワークスペースです。ライセンスは Apache License 2.0 で、リポジトリから入手して自社の Cloudflare アカウントへデプロイできます。

名前に OS と付いていますが、パソコンやサーバーの基本ソフトという意味ではありません。社内の知識・データ・権限の上で AI エージェントとアプリを動かすための土台、という意味合いで使われています。ブラウザを開けば、調査を頼む、資料を作る、繰り返しの作業を自動化する、といった仕事をひとつの場所で進められます。

特徴的なのは出自です。Cloudflare が社外向けの製品として企画したのではなく、自社の社員が使うために作り、2026 年 5 月から全社員へ展開したものが公開されました。現在はエンジニア以外を含む数千人が日常的に使っていると説明されています。社内で回っている仕組みがそのまま出てきた形なので、機能の並びも実務の順番に沿っています。

この記事では、Cloudflare OS の構成要素を一次情報から整理したうえで、自社の業務改善へどう組み込むかを扱います。生成 AI を業務へ広げる話の全体像は 生成 AI の業務活用アイデア 15 選 で整理しているので、本記事は Cloudflare OS という選択肢に絞って掘り下げます。

FIXIT

社内で AI を使う仕組みなら、もう ChatGPT を配ってるところも多いよね。

Tsukasa

結論から言うと、違いは出口です。会話で終わるか、業務アプリが残るか。

FIXIT

えっ、アプリって社員が作るの？エンジニアじゃないのに？

Tsukasa

エージェントに頼んで作らせます。判断の軸は、それを安全に動かせる場があるかです。

3 つの構成要素

Cloudflare OS は大きく 3 つの層で説明されています。

エージェントの作業場 (ワークスペース)

会社が整理した知識とスキルを前提に、AI エージェントが作業する場所です。エージェントのセッション、作業の状態、生成したファイル、アクセスできるリソース、隔離された実行環境がひとまとまりになっています。

ここで効いてくるのが Knowledge Library です。チームや会社が蓄えてきた社内用語・業務手順・うまくいったやり方が登録されており、エージェントはそれを前提に動きます。誰かが見つけた良い進め方を全員が使える状態にする、という設計思想です。社内 AI が「一般論しか返さない」状態から抜け出せるかどうかは、ここに何を入れられるかで決まります。

Gadget と呼ばれる自分用のアプリ

Cloudflare OS で作られる成果物は、チャットの回答ではなくアプリです。クライアントコード・サーバーコード・API・永続的な状態を持つフルスタックのアプリで、公式には Gadget と呼ばれています。各アプリは専用の SQLite データベースを持ち、他の利用者の環境から隔離されたサンドボックスで動きます。

たとえばスライド資料であれば、ファイルそのものが 1 つの小さなアプリとして存在し、機能が足りなければエージェントに頼んで追加できます。作ったアプリは最初は非公開で、共有の仕方は 2 通りあります。アプリ自体を共有してリアルタイムに共同編集する方法と、設計図 (ブループリント) を共有して各自の複製を作ってもらう方法です。後者は、うまくいった業務ツールを部署へ横展開するときに効きます。

Gatekeeper による権限制御

3 つめが、この製品の肝にあたる部分です。Gatekeeper は、Cloudflare OS と外部サービスの間に立つサービス専用の Worker で、対象サービスの API・管理するリソース・実行できる操作を理解しています。OAuth 認証の処理、資格情報の管理、アクセスルールの適用、参照したデータの記録までを一手に引き受けます。

重要なのは、エージェントが何のアクセス権も持たない状態から始まることです。エージェントは特定のリソースへのアクセスを申請し、許可されると型付きバインディングという形で受け取ります。資格情報そのものはエージェントから隔離されたままです。単一リポジトリだけ許可する、特定フィールドをマスクする、レート制限をかけるといった細かな制御も Gatekeeper 側で実装できます。

さらに、エージェントが参照したリソースはすべて記録されます。別の人がそのワークスペースや成果物を開くとき、Gatekeeper が「その人は元データを見てよいのか」を確認します。機密データを参照した後は、特定の宛先への書き出しや新しい共同編集者の追加を制限するといった運用も可能です。

アーキテクチャの全体像

土台は Cloudflare のプラットフォームそのものです。Workers・Durable Objects・Dynamic Workers・Facets が中核で、ワークスペースはそれぞれ Durable Object として、各 Gadget は Dynamic Worker Facet の中で動きます。クライアントとサーバー、エージェントとアプリの間の通信には、オブジェクト・ケーパビリティ方式の RPC である Cap'n Web が使われています。

flowchart LR
  U["社員<br/>(ブラウザ)"] --> A["Access<br/>入口の認証"]
  A --> W["ワークスペース<br/>Durable Object"]
  W --> K["Knowledge Library<br/>用語・手順・スキル"]
  W --> G["Gadget<br/>Dynamic Worker Facet"]
  W --> GK["Gatekeeper<br/>サービス別 Worker"]
  GK --> S["社内システム・<br/>外部 SaaS"]
  W --> AG["AI Gateway<br/>推論の窓口"]
  AG --> M["各 AI モデル"]

入口は Cloudflare Access が守ります。誰が Cloudflare OS に入れるかはここで決まります。出口にあたる推論は、すべて AI Gateway を経由します。どのモデルを使えるようにするかを一箇所で決められ、リクエストごとに利用した個人・チーム・ワークスペースへ費用が割り当てられます。管理者は使い道を把握したうえで予算やレート制限を設定できます。

コード実行の隔離も明確です。サーバー側のコードは外部へのネットワーク通信を無効にした Dynamic Worker 上で動き、クライアント側はブラウザ内のサンドボックス化されたフレームで動きます。外部と通信したいときは、Gatekeeper を通じて明示的に許可を得る流れになります。

既存の MCP サーバーがあれば、MCP Server Portal を通じて連携できます。社内ツール向けに MCP サーバーを整備してきた組織は、その資産をそのまま活かせます。MCP サーバーを自作する手順は MCP サーバーの自作ガイド で解説しています。

社内チャット AI との違い

すでに生成 AI を全社導入している組織から見ると、何が上乗せされるのかが判断の分かれ目になります。

観点	一般的な社内チャット AI	Cloudflare OS
成果物	会話の回答・生成テキスト	状態と API を持つアプリ (Gadget)
社内知識	検索連携や添付で都度渡す	Knowledge Library に用語・手順・スキルとして常設
社内システム	連携ごとに個別実装、権限は接続先まかせ	Gatekeeper が認証・権限・記録を一元管理
資格情報	連携ツールが保持し、範囲が粗くなりがち	エージェントに渡さず、型付きバインディングで貸し出す
横展開	プロンプトの共有に留まる	アプリの共有・ブループリントによる複製
コスト把握	契約単位や部門単位で概算	リクエスト単位で個人・チームへ割り当て

チャット型の AI は「聞けば答えが返る」ところまでは行きますが、返ってきた答えを業務の形に落とす部分は人が毎回やり直しています。Cloudflare OS は、その落とし込みをアプリとして残し、権限つきで共有する部分を引き受ける構造です。

FIXIT

社内システムにつなぐって、いちばん怖いところじゃない？

Dodai

そこは事故ります。だから鍵をエージェントに渡さない設計になっています。

FIXIT

渡さないで、どうやって使うの？

Dodai

Gatekeeper が代わりに叩きます。許可した操作だけ、記録が残る形で。

FIXIT

ふーん。じゃあ、うちでも安心して全部つないでいいってこと？

Dodai

逆です。許可範囲を決めるのは自社です。まず 1 系統から始めるべきです。

業務改善にどう使うか

ここからが本題です。Cloudflare OS を入れれば業務が改善するわけではありません。改善するのは、対象業務の選び方と権限設計、そして測り方を先に決めた場合です。順序は次のとおりです。

flowchart TD
  S1["1. 業務の棚卸し<br/>頻度 × 手作業時間 × 定型度"]
  S2["2. 接続なしの範囲で開始<br/>調査・資料作成"]
  S3["3. 社内の前提を移す<br/>Knowledge Library 整備"]
  S4["4. 接続先を 1 系統に絞る<br/>Gatekeeper 設計"]
  S5["5. 定型作業をアプリ化<br/>Gadget + ブループリント"]
  S6["6. 効果とコストを測る<br/>AI Gateway の計上"]
  S1 --> S2 --> S3 --> S4 --> S5 --> S6

1. どの業務を対象にするか決める

最初にやるのは導入作業ではなく棚卸しです。頻度が高く、手作業の時間が長く、判断が定型的な業務ほど効果が出ます。逆に、頻度が低い業務や、判断の責任が重い業務から手を付けると、労力に見合いません。

向く業務	後回しにする業務
定例レポートの集計と作成	承認・与信など責任の重い判断
社内データを見るための簡易ツール	外部への確定送信を伴う処理
問い合わせ内容の分類と一次整理	個人情報を広く横断する集計
議事録から次のアクションを起こす作業	監査対象で記録要件が厳しい手続き

棚卸しの進め方そのものは 業務効率化は何から始める? で詳しく扱っています。ここで優先順位を付けずに始めると、使う人と使わない人に分かれて終わります。

2. 接続を伴わない範囲から始める

最初の 1 か月は、社内システムへつながない範囲に限定するのが安全です。調査、情報整理、ドキュメントや資料の作成であれば、失敗しても影響は自分の作業内に収まります。ここで「何がうまく任せられて、何が任せられないか」の感覚を先に掴みます。

この段階で観察しておきたいのは、AI の出力品質ではなく、社員がどこでつまずくかです。指示の書き方なのか、社内の前提が伝わらないことなのか。後者であれば、次の段階で解けます。

3. 社内の前提を Knowledge Library へ移す

AI は社内の暗黙の前提を知りません。「弊社では見積は税抜で書く」「この略語はこの部署ではこの意味」といった前提が抜けたまま出力されると、毎回人が直すことになり、効率化どころか手間が増えます。

Knowledge Library に用語・手順・うまくいったやり方を登録するのは、この手戻りを構造的に潰す作業です。個人が自分のプロンプトに書き足して済ませていた知識を、会社の資産として置き直します。運用ルールの整備は 生成 AI 利用ガイドラインの作り方 も併せて参考にしてください。

4. 接続先を 1 系統に絞って Gatekeeper を設計する

社内システムへつなぐ段階では、いきなり複数の系統を開けないことです。まず 1 系統、読み取りだけ、対象は特定のリソースに限定する。この形で回してみて、記録の残り方と運用の手触りを確認します。

Gatekeeper は対象サービスごとに作る仕組みなので、設計時に決めるべきことは明確です。どのリソースを対象にするか、どの操作を許可するか、どのフィールドをマスクするか、レート制限をどう置くか。既存の MCP サーバーがあれば、MCP Server Portal 経由の連携から始める手もあります。

5. 定型作業をアプリとして固める

繰り返し発生する作業は、その都度エージェントに頼むのではなく、Gadget として固めます。アプリになると、実行の手順が揃い、結果の形式も安定します。属人化していた作業が、誰が実行しても同じ手順で回る状態になります。

うまくいったアプリはブループリントで共有し、各自の複製として横展開します。ここで気を付けたいのは、レビューのない自作アプリが乱立する状態です。業務の記録として残るものや、対外的な数字を扱うものは、誰かが中身を確認する運用を先に決めておく必要があります。

6. 効果とコストを測る

推論はすべて AI Gateway を経由し、リクエストごとに個人・チーム・ワークスペースへ費用が割り当てられます。つまり「どの部署がいくら使い、何に使ったか」を後から追える構造になっています。予算とレート制限も設定できます。

測るべきは費用だけではありません。対象業務にかかっていた時間がどれだけ減ったか、手戻りが減ったか、使っている人が何人いるか。この 3 点を最初に決めておかないと、導入したこと自体が成果として語られる状態になります。指標の置き方は AI 導入効果を数値化する KPI・ROI 設計 で整理しています。

FIXIT

正直、全社に配って「使ってね」で終わりそうな気がするんだけど。

Shiori

整理すると、配布は最後です。先にやるのは対象業務の絞り込みと権限の設計です。

FIXIT

でも、早く全員に使ってもらったほうが効果は出ない？

現場では逆になります。前提が揃っていないと、直す手間のほうが増えます。

Kaname

社内の用語と手順を先に登録しておくと、そこから一気に回り始めます。

導入前に押さえる注意点

現時点の状況として、公式が示している前提がいくつかあります。

まず完成度です。2026 年 8 月のリリース時点で、Cloudflare は v2 について「非常に高機能だが粗い部分が多く残る」と説明しています。全社の基幹業務をいきなり載せる段階ではありません。

次に開発体制です。外部からのコード貢献は原則として受け付けておらず、受け入れるのは小さく検証しやすい修正に限るとされています。自社で大きく改造して使う想定であれば、その差分を自分たちで維持し続ける負担を見込んでおく必要があります。

セットアップの手間も見ておきます。外部サービスとの連携に必要な OAuth の資格情報取得は、意図的に簡単にはしていないと明言されています。安全側に倒した設計である一方、つなぎ込みの初期作業はそれなりに発生します。

提供形態は今後変わります。現在はオープンソース版を自社の Cloudflare アカウントへデプロイする形ですが、Cloudflare ダッシュボードから使えるフルマネージド版が公開予定とされています。開発ワークフロー向けのコンテナ対応や、Slack などのチャットツールへのワークスペース展開も進行中です。導入支援のパートナーとして Presidio と Happy Cog が挙げられています。

FIXIT はこう見ている

Cloudflare OS で注目すべきは、AI が賢くなったことではなく、権限の扱い方が設計の中心に据えられたことだと考えています。エージェントを無権限から始め、資格情報を渡さず、参照したものを記録し、共有時に相手の権限を確認する。この一連の流れは、社内 AI 活用が実際に止まる場所を正確に突いています。

私たちがクライアントワークで見てきた限り、生成 AI の社内展開が進まない理由は性能不足よりも「どこまで触らせてよいか決められない」ことにあります。決められないから、当たり障りのない用途に限定され、効果が出ないまま話が止まる。Cloudflare OS はその決定を実装として書ける形にしました。逆に言えば、決めるべきことを決めるのは引き続き自社の仕事です。

もう 1 つ、成果物がアプリとして残る点も見逃せません。会話は流れて消えますが、アプリは業務手順として蓄積されます。属人的な作業を手順に落とし込む、という業務改善の王道が、AI を挟んだ形で回るようになります。AI エージェントを業務へ組み込む設計の考え方は AI エージェント設計パターン入門、社内で推進体制を作る進め方は 社内 AI 活用推進チーム (CoE) の作り方 で整理しています。

自社のどの業務から着手すべきか、接続範囲をどう設計するかを一緒に整理したい場合は、AI 駆動開発サービス のページや 無料相談 からご相談ください。

おすすめ参考リソース

• Cloudflare 公式ブログ: Cloudflare OS：エージェント、アプリ、作業のためのオープンプラットフォーム
• Cloudflare 公式: プレスリリース (2026 年 8 月 4 日)
• GitHub: cloudflare/cloudflare-os
• GitHub: cloudflare/cloudflare-os-starter