Claude Codeでフルアプリを作る：実際の例

ゲーム開発の経験がゼロのビルダーが、実際のGoogle Earthの都市上で動くGTAスタイルのゲームを週末1本でリリースした。コードの約80%はClaudeが書いた。ゲームはOpenStreetMapから実際の警察署、空港、港を引き出す。車内のラジオはRadio Garden APIを経由してローカルのラジオ局に自動チューニングする。

これはデモではない。cw.naveen.toにライブのウェイトリストがある。

このビルドの背後にあるパタードと、それに似た他の事例は具体的で再現可能だ。成功した事例が何をしたか、そして何をしなかったときに何が起きたかを見ていこう。

週末に実際に作れるもの

2026年4月の実際の3つのビルドから始めよう。幅が重要だ。

Naveen（XでのID：@naveenvkt）がCrimeworldをリリースした。実際のGoogle Earthの都市上で動くブラウザベースのGTAスタイルゲーム。スタックはCesium、Google 3D Tiles、Three.js、Radio Garden API、OpenStreetMapのデータ。ゲーム開発の経験はなし。Claudeが約80%のコードを書いた。ビルドは週末1本で完成した。機能していて、一部に不具合があり、ライブのウェイトリストがある。

Santiagoがcareer-opsを作った。従来のアプリケーションコードが一切ないAI求人検索システム。システム全体は約3,200行のMarkdownプロンプトファイルで構成されている。modes/ディレクトリに14のスキルモードが存在する。CLAUDE.mdがオーケストレーション層。このシステムは740以上の求人を評価し、100以上のATS最適化済み履歴書を生成し、Head of Applied AIのポジションを獲得した。サブエージェント向けのclaude -pワーカーによる並列バッチ処理を使用。提出ごとに人間によるレビューが設計に組み込まれている。ジョブにA〜Fのスコアをつけ、4.0/5未満には応募しないよう推奨する。ソースコードはGitHubのsantifer/career-opsでMITライセンスで公開されている。

3人目のビルダーで金融の経験がない人が、衛星画像を使ったヘッジファンドの駐車場カウント戦略をテストした。彼らは仮説を平易な英語で説明した。小売業者の駐車場の光学衛星画像が収益を予測できるはず。Claudeがその説明から分析パイプライン全体を構築した。光学的アプローチが約33%の精度で失敗したとき、ビルダーは平易な英語で新しい仮説を説明した。レーダーはアスファルトとは異なる方法で金属の車から反射する。Claudeがパイプラインをゼロから再構築した。最終システムはGoogle Earth EngineからSentinel-2の光学データとSentinel-1のレーダーデータを引き出し、OpenStreetMapの駐車場の境界を処理し、35以上のPythonスクリプトで並び替えテスト、二項検定、ブートストラップリサンプリングを実行する。3つの小売業者のレーダーで100%の精度に達した。10の小売業者にスケールすると50%に落ちた。ビルダーの結論。「堀はアルゴリズムではなくデータの品質だ。」これが、証明するためではなくテストするために作ったときに得られる種類の正直な結果だ。

3つの異なるドメイン。3つの異なる技術的背景。1つの一貫したアプローチ。全員が何を望むかを平易な英語で説明し、作業を分割し、実装はClaudeに任せた。

最初のプロンプトを書く前に

仕様が最初。常に。

Claude Codeに関するAnthropicの公式ガイダンス：コードを書く前にClaudeにインタビューさせる。技術的な実装、UI/UX、エッジケース、制約、トレードオフについて明確化の質問をするよう依頼する。答えをSPEC.mdファイルに書く。そのspecから実行するために新しいセッションを始める。WorthItのビルダー（ブートキャンプにいるジュニア開発者で、主にバックエンドのJava、フルアプリの経験なし）はこう説明した。「詳細なプロンプトは漠然としたものに勝つ、毎回。ダッシュボードを作れではなく、フル製品仕様を書く。」

