🛡️ AIモデルが突然使えなくなる日に備える モデル可用性BCPの設計

検証日: 2026-06-14 / 契機: 2026-06-12 の Anthropic Claude Fable 5 / Mythos 5 米政府指令停止
対象読者: 実装エンジニア / LLMOps / SRE

■概要

AIモデル可用性 BCP（Business Continuity Plan）は、「特定の AI モデルが突然使えなくなる」リスクを事前に想定し、サービスを継続できるようにする運用設計です。

従来のシステム可用性設計は「ベンダー障害」や「計画メンテナンス」を主な中断シナリオとして想定してきました。しかし 2026 年 6 月 12 日の事象は、それとは異なる種類の中断——規制当局の指令による予告なしの即時停止——が現実に起きることを示しました。

契機イベント: Fable 5 / Mythos 5 の即時停止（2026-06-12）

2026 年 6 月 12 日（金）17:21 ET、Anthropic は米商務省からの輸出管理指令を受け、最新モデル Claude Fable 5 および非公開上位モデル Claude Mythos 5 を全顧客向けに即時無効化しました（Anthropic 公式声明より）。

指令の対象は「米国内外を問わず、すべての外国籍者（自社の外国籍従業員を含む）への提供」でした。外国籍ユーザーと国内ユーザーをリアルタイムに選別することが実務上不可能なため、Anthropic はコンプライアンス確保の手段として全面停止を選択しました。

この事象には次の3つの特徴があります。

1. 通知ゼロ・即日全停止だった — 通常の計画的 deprecation で保証される通知期間が一切適用されませんでした。
2. 契約上、通知ゼロは規約どおりだった — 各ベンダーの利用規約には法令遵守 / force majeure 条項があり、それが通知日数の保証を上書きします。
3. 同一ベンダー内で生き残ったモデルがあった — 停止対象は Fable 5 / Mythos 5 のみで、Claude Opus 4.8 等は影響を受けませんでした。

本ドキュメントは、この事象を起点に「AIモデルが突然使えなくなる」リスクを4クラスに分解し、クラスごとに効く対策・効かない対策を、構造・データ・実装・運用の各面から整理します。

不確実性の明示: 援用された具体的法令名（IEEPA / ECRA / EAR の deemed export 条項のいずれか）は公式声明に明記されておらず "national security authorities" の総称のみです（[未確認]）。政府側の制限解除条件・期限も確認できていません（[未確認]）。事実は一次ソース（Anthropic 公式声明）と複数報道のクロスチェックに基づきますが、WebFetch がブロックされた一部報道（Bloomberg / CNBC / CNN / NBC / Axios）は検索スニペット経由のため [二次情報] とマークします。

■特徴

特徴1: 「モデルが消える」を4クラスに分解する

「特定モデルが突然使えなくなる」を単一リスクとして扱うと、対策を誤ります。発生メカニズム・通知の有無・影響範囲が異なる4クラスに分けると、クラスごとに効く対策が変わります。

今回の事象はクラス2に該当します。クラス1への備え（計画退役の前倒し移行）をいくら整えても、クラス2を防ぐことはできません。

特徴2: ベンダー横断の最小通知日数は桁が違う

計画的 deprecation（クラス1）において、主要ベンダーは一定の通知期間を設けています。一次ソースで確認した最小通知日数を横並びにすると、preview と GA の間で桁が一つ違います。

BCP 設計上は「最弱リンク = preview / experimental の2週間（または通知なし）」を前提に置くことが適切です。また Anthropic の通知は Claude API 直販のみに適用され、Amazon Bedrock 経由の場合は Bedrock 側のライフサイクル日程が優先されます。

特徴3: 通知日数の保証は法令遵守 / force majeure 条項で上書きされる

上記の通知日数は「計画的な退役（deprecation）」に対する commitment にすぎません。主要ベンダーの利用規約・サービス条件には、法令遵守・政府指令・不可抗力による即時停止を認める条項が概ね存在し、それが通知日数の保証を上書きします（AWS / Azure は一般条件またはサービスライフサイクル文書上の例外として規定。逐語の確認状況は下表と[未確認]マークを参照）。

計画的 deprecation の通知日数（lifecycle 文書の commitment）と、法令/政府指令による即時停止（Terms の suspension / force majeure 条項）は別レイヤーです。後者が前者を上書きするため、「数ヶ月の猶予があれば移行できる」という前提だけで BCP を組むと、今回のような事象に無防備になります。

