リソースとコストの最適化 - エージェントパターン
Well-Architected Resource and Cost Optimization (適切に設計されたリソースとコストの最適化) → Agentic Enterprise Resource and Cost Optimization (エージェントによるエンタープライズリソースとコストの最適化) の詳細
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Agentforce | アクション | ✅ コレクションを受け入れるデザインアクション。50 件のケース更新を処理するエージェントは、50 件の個別の呼び出しではなく、ケース ID のコレクションを使用して 1 つのアクションを呼び出します。 |
| Agentforce | アクション | ✅ 1 つの SOQL ステートメントで親と子のデータを取得するリレーションクエリを使用して、アクションチェーン全体で SOQL 予算を管理する |
| プラットフォーム | プラットフォームキャッシュ | ✅ プラットフォームキャッシュに参照データをキャッシュすることで、同じ会話内のアクション間でクエリを繰り返す必要がなくなります。 |
| プラットフォーム | Apex | ✅ 同期制限を超えたエージェント操作をキュー可能または一括Apexに移行します。 |
| プラットフォーム | Apex | ✅ Apex実行ログを使用して負荷中のアクションをプロファイルします。同期制限に近づいている場合、計算負荷の高い処理を非同期コンテキストに移行する |
| Agentforce | アクション | ✅ データスキューシナリオのハードな子レコード制限とページネーションを使用したアクションの設計 |
| Agentforce | アクション | ✅ 「すべての履歴」を予期せずに要求する可能性のあるエージェントの量がしきい値を超えた場合のサンプリングの実装 |
| プラットフォーム | スケールセンター | ✅ Scale Center トランザクショントレースを使用して、クエリを過度に消費するアクションを特定する |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | アクション | ⚠️ コレクションを受け入れる代わりに、レコードごとに別々のアクションを呼び出す (例: 50 件のケース更新に対して 50 件の個別のコール) |
| プラットフォーム | Apex | ⚠️ 10 ~ 15 アクションの複雑なワークフローでアクションあたり 5 ~ 10 個の SOQL クエリを実行し、100 個の同期 SOQL の制限に近づいている |
| プラットフォーム | Apex | ⚠️ 大規模な処理を非同期コンテキストではなくアクションで同期的に実行(例:同期Apexで1,000件以上のリードを獲得) |
| Agentforce | アクション | ⚠️ エージェントが防御コードなしで 15,000 件の商談がある取引先または 5,000 件の活動があるケースから無制限の子レコードを取得できるようにする |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| プラットフォーム | イベント監視 | ✅ パイロットフェーズ中のイベントモニタリングで API 使用量を監視し、完全なロールアウト前に実際の使用量を把握する |
| Data 360 | 設定 | ✅ ベクトル検索で実際に使用された結果の数のみを取得するように top-k 制限を設定する |
| Data 360 | Analytics | ✅ Top-k パラメーターのチューニングのための Data 360 Analytics でのベクトル検索結果の利用状況の監視 |
| プラットフォーム | プラットフォームイベント | ✅ 作業の有無に関係なく、API コールを消費するスケジュール済みポーリングではなく、エージェントの介入が必要な状況でプラットフォームイベントを公開 |
| インテグレーション | アクション | ✅ 複合パターンを使用: 1 つの MuleSoft 環境 API を作成して複数のシステムチェック (在庫、価格設定、クレジット) を並列で集計し、エージェントが 1 つの外部アクションを呼び出して 1 つのコールアウトを消費 |
| インテグレーション | アクション | ✅ エージェントの操作ごとに複数の連続したフローを実行するのではなく、すべての下流の更新を実行する単一の MuleSoft フローを設計する |
| Agentforce | エージェント設定 | ✅ 標準コンポーネントを使用してエージェントをLightningページに埋め込み、インタラクションごとにAPIコールを消費しないようにします。 |
| ビジネス | 計画 | ✅ MuleSoft ライセンスモデル (トランザクションベースライセンスとプラットフォームライセンス) を推定エージェント取引量と比較して評価し、最適な経済性を判断する |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Data 360 | 設定 | ⚠️ 上位 5 件のみを使用している場合に上位 50 件のベクトル検索結果を取得すると、コンピューティング予算とコンテキスト予算の 90% が無駄になる |
| プラットフォーム | スケジュール済みジョブ | ⚠️ 作業の有無に関係なく API コールを消費するスケジュール済みポーリング (例: 5 分ごとに 80% の確率で作業が見つからないことを確認) |
| インテグレーション | 指定ログイン情報 | ⚠️ 複数のシステムコールを集計する 1 つの複合 API ではなく、3 つのコールアウトを使用する 3 つの個別のアクション |
| プラットフォーム | Apex | ⚠️ 標準Lightningコンポーネントで回避できる場合、APIコールを使用して明示的なAPI要求を行うカスタムLWC |
| インテグレーション | 外部システム | ⚠️ CDC イベントに登録するのではなく、毎日何百もの API コールを使用して Salesforce の状態をポーリングする外部システム |
| インテグレーション | アクション | ⚠️ 各ステップ (顧客へのクエリ、商品のクエリ、在庫の確認、注文の作成、在庫の更新、配送の通知) の API コールを連続して実行し、複合パターンで消費を 75% 削減する場合、トランザクションあたり 12 件以上のコールを消費する |
| インテグレーション | エージェント設定 | ⚠️ 各システムインタラクションが必要かどうかを評価せずに、多くのシステム間でエージェントアクションをオーケストレーションし、追加した各システムで API 消費量を乗算する |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Agentforce | プロンプトテンプレート | ✅ プロンプトの長さを最小限に抑える: 冗長な指示、冗長な例、不要なコンテキストを削除します。コンテキストの選択により、遅延と品質の両方が改善 |
| プラットフォーム | Apex | ✅ インデックス付き検索条件で選択的な SOQL を使用します。テーブル全体のスキャンの原因となっている欠落しているインデックスを特定するクエリプランツールの活用 |
| Agentforce | エージェント設定 | ✅ 連動関係が存在しない場合は、アクションの並列実行を使用します。取引先の詳細と商談を同時に取得すると、順次取得と比較して遅延が半分になります。 |
| プラットフォーム | プラットフォームキャッシュ | ✅ 頻繁にアクセスされる参照データ (商品カタログ、テリトリーの対応付け、価格設定ルール) をキャッシュすることで、SOQL の繰り返しを排除 |
| プラットフォーム | プラットフォームキャッシュ | ✅ 類似するクエリに一致するセマンティックキャッシュを実装して、新しい推測なしで繰り返し要求に対応 |
| プラットフォーム | Apex | ✅ 非同期ガバナ制限の緩和を使用して、緊急でない要求を非同期で処理 (状況の更新、一括処理、レポート生成) |
| プラットフォーム | Apex | ✅ 現実的なデータ量でのアクションのプロファイル。高速 LLM 推測に関係なく、3 秒かかるアクションがボトルネックになる |
| Agentforce | アクション | ✅ アクションに一括処理を実装して操作あたりの実行時間を最小限に抑える |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | プロンプトテンプレート | ⚠️ 遅延と品質の両方を改善する選択的コンテキストの代わりにノイズを追加する徹底的なコンテキストを含める |
| Agentforce | エージェント設定 | ⚠️ 連動関係が存在しない場合にアクションを順次実行する (例: 取引先クエリ 2s + 商談クエリ 2s = 2s 並列ではなく 4s 順次) |
| プラットフォーム | Apex | ⚠️ インデックス付き検索条件で選択的な SOQL を使用する代わりに、インデックスがないためにテーブル全体をスキャンする |
| プラットフォーム | プラットフォームキャッシュ | ⚠️ Data 360 を繰り返し (コールあたり 1.5 秒) 照会して、キャッシュ可能な共通データを探す (プラットフォームキャッシュから 50 ミリ秒) |
| Agentforce | エージェント設定 | ⚠️ 緊急でない業務 (状況更新、一括処理、レポート生成) の同期完了が必要 |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Data 360 | 設定 | ✅ Knowledge記事、製品ドキュメント、ケース履歴を、250~750の意味のある単語セグメントに分割 |
| Data 360 | 設定 | ✅ エージェントのクエリパターンに対してチャンクサイズを検証します。バランス精度 (小さいチャンク) とコンテキストの完全性 (大きいチャンク) |
| Data 360 | 設定 | ✅ エージェントクエリパターンに一致する埋め込みを使用します。取得精度と取り消しを測定する代表的なクエリに対して選択内容を検証する |
| Data 360 | 設定 | ✅ ビジネスの制約を確保するメタデータ検索条件を使用してベクトルの類似性を強化 (意味の類似性に関係なく、販売終了品目を除く有効な商品に絞り込むなど) |
| Data 360 | 設定 | ✅ 複数のソースの顧客データを 1 つのビューに集計する統合プロファイルを使用します。1 つのクエリで完全なコンテキスト (属性、インサイト、エンゲージメント、予測) にアクセス |
| Data 360 | 設定 | ✅ 正確なクロスシステム顧客マッチングを提供する ID 解決を有効にする |
| Data 360 | 設定 | ✅ データレジデンシーコンプライアンスの規制要件に一致する地域で Data 360 インスタンスを設定する |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Data 360 | 設定 | ⚠️ ベクトル検索結果に無関係な情報が含まれる大きすぎるチャンクを使用している |
| Data 360 | 設定 | ⚠️ メタデータ検索条件を使用せずにセマンティック類似性のみに依存し、中止された結果や品質の低い結果を返す |
| Data 360 | 設定 | ⚠️ Data 360 統合プロファイルを使用するのではなく、複数の個別のソースクエリを調整して完全な顧客コンテキストを実現 |
| Data 360 | 設定 | ⚠️ エージェントのクエリパターンと一致しない埋め込みモデルの使用 (質問と回答の類似性のためのドキュメント分類の埋め込みなど) |
| Data 360 | 設定 | ⚠️ 欧州以外の Data 360 インスタンスで欧州の顧客データを処理し、データレジデンシー要件に違反する |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Agentforce | エージェント設定 | ✅コンテキストを明示的に優先する: 最近の会話履歴 (最上位)、重要なビジネスデータ/レコードの状態/権限 (2 番目)、履歴コンテキスト (最下位、スペースが許す場合のみ) |
| Agentforce | エージェント設定 | ✅ 10 ~ 15 ターン後、詳細な履歴なしで重要な事実を維持しながら、初期の会話を簡潔な概要にまとめる |
| Data 360 | 設定 | ✅ すべての LLM コールで完全な履歴ではなく、Data 360 またはカスタムオブジェクトに拡張コンテキストを保存します。現在のニーズに焦点を絞ったプロンプトを保持するオンデマンドのクエリ |
| Agentforce | アクション | ✅ アクション応答から必須項目のみを返します。取引先の取得では、50 項目すべてではなく、現在の ToDo に関連する項目が返されます。 |
| Agentforce | エージェント設定 | ✅ コンテキストウィンドウ割り当ての任意の切り捨てではなく、明示的な優先順位付けロジックを設計する |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | エージェント設定 | ⚠️ 明示的な優先順位付けロジックを使用しないコンテキストの任意の切り捨て |
| Agentforce | エージェント設定 | ⚠️ 10 ~ 15 ターンを超えて完全な逐語的な会話履歴を維持し、コンテキスト予算を消費する |
| Agentforce | エージェント設定 | ⚠️ 拡張コンテキストを外部に保存してオンデマンドで照会する代わりに、すべての LLM コールに完全な履歴を含める |
| Agentforce | アクション | ⚠️ 現在の ToDo に関連するサブセットのみがある場合に取引先取得から 50 項目すべてを返すと、コンテキスト予算が消費されます。 |
| Agentforce | エージェント設定 | ⚠️ 応答生成用の十分なスペースを確保せずにコンテキスト予算を割り当てる |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| プラットフォーム | アクション | ✅ レコードの CRUD、承認、通知、レポート、検証をカバーする一元化されたアクションライブラリを開発します。プラットフォームチームは、一貫した動作、セキュリティ、パフォーマンスを確保 |
| Agentforce | エージェント設定 | ✅ より狭いコンテキストと明確な境界を維持しながら、専門分野の深い専門知識を持つ専門エージェント(ケース管理のサービスエージェント、商談ガイダンスの販売エージェント)を作成する |
| Agentforce | エージェント設定 | ✅ クロスドメインのニーズに合わせたエージェントビルダーオーケストレーションの調整スペシャリストエージェントの使用 |
| Agentforce | プロンプトテンプレート | プロンプトビルダーで検証済みのプロンプトパターンを維持します。テンプレートは、RAG クエリの形成、複数ステップの推論、応答の書式設定に関する実証済みのアプローチを取得します。 |
| Agentforce | プロンプトテンプレート | ✅ 改善の A/B テストを可能にするバージョンプロンプトテンプレート |
| Data 360 | 設定 | ✅ 複数のエージェントに対応する Data 360 で共有Knowledgeベースを維持します。1 つの商品Knowledgeベースが営業、サービス、パートナーポータルエージェントをグラウンディング |
| Agentforce | エージェント設定 | ✅ 実証済みのビルディングブロックから新しいエージェントを作成: 目的の定義、[アクション] の選択、プロンプトの設定 (カスタムビルドの場合は数週間から数日) |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | プロンプトテンプレート | ⚠️ 検証済みのプロンプトテンプレートライブラリを再利用するのではなく、エージェントごとにアドホックプロンプトを作成する |
| Agentforce | アクション | ⚠️ 一元的な再利用可能なアクションライブラリを使用するのではなく、エージェントごとにアクションを再実装する |
| Agentforce | エージェント設定 | ⚠️ 専門分野の深い専門エージェントではなく、すべてのシナリオを試すユニバーサルエージェントの構築 |
| Data 360 | 設定 | ⚠️ 複数のエージェントをグラウンディングする単一のKnowledge Baseを共有するのではなく、エージェントごとにKnowledge Baseを複製する |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| プラットフォーム | カスタムメタデータ型 | ✅ カスタムメタデータ型とプロンプトビルダーを使用して、コードを変更することなく動作を制御できます。システム管理者が開発サイクルなしでプロンプトテンプレートと推論パラメーターを変更する |
| Agentforce | エージェント設定 | ✅ 品質評価指標、満足度、フルロールアウト前の ToDo 完了 (例: 10% を v2、90% を v1) を比較する実験バージョンにサブセットを転送 |
| Agentforce | エージェント設定 | ✅ 検証期間を監視し、AB テスト中に問題が見つかった場合はロールバック機能を維持する |
| Agentforce | アクション | ✅ コンポーネント間の明確なインターフェース契約を定義する: アクションで入力、出力、エラー、パフォーマンスの期待を指定 |
| Agentforce | エージェント設定 | ✅ 複数週のロールアウト期間で成功バージョンを段階的に拡大 (10% ~ 25% ~ 50% ~ 100%) |
| Agentforce | アクション | ✅ インターフェース契約が保持されている場合、エージェントが変更せずにアクション実装を置き換える |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| プラットフォーム | Apex | ⚠️ 構成主導のアプローチを使用する代わりに、コードを変更してエージェントの動作を変更する必要がある(カスタムメタデータ型、プロンプトビルダー) |
| Agentforce | エージェント設定 | ⚠️ 品質評価指標と満足度を比較するサブセットで A/B テストを行わずに、新しいエージェントバージョンを完全にロールアウトする |
| Agentforce | アクション | ⚠️ エージェントはインターフェース契約ではなくアクション実装の詳細に依存し、実装が変更されると中断する |
| Agentforce | エージェント設定 | ⚠️ 段階的なロールアウトなしで、新しいバージョンを 100% のユーザーにすぐにリリースする |
| Agentforce | エージェント設定 | ⚠️ 実験バージョンテスト中にロールバック機能なしで動作している |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Agentforce | エージェント設定 | ✅ 各要求をできるだけ少ないエージェントアクションで解決 — Flex Credits はアクションごとに消費されるため、複数ステップのロジックを 1 つのアクションに統合することで、コストを直接削減できます。 |
| Agentforce | エージェント設定 | ✅ 文書化した Flex Credit 消費レートと想定されるインタラクション量に基づいて月次コスト予測をモデル化し、予算計画を可能にします。 |
| Einstein | 監視 | ✅ エージェント、使用事例、ユーザー母集団ごとの Flex Credit 消費を監視して、最適化が必要な高消費パターンを特定する |
| Einstein | 監視 | ✅ 実際の消費量を予測と比較して将来の計画を通知し、最適化の機会を特定する |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | エージェント設定 | ⚠️ 1 つの統合アクションで要求が解決される多数の小さなアクションをチェーニングし、インタラクションあたりの Flex Credit 消費を乗算する |
| ビジネス | 計画 | ⚠️ インタラクションごとのコストモデリングが実行されなかったため、Flex Credit 消費が本番リリース後にのみ予測を超えることが判明 |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Agentforce | エージェント設定 | ✅ セッションの境界とタイムアウトを設計して、会話を途中で終了して新しい請求可能な会話を強制することなく、会話を適切に保持する |
| Agentforce | エージェント設定 | ✅ 請求可能なフォローアップを要求するのではなく、最初の会話内で ToDo を完了するようにエージェントの機能を最初の会話の解決に集中させる |
| Einstein | 監視 | ✅ 会話あたりの価格設定で、初回会話の解決率をコスト効率指標として追跡する |
| Agentforce | エージェント設定 | ✅ 既存の会話コンテキスト内で関連する問題を処理する。各会話に定額料金が発生する個別の会話を開く必要はない |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | エージェント設定 | ⚠️ 短いセッションタイムアウトで会話が途中で終了し、ユーザーが新しい請求可能な会話を開始して 1 つの ToDo を終了できるようにする |
| Einstein | 監視 | ⚠️ 最初の会話の解決率を追跡せずに会話量合計のみを監視し、会話あたりの価格設定の主コストレバーを見逃している |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| ビジネス | ドキュメント | ✅ ライセンスユーザーがエージェントに積極的にエンゲージするように採用を促進する (ユーザーごとの価格設定が未測定の場合、各インタラクションの最小化ではなく使用量に基づく) |
| Einstein | 監視 | ✅ 利用状況を追跡して、対象を絞ったトレーニングやライセンスの再割り当てで使用頻度の低いライセンスユーザーを特定する |
| ビジネス | ドキュメント | ✅ ユーザー母集団別にエージェントのインタラクションをビジネス成果に結び付け、価値の高い使用事例でシートあたりの投資を正当化 |
| ビジネス | 計画 | ✅ ライセンスが過剰ライセンスに囚われるのではなく、実際の使用量に合わせてライセンスを維持するようにケイデンスでユーザー母集団を確認する |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| ビジネス | 計画 | ⚠️ 採用計画のないユーザーごとのライセンスのプロビジョニング、エージェントとほとんどエンゲージしないユーザーのシートごとの固定コストの支払 |
| Einstein | 監視 | ⚠️ ユーザー母集団ごとの利用状況を決してレビューせず、従来のシートを無駄にするのと同じ過剰ライセンスにライセンスを移行させる |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Agentforce | エージェント設定 | ✅ シンプルなロジックで初期ルーティングを処理するトリアージエージェントを実装し、複雑さが必要とする場合にのみユーザーを専門エージェントに転送 |
| プラットフォーム | フロー | ✅ ルールベースのロジックで十分な確定的シナリオではフローの自動化にフォールバックし、本当に必要なあいまいな状況ではエージェントの推論を保留 |
| Data 360 | エージェントの設定 | ✅ グラウンディングデータを選択して取得し、エージェントの推論で必要な場合にのみベクトル検索とドキュメント取得を呼び出して、すべてのインタラクションでグラウンディングデータを取得する |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | エージェント設定 | ⚠️ すべての要求を専門のエージェントに直接転送し、単純なトリアージロジックで処理できる要求に対して高価な複雑な呼び出しが発生する |
| プラットフォーム | フロー | ⚠️ 変数を使用せずにフローを低コストで実行できる確定的ルールベースのワークフローでエージェントの推論を使用 |
| Data 360 | エージェントの設定 | ⚠️ 推論が必要かどうかに関係なく、すべてのインタラクションでグラウンディングデータを取得し、実際のニーズを追跡しない Data 360 の消費を促進 |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Data 360 | エージェントの設定 | ✅ 定義された更新ケイデンス (24 時間など) を使用して商品カタログの埋め込みをキャッシュし、定期的な質問のためにキャッシュから取得し、新規または顧客固有のデータのみについて Data 360 を照会する |
| Data 360 | エージェントの設定 | ✅ 一般的な要求に対するクエリの繰り返しを減らすキャッシュ戦略を実装し、コストの最適化とデータの鮮度要件のバランスを取る |
| Data 360 | 組織 | ✅ 増分成長コストとは別に、データの取り込みと処理のコスト(ハーモナイゼーション、ID解決、組み込み生成)を前もってモデル化 |
| Data 360 | エージェントの設定 | ✅ 取得拡張生成を追加する前に、特定の使用事例で RAG オーバーヘッドが品質の改善に適しているかどうかを評価 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Data 360 | エージェントの設定 | ⚠️ クエリの大部分が同じよくある質問であるにもかかわらずキャッシュが実装されておらず、同じ回答を繰り返すために Flex Credits を消費している |
| Data 360 | 組織 | ⚠️ データの新鮮度要件を考慮しない積極的なキャッシュの実装、古い情報のユーザーへの提供 |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| プラットフォーム | 組織 | ✅ Partial Copy Sandbox と対象顧客データサンプルをエージェント開発に使用し、本番前の検証専用の Full Copy Sandbox を予約 |
| プラットフォーム | 組織 | ✅ Data 360 の容量、迅速なテストのための Flex Credits、インテグレーション接続など、開発インフラストラクチャのコストを事前に計画する |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| プラットフォーム | 組織 | ⚠️ エージェント開発用に Full Copy Sandbox をプロビジョニングするすべての開発者は、Sandbox のコストを 5 倍にします。 |
| プラットフォーム | 組織 | ⚠️ アドホックな手動テストに依存してカバー率が低く、本番でのみ品質の問題を発見 |
| ビジネス | 計画 | ⚠️ 計画時に開発インフラストラクチャのコストが見えなくなり、実装時に予期しないコストが発生する |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| ビジネス | ドキュメント | ✅ 開発、推測 (Flex Credits)、インフラストラクチャ (Data 360 + MuleSoft)、運用、ガバナンス、変更管理の 6 つのコストカテゴリすべてをカバーする包括的な TCO モデルを構築する |
| ビジネス | ドキュメント | ✅ インタラクション量、クレジット消費レート、成長軌道に関する文書化した前提条件を使用して、3 ~ 5 年間のコストを予測するスプレッドシートの TCO モデルを作成する |
| ビジネス | ドキュメント | ✅ 感度分析を実行して、総投資に最も影響する前提条件を明らかにし、焦点を絞った検証作業を可能にします。 |
| ビジネス | ドキュメント | ✅ Salesforce の固定数値ではなく、一般的な AI エージェント業界ベンチマークから、成熟したエージェントの年間開発コストの意味のある割合として継続的な運用コストをモデル化する |
| ビジネス | 計画 | ✅ 過小評価されていることが多い変更管理コスト (ユーザートレーニング、ビジネスプロセスの適応、組織の変更) を含める |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| ビジネス | 計画 | ⚠️ 継続的な消費 (Flex Credits、Data 360、業務) をモデル化せずにエージェントビジネスケースの開発コストのみを含めることで、リリース後に予定外の年間コストを大幅に削減 |
| ビジネス | 計画 | ⚠️ エージェントの自律性とリスクレベルに応じて増大するガバナンスオーバーヘッド (安全性レビュー、人的監視インフラストラクチャ、監査ログ、コンプライアンス検証) の省略 |
| ビジネス | 計画 | ⚠️ 特にエージェントが大幅なワークフローシフトを作成する場合は変更コストを過小評価し、予算不足に陥る |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| ビジネス | ドキュメント | ✅ メンテナンス コストを含む包括的な3年間のTCO比較により、事前作成済みAgentforceエージェントとカスタム開発を評価 |
| ビジネス | ドキュメント | ✅ アーキテクチャ決定レコードで構築と購入の意思決定を文書化し、コストと機能の変化に応じて将来の再評価が可能 |
| Agentforce | エージェント設定 | プロンプトビルダーを使用した事前作成済みエージェントのカスタマイズと、標準とフルカスタムの中間的なアクション設定を検討 |
| ビジネス | 計画 | ✅ コスト以外の要素の決定基準: タイム トゥ バリュー、組織開発能力、戦略的差別化の価値、ベンダーの依存関係の許容度 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| ビジネス | 計画 | ⚠️ 事前作成済みオプションを示す 3 年間の TCO をモデル化せずに「制御したい」カスタムエージェントを作成すると、大幅に安くなる可能性がある |
| ビジネス | 計画 | ⚠️ 複数年にわたる継続的なメンテナンス、クレジット消費、ベンダー更新のメリットを予測せずに、初年度のコストのみに基づいて構築または購入を選択 |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| ビジネス | ドキュメント | ✅導入前にエージェントのTCOを従来の自動化の代替方法(フロー、Apex、手動プロセス)と比較して、投資の正当性を検証 |
| ビジネス | ドキュメント | ✅ 最大負荷の従業員コスト、エラー率、処理時間、スループット容量を含む手動プロセスのベースラインを確立し、潜在的な節約の可能性を明らかにする |
| Agentforce | エージェント設定 | ✅ 従来の自動化では対応できない自然言語理解、適応的推論、シナリオの変動が大きいタスクにエージェントを導入する |
| プラットフォーム | フロー | ✅ 明確なルールがある確定的ワークフローにフローの自動化を使用することで、変数の推測の消費なしで同等の結果を低コストで提供 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | エージェント設定 | ⚠️ フローが変動コストなしで同等の機能を提供する場合、年間 15,000 ドルのクレジットを消費する単純な確定的ルーティングタスクにエージェントをリリースする |
| ビジネス | 計画 | ⚠️ 従来の自動化がより低い総コストで同等の結果をもたらすかどうかを評価せずに、すべての自動化でエージェントアプローチをデフォルトにする |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Einstein | 監視 | ✅ エージェント、ユーザー母集団、期間、インタラクション種別別に消費を表示する Flex Credit 消費ダッシュボードを作成して、消費の急増をすばやく特定する |
| Einstein | 監視 | ✅ クレジット消費をビジネストランザクションに関連付けるインタラクションごとのコスト属性の実装 (解決済みケースあたりのコスト、評価済みリードあたりのコスト、処理済み注文あたりのコスト) |
| Einstein | 監視 | ✅ エージェントおよび使用事例 (組織全体だけでなく) 別に 70% や 85% などのしきい値で予算アラートを設定し、超過が発生する前にプロアクティブな介入を可能にします。 |
| Einstein | 監視 | ✅ 異常な消費パターン (プロンプトの非効率性、予期しない使用パターン、悪用を示す突然の急増) を特定する異常検知を実装する |
| ビジネス | ドキュメント | ✅ コストダッシュボードをビジネス関係者や技術チームと共有し、コスト意識の高いエージェントの使用を可能にする透明性を高める |
| ビジネス | ドキュメント | ✅ 四半期ごとの予算レビューを実施し、実際の使用量を予測と比較し、ビジネス成果を評価し、実証値に基づいて割り当てを調整 |
| ビジネス | 計画 | ✅ クレジット予算の 10 ~ 15% を実験や予期しない消費の増加に備えて確保し、イノベーションのボトルネックを回避 |
| ビジネス | 計画 | ✅ エージェントの採用トレンド、新規リリース、拡大する使用事例に基づいて複数年の予測を作成し、業務量計画とベンダー交渉を可能にする |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Einstein | 監視 | ⚠️ 毎月の請求書レビューでのみクレジット消費を監視し、更新前に最適化する時間がない 6 週間から四半期までの予算超過を発見 |
| Einstein | 監視 | ⚠️ 組織レベルでのみ予算アラートを設定し、最適化の機会を示すエージェントごとおよび使用事例ごとの消費スパイクがない |
| ビジネス | 計画 | ⚠️ 過剰支出をプロアクティブに特定して対処するのに十分な期間、消費監視が実装されていなかったため、緊急予算の増加が必要 |
| ビジネス | 計画 | ⚠️ 会計年度開始時にレビューなしで年間予算を 1 回設定すると、価値の高いエージェントがクレジットに飢え、ROI の低いエージェントが割り当てを消費します。 |
| ビジネス | 計画 | ⚠️ 実験のためにゼロの予算予備を割り当て、探索の前に長期間の承認を通じてすべての新しい使用事例を正当化することをチームに強制する |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Einstein | 監視 | ✅ エージェント種別や使用事例での比較を可能にするエージェントインスタンス別の使用量を追跡し、最適な ROI を提供するエージェントを特定します。 |
| ビジネス | ドキュメント | ✅ 消費をビジネスプロセス (リード評価、ケース解決、注文処理) に関連付けて、ビジネスリーダーが戦略的な連携を評価できるようにします。 |
| Einstein | 監視 | ✅ 部門、ロール、またはユーザーセグメント別に使用量を追跡し、エージェントの採用が最も多い場所とコストの集中している場所を明らかにする |
| ビジネス | 計画 | ✅ 四半期ごとのコストレビューを使用して、ポートフォリオ全体でエージェントの ROI を比較し、実証された価値に基づいて投資を低 ROI のエージェントから高 ROI のエージェントに再割り当てします。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| ビジネス | 計画 | ⚠️ すべてのエージェントコストをビジネスユニット属性のない IT 予算に割り当てて、支出が優先度を満たしているかどうかをビジネスリーダーが評価できないようにする |
| ビジネス | 計画 | ⚠️ エージェントの消費をビジネス結果に関連付けずに未分化コストとして処理し、ROI の計算を不可能にする |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| ビジネス | ドキュメント | ✅ ビジネスユニット別に消費を可視化するショーバックレポートを実装し、コスト意識を高めて、紛争のあるチャージバック紛争のない情報に基づいた使用量の決定を可能にします。 |
| ビジネス | ドキュメント | ✅ 大規模生産エージェントにはチャージバック、試験的または少量のエージェントにはショーバックを含むハイブリッド割り当てを使用して、説明責任とイノベーションの柔軟性のバランスを取る |
| ビジネス | ドキュメント | ✅ 四半期レビューを実施し、消費が提供価値と一致しているかどうかを議論し、最適化コミットメントに導く |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| ビジネス | 計画 | ⚠️ 実験エージェントのフルチャージバックの実施、新しい使用事例に対する予算の説明責任の即時課によるイノベーションと探索の抑制 |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Agentforce | プロンプトテンプレート | ✅ 追加のトークンをすべて認識するシステムプロンプトの不要な冗長性を排除することで、すべてのインタラクションで事前入力の計算とレイテンシーが増加し、エージェントが実際に使用する内容に合わせてシステムプロンプトが切り詰められます。 |
| Agentforce | プロンプトテンプレート | ✅ 関連性ランキングを使用した選択的なコンテキスト検索により、関連情報のみを含めることで、最も価値の高い情報がコンテキスト制限内に収まるようにします。 |
| Agentforce | プロンプトテンプレート | ✅ 日常的なやりとりの簡潔な応答形式を指定し、詳細な形式や広範な説明の要求を回避して完了トークンを最小限に抑える |
| Agentforce | プロンプトテンプレート | ✅ 類似するエージェント間で標準化されたプロンプトテンプレートを再利用し、一貫性と効率性を確保しながらプロンプトの最適化への投資を償却 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | プロンプトテンプレート | ⚠️ 最適化せずに対話形式でプロンプトを記述すると、冗長な手順やエージェントがめったに参照しない広範な例を含め、インタラクションごとに 2K 以上のトークンを消費します。 |
| Agentforce | プロンプトテンプレート | ⚠️ 関連情報のみを選択的に含めるのではなく、コンテキストに関連する可能性のあるすべてのデータを取得し、プロンプトトークンの消費を水増しする |
| Agentforce | プロンプトテンプレート | ⚠️ パターンを標準化するのではなく、エージェントごとに一意のプロンプトテンプレートを作成し、品質のメリットを比例させることなくプロンプトエンジニアリング工数を乗算する |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Agentforce | エージェント設定 | ✅ 重複するクエリのキャッシュから直接提供されるよくある質問に対する一般的なエージェントの回答をキャッシュする (キャッシュヒット率が 30% を超えている場合は、最適化の機会が大きいことを示します) |
| Data 360 | エージェントの設定 | ✅安定したKnowledgeコンテキスト(製品カタログ、ポリシー ドキュメント、参考資料)をキャッシュして、一般的な情報を参照するすべてのインタラクションの取得オーバーヘッドを削減 |
| Agentforce | エージェント設定 | ✅ ユーザーセッション内で会話キャッシュを実装し、全履歴を再送信することなくターン全体のコンテキストを維持し、複数ターンのインタラクションでのトークン消費を削減 |
| Agentforce | エージェント設定 | ✅ コンテンツの変動性に基づいてキャッシュ無効化戦略を定義する (時間/日の商品情報キャッシュ、リアルタイムデータはキャッシュ不可) |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Agentforce | エージェント設定 | ⚠️ クエリの 60% が同じよくある質問であるにもかかわらずキャッシュが実装されておらず、同じ回答を繰り返すために Flex Credit が不必要に消費されている |
| Agentforce | エージェント設定 | ⚠️ 新鮮さを必要とするリアルタイムデータ (在庫レベル、価格設定、在庫状況) をキャッシュし、エージェントの応答を誤らせる古い情報を提供する |
| Agentforce | エージェント設定 | ⚠️ 商品、ポリシー、プロセスが変更されたときに回答が古くなる原因となるキャッシュされた回答を更新しない |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| ビジネス | ドキュメント | ✅ 3 年間の TCO の予測、測定方法による期待されるビジネス成果、代替ソリューションとの比較、リスク評価を含むビジネスケースが必要 |
| ビジネス | ドキュメント | ✅ 部門が承認できる投資と役員の承認が必要な投資を分ける承認しきい値を定義して、高投資または高リスクのエージェントが役員から按分された精査を受けられるようにする |
| ビジネス | ドキュメント | ✅ 完全な本番環境への投資の前に、前提条件 (消費、品質、採用) を検証するパイロット導入を義務付ける |
| ビジネス | ドキュメント | ✅ エージェントの提案に ROI の計算を含める (ケース解決による 4:1 の返品率や手動処理によるコスト削減など) |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| ビジネス | 計画 | ⚠️ ビジネスケースのないエージェントのリリース、不明瞭なビジネス価値を提供しながら 3 倍の予測クレジット消費の発見、文書化した ROI のない計画外の年間消費の作成 |
| ビジネス | 計画 | ⚠️ パイロットリリースをスキップして本番に直接移行し、全予算を確定する前に消費の前提条件を検証する機会を失う |
| ビジネス | 計画 | ⚠️ 同等の価値を低コストで提供できる可能性のある代替アプローチ (手動プロセス、従来の自動化) と比較せずにエージェントの投資を承認する |
パターン
| 参照すべき場所 | 外観 |
|---|---|
| ビジネス | ドキュメント | ✅ コスト、使用量、ビジネス価値、戦略的連携を比較するすべてのエージェントを評価する年次ポートフォリオレビューを実施し、エージェントごとのレビューで見逃された最適化の機会を明らかにする |
| ビジネス | ドキュメント | ✅ 予算を消費する価値の低いエージェントの累積を防止するサンセット条件 (低い導入率、低い ROI、機能の代替、過剰なコスト) を定義する |
| ビジネス | 計画 | ✅ パフォーマンスの低いエージェントから、進化するビジネスの優先度に合わせて価値の高い商談にリソースをシフトする継続的な投資の再割り当てを実践する |
| ビジネス | ドキュメント | ✅ ROI 階層でエージェントを分類する (例: 上位 2 つは 50% のコストで 70% の価値を提供 = 優秀、中間 4 つは 35% のコストで 25% の価値を提供 = 許容、下位 2 つは 15% のコストで 5% の価値を提供 = 不成立の候補) |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| ビジネス | 計画 | ⚠️ 稼働状況や価値レビューがないまま本番環境に無期限で残っているエージェントがリリースされ、価値の低いエージェントが予算を消費して蓄積され、価値の高い商談に資金を提供している |
| ビジネス | 計画 | ⚠️ ポートフォリオの視点を持たずにエージェントを個別にのみ評価し、少数のエージェントが最大の価値を提供し、多くのエージェントが不均衡なリソースを消費するというインサイトを見落としている |