AIにtodoアプリ開発を丸投げしたら失敗した — 事前に設計書を渡したらうまくいった話

Claude Codeに「todoアプリを作って」と適当に頼んだら、10回の修正と12個のエラー、さらにはUI微妙（Win94っぽい）破棄した。なので、Geminiで設計書を作り、それをClaude Codeに渡したら、前回の問題が解消されブラッシュアップされた。AIに実装を頼むとき、仕様書の設計がいかに重要かを、失敗・成功の両面から備忘も兼ねて記録しておく。

「todoアプリ作って」— 横着が過ぎて丸投げ

前回の記事でClaude Codeの初体験を書いた。顧客管理システムを作らせて「SaaSは終わりかもしれない」と嘯いた、あの時。。

今度は調子に乗って、アプリに挑む。

今、作りたいのは、Macのメニューバーに常駐するtodoアプリ。todoアプリはiOS向けがたくさんあるけれど、私はPCで作業しているときにモバイルをわざわざ開かない。PC上でさっと確認できて、パーソナライズされたものが欲しかった。優先順位をドラッグで変えられて、完了したタスクは「確認フェーズ」を経由して、アーカイブできる——余計な機能のないごくごくシンプルなやつ。

Claude Codeへの最初の指示は、こんな感じ。

Claude Codeは「了解しました」と言って、技術スタックの選定から始めた。Tauri v2（Rustベースのデスクトップフレームワーク）+ React + TypeScript。私はTauriが何かも知らなかったけれど、「Electronよりも軽量です」という説明に「はい」と答えた。

ここから、長い修正地獄が始まる。

エラーと修正の泥沼 — 10フェーズ、12エラー

Claude Codeが選んだTauri v2はRustベースのデスクトップフレームワークで、Electronより軽量なのが売りだ。ただし、macOSネイティブの挙動（ウィンドウの透過、外クリックで閉じる等）を実現するにはWebView越しにOS APIを叩く必要があり、非エンジニアが細かく指示できる領域ではなかった。最初のビルドは通ったが、出来上がったアプリは使いづらいし端的にダサい。

UIが使いづらいので、モダンにしてください。また日本語表記にしてください。

修正してもらう。少し良くなる。でもまだ問題がある。

起動すると、アイコンが二つ出るし、右のアイコンは反応しないし、UIまだ微妙だし、角丸はいいけど、透過してないから角が白いし。

さらに修正。次の問題が出る。

それぞれのタスクに期限（デッドライン）がつけられない。期限をつけてからタスクを追加するって仕様出ないとダメだね。あと角が透過してないから白くなってる。（直ってないない）UIのベンチマークはappleに。

こんなやりとりが延々と続いた。主なエラーだけでも12件。

「今日」「明日」「来週」のクイックボタンを提案されたので入れてもらったが、実際に動かしてみるも「不要」という感想しかなかった。

最終的に、私は打ち切った。

クリックで閉じれないし、さらに、日時がカードと分離してるのはなぜ？ まず設計が間違ってる。一旦終了します。

10フェーズの修正。12個のエラー。そして破棄。

Claude Codeが悪いわけではない。私の指示が悪い。「todoアプリ作って」と丸投げしたら、AIは「何を作ればいいか」の定義から自分で推測しなければならない。推測が外れるたびに修正が入り、修正するたびに別の箇所が壊れる。モグラ叩き状態だ。

AIコーディングで失敗する最大の原因は「丸投げ」にあるという指摘もやはりある（OPTiM TECH BLOG）。虎を屏風から出す前に、虎をどう扱うかの段取りを考えるのが人間の仕事だ、と。まさにそれだった。

設計書という発想 — Geminiに頼んだ理由

失敗から数時間、もう一度やり直すことにした。

今度は、Claude Codeに投げる前に「設計書」を作ることにした。ポンコツレガシー版で学んだことは明確だった——UIの構成、データの持ち方、操作フロー。これを先に決めないと、AIは推測で作るしかなく、結果的に何度も直すことになる。まぁ当たり前だ。

設計書はGeminiに作ってもらった。Claude Codeではなく、あえてGeminiを選んだ理由は——分業する方が人間の作業フローっぽいから笑（おそらくClaude Code内で完結しても、精度はあまり変わらなそう）

Geminiは対話しながら「考えること」が得意だと感じていて（私がそう思い込んでいて）、Claude Codeは「作ること」が得意（だと思い込んでる）。あと、Googleはやはり「スタバ」と一緒で、最後にやはり頼ってしまう。