特徴4: 同一ベンダー内の別モデルへの退避で凌げる場合がある

今回の停止は Fable 5 / Mythos 5 の2モデルのみで、Claude Opus 4.8 等の他モデルは影響を受けませんでした。この事実は BCP 設計の方向性を大きく左右します。

規制による停止は「ベンダー全体」ではなく「特定モデル単位」で発動しうる点が重要です。一方で Anthropic 自身が「この基準を業界全体に適用すれば、全フロンティアプロバイダの新モデル展開を実質停止させる」と述べており（Fortune [二次情報]）、規制はベンダー横断で同時に効く可能性もあります。この非対称性が、「マルチプロバイダ化」という直感的な対策がクラス2に対して的外れになりうる理由です。

■構造

「モデル可用性 BCP」は具体的な単一システムを持たない設計方法論のため、C4 model を「BCP 設計の論理構造」に読み替えて表現します。

●システムコンテキスト図

●コンテナ図

●コンポーネント図

モデル設定外出し層

フォールバック・ルーティング層

品質 eval・監視層

監査ログ層

インシデント・顧客コミュニケーション層

■データ

●概念モデル

●情報モデル

■構築方法

すべての抽象化ツールを使わない場合でも、モデル ID をコードに直書きしないだけで、クラス1（計画 deprecation への移行）とクラス2（同一ベンダー内退避）の両方に対応できます。まずこの「外出し」を最優先で行い、マルチプロバイダ抽象化はクラス3の目的で費用対効果を見て判断します。

設定キー早見表（各ツール）

model ID を設定値として外出しする（最小実装）

環境変数で外出し（最小コスト）

# 実装案 / 例
import os
from anthropic import Anthropic

client = Anthropic()
MODEL_ID = os.environ.get("LLM_MODEL_ID", "claude-opus-4-8")  # 環境変数で切替可能

response = client.messages.create(
    model=MODEL_ID,
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
)

# 切り替えは環境変数1つで完結。退避時は1行変更するだけ
export LLM_MODEL_ID=claude-opus-4-8
export LLM_MODEL_ID=claude-haiku-4-5

設定ファイル（YAML）で外出し

# config/model.yaml（実装案 / 例）
llm:
  primary_model: "claude-opus-4-8"
  fallback_model: "claude-haiku-4-5"
  timeout_seconds: 30

Feature Flag で外出し（段階ロールアウト向け）

# 実装案 / 例（GrowthBook / LaunchDarkly 等の SDK と組み合わせ）
import os

def get_model_id(user_id: str) -> str:
    # flag が true の場合に新モデルへ段階的に移行
    if feature_flag_enabled("use_new_model", user_id):
        return os.environ.get("LLM_NEW_MODEL_ID", "claude-opus-4-8")
    return os.environ.get("LLM_MODEL_ID", "claude-haiku-4-5")

LiteLLM — マルチプロバイダ抽象化の最小セットアップ

# SDK のみ（Python 直呼び出し）
pip install litellm
# Proxy サーバとして使う場合
pip install "litellm[proxy]"

各プロバイダの API キーは環境変数で設定します。

export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."
export AZURE_API_KEY="..."
export AZURE_API_BASE="https://your-resource.openai.azure.com/"
export AZURE_API_VERSION="2024-10-21"

SDK（Router クラス）最小セットアップ

出典: https://docs.litellm.ai/docs/routing

import os
from litellm import Router

model_list = [
    {
        "model_name": "claude-opus",           # アプリ側が使う名前
        "litellm_params": {
            "model": "anthropic/claude-opus-4-8",
            "api_key": os.getenv("ANTHROPIC_API_KEY"),
        },
    },
    {
        "model_name": "claude-opus",           # 同じ名前で Bedrock も登録（フェイルオーバー候補）
        "litellm_params": {
            "model": "bedrock/anthropic.claude-opus-4-8",
            "aws_region_name": "us-east-1",
        },
    },
]

router = Router(
    model_list=model_list,
    routing_strategy="simple-shuffle",
    num_retries=3,
    allowed_fails=3,
    cooldown_time=30,
)

response = router.completion(
    model="claude-opus",
    messages=[{"role": "user", "content": "Hello"}],
)

Proxy（config.yaml）最小セットアップ

出典: https://docs.litellm.ai/docs/proxy/configs

