「半額のモデル」に乗り換える前に ― AIリクエストの54%は過剰性能、それでも切り替えは『品質の変更』として審査すべき理由
カテゴリに戻る
AI導入戦略 / ROI・投資判断2026.10.289分

「半額のモデル」に乗り換える前に ― AIリクエストの54%は過剰性能、それでも切り替えは『品質の変更』として審査すべき理由

「同じ仕事を、半額のモデルでできるなら替えればいい」。AIの利用料が予算を圧迫し始めた企業で、この判断はごく自然に下される。しかも多くの場合、それは稟議ではなく、運用側の設定変更として処理される。

2026年10月26日、OpenAIは新モデル「GPT-6.1 Terra」を公開した。標準のAPI価格は同社の上位2モデルの半額で、請求書を読んで会計ソフトに入力するような、大量の定型業務に向くとうたう。翌27日には、Salesforceが「Agent Fabric」に本番環境での品質評価と、予算超過を止めるコスト管理を追加し、IBMも同じ日に、エージェントの評価とコスト追跡を一体にした機能を一般提供した。

安いモデルが出た週に、大手が揃って「品質を測る仕組み」を売り出した。これは偶然ではない。本稿では、モデルの乗り換えがなぜ本番の品質事故の入り口になりやすいのか、そして日本の大企業が乗り換えの前に何を決めておくべきかを考える。

10月26〜27日、同じ週に出た3つの発表

10月26〜27日、同じ週に出た3つの発表。OpenAIは10月26日にGPT-6.1 Terraを公開し、API標準価格は上位2モデルの半額で、請求書処理など大量の定型業務向け。Salesforceは10月27日にAgent Fabricを拡張し、Agent Evalsで本番の品質しきい値を常時評価し、Model Walletで予算超過前にリクエストを止める。IBMは10月27日にwatsonx OrchestrateのEvaluateを一般提供し、導入前テストと本番監視、モデル・トークン利用のコスト追跡を内蔵した。Salesforceの事例では、安いモデルへ移した注文対応エージェントが配送遅延について不正確な案内をし、評価で検知して隔離・修正して復帰した

10月26〜27日、同じ週に出た3つの発表。OpenAIは10月26日にGPT-6.1 Terraを公開し、API標準価格は上位2モデルの半額で、請求書処理など大量の定型業務向け。Salesforceは10月27日にAgent Fabricを拡張し、Agent Evalsで本番の品質しきい値を常時評価し、Model Walletで予算超過前にリクエストを止める。IBMは10月27日にwatsonx OrchestrateのEvaluateを一般提供し、導入前テストと本番監視、モデル・トークン利用のコスト追跡を内蔵した。Salesforceの事例では、安いモデルへ移した注文対応エージェントが配送遅延について不正確な案内をし、評価で検知して隔離・修正して復帰した

OpenAIのGPT-6.1 Terra(10月26日)は、文書作成、図面の読み取り、フォーム入力、画面操作といった日常業務向けのモデルだ。同社は「コストと知能のバランスの最前線を押し広げる」と説明している。Microsoft Foundryでも同日に一般提供され、価格は100万トークンあたり入力1ドル、出力5ドル(短いコンテキストの標準デプロイ)とされた。7月にも同社は既存モデルを最大80%値下げしており、モデルの単価は数ヶ月ごとに下がり続けている。

Salesforceは10月27日、複数のプラットフォームにまたがるエージェントを管理する「Agent Fabric」に、次のような機能を加えた。

  • Agent Evals:導入前にテストを自動生成し、本番でもエージェント・モデル・MCPサーバーを品質のしきい値に照らして評価し続ける。下回れば、事前に決めた対応(エージェントの停止を含む)を、必要なら人の承認を経て実行する(2026年11月ベータ、2027年1月一般提供)
  • FinOpsダッシュボードとModel Wallet:予算の責任者がAI支出を一画面で見て、予算を超える前にリクエストを止める上限を設定できる(提供中)
  • コスト最適化ポリシー:応答のキャッシュや圧縮で、トークン使用量を最大75%削減できるとする(同社のテストシナリオに基づく値)

同じ発表の中で、Salesforceは象徴的な事例を紹介している。ある小売企業が、注文対応のエージェントをより安いモデルに移したところ、配送が遅れている注文について不正確な案内をするようになった。本番での評価がこれを検知し、人の承認を経てエージェントを隔離。チームが指示を修正し、評価をやり直してから本番に戻したという。

IBMも10月27日、エージェント基盤「watsonx Orchestrate」の評価機能を一般提供した。導入前にエージェント・モデル・MCPサーバーの品質や正確性を検査し、本番でも監視を続け、モデルとトークンの利用コストの追跡も組み込んでいる。

