詳細情報:
移行の実装
ツールを選択し、エージェントスクリプト改善計画を設定したら、移行します。段階的な反復アプローチを使用して、移行の管理、テスト、トラブルシューティングを容易にします。テストツール、サードパーティ AI ツール、およびチームを効果的に活用するためのヒントを紹介します。
ジャンプ先...
フェーズでのエージェントの移行
移行を段階的に進めて、後で安定させてトラブルシューティングしやすくします。
- エージェントをそのまま移行します。
すべてのサブエージェント、手順、およびアクションのベースライン移行から開始します。新しいビルダーで従来のエージェント設計を立ち上げ、エンドツーエンドで機能することを確認します。
- 回帰を特定して修正します。
回帰を特定するには、エージェントのエージェントスクリプト構文を確認し、ビルダーでエラーがないかどうかを確認します。次に、以前に実行したのと同じ手動テストと一括テストを実行して、エージェントの移行前のベースラインを確立します。
- 従来のビルダーのエージェントで機能していて、新しいビルダーでは機能していないものは、すべて後退です。
- それ以外は改善または強化です。
他の変更を行う前に不具合を修正し、問題を切り分けてトラブルシューティングできるようにします。ベースラインの移行後に何らかの問題が発生した場合、それは移行の結果であり、変更の結果ではありません。
ヒント Agentforce を使用してエージェントをアップグレードすると、検証エラーなどの問題が発生しにくくなります。ただし、推論が変更されると、エージェントのパフォーマンスに影響する可能性があります。従来のビルダーと新しいビルダーではデータモデルと基盤となる推論エンジンが異なるため、エージェントをエンドツーエンドでテストすることが重要です。 - エージェントスクリプトを使用してエージェントを強化し、改善します。
新しいビルダーでベースラインエージェントが安定したら、エージェントの信頼性とパフォーマンスを改善するための変更を開始できます。この時点で、エージェントスクリプトの機能を利用して、従来のビルダーでうまく機能しなかった問題を修正し、戦略的に決定論を導入して予測可能性と一貫性を追加できます。
- エージェントを展開します。
エージェントの移行中のある時点で、エージェントウィッシュリストのサイレンが鳴り、エージェントの機能を新しいサブエージェント、使用事例、インテグレーションに拡張することを検討できます。早く拡張したいという衝動に抗う。新機能を導入する前に、エージェントの移行に集中します。特にエージェントが新しいビルダーで安定するまでに一度に行う作業を多すぎると、エージェントのアーキテクチャが汚れ、問題を追跡、分離、トラブルシューティングするのが困難になるリスクがあります。
小さなバッチでの変更と各バッチ後のテスト
回帰を修正する場合でも、エージェントスクリプトを使用してエージェントを強化する場合でも、一度に多くの変更を加えることは避けてください。これにより、特にサードパーティの AI コーディングツールを使用している場合は、変更によって発生する可能性がある問題 (コンパイルエラーなど) を切り分けてテストするのが困難になる可能性があります。変更を繰り返し適用して、改善を測定し、結果を文書化して、回帰を最小限に抑えます。
- 最初に構造とアーキテクチャを変更してから、適宜変更を加えます。
- 各変更後にテストを行い、ベースラインに対する評価指標を追跡します。
- 小さな修正ではなく、大幅な変更後にエージェントを確定して新しいバージョンを作成します。新しいビルダーでのエージェントのバージョン管理と編集のライフサイクルについて説明します。
テストのヒント
テストは、ベースラインを確立し、結果と改善を客観的に測定し、回帰を最小限に抑えるために不可欠です。移行すると、エージェントの理由と手順が変更され、エージェントの動作に影響する可能性があります。使用する移行ツールに関係なく、慎重にテスト、調整、および再度テストして、エージェントが期待どおりに動作することを確認します。
- エージェントの移行の各フェーズの開始時にテストし、変更の各バッチの後にもう一度テストします。次のようなテストを早期に頻繁に行うように計画します。
- 移行する前に、最初のベースラインを確立し、問題を特定します。
- 最初の移行後、新しいビルダーでベースラインを確立し、回帰を特定します。
- すべての大きな変更後または小さな変更のバッチ後
- Agentforce Builder での手動テストと Agentforce テストセンターでのバッチテストを含むテスト計画を作成します。同じ計画を実行してベースラインに対して追跡します。優れたテスト計画には、少なくとも次のものが含まれます。
- ケースの作成、予定の予約、注文の追跡、[Answer Questions with Knowledge]アクションを使用したFAQなどのコア エージェント機能。
- 認証済みユーザー、認証されていないユーザー、せっかちなユーザーや不満なユーザー、雑談の多いユーザーなど、実際のユーザー行動に基づく人格。
- 複数ターンの会話、マルチサブエージェントの使用事例、エッジケースなど、シンプルでより複雑なシナリオの範囲。
- 顧客検証 (
verifiedCustomerId変数またはisVerified変数に基づくフィルタリングを含む) を実装している場合、エージェントの動作を未検証のエンドユーザーおよび検証済みのエンドユーザーとして明示的にテストします。新しいビルダーで、ライブテストモードでエージェントをプレビューします。検証済みユーザーと未検証ユーザーをシミュレートするには、[変数] タブで、顧客検証の結果または検証済み顧客 ID の保存に使用する変数の値を上書きします。 - エージェントの会話の突然の変更を明示的にテストします。ユーザーは、要求から雑談に移行したり、現在の要求が完了する前に新しい要求を行ったり、会話のトピックを変更したりできます。エージェントは適応可能ですが、探していないとトピックの切り替えの問題が見過ごされがちです。効果的にテストするには、プレビュー会話で件名を 3 ～ 4 回変更して、信頼できるエージェントの行動を確認します。
- 従来のビルダーと新しいビルダーでは、手動テストと一括テストの両方でテスト機能が異なります。それぞれで使用できるテストツールについて説明します。評価指標をできるだけ正確に比較できるように、従来のツールと新しいツールで同じ機能、人格、シナリオをテストするように計画します。
サードパーティ AI ツールの使用のヒント
エージェントはメタデータであり、エージェントスクリプトは移植性が高いため、ローコードツール、プロコードツール、サードパーティツールを柔軟に使用してエージェントを移行および強化できます。自分に最も適したツールを組み合わせて使用しますが、サードパーティツールを使用する場合、次のヒントに留意してください。
- サードパーティのAIコーディング ツールでは、Agentforceスキルが読み込まれていても、エージェント スクリプト構文が正しくなるとは限りません。エージェントスクリプトの公式ドキュメントをダウンロードし、コーディングエージェントと共有します。AI で生成された変更を受け入れる前に必ず手動で確認し、必要に応じて変更を有効なエージェントスクリプト構文にリファクタリングします。疑問がある場合は、『Agentforce Developer Guide』のエージェント スクリプト ドキュメントを参照し、AIを使用してセカンド オピニオンを求めます。
- 明確な制約と目標を定義して、Claude、Cursor、その他の AI ツールを最大限に活用します。成功条件が明確になっていると、これらのツールはアクション可能な結果を提供します。たとえば、「エージェントの改善」などの一般的な要求では、単独で効果的な結果を得ることはできません。より具体的な要求 (「エージェントが返品を処理しようとする前に注文の対象資格を常にチェックする」など) を行うと、結果が向上する可能性が高くなります。また、この移行ガイドをコンテキストとして共有することで、AI ツールが要件を理解し、効果的な方法を提案できます。
- AI ツールを使用する方法は複数あり、エージェント全体を一度に最適化する必要はありません。必要な結果が得られない場合や、エージェントの設計や動作の広範な変更を理解するのが難しい場合は、AI ツールを独立系コントラクターではなく戦略的パートナーやコラボレーターのように扱います。これらを繰り返し使用して、特定の個別の問題を診断し、アプローチを検証して、ソリューションを実装できます。効果的な一口サイズのワークフローの例を次に示します。
- スキルが事前に読み込まれている AI コーディングツールを使用して変更を行う場合は、計画モードで変更を確認します。設計に関する意思決定に異議を唱えて検証し、最善の方法を判断するために特定の変更を行った理由を説明します。次に、エージェントモードで変更を実行します。
- 手動で手順を確認し、推奨される変更をメモします。質問モードでは、AI が同意しているか、AI によって何が異なるか、その理由など、変更に関する AI の視点を求めます。このプロセスを使用して、保持する変更を決定します。次に、エージェントモードで変更を少量ずつ実行します。
