AP-07: Feedback Loop Starvation｜フィードバックループの飢餓¶

一言で（TL;DR）¶

本番環境からユーザーフィードバック、エラーログ、レイテンシメトリクス、人間による修正履歴を収集しているにもかかわらず、それらをモデル選定・プロンプト調整・閾値変更・評価セット更新に還流させるパイプラインが存在しない――エージェントがDay-1の構成で凍結されたまま本番の変化に追従できなくなるアンチパターンです。

なぜ陥るのか（誘引）¶

エージェントの初期構築は刺激的です。プロンプトを試行錯誤し、ツールを接続し、デモで動くものを見せる段階ではチームのモチベーションは高い。しかしローンチ後の「改善ループ」は地味な作業です。評価データセットの更新、閾値の微調整、プロンプトのバージョン管理、本番データからの学習――いずれもユーザーに直接見える新機能ではありません。

さらに、改善ループの責務はプロダクトチーム（何を改善すべきか）、MLチーム（どう改善するか）、Opsチーム（データをどう収集するか）の3者にまたがり、誰が主導するかが曖昧になりがちです。結果、全員が「誰かがやっている」と思い、誰もやっていない状態に陥ります。

MLOps文化の不在も大きな要因です。従来のWebアプリケーション開発では「デプロイしたら終わり」が成立しますが、確率的なシステムでは本番環境の変化（ユーザーの行動変容、入力パターンの季節変動、プロバイダ側のモデル更新）に追従し続ける必要があります。この根本的な違いを組織が理解していないと、改善パイプラインの予算と人員が割り当てられません。

最後に「十分に動いている」という認知バイアスもあります。目立つ障害が起きなければ劣化は気づかれにくい。コサイン類似度が0.01下がった、ハルシネーション率が2%上がった、といった緩やかな品質低下はユーザーの「なんとなく使いづらくなった」という定性的な感想として現れ、定量的に検知されないまま放置されます。

典型的な症状¶

本番データベースに「user_feedback」テーブルが存在し、レコードは増え続けているが、最後にそれを分析したのが3か月以上前。
ゴールデンデータセットがローンチ時のまま更新されておらず、評価スコアは常に高い（本番の実態と乖離している）。
プロンプトのバージョン管理はされているが、変更の根拠となるデータが「開発者の直感」しかない。
プロバイダがモデルを更新した際に品質劣化が発生するが、ユーザーからの問い合わせで初めて気づく。
「改善バックログ」に大量のチケットが積まれているが、常に新機能の優先度が上で着手されない。

発生メカニズム¶

flowchart TD
  subgraph 本番環境
    Agent[エージェント<br/>Day-1構成で凍結]
    Users[ユーザー]
    Users -->|リクエスト| Agent
    Agent -->|応答| Users
  end

  subgraph データ収集層（存在する）
    Agent -->|ログ| Logs[エラーログ<br/>レイテンシメトリクス]
    Users -->|フィードバック| FB[ユーザーフィードバック<br/>thumbs up/down]
    Agent -->|トレース| Traces[実行トレース]
  end

  subgraph 改善パイプライン（存在しない）
    Logs -.->|未接続| Analysis[分析・集約]
    FB -.->|未接続| Analysis
    Traces -.->|未接続| Analysis
    Analysis -.->|未構築| Actions[改善アクション]
    Actions -.->|未実装| PromptUpdate[プロンプト更新]
    Actions -.->|未実装| ThresholdTune[閾値調整]
    Actions -.->|未実装| EvalUpdate[評価セット更新]
    Actions -.->|未実装| ModelSwitch[モデル選定]
  end

  subgraph 外部変化
    ModelDrift[プロバイダのモデル更新<br/>F9]
    UserDrift[ユーザー行動の変化]
    SeasonalDrift[季節変動・新パターン]
  end

  ModelDrift -->|影響| Agent
  UserDrift -->|影響| Agent
  SeasonalDrift -->|影響| Agent

  style Analysis fill:#f99,stroke:#c00
  style Actions fill:#f99,stroke:#c00
  style PromptUpdate fill:#f99,stroke:#c00
  style ThresholdTune fill:#f99,stroke:#c00
  style EvalUpdate fill:#f99,stroke:#c00
  style ModelSwitch fill:#f99,stroke:#c00

