無料記事 2026.10.26 読了約18分

⚙️ 8回依頼・7回全滅——24分で終わらなかったAIレビューが教えてくれたこと

@bokuwalily ・ 90本

プロフィール写真を保存するだけの機能に、24分で8回AIレビューをかけたことがあります。

7回目まで、全部「不正解」でした。

1回直すたびに、新しい問題が隣から顔を出す。指摘の内容は一度も重複しない。何回やっても終わらない感覚が、じわじわとしんどくなっていく24分でした。7回目を受け取ったとき少し笑いました（笑）。「これ、終わらせる気がないのかな」と。

でもこの体験が、AIを使ううえで一番大事なことを教えてくれました。「正解の定義を先に書く」という順番のことです。技術的な話ではないので、コードがわからない方にも読んでいただける内容です。AIで何かを作ろうとしたとき、同じ場所でハマらないように——今日はその話を書きます。

その日の午後2時に何が起きていたか

プロフィール写真の保存機能——「簡単そう」に見えた

その日わたしが取り組んでいたのは、アプリのプロフィール写真をアップロードして保存する機能です。ユーザーが自分の写真を選んで、アプリに登録できるようにする、あの機能です。

「写真を選んで保存するだけでしょ？」と思いますよね。わたしも最初はそう思っていました。でもこの機能、実際には決めなければいけないことがいくつもあります。「写真をどのタイミングで保存するか（確定ボタンを押す前？後？）」「同じユーザーが何度も写真を変えたとき、古い写真はどうするか」「保存できる容量や枚数に上限を設けるか」「ファイル名が重複しないようにどうするか」「スマートフォンで縦に撮影した写真が横向きに表示されないようにするか」。

これだけの「決めること」が、コードを書き始める前に積み上がっています。パッと見ると単純な機能でも、掘り下げると決断の連鎖が待っている——これが個人開発の面白さでもあり、ハマりやすさでもあります。

でもその日、わたしはそれを全部あいまいなままAIにレビューを依頼してしまいました。頭の中では「なんとなくこういう感じ」というイメージはあるのに、それを言葉にしていなかった。「なんとなく」は文字として存在しないので、AIには伝わりようがなかったわけです。

最初の依頼文に「終わり」がなかった

午後2時ちょうどに送った最初のレビュー依頼はこんな内容でした。

「プロフィール写真をアップロードして保存する機能のコードです。レビューしてください」

今思えば、この文のどこにも「どうなったら合格か」が書かれていません。「何を確認してほしいか」もない。「どの観点でレビューしてほしいか」もない。「このプロジェクトの優先順位は何か」もない。

たとえるなら、「この料理、食べてみてください」とだけ伝えて、「どう感想を言えばいいか」の方向性を何も伝えずにいるようなものです。塩気が強いと言う人もいれば、盛り付けを褒める人もいれば、栄養バランスを指摘する人もいる。どの視点で評価するかを伝えなければ、どこから何を言ってもらっても「そこじゃないんだよな」となってしまいます。

AIはその依頼を受けて、「今見えている問題を探して教える」という動作を、7回にわたって律儀に繰り返してくれました。AIが丁寧なのは確かなのですが、それが逆に「無限に続く」形になってしまっていました。

「わかってるけど言語化できていない」状態の怖さ

後から振り返ってみると、自分の中にはうっすらと「こうあるべき」という完成イメージがありました。「確定ボタンを押したら保存が走る」「古い写真は消す」「ファイル名が重複しないようにする」——これくらいの認識はあったんです。

でも「認識がある」と「言葉で定義した」はまったく別物でした。

頭の中にあるイメージは、自分だけが見えているものです。AIには届いていない。そしてAIは届いていない部分を補うために、「ベストプラクティス」として知っているすべての観点を一つずつ確認しにきます。それはAIの仕様通りの正しい動作なのですが、依頼側が「終わりを定義していない」と、それがループとして機能してしまいます。

「なんとなくわかっている」ままで進めてしまうことの怖さは、コードに限った話ではないと思います。文章を直してもらうとき、資料のフィードバックをもらうとき——「なんとなく良くしてほしい」では、どこまで直しても「なんか違う」が続きます。この構造はまったく同じです。

