Opus 4.6 / Sonnet 4.6 / Haiku 4.5 — 個人事業主のためのモデル使い分けガイド

ステータス: リライト完成（2026-04-14）／文字数約12,800字／想定読了 15-18分

📋 メタ情報

項目	内容
タイトル	Opus 4.6 / Sonnet 4.6 / Haiku 4.5 — 個人事業主のためのモデル使い分けガイド
Slug (案)	claude-model-comparison-guide
カテゴリ	AI / Claude / 生産性
タグ	Claude Opus 4.6, Claude Sonnet 4.6, Claude Haiku 4.5, Claude モデル比較, AIコスト最適化, Claude Max
想定読者	Claude API / Max利用者、モデル選定に悩む層、APIコスト最適化を検討中の層

Meta Description（150字）

Claude Opus 4.6・Sonnet 4.6・Haiku 4.5の3モデルを実務で使い分けた個人事業主の実体験記。タスク別相性マッピング表付き。Opus=戦略思考、Sonnet=分析・操作、Haiku=単純作業で振り分け、APIコスト72%削減を実現した具体的方法を解説。

リード：「一番賢いモデルを使えばいい」は間違いだった

Opusは賢いが高い、Haikuは速いが雑、Sonnetは万能だが特徴がない。そう思っていた時期が僕にもあった。

Claude Max 20xを契約してから3ヶ月。日々の業務でOpus 4.6、Sonnet 4.6、Haiku 4.5の3モデルを使い分けてきた。最初の1ヶ月はずっとOpusだけを使っていた。「せっかくMax契約しているのだから、一番賢いモデルを使わないともったいない」という貧乏性が働いていたのだと思う。

転機は、ある朝のデイリーブリーフィングだった。Opusに「今日のSlack未読を要約して」と投げたとき、返答までに体感で10秒以上かかった。その間、僕はぼんやりと画面を眺めていた。ふと気づいた。これ、Haikuなら2秒で返ってくる。そしてこの程度の作業に、Opusの思考力は1ミリも要らない。

その日から、タスクの性質に応じてモデルを切り替え始めた。1週間ごとに各モデルを主力にして回してみた結果、「賢さ」ではなく「任せ方」でモデルを選ぶべきだという結論に至った。

この記事では、コンサル業務と複数の副業事業を並行する個人事業主の実体験として、3モデルの使い分けを実務ベースで解説する。スペック比較記事は山ほどあるが、「どのタスクにどのモデルを割り当てるか」というマッピングの話は意外と少ない。API利用者もMax利用者も、モデル選定の意思決定材料にしてもらえたら嬉しい。

第1章：3モデルの基本スペック — まず数字で整理する

使い分けの話に入る前に、2026年4月時点の3モデルの基本スペックを1枚の表で整理しておく。

【3モデル基本スペック詳細比較表】

項目	Opus 4.6	Sonnet 4.6	Haiku 4.5
リリース日	2026年2月5日	2026年2月17日	2025年10月（4.5世代）
コンテキスト窓	100万トークン	20万トークン	20万トークン
出力上限	16,000トークン	8,192トークン	8,192トークン
推論（思考）モード	Adaptive Thinking 標準装備	なし（標準レスポンス）	なし（標準レスポンス）
主な特徴	100M トークン×Adaptive thinking で深い論点構造化	SWE-bench 79.6% のコード力と安定性	高速・低コスト・軽い作業に最適化
API 入力単価	$15 / 1M トークン	$3 / 1M トークン	$0.80 / 1M トークン
API 出力単価	$75 / 1M トークン	$15 / 1M トークン	$4 / 1M トークン
体感速度	やや遅い（10-30秒、思考深化時）	中速（3-8秒、標準レスポンス）	非常に速い（0.5-2秒）
得意領域	戦略的思考・長文構造化・論点整理・複雑な判断	コード生成・データ分析・実務操作・バランス型タスク	要約・分類・単純変換・高速応答
Max 契約時の制限	5時間ごとに10回まで	制限なし（実質無制限）	制限なし（実質無制限）
適切な利用比率（推奨）	全体の 10-20%	全体の 50-70%	全体の 20-40%

