検索拡張生成（RAG：Retrieval Augmented Generation）

「検索拡張生成（RAG：Retrieval Augmented Generation）」

データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回は、現在大変に注目されている生成AIの実務での活用について考えてみましょう。

検索拡張生成（RAG：Retrieval Augmented Generation）とは

検索拡張生成（RAG：Retrieval Augmented Generation）とは、ChatGPTなどの生成AIの活用手法であり、生成AIの利用時に外部情報源を検索して得られた情報をあわせて利用することで応答を改善する取り組みのことです。
ChatGPTなどの生成AIは大規模言語モデル（LLM）をベースにして実現されていますが、LLMは通常、一般的なデータを用いてトレーニングがなされているため一般的な知識しか持っていない傾向があります。RAGは、外部情報源から検索した情報を補うことで、LLM自体が学習していない話題（自社に関する情報など）に対しても、より適切な応答をさせる手法として期待されています。

生成AIの活用はどうして今一つ進まないのか

現在、生成AIが世間的にも大変な注目を浴びています。ビジネスにおける生成AIの活用にも注目が集まっていますが、十分な成果が上がっている話は多くはないように思います。

例えばChatGPT、試しに使ってみた印象は強烈で、これを使えば何かできるのではないか？と思えたりします。さらには、他社がビジネスでの利用に取り組んでいる話を耳にしたりすると、活用せねばという気持ちに一層なってきます。

しかしながら、「文書要約」や「アイディア出しの補助」など補助的な用途では活用されていることはあるものの、その程度にとどまっていることが多く、試しに使ってみたときに受けた強烈な印象に比べてビジネスでの活用は今一つ進んでいないのが現状ではないかと思います。

どうして今一つ活躍できていないのか

どうして活用が今一つ進んでいないのでしょうか。まず、正しくないことを平気で言ってしまうハルシネーションの問題が広く知られており、正確性や結果責任が求められるような用途では使いづらい問題があります。そしてそれ以外に「自社に関連する質問をしても、一般的論な回答しかできないことが多い」など応答できることに制限があることも制約となっています。

つまり、生成AIに答えてもらいたいことや、ビジネスで利用したいと思ったことがあっても、回答を行うために必要な前提知識を「生成AIがそもそも知らない」ので活用が難しいことがあります。例えば、自社の社内規定を踏まえないとできない回答をChatGPTに求めてもうまく応答できません。

自社のビジネスで活躍させたいと考えたならば、当然に自社の事情を踏まえての回答が必要になってきますが、それができないわけです。

学習データに御社のデータは入っていない

どうしてそうなってしまうのかというと、ChatGPTを実現している大規模言語モデル（LLM）を作るときに使っている学習データが「世間で一般的に公開されているもの」だけだからです。

ですから、Webに載っているようなことや、辞書に載っているような一般的なことは学習していて答えてくれることが多いのですが、自社の社内規定などは学習データに入っていないので当然うまく答えられません。

ではどうすればよいか

そのような現実を踏まえて、生成AIはどのように活用すれば良いでしょうか。

まず、ChatGPTが知っていて処理できることを踏まえて、その制限において自分たちのビジネスで活用できることがないか考えてみることができます。それがまさに、「要約」や「アイディア出しの補助」などでのよく見られる活用です。

もう一つのアプローチは、何とかして「自社に関連したデータを生成AIに理解させて活用範囲を広げる」取り組みです。知識がないから無理ならば、知識を備えたものを用意すればいいはずです。

ChatGPTなどの生成AIは大規模言語モデル（LLM）をベースに実現されていますから、機械学習活用の通常のアプローチとしては、「自社独自のLLMを作成する」か、「ファインチューニングを用いて既存のLLMに追加学習を行う」ことでなんとかしたいところです。

機械学習の一般的事情については、こちらの記事も参照ください：
⇒ 機械学習｜用語集
⇒ ファインチューニング｜用語集

