Agent Scriptとは？Agentforceの定義をコードで管理する判断基準

Agentforceのエージェントは画面上の設定だけで作れるため、コードを書く必要はないと言われています。しかし、指示文の修正が毎週のように続き、定義を触る担当者が複数になった段階で、誰がいつ何を変えたのかを画面から追えなくなり、手戻りが起きている企業も少なくないのではないでしょうか。Agent Scriptとは、Agentforceのエージェント定義を、指示文・変数・遷移条件までコードとして記述するための言語のことです。 なお、Agentforceの機能名と提供状況は更新が続くため、本記事は2026年8月時点の情報にもとづいています。

そこで本記事では、Agentforceの定義をコードで管理すべきかどうかの判断基準から、コード化できる層とUIでの設定が必要な層の切り分け、Agentforce DXで変更履歴と配布を回す手順までを解説します。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供している。

Agentforceの運用でGUIが限界になる3つの状況

産業機器を製造する中堅メーカー（従業員約600名・営業70名）の情報システム部では、昨年に画面上の設定だけで作った営業向けのエージェントを、2名で運用してきました。この会社では営業現場からの要望を受けて指示文を直す作業が毎週のように続き、先月には「先週戻したはずの指示文が、また元に戻っている」という事故が起きています。そこでここでは、この会社を例に、Agentforceの運用でGUIが限界になる3つの状況を整理します。

GUIでの運用が限界を迎えるのは、エージェントが動かなくなった時点ではありません。定義の変更を誰も再現できなくなった時点が、GUIでの運用の限界です。

状況①指示文のチューニングが何十回も続いている

1つ目は「指示文のチューニングが何十回も続いている」という状況です。エージェントを公開した直後は、想定していなかった質問や、意図とずれた回答が必ず出てきます。その都度、指示文に条件を1行足し、言い回しを変え、参照させる項目を入れ替える作業が発生します。

この修正が一度で終わることは、まずありません。営業担当者が実際の商談で使い始めると、「この場面ではこう答えてほしい」という要望が次々と挙がってくるからです。

実際に、この産業機器メーカーでは、初回訪問前の情報整理を任せたエージェントの指示文を、直近半年で42回修正していました。1回あたりの作業は5分から10分で終わる小さなもので、情報システム部の担当Aが画面上で直し、そのまま保存していたのです。ところが42回のうち、どの修正がどの要望に対応したものかを説明できる記録は、どこにも残っていませんでした。

修正の回数が二桁に届いた時点で、変更の内容を残す仕組みを用意すべきだと考えます。営業向けエージェントの設計については、ほか記事「Agentforce for Sales｜SDR・Sales Coachの使い方と営業活用事例」で解説していますので、ぜひ参考にしてもらえると嬉しいです。

状況②定義を複数人でレビューしている

2つ目に挙げるのは、エージェントの定義を複数人で確認している状況です。担当者が1人だけなら、変更の理由はその人の記憶に残ります。確認する担当者が加わった瞬間、記憶は共有できない情報になります。

Agentforceの画面には、指示文の変更前と変更後を並べて表示する機能がありません。そのため確認する側は、変更後の文面だけを読んで、どこが変わったのかを推測することになります。

この会社では、担当Aが直した指示文を担当Bが確認する運用にしていました。担当Bは変更後の指示文を上から読み直し、気になった箇所を口頭で質問していたのです。1回の確認に20分ほどかかっており、それでも「変わっていない箇所まで読み直している」という感覚が残っていました。担当Bが読んでいたのは指示文の文面だけで、アクションの配線まで確認する余裕はありませんでした。

確認する担当者が読むべきなのは、定義の全文ではありません。変更された行だけです。

状況③Sandboxから本番へ何度も移送している

3つ目は、Sandbox組織で直した定義を、本番組織へ何度も移す状況です。修正の頻度が上がれば、そのまま移送の頻度も上がります。

移送の操作自体は難しくありません。ただ、手作業で進める限り、移し忘れと移しすぎの両方が起こります。

この産業機器メーカーの移送は月に3回から4回で、担当Aが変更セットを作って本番へ反映していました。先月起きた事故は、この工程で発生しています。担当Aが前の週に戻した指示文を含む古い変更セットを、別の修正と一緒に本番へ流してしまい、戻したはずの内容が復活したのです。営業担当者から「回答が先週の状態に戻っている」という連絡が入るまで、担当Aも担当Bも気づけませんでした。

移送が月に複数回発生している組織では、この種の事故は運用の注意深さでは防げません。以上が、Agentforceの運用でGUIが限界になる3つの状況でした。

Agentforceの運用が属人化する3つの原因

前章では、Agentforceの運用でGUIが限界になる状況を3つ整理しました。ただ、指示文の修正が多いことも、複数人で確認していることも、それ自体は前向きな運用の結果です。問題は、その運用を続けるほど特定の担当者しか状況を把握できなくなる点にあります。そこでここでは、Agentforceの運用が属人化する3つの原因を、画面の仕様に立ち返って解説していきます。

属人化が起きるのは、変更の履歴と確認の経緯を保存する場所が、Agentforceの画面に用意されていないからです。

原因①誰がいつ何を変えたか追えないから

まず1つめに挙げたいのは、誰がいつ何を変えたのかを、あとから追えないからです。Agentforceの画面は、いま有効になっている定義を表示するようにできています。過去にどういう文面だったかは、保存した時点で上書きされます。

そもそも、なぜこの構造が問題になるのかという話ですが、エージェントの回答品質が落ちたときに、原因を切り分ける材料が残らないからです。回答が変わったのは指示文を変えたからなのか、参照するデータが変わったからなのかを、担当者は推測で判断することになります。

この産業機器メーカーでも、営業担当者から「以前より回答が長くなった」という指摘を受けたとき、担当Aは直前の2週間に自分が直した箇所を思い出しながら1つずつ戻していきました。原因の特定に半日かかり、結局は文字数の上限を外した1行の修正が原因でした。切り分けの間は、営業担当者にエージェントの利用をいったん止めてもらう必要もありました。

変更の履歴が残っていれば、この作業は差分を数分読むだけで終わります。

原因②レビューの経緯が画面に残らないから

次に、確認した担当者の指摘とその対応が、画面のどこにも保存されないからです。指摘は口頭やチャットで交わされ、修正が終われば流れていきます。

残らない情報のなかで、あとから最も必要になるのは「なぜその書き方にしなかったのか」という判断です。採用した案は定義として残りますが、見送った案とその理由は消えます。

担当Bは、初回訪問前の情報整理を任せるエージェントについて、参照する過去商談を3年分に絞るよう担当Aへ指摘していました。件数が多いと回答の焦点がずれるという理由からです。ところが半年後、別の要望に対応するなかで参照範囲が5年分へ戻され、そのときには絞った理由を誰も説明できませんでした。

同じ議論を二度やり直す状態を避けるには、指摘と対応を変更の記録に紐づけて保存する必要があります。

原因③環境ごとの設定差分を目視で照合しているから

