はじめに
こんにちは！ テクノロジー統括本部 開発1部の中舘です。
現在はバックエンドエンジニアとして、出張訪問買取システム「Visit」の開発・運用をしています。
本記事では、Slack Bolt App と Anthropic API を組み合わせて、問い合わせの一次対応をAIで自動化した取り組みについてお話しします。
問い合わせ対応の工数に悩んでいるエンジニアや、AIを活用した業務改善を検討されている方の参考になれば幸いです。
課題だったこと
Visitは社内向けのシステムであり、問い合わせの内容もデータの不整合やシステムの挙動に関するものが中心です。そのため、Visitチームではエンジニアが問い合わせに対応する体制をとっていました。
問い合わせはSlackワークフロー経由で問い合わせチャンネルに届きます。対応を開始したら「コミュニケーション担当」と「調査担当」を分担し、業務が進行不可能な状況かどうかや締切を優先的に確認する、という流れです。
当番制で取り組むなどの対策をしていたものの、開発速度の低下に繋がっていました。新規メンバーにとっては「一次受けとして何をすればいいかチームで明確になっていない」「これは自分が対応するべきか迷う」といった心理的なハードルもあり、結果として対応が特定のメンバーに偏りがちでした。
事業会社であるバイセルでは、エンジニアとユーザーの距離が近く、問い合わせへの対応速度も求められます。そのため、問い合わせ対応の負荷は開発チームにとって大きな課題でした。
さらにマルチテナント化の話があがり、テナントが増えれば問い合わせ数も増えることが見込まれたため、改善の優先度はより高くなっていきました。
もう一つのきっかけ
社内では「Tech AI Hackathon」というAI活用促進のイベントが定期的に開催されていました。
Visitチームのメンバーもこのイベントに参加する中で、問い合わせ対応へのAI活用という発想は自然と芽生えていきました。
今までのエンジニアによる問い合わせ対応の履歴はSlack上に残っているため、ナレッジとしては十分に存在しています。あとはそれをAIが参照できる形にすれば、問い合わせの一次対応を自動化できるのではないか。そう考え、問い合わせBotの開発に着手しました。
問い合わせBotのシステム設計
システムは、Slack Bolt App と Anthropic API を Flask API で繋ぐ構成にしました。処理の流れは以下のとおりです。
- 監視対象チャンネルに投稿されたメッセージから「お困りの内容」セクションのテキストを正規表現で抽出
- MCPサーバーが
server/knowledge/配下のファイルを読み込み、ナレッジコンテキストを返却 - ナレッジコンテキストを含むメッセージで Anthropic API にリクエスト
- 回答を元メッセージのスレッドに返信
Slack Bolt AppはCloud Run上で動作し、問い合わせチャンネルに投稿されたワークフローのメッセージを検知します。Visitチームが対応すべきプロダクトの判定には、ワークフローの投稿に識別子として付けられた絵文字を使っています。
MCP Knowledge Serverは別のCloud Runで動作しており、server/knowledge/ ディレクトリに配置したファイル（PDF、Markdown、JSON、YAML等）を自動で読み込みます。初期のナレッジには、既に作成していたFAQスライドのPDFと、過去の問い合わせ履歴から変換したQAデータ（JSON）を投入しました。
当初の回答形式は、ただの長文テキストでした。ナレッジにヒットすれば具体的な手順を回答し、ヒットしなければ「ナレッジベースに記載がありません」と正直に伝えてエスカレーション先を案内します。
ナレッジ蓄積の課題
問い合わせBotを運用する中で、ナレッジの蓄積・更新が大きな課題になりました。
初期ナレッジは、FAQスライドとSlack API経由のワンショットスクリプトで過去の問い合わせ対応内容を取得して投入しました。都度ナレッジを取得する手法もありますが、回答速度を優先して事前にナレッジを貯める戦略をとっています。大型リリース時にはあらかじめ想定質問をFAQに追加しておくことで、リリース直後に急増する問い合わせにも備えていました。
しかし、運用を続けるうちに以下の課題が浮き彫りになりました。
- 新しい問い合わせ対応にナレッジを追従させるには、人の手でスクリプトを実行する必要がある
- エスカレーション先の変更など、ナレッジの更新が必要な場面に弱い
- リポジトリ管理のためPRの作成が必要で、エンジニア以外が更新するには敷居が高い
運用初期には、JSONファイルを直接編集して数回にわたってPRを出すという方法でナレッジを更新していました。しかし、日々蓄積されていく問い合わせのペースにこの方法では追いつけません。
たとえば、エスカレーションフローが変更されるたびに、メンション先のナレッジも追従させる必要がありましたが、更新が漏れてしまうこともありました。
Slack AI での代替
ナレッジに課題を抱える中、2026年2月にSlack AIが全社で有効化されました。
Slack AIには、過去のSlackのやりとりを要約して回答を生成する検索回答機能があります。問い合わせしたい内容を検索するだけで解決策が得られるなら、ユーザーにSlack AIを使ってもらうことで、問い合わせBot自体が不要になるのではないか。そう考え、問い合わせBotを一時的に停止してSlack AIでの代替を試みました。
しかし、前述のようにBotのナレッジが最新の状態に追従できておらず、古い回答がSlack AI検索時のノイズになっていたことや、ユーザーが能動的にAIを使うことへのハードルがあり、うまく活用できませんでした。
そのため、1ヶ月のSlack AI運用期間を経て、Botを復活させることにしました。
復活にあたっては単に元に戻すのではなく、大幅な改善を加えました。AIからの回答をJSON形式（confidence、answers[{reason, next_action}]）で受け取るようにし、信頼度に応じた挙動を実装しています。信頼度はAIがナレッジとの合致度合いから自動で算出します。信頼度が50%以下の場合はチームにメンションを付けて返信し、人間による確認を促します。
Devin を用いたナレッジ蓄積
ナレッジ蓄積の課題を解決するため、Devinを用いて問い合わせ対応ごとにナレッジを追加できる仕組みを作りました。
問い合わせ対応が完了した後、Slackのスレッドにリアクションをするだけで、Devinが起動します。Devinはスレッドの内容を読み取り、server/knowledge/qa_data.json を更新するPRを自動作成します。CIが通ればSlackに通知が届くので、マージするだけでナレッジの更新が完了します。
この仕組みにより、エンジニアでなくてもSlack上からナレッジを更新できるようになりました。問い合わせ対応後にDevinを呼び出してナレッジを追加するフローが定着し、対応完了からナレッジ追加までがスムーズに回るようになっています。
問い合わせBotの効果
問い合わせBotを導入しましたが、問い合わせ対応の工数が0になったわけではありません。ナレッジにない新しい不具合やエッジケースでの業務対応については、依然としてエンジニアの対応が必要です。
一方で、過去に同様の事例がある問い合わせや簡単に対応できる問い合わせについては、Botに任せられるようになりました。信頼度を設けたことで、対応者もユーザーも「人間による対応が必要かどうか」をすぐに判断できます。
ナレッジに存在する問い合わせのみが自動化されたため、工数削減としては1〜2割程度です。しかし、チームからは数値以上のメリットがあるとフィードバックをもらいました。
- 過去のあの問い合わせとは違うものだ、という判断がしやすくなった
- Botが既に確認しているから、別の観点をヒアリングしようと問い合わせ内容の深掘りに繋げられる
- ナレッジが自然と溜まっていくため、属人的だった問い合わせ対応の知見共有が意識せずとも進んだ
特に3つ目は、当初想定していなかった副次的な効果でした。問い合わせ対応の知見が属人化しやすいことは以前からチーム内で認識していましたが、Botのナレッジという形で自然と共有される仕組みになったことで、新規メンバーも過去の対応事例を参照しやすくなりました。
最後に
まだまだ改善の余地はありますが、課題の中心がナレッジにあることは明確になっています。Devinを使った柔軟な更新の仕組みを整えたので、使えば使うほど回答精度が上がり、工数削減に繋がっていくと考えています。今後は、過去に事例のない想定質問をFAQとして拡充することも検討しています。
問い合わせBotの開発を通じて学んだのは、「問い合わせ側に負担をかけない」という設計思想の大切さです。Slack AIのように検索を促す方法もありますが、ユーザーが問い合わせるだけで自動的に回答が届く仕組みの方が、ユーザーにとっての体験は良いと感じています。
問い合わせ対応の工数に悩んでいる方は、まずは過去の対応履歴をナレッジとして整理し、AIに回答させるところから始めてみてはいかがでしょうか。
バイセルでは、一緒に働くエンジニアを募集しています。興味がある方は、以下よりご応募ください。
