信頼性の高いAIエージェントの動作を実現するためのAgentforceガイド：決定論の6段階フレームワーク

Olfa Kharrat、製品管理担当ディレクター - Agentforce
Reinier van Leuken、製品管理担当シニアディレクター - Agentforce

信頼は、1999年の創業以来、SalesforceのNo.1の価値であり、クラウドコンピューティングとSaaSの新しいテクノロジーモデルを開拓してきました。企業は、貴重な企業データをクラウドに保存し、そのデータが安全で適切なアクセス制御によって管理されていることを認識することで、Salesforceに信頼を寄せています。それは依然として重要ですが、エージェント型AIの時代には、信頼の定義はさらに広くなっています。企業が重要なビジネス機能を実行するために自律型エージェントに依存するようになるにつれて、AIエージェントは、仕事が正確かつ適切で頼りになるような、信頼の置けるビジネスパートナーになる必要があります。

では、信頼できるAIエージェントを構築するにはどうすればよいのでしょうか？通常、信頼性とは、同じ入力に対して同じ結果が出力されることを意味します。しかし、AIエージェントは大規模言語モデル（LLM）をベースにしているため、必ずしもそのように機能するとは限りません。LLMは本質的に非決定論的です。非決定論的であることで、AIエージェントは、遭遇する条件や状況を一々明示的にプログラムすることなく、特定の状況に合わせた創造的なソリューションを開発できる流動性を手にしています。ただし、AIエージェントには、ビジネス要件に準拠し、運用ガイドラインを遵守するためのガバナンスも必要です。ビジネスプロセスを実行する際には、信頼性を実証し、決定論的制約に合致するビジネス成果を生み出す必要があります。決定論は、厳格性と規律を課するため、AIエージェントが持つ自律性と流動性に対立します。したがって、AIエージェントの作成を成功させるための鍵は、創造的な流動性とエンタープライズコントロールの適切なバランスを取ることです。

このドキュメントでは、信頼性の高いAIエージェントを開発するために重要な検討事項について説明します。6つのエージェント型制御レベルを定義し、それぞれのレベルにおけるエージェント型行動の管理と維持に関するベストプラクティスを提供します。このガイダンスはAgentforceの推論エンジンの動作を踏まえて説明しています。Agentforceが拡大、進化するに伴い、このドキュメントも最新のベストプラクティスを反映して随時更新されます。

このドキュメントでは、AgentforceのAIエージェントの設計と構築に関する基本的な知識があることを前提としています。Agentforceの概要については、以下をお勧めします。

• agentforce.comのリソースを確認する。
• トレイル「Agentblazer Championになる 」に従う。このトレイルでは、AIのコア概念について学びます。主要タスクを実行する基本的なAIエージェントの作成に役立ちます。
• help.salesforce.com でAgentforceについての記事を読む。特に「Design and Implement Agents （AIエージェントの設計と実装）」が参考になります。この学習マップは、ソリューションのアイデア出しから、AIエージェントの設定と構成、テスト、導入、モニタリングまで、すべての主要ライフサイクルステップをガイドします。

AIエージェントの行動をより深く理解するために、まずAIエージェントと、目的は似ているものの硬直的なチャットボットを比較してみましょう。

チャットボット：硬直的にルールに従う

チャットボットは、自身が参加できるダイアログを構造化する、事前に決定されたディシジョンツリーに従います。ディシジョンツリーの走査は、ユーザーの回答にもとづいて実行されます。この回答は、択一式の選択にすることも、自由テキストの回答にすることもできます。自由テキストの回答の場合、インテント分類には予測的モデルが使用されます。これらのツリーは、潜在的なすべての会話経路をマッピングし、各ステップにおけるチャットボットの応答を決定します。チャットボットの行動は、事前に設定されたルールによって硬直的に決定されます。ユーザーの入力が認識されたパスと一致しない場合、または予測的モデルが特定のインテントを認識するようにトレーニングされていない場合、チャットボットは適切に応答できません。

AIエージェント：適応力があり、直感的

対照的に、AIエージェントはLLMの力と自然言語処理（NLP）の高度な機能を活用します。AIエージェントは、LLMにより、ユーザーの入力が予期しない方法で表現されていても、その背後にあるインテントを理解できます。AIエージェントは、インテントの理解にもとづいて、さまざまな可能性の中から最も適切なアクションを選択できます。AIエージェントは、まったく新しい応答を構成することもできます。この柔軟性と適応力により、AIエージェントはチャットボットとは一線を画しています。

料理を活用したアナロジー

チャットボットとAIエージェントの違いは、新米コックと熟練のシェフの違いに例えることができます。

• 新米コック（チャットボット）は、正確な分量、段階的な手順、具体的な調理時間が記載された詳細なレシピに頼り切っています。レシピから少しでも外れると、料理は大失敗します。同様に、チャットボットは、事前にプログラムされたディシジョンツリーの枠組みの中で動作しなければなりません。
• 長きにわたる調理経験と直感を備えた熟練のシェフ（AIエージェント）。あなたの好みのざっくりとした理解と、使える材料の簡単な説明だけで、あなたを満足させる美味しい料理をささっと作れます。厳密な手順は毎回異なる可能性があり、料理自体も作るたびに微妙な違いがあるかもしれませんが、全体的な結果は一貫して満足のいくものです。同様に、AIエージェントはユーザーの入力のコンテキストとインテントにもとづいてアプローチを適応させ、インタラクションを成功させることができます。

話をまとめると、AIエージェントとチャットボットの根本的な違いは、適応力と予期しない入力を処理できる能力にあります。

AIエージェントのインテリジェンスの明確な特徴は、最適なアクションを適切なタイミングでオーケストレーションして動的に実施できる能力にあります。この柔軟性により、あらゆる潜在的なユーザーインタラクションを広範囲にプログラムする必要がなくなります。

Agentforceでは、AIエージェントを構築するには、トピック、アクション、自然言語による指示、説明が必要です。

トピック

トピックとは、AIエージェントが「完了すべきジョブ」です。トピックには、分類の説明、スコープ、各ジョブとその実行方法を定義する指示などの属性があります。トピックには、AIエージェントが実行できるアクションと、これらのアクションがどのように実行されるかを管理する指示が含まれます。

アクション

アクションとは、AIエージェントがジョブを遂行するために実行できる事前定義されたタスクです。アクションには、次の5種類があります。

• Apexコードの実行
• APIを呼び出し
• フローの実行
• プロンプトテンプレートに対するLLM応答の取得
• 予測的モデルの呼び出し

自然言語による指示と説明

AIエージェントの定義には、AIエージェントのアセットを説明し、AIエージェントが従うべきガイドラインを定義する自然言語の指示が含まれています。指示は、アクションとトピックに対して書かれます。

• アクション。アクションには以下が含まれます。
  • アクションが何をするかを説明する指示。このアクションをいつ実行すべきかを推論エンジンに伝えます。
  • AIエージェントが準備できるよう、自然言語で説明した入力。
  • どのような形式で出力し、どのように使用するかを自然言語で説明した出力。
• トピック。トピックには、より高レベルでアクションをどのように実行すべきかを規定する指示が含まれています。たとえば、指示には、声のトーン、望ましいアクションの順序、想定される前提条件、いつ人間に会話をエスカレーションすべきかに関するガードレールを指定できます。トピックには、分類の説明とスコープの境界設定も含まれています。これらすべてによって、AIエージェントは定められたロールのスコープを逸脱することなく、ジョブを実行します。
• データ。AIエージェントには、ジョブを成功させるためのデータが必要です。データには、CRMデータなどの構造化データと、企業のナレッジ記事などの非構造化データがあります。AIエージェントはアクション入力を使用してデータにアクセスします。アクションは、たとえば、CRMデータにグラウンディングしたプロンプトテンプレートや、RAG手法を使用して非構造化データのチャンクで拡張したプロンプトテンプレートを呼び出すことができます。

これらのさまざまな構成要素が正しく構築されていれば、AIエージェントが適切な境界を逸脱することなく、意図した目的を実行するのに役立ちます。

Agentforceの推論エンジンは、これらの構成要素をオーケストレーションして、適切なエージェント行動に落とし込みます。また、トピックとアクションに定義された自然言語の指示と説明を活用します。これは、2022年にYaoらによって導入されたLLMのための新しい推論パラダイム、ReActにもとづいて構築されています。このパラダイムは、問題について推論し、アクションを実行し、アクションの結果を観察し、このサイクルをタスクが完了するまで繰り返すことで、人間のタスク管理を模倣します。

SalesforceのAIエージェントは、このパラダイムを遵守しています。

1. 推論：ユーザーのインテントを把握し、適切なトピックとアクションに関連付けます。
2. 行動：適切なアクションのチェーンを開始します。
3. 観察：ユーザーのインテントに照らしてアクションの結果を評価します。インテントが満たされていない場合は、これまでに得られた結果と、トピック/アクションの指示と説明にもとづいてさらに推論します。インテントが満たされた場合は、指定された形式があればそれに従って最終回答を出力します。
4. 反復：指示された最終ステップに到達するまで、これらのステップを繰り返します。

推論エンジンは、あらゆる推論でLLMを使用し、ステップを観察します。アクションタイプによっては、行動ステップでLLMを使用することもできます。

このセクションでは、AIエージェントの決定論を強化するための段階的アプローチについて説明します。各レベルは前のレベルを基盤として構築され、複雑性と機能が段階的に増加し、AIエージェントの行動をより細かく制御できるようになります。

最初のレベルでは、AIエージェントが関連するトピックを自律的に識別し、明示的な指示ではなく、目標を使用して適切なアクションを選択できるようにすることに重点を置いています。コアメカニズムは、コンテキストを理解してユーザーの入力に応答することです。技術的には任意のアクションタイプを追加できますが、ここではアクションがプロンプトアクションであると想定します。プロンプトアクションを備えた指示のないトピックは、よくある問い合わせを迅速かつ効率的に処理する手段を提供します。

このレベルでは、動的な理解を通じて、AIエージェントの応答性と自律性のベースラインレベルを確立することが重視されます。