CLAUDE.mdはプロジェクトドキュメントではない。この区別はほとんどのガイドが示唆するより重要だ。

標準的なアドバイスはCLAUDE.mdをtech stackの説明、規約、フォルダ構成のメモで埋めることだ。このアプローチには実際の失敗モードがある。CLAUDE.mdのすべてはClaudeのコンテキストの高い優先度で動作する。膨らんだCLAUDE.mdはClaudeが特定の指示を失う原因になる。書いたルールにも関わらずClaudeが望まないことをし続けるなら、ファイルが長すぎてルールが埋もれている可能性が高い。

CLAUDE.mdのより強力な使い方はオーケストレーション制御ファイルとしてだ。オペレーショナルなワークフローと委任パターンを定義する。tech stackのドキュメントとコーディング規約は、必要に応じてロードされるスキルに移動する。CLAUDE.mdはClaudeがコードを読んで把握できないもの、つまりbashコマンド、ブランチの命名規約、テストの手順、自明でない理由で下した設計上の決定、開発環境の癖に集中させる。

CLAUDE.mdのすべての行についての公式テスト：この行を削除するとClaudeがミスをするか？そうでなければ削除する。

ゼロから書く前に/initを使って既存のコードベースからスターターのCLAUDE.mdを生成する。

構造化プロジェクトの指示の優先度ヒエラルキーは、CLAUDE.md（高、常にロード）の上にルールディレクトリ（高、パスでフィルタリング）、その上にスキル（中、必要に応じてロード）、その上にファイルの内容（標準、読まれたとき）。構造化プロジェクトのスイートスポットは60行のプロジェクトの些細事ではなく、200〜400行のオペレーショナルルールだ。

SESSION.mdがほとんどのビルダーが飛ばすもう一つのピースだ。達成したこと、現在のステータス、未解決の課題、変更した主なファイルを追跡する別のファイルを維持する。セッションを終了する前に更新する。「プロジェクトXを再開する」で新しいセッションを始める。機能を実装するかしないかを決めた理由を日付付きで記録する。SESSION.mdはコンテキストオーバーフローを、プロジェクトを終了させるイベントではなく管理可能なイベントにするものだ。

週末ビルドのプロセス

成功したフルアプリのビルドは全部、同じリズムを使っていた。セッションごとに1機能、機能間で/clear。

前の機能からのコンテキストのブリードが誤った仮定と微妙なバグを引き起こす。機能を終えて次に取り掛かるとき、Claudeは自分が何をしていたかについての仮定を引き継ぐ。その仮定は新しい機能に対してしばしば間違っている。/clearでコンテキストをリセットし、クリーンな開始状態を得る。

非自明な機能の前には必ずPlan Mode。Shift+Tab 2回か/plan。Claudeがコードベースを調査し、作成するファイル、導入する関数、存在するエッジケースを概説する。実行前に計画を確認して改善する。常に「仮定をリストアップしてください」をplanプロンプトに追加する。Claudeが静かに行う仮定がバグの発生源だ。

良いプロンプトに入れるもの：

スコープ：この機能が何をするか、明示的に何をしないか
制約：どのファイルが変更禁止か、どのパターンに従うか
例のファイル：欲しい形のファイルとして既存のファイルを指定する
成功基準：具体的、テスト可能、「動かせ」ではない

成功基準の部分は強調する価値がある。「メールバリデーションを実装する」の代わりに「validateEmail関数を書く。テストケース：user@example.comはtrue、invalidはfalse、user@.comはfalse。実装後にテストを実行する。」と書く。成功基準なしでは、自分だけがフィードバックループになる。

出力を承認する前に必ずdiffを確認する。ファイルの削除、公開APIのリネーム、変更禁止のファイルの変更、package.jsonへの新しいエントリ、スキーマのマイグレーションを特に確認する。Claudeはコードベース全体で公開APIエンドポイントをリネームすることができる。それらのエンドポイントに依存していたすべてのクライアントが壊れる。diffはそれを捉える場所だ。

