6月28日、UndoのCTOであるMark Williamsonが「Undo CTO: How to unlock the potential of AI coding agents by giving them runtime context」と題した記事をComputer Weeklyのデベロッパーブログに寄稿した。AIコーディングエージェントがソースコードだけを参照する限り「それらしい答え」を返すにすぎず、実行時の記録（ランタイムコンテキスト）を与えることで初めてバグの根本原因特定に近づけるという主張を展開している。なお本記事はWilliamsonが自社製品の技術的立場から執筆したベンダー寄稿である点は留意が必要だ。
AIが書いたコードは「それらしく見えるだけ」かもしれない
Cursor、Codex、Claude Codeといったツールの台頭により、コードを生成するスピードは飛躍的に上がった。だが、Williamsonはここに核心的な問題を見る。
「コードを書くこと自体がボトルネックだったわけではない。開発者の時間の大半は、コードを"理解する"ことに費やされている。自分が書いたコードであれ、他の誰か（あるいは何か）が作ったものであれ、コードが何をしているのかを把握し、意図通りに動いていない箇所を特定し、予期しない結果の原因をデバッグする作業に膨大な労力がかかる」
AIがより多くのコードをより速く生成できるようになっても、この「理解とデバッグ」にかかる総コストは下がらなかった。むしろ増えた。
その根本的な理由が、AIコーディングエージェントが本質的に「それらしさエンジン（plausibility engine）」であるという点だ。完全な情報がない状態で、次に来そうなものを推測しながら補完する。その結果、テストスイートは通過するが、特定の条件下で本番環境が落ちるコードが生まれやすい。ソースコードだけを見て、あらゆるシナリオを網羅することは人間にも不可能であり、AIはなおさらだ。
デバッグが長引く本当の理由
テストが失敗したとき、あるいはP1インシデント（本番環境における最高優先度の障害。サービス全停止や重大なデータ損失を引き起こすレベルの障害を指す）が発生したとき、エンジニアは通常、ログとソースコードを頼りに何が起きたかを追う。だがこれは実行時の部分的な情報にすぎない。
ランタイムコンテキストとは、プログラムが実際に動作している間の変数の状態、関数の呼び出し順序、メモリの内容、スレッドの挙動といった動的な情報の総体を指す。ログには残らない一時的な状態や、特定のタイミングでしか発生しない競合状態（レースコンディション）などは、ソースコードを静的に読むだけでは再現も推測も難しい。
再現不可能なバグ——100万分の1の条件が重なって初めて顕在化するもの——は、そもそもログには残らない。原因の特定には数週間、場合によっては数ヶ月を要することもある。そのあいだ、チームは「取り残されたチケット」を積み上げ続ける。Williamsonはこう表現している。
「未解決のバグはすべて、顧客エスカレーションの予備軍だ。それは決まって最悪のタイミング——ユーザーからの需要が異例に高い瞬間や、アップデートが失敗した深夜——にやってくる」
この問題の構造は、AIの登場によって質的には変わっていない。AIがコードを大量生成することで、理解・検証・デバッグの対象となるコードの総量が増え、問題がむしろ拡大しうる点をWilliamsonは強調している。
解決策：実行の完全な記録をAIに渡す
Williamsonが提示する解決策はシンプルだ。プログラムが実行時に行ったすべての操作を完全に記録し、その記録をAIエージェントに与える。
これにより、AIエージェントはソースコードを眺めて推測するのではなく、実際に何が起きたかという証拠に基づいて根本原因を特定できるようになる。ハルシネーションや推測に頼る必要がなくなるというのが主張の核心だ。
Williamsonが所属するUndoはTime Travel Debuggingソフトウェアで知られており、プログラムの実行を記録して「巻き戻し・再生」できる技術を提供している。Time Travel Debugging（またはRecord and Replay）とは、プログラムの実行ステップをすべてキャプチャし、後から任意の時点の状態に遡って検査できるデバッグ手法の総称だ。Mozilla FirefoxのrrやMicrosoftのTime Travel Debugging for Windowsといった実装が知られている。本記事はその技術的文脈の上に立った主張であり、Undoの製品訴求と切り離せない議論である点は念頭に置いておきたい。
何が変わるか
実行コンテキストを持ったAIエージェントが実現することとして、Williamsonは主に以下の2点を挙げている。
- 根本原因の自動特定：障害が発生した瞬間の実行状態を正確にピンポイントし、なぜその状態に至ったかをトレースできる。ソースコードを静的に眺めた推測ではなく、実際の実行証拠に基づく解析が可能になる
- 長期放置チケットの解消：再現困難で手を付けられなかったバグも、実行記録が存在すれば対処の糸口が生まれる。「100万分の1の条件でしか出ないバグ」も、一度記録さえされれば繰り返し検査できる
ただし、この主張が成立するには「問題の実行を事前に記録できている」という前提が必要であり、記録のオーバーヘッドや本番環境への適用可否は実装上の現実的な課題として残る。また「自動特定」の精度がどの程度かは元記事では具体的に示されておらず、提案段階の議論として受け取るのが適切だろう。
ソースコードだけを渡してAIに「バグを探せ」と指示するアプローチの限界は、AIが「それらしい答え」を返すにすぎない点にある。Williamsonの主張の骨格は、ランタイムの実証データを与えることで、AIを推測ベースの補完から証拠ベースの解析へと移行させられる可能性がある、という点に集約される。
詳細はUndo CTO: How to unlock the potential of AI coding agents by giving them runtime contextを参照していただきたい。
