AIエージェントのエラーの蓄積：ステップ正答率95%がなぜ不十分なのか
AIエージェントのエラー蓄積（compounding error）とは、長い課題が成功する確率が、各ステップの成功確率の積になる現象です。1ステップの正答率が95%なら、10ステップの連鎖は約60%、20ステップでは約36%しか成功しません。ハーネスは各ステップを検証し、確認済みの状態を保存して、エラーが次のステップへ引き継がれないようにします。
エラーの蓄積とは何か
エージェントは課題を一つの操作で解くのではなく、連鎖で解きます。ファイルを読み、関数を変更し、テストを実行し、インポートを直す、という具合です。各ステップが確率 p で正しく、ステップ同士が独立していて、一つの誤りがそれ以降をすべて壊すとすると、n ステップの連鎖全体が成功する確率は p の n 乗になります。これがAIエージェントのエラー蓄積で、英語では compounding error と呼ばれます。
直感は誤りやすいです。1ステップ95%は信頼できる数字に聞こえます。しかし、乗数はすぐに余裕を食いつぶします。
| ステップ数 | p = 0.95 | p = 0.99 |
|---|---|---|
| 1 | 95% | 99% |
| 10 | 約 60% | 約 90% |
| 20 | 約 36% | 約 82% |
| 50 | 約 8% | 約 61% |
このモデルは大まかなものです。実際にはステップは完全に独立しておらず、誤りの一部は無害です。それでも方向性は正しく捉えています。検証を挟まずに自律的に走らせる時間が長いほど、結果が正しい可能性は下がります。
長い連鎖が崩れる理由
序盤の誤りはそのまま残りません。エージェントは誤った土台の上に次の変更を積み重ね、何かが目に見えて壊れる頃には、バグの上に何層ものコードが乗っています。特に悪いのは、エージェントが自分で結果を評価するケースです。その判断は「すべて順調」の方向に偏るため、半ば動かないコードに対して「完了、テストは緑です」という報告が上がってくることがあります。
ハーネスはこれにどう対処するか
p を上げることには限界があります。モデルがミスをしなくなるわけではありません。主要なレバーは、誤りを次のステップに渡さないことです。ハーネスはフィードバックループを閉じます。
- 各ステップ後のセンサー。 一つの検証コマンド（例：テストとリンターを含む
make verify）が、エージェントの自己評価ではなく結果を客観的に測ります。 - 復元ポイント。 検証を通過したステップはコミットして固定します。以降の連鎖は検証済みの状態から始まり、エラーのカウンタは事実上リセットされます。
- 最小限の修正。 検証が赤いとき、エージェントは全体を書き直すのではなく、具体的な原因だけを直します。これで振れ幅が抑えられます。
- 短い課題。 一度に一つの課題、小さなステップ、頻繁な検証です。20ステップを盲目的に進める代わりに、1ステップの連鎖を20本回すことになります。
Claude Code では、検証を人の意思ではなくモデルの自発性に頼らずに実行されるよう、フックに組み込むことができます。
まとめ
AIエージェントのエラー蓄積は単純な計算です。0.95 の10乗は約0.60、20乗は約0.36です。解決策は「より賢いモデル」ではなく、ハーネスにあります。すなわち各ステップの検証、検証済み状態のコミット、そして短い課題です。この連鎖の仕組みとその背後にある法則は、講座のレクチャーで詳しく扱っています。
よくある質問
50ステップの課題はエージェントには無理だということですか？
途中で検証を挟まなければ、確かに成功の見込みは小さくなります。ステップごとに検証とコミットを行えば、課題は短い連鎖の列になり、全体の成功率は各ステップの積では決まらなくなります。
より強力なモデルを使えば解決しますか？
効果はあります。正答率を95%から99%に上げると、20ステップの成功率は36%から82%に上がります。ただし99%でも50ステップでは約61%なので、検証は依然として必要です。
エージェントが誤っていても結果に自信を持つのはなぜですか？
外部のセンサーがなければ、エージェントは結果を現実ではなく自分の予想と比べるからです。コードが正しいかどうかに関係なく、自信は高まります。
エージェントに自分で検証するよう頼むだけではだめですか？
プロンプトで頼んでも実行は保証されません。検証は仕組みとして組み込むほうが確実です。独立したコマンド、フック、またはCIでの検査がそれにあたります。