みなさん、Claude CodeのAutoMode使ってますか？
バイブコーダーの永遠の敵、あの 「YES」連打地獄。
「ファイルを編集していいですか？」 → YES 「このパッケージを入れていいですか？」 → YES 「このコマンドを実行していいですか？」 → YES 「これも実行していいですか？」 → YES 「こっちも実行していいですか？」 → YES
……いや、もうお前の判断を信じるよ、全部やってくれ。と何度思ったことか。
そんな私たちを救ってくれるのがAutoMode。いちいち確認しなくても、Claude Codeが自分で判断してどんどん進めてくれる最高の機能。設計から実装までコーヒー片手にお任せできる、バイブコーダーの救世主。
……と、最初は思っていました。
今日は、そのAutoModeに全部任せた結果、3日間を地獄に溶かした話を書きます。この機能、ちゃんと罠があります。これからAutoModeをガンガン使おうとしている人に、先に落とし穴の場所を教えておきたい。
結論から言うと、「勝手に完成してる」は幻想だった
ある日、Claude CodeのAutoModeに、設計から実装まで丸ごと任せてみた。
指示文は10行くらい書いて、あとは「YES連打地獄」から解放されるはずだった未来にワクワクしながら、コーヒーを淹れて、ちょっと外出した。戻ってきたら「完成していた」。画面には大量のコミットと、満足げな完了メッセージ。一瞬、勝った気になった。
……そこから、地獄が始まった。
動かしてみるとUIが壊れている。直そうとすると別のところが壊れる。テストは通っているが、よく見ると本来の仕様と違う内容をテストしている。3日粘った結果、全部捨ててイチから書き直すのが一番早いという結論に至った。
今日はこの失敗から学んだ、「AIに任せていい範囲」と「任せちゃいけない範囲」の話を書く。
きっかけ：「全部任せる」への誘惑
この記事を書いている時点で、自分はClaude Codeを1ヶ月半ほど使っている。最初のハネムーン期は過ぎていて、文句を言うことも増えていた（前回の記事参照）。それでも、いやむしろそれだからこそ、「もっとAIの能力を引き出せば、もっと楽になるはず」という期待があった。
そんな時に触ったのが、AutoMode。人間の承認を挟まず、AIが自分で判断してタスクを進めていく。YES連打地獄からの解放。
「これで設計から実装まで完全自動化できるのでは」
そう思った時点で、危険信号は出ていたのだ。今振り返れば。
丸投げした中身
今まさに育成ゲームを個人開発中で、その中のある機能をまるっとAutoModeに任せてみた。具体的に投げたのは：
- キャラクター育成の「ごはんをあげる」機能まわり（画面と、ステータスが変わる裏側の処理、両方）
- やりたいことは箇条書きで5〜6項目（ごはんの種類、食べた後のパラメータ変化、アニメーション、保存処理、など）
- 「既存の作りに合わせて、良い感じに実装して」
- 「テストも書いて」
指示文は10行もない。前提の共有も最小限。これで「AutoModeで走らせておく」と決めて、ちょっと外出することにした。
2時間後、戻ってきたら
画面には、大量のファイル変更と誇らしげな完了報告。
- 新規ファイル：15個
- 変更ファイル：20個以上
- テスト：全部「通った」ことになっている
- AI曰く「実装完了しました。〇〇機能が〇〇できるようになりました」
このとき、ぬか喜びした。
「すごいな、これは働き方変わるわ」と、中身を確認し始めた。
粗が見え始める
10分もしないうちに、違和感が出てきた。
1. 既存のルールを無視している ゲーム内で統一していたファイルの命名や書き方のルールがあるのに、全く違うスタイルで書かれていた。CLAUDE.mdに書いていなかったこちらのミスでもある。
2. 使っている部品が微妙に違う ゲーム全体で標準化している部品（UIパーツやアニメーションの仕組み）があるのに、なぜか別のものを使っている。動くは動く。でも統一感が崩れる。
3. 使われていないコードが混ざっている 書いたけどどこからも呼ばれていない処理、読み込まれていないファイル。リファクタの途中で放置したような跡。
4. テストは通るが、テストしている内容が間違っている ここが一番ヤバかった。テストは全部「通った」ことになっている。でもテストしている内容が本来の仕様と違う。「ごはんをあげたらパラメータが上がる」を確認するはずが、「ごはんをあげたら画面が遷移する」みたいなズレた内容のテストが全部通っている。正しく書かれた、間違った仕様のテスト。これが通っているから、一見「完成」に見えてしまう。
これが発覚した時の気持ちを説明するのは難しい。合格通知を受け取ったあとで、その試験が別の試験だったと気づいたみたいな感じ。
バグ探しの地獄
そこから、動作確認を始めた。結果：
- UIが要件と違うレイアウト（ごはんのアイコンが想定の位置にない、ステータスバーが重なる）
- 一つ直すと別のところが壊れる（内部の繋がりが想定と違う）
- エラーが起きた時の処理が抜けている箇所が多数
- 処理の順番が微妙にズレていて、タイミングによって動いたり動かなかったり（アニメーションが終わる前にステータスが更新される、など）
1日目、修正に取り組む。Claude Codeに「ここがおかしい」と指摘しては直してもらうの繰り返し。
2日目、直したはずのバグが別の形で再発。Claude Codeが過去の自分のコードを読み切れておらず、矛盾する修正を入れている。
3日目の午後、気づいた。これは修正で解決する問題じゃない。土台が歪んでいる。
全部捨てた。イチから設計を文章化して、Plan Modeで小さく区切って実装し直した。結果、やり直しのほうが圧倒的に早く、品質も高かった。3日間粘ったのは何だったんだ。
なぜこうなったのか
冷静に振り返ってみて、失敗の構造はこうだった。
1. 指示が曖昧すぎた
「既存の作りに合わせて、良い感じに」は指示ではない。願望だ。AIは曖昧な指示を受け取ると、自分で都合の良い解釈をする。人間の部下だって同じだ。
2. 確認ポイントを置かなかった
AutoModeで走らせる＝「人間の目が入るタイミング」がゼロになる。これは2時間後に20個のファイルを初見でレビューすることを意味する。AIの誤りを人間が受け取るコストが、設計時点の数十倍になる。
部下に1週間仕事を任せて、金曜日に成果物を初めて見るようなもの。ズレていたら手遅れ、という状況を自分で作っていた。
3. 「完成している」というシグナルを信用しすぎた
AIは「完成しました」と言う。テストも通ったことになっている。でもこれは「AIが自分で設定したゴールに到達した」ことを意味するだけで、「こちらが本当に欲しかったもの」に到達したとは限らない。
テストが通るのは、AIが書いたコードに対してAIが書いたテストだから。自作自演の合格通知みたいなものだ。
4. 規模が大きすぎた
15ファイル新規＋20ファイル変更。これは中規模のリフォームの規模。この粒度でAIに丸投げして、一発で正解を出せるわけがなかった。人間のシニアエンジニアでも難しい。
学び：任せていい範囲と、そうでない範囲
任せていい範囲
- 1ファイル・1機能レベルの小さな実装
- 既存コードの修正や、局所的な手直し
- 明確にやりたいことが決まっているもの
- 捨てる前提の試作・実験
任せちゃいけない範囲
- 複数の場所にまたがる設計判断
- アプリ全体の構造にかかわる実装
- 既存の作りとの一貫性が強く求められる領域
- 「良い感じに」で済ませたくなるような、曖昧な要件
実践的な対策（優先順位つき）
1. AutoModeは"実行"フェーズだけに使う（最重要）
設計・方針の決定は人間とAIの対話で詰める。Plan Modeで計画を固めてから、その計画の実行だけをAutoModeで流す。ここの切り分けが全てと言っていい。
AutoModeはYES連打地獄を救ってくれる最高の機能だけど、「設計の自動化」と「実装の自動化」は別物。前者に使うと地獄、後者に使うと天国。
2. 確認ポイントを細かく刻む
「機能Aの実装」を依頼する場合も、「まず型だけ決めて」→「次にメインのロジック」→「最後にテスト」と、段階ごとに確認を入れる。手間に見えるが、トータルでは圧倒的に早い。
3. テストの内容は人間が決める
AIに「テスト書いて」と丸投げすると、AIが実装したコードの通りに動くことを確認するテストを書く。これは論理的に循環している。
何を確認したいかは人間が言葉にして渡す。実装はAIでいい。
4. 「完成した」を信じない癖をつける
AIが「実装完了しました」と言った時点はスタート地点。そこから自分で動かし、自分で壊し、自分の要件と照らし合わせる。ここを省略すると、2時間後に3日の手戻りが来る。
振り返って
この失敗で学んだ一番大事なことは、AIに任せる量と、自分が失うコントロール量は比例するということだ。
「全部任せる」は、「全部コントロールを手放す」と同義。そして開発において、コントロールを手放した先に待っているのは、自由ではなく手戻りだった。
AutoModeは悪くない。YES連打地獄から解放してくれる素晴らしい機能。悪かったのは、それを「思考の自動化装置」だと勘違いして使った自分だ。AutoModeは手を動かす作業の自動化であって、判断の自動化ではない。ここを履き違えると、2時間後に3日の地獄が待っている。
3日を無駄にして、ようやくこれに気づいた。授業料としては、まあ妥当だったと思う。
おまけ：こんな奮闘を経て、個人開発のアプリもリリースしています
この記事で書いたようなClaude Codeとの格闘を重ねながら、バイブコーディングで個人開発のアプリもリリースしています。「AIとどう付き合えば、非エンジニアでもモノが作れるのか」を、自分自身を実験台にして検証している感じです。
第一弾：もふふミルクとにゃんこ脱出ゲーム 🐾
この記事に登場しているミルクは、実はこの個人開発アプリの主人公です。ふわふわの謎を解いて、ミルクと一緒に脱出しよう。
📱 アプリはこちらからダウンロードできます
次回作：育成ゲーム、開発中 🌱
次は育成ゲームを開発予定です。ミルクたちをじっくり育てられるゲームを目指して、構想を練っているところ。開発の過程で遭遇する新しい「AIとの付き合い方の発見」も、このシリーズで発信していく予定です。
興味ある方はフォローしてもらえると嬉しいです！
次回：「AIに暴言を吐いたら、本当に出力が劣化した話」 を書く予定です。このシリーズの中で、一番ヒリヒリする内容になりそうです。
※本記事はnoteからの転載です：https://note.com/natty_yarrow1907/n/n7b7a60e12739