第一部：Agent Scriptで制御できるAIへ — LLMの落とし穴と設計思想

Generative AIやChatGPTがビジネスの現場に浸透した今、「AIに命令を書けば全部やってくれる」と考える方も多いでしょう。しかし実際には、プロンプトだけでは業務フローを正しく制御できない場面が多々あります。AIは確率的に出力を生成するため、同じ入力でも結果が変わり、指示を増やすほど予測不能な挙動が強まることが指摘されています。この入門編では、Salesforceの次世代プラットフォームAgentforceと、その中核技術であるAgent Scriptに焦点を当て、LLMを“使う人”から“制御する人”へ転換するための考え方を身に付けます。
この記事を読むことで、以下が理解できます：
・Agent Scriptとは何か：ハイブリッド推論を実現するYAMLライクなスクリプト言語です。
・LLMに任せると起きる失敗：本人確認の省略やアクション順序の不整合など、実際に起こり得る事故パターンを解説します。
・スクリプト設計の基本：トピック、変数、アクションをどのように組み合わせるかを具体的に示します。
・導入のタイミングと運用のコツ：プロンプトのみで開始し、問題が見つかった箇所にだけ決定論的ロジックを追加する手法を紹介します。

Agent Scriptとは？ — LLMの限界を超えるための新技術

Agent Scriptは、Salesforceが提供するAgentforceプラットフォームのために設計された高レベルなスクリプト言語です。YAMLライクな構文を採用し、自然言語による柔軟さとプログラム的な確実性を両立させることを目指しています。コードはコンパイルされ、Salesforceの低レベルメタデータに変換されるため、実行時の安全性とパフォーマンスが確保されています。開発者でなくても読み書きしやすいよう工夫されており、ホワイトボックスな制御を実現するのが特徴です。

Agent Scriptが生まれた背景には、LLMだけでは業務プロセスを安定的に運用できないという課題があります。LLMは確率的モデルであり、入力と出力が一意に対応しません。さらに、実行手順や状態管理をAIに丸投げすると、プロンプトのちょっとした変更や文脈の揺らぎで意図しない挙動を引き起こすことが報告されています。これを解決するため、Agent Scriptは決定論的なフロー制御と自然言語による自由度の両方を提供します。

LLMの限界 — プロンプトだけでは危険な3つの失敗例

LLMにすべてを任せるとどのような問題が起こるのでしょうか。ここでは、現場でよく見られる代表的な失敗パターンを3つ紹介します。あなたの環境でも似たような問題が起きていないか確認してみてください。

例1：本人確認の省略

ECサイトの注文問い合わせを想定したケースでは、購入者本人かどうか確認する前に注文情報を開示してしまう事故が多発します。プロンプトだけで「本人確認をしてください」と指示しても、LLMは文脈次第で省略してしまうことがあり、個人情報漏えいのリスクがあります。Agent Scriptでは変数と条件分岐で必ず本人確認を実施するよう制御できます。

例2：アクション順序の不整合

複数の処理を連続して実行する場合、LLMが指示を解釈する順序が変わり、請求が先に走ってしまうなどの問題が発生します。たとえば「注文をキャンセルし、返金して、メールで通知する」という流れでも、AIは文脈次第で「メール送信」を先に実行してしまいます。Agent Scriptのrunやtransitionで明示的に順序を定義すれば、後戻りのない確実な処理が可能です。

例3：トピックのルーティングミス

会話エージェントはユーザーの意図によって異なるフローに分岐します。しかし、プロンプトのみだと意図判定が不安定で、返品の問い合わせがサポート窓口に転送されるなどルーティングミスが発生します。Agent Scriptではavailable whenを使って、特定条件でのみツールやトピックを有効化できるため、誤ルーティングを防止できます。

Agent Scriptの思想 — 混沌から秩序へ

