インフラ問い合わせ対応をAmazon Bedrock×Slack Botで効率化した事例

参考になった

レビュー投稿日の情報になります

Sansan株式会社 / 白井達也

テックリード / インフラエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名

最終更新日2026/03/01投稿日2026/03/01

アーキテクチャ

アーキテクチャの意図・工夫

シンプル・低コストな構成

シンプルな構成で小さく始めて、評価と改善を繰り返す方針で設計しました。また、固定費のかからないサーバーレスなサービス（Lambda・SQS・Amazon Bedrock）のみで構成することで、試行錯誤のコストを最小限に抑えています。回答精度が不十分であれば、Knowledge Basesやベクトルデータベースを導入し、より高度な検索・取得の仕組みへ発展させる余地も残しています。

モデルの使い分け

用途に応じて下記のモデルを使い分けました。Amazon Bedrockは共通のAPI経由でモデルを呼び出す仕組みであるため、モデルIDを変更するだけで別モデルへ切り替えることができます。将来的により高性能なモデルが登場した際にも柔軟に対応できます。

モデル	用途	選定理由
Amazon Nova Lite	リランキング・要約	低コストかつ十分な日本語理解力を持つ。 Claude 3 Haiku等の他モデルと比較しても日本語の要約精度とコストパフォーマンスのバランスが最も優れている。
Amazon Titan Embeddings V2	ベクトル化・類似度計算	Amazon純正の埋め込みモデルであり、低コストで利用可能。512次元・正規化済みベクトルによりコサイン類似度を単純なドット積で計算できる。多言語対応に強いCohere Embed Multilingualの利用も検討したが、今回はPoCフェーズであったため、Marketplaceサブスクリプション等の追加の手続きなく利用できる純正モデルで精度を検証し、不足すれば切り替える方針とした。

タイムアウト・リトライ対策

Slack Event APIには「3秒以内に応答しないとリトライされる」という制約があります。一方で、本Slack Botの検索処理には数秒〜数十秒かかるため、応答が間に合わず、タイムアウトによる重複処理が発生します。この課題に対して、SQS FIFOキューを用いた非同期処理で対応しました。具体的には、受信用Lambda関数（Webhook）がHTTP 200を即座に返却し、実際の検索処理はSQS経由で別のLambda関数（Processor）が担当します。また、SlackのイベントIDをSQSの重複排除キーとして使用することで、リトライ時の重複実行を防止しています。加えて、SlackのチャンネルIDを順序制御のキーに指定し、同一チャンネル内のイベント順序を保証しています。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

我々インフラチームでは、社内からの問い合わせ（月50件程度）をSlack上で受け付けて対応しています。
対応ナレッジはConfluence（手順書100件以上）とSlack（過去対応履歴10年分・1万件超）に蓄積されており、運用やトラブル対応時の資産として活用していますが、これらのナレッジを活用する上で以下の課題がありました。

課題	説明	具体例
手順書の検索に時間がかかる	タイトルだけでは適用範囲が判断しづらく、類似した手順書も複数存在する。適切な手順書にたどり着くまでに時間がかかる。	「RDSインスタンスの作成」に関する手順書が環境別・パターン別に複数あり、どれを参照すべきか判断に迷う。
過去事例が見つからない	表現の揺れがあるため、キーワード検索では関連する事例がヒットしないことがある。	「スケールアップ」と「インスタンスタイプ変更」のように、同じ作業でも表現が異なると検索でヒットしない。
検索スキルの属人化	経験の浅いメンバーは「どの手順書を見ればいいか」「どのキーワードで検索すればいいか」の判断自体が難しい。	ベテランなら心当たりのある手順書にすぐたどり着けるが、経験が浅いと検索の起点がわからない。

どのような状態を目指していたか

Slackのリアクション操作で手順書や過去事例を効率的に検索できるBotを構築し、以下の状態を実現することを目指しました。

これまで数分かかっていた手順書・過去事例の検索を数秒〜数十秒に短縮する。
キーワード検索では発見できなかった関連情報を、意味的な類似性によって発見できるようにする。
経験の浅いメンバーでも必要な情報に効率的にたどり着けるようにする。

比較検討したサービス

Amazon Bedrock
Azure OpenAI Service
Gemini for Google Workspace

比較した軸

コスト
- 従量課金制で固定費がかからないこと。PoCフェーズのため、検証時間帯以外に課金が発生せず、総コストを抑えられる構成にできること。
導入の容易さ
- 新たなクラウド環境の契約・学習が不要であり、既存のスキルセットで構築できること。
データの取り扱い
- 社内ナレッジを既存のセキュリティ境界内で取り扱えること。

選定理由

PoCフェーズのため、少ない工数で導入できることを最重視しました。インフラチームにはAWSの利用実績・ノウハウが豊富にあり、Amazon Bedrockであれば既存のAWSインフラをそのまま活用でき、学習コストを抑えて短期間で導入できると判断しました。

導入の成果

改善したかった課題はどれくらい解決されたか

課題であった手順書検索および類似事例検索の速度・精度について、以下のように改善しました。

