モデル使い分けの「固定費」って、どこから割に合うんだろう

Last updated at 2026-05-10Posted at 2026-05-10

最近、GPT-5.5 と Claude Opus 4.7 を どう使い分けるか という話をよく目にします。

よく見るのは、「GPT-5.5 は自走・探索・ツール横断、Opus 4.7 は精密修正・レビュー・仕様厳守、だから工程ごとに分業させるとよい」という整理です。

この主張自体は、かなり納得できます。

実際、OpenAI の GPT-5.5 発表では、コーディング、リサーチ、データ分析、ドキュメント作成、ソフトウェア操作をまたいでタスクを進める力が強調されています。Terminal-Bench 2.0 では GPT-5.5 が 82.7%、Claude Opus 4.7 が 69.4% という比較も出ています。

一方で Anthropic の Opus 4.7 発表では、難しいソフトウェアエンジニアリング、長めのタスク、指示への精密な追従、自己検証が強調されています。SWE-Bench Pro では Opus 4.7 が 64.3%、GPT-5.5 が 58.6% という数字もあり、「実装・修正・レビュー寄りなら Opus」という見方も分かります。

なので、どちらが強いかという勝敗の話をしたいわけではありません。

自分が気になっているのは、そこではなくて、それを本当に工程として分けるほどの仕事って、どれくらいの規模から出てくるんだろう? という点です。

これも前回の記事と同じで、主張に反対したいわけではない。ただ、自分の手元の開発と、SNS で語られているモデル分業の話のあいだに、少し距離を感じています。

自分の現場では、まだ分業させるほどの必然性がない

自分も仕事で AI を使っています。

ただ、普段の開発で「GPT-5.5 に探索させて、Opus 4.7 に精密修正させて、別のモデルにレビューさせる」みたいな分業を常用するかというと、正直そこまでの場面があまりありません。

特にマイクロサービスを開発している範囲だと、1つのサービスの責務はそれなりに切られています。もちろん複雑な業務ロジックはありますが、巨大なモノリスを丸ごと探索して、複数のツールをまたいで、長時間自走させるような仕事ばかりではありません。

AI を使うときの典型的な流れは、だいたいこんな感じです。

仕様や既存コードを見ながら、AI と対話する
修正方針を決める
実装してもらう
差分を見て、気になるところを直す
テストや型チェックを回す
もう一往復、レビュー観点で対話する

この流れだと、途中でモデルを切り替えるより、Opus 4.7 のようなモデルで一貫して進めたほうが速い感覚があります。

これは「Opus が GPT より優れているから」という話ではありません。単に、切り替え固定費を払えるだけのタスク量が、そもそもない という話です。

切り替えるたびに、見えない固定費が乗る

モデルを切り替えると、どうしても受け渡しが発生します。

これまでの会話、判断の背景、細かい制約、どこまで確認したか、何を捨てたか。そういうものを次のモデルに渡す必要があります。

もちろんコンテキストを全部貼ればよい、という話ではあります。でも、実際には「全部貼る」こと自体がひとつの作業です。しかも貼ったところで、前の会話の空気や判断の重みまで完全に引き継がれるわけではありません。

真面目に書き出すと、切り替え時にはこれくらいのコストが乗ります。

それまでの会話の文脈をどう渡すか考える
判断の背景や、捨てた選択肢を説明し直す
モデルごとのプロンプトの癖に合わせる
出力の癖に合わせて、採否の基準を頭の中で切り替える
うまく行かなかったとき、どのモデルの判断が原因かを切り分ける

ひとつひとつは数十秒の話かもしれません。

でも、対話 1 ターンあたりの摩擦が確実に増える。マイクロサービス 1 本を進めるくらいの規模だと、この摩擦の合計が、モデル分業で得られる「自走力」と「精密さ」の上振れ分を食い潰している感覚があります。

だから自分の現場では、モデル分業は「できるけど、まだ得をしていない」ことが多いです。

ベンチマークの差は、工程分業の証明ではない

調べていて改めて思ったのは、ベンチマーク上の得意不得意と、実務で工程を分けるべきかどうかは、少し違う問題だということです。

GPT-5.5 は Terminal-Bench 2.0 や OSWorld-Verified のような、自走・ツール利用・コンピュータ操作を含む評価で強く見えます。OpenAI も、曖昧な複数ステップのタスクを渡すと、計画し、ツールを使い、確認しながら進めるという方向を強調しています。

Opus 4.7 は SWE-Bench Pro やコードレビュー系の事例で強く見えます。Anthropic の発表でも、指示への注意深さ、長い作業の一貫性、出力前の検証が前面に出ています。

