AI駆動開発の議論は、コーディングの速さとレビューの負荷に集中していて、テストの中身——外部結合をどう組むのか、性能をどう測るのか、運用と監視をどう確かめるのか、画面とバッチをどう回すのか——は、まだ従来の工程表の上に置かれたままです。本コラムで書くのは、その工程表ごと置き換える構成です。開発者一人ひとりがAWS上に使い捨てのフルスタック環境をVPC(隔離されたプライベートネットワーク)ごと持ち、AIエージェントがその中でIT(結合テスト)・ST(総合テスト)・外部結合・性能・運用・異常系の検証を常時回し続ける。テストは期間ではなく状態になり、テスト計画書は合格基準の定義だけを残して消える——この構成を、海外で定着しつつあるEphemeral Environment(使い捨て環境)の先にあるものとして、Ephemeral Testingと呼ぶことにします。部品はすべて実在の技術です。サービス仮想化、合成データによる増幅、カオスエンジニアリング、時刻の加速。単品ではどこかの先進企業が既に本番で使っていて、しかし束ねて「テスト工程」の代わりに置いた現場はまだほとんどありません。理論上は組めるが、誰も手を出していない——そこまで含めて書きます。
定義は四行で書けます。
前提はひとつだけです。Claude等のAIによってIaC(インフラをコードで管理する仕組み)の記述と調整が桁で速くなり、環境が「維持する資産」から「必要なときに生成する出力」に変わったこと。ここから先は、この前提の帰結をテストの各論——外部結合、性能、運用、異常系、画面、バッチ——に敷き詰めていく話です。
シフトレフトという言葉がありますが、あれとは別物です。シフトレフトはテストを工程表の左(前)へずらす話で、工程表そのものは残ります。Ephemeral Testingは時間軸から工程を外す話です。左に寄せるのではなく、常に実行されている。
テスト計画書が消える、と書いたのには根拠があります。テスト計画書の中身を思い出すと——環境の割当、実施期間、体制、実施順序、消化の管理。あの文書の実体は、環境と期間という希少資源の配分表です。環境が希少でなくなった瞬間、配分するものがなくなります。残るのは「何をもって合格とするか」だけで、それはテスト計画ではなく要件定義の側の仕事です。合格基準をどの正本——仕様書・テストコード・評価セット——に固定するかという設計は、仕様駆動か、テスト駆動か、評価駆動かに書いた通りです。
本番構成の定義(IaCの正本)は1つ。開発者ごとの環境も本番も、同じコードから生成される。
構成の骨格は上の通りで、本番構成の定義(IaCの正本)から、開発者ごとの環境も本番も同じコードで生成されます。環境の乱立は機械が始末します——所有者と有効期限のタグをテンプレートで強制し、期限切れは自動停止から自動削除へ。人が見るのは月次のタグなしリソース一覧だけです。
ITとSTの境目は、「実行」と「判定」に分けると正確に描けます。
溶けるもの――結合の段取りそのもの。従来のITで最も重かったのは、テストケースではなく段取りです。どのチームの成果物がいつ揃うか、どこまでをスタブで代替し、いつ実物に置き換えるか——結合順の管理表と置換計画は、共有環境が世界に一つしかないことの産物でした。全チームのマージ済み成果物が毎朝すべての個人環境に乗る構成では、「今週はどこまで結合するか」という問い自体が存在しません。常に全部が結合された状態で開発しています。疎通確認とリグレッションはマージごとに回り、業務シナリオは毎晩、受入シナリオ全件をエージェントが流します。
このときシナリオ消化率という進捗指標は無意味になります。毎晩100%流れるからです。意味を持つ数字は「落ちた件数と、その業務致命度」だけになります。
残るもの――判定と、本物と、本番データ。第一に、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+として提供しています。自社の工程表のどこが「環境が高価だった時代の骨格」なのか、という見立ての段階からで構いません。お問い合わせからご相談ください。