ローカルLLMにした理由は「速さ」より「主導権」
MacでSarashinaを動かしてみて、最初に強く感じたのは「速い」よりも、主導権を自分（自社）で握れるという価値でした。
クラウドLLMは便利です。けれど、業務で本当に使おうとすると、
- どこまで入力していいのか（情報の線引き）
- 社内ルールや運用の責任は誰が持つのか
- 結局、現場が“怖くて使えない”にならないか
この3つがずっと残ります。
ローカルLLMは、この「怖さ」をゼロにする魔法ではないけど、少なくとも
“自分たちで決められる範囲”が増える。ここが大きいです。
生成AIは「賢さ」より「運用が勝つ」
精度を求めると、モデルの性能に目がいきがちです。
でも実務で大事なのは、賢いかどうか以前に
- どの情報を根拠にするか
- どんな口調・形式で返すか
- 不明点は質問に戻せるか
- 誤答した時に直せる仕組みがあるか
みたいな運用の設計でした。
つまり、生成AIは「モデルの勝負」ではなくて、
運用（型・ルール・データ整備）の勝負になりやすい。
だからこそ、最初の一歩として「ローカルで小さく始める」は理にかなっていました。
RAGは“賢くする”技術じゃなくて、“ブレさせない”技術
自分の中でRAGは、精度を上げるというより
回答の拠り所を固定する装置です。
LLMは、うまく話せる代わりに、根拠がない話もそれっぽく作れます。
それを業務で使うと、「便利だけど信用できない」になりやすい。
そこでRAGを入れると、目指せる状態が変わります。
- 知らないなら「資料にない」と言える
- 答えるなら「資料のこの部分」を根拠にできる
- 根拠が間違ってたら、直すのはモデルではなく“資料”
つまり、RAGはAIの知能を上げるより、
組織の知識を“参照できる形”に整えるための仕組みだと思っています。
docs整理は「AIのため」じゃなく「人のため」
RAGの下準備としてdocsを集め始めて気づいたのは、
これはAIのためというより、人間のための整理だということです。
社内の情報って、多くの場合
- どこにあるか分からない
- 最新がどれか分からない
- 誰に聞けばいいか分からない
この「分からない」がボトルネックになります。
AIを入れることは、実はこの問題の答えではなくて、
この問題を“見える化”する強烈なきっかけになる。
「AIに読ませたい」と思った瞬間から、
資料の散らばりや古さが一気に顕在化するんですよね。
「社内AI」はシステムより“文化”が先
社内AIを作る、というとシステムを思い浮かべますが、
実際には文化（運用）が先に必要になります。
- 入れていい情報／ダメな情報の線引き
- それを誰が決めて、どう周知するか
- 使い方のテンプレ（例：質問の型、出力の型）
- 間違いが出た時にどう直し、どう共有するか
ここがないと、AIは“導入しただけの置物”になります。
逆に言えば、ローカルで小さく始めるのは、
文化を作るための実験としてちょうどいい。
今の自分の結論：小さく作って、使い方を固める
今の段階での結論は、これです。
- まずは用途を絞って「これなら任せられる」を作る
- docsを整えて「根拠がある回答」を増やす
- ルールとテンプレで「安心して使える形」にする
モデルの性能は大事だけど、業務で使えるかどうかは、
それ以上に運用の設計で決まる。
次回予告：運用テンプレ（プロンプト）を公開する
次回は、思想を実装に落とす回として、
- 根拠がない時は「ない」と返すテンプレ
- 回答形式（結論→根拠→確認質問）のテンプレ
- docsの書き方テンプレ（冒頭要点・例外・更新日など）
このあたりを実例つきでまとめます。
必要なら、この思想パートに合わせて「締めの一文」だけ、雰囲気別に3案出します。どんなトーンにします？
（例：淡々／熱量高め／やさしい）