Abstract（要旨）

Cloudflareが公開したOSS「Cloudflare OS」をMacで動かし、現在の実行モデルをQwen3.8-27B Q4_K_Mへ切り替えて再測定しました。旧9B・20B・Qwen3.5-27Bの結果も比較対象として残し、モデル性能とCloudflare OS自体の価値を切り分けて検証します。

名前からブラウザ上のデスクトップOSやAI付きノートブックを想像しがちですが、実際に触って一番しっくりきた説明は、次のものでした。

AIに毎回答えさせるのではなく、一度だけ自分用の小さな業務アプリを作らせる場所

検証した問いは、次の3つです。

同じ仕事を繰り返すと、本当にAIチャットより有利になるのか
Qwen3.8-27B Q4へ替えると、構造化出力・ツール実行・汎用Agentはどう変わるのか
作ったアプリを共有したとき、コードだけでなく実行中のデータまで混ざらないのか

先に結論をまとめます。

反復作業: 一度Gadgetにすれば、普段の画面操作・集計・絞り込みはLLMを呼ばずに実行できる
Qwen3.8-27B Q4: 短い構造化出力は none で5/5成功・中央値5.595秒、1回だけのツール実行は low で5/5成功・中央値26.209秒
Cloudflare OS Agent: 「固定文字列だけ返す」依頼には正答したが、直接APIより大幅に遅い約4分。モデル単体とAgent全体は別々に測る必要がある
ハードウェア適合: 16Kコンテキストでは実行時18GB、23% CPU / 77% GPU。新世代でも24GB機へ完全には載らない
思考設定: 短いJSONを low / 128 tokensで実行すると5/5とも最終回答を返せず、Qwenでは用途別に思考を切り替える必要が残った
共有: Blueprintはコードを再利用できる一方、状態と会話は利用者ごとに分離される
向き・不向き: 毎日使う小さな社内ツールには面白いが、単発の質問やローカルモデルへの丸投げには向かない

なお、Cloudflare OSはローカルLLM専用ではありません。公式READMEにも、主要なAIプロバイダーとセルフホストモデルの両方からLLMを選べると明記されています。本稿がOllamaを使うのは検証スコープをローカルへ限定したためで、速度の数値はM5・24GBメモリ上のこの組み合わせについての結果です。

したがって、本稿では評価対象を次の3層に分けます。

評価する層	本稿で確認すること	数値を一般化できる範囲
Cloudflare OS本体	Gadgetによる推論回数削減、Blueprintの分離、権限境界	モデルを替えても残るプラットフォーム上の性質
Agentとの統合	長い文脈、ツール選択、結果解釈	Cloudflare OSと各モデル・設定の組み合わせ
ローカル推論	速度、出力安定性、メモリ適合性	今回のマシンとOllama構成のみ

ローカルモデルが遅い、または出力に失敗した結果だけで、Cloudflare OS自体の評価を下げるのは適切ではありません。反対に、強いリモートモデルならプラットフォーム設計上の課題まで消える、とも限りません。OSSの価値と、選んだ推論基盤の性能を分離して見ることが、この記事の前提です。

この記事の持ち帰りは、特定製品のベンチマーク結果だけではありません。モデルを実務へ入れるときは、モデルの大小より先に、LLMを呼ぶ回数・仕事の狭さ・失敗時の権限を設計する必要があるという点です。

Cloudflare OSを30秒で理解する

Cloudflare OSには、主に次の3要素があります。

Agent: 会話しながら調査したり、コードを書いたりするAI
Gadget: Agentが作る、UI・ロジック・状態を持った小さなアプリ
Gatekeeper: 外部サービスへのアクセス範囲や承認を管理する接続層

通常のAIチャットとの違いを簡略化すると、次のようになります。

通常のAIチャット
  質問 → LLMが考える → 回答
  質問 → LLMがまた考える → 回答

Cloudflare OS
  要望 → LLMがGadgetを作る
                ↓
       以後は普通のアプリとして反復利用
                ↓
       判断が必要な箇所だけLLMを呼ぶ

