🚦 能力制限付きルーティング — Fable 5 に学ぶLLMゲートウェイ設計

検証日: 2026-06-10 / 起点: Anthropic「Claude Fable 5 と Claude Mythos 5」発表 (2026-06-09)
対象読者: AIエージェント実装エンジニア / LLMOps / セキュリティ担当

高性能 LLM の導入は「どのモデルを選ぶか」という問いではなく、「どの入力を上位モデルに渡さないか / ログを何日保持するか / 例外アクセスを誰に許すか」を設計する問いに移っています。Anthropic が 2026-06-09 に公開した Claude Fable 5 / Mythos 5 は、この問いに対する一つの答えを「分類器フォールバック + 30 日ログ保持 + trusted access」という形で明示しました。

本記事では、この設計を 能力制限付きルーティング (capability-limited routing) という再利用可能なパターンとして抽出し、自社の LLM ゲートウェイ (LiteLLM / Cloudflare AI Gateway / Portkey / AWS Bedrock) でどう実装するかまで落とし込みます。なお本記事では、capability-limited routing を総称、高リスク時に制限モデルへ回答を落とす下位動作を degrade-routing と呼び分けます。

概要

従来の LLM ガードレールは「拒否 (refuse) か回答 (answer) か」の二値で設計されました。分類器が危険領域を検出したら要求を弾き、そうでなければ高性能モデルがそのまま答えます。単純ですが、拒否はユーザー体験を断絶し、攻撃者には「フラグを立てずに通過する」研究課題を与えます。

能力制限付きルーティングはこの二値から脱します。制御変数を「どのモデルが答えるか」に置き換え、高リスク領域を検出しても会話を打ち切らず、能力を一段落とした別モデルが回答を引き継ぎます (degrade/fallback)。危険な能力だけを選択的に抑制しつつ、無害なトラフィックは高性能モデルで処理し続ける設計です。

Anthropic の Fable 5 では、サイバーセキュリティ / 生物・化学 / 蒸留 (distillation) の 3 領域を対象とする分類器が高リスクを検出すると、Fable 5 ではなく Opus 4.8 へ自動的に回答を委譲します。発火は平均で 5% 未満のセッションにとどまり (ベンダー自己申告値)、発火時はユーザーに通知されます。同時に 30 日ログ保持の義務化 と trusted access (Project Glasswing) による二層アクセス制度も一体で設計されています。

重要なのは、これが Anthropic 固有の選択ではない点です。OpenAI は GPT-5.3-Codex (2026-02) の時点で同型の分類器リルートを実装・公表済みであり、2026 年時点でフロンティアラボへ広がりつつある事実上の収束パターンです。

関連技術との位置づけ

能力制限付きルーティングは既存の複数パターンの合成として理解できます。

パターン対比

ベンダー実装の対応表

特徴

• degrade-routing: 分類器が高リスクを検出しても拒否メッセージを返さず、能力水準を落として (Opus 4.8) 回答を継続します。サイバーは exploit discovery / offensive cyber、生物・化学は精度より broad なセーフガードを優先、蒸留は能力の大規模抽出を検出・ブロックします。
• 発火率 5% 未満という設計目標: 「95% 超がフォールバックなしで完結する」ことを意味します。「発火率を低く保つ = over-refusal を抑制する」という指向は、従来の guardrail (安全側に倒す) と方向が異なります。ただしベンダー自己申告値で第三者検証は未公開です。
• 30 日保持義務と ZDR 不可: Mythos クラス全トラフィックに 30 日保持を義務付け、Zero Data Retention は選べません。保持は安全目的限定・学習禁止・人的アクセスは記録・原則 30 日後削除です。要件未達の組織のリクエストは、Claude API では 400 invalid_request_error で拒否されます (Bedrock/Vertex/Foundry 経由は各プラットフォームの設定に従います)。
• trusted access の二層構造: 下層は全ユーザー向け degrade-routing で危険能力を抑制し、上層は審査済みアクターにセーフガードを外した上位モデルを開放します。技術セーフガード不足を KYC・契約・保持義務・アクセスログというガバナンス統制で代替します。
• フロンティアラボの収束パターン: OpenAI が GPT-5.3-Codex で先行実装・公表済み。Anthropic の差分は (1) 対象を cyber から生物化学・蒸留へ拡張、(2) フォールバック先を汎用最上位 (Opus 4.8) にした点です。

