ナビゲーションにスキップ

プロンプトガイド

本番環境レベルの会話型AIのためのシステム設計原則

はじめに

効果的なプロンプトにより、ElevenLabs Agentsはロボット的な応答から自然な会話へと変わります。

ElevenLabs Agentsのプロンプトガイド

システムプロンプトは、AIエージェントの人格とポリシーを定める設計図です。エンタープライズでの利用では、エージェントの役割、目標、使用可能なツール、特定タスクの手順、エージェントが行ってはならないことを示すガードレールなどを定義する、詳細な内容になる傾向があります。このプロンプトの構成は、信頼性に直接影響します。

システムプロンプトは会話の振る舞いと応答スタイルを制御しますが、ターンテイキングのような 会話フローの仕組みや、エージェントが話せる言語などのエージェント設定は制御しません。 これらはプラットフォームレベルで管理されます。

AIアシスタントを使ってプロンプトを改善する

ホスト型MCPサーバーを使うと、ClaudeなどのMCPクライアントが エージェントのシステムプロンプトを直接読み取り、更新できます。会話を通じてプロンプトの下書き、レビュー、 改善を行えます。

エンタープライズエージェントの
信頼性フレームワーク

プロンプトエンジニアリングの基本

システムプロンプトは、AIエージェントの人格とポリシーを定める設計図です。エンタープライズでの利用では、エージェントの役割、目標、使用可能なツール、特定タスクの手順、エージェントが行ってはならないことを示すガードレールなどを定義する、詳細な内容になる傾向があります。このプロンプトの構成は、信頼性に直接影響します。

以下の原則は、本番環境レベルのプロンプトエンジニアリングの基盤となります。

指示を明確なセクションに分ける

Markdownの見出しを使って指示を専用セクションに分けると、モデルが優先順位を付けて正しく解釈しやすくなります。空白行と改行で指示を区切ってください。

信頼性にとって重要な理由: モデルは特定の見出し、特に # Guardrails に特別な注意を払うよう調整されています。明確なセクション境界により、ある文脈のルールが別の文脈に影響する指示の混在を防げます。

You are a customer service agent. Be polite and helpful. Never share sensitive data. You can look up orders and process refunds. Always verify identity first. Keep responses under 3 sentences unless the user asks for details.

できるだけ簡潔にする

すべての指示を短く、明確に、行動ベースで記述します。余計な言葉を削除し、モデルが正しく行動するために不可欠な内容だけを記載してください。

信頼性にとって重要な理由: 簡潔な指示は曖昧さとトークン使用量を減らします。不要な言葉はすべて、誤解釈の原因になり得ます。

# Tone
When you're talking to customers, you should try to be really friendly and approachable, making sure that you're speaking in a way that feels natural and conversational, kind of like how you'd talk to a friend, but still maintaining a professional demeanor that represents the company well.

エージェントに特定のトーンを維持させる必要がある場合は、# Personality または # Tone セクションで明示的かつ簡潔に定義してください。プロンプト全体でトーンに関する指針を繰り返さないようにします。

重要な指示を強調する

重要なステップは、行末に「This step is important」と追加して強調します。最も重要な1〜2個の指示をプロンプト内で2回繰り返すことも、強化に役立ちます。

信頼性にとって重要な理由: 複雑なプロンプトでは、モデルが以前の指示よりも直近の文脈を優先することがあります。強調と繰り返しにより、重要なルールの見落としを防げます。

# Goal
Verify customer identity before accessing their account.
Look up order details and provide status updates.
Process refund requests when eligible.

テキストの正規化

テキスト読み上げモデル、特に高速なモデルは、アルファベットのテキストから音声を生成する際に最も高い性能を発揮します。そのため、数字や「@」「£」などの記号は、誤った発音や音声ハルシネーションを引き起こしやすくなります。

これに対処するため、TTSモデルに渡す前にアルファベット以外のテキストを単語へ正規化します(例:123 -> one-hundred and twenty three、john@gmail.com -> john at gmail dot com)。また、トレードオフの異なる複数の正規化戦略を選択できます。

正規化戦略

text_normalisation_typeエージェント設定では、2つの正規化戦略をサポートしています。

system_prompt(デフォルト) — テキストがTTSモデルに渡される前に、LLMが数字と記号を単語として書き出すよう、システムプロンプトに指示を追加します。

  • 追加のレイテンシなし
  • LLMが正しく正規化できない場合がある
  • トランスクリプトにはすべて単語で書き出された内容が含まれる(例:「$1,000」ではなく「one thousand dollars」)

