こんにちは、カミナシのソフトウェアエンジニアの内田 (@A2hiro_tim) です。 11/28、AWS の CEO Adam Selipsky 氏の Keynoteで Amazon Q が発表されましたね。

今回ありがたいことに、AWS re:Invent 2023 にラスベガス現地で参加する機会をいただき、複数のセッションに加え、この Keynote も聞いてきました。

Amazon Q についての情報はまだ多くないですが、Amazon Q の中でも、"Amazon Q for general business use" と呼ばれる機能について、現地のセッションで聞いた話が面白かったので、書いてみたいと思います。

私は大学院で機械学習の研究室に所属していて、同時期に AI コンサルティングの会社でインターンもしていました。卒業後はソフトウェアエンジニアとしてキャリアをスタートしています。 AI とソフトウェアエンジニアリングの両方のバックグラウンドがあるので、現地でも両方のセッションをとっていました。

AWS re:Invent では、Keynote で新しく発表されたサービスについてもセッションが行われます。"Amazon Q for general business use" についてのセッションも追加されたので、話を聞いてきました。セッションのタイトルは、"Deploy generative AI applications on enterprise data with Amazon Q" で、エンタープライズ企業視点で "Amazon Q for general business use" がどんなサービスであるか、どんな利点があるかについて解説したセッションでした。

AI 関連の新サービスだから参加したセッションでしたが、話を聞いていると、"Amazon Q for general business use" は AI とソフトウェアエンジニアリングの融合だなと感じました。このセッションは比較的自由な形式の Chalk Talk というセッションで、内容は録画されていません。そのため、情報も十分ではなく、気になっている人もいるのではないかと思い、この記事を書くことにしました。

注意点

"Amazon Q for general business use" を含め、Amazon Q はまだ Preview です。本記事は AWS の発表と AWS re:Invent 2023 で得た情報をもとに記載していますが、サービス内容が不安定だったり、変わったりする可能性があります。十分に検討のうえご利用ください。

内容には気を遣っていますが、私の認識違い、英語の聞き間違い等あるかもしれません。もし何か見つけたらご指摘いただけますと幸いです。

記事の構成

この記事は、ソフトウェアエンジニア向けに書いています。 AI の前提知識があまりなくても読めるよう、簡単に周辺知識を補足しながら書いています。以下のような構成になっています。

"Amazon Q for general business use" の概要
- "Amazon Q for general business use" は自社専用 chatbot を簡単に作れるサービスであること
一般的な自社専用 chatbot の仕組み
- "Amazon Q for general business use" を理解するための前提知識として、そもそも一般的な自社専用 chatbot はどういう仕組みになっているか
"Amazon Q for general business use" が解決したい課題
- 自社開発することと比較して、 "Amazon Q for general business use" にどんなメリットがあるか
外部データの取得の仕組み
- "Amazon Q for general business use" のソフトウェアエンジニアリングの側面として、外部データの取得にまつわる仕組み

Retrieval Augmented Generation (RAG) に馴染みのある方は、前半は飛ばして、「"Amazon Q for general business use" が解決したい課題」から読んでいただければと思います。

"Amazon Q for general business use" の概要

この記事は Amazon Q の中の "Amazon Q for general business use" にフォーカスを当てるので、Amazon Q 全体の概要や他にどんな発表があったかは、AWS の公式ブログを参照してください。

"Amazon Q for general business use" は、いわば自社専用の chatbot を作れるサービスです。自社内の Jira, Gmail, Slack などの情報に基づいて回答してくれる chatbot を簡単に作ることができます。 OpenAI の ChatGPT では、好きなファイルや URL リンクを添付して質問をすれば、その特定の資料に基づいて回答を生成してくれます。同様に、"Amazon Q for general business use" で作った chatbot は、あらかじめ連携したサービスの情報をもとに回答を生成します。 chatbot の回答には根拠となる資料のリンクが添付されます。ファクトチェックの手段が提供されるわけです。他にも、Slack に "Amazon Q" としてアプリを招待して、スレッドの内容を要約してもらったりなどのデモもあったのですが、ここでは割愛します。

"Amazon Q for general business use" のアプリケーション（chatbot）作成側の特徴 — "Amazon Q for general business use" のアプリケーション作成側の特徴

Amazon Q を ChatGPT の対抗馬と報じるメディアもありますが、特にこの "Amazon Q for general business use" については、利用者が開発者に限られないこと、チャット形式であることから、明確に競合になりそうです。

ちなみに、ここまで何度も "Amazon Q for general business use" と書いてきたのですが、実はまだ正式名称がありません。 AWS re:Invent 2023 で Amazon Q について複数の発表がありましたが、それぞれ毛色が異なります。他の機能と誤ることがないよう、本記事では一貫して "Amazon Q for general business use" と表記します。

一般的な自社専用 chatbot の仕組み

"Amazon Q for general business use" の話に入る前に、まず、そもそも自社専用 chatbot はどういう仕組みで動いていることが多いか、（本当に簡単に）私の理解で補足します。知っている方は飛ばしてください。