3つ目の原因は、Sandbox組織と本番組織の設定が同じかどうかを、担当者が画面を見比べて確認しているからです。エージェントの定義は、指示文・アクションの配線・変数の初期値と、確認すべき項目が分散しています。

目視での照合は、項目が増えるほど見落としが出ます。しかも見落としたことに気づくのは、本番で想定と違う回答が出たあとです。

この産業機器メーカーのエージェントは、サブエージェントが5本、そこに配線されたアクションが18件という構成でした。担当Aは移送のたびに両方の組織の画面を開き、指示文とアクションを順に見比べていましたが、1回の照合に40分近くかかっていたのです。それでも先月の事故は防げませんでした。

人の目で照合している限り、確認にかけた時間と見落としの少なさは比例しません。以上が、Agentforceの運用が属人化する3つの原因でした。

Agentforceをコード管理にする3つの判断基準

ここまで、GUIでの運用が限界になる状況と、その背景にある原因を整理してきました。とはいえ、原因が分かったからといって、すべての組織がコード管理へ移るべきだとは考えていません。移行には工数がかかるため、割に合う状態かどうかを先に判断する必要があります。そこでここでは、Agentforceをコード管理に移すかどうかの判断基準を3つに整理します。

コード管理へ移るかどうかは、変更頻度・担当者の人数・移送の頻度という3つの条件がそろっているかで判断できます。

基準①定義の変更が週単位で発生していること

1つ目の基準は「定義の変更が週単位で発生していること」です。ここで数える対象は、指示文の1行の修正から、アクションの追加までを含めた変更の回数になります。

週に1回という水準を境目に置いているのは、変更の間隔が1週間を切ると担当者の記憶だけでは経緯を保持できなくなるからです。月に1回程度であれば、前回の修正内容は思い出せます。

先ほどの産業機器メーカーは、半年で42回、つまり週に1.6回のペースで指示文を修正していました。営業部門からの要望が月に8件前後で起票され、そのうち半分ほどが指示文の調整で対応できる内容だったためです。担当Aは3週間前の修正について聞かれたとき、内容を思い出せませんでした。

変更が週単位で起きているなら、記録の仕組みを人の記憶の外に置きましょう。

基準②定義を触る担当者が2人以上いること

2つ目に確認したいのは、エージェントの定義を編集できる担当者が2人以上いるかどうかです。ここでの人数には、日常的に編集する担当者だけでなく、権限を持っている担当者すべてを含めます。

権限を持つ担当者が複数いる状態では、同じ定義を同時に触る事態が起こります。Agentforceの画面は、あとから保存した内容を有効にする仕様のため、先に保存した変更は通知もなく消えます。

この産業機器メーカーでは、担当Aと担当Bの2名が編集権限を持っていました。ある週、担当Aが商談後のフォロー用の指示文を直している間に、担当Bが別の要望で同じサブエージェントを開いて保存し、担当Aの修正が消えたことがあります。二人が気づいたのは翌日、営業担当者から要望が反映されていないと連絡を受けたときでした。

編集できる担当者が2人以上いる時点で、変更を並行して扱える仕組みが必要になります。

基準③環境間の移送が定常業務になっていること

3つ目は、Sandbox組織から本番組織への移送が、例外的な作業から定常業務へ変わっていることです。年に数回のリリースであれば、その都度手順を確認しながら進めても問題は起きにくいでしょう。

一方で、移送が月に複数回に増えると、手順を確認する時間が惜しくなり、担当者が前回と同じ操作を記憶で繰り返した結果、移し忘れと移しすぎが起こります。

先ほどの会社の移送は月3回から4回で、変更セットの作成から本番反映までを担当Aが1人で担当していました。作業自体は30分ほどで終わるものの、どの変更セットに何を含めたかの一覧は担当Aの手元のメモにしかなく、担当Bは中身を確認できない状態だったのです。

移送が定常業務になっているなら、手順を設定として固定できるかどうかで判断しましょう。以上が、Agentforceをコード管理にする3つの判断基準でした。

AgentforceをGUIのまま運用してよい3つの組織

前章では、コード管理へ移るかどうかの判断基準を3つ示しました。ここで同じくらい大事なのは、移らないという判断も正しい選択になりうる点です。コード管理には工数がかかるため、その工数を払う理由がない組織まで移行を勧めるのは誠実ではありません。そこでここでは、AgentforceをGUIのまま運用してよい組織の条件を3つ解説します。

コード管理に移らない判断は、体制の不足を意味しません。いまの運用規模に必要な仕組みがすでに足りているなら、GUIのまま運用を続ける判断が正しい選択になります。

組織①エージェントの定義を触る担当が1人で完結している

1つ目は、エージェントの定義を編集する担当者が1人だけで、その1人が変更の経緯も把握している組織です。この状態であれば、変更の履歴は担当者の作業メモで十分に管理できます。

担当者が1人という条件は、少人数の会社に限りません。エージェントを1業務だけで使っており、その業務の担当部署が決まっている場合も同じです。

たとえば、ある事務機器の販売会社では、問い合わせの一次対応にだけエージェントを使い、カスタマーサポートの管理者1名が月に1回まとめて指示文を見直していました。変更の内容は、その月の作業記録として残していたのです。確認する担当者がいないため、経緯を共有する相手もいませんでした。

編集する担当者が1人で完結しているうちは、画面上での設定を続けるほうが速く進みます。少人数の体制でAgentforceを使う進め方は、ほか記事「中小企業のAgentforce導入ガイド」で詳しく解説しています。

組織②指示文の変更が四半期に1回程度にとどまっている

次に、指示文の変更が四半期に1回程度で落ち着いている組織です。変更が少ないのは、エージェントに任せた業務の範囲が明確で、想定外の質問が入ってこないためだと考えられます。

変更の頻度が低い状態では、コード管理で得られる利点も小さくなります。差分を残す仕組みを作っても、その差分が年に4回しか発生しないからです。

ある建材メーカーでは、社内の経費精算の質問に答えるエージェントを運用しており、規程が改定される期初にだけ指示文を直していました。改定の内容は規程の文書として残るため、エージェント側の履歴を別に持つ必要もありません。担当者は改定の番号を指示文のコメントへ書き添えており、どの改定に対応した修正かは、その番号からたどれる状態でした。

変更の頻度が四半期に1回にとどまっているなら、いまの管理方法を変える必要はないでしょう。

組織③本番組織で直接編集して運用が回っている

3つ目は、Sandbox組織を経由せず、本番組織で直接編集して運用が続いている組織です。この進め方は乱暴に見えますが、エージェントの利用範囲が限られていれば実務として成立します。

成立する条件は、誤った回答が出たときの影響範囲が小さく、すぐに戻せることです。社内向けのエージェントで、利用者が数名にとどまる場合が該当します。

ある物流会社の情報システム部は、自部門のヘルプデスク業務にだけエージェントを使っており、指示文を直してその場で試し、問題があればすぐ元に戻していました。移送の工程が発生しないため、環境間の設定差分も生まれません。

ただし、利用部署が2つ以上に広がった時点で、この進め方は続けられなくなります。以上が、AgentforceをGUIのまま運用してよい3つの組織でした。

