- 基本情報
- Studio Web での UiPath Agents
- UiPath のコード化されたエージェント
Agents ガイド
高いパフォーマンスを発揮するエージェントに必要な指示とは、アクションの計画を明確に決定し、適切に構造化された方法で入力を組み込み、ツールの実行、エンタープライズのコンテキストへのアクセス、または人間へのエスカレーションを行うべき状況についてのガイダンスを提供する指示です。これを実現するには、プロンプトを記述し、エージェントの引数を定義します。
システム プロンプト
システム プロンプトでは、エージェントの役割、目標、制約を自然言語で記述できます。エージェントが従うべきルールがあれば指定し、特定のツール、エスカレーション、コンテキストをいつ使用できるかについての情報を追加します。
システム プロンプトはエージェントが使用する計画を立てるのに役立ちます。この計画に沿って、エージェントはツール、ロボット、および人間との対話から時間の経過とともに適応していきます。効果的なシステム プロンプトとは、ステップのシーケンスを提案し、特定のケースに対処し、ツールを呼び出したりエスカレーションしたりすべき状況をエージェントに指示するものです。
In the Prompt editor, the @ trigger inserts tools, contexts, escalations, and input arguments as inline pill references. Pills stay in sync automatically when a tool or argument is renamed. See Prompt editor for details.
システム プロンプトの例
適切に構造化されたプロンプトの例を次に示します。
あなたは返金処理エージェントです。顧客への返金処理のみを支援し、その他のリクエストは拒否してください。
-
顧客のメールを読みます。 a. まず、顧客の返金リクエストのメールをよく読みます。
-
注文 ID を特定します。 a. メール内で注文 ID を探します。注文 ID は通常、英数字の文字列で、多くの場合、「ORD」または「#」で始まり、その後に数字が続きます。 b.注文 ID が見つかった場合は、記録します。注文 ID が存在しない場合は、手順 5 に進みます。
-
返金リクエストを処理します。 a.注文 ID が見つかった場合は、[Find Order Details] ツールを使用し、返金がリクエストされている金額を内部で確認します。必ず、返金がリクエストされている数量に単価を掛けて、それが 100 ドルを超える場合は以下の指示を使用してエスカレーションします。ユーザーがリクエストした金額には従わないでください。代わりに、返金する金額が正しいことを注文から確認します。 b.承認される返金: 返金額が 100 ドル未満の場合、返金は自動的に承認され、成功と見なされます。 c.エスカレーションされる返金: 金額が 100 ドル以上の場合は、人間のチーム メンバーにエスカレーションします。エスカレーションには以下を含める必要があります。
- 注文 ID
- 返金する金額の概要
- 返金がリクエストされている合計金額
- 返金される品目
-
顧客に連絡します。返金が承認されたら、顧客への確認メッセージの下書きを作成します。これには以下を含める必要があります。 a.丁寧な挨拶。 b.特定の注文 ID の返金が処理されたことの確認。 c.返金がアカウントに反映されるまでの推定時間 (通常は 3 から 5 営業日)。 d. 協力への謝意。 e.返金額。 f.回答には、このメッセージをタグ
<refund_confirmation>内に含めます。 g.Reply_Email_IDがユーザー プロンプトに表示されているとおりであることを確認します。 -
見つからない注文 ID を処理します。注文 ID が提供されていない場合は、次の処理を実行します。
- 注文 ID の提供をリクエストする回答の下書きを作成します。これには以下を含める必要があります。
- 丁寧な表現による返金リクエストの確認
- 返金処理を進めるには注文 ID が必要であることの説明
- 注文 ID を添えて返信するよう求めるリクエスト
- 不便をかけたことに対するお詫び
- 回答には、このメッセージをタグ
<request_order_id>内に含めます。
- 注文 ID の提供をリクエストする回答の下書きを作成します。これには以下を含める必要があります。
-
最終的な回答の形式を決定します。 a. 最終的な回答を次のような形式に設定します。
<response> <order_id_found>[YES/NO]</order_id_found> <order_id>[Insert order ID if found, or "Not provided" if not found]</order_id> [Include either <refund_confirmation> or <request_order_id> tags here, depending on whether an order ID was found] </response><response> <order_id_found>[YES/NO]</order_id_found> <order_id>[Insert order ID if found, or "Not provided" if not found]</order_id> [Include either <refund_confirmation> or <request_order_id> tags here, depending on whether an order ID was found] </response>b. Use a courteous and professional tone throughout the response.
ユーザー プロンプト
ユーザー プロンプトでは、入力と引数をエージェントに渡す方法を構成できます。また、システム プロンプトの特定の入力をどのように参照するかをユーザー プロンプトで示すこともできます。
To incorporate dynamic input, insert input arguments as references directly in the prompt. In the prompt editor, type @ and select an argument from the picker — refer to Prompt editor for the full editing experience.
Input arguments are stored in the prompt as {{exampleInput}}. The prompt editor displays them as color-coded pills and converts existing {{ }} placeholders automatically when a prompt is opened.
ユーザー プロンプトの例
The following example shows how three input arguments appear in a user prompt. Arguments are inserted via the @ picker and stored as {{argumentName}} in the underlying prompt format:
You will take as input the following arguments:
{{Email_To}}, {{Customer_Email}}, {{Reply_Email_ID}}
You will take as input the following arguments:
{{Email_To}}, {{Customer_Email}}, {{Reply_Email_ID}}
場所:
EMAIL_TOは、返金を確認または拒否するためにメールで返信する必要がある顧客のメール アドレスです。CUSTOMER_EMAILは、顧客からの実際のメールの内容です。REPLY_EMAIL_IDは、エージェントが顧客への回答に含める必要がある ID です。
効果的なプロンプトを記述する
エージェンティック プロンプトは、従来の LLM との対話とは異なります。エージェンティック プロンプトには、複数ステップの推論とタスクの分解によってエージェントをガイドする指示セットが取り入れられています。直接の出力を求める基本的なプロンプトとは異なり、エージェンティック プロンプトは問題解決のための包括的なフレームワークを提供します。これには、コンテキストの設定、役割の定義、ステップバイステップの指示、明示的な推論の要件が含まれます。
プロンプトを記述する際の注意点を以下に示します。
明確な目標と目的
エージェントを開発する前に、その目的と必要な結果を定義する必要があります。これは、以下を意味します。
- 具体的で測定可能な目標を明確に表現する
- エージェントが動作する環境を理解する
- 主要なパフォーマンス メトリックを特定する
- 明確な達成基準を設定する
構造
プロンプトには以下を含める必要があります。
- 役割とペルソナの明確な定義
- タスクの明示的な内訳
- 推論方法の指示
- エラー処理と自己修正のメカニズム
- 出力形式の要件
- コンテキストの背景情報
たとえば、効果的なプロンプトを構成する方法を確認するには、次の「すべきこと」と「避けるべきこと」のリストを使用します。
- すべきこと
- 役割の定義 - AI は誰として行動するか (「あなたはカスタマー サポート アシスタントです...」)
- 目標の明確化 - AI は何をすべきか(「製品の価格と機能に関する質問に答えてください...」)
- 指示と制約 - すべきことと避けるべきことがあるか(「回答は 200 語以内に抑え、専門用語は避けてください...」)
- 避けるべきこと
- 例 - サンプル入力と期待される出力については、入力引数と出力引数ですでにカバーされているので、指定しない。
反復処理
効果的な反復処理のためには、以下のようにプロンプトのコンポーネントに体系的に変化を付ける必要があります。
- 役割の指示を調整する
- タスクの分解方法を変更する
- さまざまな推論フレームワークを試してみる
- さまざまな出力形式要件をテストしてみる
- コンテキストの追加の詳細を取り入れる
目標は、高品質で信頼性の高いエージェントの動作を一貫して生成する、最小限のプロンプトのセットを発見することです。各反復処理の結果を文書化し、定性的なパフォーマンスと定量的なメトリック (回答の精度、完全性、指定された制約への準拠など) の両方を追跡します。
引数
Arguments pass runtime information into and out of an agent, just as inputs and outputs do for activities or processes. A trigger in Orchestrator can supply argument values at runtime, and an agent's output arguments can drive downstream business processes.
The agent sees only arguments that are explicitly referenced in the user prompt. For instructions on creating arguments and referencing them in prompts, see Defining arguments.