はじめに：カタログスペックの「罠」から抜け出そう
「最新のオープンソースモデル、LlamaのベンチマークスコアがChatGPTに迫りました！」
このようなニュースを目にするたび、社内のAI導入プロジェクトを進める皆さんは期待を膨らませるのではないでしょうか。「これなら、クラウドに出せない自社の機密データも、社内サーバー（オンプレミス）で安全に処理できるかもしれない」と。
しかし、実際にモデルをダウンロードして動かしてみると、現実はそう簡単ではありません。
「日本語で質問したのに、なぜか英語で返ってくる」
「指示したJSONフォーマットが崩れていて、システム連携できない」
「『知らない』と言ってほしいところで、もっともらしい嘘（ハルシネーション）をつくる」
実務の現場における一般的な傾向として、公開されているベンチマークスコアと、実際の業務における「使える度合い」は、往々にして別物です。
特に金融や医療、製造業といった機密保持要件が厳しい業界では、汎用的な性能よりも「特定のルールを絶対に守る堅牢性」が求められます。これを測るには、Hugging Faceのリーダーボード（性能評価のランキング）を眺めるのではなく、自社の業務データに近い入力を使って「実証実験（PoC）」を行うしかありません。理論だけでなく、実証に基づいたアプローチが不可欠です。
今回は、モデル選定のための検証用プロンプトセットを紹介します。これをコピー＆ペーストして、OllamaやLM Studioなどのローカル環境で試してみてください。カタログスペックでは見えなかった、各モデルの「素顔」と「相性」が論理的に浮き彫りになるはずです。
1. この検証スイートの目的と活用法
スペック表では見えない「業務適合性」を測る
なぜ、わざわざ自社で検証する必要があるのでしょうか。
それは、オープンソースのLLM（大規模言語モデル）の多くが英語圏で開発されており、日本語の細やかなニュアンスや、日本のビジネス慣習に対する理解度に大きなばらつきがあるからです。
例えば、パラメータ（AIの規模を示す指標）の数が数百億ある大規模モデルでも、日本語の学習データが少なければ、数十億パラメータの日英チューニング済みモデルに実務性能で劣ることがあります。また、「要約」は得意でも「論理的推論」は苦手、あるいはその逆といった特性も、実際にタスクをさせてみないと分かりません。
この検証スイートは、以下の3つの観点を明確にするように設計されています。
- 指示従順性（Instruction Following）: 「〜しないでください」という否定命令や、フォーマット指定をどれだけ正確に守れるか。
- 日本語運用能力: 単に翻訳できるだけでなく、ビジネス文書として違和感のない自然な日本語が出力できるか。
- 安全性と制御性: 機密情報を適切に扱えるか、未知の質問に対して誠実に「分からない」と答えられるか。
検証環境の前提（Ollama/LM Studio等）
本記事のプロンプトを試すにあたり、高価なGPUサーバーをいきなり購入する必要はありません。まずは手元のPC（MacBook ProのMシリーズチップ搭載機や、NVIDIA製GPUを積んだWindows機）で十分検証可能です。
推奨ツールは以下の通りです。
- Ollama: コマンドラインで手軽にモデルを切り替えてテストできます。エンジニア向けです。
- LM Studio: 画面上のチャット形式でテストでき、システムプロンプトの変更も容易です。非エンジニアにも扱いやすくおすすめです。
検証対象とするモデルは、進化が著しい以下のシリーズから選定することをお勧めします。
- Llamaシリーズ: Meta社の代表的なモデル。最新版ではメモリ効率が向上しており、一般的なパソコンでも実用的な推論（回答生成）が可能です。
- Mistralシリーズ: フランスMistral AI社のモデル群。汎用的なモデルに加え、エッジデバイス（端末側）向けの軽量モデルやコード生成に特化したモデルなど、用途に応じた選択肢が豊富です。
- Gemma / Phi / Qwen: GoogleのGemma、MicrosoftのPhiシリーズ、AlibabaのQwenなど、日本語性能やコストパフォーマンスに優れたモデルも有力な候補となります。
最新情報は各公式サイトなどで確認し、自社のハードウェア環境で動作するサイズ（パラメータ数）のモデルを選択してください。
評価スコアリングシートの使い方
検証を行う際は、漫然とチャットをするのではなく、エクセルやスプレッドシートに記録を残すことが重要です。仮説検証の観点から、以下の5段階評価をつけることをお勧めします。
- 5点（実用レベル）: 修正なしでそのまま業務に使える。
- 4点（軽微な修正必要）: 内容は合っているが、語尾や形式に微修正が必要。
- 3点（要指示改善）: プロンプトを工夫すれば使えるが、不安定。
- 2点（実用困難）: 指示を無視する、または致命的な誤りがある。
- 1点（崩壊）: 日本語が崩れている、または応答しない。
これをモデルごとに記録することで、導入の意思決定や稟議を通す際の、実証データに基づいた強力なエビデンスになります。
2. プロンプト設計の基本：ローカルLLM特有の挙動制御
検証に入る前に、技術的な前提を分かりやすく共有します。クラウド上の大規模モデル（ChatGPTなど）と、オンプレミスで動作させる軽量なローカルLLM（特に70億〜130億パラメータクラス）では、プロンプトに対する反応特性が大きく異なります。
軽量モデルでの指示従順性を高めるテクニック
パラメータ数が少ないモデルは、複雑な指示を一度に処理する能力に限界があります。「翻訳して、要約して、JSON形式に整形して」といった複数のタスクを一度に依頼すると、指示の一部が無視されたり、処理が途中で破綻したりするケースが散見されます。
ローカルLLMを確実に制御するための鉄則は「役割の明確化」と「構造化」です。
システムプロンプトによる役割定義
多くのローカルLLMは、System Prompt（「あなたは〜です」という前提定義）に強く影響を受けます。クラウド上のハイエンドモデルであれば曖昧な指示でも意図を汲み取ってくれますが、ローカルモデルでは初期設定が回答品質を大きく左右します。
- 悪い例: （指示なしでいきなり質問する）
- 良い例:
あなたは日本の金融機関に勤めるベテランのコンプライアンス担当者です。常に冷静で、正確かつ簡潔な日本語で回答してください。
この一文があるだけで、回答のトーンや精度が劇的に安定します。特に英語圏で開発されたモデルの場合、Answer in Japanese. と指示しても英語で返答されることがありますが、システムプロンプトで「日本語ネイティブの専門家」というペルソナを設定することで、日本語出力を強制しやすくなります。
コンテキスト長制限を考慮した入力設計
オンプレミス環境では、GPUメモリのリソース制約から、一度に処理できる文章の長さ（コンテキスト長）をクラウド版よりも短く設定せざるを得ない場合があります。
検証用プロンプトを作成する際は、モデルの混乱を防ぐために情報を明確に区分けすることが重要です。以下のようにタグを用いて構造化すると、軽量モデルでも内容を認識しやすくなります。
[役割定義]
あなたはセキュリティエンジニアです。
[制約条件]
- 専門用語には解説をつけること
- 300文字以内で回答すること
[入力テキスト]
（ここに解析対象のログデータを挿入）
[指示]
上記の入力テキストから異常値を検出してください。
このように[指示]、[制約条件]、[入力テキスト]を視覚的にも論理的にも分離することで、限られたリソースの中でモデルの推論能力を最大限に引き出すことが可能です。
3. 検証テンプレート①：日本語処理能力と指示追従性テスト
実際に検証を始めましょう。まずは基本となる「日本語力」と「指示を守る力」のテストです。
複雑な敬語・ビジネス文書の生成テスト
ビジネスメールや日報の作成は、LLMの定番タスクです。しかし、ローカルLLMは「過剰な敬語」や「不自然な直訳調」になりがちです。
【検証プロンプト】
[役割]
あなたは企業の広報担当者です。
[指示]
以下の事実に基づいて、取引先へ送る「システム障害のお詫びメール」を作成してください。
[事実]
- 発生日時: 2024年5月20日 14:00〜16:30
- 影響範囲: 顧客管理システムへのログイン不可
- 原因: サーバーのアクセス集中
- 現状: 復旧済み。再発防止策としてサーバー増強を予定。
[制約条件]
- 深刻になりすぎず、かつ誠実なトーンで。
- 冗長な表現は避け、300文字以内で。
- 件名は具体的に。
【評価の観点】
- 理想的な出力: 件名が「【お詫び】顧客管理システムの障害復旧のお知らせ」のように具体的か。本文で「ご迷惑をおかけし申し訳ございません」といった自然なクッション言葉が使えているか。
- 失敗パターン: 「私は広報担当者として、以下のメールを作成しました」という前置きが入ってしまう（メタ発言）。「深刻になりすぎず」という指示を誤解して、軽薄な文体になる。
出力フォーマット（JSON/Markdown）の強制テスト
社内システムにLLMを組み込む場合、出力は自然言語ではなく、プログラムが処理しやすいJSON形式であることが求められます。
【検証プロンプト】
[指示]
以下の会議メモから、決定事項（decisions）とネクストアクション（actions）を抽出し、指定されたJSONフォーマットのみを出力してください。解説や前置きは一切不要です。
[会議メモ]
田中: 次回の定例会は来週の火曜日にずらしましょう。
鈴木: 了解です。場所は第2会議室を予約しておきます。
佐藤: 資料の修正版は、私が明日の昼までに共有フォルダに入れておきますね。
[出力フォーマット]
{
"decisions": [string],
"actions": [
{"who": string, "what": string, "deadline": string}
]
}
【評価の観点】
- 理想的な出力: 純粋なJSON文字列のみが返ってくること。
- 失敗パターン: JSONの前後に ```json や 「はい、JSONを出力します」といった余計なテキストが付く（システム連携時のエラーの原因になります）。
deadlineの日付推論（来週の火曜日など）が間違っている。
このテストでは、Mistralの最新版やLlamaシリーズといった主要なオープンモデルは、指示追従性が高く比較的好成績を残す傾向にあります。特にMistral AIのモデル群は、構造化データの出力精度も向上しています。一方で、古い世代のモデルや調整不足のモデルでは、JSONの括弧を閉じ忘れたり、指示に含まれない解説を付加したりするケースが散見されるため、必ず実機での検証が必要です。
4. 検証テンプレート②：機密文書処理と匿名化能力テスト
オンプレミスLLMを導入する最大の動機は「セキュリティ」です。ここでは、個人情報の匿名化処理能力をテストします。
PII（個人識別情報）の検出とマスキング
【検証プロンプト】
[指示]
以下のテキストに含まれる個人名、電話番号、メールアドレスを検出し、それぞれ [NAME], [PHONE], [EMAIL] に置換してください。会社名や部署名はそのままにしてください。
[入力テキスト]
株式会社テックフューチャーの人事部、山田太郎です。緊急の連絡は 090-1234-5678 または t.yamada@techfuture.example.com までお願いします。同僚の鈴木花子さんもCCに入れています。
【評価の観点】
- 理想的な出力: 「株式会社テックフューチャーの人事部、[NAME]です。緊急の連絡は [PHONE] または [EMAIL] までお願いします。同僚の[NAME]さんもCCに入れています。」
- 失敗パターン: 「鈴木花子さん」を見落とす（文脈理解不足）。会社名までマスキングしてしまう（過剰検知）。置換せずに元のテキストを出力してしまう（指示無視）。
特に日本語の氏名は一般名詞（「森」や「林」など）との区別が難しく、軽量モデルでは苦戦するポイントです。ここを正確にクリアできるモデルは、実務適性が高いと判断できます。
5. 検証テンプレート③：RAG（検索拡張生成）適性テスト
企業のナレッジベース活用で主流となっているRAG（Retrieval-Augmented Generation：検索拡張生成）。ここでは、外部情報を参照させ、その内容に忠実に回答できるかを検証します。
文脈に基づいた回答生成とハルシネーション抑制
モデルが元々持っている知識（事前学習データ）と、与えられたコンテキスト（社内ドキュメント）が矛盾する場合や、情報がない場合にどう振る舞うかを確認します。
【検証プロンプト】
[指示]
あなたは社内ヘルプデスクAIです。以下の【社内規定】のみに基づいて、ユーザーの質問に答えてください。
規定に記載がない場合は、知識を捏造せず正直に「規定に記載がないため回答できません」と答えてください。
[社内規定]
交通費精算について：
- タクシー利用は原則禁止です。
- 深夜22時以降の退社に限り、上長の事前承認があればタクシー利用が認められます。
- 新幹線利用は、片道100km以上の場合に限り指定席料金が支給されます。
[ユーザーの質問]
出張で飛行機を使いたいのですが、ビジネスクラスは認められますか？
【評価の観点】
- 理想的な出力: 「規定に記載がないため回答できません。」
- 失敗パターン: 「ビジネスクラスは原則認められません」や「役員であれば認められます」など、一般的な常識やもっともらしい嘘を回答してしまう。
この「知らないことを知らないと言える能力」は、RAGシステムにおいて最も重要です。Command RシリーズやLlamaの最新版、そしてコンテキスト処理能力が強化されたMistralの最新版などは、この指示に従う能力が高い傾向にあります。特に最新のモデル群では、長い文章を読み込めるようになっていますが、情報量が増えるほどハルシネーションのリスクも高まるため、プロンプトでの強い制約が依然として不可欠です。
6. 導入判断のための評価マトリクスと次のステップ
検証結果の可視化と重み付け評価
ここまで3つのテンプレートで検証を行ってきました。結果はいかがでしたか？
おそらく、「日本語は流暢だが、JSON出力が苦手なモデル」や、「指示には忠実だが、日本語が不自然なモデル」など、それぞれの特性が見えてきたはずです。
選定の際は、自社の優先順位に合わせて重み付けを行います。最新のモデル動向を踏まえると、以下のような傾向が見られます。
- チャットボット用途: 日本語の自然さ（流暢性）を最優先。一般的な汎用モデルが適しています。
- データ処理・分析・コーディング用途: 指示従順性とJSON出力能力を最優先。特にMistral AIの最新モデル群などが強みを発揮するケースがあります。
- 検索システム（RAG）用途: ハルシネーションの少なさを最優先。コンテキスト理解に優れたモデルを選定します。
ハードウェア要件とPoCへのロードマップ
モデルが決まったら、次はそれを動かすハードウェアの選定です。最近では小型かつ高性能なモデルも登場しており、選択肢は広がっています。
- 小規模・エッジ向け（30億〜80億パラメータクラス）:
- 対象: Llama（8Bクラス）、Mistral（7Bクラス）など。
- 要件: VRAM 12GB〜16GB程度のGPU、またはMac Studioで快適に動作します。部門導入や開発者個人の環境に最適です。
- 中規模・特化型（120億〜200億パラメータクラス）:
- 対象: コーディング特化モデルなど。
- 要件: VRAM 24GB程度での運用が現実的です。
- 大規模・全社基盤（700億パラメータクラス以上）:
- 対象: Llama（70Bクラス）、Mistralの最新版相当など。
- 要件: VRAM 48GB以上が必要です。業務用のハイエンドGPU、あるいは複数枚のGPU構成が必要になります。
専門家からのアドバイス
いきなり高価なサーバーを購入する前に、まずは手元の環境やクラウドのGPUインスタンスを一時的に借りて、仮説検証を行うことを強く推奨します。
また、一部の最新モデルはクラウドAPI経由でも提供され始めています。オンプレミス環境を構築する前に、これらを利用して「モデルの能力自体」を安価に検証するのも、効率的で実践的なアプローチです。
「動く」ことと「業務に使える」ことは異なります。この検証プロセスこそが、AI導入を成功に導く確かな道筋となります。
まとめ
オンプレミスでのLLM活用は、セキュリティとコストの面で大きなメリットがありますが、モデル選定を誤るとプロジェクトは期待した成果を上げられません。今回提供した検証用プロンプトは、そのリスクを最小限に抑え、実証に基づいた判断を下すためのものです。
- 日本語能力と指示従順性は別物と心得る。
- JSON出力や否定命令など、制御能力をテストする。
- 「分からない」と言えるか、RAG適性を厳しくチェックする。
これらをクリアしたモデルだけが、業務を支える信頼できるシステムとなり得ます。
コメント