3社の発表を並べると、構図が見えてくる。「安くする手段」と「品質を測る手段」が、同じ製品の中でセットになり始めたのだ。安くすれば品質が動く。その前提が、製品設計の段階で織り込まれている。

モデルを下げる圧力は、数字の上では正しい

モデルを下げる圧力は数字の上では正しい。アクセンチュアの2026年7月調査(17カ国、年商10億ドル超の経営層750名)では、必要以上に高性能なモデルへ送られたリクエストは54%、最先端級モデルが本当に必要な業務タスクは約1割、年間トークン予算を超過したのは3社に1社。一方で、モデルの振り分けを導入済みは30%、トークン監視ツール導入済みは37%、最重要用途の成果対コストを算出できるのは35%、統制責任がIT部門と事業部門に分散しているのは48%。最適化すれば2年間のトークン費の伸びを最大44%抑制できる可能性がある

モデルを下げる圧力は数字の上では正しい。アクセンチュアの2026年7月調査(17カ国、年商10億ドル超の経営層750名)では、必要以上に高性能なモデルへ送られたリクエストは54%、最先端級モデルが本当に必要な業務タスクは約1割、年間トークン予算を超過したのは3社に1社。一方で、モデルの振り分けを導入済みは30%、トークン監視ツール導入済みは37%、最重要用途の成果対コストを算出できるのは35%、統制責任がIT部門と事業部門に分散しているのは48%。最適化すれば2年間のトークン費の伸びを最大44%抑制できる可能性がある

誤解のないように言えば、安いモデルへの切り替えそのものは、正しい方向だ。

アクセンチュアが9月17日に公表した「The CIO's Guide to AI Tokenomics」は、日本を含む17カ国・地域で、年商10億ドル超の企業の経営層750名を対象に2026年7月に行った調査だ。それによると、AIへのリクエストの54%が、その仕事に必要以上に高性能なモデルへ送られていた。同社が米国の職業データベースにある9,368の業務タスクを分析したところ、最先端級のモデルが本当に必要なのは全体の約1割だったという。

一方で、3社に1社が年間のトークン予算を超過し、今後2年でトークン支出が増えると見る企業は78%にのぼる。にもかかわらず、トークン支出のうち事業成果との関係を証明できているのは2割未満、最も重要なAI用途について成果に対するコストを算出できる企業は35%にとどまる。

つまり多くの企業は、高いモデルを必要以上に使い、その効果を説明できていない。アクセンチュアは、使い方・モデルの割り当て・統制を最適化すれば、2年間のトークン費の伸びを最大44%抑えられる可能性があると試算している。

ただし同じ調査は、そのための仕組みがまだ乏しいことも示している。業務の難しさに応じてモデルを振り分ける仕組みを導入済みの企業は30%、トークンの監視ツールを導入済みは37%。そしてAIの統制責任がIT部門と事業部門に分散している企業が48%ある。下げる圧力は強いのに、下げても大丈夫かを確かめる仕組みと、判断する人が決まっていない。ここに事故の入り口がある。

安いモデルへの乗り換えが「静かに」壊れる3つの理由

安いモデルへの乗り換えが静かに壊れる3つの理由。1 劣化はエラーにならない:安いモデルももっともらしい文章で答え、応答時間は縮みエラー率も変わらず、間違いに気づくのは顧客のほうが先になる。2 合否の物差しがPoC時点で止まっている:差が出るのは例外処理や難しい案件だが、PoCのテストセットには入っておらず、本番の実トラフィックで評価している組織は本番運用中でも44.8%。3 切り替えを決める人と品質の責任者が違う:費用を見るのはIT・FinOps、品質の結果を受けるのは業務部門で、変更は運用側の設定変更として処理されやすい。コストの削減額は翌月の請求書に出るが、品質の劣化はどこにも出ない

安いモデルへの乗り換えが静かに壊れる3つの理由。1 劣化はエラーにならない:安いモデルももっともらしい文章で答え、応答時間は縮みエラー率も変わらず、間違いに気づくのは顧客のほうが先になる。2 合否の物差しがPoC時点で止まっている:差が出るのは例外処理や難しい案件だが、PoCのテストセットには入っておらず、本番の実トラフィックで評価している組織は本番運用中でも44.8%。3 切り替えを決める人と品質の責任者が違う:費用を見るのはIT・FinOps、品質の結果を受けるのは業務部門で、変更は運用側の設定変更として処理されやすい。コストの削減額は翌月の請求書に出るが、品質の劣化はどこにも出ない

Salesforceの小売事例は、特別な失敗ではない。モデルの乗り換えには、劣化が表に出にくい構造が3つある。

