AI APIの契約ルートを日本で選ぶ｜公式直販・リセラー・クラウド経由の比較

AI APIの契約ルートは、日本では公式直販・リセラー・クラウド経由の3つに分けて考えると整理しやすくなります。起点になるのは、請求書を出す主体が誰かという一点です。同じモデルを使っていても、契約先がモデルの提供元そのものか、MixRouteのような再販チャネルか、Azure OpenAIやAmazon Bedrockのようなクラウド経由かで、支払い方法、モデルへの入口、障害時の連絡先、やめる条件はそれぞれ別になります。請求書の発行元が調達条件になっている場合は、このルートを先に絞ると比較が進みます。

見るべき項目は、請求主体、支払い方法、モデルへの入口、サポート責任、退出条件の5つです。この5項目で3ルートを並べると、自社が使う1ルートと、契約前に経理と開発が確認すべき項目が決まります。

AI APIの購入ルートは、日本では3つに分けて考えられます

購入ルートは、請求書を出す主体が誰かで3つに分かれます。モデルの提供元から直接契約する公式直販、上流の供給契約を持つ事業者から買うリセラー、クラウド事業者の契約に載せるクラウド経由です。同じモデルを使っていても、契約の窓口、支払いの条件、障害時の連絡先は別のものになります。

3類型は、まず請求書を出す主体で分けます

公式直販では、契約書も請求書もモデルの提供元から届きます。リセラーでは、請求書を出すのは提供元ではなく再販する事業者です。MixRouteは上流サプライヤーとの契約を使ってAI推論を再販するチャネルで、利用者にプラットフォーム手数料を上乗せしません。支払う相手と問い合わせる相手が提供元と別になるのはこのためです。

クラウド経由は、契約も請求もクラウド事業者と結びます。モデルはクラウドの認証と権限管理の中に入り、既存のクラウド契約に請求が合流します。情報システム部門がすでにそのクラウドを統制している企業なら、新しい契約先を増やさずに済む点が効きます。

ルートを選ぶ前に、社内で誰がこの契約を承認するのかを確認しておくと、比較の順番が決まります。

• クラウドの契約を情報システム部門がまとめているなら、請求をそこへ合流させる案が通りやすい。
• 開発チームが単独で検証を始めたいなら、カードで始められるセルフサーブが最短。

請求主体が変わると、見積書の宛名から支払いサイトまで別の書式になります。後から経理に説明する前提で候補を絞るほうが、手戻りは少なくなります。

同じモデルでも、契約の窓口が変われば条件が変わります

購入前に何を比べるかは、モデルの選定軸と購入ルートの2段階に分けると整理できます。モデルは性能、コンテキスト長、日本語精度、連携性の4つで比べ、そこに「誰と契約し、誰に問い合わせるか」を足します。

契約の窓口が変われば、契約書の宛先、支払いサイト、障害時の一次切り分け、退会時のデータの扱いが変わります。ここを曖昧にしたままモデルだけを選ぶと、稟議の後半で経理や法務から差し戻されます。

銀行振込や請求書払いを使えるかは、ルートと契約形態で変わります

カードで始めるセルフサーブと、銀行振込や請求書で進む企業契約は、同じサービスでも別の入口です。MixRouteは料金ページでチャージの金額帯と支払い方法を案内しており、表示は米ドルです。経理が銀行振込を必須にしているなら、まずこの列で候補を絞ります。

セルフサーブと企業契約では、支払いの入口が違います

MixRouteの支払い手段は、セルフサーブではVisa、Mastercard、JCBとUSDT、USDC、企業では銀行振込、請求書、柔軟な支払期日が案内されています。銀行振込や請求書払いを必要とする企業は、相談の前に可否を把握できます。カードが使えるかどうかで候補が変わる場合は、この行を最初に確認します。

経理に出す確認項目は、支払い方法のほかにもあります。請求書の宛名、支払期日、表示通貨、税務書類の種類の4つです。通貨が米ドルで固定されているなら、社内の見積書に円換算を併記する運用を先に決めておきます。この4項目が埋まらないルートは稟議の途中で止まりやすいので、比較の早い段階で候補から外す判断も必要です。

チャージの金額帯によって、付くボーナスクレジットが変わります。料金ページでは次のように案内されています。

