はじめに

大きな機能の要件整理や実装計画には時間がかかり、AIコーディングエージェントとのやり取りも長くなります。筆者は複数のプロジェクトを並行して進める機会も増え、作業の途中で利用制限に当たることが多くなりました。そこで、必要なときに使い続けられるよう、すべての作業を同じモデルに任せるのではなく、作業に応じてモデルやエフォートを使い分けることを考え始めました。

この記事は、1つのモデルをデフォルト設定のまま使っている方に向けて、筆者の試行錯誤と現在の選び方を紹介します。

筆者は、作業で何を判断してもらう必要があるかを見てモデルを選びます。「エフォート」は、そのモデルにどの程度の推論をさせるかを調整する設定です。Codexでは「Reasoning Effort」と呼ばれますが、この記事では「エフォート」と表記します。モデルとエフォートを組み合わせて選ぶのが、この記事での考え方です。

モデルや利用するサービスによっては、エフォートは推論だけでなく、情報の探索や結果の確認、ツール呼び出しなどの作業量にも影響します。エフォートはlowやhighのような段階から選びますが、設定名や選べる段階は利用するサービスによって異なります。詳しくは、Claude Codeの「effort レベルを調整する」やCodexの「Pick a reasoning effort」を参照してください。

筆者の設定をそのまま使うのではなく、自分の作業で必要な品質と、待てる時間、利用枠の消費を考えるための材料にしてください。

執筆時点のモデルとAPI料金

本文のモデル名や設定名、次に示す主なモデルとAPI料金は、執筆時点（2026年9月末）の情報です。モデルの特徴は各社の説明を短くまとめたもので、筆者の作業での優劣を示すものではありません。CodexではOpenAIのGPT-6シリーズ、Claude CodeではAnthropicのClaudeシリーズを例に挙げます。利用できるモデルは契約や接続先によって異なります。

表の料金は、各社の標準的なAPI料金を入力・出力それぞれ100万トークンあたりの米ドルで示した参考値です。CodexやClaude Codeのサブスクリプションの利用枠の減り方を表すものではありません。キャッシュ、長いコンテキスト、バッチ処理、fast modeなどの料金は含めていません。

モデル	特徴	API入力料金	API出力料金
GPT-6 Astra	複雑な推論・コーディング向けの高性能モデル	$10.00	$50.00
GPT-6 Sol	複雑な実装やエージェント作業向けのモデル	$2.00	$10.00
GPT-6 Luna	範囲の定まった作業を大量にこなすための効率重視モデル	$0.10	$0.50
Claude Fable 5.1	長時間にわたる難しい作業向けのモデル	$10.00	$50.00
Claude Opus 5.5	長時間のエージェント作業や知識労働向けのモデル	$4.00	$20.00
Claude Sonnet 5.5	性能と速度のバランスを重視するモデル	$2.00	$10.00

料金の出典：OpenAIのAPI料金表、AnthropicのAPI料金表。料金は変更されることもあるため、実際に利用するときは各社の最新情報をあらためて確認してください。

ここからは筆者の経験を交えてお話ししますが、このあと登場する「Claude Opus 5」は、筆者が試行錯誤していた当時のモデルです。また、同じく記事中に登場する「Terra」はGPT-5.6世代のモデルで、GPT-6シリーズには含まれません。

筆者は、ClaudeではMax相当、CodexではPlus相当の環境を目安に検証しています。CodexをメインにしてSolを日常的に使う場合は、継続して作業できる利用枠を確保するために、Proプランが必要だと考えています。

まずは作業を別のモデルへ任せてみた

筆者は当初、Claude Opus 5を中心に使っていました。利用制限への対策として最初に試したのは、エフォートの調整ではなく、実装作業の一部をGPT-6 Lunaへ移すことでした。一度に広い範囲を任せたわけではありません。計画の段階で変更箇所と方法を具体化し、別の実装方針を考える余地がほとんどない、小さな変更から始めました。指示どおりに、すばやく変更できるかを確認しやすかったためです。

その後、Lunaのエフォートを高い段階のxhighや、もっとも高い段階のmaxに設定して調査を試し、速度と成果物の品質を確認しました。さらに、計画を立てたあとの少し複雑な実装へと任せる範囲を広げていきました。SolやTerraも試し、モデルだけでなくエフォートも変えるようになりました。利用量を見ていると、エフォートを変えた際に利用枠の減り方が違うと感じたことも、選び方を見直すきっかけでした。これは筆者の観察であり、同じ条件で利用量を比較した測定結果ではありません。

