高性能AIを毎回使わなくていい。モデル選びは設計と作業で分ける

AIを使っていると、「ClaudeならOpusとSonnetのどちらがいいのか」「Codexなら上位モデルを使うべきなのか、軽いモデルでもいいのか」という相談が出てきます。
結論から言うと、毎回いちばん賢いモデルを使う必要はありません。
ただし、毎回いちばん軽いモデルで済ませるのも危ないです。

大事なのは、

• 考える仕事は高性能モデルに任せる。
• 決まった作業は軽いモデルに任せる。

この使い分けです。

高性能モデルは強い。でも、全部に使うとすぐ上限に近づく

モデルは、基本的には性能が高いほど複雑な判断に強くなります。
文章の一貫性。
長い文脈の理解。

戦略の組み立て。
矛盾の発見。
コードや業務フローの全体把握。

こういう場面では、上位モデルを使う意味があります。
ただし、その分だけ消費も大きくなりやすいです。
月3,000円前後の安価なプランで使っている場合、毎回上位モデルに長文を投げていると、思ったより早く上限に近づきます。

特に、

• 長い文字起こしを何本も読ませる
• 毎回大量の資料を貼る
• 何度も同じ修正を往復する
• 単純な整形まで上位モデルに頼む

こういう使い方をすると、肝心な相談や設計をしたい時に、使いたいモデルが使いにくくなることがあります。
高性能モデルは、切り札に近いです。
毎回使えば安心ではあります。

でも、全部の仕事に切り札を出していると、コストも上限も重くなります。

軽いモデルだけにすると、判断の質が落ちることがある

では、軽いモデルだけでいいのか。
ここも注意が必要です。
軽いモデルでも、指示が具体的で、作業範囲がはっきりしていれば十分に動きます。

たとえば、

• この文章を読みやすく整える
• 文字起こしを見出しごとに整理する
• 決まったテンプレートに沿って記事下書きを作る
• 表記ゆれを直す
• 既存の構成に沿ってメルマガ化する
• タグをつける
• 要点を3つにまとめる

こういう作業は、軽いモデルでもかなり対応できます。
一方で、

• そもそも何を作るべきか
• 誰に向けて出すべきか
• どの導線が売上に近いか
• この商品設計はズレていないか
• 本番反映して大丈夫か
• 読者の悩みの本当の原因は何か

ここまで軽いモデルだけに任せると、浅くなることがあります。
一見きれいな答えは返ってきます。
でも、論点がずれていたり、一般論に寄っていたり、売上につながる判断が弱くなったりする。

AIの質が悪いというより、任せる仕事が重すぎるのです。

モデル選びで見るべきなのは、名前ではなく仕事の重さ

モデル名で迷う時ほど、まず仕事を分けた方がいいです。
僕なら、ざっくり次のように分けます。

高性能モデルに任せたい仕事

• 商品設計、コンセプト設計、ポジショニング
• セミナーや講座全体の構成
• 発信戦略、導線設計、売上につながる全体設計
• 長文コンテンツの骨子づくり
• 複数資料を読んだ上での判断
• コードやサイト改修の方針決定
• 本番反映前のリスク確認
• 重要な文章の最終レビュー

ここは、頭のいいモデルを使った方がいいです。
理由は、失敗した時の影響が大きいからです。
記事1本の整文なら直せます。

でも、商品コンセプトや導線設計を間違えると、その後の発信、セミナー、相談、売上まで全部ズレます。
だから、設計や判断には上位モデルを使います。

軽いモデルに任せたい仕事

• 要約
• 整文
• 誤字脱字修正
• 見出し案の量産
• 表作成
• カテゴリ分け
• ファイル名案
• 既に決まった構成への流し込み
• SNS用の短文化
• 文字起こしの整理

ここは、軽いモデルで十分なことが多いです。
なぜなら、正解の型があるからです。
「この構成に沿って整えて」

「このテンプレに入れて」
「このルールで分類して」
ここまで決まっていれば、軽いモデルでも仕事になります。

いちばんコスパがいいのは、設計だけ上位モデルを使うこと

おすすめは、最初に高性能モデルで設計を作り、その後の作業を軽いモデルに渡す使い方です。
たとえば、記事作成ならこうです。

1. 高性能モデルで、テーマ、読者、結論、構成、導線を決める
2. その設計を保存する
3. 軽いモデルで本文下書き、整文、見出し調整を行う
4. 最後に必要なら、高性能モデルで全体レビューする

この流れにすると、上位モデルを使う回数は少なくて済みます。
でも、最初の判断は賢いモデルで作っているので、軽いモデルに任せても大きくズレにくい。
つまり、

• 高性能モデルを作業員にしない。
• 監督役として使う。