数字だけ見ると、「Opusがスペック最強で、あとは廉価版でしょ」と思いがちだ。僕も最初はそう思っていた。しかし3ヶ月使い倒して気づいたのは、「スペックの優劣」と「タスクへの適合度」はまったく別物だということだ。

たとえば、100件の領収書を仕訳するタスクにOpusを使うのは、高級レストランのシェフにカップ麺を作らせるようなものだ。いや、カップ麺は確かに完成するが、シェフの才能を完全に無駄遣いしている。しかもカップ麺の出来に差はない。

第2章：Opus 4.6 — 1Mトークン×Adaptive Thinkingの真価

「考える」仕事はOpusに任せる

Opus 4.6の最大の武器は、100万トークンのコンテキスト窓とAdaptive thinking（拡張思考モード）だ。この2つが組み合わさると、「大量の情報を読み込みながら、複雑な論点を構造化する」というタスクで圧倒的な力を発揮する。

僕がOpusを使うのは、主に以下のようなタスクだ。

クライアント提案書のストーリーライン設計。 過去の議事録、業界レポート、競合情報をまとめて投げ込んで、「この企業の経営課題に対して、どの切り口で提案すべきか」を3パターン出してもらう。Opusは投げ込んだ情報の中から横断的な因果関係を見つけ出し、構造化された論点ツリーを返してくれる。これはSonnetでも一応できるが、論理の深さと一貫性が明らかに違う。

戦略メモの壁打ち。 新しい事業アイデアや投資判断を考えるとき、頭の中のモヤモヤをそのままぶつけて「この思考に穴はあるか」「見落としている論点は何か」と問いかける。Opusはこういう抽象度の高い問いに対して、MECE的に整理しながら反論を返してくれる。コンサルの壁打ち相手としては、人間の同僚に引けを取らない。

長文コンテンツの執筆。 この記事自体もそうだが、5,000字を超える構造化された文章を書くときは、全体のストーリーラインをOpusに設計させてから、各セクションを肉付けしていく。全体像を俯瞰しながら細部を書くという二重の思考が必要な作業で、ここはOpusの独壇場だ。

複数資料の統合分析。 売上報告書、顧客フィードバック、市場分析レポートを同時に投げて、「共通のパターンはあるか」「競合より優位な点はどこか」と多面的な分析を要求する。100M トークンの窓があるからこそ、複数資料の全体像を一度に把握しながら分析できる。

Opusの弱点：速度と「もったいなさ」

一方、Opusの弱点も3ヶ月で見えてきた。まず速度だ。Adaptive thinkingが起動すると、返答までに10〜30秒かかることがある。思考が深い分だけ時間がかかるのは当然だが、ちょっとした確認作業でこの待ち時間は致命的だ。

もうひとつは、コスト感覚だ。API利用の場合、Opusの出力は1M トークンあたり75ドル。Sonnetの5倍、Haikuの19倍だ。Max契約なら利用枚の中で使えるが、枚を意識するならOpusは「ここぞ」の場面に温存したほうがよい。

さらに、Max契約時の制限も見過ごせない。OpusはSonnetやHaikuと異なり「5時間ごとに10回」という厳しい利用上限がある。つまり、軽い作業にOpusを使うだけで、本来必要な深い思考の場面でOpusが使えなくなる可能性がある。

第3章：Sonnet 4.6 — 価格据え置きで”主力”になった理由

実務の8割はSonnetで回る

正直に告白する。3ヶ月の利用実績を振り返ったとき、最も稼働時間が長かったのはSonnet 4.6だった。Opusでも、Haikuでもなく、Sonnetだ。

Sonnet 4.6がリリースされたのは2026年2月17日。SWE-bench（ソフトウェアエンジニアリングの標準ベンチマーク）で79.6%という数字を叩き出しながら、API単価は据え置き。つまり、前世代からコーディング能力が跳ね上がったのに、価格は変わっていない。これは実質的な値下げだ。