このような失敗例を踏まえると、Agent Scriptの目的は明確です。それは「LLMに任せるべき部分とプログラムで制御すべき部分を分離すること」です。Antonio Figueiredo氏は、LLMだけに頼ると非決定性・状態管理の欠如・推論と実行の混在という3つの問題が生じると指摘しています。Agent Scriptはこの指摘を踏まえ、以下を実現します：

• 推論と実行の分離：自然言語で考えさせる部分と、プログラム的に強制する部分を明確に区別します。
• 状態の保持：変数を用いてエージェントの内部状態を保持し、複数ターンにまたがるやり取りを制御します。
• 信頼できるフロー制御：トピックと遷移によって、業務フローを決定論的に設計できます。

この思想はSalesforceが掲げるAgentic Enterprise構想とも合致します。AIの能力を人間の仕事に組み込む際、単に回答生成だけでなく、企業のプロセスに則ったオーケストレーションが必要です。Agent Scriptはその土台となります。

Agent Scriptの基本構造と書き方

Agent Scriptのファイルは大きく次のブロックで構成されます：

1. system — エージェント全体の名前や説明を書きます。ユーザーに見せるわけではなく、開発者向けのメタ情報です。
2. config — LLMモデルや温度などの設定を行う場所です（将来的に拡張予定）。
3. variables — エージェントが状態を保持するための変数を定義します。型はstring、number、booleanなどが利用でき、デフォルト値も設定できます。変数はトピック間で共有されるため、一度取得したユーザー情報を別トピックで活用することが可能です。
4. language — プロンプトで使う参照データ（外部ファイルやテンプレート）を指定します。コード内で@を使って読み込みます。
5. topics — 会話や処理の単位を表します。各トピック内には複数のステップを定義でき、->はロジック命令、|はLLMに渡すプロンプトを示します。
6. start_agent — 全ての会話が始まるエントリポイントで、ユーザーの入力を解析し最初のトピックへ遷移します。

例：最小構成のAgent Script

以下は、本人確認を必ず要求してから注文状況を回答する最小構成の例です。

system:
  name: OrderSupportAgentvariables:
  isVerified:
    type: boolean
    default: falsetopics:
  start_agent:
    -> if not variables.isVerified
        -> transition to Identity  Identity:
    -> run @actions.verify_user
    -> variables.isVerified = true
    -> transition to OrderInfo  OrderInfo:
    -> run @actions.get_order
    | 以下があなたの注文状況です。

ここではvariables.isVerifiedがfalseの場合、必ずIdentityトピックに遷移して本人確認を実施します。変数をtrueに設定した後でOrderInfoに遷移するため、確認を飛ばすことはありません。このようにロジックとプロンプトを分離することで、安全性と柔軟性を両立させます。

Agent Scriptの構文ポイント

• 命令とプロンプト：->はロジックを記述し、|はLLMに送る指示文を記述します。
• 変数参照：プロンプト内で変数値を埋め込む場合は{{!variables.name}}のように記述します。
• 条件分岐：if/elseによって分岐が可能ですが、else ifは現時点でサポートされていません。複数条件は連続したifで表現します。
• 演算制約：現バージョンでは加算と減算のみがサポートされており、掛け算・割り算は使えません。
• インデントとコメント：YAMLのようにインデントが重要です。コメントは#で始め、文脈内やステップの末尾に書けます。

トピック設計の原則とスタートブロック

トピックは業務フローを分割する単位です。1トピック1責務を意識し、本人確認、注文確認、返品処理などを別々のトピックとして設計することで、ロジックが見通しやすくなります。start_agentブロックではユーザー入力を解析し、適切なトピックへ遷移させます。例えば、「返品」という単語が含まれていればReturnトピックへ遷移するように記述します：

start_agent:
  -> if @system_variables.user_input contains "返品"
      -> transition to Return
  -> if @system_variables.user_input contains "注文" or @system_variables.user_input contains "状況"
      -> transition to OrderInfo
  -> | ご用件をお知らせください。