コンテキスト管理：良いビルドと放棄されたビルドを分けるスキル

コンテキストウィンドウを何が埋めるかを理解することが、完成するビルドと混乱に漂流するビルドを分けるものだ。

Claude Codeの実効コンテキストウィンドウは約200Kトークンだが、コンパクション出力のために約20Kが予約されている。自動コンパクトは約13,000トークンが残ったときにトリガーされる。警告閾値は約20,000トークンに現れる。手動コンパクトは3,000トークン未満でブロックされる。これらの数字はClaude Codeのソースコードの分析から来ている。

公式の3つのコマンド：

/clear：無関係なタスク間でコンテキストをリセット。同じ問題に対して2回修正が失敗したら、修正し続けるのをやめて、より良い初期プロンプトで/clearを使う。
/compact <instructions>：カスタムフォーカスで要約。例：/compact Focus on the API changesで関連するコンテキストを保持して残りを削除する。
Esc + Escまたは/rewind：問題が起きる前の状態にロールバックする。

調査タスクにはサブエージェントを使う。別のコンテキストウィンドウで実行させ、要約を報告させる。メインセッションはクリーンに保たれる。Writer/Reviewerパターンも同じように機能する。メインセッションが書いたコードをレビューするために新しいセッションを使う。新鮮なコンテキストは疲れたコンテキストが見逃すものを捉える。

公式ドキュメントからの3つのアンチパターン：

キッチンシンクセッション：1つのタスク、次に無関係なもの、また最初に戻る。コンテキストが関係ないデータで埋まる。修正：/clear。

何度も修正する：失敗したアプローチ、修正、それでも失敗、また修正。同じ問題に対して2回の修正後：/clearしてより良い初期プロンプトを書く。

無限の探索：Claudeに「調査する」よう頼んでスコープなし、数百のファイルを読む。コンテキストがこの機能に必要ないコードで埋まる。修正：調査を狭くスコープするか、サブエージェントを使う。

SESSION.mdが長期的なメモリの問題を処理する。約30メッセージ後、Claudeは決して下されなかった決定、違う形で言及されたファイル、セッションの初期に変更されたコードを参照することがある。セッションが実際に何が起きたかを混同し始める。外部状態としてのSESSION.mdと機能間の/clearの組み合わせが、これがビルドを脱線させるのを防ぐ。

誰も警告しない失敗モード

これらは文書化されていて、具体的で、すべて実際のプロジェクトから出典がある。

ゴーストファイル。公式Claude Codeリポジトリのissue #26771：Claude Codeがディスクに書き込まれなかったファイルを作成したと自信を持って報告する。ツールの出力は成功を示す。git statusは別の話をする。根本原因には、パーミッションエラー、パス解決の失敗、ドロップされたツール呼び出しが含まれる。修正は簡単：ファイル操作後に常にgit statusで確認する。Claudeが言ったからといってファイルが存在すると思い込まない。

APIメソッドのハルシネーション。Claudeがprisma.$upload()を使うコードを生成した。そのメソッドはPrismaには存在しない。他の文書化された例：存在しない設定オプションを作り出す（rate-limiterオプションとしてtrustProxy）、npmに存在しないパッケージ名を作り出す。修正：テストを実行する。生成されたコードが合理的に見えるからといって機能すると思い込まない。

過剰エンジニアリングの罠。100以上のセッション履歴を持つビルダーが、承認ポップアップが時々表示されないバグを修正するようClaudeに依頼した。Claudeの提案した修正：クラッシュを乗り越えられるよう承認状態をディスクに保存する。問題：エージェントはクラッシュ時にセッションログからコールドリジュームするため、承認状態はどのみち取得されない。完全に無駄な修正で、良いエンジニアリングのように見えた。複雑な提案を受け入れる前に問うべき質問：この問題は本当に解決する必要があるのか？

無言のAPIリネーム。Claudeがコードベース全体で公開APIエンドポイントをリネームした。それらのエンドポイントに依存していたすべてのクライアントが壊れた。修正：承認前に必ずdiffを確認する。公開APIのリネームとファイルの削除を特に確認する。