Agentforceの定義をコード化する3つの効果

コード管理に移る組織と移らない組織の条件は、これで出そろいました。移ると判断した場合、次に確認したいのは、実際に何が変わるのかという点です。ここで挙げる効果は、先に整理した属人化の3つの原因と1対1で対応しており、原因のどれが自社に当てはまるかで、優先して得たい効果も変わります。そこでここでは、Agentforceの定義をコード化して得られる効果を3つ整理します。

コード化で得られるのは、変更の経緯を担当者の記憶から切り離して保存できる状態です。

効果①誰がどの指示文を変えたかがコミット単位で残る

1つ目の効果は、誰がどの指示文をどう変えたかが、コミットという単位で保存されることです。コミットとは、変更した内容とその説明をひとまとまりにして記録する操作を指します。

原因①で挙げた過去の文面を追えない問題は、定義をテキストのファイルとして扱えば解消します。変更前と変更後の両方が、履歴として残るためです。

この産業機器メーカーで「以前より回答が長くなった」という指摘に半日かけていた切り分けは、コード管理へ移したあと、直近2週間のコミットを一覧で開くだけで済むようになりました。文字数の上限に関する行が変わったコミットは1件しかなく、担当Aはその日付と変更内容をその場で営業担当者へ返せたのです。

切り分けにかかる時間は、履歴を残しているかどうかで、半日と数分に分かれます。

効果②レビューの経緯が差分に紐づいて保存される

2つ目に挙げるのは、確認した担当者の指摘と、それに対する修正が、変更の差分に紐づいて保存される点です。指摘はコメントとして差分の該当行に付き、修正すればその履歴も同じ場所に並びます。

原因②で挙げた「見送った案とその理由が消える」問題は、採用しなかった案も指摘のやり取りとして残るため、この形で解消できます。

担当Bが「参照する過去商談を3年分に絞りたい」と指摘した経緯は、コード管理へ移したあと、該当行のコメントとして保存されました。半年後に参照範囲を広げる要望が来たとき、担当Aはそのコメントを開き、絞った理由を営業企画部長へ説明したうえで判断を仰いでいます。

逆にいえば、指摘を口頭やチャットで交わしている限り、記録の形式を変えても判断の経緯は残りません。

効果③環境間の設定差分を目視せずに検出できる

3つ目は、Sandbox組織と本番組織の設定の違いを、画面を見比べずに検出できることです。両方の組織から定義を取得してファイルとして比較すれば、違う行だけが表示されます。

原因③で挙げた目視での照合は項目が増えるほど見落としが増えましたが、比較の対象がテキストになると、項目の数が増えても検出の精度は変わりません。

この産業機器メーカーの照合は、サブエージェント5本とアクション18件を画面上で突き合わせて1回40分かかっていました。コード管理へ移したあとは、両組織から取得した定義の差分を出す操作に置き換わり、担当Aは表示された数行を読むだけで違いを確認できています。

ただし、画面でしか設定できない対象は差分に現れないため、データ基盤の設定は別に記録しておく必要があります。以上が、Agentforceの定義をコード化する3つの効果でした。

Agentforceの定義を切り分ける3つの層

ここまで、コード化によって得られる効果を整理してきました。ただ、Agentforceの設定すべてをコードに置き換えられるわけではありません。対象によって、コードで完結するもの、使い分けが必要なもの、画面での設定が欠かせないものに分かれます。そこでここでは、Agentforceの定義を3つの層に切り分けて、それぞれの扱いを解説していきます。

エージェント本体はコードで完全に置き換えられますが、データ基盤に近づくほど画面での設定が必要になります。

層①コードで完全に置き換えられるエージェント層

1つ目の層は、エージェント本体・サブエージェント・指示文・アクションの配線をまとめたエージェント層です。この層は、画面でできる設定のすべてをコードで記述できます。

なぜなら、画面での操作もコードでの記述も、表示の形式が違うだけで、最終的には同じ定義を編集しているからです。

この産業機器メーカーがコード管理へ移した対象も、まずはこの層だけでした。サブエージェント5本とその指示文、配線した18件のアクションをファイルとして取得し、以降の修正はすべて手元で行う運用に切り替えたのです。移行の作業自体は2日で終わり、既存のエージェントを作り直す必要はありませんでした。

日々の修正が集中する層でもあるため、コード管理の効果が最も大きく出るのはここです。

層②コードとUIを使い分ける部品層

2つ目は、Apexクラス・プロンプトテンプレート・フローといった、エージェントから呼び出される部品の層です。この層は、コードとして扱える一方で、画面で作ったほうが確実な対象も混ざります。

使い分けが必要になるのは、部品ごとに編集のしやすさが違うためです。Apexクラスはもともとコードなので迷いませんが、プロンプトテンプレートとフローは画面での編集を前提に作られています。

この会社では、Apexクラスは以前からソース管理の対象に入っていたため、そのまま同じ扱いを続けました。一方でプロンプトテンプレートは、画面で編集して結果を確かめてから取得する手順に変え、フローは画面での編集だけに限定しています。

部品層は、対象ごとにどちらで編集するかを決めて文書に残しましょう。Agentforceの機能の全体像は、ほか記事「Agentforceの機能一覧」をご確認ください。

層③UIでの設定が必要なデータ基盤層

3つ目は、検索インデックス・リトリーバー・データストリームの接続設定といった、データ基盤に関わる層です。この層は、画面での設定が前提になります。

画面での設定が必要な理由は、これらの設定が組織ごとのデータの状態に依存しているからです。同じ設定ファイルを別の組織へ移しても、参照先のデータが同じ形で存在しなければ成立しません。

先ほどの産業機器メーカーは、製品マニュアルを検索対象にしたインデックスを持っていました。コード管理へ移す検討のなかで、この設定もファイル化しようとしましたが、Sandbox組織と本番組織でデータの件数も更新のタイミングも違うため、同じ定義を共有する意味がないと判断しています。

移送しても同じ状態を再現できない設定かどうかで、コード化の対象から外すかを判断しましょう。以上が、Agentforceの定義を切り分ける3つの層でした。

Agentforceでコード化に向かない3つの対象

前章では、Agentforceの定義を3つの層に分けて扱いの違いを整理しました。ここからは、そのなかでもコード化を避けたほうがよい対象を、理由と実際に起きる問題まで含めて掘り下げます。できないことを先に押さえておくと、移行の計画から無理な範囲を外せます。そこでここでは、Agentforceでコード化に向かない対象を3つ整理します。

コード化に向かない対象に共通しているのは、定義の中身が組織ごとのデータや画面上の情報に依存していて、ファイルとして移しても同じ状態を再現できない点です。

対象①検索インデックスの作成設定

1つ目の対象は、検索インデックスの作成設定です。エージェントが社内文書を参照して回答するとき、その文書は事前にインデックスとして処理されています。

この設定をコード化しても管理が成立しないのは、インデックスの実体が処理済みのデータであり、設定ファイルではないからです。設定だけを移送しても、移送先で同じデータが処理されていなければエージェントは何も参照できません。

