特集・集中企画

「企業の中のあらゆるナレッジはいずれAIで処理される」検索精度を最大1.8倍に高めた「GMO AI RAG」は無償のOSS版で「1社1RAG」を目指す

開発責任者にインタビュー、その先に見据えるのは「Webサービス全体のAI化」

柳谷智宣

2026年8月5日 10:30

「GMO AI RAG」製品紹介サイト

　GMOインターネットグループのGMOプライム・ストラテジー（株）は6月30日、法人向けRAG（検索拡張生成）ソフトウェア「GMO AI RAG」のEnterprise版の提供を開始した。社内のマニュアルや規定、議事録などをナレッジとして取り込み、AIが社内情報にもとづいた回答を返すソフトウェアで、2026年秋頃にはコア部分をオープンソース（OSS）として無償公開する予定だ。

　RAGは生成AIブームの初期から使われてきた技術で、企業向けの製品やサービスもすでに数多い。現在のRAG製品で重要になるのは、必要な情報をどれだけ正確に検索できるか、既存のシステムや利用環境にどこまで柔軟に組み込めるかだ。「GMO AI RAG」は、検索精度を既存の検索アルゴリズムと比べて最大約1.8倍に高める独自技術に加え、複数のLLMやストレージ、MCPとの連携に対応する。さらに、コア部分をOSSとして公開し、幅広い企業への普及を目指す点も大きな特徴だ。

　今回は、開発責任者を務める同社AI事業部執行役員兼部長の押尾孝浩氏に「GMO AI RAG」開発の経緯から技術の中身、今後の展望までを伺った。

GMOプライム・ストラテジー AI事業部執行役員兼部長の押尾孝浩氏

「企業の中のあらゆるナレッジは、いずれAIで処理される」

　GMOプライム・ストラテジーは2002年に設立。超高速CMS実行環境「KUSANAGI」の開発元として知られ、WordPressをはじめとするCMSサイトの構築・運用を請け負うマネージドサービスを事業の柱としている。東証スタンダード市場に上場しており、2025年12月末にGMOインターネットグループへ加わった。従業員数は25名と上場企業としては小規模だが、早くから社内業務をAIで自動化してきた少数精鋭の会社だ。オライリー・ジャパンの依頼を受けて技術書『詳解 WordPress』を自社メンバーが執筆するなど、WordPress界隈では知る人ぞ知る存在と言ってよい。

　今回話を聞いた押尾氏は2025年4月に入社。前職では上場企業でERP系プロダクトの製品責任者や技術責任者を務め、既存製品をAIで強化する取り組みを主導してきた人物だ。ChatGPTの登場を目の当たりにして「今後はAIが主流になる」と確信し、以来AIに軸足を置いてきたという。

　入社後まもなく着手したのが「GMO AI RAG」の前身となる企業向けRAGプラットフォーム「MAGATAMA Stack」の開発だ。実際の開発開始は2025年6月頃で、製品化までは約1年。GMOグループ入りを機に、わかりやすさを重視して現在の名称に改められた。WordPressの会社がなぜRAGなのか。押尾氏は開発の背景を次のように語った。

「企業の中のあらゆるナレッジは、いずれAIで処理されることになります。その際、RAGのような仕組みが必要になるので、それを格安でどこの企業にも使っていただけるプラットフォームという形に仕立てることが、今後必要になってくるだろうと考えて、開発を進めました」（押尾氏）

　背景には、生成AIの業務活用を阻む3つの障壁があると同社は見ている。機密情報の流出懸念、社内固有の情報に答えられないこと、そしてコストの不透明さだ。社内文書を外部のAIチャットサービスに送ることに抵抗のある企業は依然として多く、かといって汎用AIは自社の規定やマニュアルについて答えられない。従量課金では予算化も難しい。「GMO AI RAG」は、ローカル動作、RAG、そしてOSSと月額固定運用という組み合わせで、この3つに答えを出そうとしている。

SharePointのフォルダーがそのまま社内AIの知識になる「情報コレクション」

　RAGの仕組みを簡単におさらいしておこう。

