社外に出せない文書をAIに検索させる。クラウドを使わない構成を選んだ理由

クラウドのAI検索が社内で通らない理由

製造業の技術部門にいると文書を探す時間が想像以上に長いことに気づきます。過去の仕様書。試験計画書。設計変更の議事録。どこかにあるはずなのにどのフォルダの何階層目かが思い出せない。結局は当時の担当者に聞くことになります。

この課題に対してAIによる文書検索は明確な答えを持っています。自然な言葉で問いかければ関連する箇所を提示してくれる。技術としては既に成立しています。

問題はそれを社内に導入できるかどうかです。

クラウド型のサービスは文書をサーバーにアップロードして処理します。この時点で多くの企業では検討が止まります。理由は明快で扱っている文書が顧客の図面や仕様だからです。取引先との秘密保持契約に第三者への開示を禁じる条項が入っている。社内規程で技術文書の外部送信そのものが禁止されている。

「暗号化されているから安全です」という説明はこの場面ではあまり意味を持ちません。判断するのは技術的な安全性ではなく契約上・規程上それが許されるかどうかだからです。情報システム部門に相談した段階で話が進まなくなります。

ローカルで動かすということ

では外に出さずに同じことができるか。技術的には可能です。

文書検索にAIを使う場合は一般的にRAG（Retrieval-Augmented Generation）という構成をとります。文書を細かく分割してそれぞれを数値のベクトルに変換して保存しておく。質問が来たら質問もベクトルに変換して近いものを探す。見つかった箇所を材料にして回答を組み立てます。

この一連の処理は原理的にすべて手元のPCで実行できます。ベクトル変換を行うモデルも回答を生成する言語モデルもローカルで動作するものが存在するからです。

それでも制約は多い

ただしクラウドと同じ品質を期待すると外します。ローカルで動かせるモデルはパラメータ数の面でクラウド上の大規模モデルに及びません。計算資源も限られます。GPUを積んだワークステーションを全社員に配るわけにはいかない以上は一般的な業務用PCで動くことが前提になります。

ここで設計方針が分かれます。

ひとつはローカルでも高性能を目指す方向。GPUを前提にして大きめのモデルを動かす。回答の質は上がりますが導入できる企業が限られます。

もうひとつは性能を割り切って動く環境を優先する方向。メモリ16GB程度の一般的なWindows PCで動くことを条件にします。

後者を選びました。理由は届けたい相手が中小の製造業だからです。専用機材の購入が前提になった時点で検討の土俵に乗りません。

実装で詰まったところ

企業のPCは思ったより自由がない

最初に想定が甘かったのがこれです。

ローカルでLLMを動かす場合はOllamaのようなランタイムを使うのが定石です。導入も簡単でモデルの管理もしやすい。個人のPCなら何の問題もありません。

ところが企業の業務PCでは事情が変わります。管理者権限がない。指定外のソフトウェアをインストールできない。外部との通信がプロキシで制限されている。モデルのダウンロードがそのプロキシに弾かれる。

情報システム部門にとってこれらは正しい運用です。緩めてもらう交渉は導入の障壁そのものになります。

結果として必要なものを全部同梱した形で配布する方針に切り替えました。追加のインストールが不要で初回起動時に外部からモデルを取りに行かない構成です。配布物のサイズは膨らみますが「入れるだけで動く」ことのほうが重要でした。

文書の形式がバラバラである

社内文書はきれいに整理されていません。PDFもあればWordもExcelもある。同じ内容が別形式で複数存在することもあります。

特に厄介なのがExcelです。表として構造化されているとは限らずセルを結合してレイアウトを組んだ仕様書が普通に存在します。これをテキストとして読み出すと文脈が失われます。

PDFも一様ではありません。テキスト情報を持つものとスキャンした画像だけのものがある。後者はそのままでは中身を読めません。

結局は形式ごとに読み出し方を変える処理を書くことになりました。地味ですがここの精度が検索結果の質を直接左右します。

回答だけでは使えない

技術的には成立していても業務では使えないというパターンがあります。

AIが「この部品の耐熱条件は120℃です」と答えたとしてそれをそのまま信じて設計判断はできません。誤っている可能性が排除できないからです。

そこで回答と一緒に「どの文書の何ページに書かれていたか」を必ず提示する設計にしました。使う側は原典を開いて確認できる。AIの回答はあくまで探す手間を省くためのもので判断の根拠は元の文書に置きます。

この形にしてから社内で使ってもらう際の説明が通りやすくなりました。「AIが答える」ではなく「AIが該当箇所を見つける」と位置づけたほうが実態にも合っています。

導入を検討する場合の判断材料

自社で同じような仕組みを検討する場合に先に確認しておくと判断が早くなる項目を挙げます。

確認項目	なぜ必要か
対象文書の量と形式	数百件と数万件では構成が変わります。形式が偏っていれば実装は簡単になります
実行環境の制約	管理者権限の有無。インストール可否。プロキシ設定。ここで実現可能な構成が絞られます
誰が使うか	技術者だけか事務方も使うか。後者なら操作性の要求が上がります
探している時間の実測	投資判断の基準になります。月に何時間かを数えると費用対効果が計算できます
スキャン文書の割合	画像PDFが多いとOCRの工程が必要になり難易度が上がります

特に最後から2番目の実際にどれだけ時間を使っているかは数えてみる価値があります。感覚では「たまに探す」程度でも記録を取ると想像より大きい数字が出ることが多いです。

まとめ

社外に出せない文書をAIで検索する構成は技術的には実現できます。ただしクラウドと同等の性能は望めず企業のPC環境という制約が設計を大きく規定します。

重要なのは性能の上限を追うことではなく実際に導入できる形に収めることだと考えています。どれだけ精度が高くても情報システム部門の承認が下りなければ使われません。

逆に言えば割り切って設計すれば中小企業でも導入できる水準には到達します。GPUも専用サーバーも不要で手元のPCだけで探す時間を減らすことはできます。