「RAG（検索拡張）」とは？回答精度を向上させるアプローチについて

RAGとは？

「ChatGPTで経費精算のルールを聞いたら、一般的な話しか返ってこない」

「製品マニュアルの内容を質問しても、自社製品のことは何も知らない」

多くの企業がChatGPTやClaude、Geminiなどの最先端AIを導入しても、このような壁にぶつかります。理由はシンプルです。これらのAIは、インターネット上の公開情報しか学習していないからです。

RAG（Retrieval-Augmented Generation）は、まさにこの課題を解決する技術です。

なぜ生成AIは社内情報を知らないのか

ChatGPTの登場により、大規模言語モデル（以下、LLM）は広く認知され、企業での活用が急速に進んでいます。2024年にはGPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Proなど、より高性能で効率的なLLMが登場し、さらに同年後半にはOpenAIのo1やo1-miniといった「推論モデル」と呼ばれる新しいタイプのモデルも登場しました。

2025年に入ってからも技術革新は加速しています。5月にはAnthropicがClaude Opus 4とClaude Sonnet 4をリリースし、特にコーディング能力で業界最高水準を達成（SWE-benchで72.5%以上）。OpenAIはGPT-4.1に加えてo3、o4-miniといったより高度な推論モデルを展開し、GoogleはGemini 2.5 Proでマルチモーダル機能（テキスト、画像、音声、動画の統合処理）を強化しました。xAIのGrok 3/4やMetaのLlama 4など、新規参入も相次いでおり、企業はかつてないほど多様な選択肢から自社に最適なLLMを選べるようになっています。

しかし、企業がこれらの最新LLMを実務で活用しようとすると、依然として重大な制約に直面します。その制約の本質を理解するには、まずLLMが「何を知っているか」、より正確に言えば「何を学習データとして使用しているか」を把握する必要があります。

OpenAIの公式論文「Language Models are Few-Shot Learners」（Brown et al., 2020）[1]によると、GPT-3の学習データの内訳は以下の通りです：

• Common Crawl（ウェブクロールデータ）: 60%

• WebText2（高品質ウェブページ）: 22%

• Books1・Books2（インターネット由来の書籍）: 計16%

• Wikipedia（英語版）: 3%

つまり、学習データの約85%がインターネット上の公開情報、約16%が書籍という構成です。さらに重要なのは、これらの約93%が英語のデータであり、日本語を含む非英語データはわずか7%に過ぎません。

この事実が示すのは、LLMが学習しているのは「公開されている一般的な情報」のみということです。各企業固有の内部情報（社内規程、技術マニュアル、顧客データ、プロジェクト資料、契約書、議事録など）は、当然ながらインターネット上に公開されておらず、LLMの学習データには一切含まれていません。

最新のLLMにはウェブ検索機能が搭載されているものもありますが、これも公開されたウェブサイトの情報しか参照できません。セキュリティで保護された社内システムや、アクセス制限のあるドキュメントには当然アクセスできません。

その結果、いくら高性能なLLMを導入しても、「一般的な質問には答えられるが、自社の業務に関する質問には答えられない」という状況に陥ります。例えば：

• 「当社の経費精算規程で、出張時のホテル代の上限はいくらですか？」

• 「製品Aのエラーコード E-2001の対処方法を教えてください」

• 「昨年度の営業部門の売上目標達成率は？」

これらの質問に対して、LLMは一般論しか答えられません。

RAG（Retrieval-Augmented Generationの略。日本語では検索拡張生成とも呼ばれる。以下、RAG）は、まさにこの課題を解決するための技術です。RAGを使えば、LLMが学習していない社内の非公開情報を基に、正確で具体的な回答を生成できるようになります。

仕組みは以下の通りです：

1. 事前処理: 社内文書、マニュアル、データベースなどを専用のRAGシステムに取り込み、検索可能な形式に変換します

2. 質問処理: ユーザーが質問すると、RAGシステムがその質問に関連する情報を社内データから検索します

3. 回答生成: 検索された情報とユーザーの質問をLLMに送信し、社内情報に基づいた具体的な回答を生成します

