話しかけるだけで、社内サービスができる
— 非エンジニアのための全工程

▶この資料の読み方

1結論

1. Cloudflare OS は「社内の AI ワークスペース」です。チャットで頼むと、AI がその場で動くアプリ（Gadget）を書いて、そのまま社内で使える状態にします。書き出して別の場所へデプロイする工程がありません。
2. 非エンジニアが触るのはブラウザだけです。ターミナル・GitHub・デプロイの概念は、つくる人の側に一切出てきません。
3. エンジニアの仕事は「最初の設置」と「外部システムへの扉（Gatekeeper）づくり」だけです。一度置けば、アプリが 10 本になっても 100 本になっても設置作業は増えません。
4. セキュリティの考え方が根本的に違います。エージェントもアプリも最初は何にもアクセスできない状態で生まれ、必要な権限だけを「型のついた鍵（binding）」として受け取ります。API キーそのものはAI にも生成コードにも渡りません。
5. 既存のプランA／プランB を置き換えるものではありません。層が違います。使い分けの判断基準は 16〜18 章にまとめました。

2Cloudflare OS とは何か

Cloudflare が自社の社内利用のために作り、2026 年 8 月に Apache-2.0 でオープンソース公開したエージェント・ワークスペースです。ソフトウェア自体の利用料はかかりません。

2-1. 3 つの構成要素

2-2. 動いている場所

2-3. Cloudflare 自身での実績

• Cloudflare 社内では 2026 年 5 月から社員が利用開始
• 30 日間で 4,000 本以上の社内向けカスタムツールが作られた（大半は非技術部門）
• 営業チームで約 10,000 時間の手作業削減

この数字は「1 部門に 1 本の業務システム」ではなく、「一人が週に何本も、自分の困りごとに合わせて道具を作る」使われ方を示しています。

3なぜ非エンジニアでも回るのか — 3 つの理由

理由 1 — 「デプロイ」という工程が存在しない

プランA／B では、書いたコードを GitHub に push し、Actions が動き、Cloudflare に配信され、そこで初めて他人が使えるようになります。この間に失敗ポイントが 3 つあります。

理由 2 — 事故の上限が、あらかじめ天井で決まっている

非エンジニアの開発でいちばん怖いのは「うっかり社外に出す」「うっかり全部消す」です。Cloudflare OS はこれを運用ルールではなく、仕組みで止めています。

• 生成されたサーバコードは外向きのネットワーク通信が既定で無効。書かれたコードがデータを勝手に外部へ送ることが構造的にできません
• エージェントもアプリもアクセス権ゼロで生まれます。外部サービスに触るには、管理者が用意した Gatekeeper 経由のバインディングを明示的に受け取る必要があります
• 各 Gadget のデータはその Gadget 専用。隣のアプリのデータは見えません

理由 3 — 直したいときも、日本語で頼むだけ

AI の変更は、いきなり本体に反映されるのではなく、チャット単位の「変更提案」として扱われます。ユーザーはそれを受け入れる（accept）／取り消す（revert）を選べます。確定したコードは mainline と呼ばれます。

4費用

Cloudflare OS そのものは Apache-2.0 の OSS で無料です。かかるのは土台の Cloudflare 利用料と AI の推論費用だけです。

費用が読めない唯一の箇所 — AI の推論費用

ここだけは使い方次第です。AI Gateway の予算上限（Spend Limits）を必ず先に設定してください。

• モデル別・プロバイダ別・ユーザー別・チーム別に、ドル単位で上限を設定できる
• 日次／週次／月次、固定ウィンドウまたはローリング
• 上限到達時は「ブロックする」か「安いフォールバックモデルに切り替える」を選べる
• 公式ドキュメントに追加料金の記載はなく、機能自体の課金要件も見当たらない（課金条件は導入時に再確認すること）

5全体像 — 誰が、いつ、何をするか

6Step 0 — 設置するエンジニア・一度だけ

6-1. 3 つの設置方法から選ぶ

6-2. 方式 B の手順（公式 starter README より）

# 1) 取得と認証
git clone https://github.com/cloudflare/cloudflare-os-starter
cd cloudflare-os-starter
git submodule update --init          # 本体を pinned release として取り込む
pnpm install
pnpm --dir cloudflare-os install
pnpm exec wrangler login