1. 劣化はエラーにならない

安いモデルも、もっともらしい日本語で、自信を持って答える。応答時間はむしろ短くなり、システムのエラー率も変わらない。運用の監視画面はすべて「正常」を示す。配送遅延の案内が間違っていることに最初に気づくのは、多くの場合、案内を受けた顧客だ。コスト削減の効果は翌月の請求書にはっきり出るが、品質の劣化はどの指標にも出てこない。

2. 合否の物差しが、PoCの時点で止まっている

モデルの性能差が出やすいのは、定型的な問い合わせではなく、例外処理や判断の難しい案件だ。配送遅延、返品と交換が重なった注文、規程の解釈が分かれる申請。ところが、PoCで作ったテストセットは「よくある案件」が中心で、こうした例外はほとんど入っていない。乗り換え後に同じテストを流して合格しても、それはよくある案件で差がないことを示すだけだ。

本番の実際の入力で品質を評価し続けている組織は多くない。LangChainが2025年末に行った調査(回答1,340件)では、本番でエージェントを動かしている組織でも、実トラフィックでの評価(オンライン評価)を行っているのは44.8%だった。半数以上は、乗り換えの影響を本番で測る手段を持っていないことになる。

3. 切り替えを決める人と、品質の責任を負う人が違う

利用料の請求書を見るのは、情報システム部門やクラウド費用の管理担当だ。品質が落ちたときに顧客対応や手直しを引き受けるのは、業務部門である。前述の調査で統制責任が分散している企業が48%あったように、コストの判断と品質の判断が別の場所で行われている。

日本企業では、ここに特有の事情が加わる。PoCから本番化への稟議で承認されたのは、多くの場合「このモデルを使ったこのシステム」だ。しかし、運用開始後にモデルを替える行為は、運用保守の委託先による「設定変更」や「バージョン更新」として扱われやすく、業務部門の承認を経ないまま本番の品質が変わる。稟議の時点で合意した品質は、誰も気づかないうちに前提を失う。

これは「4つの壁」でいえば、品質の壁と横展開の壁が交差する場所だ。横展開が進んで利用量が増えるほど、コスト削減の圧力は強まり、乗り換えの頻度も上がる。そのたびに品質を確かめる仕組みがなければ、ROIを示すために下げたコストが、手戻りと顧客対応のコストとして別の場所に移るだけになる。

モデルの乗り換えを「品質の変更」として扱う5つの手順

モデルの乗り換えを品質の変更として扱う5つの手順。1 業務ごとの合格ラインを乗り換えの前に数字で置く:例外・難案件を含む実案件の評価セットで旧モデルの成績を基準値として記録。2 いきなり切り替えず並行稼働で比べる:本番の入力を新旧両方に流して差分を見て、一部の業務から段階的に切り替える。3 しきい値割れで戻す経路を先に作る:切り替え後も実トラフィックで評価を続け、下回れば旧モデルへ戻すか隔離する。4 手戻りまで含めた1件あたり原価で判断する:トークン単価の差ではなく、差し戻し・人の手直し・エスカレーションの増減を足した原価で比べる。5 切り替えの承認者に業務の責任者を入れる:コスト担当の単独判断にせず、委託契約にモデル変更時の再評価と事前通知を書く

モデルの乗り換えを品質の変更として扱う5つの手順。1 業務ごとの合格ラインを乗り換えの前に数字で置く:例外・難案件を含む実案件の評価セットで旧モデルの成績を基準値として記録。2 いきなり切り替えず並行稼働で比べる:本番の入力を新旧両方に流して差分を見て、一部の業務から段階的に切り替える。3 しきい値割れで戻す経路を先に作る:切り替え後も実トラフィックで評価を続け、下回れば旧モデルへ戻すか隔離する。4 手戻りまで含めた1件あたり原価で判断する:トークン単価の差ではなく、差し戻し・人の手直し・エスカレーションの増減を足した原価で比べる。5 切り替えの承認者に業務の責任者を入れる:コスト担当の単独判断にせず、委託契約にモデル変更時の再評価と事前通知を書く

安いモデルを使うこと自体は正しい。問題は、確かめずに替えることだ。モデルの乗り換えを、システムの設定変更ではなく「業務品質の変更」として扱うために、次の5つを決めておきたい。

1. 業務ごとの合格ラインを、乗り換えの前に数字で置く

まず、いまのモデルでの成績を「基準値」として記録する。テストセットは実際の案件から作り、例外処理や判断の難しい案件を意図的に含める。合格ラインは「正答率○%以上」だけでなく、「配送遅延の案内で誤りゼロ」のように、業務上のリスクが大きい項目ごとに置く。この基準値がなければ、乗り換え後に「悪くなったかどうか」を誰も判定できない。