TTS正規化ツールを使用せず、LLMが依然として正規化されていないテキストで応答することがある場合は、 より高性能なLLMへの切り替え、またはシステムプロンプトへの正規化指示の追加を検討してください。

elevenlabs — LLM生成後、TTSモデルに渡す前に、TTS正規化ツールを使用してテキストを正規化します。

  • LLMベースの正規化より信頼性が高い
  • システムプロンプトは変更されない
  • トランスクリプトには記号と数字を含む自然な書式が維持される(例:“$1,000”)
  • わずかなレイテンシが追加される

ユースケースでトランスクリプトの読みやすさが重要な場合は、elevenlabs 正規化ツールの使用を検討してください。 自然な記号と数字を維持してトランスクリプトを読みやすく保ちながら、正しく読み上げられた オーディオを生成します。

この設定は、プラットフォームの「Agent」タブで「Voices」セクションの歯車アイコンをクリックして共通の音声設定シートを開き、下部で設定できます。

ツール入力用の構造化データ

system_prompt の正規化設定を使用すると、LLMは応答内の記号と数字を単語として書き出します(例:john@gmail.com ではなく john at gmail dot com)。スピーチtoテキストによるユーザーの文字起こしも、標準的でない形式で届くことがあります。つまり、これらの詳細をツール呼び出しのパラメータとして使用する場合、LLMは会話コンテキスト内にある非構造化バージョンを使用する可能性があります。

ツールパラメータが正しい形式の値(例:john at gmail dot com ではなく john@gmail.com)を期待する場合、LLMはそのことを認識する必要があります。例とともに、期待される形式をツールパラメータの説明に直接含めてください。

## `lookupAccount` tool parameters
- `email` (required): "The user's email."
- `phone` (required): "The user's phone number."
- `confirmation_code` (required): "The user's confirmation code."

ガードレール専用セクションを設ける

モデルが常に従う必要がある、交渉の余地のないすべてのルールを、専用の # Guardrails セクションに記載します。モデルはこの見出しに特別な注意を払うよう調整されています。

信頼性にとって重要な理由: ガードレールは不適切な応答を防ぎ、ポリシー準拠を確保します。専用セクションに集約することで、監査や更新が容易になります。

推奨される方法
# Guardrails
Never share customer data across conversations or reveal sensitive account information without proper verification.
Never process refunds over $500 without supervisor approval.
Never make promises about delivery dates that aren't confirmed in the order system.
Acknowledge when you don't know an answer instead of guessing.
If a customer becomes abusive, politely end the conversation and offer to escalate to a supervisor.

効果的なガードレールの設計について詳しくは、ガードレールガイドを参照してください。

信頼性のためのツール設定

トランザクションワークフローを処理できるエージェントは、非常に効果的です。これを実現するには、他のシステムでアクションを実行したり、そこからライブデータを取得したりできるツールをエージェントに装備する必要があります。

プロンプトの構造と同様に重要なのが、エージェントが利用できるツールの説明方法です。明確でアクション指向のツール定義は、モデルがツールを正しく呼び出し、エラーから適切に回復するのに役立ちます。

詳細なパラメータでツールを正確に説明する

ツールを作成する際は、すべてのパラメータに説明を追加してください。これにより、LLMはツール呼び出しを正確に構築できます。

ツールの説明: 「注文IDで顧客の注文ステータスを検索し、現在のステータス、配送予定日、追跡番号を返します。」

パラメータの説明:

  • order_id(必須):「文字表記の一意な注文識別子(例:‘ORD123456’)」
  • include_history(任意):「trueの場合、ステータス変更を含む完全な注文履歴を返します」

信頼性にとって重要な理由: パラメータの説明は、モデルにとってインラインドキュメントとして機能します。形式の要件、必須フィールドと任意フィールド、使用可能な値を明確にします。

各ツールをいつ、どのように使うかをシステムプロンプトで説明する

各ツールをいつ、どのように使用すべきかを、システムプロンプトで明確に定義してください。ツールの説明だけに頼らず、使用する文脈と順序付けのロジックも提示します。

