1. プロローグ

初めて Claude Code を使って開発したとき、まず感じたのは作業速度の速さでした。
やりたいことをプロンプトに伝えるだけで、次々とコードが生成されていきます。
伝えたことは即座に反映されるため、

「あともう少しだけ」
「ここも直してもらおう」

やり取りを繰り返しているうちに、気づけばかなり長時間、同じセッションで作業を続けていました。
当時は、これが問題になるとは思っていませんでした。

2. 違和感は、静かに始まった

しばらく作業を続けるうちに、少しずつ違和感を覚えはじめました。

「生成されるコードがこちらの意図と微妙にズレている気がする」

とはいえ、コードは一応動いています。
致命的な不具合でもありません。

「あとでまとめて直せばいいか」

そう考えて、作業を止めずに続けていました。

やがて違和感は確信に変わりました。

Claude Code に修正を依頼すると意図通り反映されることもありますが、
別の箇所が以前の状態に戻ったり、関係ない部分に影響が出たりしはじめます。
いわゆるデグレが頻発し、修正の修正を繰り返す状態に陥りました。

それでも当時の私は、

「指示の出し方が悪いのでは」
「もう少し詰めれば良くなるはず」

と考えて、問題の原因を自分に求め、同じセッションで作業を続けていました。

決定的だったのは、テストに関するやり取りです。

本来はテストカバレッジ50%を目標にしていたテストがありましたが、なかなかテストが通りません。
修正ループに入りかけていたそのとき、Claude Code から予想外な提案がありました。

「まずは 5% 程度のカバレッジで通しましょう」

一見すると、段階的な進め方にも見えます。
しかしこれは問題を解決しているのではなく、問題そのものを小さくしようとしている 提案でした。
本来の目的である コード品質の担保 が後退し、
いつの間にか 「テストを通すこと」自体が目的 にすり替わっていたのです。

問題の本質は、 作業の区切りを決めないまま、長時間同じセッションを続けていたこと でした。

LLM（大規模言語モデル）は、与えられたコンテキストの中でタスクを前に進めることが非常に得意です。
Claude Code とのやり取りは、人間同士のペアプログラミングに近い強力さがあります。

一方で、AIには人間のように「立ち止まる」「疲労する」といった感覚がありません。

セッションが長くなるほど、参照されるコンテキストは複雑になり、
本来のゴールとは関係のない前提や試行錯誤の履歴（ノイズ）を多く含むようになります。
このノイズの蓄積が、

を引き起こしていました。

だからこそ、AI駆動開発では人間側が意識的に作業を区切る必要があります。
セッションを区切る行為は、

といった、人間の開発プロセスに相当します。

当時の私は「止める理由がなければ続けた方が効率的」と考えていましたが、
振り返ると、その継続こそが手戻りを増やしていました。

この判断が、AI駆動開発の成否を大きく左右します。

現在は、次のルールを意識しています。

1タスク = 1セッション
最初に「このセッションで何を完了させるか」を明確にし、達成したら必ず一度セッションを終了します。
条件を緩め始めたら区切る
テストカバレッジを下げる、警告を無視するなど、本質的でない回避策が出てきたら一度止まります。
「とりあえず」「一旦」が増えたら要注意
AIに「とりあえず実装してほしい」と考え始めた時点で、ゴールや判断基準が曖昧になっているサインです。
そのまま続けると迷走しやすいため、新しいセッションを切り、目的と完了条件を明文化し直します。

この経験を通して、AI駆動開発は「指示を出し続ける作業」ではなく、
「前提を管理し、意図を更新し続ける作業」 だと感じました。

長いセッションを続ければ続けるほど、目的が少しずつズレていきます。
セッションを区切り、目的と完了条件を言語化することは、AIと協働するために重要な作業です。

本記事の経験が、これからAI駆動開発に取り組む方の試行錯誤を少しでも減らせば幸いです。
今後もAIに関する学びや実践を記事にしていきますので、引き続きよろしくお願いします。