Claude Fable 5 小規模プロジェクト実践：要件からリリースまで、AI が何を担ったか

結論から：Claude Fable 5 で pulsecheck という CLI をゼロから作った——YAML に書いた URL/API 群が生きているか一括チェックし、結果を JSON で吐く。cron や既存アラートにそのまま載せられる。記事は二部構成。前半は何のためのツールか、完成品の使い方（下の説明とスクリーンショット）。後半は七ステップでClaude Code 上で AI が書いたコードと、人が決めなければならない箇所を振り返る。用途だけ知りたければスクリーンショットまで；手を動かすならステップ 1 から。

用途：三つの実務シーン

Go や YAML の話は後回し——このツールが解くのは「いまこれらのサービスは生きているか」という問い。次の三つが作った理由：

• 定期ヘルスチェック — 5～20 個の死活 URL（決済コールバック、公開 API、内部ゲートウェイ）。以前は for url in ...; do curl ... の shell スクリプトで、メンテが辛くレポートもバラバラ。pulsecheck は設定 1 ファイルで構造化 JSON を出し、cron に載せるだけ。
• リリース前・オンコール前の手動確認 — デプロイ前に一行：./pulsecheck -config prod.yaml -o /tmp/pre-deploy.json。全緑（終了コード 0）なら push；赤（1）なら止める。
• 既存アラートへの「プローブ」 — Prometheus フルスタックが不要なら、終了コードで既存スクリプトに繋ぐ：1 なら Webhook curl やメール。JSON は事後調査用に残す。

やらないこと：時系列トレンド、SMS アラート、マルチテナント管理画面——それは Datadog やクラウド監視に任せる。pulsecheck はこの瞬間の URL 群が通るかだけ。

完成スクリーンショット

以下は pulsecheck を全部終えたあとの Mac ターミナル実画面：設定読み込み、URL プローブ、JSON 出力。1 サイトが 503 のため終了コードは 1。

ローカルで再現する三コマンド：

./pulsecheck -config config.example.yaml -o report.json
echo $?          # 1 = 不健全なサイトあり
cat report.json   # レポート確認

入出力と技術構成

用途が分かったら中身の動き——「curl をバッチ実行してレポートにまとめる」を、コンパイル可能で cron 向けの CLI にした形。

メンテするのは URL 一覧の YAML だけ。プローブと集計は pulsecheck が自動処理。例：

targets:
  - https://api.example.com/health
  - https://status.example.com/ping

完成後のリポは Go 約 400 行。構成：

pulsecheck/
├── cmd/pulsecheck/main.go      # エントリ：-config -o
├── internal/checker/checker.go # HTTP 送信・レイテンシ計測
├── internal/config/config.go   # YAML パース
├── config.example.yaml
├── Makefile · README.md
└── .github/workflows/ci.yml

後半：七ステップで AI が書いたもの

ここまでで pulsecheck の WHAT/WHY は押さえた。ここから構築プロセス：Claude Fable 5 + Claude Code で空ディレクトリから v0.1.0 tag まで、AI が出したファイルと人の介入ポイント。

分担の要約：AI はコードとテスト；人はスコープ定義、Review 差し戻し、最終リリース判断。七ステップは Prompt をそのままコピーして再現可能。モデルは Claude Code の Fable 5 で十分（Opus 不要、ティア比較参照）。

環境準備

• Go 1.22+ — go version で確認
• Claude Code CLI — モデルは Claude Fable 5（日常の Agent ループに十分、モデルティア比較）
• 空ディレクトリ — mkdir pulsecheck && cd pulsecheck && git init
• （任意）GitHub リポ — ステップ 6 でリモート CI；ローカル完結でも可

ステップ 1：リポ作成・要件定義

あなたの作業：痛みを三文で書き SPEC.md に落とす。手書きでも、口頭で AI に拡張させてもよいが、非目標は人が削る（さもないと Web UI や DB が増える）。

以下の要件を読み、SPEC.md 草案を生成。列挙外の機能は追加しないこと：