構造

具体プロダクトでなく設計パターンのため、C4 を「能力制限付きルーティングを実装するシステムの論理構造」として描きます。

システムコンテキスト図

コンテナ図

コンポーネント図

各コンテナを構成するコンポーネントを、実在する実装例の具体名とともに示します。

入力分類器

ポリシールータ

フォールバック制御

出力分類器

ログ保持ストア

例外アクセス台帳

リクエストフロー

データ

このパターンが扱うエンティティをモデル化します。

概念モデル

情報モデル

データクラス別ライフサイクル

AccessGrant.kyc_status の状態遷移 (推測・実装から補完):

• is_break_glass: 緊急昇格フラグ。true の場合は事後レビュー必須かつ全フィールドを AuditLog に記録する。
• allowed_models: 付与されたモデルの許可リスト。ModelTier 全体でなく個別モデルを限定する。

構築方法

gateway 層の位置づけと前提

能力制限付きルーティングを実装する際は、実プロバイダキーを隠蔽する gateway 層を 1 箇所に置くことが前提になります。アプリケーション各所に分散させると、ゲートを通らないリクエストが生まれます。LiteLLM proxy / Cloudflare AI Gateway / Portkey のいずれも、このキー隠蔽と一元制御を前提に設計されています。

クライアント
  │ virtual key (実キーを知らない)
  ▼
gateway (LiteLLM proxy / Cloudflare AI GW / Portkey)
  │ 実プロバイダキー (アプリから見えない)
  ▼
LLM プロバイダ (Anthropic / OpenAI / Bedrock 等)

LiteLLM proxy の最小セットアップ

config.yaml の litellm_settings に 4 種のフォールバックキーを置きます。各キーの発火条件は独立しています。

# config.yaml
model_list:
  - model_name: high-capability       # 一次: 高能力モデル
    litellm_params:
      model: anthropic/claude-fable-5
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: limited-capability    # フォールバック先: 制限モデル
    litellm_params:
      model: anthropic/claude-opus-4-8
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: large-context         # コンテキスト超過時の代替
    litellm_params:
      model: anthropic/claude-opus-4-8
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  enable_pre_call_checks: true        # コンテキスト超過の事前チェックを有効化

litellm_settings:
  num_retries: 2

  # (1) コンテンツポリシー違反専用: ContentPolicyViolationError で発火
  #     高能力モデルが危険コンテンツを検出 → 制限モデルへ委譲
  content_policy_fallbacks:
    - "high-capability": ["limited-capability"]

  # (2) 一般エラー(429/500)用: ポリシー違反では発火しない
  fallbacks:
    - "high-capability": ["limited-capability"]

  # (3) コンテキスト超過専用: ContextWindowExceededError で発火
  context_window_fallbacks:
    - "high-capability": ["large-context"]

  # (4) モデル固有設定なし時の汎用フォールバック
  default_fallbacks:
    - "limited-capability"

content_policy_fallbacks と fallbacks は別キーで独立して動作します。fallbacks だけではコンテンツポリシー違反を拾えません。「能力で落とす」と「エラーで落とす」を分離することで、フォールバック発火の原因を監視ログで区別できます。

必須パラメータ早見表

利用方法

(A) 能力ゲーティング: content_policy_fallbacks + LiteLLM guardrails

LiteLLM は Presidio / Bedrock Guardrails / OpenAI Moderation / カスタムガードレールを差し替え式で利用でき、ガードレールはモデル単位で個別 attach も可能です。

# config.yaml (guardrails セクション追加例)
guardrails:
  - guardrail_name: pii-presidio
    litellm_params:
      guardrail: presidio
      mode: pre_call               # 入力に対してのみ実行
      presidio_analyzer_api_base: "http://localhost:5002"
      presidio_anonymizer_api_base: "http://localhost:5001"

  - guardrail_name: openai-moderation
    litellm_params:
      guardrail: openai-moderation
      mode: pre_call
      api_key: os.environ/OPENAI_API_KEY

model_list:
  - model_name: high-capability
    litellm_params:
      model: anthropic/claude-fable-5
      api_key: os.environ/ANTHROPIC_API_KEY
      guardrails: ["pii-presidio", "openai-moderation"]  # このモデルにのみ適用