このように、スタートブロックはエージェントの入口であり、最初にどのトピックへ進むかを決めるルータの役割を担います。

変数と状態管理 — 記憶をコードで保持する

LLMは会話の文脈を覚えているように見えても、本質的には次の出力を確率計算で生成しており、状態管理を任せることはできません。Agent Scriptではvariablesブロックに明示的に状態を保持し、トピック間をまたいで値を利用できます。変数の型はstring、number、booleanなどであり、defaultキーで初期値を設定できます。

例えば、本人確認済みかどうかを表すisVerified、取得した注文IDを保持するorderId、顧客の氏名を保持するcustomerNameなどを定義できます。変数名はキャメルケースもしくはスネークケースで記述し、命名はわかりやすくすることが推奨されます。これにより、LLMの中に含まれる曖昧な記憶ではなく、スクリプト上の明示的な状態として管理できるようになります。

アクションとツール — 外部処理の実行と制約

Agent Scriptでは、外部サービスとの連携をアクションと呼びます。例えばSalesforceのデータベースから情報を取得したり、他システムにデータを送信したりする場合に使用します。アクションは実行時に特定の引数を渡し、完了後は変数に戻り値を格納できます。一方、ツールはLLMが直接呼び出すプラグイン的な機能で、利用できる条件をavailable whenで制御します。

アクションとツールを使い分けることで、データ取得や更新を正しいタイミングと条件で実行できます。例えば本人確認が済んでいない場合はget_orderツールを非表示にしておき、認証後にのみ利用可能にすることができます。こうした制御は、従来のプロンプトベースでは困難でした。

失敗パターンへの対処 — コードで制御する具体例

Agent Scriptの真価は、先に紹介した失敗パターンを具体的なロジックで防ぐ点にあります。以下に典型的なシナリオを5つ示します。

シナリオ1：本人確認を必須にする

start_agent:
  -> if not variables.isVerified
      -> transition to Identity
  -> transition to MainIdentity:
  -> run @actions.verify_user
  -> variables.isVerified = true
  -> transition to MainMain:
  -> | ご用件を教えてください。

このシナリオでは、エージェント開始時に必ずIdentityトピックを通過することで本人確認を行います。完了後にのみMainに進むため、確認が省略されることはありません。

シナリオ2：アクション順序の保証

PaymentProcess:
  -> run @actions.validate_coupon
  -> run @actions.charge_payment
  -> run @actions.send_receipt
  | お支払いが完了しました。

run命令は記述順に実行されるため、支払い処理の前にクーポンの検証が必ず行われ、料金支払い後にレシート送信が行われます。LLMに依存した場合の順序バグを根本的に解消できます。

シナリオ3：トピックルーティングの制御

start_agent:
  -> if "返品" in @system_variables.user_input
      -> transition to Return
  -> if "注文" in @system_variables.user_input
      -> transition to OrderInfo
  -> transition to FallbackReturn:
  -> | 返品手続きを行います。Fallback:
  -> | ご質問を理解できませんでした。

ユーザーの入力を条件に分岐し、適切なトピックへ遷移させる例です。Fallbackトピックは意図が判定できなかった場合の安全弁として設計します。

シナリオ4：状態に応じたプロンプト生成

OrderStatus:
  -> run @actions.get_order_status
  -> if variables.orderStatus == "shipped"
        | ご注文は発送済みです。追跡番号は{{!variables.trackingNumber}}です。
  -> if variables.orderStatus == "processing"
        | ご注文は処理中です。もうしばらくお待ちください。
  -> else
        | ご注文の状況が確認できませんでした。サポートにお問い合わせください。

変数orderStatusの値に応じて異なるメッセージを表示しています。LLMの生成に頼らず、状態から直に出力を制御できるため、説明に一貫性が生まれます。

シナリオ5：ツール利用条件の制御

OrderInfo:
  tools:
    get_order:
      available when: variables.isVerified == true  -> run @actions.get_order
  | 注文内容: {{!variables.orderDetails}}

