SalesforceのAIエージェント基盤「Agentforce」は、対話を起点に業務処理を実行することで、CRMを単なる入力・管理システムから「判断し、実行する業務基盤」へと進化させています。一方で、PoCや初期検証では問題なく動作していたAgentforceが、本番運用に入った途端にトラブルを引き起こすケースも少なくありません。

重要なのは、こうしたトラブルの多くがAIモデルの評価不足ではなく、Agentforceを「業務システムとしてテストしているか」に起因している点です。Agentforceは単なるチャットボットではありません。Salesforceのメタデータ、業務ロジック、ユーザー権限、外部システムと密接に結びついた業務プロセスそのものなのです。

本ブログでは、Agentforce運用で実際に起こりやすい5つのトラブルを取り上げ、それぞれについて
Provarがどのような役割を果たし、なぜ本質的な防止策になり得るのか、また純正のAgentforce Testing Center（テストセンター）の役割と併用パターンについて、解説します。

Agentforceの「運用の落とし穴」とその防止策は

Agentforceは、AIエージェントを業務フローに組み込み、対話や自動応答を通じてユーザー体験を変革する仕組みです。しかしながらその柔軟性ゆえに、実際の導入現場では思わぬトラブルが生じやすいという現実があります。
またAIエージェントは、CRMのメタデータ、外部システムとの連携情報、さらにはユーザーごとの権限設定をもとに動作します。そのため、PoC（概念実証）段階では順調だったものが、本番環境では「応答しない」「別のエージェントが割り込む」「データ登録が失敗する」といった問題に発展することがあります。
以下では、Agentforceの運用で特に想定されるトラブルと、その具体的な防止策を整理します。

トラブル①：プロンプト更新後に業務フローが崩れる

Agentforce運用では、プロンプトやLLM設定の更新は避けられません。問題は、更新後に会話の分岐条件が変わり、想定外のルートに進んだり、後続のFlowやApexが実行されなくなったりする点です。
実務上のリスクは、応答文の表現が変わることではなく、業務としての結果が変わってしまうことにあります。

Provarの役割：Provarでは、会話入力から分岐条件、Flow／Apexの実行、レコード更新、そして画面反映のプロセスを1本のE2E（エンドツーエンド）シナリオとして定義できます。プロンプト更新後も同じシナリオを再実行することで、「業務として同じゴールに到達しているか」を自動で検証できます。

これはいわゆる応答比較ではなく、業務回帰テストです。そのため、プロンプト変更によって業務が壊れた瞬間を、事前に検知できなければなりません。

トラブル②：本番ユーザー権限でだけ動作しない

管理者権限では問題なく動作していたAgentforceが、営業担当や承認者の権限ではデータにアクセスできず、会話や業務処理が途中で止まるケースは非常に多く見られるトラブルのひとつです。

Provarの役割：Provarは、ユーザーやプロファイルを切り替えながらテストを実行できます。これにより、営業担当として会話を開始 → 承認者として次の処理を実行 →管理者として最終状態を確認といった、実際の業務ロール遷移を含むシナリオを再現できます。

これは単発の権限チェックではなく、「どの権限で、どの会話を経由し、どの業務が失敗するか」のライン（境界線）をE2Eで把握できる点が、実運用において極めて重要です。

トラブル③：外部システム連携

AgentforceはERP、会計システム、Slack、MuleSoft経由のAPI連携など、外部システムとの接続を前提に使われます。そのため、非同期処理やレスポンス遅延により、Salesforce側の状態と外部データが一致しなくなるトラブルは、実運用では避けられません。

Provarの役割：Provarは、外部連携を業務シナリオの一部として扱う設計になっています。
API呼び出し後のSalesforceデータ、再試行処理、最終的な画面反映までを含めて検証し、
業務として正しい状態に収束しているかを確認できます。

これは単なるAPIレスポンスの成否ではなく、「業務結果として正しいかどうか」をテストできる点が他のツールとの決定的な違いです。

トラブル④：マルチエージェント構成で処理が競合する

複数のAIエージェントが同一レコードやイベントを扱う構成では、処理順序の競合によって履歴や状態が上書きされるリスクがあります。これは単発テストではほぼ再現できません。

Provarの役割：Provarは、時系列を意識した操作と同一レコードへの複数処理、条件分岐や順序依存を含むシナリオ型テストを構築できます。これにより、「どの順番で処理が走ると問題が起きるのか」を再現し、競合条件を事前に洗い出すことが可能です。

トラブル⑤：会話履歴・前提条件のズレによる応答品質の低下

