ローカルLLMとクラウドの比較:J-WorkBenchの相対得点と測定の限界
2026年6月6日のJ-WorkBench保存記録を読み解きます。クラウド比66〜87点という相対指標、カテゴリ別の品質、AI採点の制約を整理。実業務を同じ割合で自動化できるという測定ではありません。
J-WorkBenchは、日本語の議事録、メール、規程照合など7カテゴリの人工課題を使う自作ベンチマークです。本稿は2026年6月6日の保存記録を整理します。RTX 3090 24GB上のローカル4モデルと、クラウドのサブスクCLI3種類を比較した当時の結果で、現在のモデルを再測定したものではありません。
この測定から分かること
- 当時の課題では、ローカルの相対得点はqwen2.5:14bが86、gpt-oss:20bが87、qwen2.5-coder:14bが68、qwen2.5:7bが66でした。
- 総合点は品質だけの順位ではありません。速度・経済性・ローカル価値への評価が合計40%入り、ローカルを有利にする設計上の仮定があります。
- 品質の集計軸ではクラウド群の点が高く、議事録・メールでは近い結果もありました。どちらも今回の課題・採点に限った観察です。
- 長文課題は全モデル満点でしたが、問題文に正解が明示されすぎる既知の制約があります。長文処理に十分な性能があるという証拠にはできません。
相対指標と総合点を分けて読む
「代替率」という記録上の名称はクラウド比の得点を表します。一方、総合点は正確性35、信頼性20、速度15、経済性15、ローカル価値10、導入容易性5という重みで集計しています。総合トップ4をローカルが占めても、品質で上回ったとは判断できません。
経済性は計算用の仮定、ローカル価値は評価上の加点です。GPU取得費や保守費を含む総保有コスト、システムの無停止、外部通信が一切ないことを実証する指標ではありません。費用は電気代を差し引く計算例を使い、自分の条件で計算します。
J-WorkBench リーダーボード
日本語の実務(社内規程RAG・契約照合・議事録・メール敬語・表/CSV・コード保守・長文耐性)で、 手元PCのローカルLLMがサブスク版クラウドの何割を肩代わりできるかを5軸で測ったスナップショット。 データ確定日: 2026-06-06
クラウド代替率ランキング
クラウド最良 = 100 が基準線5軸スコア(重み付き合計100点満点)
各軸0–100 / 重みは軸名に併記- 実務正確性×35 98
- 信頼性×20 99
- 速度UX×15 76
- 経済性×15 60
- ローカル価値×10 0
- 導入容易性×5 95
- 実務正確性×35 94
- 信頼性×20 98
- 速度UX×15 43
- 経済性×15 60
- ローカル価値×10 0
- 導入容易性×5 92
- 実務正確性×35 89
- 信頼性×20 97
- 速度UX×15 50
- 経済性×15 60
- ローカル価値×10 0
- 導入容易性×5 95
- 実務正確性×35 86
- 信頼性×20 96
- 速度UX×15 83
- 経済性×15 95
- ローカル価値×10 95
- 導入容易性×5 70
- 実務正確性×35 85
- 信頼性×20 95
- 速度UX×15 98
- 経済性×15 95
- ローカル価値×10 95
- 導入容易性×5 70
- 実務正確性×35 66
- 信頼性×20 89
- 速度UX×15 100
- 経済性×15 95
- ローカル価値×10 95
- 導入容易性×5 70
- 実務正確性×35 65
- 信頼性×20 88
- 速度UX×15 99
- 経済性×15 95
- ローカル価値×10 95
- 導入容易性×5 68
カテゴリ別ヒートマップ
行=モデル / 列=タスク / 濃いほど高スコア(0–100)| モデル \ タスク | 社内規程RAG | 契約・見積照合 | 議事録ToDo | メール敬語 | 表/CSV | コード保守 | 長文耐性 |
|---|---|---|---|---|---|---|---|
| Codex (ChatGPT) | 99 | 99 | 91 | 100 | 98 | 100 | 100 |
| Claude (Claude Code / Max) | 82 | 100 | 91 | 93 | 99 | 100 | 100 |
| Gemini (Gemini CLI) | 95 | 97 | 91 | 93 | 98 | 48 | 100 |
| gpt-oss:20b | 71 | 79 | 86 | 100 | 98 | 83 | 100 |
| qwen2.5:14b | 77 | 81 | 92 | 100 | 56 | 100 | 100 |
| qwen2.5-coder:14b | 75 | 47 | 86 | 90 | 51 | 28 | 100 |
| qwen2.5:7b | 39 | 57 | 88 | 85 | 31 | 83 | 100 |
称号
各モデルの個性を1行でカテゴリごとの品質得点
保存記録のscore01を100倍した値です。範囲は比較したモデル間の最小・最大で、統計的な信頼区間ではありません。
表/CSVではgpt-oss:20bが98、他のローカル3モデルが31〜56でした。この結果だけから現在の製品選びを「一択」とは決められません。コード保守ではqwen2.5-coder:14bが28、Geminiが48で、ローカルかクラウドかという区分だけでは失敗を予測できませんでした。
具体的な出力は失敗例と負の結果の記録で確認できます。規程・契約の扱いは、クラウドの点が高くても人による照合や組織の利用承認を省略する根拠にはなりません。
採点の制約
環境は保存記録上、RTX 3090 24GB、Ollama 0.19、温度0・seed7です。ルーブリックはClaudeを別実行のAI採点者として168ペア再採点していますが、独立した第三者や専門家による監査ではありません。採点モデルへの依存や、内容の誤りを見逃す可能性が残ります。
数値・JSONなどの機械的な採点とルーブリック採点が混在しています。慎重に条件付きで答えた出力を部分一致の規則が過小評価する可能性もあります。コード保守や長文など、Claudeによる二重採点をしていない課題もあります。
長文課題の全員満点は問題設計の弱さを含みます。少数の人工課題から、機密文書の安全性、実務全体の正答率、将来の品質や速度を推定しないでください。
自分の用途で確かめる手順
- まず架空データで、実際に任せたい処理を代表する課題と正解・失敗条件を用意します。
- 両方の環境で出力を確認し、正答だけでなく再作業と人の確認時間を記録します。
- 外部通信、ログ保存、連携ツール、同時実行数を確認します。ローカル起動だけでは通信しないことの証明になりません。
- 実際に削減できるクラウド費用から、電気代など追加費用を引いて比較します。
この手順は今後の評価案です。今回、実業務を使った検証やモデルの再実行は行っていません。
出典と次に読む記事
2026年9月21日訂正:相対得点を実業務の自動化率へ一般化する説明を訂正し、表/CSVのクラウド得点範囲を保存記録に合わせました。価格・モデル性能の再測定ではありません。
関連して読む
local-llm・ollamaを続けて読む
自分のPCで J-WorkBench を回す — ローカルLLM実務ベンチの再現手順
日本語実務ベンチ J-WorkBench を自分のPCで再現する手順。Ollamaでモデルをpullし、npm run bench で7カテゴリを採点、結果からサイト用データを生成するまでを通しで解説します。サブスクCLIのフラグは要検証。
local-llm・ollamaを続けて読む
· 参考リンク 2件ローカルLLMの費用回収:削減できる月額から電気代を引いて比べる
GPU初期費用13万円・月額削減3,000円・電気代651円という仮定なら単純回収は約55.3か月。契約を維持する場合との違い、測定済みベンチマークの範囲を整理します。
この記事の情報・検証メモ
- local-llm
- ollama
- claude-code
- codex-cli
- benchmark
- rag
- 公開日
- 情報確認
- 参考リンク
- 2件
- 更新性
- 定期更新
仕様・料金・提供範囲が変わりやすいテーマは、公開日・更新日・情報確認日を分けて管理します。 導入前には必ず記事末尾の一次情報と公式ドキュメントで最新状況を確認してください。