ナビゲーションにスキップ
設定エージェントの動作手順

自由形式の手順

自然言語で記述するタスク固有の指示

概要

自由形式の手順は、1つのタスクをわかりやすい自然言語で記述するものです。エージェントは指示を解釈し、状況に応じて表現や順序を調整します。自由形式の手順では、ツール（通話終了などのシステムツールを含む）の呼び出し、ナレッジベースドキュメントの検索、他の手順への連鎖が可能です。

自由形式の手順を使う場面

状況に合わせてエージェントが表現や順序を調整でき、自然言語で素早く作成したい場合は、自由形式の手順を使用します。構造化された手順、ワークフロー、システムプロンプトとの比較については、手順を使う場面を参照してください。

手順の構成

エディターでの返金手順の例を示します：

返金手順の例

手順は、トリガーとコンテンツの2つの主要部分で構成されます。どちらにも他のリソースへのインライン参照を含められ、上のスクリーンショットではレンチアイコン付きのタグとして表示されています。各手順には、ダッシュボードに表示される名前もあります。

名前

ダッシュボードで手順を識別するための短いラベルです。名前がLLMに送信されることはないため、エージェントの動作には影響しません。

トリガー

エージェントがこの手順を使用するタイミングの説明です。たとえば、_ユーザーが注文の返金を求めたとき_です。

サブ手順を作成する場合にのみ、トリガーを空欄にしてください。

コンテンツ

Markdownで記述する手順の本文です。コンテンツには、エージェントが行うことを記述します。質問する、注文を検索する、ツールを呼び出す、通話を終了する、などです。実行するステップの番号付きの順序にすることも、状況に応じた一般的なガイダンスにすることもできます。各ステップやガイドラインは、1文（ユーザーに注文IDを尋ねる）でも、何をするのか、その理由は何かを説明する短い段落でも構いません。

順番に行う操作には番号付きステップを、ステップ内の要件や下位項目には箇条書きを使用してください。

インライン参照

手順では、さまざまな種類のリソースをインラインで参照できます：

  • ツール（例：注文の検索、カードへの請求、通話の終了、人間の担当者への転送）
  • ナレッジベースドキュメント
  • 他の手順

ステップでエージェントがツール、ナレッジベースドキュメント、または別の手順を使う必要がある場合は、必ずインライン参照を使用してください。参照するとリソースが手順に自動で紐付けられるため、エージェントが使用できます。_ここで計算機ツールを使用する_のように通常の文章で言及することもできますが、その場合はリソースがすでにエージェントに紐付けられている必要があります。

トリガーまたはコンテンツで / を入力し、スラッシュメニューからリソースを選択して参照を挿入します。参照はエディター内でクリック可能なタグとして表示されます。タグをクリックすると元のリソースを開き、設定を確認できます。

APIを通じて自由形式のコンテンツを記述する場合は、次の構文で参照を挿入します：

[tool id="tool_abc123"]
[kb id="kb_abc123"]
[procedure id="agtprc_abc123"]
[system_tool id="end_call"]
{{customer_id}}

インライン手順参照には、同じエージェントの手順を使用する必要があります。エージェントのスコープと複製時の動作については、制限事項を参照してください。

トリガー内の参照により、リソースの出力に基づいて手順を開始できます。たとえば、_get_user が tier ‘gold’ を返したとき_です。コンテンツ内の参照は、そのステップでリソースを呼び出す、または参照するようエージェントに指示します。

手順内で参照するナレッジベースドキュメントには、常に auto の使用モードが適用されます。エージェントでRAGが有効な場合、ドキュメント全文をプロンプトに配置する代わりに、関連する箇所を取得します。ドキュメントがエージェントにも紐付けられている場合は、そちらの使用モードが代わりに適用されます。全文をプロンプトに保持するには、prompt 使用モードでエージェントに紐付けてください。

手順エディターのスラッシュメニュー

後で参照先のリソースが削除された場合、またはアカウントがそのリソースへのアクセス権を失った場合、タグは破損として表示されます。エディター上部の Errors バッジには、これらの参照が表示されます。リソースが存在しない場合は invalid、存在していてもアカウントにアクセス権がない場合は unavailable と表示されます。バッジを開いて影響を受けているステップを確認し、参照を修正または削除してください。

