Apache Spark の救急処置：失敗するジョブを修復する「Medic」

Apache Spark の救急処置：大規模ジョブの失敗を AI が自動修復する「Medic」の実践

Pinterest の Staff Engineer である Draško Proferović 氏が発表した、大規模な Apache Spark ジョブのトラブルシューティングを自動化する AI ツール「Medic」の開発事例は、単なるプロンプトエンジニアリングを超えた、実務レベルでの AI エージェント設計の重要性を示しています。本稿では、初期の試行錯誤から LangGraph を活用したマルチエージェントアーキテクチャへの進化、そして LLM の制約を克服するための具体的な技術的アプローチについて解説します。

単一プロンプトの限界と「Medic」誕生の背景

データプラットフォーム部門でインフラを支えるエンジニアにとって、パートナーチームからのサポート要請は絶え間ないものです。特に Apache Spark や分散システムのトラブルシューティングは難易度が高く、新人にとっては壁が高いのが実情です。また、優先順位が曖昧な状況下で「どのジョブを先に救うか」という判断に人間が時間を割く必要があるのも課題でした。

そこで Pinterest が目指したのは、ユーザーが「なぜジョブが失敗したのか？」と尋ねるだけで、根本原因の証拠に基づいた深い分析レポートと、その文脈に即した修復案を返す AI エージェントの実現です。初期段階では、単一の React（ReAct）エージェントを採用し、一つのプロンプトで問題解決のアプローチや回答形式を定義するアプローチが取られました。

しかし、この「万能プロンプト」方式には致命的な欠陥がありました。

プロンプトの調整が非効率になり、ある部分の詳細化が別の部分の挙動を悪化させるというトレードオフに直面しました。また、分析が浅すぎたり冗長になったりして品質が不安定でした。

さらに、本番環境での大規模ジョブでは、ログ出力の巨大さが LLM のコンテキストウィンドウ（記憶容量）を瞬時に埋め尽くし、推論プロセスを停止させる問題が発生しました。手動テストに依存していた評価体制も、本番データの保存期間が限られるため、変更が以前の成果を壊していないかを確認するのが困難でした。

ノイズの除去と信号強化：ログとメトリクスの扱い方

システム改善のために Pinterest が最初に着手したのは、観測可能性（Observability）とテスト基盤の整備です。OpenTelemetry を活用してエージェントの実行トレースを可視化し、質の低い回答の原因を特定しました。その上で、ログとメトリクスという「ノイズ」をどう処理するかが診断精度を分ける鍵となりました。

ログからの不要情報のフィルタリング

Spark のログには多くの例外が含まれていますが、その多くは成功するジョブでも発生する無害なものです。単に最後の例外だけを見るアプローチでは、誤った原因特定（アンカー効果）に陥るリスクがありました。

Pinterest は、ヒューリスティックな正規表現フィルタリングから脱却し、「例外分類パイプライン」を構築しました。この仕組みは以下の手順で動作します。

1. 学習: 成功するジョブで頻出する例外パターンを学習し、「レッドヘリング（誤った手がかり）」として特定する。
2. クラスタリング: エージェントが例外に指紋情報を付け、クラスタリングしてランク付けを行う。
3. フィルタリング: コンテンツの関連性と、ジョブ終了直前に発生したかという時間軸を基準に、重要な例外のみを抽出する。

これにより、エージェントは生のログを直接読み込むのではなく、「上位 K 個の切り捨てられた例外」や「特定の例外の詳細」というツールを通じて情報を取得します。その結果、信号対ノイズ比が大幅に向上し、誤った原因特定を防ぐことができました。

メトリクスの画像化によるコンテキストウィンドウ対策

時系列メトリクスデータをそのまま LLM に渡すのは、トークン効率が悪く、長期間稼働するジョブでは機能しません。Pinterest はこの課題に対し、「隔離されたサブエージェント」を設けて解決しました。

1. 分析: サブエージェントが生の時系列データを解析し、グラフとして可視化する。
2. 画像化: 解析結果を Grafana ダッシュボード風の画像にコラージュする（最小値・最大値などの注釈付き）。
3. 提示: この画像を LLM の会話コンテキストに添付する。

LLM は数値の羅列ではなく、視覚化されたパターン（例：エグゼキュータがゼロになる、ボトルネックによる長時間の停滞など）を認識して推論を行います。これにより、ジョブの稼働時間に関わらず、分析に使用するトークン数を一定に保ちながら、リソースの不整合な挙動を検出できるようになりました。

テスト基盤の確立と品質の定量化

AI エージェントの開発において、変更が既存機能を壊していないかを確認するのは困難です。Pinterest は、本番環境への依存を減らし、品質を定量化するために「エンドツーエンドテストハッチ」を構築しました。

この仕組みは以下の 2 つのモードで動作します。

• 記録モード（Record Mode）: エージェントが実際の下流システムを呼び出し、そのレスポンスを固定ファイル（Fixture）として保存します。これをコードベースにコミットすることで、再現可能なテストデータセットを作成します。
• 再生モード（Playback Mode）: エージェントは本番データではなく、保存された Fixture を対象に分析を実行し、レポートを生成します。

生成されたレポートは、事前に定義した「オフライン評価（Offline Evals）」によって自動採点されます。例えば、「修復案は 3 つまでに抑える」というルールがあれば、それを超えた回答には低スコアが付与され、冗長性の制御が図れます。このテストスイートの導入により、直感や経験則に頼らず、変更による品質の低下を即座に検知できるようになりました。

マルチエージェントアーキテクチャへの進化

最終的に Pinterest は、単一の React エージェントから、専門役割を持つマルチエージェントアーキテクチャへと移行しました。この設計は、LangGraph のディープエージェントライブラリを活用して実現されています。

各エージェントには専用のプロンプトと MCP ツールのサブセットが割り当てられ、以下のような役割分担が行われています。

1. トライアージ（Triage）エージェント: ユーザーの意図を分類し、ジョブの状態を判断。失敗している場合は、失敗仮説を生成する。
2. リサーチ（Research）エージェント: 並列に各仮説を検証し、証拠を集めてスコアリングと根本原因の特定を行う。
3. スーパーバイザー（Supervisor）エージェント: 最も信頼性の高い根本原因を選択し、ベクトルデータベースから取り込んだランブックに基づいて修復案を提案する「ヒーラー」エージェントを起動。最終レポートを組み立てる。

このアーキテクチャの最大の利点は、「単一プロンプトの分解」にあります。各役割が明確に分離されたことで、開発者は個別のプロンプトを保守しやすくなり、テストも焦点を絞って行えます。また、プロジェクトの範囲拡大（例：Spark SQL の最適化支援）も、新しいエージェントを追加するだけの簡単な作業となりました。

まとめ

Pinterest の「Medic」事例は、大規模分散システムにおける AI エージェントの実用化において、単なるプロンプト調整ではなく、「ノイズ除去」「コンテキストウィンドウの制約克服」「堅牢なテスト基盤」という 3 つの要素を体系的に設計することが不可欠であることを示しています。LLM の限界を技術的な工夫で補い、人間が判断するべき優先順位付けや複雑な推論を AI に委ねることで、インフラサポートの質と速度は劇的に向上します。

今後は、このパターンを Flink や Trino などの他の分散システムへ拡張し、さらにユーザーフィードバックを活用した自動改善にも取り組む予定とのことです。これは、エンタープライズレベルでの AI 導入における標準的なベストプラクティスとして確立される可能性を秘めています。