【要約】SlackにAWSで社内文書RAGボットを作った話【全手順まとめ】 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
社内の規定やマニュアルが増大し、情報の検索に多大なコストがかかっている。
- ・情報の散逸：規定の所在が不明で、検索に時間がかかる。
- ・対人コスト：人に聞く行為が、双方の生産性を低下させる。
- ・Slackの制約：Events APIは3秒以内の応答が必須である。
- ・実装の不安定さ：外部ライブラリへの依存が、ビルド失敗を招く。
// Approach
AWS Bedrockを活用し、サーバーレスで堅牢なRAG基盤を構築した。
- ・非同期2段構成：bot-handlerが即時応答し、重い処理を分離する。
- ・依存関係の排除：署名検証を標準ライブラリで実装し、Lambdaを軽量化する。
- ・環境変数の徹底：固有値をコードに含めず、設定ミスを構造的に防ぐ。
- ・UIの最適化：長い署名付きURLを、Slackのボタン形式で提供する。
// Result
検証により、Slack上でのスムーズな対話と参照元表示を実現した。
- ・検索体験の向上：メンションのみで、回答と参照元が取得できる。
- ・運用の安定化：依存ライブラリを排除し、デプロイ時のリスクを低減した。
- ・UXの改善：ボタン形式により、長いURLの表示崩れを解消した。
Senior Engineer Insight
> 実戦的な設計だ。Slackの3秒制約をLambdaの非同期呼び出しで解決する構成は秀逸である。また、依存ライブラリを排除しデプロイの堅牢性を高める判断も、運用を見据えたものだ。ただし、大規模環境ではLambdaの同時実行数やBedrockのクォータ管理が課題となる。