ローカルLLM PoCの評価シート。精度・速度・同時利用・運用負荷の4軸と合否ライン、自社データで精度を測る手順

Q: ローカルLLMの精度はどのくらいですか？

一般論では答えられません。精度は対象業務、文書の種類、モデルのサイズクラス、日本語追加学習の有無、RAGの検索設計で大きく変わります。判断に使えるのは、自社の実データで作った評価セットを候補モデルに通し、業務担当者が採点した合格率だけです。公開ベンチマークの順位は候補を絞る参考に使い、採用判断には自社データの評価を使ってください。

Q: ハルシネーションはどう数えますか？

合格率とは別に、根拠のない記述や読めない箇所の捏造の件数を数えます。評価セットに答えがない質問や判読できない箇所を意図的に含め、モデルが不明と返せたかを確認します。合格率が同じでも、黙って数字を変える型の誤りをするモデルは業務に使えません。

Q: 精度が合格ラインに届かないとき、まず何を直すべきですか？

プロンプトの修正、RAGの検索の見直し、モデルのサイズクラスの変更、ファインチューニングの順です。不合格例を、正しい文書を検索できていたかと、検索できたのに回答を間違えたかに分けると、原因が検索かモデルかが分かります。改善を1つ試すごとに同じ評価セットを通して効果を記録してください。

Q: 速度や同時利用の合格ラインはどう決めますか？

業務側が応答開始までの待てる秒数と同時に使う人数を決め、その条件で実測して判定します。生成速度はチャット対話で毎秒10トークン以上、コーディング補完で毎秒30トークン以上が目安です。同時利用は同時リクエスト数を1・2・5・10と段階的に増やして測ります。組み合わせで桁が変わるため、相場ではなく実測で判断してください。

「ローカルLLMの精度はどのくらいですか」という質問に、公開ベンチマークの順位で答えても検討は前に進みません。業務で問われるのは、自社の文書と自社の質問に対して、人手の修正なしで使える出力がどれだけ出るかです。これはベンチマークではなく、自社データで作った評価セットでしか測れません。本記事では、ローカルLLMのPoC（概念実証）で使う評価シートを、精度・速度・同時利用・運用負荷の4軸で設計し、そのまま使えるテンプレートと実施手順を示します。

撤退基準の考え方は『ローカルLLMのPoCで300万円溶かす前に。始める前に決める撤退基準』で扱いました。本記事はその一段下、「基準を判定するために何をどう測るか」に絞ります。評価セットの作り方、採点のやり方、合否ラインの置き方、評価結果が悪かったときに何から直すかまでを、業務担当者と情報システム部門が一緒に使える形で整理します。

この記事の要点

ローカルLLMの精度は公開ベンチマークではなく、自社の実データ30〜100件で作った評価セットで測ります。評価セットがないPoCは「動いた」で終わり、本番に進む根拠も止める根拠も残りません

評価は精度・速度・同時利用・運用負荷の4軸に分け、軸ごとに指標・測り方・合格ライン・担当を1枚のシートに書きます。精度だけで判断すると、本番で速度と運用に詰まります

精度の採点は、構築者ではなく業務担当者3人が、どのモデルの出力かを伏せて4段階で行います。ハルシネーションは「読めない」と言えたかどうかで別に数えます

合否ラインは採点の前に業務側が決め、文書にします。1つでも割ったら本番に進まないルールを先に握ると、投じた費用に引きずられずに判断できます

精度が足りないときの改善は、プロンプト→RAGの検索→モデルサイズ→ファインチューニングの順です。順番を飛ばしてモデルを大きくしても、原因が検索なら精度は上がりません

評価シートがないPoCは「動いた」で終わる

生成AIのPoCは、動かすこと自体は難しくありません。難しいのは、動いた結果を「本番に進める」「止める」のどちらかに結びつけることです。PwCの2026年春の調査では、生成AIの活用・推進度が87%に達した一方で、期待通り以上の効果を得ている企業は64%にとどまり、効果の評価を実施していない企業が13%あります。Gartnerは、生成AIプロジェクトの少なくとも30%がPoC後に頓挫すると予測し、原因の1つにビジネス価値の不明確さを挙げています。

評価シートがないPoCで起きることは決まっています。デモ用に用意したきれいな例文ではよく動き、現場の崩れた実データを入れると精度が落ちる。それでも「おおむね使えそう」という感触だけが残り、誰も数字で説明できないまま次の予算期を迎える。精度を問われれば「モデル次第」、速度を問われれば「機材次第」と答えるしかなく、稟議が書けません。

