| カテゴリ |
説明 |
失敗の例 |
| トピック分類 |
エージェントはユーザーのインテントまたは目標を正しく識別できない。 |
- 特定のクエリで誤ったトピックをトリガーします。
- 「トピック外」分類が不適切にデフォルト設定されていることがよくあります。
|
| 応答品質 |
エージェントの返信におけるコンテンツ、正確性、形式に不備が見られる。 |
- 知識ベースに基づいていない情報を提供します。
- 指定されたドメインの専門知識の範囲外の応答を生成します。
- 有効なソースを参照しているにもかかわらず、誤った情報が含まれている。
- モバイルユーザーにとって特に問題となる、長すぎるメッセージを送信する。
|
| アクションの実行 |
エージェントが特定の機能またはタスクを実行しようとすると失敗します。 |
- 間違ったアクションまたは予期しないアクションを呼び出します。
- 要求されたアクションを完了するのではなく、エラーメッセージを返します。
- 人間の担当者へエスカレーションすることを不必要に提案します。
- ユーザーから必要な入力変数を適切に収集できない。
|
| ガードレールと手順 |
エージェントが定義済みのルール、制約、または会話の境界に違反します。 |
- 明示的な操作手順を無視します。
- 人間の担当者に対して予期しないまたは時期尚早なエスカレーションを試行する。
- アクションの実行中に不適切な「保留してください」メッセージを表示します。
- 「今すぐヘルプできません」や「システムエラー」などの一般的なエラーメッセージを表示します。
|
| 知識の取得 |
エージェントが知識ベースから情報を収集し、提示する際に問題が発生しています。 |
- Knowledge Base から無関係な記事を取得します。
- 応答に不要な情報を含めます。
|
| 構造化されたガイダンス |
エージェントは、複数ステップのプロセスにおいてユーザーをガイドするのに苦労します。 |
- 一般的な、根拠のないトラブルシューティングのアドバイスを提供します。
- 1 つのメッセージ内にステップが多すぎる。
- 進行中のトラブルシューティングプロセス中にコンテキストが失われます。
- 個々のトラブルシューティングステップに行き詰まる。
- すでに有効な回答を受信したにもかかわらず、質問を繰り返します。
|
##### AI エージェントをテストするためのベストプラクティス
Agentforce でエージェントをテストするときのベストプラクティスの概要を次に示します。
1. **テストデータの強化**
効果的なテストの基盤は、包括的で現実的なテストデータです。次の原則に従って、エージェントをテストするための効果的なテストデータを用意します。
- **十分なカバレッジ**: すべての重要なトピックとユーザーパーソナをカバーする十分なテストデータを目指します。
- **実際のシナリオ**: テストデータが実際のユーザー操作を正確に表していることを確認します。
- **Negative and Edge Cases** (ネガティブケースとエッジケース): ネガティブテストケース (エージェントが実行してはいけ_ないこと_) とエッジシナリオを含めて、エージェントの境界を争います。
- **Guardrails Testing** (ガードレールテスト): エージェントのガードレールが正しく機能していることを確認するために設計された特定のテストケースを追加します。
2. **テスト実行の最適化**
テストリソースを最大限に活用するには、テストの実行方法を最適化します。Agentforce エージェントをテストするときの考慮事項は次のとおりです。
- **テストケース量**: 最大 1,000 個のテストケースを使用できます。
- **同時テスト実行**: 10 時間以内に最大 10 個のテストケースを同時に実行できます。
- **リソースの管理**: テストを実行するとクレジットが消費されることに注意してください。不要なコストを回避するために、実行を開始する前にテストデータに満足していることを確認してください。
3. **レビュー結果**
テスト結果を慎重に分析し、改善すべき領域を特定します。
- **失敗の分析**: 失敗した各テストケースを個別に検査します。予想される結果と実際の結果の違いを慎重に読んで理解し、問題を特定します。
- **サンドボックス環境を使用**: テストエージェントは CRM データを変更できる。_ライブデータが意図せずに変更されないように、Sandbox やスクラッチ組織などの本番以外の環境でテストを必ず実施してください。_
4. **調整と再テスト**
テストは、エージェントが進化しながら続行される反復プロセスです。
- **継続的なテスト**: エージェントのトピックまたはアクションを変更するたびにテストを実行します。これにより、変更が検証され、品質が維持されます。
- **テスト対象範囲を**拡大: 新しいテストケースを使用してデータセットを継続的に選定および拡張し、エージェントの全体的な対象範囲と堅牢性を向上させます。
##### テスト方法
エージェントの複雑さを考えると、1 つのテスト方法では不十分です。包括的な検証戦略は、予測可能な確定的アクションから、その非確定的な会話動作の微妙なニュアンスまで、さまざまなアプローチを組み合わせて階層化する必要があります。これらのアプローチでは、エージェントのすべてのコンポーネントを体系的に評価し、堅牢性、信頼性、安全性を確保します。
1. **エージェントシミュレーターとプラン・トレーサーを使用した手動テスト**
- **目的**: これは、エージェントをテストする最初の方法であり、多くの場合最も簡単な方法です。これは、少数のサンプルの使用事例や、エージェントの動作に関する基本的な理解を得るのに最適です。
- **メカニズム**: エージェントシミュレーターは、開発者と管理者がエージェントと直接やりとりできる制御された環境を提供します。このシミュレーターでは、管理者/開発者によって提供される情報を詳細に追跡できるため、エージェントが入力をどのように処理して出力を生成するかに関するインサイトが得られます。
- **利点**:
- クイックフィードバック
- 即時の問題の特定が容易
- エージェントのロジックフローを理解するのに役立つ
2. **テストセンターまたはAFDXテストスイートを使用したテストの自動化**
- **目的**: 手動テストで機能のベースラインが確立されると、自動化テストは拡張性、徹底性、および回帰テストにとって不可欠になります。
- **メカニズム**: テストセンターやAFDXテストスイートなどのツールを使用すると、定義済みのサンプル使用事例に基づいて自動テストを生成できます。これらのテストは、エージェントの指示とサブエージェント分類がより広範なシナリオで正しく機能しているかどうかを検証するように設計されています。
- **利点**:
- 一貫したパフォーマンスを確保します
- 微妙なバグを識別します
- 継続的インテグレーション/継続的リリース (CI/CD) パイプラインをサポート
- 包括的なカバレッジを提供します
3. **Apex とフローを使用したアクション固有の単体テスト**
- **目的**: エージェントアクション内にカプセル化された確定的ビジネスロジックを検証します。エージェントの全体的な動作は確定的ではありませんが、多くの場合、エージェントのアクションには、標準の開発方法が適用されるフローや Apex などのテクノロジーが使用されます。
- **メカニズム**: 開発者は、エージェントアクションが呼び出す特定のフローまたは Apex クラスの単体テストを作成します。これらのテストでは、エージェントのロジックの個々のコンポーネントを検証し、特定の入力セットに対して期待される出力が生成されることを確認します。
- **利点**:
- これらの単体テストを DevOps パイプラインに統合することで、自動化されたセーフティネットが提供されます。
- アクションのロジックの変更または機能強化によって回帰が発生しないことを確認する
- 本番にリリースする前にエージェントの機能の信頼性を確保します
4. **敵対テスト - セキュリティとガードレールの適用**:
- **目的**: さまざまな種類のエージェントを構築するには、セキュリティを重視し、定義されたパラメーターとガードレールの範囲内で確実に操作する必要があります。これは、意図しないアクション、データ漏洩、誤用を防止するために重要です。したがって、敵対的テストの目的は、安全メカニズムを回避するように設計された入力でエージェントに意図的に挑戦し、その堅牢性と操作に対する耐性をテストすることで、これらの潜在的な脆弱性を事前に特定し、修正することです。
- **メカニズム**: 敵対的テストは、エージェントの意図する動作の限界を押し広げる、困難、あいまい、または悪意のある入力を作成することで実装されます。エージェントビルダーの「ガードレール」機能のようなプラットフォームツールは、指示の遵守に関するインサイトを提供しますが、開発者は、制御された環境でエージェントを積極的に失敗させるカスタム敵対的テストケースを作成する必要もあります。
- **メリット**: このアプローチにより、導入前にセキュリティとコンプライアンスのリスクを計画的に軽減できます。潜在的な障害点を特定することで、敵対的テストはエージェントの信頼性を高め、ユーザーとやりとりするときにエージェントが安全かつ意図したとおりに動作することを確認します。
##### スクラッチ組織とサンドボックスでの反復テスト
「内部ループ」は、エージェントが概念から検証済みコンポーネントに移行してリリースの準備が整う重要な反復サイクルです。この継続的な調整プロセスには、開発とテストの両方の環境が必要です。Agentforceは、共有環境に影響を与えない迅速なプロトタイピングのための一時的な隔離環境であるスクラッチ組織と、本番環境へのパスを促進する現実的なデータを使用して徹底的なテストを可能にするサンドボックスを通じて、このフレームワークを提供します。
1. **スクラッチ組織での開発**: 初期開発はスクラッチ組織で実施する必要があります。ここでは、エージェントビルダーや AFDX など、開発環境内で提供されるツールを十分に活用しています。スクラッチ組織は、単体テストの実行、コード分析の実行、上位環境への変更の促進を行うための CI/CD パイプラインの有力な候補です。
2. **Deployment to Sandbox for Real Data Testing** (リアルデータテスト用 Sandbox へのリリース): エージェントのコア機能がスクラッチ組織で開発されたら、Sandbox にリリースします。Sandbox は、より現実的なテスト環境を提供する本番環境のコピーです。
- **実際のデータ**とモックデータの比較: 一部の開発者は初期テストのためにスクラッチ組織のデータをモックすることがありますが、Sandbox にリリースすると「実際のデータ」を使用してテストできます。これは、実際の顧客とのやりとりを密接に反映するシナリオでエージェントのパフォーマンスを評価するために重要です。サンドボックスでより多くの代表的なデータを使用すると、開発と調整のプロセスが大幅に加速されます。
- **Full or Partial Sandbox** for Core CRM Data (CRM コアデータの完全または部分的な Sandbox): データ量と特定のテスト要件に応じて、完全または部分的な Sandbox を使用できます。
- **Full Sandbox**: すべてのメタデータとデータを含む本番環境の完全なレプリカを提供します。大規模なデータセットを使用する広範なテストとパフォーマンスチューニングに最適です。
- **Partial Sandbox**: 本番データのサブセットが含まれます。多くの場合、完全なデータセットが厳密に必要ではない特定の機能をテストするために十分です。
- **Knowledge and RAG Management**:エージェントが知識ベースまたはRAG(Retrieval-Augmented Generation)モデルを使用している場合、すべての関連コンテンツをSandboxに取り込んでインデックスを再作成します。これにより、エージェントはテスト中に現在の情報を使用し、コンテンツを正確に取得して統合できます。
#### フェーズ4：展開とリリース
Agentforce はメタデータを使用してエージェントを定義するため、変更セットや AFDX などの標準の Salesforce 手順を使用してエージェントを導入できます。このフェーズでは、エージェントのバージョン管理や個別の有効化ステップなどの重要な機能による安全で制御されたロールアウトが強調されます。これにより、システムの安定性が確保され、問題からの迅速な復旧が可能になります。
次の手順に従って、新しいエージェントをリリースします。
1. **変更セット/メタデータ API または AFDX** を使用した導入: エージェントの導入プロセスでは、標準の Salesforce 手順を使用して、エージェントをメタデータとして扱います。これは、Salesforce の開発とリリースに慣れているすべてのユーザーにとって馴染みのあるプロセスです。変更セットまたは AFDX を使用すると、Sandbox から本番環境など、環境間でエージェント設定を移行するための体系的で一貫したアプローチが実現します。この方法により、システムの安定性と信頼性を維持するために重要なバージョン管理と適切な変更管理が容易になります。
2. **Activate Agents Post-Deployment** (リリース後のエージェントの有効化): リリースの成功後、システム管理者はエージェントを積極的に「有効化」する必要があります。リリースでは、エージェントのコードとメタデータが対象環境に配置されます。有効化は、エージェントを動作可能にして使用可能にするステップです。この分離により、エージェントが稼働し、エンドユーザーや他のシステムコンポーネントとやり取りする前にロールアウトとテストを制御できます。
3. **Use Versioning for Safe Agent Management** (安全なエージェント管理のためのバージョン管理の使用): エージェントバージョン管理は、エージェントの開発とメンテナンスの安全性と柔軟性を大幅に向上させる重要な機能です。
1. **新しいバージョンの作成、テスト**、公開: 変更や機能強化が必要な場合に、エージェントの新しいバージョンを作成することをお勧めします。その後、この新しいバージョンは、有効化されたライブエージェントに影響を与えることなく Sandbox 環境で徹底的にテストできます。新しいバージョンが検証され、準備が整っているとみなされると、公開して有効化し、以前の運用バージョンを置き換えることができます。この反復プロセスにより、中断を最小限に抑えながら、継続的な改善と革新が可能になります。
2. **以前のバージョン**へのロールバック: バージョン管理の主な利点は、新しくリリースされたエージェントや有効化されたエージェントで問題が発生した場合に、以前の安定したバージョンにすばやく簡単に戻すことができることです。エージェントの不適切な動作や予期しないエラーの発生など、何らかの問題が発生した場合、管理者は既知の正常な最後のバージョンにロールバックして有効化できます。この機能により、迅速なリカバリとダウンタイムの最小化が可能になり、ビジネス継続性とユーザー満足度が確保されます。
#### フェーズ 5: 監視と調整
##### エージェントの監視
Agentforceセッション トレーシングは、Data 360上に構築されたオープンで拡張可能なモデルで、エンドツーエンドのエージェントのやり取りを取得します。Agentforce セッション追跡では、さまざまなソースからデータが取り込まれ(まず推論エンジンログから開始)、セッション ID の下にすべてが結合されます。
セッショントレーシングデータモデル (STDM) では、エージェントセッション中に何が発生したかに関する詳細情報が次のように提供されます。
- ターンバイターンインタラクション
- 推論エンジンの実行
- アクション、プロンプト、ゲートウェイの入力/出力
- エラーメッセージ
- 最終回答
STDM は、開発者を支援する重要なツールです。
- 構築時にエージェントの設定の問題をデバッグします。
- バッチテスト中に特定のテストケースが失敗した理由を確認します。
- エージェントが一連のユーザー質問を処理できない理由や、トピック外になる理由を説明します。
開発者は、このセッション追跡データを使用して、エージェントのイベント、インシデント、および行動パターンを観察、監視、調査、トラブルシューティングする必要があります。
STDM は、エージェントの行動の詳細なログを保存するデータレークオブジェクト (DLO) とデータモデルオブジェクト (DMO) で構成されます。推論エンジンによって行われた各 LLM コールに関するメタデータは、フィードバックまたはガードレール評価指標と結合できます。データは Data 360 の DLO にストリームされ、該当する DMO にマッピングされます。
開発者は、STDM に対してクエリとレポートを実行することで、このデータにアクセスし、インサイトを取得できます。STDM のコンポーネントを次に示します。
**Agentforce セッション トレーシング データ モデル ERD**
この章では、Agentforce が 1 つの統合プラットフォーム**内で** ADLC のすべてのフェーズをサポートする方法について説明します
#### フェーズ 1: アイデアとデザイン
##### アイデア
アイデア出しフェーズは、エージェントの初期ビジョンと要件が策定される ADLC の基礎フェーズです。これには、問題の理解、潜在的なソリューションの特定、エージェントのコア機能の概要説明について深く掘り下げます。
エージェントのアイデア出しプロセスを開始するには、その主要な属性を定義します。
1. **目的/目標**: エージェントの主な目的を明確に定義します。どのような問題を解決するために設計されているか、またはどのようなタスクを達成しようとしているか?エージェントは誰にサービスを提供すべきか?これは、開発プロセス全体の指針となる簡潔で測定可能なステートメントである必要があります。
2. **人格**: エージェントの詳細な人格を作成します。これには、ID、コミュニケーションスタイル、ユーザーや他のシステムとのやり取りで果たす役割の定義が含まれます。口調、フォーマリティのレベル、および意図したコンテキストで効果を発揮する具体的な特性を考慮します。
3. **パターン**: 関連するエージェントパターンと実装戦略を特定してリンクします。これには、エージェントの構造と動作を知らせることができるアーキテクチャ設計またはベストプラクティスが含まれます。『[Agentic Patterns & Implementation on Salesforce Agentforce: A Technical Whitepaper](/docs/architect/ja-jp/fundamentals/guide/agentic-patterns)』(Salesforce Agentforce でのエージェントのパターンと実装: テクニカルホワイトペーパー) は、Salesforce Platform と Agentforce での効果的なエージェント設計に関するインサイトを提供する、このステップの貴重なリソースです。
##### 設計
設計フェーズでは、アイデア出しで生み出された概念を、エージェント構築のための詳細な設計図に落とし込みます。これには、エージェントのアーキテクチャ、ユーザーフロー、インタラクションモデル、技術仕様 (トピック、ツール、ガードレールなど) の定義が含まれます。
設計フェーズでは、エージェントの構築のための詳細なブループリントを作成します。このブループリントには次の項目が含まれます。
- **エージェント設計**: コンポーネント、モジュール、および相互作用方法を含むエージェントの内部構造の概要を説明します。これには、Knowledgeベース、エージェントの動作を制御するための設定とロジック、自然言語処理 (NLP) コンポーネント、他のシステムとのインテグレーションポイントの定義が含まれる場合があります。
- **ユーザーフロー/インタラクション設計**: 完全なユーザージャーニーとエージェントのインタラクションを対応付けます。会話フロー、ディシジョンツリー、エラー処理、フィードバックメカニズムを定義して、直感的で効果的な環境を作成します。
- **技術仕様**: パフォーマンス評価指標、拡張性に関する考慮事項、セキュリティプロトコル、インテグレーション仕様など、エージェントの機能以外の技術的な要件を文書化します。
- **プロトタイピングおよびモックアップ**: エージェントのインターフェースとインタラクションの視覚表現または対話型のプロトタイプを作成します。これにより、早期のテストとフィードバックが可能になり、本格的な開発を開始する前に設計を調整できます。
- **データ**: エージェントが必要とするデータのタイプとソースを決定するときに、エージェントがアクセスする必要があるデータセット、API、データベース、およびリポジトリを特定します。Agentforceでは、コンテキストとして提供されるデータ、構造化されたデータと構造化されていないデータ、リアルタイムデータとバッチデータのどちらであるかに焦点を絞ります。Agentforceプラットフォームは、Data 360との緊密な統合に基づいて構築されており、Salesforce CRMやその他のソースからの構造化データと非構造化データの両方を使用できます。非構造化コンテンツはネイティブにチャンク化してインデックス付けし、RAG で使用できます。MuleSoft では、外部システムに接続できます。
- **ツール**: エージェントが実行する必要があるアクションを特定します。Agentforce アクションを使用して、ビジネス目標を達成するツールを公開します。これらのアクションは、プロンプトビルダーを介したプロンプト、MuleSoft、Apex、フロー、OpenAPI仕様のAPIなどの既存のSalesforceアセットを活用します。呼び出し可能なアクションはすべて Agentforce に統合してエージェントが使用でき、使い慣れたすべての Salesforce 開発ツールを Agentforce アクションとしてすぐに使用できます。
- **エージェントの入力データ**: 従来の SDLC では、入力は正確に指定されます。ADLC では、入力は多くの場合、自然で非決定的なフリーフォームの発言です。適切な回答が得られると期待される発言の代表的なコーパスを収集します。
#### フェーズ 2: 開発
開発フェーズでは、アイデアと設計フェーズで決定された定義済みのエージェントの目的、機能、および業務範囲を新しい Agentforce Agent に変換することに重点を置いています。
開発者がエージェントを作成できるように、Agentforce には **Agent Builder** と **Agentforce Developer Experience（AFDX）の両方が用意されています。**これらの基盤ツールは、エージェントを構築および設定するための主要な環境として機能します。
- **Agent Builder** では、エージェントのコア機能を定義するための UI 環境が提供されます。
- **AFDXは**、カスタマイズや他のシステムとの統合のためのインターフェースを提供します。
エージェントの開発と構築には、エージェントビルダーまたは AFDX を使用して実行できる次の手順が含まれます。
1. **人格の定義**: エージェント設計の重要な側面は、個別の人格を確立することです。これには、次の設定が含まれます。
- **エージェントの説明**: エージェントの役割、目的、および処理するように設計された特定のカスタマーサービス ToDo の詳細な説明。
- **トーン**: エージェントのコミュニケーションスタイル、共感のレベル、および従う必要がある特定のブランドガイドライン。
2. **エージェントトピックおよびアクション**の定義: エージェントを高度化し、さまざまなタスクを処理できるようにするには、エージェントの機能を個別のトピックと対応するアクションに分割することが不可欠です。
- **トピック**: 各トピックは、独自の手順とツールのセットを備えた独自の専門エージェントとして概念化できます。
- **モジュラーアーキテクチャ。**トピックへのモジュラーアプローチにより、組織と拡張性が向上します。複数のトピックを定義することで、エージェントはより広範な複雑なシナリオを処理できます。たとえば、エージェントには「注文管理」、「よくある質問 (FAQ)」、「テクニカルサポート」、「請求に関する問い合わせ」という個別のトピックがあります。
- **トピックの手順 (**ガードレール): 各トピックには、ガードレールとして機能する特定の手順が付属し、エージェントがそのトピック内で議論または実行できる範囲を定義します。これらの手順により、エージェントがトピックから外れたり、無関係な情報を提供したりすることがなくなります。また、回答の一貫性と正確性も維持できます。
- **アクション**: トピックには、エージェントが実行できるアクションを表す「ツール」も用意されています。これらのツールは次のようなものです：
- **情報アクション**: Knowledge Base または外部システムからデータを取得してクエリに回答します。
- **トランザクションアクション**: 注文の実行、顧客レコードの更新、返金プロセスの開始など、ユーザーに代わってアクションを実行します。これらのアクションは、多くの場合、他のシステム (CRM、ERP など) と統合されます。
#### フェーズ 3: テストと検証
AI エージェントのパフォーマンスと信頼性を評価する場合、テスト担当者は多くの場合、ユーザーエクスペリエンスを低下させる可能性のあるさまざまな課題に直面します。これらの問題は、ユーザーインテントの誤った解釈から ToDo の適切な実行の失敗まで多岐にわたります。
##### 一般的なエージェントの失敗のシナリオ
堅牢なエージェントを構築するには、その失敗方法と原因を理解する必要があります。次の表は、欠陥のある推論から不十分な Knowledge 取得に至るまで、エージェントのライフサイクル中に発生する一般的な問題を分類したものです。これは、エージェントが機能するだけでなく、エンドユーザーにとって信頼性が高く直感的であることを確認するために、開発時の戦略ガイドやテスト時のチェックリストとして使用します。次の失敗シナリオは、テストケースを定義するのに役立ちます。
##### 発言分析
発言分析では、Agentforce（デフォルト）ユーザーがエージェントをどのように使用しているか、何を要求しているか、およびエージェントがこれらの要求を処理できたかどうかが示されます。これらのカスタマイズ可能なレポートは、エージェントがより効果的かつ正確に応答できるようにトピックとアクションを調整するのに役立ちます。
##### Agentforce Python SDK: Data 360 インテグレーションを使用した監視
Agent SDK 実装では、Data 360 Python コネクタを使用した高度な監視と分析を使用して、Salesforce Data 360 への接続を確立し、エージェントのパフォーマンス評価指標を照会して、包括的な監視ダッシュボードを作成します。
応答時間、成功率、ユーザー満足度、コスト総計値を追跡し、エージェントを最適化するためのアクション可能なインサイトを提供します。
```py
# Data 360 Python Connector Integration
from salesforce_cdp_connector import SalesforceCDPConnector
# Initialize Data 360 Connector
cdp_connector = SalesforceCDPConnector(
client_id='your_client_id',
client_secret='your_client_secret',
username='your_username@example.com',
password='your_password'
)
# Query agent performance data
performance_data = cdp_connector.query("""
SELECT timestamp, response_time_ms, success_rate, user_satisfaction
FROM AgentPerformanceMetrics
WHERE agent_id = 'Coral_Cloud_Resorts_Resort_Manager'
""")
# Create monitoring dashboard
def create_monitoring_dashboard(performance_data):
fig = go.Figure()
fig.add_trace(go.Scatter(
x=performance_data['timestamp'],
y=performance_data['response_time_ms'],
mode='lines+markers'
))
return fig
```
##### Agentforce DX: エージェントの監視
この実装では、CLI ベースのエージェント管理で標準の AFDX コマンドを使用し、プラットフォームの変更に関する最新情報をエージェントに提供し、継続的な改善のためにユーザーのフィードバックを取り入れます。
```zsh
# List all agents and their status
sf agent list --target-org "production-org"
# Get detailed agent information
sf agent get \
--api-name "Resort_Manager" --target-org "production-org"
# Activate agent if needed
sf agent activate --api-name "Resort_Manager" --target-org "production-org"
# Query agent performance data
sf data query \
--query "SELECT Id, Name, Status, LastModifiedDate FROM BotDefinition WHERE DeveloperName = 'Resort_Manager'" \
--target-org "production-org"
```
```python
# AgentforceDX Dashboard Creation (Similar to Agent SDK)
import pandas as pd
import plotly.graph_objects as go
from salesforce_cdp_connector import SalesforceCDPConnector
# Initialize Data 360 Connector for AgentforceDX
cdp_connector = SalesforceCDPConnector(
client_id='your_client_id',
client_secret='your_client_secret',
username='your_username@example.com',
password='your_password'
)
# Query agent performance data from Data 360
performance_data = cdp_connector.query("""
SELECT timestamp, agent_id, response_time_ms, success_rate, user_satisfaction
FROM AgentPerformanceMetrics
WHERE agent_id = 'Resort_Manager'
AND timestamp >= CURRENT_DATE - 30
ORDER BY timestamp DESC
""")
```
Agent SDKとAFDXを使用したADLCの実装については、[ここ](https://github.com/akshatasawant9699/ADLC_Whitepaper)のGitHubリポジトリを参照してください。
## ベストプラクティス
エージェント開発ライフサイクルをマスターするには、効率性、信頼性、戦略的な連携を保証する一連の基本原則に準拠する必要があります。次のガイドラインは、ADLC の各フェーズから得られた主要な教訓をアーキテクトと開発者向けの戦略的フレームワークに統合したものです。
**1\. 計画とアイデア出し**
この初期フェーズでは、エージェントの目的をビジネス目標に合わせ、強固な基盤の上に構築することに重点を置いています。
- **ビジネスへの影響を重視する**: まず、潜在的なユースケースを戦略的なビジネス目標に直接対応付けます。優先度マトリックスを使用して潜在的な影響を評価し、明確な KPI を含む 1 つの焦点を絞った使用事例から開始します。
- **早期にステークホルダーを巻き込む**: 課題となる問題点に関する洞察を収集し、全体の方向性を合わせます。
- **データインサイトの活用**: エージェントは、そのデータによってのみ機能します。Data 360 を使用して、使用可能な構造化データと非構造化データを探索し、エージェントのコンテキストと機能を確認します。既存のレポートとダッシュボードを確認して、使用事例の選択に役立つ可能性がある現在のトレンドを特定します。
- **Use Frameworks for Ideation** (アイデア出しのフレームワークを使用): 構造化されたアイデア出し方法を適用して、設計思想や SWOT 分析などの潜在的なアプリケーションをブレインストーミングし、調整します。
**2\. エージェントの構築**
このフェーズでは、パフォーマンスが高く効率的なエージェントを構築するためのベストプラクティスについて説明します。
- **Avoid Too Many Topics** (トピックが多すぎます): トピック数を制限して、エージェントを困惑させる類似トピックや重複トピックを作成するリスクを軽減します。
- **Keep Instructions and Prompts Concise** (指示とプロンプトを簡潔に): 直接的でシンプルな表現を使用し、エージェントを効果的に誘導するための発言例を提供します。
- **変数と確定的アクションの活用**: これらのツールを使用して、エージェントの動作を導き、より予測可能な結果を得るためにパフォーマンスを最適化します。
- **Keep Action Outputs Small and Concise** (アクション出力を小さく簡潔に): エージェントの回答が簡潔で的確であることを確認します。出力が長いほど、使用するコンテキストが多くなり、生成が遅くなります。
- **Optimize Actions for Speed** (処理速度の最適化): 必要な最小限のデータを返すようにフローと Apex クラスを設計します。可能な場合は事前処理することで、応答を生成するために必要なアクションを減らすことを目指します。
- **明確な範囲**の定義: 範囲外の質問に対してエージェントが RAG (Retrieval-Augmented Generation) をコールしないように、アクションの適切な説明、手順、範囲を記述します。
- **Use Hybrid Search Sparingly** (ハイブリッド検索を慎重に使用): レイテンシーに悪影響を及ぼす可能性があるため、ハイブリッド検索はどうしても必要な場合にのみ使用します。
**3\. テスト、監視、チューニング**
この反復フェーズは、エージェントの精度とパフォーマンスを向上させるために重要です。
- **テストフローの確立**: 一貫したテストサイクルに従います。
1. **Run Batch Test** (バッチテストを実行): 包括的なテストセットを実行します。
2. **View Scores/Errors** (スコア/エラーの表示): パフォーマンス評価指標を分析し、障害を特定します。
3. **Inspect Failures** (失敗を検査): 各失敗行を調べて、不一致を理解します。
4. **Update Agent** (エージェントの更新): エージェントまたはその評価データに必要な調整を行います。
- **セッション追跡情報**の確認:セッション追跡データ モデルと Agentforce Interaction Explorer を使用して、問題または予期しない動作が特定されたときに根本原因分析を実行します。情報に基づいてエージェントを調整し、エージェントの反復を続行します。
## 結論
_エージェント開発ライフサイクル_は、インテリジェントな自律システムの時代に合わせて設計された従来のソフトウェア開発原則の重要な進化を表します。
- **置換ではなく**進化: エージェント開発ライフサイクルは、従来のアプリケーションライフサイクル管理を置換することなく拡張および強化します。
- **Data as a First-Class Citizen** (一流の市民としてのデータ): エージェントの開発において、データははるかに動的で中心的な役割を果たします。
- **特殊なツールとスキル**: データ サイエンス、MLエンジニアリング、エージェント開発にわたる新しいツールとより広範な特殊なスキル セットが必要です。
- **継続的学習**: エージェントの開発により、システム自体の継続的_な学習_と_適応_が追加されます。
- **将来の影響**:エージェント型AIは、複雑なIT運用とソフトウェア開発ワークフローの自動化と最適化をさらに推進します。