LiteLLM の Policy Flow Builder を使うと「能力で落とす」と「壊れたから落とす」を分離できます。公式では policies / pipeline.steps で段階ガードを定義し、各ステップに on_fail / on_error を設定します (正確なキー構造は公式ドキュメントを参照)。以下は段階分離の考え方を示すイメージです。

# イメージ: 段階ガードの考え方 (正確な YAML キーは公式 Policy Flow Builder ドキュメントを参照)
pipeline:
  steps:
    - guardrail: fast-topical-filter   # 軽量な一次分類
      on_fail: next                    # 発火 → 次のより厳格なガードへ
      on_error: next                   # 技術障害 → 次のガードへ(ブロックしない)
    - guardrail: strict-safety-reasoner # 高精度な二次分類
      on_fail: block                   # 発火 → ブロック(能力制限フォールバックを発動)
      on_error: allow                  # 技術障害 → 通過させる(可用性優先の場合)

on_fail: next で「fast topical classifier → stricter safety reasoner」の 2 段階判定を組めます。なお on_error を省略すると on_fail と同じ挙動になり、技術障害時に意図せずブロックする恐れがあるため、可用性を優先する場合は明示的に on_error: allow を指定します。

(B) Cloudflare AI Gateway: フォールバック観測

Universal endpoint にプロバイダ配列を渡し、一次が失敗・タイムアウトすると次に切り替わります。cf-aig-step ヘッダでどのプロバイダが最終処理したかを観測できます。

step = response.headers.get("cf-aig-step", "unknown")
# step == "0": 高能力モデル到達
# step >= "1": フォールバック発火 → KPI カウンタをインクリメント
if int(step) >= 1:
    metrics.increment("capability_limited_routing.fallback_fired")

ただし cf-aig-step が示すのは fallback 配列のステップ (= 一次プロバイダの失敗・タイムアウトによる failover) であり、ガードレール判定による能力制限ルーティングそのものは直接表しません。「95% のセッションはフォールバック無し」のようなコンテンツポリシー由来の degrade を計測したい場合は、Guardrails の flag イベントログや LiteLLM の content_policy_fallbacks 発火件数を別途集計します。Guardrails は prompt と response を別々に評価し、block (遮断) または flag (ログ記録のみ・通過) を選べます。

(C) Portkey 条件付きルーティング

{
  "strategy": {
    "mode": "conditional",
    "conditions": [
      {
        "query": {
          "$and": [
            { "metadata.user_tier": { "$eq": "trusted" } },
            { "metadata.clearance_level": { "$eq": "high" } }
          ]
        },
        "then": "high-capability-target"
      },
      {
        "query": { "metadata.user_tier": { "$eq": "standard" } },
        "then": "limited-capability-target"
      }
    ],
    "default": "limited-capability-target"
  },
  "targets": [
    {
      "name": "high-capability-target",
      "provider": "@anthropic-trusted-key",
      "override_params": { "model": "claude-fable-5" },
      "input_guardrails": ["pii-detector"],
      "output_guardrails": ["distillation-checker"]
    },
    {
      "name": "limited-capability-target",
      "provider": "@anthropic-standard-key",
      "override_params": { "model": "claude-opus-4-8" }
    }
  ]
}

重要な制約: Portkey の conditional routing 自体には明示的な deny/block 機構は無いです。未マッチのリクエストは常に default ターゲットへ流れます。「拒否」を実現するには default ターゲットを制限モデルに向けるか、ターゲットに付与した guardrail 側で deny します。

(D) 例外アクセス(trusted access): LiteLLM virtual key + Access Groups

Step 1: config.yaml でモデルをアクセスグループに割り当てる

model_list:
  - model_name: claude-fable-5
    litellm_params:
      model: anthropic/claude-fable-5
      api_key: os.environ/ANTHROPIC_API_KEY
    model_info:
      access_groups: ["trusted-access"]   # 高能力モデルは trusted-access グループに限定

  - model_name: claude-opus-4-8
    litellm_params:
      model: anthropic/claude-opus-4-8
      api_key: os.environ/ANTHROPIC_API_KEY
    model_info:
      access_groups: ["standard-access"]  # 制限モデルは standard-access グループ

Step 2: 全員に standard-access キーを発行する