ここから「GPT-5.5 は探索担当、Opus 4.7 は修正担当」という整理が出てくるのは自然です。

ただし、それは それぞれのモデルに違う強みがある という話であって、すぐに 1つのプロジェクト内で工程分業したほうがよい という話にはなりません。

問いは「どのモデルが強いか」ではなく、モデルを切り替える固定費を回収できる仕事かどうか なんだと思います。

「人間が切り替える」と「システムが振り分ける」は別の話

もうひとつ、混ざって語られていて解像度が合わなくなるポイントがあります。

世の中で「モデル使い分け」と呼ばれているものには、よく見ると 2 種類 あります。

人間が会話の途中で手で切り替える使い分け: エディタや IDE で、自分でモデルを選び直すパターン
システムがプロンプトに応じて自動振り分けする使い分け: Bedrock の Intelligent Prompt Routing や、開発環境が内部で複数モデルを束ねるパターン

この2つは、経済性が全然違います。

前者は、切り替え固定費を 毎回人間が払う 形です。判断する負荷も自分にかかります。小さい開発だと、まず割が合いません。

後者は、ハーネス側にコストを寄せる 形です。トラフィックや過去の実績や評価関数を使って、システム側がモデルを選ぶ。これは個人の対話というより、大量のリクエストを流すプロダクトや業務システムの最適化の話です。

Amazon Bedrock の Intelligent Prompt Routing は、まさに後者の方向です。同じモデルファミリー内で、プロンプトに応じてモデルを振り分け、品質とコストのバランスを取る仕組みです。

こういう仕組みを見ると、「やっぱりモデルは使い分ける時代なのか」と思います。

ただ、これは個人がエディタで毎回「ここは GPT-5.5、ここは Opus 4.7」と手で選ぶ話とは少し違います。大量のタスクやリクエストがある世界で、モデル選択の判断を人間ではなくシステム側に寄せる話です。

自分の手元の対話は前者の世界で、Cursor や Bedrock 的なルーティングは後者の世界。この2つが混ざって語られるから、自分の現場と地続きに感じにくかったのかもしれません。

分業が効きそうなのは、仕事が本当に「工程」として分かれているとき

では、どんな場合ならモデル分業が効くのか。

今のところ、自分の中では 工程が本当に分かれている仕事 なら意味がありそうだと感じています。

たとえば、こういうものです。

大きなコードベースを探索して、変更候補や影響範囲を洗い出す
複数リポジトリや複数サービスをまたいで、依存関係を調べる
大量の issue やログやドキュメントから、作業単位を切り出す
何十個もの小タスクを並列に投げる
生成されたパッチを別モデルでレビューする
夜間バッチ的に、失敗したら再試行しながら進める

ここまで来ると、たしかに「探索役」「実装役」「レビュー役」「統合役」を分ける意味が出てきそうです。

GPT-5.5 のように、ツールを横断して長く動くモデルに探索や実行を任せる。Opus 4.7 のように、仕様追従や精密なレビューが強いモデルに最終確認を任せる。これはかなり自然な設計に見えます。

実際、OpenAI の Codex subagents ドキュメントでも、PR レビューを複数の専門エージェントに分ける例が出ています。pr_explorer が影響範囲を読み、reviewer が correctness や security のリスクを見る。さらに docs_researcher がフレームワークや API の仕様を確認する、という構成です。モデルも同じではなく、探索役には gpt-5.3-codex-spark、レビュー役には gpt-5.4、ドキュメント確認には gpt-5.4-mini が割り当てられています。

これはかなり分かりやすい「工程分業」の例です。ただし同じドキュメントでは、subagent は単一エージェントよりトークン消費が増えるので、明示的に求められたときだけ起動する、という線引きもされています。つまり、公式の例でも 分業は便利だが無料ではない という扱いです。

もう少し具体的に考えると、たとえば 100以上のマイクロサービスが複雑に絡み合っている大きなプロジェクト なら、モデル分業の有効性が見えてきます。

各サービスが AWS 上に展開されていて、障害対応、テスト、デプロイ確認、ログ調査、影響範囲の洗い出しが複数サービスをまたいで発生する。さらに、それを特定の熟練者だけでなく、不特定多数の担当者が自然言語で扱えるようにしたい。

この規模になると、個人がエディタでモデルを切り替える話ではなくなります。Bedrock のような基盤を使って、サービス全体の効率化、テスト、エラー時の対応、運用ナレッジの引き出し方まで含めて、ハーネスをカッチリ作る話になります。

たとえば、障害対応ひとつ取っても、最初に GPT-5.5 的なモデルが複数サービスのログ、メトリクス、デプロイ履歴、関連 issue を横断して調べる。その結果をもとに、Opus 4.7 的なモデルが影響範囲や修正案を精密にレビューする。さらに別の軽量モデルが定型的な通知文やチケット更新を処理する。

