前回、モデル選びの軸は「判断が主役のタスクか、作業が主役のタスクか」だという話をしました。今回はその「判断が主役」側、つまり多少クレジットを使ってでも高性能モデル(Claude Opus、GPT-5.5クラスなど)に切り替えたほうが結果的に得をする具体的な場面を6つに分けて紹介します。
1. ゼロから設計方針を決めるとき
新規プロジェクトやモジュールを「何もないところから」立ち上げるとき、最初の設計判断(ディレクトリ構成、責務の分割、状態管理の方式、データモデルの決め方)は、後から一番直しにくい部分になります。軽量モデルはその場では動くコードを出せても、拡張性や一貫性まで踏まえた設計判断は苦手なことが多いです。ここで安いモデルに任せて「とりあえず動くもの」を積み上げてしまうと、後工程で設計の歪みを直すコストの方が高くつきます。最初の骨格づくりだけは高性能モデルに任せるのが、結果的に安上がりになりやすいです。
2. 既存の大規模コードベースに手を入れるとき
自分が全体を把握しきれていない既存コード(特に他人が書いたレガシーコード)を触るときは、影響範囲の見落としがそのままバグに直結します。高性能モデルは複数ファイル間の依存関係を追跡し、変更が波及する箇所を洗い出す精度が高い傾向にあります。軽量モデルだと「言われた1ファイルだけ」を直して、呼び出し元の整合性が崩れるといった事故が起きやすくなります。
3. 原因不明のバグを追っているとき
「エラーメッセージ通りに直したのに直らない」「再現条件がよくわからない」といった、原因の当たりがついていないデバッグは、仮説→検証→仮説の再構築というループを何段も回す必要があります。軽量モデルはこのループの途中で同じ間違った仮説に固執しやすく、結果的に何度もやり取りを重ねてかえって消費が増えることがあります。長引きそうなバグは早めに高性能モデルへ切り替えたほうが、総コストは下がりやすいです。
4. セキュリティ・認証・決済など「間違えられない」領域
認証まわり、権限制御、決済処理、個人情報の取り扱いなど、間違いが事故に直結する領域は、コード生成の精度そのものよりも「見落としの少なさ」が重要になります。ここは軽量モデルで浮いたコストが、事故対応コストに対して割に合わない典型例なので、迷わず高性能モデルを使うのがおすすめです。
5. あいまいな要件を仕様に落とし込むとき
「こんな感じの機能が欲しい」という粒度の指示から、具体的な仕様(入力・出力・例外処理・エッジケース)まで詰める作業は、複数の妥当な解釈の中から一つを選び取る判断力が必要になります。軽量モデルはここで安易な解釈に飛びつきがちで、後になって「思っていたのと違う」手戻りが発生しやすくなります。要件定義・仕様策定のフェーズは、高性能モデルとの対話で固めてしまうのがよいでしょう。
6. マルチステップのエージェント的タスク
複数のツール呼び出しやファイル編集を連続して行う、いわゆるエージェント的なタスク(例:機能追加のためにAPI追加→型定義更新→テスト追加→ドキュメント更新、を一気通貫でやらせる)は、途中のステップでの小さな誤りが後続ステップに連鎖しやすいです。高性能モデルは全体の一貫性を保ちながら長い手順をこなす精度が高く、こうした「一気にやらせるタスク」との相性が良いです。
まとめ:高性能モデルは「保険」として使う
共通しているのは、やり直しのコストが高い場面ほど高性能モデルの価値が上がるという点です。逆に言えば、失敗してもすぐ直せる小さなタスクであれば、多少精度が落ちても軽量モデルで十分です。次の記事では、逆に軽量モデルで十分な場面と、両者を組み合わせた実践的なワークフローを紹介します。