シェア:
){kind=small}
マイケル・パトキン氏は、Vonageのリードデータサイエンティストであり、機械学習の分野で15年以上の経験を持ち、会話分析、インサイト抽出、および研究の自動化に向けたAIを活用したシステムの開発に携わっています。
AIエージェントはあなたに嘘をついている：ワークフローが信頼できる結果を生み出す仕組み
所要時間：2 分
この記事では、VonageのAIチームがワークフローを活用して、エージェント型AIシステムの予測可能性、再現性、そして本番環境での運用準備を整えた方法についてご紹介します。
生成AIは本質的に確率的なものです。AIモデルにメールの作成、会議の要約、コードの生成などを依頼した場合、実行のたびに結果がわずかに異なっても、通常は問題にはなりません。多くの創造的あるいは探索的なタスクにおいて、そのばらつきこそが価値の一部なのです。
分析システムは異なります。
AIシステムを用いて従業員の評価、業務レポートの作成、顧客とのやり取りの分析、あるいはビジネスのトレンドの把握を行う場合、一貫性が重要となります。同じデータに対して同じクエリを実行しても、毎回異なる結果が返されてしまうと、その出力を信頼したり、それに基づいて意思決定を行ったりすることが難しくなります。
Vonage社での社内実験において、顧客体験データ向けのAI駆動型分析ワークフローを構築する過程で、私たちはこの現象を直接確認しました。ある実行では、システムはマリアをトップのサポート担当者としてランク付けしました。15分後、同じ設定で実行したところ、同じシステムが代わりにジェームズを1位にランク付けしました。3回目の実行では、プリヤがトップの結果となりました。
The same AI analytics query produced different top-ranked representatives across repeated runs, despite using the same dataset and prompt.
探索的分析においては、こうしたばらつきは許容範囲内である場合もある。しかし、定期的なダッシュボード、運用レビュー、品質保証ワークフロー、あるいはコンプライアンス報告においては、出力の不整合はすぐに本番環境での問題となる。
このことから、VonageのAIチームにとって重要な疑問が浮上しました。一貫性が求められる状況において、エージェント型システムの挙動をより予測可能にするにはどうすればよいのでしょうか？
これを検証するため、我々は、標準的なエージェントによる実行と、分析手法を固定化し、推論の逸脱を低減し、再現性を向上させるように設計されたワークフロー主導の実行パスを比較する一連の実験を行った。その結果、ワークフローは、エージェントの有用性の根幹をなす柔軟性を損なうことなく、AI駆動型分析システムの一貫性を大幅に向上させることができることが示された。
現代のエージェンティックシステムは、単にテキストを生成するだけにとどまりません。問題を推論し、分析手法を選択し、中間コードを記述し、計算を実行し、結果をどのように提示すべきかを決定します。
能動的実行ループの初期段階における推論のわずかな違いが、プロセスの後半において、結果として実質的に異なる出力へと積み重なっていくことがある。
実験中、私たちは同じパターンを繰り返し観察しました。すなわち、同一のデータセットに対して同一のクエリを実行しても、実行ごとに異なる結果が得られたのです。例えば、次のようなリクエストの場合：
「私のトップ10の代表者は誰ですか？」
わずか30分の間に、トップクラスの社員を3人も輩出することができた。
基礎となるデータは一切変わらなかった。変わったのは、エージェントの推論プロセスだった。
このようなクエリに対応するには、エージェントは分析コードを1行も記述する前に、一連の決定を下さなければなりません：
どの指標が最も重要なのでしょうか？
それらの指標にはどのような重み付けを行うべきでしょうか？
値はどのように正規化すべきでしょうか？
どの閾値やフィルタを適用すべきでしょうか？
最終結果はどのように提示すべきでしょうか？
これらの決定事項はプロンプトには明示的に定義されていません。モデルは実行中にそれらを推論しますが、推論のわずかな違いが、異なる分析手法につながる可能性があります。
ある実行では、エージェントは顧客の感情や共感のスコアを優先するかもしれません。別の実行では、解決率をより重視したり、対応件数の少ない担当者を完全に除外したりするかもしれません。その結果、計算経路が異なり、最終的には異なる順位付けとなります。
このようなばらつきは、探索段階では許容範囲内です。しかし、レポート、ダッシュボード、Audit、そして運用上の意思決定が一貫性に依存する本番システムにおいては、これは信頼性の問題となります。
最近のAIエージェントの多くは、一般にReAct（Reason → Act → Observe）と呼ばれる推論パターンを採用しています。エージェントは単一の応答を生成するのではなく、一連の意思決定とツール呼び出しを経て処理を進めます。
実行の流れを簡略化すると、次のようなものになります：
理由 → データセットを理解する
行動 → 利用可能な列を照会する
観察 → 利用可能な特徴量を確認する
理由 → 指標と手法を選択する
実行 → 分析コードを生成する
観察 → 結果を評価する
検討 → 最終的なレスポンスのフォーマット設定
推論の各段階ごとに、結論が分岐する新たな可能性が生まれる。
プロセスの初期段階でのわずかな変更――たとえば、異なる指標を選択したり、重み付けをわずかに変えたりすること――は、その後のすべての段階に影響を及ぼす可能性があります。元のクエリやデータセットがまったく同じであっても、エージェントは異なる分析コードを生成したり、異なるフィルターを適用したり、スコアの計算方法を変更したりする可能性があります。
以下の図は、たった1つの推論による決定が、エージェントをまったく異なる実行パスへと導く仕組みを示しています。
A small reasoning difference inside a ReAct loop can compound into different analytical methodologies, calculations, and final outputs across repeated agent runs.
この複合的な影響は、生産的エージェントシステムにおける中核的な課題の一つである。推論の連鎖が長くなるほど、実行ごとに結果がばらつく可能性が高くなる。
このばらつきを低減するため、ワークフローによって、分析ドリフトの主な原因となっているシステムの部分を抑制できるかどうかを検討した。
エージェントがクエリの実行のたびに新しい手法を考案するのではなく、ワークフローは、検証済みの「ゴールデンラン」に基づいてあらかじめ定義された実行パスを提供します。このワークフローは、信頼できる結果を生み出した分析構造を保持しており、これには以下が含まれます：
選定された指標
計算ロジック
しきい値とフィルタ
出力の構造と書式設定
注 >> 実験の全設定およびゴールデンランについては、添付の GitHubリポジトリをご覧ください。
エージェントは依然として分析を実行し、リアルタイムのデータとやり取りを行いますが、方法論上の重要な決定事項は、実行のたびに再導出されることはなくなりました。
簡略化したワークフローの手順は、次のようなものになるでしょう：
ステップ 2：エージェントのパフォーマンス指標を集計する
目的：すべての通話にわたる平均パフォーマンス指標を算出する
アクション：agent_id ごとにグループ分けし、平均値を算出する
出力：ランキング用の一貫性のあるスコアリングデータセット
その目的は、従来型のソフトウェアにおける意味での「決定論的」なエージェントを実現することではありませんでした。むしろ、ワークフローによって推論のずれを十分に低減し、分析結果をより安定させ、再現性を高め、本番環境での運用に耐えうるものにするかどうかを検証することでした。
ワークフローによって分析エージェントシステムのばらつきを低減できるかどうかを評価するため、実際の顧客体験データを用いて一連の対照実験を実施しました。
以下のデータを含むコールセンターのデータセットに対して、同じ分析クエリを繰り返し実行してテストしました：
約3,900件の顧客対応
33名のサポート担当者
抽出された20のパフォーマンス特徴量
すべての実験では、AWS Bedrock を通じて Claude Opus 4.5 を使用し、温度設定はデフォルトのままとした。
各テストケースについて、まず標準的なエージェント型実行フローを用いてクエリを10回実行しました。次に、検証済みの「ゴールデンラン」の1つからワークフローを作成し、同じデータセットに対してそのワークフローをさらに10回実行しました。
目標：実行ごとに結果がどの程度変化したかを測定し、ワークフローによってその変動を抑制できるかどうかを検証すること。
注 >> 具体的な実験のセットアップについては、 GitHubの付録の付録に記載されています。
最初の実験では、次のような単純な分析クエリに焦点を当てました：
「総合的なパフォーマンス指標に基づいて、私のトップ10の担当者は誰ですか？」
一見すると、これは単純そうに見えます。しかし、エージェントが順位付けを行うには、その前にいくつかの分析的な判断を下す必要があります：
どの指標が最も重要なのでしょうか？
それらの指標にはどのような重み付けを行うべきでしょうか？
スコアはどのように正規化すべきでしょうか？
どのフィルターや閾値を適用すべきでしょうか？
ワークフローがなかったため、それらの判断は実行のたびに変わっていた。
同じクエリを10回独立して実行した際、エージェントは毎回異なる分析手法を生成しました。指標の重み付けを変更したり、異なる評価尺度を使用したり、ランキングに含めるパフォーマンス要因の数を変化させたりしました。
実行によっては、顧客の満足度が最も高い重み付けとなった。また、別の実行では、解決率が主要な要因となった。0～1のスコア尺度を採用した実行もあれば、0～100の尺度に変更した実行もあった。
こうしたわずかな方法論上の変更が、異なる結果をもたらした。10回の実行において、3人の異なる代表者が1位となった。
Repeated executions of the same AI ranking query produced different scoring methodologies, metric weights, and top-ranked representatives across 10 independent runs.
この変動は、データの変化によるものではありませんでした。順位の変化は、エージェントが分析そのものの仕組みについて絶えず再解釈していたことに起因していました。
ワークフローによってこのドリフトが軽減されたかどうかを測定するため、検証済みの「ゴールデンラン」から生成されたワークフローを用いて実験を繰り返した。
ワークフローがない場合、実行ごとにランキングに大きな変動が見られました。実行ごとに、上位にランクインする代表者が現れたり、消えたり、順位が劇的に変動したりしました。エージェントが応答のフォーマットを変更したため、実行によっては結果が10件未満しか返されないこともありました。
ワークフローが確立されたことで、ランキングははるかに安定したものとなりました。どのワークフローの実行においても、ある代表者が常に1位となり、別の代表者が常に2位となり、トップ10に入る代表者の顔ぶれはすべての実行を通じて一貫して同じままでした。
ランキングの下位では、順序にわずかな違いが見られただけだった。
Workflow-constrained executions produced significantly more stable ranking results across repeated runs compared to fully dynamic agentic execution.
一貫性の向上は、私たちが評価したすべてのランキング指標において測定可能なものでした：
トップ1の一貫性が60%から100%に向上した
ワークフローの実行全体を通じて、トップ10の重複が完全に安定した
実行間の類似度の順位に有意な増加が見られた
ワークフローの導入により、ランキングのずれと手法のずれの両方が軽減されました。2つの重要な示唆（正確性と実行速度）については、「まとめ」のセクションで改めて取り上げます。
2つ目の実験では、エージェントが自然言語の表現におけるわずかな違いにどれほど敏感であるかを検証した。
私たちは、同じ質問を4つの、わずかに異なる方法で尋ねました：
「私のトップ10の営業担当者は誰か？」
「業績が最も良い営業担当者10人を教えてください」
「パフォーマンス順に上位10名の営業担当者をリストアップしてください」
「どの営業担当者の実績が最も優れているか？」
各バリエーションについて、ワークフローを使用する場合と使用しない場合の両方で、複数回実行されました。
ワークフローがない場合、こうしたわずかな表現の変更が、分析結果に顕著な違いをもたらすことがよくありました。「トップの担当者」、「最も実績の高い」、「最高の指標」といった用語は、エージェントにタスクに対する異なる解釈をさせました。 実行によっては、解決率のような測定可能なKPIに重点を置いた分析が行われる一方、他の実行では感情分析やより広範な総合スコアが重視されることもありました。
人間は通常、これらの表現を同義と解釈する。しかし、その行為者はそうは解釈しなかった。
ワークフローが有効になると、実行方法がすでに定義されていたため、表現の仕方はそれほど重要ではなくなりました。表現のバリエーションごとに分析をいちからやり直すのではなく、システムは検証済みの同じ実行パスを再利用したのです。
その結果、一貫性と実行の安定性の両面で、目に見える改善が見られた。
Workflow-constrained executions produced more consistent analytical structures and response formats across different phrasings of the same query.
ワークフローの導入により、言語的な曖昧さが及ぼす影響が軽減され、意味的に類似したリクエストに対してシステムの挙動がより予測しやすくなりました。
ランキングの変動は気づきやすいものです。一方、集計のずれは発見が難しい場合が多いですが、本番環境のレポートシステムにおいては、はるかに危険です。
エージェントがより複雑な分析タスクをどのように処理するかを検証するため、同じデータセットに対して以下のクエリを繰り返し実行しました：
「以下のカテゴリごとにグループ分けして、平均センチメントスコアを算出してください call_reason_categoryごとに平均センチメントスコアを算出し、下降傾向にあるカテゴリを特定してください。」
単純なランキングクエリとは異なり、この種のリクエストでは、エージェントが実行中にいくつかの段階的な分析判断を下さなければならない：
カテゴリはどのようにグループ化すべきでしょうか？
平均値はどのように計算すべきでしょうか？
「減少」とはどのように定義すべきでしょうか？
どのフィルターや閾値を適用すべきでしょうか？
Complex aggregation queries require agents to make multiple methodological decisions that can lead to inconsistent analytical outcomes across repeated runs.
ワークフローがない場合、これらの判断は実行ごとに顕著なばらつきが見られました。トレンド分析に異なる時間枠を用いた実行もあれば、カテゴリのグループ分けが異なっていた実行もありました。また、取引量の少ないカテゴリを完全に除外した実行もあれば、それらを含めた実行もありました。
その結果、データに何の変化もなかったにもかかわらず、同じカテゴリーが、ある実行では「減少傾向」と表示され、別の実行では「横ばい」と表示されることがあります。
この種のばらつきが重要となるのは、集計クエリが運用レポートシステムの中心に位置しているからです。ダッシュボード、KPIのレビュー、コンプライアンスレポート、経営層向け要約などはすべて、時間の経過とともに一貫した結果を生み出す計算に依存しています。
ワークフローを有効にしたことで、集計手法は実行ごとに安定して維持されました。グループ化ロジック、トレンド計算、閾値、およびフィルタリングルールは、検証済みのワークフロー定義から引き継がれ、繰り返し実行しても再現性のある出力が得られました。
ワークフローの導入により、一貫性が単に有用であるだけでなく、法的に義務付けられているレポート作成の場面において、分析のずれが生じるリスクが低減されました。
最後の実験では、意図的に曖昧または矛盾した条件を含むクエリに焦点を当てました。
私たちはエージェントに次のように尋ねました：
「コンプライアンス上のリスクを抱えつつも、顧客満足度が高い営業担当者を特定する。」
この種の要求は、業務分析において頻繁に見られます。チームは、顧客からの高い評価を得ている一方で、コンプライアンス上の懸念も高まっている従業員など、異常なシグナルの組み合わせを特定する必要があることがよくあります。
課題となるのは、「高い顧客満足度」や「コンプライアンスリスク」といった用語が、クエリ自体では数学的に定義されていないという点です。エージェントは、実行中にそれらの閾値が何を意味するのかを判断しなければなりません。
ワークフローがないと、実行のたびにそれらの定義が大きく変わってしまっていた。
実行事例によっては、「高い満足度」とは4.5以上のスコアを指す場合もありました。また、他の事例では、その基準値が3.0近くまで下がったケースもありました。「コンプライアンス・リスク」の定義も、担当者がエスカレーション、Audit結果、またはポリシー違反をどのように解釈するかによって異なっていました。
その結果、同じクエリを実行しても、5人から16人の代表者が返されました。
Ambiguous analytical criteria caused the AI agent to apply different thresholds across repeated runs, producing significantly different result counts from the same query and dataset.
ワークフローを有効にしたことで、検証済みのワークフロー定義からそれらの閾値に関する決定が引き継がれ、実行ごとに大幅に安定した出力が得られるようになった。
Workflows improved consistency and result stability for ambiguous edge-case queries by preserving threshold definitions across repeated runs.
ワークフローの場合でも、本記事の前半で取り上げたランキング実験に比べ、エッジケースを安定させることは依然として困難でした。曖昧なビジネス用語は、明確に定義された分析タスクに比べ、当然ながらばらつきが大きくなる傾向があります。
しかし、ワークフローの導入により、しきい値のドリフトは依然として大幅に低減され、以下の各分野における一貫性が向上した：
結果の数
代表的な重複
出力の安定性
これは、次のような運用システムにとって重要です：
異常検知
Audit報告
コンプライアンス審査
自動アラートシステム
このような環境では、しきい値に一貫性がないと、誤検知や検知漏れが生じたり、実行のたびにフラグが立てられる結果のセットがまったく異なったりする可能性があります。
4つの実験すべてにおいて、エージェントは分析の方法を絶えず変えていました。曖昧な判断を下す必要があるたびに、エージェントは結果に変動をもたらしていました。
ワークフローがなければ、担当者は分析そのものの進め方を繰り返し変更していました。彼らは、元のクエリやデータセットが一切変わっていないにもかかわらず、実行のたびに異なる指標を選択したり、閾値を調整したり、表現の解釈を変えたり、グループ化やフィルタリングのロジックを変更したりしていました。
ワークフローでは、バリデーション済みの「ゴールデンラン」から分析手法を継承することで、そのばらつきを低減しました。
不整合の最大の原因は、システム内部で分析手法が変更されたことでした。
一連の実験を通じて、エージェントは次のような領域で繰り返し漂流した：
メトリック重み付け
閾値の定義
グループ化のロジック
フィルタリングルール
トレンドの算出
採点式
些細な推論の変更ひとつひとつが、コード生成、計算、ランキング、出力といった下流の処理に違いをもたらした。
ワークフローでは、以下を維持することで、そうした決定に制約が設けられていました：
固定指標
固定しきい値
計算パスを修正しました
固定実行順序
システムは、実行のたびに方法論を再構築するのではなく、検証済みの分析プロセスを再利用した。
Workflows stabilize AI analytical systems by preserving validated methodologies, thresholds, and calculations across repeated executions."これにより、繰り返し実行における推論のずれと出力のずれの両方が軽減された。
その影響が明らかになりました。ワークフローを有効にした結果、次のようなことが確認されました：
より安定したランキング
再現可能な集計結果
より予測可能な結果が重要
書式のバリエーションが少ない
より一貫性のある分析構造
これが重要なのは、本番システムでは、出力結果が長期にわたり安定していることが求められるからです。ダッシュボード、品質保証（QA）システム、コンプライアンス審査、自動化されたレポート生成パイプラインはすべて、同じデータに対して同じクエリを実行すれば、実質的に同様の結果が得られることを前提としています。
その一貫性がなければ、下流のシステムを信頼することが難しくなります。
また、実験の結果、分析タスク自体が明確に定義されている場合に、ワークフローの効果が最も高くなることが示された。明確な順位付けや集計タスクは、曖昧性の高いエッジケースのクエリに比べて、はるかに安定していた。
この実験から得られた最大の教訓の一つは、一貫性と正確性は同じものではないということだった。
ワークフローは、統計的に不十分な方法論や、運用上の欠陥がある方法論、あるいは偏りのある方法論であっても、それを確実に維持してしまうことがある。
あるランキング実験において、一貫して上位にランクインしていた代表サンプルは、データセットの中でサンプルサイズが最も小さいものの1つでもありました。このワークフローでは毎回同じ結果が再現されましたが、それだけで結論の信頼性が自動的に保証されるわけではありませんでした。
ワークフローは分析上の判断を保持します。ただし、それらの判断が正しいかどうかを検証するものではありません。
人間による審査は依然として重要だ：
メトリクスの選定は慎重に検討しなければならない
閾値の設定には、その分野の専門知識が必要である
集計ロジックの検証が必要
エッジケースでは、実務上の判断が必要となる
これは、ワークフローが、ビジネスの意思決定や顧客への成果に影響を与える本番システムに展開される前に、重要となります。
目標は単に再現性だけではありません。目標は、再現性があり、適切に管理された分析です。
一連の実験を通じて、ワークフローの実行速度は一貫して速かった。
ワークフローがなかったため、エージェントは次のような作業を繰り返し行わなければならなかった：
データセットの調査
方法論の再検討
計算の見直し
分析的アプローチの再検討
代替の実行パスの生成
推論のステップが1つ増えるごとに、LLMへの呼び出し回数が増え、実行オーバーヘッドが増大し、結果が乖離する可能性も高まった。
ワークフローの導入により、そうした探索的な推論の多くが排除されました。実行パスはあらかじめ定義されていたため、システムは分析手法をいちから作り直すのではなく、分析の実行そのものに集中することができたのです。
分析上の回り道を減らした結果、次のような結果が得られた：
実行パスが短くなる
応答時間の短縮
より予測しやすい実行時の挙動
パフォーマンスの向上は完全に決定論的というわけではありませんでしたが、すべての実験を通じて一貫した傾向が見られました。つまり、解析上の回り道が少なくなればなるほど、実行はより高速かつ安定したものになりました。
Workflow-constrained executions completed faster and required fewer reasoning steps than fully dynamic agentic executions.
実験の結果、ワークフローは、探索よりも一貫性が重視されるシステムにおいて最も価値があることが示された。
ワークフローは、次のような場合に特に適しています：
報告は再現可能でなければならない。
出力は、下流のシステムやダッシュボードに送信されます。
分析論理は、時間の経過とともに安定していなければならない。
その結果は、運用上の観点から検証されるか、あるいは後日Auditが行われる。
チームは、繰り返し実行する際にも、ランキング、閾値、または計算方法が一貫している必要があります。
これは特に、以下の点において重要です：
業務報告
コンプライアンス審査
QAシステム
異常検知
自動アラート
顧客分析プラットフォーム
こうした環境では、創造性よりも再現性がはるかに重要となる。
しかし、ワークフローがすべてのユースケースに適した解決策であるとは限りません。
動的な主体的推論は、次のような場合にも依然として価値をもたらします：
未知のデータセットの探索
仮説のブレインストーミング
新たな分析的視点を生み出す
方法論の試行錯誤
予期せぬパターンを探す
そのような状況では、多様性は、さまざまなアプローチや洞察を引き出す助けとなるため、むしろ有益であると言えます。
重要なトレードオフは、柔軟性と一貫性のバランスです。ワークフローでは、推論プロセスの一部を意図的に制限することで、時間の経過とともに分析行動の予測可能性を高めています。
AIエージェントは、動的に推論を行い、状況に適応し、その場で分析手法を導き出すことができるため、非常に強力です。しかし、その柔軟性ゆえに、ばらつきも生じます。
4つの実験すべてにおいて、同じ傾向が見られた。すなわち、分析手法を完全に動的なままにしておくと、クエリや基礎となるデータが一切変わっていなくても、実行ごとに結果にばらつきが生じた。
ワークフローでは、指標、閾値、グループ化ロジック、実行パスなど、分析の根底にある重要な決定事項を維持することで、そのずれを軽減しました。
それらは、エージェント型システムを完全に決定論的なものにするわけではなく、正しさを保証するものでもありません。人間によるレビュー、検証、そして専門知識は、依然として重要な役割を果たしています。
しかし、一貫性、再現性、運用上の信頼性が重要となる場合、ワークフローは、本番環境においてエージェント型システムの挙動を大幅に予測しやすくするための実用的な手段となります。
ご質問がある場合、またはあなたが作っているものを共有したい場合は、こちらをクリックしてください。
登録する 開発者ニュースレター
フォローする X（旧ツイッター）最新情報
チュートリアルを見る YouTubeチャンネル
LinkedInの LinkedIn の Vonage デベロッパーページ
最新の開発者向けニュース、ヒント、イベント情報をお届けします。
本記事で紹介する実験は、検証済みの「ゴールデンラン」ワークフローに加え、実験構成、指標の定義、および実装例によって支えられています。
この方法論についてさらに詳しく知りたい読者の皆様のために、GitHubに完全な補足資料を公開しました：
このリポジトリには以下のものが含まれています：
7つのステップからなる「ゴールデン・ラン」ワークフローの全工程、
実験の構成、
計量の定義、
検証およびエッジケースの処理例、
および本記事全体で使用されている図。