@Maki-HamarukiLab(Maki Sunwood AI Labs.)

Cloudflare OS Homeを徹底検証してみた：単純チャットからAgent Workflow、社内検索、MCPまで

Last updated at 2026-08-11Posted at 2026-08-10

Cloudflareが公開した「Cloudflare OS: an open platform for agents, apps, and work」を見て、私が作ったCloudflare OS Homeで実際に何ができるのかをローカル環境で検証した。

この記事での用語

Cloudflare OS：Cloudflareが公開している元プロジェクト。公式ブログと公開リポジトリで紹介されているAgent向けプラットフォーム。
Cloudflare OS Home：私がCloudflare OSを自分のPCで動かすために作った、非公式のセルフホスト構成／ランタイム。自作リポジトリでDocker Compose、プロジェクト内LiteLLM、Tailscaleなどをまとめている。
Cloudflare OS Home Lab：今回の実験結果、詳細ログ、スクショを保存する別リポジトリ。

以下では、Cloudflareが公開した機能は「Cloudflare OS」、私が作った実行環境全体は「Cloudflare OS Home」と書き分ける。

最初の疑問は単純だった。

これはOpen WebUIのようなチャット画面なのか。セルフホストできるのか。Agentは本当にアプリを作って動かせるのか。

そこから、Docker Compose、プロジェクト内LiteLLM、Tailscaleでローカル環境を組み、GLM-4.7 / GLM-5.2を接続した。さらに、Slides、共同ホワイトボード、Context Library、共有権限、Revoke、タスク管理Gadget、Agent Workflow、自作Streamable HTTP MCPまでを、実画面・実データ、コード／README監査、未確認事項に分けて記録した。

この記事は、2026-08-07〜2026-08-09（JST）に行った、ここまでの実験を一つにまとめた長編版である。公開済みのX投稿だけでなく、投稿していない検証、途中で失敗した操作、コードから確認した機能、まだ実証できていない範囲も含める。個別の操作ログや原寸スクショは、Cloudflare OS Home Labに残している。

先に結論

私が作ったCloudflare OS Homeは、Cloudflare OSを単純なLLMチャットUIとして動かすだけでなく、次のループを回すためのローカルAIワークスペースにしたものだった。

依頼を書く
  ↓
Agentがツールを選ぶ
  ↓
Gadgetのコード・UI・データを作る
  ↓
サンドボックスで実行・テストする
  ↓
人間がDraftを確認してAcceptする
  ↓
共有・検索・外部接続・MCPへ広げる

今回の検証で、次のことは実画面または実データで確認できた。

Cloudflare OSを自分の環境で動かすために作ったCloudflare OS Homeを、Docker Composeでローカル起動できる。
Cloudflare OS Home内のCloudflare OSから、同じComposeプロジェクト内のLiteLLMをOpenAI互換APIとして使える。
Tailscale Serveでtailnet内限定のHTTPS公開ができる。
Agentにファイル作成、コード実行、テスト、修正を行わせられる。
Agentは共同編集アプリ、Slides、タスク管理アプリをGadgetとして生成できる。
Context LibraryでMarkdown文書を検索し、本文を読んで根拠付き回答を返せる。
Gadget only共有、Collaborator、Realtime同期、Revoke後のreload拒否を確認できる。
タスク管理GadgetをAgentの作業記憶・進捗DBとして駆動できる。
自作のStreamable HTTP専用MCPを接続し、読み取りと承認付き書き込みをAgent loopに組み込める。

一方で、まだ「完全なClaude Code型の長時間Workflow」や「Open WebUIと同じ意味でのベクトルRAG」とは言えない。長時間実行、再試行、スケジュール、外部サービスの本番権限、PDF・画像検索、MCPの認証と複数ユーザー境界は未確認である。

1. Cloudflare OSとは何か

出発点は、Cloudflare公式ブログの次の記事だった。

Cloudflare OS: an open platform for agents, apps, and work

調査の出発点として、私が公開した関連X投稿も参照した。

この記録の判定ラベル

記事内では、証拠の強さを混ぜないため、次の基準で書き分けている。

表記	意味
実画面／実データで確認	ブラウザ操作、保存状態、同期、テスト結果などを実際に観測した
コード／README監査	上流ソース、UI、公開README、パッケージ構成から存在を確認した。実運用の成功を意味しない
条件付きで確認	特定のモデル、ローカル構成、Gadget実装、単発実行など、条件を限定すれば確認できた
未確認	今回は実行していない、または証拠が足りず断定しない

紹介文から受ける印象は、通常の「モデルを選んでチャットするUI」ではない。会社の知識、ツール、内部データをAgentから扱い、アプリや業務を作っていくためのプラットフォームである。

実際のホーム画面にも、質問への回答だけでなく、Outputやアプリ作成へ進む導線がある。今回の検証では、Cloudflare OSを次の3層に分けて考えると理解しやすかった。

層	役割
Workspace / Chat	依頼、会話、Agentへの作業指示
Agent / Tool loop	ファイル操作、コード実行、検索、外部接続、MCP呼び出し
Gadget / Output	実際に使えるアプリ、データ、Slides、成果物

最初の通常チャットは、かなり普通だった

最初に「Cloudflare OSとは？」とだけ尋ねたところ、LiteLLM経由のモデルはCloudflare OSを存在しない仮想OSのように説明した。

これはアプリの故障ではない。ツールも検索も追加コンテキストも使わず、モデルの記憶だけで答えた結果だった。つまり、Cloudflare OSを使えば自動的に最新情報や社内情報を知っているわけではない。

この失敗が、後のContext LibraryとAgentic検索の検証につながった。

初期セットアップでは、ログイン画面、モデル登録後の画面、reload後に会話が残る状態も保存した。つまり、最初から高度な検索ができたのではなく、モデル接続・会話保存・通常チャットを確認してから、AgentとContextへ進んだ。

2. ローカル構成：Docker Compose + LiteLLM + Tailscale

今回実際に動かしたのは、Cloudflareのマネージド版ではなく、Cloudflare OSを自分の環境で動かすために私が作ったCloudflare OS Homeである。Cloudflareが公開したCloudflare OSそのものと、私のCloudflare OS Homeは別物である。

構成

Browser / Mobile
      │
      │ localhost または Tailscale Serve
      ▼
Cloudflare OS Home container（内部でCloudflare OSを実行）
      │ http://litellm:4000/v1
      ▼
project-local LiteLLM container
      │
      ▼
GLM-4.7 / GLM-5.2 などのOpenAI互換モデル

Ollamaを前提にせず、既存のLiteLLM構成をCloudflare OS Homeのプロジェクトフォルダ内へコピーして、Cloudflare OS Home内のCloudflare OSからDockerネットワーク上のlitellm:4000へ接続した。

LiteLLMのモデル一覧取得、OpenAI互換モデルの登録、実際のチャット応答まで確認できた。