作業で必要な判断と、待てる時間を見る

モデルを選ぶときは、作業の名前よりも、何が決まっていて、何を判断してもらう必要があるかを見ます。

たとえば、原因と修正方法がわかっている小さなバグ修正なら、最初からLunaへ依頼することがあります。要件から実装方法を決める必要がある大きな変更では、まず要件を定義し、Solで変更するファイルや修正内容まで具体化した計画を作ります。その計画に沿った実装をLunaへ任せます。

これは、筆者が参考にしているSuperpowersのスキル群を取り入れた進め方の一例です。スキルとは、AIエージェントに作業の進め方などを与える手順や指示をまとめたものです。Superpowersには、要件の整理や計画、実装、レビューなどのためのスキルが用意されています。ただし、ここで紹介するモデルの使い分けにSuperpowersの導入が必須というわけではなく、すべての作業で詳細な計画書を作るわけでもありません。

急ぎの原因不明のバグなら、Solに調査から依頼します。一方、開発中の急がないバグなら、Lunaに時間をかけて調べてもらうこともあります。計画作業でも、結果を急がないならLuna maxを選ぶ場合があります。つまり、調査か実装かという分類だけでなく、方針が決まっているかと結果をいつまでに得たいかで選択が変わります。

性能だけでなく、作業が終わるまでを見る

筆者はモデルを比較するとき、まず性能を確認し、価格も見ます。ただし、単価が安ければ必ず得になるわけではありません。

回答の修正に何ターンも必要なら、作業が終わるまでの時間と利用量が増えます。この記事で特に重視する「コスト」は、APIの請求額よりも、必要なときに使える利用枠をどれだけ消費するかです。料金も選択の材料ですが、作業を終えるまでのターン数や待ち時間と切り離しては考えません。

Luna maxを使った経験から、品質やコストパフォーマンスだけでなく、作業が終わるまでの時間も見るようになりました。実装の品質に問題はなく、コストパフォーマンスもよいと感じていたため、一時期は多くの実装作業を任せていました。しかし、作業全体が終わるまでに非常に時間がかかるようになりました。

そこで通常の実装では、Luna xhighから試し、難しい場合はSol lowへ切り替えるようにしました。モデルだけでなく、エフォートも含めて使い分けを見直したことになります。この使い方に変えてから、以前より作業が速く終わるようになり、成果物の品質に大きな違いは感じていません。これは同じ作業を同じ条件で測った比較ではなく、筆者の運用上の実感です。

Luna maxを使わなくなったわけではありません。並行して進める低優先度の計画など、時間がかかってもよい作業では候補に残ります。

モデルとエフォートの組み合わせを見直す

難しい作業で必要な品質の成果物が得られないときは、品質と待ち時間を見ながら、モデルとエフォートの組み合わせを選び直します。いくつかのケースで考えてみましょう。

品質は十分、待ち時間が長い

品質は十分なのに待ち時間が長いなら、同じモデルのエフォートを下げることや、別のモデルとエフォートの組み合わせを試します。前の節の例でも、Luna max中心の使い方から、通常はLuna xhighを試し、難しい場合はSol lowへ切り替える使い方に変えました。モデルを変えるときも、エフォートを作業に合わせて選び直しています。

品質に問題あり

品質に問題があるときも、モデルの切り替えを考えます。たとえば、小さな変更のレビューをLunaに任せたところ、変更内容の明らかな問題を見逃したとします。指摘しても改善しない状態が続くなら、同じやり取りを重ねずSolへ切り替えます。とはいえ、一度の見落としだけで必ず切り替えるわけではありません。

エフォートを高くする前に

どの程度のエフォートが適切かわからないと、「とりあえず高くしておけば安心」と考えるかもしれません。しかし、必要以上に考えさせることが、かえって作業の効率を下げる場合もあります。OpenAIのGPT-5 Troubleshooting Guideでは、過大なエフォートを、単純な依頼でも検討を続けてしまう「考えすぎ」や、作業を前進させないツール呼び出しの原因の1つとして挙げています。必要な品質をすでに満たしているなら、さらに探索や確認を重ねても、待ち時間や利用量が増えるだけかもしれません。