無効な参照を一覧表示するエラーダイアログ

サブ手順

サブ手順には空のトリガーがあります。エージェントが実行できるのは、それを参照する別の手順からのみです。

サブ手順を使用すると、1つのエージェント内でステップを共有し、一度に利用可能な手順の数を減らせます。入口となる手順にはトリガーを設定し、そのコンテンツから関連するサブ手順を参照します。サブ手順のトリガーは空のままにしてください。

エスカレーション用のサブ手順には、会話を人間の担当者に引き継ぐためのステップをまとめられます。返金やキャンセルの手順からこれを参照し、トリガーは空のままにします。エージェントはどちらの手順のステップとしてもエスカレーションできますが、それ以外ではサブ手順を利用できません。

ドキュメントからのインポート

既存の標準業務手順書（SOP）から作成を始められます。手順リストの + メニューで From SOP を選択し、ファイルをアップロードしてください。

対応形式：PDF、DOCX、TXT、MD、HTML、EPUB。ファイルは20MB以下である必要があります。

インポーターはドキュメントを分析し、最大10件の異なる手順を識別します。生成された名前、トリガー、コンテンツを含む下書きが、それぞれ作成されます。各下書きを開いて調整してください。ドキュメントに10件を超えるSOPが含まれる場合は、アップロード前に小さなファイルへ分割してください。

SOPアップロードダイアログ

自由形式の手順を管理する

ダッシュボードでエージェントを開き、Procedures を選択します。 + を使って自由形式の手順を作成します。トリガーを追加し、コンテンツエディターに 指示を記述してから、エージェントの変更を公開します。

ベストプラクティス

エージェントはトリガーから適切な手順を選び、コンテンツに従う必要があります。手順の数が増えるほど、 より高性能なモデルほどこれを確実に行えます。選択肢については モデルを参照してください。

手順を適切に記述するには、2つの部分を適切に記述する必要があります。必要なときに手順を実行するトリガーと、エージェントが従えるコンテンツです。

手順を反復して改善する

まずは小さく始め、次の変更を加える前にエージェントテストで各変更を確認することをおすすめします。

1

短い手順を書く

トリガーと短いコンテンツを記述します。テストでエージェントに追加の指示が必要だと判明した場合にのみ、 コンテンツを増やしてください。

2

トリガーテストを追加

手順を開始すべきリクエストと、開始すべきではない類似リクエストに対するシミュレーションテストを 作成します。失敗の大半はトリガーが原因なので、完全なシミュレーションよりもこれらを多く作成してください。

3

完全なシミュレーションを追加

手順全体を実行し、結果を確認するシミュレーションテストを作成します。

4

テストを実行して失敗を修正

テストが失敗したら、トリガーまたはコンテンツを修正し、すべてのテストを再実行します。

トリガーを素早く反復改善するには、チャット 履歴がユーザーの リクエストで終わるシミュレーションテストを作成し、Maximum conversation turns を 1 に設定します。エージェントは 1回だけ応答するため、そのリクエストで適切な手順が開始されるかを確認でき、各実行も短時間で済みます。成功条件は _エージェントが返金手順を開始した_と記述してください。チャット履歴がない場合、最初のメッセージを持つエージェントは唯一のターンをあいさつに使ってしまい、テストでは何も確認できません。

テストまたは実際の会話が失敗した場合は、その背後にある誤りの種類を探してください。エージェントが間違ったことを言った場合、_それを言わないで_と追加すれば1つの会話は修正できます。過去の会話から類似の失敗を検索し、それらすべてをカバーする1つの指示を記述してください。原因はナレッジベースやエージェント設定にあることもあります。Architectでこの検索を行えます。失敗した会話を開き、Architect を選択して、類似の失敗を探し修正案を提案するよう依頼してください。Architectでは会話をテストに変換することもできます。

トリガーの書き方

重複または曖昧なトリガーは、誤った手順の実行につながります。ユーザーが サブスクリプションのキャンセルを求めたとき_のように書く方が、 ユーザーがアカウントについて質問したとき_よりも適切です。