しかし残念ながら、（執筆時点では）独自のデータで学習させて自社専用のLLMを新たに作ることはあまりにも手間がかかるため現実的ではありません。それならば、既存のLLMをベースに、ファインチューニングにより自社独自のデータを追加学習させたいところですが、こちらの取り組みも（現時点では）技術的にうまく機能しないことが多いとされます。

つまり、自社独自のLLMを用意することは難しく「汎用のものをそのまま使わざるを得ない状況」が現状あります。そこで代わりに注目されているのが、「RAG」の活用による生成AIの活用範囲の拡大です。

RAG（Retrieval Augmented Generation）とは何か

RAG（ラグ）は「Retrieval Augmented Generation」を略した言葉です。日本語では「検索拡張生成」と訳されます。生成AI（LLM）自身には手を入れず汎用のものをそのまま使い、自社に関するデータを「利用時に外部から補う」ことで、「自社の事情や自社固有のデータなどを踏まえた回答をさせる」取り組みです。

利用者が質問文などを入力する。
[検索フェーズ] その質問文から、外部情報源（ChatGPTの外側にある社内文書など）を検索し、検索結果から生成AIに追加で与える情報を用意する。
[生成フェーズ] 利用者の質問文に加えて、検索結果から作った追加情報を併せてプロンプトとして与えることで、生成AIの応答を外部情報源の内容を踏まえたものに変える。

検索する

利用者が生成AIに対して入力したテキストから、その入力内容に関連した情報を外部情報源から検索して取得します。例えば「社内規程を踏まえると、（こういうケースの）出張費申請はどのようにすればよいですか」という質問であるなら、「社内規程」とか「出張費申請」といったキーワードなり話題で、社内文書を検索して関連文書を見つけ出すイメージです。

ではどのようにして、関連文書を見つけてくるのでしょうか。

RAGに関連して「ベクトル化」という言葉を聞くことがあるかもしれません。「ベクトル化」「ベクトルデータベース」のような生成AI関係で利用されることがある技術を使って、質問文と「意味が似ているテキストデータを検索する処理」が作りこまれていることがあります。詳しくは以下の記事をご覧ください。

⇒ ベクトル化 / エンベディング（Embedding）｜用語集
⇒ ベクトルデータベース（Vector database）｜用語集

RAGの説明で「ベクトル化」というすごい最新技術が使われているみたいな説明がされることがありますが、想像もつかないようなことが行われているわけではなく、基本としては「関連情報の検索」が行われる処理の本質です。

また、「意味が似ているものを探せる」とは言っても、人間が意味を理解するように理解しているわけではないこともあり、ベクトル化を用いた関連文書検索がうまく機能しないこともあります。そのために、RAGを導入したものの思った通りの成果がでないとか、実用的な回答精度が出せないことが問題になることもあります。

また、「社内に溜まっているドキュメンドやナレッジを検索して活用する」取り組みは最近になって始まったことではなく既存技術もあります。例えば「ナレッジマネジメント」の取り組みとして長年の実績がある「全文検索エンジン（エンタープライズサーチ）」を用いて関連文書を探してくることもできます。

自社にすでにそのような「情報活用システム」が導入済みで活躍しているのなら、そちらをRAGの基盤として活用することもできると思います。ポイントはベクトル化を利用することではなく、「必要な情報を検索して探すこと」だからです（あるいは各種技術をうまく併用することもできると思います）。

生成AIに入力できる形にする

検索して取得したデータを、利用している生成AIに入力できる形に加工します。ベクトル化したデータかもしれませんし、検索したドキュメントから抜き出したテキストデータかもしれません。あるいはその生成AIが、WordやExcelのファイルをそのまま理解できるのなら、見つけてきたそのままで良いかもしれません。

先ほどの例ならば、「交通費の社内規程」について全文検索エンジンで関連文書を検索し、社内のファイルサーバにあるWordドキュメントがヒットしたとするなら、そのWordファイルの内容を抜き出して、テキストデータにするなどの処理をします。