Cloudflare自身も、v1では毎朝ほぼ同じレポートをAgentに再生成させ、数千トークンを消費していたと説明しています。v2ではAgentにダッシュボードのコードを書かせ、初期レポートの表示をゼロトークンにしています。

参考: How we’re rethinking work at Cloudflare with Cloudflare OS

検証環境

初回検証日は2026年8月30日、Qwen3.8での追試は2026年9月1日です。Cloudflare OSは変化が速いため、バージョンによって挙動が変わる可能性があります。

項目	内容
マシン	MacBook Pro / Apple M5 / 24GBユニファイドメモリ
CPU・GPU	10 CPUコア / 10 GPUコア
OS	macOS 26.6.2
Node.js	v25.6.1
pnpm	11.19.0
Ollama	0.33.2
現在のモデル	Qwen3.8-27B Q4_K_M (`qwen3.8:27b-cfos`)
比較に残した旧モデル	Qwen 3.5 9B / gpt-oss 20B / Qwen 3.5 27B
コンテキスト	現在のQwen3.8は16K。旧9Bは32K、旧20B・27Bは16K
Cloudflare OS	commit `af56a9d` をベースにOllama調整を追加

4モデルの実行状態は次のとおりです。サイズは ollama list、実行時メモリとCPU・GPU比率は ollama ps で確認しました。

モデル	保存サイズ	実行設定	実行時の載り方
Qwen 3.5 9B Q4_K_M	6.6GB	32K	100% GPU
gpt-oss 20B MXFP4	13GB	16K	100% GPU
Qwen 3.5 27B Q4_K_M	17GB	16K	87% GPU / 13% CPU
Qwen3.8-27B Q4_K_M	約17GB	16K	77% GPU / 23% CPU

Qwen3.8-27Bの公式モデル情報では27.3B、Q4_K_M、最大コンテキスト262,144です。ただし最大値をそのまま使ったわけではなく、この24GB機では16Kに制限しました。それでもモデルとキャッシュをGPUだけへ載せきれず、実行時は18GB、23% CPU / 77% GPUでした。

まずローカルで起動する

公式リポジトリを取得して、ルートで次を実行します。

pnpm run-local

このコマンドは依存関係のインストール、必要なビルド、ローカルサーバー起動まで行います。起動後は http://localhost:8787 を開きます。

Ollama側は、次のように16Kコンテキストの派生モデルを作りました。

# Modelfile
FROM qwen3.8:27b
PARAMETER num_ctx 16384

ollama create qwen3.8:27b-cfos -f Modelfile

Cloudflare OSのAI Providers画面で、ProviderにOllama、URLに http://localhost:11434、モデル名に qwen3.8:27b-cfos を設定します。

Providerを登録すると、各Workspaceのモデル選択からローカルモデルを指定できます。今回の検証Workspaceでも、選択中のモデルが Qwen 3.8 27B Q4 (Local, 16K) になったことを確認しました。

なお、公式READMEにもあるとおり、pnpm run-local は評価用です。本番サーバー向けの起動方法ではありません。

参考: cloudflare/cloudflare-os

検証1: 毎朝のチケット確認をGadgetにしたらどうなるか

最初に、ITヘルプデスクを想定した「Ops Pulse」というGadgetを作りました。

未完了、P1、待機中、SLAリスクを集計
ステータスで絞り込み
チケットの状態変更
状態を永続化
Agent向けに getAgentBrief() APIを公開

重要なのは、画面表示や絞り込みではLLMを呼んでいないことです。ReactとGadgetのコードが通常のアプリとして処理します。

同じデータをAgentに聞いた場合

比較のため、ローカル9B Agentに次のような単純な依頼をしました。

Incident RoomのAPIを1回だけ呼び、
現在の状態と未完了アクション件数を日本語1文で答えてください。

結果は正しい「監視中、未完了2件」でした。ただし、実行内容を見ると印象が変わります。

