AI駆動開発の話題は、コーディングがどれだけ速くなったかに集中しがちです。しかし受託開発・エンタープライズ開発の実務でより大きく変わるのは、テスト工程——IT(結合テスト)・ST(総合テスト)・STG(ステージング検証)——の側だと考えています。IT→ST→STGを「順番に・一度きり・重厚に」進める形は、テストの作成・実行・環境構築が高価だった時代のコスト構造が選ばせたものでした。Claude等のAIとIaC(インフラをコードで管理する仕組み)によって環境を作り直す費用がほぼ消えた今、この形を維持する理由も一緒に消えています。本コラムでは、工程がどう変わるかの見立てと、その受け皿として開発者一人ひとりがAWS上に使い捨てのVPCサンドボックスを持つ構成、そしてそれをエンタープライズで成立させる運用——タグと自動削除、データマスキング、性能検証の記録——までを整理します。
IT(結合テスト)→ST(総合テスト)→STG(ステージング検証)という進め方は、開発の自然法則ではありません。テストの作成・実行・環境構築のどれもが高価だった時代に、その費用を最小化するために選ばれた形です。
環境が高価であることの帰結は、はっきりしています。高価だから、環境は共有されます。共有された瞬間に、順番待ちと日程調整が生まれます。他チームのデータや設定と干渉し、障害が起きるたびに「自分のバグか、他人の残骸か」の切り分けに工数が溶けます。そして何より、「壊したら他人に迷惑」という遠慮が、破壊的なテストを妨げます。異常系を執拗に叩く、障害を意図的に起こす、データを壊してリカバリを試す——価値の高い検証ほど、共有環境ではやりにくいのです。
実行と作成が高価であることの帰結が、「一度きり・重厚に」です。環境を使える期間が限られているから、テストは節目の工程としてまとめられ、計画され、消化率で管理されます。やり直しの費用が大きいから一度で通すことが目標になり、工程はさらに重くなります。
テスト環境の調整に溶けていく工数は、SIの現場にいた方なら説明の要らない痛みだと思います。ただ、ここで確認したいのは痛みではなく構造です。この形は、環境が高価である限りにおいて合理的でした。だから論点は工程の良し悪しではなく、前提がまだ成り立っているかどうかです。
Claude等のAIによるコーディングは、アプリケーションのコードだけでなく、IaC(インフラをコードで管理する仕組み)の記述にも同じだけ効きます。TerraformやCDKのテンプレートを起こす、パラメータを調整する、変更の影響を確認する——この一連が体感で10倍速になり、環境を「作る・調整する・作り直す」費用がほぼゼロになりました。
この一点が、テスト工程のすべての前提を変えます。環境の性格が、維持する資産から、必要なときにコードから生成する出力に変わるからです。構成がズレたら直すのではなく、捨てて作り直す。維持しないものには、順番待ちも、棚卸しも、構成ドリフト(手作業変更でコード定義とズレていく問題)との戦いもありません。
工程の側に現れる変化は二つです。
一つ目。ITとSTの境目が薄れ、「工程」ではなく「常時回る検証ループ」になります。環境がいつでも作れるなら、結合の確認を節目まで貯めておく理由がありません。マージのたびに環境を作り、結合された状態で検証し、壊れたらその場で直す。節目の一発勝負が、小さく数の多い検証の常時実行に置き換わっていきます。仕様・テスト・実装を常時突き合わせる組み方は仕様駆動か、テスト駆動か、評価駆動かに書いた通りで、環境の側がようやくそれに追いつく話だと言えます。
二つ目。STGの役割が「環境差分の確認」に純化します。機能の確からしさが個人環境で検証済みなら、STGに残るのは、個人環境では再現しない差分——本番相当データ、外部システムとの接続、権限、ネットワーク——の確認だけです。機能確認の再演をやめたSTGは、薄く、短くなります。
IT→ST→STGの並びは自然法則ではなく、環境が高価だった時代のコスト構造が選ばせた形である。
なお、これは工程表から縦線が消えるという話ではありません。受託開発には契約と検収があり、工程の区切りは合意の区切りとして残ります(ウォーターフォールでAI駆動開発を回すに書いた通りです)。変わるのは区切りの位置ではなく、各区切りの中身と厚みです。
この前提の変化を受け止める構成として提案したいのが、開発者一人ひとりがAWS上にVPC(隔離されたプライベートネットワーク)ごと自分の環境を持つ形です。位置づけは開発端末の拡張——ローカルPCにDockerを立てるのと同じ感覚で、クラウド上にフルスタックの環境を持ちます。共有のIT環境・ST環境の代わりに、個人の検証環境が人数分ある状態です。
本番構成の定義(IaCの正本)は1つ。開発者ごとの環境も本番も、同じコードから生成される。
ポイントは三つあります。
維持しない前提。環境は個人の持ち物で、プロジェクトの終了と同時にVPCごと破棄します。定義はIaCの正本にあり、環境はそこから数分で再生成できる出力にすぎません。共有資産として維持しないので、構成ドリフトは直す対象ですらなくなります——ズレたら、作り直すほうが速いからです。
完全隔離だから壊せる。VPCレベルで隔離されているため、何をしても他人の検証にも本番にも届きません。他人への影響を一切考えずに、AIエージェントへ破壊的なシナリオテスト——異常系の執拗な網羅、障害の注入、データ破壊とリカバリのリハーサル——を何百回でも回させられます。共有環境の心理的コストが消滅します。付け加えると、AIエージェントが回すテストの量と副作用は人手の比ではなく、共有環境ではそもそも受け止め切れません。個人サンドボックスは、AIエージェントに与える「壊してよい作業場」でもあります。
スペックとデータ量は、テストに合わせて各自調整。機能確認は最小スペック+少量データで回転速度を優先し、性能検証のときだけ本番相当に上げて、終わったら落とします。クラウドの従量課金と噛み合う使い方で、次章の通り、「常に本番相当を維持」する方式より総額で安くなる可能性すらあります。
この構成にすると、インフラ費は確かに上がります。人数分の環境が動くのだから当然で、目安としては一人あたり月数万〜十数万円を見込むことになります。
ただ、この数字を「テスト環境の予算が増えた」と読むと、比較の相手を間違えます。並べるものは、環境の調整・順番待ち・他人起因の障害切り分けに溶けているエンジニアの工数です。環境の空き待ちで検証が翌週に回る。結合障害の半分が「他チームのデータでした」で終わる。環境担当が日程調整に張り付く。この種の時間をエンジニアの単価で金額に直すと、月数万円のインフラ費は比較にならないことが多いはずです。
もう一つ、方式の違いも費用に効きます。「常に本番相当の共有環境を維持」する方式は、誰も使っていない夜間や休日にも費用が出続けます。「使うときだけ作り、性能検証のときだけ上げて、終わったら落とす」方式は、従量課金の構造とそのまま噛み合います。並列度とデータ量によっては、環境を人数分に増やしたのに総額は下がった、という結果も普通に起こりえます。
もちろん、数字は各社の条件次第です。ただ、比較の枠組みを「インフラ費の増分 対 待ちと調整の工数」に置き直すだけで、答えが変わる現場は多いと考えています。
自由に作れる構成の弱点は一つだけです。作られた環境が、破棄されずに残ること。使われていないインスタンスが数十件積み上がった請求書は、この構成への信頼を一撃で壊します。だからここだけは、人の注意力ではなく仕組みで潰します。
統制は人の注意力ではなく、タグと自動処理で担保する。運用ルールは一行で済む。
「作るのは自由。ただし、名札のない環境は消される。」
仕組みは三段です。まず、所有者・プロジェクト・有効期限のタグを、IaCテンプレート側に必須項目として埋め込みます。環境はテンプレート経由でしか作れないため、名札のない環境が生まれる余地がそもそもありません。次に、期限切れの環境は自動停止し、猶予期間ののち自動削除します。延長したければ、本人が期限タグを更新するだけ。申請も承認も挟みません——手続きを重くしないからこそ、期限を短く設定できます。最後に、人が見るのは月次の「タグなしリソース一覧」だけ。タグなしはテンプレートを迂回した作成の兆候なので、そこだけ人が確認します。
運用ルールは一行で済みます。「作るのは自由。ただし、名札のない環境は消される。」環境の一覧表を維持する、棚卸しを回す、削除の可否を人が判断する——そうした管理業務を定常的に持たないことが、この構成を軽いまま保ちます。
個人サンドボックスは自由度の高い構成なので、エンタープライズで採用するなら統制を三箇所だけ足します。逆に言えば、この三箇所以外は自由のままでよい、という整理です。
データ。個人環境に本番相当のデータをそのまま撒くわけにはいきません。個人環境の数だけ、漏えいの面が増えるからです。マスキング済み(または合成)のデータセットを用意し、環境の作成時に自動投入されるところまでをテンプレートに含めます。「環境を作れば、安全なデータが最初から入っている」を既定にすると、開発者が本番データを持ち込む動機そのものが消えます。
性能検証の記録。各自がスペックを自由に調整できる構成では、軽量環境の結果を根拠に「性能は問題ない」と誤判断する事故が起こりえます。性能検証だけは、指定構成での実施を記録に残します。環境の構成がコードで定義されている以上、「どの構成で測ったか」は自動で記録できます——構成情報の付いていない性能報告を判断材料にしない、という運用です。
本番構成の一元管理。個人環境が何十と乱立しても、本番環境の定義だけは1つのコードから生成される状態を守ります。個人環境の自由は、本番定義の一元性と引き換えに成立している——ここが統制の最後の砦です。
環境とテストをここまで並列化しても、実はもう一つ詰まる場所が残ります。PR(プルリクエスト=コード変更のレビュー依頼)の処理速度です。
AIの生成速度に対して、「PRを1人のレビュアーが順番に裁く」という従来の世界観が合わなくなっています。個人サンドボックスで検証がいくら並列に回っても、マージの入口が直列なら、全体のスループットはそこで頭打ちになります。複数人で開発すればなおさらです。ボトルネックが「環境」から「レビュー」へ移った、と言ってもいい。AIによる一次レビューの自動化、レビュー粒度の見直し、マージ権限の持たせ方まで含めて考える必要のあるテーマで、これは稿を改めて書きます。
最後に、本コラムの主張を一つに絞るなら、こうなります。AIによる高速化の価値は「同じことを速くやる」ことではなく、「コストが高いから諦めていた運用」を解禁することにあります。開発者ごとの使い捨て環境は、十年前にも構想だけならできました。見合わなかったのは、IaCを書き続け、調整し続ける工数です。環境構築が10倍速になった今、諦めの前提だけが消えています。テスト環境の順番待ちに心当たりのある現場ほど、効く構成のはずです。
Chapter Techでは、開発プロセスの現状分析から、テスト工程と環境構成の見直し、運用ルールの整備、効果測定までの定着支援をAI Delivery Scope+として提供しています。共有テスト環境の待ちと調整にどれだけ工数が溶けているか、という見立ての段階からで構いません。お問い合わせからご相談ください。