Knowledge Worker/Intelligence Foundation が2025年に公開した調査が、少し耳の痛い数字を出している。ナレッジマネジメントの仕組みを持たない企業では、社員が週平均8.5時間もファイルを探すことに費やしていた。そうした仕組みを導入した企業ではその時間が4.6時間まで縮み、週あたり3.9時間の削減は、1,000人規模の組織なら年間で98人分のフルタイム人員に相当する。
この生産性の話を、データ主権という文脈に置き直してみよう。規制産業や公的機関、機密を扱う企業にとって、文書は「クラウドに置いてよいもの」ではない。にもかかわらず現場の社員は、内網の外に出せないはずのファイルを、外部のクラウド便や SaaS へと漏らし続けている。セキュリティ境界の内側に文書基盤を据え直すこと──それが、探す時間を減らす以上に重要な課題だ。
データ主権を意識せざるを得ないのは、一部の業界だけではない。医療・法務・金融・防衛・公共および地域の基幹インフラを担う組織は、機微データを自社ネットワークの外に出すこと自体が許されず、契約上あるいは法執行上の理由からも外部送信が制限される。そうした組織にとって、文書の圧縮・検索・知識化は「どのクラウドに頼むか」ではなく「いかに内網で完結させるか」という問いになる。道具を導入しても、その裏でクラウドへデータが流れていれば主権は守られない。「便利さ」と「守り」の間で、後者を静かに諦めてきた組織は少なくない。この記事は、その均衡を取り戻すための具体的な線を引く。
なぜエアギャップ前提の文書基盤が必要か
クラウドファーストが十年続いた結果、多くの組織は文書の「整理・圧縮・検索・知識化」を外部サービスに預けてきた。だがデータ主権を重んじる現場では、その前提が崩れている。医療・法務・金融・防衛・公共といった分野では、機微データを自社内ネットワークの外に出すこと自体が許されない。
厄介なのは「死蔵データ」だ。ストレージ分析企業 Komprise の調査によれば、企業 NAS データの 60〜70% は 90 日以上まったく参照されていない。それでも最も高価な一次ストレージを占有し続けている。エアギャップ環境でこうした文書を圧縮し、意味で検索し、自動で分類・アーカイブできれば、ストレージコストと運用負荷を同時に下げられる。
死蔵データはコストの話だけにとどまらない。参照されないファイルほど古い形式と曖昧な権限を抱え込み、誰も責任を持てないまま内網の隅に積もる。放置すればストレージ代はさておき、事故が起きたときの追跡範囲が雪だるま式に広がる。セキュリティ担当にとって、触らずにいられないデータを最低限「意味で検索でき、自動で分類される」状態に置くことが、防御の一段目になる。
具体的に考えてみよう。法務部門が十年分の契約と判例を抱え、そのすべてを外部の検索 SaaS に投げることは、守秘義務上できない。同じことが医療のカルテ、金融の審査記録、公的機関の公文書にも当てはまる。現実には「とりあえず共有フォルダに置く」が続き、探す時間も漏洩リスクも膨らむ。文書基盤をオンプレ/エアギャップで持つことは、この矛盾を解く第一歩だ。結局のところ、文書基盤をどこに置くかは「理想の原則」ではなく「運営の現実」が答えを決める。
選定のフレームワーク:五つの軸
エアギャップ/オンプレミス向けの文書ツールを選ぶとき、どの軸で見ればよいか。以下は UglyPear Data が顧客と組む際の選定フレームワークだ。「サーバー不要」の一言で判断せず、項目ごとに採点してほしい。各軸の判断材料を深掘りしたいなら、技術ブログにも選定の考え方をまとめている。
| 軸 | 見るべき点 | 陥りやすい罠 | 対応の要点 |
|---|---|---|---|
| アーキテクチャ | オンプレ機器の CPU/OS をネイティブで支えるか | x86 版しかなく、専用機で起動直後に動かない | 対象アーキテクチャ向けのネイティブ対応版 |
| 展開形態 | オンプレ/エアギャップ私有化か、常時通信必須か | 公網 SaaS に強く縛られ、内網だけでは動かない | 完全な私有化。データは内網の外に出ない |
| 形式カバー | PDF・Office・スキャン・画像・音動画など 8 形式 | PDF しか扱えず、他形式を落とす | 多形式を端から端まで処理し、版面を保持 |
| コンプライアンス | 機微情報の秘匿化と監査の痕跡 | 秘匿化がなく、漏洩リスクが高い | 13 分類の機微情報を自動検知 |
| 性能 | 大容量ファイルのスループットと同時処理 | 単一処理で数百 MB になると固まる | 自社開発エンジンによるローカル並行処理 |
この表で肝心なのは、五つの軸が独立していないことだ。アーキテクチャがネイティブでなければ、性能もコンプライアンスも端から崩れる。逆に展開形態に「常時通信必須」が混ざっているだけで、エアギャップの要件は満たせない。一項目でも「条件付き」があれば、そのツールはオンプレ前提の現場に馴染まないと見なしてよい。
オンプレミス導入サービスが実際に届ける五つのもの
ソフトを「インストールできた」のは入り口に過ぎない。本当の導入は、次の五つからなる。
環境検証──対象となるサーバー/端末の OS とアーキテクチャの上で、起動と中核機能を動かし抜く。
ネイティブ提供──対象アーキテクチャ向けのネイティブ対応版を届け、翻訳層に頼らない。
形式互換テスト──顧客の実際の過去文書を抽出して圧縮・変換し、版面・文字コードに狂いがないか確かめる。
性能チューニング──内網機器の演算力を使い切りつつ、画面を固めないよう調整する。
コンプライアンス点検──機微項目は格納前に自動で秘匿化し、操作には痕跡を残す。
これら五つは単なる作業手順ではない。エアギャップ現場では「外のネットに一度も触れずに、ここまで動かせるか」が導入の成否を分ける。だから検証も調整も、すべて顧客の隔離された環境のなかで完結させる。
製品がどう馴染むか
圧縮を担うのが SmartSlim だ。PDF・画像・動画・音声・Office・スキャン文書など 8 形式を端から端まで処理し、一部の地域で義務付けられる OFD もカバーする。対象アーキテクチャ向けのネイティブ対応版を用意しているため、専用機や内網端末でもそのまま動く。圧縮は端末内で完結し、データが外部サーバーへ渡ることはない。公式の実測では、443 ページの文書を通しで圧縮し終えるのに 124 秒。画像を圧縮してから大規模言語モデルに流せば、トークンコストを 85.9% 削減できる(GPT-4o 検証)。エアギャップ環境では、ローカルで完結するこの設計が特に効く。演算を節約しながら、ネットワークの外へは何も出ない。詳細は SmartSlim の製品ページを参照されたい。
製品の更新も、現場視点で押さえておきたい。SmartSlim の PDF 圧縮は、従来どうしても外部ツールに頼む場面があった。近期のアップデートで、ここを自社開発の圧縮エンジンだけで完結できる形に変えた。利用者への意味はシンプルだ。導入時に持ち込む部品が減り、環境検証や形式確認の工程が短くなる。隔離された環境ほど、構成が一つ減るだけで手間は目に見えて下がる。
文書を「整理できる」側面は MagiFiler が担う。内網にファイルが散乱し、見つからないのは昔からの癖だ。MagiFiler なら、対話的な自然言語でファイルを操作し、内容の意味から検索し、自動で分類・タグ付け・保管できる。macOS・Windows・Linux に対応し、端末 3 台まで紐付け。買い切りのワンタイム払いで、ライセンスキーは即時発行される。SmartSlim が「小さく圧縮する」を、MagiFiler が「見つかる」を支える。二つは補完し合う能力だ。詳しくは MagiFiler の製品ページを確認されたい。
RAG データエンジニアリング基盤は、「大規模言語モデルに食わせる」を解く。ナレッジベースをエアギャップ環境で本当に使い物にするには、散らばった文書をモデルが食える構造データに変える作業が本質的な難関だ。当社の RAG 基盤は六つの工程と八つの能力を備え、私有化展開でデータを内網の外に出さず、組み込みで 13 分類の AI 機微情報を自動秘匿化する。ここで避けて通れないのがセキュリティの文脈だ。IBM の「Cost of a Data Breach Report 2025」によれば、5 社に 1 社の企業が従業員の非公認 AI ツール利用(シャドー AI)を発端とするデータ漏洩を経験した。そうした企業の平均漏洩コストは同等企業より 67 万ドル高く、漏洩に遭った組織の 63% は AI ガバナンス方針すら持っていなかった。RAG を完全な私有化環境で動かすことは、シャドー AI という漏洩経路を塞ぐことに他ならない。基盤の全体像は RAG データエンジニアリング基盤のページで確認できる。
エアギャップ文書方針を評価中なら、製品一覧から各ツールの要件を照らし合わせてほしい。
こんな現場に馴染む
どの組織にも当てはまるわけではない。以下のいずれかに当てはまるなら、オンプレ/エアギャップの文書基盤は検討に値する。契約や記録を外部 SaaS に預けられない法務・医療・金融部門──ここでは「検索はできて、外へは出ない」が基本線だ。規制や監査でデータの持ち出しを禁じられている公的機関──内網だけで圧縮・検索・知識化が完結してはじめて監査対応が立つ。そして、大量の過去文書を抱えながら高価な一次ストレージを圧迫されている情報システム部門──死蔵データを圧縮・アーカイブすれば容量とコストが一緒に下がる。共通項は「クラウドに頼めない」だ。
三つの製品はそれぞれ役割を分けながら、一本の流れにつながっている。SmartSlim が容量を減らし、MagiFiler が整理し、RAG 基盤が知識に変える。すべてが内網のなかで完結するため、境界を越えるデータは生まれない。小さく始めて三つの指標で効果を測れば、次の部署へ広げる根拠が手に入る。この流れは既存のセキュリティ方針とも衝突しない。
導入を進めるとき
エアギャップ化は、システムを差し替えるだけで終わるものではない。文書という線も一緒に越えなければならない。小さな範囲でパイロットを提案したい。ある部署の文書管理やストレージ最適化の現場を一つ選び、SmartSlim・MagiFiler・RAG 基盤を内網の上で回してみる。注目すべきは圧縮率、ファイル検索にかかる時間、ナレッジベース構築の周期という三つの指標だ。試用の入口は SmartSlim の製品ページに、各ツールの比較は 製品一覧に、より深い技術解説と選定の考え方は 技術ブログにある。
よくある質問
Q:エアギャップ環境では専用ハードウェアが必須か。
A:必ずしもそうではない。重要なのはアプリケーション層がその環境でネイティブに動き、データがネットワークの外に出ないことだ。既存の社内サーバーや端末の上に私有化して組めば十分な場合が多い。厳しい形式互換が必要なら、導入段階で一緒に検証する。序盤は一台のワークステーションでの概念実証をおすすめする。
Q:既存のクラウド文書ツールはそのまま移せるか。
A:大半は無理だ。クラウド前提のツールは常時通信を前提としており、内網だけでは動かない。正解は、オンプレ/エアギャップをネイティブで支え、多形式をカバーするツールを選ぶこと。互換層をかぶせて凌ぐのは、運営中にいつ崩れるか分からない負債を抱えるのと同じだ。
Q:私有化展開と SaaS、どう使い分けるか。
A:内部の文書・契約・財務データを扱うなら、優先して完全な私有化を。データは内網の外に出さない。対外的な展示系の軽い用途だけが SaaS の対象になる。境界をどこに引くかはデータの機微度が決める。その基準を文書として残しておけば、監査対応も軽くなる。
Q:RAG 基盤はエアギャップ上で実際に動くか。
A:動く。対象アーキテクチャ向けのネイティブ対応版に調整を施し、知識エンジニアリングの六つの工程をローカルで完結させる。機微情報の秘匿化は格納前に自動実行され、外部の演算資源には頼らない。モデルを外へ出す必要も、推論を外に任せる必要もない。
Q:導入サービスに古い文書の移行は含まれるか。
A:形式互換テストの枠組みに含まれる。過去文書の版面・文字コードを抽出検証する。ただし全蔵書の移行工数は実際のデータ量ごとに別途見積もり、標準導入パッケージには含まれない。範囲はパイロット段階で一緒に決める。