非エンジニアが Claude Code で社内サービスを作り、社内配信するまで

0結論

1. ご提示の工程のうち「(E) Cloudflare で動作するようにベース変更」は、工程ごと削除する。 最初から Cloudflare ネイティブのテンプレートで作り始める。cf-internal-app-starter が既にある。 非エンジニアが自由なベースで作ったものを後から Workers に移す作業は、認証・DB・ファイル保存・ビルドの 4 箇所を全部書き直すことになり、「最低限のフォロー」には収まらない。
2. 「ローカルで実行確認」は各自の PC ではなく GitHub Codespaces で行う。 PC へのインストールがゼロになり、環境差分に起因する問い合わせが消える。壊れたら作り直せる。
3. Cloudflare の鍵を非エンジニアの手元に置かない。 デプロイは GitHub Actions だけが行い、非エンジニアは「試用環境へ出す」「本番公開を申請する」までを 自分の判断でできる。

1ご提示の工程との差分

2全体像と鍵の置き場所

3役割分担

4手順

Step 0 — 基盤整備 E・一度だけ

0-1. 社内マーケットプレイスを作る

Claude Code のスキルは、リポジトリの .claude/skills/ に置けばそのリポジトリを開いた Claude Code が自動認識します。ただしアプリが増えるとスキルが各リポジトリに散らばるため、 プラグインとして 1 箇所にまとめ、マーケットプレイス経由で配ります。

synon/claude-plugins/            （プライベートリポジトリ）
├── .claude-plugin/marketplace.json
└── plugins/synon-internal-app/
    ├── .claude-plugin/plugin.json
    └── skills/
        ├── service-spec/     ← 構築テンプレート
        ├── service-ship/     ← 更新テンプレート
        └── service-fix/      ← 自己診断

同梱の synon-claude-code-kit.zip の plugin/ と marketplace/ をそのまま配置します。 テンプレート側の .claude/settings.json に extraKnownMarketplaces と enabledPlugins を書いてあるので、利用者側の登録作業は不要です。

0-2. テンプレートリポジトリを作る

既存の cf-internal-app-starter に、キットの template/ を上書き適用します。 詳細な適用手順は template/APPLY.md。追加・差し替えるのは次の 7 ファイルです。

そのうえで Settings → Template repository にチェックを入れます。

0-3. Cloudflare 側をアカウント単位で固める

0-4. Claude Code のログイントークンを配る

claude setup-token     # 有効期間1年の OAuth トークンが標準出力に出る

これを Organization の Codespaces シークレット CLAUDE_CODE_OAUTH_TOKEN に登録します。 ~/.claude は Codespace の stop/start では残りますがコンテナの rebuild で消えるため、 トークンをシークレットに置いておかないと利用者が再ログインを求められます。

前提として Claude Pro / Max / Team / Enterprise のシートが必要です。無料プランに Claude Code は含まれません。

Step 1 — リポジトリ生成とプロビジョニング E・アプリごと30分

gh repo create synon/<アプリ名> --private --template synon/cf-internal-app-template
gh repo clone synon/<アプリ名> && cd <アプリ名>

1. wrangler.jsonc の名前を 6 箇所書き換える（name / env.staging.name / D1 名 ×2 / R2 名 ×2）
2. Vectorize と ai のブロックを削除する。どちらも remote: true = ローカル開発でも Cloudflare の実リソースに接続するため、残すと Codespace に Cloudflare の鍵が必要になり、本提案の鍵分離が崩れます。 AI 検索が必要になった時点でエンジニアが個別に判断してください。
3. npm run bootstrap（D1 / R2 / KV を作成し、ID を wrangler.jsonc に書き戻す）
4. GitHub の設定
   • Branches → main に branch protection（PR 必須 / 承認1名 / バイパス禁止） ← これが本番公開の承認ゲート。GitHub Team 以上が必要（§6「GitHub のプラン要件」）
   • Environments → staging / production を作成（環境別シークレットと監査のため）。 ※ production の Required reviewers はプライベートリポジトリでは Enterprise Cloud 限定で Team では設定できないため、承認は上の branch protection で担保する
   • Secrets（Actions）→ CLOUDFLARE_API_TOKEN / CLOUDFLARE_ACCOUNT_ID
   • Variables（Actions）→ STAGING_URL / PRODUCTION_URL
   • staging ブランチを作成して push
5. 対象 Worker の Access アプリの AUD タグを wrangler.jsonc の ACCESS_AUD に記入
6. npm run deploy:staging で初回デプロイ、URL を確認

利用者に渡すのは リポジトリの URL 1本だけです。

