こんにちは。データ基盤開発部/データアプリケーショングループ/ML 基盤チームの河西です。
私の所属する ML 基盤チームでは、DMM.com の数百万件を超えるコンテンツを情報検索や機械学習を使ってユーザーにパーソナライズして届けるために、検索・レコメンドを改善する ML エンジニアと協業し、日々 ML バッチ基盤を改善しています。
私たちは、「ML 基盤を利用するユーザーに対してシステムの安定稼働と開発の効率化を提供する」 という Mission を掲げ、最終的には「様々なアイデア/仮説を素早く正確に検証できる」 状態を実現することを目指しています。
今回は、ML 基盤チームとしての取り組みではなく、部内の取り組みである「分科会」の一環として、n8n と Google Cloud を組み合わせた AI Agent ワークフローを構築したので、その技術構成やハマりどころについて紹介します。
背景と動機
部の取り組み「分科会」について
私が所属する部では、「分科会」という取り組みが行われています。 これは、「生成 AI 活用」「開発生産性向上」「ドメイン知識向上」 など、メンバーから募った複数のテーマの中から、各々が関心のあるものを選択して活動する制度です。
業務時間の一部を使って、技術的な探求や検証をすることで、日々のチームでの開発とは別に、個人的に関心の高い技術に触れられる貴重な機会となっています。 私は今回、この中から 「生成 AI」 のテーマを選択し、特に生成 AI におけるプロダクト活用に焦点を当てたチームに入りました。
なぜこれに取り組んだのか
個人的に、AI Agent (LLM) の活用に関しては、Claude Code、ChatGPT、Gemini など、コーディング実装・アシスタントや何らかの壁打ち相手といった局所的な利用に留まっていました。
一方で、弊社を始め各社においても、LLM を利用したプロダクトの活用事例が散見されるようになってきました。
また、ML 基盤チームとしても、今後 LLM を活用したプロダクトを構築していくことは必須になると考えています。 そんな思いから、AI Agent を活用したシステム構築にチャレンジしてみたいと考えていました。
解決したい課題
AI Agent を活用したシステム構築の題材として、我々が提供している ML 基盤を利用する ML エンジニアの運用負荷軽減 に着目しました。
ML 基盤チームではバッチ基盤の ML パイプラインとして、Vertex AI Pipelines の基盤を運用していますが、その上で動くパイプラインの実装や実行エラー時の対応は、基本的に別チームである ML エンジニアが行っています。
現状、エラー発生時のフローは以下のようになっています。
- パイプラインの失敗ログをトリガーに Cloud Functions が実行され、Slack に通知が飛ぶ
- この通知には「Google Cloud コンソールの URL」に加え、「最大 3000 文字までのエラーログ」が含まれています。
- ML エンジニアが通知の内容（3000 文字のログ）を見て、判断できない場合は、通知にある URL をクリックして Google Cloud コンソールを開く
- パイプライン内の大量のログの中から原因箇所を特定し、対応する
この「通知を見てコンソールを開き、ログを見に行く」という作業は、頻度が高いと ML エンジニアにとって大きな負担になります。 例えば、Google Cloud 側で GPU の確保に失敗した等、パイプラインコードの修正を伴わないものは、本来コンソールを開かなくても良いものです。
そこで今回は、「エラー通知を受け取ったら、AI Agent が自律的にログやメトリクスを見に行き、解析結果（一次切り分け情報）を Slack に返してくれる」 仕組みを構築することにしました。
これが実現できれば、ML エンジニアの運用効率を向上させることができるうえに、今回の目的である「AI Agent を利用したシステム間連携（Slack × Google Cloud）」の検証にも最適なテーマとなると考えました。
技術選定
実装方針
今回のシステムは、「Slack 通知をトリガーに、外部ツール（Google Cloud）を実行し、その結果を LLM が判断して回答する」というフローになります。 これらをすべてフルスクラッチ（Go や Python など）で実装できますが、開発工数をできるだけ削減し、まずは小さく試すことを重視したため、LLM とのインテグレーションが可能なノーコード・ローコードのワークフローエンジンを活用する方針としました。
ツールの比較・選定
上記の要件を満たす候補として、n8n と Dify を検討しました。 機能面でどちらかが圧倒的に優れているという決定打はなかったものの、今回は以下の理由から n8n を選定しました。
- Integrations の豊富さ: システム間連携（Slack, Google Cloud 等）のノードが標準で充実しており、今回の要件である「既存システムとのつなぎ込み」が容易そうだった。
- 実装事例: 今回のユースケースに近い他社での実装例が多く見つかり、構築のイメージが湧きやすかった。
システムアーキテクチャ
ML 基盤が運用されている Google Cloud 上で構築することを前提に設計しました。
最終的な全体構成は以下の通りです。
社内ツールとしてのセキュリティを担保するため、n8n は Cloud Run 上でセルフホストし、前段には Identity-Aware Proxy (IAP) を配置してアクセス制限をかけています。
直面した 2 つの課題
この構成を実現するにあたり、以下の 2 つの技術的な壁にぶつかりました。
1. Slack からの Event は IAP を越えられない
Slack の Event Subscription（Bot へのメンション等）をトリガーにする場合、Slack 側からの HTTP リクエストを受け取る必要があります。しかし、Slack は Google の IAP 認証（Google アカウントログイン）に対応していないため、そのままではリクエストがブロックされてしまいます。
2. LLM 単体では URL の先にあるログを読めない
Slack に通知されるのは「Vertex AI Pipelines のコンソール URL」と「3000 文字までのエラーログ」のみです。 LLM が詳細なエラー原因を特定するためには、Google Cloud へアクセスし、ログやメトリクスの情報を自律的に取得・操作する MCP Server が必要でした。
技術的課題の解決（インフラ実装）
上記の課題を解決するため、以下の 2 つのコンポーネントを実装しました。
1. IAP 突破のための Proxy Server (Go + Cloud Run)
Slack と n8n の間に、認証を中継するための Proxy Server を挟む構成にしました。
- 構成: Slack -> Proxy Server -> IAP -> n8n
- 実装: Cloud Run + Go
- 処理の流れ:
- Slack App からのリクエストを受け取る。
- Service Account を用いて OIDC トークンを発行し、IAP に向けた JWT 認証をする（参照: プログラムによる IAP への認証）。
- 認証ヘッダを付与して n8n のエンドポイントへリクエストをプロキシする。
なお、Slack App との初回接続時に発生する url_verification イベント（参照）のハンドリングもこの Proxy 内で行っていますが、基本的には右から左へリクエストを流すシンプルな作りです。
2. ログ・メトリクス取得のための MCP Server
エラー通知に含まれる URL から Cloud Logging や Metrics の詳細情報を取得するために、Model Context Protocol (MCP) を実装しました。n8n の AI Agent の Tools にこの MCP を持たせています。
- 実装: Go
- ライブラリ: 実装当時は公式 SDK が未成熟だったため、
mark3labs/mcp-goを利用しました。- ※記事執筆時点では公式の modelcontextprotocol/go-sdk が V1 になっているため、今後はそちらを利用するのが良さそうです。
これにより、Agent は「エラー通知の URL を受け取る」→「MCP Server 経由でログを取得」→「原因解析」というフローを実行できるようになりました。
n8n 上での AI Agent 構築
インフラとツールが整ったので、最後にこれらを統合する n8n ワークフローの構築についてです。
ワークフロー全体像
構築したワークフロー全体像は以下の通りです。
Slack からの入力をトリガーに、AI Agent が思考・ツールを実行し、最終的に Slack に返答するというシンプルなフローです。 中心となるのは、n8n の AI Agents ノードです。
Agent ノードの設定
Agent ノードは Chat Model, Memory, Tool の 3 つの機能を統合的に管理でき、GUI ベースで直感的に設定が可能です。
プロンプトと入力設定
- System Prompt: 「あなたは Google Cloud の運用担当者です...」といった役割定義や、出力形式の指示を記述します。
- Prompt (User Message): Slack トリガーから渡ってきた JSON データ（メッセージ本文など）を、GUI 上でドラッグ＆ドロップするだけで変数として埋め込むことができて便利です。
各コンポーネントの構成
Agent ノードに接続する各機能の詳細は以下の通りです。
1. Chat Model (Gemini) Google Cloud との親和性や性能を考慮し、Gemini を採用しました。
2. Memory (Window Buffer Memory) Agent ノード標準の Window Buffer Memory を利用しています。
- 工夫点: Slack 上での文脈を正しく保持するため、セッションキー（Session Key）には
{channel_id}:{thread_ts}を設定しました。 - これにより、基本的には「チャンネル × スレッド」単位で会話のコンテキストが独立して管理され、他のスレッドと混線することなく対話が可能になります。
3. Tool (MCP Server) 先ほど作成した MCP Server を Tool として接続しています。
- 工夫点: n8n をホストしている Cloud Run の Sidecar コンテナ として MCP Server を立ち上げる構成にしました。
- これにより、n8n からは
localhost経由でセキュアかつ低レイテンシに HTTP Streamable で MCP Server へアクセスできます。
以上、n8n の標準機能と Cloud Run の構成パターンでシンプルに構築できました。
結果
実際に構築したワークフローの挙動がこちらです。
メンション付きのエラー通知に対し、Agent がスレッドで原因と対応策までの解析結果を返してくれるようになりました。 ただし、内容によっては、正しく原因解析ができていなかったり、「わかりませんでした」などの回答をしたりと、精度の面に関しては今後の課題となりそうです。 ここに関しては、後述する監視・改善の仕組みを導入していく予定です。
今後の展望
今回の取り組みは分科会での PoC（概念実証）という位置づけでしたが、十分に実用性が見込める結果となりました。 今後は以下のステップを進めていく予定です。
- 本番環境への適用: 現在の構成を本番環境へデプロイし、チームの実運用フローに組み込む。
- LLMOps の実践: 次のステップとして LLM オブザーバリビリティツールの OSS である Langfuse を n8n に組み込み、入出力のトレースや評価する仕組みを検証しています。このあたりの「n8n × Langfuse」による LLMOps の取り組みについては、また別の記事で詳しく紹介できればと思います。
