メインコンテンツへスキップ
ガードレールを単一の API キーにアタッチできますが、ほとんどのチームはフロアを 望みます：キーが別のものをオプトインしない限り、ワークスペースのすべてのキーに 適用されるコンテンツポリシーです。そのフロアがワークスペースデフォルトです — is_default とマークされたひとつのガードレールで、キーに明示的なアタッチメントが ないときにゲートウェイがフォールバックします。 このページはデフォルト AI ガードレールを扱います：どう設定するか、解決がどう 機能するか、そして暗記する価値のあるひとつの不変条件 — ワークスペースごとに ひとつのデフォルト。完全なエンジンリファレンスについては、 ガードレールリファレンスを参照してください。
ここでのすべては、あなた自身のセッション下で実行される、ホスト型ゲートウェイ （api.orcarouter.ai）上のコンソールアクションです。最後の /v1/* 呼び出しの みが sk-orca-... リレーキーを使います。デフォルトガードレールのプロモートまたは 降格にはワークスペースで Developer+ が必要です。

​
1. なぜデフォルト AI ガードレールを設定するのか

キーごとのアタッチメントは正確ですが忘れやすい — 新しいキーを発行し、ドロップ ダウンをスキップすると、そのキーはゼロのスクリーニングで出荷されます。 ワークスペースデフォルトはそのギャップを閉じます：

アタッチメントのないキーが継承する

guardrail_id が未設定（0/null）の任意のキーは、デフォルトで自動的に スクリーニングされます — 設定後に作成されたキーを含みます。

一度編集すれば、ワークスペース全体がシフトする

デフォルトは各キーではなくゲートウェイに存在します。編集すれば、継承する すべてのキーが次の呼び出しでシフトします — 再デプロイなし、SDK 変更なし。
一般的なパターン：保守的な PII Shield をワークスペースデフォルトにして 何も偶然に漏れないようにし、その後、必要なときに特定のキーがより厳格またはより 緩いポリシーをアタッチできるようにします。

​
2. ガードレールをデフォルトにプロモートする

コンソールで Guardrails を開き、フロアにしたいガードレールを編集し、 Set as workspace default をトグルします。保存します。
1

ガードレールを作成または選ぶ

通常どおりポリシーを作成します — 例：PII Shield プリセット、 both ステージでマスクする単一の pii ルール。
2

デフォルトとしてマークして保存する

Set as workspace default をオンにして保存します。ガードレールの is_default フラグがオンに切り替わります。
3

キーをアタッチしないままにする

明示的なガードレールがない任意のキーは、今やこれを継承します。すでに 別のガードレールを指しているキーは、そのアタッチメントを保持します。
デフォルトが有効になるには、有効でもなければなりません。is_default と マークされていても無効化されたガードレールは強制なしに解決されます — トグルと有効状態は独立したスイッチです。

​
3. ワークスペースごとにひとつのデフォルト — プロモーションはアトミック

これが不変条件です：ワークスペースごとに最大ひとつのガードレールが is_default を持ちます。古いものを手動で解除する必要は決してありません。 新しいガードレールをデフォルトにプロモートすると、ゲートウェイは同じ トランザクション内で以前のデフォルトを降格します — プロモートと降格は両方とも 着地するか、どちらもしません。2 つのガードレールが両方ともデフォルトである窓も、 どれもデフォルトでない窓も決して存在しません。 
Before:   billing-pii   ← is_default ✓
          legal-redact

Promote "legal-redact" to default
          (single transaction)
          ┌─────────────────────────────────────────┐
          │  legal-redact  → is_default = true       │
          │  billing-pii   → is_default = false       │
          └─────────────────────────────────────────┘

After:    billing-pii
          legal-redact  ← is_default ✓
先に降格する必要はありません。新しいものをプロモートするだけです — 古い デフォルトはアトミックにあなたのためにクリアされます。降格されたガードレールは 依然として存在し、有効なままです。単にフォールバックとして機能しなくなるだけです。 それに明示的にアタッチされたキーは影響を受けません。
作成時（真新しいガードレールをデフォルトとしてマーク）でも編集時 （既存のもののフラグを切り替え）でも、同じアトミックスワップが適用されます。

​
4. 解決がデフォルトをどう使うか

任意のリクエストについて、ゲートウェイはこの固定された順序で正確にひとつの ガードレール（または none）を解決します：
順序何が適用されるか
1キーの明示的な guardrail_id — 存在し有効である場合。
2ワークスペースの有効な is_default ガードレール（キーにアタッチメントなし）。
3None — リクエストはポリシーのないワークスペースとバイト単位で同一です。
明示的なキーアタッチメントは決してサイレントにデフォルトにフォールバックしません。 キーがガードレールを指し、そのガードレールが無効化されている場合、キーは 強制なしに解決されます — ワークスペースデフォルトではなく。アタッチされた ガードレールの無効化はそのキーのオフスイッチです。（ファイアウォールポリシーは ここで異なる振る舞いをします — 無効化されたアタッチ済みファイアウォールポリシーは ワークスペースデフォルトにフォールバックします。 ガードレール vs. ファイアウォールを参照。）
つまりデフォルトはアタッチされていないキーのみのフォールバックです。明示的な 選択をしたキーを上書きすることは決してありません。
設計上のフェイルオープン。 デフォルト解決が一時的なエラーに遭遇した場合、 ゲートウェイはリクエストを失敗させるのではなく強制なしに劣化します。安全性は 劣化しますが、可用性は維持されます。

​
5. 実例

ワークスペースに 2 つのガードレールと 3 つのキーがあるとします：
  • pii-shield — ワークスペースデフォルトとしてマーク、有効。
  • strict-block — クレジットカードをブロック、デフォルトではない。
  • キー A — アタッチメントなし。キー B — strict-block にアタッチ。キー C — 後で無効化したガードレールにアタッチ。
email に言及するリクエストはこのように解決されます：
guardrail_id が未設定なので、解決は有効な is_default ガードレール pii-shield に流れ落ちます。email はモデルが目にする前に [EMAIL] に マスクされます。
明示的アタッチメントが勝ちます。strict-block が適用され、デフォルトは 決して参照されません。
アタッチメントは存在しますがそのガードレールは無効化されているため、解決は none を返します — pii-shield に流れ落ちません。リクエストは スクリーニングされません。
ここで strict-block をデフォルトにプロモートして保存します。ひとつの トランザクション内で strict-block.is_default が true になり、 pii-shield.is_default が false になります。キー A は、キー自体を一切 変更することなく、次の呼び出しで即座に strict-block を継承します。

​
6. リクエストがデフォルトにヒットすることを確認する

アタッチされていないキーでリクエストを送信し、 マッチフィードを確認します — デフォルト ガードレールの下に記録されたマッチが、フォールバックが発火したことを確認します： 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Reply to jane@acme.com please"}
    ]
  }'
デフォルトがマスキング PII ポリシーであれば、ゲートウェイは転送前に email を [EMAIL] に書き換えます。ブロックする場合、呼び出しは HTTP 400 guardrail_blocked を返します — これはクォータを消費せず、skip-retry と マークされます。完全なレスポンス形状は guardrail_blocked エラーを 参照してください。
いずれかのキーがそれに頼る前に、デフォルトの挙動を証明したいですか？ ガードレールエディタの Test タブを開き、input ステージでサンプルを実行 します — アップストリーム呼び出しなし、クォータなし。 テストと evalを参照。

​
7. 次にどこへ

単一のキーにアタッチする

ひとつのキーがワークスペースフロアと異なるポリシーを必要とするとき。

最初のガードレールを作成する

エンドツーエンドのループ — 作成、テスト、アタッチ、送信。

解決とスコープ

キー、ポリシー、ワークスペースがどう組み合わさるか。

バージョニング

すべてのプロモーションは履歴行を書き込みます — diff して revert します。
デフォルトのプロモートまたは降格はそれ自体がバージョン付きの変更です — ガードレール の History を開いて、いつ is_default が切り替わり、誰が行ったかを確認します。 完全なエンジンについては、ガードレールリファレンスを 読んでください。