考える仕事と作る仕事を分けた方が、単純にコントロールする人間（私）がやりやすいというのもある。人間社会でもそんな気がするし。

Geminiに渡したプロンプトはこんな感じ。

「このように依頼したら使いづらかった」と伝えた上で、「どんな機能が必要か提案して」とGeminiに聞いた。

Geminiは、設計書を出してきた。設計書には「Air-Flow ToDo」というアプリ名から始まり、技術スタックにSwiftUI + SwiftDataを提案し（Tauriではなく）、UI仕様、セクション構成（Routine / Active / Review / Archive）、データモデルのSwiftコードまで含まれていた。

さらに、Claude Codeにそのまま渡せるプロンプト（claude_prompt.md）まで作ってくれた。技術要件、UIスペック、モデル定義、最初のタスクが整理された状態で。

開発や制作をやっていれば当然の工程なのだけれど、「設計書を作ってから実装に入る」という手順を、AIに対してもちゃんと踏むべきだったのだと、この時気づいた。

設計書をClaude Codeに渡す

Geminiが作った設計書（blueprint.md）とClaude Code向けプロンプト（claude_prompt.md）を、レガシー版の開発ログ（todo-app-legacy.md）と一緒にClaude Codeに渡した。

先ほど作ったtodoアプリ（todo-app-legacy.md）はレガシーだったので、今回は、設計書（blueprint.md）を理解してから、claude_prompt.mdを元に実装してください。

Claude Codeは設計書を読み込み、まず環境を確認した。SwiftUIにはXcodeが必要だが、私のMacにはCommand Line Toolsしか入っていない。Claude Codeはそれを検出し、SPM（Swift Package Manager）ベースに切り替えてビルドを始めた。

出来上がったアプリを起動した。UIはAppleに寄せてきた。正直もう少し叩いたらより良くなる予感はしたけれど、レガシー版とは比べものにならない。

レガシー版で直らなかった問題が、ほぼ解消されていた。

なぜこうなったか。設計書の時点で、Geminiが「SwiftUI + NSPopover」という技術選定をしていたからだ。Tauriの問題（WebViewの透明化、外クリック検知）は、そもそも発生しない設計になっていた。

設計が正しければ、実装の大部分はAIが一発で仕上げてくれる。逆に設計が曖昧だと、AIは推測で作り、人間がモグラ叩きで直すことになる。

丸投げと設計書の差 — 非エンジニアが学んだこと

AIにアプリ開発を頼むとき、「何を作りたいか」を口頭で伝えるのと、設計書として渡すのとでは、結果がまるで違う。丸投げだとAIは推測で技術選定し、推測が外れるたびにモグラ叩きが始まる。設計書があれば、AIは迷わず実装に集中できる。非エンジニアこそ、設計を先にやる意味がある。この体験で分かったことを整理すると、

2026年現在のエンジニア界隈では「仕様書駆動開発」（Spec-Driven Development）が話題になっている（yoshidashingo）ようだ。要件定義・設計・タスク分解をドキュメント化し、AIに渡して実装させるアプローチだ。

私はエンジニアではないから「仕様書駆動開発」という言葉は後から知ったけれど、やったことは同じことだと思う。設計を先に作り、AIに渡す。これだけで結果が劇的に変わる。

ChatGPT初日は「ググる手間を省く道具」だった。Claude Code初日は「自分の代わりに仕事をする存在」だと思った。そして今は——AIは「設計通りに作ってくれる施工業者」に近い。設計図がなければ、どんなに腕のいい業者でも、建て主が満足する家は建たない。

もうひとつ。GeminiとClaude Codeの使い分け（これは私自身がレガシーなタイプであることに起因してるが）。Geminiに「考えてもらう」、Claude Codeに「作ってもらう」。AIはひとつのツールで全部やらせるより、得意分野で分けた方がいい——というのは、まぁ、古臭い考え方なんだろうな〜。

参考文献

• Anthropic. "Claude Code Documentation." docs.anthropic.com
• yoshidashingo. "Claude Codeで実践する仕様(スペック)駆動開発入門." yoshidashingo.com
• OPTiM TECH BLOG. "丸投げは失敗のもと？ 屏風の虎とAIに学んだプロジェクト効率化のコツ." tech-blog.optim.co.jp