指示のないアクション選択の基盤にもとづいて、このレベルでは、AIエージェントの行動をガイドする明示的な指示を導入します。正確な指示を追加することで、AIエージェントがさまざまな状況にどのように対応するかを制御できるようになります。AIエージェントへの指示は、ルール、ガイドライン、ガードレール、例のようなものです。これらは、さまざまなトピックを処理し、アクションを実行し、出力を処理する方法について、AIエージェントに具体的な指示を与えます。このレベルの目標は、一貫性を高め、企業のガイドラインとプロセスを厳格に遵守させるために、AIエージェントに明確なガイダンスを提供することです。

グラウンディングとは、AIエージェントの理解と応答を外部のナレッジソースに結び付けることです。グラウンディングにより、AIエージェントによって提供された情報の正確性、最新性、関連性を確保できます。このレベルでは、データベース、知識ベース、その他の情報リポジトリへのアクセスが統合されます。AIエージェントの応答を検証済みのデータにグラウンディングすることで、AIエージェントの信頼性と信用が強化されます。

このレベルでは、AIエージェントが変数を使用する機能が追加されます。変数があることで、AIエージェントはインタラクションをパーソナライズし、複数のインタラクションをまたいでコンテキストを保持し、エージェントセッション中に維持されている特定のデータポイントにもとづいて行動を動的に調整できるようになります。たとえば、AIエージェントは、ユーザーの好み、注文の詳細、その他の関連情報を取得し、そのデータを使用してインタラクションを調整できます。変数の追加により、AIエージェントはより複雑で詳細に規定され、パーソナライズされたインタラクションを適切に処理できるようになります。

このステップでは、AIエージェントをSalesforceの主要機能であるApex、API、フローと連携させます。この連携により、AIエージェントはSalesforceエコシステム内で複雑な操作を実行できるようになり、データのアクセスや操作、ワークフローの起動、他システムとの連携などが可能になります。

• Apexは、プログラムによる制御が可能になります。
• APIは、他のアプリケーションとのシームレスな連携が可能になります。
• フローは、複雑なビジネスプロセスを自動化できます。

このレベルでは、AIエージェントは、高度なタスクを実行し、ビジネス成果に直接貢献できる強力なツールに変身します。

レベル5の技術的連携にもとづいて、この最終レベルでは決定論的推論を導入し、確率的AIと厳格なビジネスロジックの間のギャップを埋めます。以前のレベルでは、使用するツールの選択をLLMに委ねていましたが、Agent Scriptを使用すると、推論プロセス自体を「ハードコード」できます。ドキュメントスタイルのキャンバスまたは直接コードを使用して、必須の認証ゲート、if/else条件分岐、強制トピック遷移など、ユーザーの入力に関係なくAIエージェントが従う必要がある不変パスを定義できます。このハイブリッド推論アプローチにより、LLMの会話の柔軟性を、保証された実行レイヤーで挟み込むことができます。レベル6では、AIエージェントがゼロトラストのエンタープライズグレードのパートナーへと進化し、リスクの高いコンプライアンス、規制開示、複雑なマルチステップの依存関係を、絶対的な精度で処理できるようになります。

AIエージェントの応答性と自律性のベースラインを出発点として、トピックとアクション、それに対応する説明のみで構成されるAIエージェントについて考えてみましょう。このサンプルエージェントを使用して、推論エンジンの各ステップについて説明し、AIエージェントがこれらの説明をどのように使用して適切なトピックと実行するアクションを選択するかを示すことができます。この例ではトピック指示を省いているため、レベル1のAIエージェントが上位レベルと比べて最も高い自由度を持つことが確認できます。レベル1では、AIエージェントは進行中の会話のみにもとづいて、適切だと考えるアクションを完全に自由に選択できます。

以下の推論エンジンに関する考慮事項を確認してください。

• 構成設定は、推論エンジンのLLMに対して固定されています。エージェントビルダーはこれらを変更できません。現在、エージェントビルダーは、推論のためにSalesforceインフラストラクチャ上でホストされたOpenAIのLLMまたはAnthropicのLLMのいずれかを選択できます。今後、さらに多くのモデルが追加されるにつれて変更される可能性があります。
• 推論エンジンのデフォルト履歴： 推論エンジンへのリクエストが発生すると（ステップ2～5）、推論エンジンは最新のリクエストと応答の履歴を自動的に検索します。これにより、推論エンジンの会話コンテキストが維持されます。顧客とのやり取りに加え、プランナーLLMへのこれらの呼び出しには、トピック選択などの他のリクエストに対応するための推論エンジンLLMへの呼び出しも含まれます。

推論プロセスには、次の4つの主要ステップがあります。

1. トピックの選択
2. アクションの選択
3. エージェントループ
4. グラウンディングチェック

トピックは、AIエージェントが適切なアクションまたはアクションのシーケンスを分類する際の正確性を向上させるように設計されています。各トピックは、意味的に区別可能な複数のアクションで構成されている必要があります。これらのアクションは、すべて1つの簡潔なトピック説明に、そして類似する1つのAIエージェント機能に属することができます。

推論エンジンLLMによって、適切なトピックが選択されます（図のステップ2～3）。LLMは、トピックプロンプトを使用して、分類の説明が最後の発話に最も近いトピックを選択します。このトピックプロンプトには、すべてのトピックの分類の説明と会話履歴が表示されます。会話履歴には、発話とAIエージェントの応答に加えて、実行されたアクションとその結果が含まれます。さらに、このプロンプトには重要な指示が組み込まれており、会話履歴のコンテキスト内での分析を義務付け、LLMに思考プロセスを共有することを求めています。

その他の考慮事項：

• 可視トピックと併せて、「オフトピック」の発話に対応する追加の隠しトピックが自動的に存在します。このトピックは、他の既存のトピックが発話と一致しない場合に選択されます。これにより、AIエージェントは誤分類を回避できます。このトピックにはアクションはありません。推論エンジンが後から適切な応答を構成できるようにするためだけに存在します。
• トピックプロンプトでは、トピックの名前と分類の説明のみが使用されます。
• 推論エンジンLLMは、一度に1つのトピックしか選択できません。
• 会話は予期せず方向転換することがあります。推論エンジンは、発話を受け取るたびにトピック選択ステップに進みます。つまり、新しい発話ごとに新しいトピックが選択可能になるということです。

トピックの目的は2つあります。

1. アクションをグループ化することで、推論エンジンを混乱させるリスクを軽減し、推論エンジンが誤ったアクションを選択しないようにします。
2. アクションの選択と実行を指示でガイドします（詳細については、レベル2：エージェント制御：指示を参照）。

AIエージェントの能力を、関連アクションで構成され、明確に定義されたトピックに慎重に整理することで、AIエージェントは効果的かつ予測どおりに動作し、更新と拡張が容易になります。トピック設計には、トップダウンとボトムアップの2つのアプローチがあります。

• トップダウンアプローチでは、まずAIエージェントが担う高レベルのジョブ（達成すべきタスク）としてトピックを設計し、その後で各トピックに対する個別のアクションを定義します。
• ボトムアップアプローチでは、個別のアクションをすべて定義してから、トピックにグループ化します。

どちらのアプローチも、適切に従えば良い結果につながります。

ボトムアップアプローチ

このセクションではボトムアップアプローチについて順を追って説明します。ボトムアップアプローチは、そもそも推論エンジンがトピックを必要とする理由と密接に関連しているからです。

ステップ1： すべてのAIエージェントアクションのリストアップ

まず、AIエージェントが実行できる必要のある具体的なアクションをすべてリストアップするところから始めます。この段階では、一般的にし過ぎず、非常に具体的にすることが大切です。早い段階でアクションをグループ化したり、単純化したりしないでください。目標はAIエージェントができることの包括的かつ詳細な視野を作成することです。

たとえば、カスタマーサービスエージェントの場合、最初のリストには次のようなものが含まれる場合があります。

• 注文を返品する：注文の返品プロセスを開始するときに使用します。
• 在庫状況を確認する：商品の在庫があるかどうかを確認するときに使用します。
• 商品交換ポリシーを確認する：交換ルールに関する情報を取得するときに使用します。
• ナレッジで質問に回答する：一般的な質問やFAQ形式の質問に回答するときに使用します。
• プロモーションを確認する：利用可能なプロモーションや割引を確認するときに使用します。
• 配送日を予測する：予想配送日時を推定するときに使用します。
• 注文状況を確認する：顧客の注文の現在のステータスを検索するときに使用します。
• 顧客注文を検索する：特定の顧客による過去のまたはアクティブなすべての注文を検索するときに使用します。
• 技術的な問題をトラブルシューティングする：商品やサービスの技術的な問題を解決するときに使用します。
• 顧客注文条件を検索する：注文に関連するすべての条件を検索します。
• 顧客アセットを検索する：顧客に関連付けられたアセットを特定または検索するときに使用します。
• 配送先住所を変更する。

この時点では、「顧客の苦情の解決」などのアクションは広範すぎることに注意してください。アクションは、AIエージェントの行動の最小単位の細かさを表す必要があります。苦情にはさまざまな種類があり、それぞれ異なるアクションにすでに対応が含まれています。

• 商品の損傷や機能不全のトラブルシューティングなど、配送後の問題は、「技術的な問題をトラブルシューティングする」に含まれています。
• 配送されない、配送日の変更の必要性、注文の変更などの配送前の問題は、「注文状況を確認する」、「配送日を予測する」、「注文を返品する」などのアクションに含まれています。
• ポリシーに関する問い合わせなど、一般的な顧客の懸念は、「ナレッジで質問に回答する」または「商品交換ポリシーを確認する」に含まれています。

ステップ2：推論を混乱させる可能性のあるアクションのペア（または複数のアクション）にマークを付ける

性質がよく似ているアクションをマークします。推論エンジンを混乱させる可能性があるからです。説明に意味的に十分な差異がないと、推論エンジンはステップ5でどちらのアクションを選択すべきか判断できなくなります。

たとえば、「技術的な問題をトラブルシューティングする」と「ナレッジで質問に回答する」の説明は似ていますが、機能が大きく異なる場合があります。このような意味的な重なりをマークすることで、複数のトピック間に分離すべきアクションを識別できます。

