10月11日、SiliconAngleのM. Touheedが「Agentic workloads break assumptions about software testing. Here's how to cope」と題した記事を公開した。AIエージェント型ワークロードは、従来のソフトウェアテストが依拠してきた3つの前提——「ジョブはすぐ終わる」「リトライはタダ」「同じ入力は同じ出力を返す」——をすべて壊す。PoCが成功したのに本番で問題が噴出するのはモデルの品質ではなく、周辺インフラと運用プロセスがエージェント型ワークロードの特性を前提としていないことが原因だ。この構造的な落とし穴と、その具体的な対処法を本記事は詳説している。
「パイロットは成功した、本番は崩壊した」の正体
エージェント型AIのPoC（概念実証）がうまくいったのに、本番運用に移した途端に問題が噴出する——この現象の原因は、モデルの品質ではない。周辺インフラと運用プロセスが、エージェント型ワークロードの特性を前提としていないことが根本原因だ。
従来のエンタープライズシステムは、暗黙のうちに3つの前提に立脚していた。
- ジョブはすぐ終わる
- リトライはタダ
- 同じ入力は同じ出力を返す
エージェント型ワークロードはこの3つをすべて壊す。
背景として、2024〜2025年にかけてエージェントAIの企業採用が急増フェーズに入ったことが、この問題を顕在化させている。PoCから本番への移行件数が増えるほど、従来の運用プロセスとの摩擦が大規模に露出するようになった。
何が変わったのか
処理時間はミリ秒ではなく分単位になった。 エージェントのタスクは、既存スタックのタイムアウト閾値を超えるほど長く走ることがある。安定していたはずのシステムが、謎めいた形で落ち始める原因がこれだ。
リトライがコストを生む。 従来のリトライはほぼ無償だったため、チームは気前よくリトライしてきた。しかし従量課金のモデルAPIでは、成功しようが失敗しようが、試行ごとにコンピュートリソースが消費される。緩い品質閾値と自動リトライの組み合わせが、気づかないうちにコストを積み上げる。クラウドやモデルAPIの利用料は月次の非同期請求のため、複利的に膨らんだ費用は請求書が届くまで見えない。
障害が再現できない。 これが最大の変化だ。不正な出力を調査するとき、エンジニアの標準的な手順は「もう一度走らせて失敗を観察する」ことだ。しかしエージェントが絡むと、それが通用しない。エージェントの意思決定、ツール呼び出し、APIの実行をステップごとに記録したトレースがなければ、調査は推測にしかならない。こうした分散トレーシングの基盤として、OpenTelemetryのような標準仕様を活用する動きが広がっている。
なぜパイロットはこれを隠してしまうのか
インタラクティブな検証段階では、人間がエラーハンドラーとして機能している。結果を読んで問題を見つけ、手動で修正する。コストも手動でカウントされるから見える。
本番の自動ワークフローは違う。スケジューラーが一晩で400回実行する間、誰も見ていない。人間が一つひとつ吸収して補正していたエラーが、下流のシステムをサイレントに壊し続ける。エラーは最初からそこにあった——人間が隠していただけだ。
自動化に移行する前に、エンジニアリングリーダーは「人間が手動でやっていたタスクを全部洗い出し、どの自動チェックがそれを引き継ぐか」を明文化しなければならない。
特に注意すべき3つのリスク
① コストの不可視化
自律的なAIループは、人間の介入や承認なしにAPIを叩き続ける。「API呼び出し単価」ではなく、「完了単位あたりのコスト」を指標にすること。前者は廃棄された試行分を除外しているため実態を反映しない。
② 成功に見える失敗
最もコストの高い欠陥は、エラーではなく「構造的には正しいが内容が間違っている出力」だ。確率的なエージェントは自分の論理的誤りを認識できないため、形式は正しいが内容が破綻したデータを生成する。下流の自動システムはアラートを出さずにそれを受け入れて処理する。通常の死活監視やエラーログではこの種の欠陥は検出できない。**LLM-as-a-judge（LLM自体を評価者として用い、別のLLMの出力品質を採点する手法）、アサーションチェック、セマンティックベンチマーク**など、事前に定義したプログラム的基準で出力品質を計測する必要がある。
③ 誰も説明できないインシデント
どのモデルバージョン、どの入力、どの設定が特定の出力を生んだかを特定できなければ、調査もできないし監査にも耐えられない。実行中に記録するのは安価だが、後から再構成するのはほぼ不可能だ。
チームに問うべき5つの質問
記事は、上記のリスクに対処するための確認事項として以下を挙げている。
- 「許容できる出力」の定義は、実行前に文書化されているか？ 個人の判断で変わる基準は自動化できない。曖昧な基準のままPoC評価を終えているチームは、この問いで初めて足元の脆さに気づくことになる。
- 完了1件あたりの平均試行回数は把握しているか、上限は設けているか？ 上限なしのリトライループが過剰支出の最多原因だ。把握できていなければ、コスト管理は事実上機能していない。
- すべての実行について何を記録しているか、6ヶ月後にそのレコードを提出できるか？ 入力ペイロード、プロンプト・モデルバージョン、タイムスタンプ、実行レイテンシ、リトライ回数、トークンコスト、最終出力が含まれるべきだ。規制業種では監査対応として、そうでない業種でも障害調査の基盤として、この記録は不可欠になる。
- 各クラスの出力を承認するのは、名前で言える誰か一人か？ チームではなく個人を指定する。責任の所在が曖昧なまま自動化だけが進むと、誰もインシデントをオーナーシップできなくなる。
- プロバイダーがモデルを更新したとき何が起きるか？ モデルのバージョン変更はレスポンスの書式、精度、推論ロジックを微妙に変える。本番投入前にステージング環境でテストしなければならない。このリスクはモデルのバージョン固定ポリシーと合わせて議論されるべき問題でもある。
スキルのギャップも見落とさない
エージェント機能を構築するチームの多くは、アプリケーション開発出身だ。同期的なリクエスト・レスポンスの世界に慣れているため、エージェント型ワークロードを扱う際のメンタルモデルが合っていない。
これらのワークロードの挙動はデータパイプラインに近い。長時間稼働し、部分的に失敗し、再実行コストが高い。このスキルギャップは、一連の予期しないインシデントとして表面化する。スキルの会話は、インシデント対応より安上がりだ。
記事の結論は明快だ。「エージェントAIは新しい種類の運用問題を生み出したわけではない。数十年にわたって存在してきた前提を取り除いただけだ」。実行前に正しさの定義を決める、完了単位のコストを測る、再現できないものを調査できるだけ記録する、出荷に責任を持つ人物を名指しで決める——どれも目新しいことではないが、現在のスタックはそのように設計されていない。
詳細はAgentic workloads break assumptions about software testing. Here's how to copeを参照していただきたい。
