この記事は Sansan Advent Calendar 2025 の24日目の記事です。
こんにちは。
技術本部 Sansan Engineering Unit Infrastructureグループの白井達也です。
ありがたいことにクリスマスイブ🦌🛷の担当を頂きました。予定がある方は後日ゆっくり、予定がない方は今夜のお供にどうぞ。🥂クリスマスツリー🎄ほど華やかではありませんが、実用的な内容🎁をお届けします！
1. はじめに
私たちInfrastructureグループ（以下、インフラグループ）では、Sansanのインフラに関する社内からの問い合わせをSlackで受け付けています。「新しいRDSインスタンスを構築してほしい」「このエラーの原因を調べてほしい」といった問い合わせが月に50件ほど届きます。1件あたりの対応時間は短いものが多いですが、積み重なると無視できない工数となります。
この問い合わせ対応を効率化し、インフラの安定性向上や運用改善といった本質的な活動により多くの時間を充てるため、Amazon Bedrockを活用したSlack BotのPoC（Proof of Concept）を実施しました。
この記事では、そのPoCで行った試行錯誤の過程と、実際に得られた知見をご紹介します。 生成AIを活用した業務効率化に興味のある方の参考になれば幸いです。
2. 背景・課題
インフラグループが受け付ける問い合わせの内訳を調べたところ、作業依頼が約半数、トラブル対応が2〜3割を占めていました。
今回のPoCで扱った課題は以下の通りです。
作業依頼対応時の課題: 手順書の検索
Confluence内に100件以上の手順書があり、多様なシステムや状況に対応しています。しかし、タイトルだけでは適用範囲が判断しづらく、類似した手順書も複数存在します。そのため、メンバーによっては検索に時間がかかったり、適切な手順書を見つけられなかったりすることがあります。トラブル対応時の課題: 類似事例の検索
Slackの問い合わせチャンネル内には過去の対応履歴が1万件以上蓄積されており、トラブル対応の資産として活用しています。しかし表現の揺れがあるため、キーワード検索では関連する事例が見つからないことがあります。
Slack Botを導入してこれらの「探す」作業を支援することで、経験の浅いメンバーでも迅速かつ確実に対応でき、チーム全体の対応品質も底上げできると考えました。
3. つくったもの
3-1. 概要
Slackのリアクション機能を活用した検索Botを作成しました。問い合わせメッセージに特定のリアクション（絵文字）を付けると、Botが自動で手順書や類似事例を検索し、結果をスレッドに返信します。
| リアクション （絵文字） |
機能 | 検索対象 |
|---|---|---|
 |
手順書検索 | Confluence内の手順書 |
 |
