# コーディングエージェント時代のソフトウェア検証

- 番組: [Software Engineering Daily](https://ai-curator.jp/podcasts/shows/cmv3z5c1c000w5o10bjjhgahi)（Software Engineering Daily）
- 元のタイトル: Software Verification in the Age of Coding Agents
- 配信日: 2026年10月15日
- 長さ: 47分
- 要約作成日: 2026年10月15日
- トピック: [#決定論的シミュレーションテスト](https://ai-curator.jp/topics/%E6%B1%BA%E5%AE%9A%E8%AB%96%E7%9A%84%E3%82%B7%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%86%E3%82%B9%E3%83%88) [#ファジング](https://ai-curator.jp/topics/%E3%83%95%E3%82%A1%E3%82%B8%E3%83%B3%E3%82%B0) [#分散システム](https://ai-curator.jp/topics/%E5%88%86%E6%95%A3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0) [#AIコーディングエージェント](https://ai-curator.jp/topics/AI%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#ソフトウェア検証](https://ai-curator.jp/topics/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E6%A4%9C%E8%A8%BC) [#カオスエンジニアリング](https://ai-curator.jp/topics/%E3%82%AB%E3%82%AA%E3%82%B9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0)
- URL: https://ai-curator.jp/podcasts/cmv9bqhyh00004b0zfexewk9t

## 要約

Antithesis の Red Team に所属し AI 戦略も率いる Carl Sverre が、決定論的シミュレーションテスト（DST）の仕組みと意義を Sean Falconer と語った。テストが既知の挙動の回帰確認に偏りがちで、未知の未知を捉えにくいという課題から出発し、ファジングを応用した探索、SQLite の10年来のバグを15分で再現した事例、AI 生成コード時代に仕様と検証が重要になるという見方までを扱っている。

## ポイント

- 多くのテストは既知の機能を固定する回帰テストであり、未知の未知を探すテストは書きにくいため、信頼性ツールへの投資が不足してきたと Carl は述べている。
- DST の要素は「決定論」と「シミュレーション」で、同じ事象列を再現でき、任意の時点でタイムラインを分岐させて状態空間を幅優先で探索できる。
- Antithesis は Linux ソフトを自動で決定論化し、カバレッジ誘導型ファジングで新しい挙動を探る。SQLite の WAL リセットバグは汎用ワークロードでも約15分で見つかったという。
- 厳密にシリアライズされたログ、プロパティ、マルチバース・デバッグ、因果分析で原因究明を支援する。
- Antithesis は反例を探すため、TDD のようにテストへ過剰適合しにくく、AI に汎用的で正しい実装を促せると主張している。
- AI がコードを大量生成する時代には、エンジニアの役割は精密な仕様と、それに紐づく検証の網の構築へ移るという見方を示した。

## 章立て

- [01:04] **Red Team の役割と立ち位置** — Carl が所属する Red Team は分散システムの専門家集団で、顧客支援で得た知見を製品に還元する。FDE への知見共有や AI スキルリポジトリ作成も担う。
- [06:14] **なぜテストは過小投資されてきたか** — テストの多くが回帰確認に偏り、未知の未知を扱いにくいこと、状態を持つ分散システムでは組み合わせが爆発することを説明する。
- [07:33] **カオスエンジニアリングとモックの考え方** — Netflix の事例に触れ、モックは本番より悪い挙動を含む上位集合にすべきだと述べる。LLM 組み込みで状態空間が広がる点も議論する。
- [16:38] **DST の仕組み** — 決定論とシミュレーションという二要素、乱数制御とタイムライン分岐、カバレッジ誘導型ファジングによる探索を解説する。
- [25:01] **SQLite の WAL バグ事例とデバッグ機能** — 10年存在した並行性バグを約15分で検出した例と、ログ、プロパティ、マルチバースデバッグ、因果分析を紹介する。
- [31:20] **静的検証・形式手法との関係** — Hydro のような型システムによる検証や形式手法とは対立せず補完関係にあり、DST は統合・ストレステスト寄りだと整理する。
- [37:10] **AI時代の開発サイクルと検証** — Antithesis 駆動開発、実行時間の設計、エージェントによる実行中の通知購読、仕様と検証の重要性を語る。
- [44:57] **コードの拡散的生成という展望** — 仕様を変えてコードベース全体を再生成する未来像を提示し、検証がその鍵になると述べて締める。

## 解説記事

Software Engineering Daily の本エピソードでは、ソフトウェア検証企業 Antithesis の Red Team に所属し、同社の AI 戦略も率いる Carl Sverre が、ホストの Sean Falconer と対話した。テーマは決定論的シミュレーションテスト（DST）の仕組みと、AI がコードを大量に書く時代の検証のあり方である。

#### テストが過小投資されてきた理由

Carl は前職の SingleStore（旧 MemSQL）で10年間データベース開発に携わり、開発者が自分でテストを書く文化を経験した。その経験から、テストの多くは「機能Xを実装したので、その挙動を受け入れ可能として固定する」回帰テストになりがちだと指摘する。未知の未知を探すテストは本来最も面白いが、書くのが難しいため、優秀なエンジニアが集まりにくいという見方である。

難しさの核心は状態を持つシステムにある。純粋なコードなら入力と出力の対応を確認する単体テストで足りるが、実際のソフトは過去の入力履歴に依存し、障害も絡む。Aが起き、次にBとCという悪い事象が起きる、といった時系列を統合テストで手書きするのは既知のケースに限られ、未知のケースを網羅しようとすると組み合わせ爆発になる。

#### DST の二つの要素

Carl は DST を「決定論」と「シミュレーション」で説明する。決定論とは、ソフトウェアが同じ事象列を毎回見て、再生できることだ。Antithesis は Linux 上で動くソフトを、Docker コンテナ群ごと自動で決定論化する。時刻、乱数、イベント順序といった非決定性は、プラットフォームが注入し制御する。自前で DST を作る場合は、非決定的な読み取りとスケジューリングを自分で制御できるよう書き直す必要がある。

シミュレーションとは、決定論的な履歴の任意の時点でタイムラインを分岐させ、別の乱数や事象順序で探索することだ。乱数を毎回システムに問い合わせる形にすれば、より細かい粒度で分岐できるため、擬似乱数生成器を使わず直接システム乱数を読むことが推奨されるという。3ノード構成で1ノードが落ちた後、リーダー選出の最中に復帰したらどうなるか、といった状況を多数の分岐で試せる。

探索にはファジングの手法であるカバレッジ誘導型を応用する。通過した分岐を監視して新しい挙動を見つけ、挙動が増える領域に探索の力を集中する。これにより、ロック取得順などに起因するスレッド競合バグを見つけやすいと Carl は述べる。

#### SQLite の10年来のバグを15分で

具体例として挙げられたのが、SQLite の WAL（先行書き込みログ）に関するバグだ。10年存在し、非常に狭いタイミングでしか起きず、大口ユーザーの Tailscale しか遭遇しなかったという。Carl は修正前の版を Antithesis に入れ、挿入とチェックポイントを繰り返す単純なワークロードと、データベース破損を確認する integrity check をプロパティとして与えた。約15分でファザーが正確な操作順序まで絞り込んだと語る。バグの存在を知った上で作ったワークロードではあるが、その後に全操作を均等確率で実行する汎用ワークロードでも、同じ時間で見つかったと説明している。

発見後の調査には、事象順が厳密に直列化されたログ、SSH で任意時点に入って時間を遡れるマルチバース・デバッグ、バグが確定した地点を自動で二分探索する因果分析が使える。単なる可観測性基盤とは違う点だとされる。

#### 他の手法との関係と AI 時代の開発

型システムでバグを防ぐ AWS の Hydro のような静的検証について、Carl は自分は詳しくないと断った上で、対立ではなく補完関係だと述べた。ただし、そうした手法は特定の書き方を強いるため新規開発向きで、自作 DST も開発負荷が高いという。DST は統合テストとストレステストに近い位置づけで、単体テストなど他の手法とも併用すべきだとする。また、プロセス内のスレッドでも実質的には分散システムだと指摘した。

AI との関係では、TDD ではエージェントが特定のテストに過剰適合しがちだが、Antithesis は反例を探すため、「データベースは決して壊れない」といった一般的な性質を満たす実装を促せると主張する。実行時間については、PR では15分程度の短い実行、メインブランチでは12時間といった長時間実行を段階的に重ねる運用を紹介した。デフォルトで48並列、sleep の早送りで48倍以上の高速化になり、ジョブシステムのようなコードでは千倍に及ぶこともあるという。エージェントが実行中の特定プロパティの失敗を購読し、完了を待たずにデバッグを始める機能も検討されている。

#### まとめ

コード生成のコストが下がるほど、仕様の精密さと、それに結びついた検証の網が重要になる、というのが Carl の見方だ。将来は仕様を変えてコードベース全体を再生成する「拡散」的な開発もあり得るとし、その検証側を担う技術として DST を位置づけている。なお、本エピソードは Antithesis がスポンサーであり、語られる効果は同社関係者の主張である点には留意したい。日本の開発者にとっては、分散システムや並行処理のバグ対策に加え、AI 生成コードを性質ベースで検証する発想を考えるきっかけになる。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Software Engineering Daily「Software Verification in the Age of Coding Agents」