安全な官公庁ナレッジベースの構築：プライベート RAG と文書圧縮

「紙の台帳をスキャンして、共有サーバーに放り込む。これで『ナレッジベース』のできあがり」——そう考えている官公庁の担当者は、おそらく少なくない。しかしこれは、ナレッジベースとは何かについての根本の誤解かもしれない。

公共部門の現場を苦しめてきたのは、これまで一度も「容量が足りない」ことではなかった。自組織の情報を、きちんと統治し、かつ実際に使える形にできるかどうか。その一点だった。

ファイルはどんどん溜まる。だが、窓口で即座に呼び出せて、しかも「これなら根拠にできる」と信頼を置ける割合は、逆に縮んでいく。正直に言えば、こうした仕組みの多くを「ファイル庫」と呼ぶほうが、「ナレッジベース」と呼ぶよりもずっと誠実だ。

少し背筋が冷えるような数字がある。世界中を流通している PDF はすでに 3 兆枚を超え、主要なコラボレーション・プラットフォームの一つだけでも、毎日 20 億件以上のファイルが新規アップロードされている。官公庁のシステムはこれより重い。公文書、会議録、審査記録、図面、音声・映像——形式は混在し、版数は際限なく増え、保存期間は十年単位に及ぶ。量は増えた。だが「探せる」は追いついていない。

M-Files が Vanson Bourne に委託した世界的な調査が、この痛みを的確にとらえている。回答者の 96% が「文書の最新版を探すのに苦労する」と答え、83% が「すでにあるはずの文書が見つからず、結局ゼロから作り直したことがある」と答えたのだ。これを官公庁の文脈に置いてみよう。ある政策の解釈が、部署ごとにわずかに異なる形で保存され、どれが「現在効力を持つ版」か誰にも確信が持てない。市民が窓口を訪れ、担当者が引いた根拠が三年前の旧文書だったとしたら。この「溜めれば溜めるほど混沌とする」傾向は、単なる保存不足よりずっと深刻だ。

面白いことに、解決策は「ハードディスクをもう何台か買う」ことではない。

UglyPear Data は「圧縮 × RAG データ基盤」を、官公庁の自前インフラだけで動かせる構成にまとめた。そしてこの全体パイプラインは、最近エンドツーエンドで実証を終えている。公共部門のチームが特に注目すべき点は、実は目立たないところにある。権限が「ファイルに貼り付けられる」ものではなく、「検索されたその瞬間に効く」という設計だ。言葉にすると抽象的に聞こえるかもしれない。だが動くところを見ると、話は変わる。

一つの文書の中に、公開してよい業務内容と、本当に機微な作業メモが混在することは珍しくない。従来のやり方では、文書全体に一つの権限を振るしかなく、結果として「全部オープン」か「全部ロック」の二択を迫られた。どちらも現場にそぐわない。現在の基盤は、公開から制限までの段階的区分を支え、その区分を「内容のセグメント（段落・箇所）」の単位まで押し下げる。部署も役割も異なる人が同じ知識ベースを検索しても、それぞれが権限を持つ部分だけを見る。この「人・セグメントごと」の権限モデルは、官公庁の実態に、全体一律のファイル錠よりずっとフィットする。同じ報告書でも、課長にはある措置が見え、係員には別の口径が見える——そうであるべき姿だ。

なぜこれほど神経を使う価値があるのか。IBM の『2025 年データ漏洩コスト報告書』が一つの目安を出している。データ漏洩の世界的な平均コストは 444 万米ドルに達し、封じ込めまでの平均期間は 241 日だった。官公庁のデータはこれより高い機微性を持つ。一度外に出れば、金銭的な損害を超えた代償がついてくる。知識ベースを自組織の環境にとどめ、データを内網（イントラネット）から外に出さないことは、露呈の表面積を根元から小さくする作法だ。「プライベート配置」の意味とは、流行ではなく、底線（ベースライン）なのである。

ただ、門を閉ざすだけでは足りない。公共部門のチームには、もっと実務的な懸念がある。既存システムのデータなど、そもそも動かせるのか。

「知識ベースを作る」と聞いて、多くの部署が思い浮かべるのは「業務データベースを全部移行しなきゃ？」という恐怖だ。だが通常はそうする必要がない。成熟したアプローチは、官公庁の既存データベースに直接接続する。原本はその場にとどまり、域内にとどまったまま、コンプライアンスのルールのもとで検索・引用できるようになる。学籍、社会保障、審査といったシステムは、これまでどおり回り続ける。知識層は横からそれらを引くだけだ。古いシステムをぶち壊して組み直す必要はない。この穏やかな進化の道筋こそが、組織のなかで実際に採用される。