• $10から$999はボーナスクレジットなし
• $1,000から$4,999は2%（上限$100）
• $5,000から$14,999は3%（上限$450）
• $15,000から$29,999は5%（上限$1,500）
• $30,000以上はEnterprise向けのカスタム

これはチャージ額に応じた単発の金額帯であり、月額サブスクリプションではありません。クレジットは有効期限がないと案内されているため、残高を今月で使い切る前提で契約を選ぶ必要はありません。ボーナスクレジットには上限があり、金額帯が上がるほど率も上がります。単発のチャージで始めるのか、企業契約として継続するのかを先に決めておくと、見積もりの前提が経理と揃います。

表示通貨と請求書の扱いは、契約前に確認します

MixRouteの料金ページは表示通貨をすべて米ドルに統一しており、現行の範囲では現地通貨への換算や地方税の計算を行いません。円建ての請求額は自社で為替レートを当てはめて見積もることになるため、為替が動けば費用も動きます。

日本向けの請求書の発行主体、税務書類、支払い条件は、所在地とプランを添えて相談窓口へ確認してください。適格請求書が必要な場合は、契約前に発行可否を確認します。

銀行振込や請求書払いを前提にしているなら、自社の支払い方法で使えるチャージの金額帯を確認するところから始めます。ここで候補は1つか2つに絞れます。

モデルへの入口は、ルートによってどう変わりますか

直販はプロバイダーのAPIを直接呼びます。リセラーやゲートウェイでは、1つのエンドポイントから複数モデルを選ぶ形になり、キー単位の制御や容量確保の考え方が変わります。呼び出し方が変われば、契約後に誰が何を管理するかも変わります。

直販はプロバイダーのAPIをそのまま呼びます

公式直販では、アプリはプロバイダーのSDKとエンドポイントを直接呼びます。モデルの追加や廃止の告知が一次情報として届き、API仕様も提供元のドキュメントがそのまま当てはまります。提供元を変えるときは、認証方法やAPI仕様の違いに応じて実装を調整します。

クラウド経由では、そのクラウドの認証と権限の仕組みを通してモデルを呼びます。モデルごとに対応するAPI、エンドポイント、利用可能リージョン、モダリティが異なるため、選定では能力だけでなく、自社が使うリージョンとAPIに適合するかを確認します。

呼び出し方の違いは、実装の書き換え量にも現れます。直販ではSDKの更新を自社で追随します。まとめる窓口を通す場合は、アプリ側の接続先を1つのままにして、モデルの切り替えを窓口側の設定で行えます。そのぶん、どのキーがどのモデルを呼べるかを窓口側で設計する責任は自社に残ります。

まとめる窓口では、キー単位の制御を設計できます

リセラーやゲートウェイでは、1つの窓口から複数モデルを選べます。MixRouteでは、キーごとに次の4つを設定できます。

• 呼び出せるモデルの許可リスト
• 前もって配分して使い切るまで差し引かれる支出予算。金額であり、月次の上限やレート制限ではありません。
• IP許可リスト（CIDR対応）
• 有効期限（-1で無期限）

キーに予算を付けなければ、上限はアカウント残高の1層だけになります。

IP許可リストだけで守れる範囲は限られます。MixRouteのコンソールは、IPは偽装され得るため、これだけに頼らずnginxやCDNと併用するよう案内しています。契約後に誰がどの範囲で使えるかを設計するときは、この前提で組み立ててください。

大量のリクエストを安定して流したい場合は、従量課金とは別に容量を事前確保する契約を検討します。MixRouteは容量の事前確保を provisioned throughput の事前購入として案内しています。対象モデルと提供条件は個別の確認が必要なので、必要なスループットと利用期間を整理したうえで、容量確保の対象と条件を相談するのが次の一歩です。

障害時と契約時に、サポート責任を負うのは誰ですか

請求主体とサポート主体は一致するとは限りません。リセラーの請求書には再販事業者の名前が載り、モデル自体の品質や可用性は上流の提供元が握っています。問い合わせが来たときに、誰が一次切り分けをして、どこへエスカレーションするのかを契約条件として決めておきます。

一次切り分けの窓口を契約前に決めます

