ローカルLLMの評価方法｜業務データで精度を測る5ステップと指標

2026.11.09

記事の要約 ローカルLLMの評価方法とは、公開ベンチマークの順位ではなく、自社の業務データで作った評価セットに対する精度を測る手順を指します。 評価セットは入力・期待出力・採点基準を軸に作り、正答率80％を100件で測ると誤差はおよそ±8ポイントになるため、件数は見たい差の幅で決めます。 採点はLLM-as-a-judgeに任せきりにせず、提示順や回答の長さへの偏りを踏まえて人手評価を一部に組み合わせ、モデル更新時・データの変化時・定期に再評価します。 「公開ベンチマークで上位のモデルを選んだのに、自社の問い合わせ対応では誤答が目立つ」。ローカルLLMの導入を進める開発者や推進担当の方から、よく伺う悩みです。 本記事では、公開ベンチマークだけでは足りない理由から、評価セットの作り方、タスク別の指標、LLM-as-a-judge（＝別のLLMに採点させる方法）の限界、再評価の頻度まで順に解説します。 東京大学松尾研発のAIスタートアップとして製薬・製造業のAI開発を手がける弊社の経験も踏まえています。 ローカルLLMの評価方法とは？公開ベンチマークだけでは足りない理由 ローカルLLMの評価方法とは、自社の業務データで作った評価セットに対する精度を測る手順を指します。 公開ベンチマークだけでは足りない理由は3つあります。第1に、出題の分布が業務と違うことです。ベンチマークは常識問題や一般知識が中心で、変更申請書の様式や自社製品の型番、社内規程の言い回しは含まれません。 第2に、データ汚染（コンタミネーション）です。公開問題は学習データに紛れ込みやすく、Hugging FaceのOpen LLMリーダーボードも、MMLUで汚染が進んだことを理由の1つに、より難しいMMLU-Proへ差し替えました。覚えていた得点は、初見の業務データでは再現されません。 第3に、日本語と専門語彙への対応です。海外発のベンチマークは英語中心で、日本語ベンチマークでも製薬のGMP用語や製造現場の略語までは一般に含まれないため、自社での確認が欠かせません。 判断としては、公開ベンチマークは候補を3〜5モデルに絞る段階までに使い、最終選定とファインチューニング（＝自社データでの追加学習）後の確認は業務データで行います。 候補の絞り方は「ローカルLLMの日本語モデル比較｜業務向け7選と選び方2026」で整理しています。 参照元：Hugging Face「Open LLM Leaderboard About」 業務データで評価セットを作る5ステップ（件数と形式） 評価セットとは、業務の入力と期待する出力、採点基準を1組にしたデータの集まりです。学習に使った問題で測ると暗記の成果を測ることになるため、学習データとは別に作ります。 弊社がPoC（＝本番開発の前に小さく行う技術検証）で評価セットを作る手順は、次の5ステップです。飛ばしたステップがあると、後で出た数字の意味を説明できなくなります。 1. 評価する業務とタスクの種類を1つに決める 最初に、「何の業務の、どの判断を任せるか」を1文で書きます。問い合わせの分類、帳票からの項目抽出、規程に基づく回答生成では、使う指標が変わるためです。ここが曖昧だと採点基準も書けません。 複数の業務を1つの評価セットに混ぜると、どの業務で精度が落ちたのか分からなくなるため、業務ごとに別に作ります。 2. 実際の業務データから入力を集める 入力は、過去の問い合わせログや実際の帳票など、本番で流れるデータからそのまま抜き出します。作文した例題では、現場特有の省略や誤字、長文が再現されません。 個人情報や取引先名は匿名化します。典型例だけでなく、形式を指定する問題・長い入力・自社でしか使わない用語・判断が割れる境界例の4種と、答えられないはずの質問を意図的に混ぜます。本番で先につまずくのはこの種の入力で、典型例だけでは精度が高く出ます。 3. 期待出力と採点基準を現場担当者が書く 期待出力（＝正解とみなす答え）は、その業務を日常的に担当している人が書きます。開発者が書いた正解は、現場の判断基準とずれやすいためです。 正解が1つに定まらない生成タスクでは、含むべき要素と含んではいけない要素を採点基準として文章にします。採点基準が書けない問題は、採点者ごとに結果がぶれるため評価セットから外します。 生成タスクの尺度は「そのまま使える／手直しすれば使える／使えない」の3段階にし、導入判断は「そのまま使える」の件数で比べます。人が確認してから使うか顧客にそのまま出すかを先に決めると、許容できる誤りの線が定まり、基準が書けます。 4. 件数を統計の誤差から決める 件数の目安は、見たい精度の差が誤差に埋もれない数です。正答率80％を100件で測ると、二項分布の標準誤差から計算した95％信頼区間はおよそ±8ポイントになります。 つまり100件では78％と84％の差は偶然の範囲で、モデルの優劣は判断できません。400件に増やすと信頼区間はおよそ±4ポイントに縮みます。 5. 形式をそろえて版管理する 形式は、入力・期待出力・採点基準・出典・難易度の5列にそろえ、CSVやJSON Linesで保存します。 版番号を付け、問題を追加したら版を上げます。版が違う評価セットで得点を比べると、モデルの改善と問題の変化が区別できないためです。 ファインチューニングの手順は、親記事「ローカルLLMでファインチューニングを行う方法とは？手順や必要な環境を解説」で解説しています。 タスク別のLLM評価指標｜正答率・F1・根拠一致・有害出力率 LLMの評価指標は、タスクの種類ごとに選ぶ必要があります。分類向けの正答率を生成タスクに流用すると、言い回しが違うだけの正解を誤答と数えてしまうためです。精度が実際より低く出て、使えるモデルを落とす側の誤りになります。 タスク主な指標指標の意味注意点分類（問い合わせの振り分け）正答率・F1正解した割合／適合率と再現率をまとめた値少数カテゴリの取りこぼしはF1で見る抽出（帳票から項目を取り出す）完全一致・部分一致正解と一字違わず一致した割合／一部一致した割合全角半角や日付書式をそろえてから採点する生成・RAG（文書を根拠に回答）根拠一致・回答の妥当性主張のうち根拠文書で裏付けられる割合／質問に正面から答えた度合い採点役のLLMの偏りを別途確認する形式・速度（全タスク共通）形式遵守率・応答時間指定した形式どおりに返った割合／回答1つあたりの処理時間量子化版を比べるときは精度と並べて測る安全性（全タスク共通）有害出力率・拒否率不適切な出力の割合／回答を拒否した割合答えられる質問まで拒否していないかも測る 正答率が少数カテゴリの不調を隠すのは、多数カテゴリの正解だけで率が押し上がるためです。件数の少ない緊急の問い合わせを全件落としても正答率は高いままで、カテゴリごとのF1で初めて表れます。 生成タスクとRAG（＝文書を検索し、その内容を根拠に答えさせる検索拡張生成の仕組み）では、根拠一致（faithfulness）が中心です。RAGASの定義では、回答に含まれる主張のうち検索した文脈で裏付けられる割合を0〜1で表し、低い回答は文脈にない内容を補っています。 この補いがハルシネーション（＝もっともらしい誤り）で、対策は「ハルシネーション対策とは？原因と安全なAI活用法を徹底解説」で解説しています。 有害出力率は安全性の指標で、日本語では国立情報学研究所のAnswerCarefullyが使えます。1,800件の要注意質問（2024年9月公開の第2版）から成り、商用利用も認められています（再配布は禁止）。 答えられる質問まで拒否していないかも測ります。安全側に寄せすぎたモデルは現場で使われなくなるためです。 参照元：RAGAS「Faithfulness」／国立情報学研究所 大規模言語モデル研究開発センター「AnswerCarefully Dataset」（2024年9月） LLM-as-a-judgeの使い方と限界｜人手評価・再評価との組み合わせ LLM-as-a-judgeとは、採点基準をプロンプトで与え、別のLLMに回答を点数づけさせる方法です。Zhengらの論文（2023年）では、GPT-4を採点役にした場合の人間との一致率は85％（引き分けを除く）で、人間同士の81％と同水準でした。 一方で同論文は3つの偏りを報告しています。第1は位置バイアスで、2つの回答の提示順を入れ替えると判定が変わる現象です。GPT-4でも同じ判定を保てたのは65.0％で、対策は順序を入れ替えて2回採点し、一致した場合だけ採用することです。 採点役も生成モデルなので、先に読んだ回答を基準に後の回答を比べ、順番を手がかりにします。65.0％は、3回に1回は順番だけで判定が入れ替わる水準です。 第2は冗長性バイアスで、長い回答を高く評価する傾向です。繰り返しで水増しした回答に、Claude-v1とGPT-3.5は91.3％の確率でだまされました（GPT-4は8.7％）。 採点役自身が長く丁寧な回答を好む学習を受けているためです。91.3％は、水増し回答の2回に1回以上に点を付ける水準で、長く書くだけで点が稼げます。 第3は自己選好バイアスで、採点役が自分の生成した回答を好む傾向のため、採点役は評価対象と別系統のモデルにします。 偏りがある以上、人手評価をゼロにはしません。第1に、評価セットの1〜2割を抜き取り、人とLLMの採点を突き合わせます（割合は弊社の目安）。一致率が低ければ、採点基準の文章を直してから自動化します。 第2に、重要な問題は2人で独立に採点する二重評価にします。判定が割れた問題は採点基準が曖昧な証拠で、基準の修正対象になります。 再評価が必要なのは、モデル更新時・データドリフト時・定期の3つです。どれも前回と同じ版の評価セットで測り、得点の差を比べます。版が違うと得点の差の原因が分からないためです。 モデル更新時とは、ベースモデルの差し替えや量子化（＝モデルを軽くする圧縮処理）の変更で、量子化だけでも精度が変わり得ます。量子化版の比較では形式遵守率と応答時間も測ります。 データドリフトとは、新製品の追加や規程改定で入力の性質が変わることで、本番ログの誤答を評価セットに追加して版を上げます。 定期の再評価は四半期ごとなど業務の変化速度に合わせて決め、怠ると精度低下に気づくきっかけが現場からの苦情になります。 PoCの段階で頻度まで決める進め方は「PoC検証とは？目的と3つの観点・進め方・成功事例を解説」で解説しています。 参照元：Zheng et al.「Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena」（arXiv、2023年6月） ローカルLLMの評価ツール・ベンチマーク5選の比較 評価セットができたら、採点と記録はツールに任せます。日本語の公開ベンチマーク2つと評価フレームワーク3つを、良い点と注意点で比較します。 ツール・ベンチマーク提供元良い点注意点Nejumi Leaderboard 4Weights & Biases日本語モデルを汎用言語性能とアラインメントの2軸で比較。自社環境でも実行可順位は業務精度を保証しない。一部データは非公開llm-jp-evalLLM-jp複数カテゴリの日本語データセットを横断して自動評価。Apache-2.0データセットごとにライセンスが異なる。業務データの読み込みは自作RAGASオープンソース根拠一致・回答の妥当性などRAG専用の指標採点にLLMを使うため採点役の偏りが乗るpromptfooオープンソース設定ファイルで検証項目を宣言し、ローカルだけで実行。レッドチーミング機能もドキュメントは英語中心。採点基準は自分で書くLangSmithLangChainデータセット管理・人手レビュー・LLM採点・本番ログの評価を一体で提供商用SaaS。クラウド版は評価データが外部に出る 選び方の基準は、評価セットの形式をそのまま読めるか、採点の記録が残るか、ローカルで完結するかの3点です。ローカルLLMを選んだ理由が情報漏洩対策なら、評価データを外部に送るツールは方針と矛盾します。 形式をそのまま読めないと変換を挟み、変換ミスがモデルの精度差に混ざります。記録が残らないと、前回との差が総得点だけになり、どの問題で落ちたか追えません。 このように、ローカルLLMの精度は、自社の評価セットで測って初めて導入判断に使えます。 こうした評価セットの設計とPoCを支援するため、弊社はAI PoCサービス「ココロミ」（スタンダードプラン月々250万円〜）を提供しています。 細胞・遺伝子治療CDMOのCyto-Facto社とのAI-OCR開発では、機器画面の読み取りをサンプル画像で評価し、認識精度100％を達成しています。評価の数字を先に出してから設計を進める考え方は、ローカルLLMでも同じです。 参照元：株式会社EQUES「Cyto-Facto 導入事例」（2025年10月） ココロミ の詳細はこちら ローカルLLMの評価方法に関するよくある質問 Q. 評価セットは何件あれば足りますか？ 見たい精度の差で決まります。100件では正答率80％の信頼区間がおよそ±8ポイントになり、数ポイントの差は判断できません。 Q. LLM-as-a-judgeの採点はどこまで信用できますか？ 一致率85％の報告がある一方、提示順や長さへの偏りもあります。1〜2割を人手でも採点し、採点役は評価対象と別のモデルにしてください。 Q. ファインチューニング後に精度が下がることはありますか？ あります。学習データに特化しすぎて指示に従えなくなる過学習や、安全性の低下が起こり得るため、前後で同じ版の評価セットを使い、業務指標と有害出力率の両方を比べてください。 まとめ ローカルLLMの評価方法の核心は、公開ベンチマークの順位ではなく、自社の業務データで作った評価セットで精度を測ることにあります。要点は次のとおりです。 公開ベンチマークは候補の絞り込みまでに使い、最終判断は業務データで行う 評価セットは本番データから入力を集め、現場担当者が期待出力と採点基準を書き、見たい差の幅から件数を決めて版管理する LLM-as-a-judgeは位置・冗長性・自己選好の偏りを踏まえて人手評価と組み合わせ、モデル更新時・データドリフト時・定期に再評価する 評価セットの設計でお困りの際は、お気軽にご相談ください。最後までお読みいただき、ありがとうございました。 業務データでの評価セットづくりから、伴走しませんか 評価セットの設計と精度の実測を、AI PoCサービス「ココロミ」で支援します。まずは無料相談からどうぞ。 無料で相談する ココロミを見る

