LWCからAgentforceへ未保存値を渡す～lightning/accApiで業務画面から会話を段階的に進めてみた～

2026.08.17

#Salesforce #Agentforce #LWC #lightning/accApi

Salesforce Summer ’26では、Lightning Web Components（LWC）から標準Agentforceパネルを操作するためのヘッドレスモジュール「lightning/accApi」が新たに利用可能になりました。パネルの開閉に加え、指定したEmployee Agentへ自然言語の指示を送れます。
本記事では、商談レコードページに「値引申請アシスタント」を配置し、保存済みの商談情報とLWC上の未保存入力値を1つの指示にまとめて送信しました。さらに、同じAgentforce会話へ「稟議文を作成」「承認者の懸念を予測」という2回目・3回目の指示を送れるかを実機で確認します。

 
本記事は2026年8月時点の公式仕様と検証環境での実機結果を基にしています。
Agentforceの機能は更新頻度が高いため、導入時は最新の公式ドキュメントも確認してください。

lightning/accApiとは

lightning/accApiは、Agentforce Conversation Client API（ACC API）をLWCから利用するためのヘッドレスモジュールです。Lightning Experienceのデスクトップ環境にある標準Agentforceパネルを、カスタムLWCからプログラムで操作できます。

 
3メソッドはいずれも非同期でPromiseを返します。複数の要求はキューに入り、順番に処理されます。一方、execute()はAgentの回答本文をLWCへ返さず、特定のAgent Action名を引数で直接実行することもできません。

lightning/accApiを使わなくてもできたこと

lightning/accApiによって、初めてAgentforceへ定型的な質問を送れるようになったわけではありません。従来も、ユーザーはパネルを手動で開き、自由入力または「会話のおすすめ」から会話を開始できました。ようこそのおすすめと会話中のおすすめは、Employee Agentの既存機能として提供されています。
また、現在のレコードIDを発話やコンテキストとしてAgentへ渡し、Prompt Builderやレコード取得アクションを用意すれば、商談に保存されている金額・値引率・粗利率などを使った処理も構成できます。したがって、「保存済みの現在レコードを対象に、1つの定型処理を行う」だけでは、LWCを追加する必然性は大きくありません。
なお、従来からAgent Quick Actionを使えば、レコードページ上のボタンからAgentforceパネルを開き、現在のレコードIDを含む定型的な発話を送信できます。その先でPrompt BuilderをAgent Actionとして利用すれば、対象レコードのIDや保存済み項目をプロンプトへ差し込む構成も可能です。したがって、「レコードページ上のボタンから、現在の商談IDや保存済み情報を使った処理を開始すること」自体は、カスタムLWCだけの特徴ではありません。

LWC ＋lightning/accApiを使う価値

今回の価値は、レコードIDや保存済み項目を扱えることそのものではなく、LWCが保持する画面状態を使って発話をプログラムで組み立てられる点です。特に、レコードへまだ保存していない入力値、ユーザーがその場で選択した条件、一覧で選んだ複数ID、LWC内の計算結果などを、長い指示文へ動的に整形して送れます。

従来のAgentforceパネル利用と、LWC＋lightning/accApiを組み合わせた場合の違い

図は、Agentforceパネル内の自由入力や「会話のおすすめ」を中心に利用する場合と、LWC ＋lightning/accApiを組み合わせる場合を比較したものです。従来方式でも、保存済みの商談情報を利用した会話や、パネル内での自由な追加質問は可能です。また、Agent Quick ActionとPrompt Builderを組み合わせれば、レコードページ上のボタンから現在のレコードIDを含む定型発話を送り、保存済み項目を利用することもできます。
今回の差は、LWC上の未保存値や選択結果など、レコード外の画面状態を含む長い指示を動的に生成し、業務画面上のボタンから同じAgentforce会話を段階的に進められる点にあります。
本記事では、このうち「未保存値の引き渡し」と「2回目・3回目の指示送信」を中心に検証します。

今回の検証シナリオ

商談レコードページに「値引申請アシスタント」のLWCを配置しました。
ユーザーは商談の現在値を確認しながら、今回検討している値引条件をLWCへ入力します。
入力値は商談へ保存せず、LWCがAgentforceへ指示を送信します。

商談レコードページに配置した「値引申請アシスタント」LWC

検証環境

保存済みの商談情報とLWC上の未保存入力値を統合し、Agentforceへ送る流れ

実装のポイント

現在の商談IDと対象Agentを分けて扱う

商談レコードページでは、Salesforceが現在のレコードIDをrecordIdへ自動設定します。一方、どのEmployee Agentを開くかはbotIdとしてLightning App Builderから設定します。

JavaScript：recordIdとbotId

import { LightningElement, api, wire } from 'lwc';
import { open, close, execute } from 'lightning/accApi';

