社外に出せないデータをAIで扱う|ローカルで完結させる構成と要件
契約書、人事評価、顧客対応の記録、未公開の決算資料、医療や法務の文書。これらをクラウドのAIに貼り付けられない、という制約は多くの会社にあります。その場合の答えは、モデルを手元で動かすことです。必要な機材と、現実的にできること・できないことまで、必要な数字とともに並べます。
まず確認すること
技術の話に入る前に、社内の判断を固めておくと手戻りがありません。
- 契約上どこまで出せるか: 主要なAIサービスには、入力を学習に使わない法人向けプランがあります。それで要件を満たせるなら、ローカル化しないほうが安く速い
- 禁止の根拠は何か: 法令なのか、顧客との契約なのか、社内規程なのか。規程が古いだけなら、更新の議論のほうが早いこともあります
- 対象の文書はどれくらいあるか: 数百ページなら人が読める量です。数万ページから、AIに任せる価値が出ます
- 誰が使うか: 1人なら手元のPC、部署なら共有サーバ、全社なら冗長化も要ります
ローカルを選ぶ理由が「なんとなく不安だから」の場合、コストと手間に見合わないことが多い。外に出せない理由がはっきりしているときだけ、この道に進むのが健全です。
ローカルで何ができて、何ができないか
| やりたいこと | ローカルで | 必要な機材の目安 |
|---|---|---|
| 文書の要約・整形 | できる | 8〜14Bクラス。VRAM 8〜12GB / Mac 16〜24GB |
| 社内文書の検索と回答(RAG) | できる | 14〜30Bクラス。VRAM 16〜24GB / Mac 32〜48GB |
| 会議録音の文字起こしと議事録 | できる | Whisper+LLM。VRAM 8GB以上 / Apple Silicon |
| 契約書のリスク抽出・比較 | できるが検証が要る | 27〜32Bクラス以上。VRAM 24GB(長い文書はKVキャッシュの量子化が前提)/ Mac 48GB |
| 複雑な推論・長い文書の精読 | クラウド上位モデルには及ばない | 70B以上。Mac 64〜128GB |
| 最新の外部情報を踏まえた回答 | できない(学習時点までの知識) | — |
要約、検索、整形といった「文書を読んで形を変える」仕事は、ローカルの中規模モデルで実用になります。一方、難しい判断や最新情報が要る仕事は、クラウドの上位モデルとの差が出ます。全部をローカルに移そうとせず、出せない文書だけをローカルで扱うのが現実的です。
構成の3段階
1. 個人で試す(20〜38万円)
まず1台で感触を掴む段階です。VRAM 12〜16GBのGPU搭載機か、ユニファイドメモリ32GBのMac。LM StudioかOllamaを入れて、手元の文書を10件ほど読ませてみる。ここで「この品質で業務に足りるか」を判断します。多くの場合、この検証で要件が具体化します。
2. 部署で共有する(32〜48万円)
使えると分かったら、共有サーバに移します。Mac mini M4 Pro 64GBかRyzen AI Max+ 395 128GBにOllamaを常駐させ、社内ネットワークからAPIで呼び出す形。Web画面が要るならOpen WebUIやDifyを同じPCに入れます。静音・省電力なので事務所に置けます。UPSを忘れずに。
3. 全社で使う(75〜115万円)
同時アクセスが増えると、会話ごとの作業メモリ(KVキャッシュ)が人数分必要になるのでメモリが要ります。RTX 5090搭載ワークステーションかMac Studio M4 Max 128GB。この規模になると、故障時の代替、バックアップ、アクセス制御の設計も必要です。
精度を決めるのはモデルより前処理
ローカルRAGで「答えが的外れ」になる原因の大半は、モデルの賢さではなく文書の前処理にあります。PDFの表がバラバラの文字列になっている、2段組が行ごとに混ざっている、スキャン文書がOCRされていない、章立てを無視して固定長で切っている。この状態では、どんなモデルでも正しく答えられません。
レイアウトを解析するPDF変換、見出し単位での分割、表の別扱い。ここを丁寧にやると14Bクラスでも十分に答えるようになり、雑にやると70Bでも答えません。機材の予算を上げる前に、前処理にかける時間を確保してください。1万ページの初回処理には、数時間から一晩かかります。
運用で決めておくこと
- アクセス制御: 誰がどの文書に質問できるか。人事文書と一般文書を同じベクトルDBに入れると、権限のない人に答えてしまいます
- ログの扱い: 質問と回答を残すか。監査で必要な一方、それ自体が機密になります
- 回答の検証: ローカルモデルも誤った内容を自信を持って答えます。出典の該当箇所を必ず併記する設計にしておくと、利用者が自分で確認できます
- 更新: 文書が増えたときに差分だけをベクトル化する仕組みを最初から作る。全件の再処理は現実的ではありません
- 停電と故障: UPS、バックアップ、代替機。常時稼働機の運用はこちらのガイドにまとめています
よくある誤解
- 「ローカルなら絶対に安全」: 機材が社内にあるだけで、アクセス制御を怠れば情報は漏れます。クラウドか手元かは、リスクの所在が変わるだけです
- 「大きいモデルほど良い」: 70Bを遅い速度で使うより、27Bを快適に使ったほうが業務では回ります。速度は利用頻度に直結します
- 「一度作れば終わり」: 文書は増え、モデルは新しくなります。年に1〜2回は見直す前提で計画しましょう
- 「GPUが必須」: 大容量メモリのMacやミニPCなら、GPUなしでもMoE型のモデルが実用的な速さで動きます(MoEとは)
必要なメモリを計算しておく
「ローカルで動かす」と決めたあと、最初につまずくのがメモリの見積もりです。必要量は3つの足し算で出ます。モデルのファイルサイズ + KVキャッシュ + 計算バッファ。数字を入れると次のようになります。
27〜32Bクラスを4bit量子化で動かす場合、ファイルは約17〜20GB。社内文書を長く読ませるならコンテキストは32,768トークンほしいので、KVキャッシュがおよそ4〜6GB。バッファに1GB強。式にすると18GB + 5GB + 1.5GB = 約24.5GBです。VRAM 24GBのGPUでは、あと0.5GBのところでVRAMに収まりません。「24GBのGPUを買ったのに動かない」は、ここで起きます。
ユニファイドメモリのMacで見ると、48GB構成でモデルに使えるのは約36GB。必要量が25GBでもまだ余裕があり、他のアプリと並行して動かせます。モデル別のページに、モデルごと・コンテキスト長ごとの必要メモリを載せています。買う前にその数字を見ておきましょう。
KVキャッシュをq8_0に量子化すれば、この値はおおむね半分になります。品質はわずかに落ちますが、あと数GBで収まるという場面では現実的な手段です。
社内文書を読ませるまでの手順
モデルを起動しただけでは、社内の質問には答えられません。手元の文書を検索できる形にする工程(RAG)が要ります。段取りは決まっています。
- 対象を絞る: いきなり全社の共有フォルダを対象にしない。よく聞かれる質問が集まっている文書群、たとえば就業規則と経費規程だけから始める
- テキストに変換する: PDFとスキャン画像が混ざっているのが普通です。ここでの取りこぼしが、そのまま回答の抜けになります
- 分割する: 500〜1,000字ごとに区切り、前後を少し重ねる。章立てを無視して機械的に切ると、条文の途中で分断されて意味が通らなくなります
- 埋め込みを作る: 検索用のベクトルを作ります。この処理もローカルで完結させないと、文書が外に出ます
- 回答に出典を付ける: どの文書の何ページを見て答えたかを必ず表示させる。これがないと、業務では使ってもらえません
この5工程のうち、精度を左右するのは2と3です。モデルを大きくするより、ここを直すほうが効果があります。
止まったときにどうするか
共有機を1台で運用すると、その1台が故障した日に業務が止まります。事前に決めておく項目です。
| 起きること | 備え |
|---|---|
| 機材の故障 | クラウドAPIへの切り戻し手順。機密を含まない処理だけ先に戻す判断基準も決めておく |
| 停電・瞬断 | 常時稼働ならUPS。数分もてば安全にシャットダウンできる。目安1〜3万円 |
| 担当者の不在 | 起動・停止・モデル更新の手順書。属人化させない |
| ディスクの故障 | 投入した文書とベクトルDBのバックアップ。作り直せる状態を保つ |
| モデルの更新 | 入れ替え前に、同じ質問で回答を比較する。良くなったと決めつけない |
編集部メモ: 「社外に出せないから、ローカルでやりたい」という相談で最初に確認するのは、実は機材ではなく文書のほうです。PDFがスキャン画像だった、表が画像として貼られていた、同じ規程の版が3つある。こうした状態のまま高性能な機材を入れても、返ってくるのは自信たっぷりの間違った答えです。
逆に、文書がきれいに整理されている会社では、思ったより小さい機材で足りることが多い。買うより先に、対象の文書を10本開いてみる。それだけで、必要な機材の見積もりはだいぶ変わります。
クラウドを使ってよい場合との線引き
すべてを手元に置く必要はありません。契約と規程を読むと、外に出せるものと出せないものの線は意外とはっきりしています。先に線を引いておけば、機材の規模もその分だけ小さく収まる。
| 扱うもの | 置き場所 | 判断の根拠 |
|---|---|---|
| 公開済みの資料、一般的な調べ物 | クラウドで問題ない | そもそも社外に出ている情報 |
| 社内向けだが機密でない文書 | 契約次第 | 学習に使われない契約かどうかを確認する |
| 個人情報を含む記録 | ローカル、または明示的に許可された経路 | 社内規程と、必要なら法務の判断 |
| 顧客との守秘義務がかかる資料 | ローカル | 契約書に外部送信の制限があることが多い |
| 未公開の決算・人事情報 | ローカル | 漏えい時の影響が大きく、社内でも権限が分かれる |
上2行をクラウドの上位モデルに任せられれば、ローカル側に求められる品質は下がります。配分を変えたときの損得は、コスト比較のページの計算機で確かめてください。
導入の順番
いきなり全社に広げると、精度の問題と運用の問題が同時に起きて、原因の切り分けができなくなります。段階を踏むほうが結果的に早く進みます。
- 1台で試す: 個人の機材で、対象の文書を10本だけ入れて動かす。ここで前処理の問題がほぼ全部見つかります
- 1部署で回す: よく聞かれる質問が集まっている部署を選び、共有機を1台置く。使われ方と待ち時間を1か月見る
- 権限を合わせる: 文書ごとのアクセス権と、質問できる範囲をそろえる。ここを飛ばして広げると、あとから戻すのが大変になります
- 対象を広げる: 文書の範囲を増やす。増やすたびに、既存の質問で回答が悪くなっていないかを確かめる
- 運用に移す: 手順書、バックアップ、更新の判断基準。担当者が替わっても回る形にして完了です
よくある質問
ローカルLLMの回答品質は業務で使える水準ですか
用途によります。社内文書を検索して該当箇所を要約する、定型の文章を作る、分類する。こうした「範囲が決まっている仕事」なら27〜32Bクラスで実用になります。一方、複雑な推論や長いコードを書かせる用途では、クラウドの上位モデルとの差がはっきり出ます。まず範囲の決まった仕事から始めるのが確実です。
インターネットに接続しない環境でも動きますか
動きます。モデルのファイルを一度ダウンロードしてしまえば、以降の推論に通信は要りません。閉域網の中に置く構成も可能です。ただしモデルの更新やツールのアップデートには持ち込みの手順が要るので、その運用ルールを先に決めておきましょう。
個人情報を扱う場合に追加で必要なことはありますか
機材が社内にあっても、アクセス制御とログは要ります。誰がどの文書に質問できるかを、元の文書の権限と一致させておくのが基本です。ここがずれると、権限のない人が要約経由で内容を読めてしまいます。具体的な要件は自社の規程と、必要なら法務の確認に従ってください。
どの機材から始めるのがよいですか
部署で共有するなら、ユニファイドメモリ64GB以上の常時稼働機が扱いやすい構成です。GPUの増設や電源容量を気にせず、静かで消費電力も小さく収まります。社内文書の検索・要約をさせるPCスペックに、要件を満たす構成を並べています。