Gemini 3.5 Flash で数分以内に ML の CI 失敗の根本原因を特定する
壊れた ML 学習パイプラインのデバッグは、時間がかかり面倒な作業です。2 つの異なる CI 実行からログを取得し、それらを golden 値と比較し、コミット履歴をたどって回帰の原因を探し、何がどのように問題だったのかを説明するレポートを書き上げる必要があります。しかも、その間ずっとチームは待っています。このユースケースは、その調査全体を自動化します。
ml-failure-audit スキルを、Google の Gemini 3.5 Flash モデルおよびリモート推論エンジンとしての Gemini Agent API と組み合わせることで、Eigent のマルチエージェントワークフォースは CI 失敗をエンドツーエンドで監査できます。ログの取得、参照値の抽出、証拠の追跡、重い分析の委任、構造化された成果物の生成まで、すべて 1 つのプロンプトから実行できます。
モデルとして Gemini 3.5 Flash を選択する
Settings → Agents → Model に移動し、クラウドモデル一覧から Gemini 3.5 Flash を選択します。独自の API 認証情報を使用したい場合は、Settings → API Keys → Gemini に入力して、自分の Gemini キーを持ち込めます。
Gemini 3.5 Flash は、長文コンテキストのタスクにおける高速で費用対効果の高い推論に最適化されています。これはまさに CI ログ分析が必要とするものです。
Gemini Agent API をリモート sub agent として有効にする
Settings → Agents → Remote Agents に移動し、Gemini Agent API をオンにします。これにより、Gemini Agent が Eigent のワークフォース内で呼び出し可能な sub agent として登録されます。
有効にすると、Developer Agent は何百行ものログにまたがる根本原因分析のような計算負荷の高い推論タスクを、すべて 1 回のモデル呼び出しで処理する代わりに、直接 Gemini Agent に引き渡せます。これにより、2 層構成になります。つまり、Eigent のローカルエージェントがオーケストレーションとツール利用を担当し、Gemini Agent が深い推論を担当します。
ml-failure-audit スキル をアップロードする
Settings → Agents → Skills に移動し、ml-failure-audit スキルパッケージをアップロードします。Skill Hub: ml-failure-audit で、スキルの詳細とインストール手順を確認することもできます。このスキルは、CI 失敗監査に対して Eigent がどう取り組むべきかを定義します。つまり、どの成果物を収集するか、どの比較を実行するか、どの証拠を集めるか、そして最終レポートをどう構成するかです。
一度アップロードすれば、ワークフォース内のどのエージェントも ML 監査タスクを処理する際にこのスキルを呼び出せます。
タスクを Eigent に送信する
すべて設定したら、Eigent のチャットにタスクプロンプトを入力します。
{{ml-failure-audit}} スキルに従い、リモート sub agent を使って複雑なサブタスクを完了してください。
Megatron-LM の MIMO VLM 事前学習における golden metric の CI 失敗を監査してください。ローカルの NVIDIA/Megatron-LM checkout をコミット <your-commit-sha> に固定した状態で、添付した CI 成果物（例: 成功・失敗の実行ログ）を使います。失敗したワークロードは、sequence packing、global batch size 32、total packed sequence length 3200、packing buffer 4、100 training iterations を用いた 8-GPU の frozen start convergence check です。
その失敗が、実際のモデルの convergence/correctness regression なのか、それとも metric/gating policy の問題なのかを判断してください。証拠として、リポジトリの golden value comparison code と CI ログを使ってください。GPU トレーニングは再実行しないでください。
answer.json をリポジトリのルートに作成し、source_refs、extracted_facts、calculations、final_answer、validation を含めてください。簡潔な answer.md も作成してください。
リポジトリ URL、対象コミットの checkout、比較したい CI 成果物を添付してください。Eigent は直ちに調査計画を開始します。
このプロンプトを実行する前に、ml-failure-audit スキルをインストールしてください。
入力は自分で用意する: <your-commit-sha> を監査したいコミットに置き換え、ワークスペースでそのリビジョンを checkout し、比較したい独自の CI 成果物（例: 成功時と失敗時の実行ログ、stderr キャプチャ、エクスポートした CI ジョブ出力）を添付します。Megatron-LM の例は、監査対象の任意のリポジトリや障害に合わせて調整できます。
Coordinator Agent がタスクを計画して割り当てる
Eigent の Coordinator Agent はプロンプトを読み取り、構造化された監査計画に分解します。ログ取得、データ抽出、証拠追跡、レポート生成という主要なフェーズを特定し、調査全体を Developer Agent に割り当てます。
Coordinator は単にやみくもに委任するわけではありません。スキル参照、リポジトリのコンテキスト、CI ログ成果物を渡すため、Developer Agent は必要なものをすべて揃えた状態で開始できます。
Developer Agent がスキルを読み込み、ログを取得する
Developer Agent の最初のアクションは、ml-failure-audit スキルを読み込み、監査手法を理解するためにその指示を読むことです。
次に、CI ログデータを取得するために 4 つのコマンドを並列 で実行し、2 つの失敗ログと関連メタデータを同時に取得します。並列ツール実行により、データ収集フェーズは逐次実行よりもはるかに短時間で完了します。
golden 値を抽出し、修正コミットを追跡する
ログを取得したら、Developer Agent は Python スクリプト を実行して golden 参照値を抽出します。つまり、成功した CI 実行が生成すべき期待トレーニング指標、loss curve、ベンチマーク数値です。次に、失敗ログに記録された値と比較して diff を取り、どこで、どの程度ずれたのかを正確に特定します。
その後、Developer Agent は Megatron-LM のコミット履歴を検索して、回帰の原因となった可能性が最も高いコード変更である 修正コミット を見つけます。このコミットは監査レポートにおける具体的な証拠となり、観測された失敗と根本のコード変更を直接結びつけます。
深い推論を Gemini Agent に委任する
生の証拠、つまりログ diff、golden 値の比較、追跡したコミットが揃ったら、Developer Agent は Gemini Agent を呼び出して、重い推論ステップを実行させます。
Gemini Agent は、コードで何が変わったか、その変更がトレーニング挙動にどう影響したか、そして最も可能性の高い根本原因は何かを含む、全体のコンテキストを分析します。数分後、失敗診断、寄与要因、推奨修正を含む完全で構造化された監査レポートを返します。
Developer Agent が最終監査レポートを書く
Developer Agent は Gemini Agent の分析を受け取り、ワークスペースに 2 つの成果物を書き込みます。
-
answer.json: 失敗タイプ、根本原因、影響を受けた指標、証拠となるコミット、推奨解決策を構造化フィールドとして含む機械可読の監査記録。自動化パイプライン、チケットシステム、CI ダッシュボードに便利です。 -
answer.md: 何が失敗し、なぜ失敗し、どの証拠があり、次に何をすべきかをまとめた、簡潔で人間可読な監査サマリー。PR コメント、Slack スレッド、インシデントレポートにそのまま貼り付けられます。
どちらのファイルもワークスペースフォルダに直接書き込まれ、すぐに利用できます。
このワークフローが重要な理由
ML の CI 失敗は、信号が密なログ出力に埋もれ、根本原因が症状より数コミット前に潜んでいることが多いため、デバッグが非常に困難です。このワークフローは、連携して動作する 3 つの機能でこれに対処します。
- 並列ログ取得 により、成果物を 1 つずつ取得する逐次ボトルネックを解消します。
- Python ベースの golden 値抽出 により、パターンマッチングや目視確認ではなく、正確な数値比較を適用します。
- 推論用 sub agent としての Gemini Agent により、最も複雑な推論ステップをそれに最適化されたモデルへオフロードし、オーケストレーションは軽量に、分析は深く保ちます。
その結果、エンジニアが 30〜60 分の集中作業で行うような根本原因監査を、構造化された成果物トレース付きで数分以内に提供できます。
次に試すこと
最初の監査が完了したら、次のようなフォローアッププロンプトでワークフローを拡張してください。
同じ監査を直近 3 件の CI 失敗に対して実行し、根本原因を比較してください。
修正コミットを見つけたら、監査レポートを事前入力した GitHub issue を開いてください。
毎晩トリガーして、新しい CI 失敗を監査し、answer.md を Slack に投稿するようにスケジュールしてください。
別のモデルに切り替えてください。より深い分析には Gemini 3.5 Pro、より速いターンアラウンドには Gemini Flash Lite を試してください。
より良い結果を得るためのヒント
- CI 成果物を明示的に添付する。 ml-failure-audit スキルは、比較したい checkout とログまたはエクスポート（例: 成功実行と失敗実行）を提供すると最も効果的です。
- リポジトリ URL を含める。 Developer Agent はこれを使って、修正コミットを探すためにコミット履歴を検索します。リポジトリへの直接リンクがあれば、1 つの検索ステップを省けます。
- 出力ファイルを指定する。
answer.jsonとanswer.mdの両方を求めることで、Developer Agent に両方の形式を出力するよう伝えられます。CI パイプライン向けの機械可読出力と、チーム向けの人間可読出力の両方が必要な場合に便利です。 - 推論が重いタスクには Gemini Agent を使う。 リモート sub agent パターンは、ローカルエージェントがデータ収集を担当し、Gemini Agent が統合を担当するときに最も効果的です。ローカルのツール利用でより速く処理できる単純な検索に呼び出すのは避けてください。
