Cloudflareが公開した「Cloudflare OS」を、公開されているソースコードからローカルで起動し、LiteLLM、Tailscale、Gadgetエージェントの動作を検証した。
この記事では、単純なチャットとして動いたかだけではなく、次の点を実際に確認した結果をまとめる。
- Cloudflare OSは何をするものか
- ソースコードはあり、セルフホストできるのか
- Ollamaではなく、プロジェクト内のLiteLLMを使えるのか
- Open WebUIと比べて何が違うのか
- Knowledge／RAGは使えるのか
- Claude Codeのようなエージェント処理になるのか
- Tailscaleで安全に公開できるのか
- ローカル実行にいくらかかるのか
調査日は2026-08-07。今回作成した検証用リポジトリは次の通り。
関連するX投稿
Cloudflare OSに関する今回の調査・検証に関連する投稿も、あわせて参照できるようにしておく。
先に結論
Cloudflare OSは「普通のOS」ではない
Cloudflare OSは、会社やチームの仕事をAIで進めるためのワークスペースであり、一般的なPC用OSではない。公式ブログのタイトルは Cloudflare OS: an open platform for agents, apps, and work で、上流READMEでは次の3つが中心機能として説明されている。
- エージェントに作業を依頼するチャットUI
- エージェントに作らせるサンドボックス型アプリ「Gadget」
- エージェントとアプリの外部アクセスを制御するGatekeepers
上流ソースは cloudflare/cloudflare-os で公開されている。
今回の検証結果
| 確認項目 | 結果 |
|---|---|
| ローカル起動 | Docker Composeで起動できた |
| カスタムモデル | LiteLLMのOpenAI互換エンドポイントを登録できた |
| 通常チャット | 成功。ただし知識不足による誤回答も確認 |
| Knowledge／RAG | Open WebUI同等の画面はローカル版で未確認 |
| エージェント | Gadget作成、ファイル書き込み、コード実行、テストを確認 |
| Tailscale | tailnet限定のHTTPSアクセスを確認 |
| 本番セルフホスト | 今回は未検証。ローカル開発・調査用の構成 |
一言でまとめると、Open WebUIの置き換えというより、
依頼を書く → エージェントがアプリを作る → 実行する → Draftをレビューする
という流れを中心にした環境だった。
1. まずCloudflare OSを起動する
上流READMEには pnpm run-local によるローカル起動方法がある。今回は、上流ソースをリポジトリへ含め、LiteLLMも同じDocker Composeプロジェクトへ組み込んだ。
構成は次の通り。
Browser
│ http://localhost:8877 または Tailscale Serve
▼
Cloudflare OS container
│ http://litellm:4000/v1
▼
project-local LiteLLM container
│
▼
configured model providers
起動手順
git clone https://github.com/Sunwood-ai-labs/cloudflare-os-home.git
Set-Location cloudflare-os-home
Copy-Item .env.example .env
notepad .env
docker compose up --build -d
ブラウザーで http://localhost:8877 を開く。.envには少なくとも LITELLM_MASTER_KEY を設定する。実際のAPIキーやAWSプロファイルはリポジトリへ保存しない。
初期ホーム画面では、Workspace、Blueprints、Outputs、Exploreなどの作業単位が見える。
2. LiteLLMをOllamaの代わりに使う
今回のポイントは、Ollamaを新しく用意するのではなく、既存のLiteLLM構成をプロジェクト内へコピーして完結させたことだ。
Cloudflare OSのコンテナから見たAPI URLは、ホストの localhost ではなくComposeのサービス名を使う。
http://litellm:4000/v1
UIの「Add AI Model」からOpenAI互換モデルを登録する。
- Model ID:
glm-4.7 - Display Name:
LiteLLM · glm-4.7 - API Token:
.envのLITELLM_MASTER_KEY - API URL:
http://litellm:4000/v1
検証では、LiteLLMの認証付き /v1/models から26個のモデルIDが返り、Cloudflare OSから glm-4.7 を登録して応答を得られた。
役割分担は明確だった。
| コンポーネント | 担当 |
|---|---|
| Cloudflare OS | Workspace、エージェントループ、Gadget、ツール実行、Draft |
| LiteLLM | OpenAI互換API、モデルルーティング、プロバイダー切り替え |
glm-4.7 |
今回の実験で実際に応答したモデル |
つまり、エージェント性を作っているのはLiteLLMではなく、Cloudflare OS側のagent loopとツール定義である。
3. 通常チャットとKnowledge／RAG
最初に「Cloudflare OSとは？」と質問したところ、画面は正常に動いたが、モデルはCloudflare OSを存在しない仮想OSのように説明した。
この結果から分かるのは、次の2つだ。
- 通常の質問は、ツールを使わずLLMの文章回答だけで完了できる
- チャットが動くことと、製品知識が正確であることは別問題
リロード後も会話は残った。
Knowledge／RAGについての注意
上流READMEには「会社の運営方法についての知識をあらかじめ持ったエージェント」という思想が説明されている。しかし、今回のローカル版でOpen WebUIのKnowledge collectionのような登録画面や、文書をアップロードしてRAG検索する画面は確認できなかった。
したがって、今回の結論は次のようになる。
- Cloudflare OSの思想として、会社の知識・ツール・データをエージェントに扱わせる方向性はある
- しかし、ローカル版でOpen WebUI同等のKnowledge／RAG機能を実証したわけではない
- 最新情報や社内文書を根拠付きで回答させるには、別途コンテキスト注入、Gatekeeper、ツール、検索基盤などの設計が必要
比較対象のOpen WebUIには、公式ドキュメント上、Knowledge、RAG、Knowledge付きのWorkspace Modelsがある。
4. Open WebUIとの比較
| 観点 | Cloudflare OS | Open WebUI |
|---|---|---|
| 主目的 | エージェント、アプリ、業務の実行環境 | LLMチャット・モデル利用・Knowledgeの統合UI |
| 基本単位 | Workspace / Gadget / Output | Chat / Model / Knowledge |
| カスタムモデル | OpenAI互換APIの登録を実測 | Workspace Model／モデルプリセットが豊富 |
| Knowledge／RAG | 上流の思想はあるが、ローカル画面は未確認 | Knowledge Base、ファイル、RAGを公式に提供 |
| エージェント | agent loop＋Gadgetツールを実測 | Tools、Functions、Pipelines、Computerなどで構成 |
| コードを書いてアプリ化 | Gadgetが中心機能 | 標準の中心ではなく、機能や拡張で実現 |
| コード実行 | AgentのCode Mode／Gadgetで実測 | 構成やComputerなどの利用形態による |
| 人間のレビュー | Pending changesのAccept／Discardを実測 | 機能・拡張ごとに異なる |
| 向いている用途 | 作って、実行して、成果物を残す | 会話して、検索して、モデルを使う |
Open WebUIは「Knowledge付きのモデルを作って使う」体験が明確で、Cloudflare OSは「エージェントにアプリを作らせる」体験が強い。両者は似たAI UIに見えるが、中心に置いている単位が違う。
5. Tailscaleでtailnet限定公開する
Tailscale Serveを使うと、Funnelで一般公開せず、tailnet内だけへHTTPSで公開できる。
$env:CFOS_PUBLIC_BASE_URL = 'https://<your-tailnet-host>:8877'
$env:CFOS_BACKEND_HOST = '<your-tailnet-host>:8877'
docker compose up -d --force-recreate cloudflare-os
.\scripts\enable-tailscale-serve.ps1
検証したものは次の通り。
- Tailscale URLのHTTPSレスポンス 200
- Tailscale URLからのログイン
- Tailscale経由のチャット
- リロード後の状態保持
- モバイル幅の表示
今回の構成では、Tailscale Serveの先をCloudflare OSの8877番ポートへ向けた。Funnelは使っていないため、一般インターネットへ公開する構成ではない。
6. Claude Codeのようなエージェントになるのか
ここが一番重要な検証だった。
単純な質問では通常チャットで終わるが、作業内容を具体的にし、実行を要求すると、Cloudflare OSはツールを使うエージェントとして動いた。
実際に送った指示は次の通り。
Act as a coding agent, not a chat-only assistant.
Create a minimal Gadget named "Agent Proof" with a page that displays
"2 + 2 = 4". Use your available coding tools to create the files and execute
a test. Do not merely explain how; perform the tool work first, then summarize
the files and test result.
実際に確認できた処理は次の通り。
createGadget
writeFile / editFile
executeCode
Wrote 2 files, ran code
server.js
client.js
Gadget accessible: true
依頼送信、途中のGadget結果、完成後のDraftを順番に撮影した。
この実験で確認できたのは、単なる回答生成ではない。
ユーザーの依頼
↓
会話履歴 + エージェント用システム指示 + 利用可能ツール
↓
LLMがツール呼び出しを選択
↓
Gadget作成 → ファイル書き込み → コード実行
↓
結果をLLMへ返す
↓
最終回答 + 変更Draft
Claude Codeと似ている点は、モデルが文章を返すだけではなく、ツール呼び出し、ファイル変更、実行、結果確認まで行うことだ。
違いは、今回のCloudflare OSがホストPC上の任意リポジトリを直接編集するのではなく、サンドボックス内のGadgetを中心に扱う点にある。生成変更は Pending changes になり、 Accept changes または Discard でレビューできる。
エージェントに動いてもらう依頼文
質問ではなく、作業の完了条件まで書くとツール呼び出しが起きやすい。
文章だけで説明せず、まず実行してください。
必要ならGadgetを作成し、ファイルを書き、コードを実行・テストしてください。
失敗したら修正して再実行し、最後に変更ファイル・実行結果・未完了点を報告してください。
7. セルフホストと費用
今回の構成は「ローカルで動かすためのセルフホスト型ラボ」と考えるのが正確だ。
| 構成要素 | 費用の考え方 |
|---|---|
| Cloudflare OSソース | ローカル利用で固定のSaaS利用料は発生しない。Apache-2.0の上流ソースを使用 |
| Docker／ローカル実行 | PCのCPU、メモリ、ストレージ、電気代 |
| LiteLLM | ソフトウェア自体はローカル実行可能 |
| モデルAPI | 接続先プロバイダーの従量課金。ローカルモデルならAPI課金なし |
| Tailscale | 利用するプランとtailnetの条件による |
| Cloudflareマネージドサービス | Workers、AI、ストレージ等を別途使う場合は別料金 |
重要なのは、Cloudflare OSをローカルで起動しただけで、CloudflareのSaaS料金が自動発生する構成ではないことだ。ただし、モデルAPIやTailscale、Cloudflareの追加サービスを使えば、それぞれの料金が発生する。
上流READMEにも、ローカル起動は試すための方法であり、本番サーバー運用向けではないと書かれている。今回のDocker Composeも、本番workerdセルフホストの完成形ではなく、再現可能な開発・検証環境として扱うべきだ。
8. セキュリティと公開範囲
公開リポジトリへ入れたのは、ソース、設定テンプレート、検証スクリプト、個人情報を除いたスクリーンショットだけだ。
次のものは公開対象外にした。
.env- AWSプロファイル
- APIキー、パスワード、Workspace ID
- 実際のTailscaleホスト名
- 元のX投稿スクリーンショット（個人情報・第三者投稿を含むため）
Tailscaleで公開するときも、tailnet-onlyのServeに限定し、Funnelを使わない。認証と公開範囲は別の層なので、URLを知っているだけでアクセスできる構成にはしない。
9. 再現したい人向けの確認ポイント
起動後は、最低限次を確認できる。
docker compose config --quiet
.\scripts\verify-project-litellm.ps1
エージェント検証を再現する場合は、認証情報を環境変数へ直接設定する。
$env:CFOS_USERNAME = 'your-local-account'
$env:CFOS_PASSWORD = 'your-local-password'
$env:BASE_URL = 'http://localhost:8877'
node .\qa\agentic-gadget-smoke.mjs
検証結果の一覧は QA.md、調査の全ログは RESEARCH-LOG.md、全スクリーンショットは artifacts/screenshots にまとめている。
まとめ
今回分かったことは、Cloudflare OSを「チャットUI」としてだけ見ると本質を見誤るということだった。
- LiteLLMをプロジェクト内へ置けば、OpenAI互換モデルを接続できる
- 通常チャットは動くが、Knowledge／RAGが自動で付くわけではない
- 具体的な作業依頼では、Gadget作成、ファイル変更、コード実行、テストまで進む
- Tailscale Serveでtailnet内だけへ公開できる
- ローカル実行自体にCloudflare SaaS料金は自動発生しない
- ただし、今回の構成は本番用セルフホストではなく、検証用のローカルラボである
Open WebUIが「モデル、会話、Knowledgeを使いやすくまとめる」方向なら、Cloudflare OSは「エージェントにアプリを作らせ、実行し、成果物を残す」方向が強い。
Knowledge／RAG、外部サービス接続、長時間自律タスクまで本格運用するには、ローカル版で未検証の領域を別途設計・検証する必要がある。