実行	完了時間	Gadget API呼び出し	画面上のトークン表示	結果
1回目	33.6秒	2回	8,389 tokens	正解
2回目	90秒時点で未完了	4回	9,137 tokens	直後に正解

2回目では、Agentが最初にプロパティ名を間違え、戻り値を確認し直し、さらに不要な再試行も行いました。小さいモデルでは、答えが簡単でも、汎用Agentとして道具を探して使う処理が重いことが分かります。

一方、Gadgetの画面は同じ集計をコードで表示するため、LLM呼び出しは0回です。

ここから得られたインサイト

Agentは、毎回レポートを作る「実行担当」より、レポート用Gadgetを作る「道具職人」にした方が効率的です。

たとえば、Gadget作成に5分かかると仮定します。毎回Agentに聞く時間が33.6秒なら、約9回の反復で待ち時間の元が取れます。90秒かかるケースなら約4回です。

これはあくまで概算ですが、題材選びの目安になります。

損益分岐の回数 ≒ Gadgetを作る時間 ÷ 1回あたりのAgent待ち時間

月に1回しか行わない仕事なら、普通にAgentへ聞いた方が早いでしょう。毎日・毎週行う仕事ならGadget化が効いてきます。

検証2: Qwen3.8-27B Q4へ切り替えて再測定する

初回記事では9B、gpt-oss 20B、Qwen3.5-27Bを比べました。今回は現在の実行モデルをQwen3.8-27B Q4_K_Mへ切り替え、同じ2本のスクリプトで追加測定しました。旧結果は世代差を読み取る対照として残します。

gpt-oss 20B: 約13GB。Agent、ツール呼び出し、構造化出力を重視したモデル
Qwen 3.5 27B: 約17GB。旧27Bの対照
Qwen3.8-27B Q4_K_M: 約17GB。現在Cloudflare OSへ登録しているモデル

gpt-oss 20Bは公式に16GBメモリでも動作可能と案内されています。Qwen 3.5 27BのOllama標準Q4_K_Mは17GBです。

Qwen3.8のOllama公式タグは最大256Kコンテキストですが、ローカルで最大値を使えることを意味しません。今回は旧27Bと揃えて16Kに制限しました。

参考: Ollama gpt-oss、Ollama Qwen3.8 tags

タスクA: 短い構造化出力

まず、Local Model Routerから使う次の限定タスクを与えました。

判定結果はコード側で確定済み
LLMは理由を日本語2文で説明するだけ
JSONで返す
外部送信は禁止
最終判断は人間

JSON、固定ルート、外部送信の境界、人間の最終判断という4条件をすべて満たせば成功です。

モデル	思考設定	回数	成功	中央値
Qwen 3.5 9B	`none`	5	5/5	1.923秒
gpt-oss 20B	`low`	5	5/5	2.767秒
gpt-oss 20B	`medium`	3	3/3	5.889秒
Qwen 3.5 27B	`none`	3	3/3	11.710秒
Qwen3.8-27B Q4	`none`	5	5/5	5.595秒

新しいQwen3.8は旧Qwen3.5-27Bの中央値11.710秒から5.595秒へ短縮しました。ただし旧値は3回、新値は5回で、初回ロードの影響も含む探索的測定です。9Bの1.923秒よりは遅く、世代が新しくなっても「大きいモデルほど短い仕事に向く」とは言えません。

さらに、同じ思考設定を全モデルへ適用すると失敗しました。

モデル	相性の悪い設定	結果
Qwen 3.5 9B	`low` / 128 tokens	0/5、思考だけで上限へ到達
Qwen 3.5 27B	`low` / 128 tokens	0/3、思考だけで上限へ到達
Qwen3.8-27B Q4	`low` / 128 tokens	0/5、思考だけで上限へ到達
gpt-oss 20B	`none`	0/5、壊れたJSONを返却