# 2) 設定ファイルを埋める（deployment.jsonc）
#    account ID / Worker 名 / ホスト名 / Access audience / 管理者メール

# 3) 検証してデプロイ
pnpm check
pnpm deploy

# 4) /admin を開いて サイト名・ロゴ・アクセントカラー を設定
#    （ブランディングの変更に再デプロイは不要）

前提: Node.js 24 / pnpm 11 相当。

6-3. Cloudflare アカウント側に必要なもの

starter の README に明記されている必要サービス:

• Workers
• KV（3 つの namespace。deployment.jsonc で null のままなら Wrangler が自動作成）
• R2（1 バケット。同上）
• Browser Rendering
• Dynamic Worker Loaders
• （任意）Workers AI / AI Gateway

6-4. Access の設定（方式 B のとき）

1. Cloudflare Zero Trust で、Cloudflare OS のホスト名に対して「self-hosted」の Access アプリケーションを作る
2. そのアプリの Application Audience (AUD) タグをコピー
3. deployment.jsonc の Access audience 欄に貼る
4. 誰が入れるか（社内ドメインのメール、IdP のグループ等）を Access のポリシーで決める

7Step 1 — 入口と上限を決めるエンジニア・一度だけ

デプロイ直後にやることは 4 つだけです。

予算上限の推奨初期値（Synon 想定・目安）

8Step 2 — 入るつくる人

  ブラウザで社内 URL を開く
        │
        ▼
  Cloudflare Access のログイン画面（会社のメール／いつもの SSO）
        │
        ▼
  Cloudflare OS のホーム画面

インストールするものはありません。Mac でも Windows でも、ブラウザだけで同じです。

9Step 3 — 頼むつくる人

チャット欄に、日本語で、業務のことばで書きます。技術の言葉は要りません。

9-1. 良い頼み方・悪い頼み方

違いは 3 点だけです。

1. 入力する項目を全部書く
2. 一覧でどう見たいかを書く
3. 選択肢のあるものは、選択肢を全部書く（「未対応／対応中／完了」）

9-2. 題材 1 — 顧客問い合わせの受付台帳

お客様からの問い合わせを記録する社内用の台帳を作ってください。

【登録する項目】
- 受付日（既定は今日）
- 会社名
- 先方の担当者名
- 問い合わせ内容（長文）
- 種別（見積依頼／技術質問／不具合／その他）
- 対応状況（未対応／対応中／完了）
- 社内の担当者名

【画面】
- 上に新規登録フォーム、下に一覧
- 一覧は対応状況と種別で絞り込める
- 未対応を上に、受付日の新しい順
- 未対応が3日以上たっているものは行を赤くする

【その他】
- 一覧を CSV で書き出すボタンをつけてください

9-3. 題材 2 — 日報の集計ダッシュボード

社員が毎日の作業時間を入力し、月次で集計するダッシュボードを作ってください。

【入力】
- 日付／案件名／作業内容／作業時間（0.5時間刻み）
- 入力は1日ぶんをまとめて、行を足せる形にしてください

【集計】
- 今月の案件別の合計時間を棒グラフで
- 今月の自分の合計時間を大きく表示
- 案件別・週別の表

【注意】
- 他の人の入力は見えないようにしてください（自分のぶんだけ）

9-4. 頼んだあと、裏で起きていること

10どのモデルが動き、トークンはどう減るのか全員

「頼むと AI が作ってくれる」の裏側で、誰のどのモデルが呼ばれ、費用が誰に立つのかです。Cloudflare OS はここを 2 段構えにしていて、理解しておかないと「使えない」「請求が読めない」の両方が起きます。

10-1. AI は既定で無効。誰かが費用を持つと決めるまで動かない

公式 starter の README にこう書かれています。

設置しただけでは、チャットで頼んでも何も生成されません。Step 1（7 章）でここを決めます。設定は deployment.jsonc の aiGateway で、4 つのモードがあります。

必要なシークレットは CF_AI_GATEWAY_API_TOKEN の 1 本。API トークンの権限は AI Gateway – Read ／ AI Gateway – Edit ／ Workers AI – Read（アカウント権限）。

pnpm exec wrangler secret put CF_AI_GATEWAY_API_TOKEN --name your-workshop-worker

10-2. モデルは「会社が土台を絞り、本人が選ぶ」

【管理者】 deployment.jsonc の providers
   = 会社が費用を持つモデル群（deployment-funded model catalog）
                    │  この範囲の中で
                    ▼
