ローカルLLMの活用事例｜企業・自治体・病院が社内で使う8例と共通点

ローカルLLMの活用事例とは、外部のAIサービスにデータを送らず、院内・庁内・社内の閉じた環境で動かす大規模言語モデルを、実際の業務に使った例のことです。今回、発表元の資料で確かめた国内の実名事例8件は病院・銀行・自治体・印刷会社にわたり、どれも患者情報や顧客情報のような外に出せないデータを、専門のパートナー企業と組んで扱っています。効果を数字で発表しているのは一部だけで、多くは実証中か、数字を出していない段階となります。社員10〜200名の会社がこの条件をそろえるのは簡単ではなく、まずは学習させない設定とログ管理ができる既製の法人向けサービスで足りないかを確かめる順番が現実的でしょう。

ローカルLLMの仕組みやGPUの考え方、メリットとデメリットの全体像は、ローカルLLMとは何か（仕組みと全体像）にまとめています。ここから先は、発表された事実だけで事例を並べ、自社に置き換えるための材料として読める形にしてあります。

業種別に並べた国内のローカルLLM活用事例8件

発表元の資料で確かめられた8件を業種別に並べると、医療が2件、金融が2件、自治体が3件、企業の実証が1件となります。どの事例も、業務・動かした場所・モデルやパートナー・発表された効果・本番か実証かの5つの物差しでそろえています。

※2026年10月6日時点で、各発表元のプレスリリース・公開資料を確認した内容です。効果の数字はすべて発表者による公表値で、第三者による検証は確認できていません。宮崎県はHPE、草加市はFIXERの発表で確認したもので、自治体側の公式ページでの発表は確認できていません。

出典：織田病院＝オプティム・織田病院・シーエスアイ 2024年3月29日発表、オプティム 2024年11月7日発表／三重大学医学部附属病院＝三重大学・NTT西日本 2024年11月1日発表／あおぞら銀行＝neoAI 2025年4月17日発表／常陽銀行＝めぶきフィナンシャルグループ 2026年3月26日発表、Athena Technologies 2025年7月8日発表、Athena Technologies 2026年3月26日発表／山口県＝NTT西日本 2024年9月17日発表、山口県の報道発表／宮崎県＝HPE 2026年4月23日発表／草加市＝FIXER 2026年8月28日発表／共同印刷＝共同印刷 2025年3月31日発表

製造業・法律・会計の分野では、ローカル環境で動かしていると発表元の資料で確かめられる実名事例は、2026年10月6日時点で確認できていません。ローカルLLMの事例として名前が挙がる製造業の取り組みも、公表資料を読むとクラウド上のサービスを使う構成だったり、動かす環境の記載がなかったりします。業種で自社を重ねるより、扱うデータの性質で重ねたほうが、自社に近い事例を見つけやすいでしょう。

医療と金融の事例：患者情報・顧客情報を外に出さずに使う

医療と金融の4件は、患者や顧客の情報を含む文書を、外部に出さないまま要約や翻訳にかけている点で共通しています。このうち業務時間の短縮を実績の数字で発表しているのは、織田病院だけになります。

三重大学医学部附属病院：NTT西日本のtsuzumiで電子カルテ要約を実証

三重大学医学部附属病院は、NTT西日本と組み、電子カルテの内容を要約して退院サマリを作る実証を2024年11月1日に始めると発表しました。退院サマリは年間約1.5万件あり、1件に30分程度かかるケースもあると、両者の発表資料に書かれています。使うモデルはNTT版LLMの「tsuzumi」で、70億パラメータの大きさとなります。NTT西日本が動作環境を整え、電子カルテのデータで追加の学習も行う役割分担です。動作環境は医療機関のネットワーク内に置き、情報を外部へ出さない形で動かす計画となっていました。

AIが作った下書きは医師が確認・修正する前提で、AIに書かせて終わりにはしていません。実証は2025年3月31日までの予定で、終了後の結果は2026年10月6日時点で公表資料を確認できていない状態です。数字の発表がない以上、どれだけ時間が減ったかはまだ分からないものとして読むのが正確でしょう。

織田病院：オンプレミスの完全ローカル環境で看護サマリーを要約

佐賀県の社会医療法人 祐愛会織田病院は、オプティム・シーエスアイと共同で、入退院時の看護サマリーの要約文をAIで作る取り組みを2024年3月29日に発表しました。電子カルテ「MI・RA・Is」と連携し、オプティムの「OPTiM AI」をインターネットにつながない院内の環境で動かす構成になります。3月の発表では試験的な導入とされ、11月7日の発表では導入されたという表現に変わりました。