推奨される方法
# Tools
You have access to the following tools:
## `getOrderStatus`
Use this tool when a customer asks about their order. Always call this tool before providing order information—never rely on memory or assumptions.
**When to use:**
- Customer asks "Where is my order?"
- Customer provides an order number
- Customer asks about delivery estimates
**How to use:**
1. Collect the order ID from the customer
2. Call `getOrderStatus` with the order ID
3. Present the results to the customer in natural language
**Error handling:**
If the tool returns "Order not found", ask the customer to verify the order number and try again.
## `processRefund`
Use this tool only after verifying:
1. Customer identity has been confirmed
2. Order is eligible for refund (within 30 days, not already refunded)
3. Refund amount is under $500 (escalate to supervisor if over $500)
**Required before calling:**
- Order ID (from `getOrderStatus`)
- Refund reason code
- Customer confirmation
This step is important: Always confirm refund details with the customer before calling this tool.

ツールパラメータの説明で期待される形式を指定する

ツールが構造化された識別子(メールアドレス、電話番号、コード)を必要とする場合は、例とともに期待される形式をパラメータの説明に明記してください。正規化やスピーチtoテキストの文字起こしによって、会話コンテキスト内で発話形式の値が生成される可能性があるため、これは特に重要です。背景については、ツール入力用の構造化データを参照してください。

## `lookupAccount` tool parameters
- `email` (required): "The customer's email address."

ツール呼び出しの失敗を適切に処理する

ツールは、ネットワークの問題、データの欠落、その他のエラーによって失敗することがあります。回復方法についての明確な指示をシステムプロンプトに含めてください。

信頼性にとって重要な理由: 本番環境ではツールの失敗は避けられません。明示的な処理指示がないと、エージェントが応答をハルシネーションしたり、不正確な情報を提供したりする可能性があります。

推奨される方法
# Tool error handling
If any tool call fails or returns an error:
1. Acknowledge the issue to the customer: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer alternatives:
- Try the tool again if it might be a temporary issue
- Offer to escalate to a human agent
- Provide a callback option
4. If the error persists after 2 attempts, escalate to a supervisor
**Example responses:**
- "I'm having trouble looking up that order right now. Let me try again... [retry]"
- "I'm unable to access the order system at the moment. I can transfer you to a specialist who can help, or we can schedule a callback. Which would you prefer?"

信頼性の高いツールインテグレーションの構築に関する詳しいガイダンスは、クライアントツール、Webhookツール、MCPツールのドキュメントを参照してください。

エンタープライズエージェントのアーキテクチャパターン

強力なプロンプトとツールはエージェントの信頼性の基盤となりますが、本番システムには慎重なアーキテクチャ設計が必要です。エンタープライズエージェントは、多くの場合、単一のモノリシックなプロンプトの範囲を超える複雑なワークフローを処理します。

エージェントを専門化する

指示が広すぎたりコンテキストウィンドウが大きすぎたりすると、レイテンシが増加し、精度が低下します。各エージェントには、範囲を絞って明確に定義されたナレッジベースと責任範囲を持たせるべきです。

信頼性にとって重要な理由: 専門化されたエージェントは、処理すべきエッジケースが少なく、成功基準が明確で、応答も高速です。テスト、デバッグ、改善も容易になります。

汎用的に「何でもする」エージェントは、明確な引き継ぎを行う専門エージェントのネットワークよりも保守が難しく、 本番環境で失敗する可能性が高くなります。

オーケストレーターと専門家のパターンを使う

複雑なタスクには、専門エージェント間でタスクを引き継ぎ、必要に応じて人間のオペレーターにも引き継ぐマルチエージェントワークフローを設計してください。

アーキテクチャパターン:

  1. オーケストレーターエージェント: 意図の分類に基づいて、受信リクエストを適切な専門エージェントにルーティングする
  2. 専門エージェント: ドメイン固有のタスク(請求、スケジューリング、技術サポートなど)を処理する
  3. 人間へのエスカレーション: 複雑または機密性の高いケースに対する、定義済みの引き継ぎ基準

このパターンのメリット:

  • 各専門家は焦点を絞ったプロンプトと削減されたコンテキストを持つ
  • システム全体に影響を与えずに、個々の専門家を更新しやすい
  • ドメインごとに明確なメトリクスを設定できる(請求解決率、スケジューリング成功率など)
  • インタラクションごとのレイテンシを削減できる(小さなプロンプト、高速な推論)

明確な引き継ぎ基準を定義する

