マニュアル作成・共有サービスにおけるBedrock活用事例
株式会社スタディスト / corrupt952
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
ツールの利用開始時期 | 事業形態 |
---|---|
2024年2月 | B to B |
アーキテクチャ
![アーキテクチャ図](https://cdn.findy-tools.io/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBZkE9IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--f56c4f4302188e598b2574f0a9d64d28c7fc4048/%E5%90%8D%E7%A7%B0%E6%9C%AA%E8%A8%AD%E5%AE%9A%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB.drawio%20(1).png?disposition=inline)
アーキテクチャの意図・工夫
一般的なDBアクセスなどと比べてLLMは決して速くはありませんし、クライアントから呼び出されるAPIから直接LLMを実行するのはあまり好ましくありません。
ChatBotのような仕組みであればWebSocketを利用しますが、そうでない場合の多くが特定の形式(JSONなど)を出力させていることもあり、非同期処理基盤でLLMと通信し、変換・加工を行ってクライアントに返すような仕組みにしています。
これをStreamで処理するのは複雑さの割にメリットが現時点では少ないだけなので、ChatBotのような仕組みやすぐに返ってくるようなケースではそのまま通信するケースもあります。
導入の背景・解決したかった問題
導入背景
スタディストのサービスであるTeachme Bizでは、効率的なマニュアル作成・共有を提供するサービスとして、常にお客様の課題に向き合い、新しい技術を含め解決策を模索し続けています。
AI技術の進歩により、マニュアル作成プロセスの大幅な効率化が可能になると考え、LLMの導入を決定しました。
主な導入理由は以下の3つです。
- マニュアル作成時間の短縮
- 品質の一貫性向上
- ユーザー体験の改善
当初は他社サービスを利用していましたが、安定性やデータセキュリティの課題から、より信頼性の高いサービスを求めていました。
Amazon Bedrockは、これらの課題を解決し、さらなる機能拡張の可能性を提供する最適な選択肢でした。
ツール導入前の課題
当初は他社サービスを利用していましたが、以下の課題や問題がありました。
- モデルのサポート方針の不安定さ
- 言語モデルによって利用リージョンの切り替えが必要
- モデルの他リージョンへの展開が不確実
- 生成AIログの強制保存
- 30日間のログ保存と他社によるデータ閲覧の可能性
- 保管場所が日本以外で、当社サービス利用規約との整合性に課題
- オプトアウト申請の長期化(8ヶ月以上否認)
- サービスの不安定さ
- 頻繁な負荷高判定によるリクエスト処理の遅延
- 過剰なコンテンツフィルタ
- 日によってコンテンツフィルタにひっかかるケース、そうでないケースがある
- 「包丁の研ぎ方について教えて」といったものが、フィルターにひっかかりエラーになる日とそうでない日があった
どのような状態を目指していたか
LLMを利用した機能のリリースも控えていたこともあり、導入前の他社サービスでの課題を解消できることを目指していました。
- 安定したサービス提供
- データセキュリティの向上
- 明確なモデル展開方針
比較検討したサービス
- OpenAI
- Azure OpenAI
比較した軸
- モデルの展開方針
- ログ強制保存の有無
- 安定した可用性
選定理由
- 当社サービスはAWS上で構築されているため親和性が高い
- AWSの明確なリージョン展開方針(バージニアから東京へ)
- ログの強制保存がなく、簡単にオプトアウト可能
- 安定した可用性
導入の成果
改善したかった課題はどれくらい解決されたか
- モデルの展開方針
- 解決
- ログ強制保存の有無
- 解決
- 安定した可用性
- 恐らく解決
- 過剰なコンテンツフィルタ
- 解決
どのような成果が得られたか
- リージョンのサポート方針の明確化
- AWSの段階的な東京リージョン展開により、サービス提供の計画が立てやすい
- データセキュリティの向上
- ログの強制保存がなくなり、サービスの利用規約との整合性が確保
- モデル呼び出しのログ記録はデフォルトで無効のため
- 海外リージョンを利用していてもログ記録を無効にしていれば、海外リージョンに顧客データが保管されない
- 不正検出が全て自動で行われ、異常検知時にもAWSの社員が閲覧することがない
- 安定した可用性
- 他社サービスと比較して、全体的なエラーが大幅に減少し、サービスの安定性が向上
- 性能面
- モデルの話かつ具体的な数値はありませんが、上長・チームへの説明時に「悪くなっていない、むしろ良い」という評価
- 過剰なコンテンツフィルタがない
- 他社サービスと比べてですが、過剰かつ毎日結果が変わるようなコンテンツフィルタがないため、こちらで比較的コントロールがしやすい
導入時の苦労・悩み
私がスタディスト以外でのLLM関連の開発経験もあり、特に大きな問題もなくスムーズに移行できました。
他社サービスからの移行もパラメータは類似性が高いので、特に問題にはならないと思います。
ただし、以下の点には注意をする必要がありました。
- 言語モデルに最適化したプロンプトの場合、動作検証を含めた移行に問題が生じる可能性
- 言語モデルが変わったことによる出力結果の差異
弊社では特に問題にはなりませんでしたが、この点が苦労する場合もあります。
導入に向けた社内への説明
上長・チームへの説明
サービスが変わることによる言語モデル性能が論点として挙がりました。
そのため、1日で切り替えたバージョンのアプリケーションをデプロイし、実際に触ってもらって問題ないかどうかを体験してもらい納得感のある形で進めました。
活用方法
よく使う機能
- マニュアル半自動作成機能の一部の処理
- 文章の校正・言い換え
ツールの良い点
- AWS環境との親和性の高さ
- SDKを利用して他社サービスと似たようなパラメータでリクエストが可能
- データセキュリティとコンプライアンスの確保が明確かつ担保しやすい
- 明確な言語モデルの展開方針
- 比較的安定したレスポンス
- 過剰なコンテンツフィルタがない
ツールの課題点
- APIドキュメントのパラメータと実際の挙動が異なるケースがある
- Rate Limitがやや厳しいケースがある
- Guardrails for Amazon Bedrockは英語以外の言語に対してコンテンツフィルタの性能が弱い
ツールを検討されている方へ
Amazon Bedrock導入を検討する際は、まず自社のニーズと優先事項を明確にすることが重要です。
サービスの安定性、データセキュリティ、将来的な拡張性が主な検討ポイントとなります。
特にAWS環境との親和性が高いため、既存のAWSサービス利用組織にとっては魅力的な選択肢となり得ます。
これらが問題なければ、LLMを触ったことがある人であれば簡単に利用を開始することができます。
今回の話については、弊社若松がAWS Summitで「生成AIと共にビジネスを変革する:注目スタートアップのAmazon Bedrock活用事例」という内容で登壇しているのアーカイブやスライドを見てみてください。
また、Amazon Bedrock で文書作成・管理をサポート。AI による新機能を実現したスタディスト社の事例といったAWS Startup ブログも公開されているので興味があれば見てみてください。
今後の展望
現在、Amazon Bedrockをマニュアル作成・編集の効率化に活用していますが、今後はさらに機能を拡張する予定です。
具体的には、マニュアルの閲覧や管理機能にもLLMによるサポートを導入し、ユーザー体験の向上を目指します。
また、Claude 3 Sonnet以外のモデルの検証も進めており、各タスクに最適なモデルの選定や組み合わせにも取り組んでいく予定です。
株式会社スタディスト / corrupt952
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
よく見られているレビュー
株式会社スタディスト / corrupt952
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法