初回のモデル一覧取得では26モデルが返り、その中からGLM-4.7／GLM-5.2を検証用モデルとして選んだ。LiteLLMはモデルルーティングとOpenAI互換APIの境界であり、Agent loopやGadget生成そのものを提供しているわけではない。Agent性はCloudflare OS側の処理である。

Tailscaleでの公開

Tailscale Serveを使い、tailnet内限定のHTTPS URLからCloudflare OS Homeへアクセスした。

tailnet内のHTTPSレスポンス: 200
Tailscale URLからログイン: 成功
Tailscale URLからチャット: 成功
モバイル幅の表示: 確認済み
Funnelによる一般公開: 未使用

この構成で大事なのは、「URLを知っている人なら誰でもアクセスできる」公開ではなく、Tailscaleのtailnet境界内に閉じた配信にした点である。

再現条件

私が作ったCloudflare OS Homeのランタイムは、検証記録リポジトリとは分離したcloudflare-os-homeで管理している。基本的な起動手順は次の通り。

git clone https://github.com/Sunwood-ai-labs/cloudflare-os-home.git
Set-Location cloudflare-os-home
Copy-Item .env.example .env
# .envにLITELLM_MASTER_KEYと利用するモデル経路のキーを設定
docker compose config --quiet
docker compose up --build -d

起動後はhttp://localhost:8877を開き、初回ローカルアカウントを作成する。Cloudflare OS Home内のCloudflare OSのモデル登録画面から、Composeネットワーク内のLiteLLM endpoint http://litellm:4000/v1と、LiteLLMが公開するglm-4.7またはglm-5.2を登録する。

Tailscaleは任意のtailnet-only経路である。実際のホスト名はリポジトリへ保存せず、次のような環境変数を設定してCloudflare OS Homeのサービスを再作成し、補助スクリプトを実行する。

$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

初期アカウント、APIキー、OAuth秘密情報、Tailscaleの実ホスト名は記事へ保存しない。検証用GadgetとContext文書は、実験ごとにseed・入力・期待値・cleanupを分離して記録した。

いくらかかるのか

今回のローカル構成では、私が作ったCloudflare OS Homeを動かすだけでCloudflare SaaS料金が自動発生するわけではない。以下は費用の構造整理であり、実際のAPI請求額、トークン数、Tailscaleの契約料金、電気代を計測したものではない。

要素	費用の考え方
Cloudflare OS Home（自作ランタイム）	それ自体の固定利用料は確認していない。Cloudflare OSの上流ライセンス条件と、PC・依存ソフトの運用条件は別途確認が必要
Docker Compose	PCのCPU、メモリ、電気代
LiteLLM	ソフトウェア自体はローカル実行可能
モデル	接続先APIの従量課金。ローカルモデルならAPIトークン課金なし
Tailscale	契約プランと利用条件に依存
Cloudflareのマネージドサービス	Workers、AI、ストレージ等を使う場合は別料金

したがって、費用構造として中心になるのは、選択したモデルプロバイダのAPI料金と、ローカルPC・Tailscaleの運用条件である。私が作ったCloudflare OS Homeと、Cloudflareが提供するマネージド版の料金・機能・制限は別物として扱う必要がある。

ローカル起動で確認できた範囲

上流READMEも、ローカル起動は「試すため」の経路であり、本番用途ではないと説明している。また、workerd上で自分のサーバーへ配備する手順は整備中とされている。今回のDocker Composeは、ローカル検証環境としては動作したが、Cloudflareのマネージド版相当の本番セルフホスト性や、workerd本番運用までを証明したものではない。

3. Open WebUIとの違い

Cloudflare OS Home（内部で動くCloudflare OS）をOpen WebUIの置き換えとして見ると、少し違和感がある。Open WebUIはチャット、モデル、Knowledge、RAGをすぐ使える点が強い。一方、Cloudflare OSのAgent機能は、アプリを作らせ、コードを実行し、成果物を残す側へ重心がある。

観点	Cloudflare OS Home	Open WebUI
主目的	Agent、アプリ、業務の実行環境	LLMチャットとモデル利用の統合UI
基本単位	Workspace / Gadget / Output	Chat / Model / Knowledge
通常チャット	可能	得意
カスタムモデル	OpenAI互換APIを画面登録して確認	モデル設定・プリセットが豊富
コードを書いてアプリ化	中心機能。Gadgetを生成	標準の中心機能ではない
Agent loop	ファイル、コード、検索、接続、MCP	Tools / Functions / Pipelines等で構成
Knowledge	Context Libraryとして実装。明示的に検索・readする	Knowledge / RAGが分かりやすい
検索方式	今回のContextは部分一致・線形走査	構成によりEmbedding / Vector検索
共有	Workspace、Gadget only、Buildなどの境界	機能・拡張ごとに異なる
人間の確認	Pending changes、Accept / Discard、Tool承認	操作や拡張機能ごとに異なる
向いている仕事	作る、実行する、共有する、状態を残す	会話する、検索する、モデルを使う

結論として、Cloudflare OS Homeで動くCloudflare OSは「チャット画面」として使うより、「Agentが仕事を進める作業環境」として使う方が特徴を活かせる。

なお、この表は同一バージョン・同一データ・同一モデルで速度、品質、費用を測ったベンチマークではない。Cloudflare OS Home（自作ランタイム）とOpen WebUIの思想・標準導線を、今回のローカル検証で見えた範囲から定性的に比較したものである。

Cloudflare OSとCloudflare Computerは同じものか（未投稿・概念調査）

実験の途中で、Cloudflare Computerも比較対象として調べた。これはCloudflare OSを実際に接続・起動した検証ではなく、公開リポジトリのREADMEとパッケージ構成を読んだコード／公開情報監査である。X投稿用の比較図も作ったが、投稿はしていない。

公開情報を役割で整理すると、次のようになる。

観点	Cloudflare OS	Cloudflare Computer
位置づけ	Agent Chat、Gadget、Blueprint、Gatekeeper、共有を組み合わせる製品・体験レイヤー	Durable ObjectとSQLiteを権威状態にする仮想ファイルシステム・実行基盤
Agentとの関係	Agentが文書を作り、アプリを生成し、ツールを呼び、承認を待つ	Agentが使う作業ディレクトリ、fs操作、runtime.execの受け皿になり得る
実行面	Cloudflare OS側のCode Mode、Gadget、Gatekeeper	Container、Worker shell、Worker JavaScriptの3バックエンド
状態	Workspace、Gadget、共有状態、Contextなど	Durable Object上のSQLite-backed VFS、fs、相対import、Git／Artifacts連携の公開入口
今回の実験	Cloudflare OS Home上でDocker Compose、LiteLLM、Tailscale、Gadget、Context、MCPを実画面で検証	ローカル接続・統合・性能は未検証。公開READMEの機能整理のみ

