ガードレール（入力と出力の検査）は「どこに置くか」「止めるか、記録するか」を決める設計：OpenAI・Anthropic・Google・AWSの公式の部品を、公式資料で確かめる

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月22日に確認しました。変わることがあります。

先に結論

• ガードレールとは、AIに渡す前の入力と、AIが返した後の出力を調べて、通す、止める、直す、記録する、のどれかをする仕組みです。この記事では、公式の文書が説明している範囲に絞ります。
• 公式の部品は、検出と、遮断の基準づくりが中心です。止めたときに何を返すか、誰に知らせるかは、アプリ側で決める設計の仕事です（僕らの整理です）。
• 検査は、置く場所によって守れる範囲が変わります。たとえばOpenAIのAgents SDKでは、入力の検査は最初のエージェントだけ、出力の検査は最後のエージェントだけが対象です。途中は別の仕組みが要ります。

公式の部品を並べる

検査を置く場所

入力、出力、道具の呼び出し

OpenAIのAgents SDKの文書によると、検査は3か所に置けます。入力の検査は、ユーザーの入力を調べ、最初のエージェントでだけ動きます。出力の検査は、最後の答えを出すエージェントが終わった後に動きます。道具の検査は、自分で定義した関数の道具を呼ぶたびに動きます。

ここに、設計上の穴が書かれています。入力と出力の検査は、途中のエージェントを対象にしません。道具の検査は、エージェントへの引き継ぎ（ハンドオフ）や、OpenAIが用意した道具（ホスト型の道具）、組み込みの実行用の道具は対象外です。つまり、「検査を付けたつもり」の外側が、構成によってはあります。

「道具の結果」を検査する

Anthropicの文書は、利用者は信頼できるが、AIが読む第三者の内容（道具の結果など）に悪意のある指示が混ざる場合を、別の脅威として扱っています。対策として、次の点が挙げられています。

• 信頼できない内容は、tool_result（道具の結果）の枠にだけ入れる。システムの指示や、ふつうのユーザーの文章に混ぜない。
• 内容の出どころと性質を、ラベルで示す。
• 信頼できない文字列は、JSONとして書き出して、区切りをはっきりさせる。
• 自分の指示を、道具の結果の中に入れない。
• 権限は最小にする。
• AIに渡す前に、道具の出力を小さいモデルで調べ、指示が混ざっていれば渡さない。

「間接インジェクション」の考え方そのものは、別の記事でも扱っています。

止めるか、待つか：並べるか

OpenAIのAgents SDKは、入力の検査の動かし方を2つに分けています。既定は並列で、検査をエージェントと同時に走らせます。待ち時間は最小ですが、検査が引っかかったときには、エージェントがすでにトークンを使ったり、道具を動かしたりしている場合があります。もう1つは、検査が終わるまでエージェントを始めない方法です。引っかかれば、費用も副作用も出ません。代わりに、始まるまでの待ち時間が増えます。

OpenAIの別の文書（Latency optimization）にも、モデレーションのように結果がほぼ決まっている確認は、本命の処理と同時に始めて、結果が予想と違えば本命を取り消す、という書き方が載っています。

モデレーションAPIは、ストリーミング（少しずつ表示する方式）の場合、スコアは出力が全部そろってから届き、途中の断片には付かない、と書かれています。

見立てです。ここは、「失敗の重さ」で決めるのが分かりやすいと思います。メールの送信や支払いのように、取り消せない作業につながる入力は、先に検査を終えてから進める。チャットの返事のように、あとで引っ込められるものは、並べて待ち時間を優先する。公式の文書は、この判断基準を書いてはいません。

検査の結果をどう扱うか

スコアは「信号」で、判決ではない

OpenAIのModeration APIの文書は、スコアを、自分の方針のための信号として使い、自動で遮断する判断にはしないように、と書いています。また、安全に配慮した返事や、拒否の文章でも、有害な話題に触れていれば「フラグあり」になりうる、と書いています。モデルが更新されると、スコアの基準が変わる可能性もあります。自分で閾値を決めた場合は、見直しが必要です。

Geminiの安全設定は、遮断が「害の確率」に基づき、「害の重さ」ではないと書いています。確率が低くても、重い内容がありうる、という注意です。

検査自体が失敗する

Anthropicの文書には、検査用の小さいモデルが、検査の依頼そのものを拒否することがある、と書かれています。その場合の拒否（refusal）は、有害の判定として扱うように、とあります。OpenAIの文書は、モデレーションの結果が、スコアの代わりにエラーになることがあると書いています。Agents SDKでは、検査の関数が例外を出した場合は、「却下」とは見なされません。

