「とりあえずRAG」をやめたSkyの判断――社内情報のAI活用で本当に問われる設計とは

目次

「RAGを入れれば解決する」という期待がなぜ裏切られるのか

社内のドキュメントをAIに読み込ませれば、業務効率が劇的に変わる――。そう期待してRAG(Retrieval-Augmented Generation:検索拡張生成)を導入した企業が、思ったほど検索精度が上がらないという壁にぶつかるケースが増えている。RAGとは、AIが回答を生成する前に社内文書などの外部情報を検索して参照させる仕組みで、いわば「自社データを読めるAI」を作るための定番アプローチだ。

問題は、「RAGを導入する」こと自体が目的化しやすい点にある。システムインテグレーターのSkyも、その落とし穴を経験した一社だ。同社が直面したのは、検索精度の低さと複雑な権限制御という二重の課題だった。そしてSkyが選んだのは、RAGを捨てることではなく、「何でもベクトル化する」設計思想を捨てることだった。この判断の中身を解きほぐすと、AI活用の本質的な設計論が見えてくる。

Skyが「何でもベクトル化」をやめた理由

RAGの一般的な実装では、社内文書をベクトル(数値の配列)に変換して検索可能な状態にする「ベクトル検索」が使われる。ベクトル検索は意味的な近さで文書を探せるため、キーワード完全一致に頼らなくていいという利点がある。しかし、あらゆる情報を一律にベクトル化する設計には限界がある。

Skyが直面したのは、社内情報の性質が一様ではないという現実だ。規程や手順書のように構造が明確な情報と、議事録や日報のように非構造的な情報では、検索に適したアプローチが根本的に異なる。それを同じ手法で処理しようとすれば、精度は必然的に落ちる。同社はこの点に向き合い、情報の種類に応じて検索手法を使い分ける設計に切り替えた。「とりあえずベクトル化」から「情報の性質を見てから設計する」への転換である。

加えて、権限制御の問題も見過ごせない。社内情報には、誰でも見ていい情報と、特定の部署や役職者だけが参照できる情報が混在する。RAGシステムがその境界を無視して検索結果を返してしまえば、機密情報の意図しない開示につながりかねない。Skyはこの権限管理の複雑さとも正面から向き合った。

対象はSkyだけでなく、AI活用を検討するすべての企業担当者

Skyの取り組みが示す教訓は、同社固有の話ではない。RAGを活用した社内情報検索システムの構築を検討している、あるいはすでに導入して効果に疑問を感じている企業の情報システム部門やDX推進担当者にとって、直接的に参照できる事例だ。

特に影響が大きいのは、複数部門の文書が混在する中規模以上の企業だ。情報の種類が多様になるほど、「一律にベクトル化して検索」という設計のひずみは大きくなる。また、人事情報や法務文書など権限管理が厳格に求められる業種――金融、医療、製造業の品質管理部門など――では、権限制御の設計が不十分なRAGシステムはリスク要因になりうる。

日本企業の社内文書環境でこの問題はより深刻になる

日本のビジネス環境に照らすと、この設計問題はさらに複雑な様相を帯びる。日本企業の社内文書は、PDFで固定されたフォーマットの文書、Excelで管理される台帳、メールやチャットツール上のやり取り、紙をスキャンしたものなど、形式が極めて多様だ。こうした異種混在の情報群を「とりあえず全部ベクトル化」する設計では、検索ノイズが増えるのは避けられない。

さらに、日本語特有の表記揺れ(漢字・ひらがな・カタカナの混在、送り仮名の違いなど)は、ベクトル検索の精度に影響を与える要因としてよく知られている。情報の性質と言語的特性の両方を考慮した設計が、日本語環境では特に求められる。Skyが実践した「情報の種類を見極めてから検索手法を選ぶ」というアプローチは、こうした日本語環境の課題に向き合う上でも参考になる視点を持っている。

「社内AI検索」の精度が上がらないとき、次の手をどう判断するか

RAGシステムを動かしてみたものの、検索精度が改善しない場合、どのタイミングでどの判断をすべきかは難しい。Skyの事例はひとつの方向性を示しているが、情報の整理・分類自体に工数とコストがかかることも事実だ。「情報の種類別に検索手法を変える」設計は理にかなっているが、社内情報の分類基準を誰がどう定義するかは、技術的な問題というより組織的な問題でもある。

また、権限制御の精度をどこまで高めるかについても、完全な制御を目指すとシステムの複雑性が増し、運用負荷が上がる。どこで折り合いをつけるかは、組織の規模やセキュリティポリシーによって異なる。Skyの判断がそのまま他社に適用できるわけではなく、自社の情報構造と照らし合わせた検証が必要だ。

NEWGATAが見るSkyの判断が持つ本当の意味

Skyの事例が際立つのは、「RAGを使う・使わない」という二項対立ではなく、「何をどの手法で扱うか」という設計の粒度を上げた点にある。これは、AI活用の議論が「ツールを導入するか」から「どう設計するか」という段階に移行していることを示す一例だ。

日本のビジネス現場では、AI導入を「ベンダーのソリューションを選ぶ」行為として捉えがちだ。しかしSkyが示したのは、社内情報の性質を先に理解し、それに合わせてシステムを設計するという、いわば「情報の棚卸しが先、技術選択は後」という順序だ。この順序を逆にすると、どれほど高度なAI技術を使っても精度は上がらない。RAGの限界に悩む企業が増える中で、Skyの「やめた判断」は、次の一手を考えるための実践的な判断軸になりうる。AI活用の成否を分けるのは技術の選択ではなく、自社の情報を正確に理解できているかどうかだ、という点を、この事例は静かに、しかし明確に示している。

本記事は公開情報をもとに、NEWGATA編集部で確認のうえ掲載しています。

参照元

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次