ローカルLLMとは、事務所内の機器で動かす生成AIモデルのことです。

顧問先の資料を外部のサーバーに送らずに生成AIを使えないか。この問いから、ローカルLLMという選択肢にたどり着く事務所が増えています。この記事では、事務所にローカルLLMを載せるかどうかを判断する5つの基準と、実際に載せる場合の6工程、そして運用を回すための体制を整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、ベンダーの仕様は各社の公式ドキュメントで確認しています。

2026年にローカルLLMが士業の選択肢に入ってきた三つの事情

ローカルLLMが現実的な選択肢になったのは、性能・実行環境・規制の議論という三つが同時に動いたからです。どれか一つだけでは、事務所が機器を持つ理由にはなりませんでした。

ひとつめは、公開重みモデルの性能向上です。OpenAIは重みを公開したモデル gpt-oss を提供しており、同社は用途に応じてサイズの異なる二種類を用意していると説明しています。手元の機器で動かせる規模のモデルでも、要約や分類、定型文書の下書きといった事務所業務の下ごしらえには実用の域に入ってきました。士業のチカラでも、公開重みモデルと最先端モデルの差が縮まりつつある一方で、安全対策の作り込みには差が残る点を別記事で整理しています。事務所として押さえておきたいのは、性能が近づいたことと、そのまま業務に載せられることが別だという点です。

ふたつめは、実行環境の敷居が下がったことです。Ollama や LM Studio のように、モデルをダウンロードして数回の操作で起動できる実行環境が普及し、サーバー構築の専門知識がなくても手元の端末で試せるようになりました。数年前であれば、Pythonの環境構築とライブラリの依存関係の解決だけで数日を溶かす作業でしたが、いまは既存の業務用PCで小さいモデルを立ち上げ、実際の文書を投げて感触を見るところまでを短時間で試せます。ただし、事務所の資産として運用する場合は、更新の頻度と提供元の継続性を確認したうえで採用している例が多いようです。

みっつめは、規制側の議論が、データをどこに置くかという論点に向かってきたことです。個人情報保護委員会は生成AIサービスの利用について、個人情報を含むプロンプトの入力にあたって利用目的の達成に必要な範囲内かを十分に確認することなどを内容とする注意喚起を公表しています。入力データが事務所の外に出ない構成であれば、この確認事項のうち外部提供に関わる部分の検討は軽くなります。ただし後述するとおり、外に出さないことと安全であることは別の問題です。むしろ、外に出さない構成を選んだ事務所ほど、事務所内での取扱いを自力で設計する負担を負うことになります。

事務所にローカルLLMを入れるかを決める5つの判断基準

結論から書くと、ローカルLLMは守秘性の高い一部の業務に限って導入し、それ以外はクラウドの法人プランと併用する構成が、現時点では扱いやすい形です。全業務をローカルに寄せようとすると、性能と運用負荷の両方で無理が出ます。判断は次の5点で行います。

判断基準の一つめは、対象業務の守秘性です。顧問先の未公開情報、係争中の案件資料、未出願の発明内容のように、契約上も実務上も外部送信を避けたい情報を扱う工程があるなら、ローカル化の価値は高くなります。逆に、公開情報の要約や一般的な文章整形が中心なら、わざわざ機器を持つ理由は薄くなります。ここを曖昧にしたまま導入すると、結局クラウドで足りる作業にローカル機を使い、運用コストだけが残ります。

二つめは、求める出力品質です。最先端のクラウドモデルと、手元の機器で動く規模のモデルとでは、長文の論理構成や複雑な指示への追従で差が出ます。下書きの粗さを人が埋める前提で使うのか、それとも精度を求めるのかで結論が変わります。事務所の実務でいえば、面談メモの整理や定型文の生成のように、出力の骨格が決まっている作業ほどローカルでも成立しやすくなります。

三つめは、機器を面倒見る人がいるかどうかです。モデルの更新、OSのセキュリティ更新、バックアップ、故障時の切り分けを、誰の仕事にするのかが決まらないまま導入すると、半年後に誰も触らない箱になります。所内に担い手がいない場合は、外部保守を前提に見積もりを取るところから始めます。

四つめは、可用性の要求です。ローカル機が止まったときに業務が止まるなら、予備機か、クラウドへの切り替え手順を用意しておくことになります。繁忙期に機器が落ちたときの代替手段を、導入前に決めておくかどうかで、事故のときの混乱がまるで変わります。

