はじめに
この記事自体も、実際に作成した社内QA Bot と同様に生成AIを活用しながら整理・執筆しています。
構成整理や文章のたたき台生成には Claude / ChatGPT を活用していますが、実際の設計・運用・ハマりどころは実体験ベースです。
社内問い合わせ対応をしていると、こんなことありませんか？
- 「〇〇の移管手順ってどうでしたっけ？」
- 「その件、前にも説明した気がする…」
- 「Wikiに書いてあったはずだけど見つからない」
- 「Slack の過去スレを掘るのがつらい」
自分は AWS 請求代行サービス（リセール）の運用を担当しているのですが、問い合わせ対応のかなりの時間を、
- Backlog Wiki を探す
- Slack の過去ログを探す
- 同じ説明を何度もする
ことに使っていました。
そこで、
「もう AI に全部読ませて答えさせればよくない？」
という発想で、Slack から質問すると Backlog Wiki を参照して回答してくれる Bot を作りました。
しかも、月額だいたい 10ドル程度 です。
何を作ったのか
Slack で @bot メンションすると、Backlog Wiki を検索して回答してくれる Bot です。
構成はかなりシンプルです。
Slack（質問）
↓
ECS Fargate（Python + Slack Bolt for Python）
↓
Amazon Bedrock（Claude）
↓
Backlog Wiki
ポイントは、
- 「完璧な AI」
- 「巨大な RAG 基盤」
を目指さなかったことです。
まず困ったのは「検索が遅い」こと
最初は素直に、
- Slackで質問を受ける
- Backlog Wiki API を検索
- Claude に回答生成させる
という流れで作りました。
でも、これが遅い。
かなり遅い。
UX 的には完全に負けでした。
ユーザーからすると、
「Bot 呼んだのに無反応」
が一番不安になります。
そこで S3 に「ベクトルキャッシュ」を作った
最終的にこんな流れにしました。
やっていることはシンプルで、
- 毎日深夜に Wiki を取得
- ベクトル化して S3 に保存
- 質問時はまず S3 側で高速検索
- 必要な Wiki だけ本文取得
という構成です。
効果
これで体感速度がかなり改善しました。
特に、
「まず候補を絞ってから本文を取りに行く」
のが効きました。
「即レス」が UX をかなり変えた
もうひとつ効いたのがこれです。
Bot はまず即座にこう返します。
少々お待ちください。 現在 Backlog Wiki を確認しております...
その後、数秒後に chat.update で回答に置き換えます。
たったこれだけなんですが、ユーザー体験がかなり変わりました。
生成 AI 系って、
- 実際の回答精度
- レスポンス速度
以上に、
「待たされてる感」
が UX に直結する気がしています。
技術スタック
| コンポーネント | 技術 |
|---|---|
| Bot本体 | Python + Slack Bolt |
| 生成AI | Amazon Bedrock（Claude） |
| ナレッジ | Backlog Wiki |
| 実行環境 | ECS Fargate |
| IaC | Terraform |
| ログ | CloudWatch Logs |
やったこと / やらなかったこと
やったこと
Wiki を本気で整備した
実は一番効いたのは AI よりここでした。
- 移管手順
- FAQ
- 制限事項
- 運用ルール
などを 30ページ以上整備。
結果として、
「Bot に答えさせるために人間が Wiki を書く」
という流れが生まれました。
これはかなり大きかったです。
やらなかったこと
複雑な RAG パイプライン
やってません。
運用が重くなるので。
100% 正しい回答
目指してません。
この Bot は「一次回答用」です。
最終確認は人間がやる前提にしています。
月額コスト
かなり安いです。
| 項目 | 月額 |
|---|---|
| ECS Fargate | 約 $5 |
| Amazon Bedrock | 約 $3〜5 |
| 合計 | 約 $10/月 |
ランチ1回分くらいです。
実際に得られたもの
定型問い合わせの削減
かなり楽になりました。
特にオンボーディング。
新人メンバーがまず Bot に聞けるので、心理的ハードルも下がりました。
ナレッジ文化が回り始めた
これが一番大きかったかもしれません。
以前は、
「Wiki 書いても誰も見ない」
状態でした。
でも Bot が参照するようになると、
「Wiki に書けば Bot が答えてくれる」
になる。
結果として、
- Wiki が増える
- 「AIが読み取りやすい書き方」を意識して内容が整理される
- Bot の回答精度が上がる
- さらに Wiki が活用される
という循環ができました。
生成AIの「勝ち筋」はここだと思う
この仕組みを作って感じたのは、
AI の価値は「完璧な回答」ではなく「一次回答の高速化」
だということです。
そして、そのためには AI 単体ではなく、
- ナレッジ整備
- 検索しやすさ
- 運用しやすさ
の方がむしろ重要でした。
今後やりたいこと
今後はさらに、
- 回答精度の継続改善
- 問い合わせ傾向の分析
- レポート自動生成
- 他チーム展開
なども試していきたいと思っています。
特に、
「問い合わせ内容そのものを分析して改善につなげる」
ところまで回せると面白そうです。
まとめ
- 「またこの質問か…」を AI で減らした
- 重要なのは完璧さよりスピード
- ナレッジ整備と生成 AI は相性がいい
- 小さく作って運用しながら育てるのが大事
もし社内問い合わせ対応で困っているなら、
まずは月10ドルくらいで、小さく始めてみるのおすすめです。
余談：途中で Kiro から Claude Code に切り替えた
ちなみに、この Bot の開発は当初 Kiro を使って進めていました。
ただ、実装が大きくなるにつれて修正がうまくいかず、変更後に元へ戻すケースが徐々に増えてきました。
そこで途中から Claude Code に切り替えました。
一方で、Kiro は AWS 関連のドキュメント作成や構成整理にはかなり強く、今でもその用途ではよく使っています。
生成AI系の開発支援ツールって、
「どのツールが良いか」
というより、
「今の用途や開発フェーズに合っているか」
が大事なんだなと感じました。