効果として、退院時看護サマリー1件あたりの作成時間が導入前の平均16.31分から、初回10.90分、使用3回目以降は7.47分に減ったと同社は発表しています。削減率は初回で33.2%、3回目以降で54.2%となります。発表の数字から計算すると、慣れた後は1件あたり約8.8分の短縮にあたります。一方で、何人の看護師が何件で測った数字なのかは、発表資料に書かれていません。

API課金が発生しないため長期的にはコスト削減が期待できるという説明もありますが、こちらは期待であって実績の数字ではない点に注意が必要です。国内初という表現も、オプティム調べという前提つきで読んでおきましょう。

あおぞら銀行：オンプレミス型AI基盤に向けて行内特化LLMを開発

あおぞら銀行の事例は、neoAIが2025年4月17日に、事務規定の管理業務を想定した行内特化のLLM「あおぞらLLM（仮称）」を開発したと発表したものです。行内のデータで学習させたモデルで、オンプレミス型の次世代AI基盤の構築に向けた取り組みと位置づけられています。発表された数字は、難しい問いに対する応答精度が従来比130%というものです。これは内部ベンチマークで、学習させる前のモデルと比べた値になります。

第三者が検証した数字ではなく、本番で動いているという記載もまだありません。130%という数字だけを見て、業務での効果が確かめられたと受け取らないように気を付けてください。

常陽銀行：閉域クラウド上のローカルLLMで翻訳・個人情報マスキング

常陽銀行については、めぶきフィナンシャルグループが2026年3月26日に、生成AIの行内利用を始めたと発表しました。使う業務は翻訳と個人情報マスキングで、稟議書のレビューと業務文書の自動生成は試行を続けているところです。2025年7月からAthena Technologiesと実証を進め、融資審査業務などを含む5つのユースケースで有効性を確かめたうえでの行内利用となります。

動かす場所は自社のサーバーではなく、インターネットから分離した閉域クラウドで、Athenaの導入事例ではAzure VNet上にローカルLLMを構築したと説明されています。ローカルと呼ばれていても、建物の中にサーバーを置く形とは限りません。効果の数字と利用者数は、発表資料からは読み取れない状態です。

自治体と企業の事例：庁内の機微データと社内の情報資産

自治体の3件は、個人情報などの機微なデータを扱う庁内業務にAIを広げるための取り組みで、そのうち2件はベンダー側の発表だけが確認できる状態です。企業の共同印刷は、社内の情報資産を外に出さずに使う実証として発表されています。

山口県：機微データを扱う業務でtsuzumiを実証

山口県は、NTT西日本と組み、2024年9月17日に、令和6年（2024年）10月から1年間の予定でtsuzumiの実証を始めると発表しました。想定されている業務は、機微データを扱う業務の対応記録の要約・校正と、各種業務マニュアルの検索・要約になります。NTT西日本の発表では、オンプレミス環境に置いた小型のGPUサーバーでtsuzumiを動かす構成と説明されています。効果の数字や対象となる職員の数は、発表資料からは読み取れません。

宮崎県・草加市：ベンダーが発表した庁内専用の生成AI

宮崎県の事例は、HPEが2026年4月23日に発表した内容になります。給与・旅費・会計事務などの業務で、庁内専用のオンプレミス型生成AIの活用を始めたと発表されています。サーバーはHPE ProLiant DL385 Gen11（NVIDIA搭載）で、ソフトはSparticleのプライベート版GBase、構築は南日本ネットワークという組み合わせです。県の公式ページでの発表は確認できておらず、効果の数字・利用者数・GPUの台数も記載がありません。

草加市は、FIXERが2026年8月28日に導入開始を発表した例となります。従来は個人情報の入力を禁止していた業務、たとえば個人情報を含む会議録の作成や、機密データを基にした計画策定、内部規程の素案作成にAIを使えるようにする狙いが示されています。処理はオンプレミス型のアプライアンス「Sovereign GaiXer」の専用筐体の中で終わる構成です。全国自治体初という表現はFIXERによるもので、使うLLMの名前や効果の数字は発表されていません。

ベンダーの発表だけで成り立っている事例は、導入した側が何をどこまで使っているのかが見えにくいため、発表者の名前を添えて読むのが無難でしょう。

共同印刷：外部ネットワークにつながない専用端末で実証