- ツール名 pulsecheck、Go 1.22 CLI
- YAML 設定の URL 一覧を並列 HTTP GET
- JSON レポートを -o 指定パスに出力
- フィールド：url, status_code, latency_ms, ok
- デフォルトタイムアウト 5 秒、環境変数 PULSECHECK_TIMEOUT で上書き可
- 終了コード：0 全緑、1 失敗あり、2 設定エラー
- 非目標：GUI なし、DB なし、Docker なし、アラート推送なし

AI の出力：SPEC.md。確認：勝手な機能追加がないか；検証コマンドに go test ./... があるか。

検証：cat SPEC.md で「必須 / 非目標 / 終了コード」の三節が揃っていること。

ステップ 2：プロジェクト骨格

あなたの作業：AI に骨格だけ、ビジネスロジックは書かせない。このステップは Fable 5 がほぼ一手に。

SPEC.md を読み、Go モジュール github.com/you/pulsecheck を初期化。
骨格のみ作成、ビジネスロジックは stub 返却：
- cmd/pulsecheck/main.go で -config と -o をパース
- internal/config で YAML 読み込み
- internal/checker は空実装
- Makefile：test、lint、build
- .github/workflows/ci.yml はプレースホルダ
go build ./... が通ること。実 HTTP ロジックは書かない。

AI の出力：上記ツリーの 8 ファイル。所要約 6 分。

検証：

go build ./...
./pulsecheck -h   # ヘルプ表示

ステップ 3：プローブ実装とテスト

あなたの作業：テスト先行、実装はその後。プロジェクトで一番「本番っぽい」ステップ——AI が go test を自分で回し、赤なら直して緑にする。

internal/checker で：
1. 先に checker_test.go。httptest で 200、500、タイムアウトの三パターン
2. 次に checker.go：HTTP GET、status_code と latency_ms を記録
3. go test ./... をループして全通過まで
4. main.go で config → checker → -o パスへ JSON 出力を接続

AI の出力：コアプローブコード。ロジックの抜粋：

func CheckURL(ctx context.Context, client *http.Client, url string) Result {
    start := time.Now()
    req, _ := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    resp, err := client.Do(req)
    if err != nil {
        return Result{URL: url, OK: false, LatencyMs: time.Since(start).Milliseconds()}
    }
    defer resp.Body.Close()
    ok := resp.StatusCode >= 200 && resp.StatusCode < 300
    return Result{
        URL: url, StatusCode: resp.StatusCode,
        LatencyMs: time.Since(start).Milliseconds(), OK: ok,
    }
}

実測では Fable 5 が go test を 3 ラウンド：2 ラウンド目で「タイムアウトが HTTP client に渡っていない」バグを自力修正。人手のパッチなし。

検証：

go test ./... -v   # 表駆動 12 ケース全緑

ステップ 4：Review 差し戻し

あなたの作業：自分が Reviewer になり、修正リストを AI に渡す。自分で直さない（フィードバックループの検証にならない）。

以下の Review 指摘を反映。修正後も go test ./... は緑のまま：
1. JSON フィールド latency を latency_ms に（SPEC 準拠）
2. 複数 URL は worker pool、デフォルト最大 10 並列
3. stdout は JSON パス通知のみ；warn ログは stderr

AI の出力：worker pool、フィールド改名、ログ分離。人の判断：この三つを直すべきか——ここは AI に代われない。

検証：go test ./... 緑維持；手元 URL で JSON フィールド名を目視確認。

ステップ 5：設定ファイルと README

あなたの作業：運用担当がそのままコピペできるドキュメントとサンプル設定を AI に書かせる。

config.example.yaml と README.md を生成：
- インストール：go install または go build
- 使用例、終了コード表（0/1/2）
- cron で 5 分おき実行＋ログ追記の例
- 存在しないサブコマンドを捏造しない

AI の出力：

targets:
  - https://api.example.com/health
  - https://status.example.com/ping

検証：example の URL を到達可能なものに差し替え、「完成スクリーンショット」のコマンドで report.json のフィールドが揃うこと。

ステップ 6：GitHub Actions 接続

あなたの作業：GitHub に push し、AI に CI 完成と失敗時の自己修復を任せる。

