全部のタスクを最上位モデルに投げていませんか？
ミドリ： タツヤさん、社内で使っているAI機能のAPI費用が、想定の3倍くらいになってしまって……。使われているのは良いことなんですけど、経理から説明を求められています。
タツヤ(nodding)： よくある相談だね。まず1つ確認させて。社内の全機能、同じモデルで動かしてる？
ミドリ： ……はい。いちばん賢いやつを指定しておけば間違いないと思って。
タツヤ： それが原因の8割だと思うよ。2026年のAPI設計では、タスクごとにモデルの階層を割り当てるのが標準になってる。今日はその考え方を整理しよう。
2026年、モデルは3階層に整理された
ミドリ： 階層って、どういう分け方なんですか？
タツヤ： 主要ベンダーがほぼ揃って、上位・中位・軽量の3段構成を出してきた。2026年7月にOpenAIが一般公開したGPT-5.6ファミリーがわかりやすい例で、上からSol・Terra・Lunaという並びになっている。
ミドリ(thinking)： 名前で階層がわかるようになってるんですね。
タツヤ： Anthropicは2026年7月24日にOpus 5をリリースしてClaude Maxの既定モデルにしたし、Googleも2026年8月13日にGemini 3.7 Flashを出している。各社とも「最上位1本」ではなく「用途別に選べるライン」を持つ形に落ち着いた。
ミドリ： なぜこの形に？
タツヤ： エージェントが普及して、1つの依頼で何十回もモデルを呼ぶようになったから。呼び出し1回あたりの単価が、そのまま運用コストに直結するようになったんだ。
価格差は「倍」ではなく「桁」
ミドリ： 実際、階層でどのくらい価格が違うんですか？
タツヤ： 公表されている単価を並べるとこうなる。100万トークンあたりの入力/出力価格だよ。
| モデル | 入力(/1Mトークン) | 出力(/1Mトークン) |
|---|---|---|
| GPT-5.6 Sol(上位) | $5.00 | $30.00 |
| GPT-5.6 Terra(中位) | $2.00 | $12.00 |
| GPT-5.6 Luna(軽量) | $0.20 | $1.20 |
| Claude Opus 5(上位) | $5.00 | $25.00 |
ミドリ(surprised)： Sol と Luna で……出力が25倍違いますか？
タツヤ： そう。しかも2026年は下位モデルの値下げ競争が起きていて、OpenAIはLunaの価格を大幅に下げている。モデル競争の軸が、性能から「同じ性能をいくらで出せるか」に移ったんだ。
ミドリ： じゃあ安いモデルで全部やればいいんじゃ……。
タツヤ(thinking)： そこは早い。軽量モデルは難しい推論で明確に落ちる。全部Lunaにしたら、今度は誤答の後始末で人件費が飛ぶ。だから割り当ての話になる。
なお各社の価格は改定が頻繁です。実際の見積もりでは必ず公式の料金ページで最新の単価を確認してください。ここでの数字は階層差の大きさを掴むための目安として扱ってください。
階層の割り当て表を作る
ミドリ： 割り当ての基準はどう決めればいいですか？
タツヤ： うちで使っている判断軸は3つ。「間違えた時のコスト」「必要な推論の深さ」「呼び出し回数」。これで表を作る。
| タスク | 推論の深さ | 誤りコスト | 呼び出し量 | 割り当て |
|---|---|---|---|---|
| 文章の分類・タグ付け | 浅い | 低 | 多い | 軽量 |
| 定型メールの下書き | 浅い | 低 | 多い | 軽量 |
| 検索クエリの書き換え | 浅い | 低 | 非常に多い | 軽量 |
| 議事録の要約 | 中 | 中 | 中 | 中位 |
| 顧客向け提案文の生成 | 中 | 中 | 少ない | 中位 |
| 設計判断・コードレビュー | 深い | 高 | 少ない | 上位 |
| 契約書のリスク抽出 | 深い | 非常に高 | 少ない | 上位 |
ミドリ： 「呼び出し量が多くて浅いもの」から軽量に落とすのがコスパいいんですね。
タツヤ(nodding)： そこが最大の削減ポイント。エージェントの内部処理は、実は浅いタスクの塊なんだ。「次にどのツールを呼ぶか」「この検索結果は関連するか」みたいな判定が大量に走っている。
ミドリ： 全部が高度な推論じゃないと。
タツヤ： ぜんぜん違う。体感だと呼び出し回数の7〜8割は判定・整形・分類で、深い推論が要るのは残りの2〜3割。ここを分けるだけで請求書が変わる。
段階的エスカレーションという設計
ミドリ： 分類が難しいタスクはどうすればいいですか？「たまに難しい」みたいなやつ。
タツヤ： そこはエスカレーションで設計する。まず軽量で処理して、自信がない時だけ上位に上げる。
1. 軽量モデルで処理
2. 出力に自己評価を付けさせる(確信度・不足情報)
3. 確信度が低い / 必須項目が欠けている → 上位モデルで再実行
4. それでも満たさない → 人間にエスカレーションミドリ(thinking)： 2回呼ぶことになるから、かえって高くなりませんか？
タツヤ： そこは頻度次第。上位に上がる割合が2〜3割以内なら、全件を上位で回すより確実に安い。逆に半分以上上がってしまうなら、そのタスクは最初から上位に固定したほうがいい。
ミドリ： どっちが得か測ってから決めるんですね。
タツヤ： そう。エスカレーション率をログに残して、月次で見る。これが階層化を続けるための唯一の運用コストだよ。
削減はモデル選定だけではない
ミドリ： モデルを分ける以外に、効く手はありますか？
タツヤ： 3つある。順に効果が大きい。
- プロンプトキャッシュを使う — 毎回同じシステム指示や参照文書を送っているなら、キャッシュ対象にすると入力側が大きく下がる
- 渡す情報を削る — 検索結果を20件から5件に減らすだけで入力トークンが減る。精度も上がることが多い
- 出力を短くする — 出力単価は入力の5〜6倍。「200字以内で」と指定するだけで効く
ミドリ(surprised)： 出力のほうが高いんですね。知りませんでした。
タツヤ： ここは見落とされがち。表を見返してほしいんだけど、Solは入力$5に対して出力$30。冗長な回答は、そのまま冗長な請求になるんだ。
ミドリ： 「丁寧に長く答えて」って書いてました……。
タツヤ(smiling)： それ、費用対効果でいうといちばん高くつく一文だね。
乗り換えやすい構造にしておく
ミドリ： 価格がこれだけ動くと、乗り換えも起きますよね。
タツヤ： 起きる。だから特定モデルに直結しない書き方にしておくのが大事。
- モデル名を設定値として1か所に置く。コード中に散らさない
- リクエストを組み立てる処理を共通の関数にまとめる
- 評価用の入力セットを20〜30件用意しておく — 乗り換え検討時に即比較できる
ミドリ： 評価セットがあると判断が速くなりますね。
タツヤ： これが本当に効く。新モデルが出た日に30分で判断できる会社と、検討に3週間かかる会社の差は、この20件があるかどうかだけなんだ。
脱エンジニアの視点で考えると、「どの業務が間違えても取り返せるか」を仕分けできるかが分岐点になります。 誤りコストの判断は業務を知っている人にしかできない。技術的な性能比較より、こちらのほうが階層化の精度を決めるよ。
定額プランとAPI課金は別問題
ミドリ： ちなみに、社員が使っている月額プランのほうはどう考えればいいですか？
タツヤ： そこは切り分けたほうがいい。人が対話で使う分は定額プラン、システムが自動で呼ぶ分はAPI。この2つは会計上も運用上も別物として扱う。
| 用途 | 適した契約 | 費用の性質 |
|---|---|---|
| 社員が調べ物・文章作成に使う | 定額プラン | 人数に比例。予測しやすい |
| 社内システムがAIを呼ぶ | API従量 | 利用量に比例。急増しうる |
| エージェントが自動で動く | API従量 | 呼び出し回数に比例。最も膨らむ |
ミドリ(thinking)： 危ないのは下の2つですね。
タツヤ： そう。定額プランは上限が決まっているから事故らない。膨らむのは必ずAPI側。だから予算管理も、API側にだけ月次の上限アラートを仕込んでおくといい。
ミドリ： アラートは何を基準に設定すればいいですか？
タツヤ： 単純でいい。平常月の1.5倍で通知、3倍で自動停止。無限に回るループが1本混ざるだけで、1日で月予算を使い切ることが現実に起きるからね。
削減シミュレーションの立て方
ミドリ： 経営会議で説明する時、どう見せればいいですか？
タツヤ： 3行で済む表を作る。仮に月100万回の呼び出しがあって、うち8割が浅いタスクだとする。
| 構成 | 内訳 | 相対コスト |
|---|---|---|
| すべて上位モデル | 100万回 × 上位単価 | 100 |
| 8割を軽量に移行 | 80万回×軽量 + 20万回×上位 | 約23 |
| さらにキャッシュ・出力短縮 | 上記 + 入力削減 | 約15 |
ミドリ(surprised)： 100が15になるんですか。
タツヤ： 階層差が桁で効くから、こういう変化になる。もちろん実際の比率は業務次第だから、この表はあくまで構造を示すものとして使ってほしい。大事なのは金額そのものより、「浅いタスクの比率」が削減幅を決めるという関係を示すことなんだ。
ミドリ： じゃあ、まず自社の浅いタスク比率を測るところからですね。
タツヤ(nodding)： そこが出発点。測らずに階層化しても、どれだけ効いたか説明できないからね。
よくある失敗
ミドリ： やりがちなミスも教えてください。
タツヤ： 4つ挙げるね。
- 一斉に軽量モデルへ切り替える — 品質低下がまとめて出て、原因の切り分けができなくなる。1機能ずつ
- 評価せずに新モデルへ飛びつく — ベンチマークの点数と自社業務の相性は別物
- キャッシュ前提の設計を後回しにする — 変動部分を先頭に置いてしまうとキャッシュが効かない
- 費用をモデル別に分解していない — 総額しか見ていないと、どこが高いか永遠にわからない
ミドリ(thinking)： 最後のやつ、うちも総額しか見てないです。
タツヤ： まずはそこからだね。機能別・モデル別に費用が見えるようにするのが、階層化の前提になる。
まとめ
タツヤ： 今日の要点を整理しよう。
- 2026年は主要ベンダーが上位・中位・軽量の3階層を揃えた。GPT-5.6のSol/Terra/Lunaが典型例
- 階層間の価格差は倍ではなく桁。上位と軽量で出力単価が25倍違う例もある
- 割り当ては「推論の深さ × 誤りコスト × 呼び出し量」で決める。呼び出しの7〜8割は浅いタスク
- 判断が分かれるタスクはエスカレーション設計。上位に上がる率が2〜3割以内なら得
- 出力単価は入力の5〜6倍。「短く答えさせる」だけで効く
- モデル名を1か所に集約し、評価セットを20〜30件持つ。乗り換え判断が30分で終わる
ミドリ(smiling)： 「いちばん賢いモデルを指定しておけば安心」から卒業ですね。
タツヤ： そう。賢いモデルを使うことより、賢く割り当てることのほうが難しくて価値がある。しかもこれは1回設計すれば、モデルが変わっても考え方は残るからね。
次のアクション
ミドリ： 何から手を付けましょう。
タツヤ： 3ステップで進めてほしい。
- 直近1か月のAPI費用を、機能別に分解する — どの機能が総額の何%かを出す。ここが見えないと最適化の順番が決まらない
- 上位1〜2機能について、割り当て表を作る — 「推論の深さ・誤りコスト・呼び出し量」の3軸で採点し、軽量に落とせる処理を特定する
- 評価用の入力セットを20件作る — 実際の業務データから代表例を選ぶ。以後すべての比較がこれで済む
タツヤ： Shimanto AI Solutionsでは、この設計と移行を支援しているよ。
- API費用の可視化と分解 — 機能別・モデル別のコスト計測を仕込み、削減余地を数字で示す
- 階層割り当てとエスカレーション設計 — 業務ごとの誤りコストを一緒に評価し、安全に落とせる範囲を決める
- 評価セット構築と乗り換え判断の仕組み化 — 新モデル登場時に即日で比較できる体制を整える
ミドリ： 費用が見えるようにするところからですね。
タツヤ： それが最初の一歩。測れないものは減らせないからね。
参考にした情報
本文の単価は執筆時点(2026年8月)に公表されていた値です。API価格は改定が頻繁なため、見積もりには必ず各社の公式料金ページをご確認ください。
- GPT-5.6 benchmarks across Intelligence, Speed and Cost — Artificial Analysis(Sol/Terra/Lunaの性能・価格比較)
- OpenAI 公式 / Anthropic 公式 / Google AI for Developers — 各社の最新料金は公式ページが一次情報