エフォートは、高くしておけば安心という設定ではなく、作業に必要な分だけ考えてもらうための設定として捉えます。一段下げても成果物が要件を満たし、指示漏れがなければ、その作業には低い設定で十分かもしれません。

筆者の使い分け例

筆者の現在の選択を、3つの例に絞ると次のようになります。特定のモデルや設定を読者に推奨する表ではありません。

作業の状況	選択例	選ぶ理由
普段の計画	Sol medium	要件から実装方法を決め、変更箇所や修正内容まで具体化したい
方針が決まった実装	Luna xhighから試す	計画に沿って実装し、結果を確認できる
完了を急がない作業	Luna maxも候補にする	時間はかかるが、品質を期待できる

計画を立ててから実装を任せる場合、実装中に想定外の問題が見つかれば、Lunaで解決できそうならそのまま対応してもらいます。難しければSol lowなどへ切り替えます。計画を変えなければ解決できない場合は、勝手に逸脱せず変更案を出してもらい、基本的には筆者が判断します。

実装後のレビューでは、計画との一致だけでなく、要件を満たしているかを確認し、テストも実行します。変更範囲が小さく、テストが十分にある場合はLunaへレビューを任せることもあります。レビュー中に見落としが続けばSolへ切り替えます。テストが通ることだけで、あらゆる不具合がないとは判断しません。

ベンチマークは出発点にする

候補を探すとき、筆者はArtificial Analysisなどのベンチマークを確認し、性能と価格を見ます。ただし、その順位だけで普段使うモデルは決めません。ベンチマークの測定条件と、スキルや指示を組み込んでエージェントに作業させる環境は異なります。実際の作業で、成果物の品質、完了までの時間、利用量を確かめます。

数値を見るときは、何を測った指標かにも注意が必要です。たとえば、回答の出力が始まるまでの待ち時間と、出力が始まってからの速度は別のものです。また、測定時期や条件が異なる数値を、そのまま現在の性能として扱うことはできません。

ベンチマークの評価と使用感が合わないなら、モデルそのものの性能だけでなく、指示やスキルの影響も疑います。ただし、筆者には、指示を変更して評価が変わった具体例はまだありません。実証済みの改善策ではなく、比較するときに確認したい観点です。

高いエフォートを使うときの速度

必要な品質を得るために高いエフォートを選び、その待ち時間を短くしたい場合は、モデルの処理を高速化するfast modeも選択肢になります。たとえば、CodexのFast modeは、エフォートとは別に切り替える設定です。ただし、通常より利用枠や料金の負担が増えます。適用条件や負担の増え方は、利用するサービスや接続方法によって異なります。

筆者も、利用環境のfast_modeで速度を補うことがあります。Lunaでは常時有効にして高めのエフォートで使うこともありますが、一般的な推奨設定ではありません。必要な推論の待ち時間を短くすることと、不要な探索や確認を減らすことは別です。 高速化できるからとエフォートを高くするのではなく、まず作業に必要なエフォートを選び、そのうえで待ち時間を短くするための負担を受け入れるか考えます。

まずはエフォートを一段下げてみる

複数のモデルを使い分ける前に、まずは、いま使っているモデルのエフォートを調整するところから始めてみてください。エフォートを変更できるか、現在の設定と選べる段階を確認します。CodexのCLIでは/modelからモデルとエフォートを選べます。ほかの利用環境での操作は、Codexの公式ドキュメントやClaude Codeのモデル設定を参照してください。

いまの設定より低い段階を選べるなら、一段下げて試します。たとえば、highからmediumへ下げる、といった変更です。すでに最低の段階で使っている場合や、エフォートを変更できない環境では、この方法は試せません。

比較するには、普段から繰り返していて、結果の良し悪しを判断しやすい作業を選ぶと、違いを確かめやすくなります。成果物が要件を満たすか、指示が漏れていないかを確認します。応答時間や利用量の変化も見ておくと、選択の材料になります。

品質が落ちたり指示漏れが出たりしたら、元の設定へ戻します。問題がなければ、その作業には低いエフォートで十分かもしれません。

筆者の使い分けも最初から決まっていたものではありません。利用制限をきっかけにモデルを試し、エフォートも変えながら、必要な品質と待ち時間、利用量のバランスを探ってきました。まずは一段だけ設定を変え、自分の作業で違いを確かめるところから始められます。