Jenkins失敗ログをn8nとClaudeで自動調査、Slack通知へ

CI/CDパイプラインが失敗した際、大量のコンソールログを目視で確認し原因を特定する作業は開発者にとって大きな負担となっている。株式会社JQITのエンジニアがQiitaに公開した記事では、Jenkinsのビルド失敗を検知し、ワークフロー自動化ツールn8nがログを回収、Claudeが原因を要約、Slackへ通知するまでの全自動化システムを実コード付きで解説している。このシステムの設計上の特徴は、Jenkinsとn8nの役割分担を明確にした点にある。

役割分担の原則

本システムの根幹は、Jenkins側は「失敗した事実とログのありか」を通知するだけに留め、ログの回収・AIによる解析・通知のすべてをn8nに集中させる設計だ。この切り分けにより、AI解析のロジックを変更してもJenkins側に一切の修正が不要になる。Jenkins側の共通処理はShared Libraryの1ファイルに集約されており、各パイプラインからは1行の関数呼び出しで利用できる。

Jenkins側実装の詳細

各パイプラインのパイプラインレベルpostブロックのfailureハンドラ内で、共通関数notifyN8nFailure()を1行呼び出すだけでシステムが動作する。

エラーハンドリングの注意点

failureブロックは「すでにビルドが失敗している後処理」から呼ばれる。ここで例外を投げると後処理そのものを破壊しかねないため、同関数内ではあらゆる失敗を握り潰し、警告ログのみを出力する設計を採用している。通知はbest-effort方式とし、通知が届かなくてもビルド結果はFAILUREのまま完了する。

認証情報の安全な取り扱い

Webhook URLと認証トークンはJenkins Credentialsから取得する。重要なのは、Groovyの文字列補間（"${...}"）を使ってcurlコマンドに埋め込まない点だ。補間を用いるとマスク機構をすり抜けてログに平文が出力されるリスクがある。そのため、withCredentialsで環境変数に束縛し、シェル側で環境変数として参照する方式を取っている。URLは必須、トークンは任意という非対称な設計で、トークンが空の場合は認証ヘッダーを送信しない。

ペイロードの構造

Jenkinsからn8nのWebhookに送信されるペイロードは、ビルドURLとステージ名等をJSON形式で構成する。シャード（並列実行）を含むパイプラインに対応するため、デフォルトで実行ノードの情報を付加する設計となっている。各パイプラインからの拡張データをマージできる仕組みも備えている。

n8n側のワークフロー構成

n8n側はWebhookノードでJenkinsからのリクエストを受信し、以下の処理を逐次実行する。

ログ回収処理

curlコマンドを用いてJenkinsのコンソールログエンドポイントからログを取得する。公開ホストがCloudflare Accessで保護されている環境に対応するため、Kubernetes内部のサービスエンドポイントにURLを書き換える処理を含む。ログの最後の200行を抽出し、処理量を抑える工夫も施されている。

プロンプトの設計

Claude CLIに渡すプロンプトでは、ログの末尾に該当部分を設定し、AIに「問題の根本原因」「発生したエラーの種類」「修正の方向性」の3点を抽出させる。自然言語による指示を最小限に抑え、JSON形式で構造化データを出力させることで、後続の処理で扱いやすくしている。

Claude CLIの実行

n8nのExecute Commandノードを使用して、pod内でClaude CLI（claudeコマンド）を実行する。Claude CLIの認証トークンはHashiCorp Vaultから環境変数として供給される。出力はJSONとしてパースされ、後続ノードで利用される。

Slack通知の実装

Slackノードでは、ブロックキット（Block Kit）を用いて構造化されたメッセージを構築する。通知には以下の情報を含む。

• ビルド名と結果
• 失敗ステージの特定
• Claudeによる原因要約
• JenkinsのビルドURLへのリンク
• 再実行ボタン（任意）

Slack Botトークンはn8nのクレデンシャル管理機能から参照する。

関連資料の活用

全ての設計ドキュメントやJenkins Shared LibraryのコードはGitHubリポジトリで公開されている。n8nのワークフローJSONのエクスポートファイルも同リポジトリで入手可能であり、自環境への導入を検討する際の参考になる。

前提環境と代替可能性

記事ではKubernetes上でJenkinsとn8nが動作し、HashiCorp Vaultによるシークレット管理を行う環境を前提としている。ただし、KubernetesとVaultは必須コンポーネントではない。以下の3条件が満たされれば任意の環境で動作する。

• n8nからJenkinsの内部エンドポイントに到達可能であること
• n8nのpod内でClaude CLIが実行可能であること
• Jenkinsの認証情報が安全に渡せること

編集部の見解

このシステムが示すのは、CI/CDパイプラインにおけるAI活用の現実的なアプローチだ。JenkinsにAI処理を直接組み込むのではなく、n8nを中継点として役割を分離した設計は、保守性と拡張性の点で優れている。特に、AI解析のロジックを変更する際にJenkins側への影響がゼロである点は、大規模な開発組織において効率的な運用を実現する鍵になる。 短期的には、同様のアプローチがJenkins以外のCIツール（CircleCI、GitHub Actions等）にも応用される可能性が高い。AIによるログ解析は、開発者のデバッグ時間を削減し、デプロイサイクルの短縮に寄与する。 長期的視点では、AIが単なるログ解析ではなく、障害原因の特定から修正コードの提案までを担う時代が到来するかもしれない。ただし、現状のAIは誤った原因を自信満々に提示するリスクを内包している。このシステムの価値は、AIの出力をあくまで「要約と方向性の提示」に限定している点にある。最終判断は人間が下すという責任分担の明確さが、実運用に耐えうる設計と言える。

参考

• Qiita「Jenkinsの失敗ログをn8nで回収してClaudeに原因調査させ、Slackへ自動通知する」 — 2026-06-28公開
• Claude CLI公式ドキュメント — Anthropic
• n8n公式ドキュメント — n8n GmbH