# config.yaml
model_list:
  - model_name: claude-opus
    litellm_params:
      model: anthropic/claude-opus-4-8
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: gpt-fallback
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

litellm_settings:
  num_retries: 3
  request_timeout: 30
  fallbacks: [{"claude-opus": ["gpt-fallback"]}]
  allowed_fails: 3
  cooldown_time: 30

general_settings:
  master_key: sk-1234

# Proxy 起動と確認
litellm --config config.yaml
curl http://0.0.0.0:4000/chat/completions \
  -H "Authorization: Bearer sk-1234" \
  -H "Content-Type: application/json" \
  -d '{"model": "claude-opus", "messages": [{"role": "user", "content": "Hello"}]}'

OpenRouter / Vercel AI Gateway / LangChain / Bedrock の最小セットアップ

OpenRouter はインストール不要で、OpenAI 互換クライアントの base_url を差し替えるだけで利用できます。

# 実装案 / 例（補完元: https://openrouter.ai/docs/guides/routing/provider-selection）
import os
from openai import OpenAI

client = OpenAI(api_key=os.getenv("OPENROUTER_API_KEY"), base_url="https://openrouter.ai/api/v1")
response = client.chat.completions.create(
    model="anthropic/claude-opus-4.8",
    messages=[{"role": "user", "content": "Hello"}],
)

# LangChain: プロバイダ:モデル 形式で指定（出典: https://docs.langchain.com/oss/python/langchain/models）
from langchain.chat_models import init_chat_model
model = init_chat_model("anthropic:claude-opus-4-8")

# Amazon Bedrock Converse API: modelId を変えるだけで別モデルへ切替
import boto3
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
response = bedrock.converse(
    modelId="anthropic.claude-opus-4-8-v1:0",
    messages=[{"role": "user", "content": [{"text": "Hello"}]}],
)

■利用方法

フォールバック設定キー一覧表

retry と fallback の順序（共通原則）

「同一モデルへのリトライを尽くしてから別モデルへフォールバック」が基本順序です。

リクエスト
  └─ プライマリモデルへ送信
       ├─ 429 / 5xx → 同一モデルへ retry（num_retries 回）
       │     └─ retry 尽きたら → fallback モデルへ
       ├─ 4xx（400/401/403 等） → retry しない（即失敗 / 別 fallback へ）
       └─ 200 → 成功、schema 検証して返却

• retry 対象: 429（レート超過）、5xx（サーバ障害）
• retry 非対象: 400（不正リクエスト）、401（認証）、403（権限）など 4xx 系
• 4xx はリトライしても解決しないため即座に fallback（またはエラー）へ移行します。

LiteLLM — フォールバック設定の書き方

出典: https://docs.litellm.ai/docs/completion/reliable_completions / https://docs.litellm.ai/docs/routing

from litellm import completion

# 基本フォールバック（モデル名リスト）
response = completion(
    model="anthropic/claude-opus-4-8",
    messages=[{"role": "user", "content": "Hello"}],
    num_retries=3,                                    # 同一モデルへのリトライ
    fallbacks=["openai/gpt-4o", "openai/gpt-4o-mini"], # 順に試す
)

# Router でエラー種別ごとにリトライ回数を分ける（実装案 / 例）
from litellm import Router
from litellm.router import RetryPolicy, AllowedFailsPolicy

retry_policy = RetryPolicy(
    ContentPolicyViolationErrorRetries=0,   # コンテンツポリシー違反はリトライしない
    AuthenticationErrorRetries=0,           # 認証エラーはリトライしない
    RateLimitErrorRetries=3,               # 429 は 3 回リトライ
    InternalServerErrorRetries=3,          # 5xx は 3 回リトライ
)
router = Router(
    model_list=model_list,
    num_retries=3,
    cooldown_time=30,
    retry_policy=retry_policy,
)

テスト用フラグ mock_testing_fallbacks: true を付けると、実際の障害なしにフォールバック動作を検証できます。

OpenRouter — フォールバック設定の書き方

出典: https://openrouter.ai/docs/guides/routing/model-fallbacks

# models 配列（標準エンドポイント用）。実際に使ったモデルは response.model で確認できる
response = client.chat.completions.create(
    model="anthropic/claude-opus-4.8",   # プライマリ（先頭として扱われる）
    messages=[{"role": "user", "content": "Hello"}],
    extra_body={
        "models": [
            "anthropic/claude-opus-4.8",
            "openai/gpt-4o",
            "google/gemini-2.0-flash",
        ],
    },
)