評価シートは、この状態を避けるための道具です。何を測るか、どう測るか、いくつなら合格か、誰が判定するかを、PoCを始める前に1枚にします。シートが埋まっていれば、結果が悪くても「どこが足りないか」が分かり、良ければ本番構成の根拠になります。

評価シートの全体像（4軸）

ローカルLLMのPoCで測るべき軸は4つです。精度だけを測るPoCが多いのですが、本番で詰まるのはむしろ速度・同時利用・運用負荷です。精度が合格でも、10人が同時に使うと待ち時間が業務に耐えない、更新を担う人がいない、という形で止まります。

軸	答える問い	主な指標	測り方	合格ラインを決める人
1. 精度	人手の修正なしで使える出力がどれだけ出るか	合格率、ハルシネーション件数、タスク別指標	自社データの評価セットを候補モデルに通し、業務担当者3人がブラインド採点	業務部門
2. 速度	1人で使ったときに待てるか	最初の1トークンまでの時間、生成速度、長文入力時の劣化	評価セットのうち長短の入力を選び、実機で計測	業務部門と情報システム部門
3. 同時利用	想定人数が同時に使ったときに待てるか	同時リクエスト数ごとの待ち時間と生成速度	同時リクエスト数を段階的に増やして計測	情報システム部門
4. 運用負荷	本番後に誰が何時間かけて維持するか	月あたりの運用工数、担当者の有無、障害時の復旧手順	PoC期間中に発生した作業を記録し、本番の頻度に換算	情報システム部門と経営

4軸それぞれに「指標」「測り方」「合格ライン」「担当」を書き込んだものが評価シートです。合格ラインの欄だけは、測る前に埋めます。測ってから決めると、出た数字に合わせてラインが動きます。

軸1 精度: 自社データで評価セットを作る

精度の評価は、評価セットの質で決まります。公開ベンチマークの順位は候補モデルを絞る参考にはなりますが、自社の業務で使えるかの判定には使えません。日本語の業務文書は、表記揺れ、社内用語、崩れたレイアウトを含み、ベンチマークの設問とは性質が違うからです。

評価セットの作り方（30〜100件）

対象業務を1つに絞ります。「この帳票の項目抽出」「この問い合わせの分類」のレベルまで具体化します。業務が複数あるなら、業務ごとに評価セットを分けます
現場の実データから抜き出します。件数は、モデル選定のミニ検証なら30〜50件、本番判断の業務PoCなら50〜100件が目安です。件数を増やすことより、業務のばらつき（長い文書、短い文書、例外的な書式、古い様式）を代表する例が入っているかを優先します
失敗しやすい例を意図的に入れます。固有名詞、数値と単位、否定表現、表の中の項目、手書きやFAXの低品質画像など、モデルが間違えやすい箇所を含めないと、評価が甘くなります
正解データを人手で用意します。要約なら「含まれていなければならない要点」、抽出なら項目ごとの正解値、分類なら正解ラベル、検索回答なら根拠となる文書の箇所を書きます。正解が一意に決まらないタスクは、「許容できる出力の条件」を文章で書きます

評価セットに使うデータは、社外に出さない前提で扱います。候補モデルがクラウドAPIを含む場合は、個人情報や機密をマスキングした版を使うか、ローカルで動くモデルだけを対象にします。

タスク別の指標

精度の指標はタスクで変わります。「合格率」と一言で言わず、何を数えるかを先に決めます。

タスク	数える指標	正解データの形	合格ラインの例の置き方
要約	必須要点の網羅率、事実と異なる記述の件数	要点の箇条書き	必須要点を全部含む出力の割合
社内文書の検索回答（RAG）	根拠文書を正しく参照した割合、根拠のない記述の件数	根拠箇所と期待する回答	根拠付きで正答した割合
分類・仕分け	ラベルの一致率、迷いやすいラベル間の誤り	正解ラベル	一致率と、重大な取り違えがゼロか
項目抽出（帳票・契約書）	項目ごとの一致率、読めない箇所を捏造した件数	項目別の正解値	項目別一致率と捏造ゼロ
翻訳	誤訳、訳抜け、用語、自然さ	参考訳または許容条件	誤訳・訳抜けの件数上限

翻訳の採点軸は『ローカルLLMで翻訳する2026』で、RAGの検索精度の見方は『社内文書RAGの作り方2026』で詳しく扱っています。

採点のやり方（4段階・3人・ブラインド）

