プロンプトからデプロイまで
— 非エンジニアのための作業工程ガイド

▶この資料の位置づけと読み方

同じフォルダにある cloudflare-os-internal-service-guide が「導入すべきか」を判断するための資料であるのに対し、この資料は「実際に手を動かす順番」だけを、1 工程 1 図で並べたものです。

13 分でわかる全体像全員

この資料でいちばん大事な図です。工程は 3 つのかたまりに分かれ、「デプロイ」は最初の 1 回しか出てきません。

普通の Web アプリ開発と決定的に違う 3 点

2使う部品 — Cloudflare スタックの地図エンジニア

「Cloudflare スタック」と言ったとき、実際に動いている部品はこれだけです。つくる人はこの図を覚える必要はありません。エンジニアが 1 回そろえるだけです。

3工程表 — 誰が、いつ、何を全員

4始める前のチェックリストエンジニア

工程 1 に入る前に、これが全部そろっているかを確認してください。1 つでも欠けていると途中で止まります。

5工程 1設置するエンジニア

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

5-2. 方式 B — コマンドが何をしているか

$ git clone https://github.com/cloudflare/cloudflare-os-starter
      └→ 「設置キット」を取ってくる。本体はまだ入っていない

$ cd cloudflare-os-starter
$ git submodule update --init
      └→ 本体を「特定のバージョンに固定して」取り込む
         ★勝手にバージョンが上がらない設計。早期アクセス版として正しい

$ pnpm install
$ pnpm --dir cloudflare-os install
      └→ 必要な部品を集める（2〜5分）

$ pnpm exec wrangler login
      └→ ブラウザが開く。自社の Cloudflare アカウントに繋ぐ

  ここで deployment.jsonc を編集 ────────────────┐
                                                 │
$ pnpm check                                     │
      └→ 設定の書き間違いを先に見つける          │
         ★ここで落ちるのは正常。直して再実行     │
                                                 │
$ pnpm deploy                                    │
      └→ 自社の Cloudflare アカウントに設置される│
                                                 │
$ open https://<ホスト名>/admin  ←──────────────┘
      └→ サイト名・ロゴ・色を設定（再デプロイ不要）

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

5-3. deployment.jsonc に書く 5 つ

5-4. 工程 1 の完了条件

• pnpm check が通る
• pnpm deploy が成功する
• ホスト名を開くと Access のログイン画面が出る
• ログインするとホーム画面が出る
• /admin が開ける（管理者メールのアカウントで）

6工程 2入口を決める — Cloudflare Accessエンジニア

6-1. 3 層で守られている

ここを誤解すると、権限設計を丸ごと間違えます。

6-2. 手順

1. Zero Trust → Access → Applications → Add an application
2. 「Self-hosted」を選ぶ
3. ホスト名（os.synon.co.jp）を入れる
4. できたアプリの Application Audience (AUD) タグをコピー
5. deployment.jsonc の Access audience 欄に貼る → pnpm deploy
6. 「誰が入れるか」をポリシーで決める

Access のポリシー ＝ 入場者名簿です。Cloudflare OS 側にユーザー管理画面はありません。退職者を落とすのも、ここ 1 か所です。

6-3. ポリシーの決め方（Synon の推奨）

6-4. 唯一の穴 — オリジン直叩き

deployment.jsonc の access.issuer / audience はこの検証のためにあります（公開鍵は 6 週間ごとローテーション）。

6-5. 工程 2 の完了条件

• 社内メールでログインできる
• 社外メール（個人の Gmail 等）でログインできないことを実際に試した
• Require Access protection が ON
• 退職時に誰がこの名簿から落とすかが決まっている

7工程 3AI と予算の栓を開けるエンジニア

7-1. AI は既定で無効。開けないと何も生成されない

公式 starter の README にこうあります。

# 必要なシークレットは 1 本だけ
pnpm exec wrangler secret put CF_AI_GATEWAY_API_TOKEN --name synon-os

