ここ数年、多くのネット通販チームにとって「資料」は片付ければ済むものだった。スキャンして共有フォルダに放り込み、次へ。しかしデータの居場所を巡る規制の目が厳しくなると、このやり方は通じなくなった。顧客情報や取引記録が「どこにあるか」を問われる市場が増え、「後でまとめる」はもはや答えにならない。データ主権やプライベートデプロイ、air-gapped でのコンプライアンス——こうした言葉が現場の会議に並ぶようになった。
UglyPear Data が見てきたのは、いつも同じ構図だ。ボトルネックはツールの不足ではない。ファイルが多すぎ、散らばりすぎ、デリケートすぎるせいだ。消すのが怖い、また見つからないのが怖い、監査で知らないうちに穴が見つかるのが怖い。
McKinsey の試算では、知識労働者の約 19% の労働時間が「情報の検索・収集」に費やされている。ECチームならこの数字は一段と上がる。商品カタログ、仕様書、仕入れ先との契約、サポート用のトーク、返品ポリシー、配信台本——すべてが毎日積み上がる。Komprise が企業の NAS を調べると、少し痛い事実が出た。90 日以上アクセスされていないデータが全体の 60%–70% を占めているのに、いちばん高価なプライマリストレージを食い続けている。必要なファイルは、忘れたファイルの下に埋もれる。
Asana と集中力の研究が示す数字も忘れがたい。作業が一度中断されると、再び集中状態に戻るのに平均 23 分かかる。そのうえ一日に約 35 の異なるアプリ間を切り替えているという。資料が散るたび、人は「集中のリセット」を強いられている。
金銭の話もある。プライマリストレージは上位ティアの値段がつく。六〜七割のデータをそのティアに置きっぱなしにするのは、眠ったファイルに家賃を払い続けるようなものだ。セールが終わっても、前シーズンのランディングページや配信の切り抜き、無効になったキャンペーン条項はそのまま残る。誰も消さない。「後で使うかも」と外したくないからだ。
EC特有の悩みもある。チャネルが多く、バージョンが乱立する。同じ商品に近い説明が五つも飛んでいる——詳細ページ、配信原稿、アフターサポートの条項、海外向けの記述。どれが最新か、たいてい誰も確信を持てない。そのとき気づく。本当に高いのは保存ではなく、「探す」と「見分ける」ことだ。
これらすべてを公開クラウドのモデルに渡して知識ベースを作るのは、聞こえは楽だ。実際にやってみると、三つの悩みがついて回る。
一つ目、データは自社のネットワークを出なければならない。顧客の注文や取引記録に関わるものなら、一行も書かないうちにコンプライアンスの壁にぶつかる。二つ目、生ファイルがそのままインデックスに入り、数百ページのカタログではページごとの写真が保存枠と検索枠をすぐに食いつぶす。三つ目、検索が遅く、モデルが「覚えている」内容を信用できるかいつまでも確信を持てない。
では、コンプライアンスを守りながら検索できる資料庫をどう組むか。答えは短い。データは自社の敷地に置いたまま、私有化した RAG データ基盤で組み、手前に圧縮という前処理を置くことだ。
以下が、実際に効く選定の軸だ。
| 次元 | パブリッククラウド SaaS ナレッジベース | プライベート RAG + 圧縮（オンプレ） |
|---|---|---|
| データの行き先 | ドメインを出て公衆クラウドへ | 自社ネットワーク内に留まる |
| コンプライアンス適合 | 現地のアーカイブ・プライバシー要件に沿いにくい | 現地のコンプライアンス要件に合わせやすい |
| 検索応答 | ネットワークと割り当てに左右される | ローカル検索で応答が速い |
| ファイルサイズ | 元の大きなファイルをそのまま格納し場所を取る | 格納前に圧縮してスリム化 |
| 長尾フォーマット | 対応範囲が限られる | PDF・画像・動画・図面など多様に対応 |
私有 RAG で本当に手間のかかる箇所は、モデルをつなぐことではない。資料をきれいに仕立てて、きちんと庫に収めるところだ。UglyPear Data の取り組みは、検索拡張生成（RAG）のデータ基盤だ。定められた処理の流れを持ち、私有化してデプロイするからデータはネットワークを出ない。13 種類の AI 機微情報に対しても自動で秘匿化する。ECであれば、仕入れ先との契約や顧客の注文、商品の資料がすべてローカルで検索・引用でき、元データは移動も外部流出もしない。仕組みの全体像は RAG データ基盤 から眺められる。
RAG だけでは、知識ベースはまだむくんだままだ。SmartSlim は格納前の段階を受け持つ。文書・画像・動画・音声を圧縮し、公開されている目安では体積を 60%–80% 減らせる。ここで最近、ようやく手になじんできた点を一つ。商品カタログのような「複合文書」は画像を大量に内包している。圧縮エンジンは、文書がナレッジベースに入る前に、内包された画像をより軽い形式に変換する。一冊丸ごとスリム化されてから格納されるわけだ。画像を手動で書き出す必要はないし、圧したあと見えなくなる心配もない。印影や図表といった肝心の視覚情報はそのまま残る。デスクトップ版とサーバー版の違いは SmartSlim で確認できる。
公開されている実測値を挙げよう。443 ページの文書を 124 秒で処理した例がある。画像関連のトークンは約 85.9% 削減される。見かけは保存の節約だが、検索前に小さくなれば検索は速く正確になり、端末間の同期も詰まらなくなる。
具体的な場面を一つ。サポートに、古い商品の保証条項を問い合わせられたとする。以前ならチャット履歴を掘り、PDF を探し、製品チームに聞かなければならなかった。いまはローカルの知識ベースに尋ねるだけで、答えは出所付きで返ってくる。どの文書の、どの節かが一目だ。注文や契約は内網に留まるから、一文の返答を得るために顧客データを外に出す必要はない。この手の現場話は 技術ブログ にもいくつか載せている。
監査の場も楽になる。監査が求めるのは「原本をいつでも呼び出せ、しかもネットワークの外に出ていない」と証明できるかだ。私有化デプロイとローカルアーカイブはその要求にぴたりと合う。
圧すだけで庫を作らなければ、ファイルは小さくなっても人は見つけられない。庫を作って圧さなければ、重すぎて動かない代物ができあがる。両方がリレーすることではじめて、知識ベースは軽く、速く、コンプライアントになる。
FAQ
Q: ECサイトの資料庫は私有化しなければならないか？
A: 必ずしもそうではない。資料が軽く、機微でなければ公衆クラウドの SaaS でも足りる。しかし取引記録、顧客の注文、仕入れ先との契約に関わるものは、データがネットワーク内に留まる私有化デプロイのほうがずっと安全だ。
Q: 商品カタログや仕様書は画像が多いが、圧縮でにじむか？
A: エンジンは複合文書に特化して扱い、内包画像を軽い形式に変換しつつ肝心の視覚情報を残す。公開の実測では 443 ページの文書を 124 秒で処理し、鮮明さは保たれている。
Q: RAG 知識ベースの組み立てにどれくらいかかるか？
A: UglyPear Data の取り組みは端から端までの実測を重視し、検索と応答はサブ秒の水準に達する。実際の期間はデータ量と接続の方法による。多くの場合、既存の業務データベースに直接つなぎ、移行はしない前提で見積もる。
Q: 圧縮と RAG をなぜ一緒に使うか？
A: どちらか単体でも使えるが、組むと収まる。圧縮は格納前にファイルを小さくし、RAG はローカルで検索と生成を行う。このリレーが、庫を軽く速くコンプライアントにする。
Q: 画像の多い文書では、モデルへのトークン費用を下げられるか？
A: 下げられる。公開の実測では画像関連のトークンが約 85.9% 減る。検索に回す素材ほど恩恵が大きい。
Try it now
実際の動きを見たいなら、SmartSlim でデスクトップ版とサーバー版を確認しよう。あるいは RAG データ基盤 の私有化デプロイの選択肢を眺めてもいい。技術ブログ には他の現場の分解もあるし、製品総覧 なら一度にすべてが見渡せる。