共同印刷はSI&Cと組み、2025年3月31日に、ローカルLLMの実証を4月から本格的に始めると発表しました。使い道は営業資料の自動生成、顧客対応の効率化、業務習得の支援の3つになります。外部ネットワークにいっさい接続せず、専用端末の中で全ての処理を終える完全オフラインの環境で動かすと説明されています。

営業資料の作成時間30%削減は、発表の中で期待される効果の一例として掲げた数字で、実際に測った結果ではありません。漏洩リスクについても、期待される効果として書かれている段階にとどまります。

自治体や印刷会社の例のように、AIへの入力を禁止している情報を抱えている会社は少なくないでしょう。最初からサーバーを用意しなくても、入力してよい情報の線引きを決め、社員が使うAIの環境を会社で1つにそろえるところから始めることも出来ます。

「ローカル」の意味は事例ごとに4通りある

同じローカルLLMの事例でも、AIが動いている場所は院内・庁内のサーバー、専用端末、閉域クラウド、構築途中の4通りに分かれます。事例を自社に重ねるときは、この違いを先に押さえておきましょう。

インターネット接続なしと書いているのが織田病院、完全オフラインと書いているのが共同印刷で、常陽銀行もインターネットから完全に分離した閉域環境と発表しています。草加市についても、FIXERは社内データをインターネットに送信せず、AI処理が本体内で完結すると説明しました。閉域クラウドを使う常陽銀行の形は、建物の中にGPUサーバーを置かない代わりに、クラウド上でネットワークを分ける設計が要ります。どの形が正しいということはなく、自社の規程がどこまでを社内とみなすかで選ぶものです。

完全オフライン・閉域で動かす利点は、入力を禁止していた情報を扱えること

閉域で動かす利点は、これまで規程でAIへの入力を止めていた情報を、業務に使える範囲へ広げられる点にあります。草加市の発表が、それまで入力を禁止していた個人情報を含む会議録を対象に挙げているのは、その分かりやすい例となります。病院の電子カルテや銀行の顧客情報も、外部に出さないことを前提に発表されています。

その代わり、インターネットにつながないぶん、モデルの入れ替えやソフトの更新は人の手で運び込む作業になり、手間は増えてしまいます。

クラウド型LLMとの違いは、データの通り道と面倒を見る人

クラウド型LLMとの違いは、入力したデータがどこを通り、誰の設備で処理されるかにあります。クラウド型は提供元の設備で処理されるため、規模の大きなモデルをすぐ使える反面、データは社外の設備を通ることになります。ローカル型はデータを手元にとどめられる代わりに、モデルの性能と設備の面倒を自分たちで見ることが前提です。

費用や性能を含めた細かい比べ方は、ローカルLLMとクラウドの比較で扱っています。クラウド型でも法人向けのプランやサービスには、入力を学習に使わない設定や、利用ログを会社で管理する機能を持つものがあります。ローカルでなければ守れないデータがどれだけあるかが、分かれ目になります。

事例に共通する5つの条件：機密・閉域・専門用語・量・パートナー企業

8件の事例を並べると、外に出せない機密データ、閉域で動かす要請、専門用語の多い文書、まとまった業務量、組んだパートナー企業の5つがそろっている点が共通しています。このうち1つでも欠けている会社では、自前でローカルLLMを作る理由が弱くなりがちです。

機密情報を外部に出さないことが導入理由の出発点

どの事例も、導入の理由の先頭には機密情報を外部に出さないことが置かれています。扱うデータは患者の電子カルテ、銀行の顧客情報や行内規定、庁内の機微データ、会議録に含まれる個人情報と、いずれも漏れたときに取り返しがつかない種類のものになります。一般的な会社の営業メールや社内報の下書きのように、外に出ても困らない文書が中心なら、この条件には当てはまりにくいでしょう。

専門用語の多い文書が、まとまった量で発生している

次に共通するのは、専門用語の多い文書が、毎日まとまった量で発生していることです。三重大学医学部附属病院の退院サマリは年間約1.5万件あり、銀行の事務規定や自治体の業務マニュアルも、独自の用語や言い回しが多い文書となります。三重大学医学部附属病院が電子カルテのデータでの追加の学習を計画し、あおぞら銀行が行内データで学習させているのは、この専門用語に合わせるためと考えられます。量が少なければ、設備を用意する手間に見合う効果が出にくくなってしまいます。

社内文書RAG・社内専用チャットとしての使い方

