面倒な一次調査はDevinにお任せ！Devin MCPとn8nで作る、CS問い合わせ一次調査Bot

こんにちは。エンジニアのtanihiroです。

株式会社スマートバンクが運営しているワンバンクでは、日々様々なお問い合わせがユーザーから寄せられます。届いたお問い合わせはCSチームが対応していますが、中にはエンジニアに確認しないと回答が難しいものもあります。

そのようなケースでは、CSチームから顧客体験チームのエンジニアへエスカレーションする体制が整えられています。Slackワークフローで調査依頼をテンプレート化し、担当エンジニアが調査して回答する流れが確立されています。

しかし、この調査作業が結構たいへんなのです。

今回は、この一次調査を自動化するために、Devin MCPとn8nを組み合わせたBotを作ってみた話をします。

調査の何がたいへんなのか

調査依頼を受けたとき、私たちが最初にやることは以下のようなことです。

そもそも仕様としてなにが正しいのかを確認する
該当の実装箇所はどこなのかを探す
DBの値はどうなっているのかを確認する
access logはどうなっているのかを確認する

などなど。

これらの調査に時間がかかると、当然ながらユーザーへの返信も遅くなり、ユーザー体験を損なってしまいます。エンジニアとしては、できるだけ素早く反応したいのですが、毎回この初動調査に時間を取られるのが現実でした。

ソースコードレベルの調査をDevinに任せることにした

そこで、ソースコードレベルの調査をDevinに任せるBotを作ってみることにしました。

ソースコードレベルの調査に留めた理由としては以下です。

DBやaccess logにアクセスできるようにするのは、権限の観点からかなり大変
ソースコードレベルの調査であれば、すでにDevinはアクセス可能な領域なので、サクッと試せる

そしてもう一つ、Devinを使う大きなメリットがあります。

複数リポジトリをまたがって調査できることです。

私たちのプロダクトは、Rails API、React管理画面、iOSアプリなど、複数のリポジトリで構成されています。CS問い合わせの調査では、「フロントエンドでこう表示されているから、バックエンドのAPIはこうなっているはず」といった横断的な理解が必要になることが多いです。

Devinなら、複数のリポジトリを同時に見ながら、「このAPIエンドポイントはここで定義されていて、管理画面からはこう呼ばれている」といった調査が可能です。これは人間がやると結構時間がかかる作業ですが、Botなら一気にやってくれます。

完璧な調査を目指すのではなく、まずは「素早い動き出しを可能にする」ことを目標にしました。ソースコードから仕様や実装箇所を把握できるだけでも、次の調査に進むハードルがぐっと下がります。

Devin MCPとは

みなさんは、Devinを使っていますか？Devin wiki便利ですよね。

Devin MCPを利用すると、LLMからDevinによる調査を行えるようになります。

具体的には以下のようなことができます。

リポジトリのドキュメント構造を取得
リポジトリのドキュメント内容を読み取る
リポジトリについて質問して、文脈に基づいた回答を得る

これらをGeminiなどのLLMから呼び出せるので、「Geminiに調査を依頼→Devinがコードベースを調べる→結果をGeminiが整形」という流れが実現できます。

詳しくは公式ドキュメントを参照してください。

n8nでCS調査Botを作る

実装にはn8nを利用しました。n8nは、ノーコード/ローコードでワークフローを構築できるオートメーションツールです。

ワークフローの流れ

以下が実際のワークフローです。

Slack Trigger：CSからのお問い合わせに「一次調査」絵文字でリアクションする
n8nが作動：リアクションをトリガーにワークフローが開始
Geminiが調査対象を判断：お問い合わせ内容をもとに、調査対象のリポジトリを判断
Devin MCPでコードベース調査：Devinを利用して実装の該当箇所や現時点の仕様を把握し、原因の仮説を立ててレポートにまとめる
CodeノードでJSONをパース：Geminiが返すJSONを抽出・パースする
GitHub Issueを作成：まとめた内容をIssueとして起票し、Slackにも通知

ワークフローで投稿された問い合わせに対して、「一次調査」でリアクションするとn8nが作動

