エージェント型および従来のワークフローの自動化の決定

Agentforceを使用すると、企業はルールに簡単には削減できない自動化作業の新しいパラダイムを開くことができます。これらの新機能には、構造化されていない会話からの顧客のインテントの解決、システム全体のマルチパーティプロセスの調整、運用状況へのリアルタイムの対応が含まれます。エージェント型ワークフローでは、定義済みの手順を実行するのではなく、結果に基づいて推論するように設計された自動化が使用されます。この需要を満たすには、自動化の複雑さの全範囲で動作するプラットフォームと、各機能がどの段階に適しているかを示すフレームワークが必要です。

Agentforce は、Einstein Trust Layer、推論エンジン、エージェントスクリプト、Flow、Apex、Data 360 を 1 つの統合プラットフォームに統合します。この組み合わせにより、単純なレコードトリガーの自動化から、音声、ビジョン、ドキュメント、リアルタイムテレメトリにわたる複雑なマルチエージェントオーケストレーションまで、あらゆるものが処理されます。MuleSoft は、企業全体でエージェントワークフローを接続するために必要な MuleSoft ファブリック、ガバナンス、クロスシステムオーケストレーションを使用してこのプラットフォームを拡張します。Agentforce Operations（旧Agentforce Supply Chain）は、これらの機能を運用プロセスと製造プロセスの特定の要求に適用します。

このガイドでは、オーケストレーション密度フレームワークと、この商品ランドスケープ全体で情報に基づいた意思決定を行うためのガイドラインを紹介します。このフレームワークは、アーキテクトが Salesforce Platform のインテリジェントな自動化の使用事例に適した密度レベルを使用して適切なツールとパターンを選択するための反復可能なアプローチを提供します。

Agentforce は、ルールベースの自動化から推論ベースのワークフローへの Salesforce Platform での作業の根本的な移行を表します。その可能性を引き出すには、アーキテクトはエージェントの配置、構成、オーケストレーションについて、十分な情報に基づいて慎重に判断する必要があります。次の原則は、エージェント型意思決定に対する反復可能なガイドラインを提供します。

• **適切なタスクに適切なツールを使用します。**実行パス、モダリティの組み合わせ、目標の複雑さに基づいてオーケストレーション密度を使用し、最適なソリューションを決定します。

  • ルール ベースの確定的作業には、フローとApexを使用した従来の自動化を使用します。ここでは、一連のルールで結果の範囲を完全に設定して定義できます。従来の自動化では静的な実行パスになるため、予測可能で反復可能な結果が保証され、監査可能性にとって重要です。厳格なコンプライアンスと法令遵守を必要とするタスクには、従来の自動化を選択します。

  • Agentforce Gridは、オーケストレーションの複雑さが低~中程度の一括推測の使用事例に使用します。このパターンでは、単一ターンの生成推論を使用して大量の CRM レコードのデータを分類、スコアリング、または集計し、即座に監査可能な高スループットの実行を保証します。

  • Agentforce と Agent Script は、目的の結果がわかっているが、設計時に正確な実行パスを指定できない、自由回答型の目標を持つタスクに使用します。このパターンをガイド付き決定論による推論が必要な要件に適用して、予測可能で追跡可能な結果を実現します。

  • Agentforce Operationsを使用して、サプライチェーン ワークフローのAI対応管理でコラボレーション ビジネス プロセスを合理化および自動化します。

• **オーケストレーション密度の低い使用事例へのエージェント ワークフローの適用は避けてください。**機能要件と非機能要件について、従来の自動化とエージェント自動化のトレードオフを評価します。従来の自動化では、使用事例に必要な拡張性、信頼性、パフォーマンスを実現できます。

• Agentforceと従来の自動化をフローおよびApexと組み合わせたエージェント自動化ハイブリッド アプローチを採用するのは、エージェント型または従来の自動化を単独で使用する場合よりも、この相乗効果の方が価値が高い場合です。

