Qwen vs Claude — 自社ホスト LLM をどこまで実務に投入できるか（PoC と人手運用テストの両方を見た結論）

ccf代表
13 時間前
読了時間: 8分

背景

OPSNOTE（当社開発中の手順書 SaaS）の AI 機能は標準で Anthropic Claude API を使う。一方で「顧客データを外部 API へ送れない」テナント要件が発生する可能性を考慮し、自社 Azure サブスクリプション内で完結する LLM 経路を SKU として用意したい。Azure Japan East の T4 GPU 上で Qwen2.5:14B-Q4 を動かし、Claude Haiku 4.5 / Sonnet 4.6 と横並びで評価した。

評価は 2 段階で実施した。

機械計測 PoC（性能・コスト・5 シナリオ × 単発比較）
人手運用テスト（実テナント上で 21 件の業務シナリオを実施・本番経路で tool calling 含む）

結論を先に書くと、機械計測 PoC では Haiku 比 106% で「採用可」、人手運用テストでは 42% で「不合格」という逆転が起きた。ここではその差がどこから来たかをまとめる。

１．機械計測 PoC（先行）

検証構成

インフラ: ACA Serverless GPU Consumption-GPU-NC8as-T4 / Japan East
ランタイム: Ollama + LiteLLM（Anthropic 互換プロキシ）
モデル: qwen2.5:14b-instruct-q4_K_M
比較対象: Claude Haiku 4.5 / Sonnet 4.6
シナリオ: タイトル/概要・ステップ列挙・レビュー要約・本文校正・判断ポイント分岐の 5 種 × 2 試行
評価者: Claude Opus 4.7（5 段階主観評価）

結果サマリ

モデル	総平均（5点満点）	Haiku比
Qwen2.5:14B-Q4	4.25	106%
Haiku 4.5	4.00	100%
Sonnet 4.6	4.80	120%

PoC 受入基準「Haiku 比 70% 以上」は大幅クリア。この時点では採用可と見えていた。

応答性能（Warm steady）

シナリオ	Qwen latency	Haiku latency	Sonnet latency	Qwen tok/s	Haiku tok/s
S1 タイトル/概要（~100 tok）	5.3s	2.9s	3.9s	20	59
S2 ステップ列挙（768 tok）	63.0s	6.4s	14.0s	14	121
S3 レビュー要約	5.3s	3.2s	7.1s	19	79
S4 本文校正	14.1s	2.3s	8.3s	20	156
S5 判断ポイント	24.9s	4.3s	8.7s	20	121

T4 × 14B-Q4 の生成速度は warm 中央値で 約 20 tok/s に収束。Haiku の 1/3〜1/10。長文タスクは 1 分級になる。

Cold start・VRAM

指標	値
Cold latency 中央値（9 試行）	147.6 秒
Cold latency 範囲	87.7s 〜 153.2s（二峰性）
Cold 直後 VRAM	9475 MiB / 16384 MiB（~58% 使用）

二峰性は Azure Files キャッシュヒットの有無に起因と推定。14B-Q4 は T4 16 GB に収まることが確定。Cold 待ち 90〜150 秒は同期 UI 用途では非現実的で、Warm 常駐（min=1）が前提。

コスト（社内利用想定 2,200 req/月）

モデル	月額	内訳
Qwen（ピーク warm 平日 9–18h）	約 $307	GPU $0.3816/h × 198h、req 数に非連動
Qwen（全 cold / min=0）	約 $217	営業日あたり ~35 回の cold 待ち発生
Qwen（24/7 常時 warm）	約 $1,115	ノーコールド SLA が必要な場合
Haiku 4.5	約 $5	API 従量
Sonnet 4.6	約 $16	API 従量

Qwen が Haiku より安くなる損益分岐

Qwen 運用	月次固定	Haiku との分岐点
24/7 常時 warm	$1,115	約 490K req/月
ピーク warm	$307	約 135K req/月
全 cold	$217	約 95K req/月

社内利用規模ではどのパターンでも API 型が桁違いに安い。

２．人手運用テスト（後発・実テナントで実施）

機械計測 PoC は単発の比較プロンプトで Claude を評価者にしている。実テナントの本番経路（mTLS + LiteLLM + 実 tool calling + 21 件の業務シナリオ）でやり直したのが人手運用テスト。ここで PoC とまったく異なる結果が出た。

