AIへの依頼は、なぜ小さく分けるほどうまくいくのか
結論から書く。Claude CodeやCursor、ChatGPTのようなAIコーディングツールに大きな仕事をまとめて投げると、途中で文脈を見失われ、期待と違う実装が返ってくる確率が上がる。対策は単純で、依頼を「検証可能な小さな単位」に分割し、前のステップの出力を次のステップの入力として渡すことだ。これはAnthropicの公式ドキュメントでも「プロンプトチェーン」として言及されている考え方であり、筆者自身の日々の運用でも同様の感覚がある。
ただし、この記事で紹介する「分割の基準」の多くは筆者の経験則であり、万人に効く公式の指標ではない。公式の見解と、筆者の実感を分けて書く。
大きな依頼がなぜ崩れるのか
一発の大きなプロンプトで「機能Aを実装して、テストも書いて、リファクタリングもして、READMEも更新して」のように複数の異なるタスクを詰め込むと、モデルが後半の指示を軽視したり、前半の指示を忘れたりする挙動が起きやすいとされている。
一つのプロンプトに複数の異なるタスクを詰め込むと、モデルが後半の指示を軽視したり、前半の指示を忘れたりする挙動が起きやすい
これはAnthropicのプロンプトエンジニアリングガイド「chain prompts」内の説明に基づく。単一責務のプロンプトに分けることで、モデルの注意が分散しにくくなるという趣旨だ。
筆者の体感では、これは「モデルが賢いかどうか」というより「一度に処理する情報の種類が増えるほど、各タスクへの実行精度が薄まる」という単純な現象として理解している。ここは実測に基づく主観であり、モデルの内部挙動を保証するものではない。
公式が推奨する「分割して進める」ワークフロー
Claude Codeのような自律的コーディングエージェントの使い方について、Anthropicのエンジニアリングブログでは、大きな仕事をまとめて投げるのではなく、計画を立ててから小さく検証可能な単位で進めるワークフローが紹介されている。具体的には「探索(explore)→計画(plan)→実装(code)→コミット(commit)」のように段階を分けて依頼する手法だ。
探索: まず現状のコードやドキュメントを読ませて状況を把握させる
計画: 実装方針をテキストで書かせ、人間がレビューする
実装: 承認した計画に沿って、小さい差分で実装させる
コミット: 差分をレビューし、問題なければコミットする
このワークフローの利点は、「計画」の段階でズレに気づけることにある。実装が終わってからやり直すより、計画書の1行を直す方がコストが低い。
なお、上記2つの公式ドキュメントからの引用は、いずれも記憶に基づく参照であり、実際のドキュメント本文と完全に一致するかは公開前に再確認が必要な状態にある。読者が実務に取り入れる際は、リンク先の一次情報を直接確認することを推奨する。
どこまで細かく分ければいいのか
「小さく分ける」と言われても、分割の粒度に明確な正解はない。これは公式ドキュメントにも数値的な基準は示されておらず、筆者の経験則として以下の目安を置いている。
1つの依頼で触るファイルは、できれば1〜3個まで — それ以上になると、レビューする側も差分の全体像を追いにくくなる
1つの依頼の中に「判断」を1つまでに絞る — 「どう実装するか」と「どうテストするか」を同時に判断させない
出力を読んで30秒以内に良し悪しが判定できるか — 判定に時間がかかる依頼は、粒度が大きすぎるサイン
これらは筆者が試行錯誤の中で採用している基準であり、効果を数値で検証したものではない。あくまで一つの参考として捉えてほしい。
分割しすぎるとむしろ効率が落ちる
一方で、分割すればするほど良いわけでもない。1行修正のような些細な作業まで律儀に「探索→計画→実装」のステップを踏ませると、指示を書く手間や承認のやり取りが増え、トータルの時間はむしろ伸びる。
筆者の感覚では、分割の判断基準は「失敗したときの手戻りコスト」に置くとバランスが取りやすい。手戻りが小さい作業(タイポ修正、ログ追加など)はまとめて依頼し、手戻りが大きい作業(設計に関わる実装、複数ファイルにまたがる変更)は細かく分ける。これも筆者個人の運用ルールであり、チームやプロジェクトの性質によって最適解は変わるはずだ。
実務でやっていること
筆者が普段Claude Codeを使うときに意識しているのは、次の3点だ。
大きめの機能追加は、必ず先に計画をテキストで書かせてから承認する
1回の依頼につき「何を確認すれば完了とみなせるか」を先に自分の中で決めておく
出力のブレが大きいと感じたら、依頼そのものを分割し直す(モデルを変えるより先に試す)
これらは筆者自身の運用であり、公式に推奨されている手順そのものではない体験談として書いている。
まとめ
AIへの依頼を小さく分けるのは、単なる作法ではなく、モデルが一度に注意を向けられる範囲の限界に対処する実務的な工夫だ。公式のプロンプトエンジニアリングガイドやClaude Codeのベストプラクティスも、この方向性を支持している。ただし「どこまで細かく分けるか」の具体的な粒度は、公式に明確な基準があるわけではなく、筆者を含め各人が経験則で調整しているのが実情だ。まずは「計画を立ててから小さく実装する」という最小限の型から試し、自分の作業に合った粒度を見つけていくのが現実的だと思う。