Step 2 — 仕様書を作る U・20〜30分

利用者は GitHub でリポジトリを開き、Code → Codespaces → Create codespace を押すだけ。 数分で作業環境が立ち上がり、START-HERE.md が自動で開きます。 ターミナルで claude → /service-spec。

このスキルの設計方針:

• 一度に聞く質問は 1 つだけ。まとめて聞かない
• 技術用語を出さない。「テーブル」ではなく「一覧に出したい項目」
• 決めないと後で高くつく 4 点だけしつこく聞く — 誰が見られるか／消せるか／お金や個人情報を扱うか／既存システムと繋ぐか
• 「今回やらないこと」の節を必ず埋めさせる。ここが空の仕様書は必ず膨らんで破綻する
• 受入条件を Given / When / Then で 5 件以上書かせる。これが /service-ship の合格判定になる
• 社外アクセス・機微情報・金額確定・既存システム連携・200人超・25MB超 のいずれかに触れたら [要E確認] を立ててエンジニアに回す

成果物は docs/SPEC.md。この仕様書は読み物ではなく、配信時に機械的に照合される契約である点が重要です。

Step 3 — 開発と確認 U・反復

仕様書の承認後、Claude が「画面が 1 枚立ち上がって動くところまで」を作ります。 全機能を一気に作らせない設計にしてあります（スキル内で明示的に禁止）。

以降は「一覧に申請日の列を足して、新しい順に並べて」のように日本語で伝えるだけです。

Step 4 — 初回の社内公開 E・10分

Step 1 で既に Cloudflare 上に出ているため、ここでやることはベース変更ではなく確認だけです。

1. 試用環境の URL を開き、Cloudflare Access のログイン画面が出ることを確認
2. @synon.co.jp でログインして画面が出ることを確認
3. /cdn-cgi/access/get-identity を開き、groups が取れていることを確認
4. Zero Trust のシート消費を確認（Free は 50 シート上限、認証イベントで消費され手動削除まで保持）
5. 利用者に URL を渡し、試用者に案内してもらう

Step 5 — 機能拡張 U・反復

Step 3 と同じ。docs/SPEC.md を更新しながら 1 機能ずつ足します。 仕様書にないことを Claude が勝手に実装しないよう、CLAUDE.md で禁止しています。

Step 6 — 配信 U ／ 本番承認 E

利用者が /service-ship と打つと、次が自動で走ります。

全部通ると staging ブランチへ push → GitHub Actions が試用環境へデプロイ → gh run watch で見守り → 試用環境の URL を利用者に提示します。

利用者が「本番に出したい」と言った場合のみ、本番公開の PR を作ります。 受入条件が全て満たされ、試用が済んでいることが条件です。Claude は PR をマージしません。

エンジニアは PR を見て、Actions の保護ファイル検査の警告を確認し、マージします。 この「マージ」が本番公開の承認そのものであり、main への push で本番デプロイが走ります。 デプロイ → スモークテスト → 失敗時は自動ロールバック。

5事故を防ぐ 4 層

「非エンジニアが自走する」ことの前提は、壊せないようにしておくことです。 1 層でも欠けると、いずれ必ず事故が起きます。

6技術判断の根拠・プラン要件・コスト

なぜ Codespaces か

導入摩擦がゼロであることの価値が、月数十ドルの従量課金を上回ります。 既存の cf-internal-app-starter は Docker 前提で作られていますが、.devcontainer/ が 空のままなので、Codespaces 対応の追加は差分が小さく済みます。

なぜ最初から Cloudflare ネイティブか

「まず作らせて、あとで移す」を選ばない理由は、移す作業がエンジニアの片手間に収まらないからです。

移行作業は「動くものを動かなくして直す」工程になるため、利用者からは後退に見え、 エンジニアからは終わりの見えない作業に見えます。最初から正しいベースで始めれば、この工程は消えます。

なぜ Workers Paid（$5/月）が事実上必須か

• D1 が 10 個上限 = 本番＋試用の 2 個ずつなので Free では 5 アプリで枯渇します
• CPU 10 ms = Access の JWT 検証（JWKS 取得を含む）＋ D1 クエリ数回で危うい

GitHub のプラン要件（GitHub Team が最低ライン）

承認ゲートの設計を修正した理由

当初は本番デプロイの承認を GitHub Environments の Required reviewers で行う設計にしていましたが、 プライベートリポジトリで Required reviewers（および Wait timer）を使えるのは Enterprise Cloud のみ であることが分かりました（Team でも使えません）。

