6月18日、Gal Veredが「Why AI Testing Must Live Inside Your CI/CD Pipeline」と題した記事を公開した。AIコーディングツールの普及によって生じた「検証のボトルネック」を解消するために、AIテストをCI/CDパイプラインに組み込む必要性を論じた内容だ。
AIが速くしたのはコード生成だけ、ボトルネックは「検証」に移動した
AIコーディングツールを導入したチームが数ヶ月後に気づく逆説がある。開発者の生産性は上がったのに、シニアエンジニアたちがむしろ忙しくなっている。PRレビュー、リグレッション対応、半端に出荷されたフィーチャーのエッジケース処理——それらに追われている。
AIはコード生成を高速化した。しかし、ボトルネックはなくなったのではなく、「検証」の工程に移動しただけだ。
従来のCI/CDは「与えられたものを実行する」仕組みに過ぎない。テストを書くのも、ロジックをレビューするのも、障害をトリアージするのも人間が担う前提で設計されている。AIがコードを高速に生成しても、その先の人間による検証ステップへの負荷が増すだけだ。より速いファネルから、同じ狭い排水口に流し込んでいるに等しい。
解決策はコード生成を遅くすることではない。検証のループを閉じること、そしてそれをパイプラインの中で完結させることだ。
「テストは後でやる」が機能しなくなった理由
従来のテストは「フェーズ」として扱われてきた。フィーチャーを書き、テストし、出荷する。この順序は、各ステップが人間のタイムラインで進む前提では成立していた。しかし、コーディングエージェントが人間の1本分の時間で100本のPRを生成できる時代には通用しない。
結果として起きるのは2つのどちらかだ。
- テストを書く時間がなく、メンテナンスもされないテストスイートが溜まり、本番でリグレッションが露見する
- 品質が出荷速度に追いつかないため、チームが意図的に開発ペースを落とす
どちらも許容できない。にもかかわらず、多くのチームはこの二択を迫られている。
代替手段はテストを「逐次処理」ではなく「継続的処理」に変えることだ。テストの生成・実行・修復が、コミットやPRをトリガーとして自動でパイプライン内に流れ込む構造にする。誰かが手を動かす時間があるときだけ開くツールではなく、誰も求めなくても常に動き続けるものとして。
従来のアプローチとの対比で言えば、GitHub ActionsやCircleCI、Jenkinsといった既存のCI/CDツールはこうした「実行基盤」としての役割を担うが、何をどのタイミングで検証するかの判断はあくまで人間が定義したスクリプトに依存している。記事が主張するのは、その「何を」「いつ」の部分にもAIを介在させ、検証工程そのものを自律化するという考え方だ。
CrowdStrikeの障害が示した「コードの外にある失敗」
テストがCI/CDパイプラインに内包されるべき、より本質的な理由がある。本番環境における「ソフトウェアが動くかどうか」は、コードだけでは決まらないという事実だ。
実際のシステムは、コードがデータベースの状態、サードパーティAPIの挙動、設定値、パーミッション層、キャッシュデータ、そして開発者が想定しなかったユーザー行動と組み合わさって動く。コードを単体で検証するだけでは、最もコストのかかるバグをすり抜けさせてしまう。
この問題の極端な実例が、2024年7月のCrowdStrike障害だ。センサー設定テンプレートとセンサーコードは、それぞれ単体では正常だった。しかし実行時に両者が組み合わさると、フィールド数の不一致が発生し、850万台のWindowsマシンがクラッシュした。個々のコンポーネントはすべてテストをパスしていたが、失敗はその「間」に潜んでいた。この障害の技術的経緯についてはMicrosoftによる事後レポートでも詳しく解説されている。
この「間」に手が届くには、コードを読むだけでなく、実際の環境をシミュレートして実行するテストが必要だ。そして、それはスケジュールされた実行や手動トリガーを待つのではなく、すべてのコミットで継続的に動かす必要がある。
パイプライン内テストが実現する世界
テストがCI/CDに組み込まれると、PRはレビュアーの目に触れる前に実行済みの状態で届く。「コードが正しく見えるか」ではなく「実際に動くか」が確認された状態だ。
変更されたコードに対してピンポイントのテストが自動生成され、インフラが自動構成され、結果がPRに紐づく。テストスイートは製品の変化に追従して更新され続ける。以前はテストスイートの構築と維持に数週間かかっていたものが、不要になる。
APIの変更がシステム全体に波及する問題も、スキーマバリデーションではなく実際のエンドポイント動作に対して検証される。
品質は「最後のチェックポイント」ではなく、パイプラインの性質そのものになる。PRが本番に到達する頃には、実際の稼働条件に近い環境での検証が完了している。
必要なのはスタックの変更ではない
この構造を実現するために既存のスタックを変える必要はない。すでにあるパイプラインに、継続的に動き、全レイヤーのテストをカバーし、検証の速度を生成の速度に合わせるレイヤーを追加すればいい。
記事はスタック変更が不要である点を強調しているが、これは導入障壁の低さを意識した主張でもある。既存のGitHub ActionsやGitLab CI等との統合を前提に、検証レイヤーを「後付け」で加えられるという考え方は、大規模な移行コストを嫌う現場エンジニアへの現実的なメッセージとして読める。
AIコーディングツールが本来約束していた生産性向上は、検証のループが閉じて初めて実現される。コードを速く書けても、出荷に自信が持てなければ意味がない。
詳細はWhy AI Testing Must Live Inside Your CI/CD Pipelineを参照していただきたい。