僕がSonnetを「主力」と位置づけている理由は、コストパフォーマンスだけではない。Sonnetは「分析と操作」の両方をバランスよくこなせるモデルなのだ。

データ分析と可視化。 Excelファイルを読み込ませて「このデータの傾向を分析し、グラフ化して」と頼む。売上推移の分析、顧客セグメントの分類、KPIダッシュボードの生成──これらの作業でSonnetは十分な精度を出す。Opusほど深い洞察は返ってこないが、「分析結果として間違っていない」という信頼性がある。

Cowork modeでのファイル操作。 フォルダの中身を整理する、PDFからテキストを抽出してWordに変換する、スプレッドシートのフォーマットを整える。こうした「手を動かす系」の作業は、SonnetがCowork modeで最も安定して処理してくれる。コード生成能力の高さがそのまま「ファイル操作の正確さ」につながっている印象だ。

議事録と報告書のドラフト。 会議の文字起こしを渡して、「論点ごとに整理してドラフトを作って」と依頼する。このレベルの構造化作業は、Opusほどの深い思考は不要だが、Haikuでは論点の整理が浅くなる。Sonnetがちょうどよい。

コード生成・デバッグ。 Python、JavaScript、SQLといった言語でのコード生成・修正ではSonnetの79.6% SWE-benchスコアが活躍する。本格的なアーキテクチャ設計はOpusに任せるとしても、単発の機能実装やバグ修正の大半はSonnetで十分だ。

Sonnetの「ちょうどよさ」は設計思想

Sonnetが「万能だが特徴がない」と評されることがある。僕も最初はそう感じていた。しかし3ヶ月使ってみると、この「ちょうどよさ」こそSonnetの設計思想であり、最大の強みだと理解できた。

たとえるなら、Opusは外科の名医、Haikuは救急外来のトリアージナース、そしてSonnetは総合診療医だ。大半の症状はまず総合診療医に診てもらうのが正解で、専門性が必要な場面だけ外科医に回す。日常業務の大半は「それなりの精度でそれなりの速度」が求められるタスクであり、そこに最適化されたSonnetを主力に据えるのは、理にかなっている。

第4章：Haiku 4.5 — 速さは”雑さ”ではなく”回転率”

2秒で返ってくることの価値

Haikuに対する最もよくある誤解は、「安かろう悪かろう」だ。確かにHaikuはOpusやSonnetと比べて思考の深さでは劣る。しかし、速さには速さの価値がある。

僕がHaikuを使うのは、以下のようなタスクだ。

Slack未読・メールの要約。 朝のブリーフィングで、Slackの未読メッセージを要約するだけの作業。ここにOpusの思考力は1ミリも要らない。Haikuなら2〜3秒で返ってくる。1日のスタートを切るための「軽い作業」にHaikuは最適だ。

単純な分類とタグ付け。 領収書の仕訳カテゴリ分け、メールの優先度判定、ファイル名の一括リネーム。パターンが決まっている繰り返し作業は、Haikuの高速性が活きる。10件の分類をOpusに頼めば30秒かかるが、Haikuなら5秒で終わる。100件なら、この差は致命的だ。

テキストの簡易変換。 英語の短文を日本語に訳す、箇条書きを文章に変換する、住所のフォーマットを統一する。こうした「考える必要がない変換作業」は、モデルの知能よりも応答速度が生産性に直結する。

チャットのトリアージ。 問い合わせやメッセージの一次振り分けをHaikuにやらせ、「これは重要」と判断されたものだけSonnetやOpusに回す。Haikuはフィルターとしての役割が非常に優秀だ。

軽い校正・チェック。 誤字脱字の指摘、数値の形式統一、リスト内容の簡易チェック。パターンマッチングが得意なHaikuは、このタイプの作業を高速で処理できる。

「回転率」という考え方