自社データの学習はしない

AI は大量のデータを学習するもの、と理解されている方が多いと思いますが、自社専用 chatbot は自社データの学習はしないことが多いです。学習による開発をしない理由は、例えば以下のようなものが挙げられます。

開発にコストがかかる
開発だけでなく継続的にコストと時間がかかるので、頻繁に情報が変わる場合などに対応しにくい
権限管理ができない
回答の根拠となるデータが何であるかがわからなくなる
一般的な知識と自社データによる知識の区別がつかなくなる

AI は学習をする際、元のデータがなんであるか、正確にどういう文章だったか、といった情報は失います。経営陣しか閲覧できないデータでも、一般的な知識でも、AI は区別なく学習し、その結果、上記のような課題が発生します。

自社データは生成時の参考にする

これらの課題は、事前学習済みの大規模言語モデル (LLM) を活用する方法で解決することができます。 chatbot は、質問を受けた際に、必要なデータを検索して、そのデータを LLM へ入力して、回答を生成します。

例えば「ユーザーは承認機能について困っていることはある？」と聞けば、社内のユーザーインタビューの議事録を見つけ、複数の議事録の内容を要約しつつ、「間違って承認ボタンを押してしまって取り消せないことで困っているユーザーが多いようです」のような回答を生成します（※イメージです）。

必要なデータを検索してから回答しているので、回答がどのデータに基づいたものであるかもわかりやすいです。先ほどの承認機能の例の場合、実際にユーザーインタビューの議事録を読みに行けば、生成された回答が正しいかどうかは判断しやすいです。

また、質問者の権限によって検索対象のデータをフィルターすれば、アクセス権限のない情報を知ることもありません。

これは Retrieval Augmented Generation (RAG) と呼ばれる仕組みで、事前準備や検索にも LLM が使われているのですが、さらに詳しく知りたい方は世に出ている詳しい解説を参照ください。

LLM が備えている言語理解能力を活用することで、高コストでかつ懸念も多い学習をせずに、独自データに基づいた回答を生成させている、というのが最近の自社専用 chatbot の仕組みになります。

"Amazon Q for general business use" が解決したい課題

自社専用 chatbot を開発する手法も LLM もオープンソースで公開されているため、自社開発は可能です。そうすると、わざわざ "Amazon Q for general business use" を使う必要はないと思われるかもしれません。

しかし、特にエンタープライズ企業においては、マネージドサービスである "Amazon Q for general business use" を使う価値があります。それは、エンタープライズ企業が自社専用 chatbot を開発・利用したいと考えた場合に直面する以下の3つの課題があるからです。

時間がかかる
社内で知るべきではない人に対して情報漏洩する可能性がある
正確性には特に気を付ける必要がある

"Amazon Q for general business use" はこれらの課題を解決することを意図したサービスです。

1.時間がかかる

会社の規模が小さい場合、社内の情報が一箇所に集まっていて、社員は全てのデータにアクセス可能、といった状況はあり得ます。この場合、自社専用 chatbot は相対的には早く開発できるでしょう。

しかし、歴史的経緯で複数のサービスにデータが散らばっており、データの権限管理も細かいエンタープライズ企業の場合は違います。

利用しているそれぞれのサービスからデータを継続的に集めるシステムを構築し、どの情報に誰がアクセスできるかを管理し、適切に運用していく必要があります。データ収集と権限管理の他に、もちろん chatbot 自体の開発も必要です。 AI の力を活かしたくても、なかなかすぐに始められないエンタープライズ企業が多かったのではないかと思います。

"Amazon Q for general business use" は、利用開始して、連携サービスの credential を入力すれば、crawling が始まります。継続的なデータ収集や権限管理を任せることができ、データ取得が終わったらすぐにchatbot を使うことができます。私は権限の問題で途中までしか試せていませんが、セッションで見たデモも踏まえると、1 日はかからずに自社専用 chatbot が出来上がるように見えました。素晴らしい速度です。

2.社内で知るべきではない人に対して情報漏洩する可能性がある

先に言及した Retrieval Augmented Generation (RAG) を用いれば、権限に基づいて検索可能なデータを絞り、情報漏洩せずに chatbot に回答させることが可能です。しかし、複数のサービスからデータを収集するとなると、やはり負荷が高いです。連携している外部サービスごとに権限の取り扱いは異なる中で、自社の権限との対応付けをしていくのは、サービスの数が増えれば増えるほど大変です。

"Amazon Q for general business use" は、連携サービスについて自動で権限の対応付けをしてくれるため、非常に楽です。（自動で権限の対応付けをするのはそんなに簡単ではないと思うのですが、残念ながら詳細は聞けませんでした。）

権限管理に限った話ではありませんが、私は外部サービスとの連携開発をしていた経験があり、自分たちが何もしていなくてもサービスが動かなくなる大変さを経験しているので、AWS も裏で大変な苦労をしているんだろうな、と勝手に尊敬していました。

参考に、解説の時のスライドを添付します。詳しい方が読めばもっと色々なことが分かるかもしれません。