モバイルレイアウト。Claudeはしっかりしたデスクトップレイアウトを生成する。モバイルビューは頻繁に要素の重なり、テキストのオーバーフロー、詰まった間隔が発生する。Claudeは実機でテストするメカニズムを持たない。修正：完了とマークする前にすべてのレイアウトを実機で確認する。

コンテキストの誤記憶。約30メッセージ後、Claudeは決して下されなかった決定、違う形で言及されたファイル、会話の始まり以来変更されたコードを参照することがある。セッションが実際に何が起きたかを混同し始める。修正：外部状態としてのSESSION.mdと機能間の/clear。

80/20問題

週末に動作するアプリの80%を作れる。残りの20%がほとんどのバイブコーディングプロジェクトが静かに失敗するところだ。

初期ビルド後に静かに失敗するもの：アプリストアへの適合、実機のパフォーマンス、認証フローのセキュリティ、アーキテクチャ上の決定（テストなし、CI/CDなし）、ビジネスロジックのエッジケース。これは理論的な観察ではない。数百万人のユーザーを持つ企業がAI加速で構築し、5人のエンジニアが数ヶ月間AIコードレビューを行った。彼らの結論：「Claudeとコンピテントなデベロッパーでさえこのコードを見て『ああ、大丈夫だ』と言っただろう。大丈夫じゃなかった。」

WorthItのビルダーはローンチ後に専用のセキュリティ強化パスを実行し、入力バリデーションのギャップ、欠落したエラーハンドリング、XSS保護なしを発見した。セキュリティは自動的ではなかった。Columbia DAPLabの研究は、エラーハンドリングとビジネスロジックをAI生成コードで最も深刻で一般的な沈黙の失敗パターンとして特定している。

実践的な修正：セキュリティをポストローンチのステップではなく、すべての機能の一部として扱う。主要な機能がリリースされるたびにセキュリティパスを実行する。完了とマークする前にモバイルレイアウトを実機で確認する。最初からテストを成功基準に追加する。後付けにしない。

これはClaude Codeで構築することに反する主張ではない。ツールが自動的に処理するものとそうでないものについて正直になるための主張だ。

構造化された代替案

上記のビルドはすべてアドホックだ。1人、1つのClaude Codeセッション、機能ごとに構築。このアプローチは機能し、実際の限界がある。

限界は予測可能な形で現れる。セキュリティは自動的ではない。品質ゲートは毎回実行する規律が必要だ。ポストローンチのインフラ（エラー監視、パフォーマンス最適化、セキュリティスキャン）はプロジェクトごとに別途構築または設定する必要がある。過剰エンジニアリングの罠とゴーストファイルの問題には手動の警戒が必要だ。

Build This Nowは最高のバイブコーダーが自分自身のために構築しているものだ。オーケストレーション、品質ゲート、ポストローンチインフラを既成のシステムとしてパッケージする。14のポストローンチコマンド（/security、/pentest、/performance、/audit）が、個々のビルダーがローンチ後に必要だと気づく作業を処理する。すべてのデータベーステーブルに行レベルセキュリティがデフォルトで設定されており、後付けではない。Quality GateとBuild Fixerエージェントが、Claudeの出力では完成しているように見えるが実際には失敗する問題を捉える。Plannerエージェントが実装から設計上の決定を分離し、コードが書かれる前に3人のスペシャリストが機能を同時に分析する。

アドホックなアプローチは無料で学習に使える。構造化されたアプローチがスケールするものだ。buildthisnow.comに詳細がある。

上記の週末ビルドは例外的なケースではない。仕様をプロンプトより先に書き、機能間でコンテキストをクリアし、すべてのdiffを確認し、セキュリティをビルドの一部として扱ったときに起きることだ。Google EarthのGTAクローンからアプリケーションコードのない求人検索システムまで、幅がある。機能させた実践は同じだ。