AIモデルを1社に固定しない設計｜値下げ競争を費用削減に変えるBYOM・ゲートウェイの考え方(2026年9月)

同じ日の値下げが示したこと

2026-09-22(米国時間)、AnthropicはClaude Opus 5.5を入力4ドル・出力20ドル(Opus 5から20%減)で出しました。約1時間後、OpenAIはGPT-6 Solを2ドル・10ドル、GPT-6 Lunaを0.10ドル・0.50ドルで出しています(100万トークンあたり、発表時点 2026-09)。各モデルの価格と位置づけは親記事にまとめました。ここで見たいのは個々の価格ではなく、単価の動き方です。

1つ目。単価は大きく、しかも各社の都合で動きます。発表前、Opus 5とGPT-5.6 Solの入力単価は5ドル対4ドルでした。発表後はOpus 5.5とSolで4ドル対2ドルです。どちらが安いかは、次の発表でまた入れ替わりえます。

2つ目。値下げは新モデルの価格として出ます。どちらの発表も旧モデルの単価を下げるとは書いていません。恩恵を受けるには、モデルID(呼び出すモデルの名前)を書き換えて動作を確かめる必要があります。切り替えの手間が大きい作りほど、値下げは請求書に届きません。

3つ目。下がった価格が続く保証はありません。OpenAIはSol/Lunaの価格を「GPT-5.6のプロモーション価格と比べて50%引き」と表現しており、恒久価格かどうかは発表に書かれていません。上がる方向にも動きうるということです。

とはいえ、1社固定がいつも損なわけではありません。今回もAnthropicだけを使っている会社はOpus 5.5へ、OpenAIだけの会社はSolへ切り替えれば単価は下がります。困るのは、他社のほうが安く、自社の業務でも十分な精度が出るとわかったのに、切り替えに数か月の改修が要る作りです。

仕様の出典: Anthropic「Introducing Claude Opus 5.5」 / OpenAI「Introducing GPT-6 Sol and Luna」 / Simon Willison「Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna, and a new price war」

用途ごとにモデルの層を分ける

マルチモデルというと、複数社のモデルを常に並べて使う姿を想像しがちです。発注側にとって効くのはもっと地味なことで、処理ごとに必要な賢さを決め、足りる範囲で安いモデルを当てることです。層は4つに分けると考えやすくなります。

Opus 5.5は、Anthropicが「多くの作業でFable 5.1と同等」と公称しているモデルで、中位と上位の境目にあります。どのモデルをどの層に置くかは、ここでは決めません。性能の数字はいずれもベンダー公称で、各社が自社に有利な条件を選んで出しています。表は2026-09時点の価格で並べた目安にすぎず、割り当ては自社の業務データで試してから決めます。

計算例: 全件を同じモデルで処理した場合と、分けた場合

前提は次のとおりです。月1万件の問い合わせ分類(1件あたり入力2,000トークン・出力200トークン)と、月1,000件の文書作成(1件あたり入力5,000トークン・出力1,000トークン)を処理します。単価は2026-09時点の公式価格で、キャッシュは考えません。

1ドル150円と置けば、160ドルは2万4,000円、43ドルは6,450円です(為替で動きます)。この規模なら差は月1万7,000円ほどです。ただ、件数が10倍、100倍になれば差も同じ倍率で開きます。分ける価値がはっきり出るのは、件数の多い処理に高いモデルを当てているときです。

AIゲートウェイは何をするものか

層を分けると、呼び出すモデルが複数になります。そこで間に置くのがAIゲートウェイです。アプリとモデルの間に立つ中継役で、アプリはゲートウェイだけを呼び、どのモデルに渡すかはゲートウェイ側の設定で決めます。役割は大きく4つです。

• モデルの切り替え: 呼び先を設定で差し替える。アプリのコードを直さずに、新モデルへの移行や他社モデルとの比較ができる
• 費用の集計: どの処理・どのモデルで何トークン使ったかを1か所で見る。モデルを分けるほど請求が複数社に散らばるので、ここが効いてくる
• レートの管理: 呼び出し回数の上限と、上限に当たったときの扱いを決める
• ログ: 入力と出力を記録し、モデルを替えた前後で出力がどう変わったかを後から確かめられるようにする

