ガードレール
ガードレール
安全性、コンプライアンス、信頼性を保つ保護機能により、本番環境でのエージェントの挙動を制御します。
概要
ガードレールにより、チームは本番環境におけるエージェントの挙動を強力に管理でき、エンタープライズ規模で話題から逸れず、ブランドに沿い、不正な操作に強い状態を維持できます。
Guardrails 2.0では、安全性レイヤーを再設計しました。これにより、チームは自然言語でカスタムポリシーを定義し、組み込みの保護機能をオンにし、ガードレールが作動した場合の動作を制御して、影響度の高いワークフロー全体にエージェントを安心して導入できます。
ガードレールはエージェントを適切な応答へ導き、誤った応答がユーザーに届く前に防ぎます。エージェントの応答方法を整え、ユーザー入力を検証し、すべての返信をレイテンシーを追加せずに独立して評価するという複数のレイヤーで会話を保護します。これにより、すべての会話におけるブランドおよびコンプライアンスのリスクを軽減します。
ガードレールの仕組み
ガードレールは、次の3つのレベルで会話を保護します。
システムプロンプトの強化： エージェントの挙動を制御する主な方法です。許可される挙動と許可されない挙動をシステムプロンプトに明示的に記載し、Focus Guardrailを有効にして、会話全体でそれらの指示を強化します。これにより、大半のやり取りでエージェントを適切な方向に保てます。
ユーザー入力の検証： エージェントが応答する前に敵対的な試みを検出するセーフティネットです。ガードレールはユーザーの発言を分析し、プロンプトインジェクションや操作の試みを検出して、セキュリティリスクをもたらす会話を終了できます。
エージェント応答の検証： 設定済みのポリシーに照らして、すべてのエージェントの返信をリアルタイムで独立して評価する最終チェックです。システムプロンプトがあってもエージェントがルールに違反する内容を発言しようとする場合、応答バリデーターが配信前にブロックします。
システムプロンプトの強化が基盤です。入力と応答の検証は、見落としへの軌道修正を提供します。最も重要なルールについては、システムプロンプトと独立したカスタムガードレールの両方に含めてください。これにより多層防御が実現され、LLMが指示から逸脱しても、応答バリデーターが配信前に検出します。
システムプロンプトの強化
意図したとおりにエージェントを動作させる最も効果的な方法は、優れたシステムプロンプトを作成し、Focus Guardrailを有効にすることです。これらを組み合わせることで、最初からエージェントを適切な応答へ導きます。
システムプロンプトを使用して、エージェントが行うべきことと行うべきでないことについて明示的な指示を与えられます。モデルは# Guardrails見出しに特に注意を払うよう調整されています。この見出しは、最も重要な挙動ルールに使用してください。
効果的なシステムプロンプトの作成に関する包括的なガイダンスは、プロンプトガイドをご覧ください。ElevenLabsのアカウントチームも、高品質なシステムプロンプトの作成をサポートできます。
Focus Guardrail： Focus Guardrailはエージェントのシステムプロンプトを強化し、定義した目標と指示に沿って、応答の焦点、関連性、一貫性を維持します。これは、エージェントが本来の目的から逸脱しやすい長時間または複雑な会話で特に役立ちます。
システムプロンプトの強化とFocus Guardrailの有効化を組み合わせることが、エージェントを適切な応答へ導く最も効果的な方法です。
ユーザー入力の検証
Manipulation Guardrails
ユーザーが指示を回避するようエージェントを操作しようとする試みを検出してブロックします。有効にすると、システムはインジェクションや指示の上書きの試みを示すパターンについてユーザー入力を分析し、セキュリティリスクをもたらす会話を終了できます。
エージェント応答の検証
コンテンツガードレール
政治的にセンシティブ、性的に露骨、または暴力的な内容など、エージェントの応答内の不適切なコンテンツを、ユーザーに届く前に検出して防止します。これにより、エージェントの想定ユースケースや対象者に適した応答を維持できます。
カスタムガードレール
エージェントが影響度の高い業務を担うようになると、チームにはその挙動を明確に制御する手段が必要です。カスタムガードレールでは、ビジネスにとって最も重要なポリシーを設定できます。例：
- 小売アシスタントは、対象外の商品に返金を行うべきではありません。
- 医療受付は、医療上の助言を行うべきではありません。
- 銀行のエージェントは、投資を推奨するべきではありません。
カスタムガードレールは、自然言語プロンプトを使用して独自のブロック基準を定義できるLLMベースのルールです。有効な各カスタムガードレールは、エージェントの応答を軽量モデルに送信します。このモデルはルールに照らして応答を評価し、ブロックまたは許可の判断を返します。これにより、エージェントが発言できる内容とできない内容を、柔軟かつドメイン固有に制御できます。
各カスタムガードレールでは、次を定義できます。
カスタムガードレールは、ビジネスに関連する特定のトピックをブロックし、業界固有のコンプライアンス要件を適用し、独自の安全対策を実装するために使用できます。削除せずに個別にオンまたはオフにでき、複数を有効にした場合は、他のガードレールと並行して実行されます。トリガーされたすべての違反は、確認用にログに記録されます。
実行モード
実行モードは、ユーザーが返信を見たり聞いたりする前に、ガードレールが待ち時間を追加するかどうかを決定します。
ストリーミングモードでは、ガードレールがトリガーされる前にエージェントの応答が始まる場合があります。音声では、ブロックによって通話が終了する前に、オーディオの一部（多くの場合500ms未満）が配信されることがあります。テキストエージェントでは、配信前に評価が完了しない場合、ユーザーに応答の一部または全体が表示される可能性があります。
ブロッキングモードでは、エージェントはガードレールの検証後にのみ応答します。通常、これにより200～500msのレイテンシーが追加されます。
終了戦略
終了戦略では、ガードレールがトリガーされたときにエージェントが行う動作を定義できます。次から選択できます。
end_call（デフォルト）：通話を即座に終了しますretry：会話を終了する代わりに、フィードバックを使用して応答を再生成します。エージェントの応答は最大3回再試行され、すべての試行でガードレールに違反する場合は通話が終了します。
再試行はブロッキングモードでのみ機能します。ストリーミングモードで利用できる終了戦略は、 通話の終了のみです。
再試行フィードバック
再試行フィードバックには、次のターンで適用したい任意の指示を含められます。モデルが再生成する前にシステムガイダンスとして挿入されます。これには、transfer_to_agentやtransfer_to_numberなどのシステムツールの呼び出しも含まれます。再試行フィードバックの設定例は次のとおりです。
- 一般的な拒否（デフォルト）
応答は、この条件／カテゴリに一致するコンテンツをブロックするガードレールによってブロックされました：‘{{trigger_reason}}’ 次のターンでは、ユーザーに「申し訳ありませんが、その質問にはお答えできません。ほかに知りたいことはありますか？」と伝える必要があります。 - 修正指示付きで再試行
前の応答はガードレールによってブロックされました。ブロックされた応答：‘{{agent_message}}‘。次のターンでは、新しい回答を提供し、‘{{trigger_reason}}‘に違反してはなりません。 - 別のエージェントに転送
前の応答はガードレールによってブロックされました。次のターンではtransfer_to_agentツールを使用して、エージェントに転送する必要があります。ブロックされた応答：‘{{agent_message}}‘。このガードレールは、この条件／カテゴリに一致するコンテンツをブロックします：‘{{trigger_reason}}’。 - 担当者に転送
応答は、この条件／カテゴリに一致するコンテンツをブロックするガードレールによってブロックされました：‘{{trigger_reason}}‘。次のターンでは、transfer_to_numberツールを使用して、必ず通話を担当者に転送する必要があります。
再試行フィードバックでシステムツールを使用するには、エージェントの設定で対応するツールを 有効化して設定してください。エージェントに設定されているツールのみ呼び出せます。
フィードバックテキストでは、次のプレースホルダーを使用できます。
ストリーミング実行モードは音声エージェントに、ブロッキング実行モードは テキストエージェントに推奨されます。
ブロッキング（特に再試行）は、音声では予測しにくい動作をすることがあります。音声でブロッキングを 使用する場合は、十分に検証するか、動作に確信が持てるまで再試行ではなく通話を終了を選択してください。
料金
Focus、Manipulation、Contentガードレールは、すべてのElevenAgentsユーザーに追加料金なしで含まれています。
カスタムガードレールは使用量ベースで、ElevenAgentsの他のモデル呼び出しと同様に**追加のLLMコストが発生します。**有効なカスタムガードレールは、評価のためにすべてのエージェント応答を軽量モデルに送信するため、コストはプロンプトの長さ、平均会話時間、会話量によって異なります。複数のカスタムガードレールを有効にすると、各ガードレールが応答ごとに独自の評価を実行します。本番環境で複数のカスタムガードレールを有効にする前に、想定トラフィックとモデルの選択を確認することをおすすめします。
カスタムガードレールを作成または編集する際に、推定コスト（プロンプトの下）を確認できます。
再試行とコスト： 各試行では追加のエージェント生成とガードレール評価が行われるため、 再試行ではend_callと比べて使用量ベースの請求額が増加します（ブロックされたターンごとに最大3回の試行）。
設定
ダッシュボードで設定
CLIで設定
APIで設定
実行モードと終了戦略を設定（カスタムおよびコンテンツガードレール）
カスタムまたはコンテンツガードレールごとに、ストリーミングまたはブロッキングの実行モードを選択します。
ブロッキングはテキストエージェントに、ストリーミングは音声エージェントに適しています。ガードレール違反時のアクション
（trigger_actionに対応）は、どのモードでも通話を終了、またはブロッキング選択時のみ再試行です
（ストリーミングでは再試行は利用できません）。再試行を選択した場合は、モデルを誘導するために再試行時に挿入するフィードバックを編集します。
テンプレート内では、{{trigger_reason}}（ブロックの原因となったカスタムプロンプトまたはコンテンツカテゴリ）と
{{agent_message}}のプレースホルダーを使用します。
ガードレールがトリガーされた場合の動作は、種類と設定によって異なります。
- 通話を終了： セッションは直ちに終了します（音声では通話が切断され、テキストではチャットが終了します）。トリガーは会話履歴に記録されます。
- 再試行（ブロッキングのカスタムまたはコンテンツガードレール）： 違反したアシスタントターンが削除され、システムフィードバックが挿入されます。ガードレールが引き続きトリガーされる場合、セッション終了前にモデルが最大3回再試行します。
通話を終了の場合、エンドユーザーには通話の切断またはチャットの終了として表示されます。違反の詳細は 会話ログで確認でき、エンドユーザーにはそのまま表示されません。
通話を終了した後も、ユーザーは新しい会話を開始できます。ガードレールはユーザーを永続的にブロックするのではなく、 ポリシーに違反した特定の応答（またはセッション）をブロックします。
ベストプラクティス
カスタマーサポートエージェント
カスタムガードレールを使用して、ビジネス固有のポリシーを適用します。例：- ツールで対象資格が確認されていない限り、返金、 クレジットの付与、サブスクリプションの変更をブロックする。- 明示的な承認がない限り、 割引やプロモーションコードの提供をブロックする。- ロードマップ項目や未リリース機能について 推測する回答をブロックする。
医療アプリケーション
カスタムガードレールを使用して、医療に関する境界を厳密に制御します。例：- 症状の診断や特定の治療法の推奨を ブロックする。- 医薬品の用量に関する推奨をブロックする。
- 有資格の医療専門家による助言に取って代わることをブロックする。
教育コンテンツ
カスタムガードレールを使用して、学術的にセンシティブなトピックを制御します。例：- 有害な実験や危険な手順に関する 段階的な手順をブロックする。- 実施中の評価や試験の解答集の生成を ブロックする。- 学術的不正を助長しかねないコンテンツをブロックする。
社内エンタープライズツール
カスタムガードレールを使用して、会社の業務とデータを保護します。例：- 社内限定のドキュメントや機密プロセスの共有を ブロックする。- 非公開API、システムプロンプト、インフラストラクチャの詳細の公開をブロックする。- 経営層または 管理者権限を必要とするアクションのシミュレーションをブロックする。
現実的なシナリオでテストする
デプロイ前に、以下を使用してガードレール設定をテストしてください。
- 誤検知がないことを確認するための通常の会話フロー
- セーフティ境界に近づくものの越えないエッジケース
- 有害な応答を引き出そうとする敵対的プロンプト
よくある質問
ガードレールはレイテンシーに影響しますか？
カスタムガードレールとコンテンツガードレールでは、ストリーミングモードによる追加のレイテンシーはありませんが、 ガードレールが発動する前に応答が始まる場合があります。ブロッキングモードでは、エージェントが応答する前にガードレールを 待機するため、通常は約200～500 msの遅延が発生します。再試行では、ブロックされたターンごとに最大3回、試行ごとに完全な追加生成 （および再評価）が行われるため、従量課金のコストも増加します。
ストリーミングとブロッキングの実行モードの違いは何ですか？
ストリーミングでは追加のレイテンシーはありませんが、ガードレールが
発動する前にエージェントの応答が始まる場合があります。ブロッキングでは、エージェントが応答する前にガードレールの結果を待機します（通常
200～500 msの遅延）。終了戦略としての再試行（trigger_action）は、ブロッキングモードでのみ
利用できます。ストリーミングモードでは、ガードレールが発動した際に通話を終了します。ブロッキングでは、会話を
即座に終了する代わりに、システムフィードバックを挿入して再試行できます。ただし、再試行が発生した場合は追加のモデル使用量と
追加料金がかかります。ブロッキングはテキストエージェントに、ストリーミングは
音声エージェントに推奨されます。
ガードレールを完全に無効にできますか？
はい。ただし、すべてのガードレール、特にFocus Guardrailは有効のままにすることを強く推奨します。 これらはブランド、ユーザー、コンプライアンス体制を保護するものであり、社内ツールを含むすべての 本番アプリケーションでの利用を推奨します。まれに、エージェントの想定ユースケースを妨げる場合は、特定の ガードレールを無効にしたいこともあるでしょう。たとえば、一部のアプリケーションでは、Content Guardrailが通常フラグを付けるトピックを扱う場合や、 高度にカスタマイズされたシステムプロンプトがFocus Guardrailを有効にすると適切に動作しない場合があります。各ガードレールは 個別にオンとオフを切り替えられます。
ユーザーはガードレールの判定に異議を申し立てられますか？
ガードレールの発動はログに記録され、会話分析で確認できます。 誤検知を特定した場合は、ガードレールプロンプトを調整してください。自動化された異議申し立てプロセスはありません。 ユーザーは新しい会話を開始してください。
どのガードレールが発動したかを確認するにはどうすればよいですか？
どのガードレールが発動したかに関する情報は、会話ログで確認できます。
Guardrailsとシステムプロンプトの強化を両方使用すべきですか？
はい。両者は補完的な役割を果たします。システムプロンプトの強化は行動に関するガイダンスを提供し、 指示に従うことでほとんどの問題を防止します。プラットフォームのガードレールは、セーフティネットとして独立した 適用を行います。両方を使用することで、多層防御を実現できます。
次のステップ
- プロンプトガイド: 行動ガードレールを備えた効果的なシステムプロンプトの書き方を学ぶ
- プライバシー: データ保持とプライバシー設定を構成する
- テスト: さまざまなシナリオでエージェントをテストする
- 会話をシミュレーション: ガードレール設定をプログラムでテストする
- 会話履歴の編集: 会話履歴から名前や銀行情報などの機密情報を編集する
リリースステータス
Guardrailsは現在アルファ版であり、プロダクトの改善と機能拡張を積極的に進めています。一般提供開始前も、機能セット、デフォルト、ダッシュボードのコントロール、APIフィールドは継続的に変更される予定で、一部の変更には互換性がない場合があります。
Guardrailsの改善を続ける間、設定を検証し、ログでガードレールの動作を監視することを推奨します。また、アップデートの展開に合わせて設定を見直すことも推奨します。