ステップ3：トピックとしてアクションの最初のグループを作成

アクションを明確に定義し、意味的な重複を特定したら、アクションを仮トピックにグループ化できます。トピックは、機能の論理的なカテゴリであり、全体としてAIエージェントの一貫した能力またはスキルを表すアクションのグループです。

これらのグループを作成する際は以下に注意してください。

• 使用するトピックの数を必要最小限に抑えることで、意味的な重複を回避します。
• 各トピックに、相互の関連性に意味のあるアクションが含まれるようにします。
• 連続して実行する必要がある補助的なアクションは、必ず同じトピック内に含めます。

ここでは、カスタマーサービスエージェントの初期グループ化の例を示します。

トピック1：

• 注文を返品する
• 在庫状況を確認する
• 商品交換ポリシーを確認する
• プロモーションを確認する
• 配送日を予測する
• 顧客注文条件を検索する
• 注文状況を確認する
• 顧客注文を検索する
• 顧客アセットを検索する
• ナレッジで質問に回答する
• 配送先住所を変更する

トピック2：

• 技術的な問題をトラブルシューティングする
• 顧客アセットを検索する

ステップ4：トピックの分類の説明を記述し、必要に応じてトピックを分割する

最初のグループ化が完了したら、各トピックの分類の説明を記述します。

• 私たちの例のトピック2は、明確に商品の技術的な問題に関するものです。
• 一方、トピック1が対象としているスコープは広範囲です。大部分は、注文管理に関するものですが、注文管理と関係のないアクションも含まれています。プロモーションの確認やナレッジによる質問への回答などです。トピック1は1文で明確かつ簡潔に説明することはできないため、トピックを複数のトピックに分割する必要があります。

改善後、トピックは次のようになります。

• トピック1：注文管理：顧客の注文と関連する物流の管理と変更に関連するアクションについて説明します。交換と返品に関連するアクションは除きます。
  • 在庫状況を確認する：商品の在庫があるかどうかを確認します。
  • 配送日を予測する：注文がいつ届くかを推定します。
  • 注文状況を確認する：顧客の注文状況を確認します。
  • 顧客注文を検索する：顧客が発注したすべての注文を検索します。
  • 配送先住所を変更する。
• トピック2：トラブルシューティング
  • 顧客アセットを検索する：顧客の登録済みデバイスまたは商品を検索します。
  • 技術的な問題をトラブルシューティングする：技術的な支援や診断的分析を提供します。
• トピック3：交換： 注文の交換と返品に関連するアクションについて説明します。
  • 注文を返品する：注文返品プロセスを開始します。
  • 商品交換ポリシーを確認する：商品の交換ルールを提供します。
  • 顧客注文を検索する：顧客が発注したすべての注文を検索します。
  • 顧客注文条件を検索する：注文に関連するすべての条件を検索します。
• トピック4：商品サポート：情報の検索とルーティングに使用される横断的なアクションについて説明します。
  • ナレッジで質問に回答する：知識ベース情報を使用して、一般的な顧客からの問い合わせに回答します。
  • プロモーションを確認する：現在のプロモーションや割引を表示します。

要約すると、最初に可能なすべてのアクションの包括的なリストを作成し、アクション間の意味的な重複をマークします。次に、（1つのトピックの境界内で推論エンジンが混乱しないように）少なくとも意味的な重複をすべて解決できるトピックのセットを作成します。次に、すべてのトピックの分類の説明を記述します。トピックのスコープが広すぎる場合は、もう少し細かくトピックを分割します。このガイダンスを実施することで、パフォーマンスが優れているのみならず、メンテナンスや拡張も簡単なAIエージェントを構築できます。

この構造により、より優れた推論、より正確な実行、そしてAIエージェントの行動における、より明確な判断の境界が実現します。また、AIエージェントの機能をより透明性が高くモジュール化されたものにするには、デザイナー、エンジニア、各分野の専門家のコラボレーションが不可欠です。

効果的なトピック設計のための追加検討事項

• 最適なトピック数：トピックの分類でLLMのパフォーマンスを向上させるには、一般的にトピックの数が10を超えないようにすることをお勧めします。しかし、これは目安に過ぎません。さらに、各トピックには明確で他と区別できる説明が必要です。最終的に、最適なトピック数は、トピックの分類の説明と説明の間の意味的な距離に依存します。トピックの分類の説明が大きく異なる場合、トピックが重複するリスクは最小限に抑えられます。トピック間の重複を回避するためのその他のベストプラクティスについては、こちら を参照してください。
• トピックのサイズと明確さのバランス：一般的に、分類しやすくするには、トピックのアクションや指示を小さめにすることは有益ですが、アクション間の意味的な重複が誤分類につながるように、説明が非常に似たトピックを沢山作りすぎると混乱につながる可能性があります。したがって、トピックの説明が意味的に明確に区別できるようにすることが重要です。LLMを使用すると、明確に区別できる分類を作成できます。
• 標準的な言葉とコンテキストの明確さ：LLMが特定の企業やビジネスの意味や略語を認識できない場合があります。標準的な言葉を使うか、特定のコンテキストで使用する単語の意味を明確に説明します。
• トピックプロンプトでは、トピック名と説明のみが送信されます。したがって、トピックのスコープや指示を変更しても、トピックの選択には影響しません。

実例

サービスエージェントが腕時計の保証ポリシーリクエストを受け取ったとします。この保証の問題は、商品の交換やサポートに関連しているようには見えません。注文管理が、このリクエストに対処するための最も適切なトピックのようです。したがって、リクエストを満たす可能性が最も高いトピックとして、後者が推論エンジンによって選択されます。

トピックを選択した後、推論エンジンは、選択したトピックから実行する適切なアクションを選択します。推論エンジンLLMが再び選択を担当し、観測プロンプトと呼ばれる別のプロンプトを使用します。観察プロンプトの目的は、推論プロセスの次のステップを取得することです。この次のステップは、次のいずれかになります。

• アクションを起動する
• ユーザーにアクション入力をリクエストする
• ユーザーにリクエストの明確化をリクエストする
• アクションループが完了したら（詳細は推論ステップ3を参照）、最終回答をユーザーに送信して、ユーザーリクエストを完了する

観察プロンプトへの入力は、トピックに含まれるすべてのアクションのすべての説明と会話履歴から形成されます。

アクション設計のベストプラクティス

アクションとは、AIエージェントがジョブを遂行するために実行できる事前定義されたタスクです。アクションは、作業の最も細かい定義です。AIエージェントアクションには、（1）Apexコードの実行、（2）APIの呼び出し、（3）フローの実行、（4）プロンプトテンプレートに対するLLM応答の取得、（5）予測的モデルの呼び出しの5種類があります。これらのアクションのほとんどは決定論的です。例外はプロンプトテンプレートに対する応答の取得です（外部システム、フロー、またはApexアクションにプロンプト呼び出しなどの確率的要素が含まれていないと仮定）。これらの問題については、エージェント制御のレベル5で説明します。

1. プロンプトアクションにおけるエージェント型行動の制御：プロンプトアクションでAIエージェントの行動を制御するには、次の2つの方法があります。（1）プロンプトエンジニアリングを通じてプロンプトテンプレートに指示を追加する。（2）LLMのハイパーパラメーターでプロンプト応答を生成するもの、特に温度を設定する（ドキュメント を参照）。温度パラメーターを下げると、生成される応答のばらつきが減り、応答の再現性とAIエージェントの信頼性が向上します。
2. 1つのトピックに含まれる最適なアクションの数：トピックの最大数と同様に、1つのトピックに含まれるアクションの数は10を超えないようにすることが推奨されます。繰り返しになりますが、これは目安です。実際の決定要因は、アクション間の意味的な距離です。説明によってアクションが明確に区別できる場合は、この数値を大きくすることができます。ただし、意味的距離を数値で測定することはできません。これは、エージェントビルダーの解釈に委ねられます。アクションの説明同士の意味の違いが大きいほど、意味的距離が大きくなります。ここでは、重複は常に避ける必要があります。
3. アクションの説明：「アクション指示」は、その名称から想像される内容とは異なり、推論エンジンLLMがトピックから適切なアクションを選択するために使用する指示です。アクションの説明が意味的にはっきり区別できると、分類の品質が大幅に向上することに注意してください。これらの説明を慎重に確認し、特に同一トピックに属するすべてのアクションの説明を比較してください。

実例

前の例を続けましょう。サービスエージェントは、腕時計の保証ポリシーに関する質問を受け取りました。注文管理トピックが選択された後、最も適切なアクションが選択されます。これは注文管理トピックであるため、論理的な最初のステップは、注文検索アクションを起動して、注文を検索することです（そうでなければ、何の保証情報を検索するというのでしょうか？）。

ユーザーの発話は、回答がユーザーに送り返される前に、複数のアクションの実行を動的に実施できます。これはエージェントループによるもので、次のいずれかの条件が満たされるまで、最も適切な次のアクションの選択と実行を繰り返します。

• 推論エンジンLLMが、リクエストが完了したと判断する。この場合、ユーザーリクエストはその応答によって満たされたと判断されます。このチェックの一部にはグラウンディングチェックが含まれていることに注意してください。応答がアクション出力にグラウンディングしていることを検証します。応答に含まれる一切の情報は、推論エンジンLLMによって創作されるべきではありません。幻覚などの不正確な応答につながる可能性があるからです。
• 適切なアクションが見つからない。
• 現在のステップで許可されているLLM呼び出しの最大数に達した。この数は推論エンジン自身によって設定されます。

アクションに特定のタイムアウトは適用されません。これは、アクションの実行時間が複雑さによって変動する場合に中断を避けるためです。単純に一部のアクションは他のアクションよりも実行が複雑です。

実例

注文検索を開始した後、推論エンジンはこれまでに生成された応答を評価し、回答をユーザーに送り返す前にさらに作業を行う必要があると判断します。会話履歴に注文が記録されたので、次に保証ポリシーを調べます。