選択肢には、Cloudflare AI GatewayやVercel AI Gatewayのような専用のゲートウェイ製品のほか、Amazon BedrockやMicrosoft Azureのように、クラウド事業者が複数社のモデルを自社の契約の中で提供する形もあります。今回の発表でも、Opus 5.5とSol/LunaはどちらもAmazon Bedrockで提供されています。製品ごとの機能や料金はこの記事では比べません。Cloudflare AI Gatewayを例にした使い方は、Cloudflare AI GatewayとBYOMの記事にあります。

BYOM(Bring Your Own Model)は、ツールやアプリの側がモデルを抱え込まず、使うモデルを利用者が選んで持ち込める設計のことです。ゲートウェイはその持ち込み口にあたります。

固定しないことにも費用がかかる

マルチモデルはただではありません。発注時に見落とされやすい費用が3つあります。

評価の費用

モデルを替えるたびに、出力が業務に耐えるかを確かめます。過去の問い合わせや文書を数十件から数百件集めた評価用データを作り、流して、結果を見比べる手間がかかります。評価用データは一度作れば使い回せるので、2回目からは軽くなります。

プロンプトの二重管理

同じ指示文(プロンプト)でも、モデルによって解釈や出力の形が変わります。モデルごとに指示文を調整すると、業務ルールが変わるたびに複数の版を直すことになります。層を細かく分けすぎると、この管理が膨らみます。

品質のばらつき

同じ種類の処理を複数のモデルに振り分けると、文体や出力の長さが揃わないことがあります。顧客に直接見せる文章では、これが問題になります。OpenAIはGPT-6 Sol/Lunaについて、専門用語が少なくやや短い回答になると説明しています。モデルが替われば口調も変わる、という前提で見ておきます。

これらを足すと、処理の本数も件数も少ないうちは、1社のモデルで揃えたほうが安く済む場合があります。固定しない設計の目的は、常に複数社を使うことではありません。替えたいときに替えられる状態を、安く保っておくことです。

小さい会社はどこまでやれば足りるか

AIを使う処理がまだ数本という段階なら、次の2つだけで十分です。

モデル名をコードに直書きしない

claude-opus-5-5やgpt-6-solといったモデルIDを、プログラムのあちこちに書かないことです。設定ファイルなど1か所にだけ書いておけば、切り替えは設定の変更と動作確認で済みます。直書きが散らばっていると、切り替えのたびに改修の見積もりが要ります。

呼び出しを1か所に集める

モデルを呼ぶ処理を共通の部品にまとめ、各機能はそこを通すようにします。ログの記録やトークン数の集計もこの部品に入れておけば、ゲートウェイ製品を入れる前から、どこで何トークン使っているかがわかります。後からゲートウェイ製品に移るときも、差し替える場所はここだけです。

ゲートウェイ製品の導入、処理ごとの自動振り分け、複数社の常時併用は、AIの利用料が月の費用の中で無視できなくなってから、あるいは処理の本数が増えてから考えれば間に合います。逆に上の2つは、作った後に直すと改修費がかかります。作る前に決めておく価値があるのはこちらです。

発注先に求める設計条件

見積もりや要件定義の段階で、次の点を発注先に確認しておくと、次の値下げのときに動けます。

• モデルIDは設定で変えられるか。コードの改修が要るなら、その理由
• モデルの呼び出しは共通の部品にまとまっているか
• 処理ごとの入力・出力トークン数を記録し、月次で見られるか
• モデルを切り替えるときの検証手順と、評価用データを誰が用意するか
• モデル変更は保守契約の範囲か別料金か。単価の改定を見積もりにどう反映するか
• 他社のモデルに替える場合、作り直しになる部分はどこか