export default class OpportunityDiscountAgent extends LightningElement {
    @api recordId; // 現在表示中の商談ΙⅮ
    @api botId;    // 対象Employee AgentのΙⅮ
}

保存済み項目はLWC側で取得する

今回の検証では、UI Record APIのgetRecordを使って必要な商談項目を取得しました。項目を限定して取得し、LWC上の未保存入力と明確に区別して指示へ含めています。

JavaScript：保存済み商談情報の取得（抜粋）

import { getRecord, getFieldValue } from 'lightning/uiRecordApi';
import OPPORTUNITY_AMOUNT from '@salesforce/schema/Opportunity.Amount';
import CURRENT_DISCOUNT_RATE
    from '@salesforce/schema/Opportunity.CurrentDiscountRate__c';
import GROSS_MARGIN_RATE
    from '@salesforce/schema/Opportunity.GrossMarginRate__c';

const FIELDS = [
    OPPORTUNITY_AMOUNT,
    CURRENT_DISCOUNT_RATE,
    GROSS_MARGIN_RATE
];

@wire(getRecord, { recordId: '$recordId', fields: FIELDS })
opportunity;

 
※掲載コードは要点を抜粋しています。値取得処理の記載を省略しているため、importしたgetFieldValueの使用箇所はこの抜粋には含めていません。

未保存入力を含む発話内容を動的に生成する

「申請前チェック」では、保存済み情報とLWC上の未保存条件を1つのutteranceへ整形します。未保存値であること、レコードを更新しないこと、回答形式、推測禁止まで指示に含めました。
JavaScript：初回の動的指示（要点を抜粋）

const utterance = `
以下の商談について、値引申請前のチェックを行ってください。

【保存済みの商談情報】
・商談ΙⅮ：${this.recordId}
・商談金額：${this.formatCurrency(this.amount)}
・現在の値引率：${this.formatPercent(this.currentDiscountRate)}
・粗利率：${this.formatPercent(this.grossMarginRate)}

【LWC上で入力した未保存の申請条件】
・申請予定値引率：${this.requestedDiscount}%
・今回の申請理由：${this.requestReason}
・重視する観点：${this.analysisPoint}
・申請に関する補足：${this.additionalComment}

保存済み情報と未保存情報を区別してください。
商談レコードは更新せず、不明な内容は推測しないでください。
`;

await open(this.botId);
await execute(utterance, this.botId);

2回目・3回目 もexecute()で送信する

execute()は会話開始専用ではありません。今回のLWCでは、初回送信後に後続ボタンを有効化し、同じパネルを閉じずに追加指示を送りました。2回目以降は商談情報を再送せず、「これまでの会話内容」を参照する短い指示としています。

JavaScript：会話途中の追加指示（要点を抜粋）

async handleCreateApprovalText() {
    await execute(`
これまでの会話内容と未保存の値引申請条件を踏まえて、
値引承認者へ提出する稟議文案を作成してください。
`, this.botId);
}

async handlePredictConcerns() {
    await execute(`
これまでの会話内容を踏まえて、承認者から指摘されそうな点を
重要度の高い順に3つ挙げてください。
`, this.botId);
}

LWCの業務ボタンから同じAgentforce会話を段階的に進める流れ

Agent IDはLightning App Builderで設定する

botIdを設計属性として公開すると管理者がコードを変更せず、配置先ごとに対象Agentを指定できます。

js-meta.xml：botIdの設計属性（抜粋）

<targetConfig targets="lightning__RecordPage">
    <objects>
       <object>Opportunity</object>
    </objects>
   <property
        name="botId"
        type="String"
        label="Agentforce Agent ID"
        required="true" />
</targetConfig>

実機検証結果

「申請前チェック」で初回の動的指示を送る

LWCへ「申請予定値引率20%」「申請理由：競合対抗」「重視する観点：収益性」を入力し、「申請前チェック」を押しました。指定したEmployee Agentのパネルが自動で開き、保存済み商談情報と未保存条件を含む長い指示が送信されました。

「申請前チェック」ボタンから、保存済み情報とLWC上の未保存値を含む指示を送信

ここで確認できたのは、パネルの起動だけではありません。recordId、商談項目、ユーザーの画面入力、出力形式、更新禁止などを1つの発話へ組み立て、ユーザーの手入力なしで送信できました。

「稟議文を作成」で2回目の指示を送る

初回の回答を確認した後、同じLWCの「稟議文を作成」を押しました。2回目の指示には商談情報を再掲せず、「これまでの会話内容」「先ほど提示した未保存の申請条件」を踏まえるよう依頼しています。Agentforceは同じパネル内の前段情報を利用し、稟議文案を生成しました。

「稟議文を作成」ボタンから同じ会話へ2回目の指示を送信

「承認者の懸念を予測」で3回目の指示を送る

さらに「承認者の懸念を予測」を押すと、初回の商談情報と未保存条件、前段の会話を前提に、承認者から想定される指摘・根拠・回答案・追加情報を整理しました。これにより、LWCの3つの業務ボタンから同じ会話を段階的に進められることを確認しました。

