面白い記事をみつけたので、翻訳してみます
AIエージェントの開発は刺激的で、 Agentforce Builderのようなローコードツールのエコシステムが急速に発展しているおかげで、開発を始めるのがかつてないほど簡単になりました。動作するエージェントを起動するのにかかる時間は、おそらく朝の通勤時間よりも短いでしょう。しかし、この参入の容易さは諸刃の剣です。2時間でエージェントのデモを起動できるのは確かに満足感がありますが、同じエージェントを実際のユーザーや現実世界の課題に対応させ、大規模かつ本番環境で安定して動作させることは、全く別の課題です。
本番環境では、一見些細な設計上の選択が積み重なり、深刻な信頼性問題へと発展する。こうした問題は構築段階では発見しにくいことが多いが、エージェント型AIを採用する組織が増えるにつれ、明確なパターンが見えてきている。
この記事では、Agentforceの実際の導入環境でよく見られる6つのよくある実装ミスと、それらを未然に防ぐ方法について解説します。
1. 命令の肥大化
問題点：よくある間違いの一つは、エージェントの指示にすべてを詰め込むことです。何百、何千もの単語を使って、考えられるすべてのシナリオ、エッジケース、動作のニュアンスを網羅しようとします。意図は良いものです。エージェントに必要なすべてのコンテキストを持たせたいからです。しかし実際には、これによっていくつかの問題が発生します。
- エージェントは情報を効果的に解析したり優先順位付けしたりすることができない
- トークン制限は、実行時コンテキストではなく命令によって消費されます。
- 要件が変わると、エージェントの保守や更新がほぼ不可能になる。
- エージェントが関連性のある情報を識別するのに苦労するにつれて、パフォーマンスは低下する。
対処法：指示書の内容については徹底的に吟味する。指示書には、エージェントの目的、性格、高レベルの意思決定原則といった、行動に関する中核的な指針のみを記載すべきである。それ以外のことはすべて外部化すべきである。
- 詳細な手順知識を知識記事に記載する
- データとレコードをSalesforceオブジェクトに保存します。
- アクションを使用して複雑なビジネスロジックをカプセル化する
- エージェントが情報を動的に取得するようにし、すべてを事前に準備しないようにする。
指示は職務記述書のように、明確で、焦点を絞り、簡潔であるべきです。「顧客がXと言ったらYを実行し、Zと言ったらAを実行する」と書いている場合は、指示が多すぎる可能性があります。Agentforce
Builderは、この問題の重要な部分に対応していることに注目する価値があります。ハイブリッド推論は、エージェントの計画ステップと実行ステップを分離することで、あらゆるシナリオを予測するという指示の負担を軽減します。エージェントは、徹底的な事前ガイダンスに頼るのではなく、新しい状況を推論して解決できます。とはいえ、ハイブリッド推論は、適切な指示の整備の代わりになるものではありません。不確実な状況下での推論を支援するものであり、常に間違った役割を果たしていた構造が不十分または冗長な指示を補うものではありません。
2. 負の制約
問題点：もう一つの魅力的なアプローチは、エージェントがしてはいけないことをすべてリストアップすることです。「価格に関する質問には答えない。医療アドバイスは提供しない。会社を代表して約束をしない。」テスト中に新しいエッジケースが見つかると、リストは長くなります。
問題は、単に扱いにくくなるというだけではありません。LLMは抑制ではなく生成するように訓練されています。モデルに「Xをしない」ように指示すると、モデルは作業コンテキストでその制約を保持しながら同時に出力を生成する必要があり、これは、目標とする肯定的なターゲットを与えるよりも本質的に信頼性が低くなります。さらに微妙な問題もあります。否定的な制約は、まさに避けようとしているものにモデルの注意を向けさせてしまう可能性があります。これは、誰かに特定のことを考えないように言うようなものです。
このアプローチには以下の問題点がある。
- あらゆるネガティブなシナリオを予測することは不可能だ
- 否定的な指示はモデルを混乱させたり、予期しない動作を引き起こしたりする可能性があります。
- それは能力よりも限界に焦点を当てている
- これは防御的な姿勢を生み出し、エージェントの役に立たなくなる可能性がある。
対処法：エージェントが何をすべきかを明確に示す、肯定的で具体的な指示に焦点を当てましょう。「価格について議論しないでください」と言う代わりに、「価格に関する質問があった場合は、顧客の要望を収集し、営業チームがフォローアップするためのケースを作成してください」と伝えましょう。
フレーム制約をガードレールおよびスコープ境界として用いる：
- 「あなたは、お客様が当社の製品に関する技術的な問題を解決するのを支援します。」
- 「当社のナレッジベースの情報を使って質問に答えていただきます。」
- 「お客様から返金のご要望があった場合は、担当者が対応いたします。」
これは単に構造の問題ではなく、LLMがモデルレベルで言語をどのように処理するかという問題です。「Xをしてはいけない」といった否定的な指示は、「XのときはYを行う」といった肯定的なパターンに比べて、たとえ適切に設計されたエージェントであっても、信頼性が著しく低くなります。Agentforce Scriptではユーザーが決定論的なガードレールを定義できますが、肯定的な指示の枠組みは、自然言語による指示が存在する確率的推論レイヤーを処理します。この2つのアプローチは互いに補完し合います。AgentScriptは境界を強制し、肯定的な枠組みはその境界内でのモデルの意思決定を導きます。エージェント設計においては、どちらも明確に考慮する必要があります。
3. モノリシックエージェント
問題点：顧客対応、注文処理、技術的な質問への回答、返品管理、予約スケジュールなど、「何でもできる」強力なエージェントを1つ構築したくなる誘惑に駆られる。しかし、単一のエージェントは最初は効率的に見えるものの、すぐに管理不能になる。
- 指示が冗長で矛盾している
- どのアクションと知識源がどのタスクに関連するのかは不明である。
- 異なるチームがドメインを個別に所有または更新することはできません
- 複雑さが増すにつれて、性能と信頼性が低下する。
- テストとデバッグは指数関数的に難しくなる
対処法：明確な境界線を持つ、目的に特化したエージェントを設計する。組織構造と顧客体験について考えてみよう。
- トラブルシューティングや技術的な質問に対応するサービスエージェント
- 注文を追跡し、変更を処理する注文管理エージェント
- 予約の手配やカレンダーの空き状況の管理を行うスケジューリングエージェント
これらのエージェントは必要に応じて互いに処理を引き継ぎ、各コンポーネントが保守・テスト可能なマルチエージェントシステムを構築します。これにより、異なるチームがそれぞれの担当エージェントを独立して所有し、反復開発を行うことも可能になります。重要なのは、適切な粒度を見つけることです。粒度が広すぎて巨大なモノリスになってはならず、かといって細かすぎて調整のオーバーヘッドを生み出すような多数のマイクロエージェントになってしまわないようにする必要があります。
4. 過剰な権限を持つエージェントと隠れたデータ依存関係
問題点：最も重大な実装ミスの一つとして、エージェントに過剰な権限を与えてしまうケースが挙げられます。これは、構築担当者が「念のため」という理由で、エージェントが必要以上に多くのデータへのアクセス権限を与えてしまうことを指します。その根底にある考え方は、「どんなデータが必要になるか分からないから、すべてにアクセスできるようにしておこう」というもので、特に構築担当者がSalesforceのデータモデルを深く理解していない場合によく見られます。
逆に、隠れたデータ依存関係は特に厄介な脅威であり、エージェントがテストでは合格しても、アクセスできないデータに遭遇すると本番環境で失敗する可能性があります。実際の例を挙げましょう。ケース割り当てを管理するために構築されたエージェントは、Case オブジェクトにアクセスできたため、テストでは完璧に動作しました。しかし、本番環境では、コンテキストを取得するためにケース コメントを照会する必要があったため、失敗しました。ケース コメントは別の CaseComment オブジェクトに格納されており、独自の権限が必要でした。これは、エージェントが実際のシナリオに遭遇するまで明らかになりませんでした。
これらの問題は以下につながる。
- 過剰な権限付与によるセキュリティリスク
- エージェントが必要なデータにアクセスできない場合に発生するサイレントエラー
- エージェントが一部のユーザーには動作するが、他のユーザーには動作しないという悪夢のようなデバッグ作業
- コンプライアンスおよび監査に関する懸念
代わりにすべきこと：エージェントの権限設定には体系的なアプローチを取る。
- 最初は制限的に始めましょう：最小限の権限から始め、必要なものだけを追加してください。
- データフローをマッピングする：エージェントが必要とするすべてのオブジェクトとフィールド（関連オブジェクトを含む）を特定する。
- 現実的なペルソナでテストする：本番環境に近い権限セットを持つテストユーザーを使用する
- 文書の依存関係：各権限が存在する理由を明確に記録しておく
- 関連オブジェクトの確認：エージェントが使用するオブジェクトについて、個別のアクセスが必要な関連オブジェクト（コメント、添付ファイル、履歴、カスタム関係など）が存在するかどうかを確認します。
権限エラーが発生した場合は、安易に広範なアクセス権限を付与しないでください。具体的な必要性を確認し、必要最低限の権限のみを付与し、その必要性を文書化してください。
5. フローとエージェントの統合
問題点：多くの組織は、リードのルーティングから承認プロセス、データ更新まであらゆる処理を自動化するSalesforce Flowsに多額の投資を行っています。エージェントを構築する際には、これらの既存のFlowsを活用したいと思うのは当然です。しかし、ここで問題が生じます。
フローは、決定論的でルールに基づいた自動化のために設計されています。フローは予測可能な経路をたどります。AならばB、CならばDといった具合です。エージェントをフローに接続すると、予測可能性を前提として構築されたシステムに確率的な要素が導入されることになります。
エージェントに接続されたフローは、従来のフローでは決して起こらないような形で障害を起こす可能性があります。
- エージェントは、フローが処理するように設計されていない予期しない入力を渡す可能性があります。
- ルールベースのトリガーでは発生しなかったエッジケースが、AIによる解釈によって突然現れる。
- 予測可能な入力に対して機能していたエラー処理が、創造的なエージェントの推論と矛盾する
多くのフローには、制御された予測可能な環境で運用されていたため、これまで表面化しなかった潜在的な問題が潜んでいます。エージェントがより多様な方法でフローとやり取りを始めると、これらの隠れた問題が顕在化します。
対処法：エージェントに接続されたフローを、特に注意深く監視する必要のある重要な統合ポイントとして扱う。
- フローを監査する：エージェントを接続する前に、フローのエラー処理、入力検証、およびエッジケースを確認してください。
- 防御的なフローを構築する：入力が予期しない形式または不正な形式である可能性を想定した検証とエラー処理を追加する
- 徹底的にテストする：想定されるシナリオだけでなく、表現のバリエーション、エッジケース、想定外のシナリオでもテストする。
- 本番環境での監視：エージェントが実際にフローをどのように使用しているかを観察し、実際の動作に基づいて改善を繰り返す。
- 露出を歓迎しよう：エージェントがフローの問題を明らかにしたときは、それを失敗ではなく、貴重な発見と捉えよう。
目的はFlowやエージェントを責めることではなく、決定論的システムと確率論的システムを組み合わせる際には、より一層の注意が必要であることを認識することです。この原則は、API、カスタムApex、外部システムなど、あらゆる統合に当てはまります。AIが関わる場合は、憶測を減らし、テストを増やすことが重要です。
6. 設定したらあとは放っておく
問題点：人間はAIプロジェクトを従来のソフトウェア展開のように考えがちです。つまり、構築し、テストし、リリースしたら、次のプロジェクトに移る、という流れです。エージェントは「完了」となります。
しかし、エージェントは根本的に異なります。エージェントは、進化するユーザー行動と変化するビジネスニーズに対応する動的な環境で動作する学習システムです。リリース時に完璧に機能するエージェントも、時間の経過とともに次のように変化していきます。
- ユーザーの行動パターンと期待は変化する
- テストで想定していなかった新たなエッジケースが発生する
- ビジネスプロセスと要件は進化する
- 基盤となるデータと統合が変化する
対処法：継続的なエージェント改善の文化と実践を構築する。
- すべてを計測する： Agentforceの組み込み分析機能とログ機能を使用して、エージェントが実際にどのように使用されているかを把握する
- 会話を定期的に見直す：苦情を待つのではなく、エージェントとのやり取りを積極的に見直して、パターンや問題点を特定する。
- フィードバックループを作成する：ユーザーが問題点を報告したり、改善点を提案したりしやすいようにする
- 本番環境で反復する：ローンチを学習プロセスの終わりではなく、始まりと捉える
- 所有権の割り当て：エージェントを継続的に監視および改良する責任者を指定する
Agentforceのテストセンターは、「定期的なレビュー」という原則を実践可能なものにします。テストケースに想定されるトピック、アクション、レスポンスをラベル付けすることで、変更のたびに実行できる回帰テストスイートを作成できます。実際の運用環境での会話を記録する拡張イベントログと組み合わせることで、将来を見据えたテストハーネスと、過去の状況を分析する診断ツールの両方を利用できます。ただし、注意点として、テストセンターは現在、単一ターンのインタラクションに対応しているため、複雑な複数ターンのフローについては、引き続き手動テストによる補完が必要です。
エージェントのメンテナンスは、ガーデニングに例えることができます。定期的な注意、剪定、そして手入れが必要です。優秀なエージェントチームは、毎週パフォーマンスをレビューし、毎月小さな調整を行い、四半期ごとにさらに詳細な改善を実施します。
意図を持って建築する
これらの実装上の失敗には共通点がある。それは、大規模環境でも確実に動作するエージェントを構築するために必要なことを過小評価していることに起因する。ローコードツールを使えば迅速に構築することは容易だが、うまく機能するものを構築するには、意図的な取り組み、規律、そして継続的な注意が必要となる。
朗報は？これらの落とし穴はすべて、適切なアプローチを取れば回避できるということです。
- 指示は要点を絞り、詳細については知識と行動を活用してください。
- 禁止事項を列挙するのではなく、前向きな形でガイダンスを提示する
- すべてを一度にやろうとするのではなく、明確な境界線を持つ設計重視のエージェント
- 権限とデータアクセスについては体系的に考え、依存関係の連鎖全体を理解する。
- AIと連携する場合、フローと統合にはより一層の精査が必要であることを認識してください。
- リリースは改良の始まりであり、終わりではないと捉える
Agentforceのエコシステムが成熟するにつれて、私たちはこれらのパターンを学び、洗練させていきます。重要なのは、謙虚な姿勢でエージェント開発に取り組むことです。徹底的なテストを行い、綿密な監視を行い、継続的に改善を重ねてください。成功するエージェントは、必ずしも最も速く開発されたものではありません。丁寧に開発され、注意深く維持管理されたエージェントこそが成功するのです。