AI Routerでモデルコストを抑える方法と、外部AI API障害時のフェイルオーバー設計

# 対象: 自組織のAI Routerのルーティングポリシー定義
# 権限: ポリシー定義の編集権限
# 変更作業: なし（定義の記述例）
# Production 実行: 該当なし（設計サンプル）

# 「小 / 中 / 大」は自組織で採用しているモデルの相対的な区分を指す。
# 具体的なモデル名と価格は変動するため、ここでは書かずに定義側で解決する。

タスク種別            | 既定の割り当て | 出力上限 | 品質ゲート                   | 不合格時の扱い
----------------------|----------------|----------|------------------------------|----------------------------
分類・ラベル付け      | 小             | 短       | 許可ラベル集合に含まれるか   | 中へ1回だけ再試行
構造化抽出（JSON）    | 小             | 中       | JSONスキーマ検証             | 中へ1回だけ再試行
要約（短文）          | 小             | 中       | 入力に無い固有名詞が無いか   | 中へ1回だけ再試行
要約（長文・横断）    | 中             | 長       | 参照元の提示があるか         | 大へ1回だけ再試行
コード生成（定型）    | 中             | 中       | 構文解析とテスト実行         | 大へ1回だけ再試行
設計判断・長文推論    | 大             | 長       | 人間のレビュー               | 再試行しない（人へ回す）
自由入力の対話        | 中             | 中       | 出力フィルタ                 | 中で再試行（上位へ上げない）

共通の制御:
  timeout:            タスク種別ごとに設定。長文推論だけ長くする
  max_retries:        2 まで。ジッタ付き指数バックオフ
  prompt_cache:       システムプロンプトと共通コンテキストは前方固定にして再利用する
  result_cache:       入力のハッシュをキーにする。ただし個人情報を含む入力は対象外
  batching:           即時性が不要なタスクのみ。締切のあるタスクは対象外
  budget_guard:       日次・月次の上限に対する消費割合を監視し、しきい値で通知する

計測の前提:
  - 振り分けの妥当性は、自組織の利用ログ（タスク種別ごとの件数・入出力量・
    品質ゲートの合格率・上位モデルへの再試行率）で判断する
  - 単価と提供モデルは変わるため、各プロバイダの現行の価格ページを定期的に確認する

# 対象: 自組織のAI Router（複数プロバイダを束ねる中継層）
# 権限: 各プロバイダのAPIキー参照権限とRouterホストへのシェルアクセス
# 変更作業: なし（疎通確認と状態ファイルの読み書きのみ）
# Production 実行: 可能（本番トラフィックとは別経路のヘルスチェック）

STATE_DIR=/var/lib/ai-router/breaker
FAIL_THRESHOLD=5          # 連続失敗がこの回数に達したら OPEN にする
mkdir -p "$STATE_DIR"

for p in provider-a provider-b; do
  # 軽量なエンドポイントを使う。本番の推論リクエストで死活を測らない
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 "https://$p.example.com/v1/models")
  fails=$(cat "$STATE_DIR/$p.fails" 2>/dev/null || echo 0)

  case "$code" in
    200)
      fails=0
      ;;
    429)
      # レート制限は「プロバイダは生きている」。切り離さずバックオフとキューイングで受ける
      echo "$p: 429 rate limited -> backoff, do not open breaker"
      ;;
    5*|000)
      # 5xx と接続不能は障害として数える（000 は curl が到達できなかった場合）
      fails=$((fails + 1))
      ;;
    4*)
      # 429 以外の 4xx はこちらのリクエストの問題。切り離しても直らない
      echo "$p: client error $code -> check request, do not open breaker"
      ;;
  esac

  echo "$fails" > "$STATE_DIR/$p.fails"

  if [ "$fails" -ge "$FAIL_THRESHOLD" ]; then
    echo "$p: OPEN -> 新規ルーティングを停止し、次候補へ退避。一定時間後に HALF_OPEN で試行"
  else
    echo "$p: CLOSED (http=$code consecutive_fails=$fails)"
  fi
done