2024年から2025年にかけて、多くの企業がRAGの導入を進めています。理化学研究所がスーパーコンピュータ「富岳」のサポートに当社のRAGシステム「AskDona」を導入し、4時間かかっていた問い合わせ対応を5秒に短縮した事例は、RAGの実用性を証明する代表例となりました。

つまり、RAGは「LLMの汎用的な能力」と「企業固有の専門知識」を組み合わせることで、真に実用的なAIアシスタントを実現する技術なのです。

RAGは陳腐な技術？

いいえ、違います。RAGは今後さらに重要性を増す基盤技術です。「LLMが進化すればRAGは不要になる」「企業がファインチューニングでカスタムモデルを作ったり、SLMを開発すればRAGはいらない」という意見もありますが、それは技術の背景を理解していない誤解です。

なぜRAGは必要とされ続けるのか

1. 情報の即時更新性が不可欠だから
   企業の情報は日々更新されます。規程の改定、製品仕様の変更、組織変更、新しいプロジェクトの開始など、ビジネスは常に動いています。RAGなら、文書を差し替えるだけで即時最新情報での回答が可能です。一方、モデルの再学習には数日から数ヶ月かかり、その間にも情報は古くなっていきます。
   
   

2. コンテキストウィンドウの制約があるから
   最新のLLMは確かに大量の入力を処理できるようになりました。例えばGemini 2.5 Pro/Flashは100万トークン以上（日本語で約150万文字）を受け付けることができます。しかし、これは根本的な解決にはなりません。
   第一に、企業の保有する情報量を考えると、仮にコンテキストウィンドウが10倍、100倍に拡大しても、ユーザーが質問するたびに社内の全情報を毎回LLMに送信することは計算資源やコストの観点から非現実的です。
   第二に、より重要なのは、大量の情報を入力することが必ずしも良い結果につながらないという事実です。スタンフォード大学とMeta AI Researchの研究チームによる論文「Lost in the Middle: How Language Models Use Long Contexts」（Liu et al., 2023）[2] では、LLMは長大なコンテキストの中間部分にある情報を見落としやすいことが実証されています。質問に関係ない情報を大量に含めると、むしろ回答精度が低下するのです。
   つまり、「必要な情報だけを的確に選んでLLMに渡す」というRAGの基本機能は、コンテキストウィンドウがどれだけ拡大しても不可欠なのです。
   
   

3. AGI（汎用人工知能）が実現してもRAGは必要
   仮に人間レベルの汎用的な知能を持つAGIが登場したとしても、RAGの必要性は変わりません。理由はシンプルです。AGIがどれだけ賢くても、存在を知らない情報にはアクセスできないからです。

   
   例えば、世界最高の知能を持つ人間でも、あなたの会社の最新の売上データや内部規程を知ることはできません。同様に、AGIも各企業の社内情報に直接アクセスすることはできません。

   
   ここでRAGが本質的な役割を果たします。RAGは、AGIと企業の情報システムをつなぐインターフェースとして機能し、AGIが必要な社内情報を検索・取得できるようにします。AGIがユーザーの質問を理解し、RAGがその質問に関連する社内情報を探し出し、AGIがその情報を基に回答を生成する。この連携により、初めてAGIは企業固有の課題に対応できるようになるのです。

   
   つまり、AGIの登場は「RAGを不要にする」のではなく、「RAGをより重要にする」ことになります。AGIという高度な思考エンジンが、RAGという情報アクセス機能と組み合わさることで、真に実用的な企業向けAIシステムが実現するのです。

   
   

4. 企業独自のSLM（小規模言語モデル）時代でもRAGは重要
   最近では、企業が独自の小規模言語モデルを持つトレンドも生まれています。しかし、これらのモデルも以下の課題を抱えています：

   • 特定情報の選択的な更新や削除が技術的に困難

   • モデルの再学習には高額なGPUリソースと専門人材が必要

   • 学習データの品質管理とバイアス制御が複雑
     
     

