GitHub アカウントなしで、手元の Mac だけで回す

0結論

1. 開発は Claude Code（利用者の Mac 上）で行う。利用者のフォルダを直接触って開発サーバを立てる。
2. Cowork は仕様書づくりまで。開発ループは回らない。理由は §3 に道具の仕様として書く。
3. GitHub は裏方として残すが、利用者はアカウントも画面も要らない。 リポジトリごとの Deploy key（アカウントに紐づかない、リポジトリ単位の書き込み鍵）で push だけできるようにする。
4. Cloudflare の鍵は利用者の Mac に置かない。配信は GitHub Actions のみ。プランA の核心原則をそのまま維持できる。
5. 増える手間は端末セットアップ30分/人（1回）と本番公開のたびの PR 作成2分。 減るのは Codespaces の費用と、利用者分の GitHub シート。

1プランA との差分

2全体像

なぜ work ブランチを分けるのか

毎日の自動保存が staging に直接入ると、未完成のコードが試用環境に出てしまいます。 work は「push しても何も起きないブランチ」なので、安心して自動保存できます。

鍵の置き場所（プランA と同じ原則）

3なぜ Cowork では開発ループが回らないか

推測ではなく、道具の仕様として決まっています。Cowork がお客様の Mac のフォルダを触るときのシェルには、次の制約があります。

1. ネットワークにアクセスできない → npm ci / npm install が必ず失敗する
2. 1回のコマンド実行に時間の上限がある（約45秒） → npm run dev のような常駐プロセスを立ち上げられない
3. ファイルを削除できない → ビルド成果物の作り直しや node_modules の入れ替えで詰まる

したがって Cowork は「文字を読み書きする工程」に限って使えます。

4手順

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

1. 既存の cf-internal-app-starter に、キットの template/ を上書き適用（詳細は template/APPLY-B.md）
2. Settings → Template repository にチェック
3. Cloudflare のアカウント単位 Access を有効化（all_workers + all_preview_workers）
4. Chatwork の通知先ルームを決め、API トークンを用意する

Step 1 — 端末セットアップ E・1人1回・30分

利用者の Mac に向かって作業します。事前に入れておくもの:

xcode-select --install                          # git
# Node.js v22 以上（https://nodejs.org の pkg か Homebrew）
curl -fsSL https://claude.ai/install.sh | bash  # Claude Code
claude                                          # 初回ログイン（本人の Claude アカウント）

そのうえで:

APP=<アプリ名> USER_NAME="<氏名>" USER_MAIL=<社内メール> bash scripts/setup-mac.sh

途中で公開鍵が表示されるので、GitHub の Settings → Deploy keys → Add deploy key（"Allow write access" にチェック） に登録して Enter。

完了すると、利用者のデスクトップに 「<アプリ名>を開く.command」 ができます。 ダブルクリックすると START-HERE.md が表示され、そのまま Claude が起動します。 利用者がターミナルを意識する場面はここだけです。

cd ~/社内サービス/<アプリ名> && git push origin work:main

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

デスクトップの「◯◯を開く」をダブルクリック → /service-spec。 質問に答えるだけで docs/SPEC.md ができます。設計方針はプランA と同一です。

• 一度に聞く質問は1つだけ。技術用語を出さない
• 決めないと後で高くつく4点だけしつこく聞く（誰が見られるか／消せるか／お金や個人情報／既存システム連携）
• 「今回やらないこと」の節を必ず埋めさせる
• 受入条件を Given / When / Then で5件以上書かせる（これが /service-ship の合格判定になる）

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

Claude が「画面が1枚立ち上がって動くところまで」を作ります。確認はブラウザで http://localhost:5173 （Codespaces のような PORTS タブは不要）。

区切りがついたら必ず /service-save。スキル側からも自動的に促します （機能を1つ作り終えたとき、30分以上保存していないとき、大きな変更に入る前）。

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

プランA と同じ。試用環境の URL を開き、Access のログイン画面 → @synon.co.jp でログイン → /cdn-cgi/access/get-identity で groups を確認 → Zero Trust のシート消費を確認。

Step 5 — 機能拡張 U・反復

Step 3 と同じ。docs/SPEC.md を更新しながら1機能ずつ。

Step 6 — 配信 U と本番申請

/service-ship で自動チェックが走ります。1つでも落ちたら配信しません。

全部通ると work へ保存 → work:staging へ push → GitHub Actions が試用環境へ → Chatwork に結果が流れます。

本番公開は、利用者が docs/releases/<日付>-<名前>.md という申請書を作り、 エンジニアへ送る連絡文が画面に表示されます。エンジニアは:

