「品質が必要なタスクはクラウドAPIのフラッグシップモデルに任せる」——多くの開発現場で共有されてきたこの前提を揺さぶる実例が報告されました。ノートPC上で動くローカルLLMが、特定のタスクでClaude Opusを上回ったのです。
この記事では、何が起きたのかを整理したうえで、「ローカルLLMとクラウドAPIをどう使い分けるか」を判断するための基準を3つの軸でまとめます。
何が起きたか：ローカルLLMがOpusに勝った実例
エンジニアのSimon Willison氏が、独自の「ペリカンが自転車に乗るSVG生成ベンチマーク」で、Qwen3.6-35B-A3BとClaude Opus 4.7を比較しました。結果は、Qwen3.6の勝利でした。しかもQwen3.6は、20.9GBのggufファイルをMacBook Pro（M5）上のLM Studioでローカル動作させた状態です。
OpusはSVGの自転車フレームを描き損じた一方、Qwen3.6はフラミンゴに「Sunglasses on flamingo!」というSVGコメントを添える余裕まで見せました。クラウドの最上位モデルが、ノートPCで動く公開モデルに特定タスクで負ける——数年前なら考えにくかった光景です。
結果をどう読むか
注意したいのは、Willison氏自身が「Qwen3.6がOpusより全体的に優れているとは思わない」と明記している点です。SVGという強く構造化されたテキスト生成に限った勝利であって、曖昧な要件の整理や複雑な判断で上回ったわけではありません。
つまりこの結果から読み取るべきは「ローカルLLMで全部いける」ではなく、「特定タスクに限れば、ローカルLLMがフラッグシップAPIに勝ちうる時代になった」という一点です。この前提に立つと、「クラウドかローカルか」という二択ではなく、「どのタスクにどのモデルを使うか」という粒度で設計する必要が出てきます。
使い分けの判断基準：3つの軸
タスクの振り分けは、次の3軸で考えると整理しやすくなります。
軸1: タスクの構造化度。出力形式が固い（SVG・HTML・JSON・定型コードなど）タスクほど、ローカルLLMが健闘しやすい領域です。逆に、曖昧な要件の整理、コードレビューコメントの品質、長い文脈をまたぐ判断は、依然としてOpusクラスのAPIモデルに分があります。
- ローカルに逃がしやすい: SVG/HTMLの構造生成、コードの定型補完、Lintエラーの説明文生成、分類・タグ付けの前処理
- APIに残すべき: 自然言語での複雑な要件整理、設計判断を伴うレビュー、顧客向け文章など最終品質が問われる生成
軸2: コストと呼び出し頻度。高頻度で回る処理ほど、ローカル化によるコスト削減効果が大きくなります。月のAPI請求のうち「品質が過剰なタスク」が占める割合を確認し、大きいものから差し替え候補にするのが定石です。逆に呼び出しが月数十回程度なら、ローカル環境の維持コスト（モデル更新・検証の手間）のほうが高くつくこともあります。
軸3: データの外部持ち出し可否。社内規程や顧客契約でデータを外部APIに送れない場合は、品質やコスト以前にローカルが唯一の選択肢になります。逆にこの制約がないなら、「すべてローカル」にこだわる理由は薄くなります。
小さく検証する手順
いきなり全面移行を検討すると評価軸が増えすぎて動けなくなるため、検証は小さく始めるのが現実的です。
1つのタスクに絞って、次の流れで確認します。まずLM Studioなどのローカル実行環境に量子化済みモデル（今回の例ならQwen3.6の量子化版）を導入し、手元のマシンで実用的な速度で動くかを確認します。次に、対象タスクの入力をローカルモデルとAPIモデルの両方に投げ、出力を並べて比較します。判断材料は「出力の差分」と「レイテンシ」の2つに絞るのがコツです。
品質が許容範囲であれば、そのタスクだけをローカルに切り替えます。必要なマシンスペックは、モデルファイルサイズに対して1.5倍前後のメモリを見込むのが実務上の一般的な目安です（20GB級のモデルなら32GB前後）。手元の環境で厳しい場合は、より小さい量子化モデルで同じ比較をしてみる価値があります。
まとめ
- ローカルLLM（Qwen3.6-35B-A3B）が、SVG生成という特定タスクでClaude Opus 4.7に勝つ実例が報告されました。ただし汎用力で上回ったわけではありません
- 使い分けは「タスクの構造化度」「コストと頻度」「データ制約」の3軸で、タスク単位に判断します。構造化された高頻度タスクがローカル化の第一候補です
- 検証は1タスクに絞り、「出力差分」と「レイテンシ」だけを見て小さく始めるのが現実的です
「ローカルLLMは趣味か実験用」という感覚は、そろそろ見直す時期に来ています。まずは自社のAPI利用の中から「品質が過剰なタスク」を1つ選び、手元のマシンで比較してみるところから始めてみてください。