Salesforce sObject は、従来、レコード自動化の主要なエントリポイントでした。insert、update、delete などのデータ操作言語 (DML) イベントの直後にルールに基づいてロジックが実行されます。効率的なレコード トリガー自動化のためのツールを決定するために、自動化の量、レコード量、依存関係の無秩序な増加を考慮して、システムの複雑さを測定する手段として自動化密度を導入しました。従来の自動化では、データを構造化され、スキーマに準拠し、ルールベースの構造に取り込むには、広範な事前作業が必要です。

エージェント型オートメーションは、ユーザーインテントや非構造化データを入力として従来のオートメーションをアップグレードし、推論を適用することで目的の結果を達成します。アーキテクトは、マルチモーダル非構造化データの確率的推論を活用するタイミングと、予測できない結果のリスクを軽減するためにガイド付き確定的ワークフローを適用するタイミングを決定する必要があります。

要件がルールベースのステップの実行から結果に対する推論に移行する場合、アーキテクトは提案されたソリューションの推論の深さと目標の複雑さを評価するための標準化されたフレームワークが必要です。

オーケストレーション密度は、エージェントワークフロー内の複雑さの基準です。オーケストレーション密度は、実行パス、ゴールの複雑さ、モダリティの組み合わせの 3 つの要素によって決まります。自動化密度はシステムのルールと量の物理的な複雑さを測定しますが、オーケストレーション密度は目標に向けたエージェントのパスの推論の複雑さを測定します。複合オーケストレーション密度を使用して設計要件を評価し、アーキテクチャ標準にマップします。

• Execution Path (実行パス): ワークフローの範囲を完全に設定し、設計時に指定できる程度。完全に指定されたワークフローとは、ワークフローですべてのブランチと結果が定義され、実行パスが事前に決定されていることを意味します。指定できないワークフローには、コンテキストデータと命令に対する推論によって実行時に出現する可能性があるパスがあります。
• 目標の複雑度: ワークフローで実行時に解決する必要がある個別の結果、決定ポイント、パスのバリエーションの数。複雑度の低いワークフローは、1つの限定されたタスクを事前に決められた結果で処理しますが、複雑度の高い目標は、設計時に予測できないエッジケースや競合する目標を含む複数のフェーズにまたがります。
• モダリティの組み合わせ: ワークフローで処理する必要がある入力タイプと、ワークフローで生成する必要がある出力フォームの範囲。モダリティが低い場合、標準CRMフィールドを読み取り、レコードの更新を行います。中モダリティでは、構造化された CRM 項目と静的な非構造化データ (メール本文やケーストランスクリプトなど) を組み合わせて使用し、レコードを更新します。高モダリティミックスでは、ライブオーディオやテレメトリーなどの動的なリアルタイムストリームが使用され、複数の外部システム間でマルチモダリティ出力が生成されます。

適切なオーケストレーション密度レベルを判断するには、実行パス、目標の複雑さ、モダリティの組み合わせを順次評価する必要があります。最初に実行パスを調べます。パスを完全に指定できる場合は、従来の自動化から開始します。エージェント型ソリューションを使用して、推論要件なしで確定的パスをオーケストレーションおよび実行するのはアンチパターンです。エージェントの無秩序な増加 (AI エージェントの過剰な増加、未管理) やエージェントのスロップ (AI が生成する低品質で不要な出力) を招き、価値の回収率が低下します。

部分的なパスや指定できないパスについては、引き続き目標の複雑さを評価します。目標の複雑さは明確に定義されているが、パス上の特定のノードで確率的評価が必要な場合は、特定のローカライズされたニーズを満たすためにフローまたは Apex からエージェントをコールすることを検討してください。代わりに、実行パスのステップで大量のレコード セットにわたって1つ以上のAI主導の要件が必要な場合は、Agentforce Gridを検討してください。グリッドでは、複数の AI またはエージェント列を介した複数ステップのシートベースのワークフローがサポートされます。これは、行指向の一括実行に最適です。このアプローチにより、パスが事前に定義できない場合にのみ確率的推論を呼び出すことで、ワークフローのパフォーマンスと監査性が維持されます。

