AIコーディングでモデルを切り替える基準:速さ・費用・難しさで決めるメモの作り方
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。
AIコーディングのモデルは、ランキングの上位かどうかではなく、「この作業で失敗したら何が起きるか」で切り替えるのが実用的です。基準は3つに絞れます。 • 速さ:返事を待てる時間か。補完や小さな質問は待ち時間が短いほど作業が途切れません。 • 費用:その作業を1日に何回頼むか。回数が多い作業ほど、1回あたりの消費の差が効きます。 • 難しさ:一度で外れたときの手戻りが大きいか。複数ファイルにまたがる変更や原因不明の不具合は、外れたときの損失が大きくなります。 おすすめの運用は、普段使う「既定モデル」を1つ決め、そこから上げる条件と下げる条件を作業種別ごとにメモしておく方法です。頭の中の感覚を文字にしておくと、迷う時間が減り、あとで見直せます。この記事では、そのメモの雛形、記入例、記入を手伝わせる依頼文を順に示します。
公式資料で確認できること(2026年10月29日に閲覧)
切り替えの手段と考え方は、ツールごとに次のように説明されています。モデル名や既定値は更新されるため、実際の一覧は各ページで確認してください。
- Claude Code:モデル設定のページによると、セッション中は /model で切り替えられ、起動時は --model、環境変数、設定ファイルでも指定できます。sonnet(日常のコーディング向け)、opus(複雑な推論向け)、haiku(単純で速い作業向け)といったエイリアスがあり、計画はOpus、実行はSonnetにする opusplan も紹介されています。保存した選択が次回の既定になる点や、そのセッションだけの切り替えができる点も記載されています。
- GitHub Copilot:チャットモデルの変更手順では、VS Codeなどのチャット画面のモデル選択から変更します。Visual Studio向けの手順では、「Auto」を選ぶと作業に応じてモデルが自動選択されると説明されています。使えるモデルはプランと利用場所に依存し、モデルごとに消費の度合いが異なるとも書かれています。Businessでは、組織がモデルの切り替えを許可する必要があります。なお、チャットのモデル変更はインライン補完のモデルには反映されません。
- Cursor:モデルと料金のページでは、プランによって選べるモデルが異なること、自動選択のAutoがあること、利用枠の仕組みがプランごとに定められていることが説明されています。Autoの利用可否や選べるモードもプランによって異なります。具体的なモデル名や枠は変わりやすいため、契約中のプランの表示を見て判断してください。
各ツールには、モデルを切り替えるための操作が用意されています。難しいのは「いつ切り替えるか」を毎回考えることなので、条件を先に決めておく価値があります。
切り替えメモの雛形
まず、使えるモデルを3段階に分けて名前を埋めます。段階は相対的なもので、性能順位を調べる必要はありません。「速くて消費が軽いもの」「普段使うもの」「重い作業用に使うもの」の3つを、自分の環境の選択肢から選びます。
- 軽、位置づけ：速い・消費が軽い、使うモデル名(記入)：
- 標準、位置づけ：既定。普段はこれ、使うモデル名(記入)：
- 重、位置づけ：遅い・消費が重いが難所向け、使うモデル名(記入)：
次に、作業種別ごとの切り替えメモを書きます。コピーして使ってください。
- 小さな修正・名前変更、既定の段階：、上げる条件(→重)：、下げる条件(→軽)：、確認方法：、実際に使ったモデル・結果メモ：
- コードの説明・読み解き、既定の段階：、上げる条件(→重)：、下げる条件(→軽)：、確認方法：、実際に使ったモデル・結果メモ：
- テスト追加、既定の段階：、上げる条件(→重)：、下げる条件(→軽)：、確認方法：、実際に使ったモデル・結果メモ：
- 不具合の原因調査、既定の段階：、上げる条件(→重)：、下げる条件(→軽)：、確認方法：、実際に使ったモデル・結果メモ：
- 複数ファイルの変更、既定の段階：、上げる条件(→重)：、下げる条件(→軽)：、確認方法：、実際に使ったモデル・結果メモ：
- 設計・方針の相談、既定の段階：、上げる条件(→重)：、下げる条件(→軽)：、確認方法：、実際に使ったモデル・結果メモ：
- 文書・コメント整備、既定の段階：、上げる条件(→重)：、下げる条件(→軽)：、確認方法：、実際に使ったモデル・結果メモ：
「確認方法」の列が重要です。テストが通る、型チェックが通る、差分を人が読む、など、AIの回答が正しいかを誰がどう確かめるかを書いておくと、軽いモデルに下げてよいかの判断材料になります。確認方法が弱い作業ほど、段階を上げる理由が増えます。
記入例(説明用の例)
以下は説明用の架空の例で、実際に測定した結果ではありません。段階の対応は、前述のClaude Codeのエイリアス説明に合わせて「軽=haiku、標準=sonnet、重=opus」と置いています。
- 小さな修正・名前変更、既定：軽、上げる条件：同じ修正で2回外れた、下げる条件：なし、確認方法：差分を目で確認、型チェック
- テスト追加、既定：標準、上げる条件：対象が3ファイル以上に依存する、下げる条件：既存テストの形をなぞるだけ、確認方法：テスト実行
- 不具合の原因調査、既定：標準、上げる条件：再現手順が不明、または2回仮説が外れた、下げる条件：原因の行が特定できた後、確認方法：再現が消えるか
- 複数ファイルの変更、既定：重で計画→標準で実装、上げる条件：設計方針が定まっていない、下げる条件：方針が決まり、機械的な置換になった、確認方法：テスト全体と差分レビュー
記入の手順
- 最初は1週間ほど、既定モデルだけで作業します。 切り替えの基準は、既定でうまくいかなかった場面から見つかります。
- 外れた場面を1行ずつ記録します。 「何を頼んだか」「どう外れたか」「やり直しにかかった時間」の3点で十分です。
- 外れ方で分類します。 同じ指示を繰り返しても的外れなら難しさの問題、指示や情報が足りないなら入力の問題です。後者はモデルを上げても直らないことが多いので、まず依頼文とファイルの渡し方を直します。
- 上げる条件を「回数」か「範囲」で書きます。 「難しそうなとき」では判断できません。「2回外れた」「3ファイル以上」のように、数えられる形にします。
- 下げる条件も必ず書きます。 上げたまま戻さないと、費用と待ち時間だけが増えます。方針が決まった後の機械的な作業は、軽い段階に戻す候補です。
Claude Codeなら、重い段階で方針を作り、/model で標準に戻して実装する運び方ができます。opusplan のように計画と実行を分ける機能がある環境では、メモの「複数ファイルの変更」欄にそのまま使えます。Copilotでも、チャットのモデル選択から同じように段階を変えられます。
記入の下書きをAIに頼む依頼文
外れた場面の記録が数件たまったら、整理をAIに手伝わせられます。次の依頼文の 【】 内を置き換えて使ってください。機密のコードや社名は、説明用のダミーに置き換えてから貼ります。
以下は、私がAIコーディングで依頼して外れた場面の記録です。
切り替えメモの「上げる条件」「下げる条件」の案を作ってください。
【条件】
- 条件は「2回外れた」「3ファイル以上」のように数えて判断できる形にする
- 記録から読み取れないことは推測せず、「情報不足」と書く
- モデル名や性能の優劣には触れない
- 外れた原因が、モデルの能力ではなく指示や渡した情報の不足に見える場合は、その旨を分けて書く
【使える段階】軽:【モデル名】/ 標準:【モデル名】/ 重:【モデル名】
【記録】
1. 依頼:【例:関数名の一括変更】/ 結果:【例:2か所の呼び出しを見落とした】/ やり直し:【例:10分】
2. 依頼:【】/ 結果:【】/ やり直し:【】返ってきた案は、そのまま採用せず、自分の記録と照らして確認してください。AIは記録の傾向を整理するのは得意ですが、あなたのコードベースの事情や、チームの確認ルールまでは知りません。
見直しのタイミング
メモは一度作って終わりではありません。見直す目安は次の3つです。
- 使えるモデルの一覧や既定が変わったとき
- プランや契約が変わり、使える範囲や消費の考え方が変わったとき
- 同じ作業種別で、上げる条件に当てはまらないのに外れる場面が続いたとき
特に会社や組織のアカウントでは、使えるモデルが管理者のポリシーで決まることがあります。メモの「使うモデル名」の欄は、自分が実際に選べるものだけで埋めてください。
最後に、費用は「1回の消費×回数」で決まります。軽い段階を増やすより、外れてやり直す回数を減らすほうが、結果的に費用も時間も下がる場面は少なくありません。メモの「実際に使ったモデル・結果メモ」の列は、その判断のための記録です。月に一度でも眺めて、条件を1つか2つ書き換えれば、メモは自分の作業に合ったものになっていきます。