ところが、この処理を行う中で、AIエージェントは「注文検索」アクションで検索した情報により、顧客が実際には腕時計を2本購入していたことが判明します。そのため、エージェントループ内で、推論エンジンは顧客にどちらの腕時計の保証情報が必要なのかを指定するよう質問することを決定します。

過剰なスクリプト化を避ける

AIエージェントがユーザーと会話する方法をあまり台本化しすぎないようにします。過剰な台本化は、AIエージェントが信頼関係を築き、ユーザー固有のニーズを理解し、動的な状況にリアルタイムで効果的に応答する能力を妨げます。さらに、長々とした指示により、AIエージェントの応答が遅くなり、推論エンジンが混乱する可能性があります。指示による決定論の強制は、好ましいアプローチではありません。

避けるべきこと

たとえば、AIエージェントに対して、サービス対応で競合他社に言及しないように指示する必要はありません。これは意図しない行動につながる恐れがあります。競合でもあるプロバイダーとの連携について聞かれた際にもAIエージェントが回答を拒否する可能性があるからです。代わりに、「競合他社について話すときは、自社の利益を考慮して回答する」といった指示にすることができます。これにより、「競合他社xyzについては…の場合のみ言及する」といった限定的な条件付き指示を回避し、LLMの推論能力を活用できます。この例は、どうすれば人間のサービススタッフが入社後に研修を受けるのと同様に、抽象レベルの高い指示を与えられるかを示しています。

すべきでないことの例をさらにいくつか見てみましょう。以下は、求人Webサイトで求職者のプロフィールを担当するサービスエージェントに与えられた不適切な指示の例です。このような指示は、求職者に可能なあらゆる発話の予測を試みているため、避けるべきです。

指示1： AIエージェントが「プロフィールに写真を追加できますか？」という質問を受けたら、すぐ求職者に「プロフィールのタイプは何ですか？」と聞き返します。

指示2： 求職者がプレミアムプロフィールであると回答した場合は、「契約情報を確認させてください」と回答し、契約情報を検索して、プロフィール写真の更新について合意があるかどうかを確認します。

求職者が写真を更新できることについて合意があった場合は、「はい、追加できます。新しい写真をアップロードしていただけますか？」と回答します。写真を受け取ったら、それを使用して求職者のプロフィールを更新します。契約内容にプロフィール画像の変更が含まれていない場合は、「申し訳ありませんが、追加することはできません。担当者におつなぎします」と回答します。

指示3： プレミアムプロフィール以外の場合：求職者がプレミアムプロフィール以外であると回答した場合は、「写真を更新することはできません。ご希望でしたら、担当者におつなぎします」と回答します。

指示4： プロフィールタイプがはっきりしない場合は、「プロフィールタイプを理解できませんでした」と回答します。

代わりに行うべきこと

このようなマイクロマネジメントを行うのではなく、AIエージェントの行動や振る舞いを指示する柔軟なアプローチを採用します。以下のベストプラクティスを検討してください。

1. ナレッジ記事に含まれるポリシーやルールについては、指示として記述するのではなく、RAG/ナレッジアクションを使用します。関連情報が適切なタイミングで検索されます。さきほどの例では、「写真の更新」というタイトルのナレッジ記事に、「プロフィールの写真を更新できるのは、契約で写真の変更が許可されているプレミアムプロフィールの求職者のみです」と記載することを意味します。
2. 主なガイドラインとガードレールを会話の内容とは独立して個別に記述します。期待される行動や手順について、AIエージェントに明確で簡潔な説明を提供します。

これらのベストプラクティスにもとづいて指示セットを改善すると、次のようになります。

指示1 ：「アカウントの変更についてのリクエストを受けた場合は、ナレッジアクションを使用してポリシーの確認します」

指示2 ：「該当するポリシーが見つからなかった場合は、質問に回答しないでください」

これらのガイドラインを適用することで、AIエージェントの結果を改善できます。これで求職者がAIエージェントにプロフィールの変更をリクエストしたときに、AIエージェントは、必要なポリシーを知識ベースから検索し、取得したルールを解釈し、そのルールを状況に適用し、最後に求職者に回答する必要があることを理解できるようになります。台本化のしすぎとは対照的に、この行動的なアプローチは汎用性が高く、幅広い場面に応用が効きます。起こりうる会話パターンをすべて書き出さなくても、AIエージェントは幅広い会話トピックに対して期待される行動で柔軟に応じることができるようになります。

アクションの実行順序を強制する（Agent Scriptには適用されません）

オブザベーションプロンプトには指示とアクションの説明が含まれていますが、実行順序は定義されていません。アクションの順序が重要な場合は、同じ指示内で明確に指定する必要があります。Agent Scriptでは、トランジションにより実行順序を強制できます。この点については第6章で詳しく説明します。

求人Webサイトエージェントの例の続きを見ていきましょう。AIエージェントは適切な面接官との面接日程を処理できるようにする必要があります。このとき、まず採用担当者の空き時間を確認してから、求職者に3つの時間枠を提案しなければなりません。

この場合、実行順序を維持するため、指示を別々のボックスに分けないでください。

1. 指示1：面接官の空き時間を確認します。
2. 指示2：次に求職者に適切な時間枠を提案します。

これらの指示は機能しません。なぜなら、推論エンジンは指示2の「次に」が何を指すのか認識できないからです。これは、指示が特定の順序で送信されるのではなく、グループとして推論エンジンに送信されるためです。

そうではなく、シーケンスを定義する指示は一つの文にまとめて、次のように記述してください。

1. 指示1：面接官の空き時間を確認します。次に求職者に適切な時間枠を提案します。

アクション出力を上書きせずに強制する

推論エンジン自体がLLMです。エージェントループに従って最終回答を生成する責任があります。このアプローチは、応答生成にガードレールを提供するAIエージェントの指示を確実に実行したり、ユーザーリクエストを満たすためにエージェントループで実行された複数のアクションの出力を統合したりする際に必要です。

ただし、プロンプトアクションが1つしか実行されていないことが想定される場合、AIエージェントがアクションの出力を一切変更しないような指示を実装することができます。これにより、AIエージェントの行動を予測可能で信頼性の高いものにすることができます。

承認済みのプロンプトテンプレートでこの厳格な遵守を徹底することは、特定のシナリオ、特に一貫性、コンプライアンス、事前定義されたメッセージングが重要な場合に決定的に重要になります。以下に2つの例を示します。

• 規制業種：金融、ヘルスケア、法務など、規制の厳しいセクターで事業を展開する組織は、多くの場合、顧客とのすべてのコミュニケーションを厳格に管理する必要があります。承認済みのプロンプトテンプレートにより、回答を法的および規制要件に確実に準拠させ、誤解、法的責任、不正確な情報の拡散といったリスクを最小限に抑えることができます。
• 事前のテストおよび検証済みの回答：プロンプトテンプレートの正確性、有効性、期待する結果が確実に得られるように、厳格なテストと検証を受けている場合。これらのテンプレートから逸脱すると、その有効性と価値が損なわれる可能性があります。厳密な遵守により、実証済みのメッセージング一貫して提供されることが保証されます。

この指示は、AIエージェントがアクションの出力を変更する自由を制限します。このPlan Tracerに示されているように、指示がプロンプトテンプレートの出力（「promptResponse」など）を参照していることを確認してください。

そのため、この場合の指示は次のようになります。

「 AIエージェントのチャネルに関係なく、promptResponseの出力を変更しないでください 」

厳格な遵守を求める際の制約：

1つのインタラクションで複数の異なるエージェントアクションが必要な場合、単一のテンプレートを厳格に遵守させることは現実的ではありません。実際、このような状況では、推論エンジンがこれらのアクションを1つの回答にまとめるため、すべてのアクション出力を変更する必要があります。

最適な指示数

一般的なLLMの特性にもとづくと、目標とする指示の数は、指示の複雑さと指示のインタラクションに応じて5〜10個の範囲になります。推論エンジンが従える指示の数に影響する指示特性は次のとおりです。

• 明確性と特異性：明確に定義されたルールは、従いやすくなります。
• ルール間の競合：ルールが互いに矛盾する場合、解決のための追加のロジックが必要になります。
• 長さと複雑さ：各ルールに深い推論が必要な場合は、小さな指示に分割することを検討してください。

指示に従うことが非常に重要な場合は、その重要性を反映する用語を追加します。

• 緊急性と重要性（即時、緊急、重大、必須、義務）
• 権限と執行（必要、強制、厳格に実施）
• 結末と警告（違反すると〜になる、遵守しないと〜になる、非遵守は〜を招く、厳罰が適用される、例外なく）
• 明確性と直接性（必ず、禁止、禁忌、許可されない、必ず/絶対に）

データにもとづいてグラウンディングすることで、AIエージェントの信頼性と信用性は大幅に向上します。グラウンディングされた応答は、推測や古いナレッジにもとづくのではなく、事実情報にもとづいています。検索拡張生成（RAG）は広く採用されている手法で、AIエージェントが知識ベースにアクセスして、より正確かつ文脈に即した回答を生成できるようにします。ユーザーの問い合わせにもとづき、AIエージェントは検索拡張生成（RAG）を用いて適切なデータソースから関連情報を取得し、その情報をプロンプトに付加した上でLLMに送信します。検索拡張生成（RAG）を利用するAIエージェントは、対話の品質、正確性、全体的な有用性が向上するため、ユーザーの信頼と満足度が向上します。検索拡張生成（RAG）のベストプラクティスについては、「Agentforce and RAG: best practices for better agents」という公開ホワイトペーパーを参照してください。

ナレッジと指示の違い

ガイダンスと柔軟性の適切なバランスを取るには、ナレッジと指示を区別することが重要です。両者の目的は異なるからです。

