目次を表示する

AI エージェントを動かし続ける ─ 運用工学の地図

Drift ─ モデル / プロンプト / データの 3 種

Drift ─ モデル / プロンプト / データの 3 種

エージェントの最も静かに進む故障が **Drift（ドリフト）**だ。alert は鳴らない、エラーは出ない。ただ評価指標が徐々に / 突発的に劣化する。本章では、Drift の 3 種類（モデル / プロンプト / データ）を実例で整理し、検知と対処を扱う。

3 種類のドリフトの早見表

種類発生源典型症状検知手段
モデルドリフトLLM プロバイダの checkpoint 更新・モデル退役同じプロンプトで違う応答、API エラーpinned snapshot + 回帰スイート
プロンプトドリフトチームの累積編集、cache TTL 退行コスト膨張、品質劣化prompt registry + 自動 eval
データドリフトRAG コーパス更新、入力分布変化retrieval 精度劣化、Router 誤分類PSI / KS / embedding distance

モデルドリフト

2026 の主要事件

Claude Sonnet 4 / Opus 4 の 2026-06-15 retire： API でピン留めしている claude-sonnet-4-0 / claude-opus-4-0 が 6/15 以降エラーを返す。Anthropic は最低 60 日前に通知すると公約しているが、気づかないチームが多いのが現実。

Claude のモデル ID 規則変更：

  • 4.5 までは YYYYMMDD の日付付き snapshot ID
  • 4.6 以降は dateless ながら同じく immutable な pinned snapshot
  • evergreen pointer ではない

GPT-5 → 5.5 移行（2026-04-24）： 単純なモデル slug 差し替えでは済まない。reasoning effort のデフォルト変化、image 処理の挙動変化、prompt 解釈の揺らぎを伴う。GPT-5 系の一部 variant は 2026-07-23 deprecate 予定。

Claude Mythos Preview（2026-04-07）： Project Glasswing で限定配布。public API なし、価格未公表 → 通常本番には使えない。Anthropic 自身は「汎用モデルだがサイバーセキュリティタスクで突出した能力を emergent に示す」と説明（一次ソース: Anthropic Glasswing / Mythos Preview announcement）。「1M context」「12 月 2025 cutoff」など細部スペックは公開情報からは未確認 [要検証]。

対処：3 つの実装ガード

1. Pinned snapshot を必ず使う

# ❌ 悪い：evergreen alias を使う
client.messages.create(model="claude-opus-latest", ...)

# ✅ 良い：immutable な pinned snapshot
client.messages.create(model="claude-opus-4-7-20260321", ...)

evergreen alias を本番で使うと、プロバイダが checkpoint を更新した瞬間に挙動が変わる。production では一切使わないのが原則。

2. Deprecation 通知に対する自動回帰 eval を CI に組む

週次 CI ジョブ：
  1. 公式の deprecation page を fetch
  2. 自社で使っているモデル ID を抽出
  3. deprecation 予定日が 60 日以内なら、Slack に警告
  4. 60 日以内なら、移行 PR を自動起票（人間が決める）

Anthropic / OpenAI はそれぞれ deprecations ページを公開している。それを programmatic に確認する仕組みを CI に組み込む。

3. Managed 環境と API 経由を区別する

環境モデルドリフト影響
Claude.ai / Claude Code（managed）Anthropic 側でモデル選択を吸収 [要検証 細部]
API 経由のあなたのプロダクト自分で対応する必要

managed 環境を使っているチームは「Claude Code の中でモデルが切り替わったから自分も切り替わる」と誤認しがちだが、API を直接叩いているプロダクトは別。

プロンプトドリフト

2026 の象徴的事件：Anthropic prompt cache TTL silent regression

事件の経緯：

  • 2026-03 初頭、Anthropic が prompt cache の default TTL を 1 時間 → 5 分に silent に下げた
  • 気づかないユーザーが続出
  • GitHub issue anthropics/claude-code#46829 が 119,866 API call の解析を報告：
    • 3/8 以降、5 分 tokens が 1 時間 tokens の 5:1 で支配的
    • 3 月単月で 25.9% コスト増
    • Opus で $1,581 / Sonnet で $949 の overpay
  • Anthropic は issue を closed-not-planned で扱い、4/13 The Register 記事ではキャッシュ tweaks が原因ではないと否定

教訓：

  • プロンプトテキストを 1 行も変えていなくても、プロバイダ側のインフラ変更でコストが激変する
  • production で 1 時間 TTL を使うなら、必ず ttl: "1h" を明示指定（default に依存しない）

プロンプトドリフトの一般的な原因

  1. チームの累積編集：プロンプトを少しずつ書き換えて、数ヶ月後にいつの間にか挙動が変わる
  2. モデル checkpoint 更新：プロンプトテキスト不変でも、モデル側の更新で挙動が変わる
  3. 動的コンテンツの混入：タイムスタンプ、message ID が system prompt に含まれると、cache が exact byte match を要求して毎ターン invalidate
  4. Cache infrastructure の変更：上記の 5 分 TTL silent regression のような

Promptops 2026 のベスプラ

✅ Prompt は immutable な versioned artifact として中央 registry に保存
   - Maxim AI / Langfuse / Mirascope / LangSmith / PromptLayer / Braintrust / Adaline
   - git commit と同じ感覚で「変えたら新バージョン」

✅ 変更は PR + 自動 eval が必須 CI
   - main baseline 比 -3% でブロックが業界標準