5. 知識の編集技術の限界
   ROME（Rank-One Model Editing）やMEMIT（Mass-Editing Memory in Transformers）といった、モデルの知識を直接編集する技術も研究されています。しかし、これらは：

   • 限定的な事実の修正にしか使えない

   • 大規模な情報更新には対応できない

   • 高度な技術的専門知識が必要

   • 予期しない副作用のリスクがある

ファインチューニングとは違う？

違います。RAGとファインチューニングは、LLMの性能を向上させるという同じ目的を持ちながら、全く異なるアプローチを取る技術です。

ファインチューニングは、既存のLLMに対して特定のドメインやタスクのデータを追加学習させることで、モデル自体のパラメータを更新する手法です。例えば、法務専門のLLMを作りたい場合、大量の法律文書や判例でモデルを再学習させ、法律用語や法的思考に特化したモデルを作成します。この手法により、モデルは新しい知識を内部に「記憶」し、特定分野での応答品質が向上します。

一方、RAGはモデル自体には一切手を加えません。代わりに、外部のデータベースから必要な情報を検索し、その情報をコンテキストとしてLLMに提供することで、正確な回答を生成させます。つまり、モデルは「知識を覚える」のではなく、「提供された情報を理解して活用する」という役割に徹します。

この違いが生む最大の利点は「情報の即時更新性」です。ファインチューニングされたモデルが古い情報を更新するには、再度学習プロセスを実行する必要があり、これには数日から数週間、大規模なモデルでは数ヶ月かかることもあります。また、GPUなどの計算資源も必要です。さらに、特定の情報だけを選択的に忘却させたり更新したりすることは技術的に非常に困難で、しばしば意図しない副作用（他の知識への影響）を引き起こします。

RAGであれば、データベースの該当文書を差し替えるだけで、即時最新情報での回答が可能になります。例えば、社内規程が改定された場合、ファインチューニングでは全体の再学習が必要ですが、RAGなら該当文書を更新するだけで済みます。

コスト面でも大きな違いがあります。ファインチューニングには専門的な技術者、高性能な計算機、そして相当な時間が必要です。一方、RAGシステムは一度構築すれば、技術的な専門知識がなくても文書の追加・更新・削除が可能です。

つまり、ファインチューニングは「モデルの知識を変える」手法であり、RAGは「モデルに最新の資料を渡す」手法と言えるでしょう。企業の実務においては、日々更新される情報への対応が不可欠なため、RAGがより実用的な選択肢となることが多いのです。

RAGはどれも一緒なんじゃないの？

違います。RAGは基本的な仕組みこそ共通していますが、その実装方法やアーキテクチャによって性能に大きな差が生まれます。

多くの人は「RAGなんて、要は検索して、その結果をLLMに渡すだけでしょ？」と考えがちです。確かに基本原理はシンプルです。しかし、実際の性能は「どのように情報をデータベース化するか」「どのように検索するか」「何を検索対象とするか」「どのように情報を統合するか」といった実装の詳細に大きく左右されます。

理化学研究所と当社が共同検証した結果が、この事実を明確に示しています。スーパーコンピュータ「富岳」に関する約16,000ページの技術文書（マニュアル等）を使って、当社のAskDona、Google Cloud（Vertex AI Search）、Microsoft Azure（Azure AI Search）、AWS（Amazon Bedrock）、オープンソースのLangChainという5つのRAGシステムを比較しました。その結果、回答精度に顕著な差が現れました。AskDonaが80ポイントを超える精度を達成した一方、他の4システムは50〜60ポイント台に留まったのです。

なぜこれほどの差が生まれるのでしょうか。

RAGの仕組み（一般例）

RAGは「事前処理」と「リアルタイム処理」の2つのプロセスで構成されています。

事前処理：知識ベースの構築

1. 文書の取り込み: PDF、Officeファイル（Word、Excel、PowerPoint）、HTML、CSVなど様々な形式の文書を取り込みます

2. テキスト抽出: OCR技術などを使って文書から文字情報を抽出します