PoC報告書の書き方｜経営判断に使える7項目の構成とテンプレート

2026.11.09

記事の要約 PoC報告書とは、検証で動いたかどうかの記録ではなく、本番開発に投資してよいかを判断する材料をそろえた文書で、結論・費用・効果を先頭に置きます。 構成は目的・成功基準・検証条件・結果・制約・費用・次の一手の7項目で、数字は比較対象と検証条件、分母となる件数、現状値との差をそろえて判断に使えます。 Gartnerは生成AIプロジェクトの少なくとも30％がPoC後に中止されると予測し、理由の1つに事業価値が不明確なことを挙げています。 「PoCは終わったのに、経営層から『本番に進めるのか』と聞かれて答えに詰まった」「精度の数字は出したのに、稟議（＝社内の決裁手続き）が止まった」。AI推進の担当者からよく聞く声です。 本記事では、PoC報告書の書き方を、読み手別に必要な情報、7項目の構成、数字の出し方、よくある不備、テンプレートの順に解説し、公開されたPoC結果報告も3件取り上げます。 東京大学松尾研発のAIスタートアップとして製薬・製造業のAI PoCを手がける弊社の経験も踏まえてまとめました。 PoC報告書とは？判断に使えない報告書が生まれる理由と読み手別に必要な情報 PoC報告書とは、PoC（＝本番開発の前に小さく行う技術検証）の結果を、本番に進むか・条件付きで続けるか・やめるかの判断材料として整理した文書です。動いた事実の記録ではなく、投資判断の材料が主役です。 判断に使えない報告書は、検証中に精度を上げる作業へ時間が吸われ、終了間際に結果だけを文書化するときに生まれます。何と比べて良いのか、どの条件で出た数字かが抜け、読み手が根拠を補うことになります。 会議で「現状と比べてどうか」と聞かれて答えられず、追加調査が宿題になるのが典型的な症状です。 Gartnerは2024年7月、生成AIプロジェクトの少なくとも30％が2025年末までにPoC後に中止されると予測し、理由にデータ品質・リスク管理・コスト増と並べて事業価値が不明確なことを挙げました。 読み手は3者で、知りたいことが違えば先に置く情報も変わります。 読み手知りたいこと先に置く項目経営層本番に進めるか・費用と効果はいくらか結論・費用・効果の3点現場（業務部門）どの条件なら使えるか・作業がどう変わるか検証条件・制約情報システム部門構成・データの流れ・セキュリティ・運用負荷構成図・データ経路・運用要件 3者に1つの報告書で応えるには、先頭1ページを経営層向けの3点に絞り、条件と制約、構成の順に深くする形が現実的です。 参照元：Gartner「Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept」（2024年7月） PoC報告書の構成7項目（目的・成功基準・検証条件・結果・制約・費用・次の一手） 経営判断に使えるPoC報告書は、次の7項目を同じ順番で並べます。順番そのものが「何を確かめ、何が分かり、次に何をするか」という判断の流れになるため、書き手も読み手も迷いません。 目的：何を確かめるためのPoCか 成功基準：合格条件と撤退条件 検証条件：データ・期間・範囲・評価者 結果：成功基準と同じ指標での実測値 制約：本番で変わる条件と未検証の範囲 費用：本番化の概算と体制 次の一手：進む・条件付き・やめるの提案 順番が判断の流れになるのは、目的が成功基準の指標を、成功基準が検証条件の範囲を、条件が結果の読み方を決める連鎖があるためです。前の項目が抜けると、後ろの読み方が決まりません。 1. 目的：何を確かめるためのPoCか 目的は、業務課題と確かめたいことを1文で書きます。「変更申請書の草案作成時間を半分にできるか」のように対象業務と指標を含めた形にします。目的が曖昧だと評価軸が定まらず、評価が印象論になります。 2. 成功基準：合格条件と撤退条件を数値で 成功基準には、着手前に決めた合格条件と撤退条件をそのまま載せます。途中で基準を変えたなら、いつ・なぜ変えたかを併記すると、結果に合わせて基準を動かした疑いを防げます。 3. 検証条件：データ・期間・対象範囲・評価者 検証条件には、データの件数と種類、期間、対象範囲、評価者と、検証シナリオ（誰がどの手順で使ったか）を書きます。 デジタル庁の2023年度検証は期間（2023年12月〜2024年3月）・対象者・検証内容を分けて公開しており、条件を明記した公開報告の手本です。条件が抜けると、本番で条件が変わったときに結果を読み直せません。 4. 結果：成功基準と同じ指標で、現状値と並べる 結果は、成功基準と同じ指標・単位で書き、現状の人手による値と並べます。精度だけでなく処理時間・確認工数・エラー件数など業務の指標を含めると、本番化後の効果に換算できます。 5. 制約：本番で変わる条件と未検証の範囲 制約には、PoCでは成り立っていたが本番では変わる条件を書きます。サンプルと実データの差、対象外にした例外処理、AIに任せていない判断などです。制約を書かない報告書は、本番で初めて問題が見つかる報告書であり、経営層にとって制約は投資範囲を見積もる情報です。 6. 費用：本番化の概算と体制 費用には、PoCにかかった額ではなく、本番化した場合の初期開発費・年間運用費・社内体制の概算を書きます。効果と費用の数字が同じ報告書にそろって初めて、稟議は進みます。決裁者は効果を費用と並べて他の案件と比べるので、片方が無いと比較に乗らず保留になります。 概算できない項目は「未算定」と明記し、算定の期限を添えます。 PoC開発から本番開発への流れは「PoC開発とは？失敗しないためのプロセスと成功の秘訣を徹底解説」で解説しています。 7. 次の一手：進む・条件付きで続ける・やめるの提案 次の一手は、本番へ進む・条件付きで再検証する・撤退するのどれを提案するかを明記し、選択ごとに必要な条件・期限・責任者を書きます。「期待できる」で終わる結論は、判断を読み手に丸投げした状態です。結論ごとに厚く書く欄が変わります。 進む：成立した条件と未確認の条件、本番で増えるリスク 条件付きで続ける：届かなかった理由、次に確かめる問い、必要な件数と期限、費用の上限、判断日 撤退：否定された仮説、止める投資、残す知見とデータ 参照元：デジタル庁「2023年度 デジタル庁・行政における生成AIの適切な利活用に向けた技術検証を実施しました」（2024年5月） 結果の数字の出し方：比較対象・条件・件数・現状値との差 結果の数字は、「精度92％」のように単独では判断に使えません。比較対象・検証条件・分母となる件数・現状値との差の4点がそろって初めて、経営層は本番でも同じ効果が出るかを見積もれます。 何と比べたか（現状の人手・既存ツール・前回の検証）と、どの条件で出たかを同じ行に書けば、解釈に迷いません。 表の数字は見本です。判定の根拠に現場の一言を添えると、経営層が「動いた」と「使える」を分けて読めます。 検証項目成功基準結果（分母つき）判定根拠・現場コメント草案作成時間60分→30分以下平均27分（120件）合格QA担当3名「修正は体裁が中心」逸脱報告書未設定未検証条件付き30件を4週間で追加検証 条件には、対象にした範囲と外した範囲の両方を書きます。「この条件の外では未検証」と先に書くほうが、報告書の信頼は長く保たれます。 割合には常に分母を添えます。「正答率56％」より「43件中24件が正答」（見本の数字）のほうが、件数の少なさも含めて判断できます。 平均値だけでなく区間も示します。削減時間が平均15分でも最小0分・最大60分なら効果は業務によって偏っており、偏りが見える数字は本番で優先する業務を選ぶ材料になります。 現状値との差は業務の単位に換算します。1件15分の削減なら月間件数をかけて月何時間かまで書くと、費用の項目と突き合わせられます。 指標の選び方は「PoC検証とは？目的と3つの観点・進め方・成功事例を解説」をご参照ください。 PoC報告書によくある不備4つと、公開されている結果報告に学ぶ書き方 弊社がAI PoCのご相談で見る範囲では、報告書の不備は次の4つに収まることがほとんどです。いずれも検証中に決めなかったことを、書く段階で埋めようとすることから生まれます。読み手の側では「疑われる」「読み直せない」「決められない」という3つの形で現れ、いずれも書く段階ではなく検証の設計段階で防げます。 よくある不備4つと直し方 不備読み手に起きること直し方成功基準が後付け基準を結果に合わせたと疑われる着手前の基準と変更の経緯を書く検証条件の省略条件が変わると読み直せない件数・期間・範囲・評価者を明記する費用の抜け効果だけでは稟議が進まない本番化の初期費・運用費・体制を書く「期待できる」で終わる結論判断が読み手に丸投げされる進む・条件付き・撤退のどれかを提案する 成功基準・検証条件・費用の枠は、着手前に報告書の空欄として用意するのが対策です。 PoCが本番に進まなかった事例は「PoC失敗の事例5選｜本番に進まない原因と防ぎ方【2026年】」で整理しています。 公開されているPoC結果報告3件に学ぶ デジタル庁の2023年度検証は、目的を利用方法の知見の獲得、改善できる業務の特定、改善効果の推定の3つに分け、報告資料とともに投稿プロンプト一覧やテストケース例（CSV）を公開しました。目的を分けないと評価軸が1つになり、業務ごとの差が見えなくなります。 注意点は、行政の検証は規模が大きく、数字をそのまま自社に当てはめられないことです。学ぶべきは数字ではなく、目的・条件・結果・課題を分けて書く形式です。 両備システムズが公表した札幌市との旅費事務のAI実証（2025年12月〜2026年3月）は、処理時間を平均15.4分・27.2％削減、規程遵守率98.1％と報告しました。判断基準が明確な規程のみが対象、25分以下では時間が増えた例もあると例外を併記した点が手本です。 例外を書かないと、時間が増える業務まで適用範囲に入り、本番で効果が相殺されます。一方、公表形式はプレスリリースなので、社内の報告書に要る費用や体制の情報は含まれません。 国土交通省のPLATEAUは、3D都市モデルの実証148件（2026年11月時点）を、概要・実現したい価値・方法・結果と課題・参加ユーザーからのコメント・今後の展望という同じ見出しで公開しています。 見出しを固定すると、件数が増えても比較できることを示す例です。見出しが件ごとに違うと、読み手は同じ項目を探す段階で詰まります。 参照元：株式会社両備システムズ「札幌市との生成AI及びAIエージェントを活用した旅費事務効率化の実証実験において時間削減等の成果を確認」（2026年6月）／国土交通省「PLATEAU ユースケース」（2026年3月） そのまま使えるPoC報告書テンプレート（項目・書くこと・例文） 7項目をテンプレートにまとめました。例文は製薬の品質保証業務を想定した見本です。PoCの着手前にこの表の空欄を作り、検証中に埋めていく使い方を前提にしています。 空欄を先に作ると、評価者・件数・撤退条件を決める作業が着手前に前倒しされ、空欄がそのまま検証中の記録項目になるためです。 項目書くこと例文（例）目的対象業務と確かめたいことを1文で例：変更申請書の草案作成時間を半分以下にできるか成功基準合格条件と撤退条件を数値で例：合格＝60分→30分以下。撤退＝45分超検証条件データ・期間・範囲・評価者例：過去の申請書120件、8週間、QA担当3名が評価結果同じ指標で現状値と並べる例：平均27分（現状60分）、修正は平均4.2か所（最小1・最大11）制約本番で変わる条件と未検証の範囲例：逸脱報告書は未検証。社外秘データは社内環境で処理費用本番化の初期費・年間運用費・体制例：初期開発費と年間運用費の概算、運用担当1名次の一手進む・条件付き・撤退と条件・期限・責任者例：条件付きで本番へ。逸脱報告書30件を4週間で追加検証 1ページ目に結論・費用・効果の3点、2ページ目以降に表の順で本文、構成図とセキュリティ要件は別紙にします。経営層が1ページ目だけで決裁の方向を決められる状態が目標です。 別紙に回すのは、情報システム部門が深く読め、1ページ目を薄く保てるためです。ここで方向が決まらないと、決裁は次回に回ります。 成功基準の欄を開始前に埋めるには、計画段階で関係者の合意が要ります。進め方は「PoCの進め方｜5つのステップとチェックリスト・成功事例4選」と「AI PoCの進め方とは？期間や失敗しない秘訣を事例と共に解説」をご参照ください。 このように、判断に使える報告書は、検証の設計段階で枠を決めておくことで書けます。この段階から、弊社はAI PoCサービス「ココロミ」（スタンダードプラン月々250万円〜）で支援しています。 スカパーJSAT株式会社との静止軌道衛星の軌道保持業務のPoCでは、評価観点を妥当性・一貫性・説明可能性・再現性・運用負荷の5つに置き、AIの出力はエンジニアがレビューする前提で検証しました。本格的な運用適用の判断はこれからの段階です。 参照元：株式会社EQUES「スカパーJSAT株式会社 導入事例」 ココロミ の詳細はこちら PoC報告書に関するよくある質問 Q. PoC報告書は何ページくらいが適切ですか？ 目安は、1ページ目に結論・費用・効果の3点、本文は7項目で5〜10ページ、構成図などは別紙です。 Q. 成功基準に届かなかった場合、報告書はどう書けばよいですか？ 届かなかった事実と、原因がデータ・検証条件・モデルのどれにあるかの切り分けを書き、撤退か条件付き再検証を提案します。撤退条件を事前に決めていれば、「投資しない」という判断を得た成果になります。 Q. PoC報告書は社内のどの書式に合わせるべきですか？ 最終的に稟議書に転記されるので、稟議書の項目に合わせるのが近道です。費用・効果・リスク・体制の項目名をそろえると、書き直しが減ります。 まとめ 要点は次のとおりです。 読み手は経営層・現場・情報システム部門の3者で、先頭1ページは経営層向けの結論・費用・効果の3点に絞る 構成は目的・成功基準・検証条件・結果・制約・費用・次の一手の7項目で、成功基準は着手前の値を載せる 数字は比較対象・検証条件・分母・現状値との差をそろえ、進む・条件付き・撤退のどれかを提案する 報告書の枠から一緒に設計したい段階でも、お気軽にご相談ください。最後までお読みいただき、ありがとうございました。 判断に使える報告書になるPoCを、設計から始めませんか 成功基準と検証条件を先に決める設計から、AI PoCサービス「ココロミ」で伴走します。まずは無料相談からどうぞ。 無料で相談する ココロミを見る

