Netflix Technology Blogが「Making Failure Diagnosis Reliable with Pensive AI」と題した記事を公開した。Netflixのデータ基盤における障害診断システム「Pensive AI」の設計と、AIを決定論的プロセスで包む信頼性確保の手法について詳しく紹介している。
ピーク時に1日10万件の失敗をどう捌くか
Netflixでは、データエンジニアやMLプラクティショナーがTitus、Spark、Trino、Druidといった基盤上で毎日数百万のワークロードを実行している。ピーク日には約10万件のワークロードが失敗する。失敗そのものより問題なのはその後だ。エンジニアは大量のログから有用なシグナルを拾い、コード起因かプラットフォーム起因かを判断し、リトライすべきか設定を変えるべきかを決めなければならない。
その課題に対する最初の回答がPensiveだ。正規表現と手書きのJavaルールで失敗を分類し、ワークフローオーケストレーターMaestroにリトライ・修復の指示を渡す仕組みで、約50%の失敗をセルフサービス化した。
しかし3ヶ月間で処理した約700万件の失敗分類のうち、半数近くが"unknown"バケットに落ちた。新しい失敗パターンに対してルールを書き続けるのは限界がある。そこで投資したのがPensive AIだ。
設計の核心：AIをルールで挟む
Pensive AIの最大の特徴は「AIをそのまま使わない」点にある。記事の著者であるPraneeth Yenugutalaらが強調するのは、AIを決定論的なプロセスで包むという設計方針だ。
ログをLLMに「全文コピーさせない」エラー抽出
LLMに長いスタックトレースをそのまま出力させると、遅くてコストもかかる。Pensive AIの解法はシンプルだ。ログの各行に行番号を付与し、{行番号, テキスト}のレコード列としてモデルに渡す。モデルはエラースパンの開始行と終了行の2つの整数だけを返す。実際のログテキストはPensiveが手元のログコピーから再構築する。
これにより：
- エラーが数行でも数百行でも、モデルの出力は常に「整数2つ」
- 表示コンテンツはオリジナルログから直接取得するためハルシネーションが混入しにくい
- レイテンシとコストが大幅に削減される
抽出はMaestroのステップ失敗時に自動実行される。Maestroのハードタイムアウトは90秒で、Pensive AIの各ログ抽出呼び出しはこの制限内に収まるよう共有デッドラインを設定している。デッドラインを超えた呼び出しは結果から除外され、全体のレスポンスは必ず時間内に返る。
既存クライアントを壊さないデータモデルの移行
旧Pensiveのデータモデルはエラーを1つのフラット文字列で持っていた。Pensive AIはログソースごとのエラーリストと元ログへのディープリンクを返す新しいモデルに移行した。既存フィールドを上書きすると既存クライアントが壊れるため、新旧両フィールドを並行して生成し続ける方式を採用している。UIは新フィールド優先・フォールバックで新旧を吸収し、各クライアントが自分のペースで移行できる設計だ。
オンデマンドデバッグのキャッシュ戦略
エラー抽出が「常時オン・高速」なのに対し、より深い根本原因分析（RCA）はオンデマンドで提供される。生成に数十秒〜1分かかるため、全失敗に自動実行するとコストが膨大になる。ほとんどの失敗ステップは誰も開かないからだ。
キャッシュの単位は「ステップ試行（step attempt）」、つまり人ではなくワークロードの実行インスタンスだ。同じ失敗ステップを複数人が調査しても、LLM推論は1回しか走らない。2回目以降はキャッシュのキー・バリュー読み取りになる。さらに、Data PortalのUIで生成した結果は、MCP（Model Context Protocol）——LLMが外部ツールやデータソースと連携するためのオープンプロトコル——経由のアクセスでも即座に再利用される。
同一ステップへの並行リクエストには条件付き書き込みでクレームを取り合い、先勝ちした1つのプロセスが生成を担当し、他は結果を待つ。生成中にクライアントが切断しても生成はキャンセルされず、完了結果はキャッシュに保存される。レスポンスの有効期限は90日で、古いワークロードへのリクエストが少ないことを踏まえたコスト最適化だ。
評価フレームワーク：「動くデモ」では不十分
LLMを本番に投入する際の最大の課題は評価の継続性だ。Pensive AIでは4つの指標を測定している：
- Inclusion（網羅性）：旧Pensiveが検出していたエラーがAI抽出にも含まれているかをLLMジャッジで判定
- Precision（精度）：抽出されたエラーが単体で意味のある情報かどうか
- Repeated noise（反復ノイズ）：データセット全体で30%以上のワークフローに出現する汎用的な行を候補としてフィルタリング（実際に除外リストに載ったのは3行のみ）
- Latency（レイテンシ）：品質スコアだけでは見えないコスト増を検出するため
評価用の入力ログは本番リクエスト時に非同期でS3にアーカイブしており、ユーザー向けのクリティカルパスには乗らない。ログは最短7日・最長30日で期限切れになるため、評価再現性を確保するためのアーカイブは設計上の必須要件だった。
現時点の成果
- AIエラー抽出が全失敗の100%をカバー（旧Pensiveがunknownとした失敗を含む）
- Pensive AIを使わなかったステップ失敗では、使ったものと比べて手動デバッグログ探索アクションが平均321%多かった——元記事はこれをPensive AIの有用性を示す観察値として報告しており、利用傾向と行動量の相関として読むのが適切だ
記事はさらに、MCPを通じたエージェント的なデバッグ体験の展開についても言及しており、今後の方向性として「より自律的なデバッグ」を示唆している。
詳細はMaking Failure Diagnosis Reliable with Pensive AIを参照していただきたい。