データベースに入っている正規化された表形式のデータ（DWHやRDBなど）が関連情報であった場合など、見つかったデータの形式が生成AIと相性が悪いこともあります。そのような場合には、うまく回答できるように工夫して前加工しなければいけないこともあります。

生成AIに関連情報を与えて回答させる

最後に、「利用者が入力したテキスト」に、「外部情報源を検索して取得した関連情報」も併せた入力を生成AIに与えて応答を生成させます。

技術的には、LLMを事前学習する代わりに、「利用時に追加学習させたかのような挙動変更」を実現できる「コンテキスト内学習（In-Context Learning）」を用いることで、生成AIの挙動を動的に変更していることになります。

⇒ コンテキスト内学習（ICL: In-Context Learning）｜用語集

RAGの性能を引き上げる方法は日々研究されており、もっと手順が工夫されていることもありますが、「基本的な実現手順」としてはここまでの説明の通りです。

RAGの実際の動作イメージを手動で試してみる

RAGのシステムを実際に開発するのは大変ですが、「手作業」で似たようなことをやってみましょう。

RAGなしで聞いてみると

その前にRAGなしでそのまま聞いてみましょう

日曜日に名古屋の実家で休暇を取っていて、名古屋から直接に大阪出張した際の交通費申請は社内規程上どういう処理をすべきでしょうか。

社内規程に関する具体的な内容は、企業によって異なりますが、一般的なケースを基に説明いたします。名古屋の実家から大阪への出張という状況での交通費申請については、以下のようなステップで対応することが考えられます。

1.社内規程の確認:
まず、社内の出張規定や交通費支給規程を確認してください。多くの企業では、出張の際の交通費は「通常勤務地から出張地までの交通費」を基準にしています。しかし、休日や休暇を利用して他の場所から直接出張に行く場合の取り扱いについても規定されていることがあります。
2.上司や人事部門への相談:
規程で明確でない場合や、特例として扱う必要がある場合は、上司や人事部門（経理部門の場合もあり）に相談してください。その際、名古屋の実家から大阪への直接移動の理由や、通常の勤務地（本社等）から大阪への交通費と比較したコストの違いなどを説明すると良いでしょう。
3.交通費の比較:
通常勤務地から出張地までの交通費と、実際にかかった交通費（この場合は名古屋から大阪）を比較します。多くの企業では、低い方の交通費を支給することが一般的ですが、企業によっては実際にかかった費用を全額支給する場合もあります。
4.申請書類の準備:
交通費申請に必要な書類（交通費申請書、領収書やチケットのコピーなど）を準備します。特別な事情がある場合は、その説明を添えることが重要です。
5.申請の提出:
必要な書類を揃えたら、規定の手続きに従って交通費の申請を行います。

重要なのは、事前に社内規程を確認し、必要に応じて上司や関連部門との相談を行うことです。また、交通費の申請にあたっては、正確な情報と必要な書類を準備することが求められます。

一般論で頑張って答えてくれていますが（これはこれでありがたいことですが）、しかし自社のルールで具体的に何をどうしたらいいのかはわかりません。しかし、ChatGPTは社内のルールについて知らないので、このようになってしまいがちです。

RAGで関連情報を与えるイメージ

では次に、「関連情報を与えて回答させる」とはどういうイメージなのか、まずは例を見てもらいましょう。なお、あくまでもイメージ例です。

以下の質問について、補助情報を参照して回答してください。また、補助情報を参照して回答しているときには、参照情報のどの部分を参照してどのような理由で回答したかも添えて回答してください。

質問：
日曜日に名古屋の実家で休暇を取っていて、名古屋から直接に大阪出張した際の交通費申請は社内規程上どういう処理をすべきでしょうか。

補助情報：
（社内規定文書の出張費のセクションの内容をテキストデータとして抜き出して貼り付けたもの）

この全体を利用者が入力するわけではありません。利用者が入力した部分は「太字の部分」だけ（先ほどと同内容）です。それ以外はRAGにより自動的に追加される部分です。