【つくる人】 Connections パネル
   ・自分のモデル（BYOK）を追加できる
   ・Gadget の aiModel バインディングで、どのモデルを使うか選ぶ
   ・agentSpawner バインディングでも「どのモデルで動かすか」を選ぶ

/admin 画面ではモデルを選べません。管理者の担当は deployment.jsonc、つくる人の担当は Connections パネルです。

コード生成に使われるモデルも固定ではありません。公式ドキュメントにこうあります。

10-3. 1 リクエストごとに、誰の財布から出るかが判定される

ENABLE_CLOUDFLARE_LIMITS を有効にすると、AI を呼ぶ直前に毎回この判定が走ります。

10-4. トークンはどこで減るのか

10-5. 何がいくらか

Workers AI（Cloudflare 自前のモデル）

• 単価の基準は Neuron。$0.011 / 1,000 Neurons
• 1 日 10,000 Neurons まで無料（毎日 UTC 0 時＝ JST 9 時リセット）

外部プロバイダ（OpenAI / Anthropic / Google など）

• 推論単価へのマークアップはありません。各社と直接契約したときと同じトークン単価
• Cloudflare のダッシュボードでクレジットを購入する場合のみ 5% の手数料（$100 購入で $105 請求）
• Unified Billing の対応: OpenAI / Anthropic / Google AI Studio / Google Vertex AI / xAI / Groq
• 認証情報の優先順位: リクエストに含まれるキー > BYOK（保存済みキー） > Unified Billing

10-6. 見えるもの、止められるもの

AI Gateway のダッシュボードで見えるもの

リクエスト数 ／ トークン使用量 ／ コスト ／ エラー数 ／ キャッシュ率。ログにはプロンプト本文とモデルの応答も残ります。

コストの読み方の注意

• 表示されるコストはトークン数からの推定です。公式ドキュメント自身が「正確な金額はプロバイダのダッシュボードを見よ」と注記しています
• 交渉単価がある場合は Custom Costs（per_token_in / per_token_out）で上書きできます
• キャッシュヒット時のコストは常に 0 です。ただしキャッシュキーは「プロバイダ＋エンドポイント＋モデル＋認証ヘッダ＋リクエストボディ全体」の完全一致なので、実務ではまず当たりません。節約手段として当てにしないでください

止める仕組み — Spend Limits

• 無料。1 ゲートウェイあたり最大 20 ルール
• 粒度: モデル別 ／ プロバイダ別 ／ カスタムメタデータ別（ユーザー・チーム・アプリ等）
• 期間: 日次・週次・月次、固定ウィンドウまたはローリング
• 上限到達時: 既定はブロック（HTTP 429）。Dynamic Routes と組み合わせると安いモデルへ自動フォールバック

誰がいくら使ったか（Identity-aware AI Gateway）

• Cloudflare Access と連携し、Access JWT の sub クレームを cf.user_id として記録します
• メールアドレスは記録されません。社員名で見たい場合は突き合わせが要ります
• サービストークン経由のリクエストには識別子が付きません

ログの保持

保持「期間」（何日で消えるか）は公式ドキュメントに記載がありません。

10-7. Synon での運用方針（提案）

10-8. この章の未確認事項

11Step 4 — 直すつくる人

11-1. 変更は「提案」として届く

  mainline（確定しているコード）
        │
        ├── チャットA の変更提案 ──→ 受け入れる → mainline に入る
        │                        └→ 取り消す   → 無かったことになる
        │
        └── チャットB の変更提案 ──→ …

気に入らなければ取り消せます。「壊してしまったらどうしよう」は要りません。

11-2. 直し方のコツ

11-3. コードは見なくていい

コードエディタは存在し、権限のある人（build 役割）は開けます。ただし非エンジニアが開く必要はありません。開かない前提で運用してください。

12Step 5 — つなぐつくる人＋エンジニア

自分で入力するだけのアプリなら Step 5 は飛ばせます。GitHub や Google Drive、社内 DB のデータを使いたくなったときにここへ来ます。

12-1. Gatekeeper — 外部システムへの「扉」

12-2. 標準で同梱されている Gatekeeper

GitHub ／ Google ／ Cloudflare ／ Supabase ／ Notion ／ Confluence ／ Email（Workers 経由）／ Home Assistant ／ Slack ／ Spotify ／ ZoomInfo