見落としがちなもう一つのリスクは、「更新がそれまでのものを消してしまう」ことだ。官公庁の文書には強い保存要件がある。十年前の記録が、いつ誰の手元で必要になるかわからない。基盤は増分更新を支える。新しい文書は毎回ゼロから再構築するのではなく差分として処理され、各更新はスナップショットを残すから、何かあればロールバックできる。さらに一括削除には、誤った大量削除を防ぐ仕掛けが働く。多くの管理者が恐れる二つの言葉——「もう探せない」と「うっかり消した」——を、プロセスのなかで事前に塞いでしまうのだ。

圧縮についても触れておく。官公庁の文書は PDF、スキャン画像、OFD、図表、音声・映像の塊で、一つが数十〜数百メガバイトに達するのはざらだ。メールに添付できず、安価に保管できず、開くだけで待たされる。公開された実測では、443 ページの OFD 文書を端から端まで圧縮するのに 124 秒を要した。また画像を圧縮して大規模言語モデルに渡したとき、トークン・コストは約 85.9% 下がった（GPT-4o を基準に計測）。圧縮と RAG は別の二つの仕事ではない。一つの鎖の、前後の輪だ。送りやすく・蓄えやすい大きさに縮めてから、構造を知識ベースへ抽出し、それから初めて検索と生成が回る。順序を逆にすれば、モデルは本文に手をつける前に、文書の大きさで息が詰まる。

三つの道——公有クラウド SaaS 型、単なるローカルファイル保管、そしてプライベート RAG ＋ 圧縮——は、実際にどこが違うのか。一つの表で整理しよう。

この表は「どの次元を見るべきか」の枠組みであって、いずれの製品への評価でもない。次元を並べたうえで、公共部門のチームは自らに問うてみるといい。データは内網を出せるか。一つの文書のなかで、公開部分と機微部分を別々に権限を付けられるか。既存システムを移行せずに接続できるか。更新を誤っても戻せるか。それに答えれば、道は自ずと選ばれる。

冒頭の誤解に戻ろう。ナレッジベースの正体は、決して「紙をハードディスクへ運ぶ」ことではない。正しい人が、正しい瞬間に、見るべき部分だけを見られ、しかもデータが常に自らの手の中にあることだ。官公庁という場の特殊さは、開かれて奉仕しつつも区分を守り、古いシステムにつながりつつも作り直さず、十年前の記録を残しつつも今日のモデルを動かす、その矛盾を一つに編み上げるところにある。それこそが、本当に地に足の着いた解だ。

全体像を知るには、RAG データ基盤 を手にとってほしい。現場の工夫は 技術ブログ に詰まっている。

今すぐ試す

官公庁のナレッジベースや、私有化された文書ハブをご検討なら、一つのパイロット文書セットから、小さく始めてみよう。一つの部署と一つの文書種を選び、「圧縮—構造化—検索—権限付与」の小さな輪を回してみる。関連する製品とソリューションは RAG データ基盤 と UglyPear Data の製品総覧 にあり、配置や選定の細部はそちらで確認いただける。

よくある質問

Q：官公庁のデータは非公開（プライベート）に保つ必要があるのか？
A：機微な情報を扱うナレッジベースには、プライベートないしオンプレミスでの配置が安全な標準になる。データを内網内にとどめるためだ。純粋に公開情報なら柔軟に扱ってよい。原則は、機微度に応じて段階を分けることであり、すべてに一つの規則を当てはめる必要はない。

Q：既存の業務システムのデータをすべて移行しなければならないか？
A：いいえ。既存データベースへ直接接続する手段があり、原本は動かず・域内にとどまったまま検索や引用が可能になる。傷の深いデータ移行を避けられる。

Q：一つの文書に、公開できる内容と機微な箇所が混在している場合はどう管理するか？
A：セグメント単位の区分を支え、権限は検索時に付与として下推される。役割ごとに権限のある部分だけが見えるため、文書全体での二択は不要だ。

Q：更新すると古い版が上書きされて失われるのではないか？
A：増分更新とスナップショット・ロールバックを支えるから、いつでも差し戻せる。一括削除には誤削防護が働き、操作ミスのリスクを下げる。

Q：圧縮は検索の精度や原文の鮮明さを損なうか？
A：圧縮の対象は保存・伝送の大きさだ。押印や表の構造といった重要な版式要素は圧縮後も保持される。本文は構造化して抽出され検索に用いられるため、内容の完全性は損なわれない。