前回の記事で、規制業界のアナログ職場にローカルLLM＋RAGの導入を提案し、役員からGOが出たところまで書きました。
今回はその一歩手前の話です。なぜクラウドAIではなく、ローカルLLM＋RAGという選択肢にたどり着いたのか。
うちの職場は「クラウドAI禁止」と明文化されているわけではありません。ただ、気軽には使えない。この「グレーだけど実質使えない」状態は、完全禁止の職場で働く人にもそのまま当てはまる話だと思うので、意思決定の中身を残しておきます。
ハードルの本丸は「個人情報を入力してしまうリスク」
クラウドAIが使えない理由としてよく挙がるのは「セキュリティポリシー」という漠然とした言葉ですが、実際に提案を組み立てる中で見えてきた本丸はもっと具体的でした。
個人情報をプロンプトに入力してしまうリスクです。
うちの職場は業務の中心に個人情報があります。クラウドAIを開放した場合、「この書類の内容を要約して」と善意でコピペした瞬間に、個人情報が外部サーバーに送信される。悪意ゼロでも事故が起きる構造です。
ここで重要なのは、すべての業務がアウトなわけではないことです。
- 事務手続きの流れの確認
- 社内マニュアルの検索・要約
- 様式の書き方の質問
このあたりは個人情報を含まない情報です。「入力していい情報・ダメな情報」の線引きを整理し、ルールと教育をセットにできれば、クラウドAIも選択肢としては残ります。実際、検討の途中で「クラウドは完全に無し」と切り捨てたことは一度もありません。
問題は、その線引きの整理・周知・徹底にかかるコストと、それでも残る「うっかり」のリスクでした。
このとき意識していたのは、「AIに個人情報を入れてはいけない」で思考停止しないことです。リスクをゼロにする発想ではなく、扱うデータの分類と用途で線を引く。禁止か全面解禁かの二択ではなく、その間にある現実的な落とし所を探すスタンスで検討を進めました。
決め手はイントラ環境だった
最終的にローカルLLM＋RAGに振り切った決め手は、リスク論よりも物理的な業務動線です。
うちの職場の端末構成はこうなっています。
- 業務のメイン動線：イントラ端末（インターネット接続なし）
- インターネット端末：一部のみ。共用に近い扱い
仮にクラウドAIの利用ルールを整備できたとしても、使えるのはネット端末だけ。つまり「AIに聞きたいことができたら、席を立ってネット端末まで移動する」という運用になります。
これ、確実に使われなくなるやつです。
調べ物のために席を立つくらいなら、隣の人に聞くか、諦めて自己流でやる。アナログな職場ほどこの傾向は強い。AIが業務フローの外にある限り、定着しません。
逆に言えば、イントラ内にLLMを置ければ、全員が今使っている端末からそのまま使える。この「シームレスさ」が、ローカルLLM＋RAGを選んだ最大の理由です。
選択肢は4つあった：比較表
検討した選択肢を整理するとこうなります。
| 選択肢 | 個人情報リスク | イントラ親和性 | 導入ハードル | 現場の使いやすさ |
|---|---|---|---|---|
| クラウドAI（ChatGPT等） | 入力ルール整備が必須 | ✕（ネット端末のみ） | 低 | ✕ 席を立つ運用 |
| 閉域クラウド | 低い | △（要ネットワーク精査） | 中〜高 | ○ |
| 何もしない | ゼロ | − | ゼロ | −（現状の非効率が続く） |
| ローカルLLM＋RAG | 低い（データが外に出ない） | ◎（イントラ内に設置） | 中 | ◎ 既存端末でそのまま |
補足です。
閉域クラウドは「クラウドの性能と、オンプレに近い安全性のいいとこ取り」に見える選択肢で、実際まだ捨てていません。ただ、イントラと閉域網をどう接続するか、ネットワーク構成の精査が必要で、即断できる状態にありませんでした。ベンダー相談の中で引き続き比較対象に残っています。
何もしないは、ゼロリスクに見えて「事務ミスと問い合わせ対応のコストを払い続ける」選択です。ここを可視化できたことが、提案が通った一因だと思っています。
ローカルLLM＋RAGは導入ハードルこそ中程度ですが、「データが外に出ない」「既存端末からそのまま使える」の2点で、うちの環境では頭ひとつ抜けていました。
チャットAI単体では現場に刺さらなかった
ここからは選定の中でわかった、もうひとつ大事な話です。
仮にイントラ内にローカルLLMを置けたとして、素のチャットAIだけでは現場に刺さりません。
普段AIを使わない人に白紙のチャット画面を渡すと、ほぼ確実にこうなります。
「……で、何に使えばいいの？」
私たちのようにAIを日常的に使う側は「何でも聞けばいい」と思いがちですが、効率化のイメージが湧いていない人にとって、自由入力欄は自由ではなくただの空白です。具体的な用途と結びつかない道具は、数回触って終わります。
提案を組み立てる段階でこの壁を感じたので、「AIを入れます」ではなく「この困りごとがこう解決されます」まで落とし込む必要がありました。
RAGが刺さった理由：困りごとに直結したから
そこで効いたのがRAG（検索拡張生成）です。社内のマニュアルや手続き文書をLLMに読み込ませ、根拠付きで回答させる仕組みです。
うちの職場の慢性的な困りごとはこうでした。
- 事務手続きが煩雑で、手順を覚えきれない
- マニュアルはあるが、どこに何があるか分からない（マニュアル迷子）
- 結果として事務ミスが起きる
- 分かる人への問い合わせが集中し、その人の業務が止まる
RAGはここに直撃します。「この手続きの様式はどれ？」「この場合の処理手順は？」に、根拠のマニュアルを示しながら即答する。チャットAIという新しい道具ではなく、「マニュアル検索の苦痛がなくなる仕組み」として提示できるわけです。
前回書いたとおり、個人のMacでOllama＋Open WebUIのデモ環境を作って見せたのですが、反応が明らかに変わったのは「何でも答えるAI」を見せたときではなく、「手元の文書を読み込ませて答えさせる」流れを見せたときでした。
自分の業務の景色と重なった瞬間に、道具は初めて「使うもの」になる。これは今回の検討で一番の学びです。
まとめ：環境が選択肢を決める
意思決定の流れを振り返るとこうなります。
- 本丸のリスクは「個人情報の入力事故」。整理すればクラウドも選択肢に残る
- ただし業務動線がイントラ中心 → クラウドAIは物理的に業務フローに乗らない
- 閉域クラウドはネットワーク精査が課題。比較対象として継続
- イントラ内に置けて、データが外に出ないローカルLLM＋RAGが最有力
- 刺さる用途はチャットではなくRAG。困りごと（マニュアル迷子・事務ミス・問い合わせ過多）に直結させる
「どのAIが優秀か」ではなく「自分の職場の動線のどこに置けるか」から逆算したのが、うちの結論でした。クラウドAIが使えない・使いにくい職場の方の参考になれば。
現在はベンダー相談を含む段階的な検討フェーズに入っています。続きはこのシリーズで書いていきます。
このシリーズの記事
- 規制業界のアナログ職場でローカルLLM＋RAG導入を提案した話【#1】
- クラウドAIを気軽に使えない職場でローカルLLM＋RAGを選んだ理由【#2】（本記事）
