私には、プロダクトオーナー・エンジニアとして常に抱えている大きな課題があります。それは「いかにコスパ良くソフトウェア・システム開発ができるか？」ということです。
現在、AIコーディングの能力を測るベンチマーク「SWE-bench Pro」などのランキングを見ると、Claude系が上位を占めていますよね。しかし、実際のプロダクト開発で手を動かしている中で、私は現在GitHub Copilotのメインモデルとして「GPT-5.5」を選択しています。
カタログスペックと私の体感値にはズレを感じるため、今回は「コスパの最適化」という観点から、私のモデル選択の変遷についてまとめてみたいと思います。
高性能だが「高すぎる」Opusと、実装が漏れるSonnet
私は普段、GitHub Copilotをメインの開発環境として利用しています。AIを利用し始めた当初は、Claude Sonnet 4.6をメインに据え、サブとしてGPT-5.4を使い分けるスタイルでした。
特にPlanモード（計画フェーズ）の時には、Claude Opusを使って実装計画書や設計書を作成させていました。正直なところ、Opusは非常に賢く、人間が見落としていた仕様の漏れまでしっかりカバーしてくれます。手戻りが防げるという意味では非常に優れた性能を持っています。
実際、最新のOpus 4.8を使ってみたところ、GPT-5.5でどうしても解決できなかった不具合を見つけて修正してくれました。（私が試行錯誤の末に渡したコンテキストの内容がたまたま良かっただけかもしれませんが、それでもその推論能力はやはり優秀です）。
しかし、いかんせん絶対的な金額（単価）が高すぎます。
日常的な実装の壁打ちやトライアンドエラーでガンガン回すにはコストがかさみ、「コスパ良く開発する」という私の命題からは外れてしまい、用途が設計等の要所に限定されてしまいます。
そこで、コストの安いSonnetに実装を任せてみると、今度は肝心の実装がごっそり抜け落ちていたり、コメントで // TODO: 実装する と放置されていたり、画面間の動線が繋がっていなかったりという状態が頻発しました。（さらに4月頃はClaudeの挙動自体が不安定で、後日公式からバグの報告が出るなど、サブのGPT-5.4の方が賢く動く逆転現象すらありました）
私の体感とベンチマークで差があるのはなぜか
では、上記のように私の業務で課題を感じるClaudeが上位で、逆に頼りになるGPT系が、なぜSWE-bench ProのようなベンチマークでClaudeに大きく差をつけられているのでしょうか。
実は最初からその理由が分かっていたわけではありません。ですが、2026年5月に発表された新しいAIコーディングベンチマーク「DeepSWE」の記事を読んだとき、非常に腑に落ちました。
DeepSWEの開発チームは、既存のSWE-bench（過去のGitHubのIssueとPull Requestを評価に使用）が抱える「データ汚染（リーク）」の可能性を指摘しています。つまり、最新のモデルたちは、訓練データの段階で既にそのIssueの答えとなるコードを含んで学習しており、いわば「ベンチマーク向けの試験勉強」をしてしまっている可能性があるということです。
これに対しDeepSWEは、完全にゼロから書き下ろしたオリジナルのタスクを用意し、コードの差分ではなく「実際にソフトウェアを動かして振る舞いが正しいか」をテストするように設計されています。このアプローチの違いを見たとき、実務での体感とカタログスペックの差は、こうした「カンニング的な要素」が影響していたのだと、私の中でしっくりと繋がりました。
従量課金化と、私の経験に基づくGPT-5.5・5.4の使い分け
そうしたカタログスペックの乖離を理解した上で、GitHub Copilotが完全な従量課金へ移行したことで、「どのモデルを選ぶか」がダイレクトにコストに直結するようになりました。
そこで行き着いた最適解が、現在のGPT系をメインとする体制です。
GPT系のアプローチは、基本的には「余計なことはしない」スタンスです。しかし、指示への忠実性が高く、必要な部分・漏れている部分は的確に補ってくれます。
当初、ラリー回数が劇的に減るGPT-5.5をメインに置いていました。確かにGPT-5.5の実装速度は非常に優秀で、急いでいる時やトークン使用量にこだわりがなければ最高の選択肢です。（現実問題として、AIの生成速度よりもビルドの時間や単体テストの実行時間の方がボトルネックになっています）。
しかし、あくまで私の体感ですが、GPT-5.5を使い込んでいくうちにトークン消費量の多さ（予測の難しさ）に気づきました。HighやxHigh設定で回すと、一度の処理で1000〜2000トークンを一気に消費して驚く時が何度かあったのです。Medium設定でも基本は200前後で済みますが、たまに1000を超えることがあり、コストコントロールの扱いが非常に難しいと感じました。
そこで再評価したのがGPT-5.4です。
実は、GPT-5.4はコードに対して発生するトークン使用量が5.5より格段に少なく、それでいて「xHigh」設定で回せば、ある程度の実装やプログラミングは十分にこなせることが分かりました。
まとめと、これからについて
ベンチマークの点数は、あくまで特定のテスト条件下でのスコアでしかありません。
ちなみに、先日SWE-bench等でスコア上位として大々的に発表されたばかりの最新モデル「Claude Fable 5」ですが、セキュリティ上の懸念（ジェイルブレイク手法の発見等）から米国政府の輸出管理指令が入り、なんと公開からわずか3日後の2026年6月12日に全世界で公開停止（アクセス遮断）になるという異例の事態が起きています（参考：Anthropic公式声明や各メディア報道）。カタログスペックが高くても、実務で安心して使えなければコスパ以前の問題です。
私がいま最も強く感じているAIエージェントを利用した開発の課題は、「いかにコスパ良くソフトウェア・システム開発ができるか」です。だからこそ、単一の高性能なモデルにすべてを依存するのではなく、状況に応じた緻密な使い分けが不可欠になります。
あくまでこれまでの私の経験と体感に基づいたものですが、現在私が導き出した運用方針は以下の通りです。
- Planモード（計画・設計）: 圧倒的な推論力を持つOpus 4.8、またはGPT-5.5のxHighを使用する。
- 実装モード: トークン消費が少なくコスパに優れるGPT-5.4のxHighを使用する。
逆に、定型作業をこなすSKILL機能や、バックグラウンドで動かすサブエージェントには、トークン節約のためにさらにモデルのレベルを下げる。
環境が整えば、ローカルLLMの活用やさらに安価なモデルへの切り替えなども十分に選択肢に入ってきますよね。
ただ、この「コスパと使い分けの最適解」を探る試行錯誤は現在も継続中です。
次回の記事では、さらに踏み込んだ「具体的なトークン節約の仕組み化」について掘り下げてみたいと思います。
コメント