fallbacks パラメータ（Anthropic Messages API 互換エンドポイント用）は最大3件まで、models との併用は不可です。

LangChain — フォールバック設定の書き方

出典: https://docs.langchain.com/oss/python/langchain/models

from langchain.chat_models import init_chat_model

primary = init_chat_model("anthropic:claude-opus-4-8")
fallback_1 = init_chat_model("openai:gpt-4o")
fallback_2 = init_chat_model("google_genai:gemini-2.5-flash-lite")

# primary 失敗 → fallback_1 → fallback_2 の順に試行
model = primary.with_fallbacks([fallback_1, fallback_2])
response = model.invoke("Hello")

実行時に config={"configurable": {"model": "...", "model_provider": "..."}} で切り替えられるようにするには init_chat_model(..., configurable_fields=("model", "model_provider")) を使います。

Vercel AI Gateway — フォールバック設定の書き方

出典: https://vercel.com/docs/ai-gateway/models-and-providers/model-fallbacks

import { streamText } from 'ai';

const result = streamText({
  model: 'openai/gpt-5.5',                     // プライマリモデル
  prompt: 'Hello',
  providerOptions: {
    gateway: {
      models: ['anthropic/claude-opus-4.7', 'google/gemini-3.1-pro-preview'],
    },
  },
});
// 最初に成功したモデルから返す（公式逐語: "Failover happens automatically."）

フォールバック後にどのモデルが使われたかは result.providerMetadata のゲートウェイ情報から取得でき、監査ログに残せます（具体フィールド名は公式 provider-options リファレンスで確認してください）。

fallback 先での出力 schema 検証

フォールバック後のモデルはプライマリと同じ出力フォーマットを返すとは限りません。下流の JSON パーサが壊れることを防ぐため、fallback 先でも出力を検証します。

# 実装案 / 例: pydantic を用いた schema 検証
from pydantic import BaseModel, ValidationError
import json

class OutputSchema(BaseModel):
    answer: str
    confidence: float

def parse_validated(content: str) -> OutputSchema:
    try:
        return OutputSchema(**json.loads(content))
    except (json.JSONDecodeError, ValidationError) as e:
        # schema 不一致はフォールバック成功とみなさず再試行またはエラーにする
        raise ValueError(f"Output schema validation failed: {e}\nRaw: {content}")

■運用

退避ルートの runbook 化

モデル停止イベントを「障害」として扱い、手順を事前に文書化しておくことが稼働後の核心です。

夜間インシデント中に素引きできる最小手順は次のとおりです。

# 1. model ID を切り替える（環境変数 or feature flag）
export LLM_MODEL_ID=claude-opus-4-8
# 2. ロールアウト反映を確認
kubectl rollout status deployment/app-backend
# 3. 5分後に確認するメトリクス: gen_ai.fallback.hop>0 のリクエスト数 / parser エラー率 / p99 latency
# 4. 閾値（p99 +40% / 拒否率 +5%）を超えなければ 1% → 5% へ段階拡大

1. model ID の切り替え: 設定値として外出しされた model ID を変更するだけで退避が始まる（コード変更なし）。
2. カナリアロールアウト: 退避先へ一度に全トラフィックを流さず、段階的に増やして品質を確認する。

同一セッション内で同じモデルに当たるよう、セッション ID でハッシュしてカナリアを割り当てます（高リスクアプリは 0.1% 開始が推奨 [二次情報]）。

3. 品質監視: レイテンシ（p50/p95/p99）、エラー・拒否率、出力スキーマ適合率、コスト per request、ユーザーフィードバックを継続監視する。
4. 自動ロールバック: p99 latency +40% 超・拒否率 +5% 超・コスト超過のいずれかで feature flag 経由で前モデルへ戻す。

観測（OTel span 属性）

フォールバック発生時に以下の OTel span 属性を emit し、「今どのモデルが動いているか」「なぜ退避したか」を可視化します（futureagi.com [二次情報]）。

# すべてのリクエストに model version と rollout 状態を付与する
with tracer.start_as_current_span("llm.request") as span:
    span.set_attribute("gen_ai.model", model_id)
    span.set_attribute("gen_ai.model_version", response.headers.get("x-model-version"))
    span.set_attribute("gen_ai.rollout_state", "canary")  # canary / stable / shadow
    span.set_attribute("gen_ai.request_id", request_id)