.github/workflows/ci.yml を完成：
- go test -race ./...
- golangci-lint run
- go 1.22 使用
lint 失敗時はログを読み修正して再コミット。

初回 lint で unused import が出たが、Fable 5 が CI ログを読んで自分で削除。ローカル 16GB で -race が Swap を誘発するなら、race を GitHub Runner か Cloud Mac ノード に逃がす——Claude Code 実行環境の選び方と同じ発想。

検証：GitHub 上で CI 全緑。

ステップ 7：検証と tag リリース

あなたの作業：最後は必ず人手——smoke test、tag 打ち。CHANGELOG 草案は AI でも、リリース判断はあなた。

go test ./...
make build
./pulsecheck -config config.example.yaml -o /tmp/report.json
cat /tmp/report.json | jq .
git add -A && git commit -m "feat: pulsecheck v0.1.0"
git tag -a v0.1.0 -m "first release: YAML-driven HTTP health probe"
git push && git push --tags

ここまででpulsecheck は要件からリリース完了：cron に載せられ、監視に繋げられる CLI。所要約 52 分。

ステップ別：AI の担当範囲

振り返ると、七ステップの分担はこう整理できる：

コーディング成果の約 78% は AI が記述。スコープのハサミ、Review 判断、tag 署名——モデルを替えても人の領域は変わらない。

シーン別の選び方（意思決定マトリクス）

推奨スタック（組み合わせ可）

• 個人開発 — Fable 5 で ②–⑥；リリース前の微調整は Cursor Tab；Opus は対外サービスの Review のみ。
• 小チーム — リポテンプレに七段階 checklist；新ツールは pulsecheck フローを複製；Agent は Claude Code 本番ワークフローに接続。
• トークン節約 — Spec 推敲と CHANGELOG は Gemini Flash；コーディングループは Fable 5；ルーティングは OpenRouter 価格構造参照。

MCP を重ねる場合：MCP が Issue / 監視コンテキストを引き、Fable 5 がリポを編集；⑦ のリリース判断は人手推奨。

よくある誤り

• 誤り 1：何を作るか決めずにチャット開始 — 泛泛とした提案になる；先に pulsecheck のような一行ゴールを。
• 誤り 2：ステップ 2 でビジネスロジックまで書かせる — 骨格と実装が混ざり、後のテストが辛い。
• 誤り 3：ステップ 4 Review をスキップ — JSON フィールド名や stdout 汚染が「完成品」に残る。
• 誤り 4：ステップ 7 なしで tag — smoke test なきリリースはリリースではない。
• 誤り 5：16GB ローカルで race + Agent 同時 — 遅いのはメモリ；CI は Runner / Cloud Mac へ。

FAQ

pulsecheck は何を解く？

「この URL 群は今つながるか」——shell の curl ループも、重量監視 SaaS も不要。個人プロジェクト、小チーム、リリース前の素早い死活確認向け。

UptimeRobot や Prometheus との違いは？

pulsecheck は自前マシンで動く軽量 CLI。設定は手元、SaaS 依存なし。後者はフル監視で機能もコストも大きい。本記事は前者——足りる分だけ、コードも自分で直せる。

リポを clone できる？

本記事は実測振り返り + 再現手順。七ステップの Prompt で同等物を自分のディレクトリに生成すればよく、文中 diff との完全一致は不要。

どのステップで AI が一番働く？

ステップ 3（テスト + 実装）とステップ 2（骨格）が Fable 5 ほぼ丸投げ；ステップ 1 と 7 は人手が多い。

Cursor Tab 補完との違いは？

Tab は単一ファイル向き；端到端プロジェクトは Claude Code のマルチファイル + テスト実行。比較は Copilot vs Cursor 実測。

まとめ

成果物：pulsecheck——YAML の URL を一括チェックし report.json を出力（上のスクリーンショット参照）。プロセス：Claude Fable 5 で七ステップ、空ディレクトリから v0.1.0 tag。Go コードとテストの大半は AI、人はスコープ・Review・リリース。「AI で小プロジェクトできるか」だけ知りたければスクリーンショットと入出力表で十分；自分でやるならステップ 1 の Prompt をコピーから。