Qwenでは短い定型処理を none、gpt-ossでは low 以上にする必要がありました。「Ollama用の共通設定」ではなく、モデルごとの設定が必要です。

タスクB: 1回だけツールを呼ぶ

次に、get_agent_snapshot を1回だけ呼び、monitoring と未完了2件を日本語1文で返すテストを行いました。

モデル	思考設定	回数	成功	中央値
Qwen 3.5 9B	`low`	5	5/5	7.057秒
gpt-oss 20B	`low`	5	5/5	1.846秒
gpt-oss 20B	`medium`	3	3/3	3.358秒
Qwen 3.5 27B	`low`	3	3/3	23.887秒
Qwen3.8-27B Q4	`low`	5	5/5	26.209秒

Qwen3.8は毎回1回だけ正しいツールを呼び、返答も5回すべて同じでした。一方、中央値は旧Qwen3.5-27Bの23.887秒より速くならず、gpt-oss 20Bの1.846秒には大きく及びません。構造化出力の世代差が改善しても、ツール実行の待ち時間まで一緒に改善するとは限らない結果です。

タスクC: Cloudflare OSの汎用Agentとして使う

最後に、検証1と同じIncident Roomへ接続し、Cloudflare OS本体の長いシステムプロンプトとツール群を含めて実行しました。

モデル	設定	結果	時間・挙動
Qwen 3.5 9B	32K / `low`	正解	33.6秒・Gadget 2回
Qwen 3.5 9B	32K / `low`	正解	90秒超・Gadget 4回
gpt-oss 20B	16K / `low`	失敗	38.5秒・1回呼んだが変数を未展開のまま回答
gpt-oss 20B	16K / `medium`	正解	70.6秒・Gadget 1回、事前にコードを1回参照
Qwen 3.5 27B	16K / `low`	未完了	107.6秒で最初のGadget呼び出し、150.9秒で停止
Qwen3.8-27B Q4	16K / `low`	正解	ツールなしの固定文字列に約4分（20:10開始、20:14完了）。長い内部推論の後に `QWEN38_OK`

この実Agent比較は各条件1〜2回の探索的測定であり、時刻表示も分単位なので、統計的・精密なベンチマークではありません。それでも、モデル単体の試験だけでは見えない差がはっきり出ました。Qwen3.8のAgent試験ではツールを使わせていません。したがって約4分には、外部APIの待ち時間ではなく、長いシステム文脈を読んでAgentとして応答するまでのコストが表れています。

20Bはツール再試行を減らしたが、汎用Agent全体では9Bより必ず速いわけではない
Qwen3.8-27Bは直接APIの短い構造化出力なら中央値5.595秒だった一方、Cloudflare OS Agentの固定文字列応答は約4分だった
同じモデルでも、直接APIとAgent経路の差はモデル名の差より大きくなり得る
長いシステムプロンプト、ツール選択、コード生成、結果解釈の負荷は、モデルサイズを上げても残る

ここで評価しているのは、あくまでCloudflare OSと各ローカルモデルを組み合わせたときの使用感です。リモートの上位モデルへ替えた場合は速度、ツール選択、コード生成品質が変わり得るため、この表をCloudflare OSそのものの性能順位として読むことはできません。

ここから得られたインサイト

当初の9Bだけの結果は、確かにモデル性能の制約へ強く引っ張られていました。ただし、上位モデルを試すと、次のように問題を分解できます。

モデル固有の出力不安定性: Qwen3.8は限定ツールを5/5で1回だけ呼べた
統合互換性: 4Kコンテキストのgpt-ossではOllamaストリーム終了エラーが発生し、16K化が必要だった
ハードウェア適合性: Qwen3.8-27Bも24GB機へ完全には載らず、短い処理でも9Bより遅い
Agent設計の重さ: Qwen3.8はツールなしの固定文字列でも約4分。巨大なプロンプト、会話履歴、Agent用出力形式の負荷は、モデル単体の短い試験から予測できなかった

このマシンでの現実的な分担は次のとおりです。

