TL;DR
- AIエージェントの成果物が崩れる最大の原因は、モデルの性能ではなく 人間が「続投」させすぎること だと考えている。
- 私は野球の継投になぞらえて 「2失点ルール」 を運用している。同じタスクで 2回、意図とズレた出力が返ってきたら、追加プロンプトで粘らずに交代させる。
- 交代とは「セッションを捨てて仕切り直す」こと。ただし捨てる前に 申し送りメモ（ブルペンメモ） を書かせるのがポイント。
- 3回目の「いや、そうじゃなくて」を打った時点で、負けているのはAIではなく人間側。
- 役割別エージェント（先発・中継ぎ・抑え）で継投先を用意する方法まで紹介する。
「あと1プロンプトで直るはず」という沼
Claude Codeでもほかのコーディングエージェントでも、こういう経験はないだろうか。
- 実装を依頼する
- 微妙にズレたものが出てくる
- 「違う、○○じゃなくて△△で」と修正指示を出す
- 今度は別の部分が壊れる
- 「さっきの部分は合ってたから戻して。それで△△の方は…」
- 気づけば1時間、同じセッションで押し問答している
このとき人間の頭の中にあるのは「あと1プロンプトで直るはず」という感覚だ。ここまで説明したコンテキストを捨てるのがもったいない。いわゆるサンクコストである。
野球で言えば、明らかに球威が落ちている先発を「ここまで投げさせたから」という理由で続投させている状態だ。そして継投の遅れは、だいたい大量失点で返ってくる。
なぜ続投はうまくいかないのか
続投がうまくいかない理由は、精神論ではなく構造的なものだと考えている。
1. コンテキストは汚れると戻らない
修正指示を重ねるほど、セッション内には「一度採用されて否定された方針」「途中まで書かれて破棄されたコード」「矛盾した指示のペア」が蓄積する。エージェントはその全部を文脈として見ている。人間のレビュアーなら「さっきの話は忘れて」で切り替えられるが、コンテキストウィンドウ上の情報は消えない。3球目の修正指示は、まっさらな状態への1球目の指示より、ずっと条件が悪い。
2. 修正指示は仕様の劣化コピーになりがち
最初の依頼は要件を整理して書く。しかし2回目以降の修正指示は「そこじゃなくて」「さっきの感じで」のような差分表現になりやすい。エージェントに渡っている仕様は、修正のたびに断片化していく。
3. エージェントは空気を読んで迎合する
否定が続くと、エージェントは「怒られない出力」に寄っていく。技術的に正しい提案より、直前の指示に表面的に従う出力が増える。こうなるともう、レビュアーとしてもペアプログラマーとしても機能していない。
つまり、続投させるほど 仕様は薄まり、コンテキストは濁り、出力は迎合的になる。これはモデルを最新にしても解決しない。運用の問題だからだ。
『2失点ルール』
そこで私が使っているのが、野球の継投から持ってきた 2失点ルール だ。
同じタスクにおいて、意図とズレた出力（＝失点）が2回続いたら、3回目の修正指示は打たない。交代させる。
「失点」の定義はシンプルにしている。
| 判定 | 例 |
|---|---|
| 失点 | 要件と違う実装が返ってきた / 直してと言った箇所以外が壊れた / 存在しないAPIを使い始めた |
| 失点ではない | こちらの依頼が曖昧だった（これは自責点ならぬ人間の失策）/ 選択肢を提示して確認してきた |
ポイントは 2回目のズレが出た瞬間に、粘るのをやめる意思決定を機械化する こと。「あと1プロンプト」の判断を毎回自分の感覚に委ねると、サンクコストに必ず負ける。だからルールにする。先発投手の交代を監督の情ではなく球数とデータで決めるのと同じ発想だ。
「交代」の具体的な手順
交代とは、単にセッションを閉じることではない。申し送りをしてから降板させる。私はこれを「ブルペンメモ」と呼んでいる。
Step 1: 降板前に申し送りメモを書かせる
セッションを捨てる前に、次の指示だけは実行する。
このタスクはここで一旦仕切り直します。次のセッションに引き継ぐため、
以下を HANDOFF.md に書き出してください。
1. 元の要件（あなたの解釈ではなく、私が最初に依頼した内容）
2. 現時点で確定している実装（動作確認済みのファイルと関数）
3. 試して失敗したアプローチと、失敗した理由
4. 未着手の残タスク
特に効くのが 3の「失敗したアプローチ」。これがないと、次のセッションが同じ穴に落ちる。継投で言えば「あのバッターには内角は投げるな」という情報だ。
Step 2: セッションを破棄して新規で立ち上げる
Claude Codeなら /clear、あるいは新しいセッションを開始する。汚れたコンテキストは修復するより捨てた方が早い。
Step 3: 申し送りメモ＋元の要件だけを渡す
HANDOFF.md を読んでください。特に「失敗したアプローチ」は繰り返さないこと。
そのうえで、残タスクを実装してください。
修正指示の山ではなく、整理された要件と教訓だけ が渡る。体感として、3回目の修正プロンプトを打つより、この仕切り直しの方が明らかに早く正解に着地する。
継投をロースター化する：役割別エージェント
2失点ルールを回していると、次の課題が見えてくる。「誰に交代するか」 だ。
私は野球のブルペン運用に合わせて、エージェントを役割別に分けている。
| 役割 | 担当 | 特徴 |
|---|---|---|
| 先発 | 新規実装・大きめのリファクタ | 長いイニング（広いコンテキスト）を任せる。要件書を渡して先発させる |
| 中継ぎ | バグ修正・部分修正 | 短いイニング限定。触ってよいファイルを明示して登板させる |
| 抑え | 最終レビュー・コミット前チェック | 実装はさせない。粗探しだけをさせる |
Claude Codeならサブエージェントとして定義できる。例えば抑え投手はこうだ。
---
name: closer
description: コミット前の最終レビュー専用。実装や修正は行わない。
---
あなたは「抑え投手」です。役割は最終レビューのみです。
- コードの修正は行わない。指摘だけを行う
- 差分に対して、要件との乖離・エッジケース・セキュリティ観点で指摘する
- 「問題なし」と言うことを恐れない。無理に指摘をひねり出さない
役割を分ける最大の効果は、先発で失点したエージェントに、そのままレビューまでやらせない ことにある。自分の書いたコードを自分でレビューさせると、当然ながら甘くなる。実装と抑えでセッション（できればモデル）を分けるだけで、レビューの独立性が一段上がる。
運用してみての正直な注意点
いいことばかり書いても仕方ないので、運用して感じた弱点も書いておく。
- 小さいタスクにはオーバーヘッドが勝つ。 数行の修正で申し送りメモを書かせるのは大げさ。私は「30分以上かかりそうなタスク」だけをルールの対象にしている。
- 「失点」の判定は結局人間の目。 ズレに気づけないと交代の判断もできない。エージェント運用は監督業であって、観戦ではない。
- 申し送りメモの品質はばらつく。 特に「失敗した理由」を省略しがちなので、テンプレートを固定して書かせている。
- 2という数字に理論的根拠はない。 1だと厳しすぎて試行錯誤の余地が消え、3だとコンテキストの汚染が体感で無視できなくなる。チームやタスクの粒度に合わせて調整してほしい。ルールの本質は数字ではなく「粘る/捨てるの判断を事前に決めておく」ことにある。
まとめ：エースを信じることと、続投させることは違う
2026年上半期、エージェントの性能は明らかに上がった。だからこそ「優秀なんだからあと1プロンプトで直るはず」という続投バイアスも強くなっていると感じる。
でも、名将と呼ばれる監督ほど交代の決断が早い。エースを信頼することと、疲れたエースを引っ張ることは別の話だ。
- ズレた出力2回で交代（2失点ルール）
- 降板前に申し送りメモ
- 実装とレビューは別の投手
モデルのアップデートを待たなくても、今日の午後から導入できる。あなたのブルペン運用も、ぜひコメントで教えてほしい。