項目	Before	After
手順書検索	・数分（Confluence内を手動で検索）・見つからないケースあり（類似手順書の判別に苦労）	・数秒〜数十秒・的中率80% ※1
類似事例検索	・数分（Slack内を手動でキーワード検索）・見つからないケースあり（同義語問題）	・数秒〜数十秒・的中率90% ※1

※1 実際の問い合わせを想定した各20組のテストケースで評価。上位3位以内に正解が含まれれば的中と判定。

どのような成果が得られたか

月額コストは200円以下で運用できています。
- 前提: 月30回の手順書検索 + 20回の類似事例検索
Amazon Bedrockに関する知見が蓄積でき、今後の類似プロジェクトへの応用の土台を構築できました。

導入時の苦労・悩み

Amazon Bedrockの導入時に遭遇した課題とその対応策をご紹介します。

(1) Nova Liteの出力フォーマット制御

課題 JSON形式での出力を指示してもマークダウンのコードブロックで囲んで返されることがありました。

対応 LLMの出力形式は完全には制御できないため、防御的な実装として、全Amazon Bedrock呼び出しメソッドへのコードブロック除去処理の追加と、パース失敗時のエラーハンドリングを行いました。

(2) Nova Liteの出力件数・内容の変動

課題「N件をすべて要約」の指示に対し、件数不足や要約粒度のばらつきが見られました。

対応 LLMが指示通りに動作しない前提で、AI要約が不十分な場合、Confluenceの抜粋テキストで代替する処理を実装しました。

(3) Embeddings類似度とリランキングの閾値調整

課題 Amazon Titan Embeddings V2のコサイン類似度のみでは、業務的に適切な結果を返せないケースがありました。
例えば、「RDS作成」の問い合わせに対して「RDS削除」の手順書が高スコアで返されてしまいました。

対応ベクトル検索だけでなく、LLMによる再評価（リランキング）を組み合わせることで精度を高めました。

Embeddings類似度で上位N件に絞り込み
Nova Liteで3軸（作業種別・環境・サービス名）の優先順位付きリランキング
閾値フィルターを適用

(4) 大量データの検索に伴うタイムアウト対策

課題 Slackの過去ログが1万件を超えており、全件を対象に類似度計算を行うとレスポンス速度が低下しました。

対応検索対象を「直近1年」→「5年」→「全期間」と段階的に広げるロジックを実装しました。
新しい事例を優先しつつ、必要な場合にのみ検索範囲を広げることで、レスポンス速度と網羅性を両立させました。
なお、検索対象のベクトルデータは事前にDBへ保存せず、Slackから取得した最新のテキストデータをその場でベクトル化して計算しています。
あえてDBを持たないことで、月額200円という低コストでの運用を実現しました。

導入に向けた社内への説明

上長・チームへの説明

サーバーレスなサービスのみで構成することで短工数・低コスト（月200円以下）で試せる見込みであることを説明しました。
また、当社では AIファーストを掲げており、組織としてAI活用のPoCを推進しやすい土壌があったため、スムーズに承認を得ることができました。

活用方法

よく使う機能

モデルの呼び出し（Converse API / InvokeModel API）
- Converse APIはどのモデルでも同じ書き方でテキスト生成を呼び出せるAPIです。
- InvokeModel APIはEmbeddingsなどモデルごとに異なるパラメーターを指定して呼び出すAPIです。

ツールの良い点

小さく始めやすいコスト構造
- 従量課金で固定費がかからないため、呼び出し回数が少ないPoCフェーズ等においてコストを最小限に抑えられます。私たちの利用規模（月50回程度の検索）では200円以下で運用できています。
モデルID指定でのモデル切り替え
- 設定ファイルのモデルIDを変更するだけで別モデルに切り替えられます。新しいモデルが出たときなどに気軽に試せる点が重宝しています。
CloudWatch Logsでの呼び出しログ確認
- Amazon Bedrockの呼び出しログはCloudWatch Logsで確認できるため、他のAWSサービスのログと同じ要領で調査やデバッグが行えます。

ツールの課題点

埋め込みモデルの日本語精度
- Amazon Titan Embeddings V2は英語に比べて日本語の検索精度が劣るため、閾値調整をしたり同義語辞書を整備することで補う必要がありました。
クォータの不透明性
- スロットリング発生時に出力されるエラーメッセージからは、RPM（リクエスト/分）とTPM（トークン/分）のどちらに抵触したかを特定できないようです。CloudWatchにもRPMやTPMの消費量に関する直接的なメトリクスがなく、原因調査に手間がかかります。PoC用途では大きな問題になりませんでしたが、本番環境でスケールさせる場合には、クォータ監視の仕組みを別途用意する必要がありそうです。

ツールを検討されている方へ

既にAWSをご利用であれば、Amazon Bedrockは追加契約なしですぐに試せます。最初からベクトルDBを構築する必要はなく、Embeddingsによる類似度計算＋LLMによる要約というシンプルな構成でも実用的な検索精度を得られる可能性があります。月額数百円程度で運用できるため、まず小さく始めて効果を検証するのがおすすめです。