RAGでは質問文を元に検索を行って外部情報を参照するわけですが、上記だと「補助情報」の部分に関連情報を埋め込んだプロンプトを作ります。

実際に関連情報を入れて回答させてみる

では例として、以下のURLにある「東京都職員の場合の規程」を外部情報源として、プロンプト内にテキストデータとして張りつけたもので実際に聞いてみましょう。

⇒ 職員の旅費支給規程（東京都）

質問：
日曜日に名古屋の実家で休暇を取っていて、名古屋から直接に大阪出張した際の交通費申請は社内規程上どういう処理をすべきでしょうか。

補助情報：
東京都の規程をコピペして全文を張ったもの：長すぎるので割愛）

名古屋の実家で休暇を取っていた後、名古屋から直接大阪へ出張する場合の交通費申請に関しては、**「(電磁的記録及び電磁的方法)」と「(旅費の精算手続)」**の節を参照する必要があります。しかし、これらの節は具体的な出張の申請方法や、特定の出発地からの出張に関する直接的な情報を提供していません。したがって、一般的な手続きや規則に従って申請を行う必要があります。

さらに、別表第一と別表第二を参照することで、出張に関連する旅費の支給規定の詳細を確認できますが、これらの表も名古屋から大阪への直接出張に特化した情報は含まれていません。**「(路程の計算)」**の節によると、旅費の計算に必要な路程は、鉄道、水路、陸路の区分に従って計算されますが、名古屋から大阪への直接出張の場合、通常は鉄道または陸路（車）を利用することが考えられます。

したがって、名古屋の実家から直接大阪へ出張する場合の交通費申請については、以下の点を考慮することが重要です：

**「(旅費請求手続等の様式)」に従い、所定の様式で旅費請求を行う必要があります。これには、内国旅行の出張の場合に使用する「第四号様式(内国旅費請求内訳書兼領収書)」**が該当します。
**「(路程の計算)」**に基づいて、名古屋から大阪までの路程を計算し、それに基づいて旅費を算出します。鉄道または陸路を利用する場合の運賃や、必要に応じて急行料金や特別急行料金が適用されるかもしれません。

旅費の精算と申請は、職員が所属する組織の会計規則や内部規程に従って行われます。これには、出張の目的、日程、必要性などに関する情報が含まれます

この回答は、提供された補助情報を基にしていますが、具体的な申請手順や必要書類については、所属する組織の人事部門や会計部門に確認することが最も確実です。

回答としてはどうも今一つな感じはありますが（ここから「質問の仕方を工夫する」とか「追加質問をして回答を変えてもらう」などのプロンプトのテクニックで必要な回答を引き出してゆくことはできるでしょう）、特に工夫したわけでもないプロンプトでとりあえず動かしてみた程度のものでも、それなりに回答することはわかりました。

ともかくも、回答が一般論ではなくなっていることに注目してください。ChatGPTに「固有の事情を配慮した回答をさせる」ことに成功しているのです。外部情報源から追加で与えた「東京都での規程」をともかくも踏まえて質問に回答した形になっています。

どうでしょうか。このようにRAGを用いれば、汎用のChatGPTでも自社の事情を踏まえた回答をしてくれそうなことがわかります。

「RAGの沼」（RAGの現実）

このようなことから、生成AIを実務で活躍させる手段として、RAGに大きな期待が寄せられるようになりました。そのため、「自社にRAGを導入する」取り組みが多くの社で進められるようになっています。

しかしながらRAGを導入する取り組みは（執筆時点においては）、「期待した導入効果が得られず」に苦労することが少なくないのが現実です。導入がうまくできずに苦しい状況が続いてしまうことがあることから「RAGの沼」とさえ言われることがあります。では、具体的には、どういうことが起こりがちだと言われているのでしょうか？

RAGを導入してみたいと思う

自社でも生成AIの活用に取り組み始めたところで、「RAGというものがある」ことを知って「自分たちでもやってみよう」と思ったとします。自社のエンジニア有志が取り組みを進めることもあるでしょうし、外部のベンダに相談することもあるかもしれません。