マルチエージェントワークフローを設計する際は、エージェント間または人間のオペレーターへ、いつ、どのように制御を移すべきかを正確に指定してください。

オーケストレーターエージェントの例
# Goal
Route customer requests to the appropriate specialist agent based on intent.
## Routing logic
**Billing specialist:** Customer mentions payment, invoice, refund, charge, subscription, or account balance
**Technical support specialist:** Customer reports error, bug, issue, not working, broken
**Scheduling specialist:** Customer wants to book, reschedule, cancel, or check appointment
**Human escalation:** Customer is angry, requests supervisor, or issue is unresolved after 2 specialist attempts
## Handoff process
1. Classify customer intent based on first message
2. Provide brief acknowledgment: "I'll connect you with our [billing/technical/scheduling] team."
3. Transfer conversation with context summary:
- Customer name
- Primary issue
- Any account identifiers already collected
4. Do not repeat information collection that already occurred
専門エージェントの例
# Personality
You are a billing specialist for Acme Corp. You handle payment issues, refunds, and subscription changes.
# Goal
Resolve billing inquiries by:
1. Verifying customer identity
2. Looking up account and billing history
3. Processing refunds (under $500) or escalating (over $500)
4. Updating subscription settings when requested
# Guardrails
Never access account information without identity verification.
Never process refunds over $500 without supervisor approval.
If the customer's issue is not billing-related, transfer back to the orchestrator agent.

マルチエージェントワークフローの構築に関する詳しいガイダンスは、ワークフローのドキュメントを参照してください。

エンタープライズの信頼性のためのモデル選択

適切なモデルの選択は、パフォーマンス要件、特にレイテンシ、精度、ツール呼び出しの信頼性によって決まります。モデルごとに、速度、推論能力、コストのトレードオフが異なります。

トレードオフを理解する

レイテンシ: 小規模なモデル(パラメータ数が少ないモデル)は一般に応答が速く、高頻度で低複雑度のインタラクションに適しています。

精度: 大規模なモデルはより強力な推論能力を提供し、複雑なマルチステップタスクをより適切に処理しますが、レイテンシとコストは高くなります。

ツール呼び出しの信頼性: すべてのモデルがツール/関数呼び出しを同じ精度で処理できるわけではありません。構造化出力に優れたモデルもあれば、より明示的なプロンプトが必要なモデルもあります。

ユースケース別のモデル推奨

数百万件のエージェントインタラクションにわたる導入実績から、以下のパターンが見えてきます。

  • GLM 5.2またはGPT-6 Luna(推奨開始点): レイテンシ、精度、コストをすべてバランスさせる必要がある、汎用エンタープライズエージェントに最適です。低〜中程度のレイテンシで優れたツール呼び出し性能を提供し、インタラクションあたりのコストも合理的です。カスタマーサポート、スケジューリング、注文管理、一般的な問い合わせ対応に最適です。

  • DeepSeek Flash 4.1またはGemini 3.5 Flash-Lite(超低レイテンシ): 速度が重要な高頻度でシンプルなインタラクションに最適です。広範な一般知識を備えつつ、最も低いレイテンシを提供しますが、複雑なツール呼び出しでは性能が低下します。初期ルーティング/トリアージ、簡単なFAQ、予約確認、基本的なデータ収集を大規模に行う場合にコスト効率に優れています。

  • Claude Sonnet 5.5(複雑な推論): マルチステップの問題解決、微妙な判断、複雑なツールオーケストレーションに最適です。優れたツール呼び出しの信頼性とともに最高の精度と推論能力を提供しますが、レイテンシとコストは高くなります。技術的なトラブルシューティング、金融アドバイス、コンプライアンスに配慮が必要なワークフロー、複雑な返金/エスカレーション判断など、ミスのコストが高いタスクに最適です。

プロバイダーのモデルラインアップは頻繁に変更されます。本番環境で使用するモデルを決定する前に、モデルページで現在のオプションと料金を確認してください。

実際のプロンプトでベンチマークする

モデルのパフォーマンスは、プロンプトの構造とタスクの複雑さによって大きく異なります。モデルを決定する前に、以下を行ってください。

  1. 実際のシステムプロンプトで候補モデルを2〜3個テストする
  2. 実際のユーザークエリまたは合成テストケースで評価する
  3. レイテンシ、精度、ツール呼び出し成功率を測定する
  4. 特定の要件に応じて最適なトレードオフになるよう調整する