7回連続で出続けた「不正解」の内訳

指摘内容を時系列で並べると

記録を見ると、こうなっています。

1回目（2:00）「保存処理が非同期になっていないため、処理中にUIが固まる可能性があります」

2回目（2:03）「エラーが発生したときの処理が抜けています。失敗した場合にユーザーへの通知がありません」

3回目（2:06）「ファイルサイズの上限チェックがありません。大きなファイルをそのまま保存しようとすると問題が起きます」

4回目（2:09）「ファイル名が固定されているため、複数回アップロードするとファイルが上書きされる可能性があります」

5回目（2:13）「保存先のパスがハードコーディングされており、環境によって動かなくなるリスクがあります」

6回目（2:17）「スマートフォンで撮影した写真の向きを補正する処理がないため、回転して表示される場合があります」

7回目（2:20）「上限チェックと実際の保存処理の順番が逆になっています。上限を超えていても保存が始まってしまいます」

こうして並べると、まるでチェックリストのように見えます。でも問題は、これが「1つの機能」に対して、7回連続で出てきたということです。

しかも気づいてほしいのは、5回目と6回目の指摘——「保存先のパスが固定」と「写真の向きの補正」——これらは、1回目を修正したことによって発生した問題ではありません。最初からそこにあったはずの問題が、4回修正を重ねてようやく視界に入ってきた、という順番です。AIは「今見えているなかから優先度が高そうな1件を出す」という動作を毎回繰り返していたわけです。

直すたびに不具合が「隣へ引っ越し」していた

7回目の指摘、「上限チェックと保存処理の順番が逆」——これ単体は直すのに2〜3分の修正です。でも6回目を直したことで、この問題が生まれていたわけです。

直すたびに不具合が隣に移っていた。コードを見ていない方にわかりやすく言い換えると、「壁の穴を埋めたら床に隙間ができた。床を直したら天井から音がするようになった。天井を補修したら、また別の壁がずれた」という状態です。

根本の設計図がないまま、部品だけを足したり削ったりしていたからこうなりました。設計図を先に確認してから直せばよかった——そのことに気づいたのは、7回繰り返した後でした。

時間も消耗しますが、「終わらない感覚」がじわじわ積み重なっていくのが一番きつかったです。

「また新しい問題が出た」の積み重ねが地味に疲弊させる

3回目あたりまでは「よし、直そう！」という前向きな気持ちがあります。5回目になると少し落ちてきます。7回目を受け取ったとき、わたしの頭の中には「これ、本当に終わるの？」という疑問が浮かんでいました。

精神的なコストが、時間コストよりも大きくなっていた、という感覚です。

一度同じ体験をした人なら、この感覚はわかると思います。何かをやるたびに新しい問題が出てくるという経験は、生産性の話よりもモチベーション管理の話になってくる。「AIを使いこなせていない自分」への自信の低下も、さりげなく積み上がっていきます。

この疲弊のサイクルを断ち切るためにも、「終わりを定義する」という一手は、技術的な効率化であるのと同時に、精神的な保護でもありました。

「正解がなかった」のではなく「正解の定義」がなかった

AIが自分から教えてくれない1つのこと

ここが今日の記事で一番伝えたいところです。

AIは「聞かれたことに答える」のがとても得意なツールです。「このコードに問題はありますか」と聞けば、本当に誠実に問題を探して教えてくれます。でも、AIが自分から教えてくれないことが1つあります。

「何をもって正解とするか」です。

わたしの7回分の指摘は、どれも正しい指摘でした。非同期化も、エラー処理も、ファイル名の一意性も、どれも「あったほうがいいもの」です。でもそれは「全部なければ合格にしない」という意味ではありません。

「このプロジェクトでは最低限何をクリアすれば合格なのか」——それを定義していなかったから、AIは毎回「気になること」を1つ指摘し続けるしかなかったんです。AIが悪いのではなく、終わりを定義しなかった依頼設計の問題でした。

最初に書くべきだった「3つの契約」

今のわたしなら、最初のレビュー依頼の前に、この3点を自分の言葉で書いてから依頼します。