つまり、「検査が動かなかったとき、通すのか、止めるのか」を、あらかじめ決めておく必要があります。これは公式が答えを書いている点ではなく、設計の宿題です。

止めたあとに残るもの

Agents SDKの文書は、出力の検査で却下されたとき、却下された最終出力は保存されない、と書いています。道具の結果がそのまま最終出力になって却下された場合は、置き換えの文言（プレースホルダー）が残ります。ただし、関数を呼んだときの引数などは残ります。そこに、却下した出力と同じ情報が入っていることがありえます（僕らの読みです）。止めたつもりでも、情報が別の場所に残りうる、という注意です。

最小の構成（見立て）

ここからは僕らの見立てです。公式の考え方を、小さな構成にまとめました。

1. 入力に、軽い検査を1つ。 有害さの分類（Moderation APIなど）か、小さいモデルによる判定。判定は、決まった形（真偽だけなど）で返させます。
2. 出力にも、軽い検査を1つ。 入力だけだと、AIが自分で作った内容は調べられません。
3. 道具の呼び出しの前に、権限の検査を。 取り消せない操作は、検査と人の確認を通します。
4. 検査が動かなかった場合の扱いを決める。 通すか、止めるか、人に回すかを、作業の重さ別に決めます。
5. 引っかかった記録を残す。 あとで基準を見直す材料になります。残す内容の扱いは、別の記事（個人情報とログ）で書きます。
6. 攻撃を想定したテストを、公開前に。 OpenAIもAnthropicも、悪意のある入力を含めて試す（レッドチーム）ことを勧めています。

Anthropicの検査の案内が示す、判定を決まった形で受け取る書き方は、公式の例を短くすると、こんな形です。動作確認はしていません。

{
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "properties": { "is_harmful": { "type": "boolean" } },
        "required": ["is_harmful"],
        "additionalProperties": false
      }
    }
  }
}

構造化出力の仕組みは、別の記事で扱っています。

よくある落とし穴

• 検査を入れたことで、安心してしまう。Anthropicは、これらの対策を層にして重ねるように書いています。検査1つで十分とは書かれていません。
• 設定を緩めたまま忘れる。Geminiの文書は、緩い設定のアプリは見直されることがある、と書いています。
• 検査の対象外に気づかない。Agents SDKの道具の検査は、OpenAI側の道具やエージェントの引き継ぎを対象にしません。
• 却下した出力が、別の場所に残る。上に書いた、引数の例のとおりです。
• スコアの基準を固定する。OpenAIは、モデルの更新で見直しが要る場合がある、と書いています。
• 検査に入力の長さの制限を使う。OpenAIは、入力を短くすると、プロンプトインジェクションを避けやすい、とも書いています。長さの制限は、検査の代わりではなく、足す層です。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。内容は公式の文書の記載で、JSONの例も公式の文書から短くしたものです。
• 公式ページは、WebFetchという取得の仕組みで読みました。この仕組みは要約を返すので、細部を取りこぼしている可能性があります。Anthropicのページは、一部の見出しの中身が取れていません。
• Bedrock Guardrailsの文書は、数値の上限、待ち時間、精度を書いていませんでした。ほかのモデルとの組み合わせ方は、読んだページでは確認できていません。
• OpenAIのModeration APIの文書は、対応する言語や、精度の数字を書いていませんでした。「ない」とは断定できません。
• 法令や、各国の規制への適合は、この記事の対象外です。助言ではありません。
• 検査の効果（どれだけ防げるか）を示す数字は、今回読んだ文書にはありませんでした。
• 仕様、既定値、対応モデルは、変わることがあります。見立ての部分は、公式の指示ではなく、僕らの整理です。

出典

• Moderation（OpenAI API、OpenAI、10月22日確認）
• Safety best practices（OpenAI API、OpenAI、10月22日確認）
• Guardrails（OpenAI Agents SDK、OpenAI、10月22日確認）
• Mitigate jailbreaks and prompt injections（Claude Platform Docs、Anthropic、10月22日確認）
• Safety settings（Gemini API、Google AI for Developers、Google、10月22日確認）
• Amazon Bedrock Guardrails（Amazon Bedrock User Guide、AWS、10月22日確認）
• Latency optimization（OpenAI API、OpenAI、10月22日確認）

更新履歴

• 2026年10月25日 書き方を直しました。

  • 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した

• 2026年10月22日 公式の資料を読み直しました。書いてあることに変わりはありませんでした。