【ITニュース解説】Coding got 10× faster. Validation didn’t. Who’s using production-trace replays to close the gap?

近年、AIアシスタントやコード自動生成ツールの進化により、ソフトウェアのコードを書くスピードが飛躍的に向上した。まるで開発者が10倍の速さでコードを生み出せるようになったかのようだ。しかし、コードを書く速度が上がったからといって、ソフトウェアをリリースする頻度が同じように速くなったわけではない。なぜなら、開発のボトルネック（作業の流れを停滞させる要因）が、コードを書くこと自体から、そのコードが意図した通りに動作するかを「検証する」ことに移ってしまったからだ。

これまで、コードが正しく動くかを確認する古典的な方法は「もっとテストを書く」ことだった。しかし、この方法は次第に限界を迎えてきた。テストを増やすことは、テストに必要な環境（フィクスチャ）や、外部システムとの連携を模倣する仕組み（モック）を大量に用意する必要があることを意味した。また、テスト実行のためのインフラ（基盤）も複雑になり、テスト自体が不安定になる「flakiness（フレークネス）」という問題も発生しやすくなった。テストが不安定だと、コードには問題がないのにテストだけが失敗したり、逆に問題があるのにテストがたまにしか失敗しなかったりするため、開発者はテスト結果を信頼できなくなり、検証作業の効率はかえって低下してしまう。さらに悪いことに、これほど多くのテストを書いても、システム間の連携で発生する「契約違反」、つまり、あるシステムが別のシステムに期待するデータの形式や振る舞いが、いつの間にか変わってしまい、意図しない不具合が起きる、といった種類の問題を見逃してしまうこともあった。

このような状況を打開するため、ある開発チームが試しているのが「プロダクション駆動型」と呼ばれる新しいアプローチだ。これは、本番環境で実際に発生するユーザーとシステムのやり取りを基に、検証を行うという考え方である。

具体的には、まず本番環境で実際に動いているシステムが、外部から受け取るデータ（HTTPリクエストの入力）や、外部に送信するデータ（HTTPレスポンスの出力）、データベースへの問い合わせ、メッセージキューを通じた通信といった、あらゆるやり取りを記録する。この際、ユーザーの個人情報（PII: Personally Identifiable Information）が含まれる可能性のあるデータは、厳格に匿名化処理される。これはプライバシー保護と法規制遵守のために非常に重要なステップだ。

次に、取得した膨大な記録の中から、システムの最も重要な機能や、ビジネスにとって価値の高いフローをカバーするような、少数の「ゴールデンパス」と呼ばれる一連の操作記録（トレース）を選び出す。これは、システムの健全性を判断するための「模範的な振る舞い」を示すデータの集合体となる。

そして、開発中の新しいバージョンのシステムに対して、これらのゴールデンパスのトレースを、継続的インテグレーション（CI）環境で「リプレイ」する。CIとは、開発者がコード変更を頻繁に共有リポジトリに統合し、自動的にテストを行うことで、問題を早期に発見する開発手法のこと。リプレイとは、本番環境で実際に発生した入力データを、開発中のシステムに与え、そのシステムの振る舞いを再現させることだ。リプレイ後、開発中のシステムが生成した出力と、ゴールデンパスのトレースが示す本来の出力を比較する。この比較では、システムの内部的な動作ではなく、ステータスコード（通信が成功したか失敗したかを示す番号）、ペイロードの形式（データの構造）、主要なフィールドの値、処理にかかる時間の範囲（タイミングエンベロープ）など、外部から観察可能な振る舞いのみに注目する。これにより、システムが外部との「契約」を守っているかを確認できる。

このリプレイテストを効果的に行うためには、リプレイの過程が常に同じ結果になる「決定論的」である必要がある。そのため、リプレイ中はシステム内の時間や、自動生成されるID、ランダムな値の生成などを固定化し、外部との連携など、結果が不確定になりがちな要素（非決定性）については、あらかじめ決められた値を返すように「スタブ化」（一時的な代替処理）する。また、製品が進化するにつれてゴールデンパスも変化する必要があるため、カナリアリリース（一部のユーザーに新機能を先行リリースしてテストする手法）やフィーチャーフラグ（機能のオン/オフを切り替える仕組み）を活用して、ゴールデンセットを継続的に更新し、常に製品の最新の振る舞いを反映させる。

このプロダクション駆動型アプローチには、いくつかの大きな利点がある。一つは、単体テストや結合テストだけでは見逃されがちな、APIの変更やシステム間の「契約」の変更による潜在的な不具合を効果的に検出できることだ。実際に本番で使われるデータに基づいているため、より現実的なシナリオでの検証が可能となる。また、モックを多用するテストに比べて不安定さ（フレークネス）が少なく、テスト結果の信頼性が向上する。さらに、重要な機能パスについては、新しいコードがリリース可能かどうかを「Go/No-Go」（リリース可否）として、より迅速に判断できるようになる。

しかし、このアプローチにもまだ課題は残されている。例えば、新しく開発された機能は、実際にユーザーに使われるまでは本番環境での記録が存在しないため、ゴールデンセットに含めることができない。そのため、新機能がリリースされるまでの初期段階では、他の検証手段が必要となる。また、複数のステップを経て状態が変化するような複雑なフロー（例：ECサイトでの購入プロセス全体）を正確に記録し、リプレイすることは、データの整合性を保ちながら慎重に設計する必要があり、難しい作業だ。ゴールデンセットは時間とともに陳腐化するため、常に最新の状態を保つための継続的な管理（キュレーション）が不可欠である。そして、何よりも重要なのは、個人情報保護や法規制遵守に関するエンジニアリングが必須であり、これを怠ることはできない。

このような課題を解決するため、このアプローチを試したことのある開発者たちは、互いに知恵を出し合っている。例えば、どのような基準でトレースを選択するのか（最もアクセスが多いエンドポイント、エラーが発生しやすいフロー、売上に直結するパス、統計的なサンプリングなど）。ストレージ容量を抑えながらゴールデンセットを新鮮に保つためのヒントは何か。比較の厳密さはどの程度にするのか（振る舞いの差分を見るか、バイト単位で完全に一致するか）。そして、記録やリプレイ、個人情報匿名化の処理において、どのようなオープンソースツールや自社開発ツールが役立ったか、といった情報交換が行われている。

このように、ソフトウェア開発の現場では、AIの進化によって生まれた新たなボトルネックを解消するため、従来のテスト手法の限界を乗り越え、本番環境のリアルなデータを活用した新しい検証方法が模索されている。これは、より高品質で信頼性の高いソフトウェアを、より迅速にユーザーに届けるための重要な一歩と言えるだろう。