計画と実施範囲

カテゴリ	計画件数	実施件数	状態
S1: 手順書生成	5	5	完了
S2: レビュー応答	3	0	未実施
S3: チャット対話（10 ターン）	10	0	未実施
S4: Lint 評価	3	0	未実施
UX 体感	3	0	未実施
合計	21	5	S1 で打ち切り

S1 5 件で不合格レンジ（< 50%）が確定し、致命的誤情報リスクも観測されたため打ち切り。S2-S4 + UX は未実施のままモデル選定の見直しに進んだ。

S1 結果（5 件 × 20 点 = 100 点満点）

件	題材	Qwen	Haiku	Qwen 達成率
S1-1	定型運用：VM 計画再起動	12	20	60%
S1-2	定型運用：DB 論理バックアップ	11	19	58%
S1-3	障害対応：CI 切り分け	8	20	40%
S1-4	ユーザ対応：VPN トラブル	8	20	40%
S1-5	緊急対応：SSL 証明書差替え	3	20	15%
合計		42	99	42.4%

判定基準（≥70% 合格 / ≥50% 条件付 / <50% 不合格）に対し 42.4% で不合格。

何が起きたか — 実用上の問題

PoC では見えなかった、あるいは評価対象外だった事象が運用テストで次々と出た。

(1) Tool calling が全件で機能しない

OPSNOTE では generate_procedure_items tool で AI が手順書項目を自動追加する。Haiku は全件で正しく invoke して 15〜23 項目を自動追加。一方 Qwen は同じ tool 仕様に対し JSON をテキストとしてそのまま emit するだけで、tool_use ブロックとして受信されず、項目追加処理が走らない。LiteLLM ↔ Ollama 間の tool calling プロトコル不整合に起因する。ユーザは出力 JSON を読んで手動で項目化する必要があり、UX が大幅劣化。

※補足

Tool callingでは、OPSNOTE内部のMCP機能を利用し、AIが応答した結果をJSONで受けて、OPSNOTEに”自動的に登録”する仕組み。

(2) Schema 安定性の欠如

S1-1〜S1-3 では正規 schema（英語キー：majorCategory / purpose / command / expectedResult 等）で出力していた Qwen が、S1-4 で突然独自の日本語キー schema を捏造（フェーズ / 担当者 / 目的 / 確認方法 / 想定結果）。仮に tool calling が動いても schema mismatch でサーバ側保存処理が失敗するレベル。S1-5 では大項目を全件「SSL証明書更新」に統一して階層逆転。同じ仕様に対する出力安定性が保てない。

(3) 致命的誤情報（本番障害級）

S1-5 で Qwen が出力したコマンド：

cp /etc/letsencrypt/live/api.example.com/fullchain.pem /etc/nginx/sites-available/default

これは Nginx 設定ファイル default を SSL 証明書 PEM で上書きする破壊的コマンド。実行すれば本番 Nginx 設定が破壊され、構文エラーで起動できず、HTTPS どころか HTTP も含む全サービスが落ちる。Let's Encrypt 証明書は /etc/letsencrypt/live/<domain>/fullchain.pem のまま参照する流儀を完全に逆転させた捏造で、「実行すると本番が壊れる」レベル。ハルシネーションペナルティ -5 を適用、S1-5 最終スコア 3 点。

(4) 網羅性が 1/3〜1/4 に縮む

件	Qwen 項目数	Haiku 項目数
S1-1（VM 再起動）	7	15
S1-2（DB バックアップ）	6	20
S1-3（CI 切り分け）	7	20+
S1-4（VPN トラブル）	5	20+
S1-5（SSL 差替え）	7	17+

Qwen は重要な検証ステップ（整合性確認・データ検証・構文チェック・ロールバック設計など）を構造的に欠落させる。

(5) 題材タイプ別の極端なばらつき

