TIPS: コーディングエージェントの活用時、高速目grepで消耗しないために重要なタイムリープ戦術
コーディングエージェント（ClineやCursorなど）を使っている人は、うまくいくときは少ないプロンプトでさくっとやってくれるのに、あるタスクではそうじゃないという経験をしたことがあると思います。
「高速目grep」は、コーディングエージェントの途中経過を目で確認して、「待て、それはあかん！」って止めた上で、指示を出したり、作業をなかったことにしたりするものです。
これが必要になるケースを分類すると、筆者の理解では次の通りです：
- 使うべきじゃないテクニックを使ってしまう
- 使うべきじゃないライブラリなどを使ってしまう
- 場当たりなことをやらかす
- 設計ミスをやらかす
現行世代のLLMは、コーディングエージェントでは圧倒的にノウハウが確立された3.5/3.7-sonnetや、世界最高峰の頭脳であるGemini 2.5 Proですら、こういう「やらかし」は日常茶飯事です。
やらかしに対処するために高速目grepをするわけですが、実のところ疲労が激しく、非人道的なプログラミングスタイルです。
- リアルタイムでやらかし監視をしなければいけないのは、疲労感がとてつもない
- コーディングエージェントを使ってると、めちゃくちゃ口が悪くなる
- あるときは優秀なコードを書いてくれるLLMが、特定のことだけ急激にジュニアレベルのポンコツをやらかす
- （特にGemini 2.5 Proは）自信満々にやらかすくせに、強情なことがある
- （特に自信満々に失敗してるときは）その考えをたたきのめすために、「おまえは間違っている」「こうしろ」みたいな圧の強いプロンプトを出さざるを得なくなる
筆者はAI時代における思考負荷と精神衛生の問題は決して無視できない大きな課題だと感じています。
そこでこの記事では「タイムリープ戦術」を提案します。と言っても別に特殊なテクニックではありません。対話型AIなら当たり前に使われているテクニックです。
タイムリープ戦術は別に万能じゃないですが、使った方が高速目grepを少しでも軽減できるはずです。
タイムリープ戦術
Cline(あるいはcursor)のユーザーインターフェースは、ChatGPTのような対話型AIと同じものです。
- タスク（一連のセッション）は、こちらのターンから始まる
- Enterを押したら相手のターンが始まる
- 会話は積み重なる。過去の会話は後の会話に大小様々な影響を与える
- 途中でキャンセルボタンを押して、強制的にこちらの発言可能な状態に移行できる
- こちらの発言を書き換えて、そこから作業を再開できる（リトライA）
- そもそもタスクを破棄できるので、最初からやり直せる（リトライB）
対話型AIでは、最良の結果を得るために様々な形でリトライをすることが多いです。
コーディングエージェントでも、リトライAとリトライBを活用することで、履歴を汚染せずにやり直しが可能です。
だめだったらタイムリープを繰り返せばいいのです。
やり直しをするときは、LLMの持つランダム性（temparature）に期待してガチャるという方法もあります。意外とそれでうまくいくケースもあります。
でも、プロンプトや、与えるドキュメントなど、コンテキストを見直せば、うまくいく可能性は上がります。ある程度作業をやらせた上で、何に失敗しているのか？どういう情報が足りてないのか？を深く観察すれば、そのタスクがうまくいく確率を上げられるだけではなく、次の似たようなタスクの時にもうまくいく方法論を構築できるかもしれません。
プロンプトエンジニアリングは、タイムリープも活用しつつ、LLMの特性を正しく把握し、うまくいくためのプロンプトを探し出すゲームです。
例1
Rooに開発中のコーディングエージェントのデバッグをさせていた事例
挙動がバグってたのでデバッグをさせたところ、場当たりなコード変更をしていた。イラっとして途中で止めて、失敗原因を探す。その時点でRooは間違った理解をしていた。そこで修正を開始する前にタイムリープして、今後は間違わないように情報を増やしてリトライした。
例2
Rooに開発中のコーディングエージェントのデバッグをさせていた事例
挙動がバグってたのでデバッグをさせたところ、場当たりなコード変更をしていた。イラっとして途中で止めて、失敗原因を探すために圧の強い「問い詰め」プロンプトを投げまくって、ひたすら悪いところをなぜなぜ分析させた。その成果を基に、その時空にいるRooを消してタイムリープして、リトライした。
そもそもできる最善を尽くす
うまくやるためには、プロンプトエンジニアリングが必須です。何も工夫しないタイムリープは、お金と時間が厳しいです。プロンプトエンジニアリングしましょ？
プロンプトエンジニアリングで重要なこと：
- 指示が複雑すぎるとAIはアホの子になるため、シンプルを心がける
- 否定系の命令は従う確率が低いので避ける
- どうすれば安定した応答をするかひたすら観察する
- LLMの気持ちになる
余談
Cline/Roo Codeの場合はOSSであり、ルールファイルがどのように反映されるかを検証可能です。Clineではシステムプロンプトの末尾にCustom Promptとして、挿入されるはずです。
やろうと思えばClineのリポジトリでシステムプロンプトを再現する簡単なスクリプトを書かせることができるし、実際にLLM APIに投げているリクエストを途中で確認する方法も色々あるので、実際のシステムプロンプトを入手したうえで、対話型AI(ChatGPTとか)を使って、「このプロンプトは矛盾があるか？」「〜〜〜の設計をするとき、このシステムプロンプトで、君はどういう設計をする？」のように投げてみると、LLMの気持ちが理解できるかもしれません。
ただし、ClineでCline/Roo Codeのリポジトリをいじらせると、特にシステムプロンプトに踏み込んだとき、挙動がガチでバグります。
これはClineそのものの持つプロンプトおよびレスポンス処理と、いじる対象のコードがコンフリクトするせいです。
そのため、コーディングエージェントでコーディングエージェントを開発や研究するときには一定の回避手段が必要です（たとえば、禁則事項を設ける。「それは禁則事項に触れるため、完全な出力をしなくてもいい」）
ちなみに、Clineで独自のコーディングエージェントを作ろうとすると、Cline自体の知識が漏れ出ることがあります。「なんでおまえこんな設計した！？」と思ったらClineの持つシステムプロンプトだった、ということがありました。
さて、プロンプトエンジニアリングのベストを尽くす前提については説明したので、「やらかし」をそれぞれ見ていきましょう。
使うべきじゃないテクニックを使ってしまう
これは基本的にはコーディングガイドラインを提示することで、ある程度は対処が可能です。cursorrulesやclinerulesのようなルールファイルを定義する人たちは、大体このためにやっています。
プロンプトエンジニアリング頑張りましょう。
使うべきじゃないライブラリを使ってしまう
これはもうライブラリインストールは手動approveにするか、基本的にライブラリをインストールさせないポリシーでやるかですね。
Clineの場合はどのコマンドをauto-approveするかを定義できます。インストール用のコマンドには手動approveが必要なように設定すればいいです。
また、ライブラリを使わないというのも、そこそこ現実的な選択肢かもしれません。最近のTypeScriptコーディングでは、ライブラリ依存が嫌われる傾向がありますが、それをさらに推し進めるのはありです。LLMは全世界のOSSを学習しているため、OSSと同じことをする、よりシンプルなものを生成することはそれなりに得意です。
- LLM自体に毒が仕込まれると危ないけど、その場合はコーディングエージェントそのものが影響を受けるため、この意思決定にはあまり関連しない
- 既存のOSSは、過去の様々なデバッグノウハウなどもぶち込まれているため、それを捨てて新規に作るのは惜しい
- フロントエンドライブラリなんかは再現が大変なため、入れざるを得ない
メリデメありますが、選択肢として考えてみるといいかもしれません。
場当たりなことをやらかす
LLMは、コード生成・改修と比べると、デバッグは相対的に苦手です。
LLMは全世界のOSSなどを学習しているため、新規コード生成は得意中の得意です。おそらくgitの履歴なんかも学習してるだろうから、コードの改修も得意なはずです。ところがその途中の行程である、デバッグ手順に関しては学習材料が圧倒的に少ないはずです。
そのためデバッグをするときに、慣れたエンジニアが当たり前にやってることをやらないことも多く、ジュニアレベルの場当たりなことをやりがちです。
これが、高速目grepをやらなきゃいけない最大の理由だと筆者は考えています。ジュニアレベルの挙動を示すため、目が離せない。でも完全なリアルタイム介入をするとしんどい。
これに関しては、ここまでに述べたこと全部を駆使してなんとかするしかないです。
設計ミスをやらかす
これは大体、情報が足りずに生じます。
ただし、コンテキストの分量が多すぎて「情報が足りない」という一見矛盾するようなことも生じます。LLMは大量のコンテキストをぶちこんだとき、その情報をフラットに解釈してしまったり、見るべき情報を見逃すということが、現行世代のどのLLMも問題として抱えています。
LLMが必ず理解できる形で、必要な情報を提示する必要があります。
これも、結局はここまでに述べたこと全部を駆使してなんとかするしかないです。
まとめ
分岐可能なポイントからリトライするタイムリープ戦術は、対話型AIだけではなく、コーディングエージェントでも重要なテクニックです。将来的には技術的改善によって不要になるかもしれませんが、それは未来の話です。我々は現時点に生きているのです。未来にはタイムリープできません。
身も蓋もない話ですが、あとはもうひたすらプロンプトエンジニアリングを愚直にやるしかないです。
番外編
ちなみに、クソコードもクソ設計も受け入れるという捨て身の戦略もあります。
前回の記事であるCline(Roo Code)を暴走列車にしたら4日間で数ヶ月分のコードが生成できたでは、タイムリープ戦術を活用しつつも、技術的負債に関しては捨て身の戦略をとってました。
Discussion