3. チャンキング（分割）: 抽出したテキストを適切なサイズに分割します（一般的には500〜1000文字程度と100-200文字のオーバーラップなど）

4. ベクトル化: 各チャンクをEmbeddingモデルで数値ベクトルに変換します

5. インデックス作成: ベクトルデータベースに保存し、高速検索可能な状態にします

リアルタイム処理：質問への回答生成

1. 質問の受付: ユーザーからの質問を受け取ります

2. 質問のベクトル化: 質問文を事前処理と同じEmbeddingモデルでベクトル化します

3. 類似度検索: ベクトルデータベースから関連性の高い情報を検索します（通常は上位5〜10件）

4. コンテキスト生成: 検索結果とユーザーの質問を組み合わせてプロンプトを作成します

5. 回答生成: LLMがコンテキストを基に回答を生成します

この仕組みにより、LLMが学習していない最新情報や専門的な社内文書に基づいた回答が可能になります。

一般的なRAGの欠点と、AskDonaの解決アプローチ

多くの企業でRAGを導入しても「期待した回答が得られない」という状況に陥っています。

ここでは、一般的なRAGが抱える5つの主要な課題と、AskDonaがそれぞれをどう解決しているかを説明します。

課題1：情報抽出の精度問題

一般的なRAGの課題

• 表が正しく抽出されない

• 行列で整理されていないExcelデータを正確に抽出できない

• レイアウトが複雑な文書で情報が欠落する

• 数式や化学式などの特殊表記が文字化けしたり正確に抽出されない

• チャートや画像などの視覚的に表現された情報が抽出されない

AskDonaの解決アプローチ

• 構造認識OCR: 単なる文字認識ではなく、表の構造や数式（LaTeX形式）も正確に抽出

• 視覚情報の抽出: チャートや画像などの視覚的に表現された情報を抽出

• 高精度な前処理: PDFやOfficeファイルの複雑なレイアウトも正確に解析

課題2：チャンキングによる文脈の分断

一般的なRAGの課題

• 固定長分割により、意味のまとまりが途中で切れる

• 重要な前後関係が失われ、誤った解釈を招く

• 章や節の構造情報が保持されない

• 意味のまとまりの分割をLLMに任せ、抜け漏れの発生

AskDonaの解決アプローチ

• 動的チャンキング: 独自のチャンキングモデルが文書の意味を理解し、文脈が保たれる最適な単位で分割

• 抜け漏れ防止: チャンキングプロセスで情報の欠落が起きない仕組み

• メタデータ付与: ファイル名、ページ番号、章・節の見出しなどの構造情報を保持

課題3：単純な検索の限界

一般的なRAGの課題

• 表記ゆれや同義語に対応できない

• 質問の意図を理解せず、表面的なキーワードマッチングに依存

• 複数の観点から情報を収集する必要がある質問に対応できない

AskDonaの解決アプローチ

• ハイブリッド検索: ベクトル類似度やキーワード検索など複数の検索手法を組み合わせ

• コンテキスト保持: メタデータを活用し、特定のマニュアル内からの絞り込みなど文脈に基づいた検索が可能

• 日本語への最適化: 専門用語の表記ゆれに対応、文脈依存の意味解釈を正確に実行

課題4：「複合的なクエリ」への対応困難

一般的なRAGの課題

• 複数の文書を横断的に参照する必要がある質問に答えられない

• 原因と結果、前提条件と手順など、関連情報を統合できない

• 一度の検索で十分な情報が得られない場合、それ以上の探索ができない

AskDonaの解決アプローチ（dona-rag-2.0以降）

• AIエージェントによる自律探索: 質問を複数のサブクエリに分解し、必要な情報を再帰的に収集

• 多段階推論: 収集した情報を統合・評価し、不足があれば追加探索を実行

• 横断的な情報統合: 複数文書にまたがる情報を自動的に関連付けて回答

課題5：大規模データでの精度低下

一般的なRAGの課題

• データ量が増えるほど、無関係な情報（ノイズ）を拾いやすくなる

• 検索空間が広がることで、本当に必要な情報を見つけにくくなる

