※Claude Codeを使用して記事を作成しています。
シリーズ：Claude Codeを使ったAndroidアプリ開発 失敗談
- #1：指示が曖昧だと、全然違うものができあがりがちな話
- #2：一度に大きすぎる指示を出すと、収拾がつかなくなりがちな話 ← 今回
※この記事の事例は、Claude Codeを使った開発で起こりがちなケースをもとにした想定例です。
Claude Codeの出力やエラーの内容は、環境や指示の内容によって異なります。
はじめに
#1で「指示は具体的に書こう」と学んでも、今度は別の落とし穴があります。
具体的に書こうとして、欲張りすぎてしまうことです。
起こりがちなケース
メモアプリを作ろうとして、「具体的に書かなければ」と意気込み、次のような指示を出したとします。
メモアプリを作ってください。
・ログイン画面（メール・パスワード・Googleログイン対応）
・メモ一覧画面（リアルタイム同期・無限スクロール）
・メモ作成・編集画面（タイトル・本文・画像添付・位置情報）
・リマインダー設定（指定日時に通知）
・設定画面（テーマ切替・通知設定・アカウント管理）
・Firebase Auth / Firestore / Storage 連携
・オフライン対応
・ダークモード対応全部を一度にお願いして、「具体的に書いたから完璧だろう」と思いがちです。
何が起こりうるか
Claude Codeは、頑張って実装してくれるはずです。
ただし、指示の範囲が大きいと、次のような問題が起こりやすくなります。
- 大量のファイルが、一度に生成される
- ビルドエラーが、複数出る
- 画面遷移が、一部つながっていない
- Firestoreのデータ構造が、画面ごとにバラバラになる
- 出力が長くなり、途中で途切れたり、細部の品質が下がったりする
どこから直せばよいかわからなくなり、最悪の場合は、全部削除してやり直すことにもなりかねません。
なぜこうなるのか
Claude Codeは、与えられた指示を一度に処理しようとします。
指示が大きすぎると、次のようなことが起こりやすくなります。
- それぞれの機能間の整合性が、取りにくくなる
- エラーが出ても、どこが原因かわかりにくくなる
- 一部の実装が、「とりあえず書いた」状態になる
- 出力が途中で途切れることがある
人間のエンジニアでも、「今日中にこの機能を全部実装して」と言われたら、品質が下がりますよね。
Claude Codeも、同じような傾向があります。
対策：小さく分割して順番に指示する
同じメモアプリを、小さく分割して順番に指示する方針にします。
【第1段階】
メモアプリの画面構成だけ教えてください。
コードはまだ書かなくていいです。
どんな画面が必要か整理したいです。↓ 画面構成が決まったら
【第2段階】
まずメモ一覧画面だけ作ってください。
データはFirestoreではなく、今はダミーデータで表示するだけでOKです。↓ 一覧画面が動いたら
【第3段階】
メモ作成画面を追加してください。
まだFirebase連携はしなくていいです。
入力して「保存」を押したら一覧に追加されるだけでOKです。このように「今回やること」を1つに絞ると、毎回動くものを積み上げやすくなります。
分割指示のコツ
| やること | 分割の考え方 |
|---|---|
| 画面を作る | 1回の指示で1画面だけ |
| 機能を追加する | まずUIだけ、次にロジック |
| 外部サービスと連携する | まずダミーデータで動かして、後でつなぐ |
| デザインを整える | 機能が完成してから、最後にまとめてやる |
「今回はここまで」を宣言する
分割指示で特に効果的なのは、意図的に「今回はここまで」と明示することです。
メモ一覧画面を作ってください。
Firebase連携・認証・通知はまだ対応しなくていいです。
今回は見た目だけ完成させることを優先します。「やらないこと」を明示すると、Claude Codeが余計なことをしにくくなります。
まとめ
| 一度に全部頼む | 小さく分割して頼む | |
|---|---|---|
| 1回の出力の品質 | バラつきが出やすい | 安定しやすい |
| エラーが出たとき | 原因の特定が難しい | 特定しやすい |
| 完成までの道のり | 遠回りになりやすい | 着実に進めやすい |
Claude Codeは、「今できることを確実にやる」ことが得意です。
大きすぎるタスクより、小さく明確なタスクに分けて渡すほうが、良い結果につながりやすくなります。
次回：【Claude Code 失敗談 #3】「いい感じにして」が、うまく伝わらなくなりがちな話
