AIエージェントのモデルと推論強度はどう選ぶ？｜広さと深さで決める4つの基準

私は「強いモデルなら全部うまくいく」と考えかけていた

AIエージェントへ開発を頼むとき、モデル名と推論強度の選択肢が並びます。

私は最初、「難しそうなら一番強いモデルでMaxにすれば安心なのでは」と考えました。

ただ、日々の作業には、画面を1つ追加するような定型作業もあれば、複数フォルダをまたいで原因を探す障害対応もあります。

全部を同じ設定にすると、簡単な修正でも待ち時間が増えます。反対に、広いコードベースの構造確認を軽い設定へ任せると、離れた場所にある依存関係を見落とす心配があります。

そこで、モデルの強さだけで決めず、次の2つを分けて考えることにしました。

作業範囲：どれだけ広い場所を見渡す必要があるか
論理の深さ：どれだけ丁寧な検証や推論が必要か

結論は「広さでモデル、深さで推論強度」を決める

私が使う基本の判断表は、次の4分割です。

ここで大切なのは、モデル名を丸暗記することではありません。

• Sol / Opusは、広い範囲を見渡す上位モデル
• Terra / Sonnetは、日常的な実装を任せやすいバランス型
• Luna / Haikuは、対象がはっきりした小さな作業を速く回す軽量型

このように、各サービスのモデルを役割へ置き換えると判断しやすくなります。

OpenAIのモデル名は更新されます。2026年9月8日時点の公式モデル一覧では、GPT-6 Astraが最も難しい仕事向け、GPT-5.6 Solが複雑な専門作業向け、Terraが知能とコストのバランス型、Lunaがコスト重視の大量処理向けと案内されています。

OpenAI公式：Models

そのため、上の表にある「Sol」は固定名ではなく、その時点の上位モデル枠として読むのが安全です。特に重大な全体障害では、現在の環境で使える最上位モデルも候補に入れます。

広く見る必要がある作業は上位モデルへ任せる

複数ファイルや複数機能にまたがる作業では、1つの関数だけ正しくても十分ではありません。

たとえば認証方式を変えるなら、ログイン画面だけでなく、API、保存先、権限判定、再読み込み後の状態までつながります。

画面 → 入力処理 → API → 保存 → 表示 → 再読み込み

このような作業では、離れた場所にある関係を見つける力を優先します。基本はSol / Opus相当の上位モデルです。

ただし、複数ファイルを触るだけで推論強度をMaxにする必要はありません。

既存の設計がはっきりしているリファクタリングなら、LowまたはMediumから始めます。広い範囲を見渡す能力はモデルで確保し、考える量は必要以上に増やさないためです。

例：5つのAPIへ認証方式の変更を反映する

この作業は範囲が広い一方、変更パターンが決まっていれば論理は極端に深くありません。

私なら、Sol / Opus相当 + Low〜Mediumを選びます。

最初に関連ファイルを列挙し、共通処理、個別処理、テストのつながりを確認してから、同じ方針で変更します。

定型的な機能追加はバランス型で速く進める

プロフィール編集画面や一般的なCRUDのように、プロジェクト内に既存パターンがある作業は、Terra / Sonnet相当 + Low〜Mediumが基本です。

ここでは最高性能より、既存コードへ合わせながら一定の速さで作ることを優先します。

たとえば、すでに「一覧、詳細、作成、更新、削除」の実装例があるなら、新しい管理画面も同じ構成へ当てはめやすくなります。

既存の実装例を確認
  ↓
同じ入力・保存パターンで作成
  ↓
型チェックと対象テスト
  ↓
画面で保存後の再表示を確認

素早い試作中にMaxを選ぶと、画面を少し変えるたびに待つことになります。仕様を探っている段階ではLow〜Mediumで回し、方向が固まってから必要な確認を追加するほうが、テンポを保ちやすくなります。

狭いけれど難しい不具合は、切り分けてMaxを使う

対象が1つの関数やファイルへ絞れていても、条件の組み合わせが多い不具合があります。

• 高負荷のときだけ起きる競合
• 特定の順番でだけ壊れる状態更新
• 境界値で発生する計算違い
• 再試行とタイムアウトが重なったときの二重処理

このような問題では、Terra / Sonnet相当、またはLuna / Haiku相当へMaxを組み合わせる選択肢があります。

重要なのは、Maxへ上げる前に対象を狭くすることです。

関連しそうなフォルダを全部渡したまま深く考えさせると、調査対象も推論量も膨らみます。まず再現条件、失敗する関数、入力、期待する出力を固定します。

再現条件：同じIDへ2件の更新が同時に届く
対象：WebSocketの更新ハンドラー1つ
期待結果：後から確定した更新だけを1回保存する
失敗結果：古い更新が最後に上書きされる

ここまで絞れていれば、軽量またはバランス型モデルでも、深い推論を問題そのものへ集中させやすくなります。

全体障害だけは上位モデルとMaxを組み合わせる

最も重い設定は、原因が分からず、影響もシステム全体へ広がっているときに使います。

たとえば、認証、データ保存、バックグラウンド処理が同時に不安定で、どこが最初に壊れたのか分からない状況です。

この場合は、広い探索と深い検証の両方が必要なので、現在利用できる最上位モデル + Maxが候補になります。

ただし、これは非常時の設定です。

原因の候補が見つかり、対象を1つの経路へ絞れたら、次の作業からモデルや推論強度を下げられないか見直します。

同じ失敗が2回続いたら、設定を上げる前に原因を見る

私は、生成したコードがコンパイルやLintで同じ種類のエラーを2回続けたら、そのまま3回目を試さないルールにします。

まず確認するのは、次の3点です。

1. エラーメッセージを正確に読めているか
2. 修正対象を間違えていないか
3. 前提にしている型や仕様が古くないか

そのうえで、対象は狭いのに論理が難しいと分かった場合は、推論強度を一段上げます。

対象範囲を取り違えていた場合は、モデルを強くするより、先に読むファイルや再現手順を直します。

強い設定は、曖昧な依頼を自動で正しくしてくれる魔法ではありません。どこまで見て、何を成功とするかを決めてから使うほうが効果的です。

推論強度は作業の途中でも見直してよい

最初の選択を最後まで固定する必要はありません。

OpenAI公式のモデルガイダンスでも、難しい作業では推論強度を上げ、定型的な続きでは下げる考え方が案内されています。対応するモデルや利用方法は環境によって異なるため、実際に選べる設定を確認して使います。

OpenAI公式：Model guidance

私なら、1つの開発を次のように切り替えます。

この切り替えなら、調査から実装、デバッグ、確認までを、ずっと同じ重い設定で進めずに済みます。

私が作業前に確認する5つの質問

最後に、モデルを選ぶ前の確認を5つに絞ります。

1. 触るのは1つの関数か、複数の機能か
2. 既存パターンを使えるか、設計から考える必要があるか
3. 不具合の再現条件は絞れているか
4. 今は試作中か、公開前の最終確認か
5. 同じ種類の失敗が2回続いているか

作業範囲が広ければモデルを上げ、論理が深ければ推論強度を上げます。

そしてMaxを使う前に、できるだけ問題を小さくします。

この順番を決めておくだけでも、「とりあえず一番強い設定」を選ぶ回数は減らせそうです。