こういう世界なら、モデルの使い分けはかなり自然です。というより、人間が毎回判断するのではなく、ハーネス側がタスク種別に応じて自動で振り分けないと回らないはずです。

一方で、これくらいの規模や複雑さがないなら、使い分けの有効性はかなり限定的なのではないか、という気もしています。

この感覚に近い数字を出している記事もありました。Augment Code のモデルルーティング記事では、動的ルーティングは各リクエストの前に分類ステップを挟むため、1判断あたり 50〜200ms 程度のレイテンシが乗ると説明されています。そのうえで、1日500回未満のエージェント呼び出ししかないチームでは、ルーターを保守するエンジニアリングコストが節約分を上回りやすい、と整理していました。

もちろん、これは特定サービスの記事なので絶対的な境界線ではありません。ただ、自分の手元の開発とは桁が違う世界を前提にしている ことは分かります。1日に数回、せいぜい十数回 AI と相談するような開発で、モデルルーティングの仕組みを作っても、固定費を回収する前に作業が終わってしまう。

1人の開発者が1つのマイクロサービスを見ながら対話で進める くらいの仕事では、探索・実装・レビューが会話の中で混ざっています。

「この関数を見て」
「この仕様だとこっちの分岐も必要では」
「テストを足して」
「この差分はやりすぎなので戻して」

こういう細かい往復の中で、いちいちモデルを切り替えるのは面倒です。工程が分かれていないのに、無理に分業させている感じが出ます。

境界線は「モデル差」ではなく「固定費を回収できるか」

ここまで調べて、自分の中では少し整理がつきました。

GPT-5.5 と Opus 4.7 の使い分けは、たぶん本当に意味があります。

ただし、それは「どちらも得意不得意があるから、常に使い分けるべき」という話ではない。

使い分けが効くのは、おそらく次の条件がいくつか揃ったときです。

1つの会話で抱えるには大きいコードベースや業務文脈がある
探索、実装、レビュー、統合が工程として分離している
複数タスクを並列に走らせるだけの仕事量がある
複数サービスやクラウドリソースをまたいで調査・対応する必要がある
熟練者だけでなく、多数の担当者に自然言語の操作導線を配る必要がある
モデル利用料やトークン量を最適化する意味がある
成果物を機械的に検証できるテストや評価系がある
モデル選択を人間ではなくハーネス側に寄せられる

この条件がないなら、モデルを使い分けるより、強いモデルを1つ選んで一貫して対話したほうが速い場面は多いと思います。

少なくとも、自分のマイクロサービス開発の範囲ではそうです。

もちろん、これは「モデル分業はいらない」という話ではありません。むしろ逆で、もっと大きなスケールでは必要になるのだと思います。

たとえば、巨大なモノリポ、100以上のマイクロサービス、複数サービスをまたぐ移行、大量のPRレビュー、AWS リソースを含む運用自動化、夜間に走らせる長時間エージェント。そういう世界では、GPT-5.5 的な自走力と、Opus 4.7 的な精密さを分けて使う価値が出てくるはずです。

でも、そこまで行かない日常開発では、モデル切り替えよりも、同じモデルとの対話を深くするほうが効く。

Karpathy の autoresearch も、この境界線を考える材料として面白いです。GitHub の README では、固定時間で実験を回し、単一 GPU・単一ファイル・単一指標に絞る設計になっています。つまり、人間が会話の中心にいるのではなく、評価指標が閉じた環境でエージェントが大量に試す世界です。こういう前提なら、探索や実験を自動化する意味がはっきり出ます。

逆に、日本語圏の記事でも「併用するなら設定資産の二重管理コストを見ろ」という整理がありました。AGENTS.md と CLAUDE.md のような規約ファイルが分かれると、半年でナレッジが分断する、という指摘です。ここでも結局、モデルやツールを増やすほど、会話の外側に固定費が積もるという話に戻ってきます。

このあたりは、前に書いた「汎用 × 反復」の話とかなり似ています。

AI の自動化も、モデルの使い分けも、たぶん 一定以上の反復量と規模があって初めて投資に見合う。それ未満の現場では、きれいな分業図より、目の前の対話の連続性のほうが価値を持つ。

自分が知りたいのは、まさにこの境界線です。

「GPT-5.5 と Opus 4.7、どっちが強いか」ではなく、どれくらいの規模になったら、モデルを分けるほうが一貫運用より速くなるのか。

この問いは、しばらく自分の中で持っておきたいです。

参考にしたもの

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up