弁護士ドットコム株式会社 Creators’ blog

弁護士ドットコムがエンジニア・デザイナーのサービス開発事例やデザイン活動を発信する公式ブログです。

散らばった情報をAIでつなぐ : Dify × Amazon Bedrockで構築した社内知識検索の導入と効果

こんにちは。クラウドサインでバックエンドエンジニアをやっている(𝕏@kunihikot)です。 最近はスト6にはまっていてハイマスターまで上がりました。対戦よろしくお願いします。

さて、本題のほうですが、私は普段クラウドサインのリアーキテクトや負債解消みたいなことを主にやっていて、プロダクトへの LLM 利用などに積極的に関わる立場ではありません。 そんな私が Dify を導入しようと思った経緯や、基盤構築までの流れ、リリースしてみて実際どうなのかみたいなことを書いていこうと思います。

背景と課題

弊社には Day0 というイベントがありまして、これは平たく言うと自由研究の発表会みたいな日で4半期に一度程度開催されます。 クラウドサインで働く人は職種を問わず月に2回ある Focus Day という日を使って好きなことを調べたり何か作ったりしてこの Day0 で発表するという感じです。

昨年の9月の Day0 で私は「クラウドサインについて何でも教えてくれる AI がほしい」というタイトルで発表しました。 内容としては下記のようなものでした。

  • 社内のプロジェクトでたまに知らない用語とか出てくるよね(コードネームや滅多に触れない機能名)
  • 「高度な管理機能」って聞いて何ができるかすぐ分かりますか?
  • helpdesk で顧客から問い合わせたが来たけど、こんな機能触ったことないよ・・みたいなことないですか?

これらを解決するのにローカルで動く LLM + Dify を使ってみよう という感じで簡単なデモを作って発表した結果 「この AI いち早く欲しい」 「運用まで持っていってくれればカスタマーサポートで効率が上がりそう」「 helpdesk の問い合わせで困った経験があるので社内ツールのひとつとしてとても欲しい」 などの声が上がり、1ヶ月後にプロジェクトとしてスタートすることになりました。

技術選定と検証

片手間で一人でやると色々と大変なので、SREの方々に協力してもらいながら進めていきました。 まず最初にやったことは

  • 話し合いのベースにするための簡単な構成図の作成
  • だいたいのランニングコストの試算
  • やろうとしてることが本当に可能なのかという技術検証
  • プロジェクト名を Deborah に決定

あたりでした。

また、クラウドサインでは、サービスの実行基盤として Amazon ECS (以降 ECS) を普段使っているのですが、今回は Amazon EKS (以降 EKS) を使ってみようということになりました。 理由としては

  • 複数のアプリケーションを管理しやすくするパッケージ管理ツールの helm が有用そう
    • ECS のタスク定義より手数が少なそう
  • お互い片手間でやっているので新しいものを使ったほうがモチベーションが上がるし、知見がたまる

という感じです。

色々と検証が終わり、予算も通り、技術的にも問題ないということで本格的に進めることになりました。 この時点では GPU インスタンスを使いvLLMを利用して色んな LLM を試してみていました。

vLLMからBedrockへ

ひと通り環境構築も終わり、vLLM の API との繋ぎこみも終わったあたりで、AWS の方から Bedrock セミナーの案内があったので参加することにしました。 Deborah プロジェクトではISMAP周りの制約もありサードパーティの LLM に社内データを投げることは許可されないだろうなぁと思っていたのですが、セミナー内で 「モデル自体をトレーニングしない場合は送信されたデータが蓄積されることは一切ない」ということが強調されていたので、これはもしかしたら使えるかもしれないなと思い、セミナーの当該内容のスクショと共に上長に相談してみたところ「使って問題ない」という回答をいただき、予算も試算してみたところ大きな金額にはならなさそうなのでvLLMはやめてBedrockを使うように方針を転換しました。

GPU インスタンス を使う場合、EKS の細かい設定調整が必要でそこに苦戦していましたが、Bedrock を使うことで GPU インスタンス不要にできたことは運用コストを抑えられて良かったかなと思っています。

実装詳細

データソースの選定

プロダクト情報の横断検索のため、社内に存在する資料を RAG(Retrieval-Augmented Generation)として利用することになりました。データソースは以下のように決定しました。

  • esa の記事
    • ただし、記事は玉石混交であるため「あるパスの下の記事全て」というやり方はまずそうなので専用のタグを打ってそれを使う
  • クラウドサインヘルプセンターの記事

これらを定期的に取得したり、削除されていればDify側からも削除するようなバッチを作成しました。

パイプライン構成

テンプレートの Knowledge Retrieval + Chatbot のパイプラインをほぼそのまま使っています。 このパイプラインでは以下のような流れでユーザーの質問に回答します

  1. ユーザーからの質問を受け取る
  2. 質問内容に関連するナレッジをベクトルDBから検索
  3. 検索された関連ナレッジとユーザーの質問をコンテキストとしてLLMに送信
  4. LLMが回答を生成