競合するディメンション(不正の検出、ポリシーの遵守、顧客満足度の向上に伴う保険金支払の決定など)や指定できない実行パスによって目標の複雑さが増しているため、自動化のガイド付き確定性のためにAgentforceとAgent Scriptを検討してください。Salesforce とサードパーティシステムを使用する企業間ユースケースでは、MuleSoft Fabric と Agent Broker を使用します。

最後に、モダリティの組み合わせを評価して、マルチモダリティ接続や特殊なインテグレーションなど、必要な技術力を特定します。モダリティミックスは、密度の計算機能ではなく機能セレクターとして機能します。基本的なオーケストレーションロジックを変更することなく、ソリューションの入力と出力の形状を処理するために必要なインフラストラクチャを決定するのに役立ちます。

このマトリックスを使用して、エージェントの自動化のアーキテクチャ標準を決定します。自動化の問題を解決するアプローチを選択して、従来の自動化とエージェントによる自動化のバランスを取ります。

• **従来の自動化(**オーケストレーション密度が低い):レコードの変更によってプロセスがトリガーされ、データが構造化され、ロジックがルール ベースで事前に決定され、結果を予測できる必要がある場合(標準価格の計算や自動タスク作成など)は、従来の自動化を使用します。
• **Agentforce Grid(**低~中オーケストレーション密度):既存のレコード全体の一括 AI タスクを処理する必要がある場合に Agentforce Grid を使用します(たとえば、このリストの各取引先の最近の 50 件のケースを集計し、センチメント スコアを計算して、ケース フィールドにスコアを保持します)。
• **ハイブリッド オーケストレーション(**高次拡張自動化):複雑なエンド ツー エンドのビジネス プロセス(請求処理やオンボーディングなど)を自動化するときに、ハイブリッド オーケストレーションを使用します。このプロセスでは、AIの計画機能が必要ですが、フローとApexのトランザクションの整合性が必要です。
• Agentforce Agent Script（高インテント複雑度）： エントリ ポイント（チャット、電子メール、音声など）が構造化されておらず、解決に会話またはあいまいなユーザ要求を処理する機能が必要な場合にエージェント スクリプトを使用します。

次の表に、さまざまな使用事例に最適な一般的な推奨事項を示します。

遅延

同期レコードトリガーフローは、プラットフォームトランザクション内で実行され、ミリ秒で完了します。Agentforce 推測時間は Atlas Reasoning Engine に依存し、推論の深さとモダリティの複雑さに応じて拡張されます。Agentforce は、遅延が主な制約となる大量の同期レコード処理には適していません。

Cost (コスト)

エージェント型ワークフローの推論コストは、結果のビジネス価値に照らして正当化する必要があります。確定的パスが存在する大量の低オーケストレーション密度のタスクの場合、従来の自動化やAgentforce Gridの方が、エンドツーエンドのエージェント ワークフローよりも経済的である可能性があります。明示的な最大再試行制限とブレーカーを使用して、設計が適切な再試行パターンに対応していることを確認します。このガードレールにより、一括処理に関連する累積的なコスト超過リスクが制限されます。

ガバナ制限

非同期実行の 1 日のプラットフォーム制限に対して大量のエージェント型ワークフローを評価します。Agentforce Grid の一括処理は、標準のプラットフォームトランザクション制限に従います。Salesforceオブジェクトを使用する自動化の場合、Salesforceはマルチテナント環境で共有リソース管理と、暴走した自動化による共有リソースの独占を防ぐための県の制限の両方を適用するため、1日あたりのDML操作の合計数を考慮してください。

監査可能性とコンプライアンス

