【要約】Jenkinsの失敗ログをn8nで回収してClaudeに原因調査させ、Slackへ自動通知する [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
CI/CDの運用において、エンジニアはビルド失敗のたびにコンソールログを手動で確認する作業を強いられている。この作業は、開発のコンテキストを中断させ、精神的な消耗を招く要因となる。具体的には以下の課題が存在する。
- ・ログの確認作業が手動であり、地味な消耗を招く。
- ・膨大なログから原因を特定するのに時間がかかる。
- ・通知だけでは、具体的な対処法が即座に判明しない。
// Approach
Jenkinsの責務を最小限に留め、解析・通知のロジックをn8nに集約する疎結合なアーキテクチャを採用した。これにより、CI環境への影響を抑えつつ、AI解析の改善を容易にしている。
- ・Jenkins Shared Libraryを用いて、失敗時のメタ情報とログURLをn8nへ送信する。
- ・n8n側で、公開URLをKubernetes内部サービス用URLへ書き換え、ログを取得する。
- ・取得したログの末尾を抽出し、Claude CLIを用いて原因を要約する。
- ・要約結果をSlackへ自動投稿する。
// Result
CI失敗時の一次調査を自動化し、エンジニアの調査工数を大幅に削減した。導入による具体的な成果は以下の通りである。
- ・Jenkins側はShared Libraryの1行追加のみで導入が可能。
- ・AI解析ロジックの変更がn8n側のみで完結し、CI環境への影響を抑えられる。
- ・「根本原因・該当ステージ・対処法」がSlackに届くため、迅速な復旧が可能。
Senior Engineer Insight
> 責務の分離が徹底されており、運用の柔軟性が極めて高い。Jenkinsに重い処理をさせず、n8nに寄せる設計は、CIパイプラインの安定性とメンテナンス性を両立させている。特に、ログ本体ではなくURLを渡す設計は、ネットワーク帯域やメモリ消費の観点からも理にかなっている。実戦投入時は、AIの誤判定（ハルシネーション）を前提とした、人間による最終確認フローを組み込むべきだ。