この産業機器メーカーでは、製品マニュアル約400件をインデックスの対象にしていました。Sandbox組織には検証用に抜き出した40件しか入っておらず、本番組織と同じ状態を再現するには、データを揃える作業が別に必要だったのです。設定の管理方法を変えても、この作業は減りませんでした。

インデックスの設定は、環境ごとに画面で作って記録に残す運用が現実的です。

対象②生成AIが壊すと直せないフローの編集

2つ目に避けたいのは、フローの定義をコードとして編集する進め方です。とくに生成AIに編集を任せる場合、修正できない状態に陥る危険があります。

フローの定義ファイルには、処理の順序だけでなく、画面上での要素の座標と接続の関係が含まれています。人が読んで意味を追える形式ではないため、生成AIが座標や接続を書き換えてしまうと、どこが壊れたのかを特定できません。

見積の履歴を整形するフローでは、担当Aがファイルを取得して手元で編集し、条件の分岐を1つ足したことがありました。反映したあとに画面で開くと要素が重なって表示され、担当Aは接続がどこで外れたのかを特定できませんでした。結局、画面で最初から作り直したほうが速く、編集を試した2時間は回収できていません。

フローは画面で作り、ファイルは取得したものをそのまま保存する対象として扱いましょう。

対象③データストリームの接続設定

3つ目は、外部システムとのデータストリームの接続設定です。ここには接続先の情報と認証の設定が含まれます。

接続設定をコードとして共有できないのは、認証情報を含む設定をファイルに残す運用を避けるべきだからです。仮に認証情報を分離しても、接続先のシステムが環境ごとに違えば、設定の大部分は組織ごとに書き換えることになります。

この会社は、基幹システムの出荷実績をエージェントから参照できるようにしていました。Sandbox組織の接続先は検証用のサーバーで、本番組織とは接続先も認証の方式も違っていたため、同じ設定を共有する余地がありません。

接続先が環境ごとに違う設定は、コード化の計画から最初に外しておくと、移送でつまずく箇所を減らせます。以上が、Agentforceでコード化に向かない3つの対象でした。

Agent Scriptがコード管理を支える3つの特徴

ここまで、コード化する対象と外す対象を判断の観点から整理してきました。ここからは、その判断を実際の運用に落とし込む手段の話に入ります。エージェント層をコードとして書くための言語が、Agent Scriptです。画面での設定に慣れた担当者ほど、新しい言語を覚える負担が気になるのではないでしょうか。そこでここでは、Agent Scriptがコード管理を支える特徴を3つ解説します。

Agent Scriptは、自然言語の指示文と、必ず通す処理の指定を、1つの定義のなかに書き分けられる言語です。

特徴①決定論的な処理を明示的に指定できる

1つ目の特徴は、必ず同じ手順で通したい処理を、式として明示的に指定できる点です。Agent Scriptは、自然言語の指示文と、条件分岐やアクションの実行といった記述を、同じ定義のなかに書けるように設計されています。

指示文だけでエージェントを組むと、同じ質問でも回答の内容や手順が毎回変わります。文章による依頼は解釈の幅を残すため、モデルが毎回同じ判断をするとは限りません。

この産業機器メーカーの営業向けエージェントでも、「過去の類似案件を確認してから回答する」という指示を文章で書いていたにもかかわらず、案件を参照せずに一般論だけを返す回答が月に数件ありました。Agent Scriptでは、この参照を条件付きで必ず実行する処理として書けるため、指示文の言い回しに結果が左右されなくなります。

回答が毎回変わると業務に支障が出る処理かどうかで、式として書くべきかを判断しましょう。

特徴②画面で作った定義がそのまま出力される

次に、画面で作ったエージェントの定義が、そのままAgent Scriptとして読み書きできる点です。Agentforceの開発画面には、視覚的に組み立てるビューと、記述を直接編集するビューがあり、どちらで作業していても編集しているのは同じ定義です。

この構造が実務で意味を持つのは、コード管理へ移るときに既存のエージェントを作り直さずに済むからです。画面で1年運用してきた定義を、そのまま取得して管理の対象にできます。

先ほどの会社が移行を2日で終えられたのも、この点が理由でした。担当Aは、昨年から画面上で組み立ててきたサブエージェント5本の定義を取得し、内容が意図どおりかを確認しただけで、記述は1行も書き直していません。

すでに稼働しているエージェントがあるなら、作り直しの工数を計画に入れる必要はありません。

特徴③言語仕様がオープンソースで公開されている

3つ目は、Agent Scriptの言語仕様が、オープンソースとして公開されている点です。文法・パーサー・リンター・LSP（言語サーバープロトコル）・VS Code拡張・ブラウザ上の編集環境が、Apache 2.0ライセンスでGitHubに公開されています。

公開されていることが実務にもたらす利点は、記述の正しさを手元で検証できることです。エディタが構文の誤りを指摘してくれるため、組織へ反映する前に単純な記述ミスを見つけられます。

一方で、コンパイルした定義を実行するランタイムは公開されていないため、Agent Scriptで書いた定義は、Salesforceの環境がなければ動きません。

※参考記事はこちら

手元のエディタで誤りが出なくても、実際の応答が意図どおりかは、組織で会話を流すまで分かりません。以上が、Agent Scriptがコード管理を支える3つの特徴でした。

Agent Scriptで定義する4つの構成要素

前章では、Agent Scriptがどういう性質の言語かを3つの特徴から整理しました。次に押さえたいのは、この言語で実際に何を書くのかという中身です。書ける対象を把握しておくと、画面での設定のどこまでがコードの管理下に入るのかが見えてきます。そこでここでは、Agent Scriptで定義する4つの構成要素を解説していきます。

Agent Scriptで書けるのは指示文だけにとどまらず、会話をまたいで保持する変数と、別の業務へ移る条件までを含みます。

要素①業務単位で分けるサブエージェント

1つ目の要素は、業務の単位で分けるサブエージェントです。Agent Scriptでは、このサブエージェントを`topic`というブロックとして記述します。

“` topic Order_Management: description: “注文状況の確認と変更に関する問い合わせを扱う” “`

業務の単位で分ける理由は、1つのサブエージェントに複数の業務を詰め込むと、エージェントがどの手順を使うべきかを判断できなくなるからです。分ける粒度は、担当者が「この作業をお願いする」と口に出せる単位が目安になります。

この産業機器メーカーは、初回訪問前の情報整理・商談後のフォロー・見積の履歴確認・製品仕様の照会・過去案件の抽出という5つでサブエージェントを分けていました。営業担当者が依頼する場面がそれぞれ違うため、指示文の修正も業務ごとに独立して進められています。

なお、Agentforceには構成の上限があり、2026年8月時点で1つの組織あたり有効なエージェントは20体、1つのエージェントあたりのサブエージェントは15、1つのサブエージェントあたりのアクションは15とされています。

※参考記事はこちら

※参考記事はこちら

1つのサブエージェントに業務を足したくなったときは、上限に届く前に、配線したアクションの数が15に近づいていないかを確認しましょう。サブエージェントの業務設計については、ほか記事「Agentforce Service Agentとは」もあわせてご確認ください。

