投稿者 投稿日: カテゴリー EC×AI活用
モデルルーティングとは、業務ごとに使うAIモデルを振り分ける設計のことです。
商品説明文の一括生成に、最上位モデルを使っていませんか。月間の請求書を見て「思ったより高い」と感じているなら、原因はたいていここにあります。最上位モデルと軽量モデルでは出力トークン単価が5倍前後違い、商品説明文のような定型生成では出力量が支配的になります。本記事では、月間で入力470万トークン・出力229万トークンを消費する店舗を想定し、全部を最上位モデルで処理した場合と、業務ごとに振り分けた場合の費用を実際の公開価格で計算します。結果は約67%の削減でした。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、プロンプト4本つきで解説します。
単価の差が5倍あるのに、同じモデルで全部やっている
結論として、EC運営でAI費用が膨らむ最大の要因は、モデル選定を業務単位で分けていないことです。理由は、公開価格の時点で最上位モデルと軽量モデルのあいだに大きな開きがあり、その差が出力トークンでさらに拡大するからです。
2026年8月時点の主要モデルの公開価格を並べます。100万トークンあたりの入力／出力の順です。AnthropicはClaude Opus 5が5米ドル／25米ドル、Claude Sonnet 5が導入価格で2米ドル／10米ドル（2026年8月31日までの価格で、それ以降は3米ドル／15米ドル）、Claude Haiku 4.5が1米ドル／5米ドルです。OpenAIのGPT-5.6は上位のSolが5米ドル／30米ドル、Terraが2米ドル／12米ドル、軽量のLunaが0.20米ドル／1.20米ドルとされています。Googleは Gemini 3.6 Flash が1.50米ドル／7.50米ドルという水準です（各社の価格は変動するため、実装前に公式の料金ページで最新値を確認してください）。
ここで注目したいのは出力単価の開きです。Claude Opus 5 の出力25米ドルに対して Haiku 4.5 は5米ドルで5倍、GPT-5.6 Sol の30米ドルに対して Luna は1.20米ドルで25倍の差があります。商品説明文やレビュー返信のように「入力は短く、出力が長い」タスクでは、この出力単価の差がそのまま請求額の差になります。
現場で繰り返し見るのは、検証段階で最上位モデルを使い、そのまま本番運用に流れているケースです。精度を確かめるために上位モデルを使うのは正しい判断ですが、精度が確認できた時点で下位モデルに落とす検証を行っていない。ここが抜けたまま数か月が経過し、請求額を見て慌てる、という流れです。
4つの業務で実際に計算する
想定する店舗の条件を置きます。月商3,000万円規模、楽天市場とAmazonとShopifyの3面展開、新規登録が月500点、レビューが月3,000件、電話とメールの問い合わせが月800件。この店舗が生成AIを使っている業務を4つに絞ります。
第一が商品説明文の生成です。500点に対して、入力2,000トークン・出力1,500トークンを消費するとして、月間で入力100万トークン・出力75万トークンになります。
第二がレビュー分析です。3,000件に対して入力500トークン・出力300トークンで、入力150万トークン・出力90万トークン。
第三が問い合わせの一次回答です。800件に対して入力1,500トークン・出力600トークンで、入力120万トークン・出力48万トークン。
第四が施策の意思決定です。月20回、売上データや競合状況をまとめて分析させる用途で、1回あたり入力50,000トークン・出力8,000トークンとすると、入力100万トークン・出力16万トークンになります。
合計すると入力470万トークン、出力229万トークンです。
これを全部 Claude Opus 5（5米ドル／25米ドル）で処理すると、入力が4.7×5で23.5米ドル、出力が2.29×25で57.25米ドル、合計80.75米ドルになります。1ドル150円換算で約12,100円です。
次に振り分けます。商品説明文とレビュー分析は定型処理なので Haiku 4.5（1米ドル／5米ドル）。商品説明文が1.0×1＋0.75×5で4.75米ドル、レビュー分析が1.5×1＋0.9×5で6.00米ドル。問い合わせの一次回答は文脈理解が要るので Sonnet 5 の導入価格（2米ドル／10米ドル）を使い、1.2×2＋0.48×10で7.20米ドル。意思決定だけ Opus 5 に残し、1.0×5＋0.16×25で9.00米ドル。
合計26.95米ドル、約4,000円です。80.75米ドルから26.95米ドルへ、削減率は約67%になります。Sonnet 5 が通常価格（3米ドル／15米ドル）へ移行した場合でも合計30.55米ドルで、削減率は約62%を維持します。
数字のカラクリは単純です。トークン量の大半を占める定型処理を、単価の安いモデルへ逃がしただけです。難しい判断が必要な用途だけ上位モデルに残せば、精度を落とさずに費用が下がります。
内訳を見ると、削減の効き方がはっきりします。全部を上位モデルで処理した80.75米ドルのうち、出力分が57.25米ドルで7割を占めていました。振り分け後は出力分が17.05米ドルまで下がっています。つまり削減の大半は出力単価の差から生まれており、入力側の工夫（プロンプトを短くするなど）よりも、出力の多い業務をどのモデルに置くかのほうが影響が大きいという構造です。
さらに踏み込むなら、商品説明文とレビュー分析をより安価な軽量モデルに置き換える選択肢もあります。たとえば出力単価が1.20米ドル台のモデルを使えば、この2業務の合計は理論上さらに下がります。ただしここは精度との相談で、日本語の商品説明文で必要な品質が出るかは、実際の商品データで検証しないと分かりません。単価だけ見て飛びつくと、手直しの工数で相殺されます。
なお、この試算はキャッシュを使わない前提の数字です。同じ前置きを繰り返し送る用途では、プロンプトキャッシュが使えると入力側の費用がさらに下がります。ルーティングの設計とキャッシュの設計は別軸なので、両方を組み合わせるとさらに効きます。
もう1点、削減率だけを目標にしないでください。上位モデルを使うべき業務まで軽量モデルへ落とすと、誤った分析にもとづく施策判断という形で、API費用より大きな損失が出ます。判断系だけは費用を惜しまない、という原則を先に決めておくことをおすすめします。
タスクを4階層に分けるルーティング設計
階層1：定型変換（軽量モデル）
入力を決まった形式に変換するだけの処理です。商品説明文の生成、箇条書きの整形、CSVの列変換、翻訳の下訳。判断の余地が小さく、出力の正解形が決まっています。ここは軽量モデルで十分機能します。
階層2：分類と要約（軽量〜中位モデル）
レビューの感情分類、問い合わせのカテゴリ振り分け、通話ログの要約。入力を理解する必要はありますが、出力は短く定型的です。軽量モデルで始め、精度が足りなければ中位へ上げる進め方が効率的です。
階層3：文脈依存の生成（中位モデル）
問い合わせへの一次回答、レビューへの返信、キャンペーン文面の作成。相手の状況に合わせた言い換えが必要で、トーンの調整も要ります。ここを軽量モデルでやると、機械的な文面になって顧客の反応が変わります。
階層4：判断と分析（上位モデル）
売上データの分析、施策の優先順位付け、規約リスクの判定、長文コンテキストの横断分析。誤ると損失が出る領域です。ここは費用を惜しまず上位モデルを使います。
階層の境界で迷ったときの判断軸を1つ示します。「その出力を人間がそのまま外部へ出すか」を基準にしてください。顧客に届く文面、モールに登録する商品情報、社外に出る資料は、階層3以上に置きます。社内で人間が読んで判断材料にするだけの中間生成物は、階層1〜2で十分なことが多い。この線引きで考えると、レビュー返信は階層3、レビューの傾向分析は階層2、という整理になります。
ジャンルによる違いもあります。食品ギフトのように季節の言い回しや熨斗の慣習が絡むジャンルでは、商品説明文であっても軽量モデルでは表現が浅くなることがあります。逆に工具や消耗品のように仕様の羅列が中心のジャンルでは、軽量モデルで十分機能します。階層の割り当ては、業務名だけでなく自店の商材特性を踏まえて決めてください。
（用途タイトル：業務のモデル階層振り分け）
プロンプト1：EC業務をモデル階層に振り分ける
あなたはAI運用コストの設計に詳しいコンサルタントです。
以下の業務一覧を4階層に振り分け、推奨モデルとコスト試算を出してください。
階層の定義：
1. 定型変換（判断の余地が小さく出力の正解形が決まっている）→ 軽量モデル
2. 分類と要約（入力理解は要るが出力は短い）→ 軽量〜中位モデル
3. 文脈依存の生成（相手に合わせた言い換えが必要）→ 中位モデル
4. 判断と分析（誤ると損失が出る）→ 上位モデル
各業務について出す項目：
A. 階層と推奨モデル、その根拠を1行
B. 月間の入力トークン数と出力トークン数の推定（1件あたりの推定値と件数を明記）
C. 現行モデルでの月額と、推奨モデルでの月額（公開価格で計算、単価も明記）
D. 削減額と削減率
E. 精度が落ちるリスクと、その検知方法
業務一覧：
{業務名／月間件数／1件あたりの入力の長さ／出力の長さ／現在使っているモデル}
制約：単価は実装時点の公式料金ページの値を使い、推定値には「推定」と明記すること。
振り分けの前に固定テストセットを作る
ここが競合の解説に欠けている工程です。モデルを下げるなら、下げても大丈夫かを判定する基準が要ります。基準がないまま下げると、品質が落ちたことに数か月気づきません。
作るのは固定テストセットです。各業務について、実際の入力を20〜30件抜き出し、期待する出力の要件を定義します。商品説明文なら「文字数が範囲内」「禁止表現を含まない」「指定した訴求語を含む」といった機械的に判定できる条件と、「読んで違和感がないか」という人手の判定を組み合わせます。
このテストセットは、モデルが更新されるたびに再実行します。2026年に入ってからのモデル更新の頻度を考えると、これは半年に1度ではなく、四半期に1度は回すべき作業です。
作るのに要する時間は、1業務あたり2〜3時間が目安です。入力サンプルの抽出に1時間、合格条件の定義に1時間、初回の実行と判定に1時間。一度作れば繰り返し使えるので、実質的には初期投資と考えてよいでしょう。アパレル系の単一店舗で試したケースでは、商品説明文のテストセットを作った結果、想定していたよりも軽量モデルで通ることが分かり、切り替えの判断が2週間早まりました。
注意点として、テストセットの入力に難易度の偏りが出ないようにしてください。簡単な商品ばかりを選ぶと軽量モデルでも通ってしまい、本番で複雑な商品に当たって崩れます。商品点数の多いジャンルから3件、仕様が複雑な商品から3件、説明文が短くて済む商品から3件、といった形で分散させます。
判定を人手だけに頼らないことも重要です。文字数、禁止表現の有無、必須キーワードの含有は、簡単なスクリプトで機械判定できます。機械判定を先に通し、通ったものだけを人間が読む二段階にすると、確認の負荷が大幅に下がります。
（用途タイトル：固定テストセットの設計）
プロンプト2：モデル切り替え判定用の固定テストセットを作る
あなたはAI出力の品質評価を設計する担当者です。
以下の業務について、モデルを切り替えてよいか判定するための固定テストセットを設計してください。
設計する要素：
1. 評価用の入力サンプル（20件、実データから選ぶ基準を提示。難易度が偏らないよう分散させる）
2. 機械判定できる合格条件（文字数・禁止表現の有無・必須要素の有無など、5項目以上）
3. 人手判定が必要な観点（3項目以内、各観点の判定基準を1行で）
4. 合格ラインの設定（機械判定は全件通過、人手判定は何割以上か）
5. 不合格だった場合の対応（プロンプト調整で解決するか、モデルを戻すかの判断基準）
業務内容：{業務の説明}
現在のモデル：{モデル名}
切り替え候補：{モデル名}
出力の要件：{文字数・形式・トーン・禁止事項}
ルーティングを実装する3つの方法
第一の方法は、業務ごとにAPIキーと呼び出し先を分けるだけの手動ルーティングです。実装が最も簡単で、スクリプトが業務ごとに分かれている店舗ならこれで足ります。
第二の方法は、ルーティング層を1つ挟む方式です。業務の種別を引数で受け取り、対応するモデルへ振り分ける関数を作ります。モデルを変更するときに1か所を直せば済むため、保守性が上がります。
第三の方法は、ルーターサービスを使う方式です。複数のモデルへの接続を1つのエンドポイントで扱えるサービスが増えており、モデル名を指定するだけで切り替えられます。ただし、経由するぶんの手数料と、障害時に切り分けが増える点は考慮が必要です。
どの方法でも、フォールバックの設計は必須です。指定したモデルが応答しないときに上位モデルへ切り替えるか、リトライするか、処理を止めるか。EC運営では「止まるより、多少高くても動く」ほうが望ましい場面が多いため、上位への一時的な切り替えを組み込んでおくのが実務的です。
ただしフォールバックには落とし穴があります。上位モデルへの切り替えが常態化していると、費用は下がらないのに設計だけ複雑になっている状態になります。フォールバックの発生回数を記録し、月間の一定割合を超えたらアラートを出す仕組みを併せて入れてください。多発しているなら、それは軽量モデル側の設定かレート制限の見直しが必要というサインです。
実装の順序としては、まず第一の手動ルーティングで始めることをおすすめします。いきなりルーティング層を作り込むと、どの業務にどのモデルが合うかの知見がないまま設計してしまい、後で作り直しになります。3か月ほど手動で運用し、振り分けが安定してから第二の方式へ移す流れが、手戻りの少ない進め方です。
設定ファイルの持ち方も一言だけ。モデル名と単価を同じファイルに書いておくと、コスト集計のときに参照先が1つで済みます。単価が改定されたらそのファイルだけを直せばよく、集計スクリプト側を触る必要がありません。
（用途タイトル：ルーティング層の仕様設計）
プロンプト3：モデルルーティング層の仕様を設計する
あなたはシステム設計を担当するアーキテクトです。
以下の条件で、モデルルーティング層の仕様書を作成してください。
仕様に含める要素：
1. 入力インターフェース（業務種別・プロンプト・オプションの受け渡し方）
2. ルーティングテーブル（業務種別 → モデル名 → 単価、を設定ファイルで外出しする形）
3. フォールバック条件（タイムアウト／レート制限／エラー時の挙動、それぞれの待機時間と上限回数）
4. ログ出力項目（業務種別・使用モデル・入出力トークン数・所要時間・概算コスト）
5. 月次でコストを集計する仕組み
制約：
- モデル名と単価は設定ファイルに外出しし、コード変更なしで切り替えられること
- 上位モデルへのフォールバックが発生した回数を記録し、閾値を超えたらアラートを出すこと
- 認証情報はコードに直書きせず環境変数から読むこと
実行環境：{言語／実行基盤}
対象業務：{業務一覧}
費用を追跡する仕組みを先に作る
削減の前に、いま何にいくら使っているかを把握します。多くの店舗ではAPIの請求額を月次の合計でしか見ておらず、どの業務がいくら消費しているかを分けられていません。分けられないと、削減の効果も測れません。
最低限、業務種別ごとにトークン数を記録します。API呼び出しのたびに、業務種別・モデル名・入力トークン数・出力トークン数をログに残すだけで、月末に集計できます。
記録を始めると、たいてい予想外のことが1つ見つかります。想定していない業務が費用の上位に入っている、1回あたりのトークン数が想定の何倍もある、テスト実行が本番と同じログに混ざっている。直近の支援案件で観測したのは、開発時の試行錯誤が本番アカウントで動いており、全体の2割近くを占めていたケースでした。検証用のキーを分けるだけで解決する話です。
集計の粒度は、業務種別で分けられていれば十分です。SKU単位や担当者単位まで細かく取ろうとすると、ログの設計が重くなって続きません。まず4〜6種別に分けて記録を始め、必要が出たら細かくする順序でよいでしょう。
（用途タイトル：AI費用の月次レポート作成）
プロンプト4：AI利用ログから月次コストレポートを作る
あなたはコスト分析を担当するアナリストです。
以下のAPI利用ログから、月次のコストレポートを作成してください。
レポートに含める内容：
1. 業務種別ごとの入出力トークン数と概算コスト（単価を明記して計算過程を示す）
2. コスト構成比の上位5業務
3. 前月比の増減と、増加している業務の要因仮説
4. 上位モデルへのフォールバックが発生した回数と、それによる追加コスト
5. さらに下位モデルへ移せる可能性がある業務の候補と、その根拠
分析の観点：
- 出力トークン数が入力の半分を超える業務は、モデル単価の影響が大きいので優先的に指摘する
- 1回あたりのトークン数が想定より多い業務は、プロンプトの冗長さを疑う
- 削減案には必ず「精度が落ちるリスク」を併記する
利用ログ：{日時／業務種別／モデル名／入力トークン数／出力トークン数}
モデル単価表：{モデル名／入力単価／出力単価}
この設計が効いてくる本当の理由
競合の記事が触れていない論点を挙げます。モデルルーティングの価値は費用削減そのものではなく、モデルの入れ替わりに対する耐性です。
2026年に入ってから、主要ベンダーの新モデル発表は数か月おきに起きています。価格改定も頻繁で、直近では特定モデルの出力単価が大幅に引き下げられた例もあります。1社1モデルに固定していると、この変動が起きるたびに全業務の実装を見直すことになります。ルーティング層があれば、設定ファイルのモデル名を書き換えるだけで済みます。
もう1つの論点は、ベンダー障害への備えです。単一ベンダーに依存していると、そのベンダーが止まった瞬間に全業務が止まります。複数モデルへの接続を最初から持っていれば、フォールバック先が確保できます。EC運営では、受注や問い合わせ対応が止まる影響が大きいため、この冗長性には費用以上の価値があります。
モデル選定の考え方はClaudeのモデル選び方、直近の価格動向はClaude Sonnet 5の導入価格、コーディング用途での使い分けはClaude Codeのサブエージェントとモデル指定で扱っています。
よくある質問
複数のベンダーと契約するのは手間ではありませんか
はい、初期の手間は増えます。ただし2社程度なら、アカウント開設と支払い方法の登録で完了します。3社目以降を検討する段階になったら、複数モデルを1つのエンドポイントで扱えるサービスの利用を検討してください。手間と削減額を比較して判断します。
軽量モデルに落とすと品質が落ちませんか
業務によります。定型変換や分類では、軽量モデルでも上位モデルとほぼ変わらない結果になることが多い一方、長文の分析や規約判断では明確な差が出ます。だからこそ固定テストセットで検証してから切り替えます。感覚で判断しないでください。
削減率6割はどの店舗でも出ますか
いいえ、出ません。本記事の試算は、定型処理が全体のトークン量の大半を占める前提で計算しています。上位モデルでしかできない分析が業務の中心を占める店舗では、削減幅は小さくなります。まず自店のトークン内訳を把握してください。
小規模店舗でも意味がありますか
月額のAPI費用が数千円の規模なら、削減額より設計の手間のほうが大きくなります。ただしトークン内訳の記録だけは始めておくことをおすすめします。利用が増えたときに、どこから手を付けるかがすぐ分かるためです。
モデルが更新されたらどうしますか
固定テストセットを再実行し、現在のモデルと新モデルを同じ入力で比較します。品質が同等以上で価格が下がっているなら切り替え、そうでなければ据え置きます。この判断を四半期に1度回す運用にしてください。
プロンプトはモデルごとに書き分ける必要がありますか
原則として同じプロンプトで動きますが、軽量モデルでは指示をより具体的にする必要が出る場合があります。上位モデルは曖昧な指示でも意図を汲みますが、軽量モデルは書かれたとおりに動く傾向が強いためです。切り替え時にプロンプトの明確化が要ることは想定しておいてください。
為替の変動はどう扱いますか
API料金は米ドル建てが一般的なので、円安が進むと円換算の費用が上がります。予算を立てるときは、為替のレンジを幅で見積もってください。本記事の円換算は1ドル150円で計算しており、実際の請求額は為替により変動します。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