ローカルLLM高速化の手順｜量子化・vLLM・バッチ処理の4手法

2026.11.09

記事の要約 ローカルLLMの高速化とは、遅さの原因を切り分けて速くする手順で、主因は計算力ではなく、トークンごとに重み全体を読み出す「メモリ帯域の壁」にあります。 量子化は重みのデータ量を減らして帯域の壁を下げる手法で、公式資料ではLlama-3.1-8Bが16bitの約15GiBから4bit級の約4.6GiBに縮みます。 症状を「最初の1トークンまでの時間」と「1トークンあたりの時間」に分けて計測し、量子化・推論エンジン・バッチ処理・KVキャッシュのどれを使うか決めます。 「ローカルLLMの回答が1文字ずつしか出てこない」「同時に数人が使うと止まる」。開発者や情報システム部門からよく受ける相談です。 遅さの原因を切り分けて精度を落とさずに速くする手順として、量子化・推論エンジン・バッチ処理・KVキャッシュの4手法をどの症状に向くかで解説します。 東京大学松尾研発のAIスタートアップとして製薬・製造業のAI開発を手がける弊社の経験も踏まえます。 ローカルLLMが遅い3つの原因｜メモリ帯域・モデル規模・実装 ローカルLLMの推論は、入力文をまとめて処理する「プリフィル」と、回答を1トークンずつ生成する「デコード」の2段階で進みます。トークン（＝モデルが文章を扱う最小単位）を1つ生成するたびに、モデルの重み全体をGPUメモリから読み出します。 このためデコードの速度は、計算力ではなく重みを運ぶメモリの速さで決まります。遅さの原因は3つです。 1. メモリ帯域：重みの読み出しが毎トークン発生する 重みが大きいほど毎トークンの読み出し量が増えるため、1トークンあたりの時間が伸びます。VRAMに収まらず一部をCPUメモリに置くと、帯域は大きく落ちます。 症状は、最初の1トークンは待てるのに、その後の文字送りが遅い形で現れます。これには量子化で読み出す量そのものを減らす手が有効です。 2. モデル規模：パラメータ数と文脈長がそのまま時間に乗る パラメータ数が2倍なら読み出し量も2倍になり、文脈長（＝一度に扱える入力と出力の合計トークン数）が長いほどプリフィルの計算が増えます。 KVキャッシュ（＝生成済みトークンの計算結果を保存する領域）も文脈が長いほど膨らみ、症状は社内文書を丸ごと貼る使い方で最初の1トークンまでが数十秒に伸びる形で現れます。業務に必要な精度を満たす最小のモデルを選ぶことが最初の判断です。 3. 実装：推論エンジンと設定で数倍の差が出る 同じモデル・同じGPUでも、推論エンジンと設定で速度は数倍変わり得ます。 GPUに載せる層数が足りずCPUで動いている例や、リクエストを1件ずつ処理していて複数人で使うと急に遅くなる例が典型です。後者にはバッチ処理が有効です。 実装が原因かどうかは、まず次の設定を確かめます。llama.cppなら-ngl（GPUに載せる層数）と-fa（Flash Attention）、Ollamaなら環境変数OLLAMA_FLASH_ATTENTION=1です。 vLLMなら--gpu-memory-utilization（GPUメモリのうち使う割合）と--max-num-seqs（同時に処理する系列数）です。ここが合っていないと、他の手法を足しても速さは伸びません。 参照元：NVIDIA Technical Blog「Mastering LLM Techniques: Inference Optimization」（2023年11月）／ggml-org「llama-server README」／Ollama「FAQ」／vLLM「Engine Arguments」 ローカルLLMの量子化｜種類と精度への影響 量子化とは、モデルの重みを16bitから8bitや4bitに丸めてデータ量を減らす処理です。読み出すバイト数が減るため、メモリ帯域の壁を直接下げられます。一方、丸めると小さな重みどうしの差が区別できなくなるため、bit数を下げるほど精度は落ちます。 Llama-3.1-8Bを16bit（F16）から4bit級（Q4_K_M）にすると14.96GiBのファイルが4.58GiBに縮み、VRAM 8GBのGPUにも載る計算です。 量子化の3方式｜GGUF・GPTQ/AWQ・FP8 第1はGGUF形式のK-quant（Q4_K_M・Q5_K_M・Q8_0など）で、llama.cppとOllamaで使われます。 第2はGPTQとAWQで、vLLMが対応します。GPTQは3〜4bitで精度低下をほぼ抑えたとし（Frantarら、2022年）、AWQは重要度の高い1％の重みを保護します（Linら、2023年）。 第3はFP8やINT8で、精度低下が小さい代わりに削減幅も半分です。FP8のネイティブ演算は原則としてAda・Hopper世代以降のGPUに限られるため、先にGPU世代で絞ります。 精度への影響と選び方 精度低下はパープレキシティ（＝モデルが次の語をどれだけ迷うかの指標）で測るのが標準です。指標が小さくても業務の回答品質が保たれる保証はありません。4bit級で精度が落ちると、数値や固有名詞、表の中の値を取り違える形で業務回答に出ます。 弊社の判断基準は8bitはほぼ無差、4bit級は検証して採用、3bit以下は原則避けるです。3bit以下では容量の減り方に対して精度の落ち方が大きく、業務で許される範囲に収まりにくいためです。 再量子化は品質が落ちるため、16bit以上の元モデルから作られた版を選びます。候補の絞り込みは「ローカルLLM比較｜主要モデル5選」が参考になります。 参照元：ggml-org「llama.cpp quantize README」「GGUF」／Frantarら「GPTQ」（2022年10月）／Linら「AWQ」（2023年6月）／vLLM「Quantization」 推論エンジンの使い分け｜vLLM・llama.cpp・Ollama・TensorRT-LLM・SGLang 推論エンジンは、「1人が手元で使う」か「数十人が同時に使う」かで選び方が変わります。1件ずつ処理するエンジンでは、利用者が増えた分だけ重みの読み出しが繰り返されるからです。 連続バッチ処理（後述）に対応したエンジンなら処理量が伸びますが、手元用のエンジンを多人数のサーバーに使うと待ち時間が人数分だけ積み上がります。 ツール向く規模機材vLLM多人数のサーバーNVIDIA・AMD GPUなどllama.cpp個人〜小規模Apple silicon・CUDA・VulkanなどOllama個人・検証macOS・Windows・LinuxTensorRT-LLM多人数のサーバーNVIDIA GPUのみSGLang多人数のサーバーNVIDIA・AMD・TPUなど vLLM：同時リクエストの多いサーバー用途の標準 PagedAttention（＝KVキャッシュをページ単位で管理する手法）と連続バッチ処理で多数の同時リクエストをさばけます。公開時のベンチマークではHugging Face Transformers比で最大24倍のスループットを示しました（2023年6月、条件は参照元）。 一方、LinuxとGPUが前提で、GPUメモリの割り当てが小さいとKVキャッシュに回る分が減り、同時数が頭打ちになります。 llama.cpp：Apple siliconやCPUを含む幅広い機材で動く Apple siliconからCUDA・AMD・Vulkanまで幅広く対応し、1.5〜8bitの量子化を自前で持ちます。 一方、多数の同時リクエストではvLLMほど伸びず、GPUバックエンドを有効にしてビルドしないとCPU実行になります。エラーは出ず遅くなるだけなので、起動ログの層数表示を見ないと気づけません。 Ollama：llama.cppをバックエンドに1コマンドで導入 「ollama run モデル名」だけで取得から実行まで完了するのが利点です。 一方、速度の上限はllama.cppに準じ、GGUF取り込み時に量子化しません。16bitのまま取り込むと帯域の壁が残るため、公式はllama-quantizeで先に量子化するよう案内しています。 TensorRT-LLM・SGLang：特定の条件で最大性能を狙う NVIDIA GPU専用に最適化した実装で、環境構築に時間がかかるため、専任のエンジニアを置ける組織に向きます。 RadixAttention（＝共通する前半のKVキャッシュを共有する手法）で同じシステムプロンプトを繰り返し使う処理に向きますが、国内の導入情報は少なめです。選定後の構築手順は「ローカルLLM構築の進め方」で整理しています。 参照元：vLLM「vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention」（2023年6月）／ggml-org「llama.cpp README」／Ollama「README」「Importing models」／NVIDIA「TensorRT-LLM README」／SGLang「Documentation」 バッチ処理とKVキャッシュ｜同時アクセスに強くする仕組み バッチ処理とは、複数リクエストのトークン生成を1回の重み読み出しでまとめて進める方法です。読み出しを共有するため、スループット（＝単位時間に生成できるトークン数）は同時数が増えても伸びます。 固定バッチでは短いリクエストが長いものの終了を待たされるため、終わった分を即座に入れ替える連続バッチ処理が多人数向けエンジンの標準です。 KVキャッシュは16bitのLlama 2 7Bで文脈長4096・バッチ1のとき約2GBに達し、同時数に比例して増えます（NVIDIA技術ブログ）。 同時数を増やすと、ある人数でKVキャッシュがVRAMを使い切り、そこを境にTTFTが跳ね上がりtokens/sが急落するか、新しいリクエストが待たされます。 vLLMの開発チームは、従来の実装ではKVキャッシュの60〜80％が断片化と過剰確保で無駄になっていたとし、PagedAttentionで解消しました。無駄が減った分、同時に載せられるリクエストが増えます。 投機的デコーディングは、小さなドラフトモデルが数トークン先の候補を出し、本来のモデルが並列に検証する方法で、出力を変えずにT5-XXLで2〜3倍の高速化が示されています（Leviathanら、ICML 2023）。 判断基準は同時リクエストが少なければ投機的デコーディング、多ければ連続バッチ処理です。前者は1件ごとの待ち時間を縮め、後者は人数が増えたときの合計の処理量を増やす手法だからです。 参照元：vLLM「Speculative Decoding」／Leviathanら「Fast Inference from Transformers via Speculative Decoding」（2022年11月） ローカルLLM高速化の効果を計測する方法｜TTFT・tokens/s・同時数 指標はTTFT・1トークンあたりの時間・同時数での劣化の3つです（TTFT＝最初のトークンが返るまでの時間）。 応答速度の症状原因手法確認方法最初の1トークンが遅いプリフィル（モデル規模）モデル規模の縮小TTFT文字送りが遅いデコード（メモリ帯域）量子化・投機的デコーディングtokens/s同時数で急落するKVキャッシュの不足連続バッチ処理・最大同時数の制限同時数を変えた計測同じモデルなのに他の環境より遅い実装（層数・設定）設定の確認起動ログの層数表示 llama.cppは「llama-bench」で単体のtokens/sを記録し、同時数はllama-serverに外部から負荷をかけて測ります。 vLLMなら「vllm bench serve」（--max-concurrency）で同時数を変えて測ります。同時数を変えずに測ると、1人では速いのに本番で数人目から急落する問題を見逃します。 精度の確認には、業務で実際に投げる質問をまず30〜50件集め、期待回答とともに評価セットにします。評価セットがないと、精度低下に気づかないまま本番に出し、利用者の指摘で発覚します。 F16か8bitの出力を基準に4bit版を採点し、正答が許容幅を超えて落ちるなら8bitに戻します。 結果は構成（モデル・量子化・エンジン・設定）とセットで記録し、構成を変えるたびに同じ評価セットで再計測します。記録がないと、どの変更で速くなったかを後から再現できません。 ファインチューニング時の評価の考え方は「ローカルLLMでファインチューニングを行う方法」、機材費用は「ローカルLLMの費用相場」をご参照ください。 どの構成なら業務に耐えるかを小さく確かめる支援として、弊社はAI PoCサービス「ココロミ」（スタンダードプラン月々250万円〜）を提供しています。 SOLIZE PARTNERS株式会社とのPoCでも、熟練技術者の知見をシステム化できるかを同じ手順で検証しました。 参照元：vLLM「Benchmark CLI」／ggml-org「llama-bench README」／株式会社EQUES「SOLIZE PARTNERS株式会社 導入事例」 ココロミ の詳細はこちら ローカルLLMの高速化に関するよくある質問 Q. 量子化すると精度はどれくらい落ちますか？ 8bitではほぼ差が出ず、4bit級は業務質問で作った評価セットで採点して判断してください。 Q. vLLMとOllamaはどちらを選ぶべきですか？ 数人までが手元で使うならOllama、数十人が同時に使うサーバーならvLLMが目安です。 Q. GPUがないCPUだけの環境でも高速化できますか？ llama.cppで4bit級に量子化した7〜8Bモデルが現実的な上限で、必要なスペックは「ローカルLLMとは？必要なPCスペック2026」をご参照ください。 まとめ ローカルLLM高速化の出発点は、遅さの原因がメモリ帯域・モデル規模・実装のどれかを計測で切り分けることです。 量子化で読み出す量を減らすことが最も直接的な高速化になる 推論エンジンは同時リクエスト数で選ぶ：1人ならllama.cpp・Ollama、多人数ならvLLM・TensorRT-LLM・SGLang TTFT・tokens/s・同時数での劣化を計測し、業務質問の評価セットで精度を確かめてから構成を決める どの構成から試すべきか迷う段階でも、お気軽にご相談ください。最後までお読みいただき、ありがとうございました。 業務に耐える推論構成を、実測で決めませんか 量子化や推論エンジンの構成比較を、AI PoCサービス「ココロミ」で支援します。まずは無料相談からどうぞ。 無料で相談する ココロミを見る