AI駆動開発の議論は、コーディングの速さとレビューの負荷に集中しがちです。その一方でテストの中身、つまり外部結合テストをどう組むのか、性能をどう測るのか、運用と監視をどう確かめるのか、画面とバッチをどう検証するのかは、従来の工程表に沿ったまま残されています。本コラムで扱うのは、その工程表そのものを置き換える構成です。開発者一人ひとりがAWS上に使い捨てのフルスタック環境をVPC(隔離されたプライベートネットワーク)ごと持ち、AIエージェントがその中でIT(結合テスト)・ST(総合テスト)・外部結合・性能・運用・異常系の検証を常時実行し続ける。テストは決まった期間に実施する工程ではなくなり、テスト計画書は合格基準の定義だけを残して不要になる。この構成を、海外で定着しつつあるEphemeral Environment(エフェメラル環境)の考え方をテスト全体に広げたものとして、Ephemeral Testing(エフェメラルテスティング)と呼ぶことにします。構成部品はすべて実在の技術です。サービス仮想化、合成データによる増幅、カオスエンジニアリング、時刻の加速。単体ではどこかの先進企業がすでに本番で使っていますが、組み合わせて「テスト工程」の代わりに据えた現場はまだほとんどありません。理論上は組めるのに、誰も手を出していない。その領域まで含めて書きます。
定義は四行で書けます。
前提はひとつだけです。Claude等のAIによってIaC(インフラをコードで管理する仕組み)の記述と調整が桁違いに速くなり、環境が「維持し続ける資産」から「必要なときに生成するもの」に変わったこと。本コラムでは、この前提がテストの各論——外部結合、性能、運用、異常系、画面、バッチ——をどう変えるかを順に見ていきます。
シフトレフトという言葉と混同されやすいので、先に区別しておきます。シフトレフトは、テストの実施時期を工程表の前半(左)へ前倒しする考え方で、「テストをいつ実施するか」を管理する工程表そのものは残ります。Ephemeral Testingでは、テストは特定の時期に実施するものではなくなり、開発中は常に実行され続けている状態になります。前倒しするのではなく、実施時期という概念そのものをなくす、という違いです。
テスト計画書が不要になる、と書いたのには根拠があります。テスト計画書の中身を思い出すと、環境の割当、実施期間、体制、実施順序、消化の管理。その大半は、数に限りのある共有テスト環境と限られた期間を、どのチームにいつ割り振るかの調整です。環境がいくらでも作れるようになった時点で、割り振るものがなくなります。残るのは「何をもって合格とするか」の定義だけで、それはテスト計画ではなく要件定義の側の仕事です。合格基準をどの正本——仕様書・テストコード・評価セット——に固定するかという設計は、仕様駆動か、テスト駆動か、評価駆動かに書いた通りです。
本番構成の定義(IaCの正本)は1つ。開発者ごとの環境も本番も、同じコードから生成される。
構成の全体像は上の図の通りで、本番構成の定義(IaCの正本)から、開発者ごとの環境も本番も同じコードで生成されます。環境が増えすぎる問題は自動化で対処します。所有者と有効期限のタグをテンプレートで強制し、期限切れの環境は自動停止を経て自動削除する。人が確認するのは月次のタグなしリソース一覧だけです。
ITとSTがどう変わるかは、「実行」と「判定」に分けて考えると正確に描けます。
なくなるのは、結合の段取りです。従来のITで最も重かったのは、テストケースの実行ではなく段取りでした。どのチームの成果物がいつ揃うか、どこまでをスタブで代替し、いつ実物に置き換えるか。結合順の管理表や置き換え計画が必要だったのは、共有のテスト環境が一つしかなかったからです。全チームのマージ済み成果物が毎朝すべての個人環境に反映される構成では、「今週はどこまで結合するか」という問い自体がなくなります。常にすべてが結合された状態で開発が進みます。疎通確認とリグレッションテストはマージのたびに実行され、業務シナリオは毎晩、受入シナリオ全件をエージェントが実行します。
このときシナリオ消化率という進捗指標は意味を失います。毎晩全件が実行されるからです。意味を持つ数字は「失敗した件数と、その業務への影響度」だけになります。
残るのは、完了判定・検収と、実物との確認と、本番データを扱う作業です。第一に、ST完了判定と検収。実行が毎晩行われていても、「この日をもってSTを完了とし、検収に進む」という区切りは契約上の行為であり、環境のコストがいくら下がってもなくなりません(ウォーターフォールでAI駆動開発を回すに書いた通り、工程の区切りは合意の節目として残ります)。第二に、外部システムの実物との確認。これは次章で扱います。第三に、本番データと本番権限を扱う作業。移行リハーサルと最終切替は、個人環境では代替できない数少ない領域です。
つまりITとSTの区別は、実行の区別としてはなくなり、完了を判定する節目として残ります。テスト報告書の中身も変わります。「期間中に何件消化したか」の記録から、「基準を満たしていることを示す、毎晩更新される実行結果」へ。判定会は、テストを実施する会ではなく、実行結果を確認して完了の判断を下す会になります。
「実行」と「判定」に分けて考える。常時実行に変わるのは前者だけで、後者は節目として残る。
外部結合テスト(外結)ほど、環境が希少だった時代の段取りがそのまま残っている領域はありません。相手会社と日程を合わせ、専用線や閉域網をつなぎ、双方の担当者が待機して、2週間の期間内にテストケースを消化する。期間内に終わらなければ、次の機会は本番直前。この進め方は、接続できる環境が一つしかないことを前提に組まれています。
Ephemeral Testingでは、外部結合テストを二つに分けます。
論理面の確認は、相手システムを模した仮想サービスを相手に毎日行います。IF仕様書と過去の通信ログを渡すと、AIは相手システムの応答を模した仮想サービスを生成できます。サービス仮想化と呼ばれる実在の技術分野で、これまでは仮想サービスを作る工数が割に合わないとされてきただけです。仮想サービスは全開発者の環境に配布され、正常応答だけでなく、遅延、タイムアウト、重複送信、順序の逆転、仕様外のコード値といった異常系の応答も、マージのたびに返してきます。従来の外結期間の貴重な枠では怖くて試せなかった異常系こそ、仮想サービスが相手なら何度でも試せます。
副産物がひとつあります。仮想サービスを生成する過程で、IF仕様書の曖昧な箇所が機械的に洗い出されることです。「このフィールドがnullのときの応答が書かれていない」「このステータスコードの発生条件が不明」。AIが仮想サービスを作り切れなかった箇所のリストは、そのまま相手会社への質問表になります。従来は接続して初めて発覚していた仕様の穴を、接続する前に、文書の段階で潰せます。
物理面の疎通確認は、実物と一度だけ行います。証明書、閉域網、実IFの細かな挙動。実物でしか確認できないものは確かに残ります。ただしそれは2週間がかりの作業ではなく、STG(ステージング)での一度の疎通確認で済みます。実物との確認で見つかった差分は仮想サービスに反映され、再現度が上がっていきます。論理面は毎日仮想サービスと、物理面は一度だけ実物と。この分離によって、相手先と日程を組んで一斉に実施する外結という進め方自体が不要になります。
論理面の確認と物理面の疎通確認を分離する。相手先と日程を合わせるのは、後者の一度の接続だけである。
なぜ誰もやらないのかも書いておきます。スタブは「テスト用の使い捨てコード」として、見積りから最初に削られてきた工数です。生成のコストがほぼゼロになった今も、削る習慣だけが残っています。
性能テストが工程の終盤に追いやられてきた理由は単純で、本番相当の環境とデータが高価だったからです。その両方のコストが変わりました。
データは増幅して用意します。個人環境に日常的に配布されるのはマスキング済みの少量データですが、性能検証にはそれでは足りません。ここでAIに合成データを作らせます。スキーマと参照整合性、そして実データの分布の偏り——特定顧客への取引の集中、月末のスパイク、長大な明細を持つ例外レコード——を保ったまま、1万件を1億件に増幅する。性能問題の多くは平均値ではなく偏りが引き起こすので、「量だけ増やしたテストデータ」と「分布を保って増幅したデータ」の差は、そのまま不具合の検出力の差になります。
負荷は本番から写します。本番のアクセスログとクエリログからリプレイシナリオを再構成すれば、想像で書いた負荷シナリオではなく、実際のトラフィックを再現できます。ピーク日の負荷を、当日の流量パターンごと個人環境で再生する。実データそのものは一方向のマスキングパイプライン経由でしか持ち出さず、写すのは流量とパターンだけです。
環境は夜間だけ大きくします。20時に環境を本番の2倍のスペックへ拡張し、増幅データを投入し、リプレイ負荷をかけ、限界点を測定して、翌朝には最小構成へ戻す。従量課金なら、この「一晩だけ本番超え」は数千円から数万円のオーダーで済みます。性能テスト環境の予約表や、年に数回しか使わないのに維持され続ける負荷試験環境は、この時点で必要なくなります。
統制のルールは一行だけ残します。性能の判定に使ってよいのは、指定構成での実測値だけ。環境の構成はコードで定義されているので、「どの構成で測ったか」は測定値に自動で付いてきます。構成情報のない性能報告が判断の場に出てくること自体が、この構成では起こりません。
従来の運用テストは、リリース前の一週間で手順書の読み合わせと切替リハーサルを行う工程でした。そして監視は、本番障害で初めて本格的に動きます。アラートの閾値は適切か、ランブック(復旧手順書)は実際に使えるか、アラートの文面から原因に辿り着けるか。このどれも、リリース前には検証されていません。検証できる環境がなかったからです。
個人環境がフルスタックであるとは、監視までを含むということです。ダッシュボード、アラート定義、ランブック。運用に必要な一式がIaCの正本に含まれ、すべての個人環境に本番と同じものが構築されます。そこにAIエージェントが毎晩、障害を注入します。AZ障害、プロセス停止、ディスク枯渇、依存先の遅延。カオスエンジニアリングは実在の実務で、AWSにはFault Injection Serviceという専用サービスまであります。使われてこなかったのは技術が足りないからではなく、壊してよい本番相当の環境が存在しなかったからです。
このとき検証されるのは、システムの耐性だけではありません。監視は鳴ったか。ランブックの手順で復旧できたか。アラートの文面は原因に辿り着ける書き方だったか。監視と運用手順そのものがテスト対象になります。「本番障害が、監視にとって最初の実地テスト」という長年の状況が、ここで終わります。
異常系テストの作り方も逆になります。従来は、人が異常系を想像して仕様書に書き切ることが前提でした。そして、書き切れた現場はありません。Ephemeral Testingでは、エージェントが毎晩障害を注入した記録——何をしたら、何が、どう壊れたか——が異常系のカタログとして蓄積されていきます。人の仕事は異常系を列挙することではなく、判定することになります。「この壊れ方は業務上致命的だから直す」「この壊れ方は許容する」。異常系仕様書は、事前に書き上げる文書から、実際に壊した記録に優先度を付けたものに変わります。
画面のテストには実際の操作をどう再現するかという問題が、バッチのテストには締め日や年度末をどう迎えるかという問題が、それぞれ最後まで残っていました。どちらにも答えが出ています。
画面のテストは、人の探索的テストをエージェントが再現します。computer use系のエージェントは実際のブラウザを操作できます。シナリオの元になるのは、人が一度だけ行う探索的テストのセッション録画です。エージェントはそれを学習して同じ操作を再現し、さらにバリエーションを加えます。入力順を入れ替える、途中でブラウザバックする、二重送信する、セッション切れの状態で確定ボタンを押す。人が一回行った操作が、毎晩数百通りのバリエーションで実行されます。全操作の動画とDOMログが自動で記録されるので、スクリーンショットをExcelに貼るという作業は、この構成には存在しません。
バッチのテストは、環境の時刻を進めます。月次・四半期・年度末のバッチは、従来「その日が来ないとテストできない」か、共有環境の時刻を変えるために全チームへ根回しするかの二択でした。個人環境なら、時刻を偽装するライブラリで環境全体の時刻を進められます。日次、月末、期末、年度末、年跨ぎの処理を、一晩で数年分実行する。年度をまたぐ決算処理を本番で初めて動かす、ということがなくなります。締め日にしか発生しない不具合を、毎晩再現して検証できます。
共有環境では、時刻の変更は他チームのテストを壊すため禁止事項でした。使い捨ての個人環境には、他の誰かのテストに影響するという状況がそもそもありません。共有環境では遠慮してできなかった操作がすべてできるようになり、その分だけ検証できる範囲が広がります。
日中はマージごとの常時検証、夜間は本番超えの性能・障害・時刻加速、朝には判定材料が届く。
ここまで検証を並列化すると、最後に残るボトルネックはPR(プルリクエスト=コード変更のレビュー依頼)です。AIの生成速度に対して、1人のレビュアーが順番に読む方式では追いつきません。この問題も環境の側から解決します。
PRごとに専用環境が起動します。これはエフェメラル環境の本来の使い方で、PRが作られた瞬間にそのブランチのフル環境が起動し、IT・ST・異常系スモーク・性能スモークまで実行した検証結果付きでレビューに届きます。レビュアーが受け取るのは「読むべきコード」ではなく、「どのテストが通り、どのテストが失敗したかの一覧」です。
すると、人が行うレビューの役割が変わります。「動くかどうか」を人がコードを読んで確かめる理由は、もうありません。人が見るのは三つだけです。仕様解釈のずれ、つまりテストは通ったが合格基準の解釈そのものが違う可能性。事前に宣言された重点領域、たとえばデータモデル変更、認証、決済、個人情報。そして、合格基準そのものを変更するPR。
マージの進め方も変わります。検証済みPR同士の順序と競合は、エージェントが依存関係の順に再検証しながら自動でマージしていきます。人の承認が必須なのは「合格基準を変えるPR」と「本番構成の定義(正本)を変えるPR」の二種類だけ。「人が全部読む」という前提がなくなるので、レビュー待ちの滞留もなくなります。
個人環境が数十個、毎晩作られては削除される。構成は各自が実験で自由に変更する。この状況に対する当然の疑問が、「最終的な本番構成は誰が担保するのか」です。
答えは一点に集約されています。本番の定義は一つのリポジトリ——正本——にしかなく、正本に反映されていない変更は、どの個人環境でどれだけ動いていても、本番には存在しません。個人環境で「この構成のほうが速い」と分かったら、その変更は正本へのPRとして提出され、正本の所有者であるアーキテクトが判定します。人間による統制のゲートは、前章の合格基準とこの正本の二箇所だけです。
統制の重心も変わります。従来の「環境を勝手に作らせない」という入口の統制から、「正本に勝手に触らせない」という出口の統制へ。入口は開放してよく、増えすぎた環境はタグと自動削除で整理される。出口は一点で締まっている。この形なら、開発者の自由度と統制の強さを両立できます。実データの扱いも同じ考え方で、本番からのデータの持ち出しは一方向のマスキングパイプラインだけに限定し、逆向きの経路は存在しません。
最後に、なぜ誰もやっていないのかを正直に書きます。部品は全部実在します。使い捨て環境、サービス仮想化、合成データ、カオスエンジニアリング、時刻の加速、PRごとのプレビュー環境。それぞれ単体では、どこかの先進企業が本番運用しています。足りないのは技術ではなく、組織側の仕組みです。環境を資産として計上する会計。テスト計画書の消化率で進捗を測る管理。外結は相手と日程を組んで行うものだという商習慣。どれも「テストは期間を区切った工程である」ことを前提に組まれた仕組みで、技術よりも、こうした仕組みのほうが変わりにくい。だからEphemeral Testingは2026年時点で、理論上は組めるのに絵空事の側に置かれています。先にこの仕組みを組み替えた現場から順に、テストは期間で区切られた工程ではなくなっていくはずです。
Chapter Techでは、開発プロセスの現状分析から、テスト工程と環境構成の再設計、運用ルールの整備、効果測定までの定着支援をAI Delivery Scope+として提供しています。自社の工程表のどこが「環境が高価だった時代の前提」で組まれているのか、という見立ての段階からで構いません。お問い合わせからご相談ください。