従来の自動化では、フロートリガーエクスプローラーと Apex ログで完全に監査可能な実行履歴が生成されます。Agentforce ベースのエンドツーエンドまたはハイブリッドのパターンでは、エージェントの意思決定を透過的にする理由ログが生成されますが、解釈には専門知識が必要です。エージェントスクリプトを介したガイド付き決定論は、完全な実行監査可能性がコンプライアンス要件である規制対象の業界に推奨されるパターンです。

エスカレーション

高密度で運用されるエージェント型ワークフローでは、金融取引、規制申請、サプライヤーコミットメントなど、元に戻せない結果をもたらすアクションに対して明示的な人間の承認またはエスカレーションゲートを組み込む必要があります。エージェントスクリプト条件付き制御は、エージェント型ワークフロー内でこれらのゲートを決定論的に適用するメカニズムを提供します。

**オーケストレーション設計ではシンプルさを優先します。**目標を達成できる最小限のオーケストレーションレベルで開始し、実際の負荷で検証して反復します。チェーン内のエージェント、ハンドオフ、または連動関係が追加されるたびに、一貫性のない動作が発生する可能性がある新しいサーフェスが導入されます。

指定可能な実行パスで、推論が必要なノードでエージェントの埋め込みを開始します。Agentforce でエージェントを作成するためのベストプラクティスに従います。多数のサブエージェント (以前は「トピック」) を詰め込まないようにし、手順を膨らませないようにします。自動化の使用事例でリリースされたエージェントは、唯一のインターフェースではないため、無駄を省くことができます。チェーン用の適切なプリミティブを選択します。オーケストレーション (委任) パターンでは、実行シーケンスをより厳密に制御でき、サブタスクをスペシャリストに委任できます。振付 (ハンドオフ) パターンは避けてください。ハンドオフ設計を実装する必要がある場合は、ローカルの目的ではなくグローバルに最適化できるように、目標、コンテキスト、状態を受信エージェントに提供します。

アクションやツールの無秩序な増加を回避します。アクションはエージェントの推論が実現される場所で、その設計によって信頼性の高い結果または失敗が生成されるかどうかが決まります。すべてのアクションは、AI エージェントが会話の次の展開を計画するために使用できる構造化された観察可能な応答を返す必要があります。

同じタスクを実行するために複数のアクション (および異なる出力構造) があると、エージェントが作業に適したツールを判断または選択する能力が低下します。エージェントが微妙な違いを見落としてしまう可能性があります。アクション定義が重複すると、誤った分類のリスクがあります。アクションライブラリが監査され、バージョン管理され、サブエージェント (旧称トピック) 範囲に準拠していることを確認します。

**観察可能な目標を定義します。**目標を単なる手順ではなく、観察可能な結果として定義します。漠然とした目標がエージェントのドリフトを招く。指定可能な実行パスを追加します。ハイブリッドな推論でエージェントグラフを使用して、明示的な状態を持つグラフノードとしてゴールをモデル化します。ランタイムはワークフローでのエージェントの現在の位置を追跡し、接線入力後に復元します。コンテキストウィンドウで追加情報を受け取ったときに目標を失うことはありません。

テストと評価。堅牢なテストおよび評価フレームワークを実装して、確率的ノードの推論とエージェントによる自動化の出力を検証します。期待される結果パスに対して実行パスを検証し、モデルが正しい結果に到達することを確認します。実行ステップで結果をアサートすることで、エージェントが成功を誤って報告したり、無限ループや回復不能なループに入ったりするサイレント失敗を回避します。セッション追跡を使用して、ターンバイターンのインタラクション、推論エンジンの実行、アクション、プロンプトとゲートウェイの入力/出力、エラーメッセージ、最終応答を検査します。

著者について

Arvind Palaniswamy は、Office of the Chief Architect, Well-Architected Team のソフトウェアエンジニアリングアーキテクトです。彼は第一原理を使って複雑なシステムを最もシンプルな形で組み立てたいのです数十年の経験とMS/MBA(ケロッグ)教育を通じてエンジニアリング、オペレーション、ビジネスを理解しています。