類似事例検索 | Slackチャンネル内の過去スレッド |
3-2. 使い方
- 問い合わせチャンネルに届いたメッセージを確認
- リアクションを付ける
- 手順書を検索する場合:
- 類似事例を検索する場合:
- 手順書を検索する場合:
- Botが「検索中...」と返信
- 数秒～数十秒後、検索結果がスレッドに投稿される
3-3. 投稿メッセージ
検索結果は以下のような形式でスレッドに投稿されます。
手順書検索の場合
問い合わせ例
新しいRDSインスタンスを構築してほしいです。DB XXと同様の構成でお願いします。Staging環境用です。
投稿メッセージ
🔍 類似する手順書が見つかりました
類似度の高い上位2件:
1. RDSインスタンス構築手順（リンク）
類似度: 92%
新規RDSインスタンスを構築する手順です。パラメータグループやセキュリティグループの設定も含みます。
2. Aurora MySQL クラスター作成手順（リンク）
類似度: 78%
Aurora MySQL互換クラスターを作成する手順です。パラメータグループやセキュリティグループの設定も含みます。
類似事例検索の場合
問い合わせ例
Staging環境でServer-XXXが起動しません。エラーログを確認したところ、ディスク関連のエラーが出ています。
投稿メッセージ
🔍 類似事例が見つかりました 類似度の高い上位3件: 1. Staging環境でServer-XXX起動時にエラーが発生、 ディスク容量不足が原因でログクリーンアップで解決（リンク） 類似度: 87% | 投稿: 2025/11/15 14:30 2. Staging環境でServer-YYYが起動できない問題が発生し、 Auto Scalingグループの設定重複が原因だった（リンク） 類似度: 82% | 投稿: 2025/10/22 09:15 3. Production環境でServer-ZZZが起動しない事象、 AMI更新後の設定漏れが原因（リンク） 類似度: 78% | 投稿: 2025/08/03 16:45
3-4. システム構成
構成イメージ
インフラグループメンバーがリアクションを付けると、Lambdaが必要な情報を検索・選定し、Amazon Bedrockが結果を要約します。
手順書検索
類似事例検索
技術スタック
主要な技術スタック（クリックで展開）
| レイヤー | 技術 |
|---|---|
| 実行環境 | AWS Lambda（Python 3.13） |
| イベント受信 | Lambda Function URL |
| LLMモデル | Amazon Nova Lite（Amazon Bedrock） |
| ベクトル埋め込み | Amazon Titan Text Embeddings V2 |
| 手順書検索 | Confluence Cloud REST API |
| チャット連携 | Slack API（Events API / Web API） |
4. 技術的なポイント
4-1. 検索アプローチ
今回のPoCでは検索機能の有効性を検証する目的で、以下の方針で実装しました。
- シンプル優先: 最初から高度なシステムを作り込まず、まずは動くものを作って評価する。検索の精度が不十分なら、ベクトルDBなどの専用ストアの導入を検討する。
- コスト最小化: 生成AIを使うシステムは高額になりがちだが、用途を絞り込んで低コストで実現する。
この方針のもと、手順書・類似事例ともに以下の3ステップで検索機能を実装しました。
4-2. キーワード検索の精度向上
手順書をキーワード検索で探す際、同義語で書かれた手順書が見つからない問題に遭遇しました。例えば「スケールアップ」で検索しても、タイトルが「インスタンスタイプ変更」の手順書はヒットしません。この問題に対し、以下の改善で検索精度を向上させました。
- キーワード辞書の拡充: 「スケールアップ」で検索する際、「インスタンスタイプ」「変更」も含めて検索
- 日英キーワードの両対応: 「Staging」と「ステージング」を両方検索
- タイトル＋本文の2段階検索: タイトルと本文を別々に検索し、結果をマージ
4-3. 文脈的に関連性の高い結果を優先的に表示
当初はキーワード検索（Step 1）のみで検索機能を実装する予定でしたが、実際に使ってみると以下の課題が見つかりました。
- 表現の揺れに弱い: 「起動できない」で検索しても「起動しない」と書かれた手順書や過去事例が見つからない。
- キーワード一致＝関連性の高さではない: キーワードがマッチしても、文脈が異なれば求めている情報ではない。
そこで、Step 2で問い合わせ文と検索対象のテキストをベクトル化し、意味的類似度を計算することで、キーワードが完全一致しなくても文脈的に関連性の高い結果を優先的に表示できるようにしました。
4-4. 類似事例検索の時間短縮
Slackチャンネルには10年以上・計1万件以上の問い合わせメッセージが蓄積されています。全期間を検索対象にすると、ヒットしたすべてのメッセージに対して意味的類似度計算が必要となり、さらにSlack APIのページングやレートリミットの制約も加わって、処理時間が増大しました。実際、Lambdaの実行時間が60秒を超えてタイムアウトするケースが発生しました。
そこで、段階的検索を導入しました。
- まず1年以内の履歴を検索し、類似度計算を実施
- 予め定めた閾値以上の結果が見つからなければ5年以内に拡大
- それでも見つからなければ全期間を検索
これにより、新しい事例を優先的に表示しながら、多くのケースで検索時間を大幅に短縮できました。
4-5. コスト
月30回（手順書検索）+ 月20回（類似事例検索）の検索を想定した場合、Amazon Bedrockの利用料金は月額約15円程度です。LambdaやCloudWatch Logsなどの利用料金を含めても、全体で月額200円以下に収まる見込みです。
5. 得られた成果
現在、チーム内でフィードバックをもらいながらブラッシュアップを進めている段階ですが、すでに下記の成果を確認しています。
5-1. 実用的な検索精度
PoCの有効性を確認するため、実際の問い合わせを想定した評価を実施しました。具体的には、「EC2インスタンスのスケールアップをお願いします」のような依頼と、それに対応する正解の手順書や類似事例スレッドの組を各20組用意し、検索結果の精度を測定しました。 検索結果と正解を目視で確認したところ、以下の結果となりました。
- 手順書検索: 20件中16件が正解（的中率 80%）
- 類似事例検索: 20件中18件が正解（的中率 90%）
※検索結果の上位3位以内に正解が含まれていれば的中と判定しました。
完璧ではありませんが、メンバーが手作業で探していた情報を提示できるようになり、「探す作業の起点」としては十分に機能することが確認できました。
5-2. 「探す」時間の短縮
これまで数分かかっていた「手順書を探す」「過去の事例を探す」作業が、数秒～数十秒で完了するようになりました。特に経験の浅いメンバーにとって、最初の一歩を踏み出しやすくなりました。
6. 今後の展望
6-1. 検索精度の継続的改善
実際の担当者による利用を通じてフィードバックを収集し、閾値やキーワード辞書などの継続的な改善をしていきます。また、検索精度をさらに高める必要が生じた場合や、複数データソースの横断検索などが求められる場合は、ベクトルDBを用いたRAGアーキテクチャの導入も検討します。
6-2. 新たな取り組み：インシデント対応支援Slack Bot
次のステップとして、インシデント発生時の情報収集を支援するSlack Botの構築に挑戦したいと考えています。
今回の手順書検索や類似事例検索は「検索して結果を返す」というシンプルな処理でした。一方、インシデント対応では状況に応じて適切なアクションを選択する必要があります。例えば以下のような判断です。
- 段階的なトラブルシューティング
- アプリケーションエラーを検知したら、まずログを確認
- ログにDB接続エラーがあれば、データベースの接続プール状況を調査
- 接続プールが枯渇している場合、実行中のスロークエリを特定
こうした判断を臨機応変に行うには、AIエージェントとしての実装が求められます。Amazon Bedrock Agentsの活用を検討する予定です。
7. まとめ
Amazon Bedrockを活用したSlack Botにより、インフラ問い合わせ対応の「探す」作業を効率化できました。Slackのリアクションという直感的なUIと、キーワード検索・意味的類似度・生成AIを組み合わせたシンプルな仕組みで、月額200円以下という低コストながら実用的な検索精度を実現しています。
今回のPoCを通じて、最も重要だと感じたのは「完璧を目指さず、小さく始めて改善を繰り返す」ことです。
最初はキーワード検索だけで十分だと考えていました。しかし実際に動かしてみると、同義語や表現の揺れに対応できないことが分かりました。そこで意味的類似度の計算を追加し、さらに段階的検索を導入する。このような試行錯誤の積み重ねが、結果的に実用的な検索精度につながりました。
生成AIは「高度なRAGシステム」や「複雑なプロンプトエンジニアリング」がなくても、十分に価値を発揮できます。まずは手元の課題に対してシンプルに試してみる。そのハードルは、思っているより低いかもしれません。
本記事が、生成AIを活用した業務効率化に一歩踏み出すきっかけとなれば幸いです。
8. We are hiring
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
open.talentio.com open.talentio.com
open.talentio.com open.talentio.com