契約1：保存の順序を固定する
「ユーザーが確定ボタンを押したタイミングで保存処理を開始する。それ以前は保存しない」

契約2：ファイル名のルールを決める
「ランダムな文字列と保存時刻を組み合わせたファイル名を使う。重複は発生しない前提とする」

契約3：上限の判定タイミングを決める
「保存処理の開始前に上限チェックを行う。上限を超えていれば保存しない」

この3行を「合格条件」として冒頭に書いた上でレビューを依頼すれば、AIはこの3点を基準に「クリアできているか」を判定してくれます。「気になること」を無限に探し続ける動作にはなりません。

「そんなことでいいの？」と思われるかもしれません。はい、これだけで大丈夫です！重要なのは完璧さではなく、「ここまでできていれば合格」という境界線を引くことです。その境界線があることで、AIは「境界線の内側にあるか」を判定できます。境界線がないと、外の世界を無限に探し続けるしかない——AIの動作としてはそれが正しいのです。

「依頼前の3行」を書く練習

最初は少し慣れが必要かもしれません。でも書き方には型があります。こんな問いに答える形で書くと、スムーズに言葉が出てきます。

「この機能を使う人が"できた"と感じるのは、どんな状態のとき？」
「今回だけは妥協していいと割り切る部分はどこ？」
「もし1つだけ絶対に外せない条件があるとしたら、それは何？」

この3問に答えるだけで、おおよその合格条件が出てきます。完璧な仕様書を書く必要はありません。箇条書き3行、自分の言葉で十分です。「技術的に正確かどうか」を気にしなくていいです。「使う人から見てどうか」という視点さえあれば、AIはその意図を汲んでくれます。

ループにはまる人の「依頼文の共通点」

「なんとなく不安だから見てほしい」が最も危険

AIレビューのループにはまる人の依頼文には、ある共通点があります。「なんとなく不安だから見てほしい」という構造です。

自分の中に「これで完成」という基準がない状態で、「おかしいところを教えてください」とお願いする。AIは言われた通り、おかしいところを探して教えてくれます。でも、その「おかしいところ」が無限に続くかどうかは、AIには判断できません。

わたしがまさにそれでした。「なんか不安だからレビューしてもらおう」という気持ちで、8回の旅が始まっていました。

「1つ直したら即投げる」の反射もループを作る

もう一つのパターンは、指摘が来たらすぐ直してすぐ次のレビューを投げる、という反射的な動きです。

指摘が来る→2〜3分で直す→すぐ次を投げる。この速度で回すと、8回でちょうど24分になります。でも「終わりに近づいているかどうか確認する」ステップがないので、いつまでたってもゴールが見えません。

本当に速く終わらせるためには、「立ち止まってゴールを定義する」時間が必要でした。矛盾しているように聞こえるかもしれませんが、立ち止まることが最速の道でした。

ループに入った依頼文と抜けた依頼文、並べると

参考に、ループに入った依頼文と、脱出できた依頼文を並べてみます。

ループに入った依頼文の例：
「プロフィール写真をアップロードして保存する機能のコードです。レビューしてください」

→ AIが何を基準にレビューすればいいかわからない。観点の数だけ指摘が来る可能性がある。

脱出できた依頼文の例：
「プロフィール写真の保存機能のコードです。以下の3点がクリアできているかを確認してください。①確定ボタンを押してから保存が始まること。②ファイル名が一意になっていること。③保存前に上限チェックが走ること。この3点がクリアできていれば合格とします」

→ AIは3点の基準に対して「クリアできているか/できていないか」を判定できる。指摘があっても、その3点に絞られる。

文字数は増えましたが、所要時間は大幅に短くなりました。「先に定義する」の効果は、依頼文を長くすることで得られるのではなく、「終わり」を含めることで得られます。

8回目に初めて「完成」が出た理由

7回目の後に5分だけ手を止めた

7回目の指摘を受け取ったとき、わたしは手を止めました。「このまま直して8回目を投げても、また9回目が来るかもしれない」と感じたからです。

そこで5分だけ、メモに「この機能が合格になる条件」を書き出しました。箇条書きで3行。先ほどの3つの契約です。