Agentforceは自律的に学習し続けるAIではありませんが、会話履歴や参照データの扱いを誤ると、意図しない文脈を引きずった応答が発生します。

Provarの役割：Provarでは、初期データ状態と会話履歴の有無、業務前提条件などをテストごとに明示的に定義・固定できます。これにより、常に同じ条件から業務を開始でき、「なぜか挙動が違う」という再現不能なトラブルを防止できます。

Agentforceテストセンターの併用と適用パターン

ここまで見てきたように、Agentforce運用で発生する主要な実務上のトラブルは、基本的にProvar単独で事前に再現・検知・防止することが可能です。

では、Agentforceテストセンターは不要なのでしょうか。答えはNOです。Agentforceの品質には、AIとしての健全性（単一応答・ガードレール・禁止表現）、または業務システムとしての信頼性（マルチターン・状態遷移・業務結果）という2つの異なるレイヤーがあります。主にテストセンターは前者、Provarは後者を担います。両者は競合ではなく、役割の異なる補完関係にあります。

両者の併用を前提に、Agentforceの導入から本番稼働までの流れの基本パターンを簡単に説明します。

PoC段階：主にテストセンターを用いてプロンプト精度やAI応答の正確性を確認します。一方、PoC段階からProvarによる自動検証を導入することで、手動テストでは網羅できない大量の対話パターンを試行でき、AIが失敗する条件（AIの境界線）を迅速に特定できます。

Sandbox段階：主にProvarによってSalesforceフローや外部API連携を含むE2Eテストを高度に自動化します。

Staging段階：テストセンターによるAI応答比較と、Provarによる継続的な回帰テストを併行実施し、本番移行前の整合性を二重に担保します。

Production（本稼働）段階：Provarを定期的な回帰・性能検証の自動ジョブとして運用。Salesforceの定期バージョンアップへの対応、また自動実行とレポート機能を活用し、AIプロンプト変更やFlow修正のたびに自動的に再テストを実施する体制を整えます。

「AI特有の品質、健全性」の領域はテストセンターの得意分野であり、プロンプトの「微差」による比較検証や差別的な表現、会社の規約に反する回答といったハルシネーションを含むAIの倫理・安全性チェックなどは、テストセンターに組み込まれた評価モデル（LLMがAIを評価する仕組み）が適しています。

まとめ：Agentforce運用の品質保証は新たなステージへ

Agentforceを単なるPoCで終わらせず、本番業務で使い続けるためには、マルチターン会話と業務を一体としてE2Eで検証できる基盤が不可欠です。

その主要な役割を担うのにProvarが最適です。そのうえで、AIエージェント単体の初期品質確認やガードレール検証には、テストセンターを併用する。この役割分担こそが、最も現実的で再現性の高いAgentforceテスト戦略となります。

エージェントを介する運用においては、「AIが正しく会話するか」よりも、「AIがSalesforceのデータを壊さないか（Provarの役割）」のほうが、ビジネスリスクが圧倒的に高いため、Provarによる様々なリスク回避の検討は正しい方向性と言えるでしょう。

よくある質問（FAQ）

A：AIエージェントのテストの重要な観点は、単一の応答が正しいかではなく、複数ターンの会話を通じて業務が正しく完了するかです。Agentforceは会話を起点にSalesforceの業務処理を実行するため、基本的にはマルチターン会話と業務状態を一体で検証する必要があります。

A：シングルターン（単一応答）検証では、会話の文脈が次の判断にどう影響したか、また前の業務処理結果が次の応答にどう反映されたかを確認することができません。そのため、最終的なデータ更新や業務結果の正しさを保証できないという限界があります。ほとんどの自動化ツールは実務レベルに求められるマルチターン発話の検証に対応することができません。

A：Agentforce Testing Center（テストセンター）はシングルターンの応答品質やAIのガードレール確認を目的としています。一方Provarは、実務レベルのマルチターン発話とSalesforceの業務状態を同時に保持し、E2Eでシステム全体を検証する設計です。両者は競合ではなく、役割が明確に異なります。

A：ProvarはもともとSalesforceの状態遷移を前提としたE2E業務テスト基盤として設計されています。この「前の結果を前提に次へ進む」構造が、マルチターン会話の検証と本質的に同じため、無理なくマルチターン×E2Eテストに対応できます。

A：Provarは、会話 → 業務ロジック → Flow / Apex → データ更新 → UI反映までを、1つのテストシナリオとして検証できます。したがって、AIエージェントを起点とした業務ワークフロー全体の信頼性を保証することが可能となります。