“使ってよい”SLM ― 規制業界の日本企業のためのオンプレミス小規模言語モデル

日本の金融・医療・公共分野では、最先端（フロンティア）モデルは、プロジェクトが始まる前から選択肢から外れていることが少なくありません。性能が足りないからではなく、データに近づけることが許されないからです。こうした環境で成否を分けるのは、より大きなモデルではありません。データがすでに存在する場所で動作する、日本語に強い小規模モデルです。

銀行や病院、自治体にAIの提案を持ち込んだとき、採用されない理由がモデルの品質であることはほとんどありません。判断を左右するのは、顧客が早い段階で口にする一言です。「そのデータは、社内ネットワークの外には出せません」。こうした会話が止まってしまうポイントは、次の3つに集約されます。

本記事では、実際に“動かすことを許された”モデル、すなわちオンプレミスまたはプライベートVPCに展開し、汎用的な能力ではなく一つの狭いタスクに合わせてチューニングした、日本語に強い小規模モデル／オープンウェイトモデルについて論じます。制約が最も明確に表れる例として電子カルテの要約を主題に取り上げ、そのうえでタスクに応じたモデルサイズの決め方、利用可能なハードウェアに合わせた量子化、日本語品質の評価、そして顧客と共有する“精度とコンプライアンスのトレードオフ”の考え方を順に見ていきます。本記事は、現実の制約下で進める日本のエンタープライズAI導入をテーマにした連載の一部です。

01顧客が本当に抱えている制約

業界の提案は、たいてい“能力”の話から始まります。しかし、顧客の本当の問題は“許可”です。そして、それは過度に慎重なわけではありません。3つの異なる要因が、同じ結論へと収束するのです。

• APPI（個人情報保護法） 医療記録、そして金融や行政が保有する情報の多くは、要配慮個人情報にあたります。その取り扱いには厳格な管理が求められ、国外への移転には一定の要件が課されます。
• 業界ガイドライン 医療機関は、厚生労働省・総務省・経済産業省による安全管理ガイドライン、いわゆる3省2ガイドラインへの準拠が求められます。医療機関向けのガイドラインは、直近の大きな改定である第6.0版が2023年に公表されています。これらは、機密性・完全性・可用性に加え、記録の真正性や委託先に対する厳格な監督などを求めています。
• 契約と社内リスクポリシー 顧客とのNDAや社内規程は、法律上または技術上は許容される場合であっても、データを海外APIへ送信すること自体を明確に禁じているケースがあります。

これは例外的なシナリオではありません。日本企業におけるレガシーシステムの影響は根強く、オンプレミスは例外ではなく、標準的な選択肢として残っています。

経済産業省が2018年に公表した『DXレポート』では、放置されたレガシーシステムによって、年間最大12兆円の経済損失が生じる可能性が示されました。これは、よく知られる「2025年の崖」の出典でもあります。

その後、多くの日本企業がDXに取り組むようになりました。しかし、DXに着手していることと、十分な成果を得られていることは同義ではありません。日本企業が保有する機微なデータの多くは、当面、海外APIへ送信されないというのが現実的な見方です。

02サイズは“スコア”ではなく“仕様”である

“大きいモデルほど良いモデルだ”――これは顧客の、そして正直に言えば業界全体の直感です。あらゆることをこなす必要のある汎用アシスタントであれば、それはおおむね正しいでしょう。

しかし、こうした導入案件のほとんどは汎用的ではありません。実態は、外部へ動かせないデータを使い、日本語によって、一つの狭く反復的なタスクを大量に処理するというものです。

そうしたタスクでは、日本語で継続事前学習され、その特定業務に合わせてチューニングされた小規模モデルが、最先端の汎用モデルに遜色ない性能を発揮することがあります。しかも、顧客のオンプレミス環境にあるGPU 1枚で動かせる可能性があります。

問いは「そのモデルはどれだけ高性能か」ではなく、「この一つのタスクに十分な性能か、そしてデータがある場所で動かせるか」へと変わります。その現実的な選択肢が、オンプレミスまたはプライベートVPCに展開する、日本語に強い小規模モデル／オープンウェイトモデルです。

03主役の事例：カルテを読み返す医師

ほぼすべての診察の前に、医師は長い患者の記録――過去の受診歴、検査結果、処方、紹介状、自由記述の看護記録――を読み返し、その患者の状態を頭の中で組み立て直します。