• ナレッジ：ナレッジは、AIエージェントが回答を生成する際にアクセス可能な図書館の蔵書のようなものと考えてください。たとえば、ドキュメント、ナレッジ記事、ホワイトペーパーなどがナレッジです。企業のポリシーや一般的な社内規則が含まれることもあります。ナレッジが、メール、通話記録、さらには（AIエージェントの）会話履歴などの取引ファイルを指すこともあります。最後に、ナレッジには構造化データの長いテキストフィールドが含まれます。ナレッジは通常、RAGを通じてAIエージェントに提供されます。
• 指示：指示は、AIエージェントが各アクションをいつ使用すべきかを明確にする最小限のルールセットと考えてください。指示は、適切な語調など、会話全体にガードレールを設けることもできます。多くの場合、指示は明確さやインテントを損なうことなく、より簡潔で柔軟にできます。想定されるすべての顧客シナリオに対して具体的な回答を記載した硬直的な台本を提供するのではなく、AIエージェントがさまざまな状況で適切なアクションを選択できるようにするための一般的なガイドラインや原則を実装することを検討してください。

検索拡張生成（RAG）

検索拡張生成（RAG）は、ナレッジのインテリジェントなデータレイヤーとして機能します。AIエージェントはさまざまな形式の情報にアクセスでき、質問に答えるための関連するテキストフラグメントを提供します。RAGを使用すると、AIエージェントは、無関係なコンテンツでLLMプロンプトを圧迫したり、コンテキストウィンドウを超えたりすることなく、より正確なLLM応答を得ることができます。

RAGは実行時に次の3つのステップを実行します。

1. 検索：AIシステムは、大規模なデータベースやナレッジソースを検索して、LLMプロンプトに必要な関連情報を収集します。これは、従来のキーワードベースの検索よりも洗練された手法であるセマンティック検索を使用して行われます。完全一致する用語を探すキーワード検索とは異なり、セマンティック検索では、単語の背後にある意味やコンテキストを理解しています。正確な単語の一致を探すだけでなく、概念や用語間の関係性にもとづいて関連情報を特定します。キーワード検索は、この検索プロセスでも役割があり、特定の用語や名前のキーワードマッチングでセマンティック検索を強化できます。この検索タイプはハイブリッド検索と呼ばれます。
2. 拡張：検索した情報がプロンプトに追加されます。
3. 生成：LLMは、検索したナレッジで拡張されたプロンプトにより、コンテキストに沿ったより正確な応答を生成します。

Agentforceでは、プロンプトテンプレートの有無にかかわらずRAGを使用できます。

1. プロンプトベースのRAG：このアプローチでは、応答の生成方法を指定する指示は、プロンプトテンプレート内のプロンプト指示に含まれています。この場合、応答はLLMが生成する内容に完全に依存します。プロンプトの指示以外にも、エージェントスタジオのLLM設定など、応答に影響を与える方法がありますが、それでも結果が決定論的にはなることはありません。
2. 推論エンジンベースのRAG：AIエージェントは、プロンプトテンプレートを使用する代わりに、フローまたはApexクラスを通じてチャンクを取得して、変数に保存するアクションを使用します（次のセクションを参照）。このアプローチでは、（LLMではなく）推論エンジンが、検索したデータにグラウンディングして直接回答を生成します。応答生成を制御する指示は、プロンプトテンプレートの指示ではなく、AIエージェントの指示です。検索したコンテンツを保持する変数は、アクションへの入力として明示的に渡すことができます。また、変数のコンテンツへのデフォルトアクセスを付与することで、推論エンジンに渡すこともできます。このアプローチにはトレードオフがあります。推論エンジンにかかるコンテンツと責任の負荷が過剰になるリスクがあります。さらに、プロンプトとは異なり、推論エンジンのLLMのパラメーターは設定できません。一方、推論エンジンは、検索したチャンクと会話の履歴の両方を使用して回答を生成できます。

推奨される方法はオプション1です。推論エンジンが実行するタスクの数が減り、回答の質が向上します。次のセクションでは、このルールの例外について説明します。この例外では、コンテンツが会話全体を通じて保持され、アクションに明示的に渡されます。

RAGのベストプラクティス

• スクリプト化されたRAG指示を避ける：特定の質問に対する指示を特定の記事に直接リンクするのではなく、RAGのインテリジェンスを活用して、最も関連性の高いデータソースと正確なテキストフラグメントを動的に発見させます。RAGのマッチングプロセスは、単に質問とソースの正確な対応関係にもとづくのではなく、質問のより広範な理解にもとづいています。
• トピックを統合する：関連する質問カテゴリを1つのトピックにまとめます。RAGは、広範なトピック内であっても、質問の種類にもとづいて関連する回答を効果的に特定できます。たとえば、メンテナンスやバッテリー問題といった製品トラブルは、より包括的なトピックに集約できます。
• RAG出力を変数に保存する：インタラクション数の上限に達する可能性がある場合は、RAG出力を変数に保存します。これにより、標準のしきい値を超えても、AIエージェントのインタラクションのガイドに必要な情報にアクセスできる状態を維持できます。この具体例は、次のセクションで紹介します。

特定のビジネスプロセスでは、特定のアクションシーケンスの適用や、アクションまたはトピックを動的に実施する条件など、実行が予測可能であることが求められます。

変数を利用することで、この決定論的な行動を達成できます。変数は、AIエージェントの構造化された短期記憶として機能し、アクションの入力または出力として使用されます。さらに、変数の状態は、特定のトピックやアクションの動的な実施を制御できます。

変数による決定論制御の方法

変数は、次のようにしてAIエージェントのガイド付き決定論を実現できます。

1. 永続的な動的グラウンディング：変数を使用すると、AIエージェントは世界に対する理解を継続的に更新しながら、重要な情報を後のインタラクションに影響されることなく保持できます。この方法では、重要な情報、たとえば、RAGで検索された非構造化データや、ユーザープロファイル情報などの構造化データが、会話の長さにかかわらず会話全体を通じて維持されます。
2. アクションの入力/出力：変数は、アクションの入力としても出力としても使用できます。アクションは変数を明示的に参照し、アクションの実行時に、これらの入出力は、推論エンジンに依存することなく設定されるため、AIエージェントのアクションがより決定論的になります。
3. フィルタリング：変数を使ってアクションやトピックの条件付き実行を制御できます。変数を使用すると、アクション間の特定の情報フローと、アクションの決定論的な実行が可能になります。この機能は、メールなど、特定の入力変数が検証されない場合にアクションを開始できない、セキュリティルールの場合に特に重要です。

Agentforceの変数の種類

Agentforceには2種類の変数があります。

• コンテキスト変数は、ユーザーと会話セッションに関する情報を保持するシステム生成変数です。
• カスタム変数はユーザーがインスタンス化できます。カスタム変数は、変数による決定論のサポートの3つの方法で使用される任意の種類の情報を格納できます。

これらの変数タイプは以下の機能をサポートしています。

ユースケースの例である顧客対応のトラブルシューティングエージェントを使用して、変数をさらに掘り下げていきましょう。この例では、変数は、永続的な動的グラウンディング、アクションの入力/出力、フィルタリングの3つの目的すべてに使用されます。

この例では、AIエージェントは、顧客がデバイスの技術的な問題をトラブルシューティングする手助けをします。通常、トラブルシューティングにはいくつかのステップが必要です。AIエージェントは、人間のサービス担当者の仕事を模倣したサービスエクスペリエンスを提供する必要があります。そのために、AIエージェントは顧客にすべてのトラブルシューティング手順を一気に提示してはいけません。代わりに、顧客の反応にもとづいてステップ間を移動できる機能（前の手順に戻るなど）とともに、段階的な手順を提供すべきです。

この場合の課題の1つは、会話全体を通してすべてのトラブルシューティング手順を覚えておくAIエージェントの能力です。AIエージェントが保存できるインタラクションの数に制限があるため、AIエージェントのメモリは限られており、会話が長引くとこれらの手順が推論エンジンのコンテキストから失われる可能性があります。

この課題に対処する方法は、トラブルシューティング手順全体で、変数を使用して推論エンジンを動的にグラウンディングすることです。情報を検索して変数に保存することで、会話全体を通じて情報が利用可能な状態を維持し、更新することができます。推論エンジンは、この変数に保存された情報を使用して、動的にグラウンディングします。

この例では、トピックに2つのアクションが含まれています。これら2つのアクションは、一貫したデータフローを維持するために必要です。1つ目のアクションは、変数にすべてのトラブルシューティング手順を格納するために使用されます。2つ目のアクションは、実際のトラブルシューティングでその変数を使用します。

1. アクション1：「問題解決手順の設定」。これは、AIエージェントが最初に問題を認識したときに動的に実施される初期アクションです。検索拡張生成を使用してインデックス付きの知識ベースから必要な解決手順をすべて抽出します。このアクションは、取得した出力を「Resolution Steps」という名前の変数に保存します。
2. アクション2：「問題解決の途中で使用」。このアクションは、トラブルシューティングプロセスの間に、使用可能性が最も高い、次のトラブルシューティングステップを出力するプロンプトにもとづいています。AIエージェントは、問題解決の最中にこのアクションを使用するように指示されます。

元の顧客からの質問は両方のアクションに入力されます。2番目のアクションにはもう一つの入力があります。変数「Resolution Steps」の内容です。この変数は1つ目のアクションで設定されました。2つ目のアクションはトラブルシューティング手順を自分で検索するのではなく、変数を通じて1つ目のアクションから入力として受け取ることに注意してください。次の図は、これら2つのアクション間のデータフローを示しています。

［Use in the Middle of Solving an Issue］アクションは、常に［Issue Resolution Steps］アクションによって検索された元のトラブルシューティング手順を参照します。このデータフローにより、トラブルシューティング手順が一貫して維持され、会話の長さに関わらず常に利用可能な状態が保たれます。

この例で定義されたアクションを実行するには、「常に『解決手順の設定』を最初に実行する」といった具体的な指示が必要です。しかし、AIエージェントが使用するLLMの非決定論的な性質により、場合によっては異なる順序で実行される可能性があります。そこで、アクションが決定論的な順序で実行されるように、これらの変数に条件付きフィルターを導入し、適切なアクションシーケンスを適用します。AIエージェントは、変数「Resolution Steps」の値を読み取り、この変数に値があるかどうかにもとづいて2つのフィルターを定義します。

