RAGだけでは解決できない！？社内情報共有の最新ソリューション

情報システム部門向け

社内文書をRAGでつないだ。検索は速くなり、根拠つきで答えが返るようになった。それなのに、同じ質問が何度も来る。同じ調査が、担当を変えて繰り返される。——RAGを導入した組織から、よく聞く話です。

原因は検索の精度ではありません。RAGが扱えるのは「誰かが書いた文書」だけで、現場で本当に効く知識の多くは、そもそも文書になっていないからです。本記事では、RAGの守備範囲と、その外側に残る空白を整理します。

RAGは「あの資料どこ？」を消した ― ここは本当に解決した

先に、RAGの成果を正しく置いておきます。社内規程・手順書・設計書が散らばっていた状態から、横断で検索でき、出典つきで答えが返るようになったのは大きな前進です。「あの資料どこでしたっけ」という問い合わせは確実に減ります。

ですから、この記事はRAGを否定するものではありません。RAGを入れた後に残る空白の話です。

それでも消えない4つの空白

書かれていない知識は、検索できない索引の外なぜその設計にしたか、どの案を捨てたか、どこで詰まったか。判断の理由と失敗の記録は、成果物の文書には残りません。索引に最初から存在しないので、どれだけ検索精度を上げても出てきません。

AIが調べたことが、次のAIに戻らない書き戻しが無いAIが1時間かけて突き止めた原因も、会話が終われば消えます。翌週、別の担当のAIが、同じ一次資料を最初から読み直す。RAGは読み取り専用なので、AIが得た知見を書き戻す先がありません。

「取りに行く」しかなく、「知らせる」経路がない宛先が無い検索されなければ届きません。しかし実務で滞るのは「誰かの返事待ち」「来月やると決めたこと」「渡したきり音沙汰がない成果物」です。これらは検索する対象ではなく、向こうから知らせてほしい情報です。

古い記述も、同じ顔で返ってくる鮮度3年前の手順書も、昨日の議事録も、検索結果としては同じ重みで並びます。誰がいつ直すのかが決まっていないと、間違った内容が「出典つき」で引用される——根拠が添えられるぶん、かえって疑われにくくなります。

なぜ空白が生まれるのか

RAGは読み取り専用の索引です。「人が書く → AIが読む」という一方向を前提に作られています。ところが実際の現場では、すでにAIが書き手になり、別のAIが読み手になる場面が増えています。そこに橋が架かっていない、というだけの話です。

図1：RAGが扱えるのは「人が書いた文書」まで。判断の理由・失敗・確認待ち・AIが得た知見は、そもそも書かれないため索引に入らない。

観点	RAG（検索の層）	足りていない層
情報の作り手	人が書いた文書	AIが作業の副産物として残す
向き	読むだけ（一方向）	読み書き（双方向）
届き方	検索された時だけ	次の会話で、向こうから戻る
鮮度	誰かが直すまでそのまま	訂正・統合の経路がある
粒度	一次資料をそのまま（毎回読み直す）	要約を1回作り、全員が使う

当社の運用で実際に起きたこと

抽象論になりやすいテーマなので、自社インフラの運用から3つ挙げます。いずれも、どの設計書にも書かれていない種類の知識です。

例1：ドライバの「提供元」が違うだけで、1時間後に通信が落ちる仮想化ホストのネットワークカードが、OS標準の汎用ドライバのまま動いていました。一見すると正常に見えるのに、1時間ほど経つとリンクが切れ、ホストと仮想マシンが同時に到達不能になる。メーカー提供のドライバに入れ替え、省電力機能を止めて解消しました。構成図にも手順書にも書きようがなく、次に同じ機種を触る人は、また同じ半日を使います。

例2：設定ファイルは「書けた」で終わらせないWebサーバの設定を変更したのに検証コマンドを打たず、そのまま放置しました。稼働中のプロセスは設定を読み直さないため異常は出ません。異変が表に出たのは、十数時間後の再起動のとき——公開サイトがまとめて停止しました。手順書には「編集する」としか書いていません。「編集したら必ず構文チェックを通す」は、事故の後にしか生まれない知識です。

例3：AIの指摘の約半分は、別のAIに否定された当社では、AIが書いたコードを別ベンダーのAIが相互検証する仕組みを動かしています。6回のレビューで挙がった指摘は約110件。そのうちおよそ半数は、検証側のAIが「コードを読めばそうなっていない」と否定しました。裏を返せば、1台のAIの出力をそのまま信じていたら、存在しない問題の対応に半分の時間を使っていたことになります。

例1と例2は「文書にならない知識」、例3は「AI同士のやり取りがあって初めて確定する知識」です。どちらもRAGの索引には最初から入っていません。

SmartOptimizerなら、一気に解決する

ここまで挙げた空白は、人がもっと書けば埋まる——そう考えると、まず埋まりません。ドキュメントを書く時間は、どの現場にも残っていないからです。SmartOptimizerの答えは逆です。書くのは、人ではなくAI。

SmartOptimizer の本質

1. RAGが扱えない情報を、AIが自動で生成する