curl 'http://localhost:4000/key/generate' \
  -H 'Authorization: Bearer <master-key>' \
  -H 'Content-Type: application/json' \
  -d '{"models": ["standard-access"], "duration": "90d", "metadata": {"tier": "standard"}}'

Step 3: 審査を通った主体にだけ高能力モデル入りキーを期限付きで発行する

curl 'http://localhost:4000/key/generate' \
  -H 'Authorization: Bearer <master-key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "models": ["trusted-access", "standard-access"],
    "duration": "30d",
    "max_budget": 100,
    "metadata": {"tier": "trusted", "approved_by": "security-review", "purpose": "cyber-defense-research"}
  }'

この構成で「Mythos 5 は Glasswing 参加者だけ」を自社 gateway で再現できます。発行・利用・期限切れはすべて proxy ログに残り、監査証跡になります。

運用

フォールバック発火率の監視

能力制限付きルーティングの稼働品質は「上位モデルへ届かず制限モデルへ落ちた割合」で把握します。Anthropic は全体の 5% 未満がフォールバック発火と公表していますが (ベンダー自己申告。二次情報: CyberScoop)、これは自社トラフィックでの実測が必須です。下表の 5% / 95% は Anthropic 公表値を初期参考値として置いたもので、自社 baseline 確立後に更新します。

# Grafana アラートルール例 (PromQL): 発火率が 10% を 5分超継続したら通知
- alert: HighFallbackRate
  expr: |
    rate(litellm_content_policy_fallback_total[5m])
    / rate(litellm_requests_total[5m]) > 0.10
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "フォールバック発火率が 10% を超過"

ログ保持運用

一律 TTL は誤りです。Anthropic 自身がデータクラスごとに保持を分離しています。AWS Bedrock Model Invocation Logging はデフォルト無効で、有効化すると request/response/metadata を CloudWatch Logs / S3 へ収集し、保持期間は自社設定で完全制御できます。

# Terraform: 規制業種 (医療・金融) は CloudWatch 90日 / 180日後 Glacier / 7年保持
resource "aws_cloudwatch_log_group" "bedrock_regulated" {
  name              = "/aws/bedrock/invocations/regulated"
  retention_in_days = 90
}

resource "aws_s3_bucket_lifecycle_configuration" "bedrock_logs_regulated" {
  bucket = aws_s3_bucket.bedrock_logs_regulated.id
  rule {
    id     = "regulated-ttl"
    status = "Enabled"
    transition {
      days          = 180
      storage_class = "GLACIER"
    }
    expiration {
      days = 2555  # 7年
    }
  }
}

確実な削除と削除証跡:

• S3 lifecycle の動作検証: aws s3api list-objects-v2 で expiration 後にオブジェクトが存在しないことを週次確認する。
• 削除証跡: S3 Object Lock (Compliance モード) または CloudTrail で DeleteObject イベントを記録する。
• DB の物理削除確認: 論理削除フラグでは GDPR 消去権 (Right to Erasure) を満たせない。

人的アクセスは IAM で最小権限化し、CloudTrail のデータイベント (s3:GetObject) で「誰がいつどのログを参照したか」を別バケットに長期保存します。これが Mythos クラスの「人的アクセス全ログ」要件の自社再現になります。

例外アクセス運用

PAM (Privileged Access Management) の型を gateway 層で実装します。高能力モデルを含む virtual key には有効期限を必ず付与し、恒久キーは発行しません。break-glass (緊急昇格) は発動条件を文書化し、24 時間以内の事後レビュー SLA を設定して、CloudTrail + Lambda で Slack へ即時通知します。

ベストプラクティス

モデル選定を「性能比較」から始めると、稼働後に保持要件・分類器チューニング・例外アクセス管理が後付けになります。Fable 5 のように「保持要件を満たさなければ API が 400 invalid_request_error で弾く」時代では、設計の順序を守ることが稼働の前提条件です。

Phase A: 能力ゲーティング (モデル選定の前提)

