Salesforce Agentforceの導入を検討するチームから、毎週のように同じ質問を受けます。「Einstein Copilot Studioと何が違うのか」「TopicとActionは結局どこで使い分けるのか」「APexアクションとMCPサーバ統合は競合するのか」。製品の更新スピードが速く、公式ドキュメントが各機能ごとに散らばっているため、全体像をつかむのが難しいというのが実情です。
本記事では、Agentforceをエンタープライズに導入するうえで必要な6つの構造軸 ─ Agent Builder（旧称Agentforce Studio）、Topic、Action Library、Apex連携、Data Cloud、MCPサーバ統合 ─ を一つの「構造マトリクス」として整理し、実装フェーズごとに何を決めるべきかを公式仕様ベースで解説します。10社規模のAIエージェント導入支援を行ってきたなかで、Salesforce既存ユーザがつまずきやすい意思決定ポイントも合わせて取り上げます。
正直にお伝えすると、Agentforceは「ノーコードで簡単に作れる」とマーケティング素材で語られがちですが、エンタープライズ要件（権限分離、監査ログ、運用責任の所在）まで含めて設計すると、Apex・Flow・Data Cloud・セキュリティ管理の知識が前提になります。本記事はその前提を踏まえ、評価フェーズの読者が「自社で何を準備すべきか」を見通せる構成にしました。
まず押さえるべき”構造マトリクス” ─ Agentforceの6軸
Agentforceの公式ドキュメントは機能ごとに分散していますが、実装の意思決定に必要な軸は次の6つに整理できます。私が社内で評価フレームとして使っているマトリクスをそのまま掲載します。
| # | レイヤー | 役割 | 誰が触る | 主な決定事項 |
|---|---|---|---|---|
| 1 | Agent Builder（旧Studio） | エージェント定義・テスト・デプロイのUI | 管理者 / 業務PM | エージェントの種類（Service / Sales / Custom）と利用範囲 |
| 2 | Topic | エージェントが扱うタスクのカテゴリ境界 | 業務PM / 設計者 | 業務領域の分割粒度、各Topicの説明文 |
| 3 | Action Library | Topic内で呼び出す具体的な操作の集合 | 設計者 / 開発者 | Standard / Flow / Apex / Prompt / API の選択 |
| 4 | Apex Actions | サーバサイドのカスタムロジック | 開発者 | @InvocableMethodの設計、入出力型 |
| 5 | Data Cloud / Data Library | 非構造化データの検索基盤（RAG） | データエンジニア | 取り込み元、チャンキング、検索粒度 |
| 6 | MCPサーバ統合 | 外部ツール・データへの標準接続 | アーキテクト | 許可サーバの選定、Allowlist運用 |
この6軸を上から下へ順番に決めていくのが、Agentforce実装のもっとも素直なフローです。逆順 ─ たとえば「Apexアクションを先に書く」「MCP統合から考える」 ─ で進めようとすると、Topic境界が崩れ、後でAction Libraryの再設計が必要になることが多いです。
以降のセクションでは、それぞれのレイヤーで「何が公式仕様として定義されているのか」「実装現場で気をつけるべき点はどこか」を順番に掘り下げます。
レイヤー1:Agent Builder（旧Agentforce Studio）の位置づけ
Agent Builderは、Salesforceの管理画面（Setup）から起動するノーコード/ローコードのオーサリング環境です。2024年9月のAgentforce発表時には「Agentforce Studio」「Agent Builder」という名称が並列で使われていましたが、現在の公式ドキュメントではAgent Builderが正式名称として統一されています。Einstein Copilot StudioをAgentforce向けに刷新したもの、と理解するのが一番近いです。
Agent Builderの主要パネル
Agent Builderの画面は大きく3つのパネルで構成されます。
- Conversation Preview:右側のチャットウィンドウで、エージェントの応答をその場でテストできる。Topicとアクションの選択トレースが表示されるため、デバッグの中心になる。
- Topic List:左側のサイドバーに、エージェントが扱うTopicが一覧表示される。Topicごとに有効/無効を切り替えられる。
- Action Library:中央のキャンバスで、選択したTopic内のActionをドラッグ&ドロップで追加・編集する。
エージェントの種類とテンプレート
Agent Builderで新規エージェントを作成するとき、最初に選ぶのが「エージェントタイプ」です。公式ドキュメントで定義されている主要なタイプは次の3つです。
| タイプ | 用途 | 事前定義Topic |
|---|---|---|
| Service Agent | カスタマーサポート、ナレッジ参照 | Case管理、Knowledge検索、エスカレーション |
| Sales Coach / SDR | 営業支援、商談コーチング、リードナーチャー | Opportunity分析、メール起案、コール準備 |
| Custom Agent | 業務固有のフロー | なし(ゼロから設計) |
Service AgentとSales Coachは、業務テンプレートとしてTopicが事前に組み込まれているため、PoC開始時間を短縮できます。一方Custom Agentは、Topic設計を一からやる必要がある分、業務との整合性を取りやすいです。私自身の経験では、Salesforce既存運用の上に乗せる場合はService Agentから始め、独自業務はCustom Agentで段階的に追加するハイブリッドが現実的です。
注意点として、テンプレートを選んでも、エージェントの応答内容は「Topicの説明文」「Actionの設定」「Data Cloudのデータ」によって大きく変わります。テンプレートはあくまで初期スキャフォールドであり、業務要件に合わせた調整は必須です。
レイヤー2:Topicの設計 ─ 境界線の引き方が成否を分ける
Topicは、エージェントが扱う業務領域を分割する単位です。たとえばService Agentであれば「Case受付」「FAQ回答」「人間オペレーターへのエスカレーション」がそれぞれ独立したTopicになります。実装的にはTopicの粒度が、後段のAction Library設計を決定的に左右します。
Topic設計の3つの基本ルール
公式のTrailhead教材と、実装プロジェクトで得た経験から、Topic設計には次の3つの基本ルールがあります。
- 1Topic = 1業務カテゴリ:「ケース受付」と「FAQ回答」を同一Topicにまとめない。エージェントの動作はTopic単位で予測可能性を高めるべきで、混在するとAction選択精度が落ちる。
- Topic説明文は”業務担当者の業務範囲”のように書く:Salesforceの公式ガイダンスでは、Topic descriptionに「いつこのTopicが選ばれるべきか」を明示するよう推奨されている。「ケース受付Topic:顧客から新しい問い合わせを受け取ったときに使用する」のように。
- Topic数は最初は5以下に抑える:Topicが10を超えると、エージェントのルーティング精度が体感的に落ち始める。実プロジェクトでも、最初は3〜5 Topicに絞り、運用しながら追加するのが定着しやすい。
Topic設計の悪い例と良い例
実際にPoCで遭遇した、悪いTopic設計と修正案を共有します。
❌ 悪い例:Topic名「サポート」、説明文「顧客サポートに関すること全般」
⭕ 修正後:
- Topic名「Case受付」/ 説明文「顧客から新規問い合わせが入った際に使用。CaseオブジェクトをCRMに登録する」
- Topic名「ナレッジ参照」/ 説明文「既存FAQ・マニュアルから回答可能な問い合わせに対応。Data Libraryから検索する」
- Topic名「エスカレーション」/ 説明文「ナレッジで回答できない、または感情分析でネガティブと判定された場合に使用。人間オペレーターをアサインする」
境界がはっきりするほど、エージェントの応答も予測可能になります。逆に「サポート全般」のような曖昧なTopicは、Action選択の判断材料が薄くなり、ハルシネーションを誘発しやすくなります。
レイヤー3:Action Library ─ 5種類のActionタイプを使い分ける
Action Libraryは、Topic内でエージェントが呼び出せる具体的な操作の集合です。Agent Builder上で「New」→「Add from Asset Library」を選ぶと、追加可能なActionタイプが表示されます。公式仕様で定義されている主要タイプは5つです。
| Actionタイプ | 用途 | 実装難易度 | 運用責任 |
|---|---|---|---|
| Standard Action | Salesforce標準オブジェクトのCRUD(Case作成、Lead更新など) | 低(設定のみ) | 管理者 |
| Flow Action | ノーコード自動化(Flow Builderで作成) | 中 | 管理者 + Flow設計者 |
| Apex Action | カスタムロジック(@InvocableMethod) | 高 | 開発者 |
| Prompt Template Action | 生成AIプロンプト(Prompt Builder) | 中 | 業務 + AI担当 |
| MuleSoft / API Action | 外部システム連携 | 中〜高 | 統合担当 + アーキテクト |
Actionタイプ選択の意思決定フレーム
5種類すべてを使う必要はありません。むしろ、機能を絞ったほうが運用が楽になります。私が現場で使っている意思決定フレームは次のとおりです。
- Salesforce標準オブジェクトで完結する操作か? → Yesなら Standard Action。
- 条件分岐や複数オブジェクトの更新が必要か? → Yesなら Flow Action(管理者がメンテ可能)。
- 複雑な計算、外部API呼び出し、SOQLでは表現できない処理か? → Yesなら Apex Action。
- 生成AIによるテキスト生成・要約・分類が必要か? → Yesなら Prompt Template Action。
- 外部システムへの連携が必要で、MuleSoftアクセスがあるか? → Yesなら MuleSoft Action。それ以外は次節のMCPサーバ統合を検討。
順番が大切です。上から順に検討することで、必要以上にApexを書くことを避けられます。Apexは強力ですが、デプロイ・テストカバレッジ・コードレビューの運用コストがかかるため、業務管理者が触れない領域になりがちです。
レイヤー4:Apex Actions ─ サーバサイド拡張の作法
Apex Actionは、Agentforceで最も柔軟性が高い拡張ポイントです。Salesforceの公式ワークショップでも繰り返し取り上げられており、@InvocableMethodアノテーションを使ったApexメソッドをActionとして登録できます。
最小サンプル:取引先の関連商談を要約するApex Action
// 注意:本番環境で使用する前に、必ずテスト環境で動作確認してください。
// 動作環境:Salesforce Spring '26、API version 62.0以上
public class GetAccountOpportunitySummary {
public class Request {
@InvocableVariable(label='Account Id' required=true)
public Id accountId;
}
public class Response {
@InvocableVariable(label='Summary')
public String summary;
}
@InvocableMethod(
label='Get Account Opportunity Summary'
description='指定された取引先の関連商談を集計し、要約を返す'
category='Agentforce'
)
public static List<Response> execute(List<Request> requests) {
List<Response> results = new List<Response>();
for (Request req : requests) {
List<Opportunity> opps = [
SELECT Id, Name, Amount, StageName, CloseDate
FROM Opportunity
WHERE AccountId = :req.accountId
AND IsClosed = false
ORDER BY CloseDate ASC
LIMIT 10
];
Decimal totalAmount = 0;
for (Opportunity o : opps) {
if (o.Amount != null) totalAmount += o.Amount;
}
Response r = new Response();
r.summary = String.format(
'オープン商談 {0} 件、合計金額 {1} 円。最早クローズ予定 {2}。',
new List<Object>{
opps.size(),
totalAmount.format(),
opps.isEmpty() ? '該当なし' : String.valueOf(opps[0].CloseDate)
}
);
results.add(r);
}
return results;
}
}Apex Action設計の3つの原則
10件以上のApex Actionをレビューしてきたなかで、共通して大切だと感じた原則は3つです。
- 1メソッド = 1ビジネスタスク:複数の業務を1つのApexメソッドに詰め込まない。エージェントから呼び出される単位は小さく保つ。
- 入出力はDTOクラスで明示:@InvocableVariableのlabelとdescriptionを必ず書く。エージェントはこの説明をもとに「いつこのActionを呼ぶか」を判断する。
- 例外処理は明示的に:Try-Catchで業務エラーをResponse型にラップし、エージェントが理解できる文字列として返す。例外をそのまま投げると、エージェントの応答が不安定になる。
正直にお伝えすると、Apex Actionは「書くこと自体」より「テストカバレッジ75%を維持しながら継続的にデプロイする運用」のほうが大変です。Salesforceの本番環境はテストカバレッジが満たないとデプロイできないため、Apex Actionを増やすほどテストコードのメンテナンス負荷が積み上がります。これがApex一辺倒の設計を避けるべき最大の理由でもあります。
レイヤー5:Data Cloud / Data Library ─ RAG基盤としての位置づけ
AgentforceにおいてData Cloud(およびData Library機能)は、構造化されていないナレッジ(PDF、Webページ、SharePointドキュメントなど)を検索可能にするRAG(Retrieval-Augmented Generation)基盤として機能します。公式ドキュメントでは「Salesforce Data CloudがData Libraryを支える基盤として、データのingest・chunking・index・storeを担当する」と定義されています。
Data Libraryの構築フロー
- ソース選択:File-basedかURL-basedかを選ぶ。Webクロールはサイトマップ単位、ファイルアップロードはPDF/HTML/Markdown対応。
- Chunking設定:デフォルトはトークン数ベースの自動分割。業務文書が長い場合は、見出し単位のセマンティックチャンキングが推奨される。
- 埋め込みモデル選択:Salesforceマネージドの埋め込みモデルが標準。
- Action経由でRetrieval:Data LibraryはAction Library内の「Knowledge Retrieval Action」として組み込まれ、Topic設計に紐づく。
Data Library運用の落とし穴
クライアントのCSチームでData Libraryを構築した際、想定外だったのは「データの鮮度管理」の運用負荷でした。FAQが更新されてもData Libraryに反映するには再ingestが必要で、運用ルールを決めないとすぐに「古い回答を返すエージェント」になります。
導入した運用ルール
- FAQ更新は週次バッチで一括ingest(月曜朝に自動実行)
- 重要更新(料金・契約条件)は手動で即時ingest、Slack通知
- Data Libraryのバージョンタグを記録、回答精度に問題があれば前バージョンに巻き戻し可能に
測定期間:2026年2月〜3月(2ヶ月間)
結果:「古い回答が返ってきた」というインシデント発生件数 月8件 → 月1件
ポイント:Data Library単体の精度ではなく、ingestルール・通知・ロールバック手順を含む運用設計が効果を最大化しました。
レイヤー6:MCPサーバ統合 ─ Agentforce 3.0で追加された標準接続
2026年に入って大きな変化があったのが、MCP(Model Context Protocol)対応です。MCPはAnthropicが提唱したオープン標準で、AIエージェントと外部ツール・データソースを標準化されたプロトコルで接続する仕組みです。Salesforceは2025年7月にPilotを開始、2026年1月にBetaがリリースされました(Salesforce公式ブログ「Agentforce MCP Beta Brings All the Power of Tool Calling, None of the Context Bloat」より)。
MCP統合の3つの活用パターン
| パターン | 用途 | 例 |
|---|---|---|
| サードパーティMCPサーバ呼び出し | 外部SaaS連携 | GitHub、Slack、Jiraなどの公開MCPサーバ |
| 自社MCPサーバ公開 | 社内APIをエージェント間で再利用 | 独自データ・独自業務ロジックを社内エージェント網に公開 |
| AgentExchange経由 | Salesforceがキュレートしたサーバ群 | 導入難度が低く、エンタープライズ要件を満たすベンダー連携 |
MCP統合とApex Action / MuleSoft Actionの使い分け
MCPが登場したことで、「外部連携はApex / MuleSoft / MCPのどれで実装するか」という新しい選択肢が増えました。公式ブログ「Choose the Right Agentforce Integration Pattern: API, MCP, or A2A」を参考に整理すると、次のような使い分けが妥当です。
- Apex / Flow:Salesforce内部のロジック、データ変換、複数オブジェクトをまたぐ処理
- MuleSoft API:既存のレガシーシステムやプロトコル変換が必要な統合
- MCP Server:エージェント間で再利用可能な、標準化された外部ツール接続
- Agent-to-Agent (A2A):複数のエージェント同士のオーケストレーション(別記事で詳述)
マルチエージェント設計の文脈では、Orchestrator-Workerパターンと組み合わせて、AgentforceをWorkerの1つとして配置するアーキテクチャも実装可能になってきています。
MCP統合のAllowlist運用
MCPサーバ統合で最重要なのがAllowlist管理です。任意の外部MCPサーバを接続できると便利な反面、エンタープライズではセキュリティリスクになります。Agentforceの公式ガイダンスでは、次のような運用が推奨されています。
- 管理者がAllowlistにサーバを登録
- サーバ単位、ツール単位でメタデータを選択
- 監査ログにAction呼び出しを記録
- 定期的なAllowlistレビュー(四半期ごとに棚卸し)
エンタープライズ導入の評価フレームワーク
ここまでが6軸の構造解説です。実際にAgentforceを社内導入するときに、私が評価フレームとして使っているチェックリストを共有します。SaaS選定の意思決定者向けに、観点を5カテゴリに整理しました。
1. ライセンス・コスト評価
| 項目 | 確認ポイント |
|---|---|
| 従量課金単位 | Conversation単位かAction呼び出し単位か(Salesforce公式の最新価格表で確認) |
| Data Cloud利用料 | ingest量・storage量・query量の3軸で計算 |
| Apex / Flow 既存ライセンス | 必要なエディションを満たしているか |
| MCPサーバ利用料 | サードパーティ提供サーバの個別課金有無 |
2. セキュリティ・コンプライアンス評価
- 監査ログの保存期間と検索機能
- ユーザ権限(Profile/Permission Set)とエージェント権限の分離設計
- 個人情報の取り扱い(Data Cloudへのingest対象データの精査)
- 外部MCPサーバへの送信データの暗号化・マスキング
- EUデータ滞留要件(GDPR)、業界規制(HIPAA、PCIなど)への適合
3. 運用体制評価
Agentforce導入を成功させるには、最低3つの役割が必要です。
| 役割 | 担当領域 | 必要スキル |
|---|---|---|
| 業務PM | Topic設計、利用シナリオ定義 | 業務知識、AIプロダクト思考 |
| Salesforce管理者 | Agent Builder、Flow、Standard Action | Salesforce認定資格レベル |
| 開発者 | Apex Action、MCPサーバ実装、Data Cloud設計 | Apex、SOQL、データモデリング |
正直にお伝えすると、この3役を社内で揃えられない場合、PoCはできても本番運用フェーズで失速します。SIerに丸投げする前提なら、運用フェーズで誰がメンテするのかを契約時点で握っておくべきです。
4. 既存Salesforce資産との整合性評価
- 既存のEinstein Bot、Einstein Copilot、Service Cloud Voiceとの併用設計
- 既存Flow / Apex のAgentforce Action化可能性
- 既存Knowledgeの Data Library への移行戦略
- ユーザ権限の継承(既存のProfileを流用するか、専用に切るか)
5. AI判定可能性・改善サイクル評価
- Conversation Logsの可視化(Agent Builder内のトレース機能)
- 応答品質のメトリクス(成功率、エスカレーション率、ユーザ満足度)
- Topic / Action 単位の改善サイクル(週次レビューの仕組み)
- A/Bテストの実施可能性
導入後3ヶ月でAgentforceの効果を最大化するには、上記の改善サイクルを最初から組み込んで設計することが鍵です。「とりあえずローンチして様子見」では、応答品質が劣化したまま固定化されるリスクがあります。
【要注意】Agentforce実装でハマりやすい5つの失敗パターン
失敗1:Topicを細かく分けすぎる
❌ よくある間違い:業務工程ごとに15個のTopicを作る。
⭕ 正しいアプローチ:最初は3〜5 Topicから始め、運用しながら必要に応じて追加する。
なぜ重要か:Topic数が多いほど、エージェントのルーティング判断が困難になり、誤った Topic を選んでしまう確率が上がる。
失敗2:Action LibraryでいきなりApexから書き始める
❌ よくある間違い:エンジニアが主導してApex Actionを20個書く。
⭕ 正しいアプローチ:Standard Action → Flow Action → Apex Actionの順に検討し、必要最小限に絞る。
なぜ重要か:Apex Actionが多いほどデプロイ・テスト運用コストが膨らみ、管理者が触れない領域になる。
失敗3:Data Libraryに「とりあえず全部入れる」
❌ よくある間違い:社内Wiki全ページをData Libraryにingestして、検索精度が悪化。
⭕ 正しいアプローチ:Topicごとに必要なナレッジを選別し、Data Libraryを分割管理する。
なぜ重要か:RAG検索は対象データが増えるほど精度が下がる。Bedrock AgentCoreのKnowledge Base運用でも同じ教訓が共有されている。
失敗4:MCPサーバを無制限に許可する
❌ よくある間違い:開発者が試したいMCPサーバを次々追加し、Allowlist管理が形骸化。
⭕ 正しいアプローチ:四半期レビューで棚卸しし、使われていないサーバを削除する。
なぜ重要か:データ流出経路が把握できないと、エンタープライズ要件(SOC2、ISMS)を満たせない。
失敗5:Conversation Logsを誰もレビューしない
❌ よくある間違い:ローンチ後、応答内容を誰もチェックせず、ユーザクレームで初めて問題に気づく。
⭕ 正しいアプローチ:週次でConversation Logsをサンプリングし、Topic / Action 単位で改善を回す。
なぜ重要か:エージェントは静的なシステムではなく、運用で「育てる」ものだから。これはAWS環境でのAgent Toolkit for AWS運用でも共通する原則です。
実装ロードマップ:30日 / 60日 / 90日の段階導入
クライアントとAgentforce導入を進める際、私が標準的に提案している段階別ロードマップを共有します。あくまで目安ですが、最初の方向性決めに使いやすいフレームです。
Day 1〜30:基盤構築フェーズ
- Sandboxでのライセンス確認、Agent Builder起動確認
- 3 Topicに絞ったCustom AgentのPoC構築
- Standard Actionのみで動作確認
- Conversation Logsの記録設定とサンプル分析
- 業務PM・管理者・開発者の3役アサイン
Day 31〜60:拡張・Data連携フェーズ
- Data Library構築、Knowledge Retrieval Actionの組み込み
- Flow ActionとApex Actionの段階的追加(必要最小限)
- 運用ルール策定(Data Library更新サイクル、Conversation Logsレビュー手順)
- セキュリティレビュー(権限分離、監査ログ確認)
Day 61〜90:本番展開・改善フェーズ
- 限定ユーザでの本番展開、フィードバック収集
- MCPサーバ統合の評価(必要なら導入)
- 応答品質メトリクスのダッシュボード化
- 週次改善サイクルの定着化
- 次フェーズで追加するTopic / Actionの優先順位決定
このロードマップは「Day 1で全機能を使う」のではなく、「Day 30までに最小限で動かし、運用で育てる」ことを前提にしています。Agentforceは機能が広いぶん、最初に欲張ると運用コストで負けます。
Agentforceと他社プラットフォームの位置づけ比較
Agentforceの選定を判断するにあたって、よく比較対象になる他社プラットフォームとの違いを整理しておきます。
| 項目 | Agentforce | Amazon Bedrock Agents | Microsoft Copilot Studio |
|---|---|---|---|
| 主戦場 | SalesforceエコシステムCRM/業務 | AWS基盤上のカスタムエージェント | Microsoft 365 / Teams |
| データ統合 | Data Cloud(ファーストパーティ) | S3 / OpenSearch / Knowledge Bases | Microsoft Graph |
| 拡張ランタイム | Apex / Flow / MuleSoft | Lambda / Step Functions | Power Automate / Connector |
| 標準プロトコル | MCP(Beta) / A2A | MCP対応進行中 | Microsoft独自 + 一部MCP |
| 強み | 既存Salesforce資産との接続性 | 柔軟性、AWSサービス統合 | Officeワークフローへの組み込み |
選定の基本軸は「既存のデータと業務がどこに集まっているか」です。Salesforceに顧客データ・営業データが集約されているならAgentforceが最有力。AWSにデータパイプラインが集約されているならBedrock Agentsが有力。M365が業務ハブならCopilot Studioが選びやすい。
参考・出典
- Salesforce公式: Agentforce Data Library
- Salesforce Developers: Exercise 4: Extend Agents with Apex Actions
- Salesforce公式ブログ: Agentforce MCP Beta Brings All the Power of Tool Calling, None of the Context Bloat
- Salesforce公式: Agentforce MCP Support
- Salesforce公式ブログ: Choose the Right Agentforce Integration Pattern: API, MCP, or A2A
- Trailhead: Create a Data Library for AI Agents Effectively
まとめ:Agentforce導入を成功させる3つのアクション
- “構造マトリクス6軸”を上から順に決める:Agent Builder → Topic → Action → Apex → Data Cloud → MCPの順序を守る。逆順は再設計を招く。
- 最初は3〜5 Topic、Standard Action中心で始める:Apex一辺倒の設計はテスト運用コストで詰む。Standard → Flow → Apex の順で必要最小限に。
- 運用設計を最初に組み込む:Data Library更新ルール、Conversation Logsレビュー、Allowlist棚卸しを Day 1 から定義する。エージェントは育てるもの、放置すると劣化する。
Agentforceは強力なプラットフォームですが、「ノーコードで簡単に作れる」というマーケティングを真に受けると失敗します。Salesforceエコシステムとの整合性、エンタープライズ要件、運用体制、この3点に正直に向き合ったプロジェクトだけが、本番運用フェーズまで到達できると感じています。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。Salesforce Agentforceを含むエンタープライズAIエージェント設計・運用の伴走支援、社内研修プログラムをご提供します。
執筆:佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。著書『AIエージェント仕事術』。10社以上のAIエージェント導入支援を通じて、Salesforce / AWS / Microsoft 各エコシステムでの実装ノウハウを蓄積。