AskDonaの解決アプローチ

• ノイズ除去: 大規模データでも関連性の低い情報を効果的に排除

• 継続的な改善機能: 不回答となった質問を自動分析し、データソースの不足を特定

• 利用パターン学習: 質問傾向を把握し、システムを最適化

これらの技術により、理研の検証では当社のAskDonaが他社製品を20ポイント以上上回る精度を達成しました。特に「複合的なクエリ」において、単一の検索では回答困難な質問にも、AIエージェントが自律的に必要な情報を収集・統合することで、実用的な回答を生成できることが実証されています。

企業がRAGを効果的に活用するための準備事項

企業がRAGを導入し、実際に業務で活用して成果を出すためには、以下の準備を整える必要があります。なお、必ずしも全社導入から始める必要はなく、RAGと親和性の高い業務を行っている部署単位での導入も効果的です。

1. 質の高いデータソースの確保と整備

RAGでは、回答情報源を制御するために、基本的にRAGデータベースにある情報のみを回答情報源とします。つまり、RAGデータベースに誤った情報が含まれている場合、その誤った情報をもとに回答を生成してしまいます。そのため、RAGデータベースに追加する情報の質が高いことは必須条件です。

現実的な課題： 弊社がAskDonaを企業や組織に導入する中で得た知見として、多くの場合で以下のような課題があります：

• 社内情報が体系的に整理されていない

• そもそも重要な知識がデータ化されていない（暗黙知の状態）

• 複数のバージョンが混在し、最新版が不明確

• 部署ごとに異なるフォーマットで情報を管理

AskDonaでの解決アプローチ： AskDonaでは、単にRAGシステムを提供するだけでなく、社内データを作ること、整理することから支援します。例えば、よくある質問と回答を蓄積していくことで、徐々にRAGデータベースを充実させていく運用も可能です。

2. 実用レベルの回答精度と充実度の実現

前述の通り、RAGはどれも同じではありません。RAGデータベースにある情報をもとに正確な回答を生成できることは必要条件ですが、多くの企業がこの段階で躓いています。

よくある失敗パターン： 当社にご相談いただく企業の多くは、以下のような経験をしています：

• RAGを内製化したが、期待した精度が出ない

• ベンダーに開発を依頼したが、実務で使えるレベルに達しない

• 他社のRAGサービスを利用したが、精度が不十分

特に深刻なのは、「実証実験段階では成功したが、本番運用で失敗する」ケースです。少ないファイル点数（数十〜数百件）では良好な回答精度を示したシステムが、本番環境の大量データ（数千〜数万件）では急激に精度が低下することがあります。

「充実度」という重要な指標： 精度だけでなく「充実度」も重要です。RAGデータベースの中から一部の情報だけを用いて部分的な回答をするのではなく、ユーザーの質問に関連する情報を網羅的に取得して回答を生成することで、より実用的で充実した回答が可能となります。

実用レベルの回答精度と充実度を実現するための手段として、内製化するのではなくRAGを専門に研究開発しているベンダーのサービスを利用することも有効です。

3. 明確な導入目的と適切な期待値の設定

新しい技術に対しては、"try first"の考え方は非常に重要です。生成AIにおいて、それは「法人版ChatGPT」（ChatGPTやClaudeなどのLLMのAPIを用いたサービス）の導入にあたるかもしれません。これらは汎用的なツールであり、様々な用途に試行錯誤しながら活用できます。

しかし、RAGにおいては「とりあえずRAGを導入したい」というアプローチは推奨されません。RAGは特定の課題を解決するための専門的なシステムであり、以下のような明確な導入目的が必要です：

具体的な導入目的の例：

• 「技術サポートの問い合わせ対応時間を現在の4時間から30分以内に短縮したい」

• 「新入社員が業務知識を習得するまでの期間を3ヶ月から1ヶ月に短縮したい」

• 「属人化している専門知識を組織全体で活用できるようにしたい」

RAGと親和性の高い業務・部署：

• IT/情報システム部門：技術マニュアルやトラブルシューティング