• ［Issue Resolution Steps］アクションは、［Resolution Steps］変数が空の場合にのみ実行できます。
• ［Use in the Middle of Solving an Issue］アクションは、［Resolution Steps］変数に値が設定されている場合にのみ実行できます。

これらの条件付きフィルターは、アクションの実行シーケンスを決定論的に強制するようになりました。［Use in the Middle of Solving an Issue］は、［Issue Resolution Steps］が完了するまで待たなければならず、［Resolution Steps］変数に常に値があることが保証されます。

アクションを正しく実行するには、問題が完全に解決されたときに、［Resolution Steps］変数をリセットする3つ目のアクションが必要です。その結果、AIエージェントは、新たに発生する別の問題を支援するために必要な状態にリセットされます。この3つ目のアクションは、［Empty the Resolution Variable］と呼ばれます。アクションの全体図を以下に示します。

トラブルシューティングエージェントが顧客の問題を解決するときに変数が不可欠なのは、次のような機能があるためです。

• 永続的な動的グラウンディング：変数にトラブルシューティング手順が保存されているため、インタラクションの長さや回数に関係なく、会話全体で利用できるようになります。これにより、AIエージェントがコンテキストを忘れることがなくなります。
• データフロー：変数は、アクション間のデータフローを促進します。たとえば、［Resolution Steps］変数は、［Issue Resolution Steps］アクションで検索したトラブルシューティング手順を保存し、［Use in the Middle of Solving an Issue］アクションに入力として渡します。
• 決定論：変数は、アクションの特定の実行順序を適用するフィルターとして使用できます。たとえば、［Use in the Middle of Solving an Issue］アクションは、［Resolution Step］変数が設定されている場合にのみ実行され、確実に［Issue Resolution Steps］アクションが先に実行されます。

生成AIの時代においても、予測AIは生成能力を導き、強化し、コンテキスト化する基盤的なインテリジェンスを形成するという点で、その重要性は失われていません。生成AIがテキスト、画像、動画などの新しいコンテンツの作成に注力する一方、予測的モデルはリアルタイムのビジネスデータにもとづいて未来を予測します。ビジネス成果の例としては、顧客の解約可能性、コンバージョン率、ケースエスカレーションの確率、顧客生涯価値、ケース分類などがあります。予測は、トレンドと数値を分析することで、ユーザーのニーズの先読み、出力のパーソナライズ、意思決定の実行、コンテンツの関連性のリアルタイム最適化に役立ちます。たとえば、パーソナライズ学習、医療、財務計画などの用途では、予測AIが生成出力を個々のコンテキストや将来起き得るシナリオに合わせて出力します。予測AIと生成AIの連携により、強力な相乗効果が生まれます。先見性と創造性の融合は、よりインテリジェントで適応力があり、インパクトのあるテクノロジーソリューションを推進します。

予測的モデルの出力をAIエージェントのワークフローに連携する方法

予測モデルの出力をAIエージェントのワークフローに組み込むには、予測的モデルアクションをAgentforceアセットに追加するだけです。モデルビルダーは、予測的モデルを構築または登録（BYO）する手段を提供し、これらのモデルはAIエージェントが予測を行うために使用されます。結果の予測（および予測因子）は、カスタム変数に保存できます。AIエージェントは、これらの変数値を入力として使用し、特定のアクションやトピックの実行を条件化することができます。

予測的モデルを統合したユースケース例

• セグメンテーション：顧客セグメンテーションのためのマルチクラス分類を実行し、結果のセグメントを使用して特定のアクションをフィルタリングします。たとえば、プレミアムランクの顧客向けにプレミアムアクションを用意します。
• エスカレーションの可能性：サービスケースのエスカレーションの可能性を予測します。この可能性が特定のしきい値を超えた場合は、ケースをすばやく解決するアクションの実行を許可するか、人間の担当者に迅速にエスカレーションします。
• CPG：売上の増加（予測的モデルで計算されたスコア）が特定のしきい値を超えた場合のみ、プロモーションを計画します。
• コマース：購入傾向が特定のしきい値を超えた場合のみ商品を提案します。

特定のビジネスプロセスは正確な順序で実行する必要があり、実行中にユーザー入力を必要としません。この場合、フロー、API、Apexを介して、事前に決められたステップのフローを適用できます。本番環境で実績のある既存のフローがある場合は、そのビジネスプロセスを実行するときに、そのフローを維持して、AIエージェントに使用させることができることを示しています。以下の例はすべて、AIエージェントがユーザー入力なしで実行できる事前に決められたステップのシーケンスが含まれています。この場合のAIエージェントの行動は、実行すべき決定論的プロセスの特定、必要な入力の収集方法、出力の解釈と処理方法で構成されます。

多くの連続したステップ（目安として4つ以上）と多くの変数への依存が含まれるビジネスプロセスは、複雑になりすぎて指示による制御が大変になります。この場合、単純にこのセクションに記載されている決定論的アクションタイプを使用して、ハードコードすることができます。最後に、これらの実装には、解決されたプロンプトテンプレートを使用してLLMを呼び出すなど、非決定論的要素を含めることができることに注意してください。したがって、これらは必ずしも完全に決定論的であるとは限らず、AIエージェントらしい望ましいレベルの流動性を依然として実証することができます。

マーケティングジャーニーのステップのシーケンスは固定ルールによって条件付けられており、ユーザーの会話入力には依存しません。したがって、このフローはAgentforceアクションとして使用できます。呼び出し可能なアクションを作成して、フローやApexクラスを呼び出せるソリューションコンポーネントから、バックグラウンドタスクやイベントトリガータスクを実行することができます。フローまたはApexクラスに呼び出し可能なアクションを追加し、AIエージェントが実行するタスクと、AIエージェントを動的に実施する条件を指定します。呼び出し可能アクションは、AIエージェントのコンテキスト変数を保持し、重要な情報を渡すこともできます。

Salesforceフローは、フォローアップタスクの作成、リマインダーメールの送信、レコードの更新などの日常的なタスクを自動化するために使用できます。フローは業務の効率と生産性を向上させます。AIエージェントもフローアクションを使用してフローを実行できます。フローは、その決定論的な性質のため、ビジネスプロセスを特定のシーケンスで実行する必要がある場合に、AIエージェントの行動を指示する優れた方法です。フローアクションが望ましいことを示す良い指標は、フローアクションを使わなければ、トピックに「最初にこれを実行し、次にこれを実行し、最後にこれを実行する」といった指示が含まれるような場合です。4つ以上のステップのシーケンスを適用すると、指示や変数でステップを管理することが大変になります。

プロンプトを呼び出すことで、フローに非決定論的要素を含めることもできます。フロー内のプロンプトノードは、プロンプトテンプレートを呼び出し、フロー内の他の要素に渡すことができる応答を収集します。これらの追加の要素は、再びプロンプトノードになることもできます。たとえば、前の応答を要約することで、プロンプトのチェーンを作成します。これは、プロンプトチェイニングのルールが固定要素によって定義され、ユーザー入力に依存しない場合に特に便利です。一例として、エージェント型RAGがあります。この場合、フロー内に事前定義されたリトリーバーまたはプロンプトのシーケンスが、特定の順序で特定のデータソースにアクセスできます。たとえば、最初にユーザーの国のドキュメントからデータを検索してから、必要に応じて他のソースを参照するなどです。このチェイニングメカニズムにより、信頼できる関連情報を決められた順番で抽出できます。

フローと同様に、ApexアクションとAPIアクションは、事前定義されたアクションのシーケンスをコード化できる点で決定論的です。これらのアクションには、プロンプトテンプレートやLLMの呼び出しなど、非決定論的要素を含めることができます。ただし、その定義において、これらのステップは定論的に実行されます。適切なタイミングでアクションを呼び出し、必要な入力を収集し、出力を処理することで、AIエージェント的な変動性が軽減されます。これらの責任は依然としてAIエージェントの指示によって管理する必要があるため、非決定論的です。ApexアクションとAPIアクションは、フローアクションと同等のプロコードです。

確率的推論から決定論的推論へ

決定論レベル1から5では、AIエージェントの環境に徐々に構造を追加してきました。まず、AIエージェントが何をできるか（レベル1、トピック）を定義し、次にどのように動作すべきか（レベル2、指示）をガイドしました。さらに、真実にもとづいてグラウンディングし（レベル3、データ）、その状態を管理し（レベル4、変数）、最後に厳格なツールを与えました（レベル5、決定論的アクション）。しかし、中央の意思決定エンジンは依然として本質的に確率的なままでした。推論エンジンは依然として、どのツールを選択するか、あるいは次にどの質問をするかを自ら決定していました。そして、その判断は完全に大規模言語モデル（LLM）に依存していました。

レベル6のAgent Scriptは、このアーキテクチャを根本的に変革します。推論プロセスそのものをハードコードできる機能を導入します。

Agent Scriptにより、モデルにプロンプトを与えるアプローチから、AIエージェント自体をスクリプト化するアプローチへと移行します。これは、硬直的な旧来型チャットボットへの回帰ではありません。私たちはこのアプローチを「ハイブリッド推論」と呼んでいます。LLMの創造的で会話的な能力を、不変の決定論的ロジックのレイヤーで挟み込むことができます。実行における重要なパス（「必ず実行すべき処理」）を明示的に定義しつつ、自然言語理解や応答生成についてはLLMに一定の自由度を残すことができます。

ワークフローを設計する際は、次のステップがすでに明確で固定されている決定論的ロジックを、スクリプトを用いたLLMベースのAIエージェントで単に置き換えることは避ける必要があります。プロセスが予測可能なパスに従い、その後のアクションを判断するために複雑な推論が不要な場合、生成モデルを導入すると不要なレイテンシーやコスト、さらには誤りの余地を増やすことになります。純粋に決定論的で推論を必要としないプロセスでは、従来のプログラムベースのフローの方が依然として適しています。単純なルーティングや直線的な遷移のためにLLMを利用するのは、標準的な手続き型フローで処理できるシステムの信頼性を損なう過剰設計です。