五つめは、総額です。初期の機器費用だけでなく、電気代、保守、入れ替えまで含めた期間の合計で、クラウドの法人プラン費用と比べます。機器は買った瞬間から陳腐化が始まるため、何年で入れ替える前提かを先に決めておくと、比較の土俵がそろいます。

事務所にローカルLLMを載せる6工程

工程1は、対象業務の切り出しです。面談メモの要約、過去書面からの類似箇所の抽出のように、入力と出力が具体的に定義できる単位まで割ります。ここが曖昧なまま機器を買うと、評価の基準が作れません。切り出しの粒度は、その作業を新人スタッフに口頭で指示できる程度まで細かくするのが目安です。

工程2は、モデルの選定です。日本語の扱い、ライセンス条件、必要なメモリ量の三点で候補を絞ります。ライセンスは商用利用の可否と再配布条件を、提供元の記載で確認します。日本語の扱いについては、公開されているベンチマークの点数ではなく、自分の事務所の文書を投げて出力を見るほうが判断材料になります。士業の文書には、業界特有の言い回しと定型表現が多く含まれるためです。

工程3は、機器の準備です。モデルの規模に応じてGPUのメモリ量が効きます。まずは既存のPCで小さいモデルを動かし、業務に耐えるかを見てから機器を用意する順番が、無駄が出にくい進め方です。機器の設置場所も同時に決めます。執務室の片隅に置くのか、施錠できる部屋に入れるのかで、後述する物理管理の設計が変わります。

工程4は、業務データとの接続です。過去の書面や定型文をモデルに参照させる場合、検索の仕組みと組み合わせます。この構成は士業のチカラのRAG構築の記事で工程を分解しているので、あわせて読むと設計しやすくなります。接続する範囲は、最初から全件を対象にせず、特定の業務分野の書面だけに絞って始めるほうが、検索精度の検証がしやすくなります。

工程5は、有資格者による確認工程の埋め込みです。ローカルであってもモデルが誤った内容を出す性質は変わりません。出力をそのまま書面に転記せず、有資格者が根拠を確認してから確定する手順を、業務フローの中に置きます。この関門の作り方はハルシネーション対策の記事で整理しています。確認したことを記録に残す欄を、業務のチェックシートに追加している事務所もあります。

工程6は、記録と見直しです。誰がいつ何を入力し、どの出力を採用したかを残します。四半期に一度、対象業務の追加と除外を見直します。使われなくなった用途を放置すると、権限だけが残って管理の穴になるため、除外の判断も同じ場で行います。

以下は、ローカルLLMに面談メモの要約を任せるときのプロンプト例です。顧問先名は伏せ、架空の表記に置き換えて使います。

あなたは士業事務所の事務スタッフです。以下の面談メモを、事務所内の記録用に要約してください。

制約:
- 出力は「相談の背景」「聞き取った事実」「依頼者の希望」「次回までの宿題」の4見出し
- メモに書かれていない事実は決して補わない。書かれていない項目は「記載なし」と出力する
- 法的な評価・見通しは書かない。事実の整理のみ行う
- 固有名詞は入力のまま保持し、推測で補完しない
- 数字と日付は必ず入力どおりに転記する

面談メモ:
"""
（ここに面談メモを貼り付け。依頼者名はA社、担当者は甲と表記）
"""

もう一本は、過去の書面から類似箇所を探す用途です。検索で候補を絞ったあと、読み込みだけをモデルに任せる形にします。生成をさせず抽出に徹させることで、モデルが文章を作り込む余地を減らせます。

以下は当事務所の過去書面から抽出した候補文です。参照したい論点は「役員の任期に関する定め」です。

手順:
1. 候補文それぞれについて、論点との関連度を「高・中・低」で判定する
2. 関連度が高いものだけ、該当する条項の原文を改変せずそのまま引用する
3. 要約や言い換えは行わない。原文にない語を足さない
4. 判定理由を1文で添える
5. 候補文に該当がない場合は「該当なし」とだけ出力する

候補文:
"""
（検索で抽出した候補文をここに貼り付け）
"""

事務所内で完結させても残る守秘義務と規程の論点

データが外に出ないことは、守秘義務の検討が終わることを意味しません。ローカルLLMでも、確認しておく論点が三つ残ります。

一つめは、守秘義務の根拠が外部送信の有無だけで語られていない点です。たとえば弁護士法第23条は、弁護士またはであった者が職務上知り得た秘密を保持する権利を有し義務を負うと定めています。税理士法第38条は、正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、また窃用することを禁じています。社会保険労務士法第21条や弁理士法第30条、司法書士法第24条にも同趣旨の定めがあります。いずれも漏えいの経路を限定していないため、事務所内の機器に集約したこと自体が検討の終着点にはなりません。むしろ、事務所内の誰がどの案件の資料にアクセスできるのかという論点が前に出てきます。ローカル機に過去の全書面を投入すると、これまで担当者しか見られなかった資料が、機器を触れる全員の目に触れる状態になり得ます。