• カスタマーサポート部門：FAQ対応や製品問い合わせ

• 人事・総務部門：社内規程や手続きに関する問い合わせ

• 法務・コンプライアンス部門：契約書テンプレートや法規制の確認

• 研究開発部門：技術文書や実験手順書の参照

4. 組織的な推進体制の構築

RAG導入は技術導入だけでなく、業務プロセスの変革を伴います。成功のためには適切な推進体制が不可欠です。

導入範囲に応じた体制：

• 部署単位の導入：部署長のコミットメントと部署内推進チーム（3-5名）

• 複数部署での導入：部門横断的な推進委員会

• 全社導入：経営層のコミットメントと専任プロジェクトチーム

必要な役割と責任：

• プロジェクトオーナー：導入の意思決定と予算承認

• データ整備担当：文書の収集、整理、品質管理

• 運用管理者：日常的な運用とユーザーサポート

• 効果測定担当：KPIモニタリングと改善提案

5. セキュリティとコンプライアンス要件の明確化

企業データを扱うRAGでは、セキュリティとコンプライアンスの検討が不可欠です。

データ分類と取り扱い方針：

• 公開情報：製品カタログ、プレスリリースなど

• 社内限定情報：業務マニュアル、社内規程など

• 機密情報：経営情報、個人情報、技術機密など

導入形態の選択基準：

• SaaS型：迅速な導入と運用負荷軽減を優先する場合

• セルフホスト型：データを外部に出せない、厳格なセキュリティ要件がある場合

アクセス制御の設計：

• 部門・役職に応じた情報アクセス権限

• 監査ログの取得と定期的なレビュー

• 情報漏洩対策とインシデント対応手順

6. 継続的な運用・改善プロセスの確立

RAGの特性上、継続的な運用・改善が成功の鍵となります。RAGでは、RAGデータベースにある情報のみを回答情報源とするため、以下の課題に対処する必要があります：

網羅性の課題： RAGデータベースの網羅性が低いと、ユーザーが質問しても「該当する情報が見つかりません」という回答ばかりになってしまいます。

情報の鮮度の課題： RAGデータベースの情報が更新されずに古い情報が残っていると、誤った古い情報を回答し続けてしまいます。

AskDonaの運用支援機能：

• RAGデータ不足分析機能：ユーザーの質問に対してRAGデータベースに情報がない場合を自動で特定し、どのような情報を追加すべきかを提案

• 利用ログ分析：よく聞かれる質問や回答精度の低い領域を可視化

• 定期レビュー支援：月次・四半期での改善ポイントを自動レポート

7. 予算の確保と投資対効果の試算

RAG導入には初期投資と運用コストが必要ですが、適切に導入すれば高い投資対効果が期待できます。

コスト項目：

• システム利用料（SaaS型）またはライセンス費用

• データ整備にかかる人件費（初期および継続）

• 教育・トレーニング費用

• インフラコスト（セルフホスト型の場合）

投資対効果の考え方：

• 理研の事例：問い合わせ対応時間を4時間から5秒に短縮

• 人件費削減効果：専門家の対応時間削減

• 機会損失の防止：迅速な問題解決による稼働率向上

• ナレッジの資産化：属人的知識の組織資産化

段階的投資のアプローチ： 特定部署でのPoCから始めることで、初期投資を抑えながら効果を検証し、成功を確認してから投資を拡大することが可能です。

導入準備のサポート

これらの準備事項を整えることで、企業はRAGを効果的に活用し、理研の事例のような劇的な業務効率化を実現することが可能になります。

推奨されるアプローチは、まずRAGと親和性の高い業務を持つ特定部署でPoCを実施し、効果を確認してから段階的に導入範囲を拡大していくことです。この方法により、リスクを最小化しながら、確実な成果を積み重ねていくことができます。

なお、弊社ではAskDona導入をご検討いただく際に、これらの準備事項について無料でコンサルティングを実施しております。お客様の現状を詳しくヒアリングした上で、最適な導入計画の策定から、データ整備のアドバイスまで、専門チームがサポートいたします。