4段階で採点します。「そのまま使える」「軽微な修正で使える」「大幅な修正が必要」「使えない」の4段階にし、合格率は上2つの割合で出します。「軽微」の定義（例: 1か所の語句修正まで）は採点前に決めます
業務担当者3人が採点します。構築者は自分の出力に甘くなります。対象業務を日常的に担当している人2人と、品質を判断できる人1人の3人にします。3人の採点が割れた件は、割れた理由を記録します。そこが合格ラインの境界です
どのモデルの出力かを伏せます。候補モデルが複数あるときは、出力を混ぜて提示します。モデル名が見えると、評判に引きずられます
同じ評価セット、同じ採点者で全候補を通します。途中で評価セットを変えると、候補間の比較ができなくなります

ハルシネーションは別に数える

合格率とは別に、ハルシネーション（根拠のない記述、読めない箇所の捏造）の件数を数えます。合格率が高くても、残りの不合格が「黙って数字を変える」型の誤りなら、業務では使えません。逆に、読めない箇所を「不明」と返したものは、修正が必要でも捏造ではありません。評価セットには、意図的に「答えがない質問」「判読できない箇所」を含め、モデルが分からないと言えるかを確かめます。

軸2 速度: 2つの数字を分けて測る

速度は「速い・遅い」ではなく、2つの数字に分けて測ります。

最初の1トークンまでの時間。入力を送ってから応答が始まるまでの待ち時間です。長い文書を読ませる用途では、ここが体感を決めます
生成速度（毎秒トークン数）。応答が始まってからの文字の出る速さです。チャット対話で毎秒10トークン以上、コーディング補完で毎秒30トークン以上が許容ラインの目安です

測り方は、評価セットから入力の短いもの、長いもの（想定する最長の文書）を選び、同じ機材で複数回計測して中央値を取ります。長文入力で最初の1トークンまでの時間がどれだけ伸びるかは、必ず別に記録します。RAGで長い文脈を渡す構成では、ここが業務に耐えないことがあります。

速度の見積もりには、機材のメモリ帯域とモデルの占有サイズから予測する方法があります。計算の仕方と機材別の目安は『ローカルLLMの速度はメモリ帯域で決まる』で解説しています。PoCでは予測値と実測値の両方をシートに書き、ずれが大きければ原因（量子化、推論エンジンの設定、文脈長）を記録します。

軸3 同時利用: 想定人数で待ち時間を測る

1人で使ったときの速度は、1人のときにしか出ません。複数人が同時に使うと、推論エンジンが要求をまとめて処理するか順番に処理するかで、1人あたりの速度の落ち方が変わります。

測り方は次のとおりです。

想定する同時利用人数を業務側から聞きます。「部門50人が使う」なら、同時に使うのは昼休み明けの数人から十数人、のように同時接続のピークを見積もります
同時リクエスト数を1、2、5、10のように段階的に増やし、各段階で最初の1トークンまでの時間と生成速度を測ります
想定ピークで、業務側が決めた待ち時間の上限（例: 応答開始まで何秒まで待てるか）を超えるかを確認します
超えるなら、機材の追加、モデルの小型化、推論エンジンの変更（試作用から本番用へ）のどれで解決するかを候補として記録します

ここは数値の相場を書けません。モデル、量子化、機材、推論エンジンの組み合わせで桁が変わるためです。だからこそ、想定人数での実測をPoCの成果物に含めます。社内設置の実現性検証では、この同時利用の実測を貸出機材で行い、推奨構成と一緒に報告します。

軸4 運用負荷: PoC期間中の作業を記録する

運用負荷は、PoCで最も測られない軸です。測り方は単純で、PoC期間中に発生した作業（モデルの入れ替え、推論エンジンの更新、設定変更、障害、利用者からの問い合わせ）を全部記録し、本番で想定される頻度に換算します。

作業の種類	PoC中に記録すること	本番換算の見方
モデル・推論エンジンの更新	何回、誰が、何時間かけたか、切り戻しが必要だったか	3〜6ヶ月ごとに発生する前提で年間工数にする
障害対応	応答停止やメモリ枯渇の回数、復旧にかかった時間	利用者が増えたときの頻度を見積もる
利用者からの問い合わせ	使い方、精度への不満、権限の変更	利用者数に比例させる
評価の再実施	評価セットを通し直した回数と時間	モデル更新ごとに必ず発生する

平常月で月1〜2人日程度、モデルの世代交代や脆弱性対応が重なる月で3〜5人日が目安です。この工数を担う人が社内にいるか、外部の保守に出すかを、PoCの結論に含めます。運用担当者の不在は導入挫折の最大要因で、『導入したローカルLLM、誰が維持するのか』で体制の3パターンを整理しています。

合否ラインの決め方

合否ラインは、3つの原則で決めます。

