AIのコストを抑えるモデルの使い分け｜最新・最高級に寄せない判断の基準

AIで記事を直す仕組みを回していると、課金が思ったより伸びます。多くの場合、原因は作業量ではなく、全部の作業を最高級モデルで走らせていることです。

結論から書きます。モデルは「新しいから」「上位版だから」で選ばず、作業ごとに決めた合格点を満たす範囲で、一番安くて速いものを使います。昇格の理由は実測値だけです。最新版が出た、上位プランに加入している、は昇格の理由になりません。

この記事は、散らかったサイトをAIで作り変えるマニュアルの「前提」の作業の1本です。判断の基準をファイルに書く作業で決めた合格点を、そのままモデル選びにも使います。

この作業で決まること

この作業が終わると、どの作業にどのモデルを割り当てるかと、モデルを入れ替えてよい条件が決まります。

割り当ての例は次の形です。実際の線引きは、自分のサイトの合格点と実測値で決めます。

構造のチェック・採点・一覧の生成など、プログラムで数えられる作業：モデルを使わない、または安価なモデル
メタディスクリプション・alt・内部リンクなど、短く壊れにくい文の生成：中位のモデル
本文の全文監査、記事の骨格の作り替え、戦略の設計：最上位のモデル（頻度は低く抑える）

よくある失敗：全部の作業を最上位モデルで動かすこと。毎日の自動処理は件数が多いので、ここが一番コストを押し上げます。

前提：この記事の前に必要なもの

AIに渡す4つの前提が用意されていること（合格点がファイルにある）
モデル名を1か所にまとめて書き、作業ごとに参照する仕組み（SSOT）があること
AI作業の失敗ログを残す仕組みがあること（実測値を残す場所）

Claude Code でモデルを指定する方法は、公式ドキュメントに従います（Claude Code 公式ドキュメント）。

AIに渡すもの

作業の一覧と、それぞれの合格点（例：メタディスクリプションは110〜120字で主キーワードを含む、など）
候補のモデルの一覧（モデル名のSSOT）
評価用の入力セット（同じ記事・同じ指示で、モデルだけを入れ替えて比べる）
判定者のモデル（採点に使うモデルを固定する）

判定者を固定するのは、生成側と採点側を同時に替えると、差が生成の質か採点の甘さか分からなくなるからです。

手順

作業ごとに合格点を書く（文字数、含める要素、禁止する語など、機械で数えられる形にする）
候補のモデルを決める。最新版が出ても、候補に入れるだけで、まだ切り替えない
同じ入力・同じ指示で、候補のモデルを順に走らせる。判定者は1種類に固定する
合格点を満たしたモデルの中から、一番安くて速いものを選ぶ
モデル名をSSOT（1か所にまとめたファイル）に書く。昇格は1行、ロールバックは環境変数1つで戻せるようにする
切り替えたあと、最初の数日は作業ログを見て、合格点を満たしているかを実測する
実測値が落ちたら、SSOTを1行書き戻してロールバックする

5番目を飛ばすと、切り替えに踏み切れません。可逆性が先にあるから、実験ができます。

完了条件

☐ 作業ごとに割り当てるモデルが、1つのファイルに書かれている
☐ モデルの切り替えが、ファイルの1行の書き換えで済む
☐ 評価用の入力セットと判定者のモデルが固定されている
☐ 切り替えの判断の根拠（実測値）が、作業ログに残っている

実際に起きた失敗

「最新版だから上げる」で、2.4倍遅くなりかけた

自分のサイトの保守の仕組みで、縮退用のローカルモデルを入れ替えようとしました。新しい版が出たので、動作確認を1回だけ回して昇格させるつもりでした。

最初の採点では、新しい版のスコアが0点と出ました。危うく「新しい版は品質が低い」と結論を出すところでした。実際には、0点は生成の品質ではなく、判定者が返したJSONのパースに失敗していたための計測の失敗でした。再採点したら85点で、現行の84点と実質同等でした。

一方で、実測した処理時間は435秒と185秒で、新しい版が2.4倍遅いという結果でした。理由はバージョンではなく、モデルのアーキテクチャの違いです。現行は35Bのうち実際に動くのが3BのMoE、新しい版は27Bのdenseで、総パラメータ数が小さいほうが遅いという直感に反する結果になります。

この経験から、モデル選びに次の原則を置きました。

速度は総パラメータ数ではなく、実際に動くパラメータ数で決まる。MoEとdenseを並べて比べない
モデル比較では判定者を固定する。片方だけ新モデルで採点しない
スコア0は「悪い」ではなく「測れていない」を先に疑う。異常値は再計測する
最新版が出たことは昇格の理由にならない。昇格の理由は実測値だけ

可逆性を先に作っていたから、実験に踏み切れた

モデル名を1か所にまとめて書く仕組みを先に作っていました。昇格はそのファイルを1行書き換えるだけ、ロールバックは環境変数1つで戻せます。

もし昇格が複数のファイルに散らばった書き換えだったら、「戻すのが面倒だから、動作確認を1回で済ませたい」という圧力がかかります。実測値ではなく、作業者の都合でモデルが決まります。コストに関わる判断の前には、先に戻す道を作っておきます。

よくある質問

Q. 全部の作業を最上位のモデルに揃えたほうが、品質は上がりませんか？
A. 作業ごとの合格点を満たすかどうかで判断します。合格点を満たすなら、より安いモデルでも同じ結果になります。毎日動く自動処理は件数が多いので、ここで最上位モデルを使うとコストが伸びます。最上位モデルは、週1回の全文監査など、頻度の低い深い作業に残します。

Q. 新しいモデルが出たら、すぐ切り替えたほうが良いですか？
A. 候補に入れるだけにして、同じ入力・同じ判定者で実測してから決めます。「新しい」と「速い・安い・合格点を満たす」は別の話です。実測しないで切り替えると、遅くなっても気づかないまま課金が伸びます。

Q. 判定者をどのモデルにすればいいですか？
A. 1種類に固定することが先で、どのモデルかは次です。生成側を比較するあいだ、判定者のモデルは変えません。判定者も変えたいときは、生成側のモデルを固定した別の比較で決めます。

次の作業

作業ごとの合格点を1枚のファイルに書き出す
モデル名をまとめたSSOTファイルを作る
評価用の入力セットと判定者を固定する