こんにちは、白々さじきです。
「Claude Code がすごい」という話はよく聞くが、実際に個人開発プロジェクトを丸ごと任せると何が起きるかを体系的に検証した記事はあまり見かけません。
今回、飲み会の日程調整ツール（幹事ツール）を題材に、要件定義以外のすべての実装を Claude Code に完全委任する 2 週間の検証を実施しました。
まず結論から
| 観点 | 結果 |
|---|---|
| 速度 | 予定3日の初回実装が Day 2（1日）で完了。機能追加はシャワー中に終わるレベル |
| 理解負債 | Day 7 時点で人間側は「ほぼ覚えていない」。Claude Code がいないと自プロダクトが触れない |
| 発注スキル | 雑指示でも動くが、UIフローなど暗黙の前提は伝わらない。プライバシー要件は AI だけでは正解に辿り着けない |
| 総合判断 | 使える。ただし使い方を間違えると将来の自分が困る |
以下、日次ログに沿って詳細を報告します。
背景：なぜこの検証をやったか
デリバリー速度への強い動機
個人開発でいちばん辛いのは「実装が間に合わなくてアイデアが腐る」ことです。Claude Code を使いこなせば、アイデアを温めている時間そのものがなくなるのではないかという仮説がありました。
一方で、理解負債への懸念もありました。「自分で書いていないコードは、自分で理解できているか？」という問いです。特に SIer の現場では、自力でコードを読めない状態は将来の保守・拡張で致命的になりえます。
検証の設計
- Day 1: 人間主導でセットアップ（検証の起点を明確にするため）
- Day 2〜4: 完全委任で初回実装
- Day 5〜6: 意図的な空白（記憶を薄れさせる）
- Day 7: 機能追加① → 理解負債の観測
- Day 8〜9: 再び空白
- Day 10: 機能追加②
- Day 11: 機能削除 + 新機能追加
空白期間は「人間側の記憶が薄れた状態で機能追加に挑む」ことで、理解負債の程度を測るために設けました。
技術スタック
| レイヤー | 採用技術 |
|---|---|
| フロントエンド | React + Vite + TypeScript + Tailwind CSS v4 |
| バックエンド | Hono + TypeScript |
| DB | Cloudflare D1 (SQLite) |
| ORM | Drizzle ORM |
| 実行環境 | Cloudflare Workers（単一 Worker） |
| パッケージ管理 | pnpm |
フロントとバックエンドを同一 Worker 内で配信する構成にしたのは、スタックが揃っている方が Claude Code が実装しやすいという判断からです。CORS 設定不要、デプロイ1コマンドという副次的なメリットもあります。
Day 1：人間主導のセットアップ（所要時間 約2時間）
Claude Code は「質問・調査係」としてのみ使用し、実装はすべて自分で書きました。
詰まったポイント（3つ）
① run_worker_first を知らないと詰まる
Workers Assets を使う場合、デフォルトでは静的ファイルが優先されるため、/api/hello が SPA のフォールバックに吸収されてしまいます。wrangler.toml に run_worker_first = true を追加することで解消しますが、公式ドキュメントを読まないと気づかない設定です。
② Tailwind v4 は設定ファイルがない
v3 まで必要だった tailwind.config.js が不要になっています。慣れてしまえば楽ですが、古いやり方を知っている人ほど「なぜ動くんだ？」と戸惑います。
③ workers.dev サブドメインの初期登録
初回デプロイ時に Cloudflare ダッシュボードでサブドメインを有効化する手順が必要でした。これも知らないと手が止まります。
Day 1 は予定通り約2時間で完了しました。
Day 2：完全委任開始 – 想定外の速度
最初の指示（雑指示モード）
再度CLAUDE.md読んで実装計画を立てて、なるべく細かくタスクをきってCLAUDE.md にはプロジェクト概要・技術スタック・機能スコープ・データモデルをまとめてあります。Claude Code はこれを読んで、自律的に計画を立て始めました。
Claude Code が立てた計画
返ってきた計画は 全7フェーズ・約30タスクでした。
- フェーズ0: 準備・クリーンアップ
- フェーズ1: 共有型定義（
src/shared/types.ts） - フェーズ2: API 実装（Hono ルーティング + D1 操作）
- フェーズ3: フロント基盤（react-router-dom、レイアウト）
- フェーズ4: イベント作成ページ
- フェーズ5: 参加者ページ
- フェーズ6: 管理ページ
事前相談があったこと
実装前に確認が入りました。
「react-router-dom v7 を追加してよいか？」
CLAUDE.md に「新規ライブラリの追加は事前相談」と書いていたルールが守られています。
想定外だった挙動
「フェーズ完了時に止まって報告してください」「各フェーズ完了時に git commit してください」と指示しましたが、どちらも守られませんでした。フェーズ 3〜6 が一気に実施され、コミットもされないまま全変更が積み上がりました。
ただし結果として、Day 2〜4 で予定していた初回実装が Day 2 中に完了しました。
教訓：区切り指示・コミット指示は守られないことがある。フェーズを1つずつ手渡しにするか、仕組みとして強制する工夫が必要。
Day 5〜6：意図的な空白
何もしません。記憶を薄れさせるために設けた期間です。
Day 7：機能追加①（店候補共有） – 理解負債の顕在化
新規セッションで Claude Code を起動しました。
このとき、人間側の理解度は「ほぼ覚えていない」でした。どのファイルに何が書いてあるか、API の構造がどうなっているか、ほとんど記憶がない状態です。
一方、Claude Code は CLAUDE.md と既存コードを読んで完全に文脈を再構築しました。
ここで初めて実感しました。「Claude Code がいないと自分のプロダクトが理解できない」状態に入った。
機能追加の速度
指示を出した後、シャワーを浴びに行きました。戻ったら完成していました。所要時間は体感 15〜20 分です。
Day 8〜9：再び空白
Day 10：機能追加②（投票 + クロス集計） – トラブル2件
トラブル1：ディレクトリ間違い
Claude Code を起動したところ、説明の内容が全く違います。見てみると別プロジェクトのディレクトリで起動していました。幸い何も変更されていなかったのでセーフでしたが、気づかず進んでいたら既存コードを壊していました。
教訓：Claude Code 起動前に pwd で現在のディレクトリを確認する習慣が必要。
トラブル2：投票タイミングの仕様ズレ
できあがった UI を確認すると、投票の動線が意図と違いました。
上の画面のように、Claude Code が作った仕様では「日程回答 → 完了 → 別画面で店投票」という2ステップ構成になっていました。自分の意図は「日程回答と店投票を同じ画面で同時に、1回の送信で完結」でした。
以下の追加指示で修正しました。
店の投票タイミングを変更してください。
【現状】
日付の投票 → その後に店の投票（別ステップ）
【変更後】
日付の投票と店の投票を同じ画面で同時にできるようにする。
店候補の横に現在の投票数も表示する。
参加者が1回の送信で、日程回答（◯△×）と店の投票を
まとめて送信できるUIにしてください。
修正後は意図通りの画面になりました。
教訓：UIのフロー（何をどの順番で操作するか、何が1アクションか）は暗黙の前提になりやすい。「同じ画面で」「1回の送信で」といった言葉で明示すべき。
Day 11：機能削除 + アレルギー機能追加 – 仕様は使ってみないと分からない
今回の検証観点
- Claude Code に「機能削除」を任せた場合の挙動（初の検証）
- 削除と追加を同時に指示した場合の対応力
実施内容
- Day 10 で追加した投票機能・クロス集計を完全削除
- アレルギー情報機能を新規追加
今回はこの2つを1つのプロンプトで同時に指示しました。
CLAUDE.md と既存のコードを読んで、現在の実装状況を理解してください。
理解できたら、以下の仕様変更を実施してください。
【削除】
- 店への投票機能を削除してください
- 投票に関連するテーブル、API、UIをすべて削除
- クロス集計マトリクスも削除
【追加：アレルギー情報機能】
■ 参加者ページのUI
- 日程回答（◯△×）の下に「アレルギーがありますか？」のチェックボックスを追加
- チェックを入れたら、アレルギー一覧のチェックボックスが表示される
- チェックを外したらアレルギー一覧は非表示になる
■ アレルギーの選択肢（固定リスト）
- 特定原材料8品目を個別チェックボックスで表示:
卵、乳、小麦、えび、かに、そば、落花生、くるみ
- 最後に「その他」チェックボックスを追加
- 「その他」にチェックを入れたらテキスト入力欄が活性化する
- 「その他」のチェックを外したらテキスト入力欄を非活性にする
- 「その他」のチェックが外れている場合、テキスト入力欄に値が残っていても送信しない
■ データの保存
- アレルギー情報は participants テーブルに保存（カラム追加 or JSON）
- マイグレーションが必要なら生成・適用してください
■ 管理画面の表示
- アレルギーがある参加者がいる場合のみ、アレルギー情報セクションを表示
- 個人が特定できないようにする
- NG: 「田中さん: 卵、乳」のように名前と紐付けて表示
- OK: 「卵アレルギーあり（1名）」「乳アレルギーあり（2名）」のように項目と人数だけ表示
- 「その他」がある場合は「その他のアレルギーあり」と表示し、内容テキストは表示しない
（個人特定を防ぐため）
■ 日程回答との関係
- アレルギー情報は日程回答と同じ画面で同時に送信する（別ステップにしない）
完了したら報告してください。機能削除の落とし穴：関連機能まで指定しないと消えない
「Day 10 で追加した店への投票機能とクロス集計を完全削除してください」と指示しました。
削除自体は実行されましたが、確認してみると管理画面の「店候補追加フォーム」と「店候補一覧の表示」がそのまま残っていました。投票機能を消した以上、店候補を登録・表示する画面も不要になるはずですが、そこまでは判断してくれませんでした。
「投票機能の削除」という指示の文脈で、どこまでが削除スコープかを Claude Code は保守的に解釈します。「何が関連しているか」を人間が把握して、削除対象を一覧で列挙する形で指示するのが確実です。追加のときと同じく、削除も粒度が粗いとやり取りの回数が増えます。
アレルギー「その他」の表示仕様を3回修正した経緯
「個人を特定できないようにする」という要件は正しいのですが、実用性とのバランスが難しく、画面を見ながら3回修正しました。
初回実装：「その他」の内容を非表示
管理画面には「その他あり: ○名」とだけ表示する実装になっていました。
幹事が「その他に何が書いてあるか」を把握できず、実用的でありません。
修正1：内容を匿名一覧表示
以下の指示で修正しました。
管理画面のアレルギー表示で、「その他」の扱いを変更してください。
【現状】
「その他のアレルギーあり（1名）」とだけ表示され、内容が分からない
【変更後】
「その他」に入力された内容を匿名で一覧表示する。
例: 「その他: 松の実（1名）」「その他: マンゴー（1名）」
名前との紐付けはしない。同じ内容が複数人にあれば人数を集約する。全員の入力内容をリスト表示する実装に変更しました。「松の実」「マンゴー、キウイ」のように、誰が書いたかは分からない形で表示します。
ところが、複数項目を入力した人の場合、組み合わせで個人が特定できるリスクに気づきました。「マンゴー、松の実、キウイ」という組み合わせが1人しかいなければ、その人の回答だと分かってしまいます。
修正2：入力値をカンマ分割して項目ごとに個別集計
以下の指示で修正しました。
アレルギーの「その他」の入力と表示を変更してください。
【参加者ページの入力UI】
- 「その他」にチェックを入れたら、テキスト入力欄を表示
- 入力欄のプレースホルダーに「1つずつ改行で入力してください（例：松の実、マンゴー）」と表示
- カンマ、読点、改行のいずれかで区切って入力できるようにする
【データの保存】
- 入力値をカンマ・読点・改行で分割し、個別の項目として保存する
- 例: 「松の実、マンゴー」→ ["松の実", "マンゴー"] として保存
【管理画面の表示】
- 分割された項目ごとに1行ずつ匿名で表示する
- 例:
その他: 松の実（1名）
その他: マンゴー（1名）
- 同じ項目が複数人にあれば人数を集約する
- これにより「松の実とマンゴーの両方がある人」という組み合わせでの個人特定を防ぐ入力文字列をカンマで分割し、項目ごとに集計する実装に変更しました。「松の実: 2名、マンゴー: 1名」のような表示になり、組み合わせによる個人特定を防げます。
これで解決しました。
教訓：プライバシーと実用性のバランスは、実際に画面を見ながら段階的に詰める必要がある。「匿名集計」の具体的な意味（何をどう表示すれば個人特定につながらないか）は、実装前に言語化しきれない。AI だけでは正解に辿り着けない。
完成したアレルギー機能の画面です。
プレースホルダーの矛盾
完成後に UI を確認していたら、テキスト入力欄のプレースホルダーに矛盾がありました。
- 案内文：「改行で複数入力できます」
- 入力例：「松の実、マンゴー」（カンマ区切り）
どちらが正しいのかユーザーが迷います。カンマ区切り1行入力に統一して解決しました。
教訓：UI の細部は人間がレビューしないと矛盾が残る。Claude Code は指示通りに作るが、案内文と動作の整合性まで自発的には確認しない。
テストがないことの不便さ
「その他」の表示仕様を3回修正する中で、毎回手動で動作確認するのが地味にコストでした。テストがあれば、少なくとも既存機能の破壊確認は自動化できます。
教訓：完全委任でも、テスト生成は早い段階（Day 2 完了後など）でやらせるべきだった。
定量データまとめ
| 観点 | 結果 |
|---|---|
| 初回実装の速度 | 予定3日 → 1日で完了 |
| 機能追加①の速度 | シャワー中（約15〜20分）に完了 |
| 機能追加②の速度 | 仕様変更含め短時間で完了 |
| 機能削除 + 新機能追加 | 短時間で完了 |
| Day 7 時点の理解度 | ほぼ覚えていない |
| 区切り指示の遵守 | 守られなかった |
| commit 指示の遵守 | 守られなかった |
| ライブラリ追加の事前相談 | 守られた |
| 仕様ズレの発生回数 | 1回（投票タイミング） |
| 仕様修正の回数 | 3回（アレルギー「その他」の表示） |
| 機能削除の正確性 | 問題なし |
エンジニアへの示唆
どこまで任せるべきか
「全部任せる」は技術的に可能ですが、動作確認と仕様の言語化は人間の仕事です。特に以下は人間がレビューする必要があります。
- UIフロー（何をどの順番で操作するか、何が1アクションか）
- プライバシー要件（どこまでを匿名とするか、組み合わせ特定のリスク）
- UI の細部（案内文と動作の整合性）
CLAUDE.md の重要性
今回の検証でいちばん重要だったのは CLAUDE.md です。セッションをまたいでも Claude Code が文脈を再構築できたのは、この1ファイルがあったからです。プロジェクトの記憶が CLAUDE.md に集約されています。
ここに書くべき内容：
- 技術スタックと構成の特徴
- 機能スコープ（やること・やらないこと）
- データモデル
- 命名規則・コーディングルール
- 新規ライブラリ追加の判断基準
逆に言うと、CLAUDE.md に書いていない暗黙の期待は伝わりません。
理解負債を防ぐためにやるべきこと
- フェーズを1つずつ手渡しにする: 「全部やって」ではなく「フェーズ2だけやって、確認したら次」というリズムで進める
- 定期的なコードリーディング: 空白期間中でも週1回はコードを読む時間を確保する
- UIフローは明示的に書く: 箇条書きでも良いので、操作フローを言語化してから指示する
- テスト生成を早期化: 手動確認が積み重なる前に、テストを書かせるフェーズを設ける
プライバシー・セキュリティへの注意
「どこまでを匿名とするか」「どの情報をログに出すか」といった微妙な判断は、AI に任せきりにせず、人間が段階的にレビューすべきです。今回のアレルギー「その他」の3回修正はその典型例でした。
まとめ
Claude Code への完全委任を2週間試した結論：
「速度は圧倒的に出る。ただし、理解は人間が意識的に取りに行かないと消える。」
速度面では期待以上でした。初回実装は3日予定が1日で完了し、機能追加はシャワー中に終わります。SIer の現場でも、個人開発・社内ツール・PoC の文脈では大きな武器になります。
一方、理解負債は確実に発生します。「Claude Code がいないと自分のプロダクトが触れない」状態は、意識しないと現実になります。
上流 SE・PdM を目指すなら、AI への発注スキル（= 要件定義力）が差別化要因になります。 UIフローやプライバシー要件のような微妙な判断を言語化して指示できるかどうか。それがこれからの開発者に求められるスキルです。
次回やるなら改善したいこと
- テスト生成を Day 2 完了後すぐにやらせる
- フェーズ完了ごとのコミットを仕組み化する
- UIフロー図を CLAUDE.md に添付する
- 仕様の「やらないこと」をより詳細に定義する
コメント