✅ Canary rollout + feature flag（即時 rollback）
   - 5% トラフィックに新プロンプトを当てて eval

✅ Golden dataset を本番トラフィックから継続成長
   - 「本番で起きた重要なケース」を eval set に取り込む

✅ 日次 drift detection
   - プロバイダ側の checkpoint 更新を捕捉

動的コンテンツのキャッシュ汚染問題

❌ よくある悪い例：
system_prompt = f"""
あなたはアシスタントです。
現在時刻：{datetime.now().isoformat()}  # ← 毎ターン変わる
利用可能なツール：[...]
"""
# → cache は毎ターン invalidate して cache_read=0 になる

✅ 良い例：
# 静的部分（cache 対象）
static_system_prompt = """
あなたはアシスタントです。
利用可能なツール：[...]
"""

# 動的部分は user message に
user_message = f"現在時刻：{datetime.now().isoformat()}\n{user_query}"

データ・入力分布ドリフト

何が起きるか

RAG コーパス更新の invisible decay： コーパスを更新すると embedding 分布がずれる。retrieval の類似度スコアは healthy に見えるのに、retrieval-to-response 間で品質が落ちる。alert は鳴らない。

Router の精度頭打ち： RAGRouter-Bench（query-corpus compatibility を多クラス分類とした）で、best router 43.69%、optimal 60.83%。現行モデルは router にすると精度が頭打ちすることが分かっている。

検知手法

対象推奨手法
連続値特徴PSI（Population Stability Index）/ KS test
カテゴリ値特徴chi-square test
Embedding 分布cosine similarity 分布
LLM 出力embedding ベース or eval スコア

KL divergence は asymmetric なので Arize は対称版の PSI をデフォルトにしている。LLM 出力ドリフトは数値分布より「meaning drift」のため、embedding ベース or eval スコアでの検知が要。

実装パターン

✅ Online drift detection の実装
─────────
1. reference window（baseline）の分布を保存
2. 新規入力を streaming で観測
3. 1 時間ごと / 1 日ごとに新規分布と reference を比較（PSI）
4. PSI > 0.2 なら drift 警告
5. PSI > 0.5 なら deploy block

ツール：
- Arize：drift detection が ML 時代から実装、最も成熟
- Phoenix：OSS 層
- LangSmith：traces 中心、drift 専用は弱い
- Galileo：Luna-2 蒸留 evaluator、$0.02/1M tokens で常時 eval が経済的に成立
  （2026-04 Cisco が買収意向発表）

3 種類の Drift を統合的に運用する

実際の運用では、3 種類をまとめて daily ダッシュボードで見るのが現実的だ。

graph TB
    Daily[Daily Drift Dashboard]
    M[Model Drift<br/>deprecation watch]
    P[Prompt Drift<br/>eval delta vs baseline]
    D[Data Drift<br/>PSI on input distribution]
    A[Alert if any drift > threshold]

    M --> Daily
    P --> Daily
    D --> Daily
    Daily --> A

最低限の Daily check：

  1. モデル退役通知の有無（自動）
  2. プロンプト eval の baseline からの delta（自動）
  3. 入力分布の PSI / KS / embedding distance（自動）
  4. コスト / レイテンシの異常値（自動）

これらが 1 つでも閾値を超えたら、alert + on-call 通知。

❌ アンチパターン：「動いているから問題ない」

症状
─────────
- 月末にコストが想定の 1.5×
- ユーザーから「最近応答が変」とクレーム
- 評価指標が gradually 落ちているが誰も気づかない

根本原因
─────────
- evergreen model alias を本番で使っている
- プロンプトが文書化されていない（誰がいつ何を変えたか不明）
- データドリフトを測っていない
- daily の drift check がない

脱出法
─────────
1. すべてのモデル ID を pinned snapshot に変更
2. プロンプトを registry に移し、変更は PR + eval
3. Drift detection ツール（Arize / Phoenix / Galileo）を導入
4. Daily Drift Dashboard を設置
5. 月次で「今月の drift incident」を振り返る

業務投入の観点で重要な 3 点

  1. モデル ID は immutable な pinned snapshot を使い、deprecation の 60 日通知に対する自動回帰 eval を CI に組む：Sonnet 4 / Opus 4 の 6/15 retire は production を破壊する典型的な締切
  2. Prompt は code でなく versioned artifact として PR + canary + golden dataset で運用する：プロンプトテキスト不変でも model 側の checkpoint で挙動が動く。block 閾値 -3% が業界標準
  3. Daily drift check を 3 種統合：モデル退役通知 + プロンプト eval delta + 入力分布 PSI を 1 つのダッシュボードで

次章への接続

ch4 では、Drift と並んで頻発する運用事故である Cost runawayを扱う。$47,000 / $437 暴走の事例、token budget enforcement、85/10/5 split のモデルルーティング、cache + batch の組み合わせを実装の解像度で扱う。

この章のまとめ

  • 3 種類の Drift：モデル / プロンプト / データ。それぞれ発生源・症状・検知手段が違う
  • Pinned snapshot を本番で必ず使う：evergreen alias は production 禁止
  • **Cache TTL silent regression（2026-03）**は production を直撃する事件。ttl: "1h" を明示
  • Promptops 2026 のベスプラ：versioned artifact + PR + canary + golden dataset、-3% で deploy block
  • Drift detection の手法：連続値は PSI、カテゴリ値は chi-square、embedding は cosine similarity 分布
  • Daily Drift Dashboard で 3 種統合：alert と on-call へ