十分に理解していないことを一気に進めると失敗しやすくなります。そこで、「スモールスタート」で取り組みを進めます。まずはRAGがどういうものなのか説明してもらい（コンテキスト内学習（In-Context Learning）という技術があることなど）、ここで交通費申請での例として載せたような簡単なデモを見て、動作の仕組みも理解します。

さらにはRAGが業務で使えそうか、社内で部署を限定してRAGを動作させて業務で使えそうか検証するPoC（Proof of Concept：概念実証）を行います。PoCでも期待をさせる動作をしたので、全社的に利用できるRAGシステムを導入することになりました。

あるいは、「軽率にRAGを導入しようとして失敗」している例が多いのではなく、このように「きちんと考えて手順を踏んでの導入」を行っても起こってしまう問題だということです。

「回答精度が低すぎる」として利用されない

社内でも少なからず期待をされながら、RAGを全社導入するためのシステム開発やデータの整備が行われますが、思いのほかシステム開発の工数と予算がかかってしまいます。

そしてとうとう動作するようになった自社のRAG。しかしながら、利用してみた業務の現場からは「これでは全く使い物にならないじゃないか」と厳しい評価がなされてしまい、導入したのに利用されない状態になってしまいます。

どうして利用してもらえないのか慌てて調べてみると、業務で利用しようとして質問をしてみても、「適切な回答をしないことが多すぎる」という評価がなされていることがわかります。そこで「回答精度」をきちんと調べてみたところ、質問に対して適切に回答できているのは、多めに見積もっても数割程度しかないことが解ってしまいます。

期待して導入されることが多いRAG、しかし「回答精度が出ない」ことが大問題になることがどうも多いようである。

「RAGの沼」

なぜRAGシステムは適切な回答ができないのか。調べてみると、適切な回答をするために必要な関連ドキュメントが読み込まれていないことが多いことが解ってきます。生成AI自体の問題ではなく、いわば「見当違いのドキュメントを検索してしまい、それを読み込ませて回答させようとしている」ため、回答に失敗していることが明らかになります。

回答精度を改善するためには、検索精度を改善しなければいけません。しかしベンダに聞いてみても、何かの不備を改善すれば一気に問題が解決するわけでもなく、あるいは体系的に何かに取り組めば実用的な精度を実現できる見込みがあるわけでもないことが解ってしまいます。

それでも精度を改善しなければ、せっかく導入したRAGが無駄になってしまいます。そこで、見通しも立たないまま「泥臭い小さい修正」を延々と続けることになってしまいました。少しずつは改善されているように思えるものの、依然として十分な精度は実現できず、「精度の出ないRAGへの終わりの見えない対策」に苦しみ続けることになってしまいます。

回答精度の改善はスムーズに行えないことが多く、「RAGの沼」と呼ばれるような大変な状況に陥ってしまうことがある

しかしそれでもRAGが必要

世の中で広く使われている技術の多くは、適切な整備を行って手順通りに導入を行えば、きちんと実用的に活用できるようになっているものです。所定の機能を発揮させるだけで、沼と比喩されるような苦労が必要になることがあるのは（執筆時点）、良いことではないはずです。

しかしながら、RAGなしでは生成AIの活用の広がりに限度があることもまた事実であり、生成AIの活用を進めるためには、「RAGの沼」が待ち受けていたとしても、それでもなお取り組まざるをえない事情もあります。

それ以外のRAGについての懸念点

「RAGの沼」以外にも考えておくべきことがあります。

既存の検索技術を利用する方が良いこともある

RAGは、「生成AIが回答を作っている」というよりは、「検索により答えを見つけている」ようなところがあります。精度が出ずに苦しむ原因も、生成AIそのものというよりは、ベクトルデータベースでの検索処理がうまく機能しないことが多いはずです。