get_orderツールはvariables.isVerifiedがtrueの時のみ利用可能としています。これにより、認証前に注文情報を取得しようとするとツールが表示されず誤操作を防げます。

Beta機能と信頼レイヤー — セキュリティとコンプライアンス

SalesforceはAgentforceにEinstein Trust Layerを組み込み、エンタープライズ利用の安全性を高めています。このレイヤーでは、データマスキング、毒性検出、監査ログ、ゼロデータ保持、権限チェックなどが行われ、AIが生成・閲覧するデータを安全に管理します。Trust Layerを有効にするには、Setup画面でEinstein AI機能をオンにし、マスキングルールや監査ログの設定を行います。

また、2026年現在ベータ提供されているSetup with Agentforceでは、ユーザー管理、アクセス権のトラブルシューティング、オブジェクト・フィールド作成、Permission Set管理、フロー修正などをエージェントに依頼できます。このとき、エージェントはリクエスト者の権限をチェックし、必ずユーザー確認を求めてから実行する仕組みが組み込まれているため、誤った設定変更を防ぎます。
例えばユーザーの有効化やパスワードリセット、カスタムフィールドの追加などを自然言語で実行でき、画面遷移なく生産性を高められます。

Agent Script自体にもベータ版ならではの制約があります。else ifが使えないこと、乗算・除算がサポートされないこと、インデントやコメントルールが厳格であること、...が変数スロット埋め込み専用であることなど。実装時にはこれらを理解し、将来の正式版で改善される可能性も考慮した設計を行いましょう。

導入のタイミング — プロンプトから始め、必要なところにだけスクリプトを追加

「初めから全部Agent Scriptで書くべきなのか？」という質問をよく受けます。答えはNOです。Salesforceが公表しているパターンガイドでは、まずは簡潔な自然言語指示（レベル2）でエージェントを作成し、特定の失敗パターンが何度も発生する場合にのみ決定論的ロジック（レベル6）を追加することを推奨しています。この段階的アプローチにより、開発コストを抑えつつ安定性を高められます。

導入の目安としては以下が挙げられます：

• 本人確認が必須の場面
• 複数アクションの厳密な順序が必要な処理
• 特定条件下でのみ利用可能なツールを制御したいとき
• 変数に基づく条件分岐が複雑なとき

これらに該当する処理ではAgent Scriptを検討します。特に本人確認や複数手順を伴うワークフローではプロンプトの揺らぎが事故につながるため、決定論的制御が欠かせません。一方で、単純なFAQや単一操作の実行はプロンプトだけでも十分なので段階的な導入が推奨されます。

上記に該当しない場合は、まず簡単なプロンプトだけでエージェントを作り、動作を確認するのが良いでしょう。必要になってからスクリプト化することで、無駄な実装を避けられます。

開発フロー — 設計から実装、テスト、デプロイまで

実際にAgent Scriptを開発し運用する手順は次の5段階で考えると整理しやすいです。

1. 要件定義とプロセス設計：業務フローを図に落とし込み、必要な処理や例外を洗い出します。
2. トピック・変数・アクションの設計：フローをトピックに分解し、状態を管理する変数や外部連携アクションを定義します。
3. スクリプト作成とツール設定：YAMLベースのAgent Scriptを記述し、ロジックとプロンプトを分離します。必要に応じてavailable whenでツール使用条件を設定します。
4. テストとプレビュー：Agentforce BuilderのCanvasビューとScriptビューでフローを確認し、テストパネルでシミュレーションを行います。
5. デプロイと継続的改善：本番デプロイ後はTrust Layerの監査ログで挙動を監視し、ユーザーフィードバックを基にスクリプトとプロンプトを改善します。

利用シーン — エージェント活用の具体例