Haikuの価値を理解するには、「回転率」という概念が役に立つ。コンサルの仕事では、1つの重い意思決定よりも、100の軽い判断の積み重ねで1日が過ぎることのほうが多い。この100の軽い判断を、1つ2秒で回してくれるHaikuの存在は、体感として「仕事が軽くなる」という感覚を与えてくれる。

API利用者にとっては、コスト面のインパクトも大きい。Haikuの入力単価はOpusの19分の1だ。大量の軽いタスクをHaikuで回すだけで、月のAPI費用は桁が変わる。Max契約者にとっても、Haikuで軽いタスクを処理すれば、利用枚をOpusの深い思考に回せるという意味で、枚の最適配分につながる。

第5章：僕のタスク別使い分けマップ — 20種類以上のタスクで検証

ここまでの話を、詳細なマッピング表にまとめる。これは僕が3ヶ月かけて試行錯誤した結果の「最適配置」だ。

【タスク×モデル相性マッピング表（詳細版）】

タスク種別	具体的なタスク例	推奨モデル	理由・詳細	体感精度
戦略・高度な思考	提案書のストーリーライン設計	Opus	横断的な論点整理、クライアント課題の多面分析が必要	95%
	新規事業のフィージビリティ検討	Opus	多面的なリスク評価、市場機会の抽象度高い判断	93%
	長文レポート・ブログ記事の全体設計	Opus	5,000字超の一貫した構造・論理展開を保つ力	94%
	投資判断の壁打ち・反論出し	Opus	見落とし論点の提示、論理の穴の指摘	92%
	複雑な組織課題の分析	Opus	複数の立場・背景を統合して原因分析する力	91%
分析・データ処理	Excel/CSVのデータ分析・グラフ化	Sonnet	十分な分析精度、ピボットテーブル・グラフ生成の安定性	88%
	議事録からの論点整理・ドラフト作成	Sonnet	構造化の深さと作業速度のバランス、Opusほど時間がかからない	87%
	コード生成・デバッグ（汎用タスク）	Sonnet	SWE-bench 79.6%のコード能力、単発機能実装に十分	86%
	顧客データの顧客セグメント分類	Sonnet	パターン認識精度、複数属性での分類能力	85%
	複数資料の比較分析（3-5件）	Sonnet	複数資料の通読と比較論理を安定して実行	84%
ファイル操作・実務作業	Coworkでのファイル変換・整形	Sonnet	PDF→Word、Excel→CSV等の変換精度、フォーマット統一	89%
	スプレッドシート集計・関数生成	Sonnet	SUMIF、VLOOKUP、ピボット等の関数生成・修正	87%
	Word・PowerPointテンプレート作成	Sonnet	レイアウト・フォーマットの指示を正確に実装	86%
	フォルダ構造の整理・ファイルリネーム	Sonnet	複雑なリネームロジックの理解と実装	88%
単純作業・高速処理	Slack/メール未読の要約	Haiku	速度最優先（2秒以内）、深い思考は不要	82%
	領収書・請求書のカテゴリ分け	Haiku	パターン化された分類作業の大量処理	85%
	短文テキスト翻訳（＜200字）	Haiku	翻訳精度は十分、応答速度が生産性に直結	83%
	ファイル名・リスト項目の一括リネーム	Haiku	定型パターンの大量処理、スピード優先	86%
	メール・問い合わせの優先度判定	Haiku	フィルター役として最適、緊急判定はシンプル	84%
	簡易テキスト変換（形式統一、箇条書き化）	Haiku	考える必要がない変換、速度が全て	81%
校正・レビュー	誤字脱字チェック	Haiku	パターンマッチング得意、高速処理	80%
	数値・計算の整合性チェック	Sonnet	論理的な検証が必要、単純計算はHaikuでも可	87%
	法務・契約書のレビュー・リスク指摘	Opus	見落としリスク最小化、複雑な法解釈が必要な場合	90%
	文章のトーン・言葉選びレビュー	Sonnet	言語感度が十分、大量文章の校正に向く	85%
