サイバー攻撃の対策

内部不正の防止

システムやデータの保護

業務プロセスの改善

社内情報の共有

テレワークの導入

データ分析の実現

人材の育成

採用の効率化

採用管理システム

人事評価の適正化

情報の可視化

ペーパーレス化の実現

総務・経理業務の最適化

IT資産管理の最適化

営業プロセスの改善

見込み客（リード）の
獲得・育成

「社内情報をAIに食わせればいい」だけでは足りない、情報検索精度向上の鉄則

「RAGを導入すれば業務が変わる」。そう信じて始めたのに、検索精度は上がらず、複雑な権限制御にも阻まれる――。Skyもまた、その壁にぶつかった一社だ。だが同社は「取りあえずRAG」を捨てることで前に進んだ。何でもベクトル化するのをやめたSkyの判断とは。

公開 2026年08月17日 08時00分

著者

吉村哲樹

[キーマンズネット]

印刷する連載新着通知を受け取る

　社内に散らばる情報を生成AIで検索できるようにしたい。そう考えたとき、まず思い浮かぶのが「RAG」（検索拡張生成）だろう。社内文書をベクトル化して検索し、その結果を基に生成AIが回答する。仕組みだけを見れば、これで従業員が必要な情報をすぐに探せるようになる。

　ところが、実際の社内データはそれほど単純ではない。情報の保存先が複数に分かれているだけでなく、部署や役職によって閲覧できる範囲も異なる。大量のデータを、意味の近い文章を探せる「ベクトルストア」に取り込んだとしても、検索精度やデータ同期、アクセス権限といった新たな課題が持ち上がる。

　社内ブログと社内FAQを横断検索するRAGの構築に取り組んだSkyも、同じ問題に直面した。全従業員が閲覧できる社内ブログでは狙い通りに機能した仕組みが、社内FAQに適用しようとした途端に行き詰まったという。問題は生成AIの回答精度でも、ベクトル検索の性能でもなかった。RAGに取り組むSkyがぶつかった壁とは何だったのか。

検索精度ではなかった「取りあえずRAG」を止めた本当の壁

　Skyは、「SKYSEA Client View」や「SKYPCE」などの自社パッケージ製品の開発・販売に加え、システム開発やSI事業なども展開するソフトウェア企業だ。

　同社はAI活用を推進しており、その取り組みを担う組織の一つが「AI Innovation Lab」だ。同組織で課長代理を務める神崎真行氏は、企業におけるデータとAIの関係性について次のように語った。

Skyの神崎真行氏

　「AIによって創出される価値は、入力されるデータの質に大きく依存します。そして、企業が自社固有の業務データをいかにAIに連携・活用できるかが、競争力や価値の源泉となります。どんなに優れたAIモデルであっても、質の高いインプットがなければ質の高いアウトプットは得られません」

　自社固有の業務データを生成AIに参照させる手段として、多くの企業が検討するのがRAGだ。しかし、RAGを導入しても「検索精度が上がらない」「複雑なアクセス権限を実装できない」といった課題に直面することがある。

　Skyも当初は「AIが使いやすいデータとは何か」「取りあえずRAGを組めばよいのか」と手探りの状態だった。そこから試行錯誤を重ねる中で、特定の実装方法に依存した「取りあえずRAG」の限界が見えてきたという。

社内ブログでは成功、それでも同じ方法をFAQに使えなかった理由

　1つ目の事例として、AI Innovation Labサブチーフの西村太陽氏が紹介したのが「社内情報検索エージェント」だ。

Skyの西村太陽氏

　Skyでは、社内の手続きや規約に関する情報が「社内ブログ」と「社内FAQ」という2つのシステムに分かれていた。従業員が情報を探すには、それぞれのシステムにアクセスし、個別に検索しなければならなかった。そこで西村氏らは、生成AIを使って両方の情報を一元的に検索できる仕組みの開発に着手した。当初考えたのは、全てのデータをベクトルストアに集約してセマンティック検索（意味検索）を実装する方法だった。

　「社内ブログと社内FAQの全てのデータをベクトルストアに集約し、セマンティック検索を実装すれば解決できるのではないかと考えました。ベクトルストアを用いたセマンティック検索は、現在RAGの実装方法として広く用いられていることから、まずはこの『取りあえずRAG』の発想で開発をスタートさせました」（西村氏）

　まず、従業員が閲覧できる社内ブログの検索に「Amazon OpenSearch Service」を採用した。埋め込みモデルには「Amazon Titan Text Embeddings V2」を使い、記事の内容をベクトル化。「投稿日時」「従業員ID」「記事カテゴリー」などのメタデータを条件に指定した検索も可能にした。さらには「Amazon S3 Vectors」の活用による最大90％のコスト削減も可能になったという。

Amazon Titan Text Embeddings V2で記事の内容をベクトル化（講演動画から抜粋）

　このように社内ブログでは、ベクトル検索を使った方法で一定の成果を得られた。問題が表面化したのは、同じ方法を社内FAQにも適用しようとしたときだった。

複雑な閲覧権限をベクトルストアに“移植”するべきか

　社内FAQには、「会社」「部署」「チーム」「役職」といった複数の属性を組み合わせた閲覧権限が設定されていた。だが、単純なドキュメントレベルセキュリティの機能だけでは権限の条件判定を表現しきれなかったのだ。

　そこで同社は、全てのデータをベクトルストアに取り込む方針を見直し、「Agentic Search」と呼ぶ方法に移行した。