API トークンの権限（アカウント権限）: AI Gateway – Read ／ AI Gateway – Edit ／ Workers AI – Read

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

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

既定値: DAILY_LLM_CALL_LIMIT=100（1 ユーザー／UTC 日）、MINIMUM_CLOUDFLARE_BALANCE=2、残高キャッシュ 5 分。

7-4. 天井は 2 種類ある — ここが最重要

7-5. Synon の推奨初期値

7-6. 方針: 会社が費用を持ち、上限で守る

非エンジニアに残高管理をさせない、という判断です。

• providers = cloudflare ＋ 外部 1 社
• workersAi.mode: "gateway"（ログを残す）
• ENABLE_CLOUDFLARE_LIMITS 有効
• 回数の天井とは別に Spend Limits で金額の天井を張る

7-7. 工程 3 の完了条件

• チャットで「こんにちは」と打って返事が返る
• AI Gateway のダッシュボードにそのリクエストが記録されている
• Spend Limits が設定されている
• プロンプト本文と応答がログに残ることを、誰が見られるか決めてある

8工程 4見た目と管理者を決めるエンジニア

「別サービスに見えると使われない」 — これは技術の話ではなく、定着の話です。

工程 4 の完了条件

• ホーム画面が「社内のサービス」に見える
• 管理者が 2 名以上いる
• エージェントへの指示に、社内の言葉づかい（敬体・和暦の要否など）を入れた

9工程 5入るつくる人

   ブラウザで社内 URL（https://os.synon.co.jp）を開く
              │
              ▼
   Cloudflare Access のログイン画面（会社のメール／いつもの SSO）
              │
              ▼
   Cloudflare OS のホーム画面
              │
              ▼
   ［＋］ボタン → 「New Gadget」

10工程 6頼む — プロンプトの書き方つくる人

10-1. プロンプトは 5 つのブロックでできている

10-2. 惜しい頼み方と、良い頼み方

違いは 3 点だけです。

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

10-3. 題材 1 — 顧客問い合わせの受付台帳（そのまま貼れます）

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

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

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

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

10-4. 題材 2 — 日報の集計ダッシュボード（そのまま貼れます）

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

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

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

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

10-5. コピペ用のひな型

（　　）を（　　）するための社内用の（　　）を作ってください。

【登録する項目】
- 
- 
（選択肢があるものは「A／B／C」の形で全部書く）

【画面】
- 
- 

【決まりごと】
- 見せていい人：
- 計算のルール：

【その他】
- 

10-6. やってはいけない頼み方

11頼んだ直後、裏で何が起きているか全員

知らなくても作れます。ただし「なぜデプロイが要らないのか」はここで分かります。

12工程 7確かめるつくる人

AI が作ったものを、そのまま配らないでください。この 6 点だけ確認します。

13工程 8直すつくる人

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

13-2. 直し方の言い回し集

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

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

14工程 9つなぐ — Gatekeeperつくる人＋エンジニア

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

14-1. Gatekeeper は「外部システムへの唯一の扉」

14-2. つくる人から見た手順（4 ステップ）

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

14-3. 標準で同梱されているもの／いないもの

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

14-4. 新しい Gatekeeper を作るのは誰か

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

14-5. 観測ログ — つないだ瞬間に効き始めるもの

検証の範囲は build ＝ 全 Gatekeeper、use ＝ 名前付きバインディングのみ。以後、登録された観測者の誰か 1 人でも読めない情報を読もうとすると、その読み取り自体がブロックされます。

15工程 10配るつくる人

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

15-1. どちらを選ぶか（2 問）

  Q1. みんなが「同じデータ」を見る必要がありますか？
        └ はい ──────────────→【直接共有】（例: 問い合わせ台帳）
        └ いいえ ↓

  Q2. あとから全員ぶんを直したくなりますか？
        └ はい ──────────────→【直接共有】
        └ いいえ ─────────────→【Blueprint】（例: 各自の日報）

15-2. 直接共有の手順と注意

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

