AWS JAPAN APN ブログ

富士ソフトによる AWS の生成系 AI サービス検証結果と Amazon Bedrock 導入ソリューション

本稿は、以下 4 名による共著です。

・富士ソフト株式会社 技術管理統括部 先端技術支援部 部長 三塚 正文
・富士ソフト株式会社 ソリューション事業本部 情報ソリューション事業部 DXシステム部 部長 高橋 良雅
・富士ソフト株式会社 エリア事業本部 西日本支社 インテグレーション&ソリューション部 主任/フェロー 森田 和明
・アマゾン ウェブ サービス ジャパン合同会社 機械学習パートナーソリューションアーキテクト 本橋 和貴

アマゾン ウェブ サービス (AWS) は、生成系 AI の普及を目指して、AWS パートナーとの取り組みを積極的に推進しています。本稿では、その取り組みの一環として、AWS のプレミアティアサービスパートナー、かつ、 IoT コンピテンシーパートナーである富士ソフト株式会社 (以下、富士ソフト) による生成系 AI サービスの検証結果とソリューションを紹介します。なお、本文中に登場する AWS サービスの性能評価やコストに関する部分は、富士ソフトによる実施と評価に基づいています。

はじめに

ここ数年、生成系 AI は研究領域で目覚ましい発展を遂げてきました。特に昨年末から始まった生成系 AI ブームにより、研究の枠を超えて一般の利用者も AI 技術に触れるようになり、日常的に生成系 AI サービスの恩恵を得るようにまでなっています。

2023 年 9 月 28 日に AWS が提供を開始した生成系 AI サービスである Amazon Bedrock を用いることで、AWS のお客様は、テキスト生成、画像生成、要約、質問応答、チャットボットなど、多様な生成タスクを実現できる強力な基盤モデル (Foundation Model) に API 経由でアクセスして生成系 AI アプリケーションの開発を簡単に開始できるようになりました。これらの基盤モデルを単体で利用するだけでも価値を享受することは可能ですが、企業のビジネスに真の価値をもたらすにはさらに踏み込んだ活用方法が求められます。企業独自のデータと生成系 AI を融合させることで明確に差別化されたサービスを生み出すことができます。

AWS ではエンタープライズ検索サービスである Amazon Kendra やオープンソース検索の Amazon OpenSearch Service といったサービスを提供しています。これらを外部のデータの検索基盤として利用し、Amazon Bedrock を組み合わせることで、容易に RAG (Retrieval Augmented Generation; 検索拡張生成) システムを構築できます。また、ドキュメントの検索と生成系 AI の組み合わせだけでなく、社内のアプリケーションやサードパーティのデータを取り込む仕組みや、IoT デバイスからのデータ収集などとの連携が、強力な差別化要素となり得ます。

以下では、富士ソフトが AWS の生成系 AI サービスを検証した結果から得られたインサイトや、富士ソフトの生成系 AI オファリングがお客様にもたらす価値について解説します。

富士ソフトで実施した 2 つの検証

富士ソフトでは、注力技術の頭文字から「DX+AIS-CRM+SD+(5)G2」という技術戦略を打ち出しています。この戦略の元で AWS クラウドを活用した AI や IoT の構築や開発を通じ、お客様のビジネスの推進を支援しています。

昨今は生成系 AI の活用に関して様々なお客様からお問い合わせが増えており、富士ソフトは独立系ベンダーの立場として、Amazon Bedrock を始め、各社の生成系 AI サービスの検証を進めています。ここでは、Amazon Bedrock を対象に実施した、RAG および IoT デジタルツインダッシュボードへの適用という 2 つの検証内容を紹介します。

検証1:Amazon Bedrock と Amazon Kendra で実現する RAG の性能とコスト調査

生成系 AI は日本産業の長期的な成長を促す起爆剤として大きな期待が寄せられています。例えば、熟練者のノウハウを継承し、若手担当者が熟練者と同様の知識を持って業務に従事することによる企業の生産性向上、あるいはサービスや製品に関する一般利用者の問い合わせに対し、IT の技術を使った正確な案内の実現によるサービスレベルの維持向上などにおいて活用が期待されています。しかし、企業内に蓄積された多くの情報、ドキュメントなどのナレッジを用いて生成系 AI を使って実現を目指す際に、大きな壁になるのがハルシネーション (幻覚) 現象です。生成系 AI から企業のナレッジとして正しくない情報を回答されてしまうと、若手担当者は誤ったオペレーションを実施し、一般利用者へ誤った製品情報を伝えてしまうことになります。