　「ベクトル化はあくまでも、検索手段の1つに過ぎません。ベクトル化による意味検索を行う従来型のRAGは、ユーザーの質問をそのまま1回だけ検索にかけますが、エージェントによる意味検索を行うAgentic Searchは質問の意図を自ら理解して適切なキーワードを生成し、もし1回で見つからなければ反復検索します」（西村氏）

　この仕組みを実装するため、同社は「Strands Agents」を活用したアーキテクチャを採用した。「Amazon Elastic Kubernetes Service」（Amazon EKS）上のPodでエージェントを稼働させ、ブログデータには従来通りOpenSearchによるベクトル検索を使う。一方、社内FAQは、エージェントが既存システムのAPIを呼び出して検索する構成にした。

「Strands Agents」を活用したアーキテクチャ概要図（講演動画から抜粋）

　この方法であれば、FAQシステムに既に実装されている権限制御をそのまま利用できる。データをベクトルストアに取り込んで同期したり、同じ権限制御を別のシステムに実装したりする必要もない。

AIにSQLを書かせたい、しかし見せてはいけない日報もある

　2つ目の事例が「日報分析エージェント」だ。

　Skyでは、4000人を超える従業員が毎日、フリーテキスト形式で日報を作成している。日報には部署や役職に応じた閲覧権限が設定されており、誰でも全従業員の記録を見られるわけではない。同社が目指したのは、この日報データをAIに分析させ、「今週チームで問題になっていることは何か」「先月の特定の従業員の主な業務内容は何か」といった質問に回答できる仕組みだった。

　同社は日報データをAWSのデータウェアハウス（DWH）サービス「Amazon Redshift」に集約し、「NL2SQL」（自然言語からSQLへの変換）を使ってAIエージェントがデータを検索する仕組みを構築した。ユーザーの自然言語による質問をAIが自らSQL文に変換し、DWHに対してクエリを実行するため、部署や担当プロジェクトといったDWH上の他のデータと掛け合わせた柔軟で横断的な分析が可能となった。

　ただし、AIに自由にSQLを生成させると、別の問題が生まれる。アクセス制御を、生成されたSQLやアプリケーション側のチェックだけに委ねれば、プロンプトインジェクションなどによって、本来は閲覧できない日報が取得される恐れがある。また、データベースのユーザーレベルでの制御ではきめ細かな権限設定は不可能なため、AIに柔軟な分析を任せながら、見せてはいけないデータをどう守るかが課題になった。

プロンプトではなく「AIが触れない場所」でデータを守る

　この課題に対し、西村氏らが採用したのが、Amazon Redshiftの「RLS」（Row Level Security：行レベルセキュリティ）」だった。RLSは、データベースが返すレコードをユーザーやロールなどに応じて制限する機能だ。AIエージェントがどのようなSQLを生成しても、データベース側で閲覧権限のないレコードを除外できる。

　「具体的には、データベースが備えるRLSの機能を用いて、ユーザーが閲覧権限を持つ日報のレコードのみにアクセスを制限する仕組みを実装しました。これによってAIエージェントに対して自由にSQLを記述させる柔軟性を確保しつつ、同時に安全性も両立させることができました」（西村氏）

　AIに「この情報は表示しないで」と指示するだけではなく、AIから切り離されたデータベースのレイヤーでアクセスを制御する。これによって、AIエージェントによる柔軟なデータ分析と、行単位の権限制御を組み合わせた。

AIから切り離されたデータベースのレイヤーでアクセスを制御する（講演動画から抜粋）

RAGはベクトルストアの同義語ではない

　2つの事例に共通するのは、ベクトル検索を唯一の手段とせず、扱うデータの性質に応じて検索方法を選んだ点だ。

　社内ブログにはベクトル検索、複雑な権限を持つFAQには既存API、構造化した日報データにはNL2SQLを利用した。AIエージェントは、これらの手段をツールとして使い分ける。

　「RAGは決してベクトルストアと同義ではなく、課題の性質に応じてAPI呼び出しやNL2SQLを使い分けるべきだという学びが得られました。『取りあえずRAG』という安易な手段に飛びつかないことが重要です。具体的には、他の方法で精度が出ない場合や、権限設定がシンプルな場合に、ベクトルストアへの取り込みを検討すべきだと思います」（西村氏）

　社内情報検索エージェントによって、従業員は複数のサイトを個別に検索する代わりに、AIエージェントを通じて横断的に情報を探せるようになった。

事例から得られた学び（講演動画から抜粋）

　西村氏は、4000人の従業員が1人当たり1日5分の検索時間を節約できると仮定した場合、その効果は年間500人月以上に相当すると試算した。これは実測値ではないが、1回当たりの短縮時間がわずかでも、全社規模では大きな削減量になることを示している。日報分析エージェントも、日々の業務記録を基にした週次・月次サマリーの生成、チームが抱える課題の早期発見、目標と結果の叩き台作成、1on1ミーティングに向けた事前準備などに活用できるという。

　「これからのデータ活用は、単に情報を『見つける』フェーズから、より高度な『分析・理解』のフェーズへと向かっています。今回紹介した弊社の『取りあえずRAG』の先を見据えた考え方は、弊社だけでなくあらゆる企業にとって、データ活用をより一層加速させるために有用なノウハウになるのではないかと考えています」（神崎氏）

本稿は、「AWS Summit Japan 2026」（2026年6月25～26日）におけるSkyの神崎氏の講演「DX担当者が登壇！『とりあえず RAG 』の先へ－Data & AI の実践知－」を基に編集部で再編集したものだ。

印刷する