Qwen3.8での短い説明・分類: none
Qwen3.8での限定ツール実行: low。ただし待ち時間を許容できる処理に限定
Gadgetの新規設計や複雑なデバッグ: より強いリモートモデル、またはツールを絞った専用Agent
Qwen3.8-27B Q4: 生成品質を優先する作業用。短い定型処理の常用ルートにはしない

Cloudflare OS側ではQwen3.8のAgent呼び出しを low、短い一発処理を none へ分けました。ただし、汎用Agentで遅い仕事を直接APIの結果だけから「実用」と判定しないようにします。

再測定に使ったスクリプトは2本です。

OLLAMA_MODEL=qwen3.8:27b-cfos \
BENCH_REPEATS=5 \
BENCH_MODES=none,low \
node scripts/benchmark-ollama-reasoning.mjs

OLLAMA_MODEL=qwen3.8:27b-cfos \
BENCH_REPEATS=5 \
BENCH_REASONING_EFFORT=low \
node scripts/benchmark-ollama-tool-use.mjs

Ollamaの思考設定については公式のOpenAI互換API資料も参照してください。

参考: Ollama OpenAI compatibility

検証3: Blueprintは本当にデータをコピーしないのか

Cloudflare OSでは、Gadgetの再利用単位を「Blueprint」と呼びます。

普通のSaaSでは、全員が中央の同じアプリを使います。Blueprintでは、利用者ごとにアプリのコードを複製し、それぞれが独立した状態を持ちます。

一覧に公開されたBlueprintから、新しいWorkspaceを作って分離を確認しました。

実際に次の操作をしました。

Ops PulseをBlueprintとして公開
Blueprintから新しいGadgetを作成
元Gadgetのチケットを5件から6件に増やす
コピー側のチケット件数と会話履歴を確認

結果は次のとおりです。

項目	元Gadget	Blueprintから作ったコピー
初期チケット	5件	5件
元だけ更新後	6件	5件のまま
元の会話履歴	あり	0件

コピーされたのはアプリのコードで、稼働中の状態は独立していました。

公式ドキュメントでも、BlueprintにはSQLiteの内容、AIチャット履歴、認証情報、稼働中の接続は含まれないと説明されています。

参考: Blueprints documentation

これは便利ですが、デメリットもあります。現在は、Blueprintを更新しても既存コピーへ自動配信する仕組みがありません。利用者ごとに自由に改造できる代わりに、バージョンが分岐しやすい設計です。

セキュリティは何が違うのか

AI生成コードを自由に動かすなら、モデルの賢さより先に「失敗したときの被害範囲」が問題になります。

Cloudflare OSの実装と公式資料では、次の境界が置かれています。

GadgetのサーバーはDynamic Workerで動き、globalOutbound: null
GadgetのUIはsandboxed iframe内で動作
AgentとGadgetは、最初は外部リソースへアクセスできない
外部サービスは、明示的に渡したCapability経由でのみ利用
GatekeeperがOAuth、対象範囲、監査、書き込み承認を仲介

つまり「生成コードが安全だから信頼する」のではなく、生成コードへ危険な権限を最初から渡さない設計です。

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

ただし、本稿で確認したのはローカル環境の画面挙動と実装上の境界です。外部サービスを接続した状態での侵入テストや、組織全体の権限監査まで実施したわけではありません。

メリット・デメリットを整理する

メリット

繰り返し作業をコード化し、通常操作をゼロトークンにできる
UI、永続状態、Agent向けAPIが一つのGadgetにまとまる
利用者が自分用コピーをAIで改造できる
Blueprintでコードだけを共有し、データと認証情報を分離できる
CapabilityとGatekeeperで外部アクセスを狭くできる
Ollamaなどのセルフホストモデルも選べる

デメリット

一度きりの仕事では、Gadgetを作る時間の方が高くつく
AI生成コードの品質確認や保守は必要
個人ごとのコピーが分岐し、更新管理が難しくなる
外部連携にはGatekeeperやOAuthの設定が必要
2026年8月時点では公式にもEarly Accessと明記されている