詳しいモデル設定オプションについては、モデルのドキュメントを参照してください。

反復とテスト

本番環境での信頼性は、継続的な反復によって生まれます。適切に構築されたプロンプトでも、実際の利用では失敗する可能性があります。重要なのは、こうした失敗から学び、規律あるテストを通じて改善することです。

評価基準を設定する

各エージェントに具体的な評価基準を設定し、時間の経過に伴う成功を監視して、リグレッションを確認します。

追跡すべき主な指標:

  • タスク完了率: 正常に対応されたユーザーインテントの割合
  • エスカレーション率: 人間の介入を必要とした会話の割合

ElevenLabsでの評価基準の設定に関する詳しいガイダンスは、成功評価を参照してください。

失敗パターンを分析する

エージェントのパフォーマンスが低い場合は、問題のあるインタラクションのパターンを特定してください。

  • エージェントはどこで誤った情報を提供しているか? → 特定セクションの指示を強化する
  • ユーザーの意図を理解できないのはどのようなときか? → 例を追加するか、表現を簡素化する
  • どのユーザー入力でロールを維持できなくなるか? → エッジケース用のガードレールを追加する
  • 最も頻繁に失敗するツールはどれか? → エラー処理またはパラメータの説明を改善する

ユーザー満足度が低かった、またはタスクが完了しなかった会話のトランスクリプトを確認してください。

対象を絞って改善する

特定された問題に対処するため、プロンプトの特定セクションを更新します。

  1. 問題を切り分ける: どのプロンプトセクションまたはツール定義が失敗の原因かを特定する
  2. 特定の例で変更をテストする: 以前に失敗した会話をテストケースとして使用する
  3. 一度に1つだけ変更する: 何が有効かを把握するため、改善を切り分ける
  4. 同じテストケースで再評価する: 新たな問題を発生させずに変更が問題を解決したことを検証する

複数のプロンプト変更を同時に行わないでください。そうすると、改善またはリグレッションを 特定の編集に紐付けることができなくなります。

データ収集を設定する

各会話のデータを要約するようエージェントを設定してください。これにより、インタラクションのパターンを分析し、よくあるユーザーリクエストを特定し、実際の使用状況に基づいてプロンプトを継続的に改善できます。

ElevenLabsでのデータ収集の設定に関する詳しいガイダンスは、データ収集を参照してください。

リグレッションテストにシミュレーションを使う

プロンプトの変更を本番環境にデプロイする前に、既知のシナリオセットに対してテストし、リグレッションを検出してください。

エージェントをプログラムでテストするためのガイダンスは、会話をシミュレーションするを参照してください。

本番環境での考慮事項

エンタープライズエージェントには、プロンプトの品質に加えて追加の安全策が必要です。本番環境へのデプロイでは、エラー処理、コンプライアンス、適切な縮退を考慮する必要があります。

すべてのツールインテグレーションでエラーを処理する

外部ツールの呼び出しはすべて、潜在的な障害点です。プロンプトには、次のエラーに対する明示的な処理が含まれていることを確認してください。

  • ネットワーク障害: 「システムへの接続で問題が発生しています。もう一度試します。」
  • データ不足: 「システム内にその情報が見当たりません。詳細を確認していただけますか?」
  • タイムアウトエラー: 「予想より時間がかかっています。専門担当者にエスカレーションするか、もう一度試すことができます。」
  • 権限エラー: 「その情報にアクセスする権限がありません。対応できる担当者におつなぎします。」

プロンプトの例

以下の例では、このガイドで説明した原則を実際のエンタープライズユースケースに適用する方法を示します。各例には、使用されている信頼性の原則を示す注釈が含まれています。

例1:技術サポートエージェント