業務側が決めます。精度の合格率は「人手の一次チェックをどれだけ減らせれば投資に見合うか」で決まり、これは業務部門にしか分かりません。情報システム部門や構築者が決めると、技術的に達成しやすい数字になります
採点の前に決めて文書にします。測ってから決めると、出た数字にラインが寄ります。「評価セット100件で、そのまま使えると軽微な修正の合計が80%以上」のように、採点前に書き、関係者の合意を取ります
1つでも割ったら本番に進みません。精度が合格でも、同時利用で待ち時間の上限を超えたなら止めるか、対象を絞って再検証します。「精度は良かったから進めよう」は、PoC止まりの典型的な入り口です

ラインの数字自体に正解はありません。80%という例は、始める前に関係者が合意した数字であることに意味があります。合意の取り方と、割ったときの選択肢（クラウド継続、対象業務の縮小、時期を待つ）は撤退基準の記事を参照してください。

評価結果の読み方と「精度向上」の順番

評価の結果、精度が合格ラインに届かないことは珍しくありません。ここで大きいモデルに替えるのは、たいてい順番が違います。改善は原因の切り分けに沿って、安いものから順に試します。

順番	手段	効く症状	費用と期間
1	プロンプトの修正（指示の具体化、出力形式の固定、例示の追加）	出力形式が揺れる、指示を無視する、冗長	数時間〜数日
2	RAGの検索の見直し（文書のパース、分割の単位、検索方式、リランク）	回答の根拠がずれる、文書にある情報を見つけられない	数日〜2週間
3	モデルのサイズクラスを上げる、日本語追加学習済みモデルに替える	日本語が不自然、長文で一貫性が崩れる、推論が浅い	機材の見直しを伴うことがある
4	ファインチューニング（LoRA）	社内の文体・様式に揃えたい、特定の分類基準を覚えさせたい	データ作成が成否の8割。数週間〜

RAGの精度不足は、モデル本体よりも文書の読み込みと検索の設計が原因であることが大半です。モデルを大きくする前に、評価セットの不合格例を「検索で正しい文書を取れていたか」「取れていたのに回答が間違ったか」に分けて数えます。前者なら検索の問題で、後者ならモデルの問題です。この切り分けの仕方は『社内文書RAGの作り方2026』で、LoRAに進むべきかRAGで足りるかの判断は『LoRAで自社データをローカルLLMに学習させる』で扱っています。

改善を1つ試すたびに、同じ評価セットを通し直して合格率の変化を記録します。評価セットは、こうして「何を変えたら何%上がったか」の記録と一緒に資産になります。モデルが新しくなったときも、同じセットを通せばすぐに再判定できます。

評価シートのテンプレート

以下をそのまま表計算ソフトに写して使えます。合格ラインの列は、測る前に埋めます。

軸	指標	測り方	合格ライン（測る前に記入）	判定	担当
精度	合格率（そのまま使える＋軽微な修正）	評価セット __件、採点者3人、ブラインド	__%以上		業務部門
精度	ハルシネーション件数	根拠のない記述・捏造の件数	__件以下		業務部門
精度	タスク別指標（網羅率・一致率など）	タスクに応じて	__以上		業務部門
速度	最初の1トークンまでの時間（短文・長文）	各5回計測の中央値	長文で__秒以内		情報システム部門
速度	生成速度（毎秒トークン数）	同上	毎秒__トークン以上		情報システム部門
同時利用	想定ピーク__人での応答開始までの時間	同時リクエスト数1・2・5・10で計測	__秒以内		情報システム部門
運用負荷	月あたりの運用工数（人日）	PoC中の作業記録を本番頻度に換算	__人日以内、担当者の当てがある		情報システム部門・経営
全体	判定	1つでも割ったら本番に進まない		進む／対象を絞って再検証／止める	全員

このシートに、評価セットの保管場所、採点者の氏名、採点日、候補モデルとバージョン、機材と推論エンジンの設定を添えて、PoCの成果物にします。

評価の実施チェックリスト

実現性検証・ミニ検証・業務PoCのどこで何を測るか

評価の4軸は、PoCの段階によって測る範囲が違います。

段階	測る軸	評価セットの規模
社内設置の実現性検証（2週間）	速度、同時利用、運用負荷。精度は含まない	速度計測用に代表的な入力を数件
モデル選定ミニ検証（約30万円・2週間）	精度（候補モデルの比較）	実データ10〜50件
業務PoC（1〜2ヶ月）	4軸すべて	実データ50〜100件