企業のRAG導入方法のメリットデメリット

企業がRAGを導入する場合、大きく分けてRAGサービスを利用するか、外部に構築を依頼するか、自社で内製するかの選択肢があります。さらにRAGサービスには、クラウド型（SaaS）と自社環境で運用するセルフホスト型があり、それぞれに明確なメリット・デメリットがあります。AskDonaでは「SaaS型」に加え「セルフホスト型」の提供を予定しています。

1. RAGサービスを利用する

1-1. クラウド型（SaaS型）

メリット

• 即座に利用開始可能: 契約後すぐに使い始められ、価値を早期に実感できる

• 初期投資が少ない: 月額料金制が多く、大規模な初期投資が不要

• 継続的なアップデート: サービス提供者が機能改善や最新技術への対応を行う

• 運用負荷が最小: インフラ管理、セキュリティ対策、障害対応はサービス側が担当

• 専門知識不要: AI技術者がいなくても高度なRAGシステムを利用可能

デメリット

• データセキュリティの懸念: 機密情報を外部サービスに預ける必要がある

• カスタマイズの制限: 自社固有の要件への細かな対応が困難な場合がある

• 長期的にはコスト高: 利用規模が大きくなると、累積コストが内製を上回る可能性

こんな企業に最適: 中小企業、迅速な導入を優先する企業、セキュリティ要件が標準的な企業

1-2. セルフホスト型

当社のAskDonaでは、データを外部に持ち出すことができない企業や組織のために「セルフホスト型」の提供を予定しています。自社で契約しているAWSやAzure、GCPなどのクラウドサービスでAskDonaを利用できます。

メリット

• データの完全管理: 機密データが自社環境から出ることがない

• SaaSの利便性を維持: 製品としての完成度の高さ、継続的なアップデートの恩恵を受けられる

• コンプライアンス対応: 金融、医療、政府機関など厳格なセキュリティ要件にも対応可能

• 迅速な導入: 受託開発と比べて短期間で利用開始可能

デメリット

• インフラコスト: 自社でインフラを用意・管理する必要がある

• 一定の技術力が必要: 基本的なクラウド/サーバー管理の知識は必要

• SaaS型よりは初期負荷: 環境構築の手間がかかる

こんな企業に最適: 大企業、金融機関、官公庁、機密性の高いデータを扱う研究機関

2. RAG構築を外部に依頼する（受託開発型）

メリット

• 完全カスタマイズ可能: 自社の業務フローに完全に合わせた設計が可能

• 既存システムとの密連携: レガシーシステムとの複雑な連携も実現可能

• 知的財産の確保: 開発されたシステムは自社の資産となる

デメリット

• 高額な初期費用: 開発費用は数百万円〜数千万円になることも

• 長い開発期間: 要件定義から本番稼働まで6ヶ月〜1年以上かかることが多い

• 運用保守の負担: 完成後の運用、障害対応、アップデートは自社責任

• 開発リスク: 要件の認識齟齬や技術的な困難により、期待した成果が得られないリスク

こんな企業に最適: 特殊な要件がある企業、既存システムとの密な連携が必須の企業

3. 自社で内製する

メリット

• 完全なコントロール: 技術選定から実装まで全て自社でコントロール可能

• 技術力の蓄積: 組織内にAI/RAGの知見が蓄積される

• 柔軟な改善: 必要に応じて即座に修正・改善が可能

デメリット

• 高度な技術力が必要: AI/ML、自然言語処理、インフラの専門知識が不可欠

• 人材確保の困難: 優秀なAIエンジニアの採用・定着は極めて困難（年収2000万円超も珍しくない）

• 試行錯誤のコスト: 最適なアーキテクチャに到達するまでの時間とコスト

• 技術の陳腐化リスク: RAG技術の急速な進化に自力で追従する必要

こんな企業に最適: IT企業、研究開発型企業、すでに豊富なAI人材を抱える企業

選択の指針

セキュリティを重視する企業には、当社のセルフホスト型AskDonaのように「製品の完成度」と「データの自社管理」を両立できる選択肢が最適です。まずはSaaS型でPoCを実施し、効果を確認してからセルフホスト型に移行するという段階的アプローチも可能です。

