開発者の間で「どのモデルで書くか」が日常の話題になった。ベンチマークの順位と、実際の開発で扱いやすいモデルは一致しない。両方を見て、作業の性質ごとに選び方を示す。
コーディング向けモデルは何で比べるのか
指標としてよく使われるのがSWE-bench Verifiedだ。GitHubの実際の不具合を題材に、モデルが正しいファイルを修正できるかを、単体テストの通過で判定する。現実のバグ修正に近い課題を測れる点が評価されている。
ほかに、コード生成の正しさを見るベンチマークや、関数呼び出しの信頼性を測る指標がある。エージェント的にコードを書く場合、単発の正答率より、道具を正しく呼べるかどうかが効いてくる。
つまり、一つのスコアで優劣は決まらない。修正の精度、長い文脈の維持、道具の使い方という複数の軸で見る必要がある。
ベンチマークで上位に来るモデル
SWE-bench VerifiedではClaude Opus系が首位に立ち、GPT系が僅差で続く。開発者向けの実戦比較でも、難しいチケットの解決ではClaude系が支持される傾向がある。
一方で、端末を操作しながら複数手順を回すエージェント作業では、GPT-6 Astraが強さを見せる。コードを書くという同じ行為でも、単発の修正と、計画を立てて自律で進める作業では、得意なモデルが分かれる。
実際の開発で扱いやすいのはどれか
現場の声と数値にはずれがある。ベンチマーク首位のモデルが、どの開発環境でも快適とは限らない。応答の速さ、指示の理解、既存コードの規約への追従など、日々の使い勝手は数値に出にくい。
ある開発者コミュニティの比較では、最も難しい課題はGPT系が解き、日常的な修正の手触りはClaude系が良いという評価が繰り返し現れた。道具としての馴染みやすさと、限界性能は別の軸だ。
IDEやエディタへの組み込みやすさも見逃せない。Cursorのようなツールがどのモデルを標準に据えているかは、実際の体験に直結する。
コストと速度のトレードオフ
コードを書かせる作業は、往復の回数が増えやすい。1回の単価が安くても、やり直しが多ければ総額は膨らむ。逆に単価が高くても一発で通れば安く済む。
速度も同じだ。推論に時間を割くモデルは正確だが待たされる。エディタで補完的に使うなら速度が優先され、設計の相談なら深さが優先される。
コストを抑えたい大量の定型作業には、オープンウェイトのコーディング特化モデルも選択肢になる。自前で動かせば、反復しても追加費用がかからない。
言語やフレームワークによる得意不得意
モデルによって、得意な言語やフレームワークに偏りがある。学習データの量が言語ごとに違うためだ。PythonやJavaScriptのような主要言語は、どのモデルでも安定しやすい。
マイナーな言語や、社内独自のフレームワークでは、公開データが乏しく精度が落ちる。こうした場面では、長い文脈を維持できるモデルや、既存コードを読み込ませて規約に合わせられるモデルのほうが有利になる。
日本語のコメントやドキュメントを扱う場合も、日本語性能が効いてくる。コードそのものより、説明や命名の質に差が出る。
用途別の選び方
難しい不具合の修正や、設計の相談には、SWE-benchで上位のClaude系が向く。端末操作を含む自動化や、複数手順を任せるエージェント作業にはGPT-6 Astraが候補になる。
日常のコーディングや補完には、速くて安いモデルで十分だ。費用を抑えたい大量処理には、オープンウェイトを検討する。
最終的な指針は、自分のリポジトリで試すことだ。同じチケットを複数のモデルに投げ、修正の質と往復の回数を比べる。この小さな実験が、公開スコアより信頼できる判断材料になる。
