/w=3840,quality=90,fit=scale-down)
※本記事は、国際大学グローバル・コミュニケーション・センター（GLOCOM）が主催する『GLOCOM六本木会議オンライン #85』（2024年9月26日開催）の内容を基に作成されています。GLOCOM六本木会議は、情報通信分野における革新的な技術や概念に適切に対処し、日本がスピード感を失わずに新しい社会に移行していくための議論の場として2017年9月に設立されました。 本セッションは、Zoomウェビナーとして約110名の事前登録参加者にライブ配信されました。詳細な活動内容や過去の会議については、GLOCOM六本木会議の公式ウェブサイト（https://roppongi-kaigi.org/ ）でご覧いただけます。 本記事では、講演内容を要約・構造化しておりますが、発表者の見解を正確に反映するよう努めています。より詳細な情報や正確な文脈については、GLOCOMが公開している動画（https://www.youtube.com/watch?v=sDSoPxLyDYM ）をご視聴いただくことをお勧めいたします。
1. はじめに
1.1. 登壇者紹介
■ 城田真琴氏（野村総合研究所 DX基盤事業本部 兼 未来創発センター デジタル社会・経済研究室 プリンシパル・アナリスト）
- 大手電機メーカーを経て、2001年に野村総合研究所に入社
- IT基盤技術戦略室長などを歴任
- 専門は先端技術および先端ITビジネスの動向分析と、それらを活用したビジネス/IT戦略の立案支援
- 近著に『ChatGPT資本主義』『決定版Web3』『エンベデッド・ファイナンスの衝撃』（いずれも東洋経済新報社）
- NHK「おはよう日本」、フジテレビ「めざまし８」などのテレビ出演多数
■ 前川徹氏（東京通信大学 情報マネジメント学部 教授／GLOCOM主幹研究員）
- 1978年通商産業省入省
- 機械情報産業局情報政策企画室長
- JETRO NYセンター産業用電子機器部長
- IPAセキュリティセンター所長
- 早稲田大学大学院国際情報通信研究科客員教授（専任扱い）
- 富士通総研経済研究所主任研究員
- サイバー大学IT総合学部教授等を経て2018年4月から東京通信大学情報マネジメント学部教授
- 一般社団法人コンピュータソフトウェア協会専務理事、国際大学GLOCOM所長なども兼務
■ 小島安紀子氏（GLOCOM六本木会議 事務局/国際大学GLOCOM シニアコーディネーター）
- 本セッションの進行役を担当
- 2024年9月26日にZoomウェビナーとして開催
- 約110名の事前登録参加者にライブ配信を実施
1.2. 研究背景と目的
前川：ちょうど1年前に『ChatGPT資本主義』を出版された城田さんに今日はご登壇いただきました。この本の中で先行企業の生成AI活用事例が紹介されていますが、出版から1年が経過し、現在どのような動向にあるのか、特にRAGとAIエージェントについてお話を伺いたいと思います。
城田：企業における生成AIの活用は、技術の進展とともに多様化・高度化しています。昨年から一部の先進的な企業で取り組みが始まっているRAG（検索拡張生成）は、その代表的な例と言えます。ただし、実際の取り組みが進むにつれて「なかなか精度が向上しない」という声も聞かれるようになってきています。
一方、RAGの次のトレンドとして注目されつつあるのが、人間が細かく指示しなくとも、AIが目標達成のために自律的に行動し、タスクをこなす「AIエージェント」です。本日は、RAGの精度向上のためのヒントとLLMを活用したAIエージェントの動向について、約40分程度でお話をさせていただきます。
前川：内容が盛りだくさんになってしまったので、若干時間が伸びるかもしれませんがご容赦ください。それでは、まずRAGの制度向上というところから見ていきましょう。
小島：本日のセッションは、事前参加登録をしたリモート参加者約110名にライブ配信されています。RAGとAIエージェントという最新のトピックについて、具体的な実装方法から将来展望まで、包括的な議論が期待されます。
城田：はい、本日は主にエマージングテクノロジーと言われている先端技術と、先端ITビジネスの動向調査を専門としている立場から、2023年に注力してきた生成AI分野の研究から、特にRAGとAIエージェントにフォーカスしてお話しさせていただきます。
2. RAGの基礎と精度向上
2.1. RAGの基本的な仕組みと構成
城田：まずRAGについて、基本的な概念から説明させていただきます。RAG（検索拡張生成）は、外部のデータソース、主に社内の文書ファイルなどから情報を検索して、大規模言語モデルに事前に取り込めていない情報も加味して回答を生成させる技術です。モデルが持っている情報は必ずしも最新の情報ではありませんし、社内の情報は当然持っていませんので、そういった情報にアクセスできるようにすることで、いわゆるハルシネーションを軽減し、モデルが生成する回答の正確性をチェックできるようになります。
前川：具体的なアーキテクチャについても説明していただけますか？
城田：はい。まずユーザーがクエリーを投げると、そのクエリーをエンベディング（埋め込み）によってベクトルに変換します。一方で、外部のデータソースは「チャンク」という形で小さく分割します。大きな長文のままですと検索に時間がかかりますので、分割して、これもベクトルに変換してベクトルデータベースに格納します。
このクエリーとチャンクのベクトルを比較して、最も意味の近いベクトルを検索します。それによってヒットしたものが回答の基となり、LLMが元から持っている情報と合わせて回答を生成します。
前川：エンベディングとベクトル検索について、もう少し詳しく説明していただけますか？
城田：エンベディングとは、自然言語処理の文脈において、単語や文のクエリに対して、その意味を表現する多次元空間のベクトルとして表現することです。実際には不動小数点数のベクトルとして出力されます。
例えば、「dog」と「puppy」は意味的に近いので、ベクトル空間上でも近い位置に配置されます。一方、「dog」と「cat」は比較的離れた位置になります。このように2つのベクトル間の距離によって、それらの関連性や意味的な近さを測定できます。なお、意味の近さを測る具体的なアルゴリズムは様々なものが提案されており、一般的にRAGを構築する際には意味の近さを測るためにベクトル検索を使用します。これは単純なキーワードマッチングとは異なるアプローチです。
2.2. 企業における導入状況と課題
前川：RAGの企業における実際の導入状況について、具体的なデータはありますか？
城田：はい。AIスタートアップのX Wizardsのグループ会社であるXA Enterprise AIが今年5月に開催したセミナーで実施した調査結果があります。302社402名の参加者から回答を得たものですが、非常に興味深い結果が出ています。
前川：具体的な数字を見ていきましょう。
城田：はい。「データ連携RAGを使った生成AIの活用・導入化について検討や取り組みをされていますか」という質問に対して、既に取り組み済みが約20%、検討・開発中が約30%、そして「取り組みたいと思っているが着手ができていない」という回答が約40%となっています。合計すると約90%の企業がRAGに関心を持っているか、既に取り組みを始めているという状況です。
前川：その数字は予想以上に高いですね。
城田：そうですね。これは企業において単純な質問応答だけでなく、RAGの活用が既に一般的になりつつあることを示しています。今後はRAGの活用が前提となっていく可能性が高いと考えられます。ただし、ここで重要な課題も見えてきています。
前川：どのような課題でしょうか？
城田：導入・検討を進めている企業からは「なかなか精度が向上しない」という声が多く聞かれます。これは技術的な課題というよりも、むしろ実装方法や運用面での課題が大きいと考えています。この課題に対する具体的な改善アプローチについては、次のセクションで詳しく説明させていただきます。
小島：90%という高い関心度は、企業がRAGの重要性を強く認識していることの表れですね。
2.3. 精度向上のための4つの主要アプローチ
前川：RAGの精度向上について、具体的にどのようなアプローチが考えられるのでしょうか？
城田：RAGの精度向上には主に4つの重要なアプローチがあります。まず外部のデータソースに対する「データの前処理」です。WordやPDFなど、企業の中にある様々なデータをそのままベクトルデータベースに入れるのではなく、適切な前処理が必要になります。
前川：具体的にはどのような前処理が必要になりますか？
城田：例えば、データには不要な文字や記号が含まれていたり、特にPDFでは表面上は見えない文字が隠れていたりすることがあります。これらを機械が読み取りやすい形に整形する必要があります。データサイエンスの世界でよく「ガベージイン・ガベージアウト」という言葉がありますが、まさにその通りです。
前川：2つ目のアプローチについても説明をお願いできますか？
城田：2つ目は「チャンキング」の方法です。長いテキストをより小さなセグメントに分割する際の方法論です。この分割方法によっても精度が大きく変わってきます。
3つ目は「エンベディングモデル」の選択です。先ほど説明したベクトル化の際に使用するモデルの選択です。これも様々なモデルが存在しており、性能に大きな差が出ます。
最後に4つ目として「ベクトルストアの選択」があります。ベクトルを格納するデータベースにも様々な種類があり、それぞれ特徴が異なります。
前川：これらのアプローチはそれぞれ独立しているのでしょうか？
城田：いいえ、これら4つは相互に関連しています。また、これら以外にも様々なテクニックが考案されていますので、興味のある方は是非調べていただきたいと思います。それぞれのアプローチについて、これから具体的に見ていきましょう。
前川：はい、特に実装面での課題と解決方法について、詳しく聞いていきたいと思います。
2.4. データの前処理手法と課題
前川：データの前処理について、具体的な課題と解決方法を詳しく説明していただけますか？
城田：はい。特に問題となるのが、PDFやテーブル形式のデータの処理です。例えば、企業の決算報告書のようなテーブル形式のデータは、単純に読み込んでもAIが正確に意味を解釈できないことが多いんです。
前川：具体的な例を挙げていただけますか？
城田：例えば、2021年の収益額を尋ねた場合、実際の数値が385ミリオンであっても、AIが1809ミリオンと誤って回答してしまうようなケースがあります。これは表形式のデータを正しく認識できていないことが原因です。
前川：その課題に対する解決策はありますか？
城田：はい。最近ではLLMに特化した前処理ツールが登場しています。例えば専用のパンダスのようなライブラリや、スタートアップが提供するツールがあります。特に日本企業にとって使いやすいのが、クラウドベンダーが提供しているサービスです。
具体的には、Microsoftのドキュメントインテリジェンス、GoogleのVertex AI Studio、AWSのナレッジベースforAmazon Bedrock内のアドバンスドパーシングなどがあります。これらのツールを使用すると、テーブル形式のデータをマークダウン形式に変換するなど、AIが正確に読み取れる形式に変換できます。
小島：クラウドベンダーのツールを使用する際の注意点はありますか？
城田：はい。これらのツールはそれぞれ特徴が異なりますので、自社のデータ形式や利用目的に合わせて選択する必要があります。また、データの前処理は精度向上の基盤となる重要な工程ですので、単にツールを導入するだけでなく、出力結果の検証も重要です。
前川：前処理の重要性がよく分かりました。次は具体的なチャンキング手法について見ていきましょう。
2.5. チャンキング手法の種類と選択基準
前川：チャンキングについて、具体的にどのような手法があるのでしょうか？
城田：はい。チャンキングの方法は大きく分けて複数の種類があります。まず、最も基本的な方法として、テキストの内容や構造を一切無視して、事前に決めた文字数やトークン数で分割する「固定長チャンキング」があります。
前川：単純な分割では問題が起きないのでしょうか？
城田：実はそこが重要な点です。単純に分割すると、関連する情報が複数のチャンクに分割されて格納されることがあり、必要な情報がヒットしないというリスクが生じます。逆に、大きすぎる分割にすると、不要な情報が多く含まれすぎて検索性能が低下してしまいます。
小島：より効果的な方法はありますか？
城田：はい。例えば「ウィンドウスライディングチャンキング」という手法があります。これは少しずつオーバーラップするように分割することで、情報が失われるリスクを最小限に抑える方法です。また、文章の構造に着目して段落やセクションの区切りで分割する方法もあります。
前川：もう少し高度な手法についても教えていただけますか？
城田：より高度な手法として「セマンティックチャンキング」があります。これはテキストの意味的なまとまりで分割する方法です。また「階層チャンキング」では、テキストを親のチャンクと子供のチャンクに階層的に分割します。
前川：それぞれの手法にメリット・デメリットがあると思いますが。
城田：その通りです。例えばセマンティックチャンキングは非常に効果的な手法ですが、意味的な解析を行うため、計算リソースが大量に必要になり、実装も複雑になりやすいというデメリットがあります。一般的に、上から下に行くほど精度は上がりますが、コストも上がっていくというトレードオフの関係にあります。
前川：実際の選択はどのように行えばよいでしょうか？
城田：自分たちが使うデータの性質、要求される精度、使える計算リソース、実装の複雑さ、これらを総合的に考慮して決定する必要があります。必ずしも最も高度な手法が最適解とは限りません。
2.6. エンベディングモデルの選択と評価
前川：エンベディングモデルの選択について、具体的な評価方法はありますか？
城田：はい。エンベディングモデルの選択については、MTEBという重要なベンチマークツールがあります。これは様々なタスクにおけるエンベディングモデルの性能を評価するためのベンチマークです。
前川：実際のスコアについても教えていただけますか？
城田：言語が英語の場合、Hugging Faceで公開されている検索タスクのスコア上位モデルを参考にすることができます。ただし、これはあくまでも英語の場合であり、日本語では全く異なる結果になる可能性が高いことに注意が必要です。
小島：モデルの選択基準として、他に考慮すべき点はありますか？
城田：はい。検索タスクの性能だけでなく、クラスタリングの性能、対応する言語の種類、次元数、そしてコストやライセンスなども総合的に判断する必要があります。また、使用するデータの性質によっても適切なモデルは変わってきます。
前川：新しい手法なども出てきているのでしょうか？
城田：はい。最近では1つのモデルだけを使うのではなく、複数のモデルを動的に使い分ける「ルーターリトリーバー」という手法も提案されています。これによって、より柔軟かつ高精度な検索が可能になります。
前川：実際の導入を考える企業としては、どのような点に注目すべきでしょうか？
城田：まずはMTEBベンチマークを参考に、自社の用途に合った性能を持つモデルを選定することをお勧めします。ただし、ベンチマークスコアだけでなく、実際のデータでの検証も重要です。また、継続的な運用コストやライセンス条件についても事前に十分な確認が必要です。
2.7. ベクトルデータベースの種類と特徴
前川：ベクトルデータベースにも様々な種類があるようですが、具体的にどのように分類されるのでしょうか？
城田：ベクトルデータベースは大きく3つのタイプに分類できます。まず、ベクトルデータの格納・検索・管理に特化したライブラリ、次にベクトル専用のデータベース、そして従来のリレーショナルデータベースにベクトルデータのサポートが追加されたエンタープライズデータベースです。
前川：それぞれのタイプの特徴について、もう少し詳しく説明していただけますか？
城田：はい。これらは主にサポートしているデータタイプ、検索性能、スケーラビリティ、そして特定の検索アルゴリズムやディスタンス計算メトリクスのサポート状況などで違いがあります。特に企業での利用を考えた場合、エンタープライズデータベースが注目されます。
小島：エンタープライズデータベースを選ぶ理由は何でしょうか？
城田：スケーラビリティの観点で優れているからです。ただし、ベクトルデータのサポートが追加されてからまだ日が浅いため、今後のサポート機能の充実に期待したい部分もあります。
前川：クラウドベンダーの動きはいかがでしょうか？
城田：最近では各クラウドベンダーがマネージドサービスとしてベクトルデータベースを提供し始めています。これらのサービスは、運用管理の負担を軽減できる点で、特に企業にとって使いやすい選択肢となっています。
前川：選択の際の判断基準について、アドバイスはありますか？
城田：まず、自社のデータ規模とスケーラビリティ要件を確認し、次に既存のデータベース環境との統合のしやすさ、そして運用管理の負荷とコストを総合的に評価することをお勧めします。また、ベクトル検索の性能要件も重要な判断基準となります。
3. RAGの最新動向
3.1. グラフRAGの登場と特徴
前川：ここ数ヶ月で注目されている新しいRAGの手法について教えていただけますか？
城田：はい。最近特に注目を集めているのが、ベクトルデータベースの代わりにグラフデータベースを使用する「グラフRAG」という手法です。ナレッジグラフを生成して、それを検索に活用する方法です。
前川：ナレッジグラフの基本概念について、具体的に説明していただけますか？
城田：簡単なイメージをお示しすると、例えば「富士山」と「東京」という単語があった場合、それらの関係性を「近く」というエッジで結ぶことができます。また、「富士山」と「日本」の関係を「象徴」というエッジで結ぶというように、単語間の関係性を明示的に表現することができます。
前川：従来のRAGと比べて、どのような違いがありますか？
城田：具体例で説明させていただきます。例えば「日本の首都から見える有名な山は？」というクエリーが投げられた場合、従来のRAGでは「日本」「首都」「山」というようなキーワードで関連文章を検索し、回答を導き出すことになります。一方、グラフRAGの場合は、「日本」→「首都」→「東京」→「近く」→「富士山」というパスを辿ることで、より正確に「富士山」という回答を導き出すことができます。特に複雑な質問や多段階の推論が必要な場合に非常に有効な手法です。
小島：具体的にどのような用途に適していますか？
城田：法文書の検索と分析、医学研究や診断支援などが代表的な用途です。例えば法文書の場合、ある契約書が別の契約書の一部を参照していたり、過去の判例に基づいた法的判断が必要になることが多いため、このような複雑な関係性を扱えるグラフRAGが適しています。
前川：課題はありますか？
城田：はい。従来のRAGに比べて実装が複雑で、計算コストも高くなります。また、グラフデータベースを扱える技術者の確保も課題となります。技術選択の際は、タスクの複雑さ、データの性質、関係性の重要度、スケーラビリティ要件、実装リソースなどを総合的に判断する必要があります。最近では、両方の利点を活かしたハイブリッドRAGという手法も提案されています。
3.2. Anthropicのコンテキスト検索手法
前川：最新の動向としてAnthropicが新しい手法を発表したそうですね。
城田：はい。Anthropicが2023年9月20日に公開したコンテキスト検索という手法について説明させていただきます。この手法の問題意識は非常に興味深いものです。
前川：具体的な例を挙げて説明していただけますか？
城田：例えば、「2023年第3四半期の野村総合研究所の売上収益の伸びは前年同期比でどのくらいでしたか」というプロンプトを投げた場合を考えてみましょう。通常の検索では「当社の売上収益は前年同期に比べて6%増加しました」といった文章が見つかります。しかし、この「当社」が具体的にどの会社を指しているのか、「前年同期」が具体的にいつなのかという情報が欠落しています。
小島：その課題に対して、新手法ではどのように対応するのでしょうか？
城田：Anthropicの手法では、チャンクに対してチャンク固有の説明コンテキストを追加します。具体的には、元のチャンクの前に「このチャンクは2023年第3四半期の野村総合研究所の業績に関する決算発表資料からのものです。前年同期の売上収益は1700円でした」といった文脈情報を説明するテキストを追加します。
前川：その効果はどの程度なのでしょうか？
城田：Anthropicの公開資料によると、このようなコンテキスト情報の追加により、回答の精度が大幅に向上したとされています。特に時間的な関係性や組織の参照関係が重要な質問に対して、より正確な回答が得られるようになったということです。
小島：実装する際の注意点はありますか？
城田：はい。コンテキスト情報の追加方法自体は比較的シンプルですが、どのような情報を追加すべきかの判断が重要になります。また、追加する情報量とシステムの応答速度のバランスも考慮する必要があります。詳しくはAnthropicの発表資料をご確認いただければと思います。
3.3. クエリカスタマイズ手法
前川：検索クエリーの側からの改善アプローチについても、何か新しい手法はありますか？
城田：はい。ユーザーが入力した元のクエリーをLLMを使ってより検索に適した形に変換する「クエリカスタマイズ」という手法があります。特に注目されているのが「マルチクエリー」という方法です。
前川：具体的にはどのような手法なのでしょうか？
城田：その名の通り、1つのクエリーを複数の異なる形に変換し、それらのクエリーを使って複数回の検索を行い、最後に結果を統合するというアプローチです。具体例を挙げてみましょう。
例えば、「AIの倫理的問題」というクエリーが入力された場合、これを「AIと倫理」「AIによるプライバシー問題」「AIと人権問題」というように複数の形に分割・変換します。それぞれのクエリーで検索を行い、最後にLLMが結果を統合して回答を作成します。
小島：このアプローチにはどのような利点があるのでしょうか？
城田：1つのクエリーだけでは取りこぼす可能性のある関連情報も、複数の異なる観点からの検索によって補完できるようになります。また、抽象的な質問に対しても、より具体的な側面から情報を収集できるという利点があります。
前川：実装の難しさはどうでしょうか？
城田：クエリの分割・変換ロジックの設計と、結果の統合プロセスの最適化が重要になります。また、複数回の検索を行うため、レスポンス時間とのバランスも考慮する必要があります。ただし、従来のRAGの基本的なアーキテクチャを活かせるため、比較的導入しやすい改善手法の一つと言えます。
3.4. 各手法の実装難度とコスト比較
前川：ここまで様々な手法を紹介いただきましたが、それぞれの実装難度やコストについて比較評価をお願いできますか？
城田：はい。これまでご紹介した手法の中で、最も実装難度が高く、コストも高いのはグラフRAGです。ただし、精度は最も高いという特徴があります。具体的な実装では、計算リソースが大量に必要になる上、実装自体も複雑になりやすいという課題があります。
前川：より実装が容易な手法はありますか？
城田：はい。データの前処理やチャンクサイズの調整といったアプローチは、比較的実装難度が低いと言えます。これらは既存のツールやライブラリを活用できる場合も多く、開発・維持コストを抑えられます。
小島：効果と実装の難しさのバランスが最も良い手法は何でしょうか？
城田：Anthropicのコンテキスト検索手法は、実装の複雑さの割に効果が高いと評価できます。単純にコンテキスト情報を追加するだけなので、実装自体は比較的シンプルです。ただし、適切なコンテキスト情報の設計には工夫が必要です。
前川：企業が実際に導入を検討する際のアドバイスをいただけますか？
城田：はい。闇雲に手をつけるのではなく、実装の難しさ、開発維持コスト、そして保有されているスキルを含めて総合的に判断することが重要です。また、既存のライブラリやクラウドサービスでサポートされている機能を確認し、車輪の再発明を避けることも重要です。
4. AIエージェントの現状
4.1. AIエージェントの定義と特徴
前川：では次に、AIエージェントについてお話を伺いたいと思います。まずはAIエージェントの基本的な定義からお願いできますか？
城田：AIエージェントとは、人間が細かく指示をしなくても、目標達成のために自律的に行動し、タスクを完了していくソフトウェアシステムです。重要なポイントは、タスクの支援だけでなく、完了までを目指すという点です。
前川：従来のチャットボットとの違いを具体的に説明していただけますか？
城田：例えば、ユーザーが「AI エージェントが金融業界に与える影響についてレポートを作成して」という依頼を投げた場合、従来のチャットボットではユーザーが細かくプロンプトの形で指示を出す必要がありました。一方、AIエージェントの場合は、自分でどういったタスクを行えばこの依頼に答えられるかを考え、インターネットから情報収集したり、社内データベースを検索したり、データを分析したりといった作業を自律的に行います。
小島：つまり、指示待ちではなく、自発的に行動するということですね。
城田：その通りです。従来のチャットGPTのようなシステムは詳細なプロンプトの入力が必要な「指示待ち」であるのに対して、AIエージェントは自立的に行動するという点が大きな違いです。ただし、現時点ではまだ完全な自律性を獲得しているわけではなく、ある程度人間の介在が必要な段階です。
前川：この自律性は、どのような技術によって実現されているのでしょうか？
城田：これには複数のモジュールが関係しており、特に重要なのが次にお話する基本的なアーキテクチャの構成要素です。メモリによる文脈の保持、計画モジュールによる行動の決定、そしてツールを使用した実際の作業実行という流れで自律的な行動を実現しています。
4.2. 基本的なアーキテクチャ
前川：AIエージェントのアーキテクチャについて、具体的な構成要素を教えていただけますか？
城田：はい。AIエージェントは一般的に4つの主要なモジュールで構成されています。まず「メモリーモジュール」があります。これはユーザーが過去にどのようなプロンプトを投げたかなど、コミュニケーションの文脈を記憶しておく機能を担当します。
前川：計画に関わる部分はどのようになっていますか？
城田：2つ目の「計画モジュール」が、ユーザーが投げたプロンプトに対してどういう形で作業を組み立てればよいかを考える役割を担います。これは自律的な行動の核となる部分です。
小島：具体的なアクションはどのように実行されるのでしょうか？
城田：それが3つ目の「ツールモジュール」の役割です。外部のリソースを検索したり、APIを実行したり、データ検索を行ったりといった具体的な作業を実行します。
前川：これらのモジュール間の連携はどのように管理されているのでしょうか？
城田：4つ目の「コントロールモジュール」が全体の制御を担当します。これらのモジュールが連携して動作することで、人間の細かい指示がなくても目的の達成に向けて自律的に行動することが可能になります。ただし、現状ではまだ完全な自律性には至っておらず、人間の介在が必要な部分も残っています。
4.3. Klarna社の実装事例と効果測定
前川：AIエージェントの具体的な実装例について、成功事例はありますか？
城田：はい。スウェーデンのストックホルムにあるKlarna社の事例が非常に興味深いものです。Klarnaは後払いサービス（BNPL）を提供するプロバイダーですが、Anthropic社と提携してカスタマーサービス用のAIエージェントを開発しました。
前川：具体的な成果はどうだったのでしょうか？
城田：驚くべき結果が出ています。リリースからわずか1ヶ月で、お客様とのチャットの23%にあたる230万回の会話を処理しました。これは人間のカスタマーサービスエージェント約700人分の仕事量に相当します。
小島：品質面での評価はいかがでしょうか？
城田：顧客満足度は人間のエージェントが対応した場合とほぼ同等の水準を維持しています。特筆すべきは、問題解決能力が非常に優れており、その結果として繰り返しの問い合わせが25%も減少したことです。さらに、問題解決に要する時間も、従来の11分から2分未満にまで短縮されました。
前川：従来のチャットボットと比べて、どのような点が改善されたのでしょうか？
城田：大きな違いは、単純な質問応答だけでなく、返金処理や返品処理、注文キャンセルなどの具体的なアクションまで実行できる点です。これにより、ユーザーは一連の問題解決をAIエージェントだけで完結できるようになりました。
小島：このような成果は、他の企業でも再現可能なのでしょうか？
城田：技術的には可能ですが、実装には十分な準備が必要です。特に重要なのは、業務プロセスの明確な定義と、適切なガードレールの設定です。また、完全な自動化を目指すのではなく、人間との適切な役割分担を設計することが成功の鍵となります。
4.4. エージェントの種類と活用領域
前川：AIエージェントの具体的な活用領域について教えていただけますか？
城田：現在、海外のスタートアップを中心に様々なタイプのエージェントが開発されています。大きく分けると、水平業務向けと垂直業務向けの2つに分類できます。
前川：水平業務向けとは、具体的にどのような領域でしょうか？
城田：主に4つの分野で発展が進んでいます。まず、先ほどのKlarna社の例のような「カスタマーサポート」があります。次に「セールスエージェント」で、これはリードの生成や見積もり、メールの自動生成などによって営業プロセスを自動化します。3つ目は「ソフトウェア開発エージェント」です。これまではGitHubのコーパイロットのような補完型アシスタントが主流でしたが、より自律的なエージェントへと進化しています。4つ目が「サイバーセキュリティエージェント」で、特にセキュリティオペレーションセンターの役割を担うものが注目されています。
小島：サイバーセキュリティ分野での需要が高いのはなぜでしょうか？
城田：サイバーセキュリティの専門人材が世界的に不足している現状があり、この社会課題に対してAIエージェントが有効な解決策となる可能性が高いからです。
前川：垂直業務向けについてはいかがでしょうか？
城田：業界特化型のエージェントも徐々に登場してきています。例えば、銀行や保険業界向け、製造業向け、ゲーム業界向けなどです。具体例を挙げると、保険業界では保険の引受を専門に行うエージェント、銀行ではコンプライアンスチェックを行うエージェントなどが開発されています。
小島：現状での課題はありますか？
城田：はい。完全な自律性にはまだ達していないため、多くの場合で人間の介在が必要です。しかし、これは段階的な進化の過程だと考えています。第3次AIブームの初期にはルールベースのチャットボットから始まり、生成AIの登場でコーパイロット型に進化し、現在は自律型エージェントへと発展してきているという流れがあります。
5. AIエージェント開発の実践
5.1. 開発フレームワークとツール
前川：AIエージェントを自社で開発する場合、どのようなツールやフレームワークを活用できるのでしょうか？
城田：現在、便利なフレームワークやサービスが多数提供されています。まずオープンソースのものとしては、Microsoftが開発している「Auto-Agent」があります。また、ライブラリやフレームワークとしては、LangChainの「LangGraph」が有名です。最近では、LlamaIndexが「Workflows」というツールを公開しました。
小島：クラウドベンダーからの提供も始まっているのでしょうか？
城田：はい。AWSもGoogle Cloudも、既にAIエージェントを作成できるサービスを提供しています。これらのサービスを使用すると、開発工数を大幅に削減できる利点があります。
前川：これらのツールを選択する際の基準はありますか？
城田：まず、既存の開発実績を考慮することが重要です。例えば、RAGの開発でLangChainを使用した経験があるのであれば、同じフレームワークファミリーの利用を検討するのが効率的です。また、自社の技術スタックとの親和性も重要な判断基準となります。
小島：フレームワークやツールの利用に際して、注意点はありますか？
城田：はい。これらのツールは便利である一方で、急速に進化している領域であることを認識しておく必要があります。定期的なアップデートへの対応や、新しい機能の評価が必要になってきます。また、クラウドサービスを利用する場合は、コストとセキュリティの観点からも十分な検討が必要です。
5.2. マルチエージェントシステムの事例
前川：マルチエージェントシステムの具体的な実装事例について教えていただけますか？
城田：はい。特に興味深い事例として、気象疾患の診断におけるマルチエージェントの活用があります。通常の疾患であれば症例も豊富で比較的診断が容易なのですが、気象疾患の場合は症例が少ないため、診断が難しい課題がありました。
前川：その課題に対して、どのようなアプローチを取ったのでしょうか？
城田：研究では、単体のGPT-3.5やGPT-4を使用するのではなく、複数のエージェントが協力して診断を行うマルチエージェントシステムを構築しました。論文によると、単体のモデルを使用した場合と比較して、マルチエージェントを使用した方が診断の正確性が大幅に向上したという結果が報告されています。
小島：他に注目すべき事例はありますか？
城田：ソフトウェア開発分野では、チャットDEVという事例が知られています。これは複数のエージェントがソフトウェア開発のプロセスに関わる形で実装されています。しかし、実際の成果を見ると、GitHubの問題の約14%程度しか解決できないという結果も出ています。人間の開発者であればもっと高い解決率が期待できることを考えると、完全自律型エージェントの実現にはまだ時間がかかると考えられます。
前川：この分野での今後の展望はいかがでしょうか？
城田：マルチエージェントシステムは、単一のエージェントでは対応が難しい複雑な問題に対して特に有効だと考えています。ただし、エージェント間の協調や役割分担の設計が重要で、これらをうまく設計できるかどうかが成功の鍵となります。
5.3. コンピュータ制御エージェントの実装例
前川：コンピュータを制御するタイプのAIエージェントについて、具体的な実装例はありますか？
城田：はい。その代表的な例として、ZlaabのJSというツールがあります。これは実行したいタスクを入力すると、ブラウザを使用してエージェントが人間と同じように自動的にウェブサイトを操作してくれるシステムです。
前川：具体的な動作例を示していただけますか？
城田：例えば、Airbnbで宿を予約したいという場合を考えてみましょう。ユーザーが「ロサンゼルスの宿を予約したい」というシンプルな指示を出すと、エージェントは必要な情報が不足していることを認識し、「何人で泊まりますか？」「予算はいくらですか？」といった具体的な質問を自動的に行います。
小島：その後の予約プロセスはどのように進むのでしょうか？
城田：エージェントは、通常であれば人間が行う一連の操作、つまりGoogleでAirbnbのサイトを検索し、そこからAirbnbのウェブサイトに移動し、必要な情報を入力して検索するといった一連のプロセスを自動的に実行します。ユーザーが確認した予算や人数の条件に基づいて、適切な宿泊施設を探し出し、予約までのプロセスを代行します。
前川：このような自動化には課題もありそうですが。
城田：ええ、その通りです。特に決済を伴う操作では、セキュリティやリスク管理の観点から、完全な自動化は避け、重要なステップでは人間の確認を必要とするような設計が一般的です。この点については、後ほど安全性対策のセクションで詳しく説明させていただきます。
5.4. 実装上の課題と限界
前川：AIエージェントの実装について、現状での課題や限界についてお聞かせください。
城田：はい。現状では、完全な意味での自律的なエージェントの実現には至っていません。実際の運用では、多くの場合で人間の介在が必要な状況です。
前川：具体的にどのような場面で人間の介在が必要になるのでしょうか？
城田：例えばカスタマーサービスの場合、夜間に人間の生死に関わるような重要な質問が投げかけられることがあります。このような場合、AIエージェントが勝手に回答するのではなく、人間のオペレーターにエスカレーションする機能が必要不可欠です。
小島：他にも課題はありますか？
城田：はい。進化の過程を見ると、第3次AIブームの初期ではルールベースのチャットボットから始まり、その後コーパイロット型のチャットボットが登場し、現在は自律型のエージェントへと発展してきています。しかし、例えばソフトウェア開発エージェントのDevinでさえ、GitHubの問題の14%程度しか解決できていないという現状があります。人間の開発者であればもっと高い解決率が期待できることを考えると、完全自律型エージェントの実現にはまだ時間がかかると考えられます。
前川：今後の技術発展に向けて、重要なポイントは何でしょうか？
城田：重要なのは、完全な自動化を目指すのではなく、人間との適切な役割分担を設計することです。また、安全性やリスク管理の観点から、重要な判断や決定については必ず人間の確認を必要とする設計とすることも重要です。エージェントの能力が向上していく中で、人間との協調領域を適切に設定していくことが課題となっています。
6. 今後の展望
6.1. RAGの制度向上に向けた実践的アドバイス
前川：これまでの議論を踏まえて、RAGの精度向上に向けた具体的なアドバイスをいただけますか？
城田：はい。まず、今日ご紹介した精度向上策の中で、まだ実施されていない策があれば、ぜひ検討していただきたいと思います。ただし、闇雲に手をつけるのではなく、実装の難しさ、開発維持コスト、そして保有されているスキルを含めて総合的に判断することが重要です。
小島：具体的な導入ステップについて、アドバイスはありますか？
城田：最初のステップとしては、一見難しそうな施策であっても、既にライブラリやクラウドサービスの中でサポートされていることが多いので、まずはそういった状況を確認することをお勧めします。車輪の再発明のような形にならないよう注意が必要です。
前川：効果測定についてはどのようにお考えですか？
城田：精度向上の取り組みを始める前に、現状の精度を定量的に測定しておくことが重要です。また、各施策の実施前後で比較可能な指標を設定し、継続的にモニタリングすることで、投資対効果を適切に評価できます。
小島：リソースの制約がある企業への提言はありますか？
城田：既存のフレームワークやクラウドサービスを活用することで、開発コストを抑えながら効果的な改善が可能です。特に、既に他の分野でRAGを実装している企業であれば、その経験やノウハウを活かせる手法から着手することをお勧めします。
6.2. AIエージェント導入への提言
前川：AIエージェントの導入を検討している企業に向けて、具体的なアドバイスをお願いします。
城田：はい。まず当面は、海外のスタートアップが提供しているプロダクトの動向をウォッチすることをお勧めします。なぜなら、現在市場に出ているプロダクトのほとんどが海外スタートアップによるものだからです。
前川：実際に自社で開発する場合は、どのようなアプローチを取るべきでしょうか？
城田：その場合は、LangChainやLlamaIndexといったフレームワークの活用を検討すべきです。また、クラウドサービスの活用も有効な選択肢となります。特に、既にRAGでLangChainを使用した経験があるような場合は、そういった実績のあるフレームワークから始めることをお勧めします。
小島：リスク管理の観点からはどのような点に注意が必要でしょうか？
城田：特に重要なのは、完全な自動化を目指すのではなく、人間との適切な役割分担を設計することです。例えば、重要な判断や決定については必ず人間の確認を必要とする設計にする、夜間の重要な問い合わせは人間のオペレーターにエスカレーションするなど、適切なガードレールを設けることが重要です。
前川：段階的な展開について、具体的な手順はありますか？
城田：はい。まずは比較的リスクの低い、定型的な業務から始めることをお勧めします。実績を積み重ねながら、徐々に対象領域を拡大していくアプローチが望ましいでしょう。また、導入当初は人間の監視体制を手厚くし、エージェントの動作や判断の精度を十分に検証しながら進めていくことが重要です。
6.3. 既存フレームワーク活用の重要性
前川：フレームワークの選択と活用について、具体的なアドバイスをお願いできますか？
城田：はい。RAGやAIエージェントの実装を検討する際、一見難しそうに見える施策でも、既にライブラリやクラウドサービスの中でサポートされていることが多いのです。まずはそういった既存のソリューションの状況を確認することが重要です。
小島：なぜ既存のフレームワークを活用することが推奨されるのでしょうか？
城田：車輪の再発明を避けるためです。特に社内で開発を行う場合、LangChainやLlamaIndexなどの実績のあるフレームワークの活用を検討すべきです。これらのフレームワークは既に多くの企業で活用され、継続的に改善されています。
前川：フレームワーク選択の際の判断基準はありますか？
城田：はい。特に重要なのは、既存の開発経験との親和性です。例えば、すでにRAGでLangChainを使用した経験がある場合は、その実績を活かせるフレームワークを選択することをお勧めします。また、クラウドサービスについても、自社が普段使用しているベンダーのサービスから検討を始めるのが効率的です。
小島：実際の活用において注意すべき点はありますか？
城田：これらのツールは急速に進化している領域であることを認識しておく必要があります。定期的なアップデートへの対応や、新機能の評価が必要になってきます。また、クラウドサービスを利用する場合は、コストとセキュリティの観点からも十分な検討が必要です。さらに、開発工数を削減できる一方で、適切な管理と運用体制の整備も重要になってきます。
7. 質疑応答
7.1. 小規模LLMの可能性について
前川：先月、NTTの日高人間情報研究所長からNTT版LLMの話を伺いましたが､海外の大規模モデルと比較して、パラメータは小さいものの、日本語文献を中心に十分な学習を行うことで、精度面でも遜色ない結果が得られているようです。このような小規模LLMについて、どのようにお考えでしょうか？
城田：はい。必ずしも海外の大手ベンダーと同じ規模が必要というわけではないと考えています。特に最近では「SLM（Small Language Model）」という言葉が注目されており、特定の用途であれば小規模なモデルでも十分な性能を発揮できる可能性があります。
小島：具体的にどのような利点がありますか？
城田：モデルサイズが小さいことで、取り扱いがしやすくなります。例えば、Apple社のVisonのように、エッジ側でAIモデルを搭載する場合、大きなモデルは搭載できませんので、小さなモデルを使用することでプライバシーやレスポンス面での利点を活かすことができます。
前川：NTTのケースについてはいかがでしょうか？
城田：NTTの場合、SLMを意識されているわけではないと思いますが、日本における日本語のデータ量という意味では屈指の規模を持っています。そのデータで学習させたモデルということで、非常に期待が大きいと考えています。
7.2. AGIへの発展可能性
前川：AIエージェント技術の進展を通じて汎用人工知能（AGI）が実現するという見方について、どのようにお考えでしょうか？
城田：おっしゃる通り、AIエージェントが進化していけば最終的には汎用人工知能に近づいていくという見方は、多くの業界関係者が指摘している通りだと思います。ただし、現状のAIエージェントはまだ特定の用途に特化したものが主流です。例えばカスタマーサービスに特化したエージェントや、セールスに特化したエージェントといった形です。
小島：完全な自律性の実現にはまだ時間がかかりそうですね。
城田：はい。現状では、それらのエージェントでさえも人間の介在が完全に不要というわけではありません。ただし、AIエージェントの進化のスピードは非常に早く、できる領域は着実に広がっています。特定の業務から始まり、徐々により汎用的な幅広い業務に対応できるように進化していくと考えられます。
前川：その発展過程について、もう少し具体的に説明していただけますか？
城田：現在のAIエージェントは特定の業務しかできない状態から、徐々にできることが増えていき、最終的により汎用的なエージェントになっていくという道筋が考えられます。それが究極的に汎用人工知能に近づいていくというシナリオです。ただし、この進化の過程でどの程度の時間がかかるのか、また途中でどのような技術的ブレークスルーが必要になるのかについては、まだ多くの不確実性が存在します。
7.3. AIエージェントの安全性対策
前川：AIエージェントが外部サービスにアクセスする際のリスク、例えば予算をオーバーした宿を予約してしまうなどの問題について、どのような対策が取られているのでしょうか？
城田：はい。外部サービスへのアクセスや、カスタマーサポートなどでは、事前に「ガードレール」と呼ばれる安全対策を実装することが標準的な手法となっています。例えば、予算オーバーなどが起こらないよう、あらかじめ制限を設けておくことが重要です。
小島：具体的な実装方法について、もう少し詳しく説明していただけますか？
城田：現状では、最終的な決定や実行の前に必ず「この宿を予約しますがよろしいですか？」といった形で人間の確認を求めるステップを設けることが一般的です。また、カスタマーサービスの場合、特に夜間に人命に関わるような重要な質問が投げかけられることもあります。そのような場合、AIエージェントが勝手に回答するのではなく、人間のオペレーターにエスカレーションする機能が必要不可欠です。
前川：その他に重要な安全対策はありますか？
城田：はい。実はこれらの安全対策は、AIエージェントの発展段階に応じて進化させていく必要があります。第3次AIブームの初期のルールベースのチャットボットから、現在の自律型エージェントまで進化する中で、安全性の確保方法も変化してきています。完全な自動化を目指すのではなく、人間との適切な役割分担を設計することが、現時点での最も重要な安全対策だと考えています。