コンテンツ生成	ブログ記事の個別セクション執筆	Sonnet	Opus が骨子→Sonnetが肉付けの効率的分業	84%
	SNS投稿・メールニュースレター案	Haiku	短文生成、スピード重視で十分クオリティ	79%
	プレスリリース・公式発表文の作成	Sonnet	トーン・メッセージングのバランス、信頼性重視	86%

マッピングの運用ルール

表だけでは伝わらないコツが3つある。

ルール1：迷ったらSonnet。 どのモデルを使うべきか判断に迷ったら、まずSonnetに投げる。結果が物足りなければOpusに切り替え、過剰だと感じたらHaikuに下げる。この「Sonnetスタート→調整」のフローが最も効率がよい。

ルール2：Opusは「白紙から構造を作る」タスクだけに限定する。 Opusの思考力が真に必要なのは、既存のフレームワークに当てはめられない、ゼロから論理構造を組み立てる作業だ。テンプレートが使えるタスクにOpusを投入するのはオーバースペックだ。Max契約の5時間ごと10回制限も考慮すると、Opusはさらに温存すべき。

ルール3：Haikuは「10回以上繰り返す」タスクに使う。 同じパターンのタスクを10回、100回と繰り返すなら、1回あたりの速度差が累積して巨大なインパクトになる。逆に言えば、1回きりのタスクでHaikuを選ぶメリットは薄い。

第6章：モデル選定フローチャート — 判断の流れを可視化

実際のタスク判断を素早く行うため、テキスト版の判断フローを示す。

【モデル選定フローチャート】

  新しいタスクが到着
       ↓
  「このタスクに5分以上の考え込みが必要か？」
       ↓
     YES → 「複数資料の統合分析 or 戦略的構造化が必要か？」
       ↓       YES → 【OPUS を選択】
       ↓       NO  → 「複数資料を読み込む必要があるか？」
       ↓              ↓ YES → 【SONNET を選択】
       ↓              ↓ NO  → 【SONNET を選択】
       ↓
     NO  → 「ファイル操作/コード生成が含まれるか？」
              ↓ YES → 【SONNET を選択】
              ↓ NO  → 「単純な分類/要約/変換か？」
                       ↓ YES → 「同じパターンを10回以上繰り返すか？」
                               ↓ YES → 【HAIKU を選択】
                               ↓ NO  → 【SONNET を選択（安定性重視）】
                       ↓ NO  → 【SONNET を選択（迷ったらSonnet）】

このフローを1週間実行すれば、無意識的に最適なモデルを選べるようになる。

第7章：APIコスト最適化の具体的試算 — Before / After の数字

ここからは、API利用者向けにコスト試算を示す。Max契約者にとっても、「自分のMax枚をどう配分すべきか」の参考になるはずだ。

Before：Opusだけで回した場合

僕の月間利用量をざっくり見積もると、入力約300万トークン、出力約150万トークン。これをすべてOpus 4.6で回すと：

入力：300万トークン × $15 / 1M = $45
出力：150万トークン × $75 / 1M = $112.5
合計：月 $157.5（約23,600円）

この場合、API費用が高額になるだけでなく、Max契約の5時間ごと10回制限に頻繁に引っかかる。「あと何回Opusが使えるんだ」という心理的ストレスも発生していた。

After：3モデル混合で回した場合

実際の僕の利用配分は、Opus 15%、Sonnet 60%、Haiku 25%だ。これでコストを再計算する：

Opus分

入力：45万トークン（300万 × 15%）× $15 = $6.75
出力：22.5万トークン（150万 × 15%）× $75 = $16.88
小計：$23.63

Sonnet分

入力：180万トークン（300万 × 60%）× $3 = $5.40
出力：90万トークン（150万 × 60%）× $15 = $13.50
小計：$18.90

Haiku分

入力：75万トークン（300万 × 25%）× $0.80 = $0.60
出力：37.5万トークン（150万 × 25%）× $4 = $1.50
小計：$2.10

合計：月 $44.63（約6,700円）

コスト削減と品質の変化

