オンボーディングや顧客対応、開発者向けの連携作業にAIエージェント（自律的にタスクを実行するAIプログラム）を組み込む企業が増えています。OpenAIが紹介したBasis、Clay、Exa Labsといった企業は、単発のチャット応答ではなく、繰り返し発生する業務フロー自体にAIエージェントを組み込んでいます。CI/CDパイプライン（コードの統合とリリースを自動化する仕組み）を運用している立場から見ると、これは新しい種類の「自動化されたステップ」がリリースフローに追加されることを意味します。品質保証やテスト自動化に関わる方にとって、この変化がどこにリスクを持ち込むかを整理しておく価値があります。
まず押さえておきたいのは、AIエージェントを使った業務自動化と、従来のRPA（ルールベースの業務自動化ツール）の違いです。RPAは決められた手順を決められた順番で実行するだけなので、入力と出力の対応関係が予測可能でした。一方でAIエージェントは、状況に応じて実行するステップ自体を動的に組み立てます。たとえばアカウント管理業務であれば、顧客からの問い合わせ内容に応じて、参照するデータベースや実行するAPI呼び出しの順序をエージェントが自分で判断します。この「毎回同じ処理をするとは限らない」という特性が、テスト設計の前提を変えます。
次に、なぜこれがCI/CDパイプラインの話につながるのかを整理します。従来のソフトウェアテストは、入力Aに対して出力Bが返ることを検証する決定的（deterministic）なテストが中心でした。しかしAIエージェントを組み込んだワークフローは、同じ入力でも実行経路が変わる非決定的な振る舞いを含みます。Basisが会計処理のオンボーディングにエージェントを使う場合も、Clayが顧客データの調査業務に使う場合も、エージェントの判断ロジック自体をユニットテストのように固定検証することは難しくなります。
段階的に見ていく技術的な変更点
具体的にパイプラインに何が追加されるのかを分解します。第一に、エージェントの出力を検証する「評価レイヤー」が必要になります。これは従来のアサーション（期待値と実際の値を比較する検証コード）とは異なり、出力の「妥当性」を別のモデルや基準で判定する仕組みです。たとえば顧客対応エージェントの回答を、正確性・トーン・ポリシー準拠の観点で採点するevalスイート（評価用テストセット）を用意する企業もあります。
第二に、ログとトレースの粒度が変わります。エージェントがどのツールを呼び、どんな中間判断を経て最終出力に至ったかを追跡できないと、不具合の原因調査ができません。OpenTelemetry（分散システムの動作を追跡する標準規格）のようなトレーシング基盤を、エージェントの意思決定ステップにも拡張する必要が出てきます。従来のAPIエンドポイントのレイテンシ計測だけでは不十分です。
第三に、リリースサイクルの単位が変わります。プロンプト（AIへの指示文）やエージェントが参照するツール定義を変更するたびに、モデルの挙動が変わる可能性があります。これはコード変更と同じ扱いでバージョン管理し、リグレッションテスト（既存機能が壊れていないか確認するテスト）の対象に含める必要があります。プロンプトを設定ファイルのように扱い、変更差分をレビューする運用は、Infrastructure as Codeでの設定変更管理に近い発想です。
従来のQA手法との比較で見えてくること
これまでの品質保証は、テストピラミッド（ユニットテスト・統合テスト・E2Eテストを比率で積み上げる考え方）に沿って、決定的な振る舞いを土台に品質を積み上げてきました。AIエージェントを含むフローでは、このピラミッドの上に「振る舞いの妥当性を統計的に評価する層」を追加する発想が必要になります。単発の合否判定ではなく、100回実行して何パーセントが許容範囲に収まるかという指標での品質管理です。
これはA/Bテストやカナリアリリース（新機能を一部のユーザーにだけ先行公開する手法）の考え方と近い部分があります。エージェントの新バージョンを本番の一部トラフィックにだけ適用し、既存バージョンと結果を比較しながら段階的に展開する運用が現実的な選択肢になります。完全な決定性を前提にしたリリースゲート（リリース可否を判定する関門）の設計思想とは、根本的に異なる考え方です。
今日から確認できること
実際に自分の組織がこの変化の影響を受けるかどうかは、次の点を確認すると判断しやすくなります。
- 現在のCIパイプラインに、LLM（大規模言語モデル）やAIエージェントを呼び出すステップが含まれているか。含まれていれば、その呼び出し結果に対するテストが決定的なアサーションだけになっていないか確認します
- プロンプトやツール定義がGitなどのバージョン管理下にあるか。変更履歴が追えない状態であれば、まずそこから整備する余地があります
- エージェントの実行ログに、最終出力だけでなく中間の判断ステップ（どのツールを呼んだか、どんな根拠で分岐したか）が記録されているか
- リリース前の評価に、固定的なテストケースだけでなく、複数回実行したときの結果のばらつきを見る仕組みがあるか
これらの項目に「ない」が多い場合、AIエージェントを本番ワークフローに組み込む前に、評価レイヤーとトレーシングの整備を優先する判断ができます。逆にすでに一部が整っているなら、evalスイートの評価軸を業務ドメインに合わせて拡充する段階に進めます。
まとめ
AIエージェントを業務プロセスの中核に据える動きは、単なる新しいツールの導入ではなく、テスト戦略そのものの見直しを伴います。決定的な入出力検証だけに頼っていたパイプラインは、評価レイヤーの追加なしにはエージェントの品質を捉えきれません。
今日できる一歩としては、既存のCIパイプラインにLLM呼び出しが含まれているかを棚卸しし、そのステップのテストが固定的な期待値比較だけになっていないかを確認することです。プロンプトやツール定義のバージョン管理、実行ログのトレース粒度も合わせて見直すと、次に評価スイートを設計する際の土台が整います。