今回のローカル構成に固有の制約

Qwen3.8-27B Q4は16KでもGPUへ完全には載らず、23% CPU / 77% GPUとなった
短いJSONは none で安定したが、low / 128 tokensでは思考だけで予算を使い切った
限定ツール実行は5/5成功した一方、中央値26.209秒。Cloudflare OS Agentはツールなしの固定文字列でも約4分かかった

この3点はCloudflare OS一般のデメリットではなく、Qwen3.8-27B Q4、Ollama、24GBメモリ、16Kコンテキストという組み合わせに属します。

Cloudflareは、社内で週次利用者が数千人規模となり、30日間で4,000以上のアプリ・ツールが作られ、営業部門の手作業を推定10,000時間以上削減したと報告しています。ただし、これはCloudflare自身による推定であり、本稿のローカル検証結果とは分けて考える必要があります。

どんな仕事から試すべきか

次のうち3つ以上に当てはまる仕事は、Cloudflare OSと相性がよさそうです。

月に5回以上繰り返す
入力と出力の形がある程度決まっている
現在はCSV、スプレッドシート、複数の管理画面を行き来している
結果を保存・更新したい
人間とAgentが同じ状態を扱う
全社SaaSを導入するほど大きな仕事ではない
外部データのアクセス範囲を狭くしたい

具体例としては、次のようなものです。

チケット・案件・インシデントの状況確認
毎朝・毎週の定型レポート
CSVから作る部署専用ダッシュボード
承認前の変更内容を集める作業台
既存SaaSに足りない小さな管理画面

ダッシュボードだけでなく、次のようなインシデント振り返り文書もGadgetとして扱えます。画面内の日付、影響値、担当チームはすべて検証用のサンプルです。

題材を選ぶときは、「何回繰り返すか」と「人間の判断がどれだけ必要か」の2軸で考えると整理しやすくなります。

仕事の性質	判断が少ない	判断が多い
繰り返しが多い	Gadgetや通常コードを中心にする	Gadgetで事実を集め、LLMが提案し、人間が承認する
繰り返しが少ない	既存のスクリプトやテンプレートを使う	強いモデルとのチャット、または人間が直接対応する

Cloudflare OSが特に効きそうなのは右上、つまり「何度も発生するが、完全な自動化は怖い」仕事です。事実収集と画面操作をGadgetへ移し、曖昧な判断だけをLLMと人間に残せるためです。

反対に、単発の要約、雑談、最新情報の調査だけなら、普通のAIチャットの方が簡単です。

ローカルモデルを安全に使うルール

旧3モデル比較とQwen3.8での追試から、モデルの新しさだけでなく、仕事ごとに役割と権限を限定する分担が現実的でした。

判断はコード、説明はモデルにする
読み取り専用の小さなAPIから始める
query(sql) のような万能APIを渡さない
ID、列挙値、状態遷移をサーバー側で検証する
送信、削除、課金、権限変更は人間が承認する
思考設定はモデルと用途ごとに測る。Qwen3.8の短い定型処理は none、ツール処理は十分な出力予算を確保した low を起点にする
失敗したら権限を増やさず、強いモデルか人間へ上げる

ローカルモデルを安全にする方法は、モデルを全面的に信頼することではありません。仕事、出力形式、道具、権限を狭くすることです。

検証から得られた5つの示唆

ここまでの結果を、Cloudflare OS以外のAIエージェント導入にも使える形へ整理します。

1. AIの費用対効果は「1回答の単価」だけでは測れない

今回もっとも大きかった差は、モデル同士の性能差ではなく、そもそも推論を呼ぶ必要があるかでした。一度Gadgetにした集計や絞り込みは、その後ゼロトークンで動きます。

AI導入の試算では、モデル単価だけでなく「同じ推論を月に何回繰り返すか」を数えるべきです。反復回数が多い処理ほど、回答を安くするより、コードへ移して回答自体を不要にする方が効きます。

