AIを使っていると、こういう相談が出てきます。
Claudeなら、Opusがいいのか。
Sonnetで十分なのか。
Codexなら、5.5のような上位モデルを使うべきなのか。
5.4のような軽いモデルでもいいのか。
結論から言うと、毎回いちばん賢いモデルを使う必要はありません。
ただし、毎回いちばん軽いモデルで済ませるのも危ないです。
大事なのは、
- 考える仕事は高性能モデルに任せる。
- 決まった作業は軽いモデルに任せる。
この使い分けです。
高性能モデルは強い。でも、全部に使うとすぐ上限に近づく
モデルは、基本的には性能が高いほど複雑な判断に強くなります。
文章の一貫性。
長い文脈の理解。
戦略の組み立て。
矛盾の発見。
コードや業務フローの全体把握。
こういう場面では、上位モデルを使う意味があります。
ただし、その分だけ消費も大きくなりやすいです。
月3,000円前後の安価なプランで使っている場合、毎回上位モデルに長文を投げていると、思ったより早く上限に近づきます。
特に、
- 長い文字起こしを何本も読ませる
- 毎回大量の資料を貼る
- 何度も同じ修正を往復する
- 単純な整形まで上位モデルに頼む
こういう使い方をすると、肝心な相談や設計をしたい時に、使いたいモデルが使いにくくなることがあります。
高性能モデルは、切り札に近いです。
毎回使えば安心ではあります。
でも、全部の仕事に切り札を出していると、コストも上限も重くなります。
軽いモデルだけにすると、判断の質が落ちることがある
では、軽いモデルだけでいいのか。
ここも注意が必要です。
軽いモデルでも、指示が具体的で、作業範囲がはっきりしていれば十分に動きます。
たとえば、
- この文章を読みやすく整える
- 文字起こしを見出しごとに整理する
- 決まったテンプレートに沿って記事下書きを作る
- 表記ゆれを直す
- 既存の構成に沿ってメルマガ化する
- タグをつける
- 要点を3つにまとめる
こういう作業は、軽いモデルでもかなり対応できます。
一方で、
- そもそも何を作るべきか
- 誰に向けて出すべきか
- どの導線が売上に近いか
- この商品設計はズレていないか
- 本番反映して大丈夫か
- 読者の悩みの本当の原因は何か
ここまで軽いモデルだけに任せると、浅くなることがあります。
一見きれいな答えは返ってきます。
でも、論点がずれていたり、一般論に寄っていたり、売上につながる判断が弱くなったりする。
AIの質が悪いというより、任せる仕事が重すぎるのです。
モデル選びで見るべきなのは、名前ではなく仕事の重さ
モデル名で迷う時ほど、まず仕事を分けた方がいいです。
僕なら、ざっくり次のように分けます。
高性能モデルに任せたい仕事
- 商品設計、コンセプト設計、ポジショニング
- セミナーや講座全体の構成
- 発信戦略、導線設計、売上につながる全体設計
- 長文コンテンツの骨子づくり
- 複数資料を読んだ上での判断
- コードやサイト改修の方針決定
- 本番反映前のリスク確認
- 重要な文章の最終レビュー
ここは、頭のいいモデルを使った方がいいです。
理由は、失敗した時の影響が大きいからです。
記事1本の整文なら直せます。
でも、商品コンセプトや導線設計を間違えると、その後の発信、セミナー、相談、売上まで全部ズレます。
だから、設計や判断には上位モデルを使います。
軽いモデルに任せたい仕事
- 要約
- 整文
- 誤字脱字修正
- 見出し案の量産
- 表作成
- カテゴリ分け
- ファイル名案
- 既に決まった構成への流し込み
- SNS用の短文化
- 文字起こしの整理
ここは、軽いモデルで十分なことが多いです。
なぜなら、正解の型があるからです。
「この構成に沿って整えて」 「このテンプレに入れて」 「このルールで分類して」
ここまで決まっていれば、軽いモデルでも仕事になります。
いちばんコスパがいいのは、設計だけ上位モデルを使うこと
おすすめは、最初に高性能モデルで設計を作り、その後の作業を軽いモデルに渡す使い方です。
たとえば、記事作成ならこうです。
- 高性能モデルで、テーマ、読者、結論、構成、導線を決める
- その設計を保存する
- 軽いモデルで本文下書き、整文、見出し調整を行う
- 最後に必要なら、高性能モデルで全体レビューする
この流れにすると、上位モデルを使う回数は少なくて済みます。
でも、最初の判断は賢いモデルで作っているので、軽いモデルに任せても大きくズレにくい。
つまり、
- 高性能モデルを作業員にしない。
- 監督役として使う。
これがかなり大事です。
Claudeなら、Opusを戦略や設計に使い、Sonnetを日常作業に使う。
Codexなら、5.5のような上位モデルを複雑な設計やレビューに使い、5.4系のモデルを実装や整形に使う。
細かいモデル名は変わります。
でも、この考え方は変わりません。
指示が具体的なら、軽いモデルでも十分に使える
軽いモデルを使う時に大事なのは、指示の具体性です。
「いい感じにして」
だと、軽いモデルは一般論に寄りやすくなります。
でも、
目的:
Noah無料ライブラリのAI活用カテゴリに置く記事下書きを作る。
読者:
AIは触っているが、モデル選びで迷っていて、安いプランの上限も気にしている個人起業家。
素材:
高性能モデルは戦略や設計に使い、軽いモデルは作業に使うという考え方。
制約:
ツール比較だけで終わらせない。
モデル名は変わるため、特定バージョンの優劣を断定しすぎない。
最後に自分の仕事を分類するワークを入れる。
完了条件:
読者が「毎回上位モデルに頼るのではなく、設計と作業を分けよう」と思える状態。
ここまで渡すと、軽いモデルでもかなり使いやすくなります。
モデルの性能だけでなく、仕事の渡し方で出力は変わります。
高性能モデルに雑に頼むより、軽いモデルに具体的に頼む方が良い結果になることもあります。
毎回指示しないために、使い分けルールを保存しておく
この使い分けは、毎回口で説明する必要はありません。
よく使う人ほど、設定やメモとして保存しておいた方がいいです。
使っているツールによって名前は違いますが、考え方は同じです。
- ChatGPTやClaudeなら、プロジェクト指示やカスタム指示に保存する
- Claude CodeやCodexなら、
CLAUDE.mdやAGENTS.mdに運用ルールを書く - Obsidianを使っているなら、AI活用ルールとして1ファイルにまとめておく
- 開発や発信の作業手順があるなら、スキルファイルやテンプレートに分ける
保存しておきたいのは、長い理論ではありません。
次のような短いルールで十分です。
このプロジェクトでは、AIモデルを次の方針で使い分ける。
1. 戦略、設計、商品コンセプト、導線設計、重要判断、最終レビューは高性能モデルを使う。
2. 要約、整文、分類、表作成、テンプレ流し込み、誤字修正、既に決まった構成の下書きは軽いモデルを使う。
3. 軽いモデルで進める場合も、判断に迷う点があれば「高性能モデルで確認すべき論点」として止める。
4. 毎回、目的、素材、制約、完了条件を確認してから作業する。
5. モデル名や上限は変わるため、最新の表示を確認し、特定モデルの名前だけに依存しない。
これを入れておくと、AIに毎回同じ説明をしなくて済みます。
「このルールに沿って進めて」
と言えば、モデル選びの考え方ごと呼び出せます。
環境によっては、AIが自動でモデルを切り替えられないこともあります。
その場合でも大丈夫です。
高性能モデル用のチャットを「設計室」、軽いモデル用のチャットを「作業室」として分けるだけでも、かなり使いやすくなります。
小さな確認ワーク
今週AIに頼んだ作業を、次の3つに分けてみてください。
| 作業 | 高性能モデル向き | 軽いモデル向き | 人間が判断すべきこと |
|---|---|---|---|
| 記事テーマを決める | ○ | 最終的に何を出すか | |
| 文字起こしを整える | ○ | 固有名詞の確認 | |
| 商品コンセプトを見直す | ○ | 事業として採用するか | |
| 投稿を10本に切り出す | ○ | どれを出すか | |
| 本番反映前の確認 | ○ | 公開するか |
この表を作ると、モデル選びはかなり楽になります。
「どのAIが最強か」ではなく、
「この仕事は、考える仕事なのか。作業なのか」
で判断できるからです。
個別相談で見るべき論点
モデル選びで迷っている時、本当はモデル名だけの問題ではないことが多いです。
- 安いプランの中で、どの作業に上位モデルを使うべきか
- 毎回の指示をどうテンプレート化するか
- 自分の発信や商品設計のどこまでAIに任せていいか
- Obsidianやプロジェクト指示に何を保存すべきか
- AIで浮いた時間を、売上に近い仕事へどう戻すか
このあたりを整理しないと、ツールを変えてもまた迷います。
AI活用は、モデル名の暗記ではありません。
自分の仕事を分解して、どこに賢いモデルを使い、どこを軽く回すかを決めることです。
ここまで読んで「自分は全部を上位モデルに投げていたかも」と感じた方は、一度仕事の流れを見直した方が早いです。
設計、作業、レビューのどこでAIを使うかが決まると、同じプランでも消費を抑えながら、出力の質を上げやすくなります。
関連記事: ChatGPT、Claude、Gemini。どれを使えばいいかわからない人へ