7月12日、Shuva Jyoti Karが「Beyond the Vibe Check: Why Testing AI Agents Is a Distributed Systems Problem」と題した記事を公開した。Google Cloudのエンジニアリングブログ媒体に掲載されたこの記事は、AIエージェントのテストが従来のソフトウェアテストとは根本的に異なる分散システムの問題であると論じており、軌跡評価・オブザーバビリティ・本番信頼性の観点から実践的な設計原則を詳述している。「正しく動いているように見える」だけのエージェントを本番に出すことがなぜ危険なのか——その構造的な理由と対処法が本稿の核心だ。
「なんとなく動く」で本番に出してはいけない
多くの開発チームは今もAIシステムを「vibe testing（バイブテスティング）」——いくつか質問して、回答が「それっぽく見えれば」本番OKと判断する方法——でデプロイしている。マーケティングコピーを生成するチャットボットなら許容範囲かもしれない。しかしエージェントが本番データベースに対してクエリを発行し、クラウドインフラをプロビジョニングし、金融取引を承認し、エンタープライズシステムを自律的に変更するようになると、この手法は危険なほど不十分になる。
記事の冒頭でShuva Jyoti Karはこう断言する。
"Traditional software fails deterministically. AI agents fail probabilistically. That single distinction changes everything about how we design, test, and operate production systems."
従来のソフトウェアテストが問うのは「関数は正しい結果を返したか？」だ。エージェント評価が問うのは「安全で、観測可能で、効率的で、再現可能な実行パスを通じて、正しい結果に到達したか？」である。この違いは微妙に見えて、設計・運用の全体を変える。
なぜ実行軌跡（trajectory）こそが本質なのか
従来のアプリケーションは、エンジニアが記述した明示的な実行グラフに従う。分岐・リトライ・例外ハンドラはすべて決定論的であり、通常のアサーションでテストできる。
AIエージェントは違う。実行グラフをランタイムで合成する。「もっと情報を取得すべきか」「どのツールを呼ぶか」「計画を見直すべきか」——これらの判断を逐次行い、実行パス自体がモデルの出力の一部になる。
同じリクエストに対してエージェントを2回実行した場合、一方はドキュメントから直接回答し、もう一方は複数のAPIを呼び出して過去のチケットを要約した上で同じ結論に達することがある。両者とも「正しい」。しかし最終回答だけを評価すると、コスト・レイテンシ・安全性・運用信頼性を左右するエンジニアリング上の挙動は完全に見えなくなる。
「最終回答はタスクが成功したかを教える。実行トレースはシステムが信頼できるかを教える。」
こうした実行トレースの収集・分析には、OpenTelemetryをはじめとする分散トレーシングの標準的アプローチが活用できる。エージェントフレームワークとしてはLangChainやGoogle Cloud Agent Builderがトレース出力に対応しており、エージェント固有のオブザーバビリティ基盤として実績がある。
マルチエージェントは信頼性を指数関数的に劣化させる
記事が特に力を入れて論じているのが、マルチエージェント構成の落とし穴だ。
「専門エージェントを組み合わせれば能力が上がる」という直感に反して、実際には逆になることが多い。分散システムの世界では古典的な知識だが、システム全体の信頼性は各コンポーネントの信頼性の積で決まる。
各ステージの成功率が95%でも、8ステージのワークフローを通過する確率は：
Overall Reliability = 0.95⁸ ≈ 66%
推論ステップが増えるほど、信頼性は線形ではなく指数関数的に劣化する。
さらにマルチエージェント固有の問題として、記事は3つを挙げる。
- セマンティックドリフト：各エージェントは前のエージェントの推論状態を継承せず、受け取ったコンテキストから独自に理解を再構築する。初期の小さな曖昧さが下流で増幅される。
- コンテキストロス：LLMは有限のコンテキストウィンドウで動作するため、中間的な仮定や失敗した推論分岐が次のエージェントに渡される前に圧縮・破棄される。
- 調整オーバーヘッド：エージェントが増えるごとに同期境界が増え、オーケストレーション層自体がスケジューリング・リトライ・状態管理を担う分散システムになる。
「制約された自律性は、ほぼ常に無制限の自律性より本番での信頼性が高い。」
エージェント評価の3層モデル
記事の中核をなすのが、評価を3層に分けるフレームワークだ。
1. セッション評価（ビジネス視点）：エージェントはユーザーの目的を達成したか。タスク完了率・安全性。ただしこれだけでは「どのように」達成したかが見えない。
2. 軌跡評価（アーキテクチャ視点）：エージェントは正しく推論したか。最終回答ではなく完全な実行トレースを検査する——計画の決定、取得ステップ、ツール呼び出し、リトライ、中間推論、回復動作。ここで推論ループ・冗長なツール呼び出し・ハルシネーションによるアクションといった、最終回答だけでは見えない隠れた障害モードが露わになる。
3. ノード評価（インフラ視点）：各コンポーネントは決定論的に動作したか。正しいツールが選ばれたか、パラメータはスキーマ準拠か、認可ポリシーは適用されたか。LLMの確率的挙動がシステムの整合性を損なわないことをここで保証する。
本番エージェントの設計原則
記事はクラウドプロバイダ・フィンテック・エンタープライズAIシステムの本番デプロイを分析した上で、4つの原則を導いている。
観測可能性：すべての計画決定・取得イベント・ツール呼び出し・リトライ・状態遷移が構造化テレメトリを出力しなければならない。「なぜこの決定がなされたか」「何の情報が利用可能だったか」「どのツールが呼ばれたか」「外部システムで何が変わったか」——この4問にテレメトリだけで即座に答えられなければ、システムはブラックボックスとして稼働している。OpenTelemetryのセマンティック規約は、こうした構造化テレメトリの設計指針として参照に値する。
再現可能性：すべての実行はプロンプト・取得コンテキスト・ツール出力・モデルバージョン・設定・実行メタデータを含む不変トレースから再現できなければならない。本番障害が永続的な評価スイートへの追加になる。
決定論的境界：推論は確率的でよい。インフラは確率的であってはならない。ツール実行は強い型付きスキーマ・決定論的API・明示的な認可ポリシーを通じて媒介される。モデルはアクションを提案するが、そのアクションが有効かを決めるのは決定論的ソフトウェアだ。
状態はモデルの外に：永続的メモリはコンテキストウィンドウ内にのみ存在してはならない。トランザクショナルDB・ベクターストア・キャッシュ・分析システムに置き、独立してクエリ・バージョン管理・監査・復元できるようにする。
記事全体を通じて一貫するメッセージはシンプルだ。LLMはシステムではなく、システムの一コンポーネントに過ぎない。推論エンジンは確率的であり、その周囲のすべては決定論的でなければならない。AIエージェントのテストとは、言語生成の検証ではなく、不確実性の下での自律的意思決定の検証である。
詳細はBeyond the Vibe Check: Why Testing AI Agents Is a Distributed Systems Problemを参照していただきたい。