したがって、「ComputerがCloudflare OSの中身そのもの」「OSとComputerを接続済み」とは言えない。今回確認できたのは、OSは人間とAgentが使う製品レイヤー、ComputerはAgentに永続的なWorkspaceと実行バックエンドを与える基盤レイヤー、という役割分担の仮説である。公式統合、相互運用、同一の本番構成、性能差は別途検証が必要になる。

画像は実画面スクショではなく、公開README・パッケージ構成を調べて作ったAI生成の概念図である。実測値、UI、公式統合を示す証拠ではない。Cloudflare Computer側も公開READMEではPreview only・本番非推奨とされているため、これを本番採用判断へ直結させない。

Cloudflare OS本体・生成Gadget・自作MCPの違い

今回の記事で扱う機能は、すべてCloudflare OS標準機能というわけではない。また、Cloudflare OS Homeは私が作った実行環境のまとめであり、Cloudflareが作った別製品ではない。ここを混ぜると、読者が「Cloudflare OSに標準タスク管理や標準ホワイトボードがある」と誤解するため、次のように分けている。

層	今回の実体	何を証明する実験か
Cloudflare OS本体	Workspace、Agent loop、Gadget生成、Gatekeeper、共有、Context接続、承認UI	Agentがアプリや外部Toolを扱うための実行環境
Cloudflare OS Home（自作構成）	Docker Compose、LiteLLM、Tailscale、環境変数、起動・公開スクリプト	Cloudflare OSを自分の環境で起動し、モデル接続とtailnet内配信を組めるか
Agent生成Gadget	共同ホワイトボード、Slides、権限検証タスクボード、Agent作業台	Agentがコード・UI・状態・テストを生成し、実行できるか
自作MCP	Streamable HTTPのタスク管理サーバー、ローカルJSON	外部プロセスのToolをGatekeeper経由で接続できるか

したがって、タスク管理Gadgetや共同ホワイトボードの機能数はCloudflare OSの標準機能一覧でも、Cloudflare OS Homeに最初から備わる機能一覧でもなく、今回Agentへ作らせたアプリの実装範囲である。

4. 通常チャットからAgentへ

Agentに明示的な作業を依頼する

単に説明を求めるのではなく、次のように「まず実行する」依頼を送った。

文章だけで説明せず、まず実行してください。
必要ならGadgetを作成し、ファイルを書き、コードを実行・テストしてください。
失敗したら修正して再実行し、最後に変更ファイル・実行結果・未完了点を報告してください。

実際にAgentは、次の処理を行った。

Gadgetを作成
server.jsとclient.jsを書き込み
コードを実行
テスト結果を取得
DraftとPending changesを表示
人間がAccept changesして確定

処理の実体は、次のようなAgent loopである。

ユーザーの文章
  ↓
会話履歴 + Agent用システム指示 + 利用可能なTool
  ↓
LLMがTool呼び出しを選ぶ
  ↓
createGadget / writeFile / editFile / executeCode
  ↓
実行結果をLLMへ返す
  ↓
必要なら修正・再実行
  ↓
最終回答とDraftを表示

これは単に「Agentっぽい文章」を返している状態とは違う。ファイル変更、実行結果、テスト、Draftという外部状態が残るため、何をしたかを後から確認できる。

上流のAgent loopは、確認した実装上では最大30ターンまで、Tool処理はsequentialに進む。これは検索→read→追加検索のような複数段階を可能にする一方、無限に自律実行するWorkflowエンジンという意味ではない。実験中にも、GLM-4.7がContext検索とreadを繰り返し続けたため、こちらで停止したケースがあった。

Slidesのコード実行やContext検索では、単発のリトライ・検索語調整は観測できた。しかし、長時間停止後の再開、耐久的な再試行、スケジュール実行、失敗した外部副作用の重複防止までは検証していない。

ただし、任意のホストPCリポジトリをClaude Codeのように直接操作するものではない。今回の中心は、Cloudflare OS内のサンドボックスとGadgetだった。

5. Slides生成を検証する

最初のGLM-4.7実験

まずSlides Blueprintへ、Cloudflare OSの検証結果を日本語6枚で作るよう依頼した。

確認できたことは多かった。

Slides GadgetのDraft生成
プレビュー、Slides、Code、Connections、Edit、Presentの切り替え
server.js / client.jsの読み取りとexecuteCode
Accept changes後の保存

一方、失敗も分かりやすかった。

依頼は6テーマだったが、最終的に7枚になった。
末尾スライドに[TITLE]、[SUBTITLE]などのテンプレート文字列が残った。
executeCodeの結果取得に失敗し、Agentが何度かリトライした。
Export to PDFのボタンは見えたが、実ダウンロードは確認できなかった。

つまり、「スライドGadgetを作る」ことと、「要求仕様を満たした完成資料として自動判定する」ことは別だった。

Tailscale経由の6枚実験で分かったこと

別途、Tailscaleのtailnet-only URLから同じSlides導線を実行した。初期テンプレート4枚をAgentがクリアし、次の6タイトルを持つDraftを生成した。

Cloudflare OSのローカル検証
ローカル構成
確認できた機能
Gadgetエージェントの実行フロー
Open WebUIとの違い
制約と次の検証

途中でCloudflare OSコンテナの再起動とWebSocket再接続が発生し、Agentの最終応答は途中停止した。それでもDraftを開くと6枚が残っており、Accept後の1 / 6と6 / 6も画面で確認できた。ここでは、Agentの完了文よりも生成物の枚数・タイトル・保存状態を画面で照合する必要があることが分かった。

Tailscale経路での6 / 6
コンテナ再起動・再接続を含む途中状態
最初のAgent実験のDraft状態（Pending changesの表示であり、これ単体ではAccept後の永続化を証明しない）

この初回6枚実験も、検証結果をXへ公開した。初回の公開チェーンは、メイン投稿、5〜6枚目の続き、検証リポジトリへの導線という構成だった。

初回Slidesメイン投稿

初回Slides・続きの返信

初回Slides・検証ログ返信

GLM-5.2で内容重視に再実験

次にモデルをLiteLLM経由のGLM-5.2へ切り替え、8枚、各スライドにタイトル・リード文・具体的な本文・構成図・比較表・検証カードを入れる条件にした。

生成された最終8枚は次の構成だった。

Cloudflare OS Home × GLM 5.2
前回の課題と今回の合格条件
Browser / Tailscale → Cloudflare OS → LiteLLM → GLM 5.2
依頼からAccept changesまでの実行フロー
編集可能なGadgetとして保存される仕組み
Open WebUIとの違いと未確認範囲
8枚生成の検証カード
実運用に向く範囲と次の検証

目視確認で、表紙のコントラストとプレースホルダーを修正した。修正後は、8枚維持、プレースホルダー0件、レイアウトのオーバーフロー0件、Accept後の再表示を確認できた。

検証カードのV06は「今回の作成で確認予定／要再検証」という留保を含む。8 / 8、本文あり、プレースホルダー0件、目視調整、Accept後の再表示は確認できたが、再接続完了文の安定性やPDF出力まで確認済みという意味ではない。

