Amazon Web Services ブログ

Amazon Kendra を用いた社内ナレッジ共有の推進

この投稿は株式会社ブレインパッド リードデータサイエンティスト 岡田 直樹 氏に、 Amazon Kendra および AWS Lambda を活用した社内ナレッジ共有の仕組み化について寄稿いただいたものです。

はじめに

本稿では、「多くの企業が抱えるナレッジ共有の悩みを Amazon Kendra でどのように解消したのか？」をテーマに、ブレインパッドの取り組みを４つのポイントでまとめています。

  • 企業が抱えるナレッジ共有の悩みとは？
  • なぜ Amazon Kendra を採用したのか？
  • どのように実装したのか？
  • 便利なツールがあっても使われなければ意味がない、普及の壁をどう乗り越えたのか？

企業が抱えるナレッジ共有の悩みとは？

make_transfer_use

多くの企業は、多彩な領域で分業しながら成果を上げています。そのひとつひとつの業務の中で、日々、新しいアイデアやノウハウが生まれています。これらはいわゆる「ナレッジ」と呼ばれるもので、属人的に蓄積されていきます。このナレッジを社員や組織間で共有することができれば、関連業務で相乗効果が生まれ、業務の効率や品質は飛躍的に高まります。これがナレッジ共有の強みです。

しかし、ナレッジ共有には多くの壁が立ちはだかります。よくあるパターンは次のようなものです。

  • ナレッジ共有の時間を作ろう。
    →　主体的に関与する人材が少なく、忙しさから長続きしない。
  • 資料化して、いつでも見られるようにしよう。
    →　社内 Wiki や PDF など、多様な媒体にナレッジが分散して目的の情報が見つからない。
  • システムを導入してナレッジを集約しよう。
    →　新しいシステムにナレッジを入力してくれない。検索性が低くシステムが普及しない。

当社も同様の事態に直面していました。ナレッジ共有の本質的な問題は、ほとんどの社員はナレッジを入手することに強いニーズがある一方、コストをかけてまで自身のナレッジを提供することにモチベーションが小さいことです。ナレッジ共有の目的だけのために社員の行動を変えることは、容易ではありません。

また、ナレッジをどのように蓄積するかは、社員や部門それぞれに好ましいやり方があり、無理に統一しようとしてもナレッジ共有のモチベーションやパフォーマンスにはつながりません。経営的にはナレッジを集約したい一方、現場ではナレッジを分散して持ちたいという頭の痛い問題です。

当社において、これらの悩みを解消してくれたクラウドサービスが Amazon Kendra です。

なぜ Amazon Kendra を採用したのか？

collection_search_cost

Amazon Kendra は、社内情報を共通のインターフェースから検索できるクラウドサービスです。言うなれば、社内情報に特化した検索エンジンです。当社が Amazon Kendra を採用した理由は、３つあります。

（１）ナレッジ集約の便利さ

前節で言及したとおり、ナレッジは存在していても複数の媒体に分散しがちです。当社でも、社内 Wiki や各種ドキュメントファイルに散らばっている状態でした。この状況において、 Amazon Kendra は強力なコネクターを提供してくれています。グループウェアや Wiki、Microsoft PowerPoint や PDF など、数々の媒体のドキュメントを手間なく取り込むことができます。

つまり、ナレッジ共有のために社員がナレッジの蓄積方法を変える必要がありません。ナレッジの集約は、たとえ一時的に達成できたとしても、持続的な運用には多大なコストがかかります。これを自動化できる点は、当社にとって非常に望ましい要素でした。

（２）検索性の強さ

情報入力の利便性を追求したグループウェアや Wiki は、数多くあります。しかし、それらは情報出力、つまり検索性に弱点を有している場合が少なくありません。特に、日本語検索については顕著です。たとえば、英語であれば単語レベルのマッチングでそれなりの検索性が得られます。一方、日本語の場合は単語抽出の難易度が高く、適当な文字数で区切ってマッチングを取るケースが見られます。「東京都」と検索したとき、２文字区切りの「東京」「京都」で検索されてしまっては、求めるナレッジにたどり着くことは難しくなります。

Amazon Kendra では、機械学習を用いた検索性を提供しています。「技術　トレンド」といった従来のキーワード検索に加えて、「新技術の取り組みに関する情報が欲しい」といった自然言語検索はユーザー体験を大幅に向上してくれます。集めた情報を適切に検索できる点は、当社が Amazon Kendra を選んだ２つ目の理由です。

（３）運用コストの安さ

ナレッジの集約や検索に特化した IT ツールは、エンタープライズ検索システムと呼ばれています。これらのシステム導入におけるひとつの問題は、費用です。数百人規模の組織にシステム導入する場合、その運用コストは年間1,000万円を超えることもあります。ナレッジ共有の取り組みを気軽にはじめるには、安くない金額です。

Amazon Kendra は、一般的なエンタープライズ検索システムと比べて、遥かに安い金額で提供されています。前述したとおり、ナレッジ共有の取り組みは容易に実現できるものではありません。当社もスモールスタートを望んでいたため、 Amazon Kendra の運用コストの安さは取り組みを後押しするポイントになりました。

以上に加えて、 Amazon Kendra の実装の容易さと自由度の高さもまた、当社にとって大きなメリットになっています。次節では、当社の実装例をまとめています。

どのように実装したのか？

amazon_kendra