　ChatGPTのような生成AIは、学習した範囲の知識でしか答えられず、社内規定や自社製品の仕様といった固有の情報には答えられない。RAGは、質問が来るたびに関連する社内文書を検索し、見つかった内容を根拠としてLLM（大規模言語モデル）に回答を生成させる仕組みだ。文書をAIの学習データにするわけではないので、モデルに機密情報が取り込まれてしまう心配もない。

　「GMO AI RAG」の設計で目を引くのが「情報コレクション」だ。

　いわばナレッジのまとまりの単位のことであり、営業部のA商品に関する文書で1つ、B商品で1つ、といった具合に、部門やテーマごとに区分けして管理できる。コレクションごとにアクセス権限を設定できるほか、使用するLLM、使いすぎを防ぐトークン上限、AIへの指示となるシステムプロンプトまで個別に設定できる。

　既存ストレージとの連携方法もユニークだ。競合製品の多くは文書をRAG側にアップロードする方式を取るが、「GMO AI RAG」はMicrosoft SharePointやGoogle ドライブ、Boxなどの所定フォルダーと「同期」することができる。日常業務でSharePoint上のファイルを追加・更新・削除すれば、その内容が自動でRAG側に反映されるわけだ。

　フォルダーとコレクションの対応も柔軟で、1つのフォルダーを1コレクションにするだけでなく、複数フォルダーを束ねたり、逆に1つのフォルダーを複数のコレクションに割り当てたりできる。普段使っているSharePointやファイルサーバーが、手間をかけずに社内AIの知識になるのだ。認証もMicrosoft Entra IDやGoogle ログインと統合されており、組織全体のアクセス制御を一元管理できる。

Google ドライブのフォルダーを情報コレクションに割り当てるマッピング画面

　回答を生成するLLMは、コレクション単位で自由に選べる。AnthropicやOpenAI、GoogleといったクラウドLLMから、Llama 4.xシリーズやgpt-oss 120bなどのオープンモデルをローカルで動かす構成まで対応する。取材時に見せてもらったデモはAWS上の評価環境で、回答生成にGoogleのオープンモデル「Gemma 4」、埋め込み処理にAmazonの「Titan」を使う構成だった。Gemma 4を選んだ理由として押尾氏は「安くて割と賢いから」と語った。

　重要なのは“どのLLMを選んでも検索で引っ張ってくる情報自体は変わらない”という点だ。変わるのは回答の表現力や要約のうまさで、高度な推論まで求めるならクラウドの上位モデルを、社内情報の検索と要約が中心ならローカルLLMを、と用途で使い分ければよい。

情報コレクションごとに回答生成用のLLMと埋め込みモデルを設定できる

　セキュリティを最優先にするなら、完全ローカルで固める選択もできる。実際のニーズは業種によって分かれるそうで、学生の論文を外部のLLMに送ること自体を避けたい学術機関からは完全ローカルでの構築を求める声がある一方、もともと情報を公開・販売している出版社系などはクラウドLLMの利用に抵抗がないという。

　また、ハルシネーションへの対策もばっちりだ。検索してきた文書の範囲内でのみ回答するよう制御されており、該当する情報がなければ「社内の情報にはありません」と返す。根拠となる情報がないまま回答を生成しない設計になっている。

　もうひとつ、時流を押さえているのがMCP（Model Context Protocol）サーバーの標準搭載だ。Microsoft CopilotやClaudeといった主要なAIチャット／AIエージェントから「GMO AI RAG」に蓄積した社内ナレッジを参照可能だ。社員がチャット画面で質問するだけでなく、AIエージェントが業務の中で社内情報を引きに来る使い方を、最初から想定した作りになっている。

3種類のインデックスとニューラルチャンキングで検索精度0.591を叩き出す

　押尾氏が取材を通して繰り返し強調したのが、RAGの品質を決めるのは「検索」だという点だ。

「RAGが使えるか使えないかを決めるのは、検索の部分なんです。質問に対して的確なものを、どれだけ高速に引っ張ってこられるか。そこで決まります。引っ張ってきた中に的確な情報がなければ『社内の情報にはありません』という回答になってしまいますから」（押尾氏）