ここでのポイントは、GLM-5.2に変えたら完全自動になった、ということではない。モデルを変えても、生成後の枚数、本文、プレースホルダー、保存状態は人間が画面で確認する必要がある。

GLM-5.2版の公開スレッドは、画像を4枚ずつに分け、前回投稿URLとリポジトリURLを本文から分離した。

GLM-5.2 Slidesメイン投稿：1〜4枚目

前回投稿を参照する返信

GLM-5.2 Slides続編：5〜8枚目

検証ログ・リポジトリ案内の返信

6. Gadget Lab：アプリを作るだけで終わるのか

Gadgetが本当にアプリ実行単位として使えるのかを確認するため、共同ホワイトボードGadgetを題材に8段階の実験を行った。

#	実験	結果
1	既存Gadgetの改修と帰属情報	presence、付箋、描画、イベントへ表示名・色・clientIdを追加。Smoke test PASS
2	意図的なバグと自己修復	テストを意図的に失敗させ、原因を切り分け、Agentが修正して再実行
3	永続化と物理reload	付箋、描画、イベント数がリロード後も復元
4	同じ付箋の競合編集	Durable Objectの到着順で直列化され、後着パッチが勝つ
5	共有と権限	`Gadget only`の共有入口と、同じGadgetの状態共有を確認
6	Blueprint再利用	Blueprintから新しい空のGadgetを生成
7	外部接続カタログ	Confluence、Email、GitHub、Google、Home Assistant、Linear、MCP Server、Notion、Slack、Spotify、Supabase、ZoomInfoなどの入口を確認。OAuth・実データ接続は未作成
8	安全境界	不存在IDや異常patchを拒否し、実データとeventSeqが不変

6.1 Agentによる生成と自己修復

共同ホワイトボードは、固定のホワイトボード機能を開いたのではなく、Agentへ「共同ホワイトボードアプリを作って」と依頼して生成したGadgetである。

Agentは、共有状態、イベント連番、presence、購読通知、永続化、付箋、描画、消去、Smoke testを実装した。

途中では、次の失敗が発生した。

writeFileの引数エラー
Durable Object Storage APIの複数キー読み出しの誤認
テスト式だけが誤って失敗するケース

具体的には、最初のクライアント書き込みでAgentがwriteFileへfilenameだけを渡して失敗した。その後、サーバー側でctx.storage.get([keys])の戻り値を配列のように扱っていたため、次のエラーが出た。

TypeError: Cannot set properties of undefined (setting 'n_87hg9rtr')

AgentはストレージAPIの戻り値を調べ、複数キー読み出しを個別get()へ変更し、_loadedPromiseによるロードガードと個別put()へ修正した。

重要なのは、失敗が起きなかったことではない。ログを読み、原因を切り分け、修正して再実行し、最終的に22項目のSmoke testをpassed=trueにできたことである。

6.2 永続化・同期・競合

2つのブラウザタブを同じGadgetへ接続し、次の状態を確認した。

users: 2
events: 19
notes: 6
strokes: 3

タブBで追加した付箋はタブAへリアルタイム反映され、リロード後も付箋、描画、イベント数が復元された。

同じ付箋をAliceとBobが同時更新する競合テストでは、Durable Object内でRPCが直列化され、Object.assign(note, patch)による後着パッチが勝った。フィールド単位のマージではなく、最後に届いた編集が全体を上書きする実装だった。

送信順を反転したケースは5回繰り返し、5/5で先に送った側ではなく、後着したAliceのパッチが最終状態を獲得した。これは「同時編集を安全にマージした」結果ではなく、到着順を基準にしたlast-write-winsの観測である。実際の2物理ブラウザ、ネットワーク遅延、切断復帰を含む競合はまだ確認していない。

115は同期の観測途中にエラー送信トーストと「not run yet」表示が残る証拠画像である。最終成功状態の確認には、次の一次スクショも併用した。

この結果から、Gadgetは「見た目のモック」ではなく、状態、イベント、購読、永続化を持つ小さなアプリとして動かせることが分かった。同時に、競合解決ポリシーはGadget側で設計しなければならないことも分かった。

6.3 安全境界のnegative test

Gadget Labの安全境界では、次の小さな異常入力を実データへ当てた。

存在しない noteId への updateNote → null
存在しない noteId への deleteNote → false
存在しない strokeId への deleteStroke → false
空ID、過長ID、想定外のpatch型
setDisplayName の空入力フォールバックと32文字切り詰め
getState、getStatus、binding構造のキー確認。秘密値は出力しない

前後で eventSeq、notes、strokes、既存ID、本文が変わらず、Gadget内部の入力拒否と状態不変性を確認できた。ただし、これはGadget実装のnegative testであって、Cloudflare OS全体のセキュリティ監査ではない。未ログイン拒否、別Workspaceの認可、巨大ペイロード、高度な攻撃耐性は確認していない。

Agentの報告と画面の事実が食い違ったケース

共有実験の途中、Agentがアクセス確認の前処理としてclearAll（イベント#134）を実行し、既存のSmoke Test付箋と線を消した。Agentの最終報告は「元データは無傷」だったが、実画面はnotes: 0 / strokes: 0で、報告と一致しなかった。

手動で付箋と線を復元し、最終的にevents: 140 / notes: 1 / strokes: 1を確認した。この失敗は、Agentの最終文章をそのまま証拠にせず、画面状態・イベントログ・実データを照合する必要があることを示している。

このGadget Labの8段階実験も公開済みである。共同ホワイトボードの共有実験から続く、作る・壊す・直す・再利用する編として、次の4投稿に分けた。

Gadget Labメイン投稿

共有・Blueprint・外部接続・安全境界の返信

前回投稿を参照する返信

検証ログ・リポジトリ案内の返信

7. 複数ユーザー共有と権限・Revoke

最初の別アカウント実験

Gadget only共有リンクを別アカウントで開き、CollaboratorがGadgetを使えるか確認した。

Collaborator側では、OwnerのWorkspaceにあるChat、Code、Connections、Shareは表示されず、GadgetのUIだけが利用できた。一方、GadgetがRPCとして公開していた付箋追加は実行できた。

付箋追加後、約2.3秒でOwner側へ同期し、次の値を確認した。

events: 21
notes: 7
strokes: 3
users: 3

users: 3には、前回検証のpresenceがheartbeat期限まで残るという遅延も含まれていた。

Revokeは「画面から消えた」だけでは判定しない

最初のホワイトボード実験では、Share modalのRevoke操作で実行コンテキスト関連のエラーが出た。そこで、後から権限とRevokeだけを切り出し、複数キー、既存セッション、reload、新規セッション、親子共有まで再検証した。

専用の再検証では、次のことを確認できた。