実装と言っても、大げさな開発工程はありません。Amazon Kendra の処理フローに従えば、ノーコードでも実装が可能です。ここでは、実装プロセスの５つのポイントをまとめます。

  • Data Source ～ ナレッジの蓄積
    当社では各部門・各社員が頻繁に勉強会を開催しており、その活動を通してナレッジが Wiki や各種ストレージといった複数の媒体に蓄積されていました。このとき、勉強会の情報を後から確認することは容易にできていました。しかし、特定の分野や技術に関する知見を横断的に抽出するためには、各媒体を隅々まで確認する必要があり、利便性に乏しい状態にありました。
  • Connector ～ ナレッジの集約
    Amazon Kendra のコネクター機能を使うことにより、社内に散らばったナレッジを Amazon Kendra にリンクさせ、横断的な検索性を実現できました。また、コネクターは、閲覧制限が付与されたアカウントを経由して読み込まれるため、セキュリティーに配慮した実装が可能です。
  • Search Engine ～ 情報の検索
    Amazon Kendra には動作検証用の検索画面が用意されているため、ドキュメントを読み込んだ直後から、どんな検索をしたらどんなナレッジが見つかるのか、ユーザーの利便性をいち早く確認することができました。この点は導入イメージを固める上で、非常に助かったポイントです。
  • Search UI ～ ユーザー向けの検索画面
    Amazon Kendra には、検索エクスペリエンスというユーザーへ検索画面を公開するための機能があります。この機能はノーコードで実装できるため、テスト導入でフィードバックを受ける際、大いに役立ちました。また、 Amazon Kendra は検索エクスペリエンスだけでなく Python や React.js の API 実装に対応しているため、最終的にカスタマイズした検索画面を社員に提供して利便性を底上げすることができています。
  • Analytics ～ 利用傾向のモニタリング
    エンタープライズ検索の仕組みは、多くの人が使ってこそ価値があります。その利用程度を確認することは、骨の折れる作業です。Amazon Kendra には、どのようなワードでどれだけの検索が行われているかをモニタリングする機能が備わっています。当社では、この機能を使ってユーザーの利用傾向を把握しています。

また、上記実装に関していくつかの Q&A を記載します。

  • 社内のナレッジを集める際、どういった苦労がありましたか？
    各部門や社員がナレッジを保有していたものの、必ずしも Amazon Kendra と直接接続できる場所には置かれていなかったため、まずはそれらを収集する取り組みが必要でした。
  • Amazon Kendra からどのようなメリットが得られましたか？
    当社でも過去にナレッジ共有の挑戦は幾度となく繰り返されていたものの、多くが失敗に終わっていました。その原因は、情報の集約、検索性、運用コスト、そして実装コストです。 Amazon Kendra にはこれら問題を解消する機能があり、当社では構想から約３ヶ月でローンチすることに成功しています。そして、これまでは個人や部門単位の知見で取り組まざるを得なかった業務も、 Amazon Kendra を介して組織全体の集合知としてソリューションを見つけることができるようになっています。
  • 検索性はどのように評価して、何か改善に向けて工夫はしましたか？
    まずは、多くの社員に触ってもらいながら、フィードバックを貰いました。実装当初に起きた問題は、ナレッジとして価値の低い情報が散見されるという点でした。この原因は、たとえばデータソースの中に社内のブログ記事といった情報が含まれていたことにあります。ユーザー体験の改善に向けて、データソースの取捨選択は継続的に取り組んでいます。

以上のように Amazon Kendra を採用することで、導入までの多くのハードルを最小コストで乗り越えることができました。しかし、この手のツールの最大の課題は、導入後に訪れる「普及」という壁です。次節では、当社がその壁をどのように乗り越えたか、ひとつの事例を示します。

便利なツールがあっても使われなければ意味がない、普及の壁をどう乗り越えたのか？

chatbot

みなさんも、せっかく人・時間・金銭コストをかけて導入したツールが、なかなか普及せずに形骸化もしくは廃止となってしまった例を目にしたことはないでしょうか。どれだけ課題解決に適した機能があっても、社員が使ってくれない限り効果は出ません。

当社が Amazon Kendra の導入と同時に行った取り組みは、チャットボットの提供です。つまり、チャットで質問を投げると、それに該当するナレッジが返信されるという仕組みです。テレワークを併用する当社では全社員がチャットツールを日常的に利用しているため、チャットボットの利用はブラウザで新しい検索画面を開いてもらうよりも遥かに親和性があります。

このチャットボットの実装には AWS Lambda を利用しています。AWS Lambda は、サーバーレスでイベント駆動型のプログラムを実行することのできるサービスです。具体的には、次のワークフローを実装しています。

  1. ユーザーが、チャットボットにメンション付きで質問を投稿
  2. チャットツールが、 AWS Lambda にイベントを発行
  3. AWS Lambda が、イベントを検知して質問内容を Amazon Kendra で検索
  4. AWS Lambda が、検索結果をチャットツールに投稿
  5. ユーザーが、検索結果を閲覧

この操作は数秒で実行されるため、ナレッジ検索の良質なユーザー体験を提供できています。大半の社員は、このチャットボットからナレッジ共有の仕組みに触れており、チャットボットが仕組みの普及に貢献したことは間違いありません。そしてチャットボットだけではカバーしきれない部分もあるため、カスタマイズされた検索画面も併用してもらうことで、より優れたユーザー体験を実現しています。

さいごに

本記事では、ナレッジ共有に向けた Amazon Kendra の導入事例、そして仕組みを普及させるための AWS Lambda を用いたチャットボットの実装例を紹介しました。今後の大規模言語モデルの発展に伴い、 Amazon Kendra がさらなる飛躍を遂げることを楽しみにしています。

著者について

naoki_okada岡田 直樹

株式会社ブレインパッドのリードデータサイエンティスト。ビジネス・アナリティクス・エンジニアリングの横断的な経験を活かし、DX組織の立ち上げから未開拓分野のデータ活用まで、幅広くお客様をご支援しています。