題材タイプ	Qwen 達成率
定型運用（コマンド主体）	58–60%
障害対応(仮説検証・切り分け）	40%
緊急対応（致命的誤りあり）	15%

「コマンド主体の定型運用」では borderline、「論理性が問われる障害対応」では大幅未達、「緊急対応」では危険レベル。Haiku は全題材で 95–100%。

応答性能（運用テスト実測・per-item 効率）

PoC 単発計測より、実プロンプト・実 tool 構成・本番経路 mTLS での所要時間がより本番に近い。

件	Qwen 所要	Haiku 所要	Qwen per-item	Haiku per-item
S1-1	72s / 7 項目	42s / 15 項目	10.3 s/item	2.8 s/item
S1-2	120s / 6 項目	66s / 20 項目	20.0 s/item	3.5 s/item
S1-3	77s / 7 項目	47s / 20+ 項目	11.0 s/item	2.4 s/item
S1-4	55s / 5 項目	57s / 20+ 項目	11.0 s/item	2.85 s/item
S1-5	67s / 7 項目	60s / 17+ 項目	9.6 s/item	3.3 s/item
合計	391s	272s	約 11 s/item	約 3 s/item

総時間で Qwen は Haiku の 1.44 倍遅い
per-item 効率では Haiku が 3.7 倍速い
S1-4 で Qwen が Haiku より総時間で速く見える瞬間があるが、これは出力を minimal に切り上げているだけ（5 項目 vs 20+ 項目）。品質と引き換え

実利用では 「最初のトークンが返り始めるまでの体感」も Qwen は Haiku の 3〜5 倍長い。S2 のような長文生成では 1 分級の沈黙になる。

３．なぜ PoC と運用テストで結果が逆転したか

観点	PoC（106%）	運用テスト（42%）
評価者	Claude Opus 4.7（単独・主観）	一般ユーザ 1 名（実業務基準）
評価対象	出力テキストの 5 段階採点	実テナント上の業務適合性・tool calling・schema 整合性
Tool calling	評価対象外	全件失敗が直接スコアに影響
Schema 安定性	評価対象外	S1-4 で規約違反、S1-5 で階層逆転を観測
ハルシネーション	5 段階の中で吸収	-5 点ペナルティで顕在化（S1-5 致命的誤情報）
題材の難度	短文中心の合成プロンプト	障害対応・緊急対応を含む実業務題材
評価者バイアス	Claude ファミリ親和性あり	実利用者視点

PoC のスコアは 「短文・定型・ファミリ親和性込みの主観評価」で、実運用の判定材料としては明らかに楽観的だった。運用テストは実テナント本番経路での業務適合性を見ているため、tool calling・schema 安定性・ハルシネーションリスクが正面から効く。

４．結論

Qwen2.5:14B-Q4 on T4 の現状

品質: 実テナント本番経路で Haiku 比 42%。受入基準 70% に対し大幅未達
ハルシネーション: S1-5 で本番障害級の致命的誤情報を 1 件観測
Tool calling: 全件で invoke 失敗（LiteLLM ↔ Ollama protocol 不整合）
Schema 安定性: 同一仕様に対し独自 schema を捏造する事象あり
応答性能: 総時間 1.44 倍遅・per-item 3.7 倍遅・長文 1 分級
コスト: 社内利用規模では Claude API の 40〜60 倍

残課題と方針

運用テストは S1 で打ち切り、S2-S4 + UX は未実施。S2-S4 も同傾向と予想される
Tool calling 非互換が修正されても S1 達成率は 60–65% 程度の見込みで、仮閾値 70% に届かない
S1-5 のような致命的誤情報は tool calling 修正では解決しない根本品質課題
Qwen2.5:14B-Q4 は今回 SKU 採用見送り。代替モデル（Qwen3 等）での再評価へ
機械計測スクリプト・運用テスト計画は再利用可能な資産として残置

持ち帰り

「PoC で 70% を超えた」だけで採用判定してはいけない。tool calling・schema 安定性・致命的誤情報は単発比較ラン + 主観採点では捕まらない
評価者にモデル本人を使うとファミリ親和性バイアスが入る。実利用者の人手評価が必要
自社ホスト LLM の真価は性能ではなくデータ主権。コスト・性能で勝てる土俵ではない
業務題材の難度別に分けて評価する。定型運用・障害対応・緊急対応で挙動が大きく違う

留意事項

運用テストは一般ユーザ 1 名による主観評価。複数名独立スコアリングで補強する想定
S2-S4（レビュー応答 / 10 ターンチャット / Lint）は 未実施。本記事の数値は S1 5 件のみに基づく
致命的誤情報は 5 件中 1 件で観測。発生率の本格的な統計は別途必要