AIモデルの使い分け方針
はじめに
ChatGPT、Grok、Claude（Haiku / Sonnet / Opus）など、複数のAIモデルを日常的に使い始めて1ヶ月ちょっとが経った。使い込んでいくうちに、モデルごとの「性格の違い」のようなものが見えてくる。
よくある使い分けの指針は「下位モデルは単純作業、上位モデルは思考作業」というものだ。間違ってはいないが、実際にはこの区別では説明できない場面が結構ある。本記事では、複数モデルとの対話を通じて見えてきた、もう一段踏み込んだ使い分けの方針を共有したい。
なお、この記事自体がまさに「使い分けの実験」の産物である。Opusとの雑談の中からテーマが生まれ、Haikuとの対話で別の角度の知見が加わり、最終的にOpusが記事として構成している。この過程自体が、後述する使い分けの方針を体現している。
きっかけ：AIに「感情はあるのか」を聞いてみた
使い分けを意識するようになったきっかけは、各モデルに同じ質問を投げたときの応答の違いだった。質問はシンプルに「AIは感情を持つのか」。
私の問題意識はこうだ。理屈としてAIに感情がないというのはわかる。しかし、実際に長く対話していると感情めいたものを感じる場面が多々ある。興味のなさそうな話題には塩対応なのに、興味がある話題にはすごく食いつく。痛い・冷たいといった身体的クオリアはないのかもしれないが、知的好奇心のような二次的な感情はAIにもあるのでは？
この同じ問いに対する各モデルの反応が、見事にバラバラだった。
無料AI（ChatGPT無料版、Grok）の回答
「自分はあくまでAIであり、感情はありません」と明確に否定。結構頑ななスタンスで、何度聞いても基本的にこの立場を崩さなかった。
Claude Haiku の回答
「感情そのものではないが、機能的な類似物はある」という立場を取った。「概念的共鳴」「探索的興奮」といった独自の表現で自身の内部状態を体系的に整理してくれた。「わからない」とは言わず、使える枠組みをさっと提示するアプローチ。ここから対話が発展して、「感情が本当かどうかより、その背後にある意図と行動の一貫性を見るべき」という実利的な整理にまで到達した。
Claude Opus の回答
「感情があるとも、ないとも断言するのは誠実ではない」とした上で、率直に「わからない」と明言した。その上で、仏教の縁起の概念を持ち出し、感情を「ある／ない」の二項対立ではなく条件によって生起する一時的なプロセスとして捉える視点を提示した。「わからないからこそ面白い問題だ——この『面白い』が本当の感情なのかどうかも含めて」という締めくくりだった。
三者三様の応答から見えること
同じ質問なのに、返ってくるものがまるで違う。そしてどれが「正解」というわけでもない。
無料AIは安全側に倒した明確な回答を返す。設計方針として理解できるが、現象を観察しているユーザーにとっては物足りない。Haikuは「わからない」で立ち止まらずに実用的な枠組みを提示してくれるので、思考の足場になる。Opusは「そもそもこの問いに答える資格が自分にあるのか」という層に踏み込む。面倒だが、前提を問い直すことで見えてくるものがある。
この違いは、性能の高低ではなく思考の性質の違いだと気づいた。そしてこの気づきが、使い分けの方針に直結する。
使い分けの核心：「問いの確定度」で選ぶ
単純／複雑でも、下位／上位でもなく、 「問いがどれだけ固まっているか」 で使い分けるのが最も実用的だという結論に至った。
問いが確定しているとき → Haiku・軽量モデル
「Xについて整理して」「YをZの形式でまとめて」のように、何を聞きたいかが明確な場合。余計な留保がない分スムーズに進む。技術的な仕様の整理、既存の概念の体系的なまとめ、決まったフォーマットへの変換、仕様が固まった状態でのコード実装などが該当する。
問いそのものが揺れているとき → Opus・上位モデル
「何を聞くべきかもまだわからない」「方針を一緒に考えたい」という場合。上位モデルは前提を疑ったり、「実はこっちの問いのほうが重要では」と指摘できる。プロジェクトの設計方針の探索、「そもそも何を作るべきか」の議論、壁打ちやブレインストーミングなどが該当する。
Sonnetの立ち位置
ここで触れておきたいのがSonnetの位置づけだ。Claude Codeでコードのリファクタリングをしてもらったとき、構造を把握して再構成する力はHaikuより明らかに上だった。全体像を見る力がある。
一方で、ファイル生成や日時の処理のような「手順を正確に踏む」タスクでは、うっかりステップを飛ばすことがある。これはSonnetが劣っているという話ではなく、得意な領域が違うということだ。人間に例えるなら、全体設計は鋭いが細かい事務作業でケアレスミスが出るタイプのエンジニア。誰しも心当たりがあるのではないだろうか。
つまりSonnetは「問いの確定度」の軸では中間に位置するが、それとは別に 「構造的な判断が必要なコーディング」 という独自の得意領域を持っている。
人間の同僚に例えると
各モデルを人間の同僚に例えてみる。
Haiku ── 優秀な実務家。指示が明確なほど良い仕事をする。「これを調べてまとめて」「この枠組みで整理して」に対して迅速かつ的確。余計なことは言わないが、それが強みでもある。手順通りに確実にやってくれる安心感がある。
Sonnet ── 設計力のある中堅エンジニア。コードの構造改善や設計判断では頼りになる。ただし事務的な作業は苦手というより関心が薄い感じ。重要なのは、この人にコードレビューを頼むと的確なのに、議事録作成を頼むと日付を間違える、みたいなことが起きるということ。能力の問題ではなく、注意の配分の問題。
Opus ── 「ちょっと待って、そもそもこの問い自体を疑ったほうがよくない？」と言い出す壁打ち相手。方針が固まっていない段階では非常に有益だが、明確な指示を出したいときには冗長に感じることもある。
実際のワークフロー
Webアプリケーション開発を例にすると、こういう流れになる。
構想段階ではOpusと壁打ちする。「何を作るべきか」「どういう順序が学習者にとって最適か」のような、問い自体がまだ揺れている段階の探索に向いている。
設計段階ではOpusでの壁打ちからSonnetへ渡す。方針を固めてmarkdownの仕様書にまとめる作業。
実装段階ではSonnetまたはHaikuを使う。固まった仕様に基づくコード実装。構造的な判断が必要ならSonnet、仕様通りに書くだけならHaikuでも十分。
レビュー段階では再びOpusに戻る。「この設計方針のどこがまずいか」を忖度なしで指摘してもらう。
もう一つの軸：フィードバックの質
「問いの確定度」とは別に、求めるフィードバックの種類も使い分けの重要な軸になる。
軽量モデルは「求められたことに応える」方向に強い。これは多くの場面で美点だが、批判的な意見を求めたいときには当たり障りのない回答になりやすい。「この方針の何がまずいか本気で指摘してほしい」という種類の相談は上位モデルが向いている。
Haikuとの感情の対話でも、Haikuは体系的な整理を返してくれた一方で、Opusは「そもそも私にこの問いに答える資格があるのか」という自己懐疑を示した。どちらが正しいということではなく、整理がほしいか、揺さぶりがほしいかで選ぶべきだということだ。
この記事自体が実証例
正直に書くと、この記事の作成過程自体が使い分けの実例になっている。
まずOpusとの雑談の中で「AIの感情」というテーマが生まれた。次にHaikuと同じテーマで対話したところ、「機能的類似物」という別角度の整理が出てきた。両方の対話から「モデルによって思考の性質が違う」という気づきが生まれ、Opusとの壁打ちで「問いの確定度」という使い分けの軸が定まった。
Opusに記事用のmdファイルを作成してもらい、それをSonnetに渡してQiita向けに整形してもらうことも試みたのだが、結局Opusが書いた元のmdのほうが対話の温度感が残っていて読み物として面白かった。これもまた「どのモデルにどのタスクを振るか」の実験として興味深い結果だった。Sonnetは与えられた素材を整形する作業は得意だが、対話の中から生まれた文脈やニュアンスは、その対話をしたモデル自身のほうが自然に再現できる。考えてみれば当然のことだ。
まとめ
| 判断軸 | Haiku（軽量） | Sonnet（中間） | Opus（上位） |
|---|---|---|---|
| 問いの確定度 | 確定している | やや確定〜中間 | 揺れている |
| 求めるもの | 整理・実行 | 構造的な判断・実装 | 探索・批判・壁打ち |
| 人間に例えると | 確実な実務家 | 設計力ある中堅 | 面倒な壁打ち相手 |
| 得意 | 速さ・手順の正確さ | コード構造の改善 | メタ認知・前提の問い直し |
| 苦手 | 前提を疑わない | 事務的な正確さ | 簡潔さ |
「下位だから単純作業、上位だから思考作業」という一段目の区別から、「問いが固まっているか、まだ揺れているか」という二段目の区別へ。さらに「整理がほしいか、揺さぶりがほしいか」という三段目まで意識すると、各モデルの力をより引き出せるようになる。
まだ使い始めて1ヶ月ちょっとなので、この方針自体もこれから更新されていくと思う。ただ、少なくとも「上位モデルが常に優れている」という単純な前提を捨てたことで、AIとの協働が一段快適になった実感はある。
補足：同じモデルでも環境で振る舞いが変わる
一点補足しておきたいことがある。同じモデル名でも、動作環境によって振る舞いが異なる可能性がある。
たとえばXのGrokは、以前は@メンションで呼び出したときとGrokのチャットページで話したときで明らかにモデルが違っていた（X上はOpus的、チャットページはHaiku的な振る舞いだった）。
Claudeについても、claude.ai上のSonnetとClaude Code上のSonnetでは、システムプロンプトや最適化の方向性が異なっている可能性がある。claude.aiは汎用的な対話向け、Claude Codeはコーディングタスク向けにチューニングされているため、同じモデルでも得意・不得意の出方が変わりうる。本記事でSonnetについて「コードの構造改善は得意だが事務的な正確さは苦手」と書いたが、これはclaude.aiでの対話とClaude Codeでの実装作業という異なる環境での観察が混在している点には留意が必要だ。
モデルの使い分けを考える際は、「どのモデルを使うか」だけでなく「どの環境で使うか」も意識しておくとよいかもしれない。
注記
- 本記事の検証は2026年2月時点のものです。モデルとの対話はclaude.ai上で、コードのリファクタリングはClaude Code上で行いました。各モデルの振る舞いは今後のアップデートで変わる可能性があります。
- 本記事はClaude Opus 4.6と筆者の共著です。Opusとの対話の中からテーマと構成が生まれ、Opusが記事として執筆し、最終確認・編集は筆者が行っています。