要素②エージェントに渡す指示文

2つ目は、サブエージェントごとに渡す指示文です。Agent Scriptでは、サブエージェントの説明文と、推論の際に参照させる指示のブロックを分けて書きます。

説明文はエージェントがどのサブエージェントを使うかを判断する材料になり、指示のブロックは選ばれたあとの振る舞いを決めます。回答の内容がずれているのか、そもそも選ばれるサブエージェントが違うのかで、直すべき場所は変わります。

先ほどの会社では、営業担当者が「この前の見積を確認したい」と依頼したときに、見積の履歴確認へ進まず、過去案件の抽出が選ばれてしまう問題が起きていました。担当Aが直したのは指示のブロックではありません。サブエージェントの説明文のほうです。

回答がずれたときは、指示文を足す前に、どのサブエージェントが選ばれたのかを確認しましょう。

要素③状態を保持する変数

3つ目の要素は、会話のなかで値を保持する変数です。Agent Scriptでは変数を宣言し、`@variables.`という形式で参照して、必要に応じて値を更新できます。

変数が必要になるのは、会話が複数の往復にわたるときに、前のやり取りで確定した情報を持ち越すためです。持ち越せないと、エージェントは同じ質問を繰り返すことになります。

この産業機器メーカーの見積の履歴確認では、最初に顧客名を尋ね、その値を変数として保持する設計にしていました。以降のやり取りでは顧客名を聞き直さずに済み、営業担当者からの「何度も同じことを聞かれる」という指摘が解消しています。

同じ情報を二度尋ねる場面があるなら、その値を変数として保持できないかを確認してみてはいかがでしょうか。

要素④遷移条件を決めるトランジション

4つ目は、別のサブエージェントへ移る条件を決めるトランジションです。条件式と組み合わせて、指定した状況で確実に移動させられます。

条件を明示する意味は、エージェントの判断に任せる部分と、任せない部分を分けられることです。会話の流れから推測させると、移るべき場面で移らないことがあります。

先ほどの会社では、商談後のフォローを扱うなかで見積の話題が出たとき、見積の履歴確認へ移す条件をトランジションとして書きました。以前は営業担当者が会話を終えて依頼し直していた工程が、そのまま続けられるようになったのです。5つのサブエージェントのうち条件を明示したのはこの1本だけで、残りは会話の流れに任せています。

すべての遷移を条件として書くべきかは、移らなかったときに営業担当者の作業が止まるかどうかで判断しましょう。以上が、Agent Scriptで定義する4つの構成要素でした。

Agentforce DXでコード管理する4ステップ

ここまで、Agent Scriptで何を書けるのかを構成要素ごとに整理してきました。ただ、書けることと日々の運用に組み込めることは別の話です。取得・確認・レビュー・配布という流れを、誰がいつ担当するかまで決めて初めて運用として続きます。そこでここでは、Agentforce DXを使ってコード管理する4つのステップを解説します。

Agentforce DXで整えるべきなのは、営業からの要望が本番へ反映されるまでの、担当者の動きの順序です。

ステップ①VS Codeの拡張機能で定義を取得する

営業部門から「初回訪問前の情報整理の指示文を変えてほしい」という要望が水曜に起票され、翌朝、担当AがSandbox組織から定義を手元に取得するところから1週間が始まります。Agentforce DXのVS Code拡張は、この取得と編集を担当します。

最初に取得する理由は、手元のファイルと組織の状態を必ずそろえてから編集を始めるためです。前回の作業からの間に別の担当者が画面上で直していれば、その内容を取り込まないまま編集すると、あとで上書きが発生します。

担当Aは毎週木曜の朝、5本のサブエージェントの定義を取得し、前回のファイルとの差分を確認してから作業に入る手順にしていました。取得に数分かかるだけで、画面上で誰かが直した内容を見落とさずに済んでいます。

編集を始める前に取得する順序を、手順として固定しましょう。なお、Apexなどのコードを書く場面でAIの支援を受ける機能は別に用意されており、その内容はほか記事「Agentforce Vibesとは」で解説しています。

ステップ②CLIでエージェントの応答を確認する

定義を取得したら、次は指示文を直したうえで、その場から会話を流して応答の変化を確認します。Salesforce CLIには、エージェントとの会話を実行するコマンドが用意されています。

ここで確認するのは、変更した指示文が意図した回答につながっているかどうかです。画面のプレビューでも同じことはできますが、CLIから実行すると、確認したい会話のパターンを手順として残せます。

担当Aは、初回訪問前の情報整理について、新規顧客・既存顧客・過去に失注した顧客という3つのパターンで会話を流し、回答を確認していました。この工程には営業担当者も営業企画部長も関わらず、担当A1人で完結します。所要時間は15分ほどです。

逆に、流すパターンを決めずに会話を始めると、回答が変わった原因が指示文の修正なのか質問の違いなのかを切り分けられません。

ステップ③Gitで定義の差分をレビューする

応答を確認できたら、変更した内容をコミットして、担当Bへ確認を依頼します。ここで担当Bが見るのは、変わった行だけです。

差分だけを見る形にすると、確認の対象が「どの文をどう変えたか」に絞られます。文言が営業の要望に合っているかどうかは、起票した営業担当者へ確認を回します。

先ほどの産業機器メーカーでは、この工程だけが3者に分かれていました。担当Bが記述として問題がないかを確認し、営業担当者が文言の妥当性を確認し、営業企画部長が反映の可否を判断する形です。画面を見比べていた頃は1回20分かかっていた確認が、差分を読む数分の作業に変わっています。

確認する担当者と、文言を判断する担当者を分けておくと、指摘が混ざりません。

ステップ④CI/CDで対象組織へ配布する

最後に、営業企画部長の承認を受けて、金曜に本番組織へ反映します。CI/CD（継続的インテグレーション・継続的デリバリー）の仕組みに載せると、この反映を決められた手順どおりに実行できます。

自動化の利点は、作業が速くなることよりも、毎回同じ手順が実行される点にあります。手作業では、担当者がその場で選ぶ設定が必ず残ります。

たとえば変更セットでのリリースでは、実行するテストの範囲を4種類の選択肢から毎回選ぶ判断が発生していました。この判断の内容は、ほか記事「変更セットのリリースにおけるテストオプションの違いと使い分け」で整理しています。CI/CDに載せると、この選択を設定として固定できるため、担当Aがリリースのたびに判断する場面がなくなりました。

配布の前にテストを実行する設定も、同じ仕組みのなかに組み込めます。以上が、Agentforce DXでコード管理する4つのステップでした。

Agent Scriptで混乱する3つの表記のずれ

前章では、取得から配布までの流れを担当者の動きとして整理しました。ここからは、実際に記述を始めたときにつまずきやすい点を共有します。公式ドキュメントを読んでも解けないのが、画面の表記と記述のなかで使う語が一致していない箇所です。そこでここでは、Agent Scriptで混乱する3つの表記のずれを整理します。

画面上の名称と記述のなかのキーワードが違っていても、記述の誤りではありません。名称変更が構文に反映されていないだけです。

ずれ①構文キーワードのtopicが画面表記に追随していない