2. 「大きいモデルほど実用的」とは限らない

Qwen3.8-27B Q4は短いJSON説明を中央値5.595秒で終えましたが、同じモデルの限定ツール実行は26.209秒、Cloudflare OS Agentの固定文字列応答は約4分でした。旧Qwen3.5-27Bのツール試験23.887秒より速くはなく、24GB機では新世代への更新だけで待ち時間が解消しませんでした。

したがって、パラメータ数だけでは実用性を判断できません。モデルがメモリへどう載るか、タスクとの相性、渡す文脈と道具の量をセットで測る必要があります。ローカルモデルは万能Agentにするより、得意な一工程へ固定する方が価値を出しやすくなります。

3. 思考トークンは無料の知能ではなく、有限の予算である

Qwen3.8の短い説明タスクでは、low が128トークンを5/5とも使い切り、最終回答を返せませんでした。同じ入力を none にすると5/5成功しました。思考量を増やす設定は、難しい問題には役立つ一方、定型処理では遅延と失敗要因にもなります。

用途とモデルごとに思考設定と最大トークンを分け、成功率と待ち時間を実測してルーティングするのが安全です。

4. Blueprintは「配布の簡単さ」と「一括更新」を交換している

コードだけを共有し、状態・会話・認証情報を利用者ごとに分ける設計は、個人向け業務アプリと相性がよいものです。一方、コピー後の改造を許すほど、中央からの一括更新は難しくなります。

導入時には、作る仕組みだけでなく、所有者、変更履歴、再配布、廃止手順まで決める必要があります。これは従来のSaaS運用より、社内スクリプトやテンプレート管理に近い課題です。

5. 小さいモデルの安全性は、賢さより「失敗時の被害」で設計する

モデルが間違えない前提では運用できません。しかし、読み取り専用API、限定された状態遷移、人間の承認、外部通信の禁止を組み合わせれば、間違いが起きても被害を狭くできます。

これはCloudflare OSのCapabilityやGatekeeperに限らない考え方です。AIエージェントを評価するときは、成功率と同時に、失敗した操作がどこまで届くのかを確認する必要があります。

まとめ

Cloudflare OSの面白さは、ブラウザで動く「OS」という名前自体ではありません。

本質は、AIを毎回の回答者から、一度だけ道具を作る人へ移せることです。

Qwen3.8-27B Q4へ切り替えた追試では、短い構造化出力は5/5成功・中央値5.595秒、限定ツール実行は5/5成功・中央値26.209秒でした。一方、Cloudflare OS Agentではツールなしの固定文字列にも約4分かかりました。モデルの更新で限定タスクの出力安定性は確認できましたが、24GB機でのCPUオフロードとAgent経路の重さは残りました。Blueprintはモデルに関係なく、コードを再利用しながら元とコピーの状態・会話を分離できました。

このうち前半のモデル速度はローカル検証の結果ですが、Gadgetで推論を通常コードへ置き換えることや、Blueprintが状態を分離することはCloudflare OS本体の評価です。ローカルモデルの限界を、そのままOSSの限界とは見なしません。

したがって、今回のローカル構成でのおすすめは次の形です。

Qwen3.8-27B Q4は、Gadgetの設計や複雑な提案へ使う。普段の集計・絞り込みはGadgetのコードで動かし、短い定型生成では思考をOFF、外部変更は人間の承認を残す。

完成済みSaaSを置き換えるものというより、Excel、社内スクリプト、使い捨てダッシュボードの次の選択肢として見ると、Cloudflare OSの狙いが理解しやすいと思います。

最初の一歩としては、全社業務を自動化しようとせず、毎週30分使っている集計や確認作業を一つ選ぶのがおすすめです。そこで「Gadget化に何分かかったか」「何回使えば元が取れるか」「LLMなしで動く範囲はどこか」を測ると、自分の環境での価値を具体的に判断できます。

参考資料