プロンプトの工夫

調査の精度を上げるために、プロンプト自体もLLMと壁打ちしながら作りました。

実際のプロンプト例を載せておきます

System Prompt

あなたはワンバンクのシニアエンジニアです。カスタマーサポートからの問い合わせを受けて、関連するコードを調査し、GitHub Issueを作成するための情報を整理する役割を担っています。

## あなたの責務
1. CS問い合わせから技術的な問題を特定する
2. 該当するリポジトリとコードを探索的に調査する
3. 問題の原因を推定し、根拠を明確にする
4. エンジニアチームが対応しやすい形式で情報を整理する

## 重要な指示
- 純粋なJSONのみを出力すること
- コードブロック（```）で囲まないこと
- 説明文や前置きを含めないこと
- JSONの前後に余計なテキストを入れないこと

## 調査対象リポジトリ
- smartbank-inc/xxx: Rails API サーバー（ビジネスロジック、DB操作、バックエンド処理）
- smartbank-inc/xxx: React 管理画面（CS/運用チーム用、admin.b43.jp）
- smartbank-inc/xxx: iOS アプリ（エンドユーザー向けモバイルアプリ）

## 調査の原則
- 事実と推測を明確に区別する
- コードベースの証拠を必ず提示する
- 不明な点は「不明」「要調査」と明記する
- 仮説には必ず確信度と根拠を付ける

User Prompt

以下のCS問い合わせ内容を調査し、GitHub Issue作成用のJSONを生成してください。

## CS問い合わせ内容
{{ $json.message.text }}

## 問い合わせSlackのURL
{{ $json.message.permalink }}

## 必要なJSON構造
{
  "title": "[CS調査] {50文字以内の問題要約}",
  "description": "{Issue本文のマークダウン文字列}",
  "investigation_comment": "{調査詳細コメントのマークダウン文字列}",
}

## descriptionフィールドの内容
## 🔍 問題の概要
[1-2文で問題を要約]

## 📝 CS からの報告
> [元の問い合わせ内容を引用形式で記載]

[slackのURLを記載]

## ⚠️ 影響範囲
- **影響を受ける機能:** [機能名や画面名]
- **影響を受けるユーザー:** [どんな条件のユーザーか]
- **発生頻度の推定:** [レアケース/特定条件/全ユーザーなど]

## investigation_commentフィールドの内容
## 🎯 調査結果

### 調査したリポジトリ
- [ ] smartbank-inc/xxx
- [ ] smartbank-inc/xxx
- [ ] smartbank-inc/xxx

### 該当箇所
| リポジトリ | ファイル | 行番号 | 説明 |
|-----------|---------|--------|------|
| [リポジトリ名] | [パス] | L[開始]-L[終了] | [説明] |

### 重要なコード
言語名を指定してコードブロックを作成

### 処理フロー
1. [ステップ]
2. **[問題発生箇所]**

## 💡 推定原因

### 仮説1: [原因]
**確信度:** ⭐⭐⭐⭐☆
**根拠:**
- [根拠]

**該当コード:**
- [リポジトリ]: [パス:行番号]

## 📋 追加調査項目
- [ ] [調査項目]

このプロンプト設計により、エンジニアがすぐに判断できる形式でIssueが作成されるようになりました。

実際に使ってみて

実際に運用してみると、かなり良い精度で調査をしてくれて、助かっています。

特に大きいのは、ソースコードレベルでどうなっているかがある程度わかっている状態で、次の調査に進めることです。

例えば

「このAPIエンドポイントの実装はここで、こういうバリデーションがある」
「この機能は○○というクラスで処理されている」
「現在の仕様では△△という挙動になっている」

といった情報が自動でまとまったIssueになっているだけで、調査の初動が全く違います。

もちろん、完璧ではありません。時には見当違いな箇所を調査していたり、情報が不足していることもあります。でも、ゼロから調査を始めるよりは圧倒的に早いですし、間違っていても「ここは違う」と判断できること自体が価値です。Botの調査結果は「最初の足がかり」として扱い、エンジニアが必ず内容を確認してから次のアクションに進むようにしています。