• 取り消しは可能で、その場で効きます。ライブセッションも強制切断されます
• 取り消しのプレビューがあります（「Bob を外すと Carol も切れる」と事前に警告）
• グループ共有は存在しません（将来計画にもありません）。部署配布はメールを 1 件ずつか、Blueprint

15-3. Blueprint の手順と、最大の制限

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

16工程 11定着させるつくる人＋管理者

作って配って終わり、にすると使われません。定着のための仕掛けが 3 つあります。

16-1. + メニューに置く（Formats）

+ メニューの「New Doc」「New Slides」は特別な機能ではなく、管理者が昇格させた Blueprint（Formats）です。つまり Synon の書式に合わせた「新規 見積書」「新規 議事録」を + メニューに置けます。/admin の「Formats」パネルで設定します。

   ［＋］
    ├ New Gadget
    ├ New Doc        ← これも Blueprint
    ├ New Slides     ← これも Blueprint
    ├ 新規 見積書     ← ★Synon 書式を追加できる
    └ 新規 議事録     ← ★

16-2. 名前と説明を業務のことばにする

「Gadget 3」ではなく「営業部 問い合わせ台帳」。探せない道具は使われません。

16-3. 「これで合っているか」を 2 週間で見る

17工程 12面倒をみるエンジニア／情シス

17-1. 版は勝手に上がらない

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

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

• 本番イベントの追跡: wrangler tail
• Worker はダッシュボードのデプロイ履歴からロールバックできる
• Gadget 単位の巻き戻しは、つくる人がチャットの変更を revert（工程 8）

18つまずき早見表全員

1 週目に必ず出る順に並べています。

19お金の見え方 — トークンはどこで減るのか全員

「AI を使う ＝ 常にお金がかかる」ではありません。減る場所は 4 つ、うち 1 つはゼロです。

19-1. 単価（2026-08 時点）

Unified Billing 対応: OpenAI ／ Anthropic ／ Google AI Studio ／ Google Vertex AI ／ xAI ／ Groq。優先順位は リクエスト内キー > BYOK > Unified Billing。

19-2. 見えるもの・見えないもの

20まず結論 — 置き換えではなく、層が違う全員

Synon には、これまでに設計した社内アプリの作成・共有プロセスが 2 つあります。この部では、それらと Cloudflare OS を 3 方式として並べます。

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

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

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

21工程そのものを横に並べる全員

同じ「顧客問い合わせの受付台帳」を 1 本作るとき、工程がどう違うか。この資料でいちばん比較になる図です。

21-1. 消える宿題

21-2. 増える宿題

22比較一覧表全員

22-1. つくる人から見て

22-2. 出す側・守る側から見て

22-3. お金と手間

23どれで作るか — 判断フロー全員

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

23-1. 具体例で当てはめる

24併用の設計 — 「試す」と「ちゃんと作る」をつなぐ全員

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

24-1. 作り直すときに持っていくもの・持っていけないもの

24-2. 既に プランA／B で作ったものを移すか

危うさはありません。移す理由は「更新のしやすさ」だけです。

25未確認事項と参考エンジニア／決める人

25-1. 実機で潰すこと（稟議前・展開前）

25-2. 導入の順序と撤退基準

25-3. 参考（一次情報）

• Cloudflare 公式ブログ（Cloudflare OS の公開告知）
• GitHub cloudflare/cloudflare-os — README、docs/sharing.md、docs/observers.md
• GitHub cloudflare/cloudflare-os-starter — README、docs/customization.md、docs/ai-gateway-billing.md
• Cloudflare Zero Trust / Access 公式ドキュメント
• Workers AI ／ AI Gateway 価格ページ
• 社内資料: cloudflare-os-internal-service-guide.{md,html,pptx}（判断・稟議用）
• 社内資料: claude-code-internal-app-workflow.{md,html}（プランA）
• 社内資料: claude-code-internal-app-workflow-planb.{md,html}（プランB）