多くは接続前に設定（OAuth の取得など）が必要です。各パッケージに手順が同梱されています。

12-3. 新しい Gatekeeper を作るのは誰か

リポジトリには AI エージェント用の write-gatekeeper スキルが同梱されており、AI に書かせる前提の設計です。ただし手順の Phase 1 には「オペレーターの承認を得るまで先に進まないこと」という明示的な関門があり、TypeScript の型設計・OAuth 設計・Workers/Durable Objects の理解が前提になっています。

12-4. つくる人から見た手順

1. 画面の Connections パネルを開く
2. 使いたい Gatekeeper（例: Google）を選ぶ
3. 触ってよい範囲（このスプレッドシートだけ、など）を選ぶ
4. チャットに戻って「接続した◯◯のデータを使って△△して」と頼む

API キーを自分でコピー＆ペーストする場面はありません。あったら、それは設計ミスです。

13Step 6 — 配るつくる人

配り方は 2 種類あり、渡るものが違います。ここを間違えると事故ります。

13-1. 直接共有の手順

「Share」モーダルで相手のユーザー名かメールを入れ、build か use を選ぶだけです。 共有リンクは #share=<鍵> の形で、128bit の秘密がリンク側にあり、サーバには HMAC-SHA-256 のハッシュしか保存されません（＝サーバ側から生の鍵は復元できない）。

13-2. Blueprint（ひな型）の手順

1. Gadget エディタのヘッダーの 「Blueprint」ボタンを押す
2. タイトル・説明・スクリーンショットを入れて公開する
3. リンク（/blueprint/<id>）を配る。または 「Explore」（/explore）に並ぶ
4. 相手は 「Create Gadget」を押すと、自分専用のコピーができる

渡ったコピーには、あなたのデータも、AI との会話も、接続先も入っていません。相手は自分で Connections パネルからつなぎ直します。

13-3. 知っておくべき制限

13-4. 「Doc」「Slides」も実は Gadget

+ メニューの「New Doc」「New Slides」は特別な機能ではなく、管理者が昇格させた Blueprint（Formats）です。

14Step 7 — 面倒をみるエンジニア／情シス

14-1. 版の更新は「勝手に上がらない」

starter は本体を git submodule として特定リリースにピン留めします。公式にも 「上流リリースをピン留めし、変更をレビューし、本番アップグレードのたびに信頼境界を検証すること」と書かれています。自動更新しない設計です。早期アクセス版として正しい挙動です。

14-2. 事故ったときの戻し方

• 本番イベントの追跡: wrangler tail
• Worker はダッシュボードのデプロイ履歴からロールバックできる

15その前に — 権限モデルだけは理解しておく

比較の前提として、Cloudflare OS がなぜ非エンジニアに開放できるのかの核心を 1 つだけ。

15-1. アクセス権ゼロから始まる

  エージェント／Gadget が生まれた瞬間
        │  持っている権限: 【なし】
        │  外向きネットワーク: 【無効】
        ▼
  必要な権限だけを「型のついたバインディング」として受け取る

      const issues = await env.PROJECT.listIssues({ state: "open" });
                           ↑
                    これは「権限そのもの」。API キーではない。
                    キーは Gatekeeper の中から出ない

15-2. 「読んだこと」に権限がついて回る

Cloudflare OS の最も特徴的な仕組みです。

AI 業務利用で最も起きやすい事故を、運用ルールではなく仕組みで止めています。

16プランA／プランB とは、そもそも層が違う

16-1. 3 つの方式の位置づけ

16-2. 決定的な違いは「関門」の有無

プランA／B の設計の中心には、「本番公開の承認 ＝ エンジニアが PR をマージする行為」という一点があります。何が本番に出るかを、必ず人間が 1 回見ます。

Cloudflare OS には、これに相当する関門がありません。共有ボタンを押した瞬間に配布が完了します。

16-3. プランB の宿題が 1 つ消える

プランB の資料で「技術で解けない宿題」として残していた項目があります。

同様に、プランB で必要だった以下もすべて不要になります。

• 端末セットアップ 30 分／人
• Deploy key の発行と削除
• 毎日 18 時の自動保存（launchd）
• npm ci が社内プロキシで通るかの検証
• 「Cowork と Claude Code のどちらでやるんでしたっけ」問題

16-4. 一方で、増える宿題