品質劣化時の degraded mode 設計

自動フォールバックチェーンがすべて尽きた場合、または品質 floor を下回った場合のフォールバック先として degraded mode を定義します（Google SRE Book / futureagi.com）。

• 静的 UI 表示: LLM 呼び出しなしで「現在 AI 機能が一時的に利用できません」を返す
• ルールベース回答: ナレッジベース検索・FAQ テンプレート・hardcoded 回答
• 人間オペレータへのエスカレーション: チケット起票・Slack 通知

品質 floor の値はカナリアしきい値（p99 +40% / 拒否率 +5%）を転用するのが現実的です。

顧客説明（SEV 別ケイデンスと status 文言テンプレ）

モデル停止は「サービス障害」として扱い、incident communication のプロセスを適用します（incident.io [二次情報]）。

[Identified]
We have identified the issue affecting [AI model / AI feature name].
Our team is implementing a fix and we expect resolution within [timeframe].
Note: During this period, [alternative model / reduced capability] is in use.
Output quality may differ from the usual standard.

モデル品質変動（停止でなく出力品質の低下）を顧客に開示する専用テンプレートは一次ソースに見当たりませんでした（[未確認]）。Atlassian の「degraded performance」文言が最も近い転用元です。

監査ログ保持（EU AI Act への対応）

監査ログは規制対応・説明責任・品質劣化検知の三用途を兼ねます。

{
  "request_id": "req_abc123",
  "timestamp": "2026-06-14T08:00:34Z",
  "model_id": "claude-opus-4-8",
  "model_version": "20261001",
  "rollout_state": "canary_5pct",
  "input_hash": "sha256:...",
  "output_hash": "sha256:...",
  "fallback_hop": 1,
  "fallback_reason": "rate_limit_429"
}

EU AI Act の条文帰属は次のとおりです（条文ビューア artificialintelligenceact.eu で確認。一次ソースは EUR-Lex の Regulation (EU) 2024/1689）。

• Article 12 §1 / §2: 高リスク AI システムに、存続期間を通じたイベントの自動記録（ログ）を技術的に可能にすることを義務付ける。
• Article 19（providers）/ Article 26(6)（deployers）: Article 12 で自動生成されるログを最低6ヶ月保持することを求める。「最低6ヶ月」は Article 12 本文ではなく Article 19・26(6) 側に帰属します。

■ベストプラクティス

リスククラスごとに「誤解 → 反証 → 推奨」の構造で整理します。

クラス1: 計画的 deprecation

• 誤解: 「モデルが廃止されるかもしれないから常時マルチプロバイダを稼働させておく」
• 反証: 主要ベンダーは GA モデルに60日〜6ヶ月の通知を義務付けており、計画的 deprecation の大半は前倒し移行で対処できます。常時マルチプロバイダの維持コストは過剰投資になりえます。
• 推奨: 退役日カレンダーを監視し、通知が来たら後継モデルへの移行 eval を実施する。model ID を設定外出しにしておけば移行コードは最小です。

クラス2: 法令・政府指令 / force majeure（最重要）

• 誤解: 「今回の Anthropic 停止事件の教訓は、マルチプロバイダ化でベンダーロックインをなくすことだ」
• 反証: Anthropic 自身が「同じ jailbreak で OpenAI の GPT-5.5 を含む他の公開モデルからも同様の能力を引き出せる」「この標準が業界全体に適用されれば全フロンティアモデルプロバイダの新モデル展開を実質停止させる」と明言しています（Fortune [二次情報] / Anthropic 公式声明）。規制・輸出管理は米国ベンダー横断で効きうるため、OpenAI/Google に切り替えても同じ指令で同時に止まる可能性があります。また今回の停止対象は Fable 5 / Mythos 5 の2モデルのみで Opus 4.8 は無影響でした。同一ベンダー内の別 GA モデルへの退避が第一候補になりえた（品質 eval と契約要件の確認が前提）ため、マルチプロバイダ抽象化はオーバースペックだった疑いがあります。
• 推奨: 同一ベンダー内の別モデルへの退避経路を runbook 化する。preview モデルを本番に置かない。顧客説明テンプレと監査ログを整備する。マルチプロバイダはクラス3の目的で導入を判断し、クラス2の保険として期待しない。
• 復旧期待値（RTO）の補助情報: Anthropic は公開モデルの重み保全をコミットしています。規制による停止は「重みの消滅」ではなく「コンプライアンス確認後に復旧しうる一時停止」である場合があり、この区別が復旧期待値（どこまで待つか / 恒久退避に切り替えるか）の判断材料になります。ただし重み保全は再提供（推論可用性）の保証ではない点に注意します。