重要なのは、RAG導入の目的、セキュリティ要件、予算、技術力を総合的に評価し、自社に最適な方法を選択することです。

どんな活用ができるの？

RAGの活用方法は基本的なものから応用まで幅広く存在します。ここでは、実際の導入事例を交えながら、具体的な活用シーンを紹介します。

基本的な活用：繰り返される問い合わせへの対応

どんな企業や組織でも、日々様々な問い合わせが発生します：

• 社内からの問い合わせ（人事・総務・IT関連など）

• 顧客からのカスタマーサポートへの問い合わせ

• 技術的な質問や操作方法の確認

従来のチャットボットとRAGの決定的な違い

従来のシナリオ型チャットボットは、事前に条件分岐を設定する必要があり、以下のような課題がありました：

• 管理者側：複雑な条件分岐の設計・更新が煩雑

• ユーザー側：自分の状況に合うシナリオがないと行き詰まる

• 結果的に両者にとって不満が残りやすい

RAGでは：

• ユーザーの課題を解決するという「ミッション（指示）」をAIに与える

• 事前に予測できない問い合わせにも、RAGデータベースの情報を基に柔軟に対応

• 管理者はRAGデータベースの充実に集中すればよい

• ユーザーは自然な言葉で質問し、即座に回答を得られる

実例：理研「富岳」サポートサイトでの活用

スーパーコンピュータ「富岳」のサポートサイトに導入されたAskDonaでは、高度な問い合わせ対応を実現しています：

インテリジェントな振り分け機能：

• ユーザーが「人による対応を希望」するニュアンスを検知

• 特定のキーワード検出ではなく、文脈から意図を理解

• 必要に応じて専門家への問い合わせチケット発行リンクを生成

シームレスな引き継ぎ：

• AskDona経由で作成されたチケットには、チャット履歴が自動的に紐付け

• 担当者は、ユーザーがどのような質問をし、どんな回答を得たかを把握した上で対応

• 結果として、より的確で効率的なサポートが可能に

応用的な活用：正確性と充実度を活かした高度な業務支援

RAGの回答が正確で充実していることを前提に、より高度な活用が可能になります。

バッチ処理による大規模な情報処理

RAGデータベースの規模が大きくても正確で充実した回答ができる場合、事前に用意された質問に対して一括で回答させることができます。

活用例：

• コンプライアンスチェック：数百項目の規制要件を一括確認

• システム脆弱性評価：セキュリティチェックリストに基づく網羅的な評価

• 品質管理：製品仕様や品質基準に関する大量の確認事項を自動処理

バッチ処理のメリット：

1. 結果の標準化：属人的な判断のばらつきを排除

2. 潜在的な課題の発見：明文化されていない項目や、RAGデータベースに存在しない情報の炙り出し

3. 大幅な工数削減：人が数日かかる作業を数時間で完了

4. 監査証跡の自動生成：すべての判断根拠が記録される

Deep Research機能への応用

高精度なRAGシステムは、単純な質問応答を超えた深い調査・分析作業にも活用できます：

• 複数の文書を横断的に分析し、関連性を発見

• 時系列での変化や傾向を把握

• 矛盾する情報の検出と整合性の確認

• 複雑な因果関係の解明支援

これらの活用により、理研の事例のような「4時間→5秒」という劇的な業務効率化が、様々な部門で実現可能になります。重要なのは、まず基本的な問い合わせ対応から始め、徐々に応用的な活用へと発展させていくことです。

RAGの今後

→RAGそのものはチャット形式で必要になるでしょう。しかし、優れたRAGシステムを応用することで、特定のワークフローの劇的な改善が見込めます。

出典

[1] Brown, T., Mann, B., Ryder, N., et al. (2020). "Language Models are Few-Shot Learners." arXiv:2005.14165. https://arxiv.org/abs/2005.14165

[2] Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv preprint arXiv:2307.03172. https://arxiv.org/abs/2307.03172