ローカルLLMは、クラウドのAPIを通さず、手元のPCや社内のサーバーで大規模言語モデルを動かす使い方です。推論を自分の管理する機器の中で終えられるため、電子カルテや行内規程のように外へ送れないデータを扱う現場で導入が進んでいます。この記事では、国内の病院・自治体・銀行が公表した導入事例を構成ごとに整理し、個人がPC1台で再現できる使い方、OllamaとLM Studioでの始め方、2026年10月時点の日本語モデルの選び方と必要スペックまでをまとめます。
まとめ:ローカルLLMの活用事例と始め方の要点
- 本記事で取り上げた国内5事例は、いずれも外に出せない文書の要約・検索・照会が対象。電子カルテからの看護サマリー作成(作成時間54.2%減)、自治体の対応記録の要約、銀行の規程照会が公表されている。
- 個人の使い道はメモ・下書き・コードの3つが中心。Obsidianのノート検索、議事メモの要約、ローカルで完結するコーディング支援が代表例。
- 始めるならOllamaかLM Studio。どちらもOpenAI互換のAPIを持ち、既存のツールは接続先の変更で使える(対応しているのはOpenAI APIの一部なので、使う機能が対応しているかは確認する)。LM Studioは2025年7月から職場での利用も無料になった。
- 日本語ならモデル選びが成否を分ける。8B前後のモデルは量子化後5GB前後でメモリ16GBのPCで動くが、精度は実際の業務データでクラウドのモデルと比べて判断し、要約・分類・下書きのように人が確認する前提の用途から始める。
ローカルLLMとクラウドLLMの違い:データの置き場所と費用の構造
違いの中心はデータの置き場所です。クラウドLLMは入力した文章を提供元のサーバーへ送って処理しますが、ローカルLLMは推論まで自分の管理する機器の中で終わります。費用も、クラウドのAPIがトークン量に応じた従量課金(チャットサービスは月額制が中心)なのに対し、ローカルはGPUやPCの購入費と電気代が中心になります。その代わり、モデルの更新・障害対応・精度の検証を自分で持つことになります。
定義・メリットと弱点・構築手順を詳しく知りたい場合はローカルLLMとは?クラウド型との違い・必要スペック・Ollamaでの構築手順を解説で整理しています。この記事では「実際に何に使われているか」に絞って進めます。
国内の業務導入事例:医療・自治体・金融の5件
国内で公表されたローカルLLM(オンプレミス・閉域網を含む)の事例は、どれも個人情報や行内情報を外部に送れない業務が対象です。本番運用・実証・開発と段階が異なる点に注意して読んでください。
| 組織 | 発表日 | 用途 | 構成 | モデル・製品 |
|---|---|---|---|---|
| 織田病院・オプティム・シーエスアイ | 2024-03-29 | 看護サマリーの自動生成(作成時間54.2%減) | 院内オンプレミス・外部接続なし | OPTiM AI |
| 三重大学病院・NTT西日本 | 2024-11-01 | 退院サマリの下書き | 院内ネットワーク内 | tsuzumi(70億パラメータ) |
| 山口県・NTT西日本 | 2024-09-17 | 対応記録の要約・校正、マニュアル検索 | 庁内オンプレミスの小型GPUサーバー | tsuzumi |
| あおぞら銀行・neoAI | 2025-04-17 | 事務規定管理業務の問い合わせ応答 | 行内オンプレミス | オープンソースLLMを継続事前学習 |
| トマト銀行・Ippu Senkin | 2026-05-13 | 規程の照会(本部の全役職員) | 完全オンプレミス・外部接続なし | Local-Chat AI |
織田病院とオプティム:電子カルテと連携して看護サマリーを自動生成
佐賀県鹿島市の織田病院、オプティム、シーエスアイの3者は2024年3月29日、外部ネットワークへの接続を必要としない「OPTiM AI」を臨床現場にオンプレミスで試験的に導入したとオプティムのプレスリリースで発表しました。電子カルテと連携してオンプレミスに導入したLLMとしては国内初(同社調べ)としています。最初の対象は「入退院時看護サマリー」の要約文の自動生成でした。同年11月7日の続報では、2024年4月から10月の運用で退院時看護サマリー1件の作成時間が平均16.31分から、初回利用で10.90分、3回目以降で7.47分(54.2%減)になったと公表し、「OPTiM AI ホスピタル」として2025年1月から販売するとしています。使い慣れるほど短くなっている点は、導入初期の数字だけで効果を判断しないほうがよいことを示しています。
三重大学病院とNTT西日本:7Bのtsuzumiを院内網に置いて退院サマリを下書き
三重大学医学部附属病院とNTT西日本は2024年11月1日、NTT版LLM「tsuzumi」で電子カルテを要約し、退院サマリの作成を効率化できるかを検証する実証実験を始めると発表しました(NTT西日本のニュースリリース)。退院サマリは同院で年間約1.5万件作られ、1件に30分程度かかるケースもある業務です。70億パラメータのtsuzumiを院内のネットワーク内に構築し、患者の個人情報を外部へ送らずに要約します。医師がAIの下書きを確認・修正する流れにして、出力の質を落とさずに作成時間を短くすることを狙っています。実証期間は2025年3月31日までの予定と発表されていました。
山口県とNTT西日本:庁内の小型GPUサーバーで機微データの記録を要約
山口県は2024年9月17日、NTT西日本とtsuzumiの実証実験を始めると発表しました。同県はクラウド上の独自環境で生成AIを全庁運用していますが、機微なデータを扱う業務向けに、オンプレミスの小型GPUサーバーでtsuzumiを動かし、対応記録の要約・校正や業務マニュアルの検索・要約を対象にしています。クラウドの生成AIと、機微データ用のローカルLLMを業務で使い分ける構成です。
あおぞら銀行とneoAI:行内データの追加学習による事務規定への回答精度向上
あおぞら銀行とneoAIは2024年から、行内のオンプレミス環境にLLMを使ったAI基盤を作るプロジェクトを進めています。2025年4月17日のneoAIの発表では、オープンソースLLMに行内データで継続事前学習を行った「あおぞらLLM」(仮称)が、事務規定管理業務を想定した内部ベンチマークで応答精度を従来比130%に高めたとしています。行内の知識を継続事前学習でモデルに持たせ、そのうえでRAG(検索拡張生成)を組み合わせる構成で、発表では法人業務にも継続事前学習とRAGで効率化を広げるとしています。
トマト銀行とIppu Senkin:本部の全役職員を対象にした規程照会チャットの運用開始
岡山県のトマト銀行は2026年5月13日、外部ネットワークから遮断した完全オンプレミス環境で動く「Local-Chat AI」の運用を、本部に勤務する全役職員を対象に始めました(Ippu Senkinの発表)。各種規程をAIに参照させ、行内のルールに沿った回答を返す用途で、帳票・稟議書・スキャン文書などの画像にも対応します。ハードウェアの調達からシステム構築・ソフトウェア実装まではIppu Senkinが支援し、トマト銀行は本部での運用状況を踏まえて全店舗へ順次展開する予定です。実証実験ではなく、本部の日常業務で運用を始めた段階の事例です。
5件に共通する導入の型
5件に共通するのは、対象が要約・下書き・規程への回答といった文書業務である点です。三重大学病院の発表には「生成した文章を医師が確認・修正する」と人の確認工程が明記されています。モデルは、三重大学病院と山口県がどちらもtsuzumi(三重大の発表では70億パラメータ)です。自社で検討するときも、機微データを扱う定型文書の要約を1つ選び、人が確認・修正する工程を組み込んでから始めるのが、公表事例と同じ進め方です。
業務での使い方:社内文書検索・コード生成・問い合わせ対応
社内文書検索(RAG):規程・議事録・マニュアルの社内完結型検索
社内の規程やマニュアルに沿って答えさせたいときに使うのが、社内文書をベクトル化して検索し、該当箇所をもとにLLMが回答するRAGです。ただし、推論モデルをローカルにしただけでは外部送信は止まりません。埋め込みモデル・文書の抽出・検索の処理まで社内の機器で動かし、外部のAPIを参照していないことを確かめ、ネットワーク側でも外部への通信を制限して、文書を社内にとどめる構成にします(Open WebUIのオフライン運用の解説も同じ注意を書いています)。小さく試すなら、OllamaとOpen WebUIの組み合わせでファイルを読み込ませる構成が早く、手順はOllamaでファイルをアップロード・読み込む方法|公式アプリとOpen WebUIのRAG設定で解説しています。部署で共有するチャット画面が必要ならLibreChatとは?Docker構築手順と社内AIチャット基盤の採用判断も候補です。検索精度が業務の要件に届かない場合は、文書の分割方法や検索の設計から見直すことになり、社内に知見がなければRAG構築支援のような外部の支援を使う選択肢もあります。
コード生成・開発支援:ソースコードの外部送信を避ける構成
契約上ソースコードを外部サービスへ送れない開発現場では、コーディングエージェントの接続先をローカルLLMに切り替える使い方があります。OllamaはCodexやCopilot CLIなどの接続先になれるため、ツールはそのままでモデルだけを手元に置けます。設定例はOllamaでCodexをローカルLLM実行する方法にまとめています。ただし、8B級のモデルに複数ファイルにまたがる修正や長い手順を任せると、途中で指示を外れやすくなります。補完・説明・テストの雛形づくりなど、範囲の狭い作業から使ってください。
問い合わせ対応:返信の下書き生成と担当者による確認
個人情報を含む問い合わせメールは、過去の回答例と社内FAQを検索して渡し、Qwen3 8Bなどのローカルモデルに返信の下書きを作らせ、担当者が確認して送る運用にします。確認するのは、金額・期限・手続き名がFAQの原文と一致しているか、根拠のFAQが最新版か、宛名と顧客情報に取り違えがないかです。自動送信まで任せると、誤った案内がそのまま顧客に届きます。
個人での活用事例:メモ・下書き・学習
メモ・ナレッジ管理:Obsidianノートのローカル検索・要約
個人で効果が出やすいのは、日記や仕事のメモなど他人に見せたくない文章の検索と要約です。Obsidianでは次の2つのプラグインでローカルLLMとつなげられます。
- Smart Connections:内蔵のローカル埋め込みモデルでVault全体を自動で索引し、いま書いているノートと意味の近いノートを一覧に出す。APIキーは不要。チャット機能(クラウド・ローカルのモデル接続)はPro版のSmart Chat Proへ移った。
- Copilot for Obsidian:設定の「BYOK → Add a provider」でOllamaまたはLM Studioを選ぶと、接続先として
http://localhost:11434/v1(Ollama)やhttp://localhost:1234/v1(LM Studio)が入る。ノートを文脈にしたチャットや要約がローカルで動く。
Copilotは2026年10月時点のv4でClaude CodeやCodexもVault内で動かせるようになりましたが、それらを使うとノートはそれぞれのサービスへ送られます。ローカルで完結させたいなら、モデルの接続先をOllamaかLM Studioにするだけでなく、意味検索やPDF処理を担うMiyoの接続先、スキルやツールが通信する先もローカルのものに限り、クラウドのエージェントやCopilotがホストする機能は使わないでください(設定ドキュメントのとおり、データの扱いは接続先の提供元に従います)。ノートを個人のナレッジベースとして組み立てる手順はPersonal Knowledge Base(PKB)とは?パーソナルナレッジベースの定義とローカルLLMで組む手順で扱っています。
下書き・要約・翻訳:議事メモからの期限・担当者の抽出
会議メモから期限と担当者だけを抜き出す、長いメールを3行に要約する、英語のドキュメントを下訳する、といった作業は、8B級のモデル(たとえばQwen3 8B)でまず試す候補になります。数件の実データで出力を原文と照らし、抜けや誤りの割合を見てから業務に使ってください。後述のコードのように、システムプロンプトで出力の形を決めておくと結果が安定します。モデルが学習済みの知識だけで答える場合は学習時点までの情報しか持たないため、最新の出来事や正確な数値を答えさせる用途には向きません。入力した資料から数値を抜き出す場合も、原文との照合は必要です。
学習・検証:プロンプトとRAG設定の反復比較
プロンプトを何十通りも試す、RAGの分割方法を変えて比べる、といった反復はクラウドAPIだと従量課金が積み上がります。ローカルなら機器を用意したあとはトークン単位の課金が無く、 qwen3:8b(5.2GB)を事前に取得しておけば、ネットワークが無い移動中でも同じ条件で比較を続けられます。
ローカルLLMの始め方:OllamaとLM Studioの起動とAPI接続
実行ツールの選び方:OllamaとLM Studioの違い
| 項目 | Ollama | LM Studio |
|---|---|---|
| 最新版(2026-10-26時点) | v0.40.11(2026-10-24) | 0.4.26 |
| 操作の中心 | コマンドライン+デスクトップアプリ | GUI(モデル検索・ダウンロード・チャット) |
| APIの既定ポート | 11434 | 1234 |
| OpenAI互換API | あり(/v1) | あり(/v1) |
| 職場での利用 | MITライセンスのOSS | 2025年7月8日から無料 |
ほかのアプリやスクリプトから呼ぶ前提ならOllama、まず画面上でモデルを見比べたいならLM Studioが向きます。LM Studioは2025年7月8日の発表で、家庭でも職場でも無料で使えるようになりました。LM Studioのローカルサーバーは、Developerタブのスイッチか、CLIの lms server start --port 1234 で起動します(ポートを省略すると前回使ったポートで起動します)。既定では127.0.0.1だけで待ち受け、--bind 0.0.0.0 を付けるとLANに公開されるため、その場合は認証を有効にしてください(公式ドキュメント)。
Ollamaでのモデル取得とOpenAI互換APIからの呼び出し
Ollamaをインストールしたら、モデルを取得して対話で日本語の質を確かめます。
ollama pull qwen3:8b
ollama run qwen3:8b "ローカルLLMの利点を2文で説明してください"
Ollamaは既定で 127.0.0.1:11434 で待ち受け、/v1 配下にOpenAI互換のAPIを持ちます。Ollamaを起動した状態で pip install openai を実行し、OpenAIの公式Pythonライブラリの接続先を書き換えれば、既存のコードをほぼそのまま使えます(APIキーは必須の引数ですが、Ollamaは値を無視します)。
from openai import OpenAI
# Ollama の OpenAI 互換エンドポイント(APIキーは任意の文字列でよい)
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
memo = "4月の定例:見積の再提出は5月10日まで。担当は佐藤。次回は5月15日。"
res = client.chat.completions.create(
model="qwen3:8b",
messages=[
{"role": "system", "content": "議事メモから期限と担当者だけを箇条書きで抜き出してください。"},
{"role": "user", "content": memo},
],
)
print(res.choices[0].message.content)
このコードは、Python 3.9.6・openai 2.48.0・Ollama 0.40.5の組み合わせで、OpenAI互換API経由で応答が返ることを確認しています。確認したのは接続と呼び出しの手順だけで、確認時はポート番号(11501)とモデル(qwen3:0.6b)を検証環境に合わせて変え、ユーザーメッセージの末尾に思考を省く指定の /no_think を足しています。出力の正確さは評価していません。LM Studioを使う場合は base_url を http://localhost:1234/v1 に、model をLM Studioで読み込んだモデルIDに変えます。
日本語モデルの選び方(2026年10月時点)
まず8B前後のモデルを試し、足りなければ12B〜20B級に上げる順が無難です。Ollamaの公式ライブラリとHugging Faceで確認できる主な候補は次のとおりです。
| モデル | 公開元 | ライセンス | 取得方法 | 配布ファイルのサイズ |
|---|---|---|---|---|
| Qwen3 8B | Alibaba(Qwen) | Apache 2.0 | ollama pull qwen3:8b | 5.2GB(Q4_K_M) |
| Gemma 4 12B | Apache 2.0 | ollama pull gemma4:12b | 8.0GB(Q4_K_M・llama.cpp版) | |
| gpt-oss-20b | OpenAI | Apache 2.0 | ollama pull gpt-oss:20b | 14GB(MXFP4) |
| LLM-jp-4.1 8B thinking | LLM-jp(国立情報学研究所) | Apache 2.0 | Hugging FaceのGGUF | 5.5GB(Q4_K_M) |
| Llama-3-ELYZA-JP-8B | ELYZA | Meta Llama 3 Community License | Hugging FaceのGGUF | 4.9GB(Q4_K_M) |
ツール呼び出しやコード支援まで含めるならQwen3やgpt-oss-20b、国産の学習データで日本語の文章を書かせたいならLLM-jp-4.1、2024年から使われている日本語モデルを手早く試すならLlama-3-ELYZA-JP-8B、という分け方になります。LLM-jp-4.1はOllamaの公式ライブラリに登録されていないため、Hugging FaceのGGUFをllama.cppで動かします。公式cookbookによればLLM-jp-4.1用のパーサーはllama.cpp v0.6.0で本家に入ったため、それ以降の版を使います(モデルカードに残る「専用フォークが必要」の注記はそれ以前の記述です)。系統ごとの違いと手順はLLM-jp-4とは?8B・32B-A3B・33Bと4.1の違い・性能・使い方を参照してください。サイズ表記の「Q4_K_M」「MXFP4」は量子化の方式で、仕組みはGGUFとは?量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説で説明しています。
ELYZAのモデル:チャットテンプレートとライセンスの確認
Llama-3-ELYZA-JP-8B(2024年6月公開)は、Ollamaなら ollama run hf.co/elyza/Llama-3-ELYZA-JP-8B-GGUF:Q4_K_M で直接取得できます。この方法だと、OllamaがGGUF内のLlama 3形式ではなくChatML形式のテンプレートを割り当てることがあるため、取得後に ollama show --modelfile hf.co/elyza/Llama-3-ELYZA-JP-8B-GGUF:Q4_K_M でTEMPLATEを確かめ、違っていればModelfileでLlama 3形式のTEMPLATEと停止トークンを指定してください。
ライセンスはモデルカードのとおりMeta Llama 3 Community Licenseです。商用利用はできますが、Meta Llama 3の公開日時点で自社と関連会社のサービスの前暦月の月間アクティブユーザーが7億人を超えていた場合はMetaの許諾が必要で、モデルや出力を他のLLM(Llama 3とその派生物を除く)の改善に使うことも禁じられています。ELYZAは2026年10月2日に、LLM-jp-4をもとにした推論モデル「ELYZA-Thinking-1.0-llm-jp-4」(32B-A3Bと33B、Apache 2.0)も公開しました。8Bの性能・ダウンロード・Ollamaでの設定はLlama-3-ELYZA-JP-8Bとは|性能・必要スペックとGGUFのダウンロード、Ollamaでの使い方で詳しく扱っています。
必要スペックの目安:モデルサイズ・文脈長・同時利用数
必要なメモリは、量子化後のモデルファイルのサイズに、会話の文脈を保持するKVキャッシュと推論ランタイムが計算に使う作業領域を足した量で、PCではさらにOSやほかのアプリの使用分が加わります。文脈用のメモリは、文脈を長く取るほど、同時に処理するリクエストが多いほど増えます(OllamaのFAQでは、必要なメモリは並列数×文脈長に比例して増えるとしています)。次の表は1人で使う場合の目安です。
| 用途 | モデル規模 | 量子化後の目安 | メモリの目安 |
|---|---|---|---|
| 個人の要約・下書き | 7〜8B | 5GB前後 | 16GB |
| コード支援・社内文書検索の試行 | 12〜20B | 8〜14GB | 24〜32GB |
| 30B級モデルの単独実行 | 30B級 | 19〜20GB | VRAM 24GB以上のGPU |
GPUが無いPCでもCPUとメモリだけで動きますが、生成速度はCPUの性能・モデルの規模・量子化の方式で大きく変わります。CPUだけで12Bモデルを動かしたときの読み込み時間と生成速度はGemma 4 12BでローカルAIを動かす|必要スペック・CPU実測・Ollama API実装・26B A4Bとの違いに載せています。gpt-oss-20bはモデルカードで「16GBのメモリに収まる」とされていますが、ファイルだけで14GBあるため、OSやほかのアプリと同居させるならPC全体で24GB以上が現実的です。
導入前に知っておく注意点と、ローカルLLMを選ぶべきでない場面
導入前に確認しておきたいのは、誤答への備え、ネットワークへの公開範囲、ライセンス、更新の担当の4点です。
- ローカルでも誤答は減らない。実行場所を変えて変わるのはデータの置き場所で、誤答(ハルシネーション)の起きやすさはモデルの規模・学習データ・与える文脈で決まる。人が確認する工程を必ず残す。
- LANに公開すると、同じネットワークの他の端末から接続できるようになる。Ollamaは
OLLAMA_HOST=0.0.0.0、LM Studioは--bind 0.0.0.0で公開される。Ollama本体のAPIはリクエストに認証を求めないため、共有するならリバースプロキシで認証をかけるか、LM Studioの認証機能を有効にする。 - ライセンスはモデルごとに違う。Apache 2.0のモデルと、利用規模や出力の使い道に条件があるLlama系のライセンスを同じ扱いにしない。
- モデルの更新は自分の仕事になる。入れ替えの判断も作業も自分で行う。評価用の質問セットを用意し、入れ替えのたびに同じ質問で比べる。
逆に、次の条件に当てはまるならローカルLLMを選ぶべきではありません。最新の資料に基づく回答が必須なのに、その資料をRAGや直接の入力で渡す仕組みを作れない業務、候補モデルを実際の業務データで評価して要求精度に届かなかった業務、数十人以上が同時に使うのにGPUサーバーを運用する担当者がいない組織、扱うデータをクラウドのLLMへ送ることが社内規程や契約で認められており、費用と保守の負担を比べてもクラウドのほうが小さい場合です。こうしたケースでは、入力を学習に使わない設定のあるクラウドLLMを先に検討し、費用は利用量と既存設備をそろえて比べてください。
よくある質問
ローカルLLMとは何ですか?
クラウドのAPIを使わず、自分のPCや社内のサーバーで大規模言語モデルを動かす使い方です。推論・文書の検索・保存先をすべて自社の機器に置き、閲覧権限を管理すれば、個人情報や社外秘の文書を外部に送らずに扱えます。
ローカルLLMは個人でどんな使い道がありますか?
Obsidianなどのメモの検索と要約、議事メモやメールの要約・下書き、英文の下訳、ソースコードの補完や説明が代表的です。API料金を気にせずプロンプトを何度も試せるので、LLMアプリ開発の練習にも使えます。
ローカルLLMのおすすめモデルは?
2026年10月時点で手軽に始めるなら、Ollamaで取得できるQwen3 8B(5.2GB)やGemma 4 12B(8.0GB)、国産の日本語モデルならLLM-jp-4.1 8BやLlama-3-ELYZA-JP-8Bが候補です。PC全体のメモリが24GB以上あればgpt-oss-20b(14GB)も選べます。
ローカルLLMに必要なPCスペックは?
1人で使う場合、8B級を量子化して使うならPCのメモリ16GB、12〜20B級なら24〜32GB、30B級ならVRAM 24GB以上のGPUが目安です。文脈を長くしたり複数人で同時に使ったりすると、必要な量は増えます。
ELYZAのLLMはどうやって使いますか?
Hugging FaceでGGUFが公開されているLlama-3-ELYZA-JP-8Bを、Ollamaの hf.co/ 指定かLM Studioのモデル検索で取得します。Ollamaでは取得後にチャットテンプレートがLlama 3形式かを確認してください。