クラス3: ベンダー障害・レート制限

• 誤解: 「多段フォールバックを組んでおけば障害に強い」
• 反証: テストされない failover は本番で失敗します（zylos.ai [二次情報]）。また抽象化レイヤ自身が新たな単一障害点になる事例があります（OpenRouter は公式ステータスで 2026-02-17 に「401 Errors across API surfaces」約1時間21分を記録、解説ブログは 80〜90% 失敗と報じる [二次情報]）。LiteLLM は #15526 で高負荷時に K8s pod が再起動ループに陥るカスケード障害が報告されています（open issue・一次確認済）。
• 推奨: リトライ（429/5xx のみ、4xx はリトライしない）を尽くしてからフォールバック。フォールバックチェーンはカオスエンジニアリングで定期検証する。抽象化レイヤを導入する場合はその可用性自身を SLO に含める。

クラス4: 品質のサイレント劣化

• 誤解: 「自動フォールバックを設定しておけばサービスは継続できる」
• 反証: 自動フォールバックは「動くが結果が劣化して気づかない」リスクを生みます。「Claude Opus 向けに調整したワークフローを小型モデルに routing すると構造的に異なる出力を生み、下流の parsing/validation を壊す」（tianpan.co [二次情報] / arXiv 2606.08162）。eval ゲートも golden set が本番分布を外す・overfitting・継続保守コストという限界があり、安全性の錯覚（false assurance）を生むおそれがあります。
• 推奨: フォールバック先での出力スキーマ適合率を必ず監視する。golden set は本番の実際の失敗事例から作る。自動退避は degraded mode と組み合わせ、品質 floor を割ったら人間にエスカレーションする。

全クラス共通で最も堅い2施策

■トラブルシューティング

■まとめ

AIモデルの突然停止は「計画 deprecation」「法令・政府指令（force majeure）」「ベンダー障害・レート」「サイレント品質劣化」の4クラスに分けると、効く対策が見えてきます。今回の Anthropic Fable 5 / Mythos 5 停止のような規制起因の停止にはマルチプロバイダ化が的外れになりうる一方、全クラスに効く最小の備えは「model ID を設定値として外出しすること」と「どのモデルがいつ何を出したかの監査ログ」です。

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

■参考リンク

概要・契機イベント（一次 / 報道）

• Anthropic 公式声明 — Statement on the US government directive
• Al Jazeera 報道（二次情報）
• Fortune 報道（二次情報）
• 9to5Mac 報道（二次情報）

ライフサイクル・契約条項

• Anthropic Model deprecations
• Anthropic Commercial Terms
• Anthropic 重み保全コミットメント
• OpenAI Deprecations
• OpenAI Services Agreement
• Microsoft Azure Foundry Models lifecycle
• Google Gemini API deprecations
• Google Gemini API models
• Google Cloud Terms of Service
• Amazon Bedrock Model lifecycle

技術的緩和（構築・利用）

• LiteLLM Routing / Proxy Reliability / Reliable Completions / Proxy Configs
• OpenRouter Model Fallbacks / Provider Selection
• Vercel AI Gateway Model Fallbacks
• LangChain Models
• Amazon Bedrock Converse API / Prompt Routing
• promptfoo / Braintrust eval SDK

運用・トラブルシューティング

• EU AI Act Article 12 (Record-keeping)
• Google SRE Book — Handling Overload / Cascading Failures / Workbook — Implementing SLOs
• incident.io — Incident Communication Best Practices / Atlassian — Incident Communication
• futureagi — LLM Fallback Strategy 2026 / tianpan — LLM API Resilience
• LiteLLM Security Update 2026-03 / BerriAI/litellm#15526
• tokenmix — Is OpenRouter Reliable? / cycode — LiteLLM Supply Chain Attack
• MintMCP — AI Agent Liability

準一次ソース（arXiv）

• arXiv 2511.07885 — Intelligence per Watt（OSS vs frontier 精度比較）
• arXiv 2606.08162 — Silent Failure in LLM Agent Systems
• arXiv 2601.20727 — Audit Trails for Accountability in LLMs
• arXiv 2603.23471 — Regulating AI Agents