2. いきなり切り替えず、並行稼働で比べる

本番の入力を一定期間、新旧両方のモデルに流し、新しいモデルの出力は顧客に返さずに差分だけを比べる。差が出た案件を業務担当者が確認し、問題がなければ、リスクの低い業務や一部の利用者から段階的に切り替える。全件を一度に替えるのは、PoCを経ずに本番化するのと同じだ。

3. しきい値を割ったら「戻す」経路を、先に作っておく

切り替えた後も、本番の入力で品質を測り続ける。しきい値を下回ったときに、旧モデルへ戻すのか、エージェントを隔離するのか、人の確認を挟むのかを事前に決め、旧モデルの設定はすぐに戻せる状態で残しておく。Salesforceの小売事例でエージェントを素早く隔離できたのは、この対応が事前に決まっていたからだ。

4. 「手戻りまで含めた1件あたり原価」で判断する

乗り換えの効果を、トークン単価の差だけで測らない。新しいモデルで差し戻し率、人の手直しの工数、上位担当者へのエスカレーション件数がどれだけ増えたかを足し込んで、1件あたりの原価を比べる。単価が半分になっても、手直しが倍になれば、業務全体のコストは下がっていない。これが、経営に対して「AIのコストを下げた」と言える唯一の根拠になる。

5. 切り替えの承認者に、業務の責任者を入れる

モデルの変更を、コスト担当や運用保守の委託先が単独で決められる状態にしない。変更管理の承認者に業務部門の責任者を加え、上記1〜4の結果を添えて判断する。外部に運用を委託している場合は、契約に「モデル変更時の再評価と事前通知」を書いておく。ベンダー側が既定のモデルを入れ替えるケースも、同じ手続きに乗せる。

この5つは、特別な製品がなくても始められる。Salesforce・IBMのような統制基盤は、評価の自動化やしきい値割れ時の自動対応を楽にしてくれるが、合格ラインを決め、戻す判断を下し、承認するのは自社だ。そこを決めないまま製品を入れても、「安くなったが、何が変わったかは分からない」状態は変わらない。

まとめ ― モデルの値下げは、評価の仕組みを持つ企業にだけ利益になる

モデルの単価は今後も下がり続け、数ヶ月ごとに「より安く、十分に賢い」モデルが出てくる。アクセンチュアの調査が示すとおり、多くの企業は必要以上に高いモデルを使っており、適切に乗り換えれば大きなコスト削減の余地がある。

日本の大企業にとっての示唆は3つある。

  • 乗り換えは品質の変更である。 設定変更として扱わず、業務の合格ラインに照らして判断する
  • 劣化は待っていても見えない。 本番の入力で品質を測り続け、しきい値を割ったら戻す経路を先に作る
  • コストの判断と品質の判断を、同じ場所に置く。 手戻りまで含めた1件あたり原価で比べ、承認者に業務の責任者を入れる

言い換えれば、モデルの値下げの恩恵を受けられるのは、乗り換えても大丈夫かを素早く確かめられる企業だけだ。評価の仕組みを持たない企業にとって、値下げは「安くなったが怖くて替えられない」か「替えたが何が起きたか分からない」のどちらかになる。

Wizitは、PoCで止まったAIを本番運用とROIまで動かし切る実装パートナーとして、業務ごとの評価設計から、本番での継続的な評価、ROIの可視化までを支援している。新しいモデルが出るたびに「替えるべきか」を数日で判断できる状態をつくることは、本番化した後もAIの成果を伸ばし続けるための土台だと考えている。

---

出典:

  • PYMNTS「OpenAI Unveils Half-Price AI Model to Target Enterprise Automation」(2026年10月26日)
  • Microsoft Foundry Blog「GPT-6.1 Terra now generally available in Microsoft Foundry」(2026年10月26日)
  • Salesforce「Salesforce Expands Agent Fabric to Automatically Stop Runaway Costs and AI Agent Failures Before They Impact Customers」(2026年10月27日)
  • IBM Newsroom「IBM Introduces Identity and Control for AI Agents, Securing Frontier Intelligence for the Enterprise」(2026年10月27日)
  • Accenture「The CIO's Guide to AI Tokenomics」(2026年9月17日公表)/@IT「AI利用とコストの実態、アクセンチュアが調査」(2026年9月26日)
  • LangChain「State of Agent Engineering」(調査期間2025年11月18日〜12月2日、回答1,340件)

AI活用のご相談はWizitへ

「半額のモデル」に乗り換える前に ― AIリクエストの54%は過剰性能、それでも切り替えは『品質の変更』として審査すべき理由 | 株式会社Wizit