この作業には時間がかかり、病院全体では1日に何百回も繰り返されます。その結果、本来目の前の患者に向けるべき時間が削られていきます。

臨床医がレビューするための要約ドラフト、例えば「この患者の現状を6行でまとめ、未解決の課題にフラグを立てて示す」といった内容を生成する支援モデルは、価値の高い応用です。そしてこれは、本記事の主張を最も明快に示す一例でもあります。

この事例は、タスクの難しさについても正直です。要約は、項目を一つ抜き出すだけの単純な処理ではありません。小規模モデルにとっては精度の限界に近い課題であり、だからこそ、どのような方法によって実用的な精度を確保するのかを丁寧に検討する必要があります。

また、要約は臨床判断に影響し得るため、正しい位置づけは“自律”ではなく“支援”です。モデルがドラフトを作成し、臨床医が最終確認（サインオフ）する。この役割分担は、安全な設計であると同時に、医療上の責任を人間の側に残す設計でもあります。

04アーキテクチャ：データは決して境界を越えない

リファレンスとなる構成は、あえて堅実です。記録ストア、推論サーバー、レビュー用インターフェース――すべての構成要素が、病院ネットワークまたはプライベートVPCの内側に置かれます。外部へ送信されるデータはありません。

見た目以上に重要な点が、いくつかあります。

• PII処理は“付け足し”ではなく、独立した工程 マスキング、墨消し（レダクション）、監査ログをパイプラインに組み込みます。明確な監査証跡を残すことが、病院のセキュリティ審査を通過させる重要な要素になります。
• 推論サーバーは、意図して小さくする 4bit量子化した3〜8BモデルをvLLMやllama.cppで提供すれば、オンプレミスのGPU 1枚に収められる可能性があります。これにより、病院のIT部門でも調達可能な構成になります。
• 人間による最終確認は、アーキテクチャの一部 モデルが単独で記録に書き込むことはありません。臨床医が設計上のレビュー工程に入り、生成された内容を最終確認します。

05タスクに合わせてモデルサイズを決める

モデル選定において、最初から「どのモデルが最良か」を問うべきではありません。まず、タスクについて次の4つを確認します。

• タスクは狭く定型的か
• 大量処理を前提としているか
• 低遅延が必要か
• 日本語が中心か

「はい」が増えるほど小規模モデルが適し、自由度の高い推論が必要になるほど大規模モデルが必要になります。規制業種の本番ワークロードの多くは、電子カルテの事例を含め、3〜8Bの帯に収まり、GPU 1枚で運用できる可能性があります。

06量子化とハードウェア・フットプリント

モデルの重みを、必ずしも16bitのフル精度で動かす必要はありません。4bitのQ4_K_M形式へ量子化すると、メモリ使用量を大幅に削減できます。

一般的な目安として、4bitではパラメータ10億あたり約0.5GBのVRAMを使用し、これにKVキャッシュとオーバーヘッドとして約15〜20％を加えます。実際の必要量や性能低下の程度は、モデル、実装、コンテキスト長、ハードウェアなどによって異なります。

7〜8Bモデルであれば、構成によっては8GBのコンシューマー向けGPUでも、対話的なレビューに利用できる推論速度を実現できます。GPUが利用できない場合でも、小規模な量子化モデルであれば、バッチ処理などの用途でCPU推論を検討できます。

07日本語の品質を評価する

日本語性能は、日本のエンタープライズ業務へモデルを導入する際に、特に重要な評価項目です。英語で高い性能を示すモデルでも、日本語では不自然な表現や誤りが生じる場合があります。

モデルの評価は“雰囲気”ではなく、次の3つの層で行います。

• 日本語の一般能力 Swallow LLM Leaderboard v2などの公開リーダーボードを使い、日本語の理解力や生成能力を比較します。
• ドメイン能力 日本語が自然であることと、医療や金融の専門内容を適切に扱えることは別です。医療分野ではJMedBenchなど、対象領域に応じた評価を行います。
• 顧客自身のデータによるタスク特化評価 顧客の実際の業務文書を非識別化して評価用データとし、要約の事実正確性、ハルシネーションの有無、敬語や専門略語の扱いなどを確認します。電子カルテ要約では、臨床医を評価に参加させることが重要です。

日本語向けのオープンモデルは、この数年で大きく進化しています。日本語で継続事前学習された小規模モデルの中には、日本語タスクにおいて、より大規模な海外モデルに匹敵する性能を示すものもあります。

