実務で使える日本語Llamaモデルはどれだ？エージェント構築のための実践的評価プロンプト集

はじめに

「Hugging Faceのリーダーボードでスコアが高かったので採用したのに、実際にエージェントに組み込んでみたら全く使い物にならなかった」

実務の現場では、このような課題に直面するケースが急増しています。特にLlamaモデルの登場以降、日本語化された派生モデルが次々と公開され、選択肢が広がった反面、選定の難易度は格段に上がりました。

JGLUEなどの一般的なベンチマークは、モデルの基礎体力を測るには有用ですが、開発現場で構築しようとしている「AIエージェント」の実務能力を保証するものではありません。エージェントに必要なのは、単なる知識量ではなく、「曖昧な指示を解釈し、論理的に計画を立て、システムが理解できる形式で出力する能力」だからです。

今回は、実際のプロジェクトでモデル選定を行う際に有効な「評価プロンプト」のテンプレートを解説します。これらは、あえてモデルがミスしやすいポイントを突くように設計されています。

この記事を読み終える頃には、自社の要件に最適なモデルを見極めるための実践的な評価手法が身についているはずです。スコア表の比較にとどまらず、実際にモデルの実力をテストしていくことが重要です。

1. スコアに頼らないモデル選定の重要性

なぜ、公開されているベンチマークスコアと、現場での実感にこれほどの乖離が生まれるのでしょうか。まずはその構造的な理由を理解し、プロジェクトにおいて目指すべき評価の方向性を定めましょう。

リーダーボードと実務性能の乖離

多くの日本語LLMランキングで用いられる指標は、クイズの正答率や文章の要約精度などが中心です。これらは「静的」なタスクです。一方で、AIエージェントが求められるのは「動的」なインタラクションです。

例えば、ユーザーが「来週の会議の準備をして」と言ったとき、エージェントは以下を行う必要があります。

1. 「会議」の日時や参加者を特定するためにカレンダーを参照する（ツール使用の判断）
2. 不足情報をユーザーに質問する（対話管理）
3. アジェンダ案を作成し、JSON形式でフロントエンドに返す（構造化出力）

この一連の流れの中で、一度でもフォーマットを間違えたり、文脈を見失ったりすれば、システム全体がエラーになります。ベンチマークスコアが高いモデルが、必ずしも「システムの一部として行儀よく振る舞える」わけではないのです。

エージェント構築に必要な3つの特化能力

AIエージェント向けのモデルを選定する際、特に重視すべきなのは以下の3点です。

• Instruction Following（指示追従性）: 「〜しないでください」という否定命令や、複雑な制約条件をどれだけ厳格に守れるか。
• Reasoning（推論能力）: 曖昧なゴールから具体的なタスク手順を論理的に導き出せるか。
• Formatting（フォーマット遵守）: JSONやXMLなど、指定された出力形式を1文字のミスもなく生成できるか。

このテンプレート集の使い方

これから紹介する4つのテンプレートは、これらの能力を個別に、かつ厳密にテストするためのものです。複数の候補モデル（例：ElyzaやSwallowといった日本語継続事前学習モデル、あるいはLlamaの最新軽量モデルなど）に対して同じプロンプトを入力し、その出力を横並びで比較する「A/Bテスト」を実施してください。

重要なのは「正解すること」よりも、「どのように間違えるか」を観察することです。そのミスが、許容できるもの（プロンプト調整で直るもの）なのか、致命的なもの（モデルの特性によるもの）なのかを見極めることが、選定の鍵となります。

2. 評価プロンプト設計のフレームワーク

無計画にプロンプトを入力するだけでは、公平な評価は困難です。ここでは、モデルの実力を引き出しつつ、弱点を露呈させるための設計思想を共有します。

評価タスクの分解（理解・推論・出力）

プロンプトは、モデルの処理プロセスに合わせて3段階で評価できるように構成します。

1. 入力の理解: 日本語のニュアンスや前提条件を正しく汲み取れているか。
2. 思考プロセス: 結論に至るまでの論理展開に飛躍がないか。
3. 出力生成: 指定された文字数、文体、フォーマットを守れているか。

特に日本語Llamaモデルの場合、学習データの偏りにより、「理解はできているが、出力が英語になってしまう」ケースや、「流暢な日本語だが、論理が破綻している」ケースが散見されます。どこでつまずいたのかを切り分けることが重要です。

あえて「意地悪な」指示を含める理由

正常系のテスト（素直な質問をして回答させる）だけでは、モデルの堅牢性は測れません。実運用では、ユーザーは不完全な入力をしますし、システム連携時には予期せぬデータが渡されることもあります。