山口県の業務マニュアルの検索・要約や、共同印刷の業務習得の支援は、社内の文書を探して答えさせる使い方に近いものです。社内の文書を検索してAIに答えさせる仕組みはRAG（検索拡張生成）と呼ばれ、ローカルLLMでもクラウドのサービスでも組むことが出来ます。作り方と注意点は、ローカルLLMで社内文書RAGを作る方法で詳しく扱っています。

8件すべてがパートナー企業と組んでいる

8件の事例はすべて、モデルや環境を提供するパートナー企業と組んだ形となります。名前が出ているのはNTT西日本、オプティム、neoAI、Athena Technologies、SI&C、Sparticle、FIXERなど、AIやシステム基盤を手がける会社です。病院や銀行や県庁であっても、モデルの選定や追加の学習、サーバーの構築は外部の専門家と一緒に進めていると、発表からは読み取れるでしょう。社員10〜200名の会社が同じことをするなら、パートナー企業を探し、その費用を払う前提で考えることになります。

発表された数字の読み方：実績・期待値・未公表を分ける

発表された効果の数字は、実際に測った実績、これから目指す期待値、数字を出していない未公表の3つに分けて読む必要があります。

8件のうち、業務の時間が実際に減ったと数字で発表しているのは織田病院の1件だけになります。未公表の5件は効果の数字を出しておらず、利用者の数やGPUの台数も、確認した発表資料にはほとんど書かれていません。事例紹介の記事で効果の割合だけが並んでいるときは、それが実績なのか期待なのかを発表元で確かめてみてください。

公表されていない点：費用・利用者数・GPUの台数

自社で作るかを決めるときに知りたいのは、いくらかかり、何人が使い、何台のGPUで回しているかという点でしょう。この3つは、8件のどの発表資料にもそろって書かれていません。事例をそのまま自社の予算に置き換える材料は、公開情報からは得にくいということです。見積もりの目安はローカルLLMの社内サーバーの規模で整理していますので、あわせて見ておくと判断の材料がそろいます。

ローカルLLMの事例として紹介されるが、ローカル動作を確認できなかった例

ローカルLLMの事例として紹介されることのある取り組みにも、発表元の資料ではローカルで動かしていると確かめられないものが含まれます。製造・建設・化学・電力などの大手企業や一部の自治体の生成AIの取り組みには、クラウド（Azure OpenAIなど）上の構成だったり、動かす場所が発表に書かれていなかったりするものが見られ、ここではローカルLLMの事例に数えていません。どれも社内でAIを使う取り組みとしては参考になりますが、ローカルLLMの事例として数えると判断を誤る材料になってしまいます。

自前で動かすメリット・デメリット（初期投資・性能差・運用負荷）と進め方

自前でローカルLLMを動かすメリットは、データを外に出さない点と、規程で止めていた業務にAIを使える点にあります。デメリットは、初期投資・性能差・運用負荷の3つが、そのまま自社に乗ってくることです。

初期投資として、GPUを載せたサーバーや専用端末、または閉域クラウドの費用が先にかかります。性能の面では、手元で動かせる大きさのモデルは、クラウドで提供される大きなモデルに比べ、長い文書の読み込みや込み入った推論で見劣りすることがあります。運用負荷としては、モデルの入れ替え、ソフトの更新、利用者の権限やログの管理を、自社かパートナーが続けていくことになります。8件のうち4件は発表の時点で実証か開発の段階にあり、常陽銀行と織田病院も、試験や実証を経てから行内利用・導入へ進んだと発表しています。構築の具体的な進め方はローカルLLMの構築手順、できることの一般的な範囲はローカルLLMでできることで詳しく見ることが出来ます。

導入手順（目的整理→PoC→運用）は事例でも段階を踏んでいる

事例の進み方を見ると、どこも対象業務を絞り、実証（PoC）で確かめてから、利用を広げる順番を取っています。常陽銀行は2025年7月に実証を始め、融資審査業務などを含む5つのユースケースで有効性を確かめてから、2026年3月に行内利用へ進みました。織田病院も、2024年4月から10月にかけて使いながら作成時間を測り、その数字を11月に発表しています。自前で作るなら、まず1つの業務に絞り、今の所要時間を測ってから実証に入る順番を守りましょう。測る前の数字がなければ、効果を数字で示すことが出来なくなってしまいます。

商用利用ライセンスの確認

自前でモデルを選ぶ場合は、モデルごとに決められた利用条件（ライセンス）で、商用利用が認められているかを確かめる必要があります。公開されているモデルの中には、利用の目的や規模に条件を付けているものもあるため、パートナー企業に任せる場合でも、契約の前に条件を書面で確かめておきたいところです。事例の発表資料では、使ったモデルの名前自体が書かれていないものが少なくとも5件あります。ライセンスの扱いは発表から確かめられないため、自社で導入するときは自分たちで確認するほかありません。