二つめは、安全管理措置です。個人情報の保護に関する法律第23条は、個人情報取扱事業者が取り扱う個人データの漏えい、滅失または毀損の防止その他の安全管理のために必要かつ適切な措置を講じなければならないと定めています。同法第24条は従業者の監督についても定めています。ローカル機は物理的に事務所内にあるぶん、盗難、持ち出し、退職者のアカウント残存といった経路が新たに増えます。IPAが公開している情報セキュリティ関連のガイドラインは、中小規模の組織向けの実践内容を含んでおり、機器管理の項目を作る際の下敷きに使えます。クラウド利用では提供者側が担っていた部分を、自前で持つことになる点が、費用より先に効いてきます。

三つめは、顧問先への説明です。クラウドに送らないから安心だという説明は、事務所内での取扱いを何も説明していないことになります。どの業務でAIを使い、出力を誰が確認し、記録をどう残すのかまで書いた説明資料を用意している事務所もあります。この作り方は顧問先へのAI活用説明資料の記事で扱っています。

規程に落とすなら、既存のAI利用規程にローカル機の章を足す形が扱いやすくなります。対象機器の設置場所、利用できる職員の範囲、持ち出しの可否、モデル更新の担当、廃棄時のデータ消去手順。この5点を書いておくと、運用の判断が属人化しにくくなります。特に廃棄時の消去は忘れられがちで、入れ替えた古い機器にモデルと業務データが残ったまま倉庫に置かれる例が起きます。士業のチカラのAI利用規程テンプレートの記事に全体の骨子があります。

導入でつまずく三つの失敗と回避策

一つめは、機器を先に買ってしまう失敗です。GPUを積んだPCを用意したものの、動かしてみたら想定した業務には精度が足りなかった、という順序の誤りが起きます。回避策は、既存PCで小さいモデルを動かし、実際の業務データに近いサンプルで出力を見てから機器を決めることです。評価の基準は、導入前に文章で書いておきます。何をもって使えると判断するのかが言語化されていないと、購入の是非が担当者の感想で決まってしまいます。

二つめは、ローカルだからと入力ルールを緩めてしまう失敗です。外に出ないという安心感から、係争中の案件資料や未出願の技術情報まで無制限に投入し、事務所内の閲覧権限を超えて職員が内容を見られる状態になる。回避策は、クラウド利用と同じ入力ルールを適用したうえで、機器へのアクセス権限を業務単位で絞ることです。情報漏えいの経路を整理した別記事も参考になります。

三つめは、更新が止まる失敗です。導入直後は熱心に触っていても、担当者が繁忙期に入ると更新が止まり、脆弱性が放置されます。回避策は、モデルとOSの更新を月次の定例作業として当番表に載せ、実施記録を残すことです。担当者が一人しかいない事務所では、更新作業を外部の保守業者に切り出す選択肢もあります。更新を止めた機器を業務で使い続ける状態は、クラウドを使うより経路上のリスクが大きくなり得ます。

費用と工数の目安、そして誰が面倒を見るか

費用は、機器費用、電気代、保守、そして人の時間の四つに分かれます。機器はGPUを積んだデスクトップ相当から、共有サーバーまで幅があります。金額は構成と時期で大きく変わるため、ここでは具体額を示しません。見積もりを取る際は、モデルを動かすのに要するメモリ量を先に確定させてからベンダーに投げると、比較しやすくなります。仕様を決めずに相談すると、過剰な構成の提案が返ってきて判断がつかなくなります。

工数のほうが見落とされがちです。初期の検証、業務フローへの組み込み、職員への説明と練習、そして運用開始後の月次更新。このうち月次更新は、担当者一人あたり月に数時間の枠を見ておく事務所が多いようです（編集部が置いた前提であり、出典のある統計ではありません）。導入初月は、これに加えて職員への説明と試用の時間がまとまって発生します。

体制については、所内に情報システムの担当がいない場合、外部に保守を委託する形が現実的です。この場合、委託先が事務所のデータに触れる可能性が出るため、個人情報の保護に関する法律第25条が定める委託先の監督という論点が加わります。契約書に、作業時のデータ閲覧範囲と記録の取り方を書いておく運用を採る事務所があります。守秘義務の対象となる資料が入った機器に外部の技術者が触れる以上、口頭の了解だけで済ませない設計が要点になります。

