この記事は「会社にローカルLLM＋RAGを導入する」進行中シリーズの第1回です。 承認前・進行中プロジェクトの現在地と全体像をまとめます。技術的な詳細よりも、規制業界・アナログ職場という制約の中でAI導入をどう進めているかの体験記です。
「AIを使いたいけど、会社の方針で禁止されている」
「マニュアル検索だけで1日が終わる」
「社内に提案しても、たぶん通らないだろうな」
もしあなたが、こんなモヤモヤを抱えながら毎日働いているなら、この記事は最後まで読んでもらえると嬉しいです。
私自身、まさに同じ環境で働いています。規制業界・クラウドAI全社禁止・アナログ文化の事務職場。それでも今回、社内提案制度を使って「ローカルLLM＋RAGの導入」を提案したところ、役員から「専門的に検討していけ」というGOサインが出ました。
ただし、本格導入のGOではありません。「まず勉強して、実際の業務にどう活用できるかイメージ化してから導入しよう」という段階的アプローチの指示。そして「ベンダーにも相談しろ」という指示も同時に出ました。
ここから先、勉強会・ベンダー相談・業務イメージ化・コンプラ整理・モデル選定と、長い道のりが始まります。結論ありきの成功体験記ではなく、進行中のリアルな記録として、このシリーズを書いていきます。
会社の風景｜たぶん、あなたの会社にも似ている
まず、自分が置かれている会社の状況を共有させてください。固有の業種は伏せますが、以下のような特徴があります。
- 規制業界・イントラ環境：外部クラウドサービスの業務利用は原則禁止
- クラウドAI禁止：ChatGPT・Claude・Geminiなど、すべて業務NG
- 事務作業の多さ：手続き・帳票・確認業務が大量にある
- マニュアル・規定の爆発：社内ドキュメントが膨大で、検索だけで時間が溶ける
- アナログ文化：紙・対面・電話が中心、変化への抵抗が強い
この5つのうち、3つ以上当てはまる会社で働いている方は、結構多いのではないでしょうか。
特に厳しいのは、マニュアル探索コストです。
何かを調べたいとき、どこに書いてあるかわかりません。フォルダ階層を辿り、ファイル名で見当をつけ、開いては「違った」を繰り返す。ベテラン社員に聞きに行けば早いけれど、その人たちもいずれ退職します。
プライベートではChatGPTに聞けば30秒で終わる質問に、会社では30分かかる。この温度差が日に日に苦しくなっていました。
「これ、AIで解決できる典型例じゃないか?」というのが、すべての出発点でした。
社内提案制度で動いた｜小さな個人動機が大きく育つ瞬間
会社には、社員からアイデアを募る制度があります。今回はそれを使って提案しました。
正直、自分は会社の中ではマイノリティです。新しい技術への興味があり、プライベートでもAIツールを日常的に使っています(このブログ自体もClaude Codeで作りました)。一方で、社内には「AI? それで何ができるの?」という温度の人が多いのが現実です。
それでも提案に動いた理由は、シンプルに自分の業務負担を減らしたいという個人的な動機でした。
ただ、提案書を書いているうちに気づきました。
私が困っていることは、たぶん周りの人もみんな困っている。マニュアル探索で時間を溶かしているのは自分だけじゃない。ベテランへの問い合わせが集中して迷惑をかけているのは、自分の隣の席でも同じ。
「会社のため」という大義名分から始めると、提案書はふわっとした言葉の羅列になりがちです。逆に「自分の困りごとから始めて、それが他の人にも共通する」という順番で書くと、リアルな課題感が伝わります。実際に困っている人間が、実際に困っているポイントを書く。これが一番強い説得力になります。
もし今、あなたが社内提案を考えているなら、まず自分の業務で何が一番つらいかから書き出してみるといいかもしれません。
提案した中身｜なぜローカルLLM＋RAGなのか
提案の中身はシンプルです。
ローカルLLM(社内サーバーで動かす生成AI)＋RAG(社内ドキュメントを検索して回答に使う仕組み)を導入し、まずはマニュアル検索の効率化から始める。
専門用語が出てきたので、軽く補足します。
- LLM(大規模言語モデル)：ChatGPTやClaudeの中身。文章を理解して文章で答える脳みそ
- ローカルLLM：その脳みそを、自社のサーバーの中に閉じ込めて使うバージョン。外にデータが出ない
- RAG(検索拡張生成)：質問に対して、まず社内ドキュメントを検索し、見つかった内容をもとに回答を作る仕組み。「うちの会社の固有情報」を答えられるようになる
この組み合わせを選んだ理由は、2つあります。
① ローカルLLM = クラウドAI禁止の制約を回避
外部にデータを送らない。社内ネットワーク内で完結する。これでセキュリティ・コンプラ部門の最初のハードルはクリアできます。
最近はオープンソースのLLM(Llama系・Qwen系など)が実用レベルに達しており、社内サーバーでも動かせる現実味が出てきました。GPUコストはかかりますが、業務利用するなら経費化できる範囲です。
② RAG = マニュアル検索地獄を解く、一番の解
「うちの会社の手続きを教えて」と聞いても、ChatGPTには答えられません。会社固有の情報を学習していないからです。
RAGは違います。社内マニュアルや規定をデータベースに入れておき、質問が来たらそこから関連箇所を引っ張ってきて、それを材料にして答えを作ります。例えるなら、社内の事情に詳しいベテラン社員に質問するイメージ。AIがベテランの代わりをしてくれます。
役員に説明したとき、ここが一番伝わった気がしました。「マニュアル探すの大変なんだよ」という、役員クラスでも実感しているリアルな課題に直結したからです。
提案書だけじゃ伝わらない｜自分のMacBookでデモを作った
提案書を書きながら、ずっと引っかかっていることがありました。
「ローカルLLM」「RAG」「ベクトル検索」…言葉だけ並べても、聞いた人は絶対にイメージできない。自分が会社の人だったとしても、これを文字で読んだだけでは「で、結局何ができるの?」となるはずです。
そこで、自分のMacBookに簡易的なデモ環境を作りました。
使ったのは以下の3つの組み合わせ:
- ollama(オラマ)：自分のPCでLLMを動かすツール。コマンド1行でモデルが立ち上がる
- Open WebUI：ollamaに被せて、ChatGPTみたいなブラウザ画面で操作できるようにするツール
- Qwen3.6-35B-A3B(IQ4量子化版)：Alibabaが2026年4月にリリースした最新のオープンソースMoEモデル。総パラメータ35B・アクティブ3Bという構造で、Macでも動く
役員説明の時に、このデモ画面を見せながら「これが社内サーバーで動くイメージです」と説明しました。
実機で動くものを見せると、反応がまったく違います。「へえ、こんなのが手元で動くんだ」「これが社内に置けるならイメージできる」という具体的な反応が返ってきました。文字より画面、画面より動くもの。提案の説得力は、見せられるものの段階で全然違います。
このデモ環境の詳細(セットアップ手順・モデル選定・動作感)は、シリーズの中で別途深掘り予定です。
役員説明の反応｜想定外の好感触と、想定内の段階的指示
役員説明の反応を率直に書きます。
想定以上に好感触だった部分
- RAGの説明で強い反応：「マニュアル検索が楽になる」「あれ毎回大変なんだ」と、役員自身からも具体的な共感が返ってきた
- デモを見ての反応：自分のMacで動くQwen3.6を見せたら「これが手元で動くのか」と驚き混じりの好感触
- 専門的に検討していけという前向きな指示。方向性はGO
- 規制業界でクラウドAIが使えない現実は役員も理解しており、ローカルで完結する設計も評価された
正直、もっと「で、それって本当に必要?」みたいな冷たい反応を覚悟していました。事前に想定問答も用意していましたが、ほとんど使わずに済みました。
想定内の慎重さを感じた部分
ただし、役員からの指示は「すぐ作れ」ではありませんでした。
「まず勉強して、実際の業務にどう活用できるかイメージ化してから導入しよう」という段階的アプローチ。そして「ベンダーにも相談しろ」という指示。
この指示の背景は明確です。会社全体のAI知識が、まだまだ立ち上がっていないのです。
自分も含めてです。プライベートでAIを触っている自分ですら、業務適用となると分かっていないことだらけ。ましてや、社内の他の人にとってはAIは未知の領域。未知の技術を、知識不足のまま本格導入するのは、コンプラ的にも運用的にもリスクが大きすぎます。
役員の判断は地味だけど正解だと思います。「方向性はOK、ただしまず知識をつけて、業務イメージを具体化して、プロにも相談しながら進めろ」。これは規制業界らしい慎重さであり、結果的に失敗確率を下げる進め方です。
ベンダー指示への自分なりの納得プロセス
正直に書きます。最初は「個人開発じゃダメか」というモヤッがありました。
Claude Codeで個人開発してきた身としては、「自分で作った方が早いし安いのに」という気持ちが出てきます。でも少し時間を置いて、考え直しました。
ベンダーは、技術提供だけでなく業界知見・コンプラ整理・他社事例の共有もしてくれる存在です。社内のAI知識が立ち上がっていない今だからこそ、プロのアドバイザリーは大きな価値を持ちます。
加えて、「個人で作った仕組みを、会社が業務システムとして使う」というのは責任分界の観点で本質的に難しい。誰がメンテナンスするのか、自分が辞めたらどうなるのか、トラブル発生時の責任は誰が取るのか。これらは個人開発では構造的に答えられない問題です。
個人の好みより、会社の判断軸に乗せていく方が結果的に近道だと判断しました。この感覚の切り替えは、社内AI導入を進めるうえで地味に大事なポイントだと思います。
現在地｜勉強・業務イメージ化・ベンダー相談フェーズ
ここまでが2026年5月時点の現在地です。
- ✅ 社内提案制度で提案 → 承認
- ✅ 役員説明 → 専門検討GO(条件付き：勉強→業務イメージ化→導入の段階的アプローチ)
- 🔄 勉強・業務イメージ化・ベンダー相談フェーズ ← 今ここ
- ⏳ PoC・実証実験
- ⏳ 本格導入
「今ここ」のフェーズで具体的にやることは、こんな感じです：
- 社内のAIリテラシーを底上げするための情報整理
- 「うちの会社のどの業務に、どう使えるか」の業務イメージ化
- ベンダー候補のリストアップと相談
- コンプラ部門・情報システム部門との早期すり合わせ
業務イメージの具体化については、このシリーズの中で別途書いていく予定です。
もしあなたも社内AI導入の途中なら、今どのフェーズにいますか? このシリーズと並走しながら、自分の進捗を重ねて読んでもらえると嬉しいです。
このシリーズで書いていく予定のこと
具体的なタイトルや順序、本数も決めていませんが、ざっくりこんなテーマを書いていきたいと思っています。
- なぜローカルLLM＋RAGなのか、その戦略の中身
- マニュアル検索地獄をRAGでどう解くか、業務イメージの具体化
- 会社に導入される予定の機材の話
- ローカルLLMモデル選定の論点(ollama × Qwen3.6 のデモ環境の詳細)
- 規制業界のAIコンプライアンス論点
- ベンダー選定と社内承認プロセス
- 導入後の業務変化や、コスト・ROIの振り返り
- うまくいったこと、いかなかったこと
進行に応じて、書く順番もテーマも変わると思います。書きながら考えていくスタイルで進めます。
念のため｜シリーズが途中で止まったら察してください
正直に書いておくと、このシリーズは会社の判断次第で、いつ止まってもおかしくないプロジェクトです。
否認・方向転換・撤退・体制変更・自分の異動など、可能性はいくらでもあります。それに加えて、規制業界の特性上、書ける範囲には限界があります。プロジェクトが進むほど、書けないことが増える可能性もあります。
もしこのシリーズが途中で更新が止まったら、「ああ、何かあったんだな」と察してもらえると助かります。書けない時は書けない、書けることは書く、そのスタンスでやっていきます。
それも含めて、規制業界でAI導入を進めるリアルだと思っています。
なぜこの体験を書くのか｜あなたへ
最後に、なぜこのシリーズを書こうと思ったかを書かせてください。
① 同じ立場の人へのナレッジになると思ったから
規制業界でAI導入に悩んでいる人。社内提案を考えている人。ベンダー選定の前段で何を整理しておくべきか知りたい人。
私自身、こういう体験記事を探しても「成功した会社の華々しい事例」か「技術記事」しか見つからず、間の地味な進行プロセスを書いたものが少ないと感じていました。失敗も否認も方向転換も含めて、リアルな進行を残しておく価値があると思っています。
② 書くことが、自分の思考整理になるから
書くことで、自分の頭の中が整理されます。役員への次の説明資料も、ベンダー選定の判断軸も、書きながら明確になっていきます。ブログを書く時間が、結果的に仕事の生産性を上げるという、ちょっと変な構造です。
③ ブログと仕事の交差点を作りたかったから
このブログは「節約・ポイ活・投資・AI」の体験を書く場ですが、AIカテゴリの軸として、個人開発の体験(Claude Code・バイブコーディング)と並んで、仕事でのAI導入体験を入れたいと考えました。両方を持っている発信者は意外と少ないはずです。
---
進行中の体験記なので、結論ありきではありません。途中の試行錯誤・回り道・否認・方向転換も含めて、ありのままを書いていきます。
もしあなたも、似た環境でAI導入を考えているなら、このシリーズを「ひとりじゃない」と思える材料にしてもらえたら嬉しいです。SNSで「うちも同じです」「うちはこうやりました」と教えてもらえれば、それも次の記事のヒントにします。
次回は 「なぜローカルLLM＋RAGなのか・クラウドAI禁止環境のAI戦略」 というテーマで書く予定です。
---