本節では、ハルシネーションを回避する技術として期待されている RAG を Amazon Bedrock と Amazon Kendra で実現し、回答の精度を評価するとともに、他社の生成系 AI + 検索エンジンと比較した調査結果を紹介します。

(1) 自然な回答文を生成する Amazon Bedrock の Claude 2 と強力な回答検索を実現する Amazon Kendra

富士ソフトが構築した RAG の構成は以下の通りです。

RAG Architecture

次に示す 3 つのタスクを設けて RAG を実現しています。

  1. 検索文生成タスク – 人 (Person) の質問文における言葉の揺らぎを吸収し、精度の高い検索結果を得るために検索文の生成を実現するタスク
    • 日本企業での利用を想定し、Amazon Bedrock と連携する基盤モデルとして、日本語性能の高い Claude 2 を選択しました。ただし、本タスクはそれほど高性能なモデルを要求しないため、コストとレイテンシーがより小さい軽量版の Claude Instant を用いることも検討できます。なお、Amazon Kendra が高度な検索機能を持ち合わせているため、業務での利用用途によっては本タスクを適用しなくても正確な回答を得られるかもしれません。
    • 本検証では、後述する他社の検索エンジンとの機能差を埋めるため、明示的に本タスクを実施しています。実際の利用用途等に応じて本タスクの要否を検討してください。
  2. 回答検索タスク – Amazon Kendra と Amazon Simple Storage Service (Amazon S3) の組み合わせによって回答を検索するタスク
    • Amazon Kendra の機能により AWS 内外のリソースに接続してドキュメントを検索する仕組みを構築することが可能です。企業のナレッジを利用するにあたって強力な機能となります。
    • 本検証ではデータソースを Amazon S3 に限定しています。また、投入データに関しては業務データではなく、検証結果公開用の機密情報を含まないサンプルデータとして鎌倉時代前後の日本の武将に関するテキストデータ (692 ファイル) を使用しています。
  3. 回答文生成タスク – Amazon Kendra で得られた回答を文章として生成するタスク
    • 検索結果が複数あることや、ある程度の長文が出力されると可読性が落ちる可能性があります。また、人の問い合わせが文章であるため、インターフェースの回答も文章であることが望ましいです。
    • 本検証では、Amazon Bedrock の Claude 2 により、検索結果を要約、文章化して回答文を生成します。利用者の利便性向上のため、データの出典元である情報を付与しています。

それではまず、RAG が正しく動作するか確認してみましょう。

質問

源頼朝はいつの人?

Amazon Kendra による検索結果の抜粋