ならば、「それ以外の既存の検索技術」を用いる方が良いこともあるはずです。さらにはRAGは手段であって目的ではありません。例えば、昔から利用されている「全文検索システム（エンタープライズサーチ）」を用いて利用者が自分で社内文書を検索し、ハルシネーションなどの可能性がある生成AIを通さず、利用者がまず自分で読んで判断する方が現実的に導入効果が高いこともあるかもしれません。

「検索して見つかるもの」から必要な回答できるとは限らない

検索は「質問文」から行います。つまり質問文を基にして、含まれるキーワードや意味などが似ている関連ドキュメントを検索し、探し出してくることになります。しかし「望まれる回答」に必要な関連情報が載っている資料が「質問文に類似性がある」とは限りません。

必要なのは質問文に似ている関連情報ではなく「素晴らしい回答文」です。そのような回答を生成するために必要な外部ドキュメントは質問文ではなく回答文に似ている（あるいはどちらにも類似しない）可能性があります。

例えば、「日本以外で、このような事業が適した国がありますか？」と尋ねた場合、必要なのは「日本に関連する資料」ではなく「むしろそれ以外の様々なこと」になります。創造的な回答が欲しい場合にも、質問文と似ている情報があれば良い応答を生み出せるとは限りません。RAGには過大な期待が寄せられていることもありますが、適するタスクと適さないタスクはあります。

「生成AIに全情報を入力する」方法もある

検索して関連する情報を絞り込まずに、「外部情報源を全部丸ごと」生成AIに入力すれば良いのではないか、RAGは要らないのでは？という意見もあります。

生成AIが一度に受け取れるデータ量はどんどん増加しており、本一冊分くらいのテキストデータなら問題なく読み込めるようになっています。検索の精度が上がらずに苦しんでいるのなら、検索せずに「社内の文書を全部読み込ませる」ようなことが、現実的にできるようになってきています。

ただし生成AI、読み込ませるデータ量に応じて課金されることが多いので、全部読ませると利用料金が多くかかります。また、必要な情報を絞り込んで与えた場合と、絞り込まずに全部与えた場合では、必要な情報のみに絞り込んだ方が回答の質が高いのではないか、と現時点（の研究論文など）では言われていることもあります。

また、RAGを「読み込ませたくない情報」を制御して除外できる点で優れていると考えることもできます。例えば、利用者の権限では参照出来てはいけない情報など除外することができます。つまりファインチューニングなどに比べて、回答するたびにその都度、利用するデータを制御して動作させることができる長所がある、と考えることもできます。

ハルシネーション対策になるのか？

RAGがハルシネーション対策の技術だと説明されていることがあります。緩和策になる場合はあると思われますが、問題を根本的になくすようなことを期待できる技術ではないはずです。

RAGは外部情報源からデータを流し込むだけであって、生成AIの動作そのものを変更するものではありません。外部情報源に答えるべき内容そのものがある場合にはそれが直接参照されて正確な回答をすることは多くなるかもしれませんが、存在しない話を積極的に創作してしまうこともあるハルシネーションの本質的挙動に介入して抑止しているわけではありません。

データ流出の抑止になる？

RAGではファインチューニング等に比べて情報流出を防ぐことができると言われていることがあります。しかし、クラウドサービスとして外部の生成AIを利用するなら、結局データの外部送信は行われます。

たしかにRAGでは自社の持つデータを生成AIの「学習」に用いることはなく、その過程で情報が外部に出ることはありません。しかし、利用時にプロンプトに含める形でデータは送信されますから、別の形での外部送信はなされることになります。

クラウドサービスが、利用時に入力された情報を生成AIの学習など他の用途に使いませんと表明しているからRAGは大丈夫だと考えるのなら、ファインチューニングで用いた学習データについて、他の用途に利用しないことが表明されていれば同じく大丈夫なはずです。

ただしファインチューニング等と違い、自社の持つデータ全体を外部送信せず、その都度、検索により見つかった一部分のみ送信するので、データの外部送信を局在化して小さくできていると考えることもできます。