経験則として、システムが非構造化入力を扱い、意思決定を行う前に、ばらばらでばらつきの大きい複数の情報源（会話入力を含む場合もあります）から情報を統合する必要がある場合には、エージェント型ソリューションの採用を検討すべきです。

では、このレベルの制御はどのように実現するのでしょうか？ビジネスアーキテクトとプロコード開発者のそれぞれに向けて、2つの異なるアプローチが用意されています。

AIエージェントにレベル6の決定論を導入するために、必ずしもコードを書く必要はありません。Salesforceには、基盤となるAgent Scriptを生成するための2つの方法が用意されており、決定論的推論をより多くのユーザーが利用できるようになっています。

ビジネスアナリスト、管理者、ローコード開発者は、Agent Builderから直接レベル6の機能を利用できます。

テキストからスクリプトを生成するインターフェースとして機能する、ドキュメントスタイルのキャンバスを導入しました。コードを書く代わりに、構造化された自然言語でトピックのロジックを記述します。ビルダーはそのインテントを解釈し、バックグラウンドでAgent Scriptへコンパイルします。

• たとえば、次のように記述します。"まず、注文から30日以上経過しているか確認します。該当する場合は、返品を受け付けられないことをユーザーに伝え、丁寧に会話を終了します。該当しない場合は、商品の状態を尋ねます。"
• システムは、この自然言語の記述を自動的に解析し、必要なif/else構造、変数チェック、end_conversationコマンドへと変換します。

これにより、自然言語でロジックを記述するだけでプラットフォームがコードへ変換するため、プログラミング経験のないユーザーでも厳格なガードレールと決定論を実装できます。

最大限の精度を求める開発者は、Agent Builder内でAgent Scriptを直接記述することもできます。自然言語で記述したキャンバスは裏返して基盤となるスクリプトを表示できるため、開発者はそのスクリプトを直接編集できます。このアプローチでは、ハイブリッドな作成方法も可能です。一部の指示はキャンバス上で自然言語を用いて記述し、他の指示はコードで直接スクリプト化（または既存の指示を編集）できます。この2つの編集方法を行き来しても、両者の内容は常に完全に同期されています。

どちらの方法でも、レベル6の機能を最大限に活用できます。

• 詳細なトレース：スクリプト実行をステップごとに確認し、どこで変数が変更されたのか、どの分岐が実行されたのかを正確に把握できます。
• 複雑なループ処理：自然言語では表現しにくい高度な再試行ロジックや、多変数の状態変更を管理できます。
• バージョン管理：AIエージェントの動作をコードとして管理し、GitやCI/CDパイプラインと連携してAIエージェントのバージョン管理を行えます。

ビルダーでAgent Scriptを生成する場合でも、手作業で記述する場合でも、出力は同じです。Agent Scriptは、Atlas推論エンジンによって実行されるAIエージェントグラフへ変換されます。

レベル6を使いこなすには、内部で何が起きているのかを理解する必要があります。Agent Scriptは、推論ブロック内の特定のプログラム構造によって動作を制御します。LLMに従わせるための提案である標準プロンプトとは異なり、これらはコマンドであり、何があっても実行されます。これらは推論プロセスの前、最中、後のいずれかで実行され、いくつかの異なる決定論タイプに分類されます。まず、これらのパターンを概説し、簡単な例をいくつか紹介します。次に、スクリプト化されたAIエージェントのアーキテクチャ設計図の例を使って、さらに詳しく説明します。

レベル1～5では、プロセスの特定のステップの前後でAIエージェントが何らかの処理（アクション）を実行することを期待していました。レベル6では、それを確実に実行させます。before_reasoningブロックとafter_reasoningブロックに記述された内容は、指示にもとづいてLLMを呼び出して推論を行う前後で、それぞれ必ず実行されます。これには、他のアクションの実行、トピックへの遷移、変数の設定などが含まれます。

たとえば、トピックのbefore_reasoning指示内でrunコマンドを使用すると、LLMが応答生成のために呼び出される前にアクションを実行できます。これにより、データを即座に利用できるようになり、推論による遅延やAIエージェントがツールを呼び出し忘れるリスクを排除できます。

スクリプト構造：

条件付き決定論を使用すると、標準的なプログラミングロジックで処理フローを制御できます。これは、ステップを省略したり別の形に変更したりできないコンプライアンスワークフローでは特に重要です。

スクリプト構造：

この例では、LLMにVIP以外のユーザーに対して承認を“ハルシネーション”する選択肢は与えられません。分岐はエンジンによって決定論的に実行されます。

もう1つの強力な制御機能は、AIエージェントを現在のトピックから別のトピックへ強制的に遷移させることです。これにより、AIエージェントが処理の途中で行き詰まったり、無関係な会話へ逸れたりするのを防ぎます。

スクリプト構造：

この遷移は単なる提案ではありません。これは、変数の値にもとづいて実行フローを強制的に切り替える処理です。この遷移自体は強制的で変更できませんが、AIエージェントが遷移した先のトピックでは、通常の推論プロセスが再び実行されます。

さらに、Agent Scriptを使用すると、あるアクションの完了直後に次のアクションへ強制的に遷移させることができます。この機能により、AIエージェントは各ステップで確率的または自律的な判断に依存するのではなく、厳格な決定論的フローに従うようになります。これらのアクションを事前に定義された順序で連結することで、特定のタスクが正確な順序で実行されることを保証でき、AIエージェントのロジックと動作を完全に制御できます。

Agent Scriptを使用すると、AIエージェントの短期メモリ（変数）に対して直接読み書きできます。アクションの出力にもとづいて変数を明示的に設定することで、LLMがツールのJSON出力を誤って解釈してしまう「伝言ゲーム」のような状況を防ぐことができます。

スクリプト構造：

Agent Scriptの真の力を理解するには、個々のコマンドだけでなく、それらが連携して動作する様子を見る必要があります。以下のアーキテクチャパターン（当社の「Agent Scriptレシピ集 」にもとづくもの）は、レベル6の決定論が企業の複雑な課題をどのように解決するかを示しています。

問題：標準的なAIエージェントでは、推論による遅延が発生することがよくあります。AIエージェントはユーザーの質問を待ち、次にどのツールを使うかを検討し、さらに本来なら取得できるはずの情報をユーザーに尋ねてしまうことさえあります。そしてようやくアクションを呼び出します。その結果、遅延が多く断続的なユーザーエクスペリエンスになってしまいます。Agent Scriptによる解決：推論前決定論。

LLMが処理を開始する前に、runコマンドを使用してデータを注入します。

例：緊急トリアージエージェント。停電の通報を処理するAIエージェントを想像してください。ユーザーに住所を尋ねて待つのではなく、セッションが開始された瞬間に、スクリプトは自動的にget_current_location_by_IPとcheck_grid_statusコマンドを実行します。

結果：AIエージェントは「何かお困りですか？」から会話を始める必要がありません。代わりに、次のように会話を始めます。「変圧器火災が確認されている北地区からお電話いただいているようですね。あなたの世帯はすでに優先復旧リストに追加されています。バックアップ発電機は稼働していますか？」

ロジック：

長いプロンプト（AIエージェントにすべてのルールを一度に与えること）は、推論プロセスにおける幻覚の可能性を高めます。AIエージェントはルールZに注意が向いてしまうことで、ルールAを忘れてしまうのです。

Agent Scriptによる解決策：RAGと条件付きロジックを組み合わせ、必要なタイミングで指示を注入する「条件付きグラウンディング」。会話のその時点に適用されるルールだけをAIエージェントに提示します。

例：対象外のオファーに関するルールを提示する。そもそも顧客のクレジットスコアでは増額申請が認められないのに、そのルールをAIエージェントに提示する必要があるでしょうか？

ロジック：

条件付きグラウンディングとは、不要なタイミングでは判断を妨げる情報そのものを完全に取り除くことで、エラーの可能性を排除する手法です。

問題：不動産ローン申請、採用面接、技術的なトラブルシューティングなどの複雑なAIエージェントとの会話では、AIエージェントは必ず回答を得るべき質問のリストを保持し、ユーザーから必要な情報を漏れなく収集する必要があります。しかし、ユーザーの話はしばしば脱線します。通常のAIエージェントはその脱線に付き合ってしまい、本来必ず確認すべき質問に戻ることを忘れてしまう場合があります。その結果、申請や会話が不完全なまま終わってしまいます。

この仕組みの中核となるのがステートフルナビゲーションです。これは会話を厳密なチェックリストのように扱い、すべての項目が確認されるまで次のステップへ進めないようにします。

ステートフルナビゲーションにより、AIエージェントは現在の変数の状態に厳密にもとづいてトピック間を移動するか、特定の条件が満たされるまで同じトピック内に留まります。これにより、ユーザーが話を脱線させようとしても、AIエージェントが許可されていない経路に進んでしまうことを防げます。たとえば重要な不動産ローン申請の手続き中に、ユーザーが支店の営業時間を尋ねたとします。この場合、AIエージェントは単に話題を元に戻そうとするだけではありません。代わりに、スクリプトがその逸脱を検知し、コンプライアンスリセット用のトピックへ強制的に遷移させることができます。AIエージェントを特定の「ロジックルーム」に固定することで、必須の変数がすべて取得されるまで、未承認のトピックについて話したりセッションを終了したりすることが事実上不可能になります。

例：メンテナンスインスペクター：航空機エンジンの10項目安全チェックを技術者に案内するAIエージェント。技術者は、「待ってください。機体の胴体にも傷があるのに気づきました」と言います。

AIエージェントの動作：

1. AIエージェントはその傷を認識します（自然言語）。
2. その傷を変数に記録します（状態管理）。
3. そして、次の内容が確認されるまで、セッションを終了したりトピックを切り替えたりしません。「機体の胴体に傷があることは記録しました。ただし、インテークバルブのトルク設定を確認するまで『Exterior』には移動できません。トルクの数値は何でしたか？」

ロジック：

ただし、ガイド付き会話は単なる質問の順番リスト以上のものである必要があります。そうでなければ、AIエージェントは「フォームを会話形式にしただけのもの」になってしまいます。その本当の価値はインテリジェントなトリアージにあります。つまり、最初の確認質問によってユーザーを適切なフォームやワークフローへ導くことです。

