ローカルLLMで、「聞かれたら答える」受付を作ってみた。Local Front Deskという試み。
2026年7月12日
ローカルLLMはクラウドAIの代替ではなく、社内の受付・仕分け・記憶装置として使うと価値が出る。Local Front Deskを試作して見えてきた、業務で使うための考え方です。
ローカルLLMは、ChatGPTやClaudeのようなクラウドAIの「無料の代替」として語られることがあります。しかし、純粋な能力を比べれば、大規模なクラウドAIには及びません。
大規模なクラウドAIと、同じことをさせない。
そこで私たちは、クラウドAIと同じことをさせるのではなく、ローカルLLMの役割を限定することにしました。探す、選ぶ、整理する、そして必要なときは人へ引き継ぐ。用途を実務に必要な範囲へ絞ることで、導入しやすく、すぐ業務に役立ち、長く使えるシステムを作れないか。そこから受付システム「Local Front Desk」の開発が始まりました。
答えを自由に作らせるのではなく、決まった情報の中から正しいものを選び、人が確認できる形で返す。たとえば、次のような仕事です。
- 過去の類似案件から、参考になりそうな事例を探す
- 売上台帳から、条件に合う集計を出す
- 用意してある資料の中から、質問に合うものを送る
これらは、AIに「賢い受け答え」をしてもらう必要はありません。むしろ大事なのは、AIが変なことをでっち上げず、分からない時は正直に「分かりません、人が確認します」と言えることです。
クラウドAIでも同じことはできますが、社外に出しにくい情報、顧客情報、社内資料、取引データを扱う場合、ローカルで完結できることには実務的な価値があります。
3つの「窓口」を作った。
この考え方に沿って、実際に3つの仕組みを作りました。まとめて「Local Front Desk」と呼んでいます。
Answer 社内資料・事例検索
Keeper 営業資料・台帳検索
Guide 公開窓口・資料案内
Local Front Desk Answer
社内資料・過去の類似案件を検索し、根拠となる候補を人が確認できる形で提示します。社内メンバーは専用Web UIから利用でき、社外からのメール問い合わせを受けて結果をメールで返す運用にも対応します。質問者が検索結果を評価し、資料や検索条件の見直しにつなげる機能もあります。
現在の公開デモでは労働判例の要約データを使っていますが、本番導入では社内規程やマニュアル、過去対応記録に置き換えて運用できます。公開デモでは、専用Web UIと評価機能の一部を省略しています。
Local Front Desk Keeper
売上台帳のような構造化データに対して、自然な文章で質問できるようにしたものです。「先月の売上は？」「A型の販売件数は？」といった質問を、裏側でSQLの正確な集計に変換します。社内Web UIから利用できるほか、社外からのメール問い合わせを受け、検索・集計結果をメールで返す運用にも対応します。顧客名や担当者名は利用者の権限に応じて扱い、個人評価など判断が必要な質問は人へ回します。
Local Front Desk Guide
あらかじめ用意した資料の中から、質問に近い候補を探し、送る・聞き返す・人へ回す、の三方向に分ける仕組みです。専用Web UIはなく、Webフォームまたはメールで問い合わせを受け、資料や案内をメールで返します。原則として確認済みの資料を使い、必要に応じて、その資料を根拠に文章で回答する構成にもできます。
特に相性が良いと感じているのが、Webサイトの問い合わせ窓口としての使い方です。メールのやり取りをそのまま流用できるので、サイトにフォームを置き、質問を受け取ったらメールで資料を返す、という導線をすぐに作れます。
これは一見、チャットボットに似ています。ただ、決定的に違う点が3つあります。一つは入力の自由さです。多くのチャットボットは、あらかじめ用意された分類メニューをお客様自身に辿ってもらう形式ですが、Guideはお客様が自分の言葉で自由に書けば、意味の近さで該当する資料に結びつけます。
もう一つは保守の軽さです。チャットボットは会話シナリオの設計・分岐の管理という継続的な手間が発生しがちですが、Guideの保守は「資料フォルダに1件足す・差し替える」だけで済み、会話フローの再設計は発生しません。そして、導入・運用コストも大幅に軽くなります。
いずれも共通しているのは、AIに自由な回答生成をさせることを基本にしない点です。AIの主な役目は、質問を解釈し、候補を探すこと。文章で回答する場合も、確認済みの資料を根拠にする範囲へ限定し、判断が必要な内容は人へ引き継ぎます。
身近な機材から始められる。
今回のデモは、M1 Pro搭載MacBook Pro・ユニファイドメモリ32GBの環境で動作させています。ローカルLLMというと高価な専用サーバーを想像しがちですが、用途とモデルを絞れば、既存のMacやVRAM 12GB級のGPUを搭載したWindows PCでも、小規模な業務システムから検討できます。
複数のモデルを扱う場合や、長い資料、利用人数の増加まで考える場合は、VRAM 16GB以上を推奨します。最初から大規模な設備を導入するのではなく、まず1つの業務で効果を確かめ、必要に応じて機材や機能を拡張する考え方です。
必要なメモリやGPU性能は、使用するモデル、同時利用人数、対象データ、コンテキスト長によって変わります。VRAM 12GB級は、小規模導入を検討する際の現実的な出発点の一つです。
この仕組みの強み。
- 小さな投資で導入できる。 Local Front Deskは、クラウド型AIの月額・従量利用料を基本的に必要とせず、対応するPCとメールアカウントがあれば動かせます。
- 業務に役立つ機能に絞ってある。 集計・検索・資料送付といった、実務でそのまま使える単位で作ってあります。
- 機能が限られているからこそ、長く使える。 クラウドAIがどれだけ賢くなっても、「自社の資料から正しいものを選ぶ」という仕事の価値は変わりません。
実装で分かった、LLMに任せる範囲。
今回の試作では、ローカルLLMが自由に答えを作文するのではなく、質問の分類、資料との照合、候補の選別、そして人間に回すべきかどうかの判断に使われています。特にAnswerは、ローカル資料から根拠を探し、人が判断しやすい形に並べる受付として見る方が実態に近いです。質問者の評価も自動学習には使わず、人が資料や検索条件を改善するための記録として残します。
Keeperも、売上や件数そのものをLLMに数えさせているわけではありません。LLMは質問をフィルタ条件に変換し、集計はSQLiteで行います。ここを分けていることが、業務用途での安心材料になります。
実用段階のプロトタイプができました。
ここで紹介した仕組みは、すでに実用段階のプロトタイプとして動いています。現在の公開デモには架空設定やデモ用データも含まれますが、実際のお客様の資料やデータに合わせて仕上げていく前提で、導入の現実感が見えるところまで組み上げています。
実際に動かしてみると、設計段階では気づけなかった不具合や改善点もいくつか見つかりました。現在ご相談いただくお客様とは、より高度な製品化を一緒に進める開発パートナーとして、調整や検証も含めて伴走したいと考えています。
© 2026～ GRIP