書いてみると、驚くほどあっさり書けました！ 10分かかると思っていたことが5分で終わった。そして「なぜ最初からこれをやらなかったんだろう」という気持ちが、正直じわっと湧いてきました（笑）。

その3行を、レビュー依頼文の冒頭に追加して、8回目を投げました。

8回目の返答で24分の旅が終わった

「ご提示の3点（保存順序・ファイル名の一意性・上限チェックのタイミング）はすべてクリアしています。実装に問題はありません」

24分間の旅が、ここで終わりました。

後から計算すると、最初の7回が合計約21分。8回目の準備（3行を書く）が5分。8回目のレビューが約3分。合計29分かかりましたが、最初から5分かけて終了条件を書いてから始めていれば、1回目で合計8分以内に終わっていた計算です。

21分の消耗が、5分の準備で消えた——という体験でした。

この5分を惜しんで先に進もうとしたことが、21分の遠回りを作っていました。

よくある疑問：「要件が途中で変わったらどうするの？」

ここで一つ、先回りしてお答えしておきます。

「合格条件を先に決めても、途中で要件が変わったら意味ないのでは？」

これはよく出てくる疑問です。でも答えは「変わったら書き直せばいい」です。

合格条件は石に刻む約束ではありません。「今この瞬間、何をもって合格とするか」のメモです。要件が変わったら、メモを更新して、AIへの依頼も更新する。それだけです。

むしろ「要件が変わった」ことを明示的に宣言することで、AIが「前回と条件が変わった」という認識を持てます。「前回のレビューの指摘を全部直した」のに「また新しい問題が出てきた」という状況の多くは、要件の更新が言語化されないまま進んでいることが原因です。「条件が変わりました。今回の合格条件はこれです」と添えるだけで、ループの入り口が一つ塞がります。

「定義を先に書く」習慣に変えてから

レビュー前に必ず書く3行

この経験から、AIにレビューを投げる前に必ず書くようにした3行があります。

この機能が「完成」になる条件は何か
今回確認してほしい観点は何か
どういう状態になったら終わりにするか

慣れれば2〜3分で書けます。でも書くか書かないかで、「1回で終わるか・7〜8回ループするか」が変わります。

繰り返しに気づいたら「定義が抜けている」サイン

「あれ、また似たような指摘が来た」と感じたとき、それは「合格条件が抜けているかも」というサインです。

繰り返しはAIの限界ではなく、依頼の設計の問題である可能性が高いです。そう感じたら、ひとまず手を止めて、「今回の合格条件、書いたっけ？」と確認するのが最速の打ち手です。

この習慣を取り入れてから、同じ機能に対して何度も何度もレビューを回したことがほとんどなくなりました。以前は毎回5〜8回が当たり前だったので、1機能あたりにかかる時間がかなり変わりました。作業そのものの速度よりも「無駄に消耗しない」という意味での変化が大きかったです。

AIを責めなくなった

この体験のもう一つの変化として、「AIがわかってくれない」と思わなくなりました。

以前は、指摘が続くたびに「なんでうまくいかないんだろう」という気持ちになっていました。でも今は「依頼文に何かが足りなかったんだな」と最初に考えます。AIは依頼された通りに動いています。ループしていたのは、AIの問題ではなく、終わりを定義しなかった自分の依頼設計の問題でした。

この視点の切り替えが、思ったより大きな変化をもたらしてくれました。「変えられる部分はどこか」を考えると、AIに変わってもらうより自分の依頼文を変えるほうがずっと速いので、スピードも上がりました。

非エンジニアの方こそ使える「定義から始める」順番

技術的な言葉は一切不要

「終了条件を書く」「合格基準を定義する」というと、難しそうに聞こえるかもしれません。でも技術的な言葉は全く必要ありません。

プロフィール写真の例なら、こう書くだけで十分です。

「写真を1枚だけ保存できること。保存するのはボタンを押した後。名前が重複しないようにすること」

これで十分、終了条件になります。「使う人から見てどうあるべきか」を自分の言葉で書けるなら、それがそのままAIへの「合格の定義」になります。