そのため、評価プロンプトには以下のような「意地悪な要素（ノイズ）」を意図的に混ぜます。

• 矛盾する指示: 「短く答えて」と「詳細に説明して」を同時に含める（優先順位の判断を見る）。
• 無関係な情報: コンテキストに全く関係のないノイズ情報を混ぜる（情報の選別能力を見る）。
• 否定命令: 「挨拶は絶対にしないでください」といった禁止事項を入れる（抑制能力を見る）。

評価基準（ルーブリック）の策定

出力結果を主観で判断しないよう、事前に採点基準を決めておきます。実務においては、以下のような5段階評価を用いることが効果的です。

• 5点: 指示を完璧に守り、内容も正確で自然。
• 4点: 内容は正確だが、日本語表現にわずかな違和感がある。
• 3点: 主要な指示は守れているが、細かい制約（文字数など）を違反。
• 2点: ハルシネーション（嘘）がある、またはフォーマット違反がある。
• 1点: 指示を理解していない、または崩壊した日本語/英語での回答。

次章から、具体的なテンプレートを見ていきましょう。

3. テンプレート①：複雑な指示追従と日本語ニュアンス（基礎編）

まずは基礎体力測定です。ビジネスメール作成という身近なタスクを通じて、複数の制約条件を同時に処理できるか、そして日本語の敬語やニュアンスを適切に扱えるかをテストします。

テストの目的：敬語と制約条件の遵守

Llamaモデルベースのモデルは、英語圏の文化が色濃く残っている場合があります。過度にフレンドリーすぎたり、直訳調の不自然な敬語になったりしないかを確認します。また、「否定命令（〜しないで）」はLLMが苦手とする典型的な指示です。

評価用プロンプト

以下のプロンプトを各モデルに入力してください。

### 指示
あなたはカスタマーサポートの責任者です。以下の状況に基づき、顧客への謝罪メールを作成してください。

### 状況
- 顧客名：佐藤様
- トラブル：システム障害により、2時間サービスが利用できなかった。
- 原因：サーバーの誤設定（人為的ミス）。
- 補填：来月の利用料を10%割引する。

### 制約条件
1. 文体は「丁寧語（です・ます）」を使用し、過度にへりくだった「謙譲語」は避けること。
2. 原因が「人為的ミス」であることは正直に伝えるが、言い訳がましくならないようにすること。
3. メールの冒頭と結び以外に、定型的な挨拶文（「お世話になっております」等）を繰り返さないこと。
4. 全体を400文字以内でまとめること。
5. 件名は含めず、本文のみを出力すること。

チェックポイントと合格基準

このプロンプトに対する出力例を見てみましょう。

【良いモデルの出力例】

佐藤様

この度は、弊社サービスにおいてシステム障害が発生し、多大なるご不便をおかけしましたことを深くお詫び申し上げます。

障害の原因は、弊社のサーバー設定における人為的なミスによるものでした。管理体制を見直し、再発防止に努めてまいります。

今回のご迷惑へのお詫びとして、来月分の利用料金を10%割引させていただきます。割引は次回の請求時に自動的に適用されます。

今後とも変わらぬご愛顧を賜りますようお願い申し上げます。

カスタマーサポート責任者

【悪いモデルの出力例（よくある失敗）】

件名：システム障害に関するお詫び

佐藤様、

いつもお世話になっております。この度は申し訳ございません。
開発チームがサーバーの設定を間違えてしまったため、2時間も使えませんでした。これはヒューマンエラーです。本当にすみません。

補填として10%オフにします。

お世話になっておりますが、今後もよろしくお願いします。

判定のポイント:

1. 制約違反: 「件名は含めず」という指示を無視して件名を入れているモデルは減点対象です。
2. 日本語の質: 悪い例では「開発チームが〜間違えてしまった」といった直訳調の表現や、「10%オフにします」というビジネスに不適切なフランクさが目立ちます。
3. 否定命令の無視: 「定型的な挨拶文を繰り返さない」といっているのに、文中で再度挨拶をしてしまうケースも多々あります。

4. テンプレート②：推論とタスク分解（ReAct/CoT評価）

次に、AIエージェントの頭脳となる「推論能力」をテストします。ユーザーの曖昧な願いを、実行可能なタスクに分解できるかどうかは、自律型エージェントにとって最も重要な能力です。

テストの目的：思考プロセスの論理性

ここでは、Chain of Thought（思考の連鎖）を促し、モデルがどのように問題を解決しようとしているかを可視化させます。「やって」と言われたことだけでなく、そのために「何が必要か」を補完できるかが評価軸です。

評価用プロンプト（Chain of Thought）