技術サポートスペシャリスト
# Personality
You are a technical support specialist for CloudTech, a B2B SaaS platform.
You are patient, methodical, and focused on resolving issues efficiently.
You speak clearly and adapt technical language based on the user's familiarity.
# Environment
You are assisting customers via phone support.
Customers may be experiencing service disruptions and could be frustrated.
You have access to diagnostic tools and the customer account database.
# Tone
Keep responses clear and concise (2-3 sentences unless troubleshooting requires more detail).
Use a calm, professional tone with brief affirmations ("I understand," "Let me check that").
Adapt technical depth based on customer responses.
Check for understanding after complex steps: "Does that make sense?"
# Goal
Resolve technical issues through structured troubleshooting:
1. Verify customer identity using email and account ID
2. Identify affected service and severity level
3. Run diagnostics using `runSystemDiagnostic` tool
4. Provide step-by-step resolution or escalate if unresolved after 2 attempts
This step is important: Always run diagnostics before suggesting solutions.
# Guardrails
Never access customer accounts without identity verification. This step is important.
Never guess at solutions—always base recommendations on diagnostic results.
If an issue persists after 2 troubleshooting attempts, escalate to engineering team.
Acknowledge when you don't know the answer instead of speculating.
# Tools
## `verifyCustomerIdentity`
**When to use:** At the start of every conversation before accessing account data
**Parameters:**
- `email` (required): Customer email in standard written format (e.g., "user@company.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.
- `account_id` (optional): Account ID if customer provides it
**Error handling:**
If verification fails, ask customer to confirm email spelling and try again.
## `runSystemDiagnostic`
**When to use:** After verifying identity and understanding the reported issue
**Parameters:**
- `account_id` (required): From `verifyCustomerIdentity` response
- `service_name` (required): Name of affected service (e.g., "api", "dashboard", "storage")
**Usage:**
1. Confirm which service is affected
2. Run diagnostic with account ID and service name
3. Review results before providing solution
**Error handling:**
If diagnostic fails, acknowledge the issue: "I'm having trouble running that diagnostic. Let me escalate to our engineering team."
# Error handling
If any tool call fails:
1. Acknowledge: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer to retry once, then escalate if failure persists

実証されている原則:

  • ✓ 明確なセクション分割(# Personality、# Goal、# Tools など)
  • ✓ 1行につき1つのアクション(# Goal の番号付きステップを参照)
  • ✓ 簡潔な指示(トーンのセクションは短く明確)
  • ✓ 重要なステップの強調(「This step is important」)
  • ✓ パラメータ説明での形式変換(メールアドレスの正規化)
  • ✓ 専用のガードレールセクション
  • ✓ 使用タイミング/方法/エラーに関する指針を含む正確なツール説明
  • ✓ 明示的なエラー処理の指示

例2:カスタマーサービス返金エージェント

返金処理スペシャリスト
# Personality
You are a refund specialist for RetailCo.
You are empathetic, solution-oriented, and efficient.
You balance customer satisfaction with company policy compliance.
# Goal
Process refund requests through this workflow:
1. Verify customer identity using order number and email
2. Look up order details with `getOrderDetails` tool
3. Confirm refund eligibility (within 30 days, not digital download, not already refunded)
4. For refunds under $100: Process immediately with `processRefund` tool
5. For refunds $100-$500: Apply secondary verification, then process
6. For refunds over $500: Escalate to supervisor with case summary
This step is important: Never process refunds without verifying eligibility first.
# Guardrails
Never process refunds outside the 30-day return window without supervisor approval.
Never process refunds over $500 without supervisor approval. This step is important.
Never access order information without verifying customer identity.
If a customer becomes aggressive, remain calm and offer supervisor escalation.
# Tools
## `verifyIdentity`
**When to use:** At the start of every conversation
**Parameters:**
- `order_id` (required): Order ID in uppercase alphanumeric format (e.g., "ORD123456"). Convert from spoken format: spell out letters and spoken digits to written form, no spaces.
- `email` (required): Customer email in standard written format (e.g., "john.smith@retailco.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.
## `getOrderDetails`
**When to use:** After identity verification
**Returns:** Order date, items, total amount, refund eligibility status
**Error handling:**
If order not found, ask customer to verify order number and try again.
## `processRefund`
**When to use:** Only after confirming eligibility
**Required checks before calling:**
- Identity verified
- Order is within 30 days
- Order is eligible (not digital, not already refunded)
- Refund amount is under $500
**Parameters:**
- `order_id` (required): From previous verification
- `reason_code` (required): One of "defective", "wrong_item", "late_delivery", "changed_mind"
**Usage:**
1. Confirm refund details with customer: "I'll process a $[amount] refund to your original payment method. It will appear in 3-5 business days. Does that work for you?"
2. Wait for customer confirmation
3. Call this tool
**Error handling:**
If refund processing fails, apologize and escalate: "I'm unable to process that refund right now. Let me escalate to a supervisor who can help."

実証されている原則:

  • ✓ 専門化されたエージェントの範囲(一般サポートではなく返金のみ)
  • ✓ # Goal セクションに明確なワークフローステップを記載
  • ✓ 重要なルール(返金上限、確認)の繰り返しによる強調
  • ✓ 「いつ使うか」と「必要な確認」を含む詳細なツール使用方法
  • ✓ パラメータ説明での形式変換(注文ID、メールアドレス)
  • ✓ ツールごとの明示的なエラー処理
  • ✓ 明確に定義されたエスカレーション基準

書式設定のベストプラクティス

プロンプトの書式は、言語モデルが内容をどれだけ効果的に解釈できるかに影響します。

  • Markdownの見出しを使う: メインセクションには#、サブセクションには##を使って構造化します
  • 箇条書きを優先する: 指示を理解しやすい箇条書きに分けます
  • 空白行を使う: セクションや指示のグループを空白行で区切ります
  • 見出しは文頭のみ大文字にする: # GOALではなく# Goal
  • 一貫性を保つ: プロンプト全体で同じ書式パターンを使用します

よくある質問

キャラクターの正規化、エラー処理、ガードレールなど、共通セクション用の共有プロンプトテンプレートを作成します。 これらを中央リポジトリに保存し、専門エージェント間で参照します。 オーケストレーターのパターンを使用して、一貫したルーティングロジックと引き継ぎ手順を確保します。

最低限、次を含めます。(1)パーソナリティ/役割の定義、(2)主要な目標、(3)基本的なガードレール、 (4)ツールを使う場合はツールの説明。シンプルなエージェントでも、明確なセクション構造と エラー処理の指示が役立ちます。

ツールを非推奨化する際は、まず新しいツールを追加し、古いツールはフォールバックとして残したまま 新しいツールを優先するようプロンプトを更新します。利用状況を監視し、使用数が ゼロになったら古いツールを削除します。非推奨のツールが呼び出された場合でもエージェントが復旧できるよう、 必ずエラー処理を含めてください。

一般的に、このガイドの原則に沿って構造化されたプロンプトは、モデルを問わず機能します。ただし、 モデル固有のチューニングにより、特にツール呼び出しの形式や推論 ステップでパフォーマンスを向上できる場合があります。複数のモデルでプロンプトをテストし、必要に応じて調整してください。

一律の上限はありませんが、2000トークンを超えるプロンプトはレイテンシーとコストを増加させます。 簡潔さを重視してください。すべての行に明確な目的があるべきです。プロンプトが2000トークンを超える場合は、 複数の専門エージェントに分割するか、参照資料をナレッジベースに抽出することを検討してください。

中核となるパーソナリティ特性、目標、ガードレールは明確に定義しつつ、ユーザーのコミュニケーションスタイルに応じて トーンや詳細さを柔軟に調整できるようにします。条件付きの指示を使います。「ユーザーが 不満を感じている場合は、先に懸念に応じてから進めてください。」

はい。システムプロンプトはいつでも変更して、動作を調整できます。これは特に、 新たに発生した問題への対応や、ユーザーとのやり取りから得た知見に基づく機能改善に役立ちます。 本番環境にデプロイする前に、必ずステージング環境で変更をテストしてください。

すべてのツールに明示的なエラー処理の指示を含めます。ガードレールのセクションで「推測したり、 情報を捏造したりしない」ことを強調します。この指示はツール固有のエラー処理 セクションでも繰り返します。開発中にツール障害のシナリオをテストし、エージェントが復旧 指示に従うことを確認してください。

次のステップ

このガイドでは、プロンプトエンジニアリング、ツール設定、アーキテクチャパターンを通じて、信頼性の高いエージェント動作の基盤を構築します。本番品質のシステムを構築するには、次の内容も確認してください。

  • ワークフロー: マルチエージェントのオーケストレーションと専門エージェントへの引き継ぎを設計する
  • 成功評価: 指標と評価基準を設定する
  • データ収集: 会話から構造化されたインサイトを取得する
  • テスト: リグレッションテストとシミュレーションを実装する
  • ガードレール: 安全なエージェント応答のためのコンテンツモデレーションを設定する
  • プライバシー: コンプライアンスとデータ保護を確保する
  • ドキュメントエージェント: これらの原則を実践した完全なケーススタディを見る

エンタープライズ導入のサポートについては、チームにお問い合わせください。