Claude Codeの成果物が毎回『惜しい』で止まる副業運用者が、依頼前に握る判断リストと完了条件2枚

Claude Codeに丁寧に指示を書いてるのに、返ってくるコードが毎回「惜しい」で止まる。自分は10年以上現役でエンジニアをやりつつ副業でAIエージェントを回しているけど、この「惜しい」を潰すのに何度も時間を溶かしてきた。原因は言い回しの巧拙じゃなく、実装の前段で握るべき情報が握れていないことにある。

プロンプトエンジニアリングという言葉が流行った頃と、今のAIコーディングとの向き合い方はもう別物だ。文末を敬語にするか命令形にするかで出力が変わる時代は終わって、今のClaude Codeは実装前にどれだけ会話したかで成果物の精度が決まる。ここを勘違いしたまま「もっと詳しく書けばいい」の方向に走ると、依頼文だけが長大になって、成果物の精度は伸びない。この記事では、依頼を長くする代わりに実装前の会話を設計する話と、成果物の合格ラインを先に言語化する話をまとめる。

指示は出してるのに、Claude Codeの成果物が「惜しい」で止まる理由
実装前に「疑問点を全部出して」と言うだけで手戻りが減る
「動いた」の基準を先に言語化しないと、AIは動くコードで満足する
確認作業が減った分だけ、次の施策に時間を回せる
まとめ
参考
【PR】フリーランスエンジニアにおすすめのツール
【PR】おすすめの書籍
1. あわせて読みたい

指示は出してるのに、Claude Codeの成果物が「惜しい」で止まる理由

副業でClaude Codeを使い始めた人からよく聞くのが、「指示は詳しく書いてるのに、出てくるコードが微妙にズレる」という悩み。自分も最初はそうだった。README全部貼って、参考ファイルのパスも列挙して、期待動作も書いた。それでも半分くらいはやり直しが発生する。

原因は情報量じゃなくて、AIが実装中に無意識に置いてる前提の数だ。人間がコードを書く時も、細かい決定を無意識に処理してる。ライブラリのバージョン、エラーハンドリングの粒度、既存コードとのスタイル整合、テストの書き方、この辺りは頭の中でサッと決まって手が動く。Claude Codeも同じで、指示に書かれていない部分は既存コードを読んで推測し、推測しきれない部分は「たぶんこう」で埋める。

問題はその「たぶんこう」の量が、人間が想像してるより桁違いに多いこと。例えば「認証機能を足して」と依頼した時、AIは内部でセッション方式かトークン方式か、有効期限をどうするか、既存ミドルウェアに寄せるか新規で組むか、DBスキーマにどうカラムを追加するか、フロントの状態管理はどこに置くか、を一瞬で決めていく。全部を人間に聞かれたらキリがないから聞かない。聞かないから、出てきたコードを見て「ここが違う」となる。

Towards Data Scienceに寄稿しているEivind Kjosbakken氏も同じ指摘をしていて、AIコーディングエージェントは人間が想像するより遥かに多くの仮定を暗黙のうちに置く、と書いている。ここを自覚しないまま「いい感じでよろしく」に近い依頼を投げ続けると、いつまでも「惜しい」から抜けられない。逆に言えば、この仮定を実装前に炙り出す仕組みさえ作れば、成果物の当たり率は一気に上がる。

実装前に「疑問点を全部出して」と言うだけで手戻りが減る

じゃあどうするかというと、実装前に一言足す。「実装に入る前に、判断が分かれそうな点を全部リストアップして」と伝えるだけでいい。これだけで、Claude Codeは実装の代わりに質問を返してくる。

自分がやっているのは、依頼の最後にこの一文を必ず入れること。「認証機能を足して。ただし実装に入る前に、既存コードを読んで、判断が分かれそうな点を全部挙げて。優先度順で並べて、それぞれ選択肢と自分の推奨を添えて」。この形にすると、返ってくるのは実装ではなく判断リストになる。

判断リストが手元に来ると、こっちは選ぶだけでいい。セッション方式か、有効期限は24時間か7日か、既存ミドルウェアに寄せるか。5〜10項目くらい出てくるので、上から順に「これ」「これ」と回答していく。この会話を挟むだけで、後段の実装の精度がガラッと変わる。手戻りが体感で半分以下になった。

大事なのは「疑問点を出して」だけで終わらせず、選択肢とAI側の推奨まで出させること。選択肢がないと単なる質問になって、こっちが答えを考える羽目になる。推奨があれば「基本それでOK、ここだけ変えて」で済む。会話のラリー数が減って、判断だけに集中できる。副業でやってる以上、深夜に1時間だけ触るような使い方が多いので、ラリー数を減らせるかどうかは切実に効いてくる。

