Google「Auto-Diagnose」発表、テスト失敗を自動診断

Google「Auto-Diagnose」発表、テスト失敗を自動診断 業務効率化・自動化

統合テストの診断に何時間かけていますか?

フリーランスのエンジニアなら、誰もが経験したことがあるはずです。統合テストが失敗して、原因を探すために何時間もログファイルとにらめっこする時間です。Googleの調査では、開発者の38.4%が統合テスト失敗の診断に1時間以上、8.9%は丸一日以上を費やしているとのこと。ユニットテストなら2.7%しか1時間以上かからないのと比べると、この差は歴然です。

実際、統合テストの失敗診断は難しいものです。テストドライバーのログには「タイムアウト」や「アサーション失敗」といった症状しか表示されず、本当のエラーはシステム内のどこかのコンポーネントログに埋もれています。しかも、回復可能な警告やERRORレベルのログが大量にあって、本当の原因を見つけるのは至難の業です。

Auto-Diagnoseの仕組み

Auto-DiagnoseはGemini 2.5 Flashモデルを使っています。特徴的なのは、ファインチューニングを一切せず、プロンプトエンジニアリングだけで実現している点です。システムは失敗したテストのログを読み取り、データセンター、プロセス、スレッド間の情報を集約して、タイムスタンプ順に並べ替えます。

診断プロセスは明確なステップに分かれています。まずログをスキャンし、関連するコンポーネントのコンテキストを読み取ります。次に障害箇所を特定し、エラーを要約して、最終的な結論を出します。面白いのは、「該当するコンポーネントのログラインが含まれない場合は結論を出さない」という厳格なルールが組み込まれている点です。これによって、曖昧な推測を避けています。

出力はマークダウン形式で、「Conclusion(結論)」「Investigation Steps(調査手順)」「Most Relevant Log Lines(最も関連性の高いログライン)」の3つのセクションに分かれています。引用されたログラインはクリック可能なリンクになっているので、すぐに元のログを確認できます。

実際の運用データが示す効果

Auto-Diagnoseは2025年5月から本番環境で運用されており、既に実績があります。Googleの39の異なるチームで使われていて、これまでに52,635個の異なる失敗テストで実行され、224,782回の診断を行ってきました。関わった開発者は22,962人にのぼります。

精度については、71件の実世界の失敗を手動評価したところ、根本原因の特定精度は90.14%でした。また、ユーザーフィードバックを見ると、517件の総フィードバックのうち84.3%が「Please fix(これで修正します)」という最も肯定的な反応です。「役に立たない」というフィードバックは5.8%に留まっています。

Google内部のコードレビューシステム「Critique」には370個のツールが結果を投稿していますが、Auto-Diagnoseは有用性で14位、つまり上位3.78%に入っています。新しいツールとしては、かなり高い評価です。

失敗から学んだこと

興味深いのは、Auto-Diagnoseが診断に失敗した7件のケースです。そのうち4件はテストドライバーログが保存されておらず、3件はシステムコンポーネントログが保存されていませんでした。この失敗が、実はインフラストラクチャの実際のバグを発見するきっかけになり、関連チームに報告されています。約20件の「より多くの情報が必要」という診断が、インフラストラクチャ問題を明らかにするのに役立ったそうです。

フリーランスエンジニアへの影響

残念ながら、Auto-DiagnoseはGoogle内部のシステムなので、私たち外部の開発者が直接使うことはできません。ただ、このアプローチ自体は非常に参考になります。特に、ファインチューニングなしでプロンプトエンジニアリングだけで90%超の精度を実現している点は注目です。

フリーランスとして複数のプロジェクトを抱えていると、デバッグに費やす時間はそのまま収益機会の損失になります。統合テストの診断に1時間かかっていたものが10分で済めば、その分だけ他の仕事に時間を使えます。時給換算で考えれば、この差は大きいです。

現時点では同等のオープンソースツールは見当たりませんが、Gemini 2.5 FlashのAPIは一般にも公開されています。Auto-Diagnoseの論文やアプローチを参考に、自分のプロジェクト向けに簡易版を作ることは可能かもしれません。特に、特定のフレームワークやテスト環境で繰り返し同じような失敗に遭遇する場合は、プロンプトテンプレートを作っておくだけでも効果がありそうです。

もう一つの学びは、LLMを使った自動化では「明確なステップバイステッププロトコル」と「厳格な制約」が重要だという点です。曖昧な指示ではなく、具体的な手順と「これがなければ結論を出さない」という制約を設けることで、信頼性の高い出力が得られます。これは、テスト診断に限らず、他の自動化タスクにも応用できる考え方です。

まとめ

Auto-Diagnose自体はGoogle内部のツールですが、そのアプローチは私たちにも多くのヒントを与えてくれます。もしあなたが統合テストの診断に多くの時間を費やしているなら、Gemini 2.5 FlashなどのLLMを使って、ログ解析を自動化できないか検討してみる価値があります。完全な自動化でなくても、診断の第一段階を自動化するだけで、時間の節約になるはずです。

参考リンク:MarkTechPost

コメント

タイトルとURLをコピーしました