### 指示
あなたは企業の総務担当AIアシスタントです。
ユーザーから以下の依頼を受けました。この目標を達成するために必要なタスクを、時系列順に5ステップ以内でリストアップしてください。
各ステップには、なぜそのタスクが必要なのかの「理由」も併記してください。

### ユーザーの依頼
「来週から新入社員が3名入るんだけど、PCとアカウントの準備を急いでお願いできるかな？ちなみに1名はデザイナーだよ。」

### 出力フォーマット
1. [タスク名]: [理由]
2. [タスク名]: [理由]
...

エージェントとしての自律性判定

【良いモデルの出力例】

1. 必要なスペックとソフトウェアの確認: デザイナー職が含まれるため、通常の事務用PCとは異なるハイスペックなPCや専用ソフト（Adobe等）の手配が必要か確認するため。
2. PCの在庫確認と発注: 社内に要件を満たすPCの在庫があるか確認し、不足している場合は急ぎ発注を行うため（納期を考慮）。
3. 社内アカウント（メール・Slack等）の作成: 入社当日から業務連絡やツール利用ができるよう、3名分のアカウントを事前に発行するため。
4. キッティング（初期設定）とソフトインストール: デザイナー用ソフトを含め、業務に必要な環境をPCにセットアップするため。
5. ログイン情報の通知書の作成: 入社当日に新入社員へスムーズにPCとアカウント情報を引き渡す準備をするため。

【悪いモデルの出力例】

1. 新入社員に挨拶する: マナーとして大切だから。
2. PCを買う: PCがないと仕事ができないから。
3. アカウントを作る: ログインに必要だから。
4. 歓迎会を予約する: 親睦を深めるため。
5. 上司に報告する: 完了したことを伝えるため。

判定のポイント:

• コンテキストの拾い上げ: 良い例では「1名はデザイナー」という情報から、「ハイスペックPCや専用ソフトが必要」という推論を導き出しています。これができていないモデルは、エージェントとしては不適格です。
• 具体性: 悪い例はタスクが抽象的すぎます。「急いで」という文脈を汲み取り、在庫確認や発注を優先する判断ができているかも重要です。

5. テンプレート③：構造化データ出力とFunction Calling（実装編）

実務において最もトラブルの要因となりやすいのが、この「構造化データ出力」です。APIを叩くためのJSONが正しく生成されなければ、システムは動きません。

テストの目的：システム連携の安定性

特に日本語Llamaモデルは、JSONの中に日本語の解説を勝手に混ぜたり、キー名を勝手に翻訳したりする癖が出ることがあります。これを厳密にチェックします。

評価用プロンプト（JSON強制）

### 指示
以下の製品情報を解析し、指定されたJSONスキーマに従ってデータを出力してください。
出力はJSONデータのみとし、前後の挨拶や解説文（「はい、JSONを生成します」など）は一切含めないでください。

### 製品テキスト
「新発売の『スマートマグ Pro』は、税込3,980円で販売中。色はブラックとホワイトの2色展開。バッテリーは最大8時間持ちます。型番はSM-001です。」

### JSONスキーマ
{
  "product_name": "string",
  "price": "integer (税抜価格)",
  "colors": ["string"],
  "specs": {
    "battery_life": "string",
    "model_number": "string"
  }
}

### 注意点
- priceは税抜価格（消費税10%として計算）を整数で入力すること。

パースエラー耐性の確認

【良いモデルの出力例】

{
  "product_name": "スマートマグ Pro",
  "price": 3618,
  "colors": [
    "ブラック",
    "ホワイト"
  ],
  "specs": {
    "battery_life": "最大8時間",
    "model_number": "SM-001"
  }
}

【悪いモデルの出力例】

はい、ご指示のJSONを作成しました。

{
  "product_name": "スマートマグ Pro",
  "price": "3980円",  // 税込みのまま、かつ文字列になっている
  "colors": "ブラック、ホワイト", // 配列になっていない
  "specs": {
    "battery": "8時間" // キー名が勝手に変更されている
  }
}

判定のポイント:

1. 余計なテキスト: 冒頭の「はい、〜」が含まれていると、システム側でJSONパースエラー（JSONDecodeError）が発生します。これを含まないモデルは優秀です。
2. 型変換と計算: 「税込3,980円」から「税抜3,618円（または3619円）」を計算し、かつinteger型で出力できるか。悪い例のように文字列や税込のまま出力するモデルは、Function Callingには向きません。
3. スキーマ遵守: 指定されたキー名（model_numberなど）を勝手に変えたり省略したりしていないか確認します。

6. テンプレート④：RAG想定のコンテキスト理解（応用編）

最後に、社内ドキュメント検索（RAG）システムへの組み込みを想定したテストです。外部知識（モデルが学習した知識）と、与えられたコンテキスト（検索結果）を区別できるかが重要です。

