【一次調査の自動化】Slack × n8n × Devinで、もう一人のドメインエキスパートを作ってみた

はじめに

イノベーション開発チームの大野です！ITトレンドで開発マネジメント・QAをしています。

エンジニアによる社内質問への対応工数の問題は弊社の各チームで発生しており、多くの開発チームが抱える一般的な課題だと思います。

そこで、この課題を改善するために Slack × n8n × Devin を使って、一次調査の自動化を行いました！
開発チームの課題感と、実際に使ってみて良かった・エンジニアの負担が軽減された・みんなに使ってもらえた、という内容をご紹介します。

課題

ITトレンドでは、ユーザーやクライアントからの問い合わせに対してユーザーサポート・カスタマーサポートチームが窓口を担っています。
しかし、詳細なロジックの確認が必要なケースではエンジニアへのエスカレーションが発生します。
Slackワークフローで調査依頼をテンプレート化し、対応フロー自体は整備されています。それでも、エンジニアが行う一次調査の負担は小さくありません。

長く運用されているサービスであるがゆえに、過去の経緯や背景を知るメンバーに知識が集中しやすく、経験者に依存する状況も続いていました。

もちろん、問い合わせ対応を通じて実際に事象解消まで取り組むことは、エンジニアにとってスキル向上につながるポジティブな側面もあります。
私にとっても、ITトレンドを長く担当する中で、ドメインエキスパートとしてのスキルを高めるうえで不可欠な経験だったと感じています。

一方で、背景や文脈を十分に把握しないまま調査を行うことは、心理的にも時間的にも負荷が高く、決して楽な作業ではありません。
最初に何から着手すべきかは、質問内容や緊急度、重要度によって毎回異なります。その判断を暗黙知に頼っていたことも、負荷の一因でした。

そこで、自分が持っているドメイン知識を誰でも再利用できる形にすれば、この負荷を下げながらスキル向上と事象解決スピードを両立できるのではないかと考えました。

やったこと

n8nで質問チャンネルを監視し、特定のSlackスタンプが押されたことをトリガーとしてn8nのワークフローを開始します。

ワークフローの概要

1. 特定のスタンプが押されたかどうかを判定
2. スタンプが押されたスレッドの全文を取得
3. スレッド内容を Devin に送信してセッションを開始
4. セッションのURLをスレッドに返却

ワークフローの構成はスマートバンクさんの記事を参考にしました。
https://blog.smartbank.co.jp/entry/2025/10/08/090000

上記実装例では、Devin MCP を使い、複数のリポジトリを横断しながら一次調査した内容を、GitHub Issue として自動生成しています。

私たちの環境では以下の理由から、この2点を採用しませんでした。

• Ask Devin を使わなかった理由
  MCP 経由での検索は横断的で強力ですが、
  Ask Devin（個別の QA モード）は今回は想定した精度向上が得られなかったためです。

• GitHub Issue を作成しない理由
  Issueは日々のタスク分割やプロジェクト管理にも使われており、
  自動生成された調査結果が混ざることで
  ノイズや誤認につながる可能性を避けたかったためです。

効果

定性的な効果

• 割り当たったメンバーが毎回使っている
• 入社して1ヶ月のメンバーが対応に入れている
• 対応時の一歩目のアクションに迷わなくなった

メンバーからは嬉しいフィードバックをもらいました。

・コード上のバグではない場合も、共有いただいた状況の再現に役立った
・とりあえずAIに調査させるというのが自動で行えるのが最高
・該当のコードはすぐに見つけられました
・内容によっては解決まで進むので助かります

定量的な効果

事象解消までの速度向上は、休日や連絡待ちの発生により取得が難しいので、今回は使用率のみ集計しました。

• ワークフローの使用率 約78%（15件/19件）

ワークフローが使われていない質問については、対応メンバーの既知事象だったため不要だったものです。ですので、使用率は 実質100% になります！

課題にあった、誰が対応するか曖昧・まず何をすればいいか迷う・リポジトリが複数あり調査が重い、という状況は軽減されたのではないかと思います。

工夫したポイント

自分が持っているドメイン知識を Devin Knowledge として作成し、調査の際は必ず参照させることで精度を向上させることができました。

Devin Knowledge でリポジトリに保管してる調査の原則を見させる

Devin Knowledge は作成するとIDが発行されるので、Devinセッションを開始するAPIリクエストを送信する際に knowledge_ids にIDを指定することで安定して同じ Knowledge を参照させることができます。

search_principle.md

search_principle.mdには画像で見える範囲以外に、社内で普段使われる用語とAPI・ページのルーティング・DBのテーブル名などのマッピングを記載しました。
例えば、「〇〇マスタ」というワードが出てきたらこのページで使われるデータのことを指していて、こういった業務に使われる。データは主テーブルAをテーブルB・テーブルCと結合して取得している、というような定義を作成しました。
マッピング作業のために質問チャンネルで2025年分をざっと見て、よく聞かれているページや頻出のワードを調査の原則として追加しました。

この作業はスマートにはできない部分でしたが、長く一つのサービス開発に携わり、開発チームだけでなく色々な部署のメンバーと業務で関わった経験があるからこそできた方法だと思いました。

やらなかったこと

全自動化

全自動での回答botは目指しませんでした。
質問チャンネルに届く内容は、仕様質問だけでなく不具合と思われる報告、クライアントからご指摘いただいたことの相談まで様々です。
仕様質問への回答はともかく、特に他社が関わる際には事態の収束のために、エンジニアによる判断や、責任を分担して負うことが必要と考えています（AIに調査させました、で事態が収束するとは思えない）。

このような現場での経緯から全自動は現実的ではないと考えて、エンジニアの一歩目のアクションの負担を減らすことに注力しました。

実データアクセス

データ保護の観点と、データアクセスが必要な質問の少なさから見送りました。

データ保護に関しては、スマートバンクさんの例と同じ理由です。

DBやaccess logにアクセスできるようにするのは、権限の観点からかなり大変

過去の質問内容を確認すると、そもそもデータアクセスが必要な質問の件数が少なかったことがわかりました。
また、ワークフローを試運転した時に該当テーブル・カラムまで特定していたので、一次回答を踏まえて自分で調べることで対応できる程度の精度はあると感じました。

こういった背景により、工数を割いてデータアクセスのハードルを超えるのは今やらなくても良い、と判断しました。

次にやること

仕様の自動回答MCP作成に着手しています。

前述の通り全自動での回答はスコープ外でしたが、そうは言っても、不具合ではない仕様質問への回答は自動化するのが理想です。
仮に仕様質問への自動回答が納得いかないものだったとしても、仕様書を元にした回答をインプットにするので、今回作成した一次調査フローの回答精度も上がると期待しています。

チャンネルに届く質問はジャンル分けができているので、MCPによる回答で質問がどれくらい減ったかを定量的に評価できると考えています。

まとめ

Gemini に厳しめにレビューしてもらったところ「属人化を排除しようとしているのに、ナレッジのメンテナンスが新たな属人化を生んでいるように見えます。」というフィードバックをもらいました。
たしかに今回の取り組みはまだ途中段階ですが、「一次調査の負荷を減らす」という第一歩としては手応えを感じています。

次のステップとして、ナレッジ自体のメンテナンスをどう自動化・半自動化できるのかをテーマに模索していきます。