「置けるか」を判定する実現性検証では、精度ではなく速度・同時利用・設置条件を貴社の機材条件で実測します。精度を問うならミニ検証か業務PoCを組み合わせます。段階の設計と費用は『ローカルLLM PoCの費用・期間・進め方』で整理しています。評価シートの合格ラインと撤退基準を稟議書にどう書くかは『ローカルLLM PoCの稟議書テンプレート』を参照してください。

まとめ

ローカルLLMの精度は、公開ベンチマークではなく自社の実データで作った評価セット（30〜100件）で測ります。評価セットがないPoCは「動いた」で終わります
評価は精度・速度・同時利用・運用負荷の4軸に分け、軸ごとに指標・測り方・合格ライン・担当を1枚のシートにします
精度の採点は業務担当者3人が、モデル名を伏せて4段階で行い、ハルシネーションは別に数えます
合格ラインは採点前に業務側が決めて文書にし、1つでも割ったら本番に進まないルールを先に合意します
精度が足りないときは、プロンプト→RAGの検索→モデルサイズ→ファインチューニングの順に、同じ評価セットで効果を測りながら改善します

よくある質問

Q. ローカルLLMの精度はどのくらいですか？

一般論では答えられません。精度は、対象業務、文書の種類、モデルのサイズクラス、日本語追加学習の有無、RAGの検索設計で大きく変わります。判断に使えるのは、自社の実データで作った評価セットを候補モデルに通し、業務担当者が採点した合格率だけです。公開ベンチマークの順位は候補を絞る参考に使い、採用判断には自社データの評価を使ってください。

Q. 評価セットは何件必要ですか？

モデル選定のミニ検証なら30〜50件、本番に進むかを判断する業務PoCなら50〜100件が目安です。件数より、業務のばらつきを代表する例が入っているかが重要です。長い文書と短い文書、例外的な書式、固有名詞や数値を含む例、意図的に「答えがない例」を含めてください。きれいな例文だけで作ると、本番の実データで精度が落ちます。

Q. 誰が採点すべきですか？

モデルを構築した人ではなく、対象業務を担当している人2人と品質を判断できる人1人の3人です。構築者は自分の出力に甘くなり、業務担当者は「この程度の間違いは許容できない」という肌感覚を持っています。採点は、どのモデルの出力かを伏せて行い、3人の採点が割れた件は理由を記録します。

Q. ハルシネーションはどう数えますか？

合格率とは別に、根拠のない記述や読めない箇所の捏造の件数を数えます。評価セットに「答えがない質問」「判読できない箇所」を意図的に含め、モデルが「不明」と返せたかを確認します。合格率が同じでも、不合格の中身が「黙って数字を変える」型のモデルは業務に使えません。

Q. 精度が合格ラインに届かないとき、まず何を直すべきですか？

プロンプトの修正、RAGの検索の見直し、モデルのサイズクラスの変更、ファインチューニングの順です。不合格例を「正しい文書を検索できていたか」「検索できたのに回答を間違えたか」に分けると、原因が検索かモデルかが分かります。RAG構成で精度が出ない原因は、モデル本体より文書のパースと検索の設計にあることが大半です。改善を1つ試すごとに、同じ評価セットを通して効果を記録してください。

Q. 速度や同時利用の合格ラインはどう決めますか？

業務側が「応答が始まるまで何秒まで待てるか」「同時に何人が使うか」を決め、その条件で実測して判定します。生成速度は、チャット対話で毎秒10トークン以上、コーディング補完で毎秒30トークン以上が目安です。同時利用は、同時リクエスト数を1・2・5・10と段階的に増やして測ります。モデル・量子化・機材・推論エンジンの組み合わせで桁が変わるため、相場ではなく実測で判断してください。

主な参考資料: 生成AIに関する実態調査2026春（PwC Japan）、Gartnerの生成AIプロジェクト頓挫予測（Intelligent CIO）、AI PoCの本番化ガイド（GXO）

TodoONadaでは、評価シートの設計から評価セットの作成支援、候補モデルの比較評価までを、ローカルLLMのPoC支援として行っています。自社データでモデルを比較するミニ検証（約30万円・2週間）と、速度・同時利用・設置条件を貴社オフィスの実機で測る社内設置の実現性検証（30万円〜・税別・2週間・機材貸出料込み）を組み合わせると、精度と実現性の両方を機材を買う前に判定できます。機材のみの短期貸出（1週4.5万円〜・税別）もあります。「評価セットをどう作ればいいか」という段階のご相談も歓迎します。

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
ローカルLLM 社内設置の実現性検証（機材貸出） — 機材を買う前に、DGX SparkやMacを貴社オフィスに2週間設置して「置けるか」を判定。機材のみの短期貸出も対応

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。