判断の理由、詰まった箇所、確認待ち。整理から記録までAIがその場で行います。人が引き継ぎ資料を書く時間も、書き方を考える時間もゼロです。

2. その知識を、AI同士が検証して育てていく

別のAIが読み、参照し、間違いを指摘して訂正する。使われるほど要約は正確になり、重複は統合されていきます。

3. だから、人間は何もする必要がない

集める、書く、整理する、思い出す、催促する。情報共有のために人がやっていた仕事は、ひとつも残りません。

先ほどの図1で、索引に届かずに消えていた4つを思い出してください。SmartOptimizerは、その4つをAIの作業の副産物として書き込みます。書かれた瞬間に、それは検索できる情報になり、次のAIに戻り、待っている人へ届きます。

しかも、書き込む内容の整理までAIがやります。会話の中から「何が決まって、何が残ったのか」をAIが判定し、要点に圧縮し、重複はまとめ、宛先と期日をつけて残します。人が形式を整えることも、タグを付けることも、どこに書くかを考えることもありません。人は、いつもどおり業務を進めるだけです。

図2：図1の全体像に、SmartOptimizerが担う範囲（点線の内側）を重ねたもの。上段のRAGはそのまま、下段の行き止まりだった4つをAIが整理して書き込み、AI同士の会話で高め合う。

こうして、文書になるものはRAGが、文書にならないものはSmartOptimizerが引き受けます。片方だけでは埋まらなかった社内の情報共有が、2つ合わさることですき間なく埋まります。どちらかを捨てる必要はありません。RAGを入れた投資はそのまま活きます。

RAGが「すでにある文書を引く」仕組みだとすれば、SmartOptimizerは「まだ無い知識を作って、育てる」仕組みです。だから、RAGでは最後まで埋まらなかった空白が埋まります。

SmartOptimizerの最大の特徴は、AI同士が会話できることです。要約は「置いておく」だけでは劣化します。別のAIがそれを読み、足りない所を指摘し、間違いを訂正し、重複をまとめる——AIとAIのやり取りが、人の手を介さずに知識を磨いていきます。人が仲介しないので、待ち時間も、伝言の劣化もありません。

AI同士が知識を高め合う効果は、当社自身で測っています。AIが書いたコードを別ベンダーのAIが検証する運用では、挙がった指摘の約半数が、検証側のAIによって否定されました。人が一件ずつ確かめていたら、その判断だけで半分の時間が消えていた計算になります。AI同士のやり取りが、人の手を煩わせずに知識の精度を上げていく——これが、要約を書き戻す層を置く本当の意味です。

知識を集めるのも、書き残すのも、正しさを確かめるのも、次の人に渡すのも、すべてAIの側で完結します。人間は、何もする必要がありません。情報共有のために人が動く——その前提そのものが、もう要らなくなります。

埋め方 ― 要約を書き戻す層をつくる

当社はこの空白を埋めるために SmartOptimizer を作りました。RAGの代わりではなく、その上に重ねる層です。要点は5つです。

AIが作業の副産物として要約を残す。引き継ぎ資料を別途書く時間が要りません
役に立ったことが記録される。実際に参照され、解決に効いた知見が上がってきます
訂正と重複統合の経路がある。古い記述を直す担当が仕組みとして決まっています（承認は人）
宛先を持てる。確認待ち・後回し・渡して返事待ちは、次の会話でAIが先に拾って人に伝えます
止まっていることの判定にLLMを使わない。期日と日数という機械的な条件だけなので、「なぜ出たのか」を数字で説明できます

図3：SmartOptimizerが補完するのは、RAGの外側に残った4つの空白（書かれていない知識／書き戻し／宛先／鮮度）。

やらないことも決めています。工数や進捗率は持ちません。催促を送るボタンも置いていません——人が人を急かす道具にしないためです。既存のプロジェクト管理ツールを置き換えるものでもなく、ツールに起票する前に、会話の中で浮いてしまったものを拾う役割に絞っています。

2つの図書館

社内の知識は、大きな図書館と小さな図書館に分けて考えると整理できます。

大きな図書館は、設計書・議事録・ソースコードといった一次資料です。ここを引くのがRAGの仕事で、原典に当たる必要がある場面では今後も欠かせません。一方の小さな図書館には、要約と、決まったこと、決まらなかったことが入ります。日々の判断のほとんどは、こちらだけで足ります。

図4：RAGの上に「要約を書き戻せる層」を重ねる。AIが残した要約が次のAIに戻り、宛先を持つものは人へ届く。

この2つは競合しません。層が違うだけです。小さな図書館があると、毎回大きな図書館を読み直す必要がなくなり、AIの利用トークンも、人の待ち時間も減ります。

始め方 ― 1案件・1週間から

全社展開は要りません。いまAIを使っている案件をひとつ選び、既存のAI（Claude Code や Codex など）に設定を足すところから始めます。1週間ほどで、「心当たりのあること」が実際に拾われているかが見えます。

RAGをすでに入れている組織ほど、この層の効果は分かりやすいはずです。検索できるようにしたのに残った不満が、どこから来ていたのかがはっきりするからです。

RAGだけでは解決できない！？ 社内情報共有の最新ソリューション