全部に「できる」と返ってくる必要はありません。できない項目があれば、理由と、後から対応する場合の工数を聞いておけば判断できます。乗り換えるかどうかの判断と検証の進め方は、運用中のAIシステムのモデルを乗り換えるべきかの記事で扱っています。

日本の会社で使う場合

今回のモデルはいずれも日本から使えます。どちらの発表にも地域制限の記載はなく、API、ChatGPTの有料プラン、Claudeの有料プランで利用できます(2026-09-24時点。順次配信中のものは画面に出るまで待ちます)。

データを国内に置きたい会社は、どの経路で呼ぶかが設計に関わります。Opus 5.5はAmazon Bedrockの日本向け地理的エンドポイント(JP Geo)で提供されており、Google CloudとMicrosoft Azureでも使えます。Sol/LunaもAmazon Bedrockで一般提供されていますが、対応リージョンは発表に書かれていないので、Bedrockのドキュメントで確認します。ゲートウェイやクラウドを挟む場合、データがどこを通りどこに残るかは、モデルごと・経路ごとに確かめる必要があります。

価格はすべてドル建てで、円での請求額は為替で動きます。予算資料にはドル建ての単価と、換算に使ったレートと日付を並べて書いておくと、単価が次に動いたときに引き直しやすくなります。

仕様の出典: AWS「Claude Opus 5.5 is now available on AWS」 / AWS「GPT-6 Sol and GPT-6 Luna on Amazon Bedrock」

出典

• Anthropic「Introducing Claude Opus 5.5」(2026-09-22): https://www.anthropic.com/claude-opus-5-5
• OpenAI「Introducing GPT-6 Sol and Luna」(2026-09-22): https://openai.com/index/introducing-gpt-6-sol-and-luna
• AWS Machine Learning Blog「Claude Opus 5.5 is now available on AWS」(2026-09-22): https://aws.amazon.com/blogs/machine-learning/claude-opus-5-5-is-now-available-on-aws/
• AWS Machine Learning Blog「Bring more intelligence to everyday work with GPT-6 Sol and GPT-6 Luna on Amazon Bedrock」(2026-09-22): https://aws.amazon.com/blogs/machine-learning/bring-more-intelligence-to-everyday-work-with-gpt-6-sol-and-gpt-6-luna-on-amazon-bedrock/
• Simon Willison「Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna, and a new price war」(2026-09-22): https://simonwillison.net/2026/Sep/22/opus-and-sol-and-luna/
• TypeSafe AI「Introducing System One Models & Jev」: https://typesafe.ai/blog/introducing-system-one-models-and-jev

よくあるご質問

マルチモデルとBYOMは同じ意味ですか?

近い考え方ですが、見ている場所が違います。マルチモデルは用途ごとに複数のモデルを使い分けること、BYOMはツールやアプリがモデルを抱え込まず、利用者が選んだモデルを持ち込める設計のことです。BYOMの作りになっていると、マルチモデルにしやすくなります。

AIゲートウェイを入れないと、モデルの切り替えはできませんか?

できます。モデル名を設定で持ち、呼び出しを共通の部品にまとめておけば、ゲートウェイ製品がなくても設定の変更と動作確認で切り替えられます。ゲートウェイは、モデルや処理が増えたときに費用の集計やログを1か所にまとめるための道具です。

ベンダーロックインを避けるために、最初から2社と契約すべきですか?

必須ではありません。1社で始めても、モデル名を直書きせず呼び出しを1か所に集めておけば、他社に替えるときの作業は限られます。2社目は、他社のモデルで自社の業務を試し、精度と費用の両方で上回るとわかった時点で足せば足ります。

今回の値下げを受けて、すぐにモデルを分けるべきですか?

件数の多い処理に高いモデルを使っているなら、小型モデルで試す価値があります(2026-09時点でGPT-6 Lunaは100万トークンあたり入力0.10ドル・出力0.50ドル)。件数が少なければ月額の差は小さいので、次の改修のときにモデル名の直書きをなくしておく程度で十分です。