序文｜なぜ、クラウドLLMの話をここではしないのか
生成AIの話題に触れるとき、
多くの人がまず思い浮かべるのは、
クラウド上で提供されるLLMだろう。
ChatGPT、Gemini、Claude。
性能は高く、導入も容易で、
すでに業務に使っている組織も少なくない。
それでも本稿では、
クラウドLLMをどう使うか、
どのサービスを選ぶべきか、
といった話は扱わない。
理由は単純だ。
クラウドLLMを使ってはいけないからではない。
ただし、
「考える相手」として組織に置く段階では、
最初に選ぶべき前提ではないからだ。
クラウドLLMは、
常に「外部」と接続されている。
入力内容がどこへ送られるのか。
ログは誰が保持するのか。
責任はどこで区切られるのか。
こうした問いは、
技術的には整理可能だ。
だが、組織の現場ではそうならない。
結果として、
利用は個人判断に委ねられ、
公式には「使っていないことにされる」。
本稿が扱うのは、
この状態をどうにかする話だ。
性能の優劣でも、
セキュリティ設計の是非でもない。
LLMに相談してもいい場所を、
組織の中に成立させること。
そのためには、
まず「外とつながっていない」状態を前提にしたほうが、
話が圧倒的に早い。
これは、
クラウドLLMを否定する議論ではない。
順序の問題である。
考える相手を置く。
その存在を認める。
その一歩を踏み出すには、
余計な説明を必要としない環境が、
もっとも現実的だった。
第1章｜多くの現場で、LLMは「黙って使われている」
生成AIは、もう特別な存在ではない。
少なくとも、この記事を読んでいる層にとってはそうだ。
APIキーを発行したことがあり、
ローカルLLMを立ち上げ、
チャットUIに何かを投げてみた経験もある。
「試したことがある」段階は、すでに終わっている。
それでも現場を見渡すと、奇妙な状態が続いている。
LLMは確実に使われている。
だが、それはあくまで個人の判断で、個人の責任のもとで行われている。
業務の裏側で、黙って使われている。
企画の整理。
文章の下書き。
論点の洗い出し。
仕様を読んだときの違和感の確認。
そうした「誰かに相談したいが、人に聞くほどではない」思考は、
すでにLLMに投げられている。
ただし、その事実は組織の中では存在しないものとして扱われている。
ここに問題の核心がある。
多くの組織において、
LLMは「導入されていない」のではない。
置き場所がないのだ。
公式に使っていい場所がなく、
相談していい窓口もなく、
責任の所在も定義されていない。
その結果、
LLMは「個人の裏技」として消費される。
これは技術の問題ではない。
精度の問題でもない。
モデル選定の失敗でもない。
単純に、
LLMを“考える相手”として置く場所が、
組織の設計に含まれていなかっただけだ。
人は、置き場所のない道具を公式には使えない。
どれほど便利でも、
どれほど賢くても。
この章で押さえておくべき事実は一つだけだ。
LLMは、すでに現場で使われている。
ただし、それは「存在しないもの」として扱われている。
たとえば、こんな場面だ。
ある担当者が、契約書の草案を前に立ち止まる。
致命的な欠陥があるわけではない。
だが、どこか落ち着かない。
論点が抜けていないか、前提に無理がないか、
誰かに一度、頭の中を整理してもらいたい。
上司に聞くほどではない。
法務に回す段階でもない。
チャットで同僚に投げるのも気が引ける。
そこで、その担当者は静かにLLMを開く。
文章を貼り付け、
「論点として抜けていそうな点を挙げてほしい」
とだけ打つ。
数分後、
返ってきた箇条書きを眺めながら、
自分の頭の中が整理されていく。
修正点が明確になり、
次に誰に渡すべきかも見えてくる。
この一連の行為は、
どの業務フローにも記録されない。
誰の成果にもならない。
報告もされない。
それでも、その仕事は確実に前に進んでいる。
この具体例は、
- 効率化を謳っていない
- 自動化していない
- 判断をAIに委ねていない
ただ、
考える相手として使われているだけ。
そして重要なのは、
こうした行為が「例外」ではなく、
すでに多くの現場で日常化しているという事実だ。
第2章｜「賢いAI」より先に必要だったもの
LLMを巡る議論は、どうしても「賢さ」に寄っていく。
どのモデルが優れているか。
どこまで正確に答えられるか。
人間の仕事をどこまで置き換えられるか。
だが、第1章で見た光景に照らすと、
その議論はどこか的外れに見えてくる。
現場でLLMが使われている理由は、
「最も賢いから」ではない。
「十分に賢いから」ですらない。
もっと単純だ。
考えを投げ返してくれる相手が、そこにいるから。
人は常に、答えを求めているわけではない。
多くの場合、求めているのは――
・自分の考えが破綻していないか
・論点が抜け落ちていないか
・どこに不安の正体があるのか
そうした「思考の整理」である。
ところが、LLMが公式な場に登場すると、
役割は一気に重くなる。
判断をさせるべきか。
責任は誰が持つのか。
間違えた場合、どう担保するのか。
その瞬間、
LLMは「考える相手」ではなく
「意思決定装置」や「業務システム」として扱われ始める。
そして、議論が止まる。
RAGが必要だ、という話になる。
専門知識を入れなければ使えない、という話になる。
精度が足りない、という話になる。
だが、現場で静かに使われているLLMは、
そのどれも満たしていないことが多い。
最新モデルでもない。
業務データも与えられていない。
ルールもガイドラインもない。
それでも、
「誰かに一度、考えを預けたい」という需要には、
十分に応えてしまう。
ここで、順序を整理する必要がある。
LLMが賢くなったから使われたのではない。
使われる余地があったから、
賢さが問題にならなかったのだ。
足りなかったのは、性能ではない。
高度な機能でもない。
置き場所である。
・ここで相談していい
・ここで考えを整理していい
・答えは出さなくていい
そう言える場所が、
組織の設計に含まれていなかった。
この「置き場所」の欠如が、
LLMを裏方に追いやり、
同時に、評価も管理もできない存在にしてきた。
第3章｜Difyという選択は、思想ではない
ここで一度、名前を出す必要がある。
Difyだ。
ただし、誤解は避けたい。
ここでDifyを持ち出すのは、
「優れているから」でも
「流行っているから」でもない。
ましてや、
生成AIプラットフォームとしての完成度を
論じたいわけでもない。
理由は、もっと単純だ。
これまで述べてきた「置き場所」を、
過不足なく満たしてしまった。
それだけである。
考えてみれば、要件は多くない。
・ブラウザで開ける
・認証ができる
・常駐できる
・ネットワークの内側で完結できる
これらは高度な要求ではない。
だが、不思議なほど同時には満たされない。
多くのLLM環境は、
「個人で触る」には十分だが、
「組織に置く」には何かが欠けている。
逆に、
業務システムとして整えようとすると、
途端に重くなる。
利用ルールが必要になる。
権限設計が必要になる。
成果物の定義が必要になる。
その時点で、
「考える相手としてのLLM」は姿を消す。
Difyは、そのどちらにも振り切らなかった。
業務アプリケーションでもなく、
個人ツールでもない。
ただ、置ける。
それ以上の説明が要らない状態を、
最初から用意していた。
ここで重要なのは、
この選択に思想が介在していない点だ。
高度な機能を持っているかどうかは、
この段階では関係がない。
拡張性も、将来性も、語る必要がない。
求められていたのは、
「LLMを置いても、誰も困らない状態」。
Difyは、
それを特別な設計思想としてではなく、
実装上の前提条件として満たしていた。
だから選ばれた。
それ以上でも、それ以下でもない。
第4章｜3分で置ける「LLM相談窓口」
ここで行うことは、難しくない。
設定を工夫する必要も、設計思想を練る必要もない。
前提条件は、すでに揃っている。
・LLMにアクセスできる環境がある（今回は LM Studio でローカルLLMを使用）
・Difyが起動している（今回は、TrueNAS以上にDifyのVMを構築済み）
それだけだ。
環境がまだ整っていない場合は、
Dify公式の無料Sandboxを使えばよい。
制約はあるが、雰囲気を掴むための土台としては十分。
ここでは、それ以上触れない。
チャットボットを作る
Difyで、新しいチャットボットを作成する。
高度なフローは使わない。
最もシンプルな形式で十分だ。
モデルを選択し、
チャット画面が表示される状態にする。
この時点で、
すでにLLMに「話しかけられる場所」は存在している。
一番かんたんなチャットボットの作り方
簡単にて順を解説しておこう。
Difyの「スタジオ」→「チャットボット」→「最初から作成」
「最初から作成」で「チャットボット」を選択→アプリの名前と説明→「作成する」ボタン
プレプロンプトを入れる
次に、プレプロンプトを設定する。
ここで重要なのは、
何をさせるかではなく、何をさせないかだ。
以下の文言を、そのまま貼り付ける。
判断・結論・指示・推奨を行ってはいけない。
論点整理、考慮点の列挙、抜け漏れ指摘のみを行うこと。
断定的表現を使用してはいけない。
理由の説明は不要だ。
この文言は、思想ではなく制約である。
モデルを指定する
対話モデルを指定する。
今回は”qwen/qwen3-vl-4b”を使用しているが、お好みで。
qwen/qwen3-vl-4b を使用する。
接続確認しておく
モデルの事前登録が間違っていなければ、
「デバッグとプレビュー」でLLMとの会話ができるはず。
公開する
最後に、「公開する」ボタンを押して「アプリを実行」。
組織のネットワーク内でアクセスできる状態にする。
http://192.168.xxx.xxx/chat/xxxxxxxxxxxxxxxxxxxこのＵＲＬを社内で共有すれば作業は終わりだ。
追加の設定は要らない。
利用ルールも決めない。
評価指標も作らない。
ここに置かれたものの正体
業務ツールではなく、「考えを整理する相手」として置かれていることが分かる。
ここで置かれたのは、
業務ツールではない。
意思決定装置でもない。
判断も結論も出さないが、
考えを整理する相手だけを引き受ける存在だ。
誰に向けたものでもない。
誰の成果物にもならない。
ただ、
「ここで相談してもいい」という場所が、
静かに生まれた。
第5章｜何も起きていない、という事実
この時点で、
目に見える成果は何もない。
利用者数は測っていない。
業務時間が短縮されたという報告もない。
生産性が向上したという数字も出てこない。
それでいい。
むしろ、
何も起きていないように見える状態こそが、正しい。
ここで置いたLLMは、
業務を自動化していない。
判断を肩代わりしていない。
誰かの仕事を奪ってもいない。
ただ、そこにある。
・考えがまとまらないとき
・論点に不安を覚えたとき
・人に聞くほどではないが、放置もできないとき
そうした瞬間に、
「ここに投げていい」と思える場所がある。
それだけだ。
この状態は、
導入事例としては極めて地味だ。
成果発表にも向かない。
予算獲得の材料にもなりにくい。
しかし、現場の感覚では違う。
LLMを“黙って使う”必要がなくなる。
個人の工夫や裏技として隠す理由がなくなる。
相談しても、誰にも咎められない。
それだけで、
思考の摩擦は確実に減る。
重要なのは、
ここで使い方を定義していないことだ。
「こう使うべきだ」と言われた瞬間、
LLMは業務ツールになる。
評価対象になり、
成果を求められる存在になる。
そうなれば、
再び“置き場所”は失われる。
何も起きていない。
だからこそ、
この場所は長く残る。
終章｜LLMにアクセスできるという価値
LLMの価値は、
賢さでは測れない。
どれほど高精度でも、
どれほど多機能でも、
触れることが許されていなければ、
それは存在しないのと同じだ。
本稿で行ったのは、
新しい技術の導入ではない。
高度な活用の提示でもない。
ただ、LLMにアクセスできる状態を、
組織の中に認めただけである。
判断しなくていい。
結論を出さなくていい。
成果を求めなくていい。
それでも、
考えを投げ返してくれる相手が、
公式に“そこにいる”。
この状態がもたらすものは、
派手ではない。
だが、確実だ。
人は、
相談していい場所があるとき、
思考を止めなくて済む。
黙って抱え込まなくて済む。
LLMは、その役割を
すでに果たせる段階にある。
足りなかったのは、
賢さではなかった。
アクセスの許可だった。
この一歩は、完成形ではない。
だが、出発点でもない。
すでに始まっていた現実を、
ただ認めただけだ。
それだけで、
LLMは「個人の裏技」から、
組織の中の風景へと変わる。
この記事が示したのは、
AIの未来ではない。
現在地である。
