今回の題材は、Loghubという公開データセットに含まれるApache Sparkのシステムログです。Apache Sparkは大量のデータを高速に処理するためのフレームワークで、処理の実行状況をログとして出力します。

ログには「INFO」「WARNING」「ERROR」などのログレベルがありますが、このサンプルで扱うのは通常の動作状況を記録する「INFO」ログです。つまり、一見するとシステムは問題なく動いているように見えるログが対象になります。

公式サンプルのポイントは、そのような「正常そうに見える」INFOログをAI.AGGでまとめて分析し、人が大量のログを目で追わなければ気付きにくい処理の遅延や繰り返しのリトライ、非効率な処理の兆候を見つけることです。

事前にファイルのダウンロード、BigQueryのデータセットやテーブルの作成が必要です。今回利用したデータの中身は下記です。

公式サンプルのSQLにGeminiのモデルを指定したものが下記です。

SELECT

 Component AS spark_component,

 COUNT(*) AS log_count,

 AI.AGG(

   Content,

   'これらの Spark システム INFO ログを分析してください。2 文で簡潔にまとめてください。まず、このコンポーネントの通常の動作を説明してください。次に、隠れた非効率性、レイテンシの急増、再試行の繰り返し、異常なパターンを明示的に特定してください。',

   endpoint => 'gemini-2.5-flash'

 ) AS performance_analysis

FROM

 `your_project.dataset.spark_logs_structured`

GROUP BY

 Component

ORDER BY

 log_count DESC;

① GROUP BY Component の意味

Sparkのログには Component（SparkContext、TaskSetManager、BlockManagerなど）という、ログを出力したモジュール名が格納されています。

GROUP BY Component によって、コンポーネントごとにログをまとめています。
COUNT(*) が件数を集計するのと同様に、AI.AGG(Content, …) はコンポーネントごとのログ全体を対象として1つの要約を生成します。

ここが、1行ずつ処理する AI.GENERATE との大きな違いです。

② プロンプトが「2文構成」を指定している理由

プロンプトでは「まず通常動作を説明し、その後に異常や気になる点を指摘する」という流れを明示しています。

これは出力形式を揃えるだけではなく、「問題がなければ正常と回答してよい」ことをモデルに伝え、存在しない異常を作り出す（ハルシネーション）ことを防ぐ狙いがあります。

また、毎回同じ構成で回答されるため、ダッシュボード表示や後続処理にも利用しやすくなります。

③ 「隠れた非効率」を見つけられる理由

AI.AGGはログレベルだけで判断しているわけではありません。

プロンプトで「隠れた非効率性、レイテンシの急増、再試行の繰り返し、異常なパターン」といった観点を指定し、複数のログを横断的に分析しています。

そのため、INFOログしか存在しない場合でも、人が大量のログを読まなければ気付きにくい傾向や異常の兆候を要約できます。

AI.AGGは、複数行のデータをまとめて分析できることが特徴ですが、どのような結果を得られるかはプロンプトの指定内容によって大きく変わります。

公式ブログでは、モデルに対して「すべて正常」と回答することを明示的に許可することでハルシネーションを防いでいるとのことでした。

プロンプトを①「このログから異常な傾向を見つけてください。」で実行した場合と②「これらの Spark システム INFO ログを分析してください。2 文で簡潔にまとめてください。まず、このコンポーネントの通常の動作を説明してください。次に、隠れた非効率性、レイテンシの急増、再試行の繰り返し、異常なパターンを明示的に特定してください。」で実行した場合で比較してみたいと思います。

今回の検証では、②の具体的なプロンプトの方が短時間で完了しました。また出力トークン数もかなり小さくなりました。これは、出力内容を明確に指定したことで不要な生成量が抑えられた可能性があります。ただし、AI処理の実行時間は実行環境やサービス側の状況によって変動するため、傾向として参考にしてください。

また②の場合、「異常なパターンや隠れた非効率性はない」と回答があるものがあるのに対し、①では全部何らかの異常を指摘されています。

今回の検証では、「異常を見つけてください」という曖昧なプロンプトと、Google Cloud公式ブログで紹介されているプロンプトを比較しました。

曖昧なプロンプトでは、正常に見えるログも含めて、すべてのログに対して何らかの異常を指摘する結果となりました。一方、公式ブログのプロンプトでは、まずログ全体の正常な動作を説明し、その上で異常と思われる点があれば指摘する構成になっているため、より実務で確認しやすい分析結果が得られました。

公式ブログで紹介されているプロンプトのポイントは、モデルに「問題がなければ、そのように判断してよい」という前提を与えていることです。これにより、異常を探すことだけを目的とするのではなく、正常な状態も分析結果として受け入れるよう促しています。

なお、この考え方は「問題なければ『問題なし』と出力してください」といった一文を追加しているわけではありません。実際には、「まず正常な動作を説明し、その後に異常があれば指摘する」という二段階の指示になっています。この構成により、モデルは正常な状態を分析結果として返す選択肢を持つため、不必要に異常だけを探そうとする挙動を抑えやすくなっています。

ログ分析に限らず、AI.AGGを業務で活用する場合は、「何を見つけるか」だけでなく、「問題がなければ正常と判断してよい」という前提をプロンプトに含めることも、分析精度を高める重要なポイントといえるでしょう。

システムサポートでは、Google Cloudの導入や活用を支援しております。

Google Cloudを導入したい・導入したけど使いこなせていない…という方は、お気軽にご相談ください！