これがかなり大事です。
Claudeなら、Opusを戦略や設計に使い、Sonnetを日常作業に使う。
Codexなら、5.5のような上位モデルを複雑な設計やレビューに使い、5.4系のモデルを実装や整形に使う。

細かいモデル名は変わります。
でも、この考え方は変わりません。

指示が具体的なら、軽いモデルでも十分に使える

軽いモデルを使う時に大事なのは、指示の具体性です。
「いい感じにして」
だと、軽いモデルは一般論に寄りやすくなります。

でも、

目的:
Noah無料ライブラリのAI活用カテゴリに置く記事下書きを作る。
読者:
AIは触っているが、モデル選びで迷っていて、安いプランの上限も気にしている個人起業家。
素材:
高性能モデルは戦略や設計に使い、軽いモデルは作業に使うという考え方。
制約:
ツール比較だけで終わらせない。
モデル名は変わるため、特定バージョンの優劣を断定しすぎない。
最後に自分の仕事を分類するワークを入れる。
完了条件:
読者が「毎回上位モデルに頼るのではなく、設計と作業を分けよう」と思える状態。

ここまで渡すと、軽いモデルでもかなり使いやすくなります。
モデルの性能だけでなく、仕事の渡し方で出力は変わります。
高性能モデルに雑に頼むより、軽いモデルに具体的に頼む方が良い結果になることもあります。

毎回指示しないために、使い分けルールを保存しておく

この使い分けは、毎回口で説明する必要はありません。
よく使う人ほど、設定やメモとして保存しておいた方がいいです。
使っているツールによって名前は違いますが、考え方は同じです。

• ChatGPTやClaudeなら、プロジェクト指示やカスタム指示に保存する
• Codexなら AGENTS.md、Claude Codeなら CLAUDE.md に運用ルールを書く
• Obsidianを使っているなら、AI活用ルールとして1ファイルにまとめておく
• 開発や発信の作業手順があるなら、スキルファイルやテンプレートに分ける

保存しておきたいのは、長い理論ではありません。
次のような短いルールで十分です。

このプロジェクトでは、AIモデルを次の方針で使い分ける。

1. 戦略、設計、商品コンセプト、導線設計、重要判断、最終レビューは高性能モデルを使う。
2. 要約、整文、分類、表作成、テンプレ流し込み、誤字修正、既に決まった構成の下書きは軽いモデルを使う。
3. 軽いモデルで進める場合も、判断に迷う点があれば「高性能モデルで確認すべき論点」として止める。
4. 毎回、目的、素材、制約、完了条件を確認してから作業する。
5. モデル名や上限は変わるため、最新の表示を確認し、特定モデルの名前だけに依存しない。

これを入れておくと、AIに毎回同じ説明をしなくて済みます。
「このルールに沿って進めて」
と言えば、モデル選びの考え方ごと呼び出せます。

環境によっては、AIが自動でモデルを切り替えられないこともあります。
その場合でも大丈夫です。
高性能モデル用のチャットを「設計室」、軽いモデル用のチャットを「作業室」として分けるだけでも、かなり使いやすくなります。

小さな確認ワーク

今週AIに頼んだ作業を、次の3つに分けてみてください。

この表を作ると、モデル選びはかなり楽になります。
「どのAIが最強か」ではなく、
「この仕事は、考える仕事なのか。作業なのか」

で判断できるからです。

個別相談で見るべき論点

モデル選びで迷っている時、本当はモデル名だけの問題ではないことが多いです。

• 安いプランの中で、どの作業に上位モデルを使うべきか
• 毎回の指示をどうテンプレート化するか
• 自分の発信や商品設計のどこまでAIに任せていいか
• Obsidianやプロジェクト指示に何を保存すべきか
• AIで浮いた時間を、売上に近い仕事へどう戻すか

このあたりを整理しないと、ツールを変えてもまた迷います。
AI活用は、モデル名の暗記ではありません。
自分の仕事を分解して、どこに賢いモデルを使い、どこを軽く回すかを決めることです。

ここまで読んで「自分は全部を上位モデルに投げていたかも」と感じた方は、一度仕事の流れを見直した方が早いです。
設計、作業、レビューのどこでAIを使うかが決まると、同じプランでも消費を抑えながら、出力の質を上げやすくなります。
関連記事: ChatGPT、Claude、Gemini｜どれを使えばいいかわからない人へ

関連記事: AIに仕事を任せる時は、プロンプトより完了条件を渡す
関連記事: CodexとObsidianでAIを「育てて使う」実務システム
関連記事: ChatGPT 5.6はSolだけ使えばいいのか｜考える・作る・捌くを分けるプロンプト