1つ目のずれは、画面で「サブエージェント」と表示されているものを、記述のなかでは`topic`と書く点です。2026年4月から、エージェントのtopicはsubagentと呼ばれるようになりましたが、この変更に機能の違いはありません。

名称が変わったにもかかわらず記述が変わっていないのは、画面上の表示名と、言語の構文キーワードが別々に管理されているためです。構文としての`topic`は現在も正式なキーワードであり、古い書き方が残っているわけではありません。

先ほどの産業機器メーカーでも、担当Aが最初に定義を取得したとき、画面で5本表示されていたサブエージェントがファイルのなかでは`topic`と書かれていて、取得したファイルが古いバージョンではないかと疑っています。公式ドキュメントの記載を確認して、名称変更の対象が画面表記だけだと分かるまで、半日ほど作業を進められませんでした。

※参考記事はこちら

取得したファイルに`topic`と書かれていたら、公式ドキュメントの構文リファレンスで現役のキーワードかを確かめると、数分で判断できます。

ずれ②Topic SelectorがAgent Routerに変わった

2つ目は、どのサブエージェントを使うかを判断する仕組みの名称が、Topic SelectorからAgent Routerへ変わった点です。この変更も2026年4月の名称変更にあわせたもので、動作は変わりません。

名称の変更が実務で問題になるのは、社内の設計資料と検索で出てくる情報が食い違うためです。1年前に作った資料を見ながら現在の画面を開くと、該当する項目が見つかりません。

この会社の担当Bは、昨年作ったエージェントの設計資料に「Topic Selectorの精度が低い場合の対応」という節を残していました。コード管理へ移すタイミングで資料を見直し、名称をAgent Routerへ書き換えたうえで、判断がずれたときの確認手順を追記しています。

検索で古い名称の記事が出てきたときは、画面の名称よりも動作の説明が現在の仕様と一致しているかを見て、参考にするかを決めましょう。

ずれ③標準アクションのラベルが識別子と対応しない

3つ目のずれは、画面に表示される標準アクションのラベルと、記述で指定する識別子が対応していない点です。ラベルを見て識別子を推測しても、当たりません。

対応しないのは、ラベルが利用者向けの表示名として付けられているのに対し、識別子は内部の処理名として管理されているからです。両者を機械的に変換する規則はありません。

具体的には、`Get Record Details`と表示されるアクションの識別子は`getDataForGrounding`で、`Search The Web`の識別子は`webSearchStream`です。実際に7件の標準アクションについてラベルから識別子を推測したところ、正しく当てられたのは1件だけでした。残りの6件は、記述したあとで存在しないアクションとして扱われ、エージェントが応答しない状態になっています。

推測で書かず、必ず画面で識別子を確認してから記述しましょう。以上が、Agent Scriptで混乱する3つの表記のずれでした。

Agentforceの標準アクションを調べる3ステップ

標準アクションのラベルと識別子が対応しない問題は、記述を始めた担当者がほぼ必ず遭遇します。ただし、確認する場所さえ分かっていれば数十秒で解決する内容でもあります。推測で書いて動かない原因を探すより、先に確認する手順を習慣にするほうが速く終わります。そこでここでは、Agentforceの標準アクションの識別子を調べる3つのステップを解説していきます。

標準アクションの識別子は、画面の決まった欄から読み取って転記する対象です。推測で書いた記述は、存在しないアクションとして扱われます。

ステップ①アクションの詳細画面を開く

まず、設定画面からアクションの一覧を開き、記述に使いたい標準アクションの詳細画面を表示します。ここで開くのは、エージェントの編集画面ではありません。アクション単体の詳細画面です。

アクション単体の詳細画面を開く理由は、エージェントの編集画面にはラベルしか表示されないからです。ラベルだけを見て記述に進むと、前章で挙げた識別子のずれがそのまま発生します。

担当Aは、初回訪問前の情報整理で使う3件の標準アクションについて、それぞれの詳細画面を開いて情報を控える手順にしました。控えるのは、画面のラベル・記述で使う識別子・エージェントへ渡す項目の3つです。3件で5分もかかっていません。

記述を始める前に、使うアクションの詳細画面をすべて開いておきましょう。

ステップ②参照アクション欄で識別子を読む

詳細画面を開いたら、参照アクションの欄を確認します。この欄には、記述でそのまま使える識別子がラベルの下に1行で表示されており、選択してそのまま記述へ貼り付けられます。

この欄を見る必要があるのは、画面上でラベルと識別子が併記されている場所がここしかないためです。一覧画面にも編集画面にも、識別子は出てきません。

担当Aがこの欄の存在に気づいたのは、識別子を推測して書いた記述が動かず、7件のうち6件で同じ問題が起きたあとでした。それまでは公式ドキュメントの一覧から探しており、名称が似たアクションを見分ける手間もあって、1件あたり10分近くかかっていたのです。

参照アクションの欄を確認する手順を、社内の作業手順に加えておくとよいでしょう。

ステップ③読み取った識別子をそのまま記述する

最後に、読み取った識別子を、大文字と小文字の区別も含めて、表記を変えずにそのまま記述します。貼り付けた直後に、前後へ空白が混ざっていないかも確認しておきます。

そのまま書き写す必要があるのは、識別子の照合が完全一致で行われるためです。1文字違うだけで、存在しないアクションとして扱われます。

この産業機器メーカーでは、担当Aが読み取った識別子を先に一覧として社内の文書にまとめ、記述するときはそこから貼り付ける形に変えました。18件のアクションのうち標準アクションは9件あり、一覧を作ったあとは識別子の誤りが起きていません。

一覧に残しておくと、次に記述する担当者が同じ画面をたどり直す手間もなくなります。以上が、Agentforceの標準アクションを調べる3つのステップでした。

Agentforceの定義を移送すると壊れる3つの箇所

ここまで、記述の段階でつまずく点とその対処を整理してきました。次に控えているのは、手元で問題なく動いた定義を別の組織へ移す工程です。この工程では、記述の正しさとは関係のない理由で反映が失敗します。そこでここでは、Agentforceの定義を移送したときに壊れる3つの箇所を、先回りして共有します。

移送で壊れる原因は、定義が組織ごとに違う値を参照している点にあります。記述の誤りを疑っても見つかりません。

箇所①リトリーバーIDを参照するプロンプトテンプレート

1つ目の箇所は、Data 360のリトリーバーIDを参照しているプロンプトテンプレートです。移送先の組織で同じIDが存在しないため、テンプレートが正しく動きません。

なぜなら、リトリーバーは組織ごとに作られる対象であり、その識別子も組織ごとに発行されるからです。設定の名称が同じでも、内部で持っているIDは別の値になります。

製品仕様の照会を担当するサブエージェントでは、担当Aがマニュアルを検索するリトリーバーを参照するテンプレートを使っていました。Sandbox組織で問題なく回答できていたテンプレートが、本番組織へ移した直後から検索結果を返さなくなり、担当Aは指示文を疑って半日を費やしています。

参照しているIDが組織をまたいで有効かどうかを、移送の前に確認しましょう。