useユーザーはWorkspaceの管理UIを見られない。
Gadget内の操作は、Gadgetが公開したRPCの範囲で可能。
共有リンクをRevokeすると、既存キー2本とも再読み込み後に拒否された。
Revoke直後のiframeは一時的に見た目が残るが、失効後の入力はOwnerへ同期されなかった。
Buildユーザーが作った子リンクは、親Buildユーザーを削除すると通常は下流ユーザーも失効する。
keepUsersを使うと、下流ユーザーをOwner直下へ再ルート化して残せる。

Buildロールでは、OwnerのContext接続を暗黙に使うことはできなかった。Collaborator自身がcontext://libraryへConnect → Verify and openし、Context / Readyを確認してからWorkspaceを開く必要があった。接続が存在するだけでなく、共有Workspaceが実際に読んだcollectionへ到達できることが確認条件になっている。

親子共有では、親Buildユーザーの削除時にJoined throughの経路が表示され、keepUsersなしでは親・子の両方が失効した。子ユーザーをKeepすると、親は失効する一方、子はAccess from 2 sourcesとしてOwner直下へ再ルート化された。その後に子リンクをRevokeしても、直接付与された子ユーザーのアクセスは残った。

権限グラフだけでは「失効後に拒否された」ことまでは分からないため、reload後の一次証拠も併記する。

ホワイトボード以外でも再検証

同じ共有モデルがホワイトボード固有ではないかを確認するため、Slides、Context Library Workspace、タスク管理Gadgetでも確認した。

対象	観測
Slides	Collaboratorはページ送りとアプリ内Edit入口を使えた。Workspace管理UIは見えず、Revoke後reloadは拒否
Context Library	OwnerのPrivate collectionはWorkspace共有だけでは暗黙共有されなかった
タスクボード	Collaboratorがtoggle/create/deleteでき、Ownerへ同期。Revoke後reloadは拒否

Slidesでは、Collaboratorが1 / 8から2 / 8へページ送りでき、Owner側のページ位置は変化しなかった。Edit (E)から一時的に3 / 9へスライドを追加し、Undoで2 / 8へ戻した。アプリ内編集UIの表示までは確認したが、その編集結果がサーバーへ永続化されるかは未確認である。

Contextでは、Collaborator側がUsing your account / Context / Readyまで進んでも、Ownerが読んだPrivate collectionへ到達できない場合はVerify again後に拒否された。これは、Context接続の有無と、個々のcollectionを観測する権限が別であることを示す。

ここで分かったのは、Gadget onlyは「常に読み取り専用」という意味ではないことだ。許可される書き込み範囲は、共有ロールだけでなく、Gadgetが公開するUIとサーバーRPCで決まる。

また、権限変更の完了判定には、画面が変わったかではなく、reloadまたは新規セッションで拒否されることまで確認する必要がある。

別アカウント共有とリアルタイム同期の公開スレッドは、GLM-5.2 Slides編の続編として公開した。

共同ホワイトボード共有実験メイン投稿

前回Slides投稿を参照する返信

Collaborator追加・Owner同期・Revoke注意点の返信

検証ログ・リポジトリ案内の返信

8. Knowledge機能と社内ドキュメント検索

Context Libraryはあるのか

調査前は、Cloudflare OSにOpen WebUIのKnowledgeと同じような機能があるのか分からなかった。上流コードを確認すると、Context Library（Context & Skills）が実装されていた。

ただし、通常の/context画面を開けばすぐ使えるわけではない。Gatekeepers / ConnectionsからContextを有効化すると、サイドバーにContext & Skillsが現れる構成だった。

Context Libraryで確認できる機能は次の通り。

collectionを作る
Private / Publicの境界を分ける
Markdown、テキスト、JSON、YAML、CSV、HTML、コード、画像、PDFなどを保存する入口（上流コード／UIで確認。今回の投入はMarkdown 3件のみ）
文書ごとに「いつ使う文書か」を記述する
Agentからsearch、list、readを呼び出す
collectionのカタログとAgent Skillを参照する

実際に3件の文書を検索する

検証用に、Private collection cloudflare-os-home 社内ナレッジを作成し、次のMarkdownを登録した。

文書	内容
`agentic-search-runbook.md`	Context検索の運用手順
`slides-experiment.md`	GLM-5.2 Slidesの検証記録
`operations-tailscale.md`	Docker Compose、LiteLLM、Tailscale Serveの運用

今回のブラウザ環境ではローカルファイル選択イベントを利用できなかったため、Upload filesではなくContext UIのNew fileで文書を作成した。これはContextのアップロード機能がないという意味ではなく、今回の検証環境で採用した代替手順である。機密資料は投入せず、実験用ダミー文書だけを使った。

Agentには、タグ検索と自然文検索の両方を行わせた。タグ検索では、Context catalog、collection一覧、検索、本文readの順序が実行履歴に残った。

これは元スクショに操作内容を付けたHyperFrames説明画像であり、一次証拠そのものではない。対応する生スクショは、search／read完了、GLM-5.2の回答、自然文検索の回答である。

最初のGLM-4.7は、検索とreadを繰り返し続けた。11回のコード実行、31回のresource readになったところで停止した。

その後GLM-5.2へ切り替え、「既存の検索結果を使い、追加ツール呼び出しを最大2回に限定」と指示すると、2回のコード実行、8回のresource readで完走した。collection名、ファイル名、ヒット数、本文要点、未確認点を回答できた。

この画像も説明用スライドであり、実画面の原寸証拠は上記の105および107である。

説明用スライド自体にも検証が必要だった。Context LibraryのHyperFramesでは、最初にネストしたtimelineが重なって表示される問題と、モバイル表示でサムネイルが2×2になり小さくなる問題が出た。timelineを単一化し、モバイルでは1列へ修正してから再キャプチャした。これも、説明画像は自動生成すれば終わりではなく、読みやすさを実画面で確認する必要がある例である。

自然文からの再検索

「TailscaleでCloudflare OSを社内公開する手順を調べてください」と依頼したところ、最初の検索語では0件だった。

Agentは検索語を「Tailscale 社内公開 operations」へ調整し、候補を再検索してoperations-tailscale.mdをreadした。最終回答には、Docker起動、Tailscale Serve、アクセス範囲、.envをGitへ入れない注意が含まれた。

これは、

自然文の依頼
  → 検索語の生成
  → 0件
  → 検索語を調整
  → 候補文書をread
  → 根拠付き回答

というAgentic retrievalの実例だった。

ただし、Context Libraryの検索自体は今回確認したコードではベクトル検索ではない。ファイル名、説明、本文の部分一致を線形走査し、簡易スコアを返す方式である。Open WebUIで想像しがちなEmbedding / Vector DB / Reranking型のRAGと同じものだと考えてはいけない。

エージェンティック検索の範囲

上流コードと実画面の両方を確認した範囲では、Cloudflare OSは検索・本文取得・追加調査を組み合わせる土台を持っている。ただし、専用の「Deep Research」モードがあるわけではない。

Context Libraryのsearch / list / readをAgentが順番に呼ぶ。
既知の公開URLはwebFetchで読む。これは検索エンジンではない。
GitHub、Google、Slack、Notion、MCPなどは、Gatekeeperで明示的に接続したリソースだけをAgentへ渡す。今回、OAuthを作成して実サービスのread/writeまで行ったわけではない。
複数ソースの照合、信頼度評価、引用の自動整形は、今回の標準UIでは保証されない。
「Tailscale URLを貼るだけ」で社内検索できるわけではない。

今回の実験で実証したのは、既知のContext文書を検索してreadするAgentic retrievalであり、未知のWeb情報を検索エンジンから発見するAgentic researchではない。この区別は記事やX投稿で混同しないようにした。

社内文書運用の現実的な境界

Private collectionは所有者限定の設計として扱われる。今回の実画面ではWorkspace共有だけで暗黙共有されなかったが、別ユーザーの直接アクセスを網羅的に測ったわけではない。
チーム共通の規程やガイドは、公開範囲を確認したPublic collectionへ分ける。
TailscaleのURLを貼っただけではKnowledgeにならない。
Agentが読めるようにContextへアップロードするか、読み取り専用のGatekeeper / MCPを用意する。
回答にはcollection名、ファイルパス、該当箇所を出させる。
「見つからない」と言うべきケースも検証する。

今回まだ確認していないのは、Public collectionを別アカウントから読む権限、Git mirrorによる継続同期、PDF・画像本文の解釈、引用UIの自動表示である。上流コードに入口があっても、ローカルComposeで実際に動くこととは分けて判定した。

Context Libraryの実験結果は、説明スライド9枚と証拠スクショを使って、次の5投稿へ分けて公開した。記事では、X投稿に載せきれなかった初回GLM-4.7の反復、検索実装の限界、Private collectionの境界も含めている。

Context Libraryメイン投稿

検索・read・回答の証拠返信

結論スライド返信

前回Gadget投稿へつなぐ返信

検証ログ・リポジトリ案内の返信

9. タスク管理Gadget：簡易ボードとしての実用性

次に、ホワイトボード以外のユースケースとしてタスク管理Gadgetを作った。これはCloudflare OSの標準タスク管理機能ではなく、Agentに生成させた検証用Gadgetである。

CRUDと同期の検証

最初のseedは、設計、実装、検証の3件。次のケースを実画面で確認した。

ケース	結果
空白だけの追加	拒否。3件のまま
日本語・絵文字・長いタイトル	保持
完了切替	カウンターが`合計4 / 未完了3 / 完了1`へ変化
物理reload	タスクと完了状態を保持
サーバーテスト	`PASSED — 20/20 checks`
2接続のtoggle/create/delete	両画面へリアルタイム同期
Revoke後reload	Collaboratorは拒否

なお、最初のUI追加操作は一度反映されなかった。Owner画面をreloadしてから再実行すると、日本語・絵文字を含む追加、完了切替、reload後の保持まで安定した。過去のテスト実行に由来するexecution context系の捕捉エラーも残っていたため、タスク台の判定では「最初のクリックが通ったか」だけでなく、reload後の再確認を必須にした。

現時点では、共有チェックリストとしては成立している。しかし、担当者、期限、優先度、フィルター、タイトル編集、競合ルール、オフライン復帰は不足している。チーム向けプロジェクト管理ツールと呼ぶにはまだ早い。

10. Agent Workflow：タスク台帳を作業記憶にする

タスクボードのCRUDを確認しただけでは、単純なアプリテストに留まる。そこで同じGadgetをAgentの作業記憶・進捗DBとして使えるかを検証した。

追加したフィールドとRPC

status: todo / in_progress / blocked / done
priority
assignee
dueDate
result
evidence
updatedAt
updatedBy

Agent向けには、次のRPCを追加した。

createTask
updateTask
claimTask
startTask
blockTask
completeTask
getState
getCounters
subscribe

旧形式の{ id, title, done }データは削除せず、初回読込時に新スキーマへ移行した。

実際にAgentへ仕事をさせる

仕事のテーマは「Cloudflare OS実験の公開準備チェック」。Agentに4件へ分解させた。

目的と今回の差分を整理
必要な証拠スクショを確認
README / 実験ログの不足点を確認
公開前チェック結果をまとめる

各タスクを、create、claim、start、block、復帰、completeのRPCで更新した。4件完了後は、seed 3件を含めてtotal=7 / todo=3 / done=4となった。

さらにblocked状態を画面で証明するため、補助タスクを一つ追加した。

create → claim → start → block
total=8 / todo=3 / blocked=1 / done=4
              ↓
          startで復帰
              ↓
           complete

Agentが完了結果と証拠を持つ状態は、evidence付き完了画面、48/48のUIテスト、最終ボードでも確認した。

完了タスクにはresultとevidenceが表示され、監査ログにはcreateTask、claimTask、startTask、blockTask、completeTaskとby=agentが残った。

Agent実装後のSmoke testは、最初は44/47だった。原因は、合法なblocked → in_progress復帰を拒否としてassertしていたことと、監査ログを最新10件だけ検索していたことだった。assertionと検索範囲を修正して48/48 checksへ到達し、UIの「テストを実行」からも同じPASSED 48/48 checksを確認した。

この修正過程も、Agentが最初から正しいテストを書いた証拠ではない。状態機械の仕様とテストの期待値を人間が照合し、誤ったassertionを直した結果である。監査ログには保持上限があり、UIは最新ウィンドウを表示するため、完全な履歴を判定するときはサーバー側の保存データを別途走査した。

ここで分かった限界

assigneeは担当表示であり、認証・排他ロックではない。
dueDateは保存できるが、今回のAgentは過去日付を設定した。期限の入力検証が必要。
専用RPCでは状態遷移を検証できたが、自由編集用のupdateTaskはstatus上書きを許していた。
複数Agentの競合、オフライン復帰、外部成果物リンクの検証は未実装。
長時間停止、再開、リトライ、スケジュール実行は未確認。

したがって、「AgentがGadgetを進捗DBとして駆動できる」は実証できた。しかし、「Gadget単体がClaude Codeのような長時間・承認付き・再試行可能Workflowになる」とまでは言えない。

このAgent Workflow実験は、Context Library実験の続編として5投稿に分けて公開した。記事では、投稿画像に入りきらなかった状態遷移の実装差分、48/48の修正過程、期限とassigneeの限界も補足している。

Agent Workflowメイン投稿

タスク分解・進捗の返信

blockedからの復帰の返信

前回Context Library投稿を参照する返信

検証ログ・リポジトリ案内の返信

11. 自作タスク管理MCPを接続する

ここで、Gadget内のRPCだけでなく、外部MCPとしてAgentへツールを公開できるかを検証した。

方針

今回のMCPは、実験用に最小構成で自作した。

Streamable HTTP専用
stdio互換コードは持たせない
保存先はローカルJSON
タスク操作だけを公開
外部サービスやクラウドDBは使わない

実装は別フォルダのtask-manager-mcp-streamable-httpに分離した。

MCPの構成

