LLMをAPIから利用するとき、モデル名だけではサービスの全体像はわかりません。同じClaudeでも、Anthropicの直API、Amazon Bedrock、Vertex AI、Microsoft Foundryなど、複数の経路から提供されています。経路が違えば、推論を実行する事業者、契約、認証、請求、利用できる機能も同じとは限りません。
この記事では、2026年8月22日時点の公式情報をもとに、モデルとAPIの間にどのような提供構造があるのかを説明します。個々のサービスの優劣ではなく、AWS、GCP、Azure、モデル開発元の直API、AI Gatewayなどの関係を理解することが目的です。はじめに一つのAPIサービスを構成する主体を分け、そこから接続経路、実行形態、モデルの違いへ順に視野を広げます。
モデル名だけでは利用条件は決まらない
LLM APIには、少なくとも三つの主体が関わります。
| 主体 | 役割 |
|---|---|
| モデル開発者 | モデルを設計・学習する |
| 推論基盤の運用者 | GPUなどの計算資源を用意し、入力を受けて推論を実行する |
| 契約・接続の提供者 | 認証、APIエンドポイント、利用規約、請求などの窓口を設ける |
一つの事業者が三つすべてを担うこともあれば、別々の事業者が分担することもあります。OpenAI APIのような直APIでは、モデル開発元がAPIの提供者でもあります。一方、クラウドのモデルサービスでは、クラウド事業者が推論基盤や契約窓口を担い、別の会社が開発したモデルを提供する構造があります。
AWSからClaudeを利用する場合にも、Amazon BedrockとClaude Platform on AWSでは構造が異なります。
- Amazon Bedrockでは、AWSが推論基盤を運用します。
- Claude Platform on AWSでは、Anthropicが推論基盤を運用し、AWSのIAMとMarketplace請求を利用します。
どちらもAWSアカウントと結びつきますが、推論運用者、API機能、クォータ、データの扱いは同一ではありません。Claude Platform on AWSの公式比較には、Bedrockとの構造上の違いが整理されています。
この例からわかるのは、「どの会社がモデルを開発したか」「どの基盤で推論するか」「どこから契約するか」が別々の情報だということです。
この三つの主体を区別すると、サービス名だけでは見えにくかった違いを、複数の軸から捉えられるようになります。
LLM APIは三つの軸から整理できる
LLM APIを説明するときには、接続経路、実行形態、モデルの公開形態という異なる種類の情報が使われます。「直API」「自社運用」「オープンウェイト」は、同じ階層に並ぶ選択肢ではありません。
接続・契約経路
接続・契約経路は、アプリケーションがどの窓口を通じて推論APIへ接続するかを表します。
| 接続・契約経路 | 代表例 | 構造 |
|---|---|---|
| 提供事業者の直API | OpenAI、Anthropic、Gemini、Together AIなど | APIを提供する事業者と直接契約し、そのエンドポイントへ接続する |
| クラウドの管理サービス | Bedrock、Vertex AI、Microsoft Foundry | クラウドの認証、ネットワーク、監査、請求とモデルAPIを統合する |
| AI Gateway／仲介サービス | OpenRouter、Vercel AI Gateway、Hugging Face | 共通の窓口から複数のモデルや推論事業者へ接続する |
クラウドの請求を使いながらモデル開発元の基盤へ接続するサービスや、自社で契約したAPIキーをAI Gatewayへ登録するBYOK（Bring Your Own Key）もあります。このため、契約窓口と推論基盤の運用者が常に一致するわけではありません。
実行形態
実行形態は、推論に使う計算資源がどのように割り当てられ、誰が運用するかを表します。
| 実行形態 | 構造 |
|---|---|
| 共有API | 事業者が管理する推論基盤を複数の利用者で共有する |
| 専用エンドポイント | 特定の利用者向けに計算資源や処理容量を割り当てる |
| 自社運用 | 利用者がクラウドや自社設備に推論サーバーを構築して運用する |
一つの推論事業者が、同じモデルを共有APIと専用エンドポイントの両方で提供する場合もあります。
モデルの公開形態
モデルの公開形態は、学習済みの重みが利用者へ公開されているかを表します。
| 公開形態 | 構造 |
|---|---|
| クローズドモデル | 開発元や提携事業者が管理するAPIを通じてモデルを利用する |
| オープンウェイトモデル | 公開された学習済みの重みを複数の事業者や利用者が実行できる |
オープンウェイトモデルは、それ自体が一つの接続経路なのではありません。推論事業者の直API、クラウドのモデルカタログ、AI Gateway、専用エンドポイント、自社運用のいずれにも現れます。同じオープンウェイトモデルが複数の経路から提供されるのは、この三つの軸が独立しているためです。
三つの軸のうち、クラウドの管理サービスは、日本企業で目にすることの多い接続・契約経路の一つです。次に、AWS、GCP、Azureで三つの主体がどのように組み合わされているかを見ていきます。
AWS、GCP、Azureでの提供構造
三大クラウドはいずれも、複数の開発元によるモデルをクラウドの管理機能と組み合わせて提供しています。ここでは、前節の「接続・契約経路」に当たるクラウドの管理サービスを具体的に見ていきます。
| クラウド | モデルサービス | モデル開発元の例 | 関連する提供形態 |
|---|---|---|---|
| AWS | Amazon Bedrock | Amazon、Anthropic、Meta、Mistralなど | Claude Platform on AWS、SageMakerなど |
| GCP | Vertex AI | Google、Anthropic、Mistral、Metaなど | Gemini Developer API、専用エンドポイント |
| Azure | Microsoft Foundry | OpenAI、Anthropic、Mistral、xAIなど | 直API、パートナーごとのホスティング方式 |
表にあるモデル開発元や提供形態は固定ではありません。モデル、リージョン、機能の対応状況は、それぞれのカタログで更新されます。
AWS
Amazon Bedrockは、複数の開発元による基盤モデルをAWSのAPIとして提供するサービスです。IAMによる認証、CloudTrailによる操作記録、KMSによる暗号鍵の管理、PrivateLinkによるプライベート接続など、AWSの管理機能と連携します。提供モデルはBedrockのモデル一覧に掲載されています。
Bedrockには、単一リージョン内で処理する経路のほか、一定の地理範囲や複数地域へ処理を振り分ける推論プロファイルがあります。APIの呼び出し元リージョンと、実際の処理範囲は必ずしも同じ情報ではありません。モデル別のリージョン表には、モデルと推論プロファイルの対応が示されています。
Claude Platform on AWSは、AWSの認証・請求とAnthropicが運用するClaude APIを結びつけます。SageMakerなどへモデルを配置する形では、Bedrockの共有APIとは異なり、計算環境やデプロイ単位が利用者側の構成要素になります。
GCP
Vertex AIのModel Gardenには、GoogleのGemini、パートナー企業のモデル、オープンウェイトモデルが掲載されています。Googleが管理する共有APIとして提供されるモデルと、利用者のプロジェクトにエンドポイントを作成して配置するモデルがあります。
Geminiには、Gemini Developer APIとVertex AI Gemini APIという二つの入口があります。どちらもGoogleのモデルへ接続しますが、認証方法、Google Cloudプロジェクトとの関係、リージョンや管理機能が異なります。共通のGoogle Gen AI SDKから両方を扱えるため、SDKが同じであっても、背後の契約・管理構造まで同じとは限りません。Googleの公式比較に両者の違いがまとめられています。
Azure
Microsoft Foundryは、モデルカタログ、デプロイ、評価、監視などを含むAI開発基盤です。Foundryの概要では、OpenAI、Anthropic、Mistral、xAI、Meta、DeepSeekなど、複数の開発元によるモデルが案内されています。
Foundry上のパートナーモデルは、すべてが同じホスティング方式で動くわけではありません。ClaudeにはAzureが運用する方式と、Anthropicが運用する方式があり、処理基盤、提供地域、利用できるモデルや機能が異なります。Microsoftのホスティング方式比較は、同じカタログ内でも推論運用者を区別する必要があることを示す例です。
このように、クラウドのカタログは一つの窓口を提供しますが、その内側の推論運用者や実行形態まで一様になるわけではありません。同じことは、クラウド以外の接続経路にも当てはまります。
接続経路と実行形態の具体像
クラウドの管理サービスに続き、ここでは直API、AI Gateway、オープンウェイトモデルの推論サービス、専用環境が、接続経路と実行形態の中でどのように位置づくかを説明します。
提供事業者の直API
直APIでは、接続先の事業者がAPIの仕様、認証、クォータ、請求を直接提供します。モデル開発元が自社モデルを提供するAPIと、推論事業者がオープンウェイトモデルを実行して提供するAPIの両方が、この接続経路に含まれます。
モデル開発元の直APIでは、モデル固有のツール、状態管理、キャッシュ、バッチ処理、リアルタイム通信なども、その開発元が定めるAPI仕様として公開されます。
OpenAI、Anthropic、Googleなどは、一つのAPIの中でも複数のモデル系列を提供しています。また、テキスト生成だけでなく、画像、音声、埋め込み、モデレーションなど、用途別のモデルやAPIを持つ場合があります。OpenAIのモデルカタログも、汎用モデルと用途別モデルを分けて掲載しています。
AI Gateway
AI Gatewayは、アプリケーションと複数のモデルAPIの間に置かれる接続層です。アプリケーションからのリクエストを受け、指定されたモデルや推論事業者へ転送します。サービスによって、認証、利用量記録、ルーティング、フォールバック、レート制限、請求なども扱います。
- OpenRouterは、モデルと推論事業者を分けて扱い、複数事業者へのルーティングを提供します。
- Vercel AI Gatewayは、共通API、事業者間のフォールバック、統合請求、BYOKを提供します。
- Hugging Face Inference Providersは、複数の推論事業者を通じてモデルへ接続します。
Gatewayが提供する共通形式と、接続先が持つ固有APIは別の層です。共通形式に変換できる機能がある一方、特定の事業者だけが持つ機能は、GatewayのAPIに現れないことがあります。また、同じモデル名でも、実際に推論する事業者が変わる構成があります。
オープンウェイトモデルの推論サービス
オープンウェイトモデルは、学習済みの重みが公開され、複数の事業者が同じモデルを自社の基盤上で動かせます。Together AI、Fireworks AI、Groqなどは、そのようなモデルを従量制APIや専用エンドポイントとして提供しています。
この形では、モデルの重みに加えて、推論エンジン、ハードウェア、量子化、バッチ処理、サンプリング設定も実行結果に関係します。そのため、モデル名が同じでも、生成速度、待ち時間、価格、再現できる出力の範囲が事業者間で一致するとは限りません。
専用環境と自社運用
専用エンドポイントでは、特定の利用者向けに計算資源や処理容量が割り当てられます。自社運用では、モデルの配布条件に従い、利用者がクラウドや自社設備へ推論サーバーを構築します。vLLMなどの推論ソフトウェアは、モデルの重みをAPIとして実行する役割を担います。
共有APIでは事業者が隠しているGPU構成、推論エンジン、容量管理などが、専用環境や自社運用では構成要素として表に出ます。一方で、モデルの開発元、計算基盤の提供者、運用者がさらに分かれる場合もあります。
ここまでで、同じモデルへ複数の経路から接続できる理由が見えてきました。続いて、接続先の内側にあるモデルそのものへ視点を移します。
同じ開発元にも複数のモデル系列がある
モデル開発元は、能力、応答時間、入出力単価、コンテキスト長、対応する入出力形式などが異なる複数のモデルを提供しています。さらに、汎用の生成モデルとは別に、画像生成、音声認識、音声合成、埋め込み、モデレーションなどに特化したモデルもあります。
モデル名に使われる「Pro」「Flash」「mini」などの語は、開発元が自社の製品系列を表すための名称です。異なる開発元の名称が、同じ能力や価格帯を保証するわけではありません。モデル系列の構成や名称は更新され、旧モデルの廃止や別名の参照先変更が行われることもあります。
また、API上のモデルIDには、特定版を指す固定IDと、提供元が参照先を更新する別名があります。同じ名称が長く使われていても、背後のモデル版やAPIで利用できる機能が変化する可能性があります。
こうしたモデル間の違いは、能力だけでなく、価格、生成速度、最初の出力までの時間などにも現れます。Artificial Analysisは、それらを共通の項目で掲載しているサイトの一例です。
Artificial Analysisで見える指標
Artificial Analysisは、複数のモデルと推論APIについて、能力、価格、タスク当たりの費用、生成速度、最初の出力までの時間、コンテキスト長などを掲載する独立系の分析サイトです。
各指標は、異なる性質を表しています。
| 指標 | 表しているもの |
|---|---|
| Intelligence Index | 複数のベンチマークを統合した能力評価 |
| 入出力価格 | APIが公表するトークン単価 |
| タスク当たりの費用 | 評価タスクの実行時に生じた入出力量を含む費用 |
| Output Speed | 出力開始後の、1秒当たりの生成トークン数 |
| Time to First Token | リクエストから最初の出力が返るまでの時間 |
| Context Window | 一度の処理でモデルが受け取れる入力と出力の範囲 |
Intelligence Indexは単一の試験結果ではなく、エージェント、コーディング、科学的推論など複数の評価を集約した指標です。評価方法には、含まれる評価、重み付け、実行条件が説明されています。
生成速度と最初の出力までの時間も、同じものではありません。最初の出力が早くても、その後の生成が遅いAPIがあります。反対に、生成開始まで待ち時間があっても、出力開始後は高速な場合があります。タスク当たりの費用は、単価だけでなく、その評価でモデルが実際に生成したトークン量の影響も受けます。
こうした公開指標は、一定の条件で測定された結果です。モデルそのものの性質に加え、推論事業者、混雑、地域、API設定、測定時期なども値に影響します。ランキングの列を切り替えると順序が変わるのは、それぞれの列が別の性質を測っているためです。
横断的な一覧には、主要三社以外のモデルも同じ指標で掲載されます。その背景には、モデル開発元と提供経路の広がりがあります。
モデル開発元と提供経路は増え続けている
OpenAI、Anthropic、Google以外にも、xAI、Mistral AI、Cohere、DeepSeek、AlibabaのQwen、Moonshot AIのKimi、Z.aiのGLM、MiniMax、Amazon Novaなど、多数のモデル系列があります。
これらは一つの形だけで流通しているわけではありません。開発元の直APIで提供されるモデル、クラウドのモデルカタログに掲載されるモデル、複数の推論サービスが実行するオープンウェイトモデルがあります。一つのモデル系列が複数の経路にまたがることもあります。
モデル開発元の資料は、モデルの機能やAPI仕様を説明します。クラウドやGatewayのカタログは、その経路で利用できるモデル、地域、クォータ、料金などを示します。Artificial Analysisのような分析サイトは、共通条件で測った能力や速度などを掲載します。同じモデルについて書かれた情報でも、それぞれが説明している層は異なります。
モデル系列の公式情報は、xAIモデル、Mistralモデル、Cohereモデル、DeepSeek changelog、MiniMax modelsなどで公開されています。
ここまで見てきたように、モデル開発元、推論運用者、接続窓口は重なり合いながらも別の主体です。最後に、記事全体の関係をまとめます。
まとめ
LLM APIは、モデルだけで成り立つものではありません。モデルを開発する主体、推論基盤を運用する主体、契約と接続を提供する主体があり、それらの組み合わせによって一つのAPIサービスが構成されます。
LLM APIには、接続・契約経路、実行形態、モデル公開形態という別々の軸があります。直API、クラウドのモデルサービス、AI Gatewayは接続経路を表し、共有API、専用エンドポイント、自社運用は実行形態を表します。クローズドモデルとオープンウェイトモデルは、モデルの公開形態を表します。
AWS、GCP、Azureのモデルカタログ内でも、モデルごとに推論運用者やホスティング方式が違う場合があります。
モデル名、APIの接続先、クラウドの契約先を別々の情報として捉えると、同じモデルが複数の場所に現れる理由や、同じSDKを使っていても認証・処理地域・機能が異なる理由を理解しやすくなります。