実際に「RAGを活躍させる」ために必要なこと

RAGを活用するためにはもう一つ考慮が必要なことがあります、「検索対象のデータをどう用意するのか」です。データの検索により回答を生成しているわけですから、必要なデータが用意され、それが必要に応じて検索できる状態になっていなければ機能しません。

「検索できる」状態にするには社内のデータを整備する必要がある

例えば、企業でChatGPT活用にはRAG導入に効果があると聞いて、RAGができるシステムを調達しても、社内のデータ整備ができていなければ十分な効果は得られないでしょう。なぜなら外部情報源の検索がうまく出来ないからです。

自社の持つデータについて、どこに同様なデータがあるかを確認してデータの利用環境を整備することで「検索できる」状況を整備しなければいけません。さらには、検索結果から必要なデータを選び、適切に前処理して生成AIに渡せる必要もあります、そのためにはデータの質や形式についても整備が必要になることがあるはずです。

利用したいデータが電子化されずに紙のままになっていて電子化するところから作業しなければいけないこともあるでしょうし、古いデータと新しいデータが混ざって存在しているなら、新旧データが混ぜこぜに検索されて生成AIに投入されてしまうと、良い応答はできなくなるはずです。

つまりRAGを活躍させるためには、その前提として「社内のデータ利用環境を整備」する必要があります。

データを利用できる環境は、整備し続けなければいけない

外部ベンダに依頼をして、社内のデータ利用環境を整備したとしてもまだ問題があります。データ利用環境は継続的に整備をする必要があるためです。

例えば、社内で組織変更があって新部署ができたとか、新事業に取り組むことになった場合、従来なかったデータ（外部情報源）が発生することや、データ利活用（生成AIを用いて聞きたいこと）の新しいニーズができることがあります。

つまり、RAGを継続的に機能させるためには、組織やビジネスの状況変化にあわせて、新しいデータが新しいニーズによって検索できるように、社内のデータ利用環境を整備し続ける必要があります。そうしなければ例えば、新設された事業部門に関連するデータについて聞いても答えられないようなことが起こりえます。

RAGに必要なデータ環境の整備で役に立つ「つなぐ」技術

このようにRAGを継続的に機能させるためには、社内でデータの利用環境を整備して必要な情報を適切に検索できるようにし、検索結果を適切に前処理して生成AIで利用できる状況を継続的に維持する必要があります。業務での利用ニーズに合わせてRAGが良い結果を出せるようにするため、検索方法や前処理を工夫するなど、試行錯誤が必要になることもあります。

データの整備作業を行うたび、あるいは利活用での試行錯誤が必要になるたびに、外部ベンダに作業を依頼しないといけないなど毎回手間と時間がかかってしまうなら、RAGの活用がうまく進められなくなることも考えられます。

つまりRAGをうまく活用するためには、「社内のデータ利用環境整備」をスムーズかつ効率的に実現できる手段を用意する必要があります。

「つなぐ」技術を活用ください

このような、多種多様なシステムやクラウド上にあるデータに連携し、必要に応じでデータを読み取り、加工し、転送処理を行い、データ環境を整備する取り組みを、「GUIだけ」で効率的に開発できる手段が存在します。「EAI」や「ETL」、「iPaaS」と呼ばれる、「DataSpider」や「HULFT Square」などの「つなぐ」技術です。

GUIだけで利用できる

通常のプログラミングのようにコードを書く必要がありません。GUI上でアイコンを配置し設定をすることで、多種多様なシステムやデータ、クラウドサービスへの連携処理を実現できます。

「GUIで開発できる」ことは長所でもある

GUIだけでのノーコード開発は、本格的なプログラミングに対して簡易で妥協的な印象を受けるかもしれません。しかしながら、GUIだけで開発できることは「業務の現場の担当者が自分たち自身で主体的にクラウド連携に取り組む」ことを可能にします。ビジネスのことを一番良くわかっているのは現場の担当者です。

本格的処理を実装できる

