みなさん、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