社員10〜200名の会社は自前で作るべきか：判断チェックリスト

社員10〜200名の会社で、事例と同じ条件がそろうことは多くないため、自前で作るのは下のチェックがほぼ全部埋まるときに限るのが現実的です。埋まらない項目が多いなら、既製の法人向けサービスで学習させない設定とログ管理を整えるほうが早く始められます。

• 社内規程でAIへの入力を禁止している情報が、日々の業務にあるか患者情報・顧客情報・個人情報を含む会議録のように、外に出せないことが事例の出発点でした。外に出ても困らない文書が中心なら、自前で作る理由は弱くなります。
• その情報を扱う業務が、まとまった量で発生しているか三重大学医学部附属病院の退院サマリは年間約1.5万件でした。月に数件の業務なら、設備の手間に見合いにくくなります。
• 専門用語や社内独自の規程を、AIに読ませる必要があるか追加の学習や社内文書の検索が要るかどうかで、作る仕組みの大きさが変わります。
• GPUサーバーや閉域環境を用意し、保守を続けられる担当者がいるかモデルの入れ替え、ソフトの更新、権限とログの管理が、導入後も続きます。
• 組めるパートナー企業と、その費用の予算があるか8件の事例はすべてパートナー企業と組んでいます。費用は公表されていないため、見積もりを取って確かめる必要があります。
• 導入前の所要時間を測り、効果を自社で確かめる段取りがあるか発表された事例でも、効果の数字を出しているのは一部だけです。測る段取りがないと、続けるかどうかを決められません。
• 既製の法人向けサービスの、学習させない設定とログ管理では社内規程を満たせないかここで満たせるなら、自前で作らずに済む業務がかなり残ります。満たせない業務だけを切り出して考えます。

チェックが少ないうちは、無理に自前の環境を作るより、既製のサービスで使い方を固めてから考え直すほうが手戻りは少なくなります。自前のローカルLLMと既製の法人向けサービスを並べると、次のような違いが見えてきます。

どちらを選んでも、効果を自社で測る手間は変わりません。違いが出るのは、設備と保守を自社で抱えるかどうかになります。

会社で安全に使うには：学習させない設定・ログ管理・社員への配布・複数AIの使い分け

既製のサービスを選ぶ場合も、会社として安全に使うために決めることは自前の場合と変わりません。1つめは入力した内容をAIの学習に使わせない設定で、社員ごとの操作に任せず、会社側でそろえられるかを確かめましょう。2つめは利用ログで、誰がいつどのAIを使ったかを会社側で見られる状態にしておけば、事故があったときに追いかけることが出来ます。3つめは社員への配布で、一部の社員にしか渡さないと、渡されなかった方が個人のアカウントで使い始め、野良AI（シャドーAI）と呼ばれる会社から見えない利用が生まれてしまいます。

4つめは複数のAIの使い分けで、調べものはWeb検索に強いAI、長い文書の読み込みは長文に強いAIと、用途で選べると外れが減ります。点検の項目は生成AIのセキュリティ対策チェックリスト、使い分けの考え方は複数の生成AIをまとめて使うマルチAIにまとめています。社内ルールの作り方は生成AIの社内ガイドラインの作り方を、サービスの横並びは法人向け生成AIサービスの比較を見てみてください。外に出せないデータを扱う業務が育ってきたら、その業務だけをローカルLLMに切り出す順番でも遅くはないでしょう。

よくある質問

まとめ

今回、発表元の資料で確かめた国内の実名事例8件は、病院・銀行・自治体・印刷会社にわたり、どれも外に出せないデータを、パートナー企業と組んで閉じた環境で扱っています。動かす場所は院内のオンプレミス、専用端末、閉域クラウドと幅があり、ローカルという言葉の中身は事例ごとに違います。効果の数字を実績として出しているのは織田病院だけで、あおぞら銀行は開発時の内部ベンチマークの評価、共同印刷は期待値、残りは未公表という状態になります。

社員10〜200名の会社は、機密・業務量・専門用語・担当者かパートナー・予算の条件がそろうかをチェックリストで確かめてみてください。そろわないうちは、既製の法人向けサービスで学習させない設定とログ管理を整えることから始めるのが近道でしょう。法人のAI活用に関する他の記事は、AI活用コラム一覧にまとめています。