「GUIだけで開発できる」ことを謳っている製品は沢山ありますが、そういう製品に簡易で悪い印象を持っている人もおられるかもしれません。

確かに、「簡単に作れるが簡易なことしかできない」「本格的処理を実行しようとしたら処理できずに落ちてしまった」「業務を支えられるだけの高い信頼性や安定稼働能力がなくて大変なことになってしまった」ようなことは起こりがちです。

「DataSpider」や「HULFT Square」は、簡単に使うこともできますが本格的プログラミングと同等のレベルの処理の作りこみもできます。内部的にJavaに変換されて実行されるなど本格的プログラミングと同様の高い処理能力があり、長年にわたって企業ITを支えてきた実績もあります。「GUIだけ」の良さと、本格的能力の両方を兼ね備えています。

iPaaSなので自社運用不要

DataSpiderなら自社管理下のシステムでしっかりと運用できます。クラウドサービス（iPaaS）のHULFT Squareなら、このような「つなぐ」技術そのもの自体もクラウドサービスとして自社運用不要で利用でき、自社での導入やシステム運用の手間がなく利用できます。

関係するキーワード（さらに理解するために）

機械学習に関連したキーワード

生成AI/ChatGPTに関係するキーワード

データ連携やシステム連携に関係するキーワード

EAI
- システム間をデータ連携して「つなぐ」考え方で、様々なデータやシステムを自在につなぐ手段です。IT利活用をうまく進める考え方として、クラウド時代になるずっと前から、活躍してきた考え方です。
ETL
- 昨今盛んに取り組まれているデータ活用の取り組みでは、データの分析作業そのものではなく、オンプレミスからクラウドまで、あちこちに散在するデータを集めてくる作業や前処理が実作業の大半を占めます。そのような処理を効率的に実現する手段です。
MFT（Managed File Transfer）
- ファイルによる連携処理を、企業活動を支えられるだけの高度な水準の「安全安心確実さ」で実現する連携基盤です。単にファイルの転送処理ができるだけではなく、転送処理が間違いなく確実に行われることや、セキュアで安全な転送、転送ログをきちんと残して確認や管理ができる機能などが揃えられているファイル転送やそれを実現する基盤のことをそう呼びます。
iPaaS
- 様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのことをiPaaSと呼びます。

「iPaaS」や「つなぐ」技術に興味がありますか？

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用をうまく成功させる製品を実際に試してみてください。

「つなぐ」ツールの決定版、データ連携ソフトウェア「DataSpider<」および、データ連携プラットフォーム「HULFT Square」

当社で開発販売しているデータ連携ツール「DataSpider」は長年の実績がある「つなぐ」ツールです。データ連携プラットフォーム「HULFT Square」はDataSpiderの技術を用いて開発された「つなぐ」クラウドサービスです。

通常のプログラミングのようにコードを書くこと無くGUIだけ（ノーコード）で開発できるので、自社のビジネスをよく理解している業務の現場が自ら活用に取り組めることも特徴です。

DataSpider / HULFT Squareの「つなぐ」技術を試してみてください：

簡易な連携ツールならば世の中に多くありますが、GUIだけで利用でき、プログラマではなくても十分に使える使いやすさをもちつつ、「高い開発生産性」「業務の基盤（プロフェッショナルユース）を担えるだけの本格的な性能」を備えています。

IT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。無料体験版や、無償で実際使ってみることができるハンズオンも定期開催しておりますので、ぜひ一度お試しいただけますと幸いです。

無料製品紹介セミナーはこちら

「HULFT Square」で貴社のビジネスが変えられるか「PoC」をしてみませんか：

貴社のビジネスで「つなぐ」がどう活用できるのか、データ連携を用いた課題解決の実現可能性や得られる効果検証を行ってみませんか？

SaaSとのデータ連携を自動化したいが、その実現可能性を確認したい
データ利活用に向けて進めたいがシステム連携に課題がある
DXの実現に向けてデータ連携基盤の検討をしたい

PoCプログラム | HULFT Square