[
{
出展: 1,
情報: “源 頼朝(みなもと の よりとも、旧字体:源 賴朝)は、平安時代末期
から鎌倉時代初期の日本の武将、政治家。鎌倉幕府初代征夷大将軍。清和源氏の一流たる河内源氏の源義朝の三男として生まれ、父・義朝が平治の乱で敗れると伊豆国へ配流される。伊豆で以仁王の令旨を受けると北条時政、北条義時などの坂東武士らと平家打倒の兵を挙げ、鎌倉を本拠として関東を制圧する。”
}
{
出展: 81,
情報: “このように江戸時代に既に存在した義経が大陸渡航し女真人(満州人)に
なったという風説から、明治期になると義経がチンギス・カンになったという説が唱えられるようになった。明治に入り、これを記したシーボルトの著書『日本』を留学先のロンドンで読んだ末松謙澄はケンブリッジ大学の卒業論文で「大征服者成吉思汗は日本の英雄源義経と同一人物なり」という論文を書き、『義経再興記』(明治史学会雑誌)として日本で和訳出版されブームとなる。”
},
{
出展: 2,
情報: “源 義経(みなもと の よしつね、源義經)は、平安時代の日本の武将。
鎌倉幕府初代将軍源頼朝の異母弟。仮名は九郎、実名は義經(義経)である。”
} 略

回答

出展元: 1 によると、源頼朝は平安時代末期から鎌倉時代初期の武将で、鎌倉幕府の初代将軍です。

Amazon S3 に置いたデータソースには幅広いトピックのデータが含まれる中で、Amazon Kendra が源頼朝の関連情報をピンポイントに検索しています。また、Amazon Bedrock の Claude 2 により、検索結果から適切な要約をし、回答文を生成できています。このように、Amazon Bedrock の Claude 2 と Amazon Kendra を組み合わせることで企業のナレッジを活用できる強力な RAG を実現できることがわかりました。

(2) Amazon Bedrock と Amazon Kendra で実現する RAG の優位性

前項では、Amazon Bedrock の Claude 2 と Amazon Kendra で実現する RAG の内容について説明しました。本項では、他社の生成系 AI サービスで提供される基盤モデルと検索エンジンの比較検証を行った結果を説明します。検証に用いたデータは前項と同様、鎌倉時代前後の武将のデータです。なお、各社サービスの機能、提供内容は 2023 年 10 月 19 日時点となります。

以下は、「源頼朝の父は誰か?」について、各社の RAG システムのベースとなる検索エンジンに問い合わせた結果です。

AWS B 社 C 社
検索エンジン Amazon Kendra 非公開 非公開

検索結果

(最も関連度が高い文書)

{“父:源義朝 – 源為義長男。保元の乱で栄進するが、平治の乱で敗れ、敗走中に殺される。母:由良御前 – 藤原季範三女。兄弟源義平 – 悪源太。平治の乱後、平清盛暗殺のため京へ潜伏中に捕えられ斬首される。}
→他 関連文書 4 件

{“出生跡地にある誓願寺と誕生旧地碑 久安3年(1147年)4月8日、源義朝の三男として尾張国〜父祖は清和天皇の孫で臣籍降下した源経基、多田源氏。父の義朝は保元の乱(1156年)において、}

→他 関連文書 11 件

{“頼朝は源氏一門や多くの御家人を集め、父・義朝の菩提寺・勝長寿院落成供養を行なった。その日の夜、朝廷の頼朝追討宣旨に対抗して御家人達に即時上洛の名を出すが、〜”
→他 関連文書 8 件

いかがでしょうか。Amazon Kendra の結果に着目すると、源頼朝の父である源義朝に関する情報を適切に抽出できています。かつ、関連文書が 4 件のみとなっており、必要な情報を他社製品より無駄なく取得できていることもわかります。

文書の情報に基づいて回答を生成する RAG ですが、適切な検索結果を取得できない場合、間違った情報を基盤モデルに入力することとなり、ハルシネーションの問題が発生してしまいます。また、基盤モデルに渡すテキストが多くなると、テキスト生成により多くの処理が必要となり、レイテンシーが大きくなってしまいます。今回の検証の範囲内においては、Amazon Kendra は適切な情報をピンポイントに比較的無駄なく取得できており、これら 2 点の課題を緩和できることが期待されます。

最後に、コストに関する調査結果を説明します。本節の冒頭で、「生成系 AI は日本産業の長期的な成長を促す起爆剤として大きな期待が寄せられています」と記載しました。企業がナレッジを活用し、かつ、多くの部署、従業員に生成系 AI サービスを公開するにあたって、次に懸念となるのはコストだと考えます。

今回は、企業のナレッジを RAG システムに導入する初期コストおよび運用中のデータ投入コストを「データ整備コスト」、環境を構築・維持するための費用 (クラウドサービス利用料を含む) を「ランニングコスト」として、コストの調査を実施しました。

Cost Comparison

(Amazon Bedrock + Amazon Kendra を1としてコスト比率で表現)

Amazon Bedrock の Claude 2 と Amazon Kendra の組み合わせの環境においては、Amazon Bedrock による容易な基盤モデルの設定と、Amazon Kendra の多くの、かつ、広範囲なデータソースに対するクロール機能によって容易にデータ投入を行えることで、開発者・管理者の負荷も低くなり、データ整備コストは低いと評価しました。

また、ランニングコストについても、Amazon Bedrock の Claude 2 は比較的安価で多くのデータを扱えることと、Amazon Kendra のネイティブな機能により追加開発の工数を削減しながら業務要求を実現できることにより、結果的に全体として安価なコストで運用できると評価しました。全体の詳しい評価基準に関してはお問い合わせください。

検証2:デジタルツインダッシュボードへの適応考察

IoT データの可視化では、センサーから届くデータを活用した時系列なグラフを利用するケースが多く、グラフから状況を把握するには一定の業務理解が必要です。しかし、AWS IoT TwinMaker によるデジタルツインを利用すれば、業務に精通していない人でも IoT の状況をわかりやすく把握できます。今回は、AWS IoT TwinMaker と Amazon Bedrock を組み合わせることで、状況をよりわかりやすく伝えることが可能になるのではないかと考え、検証を行いました。

IoT データの特徴の 1 つとして、大量の時系列データであることが挙げられます。まずは、時系列データを Amazon Bedrock で集計できるか検証しました。なお、基盤モデルは文章の意味理解や文脈の把握といった能力は高いとされていますが、一般に集計等の計算をうまく行えるように学習されていません。実際の結果としても、与えたプロンプトの中で明示的に含まれている最大値や最小値の抽出は可能でしたが、平均や中央値を計算させようとすると誤った結果を示す傾向が見られました。正確な計算が必要な場合においてはこれまで通り SQL やプログラムで行う方が適切であると改めて結論づけました。

次に、集計したデータに対して値の変化の傾向を掴むことができるか検証しました。オープンデータで公開されている新型コロナウイルス感染症の新規陽性者数のデータをサンプルとして使用し、「新規陽性者数の傾向を教えてください」と質問を投げると、以下のような回答が得られました。なお、基盤モデルには Anthropic Claude 2 のモデルを利用しました。

はい、このデータから2021年1月の東京の新型コロナウイルスの新規陽性者数の傾向を分析いたします。

– 1月上旬はおおむね800人台で推移していましたが、途中から急激に増加し始め、1月7日には一気に2000人を超える2520人となりました。
– その後も2000人前後で推移し、1月15日には2000人を超える2044人のピークを記録しました。
– 1月中旬以降は徐々に減少傾向となり、月末には600人台まで減少しました。
– 全体としては、月前半が増加トレンド、月中旬がピーク、月後半が減少トレンドとなっています。
– 1月第1週は800人台、第2週は2000人超、第3週は1500人台、第4週は1000人台と推移したことがわかります。

以上のように、2021年1月の東京の新規陽性者数は全体として増加からピークを迎え減少に転じる傾向が見られました。特に、月前半の急増と月中旬のピークが特徴的でした。

プロンプトで与えたデータの傾向を取ることは上手にできることがわかりました。プロンプトを工夫し、過去のサマリーデータも付与した上で、「過去のデータを参考にし、新規陽性者数の傾向を教えてください。また、来月の患者数を予測してください。200 文字以内に抑えて回答してください。」と問いかけることで、端的、かつ、理解のし易い回答を得ることができました。

過去5ヶ月のデータから、患者数は増加傾向にある。
1月のデータからは、週末に患者数が減少し、平日に増加する傾向がみられる。
来月の平均患者数は1500人程度と予測される。

確かに過去 5 ヶ月 (2020 年 9 月~2021 年 1 月) の患者数の平均はそれぞれ 163 人、173 人、329 人、625 人、1,302 人であり、増加傾向にあります。また、曜日による比較では日曜日の患者数が少ない傾向も確認できています。ただし、「来月」(2021 年 2 月) の平均患者数の実績値は 393 人であり、予測値の「1,500 人程度」とは乖離があります。これは、緊急事態宣言の延長などの対策が行われたタイミングであり、対策の効果で傾向が変化した結果かと推測されます。

このように、Amazon Bedrock のみを使うだけでも時系列データの傾向を得ることができることがわかりました。同じく時系列データである IoT データに対しても Amazon Bedrock を使うことで傾向を把握することができると期待されます。しかし、IoT データは単一の IoT 機器からのみ得られるわけではなく、複数の機器からデータが送信されることが一般です。IoT 機器が複数ある場合は以下のような手順を踏むことで、デジタルツインダッシュボード上で現状をサマリーして把握できるようになります。

  1. 対象の機器単体で要約を生成する
  2. 個々の要約に対して、全体要約を生成する

次の動画は、デモとして複数のエアタンクに取り付けられた IoT 機器から得られたデータの要約をデジタルツインダッシュボードに表示している様子を示しています。

digital twin demo loop

これよりさらに正確な集計、欠損値の有無の判定、時系列予測、異常検知等を行うためには基盤モデルですべてを処理するのではなく、外部の分析の仕組み (表計算システムや機械学習モデルなど) と組み合わせて、それぞれの得意分野を使い分けるのが有用であると考えられます。基盤モデル自体が行動計画を作り、タスクを解くのに必要なパーツを適材適所で選択して利用する機構は一般に「エージェント」と呼ばれますが、Amazon Bedrock でも Agents for Amazon Bedrock という機能が拡充されることがアナウンスされています。今後もエージェントの利用も含めた、IoT データ分析への Amazon Bedrock の応用の検証を継続していきます。

「Amazon Bedrock 導入ソリューション」の紹介

富士ソフトでは、生成系 AI に関する全社横断組織を立ち上げています。生成系 AI をいち早く社内に導入・検証し、生成系 AI に関するプロジェクト支援を通じて知識を蓄えてきました。

Amazon Bedrock についても、プレビュー版を使用した事前検証を通じて構築から検証を行った結果、市場ニーズに応えることができると判断し、Amazon Bedrock 導入ソリューションの提供を開始しました。

bedrock solution

生成系 AI 活用推進に向けて

企業において生成系 AI を活用するには、大きく分けて以下の 3 つのフェーズがあると考えます。本ソリューションでは、業務の効率化からビジネス適用まで、企業価値の向上に貢献するフルサポートを提供していきます。

gen ai flow

  • 生成系 AI 展開フェーズ – 生成系 AI を使用できる環境を導入し、実際に触れてみることで生成系 AI を活用するための知識を習得する。
  • 活用フェーズ – 実際に生成系 AI に触れてみて、さらに実際の業務に当てはめてみることで効果を検証する。ここでは、より生成系 AI の効果を高めるためのデータの持ち方や生成系 AI 自体の活用方法を確認する。
  • 応用活用フェーズ – 活用フェーズまでの結果を基に、業種毎の標準化への適用や、サービスへの適用等によって生成系 AI のより高度な活用に取り組む。

生成系 AI は、日本企業の更なる発展を支える重要な技術と言われています。生成系 AI は今後も進化を続け、業務への貢献の幅も広がると考えられます。しかし、生成系 AI に興味はあるものの、生成系 AI で何ができるのかわからない、生成系 AI を活用したいが何をしたらいいのかわからないというお客様もいらっしゃいます。富士ソフトは、まずは生成系 AI に触れていただける環境構築とお客様に生成系 AI を最適に活用していただくための支援を提供します。

生成系 AI の導入についてご検討中の方、また課題やお悩みをお持ちの方、富士ソフトの「Amazon Bedrock 導入ソリューション」のページからお問い合わせください。

まとめ

本稿では、富士ソフトで実施した 2 つの検証として、Amazon Bedrock の Claude 2 と Amazon Kendra の組み合わせによる RAG の実現検証および現時点での他社の基盤モデル・検索エンジンで実現する RAG との比較検証結果と、AWS IoT TwinMaker と Amazon Bedrock を組み合わせたデジタルツインダッシュボードへの適応考察を紹介しました。また、富士ソフトの「Amazon Bedrock 導入支援ソリューション」についても紹介しました。

是非、AWS の生成系 AI に触れ、業務への適用を検討ください。富士ソフトは、今後も生成系 AI を含めた AI、IoT、クラウド等の先端技術を研究し、システム開発を通じて産業分野を始めとする多くの領域の発展に貢献し、皆様の業務の革新を支えていきます。


富士ソフト − AWS Partner Spotlight

富士ソフトは AWS プレミアティアサービスパートナーであり、AWS への「リフト」から、Amazon Bedorock を始めとした AWS のマネージドサービスを活用する「シフト」、モダナイゼーション領域まで、AWS のメリットを最大限活用するソリューションを提供する独立系システムインテグレーターとして事業を展開しています。

富士ソフトにコンタクト | パートナー概要

Kazuki Motohashi

Kazuki Motohashi

アマゾン ウェブ サービス ジャパン合同会社の機械学習パートナーソリューションアーキテクトとして、AWS 上で機械学習関連プロダクトを開発するパートナーの皆様に対する技術支援を担当。博士(理学)