Agent Design Patterns

テーマ

Layered Guardrails（多層ガードレール） ​

エージェントの実行パスの4つの検問所——ユーザー入力・ツール呼出・ツール応答・最終出力——それぞれに独立した検証層を置く。単一時点の検証では防げない攻撃と事故を、多層防御で受け止める。

別名 ​

呼称出典
Guardrails一般的呼称
Content Safety GuardrailsMicrosoft Azure
Defense in Depthセキュリティ原則としての呼称
Input/Output Validation一般的呼称
TripwireOpenAI Agents SDK。ガードレール違反を検知し例外で実行を即時停止する仕組み

問題 ​

エージェントへの脅威は入口だけから来ない。ユーザー入力にはプロンプトインジェクションが含まれ、幻覚や操作された推論は危険なツール呼出（誤った対象への破壊的操作）を生む。

さらに、ツールが取得したWebページ・検索結果・メールなどの外部コンテンツは、間接プロンプトインジェクションを運ぶ。最終出力には機密情報、有害情報、根拠のない断定が混入しうる。

入口の検証だけでは、危険なツール呼出、外部コンテンツ経由の攻撃、最終出力の漏洩が素通りする。マルチエージェント構成では、中間エージェントが有害コンテンツを増幅・伝播しうる（Azure）。

コンテキスト ​

適用する:

  • 外部ユーザーの入力を受けるシステム
  • Web取得・検索・メール読取など、外部コンテンツをツールで取り込むシステム
  • 出力が外部へ公開されるシステム
  • 規制産業など、コンテンツ責任が重いシステム

適用しない（不要な）ケース:

  • 入力・ツール・出力がすべて社内の信頼境界内で完結する場合。層を減らせるが、ツール呼出ガードは残す価値が高い
  • 各層の検証が同一の単純ルールの重複にすぎない場合。検証を統合する

解決 ​

4層それぞれに、決定論的ルール（正規表現・許可リスト・スキーマ検証）と、必要に応じて分類モデルまたは小型LLMによる審査を置く。入力層はインジェクションと不適切要求を検知し、ツール呼出層は呼出先とパラメータを許可リストに照合して危険操作を最小権限で遮断する。

ツール応答層は、外部コンテンツ内の指示文をデータとして扱い、無害化と機密のマスキングを行う。出力層は有害性・機密漏洩・根拠のない断定を審査する。

ガード自体を本体と別のLLM呼出にすると、本体への注入がガードに波及しにくい。ガードと本体をSectioningで分離する例が示されている（Anthropic）。

python
def run_agent(user_input):
    checked_input = guard_input(user_input)
    if not checked_input.allowed:
        return reject(checked_input.reason)

    state = llm(checked_input.data)
    while state.needs_tool:
        request = guard_tool_call(state.tool_request)
        if not request.allowed:
            return reject(request.reason)

        raw_response = tool(request.name, request.parameters)
        response = guard_tool_response(raw_response)
        if not response.allowed:
            return reject(response.reason)
        state = llm(state, response.data)

    output = guard_output(state.result)
    if not output.allowed:
        return reject(output.reason)
    return output.data

実装の要点:

  • 検証点を実行パスに配置する。 入力だけでなく、ツール呼出・ツール応答・最終出力の各境界で独立に判定する
  • 決定論的ルールを先に使う。 許可リスト、スキーマ、正規表現で安価に遮断し、意味判定が必要な場合だけ分類モデルや小型LLMを使う
  • ガードを本体から分離する。 ガードへの入力をデータとして扱い、本体のプロンプトや外部コンテンツが審査ロジックを上書きできない構造にする

トレードオフ ​

  • ✅ 1層を突破されても次層が受け止める、単一障害点のない防御になる
  • ✅ 各層を独立に監査・改善でき、誤検知率を層ごとに計測できる
  • ⚠️ 層ごとにレイテンシとコストが積み上がる。全ツール呼出にLLM審査を挟むと顕著である
  • ⚠️ 過剰な遮断は正当なタスクを妨げ、ユーザーが回避策を探し始める。誤検知率の継続計測が必須である

クラウドパターンとの対応 ​

クラウドパターン本パターンでの再定義
Gatekeeper信頼境界での検証仲介から、検証点が1箇所ではなく実行パス上の4箇所にある多層検証へ
Defense in Depth多層防御の原則に、防御対象として意味内容による攻撃（プロンプトインジェクション）を加える

関連パターン ​

  • Approval Gate — 機械層で担保できない不可逆リスクの最終層として人間が承認する
  • Routing — 入力分類器もプロンプトインジェクションの対象になるため、入力層のガードを適用する
  • ReAct — ツールループの各反復にツール呼出ガードとツール応答ガードを適用する
  • Parallelization — 応答生成と安全審査を並列に分離する構成に利用できる

出典・参考 ​

本文: CC BY 4.0 / コード片: MIT。GitHub で寄稿を受け付けています。