Salesforce Flow/ApexをAIエージェント対応にする方法｜Agentforceで既存自動化を活かす実装手順
SalesforceをAIエージェント対応にしたいとき、最初に悩みやすいのは「既存のFlowやApexをどこまでそのまま使えるのか」です。Agentforceの custom action を見て、既存資産を一気につなぎたくなる一方で、画面依存のフローや複数責務を抱えた自動化をそのまま開放すると、誤更新や権限事故が起きやすくなります。
実務では、新しく全部作り直すより、既存の自動化資産を agent-ready な形へ切り出す方が現実的です。Salesforce Blog が2026年6月17日に公開した公式記事でも、prime candidate を選び、single-purpose action に分け、deterministic な実行と probabilistic な推論を切り分ける考え方が中心でした。
結論から言うと、Agentforce対応の第一歩は、既存のFlowやApexを丸ごと公開することではありません。単機能で入力と出力が明確な autolaunched Flow や invocable Apex だけを候補にし、UI依存、複数責務、system context 前提の処理は切り分けてから action 化する のが基本です。あわせて、typed data contract、user context、fault message、human-in-the-loop を先に決めると、本番運用で崩れにくくなります。
本記事のポイント
- Agentforce対応の最初の候補は、単機能で入力と出力が明確な autolaunched Flow や invocable Apex です。
- 既存の画面依存フローや複数責務の自動化は、そのまま公開せず、UI、判断、データ更新を分離してから action 化する方が安全です。
- 本番運用では、typed data contract、user context、fault message、human-in-the-loop を先に決めることで、AIの曖昧さを Salesforce 側で吸収しやすくなります.
この記事で扱うテーマ
関連キーワード
- Salesforce Agentforce custom action
- Salesforce Flow AIエージェント対応
- Salesforce Apex AIエージェント対応
- Agentforce invocable Apex
- Agentforce autolaunched Flow
- Salesforce existing automation agent ready
このページで答える質問
- Salesforceの既存FlowやApexをAIエージェント対応にするには何から始めるべきですか？
- Agentforceのcustom actionに向く自動化と向かない自動化はどう見分けますか？
- autolaunched Flow と invocable Apex はどう切り出せば安全ですか？
- AgentforceでSalesforce更新を任せる前に何を決めるべきですか？
まずは「公開してよい自動化」と「まだ早い自動化」を分ける
Agentforce の custom action に向くかどうかは、AIの性能よりも、既存自動化の責務の切り方で決まります。Salesforce公式の整理を実務向けに言い換えると、最初にやるべきことは、既存の Flow / Apex を prime、transitional、marginal の3層で分けることです。
| 区分 | 向いている資産 | そのまま action 化してよいか | 理由 |
|---|---|---|---|
| Prime candidate | autolaunched Flow、invocable Apex、単機能の計算や照会 | 比較的よい | 入力と出力が明確で、責務が狭い |
| Transitional candidate | 画面フローの内部ロジック、複数処理が混ざったApex | 切り出してから | UI依存や複数責務が混ざっている |
| High-risk / marginal | system contextで強い更新を行う処理、広範なDML、権限回避前提の処理 | そのままは避ける | 誤実行時の影響が大きく、人の承認が必須 |
たとえば「税率を計算する」「在庫可否を照会する」「案件の次回確認日を計算する」のような処理は、Agentforceに渡しやすい候補です。一方で、「画面で条件分岐しながら割引計算、請求発行、通知送信までを一気にやる」ような処理は、そのまま action にすると責務が広すぎます。
この整理は、Salesforce Headless 360 や Agentforce 360 で触れた「AIがCRMを呼び出す接続面」と同じ論点です。接続方法より先に、何を呼ばせるかを細く定義した方が安全です。
FlowとApexは「単機能アクション」に分解してから公開する
既存自動化を agent-ready にする本質は、Flow か Apex かではなく、1アクション1責務 に近づけることです。画面、ルーティング、データ更新、通知送信が1本に詰まっていると、AIがどこまでを任されているか曖昧になります。
autolaunched Flow に寄せるときの考え方
Flow側では、画面用の Screen Flow から業務ロジックを切り離し、headless に呼べる autolaunched Flow へ寄せるのが基本です。レコードトリガー条件や画面遷移に埋まっている処理を抜き出し、入力変数と出力変数を明示すると、AI側が何を渡し、何を受け取るかが安定します。
invocable Apex に寄せるときの考え方
Apex側では、trigger handler や service layer の中に散らばったロジックから、AIに呼ばせたい処理だけを専用クラスへ切り出します。公式ドキュメントどおり @InvocableMethod を使い、wrapper class で入力と出力を型付きで定義しておくと、曖昧な引数解釈を減らせます。
| 切り出し前の状態 | 切り出し後の形 | AI対応で得られること |
|---|---|---|
| 画面フロー内に判断と更新が混在 | autolaunched Flow に業務ロジックを抽出 | 会話UI以外からも再利用しやすい |
| 巨大なApexが複数処理を担当 | invocable Apex へ単機能で分離 | 入力と出力の契約を固定しやすい |
| 結果の返し方が曖昧 | 明示的な output 変数や wrapper を定義 | Agentforce が次の会話へつなげやすい |
「割引計算」「請求書生成」「通知送信」が一体化した処理なら、Agentforceに渡すのは最初から全部ではなく、まず「割引計算だけ」のような狭い単位からです。これなら、AIが誤って選んだときの影響も限定できます。
実装で先に決めるべき5つのガードレール
Agentforceに既存自動化をつなぐとき、実際に差が出るのはプロンプトではなくガードレールです。Salesforce Blog と関連ドキュメントを実務に引き寄せると、少なくとも次の5点は先に固定しておくべきです。
- Bulkify を前提にする
1件前提で作った処理は、AIが複数候補をまとめて実行したときに破綻しやすくなります。FlowでもApexでも、複数入力を受けても返せる単位で見直した方が安全です。 - typed data contract を作る
文字列の寄せ集めや untyped JSON ではなく、Apex wrapper や明示的な Flow 変数で入力と出力を定義します。AIにとっても、人のレビューにとっても、何を期待する処理なのかが読みやすくなります。 - fault message を会話に返せる形へ整える
「失敗しました」では運用できません。上限超過、権限不足、対象なしのように失敗理由を具体化して返すと、AIが勝手に補完しにくくなります。 - user context を強制する
system context で広い更新権限を持つ処理をそのまま呼ばせるのは危険です。Apex ならwith sharingやWITH USER_MODE、Flow なら user context 実行を前提にし、見えてはいけないデータを越えさせないようにします。 - human-in-the-loop を残す
案件ステージ更新、値引き確定、外部送信のような重い操作は、下書きや候補提示まではAI、確定は人、という境界を残す方が実務に合います。
この5点は、SoAの実行制御 や AIエージェント ガバナンス と同じで、AIの自由度より業務責任の切り方を優先する考え方です。
最初のユースケースは「強い更新」より「判断補助付きの下書き」から始める
Agentforce対応を急ぐ会社ほど、最初から広い自動更新を狙いがちです。ただ、既存自動化の再利用で成果を出しやすいのは、影響が限定され、承認しやすい工程です。
| 最初に向く用途 | AIの役割 | 人が残すべき役割 |
|---|---|---|
| 商談後の要点整理 | 入力値の整形、次アクション候補の作成 | 内容確認と最終保存 |
| 割引条件や在庫の照会 | 対象の特定、既存Flow/Apexの呼び出し | 例外時の判断 |
| 案件更新候補の下書き | 項目候補、優先度、理由の提示 | ステージ確定、対外約束 |
逆に、system contextで一気に更新する古い自動化や、画面操作と密結合したフローを最初の対象にすると、Agentforceの価値検証より事故防止の方に時間を取られやすくなります。
Salesforce運用がすでに整っている会社なら、こうした小さな成功パターンを起点に横展開しやすくなります。一方で、入力率や項目定義が崩れているなら、先に CRM定着の論点 を直す方が効果的です。
参照元
本記事は、Salesforce Blog の2026年6月17日付記事「Make Your Existing Automation Agent-Ready」と、Salesforce Developer Documentation の @InvocableMethod、WITH USER_MODE、Agentforce custom actions の公開情報をもとに整理しています。
よくある質問
Salesforceの既存FlowやApexをAIエージェント対応にするには何から始めるべきですか？
最初は、単機能で入力と出力が明確な autolaunched Flow や invocable Apex だけを候補にします。複数責務の大きな自動化を一気に公開するより、安全な成功パターンを先に作る方が進めやすくなります。
Agentforceのcustom actionに向く自動化と向かない自動化はどう見分けますか？
単機能で責務が狭く、入力値と戻り値が明示できるものは向いています。system context前提の更新、画面依存の操作、複数処理が混ざる自動化は、そのままでは向きません。
autolaunched Flow と invocable Apex はどう切り出せば安全ですか？
Flowなら画面やトリガーから業務ロジックを分離し、明示的な入出力変数を持たせます。Apexなら @InvocableMethod と wrapper class を使い、typed data contract を固定すると安全です。
AgentforceでSalesforce更新を任せる前に何を決めるべきですか？
少なくとも、読み取り範囲、更新可能範囲、fault message、user context、人の承認点を先に決めるべきです。AIが候補を返す段階と、確定更新する段階を分けると事故を減らせます。
関連ページと関連記事
このテーマは、Agentforceの概念だけでなく、接続面、権限設計、CRM運用の土台とあわせて読むと実務に落とし込みやすくなります。
- Agentforce 360とは？SalesforceがAI CRMへ進む理由とHeadless 360との関係：Agentforce全体構想を先に確認できます。
- Salesforce Headless 360とは？API・MCP・CLI化がCRM運用に与える意味を整理する：画面外からの接続面を補えます。
- MCPでSalesforce連携するには？AIエージェント接続で押さえる実務論点：接続時の権限、承認、監査を整理できます。
- AIエージェント ガバナンスとは？権限、監査ログ、承認フローの設計を整理する：統制設計を深掘りできます。
- CRM定着とは？入力されない、更新されない状態をどう直すか：基盤の前提条件を点検できます。
SalesforceのAI実装境界を整理したい場合
Agentforceに既存のFlowやApexをつなぐ前に、どの処理を候補にするか、どこで人の承認を残すか、Google Workspaceや他の業務導線とどうつなぐかを整理しておくと、PoCの手戻りを減らせます。