項目	Opus一本槍	3モデル混合	改善率
月額費用	$157.5	$44.63	-72%
平均応答速度	遅い（10-30秒）	速い（2-8秒）	+70%
タスク品質	全て高品質	タスク別に最適	同等
Max制限への抵触	頻繁	ほぼなし	劇的改善

重要な発見：コスト削減と品質低下は必ずしも相関しない。適切なモデル配置により、コストを72%削減しながら、タスク別の品質は維持できる。むしろ、「軽い作業に高い思考力を使わない」ことで、Opusの利用効率が上がり、実質的な品質向上さえ実現される。

Max契約者にとっての意味

Max 20x契約者（月$200）にとって、このコスト試算は直接は関係ない。しかし、「利用枚の配分」として同じ考え方が適用できる。

Opusばかりをが使う場合、5時間ごとの利用制限に早く到達する。月の利用可能回数は限定的だ。軽いタスクをHaikuに回すだけで、Opusの枚を「ここぞ」の場面に温存できる。

僕のMax利用の実感では、3モデルを使い分けることで、利用制限を気にする場面がほぼゼロになった。以前Opusだけで回していたときは、夕方に「今日のOpus枚、あと何回使えるんだ」と気にしていた。この心理的な摩擦が消えただけで、思考のリズムが明らかに改善した。

さらに詳細な月額シミュレーションを以下に示す：

月間300万トークン利用のシミュレーション（複数パターン）

パターン	Opus %	Sonnet %	Haiku %	月額	年額	印象
パターン1：Opus重視	40%	40%	20%	$95.2	$1,143	コスト高、品質優先
パターン2：バランス型	20%	60%	20%	$51.0	$612	推奨構成
パターン3：コスト重視	10%	40%	50%	$29.3	$352	速度重視、リスク有
パターン4：実績配置	15%	60%	25%	$44.6	$535	筆者の実装

第8章：つまずきポイント3選 — よくある失敗と教訓

3ヶ月の使い分け実験で、「これは気をつけるべき」という落とし穴が3つ見つかった。

つまずきポイント①：Opusに全部任せてコスト爆発

最初の1ヶ月、僕はOpusだけを使っていた。結果、月$157.5というコストが発生し、Max契約でも利用枚への不安が生まれた。多くのユーザーが陥る罠は、「最も賢いモデル=最も効率的」という誤解だ。

教訓：賢さと効率は別。軽い作業に高級なモデルを使うのは資源の浪費。Max契約でもコスト意識は持つべき。

つまずきポイント②：Haikuの品質限界を無視した大失敗

逆に、Haikuに過度に依存した結果、複雑な分析タスクで不正確な結果を受け取ったことがある。領収書の仕訳分類は完璧だったが、「売上推移の3ヶ月トレンド分析」をHaikuに投げたときは、論点の見落としが発生した。

教訓：「軽いタスク」と「単純な分析」は別。分析の精度が必要な場面は、HaikuではなくSonnetを選ぶべき。

つまずきポイント③：モデル切り替えの判断基準が曖昧

「この仕事はOpusに任せるべき？それともSonnet？」という判断に時間がかかり、結果的に非効率になることもあった。判断基準が曖昧なまま使い分けようとすると、かえって生産性が落ちる。

教訓：判断ルールを明確にしておく。「5分以上考える必要があるか」「複数資料の統合が必要か」という2段階の問いで、99%のタスクはモデルが決まる。

第9章：読者ワーク — 「あなたのタスク別モデル配分表」を作成する

ここまでの知識を踏まえて、読者が自分自身のタスク配分を設計するためのワークシートを提供する。

【読者ワーク：自分のタスク別モデル配分表】

印刷して、実際の業務で遭遇するタスクを書き込み、推奨モデルを検討してみてほしい。

タスク名	月間頻度	1回あたりの時間	推奨モデル	実装してみた結果	メモ
例：クライアント提案書のストーリー設計	週1回	1-2時間	Opus	（実装後に記入）	複数資料の統合分析が必要
（以下、あなたのタスクを記入）

記入のコツ：

