Salesforceの自律型AIエージェント「Agentforce」は、単なるチャットボットの枠を超え、自ら思考し、判断し、アクションを実行する「Reasoning（推論）」の力を備えています。カスタマーサービスや営業活動に革命をもたらす可能性を秘めている一方で、その導入の第一歩であるPoC（概念実証）において、多くのプロジェクトチームが「AI特有の不確実性」という高い壁にぶつかっています。
この「AIが自律的に判断して動く」という特性は、裏を返せば「これまでのテスト手法が全く通用しない」ことを意味します。前回のブログ「AgentforceのPoCはなぜ失敗するのか」では、どのようにPoCを進めるべきかの基礎知識を、分かりやすく解説しました。
本記事では、AIテストの“非決定性”などを踏まえ、開発・テスト担当者が直面する技術的課題を整理し、Salesforce標準の「Agentforce Testing Center（テストセンター）」と、Salesforceネイティブなテスト自動化ツール「Provar」をどのように戦略的に使い分け、AgentforceのPoCを成功から実運用へとつなげるべきかを深堀します。
Agentforce PoCの最大の壁：テストの「非決定性」
従来のシステム開発において、テストとは「決定論的（Deterministic）」なものでした。つまり、「入力Aに対しては、必ず期待値Bが返る」という前提に基づき、その一致を確認する作業です。しかし、Agentforceの中核をなすAtlas Reasoning Engine（アトラス推論エンジン）は、大規模言語モデル（LLM）の確率的な性質を内包しています。
テスト担当者が苦慮する3つの技術的課題
「正解」の動的な変化（Semantic Matchingの難しさ）：AIの応答は、モデルの「温度感（Temperature）」やプロンプトの微細なニュアンスにより、毎回表現が変化します。単なる文字列一致（Exact Match）のテストは無意味となり、回答の意味がビジネスロジック的に正しいかという「セマンティック（Semantic：意味的）な妥当性」をどう評価するかが問われます。
ビジネスロジックの連鎖と副作用の検証：Agentforceは、ユーザーの意図を汲み取った後、Flowの起動、Apexの実行、あるいは外部APIの呼び出しを自律的に判断します。AIが「見積もりを作成しました」と正しく発話しても、背後のレコードが「正しい項目値」で、「正しい共有権限」のもとで更新されたかという、システムの状態変化までをも検証対象にする必要があります。
マルチターン対話における「コンテキストウィンドウ」の管理：多くのテストツールにおいて、一問一答（シングルターン）ではなく、5往復、10往復と続く対話の中で、AIが過去の文脈を正しく保持しているかを検証するのは極めて困難です。たとえば特定のターンで入力された「条件A」が、最終ターンの「アクションB」に正しく反映されているか、あるいは途中で文脈が霧散していないかという、持続的な状態維持の検証が求められます。
テストセンターの役割と、明らかにすべき限界
Salesforceが標準提供するAgentforce Testing Center（テストセンター）は、プロンプトエンジニアリングの初期段階において優れたツールです。
テストセンターの技術的な強み
テストセンターの主眼は、「意図（Intent）の識別精度」と「アクションの選択精度」の評価にあります。
トピック割り当ての網羅性：大量の想定質問（発話）をインポートし、AIが定義されたトピックを正しく選択できるかを「F1スコア」などの指標で定量化できます。
プロンプトの磨き込み：プロンプトの変更が、回答の正確性や「グラウンディング（根拠資料との合致度）」にどう影響したかを、AIによる自動評価を用いて高速にサイクルを回せます。
実運用を見据えたときの技術的限界
しかし、PoCを「実務レベル」に引き上げる段階では、以下の点がボトルネックとなります。
ステートレスな検証：テストセンターの実行は、多くの場合「シミュレーション」に留まります。テスト実行によってCRMデータが実際にどう書き換わったか、その後のビジネスプロセス（承認フローなど）が正常にキックされたかという「実環境での持続的な状態変化」までは追いきれません。
複雑なロール・権限の切り替えテスト：ログインユーザーのプロファイルや権限セットによって、AIがアクセスできるデータやアクションは動的に変化します。異なる権限を持つ複数のユーザーになり代わって、一連の業務フローを自動実行する機能は備わっていません。
外部システムとのエンドツーエンド（E2E）検証：Mulesoftを介したERP連携や外部DBの参照を伴う場合、Salesforceの外側で起きていることの整合性までは保証できません。
Provarがもたらす「運用のための信頼性保証」
ここで、PoCを単なる「技術の試用」から「業務の確信」へと変えるのが、Salesforce専用に設計されたテスト自動化ツールProvarです。Provarは、テストセンターが得意とする「モデル評価」のバトンを受け取り、実務に即したいわば「業務品質の担保と完遂」を担います。
「マルチターン」の会話を業務シナリオとして完全自動化
Provarの最大の特徴は、実際のブラウザ操作やAPIコールを組み合わせ、「人間のような対話シナリオ」をスクリプト化できる点です。
たとえばステップ1で「A社との商談状況を教えて」と質問。次にAIの応答を解析し、特定のキーワードが含まれていることを確認。ステップ2では「その商談のフェーズを『最終交渉』に変更して」と追加指示まで、この一連の流れを1つのテストケースとして保持し、何度でも再現可能です。
メタデータ駆動による圧倒的なメンテナンス性
SalesforceのUI（Lightning Web Components）は、Shadow DOMなどの複雑な構造を持ち、一般的なテストツールでは要素特定が非常に困難で「壊れやすい」という弱点があります。
メタデータ認識：ProvarはSalesforceのメタデータを直接読み取るため、項目名やページレイアウトが変更されても、テストコードを書き換える必要がありません。設定変更が激しいAgentforceの開発フェーズにおいて、これは保守工数を劇的に削減する決定的な要因となります。
SOQLを用いた「裏側の真実」の検証
ProvarはUI操作の裏側でSOQL（Salesforce Object Query Language）を直接発行できます。AIが「更新完了」と答えた直後、データベースを直接参照し、項目値、レコードタイプ、所有者、カスタム項目が定義通りに書き換わったかをミリ秒単位で突き合わせます。
PoCから運用テストへの進め方：3ステップの推奨ロードマップ
PoCを成功させ、スムーズに本番運用へ移行するためには、ツールの特性を活かした段階的なアプローチが鍵となります。
ステップ1：テストセンターで「AIを鍛える」（初期PoC）
まずはテストセンターを使い、AIエージェントの基本性能を検証します。
目標：意図の識別率（Topic分類）を90%以上に引き上げます。
作業：大量のCSVデータによるシングルターン検証を繰り返し、プロンプトの指示（Instructions）を最適化します。
ステップ2：Provarで足元を固める（詳細PoC〜ベータ）
主要な業務シナリオをProvarで「エンドツーエンド」に自動化します。
目標：複数ターンの対話が完了し、Salesforceデータが正しく更新されることを証明します。
作業：正常系だけでなく、「不適切な質問へのガードレール機能」や「権限外データへのアクセス拒否」など、リスクベースのテストを組み込みます。
ステップ3：CI/CD環境での継続的監視（運用〜本番）
ProvarをGitHub ActionsやAzure DevOpsなどのCI/CDパイプラインに接続します。
目標: SalesforceのリリースやAIモデルのアップデートによる「品質のデグレード」を防止します。
作業: サンドボックスでのリリース検証時に、全自動でマルチターンの回帰テストを実行し、確信を持って本番リリースを行える体制を構築します。
PoCの段階からProvarによる自動化シナリオを構築しておくことは、単なる検証作業の効率化ではありません。それは、「将来にわたる回帰テストの資産」を構築することそのものです。一度作成したマルチターンのシナリオは、モデルが更新されたり、あるいは新しいビジネスルールが追加された際に、速やかに「業務への影響」を検知するセーフティネットとして継続的に機能します。
まとめ：確信を持ってAgentforceをリリースするために
Agentforceの導入は、単なる新しいテクノロジーの採用ではありません。それは、ビジネスプロセスの中に「自律的に判断し、行動するパートナー」を招き入れるという、企業にとって極めて大きな構造的変化です。この変革を成功させるために、テスト担当者が果たすべき役割は、これまでの「バグ探し」から、「AIと実務が調和し、安定して機能し続けることの証明」へと進化しています。
しかしながら、Agentforceの品質保証は、単一のツールだけで完結するほど単純ではありません。「AIが何を会話したか」に一喜一憂するのではなく、「業務が完遂され、データが正しく残っているか」という揺るぎない事実をProvarで証明し続ける。そして、テストセンターでAIの品質を最大限に引き出す。この“併用”の戦略こそが、不確実性の高いAIプロジェクトにおいて、確信を持ってリリースできる唯一の道です。
このように、ProvarはAIエージェントが実行する「業務の完遂」を支える基盤です。Provarによるメタデータ駆動のE2Eテストは、AIの「揺らぎ」という不確実性の中に、揺るぎない「業務の正解」という評価軸を打ち立てます。
なお、Provar製品を熟知するアドックインターナショナルは、Salesforse/AgentforceのPoCから運用を成功に導く技術サービスを提供しています。詳しくは「お問合せ（CONTACT）」 までご相談ください。
よくある質問（FAQ）
Q1：Agentforceのテストで「非決定性」にどう対処すればよいですか？
A：AIの「回答テキスト」ではなく、最終的な「アクションの結果（データの状態）」を成功基準に据えることが重要です。AIの表現は揺らぎますが、Salesforceのレコードが正しく更新されたか、適切なフローが起動したかという結果は不変です。ProvarでDBレベルのアサーション（検証）を行うことで、AIの揺らぎに左右されない安定したテストが可能になります。
Q2：Agentforce Testing CenterがあればProvarは不要になりますか？
A：いいえ。検証の「深さ」と「範囲」が異なります。テストセンターは「AIが何を考えているか（推論）」の検証に優れています。一方、Provarは「AIがシステムをどう動かしたか（実行と結果）」の検証に特化しています。実業務を安全に回すためには、PoCから推論の正しさと実行結果の正しさの両方を担保する必要があるため、併用とProvarの初期利用が最も効果的です。
Q3：マルチターン対話のテストケース作成は工数がかかりませんか？
A：Provarのメタデータ駆動型アプローチにより、手動コーディングを大幅に削減できます。ProvarはSalesforceの画面要素を自動認識するため、ドラッグ＆ドロップに近い操作で対話フローを定義できます。一度作成したシナリオは、データ駆動テスト（Excel等からのパラメータ入力）によって、何百パターンものバリエーションに容易に拡張可能です。
Q4：AIモデル（LLM）がアップデートされた際の回帰テストはどうすべきですか？
A：CI/CDに組み込まれたProvarのテストセットを全自動で再実行することを推奨します。モデルの更新により、以前は成功していた複雑な文脈維持ができなくなるケースがあります。Provarで主要な業務シナリオを自動化しておけば、モデル更新のたびに「全自動で一貫性チェック」を行えるため、運用の手間を最小限に抑えつつ品質を維持できます。
Q5：外部システム（ERP等）との連携もPoCでテストすべきですか？
A：はい、本番で最も不具合が起きやすい箇所であるため、PoC段階での検証を強く推奨します。Agentforceが外部データを参照して判断を下す場合、その連携のタイムラグやデータの形式不整合がエラーの主因となります。Provarのエンドツーエンド検証機能を使えば、Salesforceの外側を含めたデータ整合性をPoCの段階で確認でき、導入後のリスクを劇的に低減できます。