ローカルLLMがClaude Opus 4.7に勝った話と、自分の選定基準の見直し

Simon Willisonの記事を読んで、少し頭を抱えた。

アリバイ言い訳的に「クラウドAPI使ってるから品質は保証されてる」と思ってた自分の判断軸が、ちょっとぐらついた感じがした。

何が起きたか

話の内容はこうだ。Simon Willisonが独自の「ペリカンが自転車に乗るSVG生成ベンチマーク」で、Qwen3.6-35B-A3BとClaude Opus 4.7を比べた。結果、Qwen3.6がOpus 4.7に勝った。しかもQwen3.6は20.9GBのggufファイルをMacBook Pro M5でLM Studioを使ってローカル動作させた状態で、だ。

OpusはSVGの自転車フレームを描き損じていた。一方Qwen3.6はフラミンゴに「」というSVGコメントを入れてくる余裕まで見せた。

自分はAPIコスト最適化をずっと気にしてきた。「軽量なモデルで済む処理はそっちに逃がす」という設計をチームでも少しずつ進めてる。でも今まで「生成物のクオリティが必要なタスクはOpusクラスに任せる」という線引きは揺るがないと思ってた。

ローカルLLMをどこに組み込むか、改めて考えた

正直、今日まで「ローカルLLMは趣味か実験用」という感覚が抜けてなかった。だが21GBのモデルがM5 MacBookで動いて、しかも特定タスクでAPIモデルに勝つなら、話は変わってくる。

自分の個人開発で言うと、画像やSVGの自動生成を挟む処理がある。今はAPIに投げてるけど、月のコストがじわじわ気になり始めてた。ローカル推論にできる部分があれば、コスト0で高速に回せる。

ただ、Simonも記事の中で書いてる。「Qwen3.6がOpusより全体的に優れているとは思わない」と。これは正直な評価だと思う。SVGというすごく構造化されたテキスト生成に強かっただけで、汎用的な判断力が上回ったわけではない。

自分が気をつけないといけないのは、この結果を「ローカルLLMで全部いける」と拡大解釈しないことだ。タスクごとに何が必要かを分解して、ローカルが有利な領域を見極める作業が要る。

たとえばSVGやHTMLの構造生成、コードの定型補完、Lintエラーの説明文生成あたりはローカルモデルで十分かもしれない。一方で自然言語での複雑な要件整理やコードレビューコメントの品質が重要な場面は、まだAPIを選ぶと思う。

次にやること

まずLM StudioとUnslothのQwen3.6の量子化モデルを自分の環境に入れてみる。M2 MacBookなので20.9GBのモデルが快適に動くか、レイテンシがどのくらいか確認したい。

個人開発のSVG生成部分だけQwen3.6に差し替えて、API呼び出しのものと出力を比較してみるつもりだ。品質が許容範囲なら、そこだけコスト0に切り替える。

「クラウドAPIかローカルか」という二択で考えてたけど、もう少し細かく「どのタスクにどのモデルを使うか」という粒度で設計する時期に来てると思う。来週それを試してみる。