• 自社の「高リスク入力カテゴリ」を言語化する (例: 外部公開コードの脆弱性探索、認証情報の操作、本番 DB 破壊系ツール呼び出し、PII 大量処理)。
• gateway 層に入力ゲートを 1 箇所置き、全リクエストが必ずゲートを通る構成にする。実プロバイダキーは virtual key で隠蔽する。
• 高リスク検出時は「拒否」より「ダウングレード」を基本にする。拒否を主体にすると over-refusal が業務を止める。
• prompt と response の両方を評価するか判断する (出力側の蒸留・漏洩対策)。
• フォールバック発火率の観測を稼働初日から入れる。
• 分類器を単独防御とせず、出力検査・ツール権限制限・監査と組み合わせた多層防御にする。

Phase B: ログ保持 (モデルが保持要件を課す前提)

• 採用候補モデルの保持要件を事前確認する (Fable 5 / Mythos 5 は ZDR 不可・30 日必須・未達は 400)。
• データクラス (本文 / 安全フラグ / 監査メタ / PII) を分離し、クラスごとに TTL・アクセス権・削除方式を独立定義する。一律 TTL は GDPR データ最小化原則 (第 5 条 1 項 e) と衝突しうる。
• TTL を目的から逆算する (安全=短期 ≈30 日 / 監査・規制=長期)。目的のない保持はしない。
• コンプライアンス境界 (HIPAA/PHI) をテナント/組織で物理分離する。Anthropic は HIPAA と非 HIPAA の混在を組織レベルで禁止している。
• structured output の schema に機密を入れない (JSON schema は本文と別キャッシュされ保護対象外になりうる)。

Phase C: 例外アクセス (高リスク能力を開く前提)

• 高リスク能力をデフォルト拒否にし、審査を通った主体にだけ高能力モデル入りキーを期限付きで発行する。
• KYC 的審査・承認基準を文書化する (Project Glasswing の「セキュリティ要件充足」に相当)。
• 付与を just-in-time + 期限付き + 多要素/HITL 承認にする。
• break-glass と事後レビュー SLA・全証跡保持を事前設計する。
• 人・サービス・AI エージェントを identity として扱い、付与/失効/利用を完全監査する (agentic identity)。

トラブルシューティング

まとめ

能力制限付きルーティングは、「拒否か回答か」の二値ガードレールを「どのモデルが答えるか」へと作り替え、分類器フォールバック・データクラス別のログ保持・KYC 型の例外アクセスを一体で設計するパターンです。Anthropic Fable 5 / Mythos 5 と OpenAI GPT-5.3-Codex の収束が示すとおり、これは今後の高リスク AI 運用の標準形になりつつあり、自社でも LiteLLM / Cloudflare AI Gateway / Bedrock を使って「モデル選定の前に能力ゲート・ログ保持・例外アクセスを決める」順序で実装できます。一方で、分類器層の構造的な脆弱性・強制ログ保持のコンプライアンス摩擦・自前実装の over-refusal という 3 つの留保があり、分類器は「侵害の到達範囲を絞る一層」であって単独の安全保証ではない点を忘れてはいけません。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

公式ドキュメント

• Anthropic: Claude Fable 5 と Claude Mythos 5
• Anthropic: API and data retention
• Anthropic: Project Glasswing
• Anthropic: Activating ASL-3 protections
• OpenAI: Codex Cyber Safety
• OpenAI: Your data in the API
• LiteLLM: Fallbacks / content_policy_fallbacks
• LiteLLM: Guardrails Quick Start
• LiteLLM: Policy Flow Builder
• LiteLLM: Virtual Keys
• LiteLLM: Model Access Groups
• LiteLLM: Access Control
• Cloudflare AI Gateway: Guardrails
• Cloudflare AI Gateway: Fallbacks (cf-aig-step)
• Portkey: Conditional Routing
• AWS Bedrock: Model Invocation Logging

学術論文

• SafeRoute (arXiv:2502.12464)
• Guarded Query Routing for LLMs (arXiv:2505.14524)
• Bypassing Prompt Injection and Jailbreak Detection in LLM Guardrails (arXiv:2504.11168)
• FalseReject (arXiv:2505.08054)
• Model Access should be a Key Concern in AI Governance (arXiv:2412.00836)

解説記事

• CyberScoop: Anthropic Claude Fable 5 release, Mythos guardrails
• TechCrunch: Anthropic released Claude Fable 5
• Unite.AI: Claude Fable 5 Makes Frontier AI a Metered Utility
• LogRocket: LLM routing in production
• GDPR Local: LLM GDPR compliance