　OSS版に搭載される標準のRAGエンジンは、文書を適切な大きさに分割（チャンキング）し、意味を数値化したベクトルに変換して、質問との類似度で検索する一般的な構成だ。これだけでも通常のRAGとして十分に機能する。その上で、検索精度を大きく引き上げる有償オプションとして用意したのが「チューンドRAG」だ。

　まず、文書の登録時に3種類の手法でインデックスを事前に生成しておく。検索は、類義語や言い換え表現を拾う検索、意味的に近い内容を探す検索、そして引っ張ってきた候補を質問の意図に合わせて並べ直すリランキングの組み合わせで動く。質問時には、候補を抽出し、質問との関連性を再スコアリングしてマッチ度の低いものを捨て、残った候補を並べ直して、最終的に選ばれた文書だけをLLMに渡して回答を生成させる三段構えだ。

　精度の土台になっているのがチャンキングだという。文書を細切れにする際、区切り方が悪いと意味の通らない断片が生まれ、それが検索品質を直撃する。よく使われるのは断片同士を1割ほど重ねて切るといった手法だが、同社は採用していない。

　押尾氏によると、ColBERTに代表されるニューラル系のアルゴリズムを応用し、段落の意味的な区切りを特定して、意味が通じるまとまりだけでチャンクを作っているそうだ。このおかげで、おかしな位置で切られた文章が検索に引っかかることがない。

「通常はPythonやTypeScriptで組むところを、うちはすべてネイティブコードで組んでいます。手間をかけた処理をしても、速度が落ちないようにするためです」（押尾氏）

　効果は数字に表れている。

　日本語RAGの検索精度を評価するデータセット「JQaRA」の全1,668問で測定したところ、検索精度を示すF1@10スコアは、Google検索に近い古典的な手法のBM25で0.332、日本語特化の埋め込みモデルRuriで0.374、両者を組み合わせても0.38台にとどまるのに対して、チューンドRAGは0.591を記録した。既存の検索アルゴリズム（0.332～0.417）と比べて約1.4～1.8倍の精度になる。F1スコアは、必要な文書を見逃さない度合い（再現率）と無関係な文書を拾わない度合い（適合率）のバランスを0～1で示す指標で、1に近いほど高精度だ。

「この精度は他社さんでもなかなか出せない数字であることは確かです」と押尾氏は胸を張った。

JQaRA全1668問におけるF1@10値の比較グラフ。従来モデルと比べて高スコアを出しているのがわかる

　インフラ面の作り込みも語ってくれた。ベクトルデータベースには「Qdrant」を採用し、クラスター構成で運用する。データは複数のノードに横串で分散格納（シャーディング）され、検索時は並列に取り出して組み立てるため、データ量が増えても速度が落ちにくい。RAIDのように、1台が故障してもデータを復元できる冗長性も確保しているという。

　クラウドの場合はAWS上にクラスターを組み、容量が逼迫すればノードを追加する。アクセスの増減があるフロント側はオートスケールで対応する。オンプレミスでも、後からマシンやディスクアレイを追加できるクラスター構成で提供するため、扱えるデータ量は実質的にストレージ次第ということだ。

無償のOSS版で「1社1RAG」を目指す

　冒頭で触れたとおり、「GMO AI RAG」はコア部分を2026年秋頃にOSSとして無償公開する予定だ。ライセンスにはAGPLを採用しており、有償オプションはAGPLのコア部分の外側に位置づけられている。

　OSS版でできることは想像以上に広い。RAGエンジン本体に加えて、ChatGPTライクな専用チャットアプリ（フロントエンド）、Windowsファイルサーバーとの連携、情報コレクション、シングルサインオン、マルチテナント、MCPサーバーまで含まれる。

　完全ローカル構成でローカルLLMを使えば、文書をベクトル化する埋め込み処理も含めて外部APIの利用料は一切かからない。クラウドLLMを使う場合も、費用が発生するのは文書登録時の埋め込み処理と回答生成で、検索自体には利用料がかからない。まずOSS版とファイルサーバーでスモールスタートし、必要になったらSharePoint連携やチューンドRAGといった有償オプションを買い足す段階的な導入も想定されているという。