同じ元記事で紹介されている手口として、HTMLレポート形式で選択肢を出してもらうやり方もある。決定事項ごとにボタンを配置したHTMLをClaude Codeに書かせて、ブラウザで開いて選択する。テキストで判断リストを追うより、視覚的に一覧できる分だけ判断が速い。案件が大きくて判断項目が10を超えるような時ほど効いてくる工夫だ。自分は普段はテキストで済ませているけど、要件が固まりきってない新規機能の初回はHTML化する価値があると感じている。

「動いた」の基準を先に言語化しないと、AIは動くコードで満足する

もう一つ、成果物の質を左右するのが「テストの仕方をAIに伝えているか」。ここが抜けると、Claude Codeは「コードとして成立している」時点で完了報告してくる。読者から見ると「動くけど自分が欲しかったのはこれじゃない」になる。

例えばチャット機能を実装するなら、依頼文にこう足す。「実装が終わったら、ローカルサーバーを起動してブラウザで開いて、実際に質問を入力して、AIから応答が返ってくることを確認して。返答がストリーミングで流れることも見て」。この一文を入れるだけで、Claude Codeは自分で動作確認まで走ってくれる。ヘッドレスブラウザの操作もツール経由で頼めば、こちらが画面を見なくても再現手順の実行結果を報告してくれる。

自分は依頼テンプレートに「完了の定義を最初に書く」欄を用意している。実装内容の下に「これが満たされたら完了」というチェックリストを添える。項目は簡単でいい。「トップページで新規登録できる」「登録後にダッシュボードに遷移する」「間違ったパスワードでエラーが出る」。3〜5個で足りる。粒度を細かくしすぎるとテンプレートが重くなって書く気が失せるので、ユーザーが触る動線を最短で1周する視点で書くのがちょうどいい。

このチェックリストがあると、AIは自分で確認手順を組んで、確認結果を報告してくれる。こちらの確認作業は「AIが出した確認結果が信用できるか」だけになる。実装の中身をゼロから追う必要がなくなるので、レビュー時間が圧縮される。ときどきAIが確認したつもりで抜け漏れがあることもあるので、疑わしい時だけ自分で1周する運用にしている。全部を毎回自分で確認するのに比べると、負荷は圧倒的に軽い。

副業でClaude Codeを回すと、時間の一番の敵は「動作確認して、直して、また確認する」のループ。ここを短縮できるかどうかが、副業として採算に乗るかの分岐点になる。指示に「動いたの基準」を最初から書き込む癖が、長く効いてくる投資だ。

確認作業が減った分だけ、次の施策に時間を回せる

判断リストと完了基準を先出しする運用に切り替えてから、自分は1タスクあたりのやり直し回数が明確に減った。数値で厳密には測っていないけど、以前は3〜4往復かかっていた実装が1〜2往復で終わる。差の2往復ぶんの時間が丸ごと浮く。

浮いた時間で何をするかが、稼げるかどうかを分ける。自分の場合はABテスト・アフィリエイト導線の見直し・記事の投稿頻度に回している。副業でAI運用を回してる人の多くが、Claude Codeが動くようになったところで満足して止まる。動く仕組みを作ったのに稼げない、という壁の正体は、動かした後に何を回すかが決まっていないことが大きい。実装スピードを上げても、上げた分を検証やマーケに回せていないと、収益にはつながらない。

もう一つ副次効果として、依頼の書き方が変わると自分の思考が整う。「判断が分かれる点は何か」「動いたの基準は何か」を毎回言語化していると、自分が本当は何を作りたかったのかが早い段階で見えるようになる。仕様が曖昧なままAIに投げて、出てきたものを見て「これじゃない」と気づく回数が減る。企画段階の解像度が上がる感覚がある。

実際、Claude Codeを毎日触る人ほど、依頼のテンプレを持ってるかどうかで作業量が変わってくる。テンプレは大袈裟なものじゃなくていい。3行でいい。「既存コードを読んで、判断が分かれる点を選択肢と推奨付きでリストアップして。判断が済んだら実装。実装後、以下の完了条件を自分で確認して報告して」。この3行をIME辞書やスニペットに登録しておいて、依頼のたびに呼び出す。仕組みとしては地味だけど、毎回書く手間がゼロになる分だけ運用が続く。

もう1つ書き添えておくと、この運用は音声入力と相性がいい。実装前の判断リスト依頼は文章としては長くなりがちなので、キーボードで書くのが面倒で省略しがちになる。しゃべって流し込むと省略の誘惑が減って、必要な文脈を全部渡せる。元記事のKjosbakken氏も文字起こしツールを使っていて、コンテキストを省略しなくなったのが一番効いたと書いている。同じ実感がある。

Claude Codeへの指示は、ただのプロンプトじゃなく実装前の要件定義ミーティングだと捉え直すといい。ミーティングで判断を先に済ませて、実装は淡々と流す。この順番を守るだけで、成果物の当たり率と副業の稼働時間の両方が変わってくる。