サポートの厚さは契約の大きさで変わります。たとえばOpenAIの日本語公式ページでは、企業向けの機能として、顧客データを学習に使用しない方針、ゼロデータ保持、SSOと多要素認証、IP許可リスト、専任アカウントチームと優先サポートが案内されています。これはOpenAI自身の記載なので、他の提供元やリセラーが同じ条件を出す前提にはできません。

実際に連絡する窓口の名前は、表のサポート責任の列に入れておくと、障害時に誰へ連絡するかで迷いません。開発者向けの窓口と経理向けの窓口が分かれる場合もあるので、障害時の連絡先と請求に関する質問の宛先は別々に整理しておきます。

サポート範囲と請求主体がまたがる質問は、契約前に所在地とプランを添えて支援範囲と契約条件を確認するのが確実です。

契約の出口では、何を確認すればよいですか

出口条件は、契約をやめたあとに何が残るかで決まります。データの保存、削除、アクセス権、ログの扱い、使わなかったクレジット、キーの失効を、契約前に並べて確認します。

データとログの扱いを出口条件として確認します

契約前に見ておきたいのは、入力してよい情報、データの保存、削除、アクセス権、ログに残す情報です。契約と運用の両面から確認します。ただしこれは特定のAPIに共通する必須要件ではないので、自社が扱うデータの種類に合わせて取捨選択します。

ログの扱いは「残さない」か「残る」かの二択ではありません。入力の保存、出力の保存、監査用のアクセス記録は別々に決まるので、項目を分けて質問します。

退出条件は、契約書に書かれた手順と、データが実際に消えるまでの時間の両方で確認します。検索用に取り込んだ社内文書や、監査用に残したアクセス記録は、入力の保存とは別の質問として切り出すと、回答が曖昧なまま残りません。確認した内容は、表の「退出条件」の行に自社の言葉で整理しておきます。

残高とキーの失効を確認します

MixRouteのクレジットは有効期限がないと案内されているため、残高を急いで使い切る必要はありません。一方で、契約終了時のキーの失効、残高の扱い、データ削除の依頼先は契約書側の条件です。開発側では、キーの棚卸しと失効手順を先に決めておくと、退会時に慌てません。

契約後の監視も比較対象に入れます。運用項目としては、コストアラートと品質モニタリングが挙げられます。従量課金では、バグや想定外の消費で請求が跳ね上がるリスクがあるためです。利用量の上限や通知をどの層で設定できるか、通知が誰に届くかも、契約前の確認項目です。

自社に合うルートは、判断表でどう決めますか

請求主体、支払い方法、モデルへの入口、サポート責任、退出条件の5項目で並べると、経理と開発が同じ表で合意できます。まず3つのルートを、この5つの確認項目で書き出します。

自社の条件を表に当てはめます

自社の条件を先に言葉にすると、ルートは自然に絞れます。銀行振込が必須なら支払い方法の列で候補を落とし、既存のクラウド統制にまとめたいならクラウド経由、複数モデルを1つの窓口で切り替えたいならリセラーが候補になります。

推論価格、チャージ手数料、BYOKを分けて見ます

比較のときは、推論の単価とチャージ手数料を分けます。MixRouteのプラットフォーム手数料は0%です。ほかのサービスを比較する場合も、同じ額を支払ったときに利用できるクレジットと、モデルごとの消費単価を確認してください。

自社で取得した提供元のキーを持ち込むBYOKでは、提供元への支払いに加えて経由サービス側の料金条件を確認します。無料枠の単位や適用プランも比較項目です。MixRouteでBYOKが必要な場合は、対応可否と料金を契約前に相談窓口へ確認してください。

候補を並べるときは、同じプロンプトと同じ入力を使い、正答率だけでなく、根拠の提示、指定形式への適合、処理時間、1件あたりの費用を分けて記録します。無料枠の結果と本番の負荷は一致しないので、無料枠は検証の入口として使い、契約の判断は自社データで行います。モデルを切り替えたときの品質の変化と再試行の増加も同じ表に書き足しておくと、運用開始後の見直しが楽になります。

ルートを1つに絞ったら、契約形態の解像度を上げます。リセラーとゲートウェイの違い、自社で運用する場合との責任分担は、ゲートウェイとアグリゲーターの違いを整理するページで確認できます。表の5つの確認項目に自社の答えを書き込み、経理と開発で同じ表を見ながら決めてください。