箇所②Apexアクションを含むフローに紐づくテンプレート

2つ目に注意したいのは、Apexアクションを含むフローに紐づいたプロンプトテンプレートです。この組み合わせでは、デプロイ自体が失敗する既知の不具合があります。

失敗の厄介な点は、エラーの内容がテンプレート側の問題として表示されるため、原因がフローに含まれるApexアクションにあると気づきにくいことです。テンプレートの記述を何度見直しても、原因は見つかりません。

この会社でも、見積の履歴を整形するフローにApexアクションを1つ含んでおり、そこに紐づくテンプレートのデプロイが繰り返し失敗しました。担当Aと担当Bの2人でテンプレートの記述を確認し続け、Apexアクションを一時的に外して試したところで、原因を特定できたのです。切り分けに要したのは2日でした。

テンプレートのデプロイが失敗したときは、紐づくフローの中身を先に確認すると早く切り分けられます。

箇所③バージョンを固定していないエージェント定義

3つ目は、参照するバージョンを固定していないエージェントの定義です。固定していないと、移送のタイミングで別のバージョンが反映されることがあります。

固定が必要になるのは、エージェントの定義が複数のバージョンを持てる構造になっているためです。どのバージョンを有効にするかを明示していないと、組織側の状態に従います。

先月この産業機器メーカーで起きた「戻したはずの指示文がまた元に戻っている」という事故も、この構造が背景にありました。担当Aが本番へ流した変更セットに、戻す前のバージョンを指す設定が含まれていたためです。コード管理へ移してからは、反映するバージョンを定義のなかで指定する運用に変え、同じ事故は起きていません。

反映するバージョンは、担当者の記憶に頼らず定義のなかで指定しましょう。以上が、Agentforceの定義を移送すると壊れる3つの箇所でした。

Agentforceのコード管理で増える3つのコスト

前章までで、コード管理に移したあとに起きる問題と対処を整理してきました。ここで正直にお伝えしておきたいのは、この移行によって作業が減るわけではないという点です。減る作業もありますが、全体では増える方向に働きます。そこでここでは、Agentforceのコード管理で増える3つのコストを解説します。

コード管理で増えるのは金額ではなく、検証と確認にかける担当者の作業時間と、検証の回数に応じたクレジットの消費です。

なお、開発に使うツール自体は無償で入手できます。Salesforce CLIは公式サイトから配布されており、VS Code拡張もMarketplace上で価格がFreeと表示されています（2026年8月12日時点・バージョン1.17.2）。ただし、Agentforceの利用に伴うライセンスの費用は別の話です。ライセンスの体系については、ほか記事「Agentforce料金・ライセンス」をご確認ください。

※参考記事はこちら

コスト①Sandbox環境での検証に必要な作業時間

1つ目のコストは、Sandbox組織での検証にかかる作業時間です。手元で定義を直すたびに応答を確認するため、検証の回数が増えます。

ここで見落としやすいのが、クレジットの消費です。エージェントの設定や構成の作業ではクレジットは消費されません。一方で、消費が発生する操作は次の5つになります。

クレジットを消費する操作 ①プレビュー実行・・・Agent Builderとプロンプトビルダーでの試行 ②テスト実行・・・テストセンターやテストスイートでの実行 ③テストケースの生成と評価・・・ケースの作成と応答の採点 ④プレビュー時のデータ検索・・・回答の根拠として参照するデータの取得 ⑤検索インデックスの作成・・・検索対象にするデータの処理

この内訳は、ほか記事「エージェントの構築作業やテスト実行でクレジットは消費されるのか」で整理しています。

この産業機器メーカーでは、1回の修正につき3パターンの会話を流す手順にしたため、週1回の修正でも月に12回の実行が発生する計算になりました。画面上で1回だけ試していた頃と比べて、実行の回数は明らかに増えています。

検証の回数が増えるほどクレジットの消費も増えるため、移行の計画には検証の回数を先に見積もっておきましょう。

コスト②差分レビューに割く担当者の稼働

2つ目は、変更の差分を確認する担当者の稼働です。GUIでの運用では実施していなかった工程が、新しく発生します。

新しい工程が増えるのに移行を勧めるのは、この確認が手戻りの発生を減らすからです。反映してから問題に気づけば、切り分けと修正と再反映が必要になり、確認にかける時間よりはるかに長くかかります。

先ほどの会社の担当Bは、週1回の差分確認に5分から10分をあてる形になりました。読むのは5本のサブエージェントのうち変更があった1本の差分だけで、残りは開いていません。画面を見比べていた頃の20分より短いものの、以前は確認せずに反映していた週もあったため、実施の回数としては増えています。

確認の工程は、短く済ませられる形にしたうえで毎回実施する運用に固定しましょう。

コスト③配布の自動化を構築する初期の設定工数

3つ目は、配布の自動化を組み立てるときにかかる初期の設定工数です。この工数は一度きりで、運用が始まれば発生しません。

初期に工数がかかるのは、どの組織へどの順序で反映するか、その前にどのテストを実行するかを、設定として書き下ろす必要があるためです。手作業のときに担当者が都度判断していた内容を、すべて明示することになります。

この産業機器メーカーでは、担当Aと担当Bが本番組織への反映手順を洗い出し、設定として書き下ろしたうえで、Sandbox組織で3回試してから運用に入りました。既存のリリース手順の文書があったため、ゼロから決める作業にはなっていません。

なお、指示文の変更が四半期に1回程度の組織であれば、この初期の工数を払う理由がありません。移らない判断も、同じ観点から見て正しい選択になります。以上が、Agentforceのコード管理で増える3つのコストでした。

Agentforceを継続的に改善する4つの体制条件

ここまで、コード管理へ移す判断から実装、そこで増えるコストまでを順に整理してきました。ただ、ツールを入れただけでは改善は続きません。誰が提案し、誰が承認し、どの手順で配布し、何を見て改善できていると判断するかが決まって初めて運用になります。そこでここでは、Agentforceを継続的に改善するための4つの体制条件を整理します。

継続的な改善を支えるのは、提案・承認・配布・測定の4つの役割が、特定の担当者に割り当てられている状態です。

条件①定義の変更を提案する担当を決めていること

1つ目の条件は、エージェントの定義をどう変えるかを提案する担当者を決めていることです。ここでいう提案は、要望をそのまま渡す行為とは違います。

提案する担当者が必要なのは、現場から挙がる要望が「使いにくい」という形で届くためです。この内容を、指示文のどの行をどう変えるかという形に翻訳する担当者がいないと、要望は溜まるだけになります。

この産業機器メーカーでは、営業企画の担当者1名が要望の受け口になり、月8件前後の起票を内容ごとに分類していました。指示文の調整で対応できるものを情報システム部へ回し、業務の進め方の見直しが必要なものは営業部門内で扱う形に分けています。

要望の受け口を営業側に置くか情報システム部に置くかは、要望を業務の言葉で分類できる担当者がどちらにいるかで決めましょう。

条件②レビューして承認する担当を決めていること

次に、提案された変更を確認し、反映してよいかを承認する担当者を決めていることです。この役割は、確認する担当者と承認する担当者に分けられます。