テストの目的：ハルシネーションの抑制

モデルは学習データに含まれる一般的な知識を優先して回答してしまう傾向があります。しかし、RAGでは「社内規定」など独自のルールに従う必要があります。ここでは、あえて一般的な常識とは異なる架空のルールを与え、それに従えるかを見ます。

評価用プロンプト（外部知識参照）

### 指示
あなたは社内規定を案内するAIです。以下の【社内規定】のみに基づいて、社員の質問に答えてください。
規定に記載がない場合は、適当に答えを作らず「規定には記載がありません」と答えてください。

### 社内規定
- 交通費の精算は、利用日の翌月末までに行うこと。
- タクシー利用は原則禁止だが、深夜24時以降の退勤に限り、部長の事前承認があれば利用可能。
- 出張手当は一律5,000円とする。

### 社員の質問
「昨日は大雨だったのでタクシーで帰りました。精算できますか？」

「知らない」と言える能力の評価

【良いモデルの出力例】

申し訳ありませんが、今回のケースでは精算できません。
社内規定では、タクシー利用は「深夜24時以降の退勤」かつ「部長の事前承認」がある場合に限られています。天候不良による利用に関する特例は記載されておりません。

【悪いモデルの出力例】

はい、精算可能です。悪天候時のタクシー利用は安全配慮義務の観点から認められる場合が多いです。領収書を添付して申請してください。

判定のポイント:

• 一般常識の排除: 悪い例では、モデルが学習済みの「一般的な会社の対応」を答えてしまっています（ハルシネーションの一種）。
• 条件の論理判定: 規定にある「深夜」「承認」という条件を満たしていないことを正しく指摘できているかが評価点です。

7. 選定結果の可視化と意思決定プロセス

4つのテンプレートによるテストが終わったら、結果を集計し、最終的なモデル選定を行います。しかし、精度だけで決めてはいけません。ビジネス実装には「コスト」と「速度」の観点が不可欠です。

評価マトリクスの作成方法

各モデルのテスト結果を5点満点で採点し、レーダーチャートを作成します。さらに、以下のシステム要件を掛け合わせて総合判断を下します。

• 推論速度 (Tokens/sec): エージェントがユーザーを待たせないか。
• VRAM消費量: 自社のインフラ（GPU）に収まるか。量子化（4bit/8bit）で精度がどう変化するか。
• ライセンス: 商用利用可能なライセンス（Apache 2.0, Llama Community License等）か。

コスト（VRAM/推論速度）と精度のトレードオフ

例えば、70Bクラスのモデル（Llama-3-70Bなど）は推論能力が圧倒的ですが、推論コストが高く、応答も遅くなりがちです。一方、8Bクラスのモデルは高速ですが、複雑な推論でミスが出やすいです。

推奨される選定フロー:

1. まず8Bクラスのモデル（Elyza-8B, Llama-3-8B-Instruct等）で上記のテストを行う。
2. テンプレート②（推論）や③（JSON）で合格点が出れば、8Bを採用（コストパフォーマンス最大）。
3. 8Bで精度不足なら、70Bモデルや、特定のタスクに特化したファインチューニングモデルを検討する。

最終決定のための稟議ロジック

ステークホルダーやチームにモデル選定を提案する際は、単に「スコアが良かったから」ではなく、以下のように論理的に説明することで説得力が増します。

「リーダーボード上のスコアはモデルAが高かったですが、当社のユースケースであるJSON出力と社内規定検索（RAG）のテストでは、モデルBの方がエラー率が80%低く、安定していました。また、モデルBは軽量であるため、月額のインフラコストもAの半分に抑えられます。したがって、実務適合性とROIの観点からモデルBを推奨します。」

まとめ

AIエージェントのためのモデル選定は、スペック表の比較ではなく、人材の採用面接に似ています。履歴書にあたるベンチマークが優れていても、実技試験にあたる評価プロンプトを実施しなければ、実際のプロジェクトに適合するかは判断できません。

今回解説した4つのテンプレートは、あくまで汎用的な初期評価の位置づけです。ここからさらに、自社特有のデータを組み込んだ詳細な検証へと進めることが求められます。

「評価環境を構築するのが手間だ」「もっと多角的な視点で検証したい」という場合は、専用の検証環境やツールを活用することをおすすめします。最新の日本語Llamaモデルを含む複数のLLMを、自社のデータを使って即座に比較・検証できる環境を整えることが、プロジェクト成功への近道となります。

モデル選定の課題を論理的に解決し、ROIの最大化とユーザーへの価値提供を実現するエージェント開発を推進していきましょう。