※ライセンス条件や提供されるモデルのバリエーションは変更されることがあります。実際に導入する際は、最新のライセンス条件、提供形態、商用利用条件を必ず確認してください。本表はモデルの優劣を示すものではありません。

08精度とコンプライアンスのトレードオフ

各選択肢を「タスク精度」と「データ管理・コンプライアンス」の2軸で整理すると、違いが明確になります。

最先端のクラウドAPIは高い性能を備えていますが、データをシステム境界の外へ送信する構成では、規制対象データを扱えない可能性があります。一方、調整済みのオンプレミスSLMは、タスクで求められる精度を満たしながら、データを境界の内側で管理できます。

求めるべきものは、「世界で最も高性能なモデル」ではなく、「業務要件を満たし、データを安全に管理しながら運用できるモデル」です。規制業種では、精度だけでなく、データを境界の内側で管理し、監査可能な状態を維持できることも重要な要件です。

09同じ構図は、ほかの業種でも有効

電子カルテの事例が最も明快ですが、この考え方は、規制対象の日本語データと、狭く大量のタスクが組み合わさる業務であれば、ほかの業種でも活用できます。

金融――保険金請求とKYC業務

損害査定担当者は、請求書類・事故報告書・診断書を手作業で読み込みます。KYCチームは、企業が保有する機微なデータをもとに、疑わしい取引に関する記録を作成します。

いずれも、情報の抽出と文書作成を支援する定型タスクです。オンプレミスのモデルが必要な項目を抽出し、記述のドラフトを作成したうえで、人間が最終確認する構成が考えられます。

公共分野――住民からの問い合わせと申請処理

自治体の窓口やコールセンターでは、住民からの問い合わせへの対応や、生活保護・許認可・補助金などの申請処理が行われています。こうした業務では、マイナンバーや個人情報を扱うため、データを自治体ネットワークの外へ出せないケースがあります。

自治体の文書をRAGで検索できるオンプレミスSLMを活用すれば、問い合わせへの回答案を生成したり、申請書の入力を支援したりできます。これらの処理をネットワーク内で完結させることができます。

10まとめ

• 日本の金融・医療・公共といった規制業種では、最先端のクラウドモデルが、性能を評価する以前に選択肢から外れることがあります。個人情報保護法、業界ガイドライン、顧客との契約や社内規程によって、データを外部へ送信できないためです。
• こうした業務の多くは、汎用アシスタントではなく、日本語による定型的なタスクを大量に処理するものです。そのため、特定業務に合わせてチューニングした日本語対応の小規模モデルやオープンウェイトモデルでも、十分な性能を発揮できる可能性があります。
• 電子カルテ要約では、モデルをオンプレミス環境で運用し、生成された要約を必ず臨床医が最終確認する構成が現実的です。
• モデル選定では、タスクに応じたモデルサイズを決め、量子化によってハードウェア要件を調整します。そのうえで、日本語性能を一般性能・ドメイン性能・タスク性能の観点から評価します。
• 精度とコンプライアンスのトレードオフで重要なのは、最高精度を目指すことではありません。データを境界の内側に保ちながら、対象業務で必要とされる精度の閾値を超えられるかどうかです。

本記事は、現実の制約下で進める日本のエンタープライズAI導入をテーマにした連載の一部です。過去および今後の記事では、検索（リトリーバル）層のセキュリティ、本番稼働後のドリフト監視、そしてこうしたシステムが依拠するガバナンス実務を取り上げます。

References

• 経済産業省（METI）『DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～』（2018年）
• 厚生労働省・総務省・経済産業省『医療情報システムの安全管理に関するガイドライン』『医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン』（3省2ガイドライン）、第6.0版（2023年）
• 個人情報保護委員会『個人情報保護法（APPI）』――要配慮個人情報に関する規定
• Swallow LLMチーム（東京科学大学）『Swallow LLM Leaderboard v2』
• llm-jp『Awesome Japanese LLM ― 日本語LLMまとめ』
• Jiang et al., “JMedBench: A Benchmark for Evaluating Japanese Biomedical Large Language Models”
• SB Intuitions『Sarashina2.2』、Preferred Networks『PLaMo 2』、国立情報学研究所（NII）『LLM-jp-3.1』、ELYZA『Llama-3-ELYZA-JP-8B』
• llama.cpp／vLLMにおけるQ4_K_M（GGUF）の量子化・VRAMベンチマーク