　Enterprise版の参考価格（税別）はクラウドの場合、初期費用が環境構築40万円～と導入支援80万円～、年間費用が運用保守180万円～とサポート66万円～。オンプレミスの場合は初期費用が環境構築40万円～と導入支援160万円～、年間費用が保守60万円～とサポート72万円～となっている。チューンドRAGは初期費用120万円、保守が年額60万円。AWSやクラウドLLMの利用料といったインフラ費用は別途必要だ。

　中小企業が気軽に導入できる金額ではないが、押尾氏が想定する主なターゲットは従業員200～2000名規模の企業とのこと。サーバーの面倒からメンテナンスまで一切を任せられる運用込みの価格と考えれば、この規模感では現実的な線だろう。小規模な企業や、まず試したい企業には無償のOSS版という受け皿がある。

　用途は社内利用にとどまらない。他システム連携APIを使えば、業務システムやSaaSのRAGバックエンドとしても稼働する。インデクシング用のAPIも用意されており、SaaSベンダーが自社サービスの裏側で「GMO AI RAG」を呼び出せば、蓄積したデータを自然言語で検索できるセマンティック検索エンジンとして使える。同等の精度のRAGを自前で作るには相応の期間とコストがかかるため、そこを肩代わりする狙いだ。

　マルチテナント対応のため、複数顧客への同時提供やOEMもできる。WordPressサイトに組み込めるAIチャットボットプラグインもすでに用意されており、同社の製品紹介サイトに先行導入されている。自社サイトのFAQをナレッジ化して、サポート窓口の一次対応をAIに任せる使い方が手軽に実現できるだろう。

KUSANAGI公式サイトに組み込まれたAIチャットボットのテスト画面

　今後のロードマップとしては、SlackやGmailのデータをナレッジとして参照できる「リモートMCP」の年内提供が予定されている。情報コレクションにリモートMCPを割り当てる方式のため、コレクション単位のアクセス権制御はそのまま機能する。

　ローカルLLMを現実的な速度で動かすためのGPUサーバー対応は、2026年8月にNVIDIA製GPUで実機検証を行い、年内を見込む。GPUと直接やり取りできる推論基盤「vLLM」経由で実行する仕組みだ。また、小規模環境向けにAMD Ryzen 9000シリーズを搭載したPCでの実機検証も予定しており、高価なNVIDIA製GPUだけでなくAMD製GPUを現実解として視野に入れているのが実用的だ。現状の対応はテキストベースだが、文書内の画像を抜き出して回答に活用する機能も今年度中に実装する計画だという。そして、その先に押尾氏が見据えるのは、Webサービス全体のAI化だ。

「AWSにしてもCloudflareにしても、自身の管理ツールにはチャットボット的なものが入っています。画面の入力項目に何を入れるべきかを、右側のペインで教えてくれるのです。今後のSaaSはそういうスタイルになっていくはずなので、その仕組みそのものを我々でカバーしていきたい。Webの発展に貢献するようなAIの使い方が、この仕組みをベースにすればできるのではないかと考えています」（押尾氏）

　「GMO AI RAG」が目指すのは、単なる社内文書の検索ツールではない。企業が持つ情報をAIが利用できる基盤を整え、チャットだけでなく、AIエージェントや業務システム、Webサービスからも活用できるようにすることだ。その入り口をOSSとして広く開放する理由について、押尾氏はこう語る。

「目指しているのは、企業ごとに、その会社の業務や知識を理解したAIがある状態です。『1社1RAG』という形で広く導入されれば、業務効率は大きく高まります。まずは多くの企業に使っていただき、RAGを普及させることを優先したい。収益化する部分は、その先で考えていけばよいと思っています」（押尾氏）

　検索精度を高める独自技術は有償で提供しながら、基盤となるRAGはOSSとして開放する。自社製品の中に囲い込むのではなく、まず利用する企業や開発者を増やすという戦略だ。2026年秋に公開されるOSS版が導入のハードルをどこまで下げられるのか。「1社1RAG」の構想を確かめるためにも、公開後に実際の環境で試してみたいところだ。