むしろ非エンジニアの方は、技術的な先入観がない分、「使う人から見た完成形」をシンプルに定義するのが得意なケースがあります。「技術的にどう実装するか」より「どうなったら完成か」のほうが先に来るから、という意味です。

エンジニアでない方が使う場面でも同じ構造

たとえばAIに「ブログ記事を書いてください」と依頼する場合も、まったく同じ構造です。

ループに入りやすい依頼：
「わたしのブランドについての記事を書いてください」

→ どんな読者向けか、何文字くらいか、どんなトーンか、何を一番伝えたいか——すべて不明。AIは「良い記事に必要な要素」を順番に確認しにきたり、一つ書いては直してを繰り返したりします。

1回で仕上がりに近い依頼：
「わたしのブランドについての記事を書いてください。読者は20代の個人事業主、文字数は1,500字前後、トーンはカジュアルで共感重視。伝えたいのは『専門知識がなくても始められる』という一点です。この条件を満たしていれば完成とします」

→ AIはこの条件を基準に書いてくれます。修正が出ても「条件に沿っているか」という軸があるため、ループにはなりにくい。

文章を作る、資料を作る、企画を考える——どんな作業でも、「これがそろっていれば合格」という基準を先に書く習慣は使えます。AIとの協力を、「直してもらう往復作業」ではなく「合格基準に対する照合作業」に変える、というイメージです。

仕組みの全部はこちらにまとめています

Claude Codeという開発ツールを自律的に動かしながら個人開発を続けている仕組みについて、AIレビューをどう組み込んで、どんな流れで作業しているかの全体像を別のnote記事にまとめています。興味がある方は、フッターのリンクからのぞいてみてください。

今日から使える「1問チェック」

投げる前に確認する1つの質問

AIにレビューや依頼をする前に、一つだけ自問するようにしています。

「わたしはこの依頼に『合格の条件』を書いたか？」

書いていなければ、2〜3行だけ追加してから投げます。それだけで、ループに入る確率がかなり下がります。

今日の記事を読んでくださった方に、ぜひ試してみてほしいのはこの1ステップです。次にAIに何かを依頼するとき、「これで完成、と言える状態はどんな状態か？」を1文だけ依頼文の頭に書き添えてみてください。

よくある疑問にまとめて答えます

読んでいる途中で浮かびそうな疑問に、先回りして答えておきます。

Q：合格条件を書こうとしても、自分でもよくわからないことがあります。どうすればいいですか？

A：それはAIに聞いてしまって大丈夫です。「この機能を作ろうとしています。合格条件として何を定義すればいいか、3点候補を出してもらえますか？」と聞くと、叩き台を出してくれます。それを選んで修正して、自分の言葉に直して使えばいい。「自分で全部決めなければいけない」わけではありません。AIと一緒に合格条件を作ってから、同じAIにレビューを依頼する——この順番でも全然OKです。

Q：条件を書いたのに、また新しい指摘が来ました。どう対処すればいいですか？

A：2パターンあります。①書いた条件の外側の指摘（たとえば条件外のセキュリティ上の問題など）なら、「今回は範囲外」と返してOKです。AIは「この機能の担当者として一般的な問題を報告する」という性質もあるので、条件を超えた指摘が来ることは普通にあります。それは「次回以降の検討事項」として受け取れば十分です。②書いた条件の内側の指摘（条件を満たしていないという指摘）なら、条件の書き方が曖昧だった可能性があります。条件の言葉を少し具体的に書き直してみてください。

Q：毎回3行書くのが面倒になりそうです。続く自信がありません。

A：わかります（笑）。最初の数回は確かに手間に感じます。でも慣れると「書かないと不安」に変わります。書かずに投げたときにループした経験が積み上がると、「先に書いておけばよかった」という後悔が先に来るようになるからです。テンプレートを作っておくと楽になります。「①使う人が"できた"と感じる状態：○○、②絶対に外せない条件：○○、③今回は後回しにする部分：○○」という3行テンプレを使い回すだけでも、だいぶ速く書けます。「書く」ではなく「穴埋めする」になると、負担がかなり下がります。