エージェントがすべきことではなく、ユーザーが何を求めているかを記述します。エージェントの 操作として表現したトリガーは、信頼性が低くなります。_ユーザーがサブスクリプションのキャンセルを求めたとき_の方が、_ユーザーのサブスクリプションをキャンセルする_よりも適切です。

狭すぎるトリガーでは、ユーザーが異なる表現を使った実際のリクエストを見逃すことがあります。ユーザーが言いそうな バリエーションを含めてください。_ユーザーが注文の返金、返品、または返金を求めたとき_は、_ユーザーが返金を依頼したとき_よりも確実に実行されます。ユーザーが どのようにリクエストを表現するかを確認するには、過去の会話を 検索してください。

ユーザーは手順の途中でリクエストを変更することがあり、トリガーだけでは 適切な手順が開始されない場合があります。過去の会話で頻繁に見られる切り替えには、最初の手順のコンテンツに もう一方の手順へのインライン参照を追加してください。たとえば、_ユーザーが交換ではなく 返金を希望する場合は実行する_と書き、その後に返金手順へのインライン参照を追加します。大半の手順で引き継ぎが必要なら、代わりにトリガーをより明確に区別してください。

コンテンツの書き方

_顧客の直近の注文を検索する_のように、エージェントへの指示としてステップを記述します。_顧客の直近の注文を検索すべきです_のようには書きません。直接的な指示は 提案よりも従いやすくなります。

理由を示すと、手順で列挙されていないエッジケースにも対応できます。_返金処理には 注文IDが必要なため_という短い説明は、ステップで想定していない状況への対応に役立ちます。 1行の説明で同じ効果が得られる場合は、すべて大文字のMUSTや厳格なスクリプトを避けてください。

望む動作を記述してください。注文が見つからない場合は、ユーザーに注文 IDの確認を求める_の方が、 注文の詳細を作り上げない_よりも効果的です。コストの高い誤りについては、 ガードレールも追加してください。

エージェントが決まった順序で操作する必要がある場合は、番号付きステップが役立ちます。判断が必要な場合は、特に高性能なモデルでは、 数文のガイダンスの方がうまく機能することがよくあります。

手順は、ある状況でエージェントがすべきことを説明します。価格、プランの詳細、営業時間などの具体的な情報は、ナレッジ ベースに置くべきです。必要とする手順からドキュメントを 参照してください。たとえば、手順にすべてのプラン価格を列挙する代わりに、_次のドキュメントから価格を案内する_と記述し、その後に価格ドキュメントへのインライン参照を追加します。

手順を組み合わせる

1つの状況を複数の限定的な手順に分割すると、エージェントが選択すべきトリガーが増え、 誤った手順を開始しやすくなります。2つの手順が同じリクエストで開始される場合は、統合してください。 コンテンツが約3,000文字を超える場合は、通常、複数の状況を扱っています。

同じステップが複数の手順にまたがって現れる場合（顧客の本人確認、注文の検索、人間の担当者へのエスカレーション）は、 サブ手順に抽出し、必要な各手順からスラッシュメニューで参照してください。共有ステップを1か所で管理すると、それを使用するすべての手順の一貫性を保てます。

本人確認やエスカレーションなど、別の手順から要求された場合にのみエージェントが実行すべき操作には、サブ手順を使用してください。 トリガーがないため、会話開始時に入口の手順と競合しません。トリガーの選択肢を減らすことで、ルーティングの焦点を維持できます。

ツールをエージェント全体に紐付けるのではなく、使用する手順から参照してください。これにより、 ツールが無関係な会話に表示されなくなります。自由形式の手順では、ツールは開始された直近5件の手順の1つである間だけ 利用可能です。そのため、たとえば_または注文を検索する必要があるとき_のように、トリガーにもツールのタスクを記載してください。 制限事項を参照してください。

トーン、アイデンティティ、拒否ポリシー、ガードレールは、システム プロンプトに含めます。タスク固有のステップは 手順に記述してください。

手順はエージェント設定の一部であるため、新しいエージェントバージョンを公開すると同時にスナップショットが作成されます。 以前の手順セットにロールバックするには、以前のエージェントバージョンを復元してください。エージェントのバージョン管理を参照してください。

チームにすでにSOPがある場合は、インポーターで下書きに変換してから調整してください。