複雑さが増してくると、単純なスクリプトからより堅牢なAgent Scriptへ移行するのが自然になります。AIエージェントは質問するだけでなく、実際に処理を実行するようになります。たとえばAIエージェントは、ドキュメントからトラブルシューティング手順を抽出したり、社内ポリシーを参照したり、外部システムへのAPI呼び出しを実行してリアルタイムで問題を解決したりします。

決定論レベルのフレームワークにおいてレベル6としてAgent Scriptが導入されたことで、レベル1のトピックが持つ自由度の高い創造性から、レベル6のAgent Scriptによる厳格なコード駆動型ロジックまで、幅広い制御の選択肢を利用できるようになりました。

しかし、強力なツールがあるからといって、すべての問題にそれを使うべきとは限りません。

最もよくある誤りは、「レベルが高いほど優れている」と考え、あらゆる場面でAIエージェントをスクリプトによって完全に制御すべきだと思い込むことです。これは正しくありません。AIエージェントのアーキテクチャと設計における本当の要点は、AIの価値である会話の柔軟性を損なうことなく安全性を確保できるよう、決定論のレベルを適切に調整することにあります。AIエージェントを過度にスクリプト化し、結局は「少し高度なだけのチャットボット」にしてしまってはいけません。

この章では、レベル1～5のガイド付き自律性に頼るべき場合と、レベル6のスクリプト化された精度を適用すべき場合を判断するための意思決定フレームワークを紹介します。これらは厳密なルールではなく、あくまで経験則です。決定論のさまざまな選択肢やレベルをどのように考えるべきかを示すための枠組みとして提示しています。

判断をわかりやすくするために、6つのレベルを2つの戦略的ゾーンに分けて考えます。

• 哲学：「信頼し、検証する」AIエージェントには目標、データ、ツール（レベル5で説明したように、決定論的な場合もあります）を与えますが、そこに到達するための最適な経路は推論エンジンに委ねます。
• メカニズム：確率的推論。AIエージェントはユーザーのインテントを分析し、状況に応じて最適なツールを動的に選択します。
• 適した用途：ディスカバリー、一般的なQ&A、リスクの低いタスク、幅広いサービス領域。

次のような場合は、レベル1～5の標準的な確率的動作に任せるのが適しています。

1.最適な進め方は常に同じとは限らない

多くの会話シナリオでは、硬直的にハードコードされたフローはむしろ不利になることがあります。なぜなら、最適な会話の進め方は状況によって変わるためです。たとえば、パーソナルショッピングや旅行プランニングのような動的インタラクションでは、唯一の正しい順序は存在しません。ユーザーは価格、場所、設備などを、自分の優先順位に応じてどの順番でも検討する可能性があります。このようなケースでステートフルなスクリプトを強制すると、会話が不自然で機械的な体験になってしまいます。そのため、ユーザーが会話の流れを主導できるようにしながら、指示を使ってAIエージェントのペルソナや目的を定義する方が効果的です。また、このアプローチは市場投入までのスピードも大きく向上させます。入れ子構造の変数や分岐を含む複雑なレベル6スクリプトを構築するのは、社内の人事FAQエージェントのような用途では過剰な設計になることが多いためです。AIエージェントをデータとRAGによってグラウンディングすることで、網羅的な手動スクリプトを作成する必要がなくなり、既存の知識ベースにもとづいて検索エンジンが会話を動的に処理できるようになります。

2.モジュラー決定論による拡張：メンテナンスの悪夢を避ける

AIエージェントの対象範囲が、独自のプロセスを持つ500種類ものITサポート問い合わせを扱うような大規模なものになると、最大の課題は「単一の決定論的エージェントスクリプトを構築できるかどうか」ではなく、「それを構築すべきかどうか」です。500種類ものタスクのあらゆる組み合わせを1つの巨大なAgent Scriptにまとめようとすると、メンテナンスの悪夢を招きます。ポリシーが変更されたり、新しいトラブルシューティング手順が追加されたりするたびに、複雑に絡み合ったロジック全体を壊してしまうリスクが生じます。

解決策は、モノリシックなスクリプトから離れ、レベル5の決定論的アクションへと移行することです。会話全体をスクリプト化するのではなく、パスワードリセットやアカウントのロック解除といった重要度の高いアクションごとに、堅牢で独立したフローを構築します。その上で推論エンジンをトラフィックコントローラーのように機能させ、ユーザー独自の言い回しからインテントを特定し、適切な決定論的アクションへとルーティングさせます。このアプローチにより、重要なタスクではスクリプトの信頼性を確保しながら、タスクの数が増えても破綻しない柔軟で拡張性の高いアーキテクチャを実現できます。

• 哲学：「何を考え、どのように推論しても、最終的に実行すべきことはこれだ」まず実行パスを定義します。AIエージェントは、そのロジックを実行するためのインターフェースとして機能します。AIエージェントの創造性は、必ず実行されるロジックのレイヤーによって囲い込まれます。
• メカニズム：決定論的推論。「頭脳」は事前にコンパイルされたグラフに従って動作し、LLMはスクリプトで許可された範囲内でのみ、推論、自然言語理解、応答生成に使用されます。
• 適した用途：コンプライアンス、金融取引、診断ツリー、リスクの高いワークフロー、規制の厳しい業界。

なお、レベル6で定義された決定論的なフローの中でも、レベル1〜5の機能は引き続き利用できます。

「ほぼ正しい」では不十分な場合には、Agent Scriptを使用するべきです。

1.必ず通過すべきゲート（セキュリティと認証）

ユーザーが送金を依頼した場合、LLMがおそらく認証を求めてくれるだろうと期待して任せることはできません。取引フローに入る前に、認証フローが必ず実行されることを確実に保証する必要があります。

• Agent Scriptによる解決策：before_reasoningブロック内、またはスクリプトの最上部でrun @actions.verify_identityを実行し、LLMが1トークンを生成する前に認証プロセスを必ず実行させます。

2.規制の遵守

ヘルスケアや金融などの業界では、AIエージェントが免責事項を一字一句そのまま読み上げたり、法令で定められた順序で質問したりする必要がある場合があります。

• Agent Scriptによる解決策：その開示文をスクリプトにハードコードします。

3.複雑なマルチステップ依存関係と必須のアクションシーケンス

ステップBがステップAの出力を必要とし、さらにステップCがステップBの計算結果に依存する場合、LLMにプロンプトコンテキストを介してこれらの変数を受け渡しさせる方法では、いわゆる「伝言ゲーム」のようになり、リスクがあります。また、あるアクションの実行後に別のアクションを実行することが必須である場合は、その実行順序をスクリプトに固定する必要があります。

• Agent Scriptによる解決策：set @variables.x = @outputs.yを使用して、ステップ間のデータを明示的にバインドし、正確に受け渡します。また、runや@utils.transitionを使用して、アクションの実行順序をスクリプトで定義します。

4.トピックドリフトの防止

重大なトラブルシューティング（例：「ペースメーカーがビープ音を出している」）では、ユーザーが突然「天気はどうですか？」といった質問をした場合でも、AIエージェントがそれに気を取られないようにする必要があります。

• Agent Scriptによる解決策：@utils.transitionを使用して、問題が解決するまでユーザーを緊急プロトコルトピックに固定し、会話が別の話題に逸れることを明示的に防ぎます。

最も成熟したAIエージェントアーキテクチャは、どちらか一方を選ぶのではなく、レベル6を骨格として、レベル1〜5を筋肉として組み合わせて使用します。そこから導かれるのが、いわば決定論的サンドイッチと呼べる構造です。Agent Scriptを使って会話の重要な開始部分と終了部分を制御しながら、途中の部分は柔軟な推論に任せます。

• ステップ1（レベル6）：Agent Scriptがトリアージと認証を強制します。
  • 結果：ユーザーの本人確認が行われ、インテントが分類されます。
• ステップ2（レベル1～5）：Agent Scriptが標準トピックへ処理を引き渡します。
  • 結果：AIエージェントはRAGやアクション、指示、場合によっては変数などを使い、ユーザーの問題を柔軟に解決します。
• ステップ3（レベル6）：AIエージェントは問題が解決したことを検出し、クロージング処理のためにAgent Scriptに戻ります。
  • 結果：Agent ScriptがCSATスコアの収集や、コンプライアンスに準拠した別れのメッセージを確実に実行します。

最終的なレコメンデーション：まずはレベル1～5から始め、迅速な構築と探索を優先しつつログを監視してください。AIエージェントが一貫性の維持に苦労している場合や、手順に従えない場合、あるいはパラメーターを誤って生成してしまう場合には、その特定のワークフローのみをレベル6で選択的に堅牢化します。

Agent Scriptは、AIエージェントに決定論を導入するためのパズルの最後のピースです。Agent Scriptは、AIは確率的である一方、ビジネスは決定論的であるという現実を踏まえています。Agent Scriptを採用することで（自然言語でAIエージェントを構築できるキャンバスを使う場合でも、直接コードを書く場合でも）、AIエージェントの能力を制限するのではなく、その力を適切な方向へ集中させることができます。それは、会話という技術とプロセス実行という科学が融合したシステムを構築することを意味します。これにより、最も重要なワークフローが常に設計どおりに確実に実行されます。

レベル6はまた、自律的であることが無制御であることを意味しないという考え方を体現しています。

意思決定やプロセス最適化に関して、業界では長年にわたり「ルール」対「AI」という議論が続いてきました。厳格なルールを重視する立場は、予測可能性を主張しました。一方、AIを支持する立場は柔軟性を主張しました。Agent Scriptは、この議論に終止符を打ちます。正しいアーキテクチャは「どちらか」ではなく「両方」であることを示しているからです。

Agent Scriptを採用することで、ハイブリッド型のAIエージェントを構築できます。つまり、コードの堅固な骨格と、LLMの柔軟な思考を併せ持つシステムです。エンタープライズAIの未来は、より大きなモデルを作ることではありません。より優れた制御を実現することです。Agent Scriptによって、その制御をついに自分たちの手に取り戻すことができます。