そのため本提案では、main への PR に承認1名を必須にする branch protection を承認ゲートとし、 「エンジニアが PR をマージする行為」が本番公開の承認そのものになる設計に統一しています。 これは Team で成立し、非エンジニアから見ても「申請 → 承認 → 公開」が1本の線で追えるため、むしろ分かりやすくなります。 Enterprise Cloud を使う場合のみ、マージ後にもう一段の承認を追加できます。

費用面の分岐点: user-owned か organization-owned か

費用の目安（月額・5人が使う場合）

合計 $50〜80/月 程度。アイドルタイムアウトを既定 30 分から 15 分に縮め、 保持期間を 7 日に設定すると Codespaces の費用は半分近くまで下がります。

7「Claude Desktop の Claude Code」だけで完結できるか

1. Claude Desktop からローカルフォルダに接続する経路（Cowork のデバイス連携）は、 ネットワークアクセスを持たないサンドボックス上で動きます。 npm install も wrangler dev も通らないため、開発サーバを立ち上げられません。
2. 仮に利用者の PC に Node と wrangler を直接入れて Claude Code CLI を動かす構成にすると、 Codespaces を選んだ理由（PC への導入ゼロ・環境差分ゼロ）がそのまま失われます。

ただし工程 2（仕様書作成）だけは Claude Desktop でも成立します。 仕様書はテキストの読み書きだけで完結するため、フォルダを接続して /service-spec を 実行すれば同じ成果が得られます。

8失敗モードと対策

9導入の順序

撤退・見直しの基準: 2週目の1名が仕様書作成まで到達できない場合、スキルの質問設計に問題があります。 展開せず /service-spec の questions.md を作り直してください。

10同梱物

synon-claude-code-kit.zip

plugin/                    Claude Code プラグイン（スキル3本）
├── .claude-plugin/plugin.json
└── skills/
    ├── service-spec/      構築テンプレート（SKILL.md / questions.md / spec-template.md）
    ├── service-ship/      更新テンプレート（SKILL.md / checklist.md）
    └── service-fix/       自己診断（SKILL.md）
marketplace/               社内マーケットプレイス定義
template/                  テンプレートリポジトリへの追加・差し替えファイル
├── APPLY.md               ★ 適用手順はここから
├── .devcontainer/devcontainer.json
├── .claude/settings.json
├── .claude/hooks/pre-push-verify.sh
├── .github/workflows/deploy.yml
├── START-HERE.md
├── CLAUDE.md.append.md
├── vite.config.ts
└── docs/SPEC.md

11未確認事項（実機で潰すこと）

1. Static Assets を使う Worker で、Worker 単位 Access 経由の Cf-Access-Jwt-Assertion ヘッダが実際に付与されるか。公式は「Static Assets 併用時は ctx.access が伝播しない」 としか書いておらず、ヘッダの有無は明記されていません。Step 0 で必ず実測してください。
2. Zero Trust の self-hosted application に *.workers.dev を直接登録できるか。 Workers 側のドキュメントは可能と読めますが、Cloudflare One 側は「アカウント内のアクティブなゾーン」を 要求しており記述が食い違っています。Worker 単位 Access を使えば回避できます。
3. wrangler d1 migrations apply の --remote 要否。 wrangler v4 は全コマンドが既定ローカル動作になりましたが、migrations のリファレンスには --remote の記載がありません。同梱の deploy.yml は --remote を明示していますが、 初回デプロイで実際の挙動を確認してください。
4. Organization の Codespaces シークレットが prebuild 時にも入るか。 公式ドキュメントに記載がありません。prebuild を使う場合は実測してください。
5. Codespaces の転送ポートを devcontainer.json で public にする方法は 2026-08 時点で存在しません。 試用者への共有は Codespace ではなくステージング環境の URL で行う設計にしてあります。

参考（一次情報）

• Claude Code — Skills ／ Plugin marketplaces ／ Permissions ／ Hooks ／ Development containers ／ Authentication
• Cloudflare — Workers と Cloudflare Access（2026-08-14 GA） ／ Access JWT の検証 ／ Workers Static Assets
• Cloudflare — Workers の制限 ／ 料金 ／ D1 の制限 ／ D1 の料金 ／ Wrangler の環境 ／ wrangler login --device
• GitHub — Codespaces の課金 ／ Codespaces のシークレット ／ 転送ポートの可視性 ／ テンプレートリポジトリ
• GitHub — 各プランの内容 ／ Codespaces の所有者と支払い ／ 組織での Codespaces の有効化 ／ Protected branches ／ Rulesets ／ Environments（Required reviewers のプラン条件）
• Vite — Server Options（allowedHosts）