プロンプティングガイド

本番環境対応の会話型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セクションに記載します。モデルはこの見出しにより注意を払うよう調整されています。

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

Recommended approach
# 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の場合、ステータス変更を含む完全な注文履歴を返します」

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

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

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

Recommended approach
# 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."

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

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

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

Recommended approach
# 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. 人間へのエスカレーション: 複雑または機密性の高いケースに対する、定義済みの引き継ぎ基準

このパターンの利点:

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

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

マルチエージェントワークフローを設計する際は、エージェント間または人間のオペレーターへ制御を移すタイミングと方法を正確に指定してください。

Orchestrator agent example
# 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
Specialist agent example
# 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.

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

エンタープライズの信頼性に向けたモデル選定

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

トレードオフを理解する

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

**精度:**大規模モデルは推論能力が高く、複雑なマルチステップタスクにも優れていますが、レイテンシーとコストは高くなります。

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

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

数百万件のエージェントインタラクションへの導入実績から、次のような傾向が見られます。

  • **GPT-4oまたはGLM 4.5 Air(推奨の開始点):**レイテンシー、精度、コストをすべてバランスよく両立する必要がある、汎用的なエンタープライズエージェントに最適です。低〜中程度のレイテンシー、優れたツール呼び出し性能、妥当なインタラクション単価を実現します。カスタマーサポート、スケジューリング、注文管理、一般的な問い合わせ対応に最適です。

  • **Gemini 2.5 Flash Lite(超低レイテンシー):**速度が重要な、高頻度でシンプルなインタラクションに最適です。幅広い一般知識を備え、最も低いレイテンシーを提供しますが、複雑なツール呼び出しでは性能が低くなります。初期ルーティング/トリアージ、シンプルなFAQ、予約確認、基本的なデータ収集において、スケール時にもコスト効率に優れています。

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

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

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

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

モデル設定の詳細は、モデルのドキュメントを参照してください。

反復とテスト

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

評価基準を設定する

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

追跡すべき主な指標:

  • **タスク完了率:**正常に対応できたユーザー意図の割合
  • **エスカレーション率:**人による介入が必要になった会話の割合

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

失敗パターンを分析する

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

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

ユーザー満足度が低かった、またはタスクが完了しなかった会話の文字起こしを確認してください。

対象を絞って改善する

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

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

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

データ収集を設定する

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

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

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

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

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

本番運用に関する考慮事項

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

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

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

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

プロンプトの例

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

例1:テクニカルサポートエージェント

Technical support specialist
# 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:カスタマーサービス返金エージェント

Refund processing specialist
# 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トークンを超える場合は、 複数の専門エージェントに分割するか、参照資料をナレッジベースに抽出することを検討してください。

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

はい。システムプロンプトはいつでも変更して、動作を調整できます。これは特に、発生した問題への対応や、ユーザーインタラクションから学びながら 機能を改善する際に役立ちます。 本番環境にデプロイする前に、必ずステージング環境で変更をテストしてください。

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

次のステップ

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

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

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