クラウドとの併用が当面の現実解になる理由

ローカルLLMをどこまで広げるかという問いには、当面は広げないという答えが合理的に見えます。理由は、性能の伸びがクラウド側のほうが速いからです。手元の機器は買った時点の性能で固定されますが、クラウドの法人プランは契約したまま提供側の更新を受け取れます。

そのため、守秘性が特に高い一部の工程だけをローカルに置き、残りをクラウドの法人プランで回す二層構成が、当面の落としどころになります。この構成を採る場合、どの情報がどちらに行くかの振り分け基準を文章にしておくことが、運用の鍵になります。基準が人の頭の中にあるうちは、担当者が変わった瞬間に崩れます。

今後の論点は、公開重みモデルの安全対策がどこまで作り込まれるかです。性能が最先端に近づいても、不適切な出力を抑える仕組みや、悪用への備えの部分では差が残るという指摘があります。事務所側は、モデルの性能だけでなく、提供元が安全性の評価をどう公開しているかを見る目を持っておくと、選定を誤りにくくなります。

よくある質問

ローカルLLMを使えば守秘義務の検討は不要になりますか

いいえ、検討は残ります。士業各法の守秘義務は漏えいの経路を限定していないため、事務所内の機器に置いたことで検討が終わるという整理にはなりません。事務所内での閲覧範囲、機器の物理管理、退職者のアカウント処理といった論点が新たに出てきます。むしろ、クラウド提供者が担っていた管理を自前で持つぶん、設計の手数は増えます。

どのくらいの性能の機器を用意すればよいですか

モデルの規模によって変わるため、先に対象業務とモデルを決める順番になります。まず既存のPCで小さいモデルを動かし、実際の業務データに近いサンプルで出力の質を見てから、機器の仕様を詰める進め方が無駄が出にくくなります。ベンチマークの数値だけで機器を決めると、自分の事務所の文書では期待した精度が出ないという結果になりがちです。

クラウドの法人プランと比べて安全性は高いのですか

一概には言えません。外部送信が発生しない点では経路が減りますが、事務所内での物理管理、権限管理、更新の継続という別の負担が増えます。どちらが安全かではなく、どのリスクを自分で持つかの選択だと捉えると判断しやすくなります。更新を継続できる体制があるかどうかが、実質的な分かれ目になります。

顧問先にはどう説明すればよいですか

事務所内の機器で処理し外部のサービスには送信しないという事実と、出力は有資格者が確認してから確定するという手順の二点を、書面で伝えている事務所があります。送信しない点だけを強調すると、事務所内の取扱いの説明が抜けるので注意が要ります。説明資料には、対象となる業務の範囲も書いておくと、後の認識違いを防げます。

モデルのライセンスは何を確認すればよいですか

商用利用の可否、再配布の条件、出力物の取り扱い、そして利用者数や売上規模による条件の変化の四点を、提供元の公式記載で確認する流れになります。日本語訳の解説記事ではなく、提供元が公開しているライセンス原文に当たることが確認の基本です。条件は改定されることがあるため、更新のたびに確認する運用にしておくと安全側に倒れます。

一人事務所でもローカルLLMは扱えますか

扱えますが、運用の担い手が一人になる点が最大の論点になります。更新と障害対応を自分で持つのか、保守を外部に出すのかを先に決めてから導入するほうが、途中で止まりにくくなります。まずクラウドの法人プランで業務の型を作り、守秘性の高い工程が明確になってからローカル化を検討する順序もあります。

出力の誤りはどう防げばよいですか

防ぐというより、誤りが混じる前提で確認の関門を業務フローに置く設計になります。出力をそのまま書面へ転記しないこと、根拠となる条文や資料を人が原典で確認すること、確認した記録を残すことの三点を手順に組み込んでいる事務所があります。ローカルであっても、この関門を省く理由にはなりません。

導入した機器を入れ替えるときは何をしますか

データの消去と、権限の棚卸しの二つを行います。古い機器にモデルと業務データが残ったまま保管される例が起きるため、廃棄・下取りの前に消去手順を実行し、実施した記録を残す運用にしておくと後から確認できます。あわせて、新しい機器で誰にアクセス権を付与するかを、その時点の在籍者で組み直します。

参考文献

• e-Gov法令検索 弁護士法
• e-Gov法令検索 税理士法
• e-Gov法令検索 個人情報の保護に関する法律
• 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等について
• IPA 情報セキュリティ関連ガイドライン
• OpenAI Introducing gpt-oss

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/