LLM は Claude 3 Sonnet を利用しています。

パイプライン構成図
パイプライン構成図

リリース

諸々リリースに必要な設定が終わったので、まずはエンジニア、PdM、デザイナー向けに先週リリースしました。 一週間前から本記事執筆時点で17人のユーザーが利用し、総会話数は23件でした。 クラウドサインの機能や仕様についての質問が多く、正しく回答できているものもあればハルシネーション(AIが誤った情報や架空の内容を生成する現象)を起こしているものもあるという感じです。 Deborah では引用元の記事IDを表示するようにしているので、ユーザーは元記事を確認できます。

スクリーンショット: Deborah がクラウドサインの監査ログ機能について回答している様子
スクリーンショット: Deborah がクラウドサインの監査ログ機能について回答している様子

質問:
  監査ログ機能について教えて

回答:

1. 定義:
   監査ログ機能は、「監査ログ閲覧権限」を持つユーザーが監査ログファイルをダウンロードできる機能です。

2. 目的:
   監査ログは、定期的に実施する「システム監査」において、サービスが問題なく運用されていることを客観的・合理的に証明するための記録です。

3. 記録対象:
   監査ログファイルには、クラウドサイン上で行われた特定の操作が記録されます。ただし、Web APIを通じて行われた操作は記録されません。

4. アクセス権限:
   この機能を利用するには、ユーザーに「監査ログ閲覧権限」が付与されている必要があります。

5. 利用方法:
   権限を持つユーザーは、監査ログファイルをダウンロードすることができます。

監査ログ機能は、クラウドサインのセキュリティと透明性を確保するための重要な機能の一つです。システムの適切な運用を証明し、必要に応じて過去の操作を確認することができます。

現在の検索対象記事数は esa が200記事、ヘルプセンターが300記事程度です。 esa とヘルプセンターの横断検索は非常に便利なのですが、まだまだ記事不足による回答の精度の低さが課題です。 また、記事の内容自体は良くても、メモ書きのようなもので検索に引っかかりにくかったりするものもあるのでソースとなる記事のクオリティを上げて社内ドキュメントを整備するのも重要だと認識しました。

あと、リリースタイミングでフィードバック用の Slack チャンネルを作っておきました。

今後の展望

回答精度向上

現状、望む回答を得られないケースがあったりするので対象記事を増やし、回答の精度を上げていくことが第一かなと考えています。 また、つい最近 Dify がバージョン1.0に上がったので、バージョンアップで増える機能にも期待しています。

利用促進策

触る習慣や「使って便利だった」という体験がないとユーザーは継続して使わないため、利用促進策も重要です。隔週程度で「対象記事の数がこれだけ増えました」「こういう使われ方の事例があります」といった情報を共有していく予定です。

下記のように使い方の提案なんかもどこかに書いても良いなと考えています。

  1. 新メンバーのオンボーディング: 「機能Xとは何ですか?」「ローカル環境でXXするにはどうすれば良い?」
  2. サポート業務の効率化: 「XXという質問を受け取った。この顧客からの問い合わせにどう答えるべき?」
  3. 開発者の疑問解決: 「XXという機能の仕様はどうなっている?」
  4. 横断的な情報検索: 「プロジェクトAとBの違いは?」

チャットボット以外の利用

Dify は様々なアプリケーションを構築できるので、単純な質問応答型のチャットボット以外の活用も検討しています。以下のような他社事例も参考にしています。

LLM x SRE: メルカリの次世代インシデント対応 ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例

ここまでやってきた感想

色々ありましたが、やってみた感想としては下記の通りです。

  • Day0 で発表したことがプロジェクトになり、リリースまでこぎつけることができたのはとても嬉しい
  • esa とヘルプセンターの記事を横断検索できるようになったのは便利
  • Dify のアップデート速度がとにかく速い。壊れたりもするけどすぐ直る
    • ダッシュボードでトークン消費量が確認できて便利
  • 有用な esa 記事にタグを付ける手伝いをお願いしたら色んな人が手伝ってくれて助かった
  • CRE チームから専用のアプリを作りたいという声がありアカウントを付与した。こういう流れが続くと盛り上がりそう
  • 普段関わりがほぼないリーガルブレインのチームの方に色々アドバイスがもらえて交流ができた

まとめ

  • 社内のナレッジ管理の重要性を再認識しました
    • AIツールの精度向上には質の高い基礎資料が不可欠であることが明確になりました
  • 横断検索機能の実現により、プロダクト情報へのアクセシビリティが向上し、業務効率化の第一歩を踏み出せました
  • リリースしただけでは積極的に使われるわけではないので、利用促進策も重要であることを認識しました
  • Day0 のような取り組みは、社内のアイデアを形にする機会として非常に有意義であることを再認識しました

Dify は様々な LLM との連携が簡単で、パイプラインの組み換えも容易です。何かを試して公開するのに手軽な環境ですので、同様の課題をお持ちの方はぜひ検討してみてください。