Agent Scriptはシステム管理、カスタマーサポート、社内手続き、ITサービス、データ統合など幅広いシーンで利用できます。例えば、Setup with Agentforceではユーザーの有効化やオブジェクト作成、Permission Set管理などを自然言語で依頼でき、カスタマーサポートでは注文確認や返品処理のフローをトピックとして定義して自動化できます。人事・総務領域では休暇申請や規程案内などをエージェント化し、ITサービスではパスワードリセットやソフトウェアインストール要求を認証と承認付きで処理できます。GraphQLミューテーションやLWCとの連携により他システムからデータを取得し、レポートやグラフを生成する用途にも活用でき、状態管理と権限チェックを組み合わせることで安全に運用できます。

今すぐやるべきチェックリスト — 自分のエージェントを診断しよう

読み終えたら、次のチェックリストをもとにご自身のエージェントをレビューしてみましょう。

1. 本人確認を必ず行っているか — 変数isVerified等で管理し、確認せずに処理へ進んでいないかチェックします。
2. アクションの順序を明示しているか — run命令を適切に並べ、LLMに任せていないか確認します。
3. トピック分割が明確か — 1トピック1責務になっているか。複雑なフローは細かく分割し、遷移を明示していますか。
4. ツールの利用条件を設定しているか — available whenやtransitionで条件付き利用を実装し、誤操作を防止していますか。
5. 変数で状態管理しているか — 会話の文脈に頼らず、重要な情報を変数に保存して次のステップで活用していますか。

チェックが終わったら、問題がある箇所に対してAgent Scriptを適用し、改善してみましょう。小さな改善でも効果は大きく、エージェントの信頼性が飛躍的に向上します。

よくある質問と誤解 — 間違えやすいポイントを解消する

Q1: Agent Scriptは開発者しか書けないのですか？

いいえ。Agent ScriptはYAMLライクなシンタックスを採用しており、Salesforce Adminやビジネスユーザーでも習得しやすいよう設計されています。Canvasビューで視覚的にフローを作り、Scriptビューに切り替えて調整することも可能です。

Q2: Agent Scriptを書けばLLMは不要になりますか？

Agent ScriptはLLMと併用します。決定論的な部分だけをスクリプト化します！！。

今後の展望 — Agentic Enterpriseへの進化

Agent Scriptの開発はまだ始まったばかりですが、今後は信頼層の自動化と拡張、Agentforce BuilderのUI改善、GraphQLなどタイプセーフなAPIとの統合、複数エージェントの協調オーケストレーションが進むと予測されています。こうした進化によって、単なるチャットボットではなく企業全体のプロセスを担うエージェントが実現し、設計思想を押さえておくことで未来の変化に柔軟に適応できるようになります。

LLM技術は日々進化していますが、業務プロセスには確実性と説明可能性が求められます。Agent Scriptのような決定論的ロジックは、人間の判断基準を明文化し、AIの自由度と組み合わせることで組織のワークフローを向上させます。将来的には複数のエージェントが連携しつつ統制されたプロセスを築き、自動化が一段と進化するでしょう。準備が必要です。

まとめ — 次に読むべきもの

この入門編では、LLMの限界とAgent Scriptの必要性、基本構造や失敗パターンの対策、導入の考え方を学びました。AIに任せきりにせず、本人確認や処理順序、トピックルーティングをスクリプトで制御することが重要です。Agent Scriptは自然言語の柔軟性と決定論的ロジックを組み合わせることで信頼性を高め、変数やトピック、アクションを使うことで安定したワークフローを構築できます。導入はまずプロンプトだけで始め、必要に応じて段階的にスクリプトを追加するのが効果的です。準備が整ったら次の「実装編」で具体的なコードの書き方を学び、最終的な「実践編」で本番運用やセキュリティを深掘りしてください。Agent Scriptを使ってあなた自身がAI設計者へ成長するお手伝いができれば幸いです。

お問い合わせ

現在Salesforceを効果的に活用できていない企業様や、これからSalesforceの導入を検討している企業様で、設定や運用、保守に関するサポートが必要な場合は、ぜひお気軽にご相談くださいませ！