「承認者の懸念を予測」ボタンから同じ会話へ3回目の指示を送信

検証して分かったこと

3段階の検証結果を、ACC APIで確認できた挙動と、別途設計が必要な領域に分けて整理します。

既存パネルだけの場合より進化した点

今回の構成は、Agentforceの推論能力そのものを増やしたわけではありません。進化したのは、業務画面と会話の接続方法です。

• 未保存値を自動で渡せる：ユーザーが会話欄へ20%や申請理由を再入力する必要がない。
• 長い指示を標準化できる： 保存済み／未保存の区別、更新禁止、回答形式、推測禁止を毎回同じ品質で送れる。
• 業務手順を画面上に提示できる： 「申請前チェック → 稟議文 → 承認者の懸念」という順序をボタンで案内できる。
• 自由会話を失わない： ボタンによる構造化された入口の後も、パネル内でユーザーが追加質問できる。

制約と実装上の注意点

回答本文はLWCへ返らない

execute()の戻り値はPromiseであり、Agentforceの回答テキストをJavaScript変数として受け取れません。回答を解析して画面を自動分岐する、項目へ保存する、別処理へ引き渡す用途には、このAPI単独では対応できません。

後続操作は利用者による回答確認を前提にする

ACC APIでは、複数の要求はキューに入り、順番に処理されます。ただし、LWCからパネル内の回答内容や表示状況を取得して、利用者が回答を確認したかを判定する仕組みではありません。今回のUIでは、利用者がパネルに表示された回答を確認してから、次の業務ボタンを押す運用としました。

特定のAgent Actionを直接指定できない

execute()で送れるのは自然言語の発話です。Agent Action名を引数に渡して確実に実行するAPIではありません。特定の業務処理へ安定してルーティングしたい場合は、Agent側のサブエージェント、Agent Actionの説明、指示を設計し、テストする必要があります。

自由入力を命令文と分離して渡す

LWC上の自由入力を発話へ組み込む場合は、入力値を命令文とは分離した参考データとして扱うことを明示し、区切りや文字数制限、入力チェックを設けます。掲載コードでは未保存入力を項目名付きで区別していますが、本番実装では自由記述欄の内容を信頼済みの命令として扱わず、必要な情報だけに絞って送る方が、安全性・コスト・可読性・回答の安定性の面で有利です。

権限と機密情報を別途確認する

LWCやApexで取得した情報をAgentforceへ渡す前に、利用者が閲覧できる情報だけを扱う設計にします。今回のようにUI APIを使う場合でも項目アクセスを検証し、Apexを追加する場合は共有設定、CRUD、項目レベルセキュリティを明示的に考慮します。

今回は未検証の範囲

• パネルを閉じて再度開いた後も、同じ会話が継続するか
• 異なるbotIdへ切り替えた場合の会話状態
• 短時間に複数ボタンを連打した場合のユーザー体験
• 専用Prompt Builder／Agent Actionを組み込んだ本番相当の精度・権限制御

どのような場面に向いているか

 
採用判断の分かれ目は、「レコードページ上のボタンからAgentforceを呼べるか」ではありません。固定発話と現在のレコードID、保存済み項目で足りるなら、会話のおすすめやAgent Quick Action、Prompt Builderを組み合わせた既存構成で十分な場合があります。一方、LWC上の未保存入力、ユーザーの選択結果、複数ID、計算結果など、業務画面にしか存在しない動的な情報を会話へ渡す必要がある場合は、lightning/accApiとカスタムLWCの価値が大きくなります。

まとめ

lightning/accApiを使うと、カスタムLWCから標準Agentforceパネルを開閉し、指定したEmployee Agentへ自然言語の指示を送信できます。今回の検証では、商談レコードページ上のLWCから、保存済み商談情報と未保存の申請条件を組み合わせた発話を送れました。
さらに、execute()を繰り返し呼び出すことで、「申請前チェック → 稟議文を作成 → 承認者の懸念を予測」という3段階の業務ボタンから、同じパネルの会話を継続できました。これは単なる起動ショートカットではなく、構造化された業務画面と自由な対話を往復させる使い方です。

一方、Agentforceの回答はLWCへ返らず、Agent Actionを直接指定することもできません。また、ACC APIでコンテキストを正しく渡せても、生成内容の業務精度は別途設計が必要です。Prompt Builder、Agent Action、グラウンディング、権限制御、人による確認を組み合わせて初めて、本番業務に耐える仕組みになります。
今回の実装から、lightning/accApiの実務上の価値は、単にレコードページ上のボタンからAgentforceを開くことではなく、LWC上の未保存値や選択結果を含む動的な発話を生成し、業務画面の入力や手順に会話を自然に組み込める点にあると評価できます。

＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！

医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら