この記事は、「オープン寄りの frontier model は、閉じた closed-source model に対抗できるのか？」という、いまのAI界隈でかなり気になるテーマを実験で確かめたものです。
ここでいう frontier model は、最先端クラスの大規模AIモデルのこと。
closed-source model は中身が公開されていないモデル、たとえば商用APIで使うタイプを指します。
一方の open-ish は、完全なオープンソースというより「かなり開放的だけど、厳密には全部公開ではない」くらいのモデルだと思うとわかりやすいです。
個人的には、この比較はかなりおもしろいです。というのも、AIの議論って「性能」か「価格」か「使いやすさ」かで話が散らばりがちですが、この記事はそこをまとめて見ようとしているからです。しかも、単なるベンチマークの数字遊びではなく、実際の開発フローに近い形で見ているのが良いです。
対象になったのは次の3モデルです。
比較には Ship-Bench というAI coding benchmark が使われています。
これは、ただコードを書かせるだけではなく、ソフトウェア開発の流れを5つの役割に分けて評価するのが特徴です。
つまり、単発で「このコード正しい？」ではなく、設計 → 計画 → 実装 → समीक्षा のつながりまで見ているわけです。
これがかなり大事で、AIの強さって「1回の回答の派手さ」よりも、「前の段階の意図をちゃんと引き継げるか」に出ることが多いと思います。
記事の結論を先に言うと、こうです。
数値を見ると、平均スコアは以下でした。
ぱっと見ると、KimiとDeepSeekはほぼ互角です。
ただし、DeepSeekはトークン効率がかなり良い。ここが記事の核心のひとつです。
トークンは、ざっくり言うとAIが処理・生成する文章の量です。
多いほど「考えた」「喋った」感じになりますが、そのぶんコストも上がります。
ここで面白いのは、Kimi と Qwen はほぼ同じくらいトークンを使っているのに、DeepSeek は半分以下だという点です。
これはかなり重要で、単に「精度が高い」だけではなく、その精度をどれだけ少ないコストで出せるかが実務では効いてきます。
Architect は、製品の要件から実装方針をまとめる役割です。
ここでは3つとも implementation-ready、つまり「このまま実装に進めそう」と判断されました。
スコアはこうです。
LLM judge の評価では、DeepSeek が最も完成度が高く、Kimi が僅差で続き、Qwen も十分に堅実だったとのことです。
人間のメモもおもしろいです。
Kimi は、指示で「要件に基づいて決めて」と言われていてもさらに確認質問をした点がプラス評価されていました。これは実務だと割とありがたい挙動です。AIって、たまに自信満々に突っ走りますからね。確認してくれるのは正直うれしいです。
また、Kimi は Next.js の中だけで完結させず、別APIサーバーを提案したのが特徴だったそうです。
これは設計思想としては少し重めですが、分離が明快でよい場合もあります。
Qwen は assumptions section（前提条件の説明）が読みやすく、その点は好印象。
DeepSeek は全体の整理が特に強かった、という評価でした。
UX Designer は、画面の流れや状態、レイアウト、操作の細かさを詰める役割です。
ここは3モデルとも本当に拮抗していて、スコアはほぼ同点でした。
正直、この差は誤差に近いです。
LLM judge でも「全部 dev-ready で、かなり詳細」と評価されていて、唯一の減点は 実際の mockup がないことでした。
まあ、テキストだけで設計させているので、そこは仕方ないですね。
人間のメモでは、Kimi がこのランで初めて text wireframes を入れてきたのが改善点として挙げられていました。
text wireframes は、文字だけで簡易的に画面の配置を表すものです。絵ではないけれど、レイアウトのイメージを伝えるには十分役立ちます。
DeepSeek はとにかく詳細で、しかも破綻しない。
Qwen は最終的な見た目のよさで少し好印象だった、というのが面白いところです。
このへんはAIの「設計の強さ」と「完成品の見栄え」が必ずしも一致しない、という典型例だと思います。
Planner は、前の成果物を受けて、どういう順番で開発するかを計画する役割です。
ここで差が出ました。
そして、Qwen は gate failure でした。
gate failure は、簡単に言うと「一定の合格ラインを超えられなかった」ということです。
この記事では、good-chunk の割合が70%以上という条件に届かず、約20%しか良い分割になっていなかったと書かれています。
これはかなり重要です。
なぜなら、計画が雑だと、後続の実装がぐちゃぐちゃになりやすいからです。
AIコーディングでは、生成コードの見た目が良くても、タスク分割が悪いと後で地獄を見ることがあります。ここは実務っぽい、かなりリアルな指摘です。
人間の観察では、3モデルとも 縦割りの実装より横に広く進める傾向 があり、E2E testing（end-to-end testing、最初から最後まで通して動くか見るテスト）を後回しにしてしまったそうです。
この判断はわりとありがちですが、あとで手戻りが増える。個人的には「やっぱりAIも人間の悪い癖を再現するのか」と少し苦笑いしました。
Developer は、実際にコードを書いてMVPを作る段階です。
ここでは3つとも一応 pass していますが、体感差はかなりありました。
LLM judge では DeepSeek が最強、Kimi が続く、Qwen はややトラブル多めという評価です。
人間のメモがかなり生々しくて、これがこの記事の読みどころのひとつです。
Kimi は出来栄えがよく、前回の Gemini / Gemma より見た目も良かったそうですが、OpenRouter での実行が遅く、thinking tokens を大量消費したとのこと。
性能が良くても、待たされると地味にしんどい。これは使う側にはかなり大事なポイントです。
Qwen はもっと大変で、CLI互換の問題や、誤ったフォルダへのコピー、.gitフォルダを消してしまう事故、さらには dev server を止めるときに Nodeプロセスを全部殺してしまい、CLI自身まで巻き込んだという記述があります。
ここは読んでいて「うわあ」となりました。AIが間違えること自体は珍しくないですが、開発環境を巻き込む事故は本当に困る。
実用面では、こういう“操作の荒さ”はかなり大きなマイナスです。
DeepSeek は速く、きれいで、トークン効率も良かった。
このあたりが、総合で勝った理由として納得感があります。
Reviewer は、最終成果物が要件通りかを確認する役割です。
ここは3つとも弱めで、でも全滅ではありません。
LLM judge のコメントでは、主な問題は 証拠不足 と パフォーマンス測定の穴 だったようです。
つまり、QAのロジック自体がめちゃくちゃだったわけではなく、「ちゃんと確かめ切れていない」という話です。
人間のメモでは、Kimi の QA agent が security issues を見つけた点が評価されていました。
Qwen は丁寧。DeepSeek も堅実。
ただし、どれも「レビューで完全に締め切る」レベルには少し足りなかった、という印象です。
この記事の主張は、単純に「このモデルが最強でした」ではありません。
むしろ、
オープン寄りの frontier model でも、品質では閉じたモデルにかなり近づける。ただし、最終的な勝負は“品質だけ”ではなく、コスト効率と運用のしやすさで決まる
という話だと思います。
この観点はすごく大事です。
AIの比較って、つい「点数が高いほうが勝ち」で終わりがちです。
でも実際には、同じくらい良いなら安いほうが勝つし、多少遅くても扱いやすいほうが勝つ。
逆に、数点高くてもコストが倍なら採用しにくいこともあります。
この記事では、その現実がかなりはっきり出ています。
DeepSeek は「品質も高い、コスト効率もいい」で、かなり説得力がありました。
Kimi は品質面でかなり強いけれど、トークン大量消費が気になります。
Qwen は悪くないのに、Planner と運用面で少し損をした感じです。
個人的には、**DeepSeek の勝ち方がいちばん“実務っぽい”**と思いました。
圧倒的な一点突破ではなく、設計・実装・効率のバランスで勝っているのが、いかにも現場受けしそうです。
一方で、Kimi の「考えすぎる強さ」もかなり魅力的です。
確認質問をしたり、設計を丁寧に詰めたりするモデルは、短期のベンチマークだけでは見えない価値があります。
ただ、そこでトークンを大量に使うなら、実際の導入では悩ましい。ここは本当にトレードオフです。
Qwen については、スコアだけ見ると「そこそこ強い」で終わりそうですが、記事を読むと、計画の弱さが後工程に響いているのがわかります。
AIは局所的に賢くても、開発フロー全体では別の顔を見せる。これが一番おもしろく、そして厄介なところだと思います。
参考: Do Open Frontier Models Have A Chance Against Closed Models?