点線で示された「改善パイプライン」が存在しないか、存在しても実行されていないことがこのアンチパターンの核心です。データは収集されていますが、アクションに変換される経路がありません。

時間の経過とともに外部変化が蓄積し、Day-1構成と現実の乖離が広がり続けます。初期は小さな差分ですが、モデルドリフト（F9）、ユーザー行動の変化、季節変動が重なると、ある時点で品質が急激に劣化したように見えます。実際には緩やかに劣化していたものが閾値を超えただけです。

駆動変数による重症度（程度）¶

駆動変数	値が高いとき（重症）	値が低いとき（軽症）
`task_variability`	タスクが多様で入力パターンが変化し続けるため、固定構成では追従不能。ユーザーが新しい使い方を発見するたびに品質が低下する	定型タスクでは入力パターンが安定しており、Day-1構成でも長期間耐えられる場合がある
`failure_cost`	誤りが金銭損失・法的リスク・安全問題に直結するため、緩やかな品質劣化でも実害が大きい。気づいたときには被害が蓄積している	誤りの影響が限定的（提案を人間が確認する場合など）で、品質劣化が致命的でない
`cost_sensitivity`	コスト最適化のためにモデルルーティングや閾値を継続的に調整する必要があるが、フィードバックなしには最適化できない。初期設定のまま不必要に高コストなモデルを使い続ける	コストが十分に低い、または予算に余裕があり、最適化の緊急性が低い
`provider_trust`	プロバイダの信頼度が低い（頻繁にモデル更新がある）場合、フィードバックなしではドリフトを検知できない	プロバイダが安定しており、モデル更新が稀な場合は影響が小さい

具体的シナリオ¶

ある EC サイトが顧客対応チャットボットをリリースしました。初期構築時に200件のゴールデンデータセットを作成し、GPT-4oで90%の正答率を達成。プロンプトは丁寧に設計され、返品・交換・在庫確認・配送状況照会の4カテゴリをカバーしています。ローンチ時のユーザー満足度は高く、チームは次のプロジェクトに移りました。

# Day-1 の構成（6か月間変更なし）
AGENT_CONFIG = {
    "model": "gpt-4o-2024-05-13",
    "temperature": 0.3,
    "system_prompt": PROMPT_V1,  # ローンチ時のバージョン
    "similarity_threshold": 0.92,  # キャッシュ閾値
    "max_context_tokens": 4000,
    "feedback_table": "user_feedback",  # テーブルは存在する
    # feedback_pipeline: なし
    # eval_schedule: なし
    # drift_detection: なし
}

3か月後、EC サイトは新しいサブスクリプションサービスを開始しました。ユーザーは「サブスクの解約方法」「次の請求日」「プラン変更」について質問し始めます。しかしプロンプトにはサブスクリプションに関する指示がなく、エージェントは返品ポリシーのコンテキストでサブスクの質問に回答し、誤った情報を提供し始めます。

同時期にプロバイダがモデルを gpt-4o-2024-08-06 に更新しました。微妙な挙動変化により、以前は正しく動作していた在庫確認のツール呼び出しパターンが変わり、成功率が95%から82%に低下しました。しかしチームはこの変化に気づいていません。

ユーザーフィードバックのテーブルには「thumbs down」が増加しています。カスタマーサポートチームからは「チャットボットの品質が落ちた気がする」という定性的な報告が上がっていますが、定量的なデータがないため優先度が判断できず、バックログの下の方に積まれています。

6か月後、競合他社がより優れたチャットボットをリリースし、自社の顧客満足度調査で大幅な低下が検出されてようやく本格的な調査が始まります。そこで初めて、フィードバックテーブルの分析、ゴールデンデータセットの再評価、プロンプトの更新が行われますが、6か月分の「改善の機会損失」は取り戻せません。

事後の分析で判明した事実を整理します。

# 事後分析で判明した本番データの実態
POST_MORTEM = {
    "feedback_records_total": 45000,      # 6か月で蓄積されたフィードバック
    "feedback_records_analyzed": 200,      # ローンチ時に一度だけ分析
    "thumbs_down_rate_month1": 0.08,      # 8% → 許容範囲
    "thumbs_down_rate_month6": 0.23,      # 23% → 深刻だが気づかれなかった
    "subscription_queries_month3": 1200,   # 新カテゴリ → プロンプト未対応
    "subscription_queries_accuracy": 0.31, # 31% → 大半が誤回答
    "tool_success_rate_before_drift": 0.95,
    "tool_success_rate_after_drift": 0.82, # モデルドリフトで13%低下
    "golden_dataset_last_updated": "2024-01-15",  # ローンチ日
    "prompt_last_updated": "2024-01-15",           # ローンチ日
}