GLM-5.2 via LiteLLM
        │
        ▼
Cloudflare OS Agent
        │ Gatekeeper / 承認
        ▼
http://host.docker.internal:18788/mcp
        │
        ▼
自作タスク管理 MCP
        │
        ▼
data/tasks.json

項目	内容
Transport	Streamable HTTP
Endpoint	`/mcp`
Health check	`/healthz`
Storage	`data/tasks.json`
Tools	`list_tasks` / `add_task` / `complete_task`
認証	今回はなし。ローカル検証専用

MCPの再現条件

MCP単体の既定ポートは8787だが、今回のCloudflare OS接続実験では、OS側の接続先に合わせて18788番で起動した。

Set-Location D:\Prj\task-manager-mcp-streamable-http
npm install
$env:MCP_HOST = '0.0.0.0'
$env:MCP_PORT = '18788'
npm test
npm start

単体テストではinitialize、tools/list、タスク追加、完了処理まで確認済みである。一方、Cloudflare OSのAgent側で承認付き実行まで確認したのはlist_tasksとadd_taskであり、complete_taskのAgent承認は未確認として残した。

Agent loopの実画面確認

Agentのツール一覧には list_tasks、add_task、complete_task が現れたが、実画面で承認付きの書き込みまで確認したのは add_task である。complete_task はMCP単体テストで完了処理を確認しただけで、Agent側の承認キュー経由の実行は未確認として残した。

GatekeepersからMCP Serverを登録。
Cloudflare OS側で接続をSet up。
Agentがlist_tasks、add_task、complete_taskを発見。
list_tasks(status=todo)を実行し、未完了0件を取得。
add_taskは書き込み操作として承認待ちになる。
ユーザーがApprove。
ローカルJSONへ週次レポートの作成を保存。
Agentが再読込し、未完了1件として報告。

この2枚が証明するのは、list_tasksの読み取りと、add_taskの承認付き書き込み・再読み取りである。complete_taskのAgent承認は、この画像からは証明していない。

これは、単純なチャット応答ではない。

ツール発見
  → list_tasks
  → add_taskを承認待ち
  → Approve
  → JSONへ保存
  → list_tasksで再確認
  → Agentが結果を報告

読み取りは即時実行され、書き込みはMCP tool annotationによって承認キューへ入った。MCPを通じても、Cloudflare OSの「Agent + Tool + Human approval」という設計が成立することを確認できた。

未確認のMCP領域

Agentからのcomplete_taskが承認キューに入るか
複数ユーザーのデータ分離
認証付き公開
Tailscale越しの外部アクセス
長時間実行と再試行

検証用のMCP_ALLOW_INSECURE=trueはローカル接続のためだけに使い、本番公開用設定とは扱っていない。

このMCP実験は、Agent Workflow GadgetからMCPへ実行境界を切り出した続編として、4投稿に分けて公開した。

自作タスク管理MCPメイン投稿

Gatekeeper接続確認の返信

list → add（承認）→ 再読込の返信

Agent WorkflowからMCPへ切り出した続編の返信

12. 証拠の残し方：生スクショと説明画像を分ける

今回の実験では、「スクショを撮った」だけでは、何を見ればいいのか分からない問題が何度も起きた。そこで証拠を二層に分けた。

一次証拠

Cloudflare OSの実画面をそのまま保存する。

元スクショは加工しない
UIのエラーや途中状態も残す
実験単位でディレクトリを分ける
秘密情報、トークン、認証情報は公開前に除外する

説明用ビジュアル

HyperFramesで、元スクショの横または下に短い説明を付ける。

何を操作したか
何が変化したか
どの数字が結果か
何がまだ未確認か

説明画像は、一次証拠の代替ではない。元画像と説明画像を分離して保存することで、「見やすさ」と「証拠性」を両立した。

実験ごとの一次証拠と説明画像

代表画像だけを見て結論を広げないよう、元スクショとHyperFrames説明画像の対応も残しておく。

実験	一次証拠	説明画像・ギャラリー
GLM-5.2 Slides	表紙の公開用マスク版、検証カード	screenshots内の生成後・Accept後画像
Whiteboard / Gadget Lab	Smoke test、reload、最終状態	Gadget Lab HyperFrames
Context Library	Agentic search完了、回答、自然文検索	Context Library HyperFrames
権限 / Revoke	reload後拒否、新規セッション拒否	権限PNG群。専用HyperFramesギャラリーは未作成
Agent Workflow	evidence付き完了、48/48、最終ボード	Agent Workflow説明ギャラリー
自作MCP	Gatekeeper接続、Agent結果	X投稿シミュレーターは説明用であり、一次証拠ギャラリーではない

内部URL・tailnetホスト名・共有リンクなどを含む原寸画像は、公開前に画像単位でマスク要否を確認する。記事に置いた画像は、可能なものから公開用マスク版へ差し替えている。

X投稿への応用

Xへ出すときは、1投稿4枚制限を前提にした。

メイン投稿は結論と最初の証拠
返信は直前の投稿へ直列接続
前回投稿URLは説明返信へ分離
画像は3:2に揃える
URLを本文へ詰め込みすぎない
元スクショを隠すほど加工しない

X APIと下書きの境界

今回の投稿ワークフローで作ったpayload.jsonは、Xアカウントの公式下書き箱ではなく、ローカルで管理する承認前データである。

通常ポスト・返信・スレッドの公開は、X APIのPOST /2/tweetsで行える。
公開APIに、通常ユーザーのX公式下書きへ保存・取得するエンドポイントは確認できない。
X Articles（長文記事）の作成・下書きは、Premium系プランのx.com Articles画面から行う仕様で、今回の公開API連携には含めていない。
Ads APIのDraft Tweetsは広告用の別機能であり、通常ポストやX Articlesの下書きとは別物である。

参照: X API Manage Posts、X公式「記事」、X Ads API Draft Tweets

公開済みの実験は7スレッド、合計29投稿ある。各返信URLはそれぞれの実験章へ配置し、ここではメイン投稿をカード表示できる裸のURLで掲載する。

初回Slides（GLM-4.7）

内容重視Slides（GLM-5.2）

共同ホワイトボード共有

Gadget Lab 8段階

Context Library検索

Agent Workflowタスク作業台

自作タスク管理MCP

今回のMCP投稿は、メイン1枚、接続確認1枚、説明返信2件という構成で、投稿後に親子関係・画像枚数・URL展開まで確認した。

ローカル投稿シミュレーターと実投稿の対応

リポジトリ内の payload.json は、すべてX公式の下書きではなく、投稿前のローカルシミュレーションである。後から実際に投稿したものと、シミュレーションだけで終わったものを分けると次の通りになる。

シミュレーター	status	その後の扱い
Gadget Lab	simulation	後にGadget Labの公開スレッドへ反映
Context Library	simulation	後にContext Libraryの公開スレッドへ反映
Agent Workflow	simulation	後にAgent Workflowの公開スレッドへ反映
自作タスク管理MCP	simulation	後にMCPの公開スレッドへ反映
Cloudflare OS × Computer比較	simulation	X投稿は実施していない。概念比較として本記事にのみ収録