まず、現在よく使うタスクを5-10個、「タスク名」欄に書き込む
月間頻度と1回あたりの時間を見積もる
第5章のマッピング表を参考に、「推奨モデル」を記入
実際に1週間その配置で業務を回す
「実装してみた結果」欄に、精度・速度・コストの実感を記入
必要に応じて翌週のモデル配置を調整

このワークを1ヶ月回すだけで、自分にとって最適なモデル配分が見える。

第10章：関連記事への内部リンク — さらに深掘りするなら

このブログシリーズの関連記事を紹介する。モデル選定を軸にした関連テーマについて、さらに詳しく学べる。

【#008 Claude Max】Max契約の内容・制限・メリット徹底解説 — Opus の5時間ごと10回制限の詳細、Max契約のコスト計算、利用枚の最適配分戦略など、Max契約者向けのより詳しい情報を網羅。
【#009 Cowork モード】Claude Code をCowork で使いこなす秘書スキル — ファイル操作・Cowork モードでの各モデル（特にSonnet）の実装パターン、Skillsの活用方法を実践例で解説。
【#010 Claude Skills 設計】カスタムSkillに「推奨モデル」を組み込む方法 — 独自Skillに各タスクの推奨モデル情報を埋め込み、毎回の判断コストをゼロにする仕組みの作り方。
【#011 MCP 活用】Model Context Protocol で複数モデルの自動振り分けを実装 — MCPを使った「タスク自動分類 → モデル自動選択」の技術実装、エージェント化の一歩先を行くパターン。

まとめ：「1モデル1用途」の時代は終わった

3ヶ月の使い分け実験を通じて得た最大の学びは、「モデル選びはスペック比較ではなく、タスクとの相性マッピングだ」ということだ。

Opusは、白紙から論理構造を組み立てる「思考の外注先」。Sonnetは、分析からファイル操作まで幅広くこなす「実務の主力」。Haikuは、大量の軽いタスクを高速で回す「回転率の鬼」。この3つの役割を意識するだけで、コストは7割下がり、品質は落ちず、利用枚の心配も消えた。

多くの人が見落としているのは、「最も賢いモデルが最も生産的」とは限らないという事実だ。生産性は「品質×速度÷コスト」で決まる。Opusの品質がいくら高くても、軽いタスクに投入すれば速度とコストで負ける。逆に、Haikuの速度がいくら速くても、複雑な戦略タスクに投入すれば品質で負ける。

Before（Opus一本槍）：

月額費用：$157.5（約23,600円）
平均応答速度：10-30秒（遅い）
Max利用制限への抵触：頻繁（ストレス有）
全タスクが「最高品質」のため、実は過剰スペック

After（3モデル混合）：

月額費用：$44.63（約6,700円）
平均応答速度：2-8秒（速い）
Max利用制限への抵触：ほぼなし（ストレスなし）
タスク別に最適なモデルを選択、コスト削減と品質両立

このシフトは、単なる「安さ追求」ではない。むしろ、「資源を正しく配置する戦略」だ。Opusの限られた利用枠を「本当に必要な場面」に温存することで、その価値は逆に上がる。

「1モデル1用途」の時代は終わった。これからは、手元のタスクを「思考」「分析」「作業」のどれに当たるかを1秒で判断し、適切なモデルに振り分ける。そのスキルこそが、AI時代の生産性を左右する「新しいリテラシー」だと僕は思う。

そしてこのリテラシーは、実際にやってみれば1週間で身につく。まずは明日から、普段Opusに投げているタスクの半分をSonnetに、Sonnetに投げているタスクの3割をHaikuに置き換えてみてほしい。きっと「あれ、何も変わらない。いや、速くなった」と感じるはずだ。

その瞬間が、モデル使い分けのスタートラインだ。

AI実務家コンサルタント

大智（Daichi）

▶コンサル歴8年・不動産デューデリジェンス累計30件超
▶AI活用で月間作業57〜62時間削減を実現
▶地方遊休不動産の稼働率 28%→62% に改善

コンサルの相談・お問い合わせはこちら →