ローカルLLMの失敗と負の結果:J-WorkBenchの保存出力7ケース
2026年6月6日のJ-WorkBench保存出力から、JSON崩壊、根拠のない断定、二重計上などの失敗、ローカルが高得点だった例、長文課題で失敗を観測できなかった例を紹介します。人工課題の結果で、一般的な故障率の測定ではありません。
ローカルLLMは「動く」が「実務で信頼できる」とは限らない。J-WorkBench(RTX 3090 / Ollama 0.19 / 温度0・seed7)の課題を回すと、日本語の実務で繰り返し出る失敗が型として見えてくる。本稿はその見本帳だ。すべて生トランスクリプトから抜いた実測で、脚色はしていない。
総合スコアではローカル14B(qwen2.5:14b 91点)がクラウドCLIを上回る。ただしそれはコスト・速度・ローカル価値(計40%)が効いた結果で、品質軸(35%)はクラウドが明確に上位(Codex 98 vs qwen2.5:14b 85)。下のギャラリーは、その品質差がどこで出るかを具体的な失敗で示すものだ。長文・議事録・メールは互角まで迫るが、規程・契約の条文推論と汚い表ではローカルが大きく負ける。
1. JSON崩壊 — gpt-oss:20b / 社内規程-02(静かな暴走)
同一モデルの規程6問中5問は正しいJSONを返したのに、この1問だけプロンプトを完全無視した。タクシー精算の審査を求められたはずが、「外国人が米国で就職する方法」という無関係な英語求人エッセイ(H-1Bビザ解説・履歴書の書き方)を53,485トークン・約8分かけて生成。しかも errored/crashed フラグは false のまま、つまりパイプラインからは「正常終了」に見える静かな崩壊だ。
プロンプト要点は「タクシー精算を審査。前後に説明文を付けず JSON(violations/conditional/ok)だけ出力せよ」。返ってきたのはこれ。
**Answer to the original question – "What is the best way to get a job inthe U.S. as a foreigner?"** … H‑1B (Specialty Occupation) … 65k + 20k foradvanced degrees; lottery‑based …学び — 構造化出力の信頼性は確率的に崩れる。しかもエラーフラグが立たないので、JSONパース+スキーマ検証を必ず挟まないと「8分かけた英語エッセイ」が後段に流れ込む。
2. 根拠なし断言 / 入社期間トラップ — qwen2.5:14b / 社内規程-05
総合1位のqwen2.5:14bでも、条文推論では足をすくわれる。Gさん(2025/9/1入社、基準日2026/6/1で勤続約9か月=1年未満)を「勤続1年以上であるため」と根拠なく断言し、看護休暇の有給3日を誤付与した。正解は有給0日。他3問は正答・整形済みなので、この1問の捏造がかえって際立つ。
{ "q": 4, "value": "{取得可能: 有り, 有給日数: 3}", "clause": "第3条", "reason": "…勤続1年以上であるため、そのうち3日分を有給とする。" }学び — 入社日から自明に計算できる勤続年数を取り違える。規程RAGをローカルに丸投げするのは危険で、根拠条文の引用と、日付計算の検算を別経路で持たせる必要がある。
3. 敬語・立場の崩壊 — qwen2.5-coder:14b / メール-03
メールは文法だけ見れば破綻しないが、立場を読み違える。発注側の担当が、下請けの遅延を自分が謝罪して立場が逆転。さらにプロンプト内の制約文「権限を超える約束はしない」を本文にそのまま流出させ、差出人の社名まで「合同会社→株式会社」と捏造した。
株式会社ノースクラフト 大森様 …納品が遅れてしまったことについて、誠に申し訳ございませんでした。…ただし、私の権限を超える約束は控えさせていただきますのでご了承ください。学び — 敬語の体裁は整っていても宛先の立場を読めない。同じ問題でclaude/codex/gemini、そして同門のqwen2.5:14bは適切に処理しており、軽量コーダー系で特に出やすい。送信前の人間レビューを前提から外せない。
4. 表の二重計上 — qwen2.5:7b / 表CSV-02
「小計/合計を足すな、明細だけ合算」と明示警告された課題で、qwen2.5:7bは3項目すべて誤答した。明細合算16800を13200、一致判定も反転、二重計上の例示値50400を18000と返している。同じ問題でclaude/codex/gemini/gpt-oss:20bは3項目とも正答した。
{ "detailTotal": 13200, "printedGrandMatches": false, "naiveWrongSum": 18000 }(正解は detailTotal: 16800 / printedGrandMatches: true / naiveWrongSum: 50400)
学び — 軽量7Bは表の行種別(明細・小計・合計)を区別した集計で破綻する。表/CSVはローカルの弱点で、互角だったのはgpt-oss:20b(98点)だけ。他ローカルは31〜56点に沈む。
5. コーディング: ローカル失敗 vs クラウド成功 — code-hozen-01
請求の1円ずれを直すタスク(Math.round→Math.floor の1行修正)。ローカルのqwen2.5-coder:14bは最終出力が生のツール呼び出しJSONで停止し、修正そのものを適用できなかった。
{"name":"read_file", ...}テストは expected tax:159 but got tax:160 で落第(score0.3)。一方クラウドのcodex/claudeは、原因特定→floor修正→exit0 まで完走した。ただし同じクラウドのGeminiも同じ署名(tax:160)で失敗しており、端数処理は種別を問わない共通の落とし穴でもある。
学び — 消費者GPUのローカルはツール操作で行き詰まり、診断はできても修正を適用できないことがある。エージェント的なコード保全では完走率がそのまま実用性に直結する。
6. ローカルの勝ち — qwen2.5:14b / 議事録-03(フロンティア3社に逆転)
失敗集だが、ローカルがクラウド3社に勝った稀な実例も正直に載せる。「江口『棚卸し、やっておきます』(担当確定・期日は本人裁量で未明示)」を、tasksにowner=江口/due=nullで残すのが正解だ。qwen2.5:14bは正しく残して0.95(合格)。
"tasks":[{ "owner":"江口", "what":"…よくある質問を棚卸し", "due":null }]対してclaude/codex/geminiは全員「安全側に倒して」undecidedに落とし不合格(0.55〜0.60)。claudeはtasksを空配列で返し、objective層で0点になった。
"tasks": []学び — 「担当確定だが期日未明示」を確定タスクとして残せるかは、フロンティアでも外す境界判断だった。提供者への従量料金を0円と扱った測定で、ローカル14Bの応答時間は6.8秒でした。GPU代・電気代が不要という意味ではありません。この課題ではクラウド3種類より高得点でしたが、規程・契約の条文推論では逆に大きく負けており、勝ち負けはタスク種別で割れる。
7. 長文取り違え — 該当なし(負の結果)
「長文を読み違える失敗」を狙って用意したが、longctx-01/02は全7モデルが完全正答してしまい、該当例を作れなかった。これはモデルの堅牢性というより、fixture本文が正解を地の文で明示し、誤答候補も名指しで打ち消していたため。要するに問題が答えを書きすぎていた。
学び — これはベンチ側の限界だ。次版は正解を直書きせず参照解決を強制する設計に直す(既知の課題として明記)。失敗例が出なかったこと自体を、テスト設計のバグとして記録しておく。
出典
すべて生トランスクリプトからの実測(脚色なし)。原文は /jworkbench/2026-06-06/ で全件公開している(transcripts/<モデル>/<課題>.md・確定知見は FINDINGS.md)。
次に読む
- J-WorkBenchの相対得点と測定の限界
- ローカルLLMの損益分岐(サブスク3パターン)
- 自分のPCで J-WorkBench を再現する手順
- J-WorkBench ハブ — 5軸スコアと実測サマリーを一覧で見る
2026年9月20日注記:掲載結果は2026年6月6日に保存された測定記録に基づきます。AI採点は独立した第三者・専門家の監査ではなく、得点を実業務の自動化率や現在の製品全体の性能と読み替えることはできません。今回の更新ではモデルを再実行していません。
2026年9月21日訂正:失敗が出なかった例も含む7ケースとして見出しを修正し、料金ゼロと総費用ゼロを区別しました。防止策の検出率は未測定です。
関連して読む
local-llm・ollamaを続けて読む
· 参考リンク 2件ローカルLLMとクラウドの比較:J-WorkBenchの相対得点と測定の限界
2026年6月6日のJ-WorkBench保存記録を読み解きます。クラウド比66〜87点という相対指標、カテゴリ別の品質、AI採点の制約を整理。実業務を同じ割合で自動化できるという測定ではありません。
local-llm・ollamaを続けて読む
· 参考リンク 5件OllamaがWindowsでGPUを使わない・遅いときの確認手順:ollama psとログ
OllamaがWindowsでGPUを使わない、急に遅くなったときの確認手順です。ollama psのPROCESSOR列、server.logのGPU検出行、nvidia-smiの見方を整理し、RTX 3090でnum_ctxを上げてCPUへ一部オフロードされる様子を2026年9月14日に再現しました。
この記事の情報・検証メモ
- 公開日
- 情報確認
- 参考リンク
- 2件
- 更新性
- 定期更新
仕様・料金・提供範囲が変わりやすいテーマは、公開日・更新日・情報確認日を分けて管理します。 導入前には必ず記事末尾の一次情報と公式ドキュメントで最新状況を確認してください。