【要約】"Cloud Run × Cloud Logging × Gemini でエラーを自動解析してメール通知する仕組みを作った" [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
データエンジニアが、Cloud Run上で稼働する約100件のバッチパイプラインを運用する中で、エラー発生時の対応に多大な工数を費やしている。エラーが起きるたびに、手動でCloud Loggingを開き、スタックトレースを読み解いて原因を推測しなければならない。
- ・ログの目視確認による、初動対応の遅延。
- ・パイプライン増加に伴う、監視工数の増大。
- ・エラー原因特定における、属人的な判断への依存。
// Approach
エラー検知からAI解析、通知までの一連の流れを、業務ロジックから切り離したイベント駆動型アーキテクチャで実現した。
- ・Cloud Run Jobsでバッチを実行し、エラーログをCloud Loggingへ出力。
- ・Log Sinkを用いて、特定の条件（severity>=ERROR）に合致するログをPub/Subへ転送。
- ・Pub/SubのPush Subscription経由で、解析用のCloud Run Serviceを起動。
- ・Vertex AI Geminiを用いてログ内容を解析し、Gmail APIで通知。
- ・仕様書駆動開発により、実装前にIAM権限やリトライ設計の不備を排除。
// Result
本仕組みの導入により、エラー発生時の初動対応における解析コストの削減が可能となった。Geminiがログから原因と対処法を言語化し、メールで即座に通知する。
- ・エラー概要、想定原因、推奨対処法の自動生成。
- ・疎結合な設計による、他のパイプラインへの容易な横展開。
- ・仕様書レビューによる、実装段階での致命的な設計ミス（権限不足や重複通知）の回避。
Senior Engineer Insight
> 運用負荷軽減の観点から、極めて合理的な設計である。特に、監視ロジックを業務ロジックから分離し、Pub/Subを介して疎結合にした点は、スケーラビリティと保守性の両面で高く評価できる。ただし、実戦投入にはGeminiのAPIコスト管理と、トークン制限への考慮が不可欠だ。また、ログテキストのみの解析ではソースコードの行特定には限界がある。高度な自動復旧を目指すなら、Function Callingを用いたエージェント構成への進化が求められるだろう。