複数のブログを自動運用していると、一日のうちに何度も Gemini を呼び出します。先日 Gemini 3.5 Flash が一般提供（GA）になり、あわせて 3.1 Flash-Lite が各プロダクトへ広がったタイミングで、私はパイプラインのどの工程にどのモデルを割り当てているかを一度棚卸ししてみました。気づいたのは、「とりあえず一番賢いモデルで全部やる」という素朴な構成が、思っていたより無駄を抱えていたことです。
ここでは、ひとつの処理を「下書き・分類・仕上げ」の3段に切り分け、段ごとに別のティアを割り当てる組み方を、実際のルーター実装と一緒にお伝えします。最新の最上位モデルに一気に寄せるのではなく、役割を分けて淡々と回すほうが、個人開発の自動運用では結局のところ堅い——というのが私自身の実感です。
「1モデルで全部」をやめた理由
最初は迷いなく上位ティアひとつにすべてを任せていました。品質は安定しますが、運用を続けるうちに二つの引っかかりが出てきます。
ひとつはコストです。本文の生成だけでなく、「この記事はどのカテゴリか」「タグ候補を5つ出す」といった軽い判定まで上位ティアに投げていたため、トークン単価の高い処理が一日の呼び出しの大半を占めていました。判定そのものは Flash-Lite でも十分な精度が出ます。
もうひとつは待ち時間です。分類のような短い処理にも上位ティアの推論時間がかかると、後続の工程がそのぶん待たされます。役割の軽い処理は速いモデルに任せたほうが、パイプライン全体のスループットが上がります。
逆に、最終的な仕上げ——読者が実際に読む文章の質——だけは妥協したくありません。ここを節約のために軽いモデルへ落とすと、一番大事なところで品質が崩れます。つまり工程ごとに求めるものが違うのだから、割り当てるモデルも分けるのが自然だ、という結論に至りました。
工程を3段に分けて割り当てる
私が落ち着いた割り当ては次の通りです。あくまで一例ですが、考え方の出発点になります。
| 工程 | 求めるもの | 割り当てるティア | 理由 |
|---|---|---|---|
| 下書き・素案出し | 速度と量。多少粗くてよい | Flash-Lite | 後段で必ず直すので、ここは安く速く回す |
| 分類・タグ付け・整形 | 安定した判定。決まった形式で返る | Flash | 構造化出力の追従が良く、単価も抑えられる |
| 仕上げ・最終推敲 | 文章の質と一貫性 | 上位ティア（Pro 系） | 読者が読む部分。ここだけは妥協しない |
ポイントは、節約してよい段と、してはいけない段を最初に決めておくことです。下書きと分類は安いモデルで構いませんが、仕上げを単価だけで判断すると後悔します。コスト削減の効果は前の2段で十分に出るので、最後の一段は質を優先して問題ありません。
段ごとにモデルを選ぶルーター
工程名を渡すと適切なモデル名と生成設定を返す、小さなルーターを挟むと管理が楽になります。モデル名を処理のあちこちに直書きせず、一箇所にまとめておくのが狙いです。GA や非推奨でモデルが入れ替わったとき、ここだけ直せば済みます。
// stageRouter.js — 工程ごとにモデルと設定を割り当てる
const STAGE_CONFIG = {
draft: { model: "gemini-3.1-flash-lite", temperature: 0.9, maxOutputTokens: 1200 },
classify: { model: "gemini-3.5-flash", temperature: 0.0, maxOutputTokens: 256 },
finalize: { model: "gemini-3.5-pro", temperature: 0.4, maxOutputTokens: 4000 },
};
// 概算用の単価（百万トークンあたりUSD。実際の値は料金ページで確認すること）
const PRICE_PER_MTOK = {
"gemini-3.1-flash-lite": { in: 0.10, out: 0.40 },
"gemini-3.5-flash": { in: 0.30, out: 2.50 },
"gemini-3.5-pro": { in: 1.25, out: 10.0 },
};
export function pickStage(stage) {
const cfg = STAGE_CONFIG[stage];
if (!cfg) throw new Error(`未定義の工程です: ${stage}`);
return cfg;
}
export function estimateCost(stage, inTokens, outTokens) {
const { model } = pickStage(stage);
const p = PRICE_PER_MTOK[model];
return (inTokens / 1e6) * p.in + (outTokens / 1e6) * p.out;
}呼び出し側は工程名を指定するだけになります。
import { GoogleGenAI } from "@google/genai";
import { pickStage, estimateCost } from "./stageRouter.js";
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });
async function runStage(stage, prompt) {
const { model, temperature, maxOutputTokens } = pickStage(stage);
const res = await ai.models.generateContent({
model,
contents: prompt,
config: { temperature, maxOutputTokens },
});
const usage = res.usageMetadata ?? {};
const cost = estimateCost(stage, usage.promptTokenCount ?? 0, usage.candidatesTokenCount ?? 0);
console.log(`[${stage}] ${model} 概算 $${cost.toFixed(5)}`);
return res.text;
}こうしておくと、本文を書くコードはモデル名を意識しなくなります。runStage("draft", ...) のように工程の意図だけを書けるので、後で読み返したときにも処理の流れが追いやすくなります。
コストの見え方が変わる
工程を分けて最初に効くのは、コストの内訳が見えるようになることです。estimateCost をログに残しておくと、「分類が一日の呼び出し回数の7割を占めているのに、金額では1割に満たない」といった偏りがはっきり数字で出ます。
仮に一日に下書き40回・分類120回・仕上げ40回を回すパイプラインを考えてみます。分類は回数こそ多いものの、出力が短く Flash の単価も控えめなので、合計金額への寄与は小さくなります。逆に仕上げは回数が少なくても、長い出力と上位ティアの単価で金額の中心になります。この構造が見えると、「どこを削れば効くか・どこは削っても効かないか」が直感ではなく数字で判断できるようになります。
私の場合、軽い判定をすべて上位ティアに投げていた頃と比べて、出力品質を落とさずに API コストを目に見えて圧縮できました。削ったのは下書きと分類のティアだけで、読者が読む仕上げ部分には一切手をつけていません。
運用してみて決めた2つの歯止め
しばらく回すうちに、ルーターに最低限の歯止めを足しました。
ひとつはフォールバックの方向を「下げる」ではなく「上げる」にしておくことです。仕上げのモデルが一時的に応答しないとき、安い下位ティアへ自動で落とすと、一番質を守りたい段で静かに品質が崩れます。仕上げで失敗したら下げるのではなく、短い待機を挟んで再試行し、それでも駄目なら処理を止めて記録する——という方針にしています。コストを理由に仕上げの品質を犠牲にしない、という最初に決めたルールをコードでも守る形です。
もうひとつは非推奨の期限をルーターのコメントに必ず書いておくことです。Gemini はモデルの入れ替わりが速く、画像系のプレビューモデルのように停止日が決まっているものもあります。割り当てを一箇所に集めておけば、停止日が来る前にそこだけ差し替えれば済みます。私は Dolice Labs で複数のブログを並行して回していますが、この「差し替え箇所がひとつ」という状態が、日々の運用の安心に直結しています。
工程別の割り当ては、特別な仕組みではありません。けれど「どの段で何を求めるか」を一度言葉にして、それをルーターという形でコードに残すだけで、コストの判断も、モデル入れ替えへの対応も、ぐっと落ち着いて進められるようになります。まずは手元のパイプラインで一番呼び出し回数の多い処理を見つけて、それが本当に上位ティアを必要としているかを問い直すところから始めてみてください。