この区別を明記しておかないと、ローカルで生成した「投稿案」を公開済みURLと誤認してしまう。公開済みと判定したのは、本文・投稿ID・添付・返信関係をX側で確認できた29件だけである。

投稿済みの内容と、記事で追加した未投稿検証

Xでは画像枚数・文字数・読みやすさの制約があるため、公開スレッドは結論と代表証拠に絞った。この記事には、専用投稿を作っていない検証や、投稿に入りきらなかった失敗・未確認範囲も含めている。

区分	この記事で扱う内容
X公開済み	初回Slides、GLM-5.2 Slides、共同ホワイトボード共有、Gadget Lab、Context Library、Agent Workflow、Streamable HTTP MCP
専用投稿なし・記事で補足	初回の通常チャット誤回答、セルフホスト構成、費用、Open WebUI比較、LiteLLM/Tailscaleの細部
詳細ログのみ・記事で補足	ホワイトボード生成中の失敗、22項目Smoke test、競合のlast-write-wins、Blueprint再利用、外部接続カタログ、安全境界
Xより詳しく掲載	29枚の権限・Revoke実験、Slides / Context / タスク台の横断権限、タスクCRUD 20/20、Agent作業台48/48
未投稿・概念調査	Cloudflare OSとCloudflare Computerの公開README／パッケージ構成比較、AI生成の概念図。実画面・統合・ベンチマークではない
未確認として掲載	PDF実出力、長時間Workflow、MCPの認証・複数ユーザー境界、`complete_task`のAgent承認、外部サービスread/write

13. Cloudflare OSでできること／まだ言えないこと

ここまで実証できたこと

領域	判定
ローカル起動	✅ Docker Composeで確認
LiteLLM接続	✅ OpenAI互換APIとして確認
Tailscale配信	✅ tailnet内HTTPSで確認
通常チャット	✅ 動作。ただし検索なしでは知識不足が出る
Agent / Code Mode	✅ ファイル、実行、テスト、修正、Acceptを確認
Gadget生成	✅ ホワイトボード、Slides、タスク台を確認
Realtime同期	✅ タブ・Collaborator・タスク台で確認
Context Library	✅ Private collection、Markdown、search → readを確認
Agentic retrieval	✅ クエリ調整を含む検索→read→回答を確認
共有・Revoke	✅ reload後拒否まで確認。既存画面の過渡状態に注意
Agent作業DB	✅ 状態遷移、blocked復帰、result/evidence、監査ログを確認
自作MCP	✅ Streamable HTTP、add_taskの承認付き書き込みを確認

まだ未確認・断定しないこと

Cloudflareのマネージド版の正式料金・機能差
PDFや画像を含む大規模な社内検索
ベクトルRAGやEmbedding検索としての性能
引用表示の自動整形と、複数文書の厳密な根拠追跡
外部サービスの実OAuth、read/write承認、監査、Revoke
長時間Agent Workflowの停止・再開・再試行・スケジュール
複数ユーザーでのMCPデータ境界と認証
complete_taskのAgent側承認
SlidesのPDF実ダウンロード検証
Blueprintの版管理、独立性、更新伝播

14. 最終的な評価

Cloudflare OS HomeをOpen WebUIと同じ尺度だけで評価すると、「Knowledge画面はどこか」「チャットは普通ではないか」という見方になりやすい。

しかし、Agentに次の仕事をさせると性格が変わる。

社内文書を検索する
  ↓
本文を読む
  ↓
根拠を付けて回答する
  ↓
タスクへ分解する
  ↓
進捗・ブロック・完了結果を記録する
  ↓
必要ならMCPを呼び、書き込みは人間が承認する

この図は、Context Library、Agent Workflow、MCPの別々の実験結果を概念的につないだものであり、単一のAgent実行で「検索→タスク分解→MCP書き込み」まで一気通貫に成功したことを示すものではない。

今回の検証で一番大きかった発見は、Cloudflare OSの価値が「高性能なチャット画面」ではなく、Agentが扱う状態と成果物を、Gadget・Context・Gatekeeper・MCPへ拡張できる点にあることだった。

逆に言えば、Gadgetの品質、RPCの認可、入力検証、競合解決、検索クエリの作り方、承認境界は、作る側が責任を持つ必要がある。Cloudflare OSが用意してくれるのは、Agentがそれらを扱うための作業環境であって、業務アプリの設計を自動的に完成させる魔法ではない。

どちらを選ぶべきか

やりたいこと	向いている選択
既存モデルで会話・Knowledge検索をすぐ始めたい	Open WebUI
Agentにアプリを生成させ、コードを実行・テストしたい	Cloudflare OS Home
社内文書を明示的に検索し、パス付きで根拠を残したい	Context Library + Agent prompt
共有アプリを少人数で試したい	Cloudflare OSのGadget + `Gadget only`
業務データを外部Toolとして公開したい	Streamable HTTP MCP + Gatekeeper
本番の長時間・再試行・スケジュールWorkflowを運用したい	今回の検証だけでは判断不可。追加検証が必要

現時点の結論は次の一文にまとめられる。

Cloudflare OS Homeは、単純チャットの代替というより、Agentにアプリ・文書・タスク・外部ツールを扱わせ、人間の確認を挟みながら仕事を進めるためのローカル実験基盤として面白い。

15. 再現・詳細ログ・証拠

この記事は全体像を読むための統合版であり、操作の完全な時系列や原寸スクショはテーマ別のログに分けている。

証拠画像は次のディレクトリに保存している。

スクショ一覧／Tailscale限定ギャラリー
artifacts/screenshots/：Cloudflare OSの原寸スクショ
artifacts/permission-revocation-20260809/：権限・Revokeの証跡
artifacts/permission-cross-usecase-20260809/：Slides、Context、タスク台の横断検証
artifacts/agent-task-workflow-20260809/：Agent作業台の証跡
artifacts/mcp-task-manager-20260809/：自作MCPの実画面証拠
artifacts/hyperframes/：説明用のHyperFramesソースと静止画

公開リポジトリや記事へ出すときは、.env、APIキー、OAuth秘密情報、共有リンクの秘密fragment、ブラウザプロファイル、tailnet専用ホスト名を含めない。スクショに残った接続先も、公開用コピーではマスクする。

次に検証したいこと

次は、自作タスク管理MCPをさらに実用へ近づける。

Agentからcomplete_taskを実行し、承認と再読込を確認する。
複数タスク、優先度、不正ID、重複追加を確認する。
複数ユーザーのデータ境界を確認する。
認証付きでTailscale越しに公開する。
Context LibraryへPDF・画像・実文書を少量投入する。
Browser / MCP / 外部Gatekeeperのread-only境界を確認する。
停止・再開・リトライを含むdurableなAgent Workflowを検証する。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up