1. 申請書を読む（staging ブランチにある）
2. 試用環境を自分でも触る
3. staging → main の PR を作る

   gh pr create --base main --head staging --title "<日本語1行>" \
     --body-file <(git show staging:docs/releases/<ファイル名>)

4. 差分を確認してマージ → 本番デプロイ → スモークテスト → 失敗時は自動ロールバック
5. 利用者に「公開しました」と連絡

この PR 作成の1工程だけが、プランA より増える手間です（1回2分）。

5事故を防ぐ4層 — ローカルで変わること

同梱の guard.sh は実測で確認済み

✓ npm run dev                         → 通す
✓ git push origin work                → 通す（保存は面倒にしない）
✓ sudo rm -rf /                       → 止める
✓ rm -rf node_modules                 → 止める
✓ git reset --hard HEAD~3             → 止める
✓ cat ~/.ssh/id_rsa                   → 止める
✓ npx wrangler d1 execute DB --remote  → 止める
✓ git push origin work:main           → 止める
✓ git push origin work:staging        → 型チェックとテストを通してから通す

6作業が消えないようにする

Codespaces にはクラウド側の保管がありましたが、プランB では利用者の Mac が唯一の保管場所です。 PC の故障・紛失・初期化で作業が消えます。三重に手当てします。

1. /service-save — 利用者が自分で保存する。合図は1つだけなので覚えやすい
2. スキルからの自動的な催促 — 機能を1つ作り終えたとき、30分以上保存していないとき、 大きな変更に入る前に、Claude の側から「保存しておきますか」と提案する
3. 毎日18時の自動保存（launchd） — scripts/autosave.sh が work ブランチへ push する。 work は何も起きないブランチなので、未完成のコードが試用環境に出ることはない

START-HERE.md にも「保存しないと、この PC が壊れたときに作業が消えます」と明記しています。

7リスクと備え

8費用

エンジニア2名なら月 $13（Cloudflare $5 ＋ GitHub Team $8）＋ Claude シート。 プランA（$50〜80）より 月$40〜70 安くなります。

代わりに増えるエンジニアの手作業は、端末セットアップ 30分 × 人数（1回だけ）と、 本番公開のたびの PR 作成 2分。利用者5名なら初回2.5時間、リリースが月4回でも8分/月です。 十分に元は取れます。

9導入の順序

撤退・見直しの基準: 2週目のセットアップが30分で終わらない、または npm ci が 社内ネットワークで通らない場合、端末ごとの差異が大きすぎます。展開せず、プランA（Codespaces）に戻すか、 共用の開発端末を1台立てる方式を検討してください。

10同梱物

synon-claude-code-kit-planb.zip

template/
├── APPLY-B.md                     ★ 適用手順はここから
├── START-HERE.md                  利用者が最初に読む案内
├── CLAUDE.md.append.md            CLAUDE.md への追記内容（非エンジニア前提・実機の注意）
├── .claude/
│   ├── settings.json              権限（sudo・作業フォルダ外・破壊的 git を deny）
│   ├── hooks/guard.sh             コマンド実行前に止める（動作テスト済み）
│   └── skills/
│       ├── service-spec/          仕様書づくり（Cowork 判定つき）
│       ├── service-save/          作業の保存 ← プランB で新設
│       ├── service-ship/          試用環境への配信・本番申請
│       └── service-fix/           困りごとの自己診断（ローカル特有の症状を追加）
├── scripts/
│   ├── setup-mac.sh               利用者の Mac のセットアップ（エンジニアが実行）
│   └── autosave.sh                毎日18時の自動保存
├── .github/workflows/deploy.yml   CI/CD ＋ Chatwork 通知
└── docs/SPEC.md                   仕様書のひな型

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

1. Deploy key で main に push できないこと。 branch protection が Deploy key にも効くはずですが、設定の組み合わせ次第で例外があり得ます。 Step 1 の直後に必ず実測してください（手順は §4 Step 1）。
2. Static Assets を使う Worker で Cf-Access-Jwt-Assertion ヘッダが付与されるか。 プランA と同じ最優先の宿題。Step 0 で潰す。
3. 社内ネットワーク／プロキシ下で npm ci が通るか。Step 1 で必ず1回通す。
4. Claude Code デスクトップの認証が、端末をまたいで安定するか。 claude setup-token（1年有効）を使う場合の運用も含めて、1台目で確認する。
5. wrangler d1 migrations apply の --remote 要否（プランA と同じ）。

参考（一次情報）

• Claude Code — Skills ／ Permissions ／ Hooks ／ Setup ／ Authentication
• GitHub — Managing deploy keys ／ About protected branches ／ GitHub's plans
• Cloudflare — Workers と Cloudflare Access（2026-08-14 GA） ／ Access JWT の検証 ／ Workers の制限 ／ D1 の制限
• Chatwork — Messages API