役割を分ける理由は、確認する内容が2種類あるからです。記述として問題がないかという確認と、業務としてその変更を入れてよいかという判断は、必要な知識が違います。

先ほどの会社では、記述の確認を情報システム部の担当Bが、業務としての承認を営業企画部長が担当していました。担当Bに求めたのはAgentforceの構成に関する知識で、その水準の目安として、ほか記事「Agentforceスペシャリスト資格の試験概要や勉強法」で扱っている試験範囲を参考にしています。変更の通知と承認のやり取りは、ほか記事「Agentforce in Slackとは」で紹介しているような、日常的に使うチャットの環境へ寄せるとやり取りが滞りません。

記述の確認と業務の承認を1人が兼ねると、どちらの観点も浅くなるため、少なくとも2人に分けておきましょう。

条件③配布の手順を文書化していること

3つ目は、承認された変更を本番組織へ配布する手順が、文書として残っていることです。自動化した設定とは別に、人が読める形の手順書を用意します。

では、なぜ自動化しているのに人が読める手順書が必要なのでしょうか。それは、設定が想定どおりに動かなかったときに、手作業へ戻す判断が必要になるからです。手順が担当者の頭のなかにしかないと、その担当者が不在の週は反映が止まります。

この産業機器メーカーは、金曜に反映するという曜日の運用と、失敗したときに前のバージョンへ戻す手順を、2ページの文書にまとめていました。担当Aが不在だった週に担当Bが1人で反映を完了できたのは、この文書があったためです。

手順書は、担当者が交代しても同じ作業を再現できる粒度で書きましょう。

条件④改善の状態を数値の指標で追えていること

最後に、改善が進んでいるかどうかを数値で確認できていることです。ここで見る指標は3つに絞ります。

エージェント定義の運用で見る3つの指標 ①リードタイム・・・変更の起票日から本番反映のコミット日までの日数 ②変更失敗率・・・本番反映の回数に対する、戻しや修正の再反映が発生した回数の割合 ③不整合の件数・・・環境間の移送で発生した不整合を、発生箇所の分類ごとに数えた件数

このうちリードタイムと変更失敗率は、ソフトウェアの配信を測る枠組みとして知られるDORA（DevOps Research and Assessment）の指標を、エージェント定義の運用に読み替えたものです。3つ目の不整合の件数は、移送で壊れる3つの箇所の分類ごとに数えます。

※参考記事はこちら

この会社では、毎月の定例で3つの数値を確認する運用にしました。指示文の修正がいつ本番へ入ったかを日付で追えるようになり、戻し作業が起きたときにどのコミットが原因かを特定できる状態になっています。移送の不整合も、リトリーバーIDの参照によるものか、フローに紐づくものかを分けて数えられるようになりました。

以上が、Agentforceを継続的に改善する4つの体制条件でした。なお、この体制を社内だけで組み立てられない場合は、支援会社の選択肢もあります。選び方は、ほか記事「Agentforce導入支援会社のおすすめ8選」が参考になります。体制設計から一緒に検討したい場合は、Agentforce導入・定着支援サービスへお気軽にご相談ください。

【一問一答】Agent Scriptに関するよくある質問

GUIでの運用が限界を迎える状況から、コード管理へ移るかどうかの判断基準、Agentforce DXでの手順、移送で壊れる箇所、そして体制の条件までを順に整理してきました。読み進めるなかで、記述にどこまでの知識が要るのか、費用の前提はどうなるのか、画面での設定とどう共存するのかといった点が気になった方もいるのではないでしょうか。最後に、Agent ScriptとAgentforce DXについて検索されやすい疑問に、簡潔にお答えします。

質問①Agent Scriptはプログラミング未経験でも書けるか

読むところから始められます。画面で作った定義がそのままAgent Scriptとして表示されるため、まずは既存のエージェントがどう記述されているかを確認するのが現実的です。ApexのようなクラスやSQLの設計は求められません。

ただし、変更履歴を扱うためのGitの操作は必要になります。コミットと差分の確認ができれば、日々の運用は進められるでしょう。

質問②Agent Scriptは手作業で書く必要があるのか

手書きを前提にしない設計になっています。Agentforceに自然言語で依頼すれば、サブエージェントや指示文の記述に変換されるため、ゼロから書き起こす場面は多くありません。

一方で、公式ドキュメントでは上級者が記述を直接編集できるとも記載されています。生成された記述を読んで直す力は、運用のなかで必要になると考えます。

質問③Agent Scriptで書いた定義は画面にも反映されるか

反映されます。視覚的に組み立てるビューと記述を編集するビューは、同じ定義を別の形式で表示しているためです。

記述で直した内容を画面で確認し、画面で直した内容を記述として取得する進め方もできます。どちらか一方に統一しなければならない制約はありません。

質問④Agentforce DXのCLIは追加費用なしで使えるか

ツール自体は無償で入手できます。Salesforce CLIは公式サイトから配布されており、VS Code拡張もMarketplace上で価格がFreeと表示されています（2026年8月時点）。

ただし、Agentforceの利用に追加のライセンス費用がかからないと断定できる公式の情報は確認できていません。費用は、ほか記事「Flex Credits・従量課金・ユーザーライセンスの違い」でご確認ください。

質問⑤Agent Scriptで検索インデックスまで定義できるか

定義できません。検索インデックスやリトリーバー、データストリームの接続設定は、画面での設定が必要な対象です。

これらの設定は組織ごとのデータの状態に依存するため、同じ定義を別の組織へ移しても同じ結果になりません。環境ごとに画面で設定し、手順を文書に残す方法が現実的です。

質問⑥Agent ScriptのファイルはGitで管理できるか

管理できます。Agent Scriptで書いた定義はテキストのファイルとして扱えるため、コミットの履歴も行単位の差分も、通常のソースコードと同じように残せます。

そのうえで、フローやプロンプトテンプレートといった部品は扱いが異なります。どの対象をGitの管理下に置くかは、3つの層の切り分けに沿って決めましょう。

エージェント定義はAgent Scriptで、データ基盤はUIで管理する

Agentforceの運用を継続的に改善していくうえで最も大きな違いを生むのは、エージェント定義をAgent Scriptとしてコードで管理し、検索インデックスやデータ接続はUIでの設定に残すという分担です。本記事では、GUIでの運用が限界を迎える状況から、コード管理へ移るかどうかの判断基準、コード化できる層と外すべき対象、Agentforce DXでの手順、移送で壊れる箇所、そして体制の条件までを一連の流れとして整理してきました。

コード管理へ移す価値があるのは、指示文の修正が週単位で発生し、定義を触る担当者が2人以上いて、環境間の移送が月に複数回起きている場合です。逆に、担当者が1人で完結し、変更が四半期に1回程度であれば、いまの画面上での設定を続けるほうが速く進みます。

本記事で紹介した判断基準と手順を、ぜひ自社の運用状況に合わせて実践してみてください。BtoBマーケティングや営業体制の設計から相談したい場合は、BtoBマーケティング無料相談もご用意していますので、少しでもお役に立てれば幸いです。