17比較一覧表

17-1. つくる人から見た比較

17-2. 出す側・守る側から見た比較

17-3. お金と手間

18どちらで作るか — 判断フロー

新しく何か作りたい、と言われたら、この 5 問を上から順に。

18-1. Q4 の「作って試す → 作り直す」が本命の使い方

これが 2 つを併存させる最大の理由です。

プランB の最大のコストは「作ってみたが使われなかった」ときの損失です。仕様書に 30 分、開発に半日、レビューに 2 分。それが空振りに終わる。

18-2. 具体例で当てはめる

19既存アプリをどう置き換えるかエンジニア＋業務側

すでに動いているものが 2 通りあります。

• (1) Docker ベースで、社内の Mac mini で運用しているアプリ
• (2) Cloudflare Workers で運用しているアプリ（プランA／プランB の成果物）

19-1. 大前提 — 「全部移す」は間違い

動いているものを触るのが、いちばんリスクの高い作業です。移行は「新しい方が良いから」ではなく、いま抱えている具体的な困りごとを消すためにだけやります。行き先は 3 つしかありません。

Cloudflare OS へ構造的に移せないもの（18 章の判断フローと同じ理由）:

• 社外の人が使うもの（Gadget は Access の内側）
• アプリ単位で独自ドメインを当てているもの
• 同梱 Gatekeeper（11 種）に無い外部 API を叩くもの → Gatekeeper 自作の工数が先に乗る
• 常駐プロセス・重いバッチ・大きなファイル・独自 DB（PostgreSQL 等）を前提にしているもの
• 社内 LAN の機器や NAS を直接叩くもの（Cloudflare 側から届かない）

19-2. まず棚卸しする（1 アプリ 1 行）

移行計画の前に、この表を全アプリぶん埋めてください。埋まらない列があること自体が結論になります。

19-3. 行き先の決め方

19-4. (1) Docker ／ Mac mini からの置き換え

移行の理由は「新しくしたい」ではない

まず、いまの構成の危うさを言葉にしてください。稟議はこの言葉で通します。

• Mac mini が単一障害点です。停電・OS アップデート・SSD 故障・置き場所の移動で止まります
• コンテナの中身を知っている人が 1 人、あるいはゼロです
• 社内 LAN 前提なら、リモートから使えない（または VPN 依存）
• バックアップが取れているかを、誰も確認していない可能性があります
• Docker Desktop のライセンス・自動起動の設定が属人化しています

中身ごとの行き先

1 アプリあたりの手順

19-5. (2) Cloudflare Workers からの置き換え

こちらは「危うさ」がありません

プランA／B の成果物は、すでに Cloudflare の上で、Access の内側で動いています。単一障害点もなく、鍵の置き場所も整理済みで、レビューの関門もあります。

移行そのものは軽い

認証（Access）もデータの所在（Cloudflare アカウントの中）も変わりません。変わるのは「誰が直せるか」だけです。手順は 19-4 と同じですが、Step 3 のデータ移行が楽です。D1 なら wrangler d1 execute で CSV を吸い出せます。

19-6. 現行環境 × 行き先のまとめ

19-7. 順番 — 一番どうでもいいものから

19-8. 置き換えをやめる基準

20導入の順序と、やめる基準

プランB と同じ考え方です。一気に全部やらない。

21未確認事項（稟議前・展開前に潰すこと）

22参考（一次情報）

• Cloudflare — Cloudflare OS: an open platform for agents, apps, and work（公式ブログ）
• Cloudflare — プレスリリース（2026-08）
• GitHub — cloudflare/cloudflare-os（本体・Apache-2.0） ／ cloudflare/cloudflare-os-starter（デプロイ用）
• GitHub — docs/blueprints.md ／ docs/sharing.md
• Cloudflare — Cap'n Web（オブジェクトケーパビリティ RPC）
• Cloudflare — Workers の料金 ／ AI Gateway の料金 ／ Unified Billing
• Cloudflare — AI Gateway Spend Limits
• InfoQ — Cloudflare OS: Cloudflare's Open-Source Corporate AI Platform Built on a Capability-Based Model
• gihyo.jp — Cloudflare、AI ワークスペース「Cloudflare OS」をオープンソースとしてリリース
• 社内資料 — claude-code-internal-app-workflow.md（プランA）／ claude-code-internal-app-workflow-planb.md（プランB）