もしフィードバック→アクションのパイプラインが動いていれば、thumbs down率の上昇は1か月目で検知され、サブスクリプション対応は3か月目に、モデルドリフトはシャドウ評価で即座に検知されていたはずです。データは全てそこにありました。消費する仕組みだけが欠けていたのです。

処方箋¶

1. フィードバック→アクションパイプラインを明示的に設計する¶

データ収集は手段であり目的ではありません。収集したデータが具体的にどのアクションに変換されるかを設計時に定義します。

データソース	アクション	頻度	オーナー
ユーザーfeedback（thumbs up/down）	ゴールデンデータセット更新、プロンプト改善の優先度付け	週次集計	プロダクトチーム
エラーログ・ツール失敗	リトライ閾値・フォールバック設定の調整	日次アラート	Opsチーム
レイテンシメトリクス	タイムアウト・キャッシュ閾値の調整	週次レビュー	Opsチーム
本番出力サンプル	評価セット拡充、ハルシネーション率計測	週次	MLチーム
モデル更新通知	シャドウ評価の即時実行	イベント駆動	MLチーム

2. G4 Eval Harness を導入する¶

本番データから自動的に評価セットを拡充し、定期的に回帰検知を行う仕組みを構築します。ゴールデンデータセットは生きたドキュメントであり、本番の変化に追従して更新されるべきです。

3. G1 Tiered Observability で構造化データを収集する¶

フィードバックループの入力となるデータが構造化されていなければ、分析もアクション変換もできません。二層観測により、必要なメトリクスとトレースを適切な粒度で収集します。

4. 改善ループにSLOを設定する¶

「ゴールデンデータセットは月1回以上更新される」「本番フィードバックの分析レポートは週次で生成される」「モデル更新後24時間以内にシャドウ評価が完了する」といったSLOを設定し、改善ループ自体を監視対象にします。

5. マイグレーションパス¶

Day-1凍結状態から改善ループが回る状態への段階的な移行：

週1（即座に）：本番フィードバックの集計ダッシュボードを作成。thumbs down率、エラー率、レイテンシP95を可視化。
週2-3：ゴールデンデータセットに本番の失敗ケースを20件追加。G4 Eval Harness の最小構成で週次評価を開始。
月1-2：フィードバック→アクションのパイプラインを1つ（最も影響の大きいもの）だけ構築。例：thumbs downの多いカテゴリのプロンプトを自動で優先度付けしてチケット化。
月2-3：モデルドリフト検知を導入。プロバイダの更新通知をトリガーにシャドウ評価を自動実行。
月3以降：フルサイクル。本番データ→分析→改善→評価→デプロイのループが自動化されている状態。

コーディングエージェント向け検出指示（machine-actionable）¶

以下のチェックリストでこのアンチパターンの兆候を検出してください。

[ ] 本番環境にフィードバック収集の仕組み（テーブル、キュー、ログ）は存在するが、それを消費するバッチジョブ・パイプライン・スケジュールタスクが存在しない。
[ ] ゴールデンデータセット（評価用データ）の最終更新日がローンチ日から変わっていない、または3か月以上前。
[ ] プロンプトのバージョン履歴で、変更の根拠（どの本番データに基づくか）が記録されていない。
[ ] モデルバージョンがピン留めされておらず、プロバイダの更新後に品質を検証するジョブが存在しない。
[ ] 閾値（キャッシュ類似度、ガードレール、リトライ上限など）が初期値から一度も変更されていない。
[ ] CI/CDパイプラインにエージェント品質の評価ステップが含まれていない。
[ ] 改善に関するバックログチケットが存在するが、すべて「未着手」のまま3か月以上経過している。
[ ] G4 Eval Harness が未導入、または導入されているが定期実行が停止している。

検出した場合の提案順序：

まず G1 Tiered Observability でデータ収集層を整備する。
次に G4 Eval Harness で評価パイプラインを構築する。
フィードバック→アクションのマッピングを設計し、最も影響の大きい1つから着手する。
改善ループのSLOを設定し、ループ自体の健全性を監視する。