3.正確性には特に気を付ける必要がある

多くの指摘があるように、生成 AI に何かを生成してもらう場合、回答の正確性には注意する必要があります。エンタープライズ企業においては、誤った際の影響が大きいため、特に気を付ける必要があります。

正確性についても、Retrieval Augmented Generation (RAG) の仕組みを使って、通常の学習を行う場合に比べて正確性が高まることが期待されます。回答の根拠となったデータのリンクを付与し、質問者は、回答が正しいか、リンクをクリックしてファクトチェックすることも可能になります。

"Amazon Q for general business use" はこれに加えて、関連するデータが検索によって見つからなかった場合に「回答するために十分な情報がない」と回答します。そもそも hallucination が起きるのは、回答の根拠となるデータが少ないことが一因だとされており、その対策と考えられます。他にも、データの検索精度を高めるためにLLM や全体の仕組みに多くの最適化をしたり、回答の内容にNGワードが含まれたら回答しないようにする機能を追加したそうです。

正確性を高めるために、 Retrieval Augmented Generation (RAG) を背景に、エンタープライズでも安心して扱えるように調整したと言えるでしょう。

私個人の意見ですが、Keynote で強調されていたほどの安全性については、セッションを聞いても不安が残りました。ファクトチェックの選択肢と情報不足時の回答中止、要素技術それぞれの最適化によって全体的な正確性が上がっていると期待されますが、いずれも緩和策で、根本的な解決策ではない、というのが私の理解です。 AI の回答の正確性を根本的に担保する仕組みがあるわけではなければ、これまで通り、誤っている可能性を常に考慮に入れてAIを使っていくことが大事です。

外部データの取得の仕組み

ここまでは AI の話をしてきました。最後に、回答の生成根拠となる外部データについて、何をどうやって取得しているか触れておきます。

"Amazon Q for general business use" は定期的に外部サービスを crawling して、document の内容と、その権限などのメタデータを取得しています。 document の内容は直接保存するのではなく、LLM で専用の形式に変換して保存します（ RAG の話のため、詳細は割愛）。 document の権限情報は AWS 上の権限とマッピングされて保存されます。

アプリケーションの外からデータを継続的に取得する場合に難しいのは、データの変更をどう扱うか、更新のタイミングはいつにするかの判断です。 document の最終変更時刻がわからない場合は、データの変更を検知するのは難しく、かといって取得の度に全てのデータを更新すれば、時間とコストがかかります。取得したデータの更新頻度が低いと、chatbot は古い情報に基づいて回答してしまいますが、頻繁にデータの更新を行うと、外部のサービスへの負荷になったり、ストレージコストが膨らみます。

"Amazon Q for general business use" では、データの更新頻度や更新方法の判断がユーザーに委ねられているようです。すでに述べたように、データ更新間隔は指定可能で、毎時間での更新も指定可能です。更新対象のデータも、変更があったデータや最新のデータだけを取得するか、全てを取得するか指定できます。

データ取得は指定した頻度でしか行われず、回答時にもデータは取得しません。回答時は、すでにあるデータから質問者の権限で利用可能なデータをフィルターし、そこから検索した結果をもとに回答を生成します。外部サービスへのアクセスがない分、応答は高速で、仮に外部サービスがダウンしていても回答が可能ですが、最新のデータに基づかないというトレードオフがあります。（ちなみに、外部サービスがダウンしていた場合、回答に付与された元情報のリンクを踏んで初めてサービスがダウンしていることに気づくことになります。）

dcument に誤りがあって修正しても、crawl が実行されるまでは誤った情報をもとに回答を生成することになりますし、例えば退職や異動があってアクセス権限に変化があっても、crawl が実行されるまでは変更前の権限のままになります。

API などのアクセス方法は quota や従量課金が設定されていることもあるので、デメリットを理解してデータ取得の方法を設定する必要があります。

感想

"Amazon Q for general business use" のマクロな構成を考えると、crawling と Retrieval Augmented Generation (RAG) のパートに分かれていて、目新しいことはないように見えます。しかし、セッションの中では RAG 部分の最適化がされたことが強調されていましたし、crawling も自身の外部連携の経験を踏まえると簡単なことではないことが分かります。

RAG、 crawling、 data の管理、認可、とそれぞれが分野として独立するくらい大きな領域であり、これらを統合して一つのサービスとして提供できるのは AWS のプラットフォームの強みだと改めて感じました。

普段からそうなのかもしれませんが、今回の Keynote やセッションでは、コスト面はあまり言及されなかった印象でした。 "Amazon Q for general business use" は強力ですが、安くはありません（これから変わると思うので、公式ページを参照ください）。

発表されたばかりの Preview 版で、これからどれだけ使われて、どれだけ進化していくのか、楽しみです。カミナシは Notion を利用しているため、残念ながらすぐに使い始めることはないと思いますが、GitHub, Google Workspace, Slack, Notion 全てを連携させられるようになれば、とてつもない価値が出せるのではないかと思います。

最後に、サマリーのスライドの写真をとっておいたので、共有いたします。