LLMチャネル選択ガイド

文書基準: 2026年8月

概要

FMを導入する際には2つの独立した選択があります。これらは別個の意思決定です。

選択軸	質問	オプション
① 利用形態	誰が、どのように使うか?	Seat(チャットUI) / API(コード統合) / セルフホスティング
② チャネル	どこで購入・運用するか?	直接利用(1P) / クラウド提供(3P) / モデル提供社+クラウド決済

例) "ClaudeをAPIとしてBedrockで使用"
     → 利用形態: API
     → チャネル: クラウド提供 (3P Inference)

例) "ChatGPTを全社員にEnterpriseとして提供"
     → 利用形態: Seat (Enterprise)
     → チャネル: 直接利用 (1P)

本文書ではまず① 利用形態(Seat vs API)を整理した後、② チャネル(1P vs 3P)を比較します。

① 利用形態: Seat vs API

区分	Seatベースプラン	APIプラン
利用主体	組織員個人(開発者含む)	アプリケーション・サービス・自動化システム
使用方式	提供社が作成したUI/ツールを直接使用(チャット、Claude Code、Copilotなど)	自社製品・サービスにモデルをプログラム的に組み込み
課金単位	ユーザー数(席)ベースの購読料	トークン・リクエスト量ベースの従量課金
適した用途	個人生産性 — 文書作成、分析、コーディング、リサーチ	顧客向け機能、大規模自動化、バッチ処理、システム統合
統制単位	ユーザー/グループ/管理者ポリシー	APIキー・サービスアカウント、プロジェクト別予算、呼び出し上限
コスト予測	席数 × 単価 = 固定	使用量に応じて変動

選択基準:

組織員がAIツールを直接使用(チャット、コーディング、分析) → Seat(Business/Team/Enterprise)
自社製品・サービスにLLMを組み込んで顧客に提供 → API
両方必要 → Seat + APIを別々に運用(大半のエンタープライズ)

APIを使う場合: なぜ3P(クラウド経由)を選ぶのか

エンタープライズがAPIをコードから呼び出す際、モデル提供社直接(1P)よりも3P(Bedrock/Vertex/Azure Foundry)を選択するケースが多くあります。

3Pを選択する理由	説明
既存クラウドコミットの消化	AWS EDP、Azure EA/MACCがあれば、LLM費用を既存のコミットメントから控除可能
ネットワーク隔離	VPC/Private Linkによりトラフィックがパブリックインターネットを経由しない
コンプライアンスの活用	クラウドベンダーの既存認証(HIPAA、SOC 2など)を活用可能
統合請求/ガバナンス	既存の請求書に合算、コストタグでチーム別追跡、IAMでアクセス制御
単一契約	調達部門が新規ベンダーを追加する必要なく既存契約内で利用
マルチモデルアクセス	1つのプラットフォームで複数のモデルを同一APIで切り替え可能

それでも1Pを選択する理由	説明
最新モデル/機能	新規モデルとベータ機能が1Pに先行してリリース
フル機能	Fine-tuning、Realtime APIなど3Pに存在しない、または提供が遅れる機能
簡単なスタート	カード登録後すぐに使用可能、クラウド設定不要
クラウド非依存	特定のクラウドに依存しない

② チャネル: どこで購入・運用するか

チャネルアーキテクチャパターン

FM提供社が顧客にモデルを提供する経路は大きく4つのパターンに分かれます。この区分をまず理解すると、各提供社の複雑なオファリングが整理されます。

パターン	例え	運営主体	請求	機能範囲
A. 直接利用(1P)	直営店	モデル提供社	モデル提供社直接請求	フル機能(最新優先)
B. モデル提供社サービス + クラウド決済	百貨店のテナント	モデル提供社	クラウドマーケットプレイス(コミット消化可能)	フル機能(1Pと同一)
C. クラウド提供(3P Inference)	PB/セレクトショップ	クラウドベンダー	クラウド請求書に統合	クラウドAPI範囲内(一部機能は遅延/非対応)
D. セルフホスティング(オープンウェイト)	自炊	顧客自身	インフラ費用(GPU/サーバー)	ライセンス条件内でカスタマイズ自由

提供社別マッピング

提供社	A. 直接利用	B. モデル提供社サービス + クラウド決済	C. クラウド提供(3P Inference)	D. セルフホスティング
OpenAI	api.openai.com(Enterprise)	—	Azure Foundry, Bedrock	✗(非公開ウェイト)
Anthropic	api.anthropic.com(Enterprise)	Claude Platform on AWS(CCU課金)	Bedrock Claude, Vertex AI Claude	✗(非公開ウェイト)
Upstage	console.upstage.ai	—	AWS/Azure Marketplace, SageMaker	✅ Solar Open(オープンウェイト)
LG EXAONE	直接契約	—	Marketplace	✅ オープンウェイト(Hugging Face)
Meta Llama	—	—	Bedrock, Vertex, Azure(ホスティング)	✅ オープンウェイト(主な利用経路)
Mistral	api.mistral.ai	—	Bedrock, Azure, Vertex	✅ 一部オープンウェイト

パターン別特性比較

比較項目	A. 直接利用	B. モデル提供社サービス + クラウド決済	C. クラウド提供	D. セルフホスティング
新規モデル提供	最初	1Pとほぼ同時	数日～数週間の遅延	オープンウェイト公開時点
プラットフォーム機能	全体	全体	クラウドAPI範囲内	なし(自前構築)
Fine-tuning	フルオプション	フルオプション	制限的または遅延	完全自由(自社GPU)
エージェント/ツール	最新(Claude Code、Codexなど)	最新	独自フレームワーク(AgentCoreなど)	自前構築(LangGraphなど)
VPC/ネットワーク隔離	Enterprise専用	マーケットプレイス内で隔離	対応(リージョン/サービス別に確認)	完全隔離(自社インフラ)
コンプライアンス	提供社の認証	提供社 + クラウドの認証	クラウド認証を活用可能(構成が必要)	自己責任
コミット消化	不可	可能	可能	不可(インフラ費用のみ)
運用負担	なし	なし	低い	高い(GPU、モデルサービング、アップデート)

実例: 「Claude Codeを使いたいが」

要件	適したパターン
最新のClaude Code + 迅速なアップデート	A. 直接利用
Claude Code + AWS EDP消化 + AWS請求書	B. モデル提供社サービス + クラウド決済(Claude Platform on AWS)
Claude APIのみ必要 + VPC隔離 + 既存のAWSガバナンス	C. クラウド提供(Bedrock Claude)

主要FM別チャネル現況

提供社別のモデル一覧とアクセス可能なチャネルはAIプラットフォームとモデルの比較を参照してください。韓国FM(Upstage、EXAONEなど)はFMプロバイダー比較（韓国）を参照してください。パターン別特性比較表は上のパターン別特性比較節を使用します。

選択ガイド(評価軸)

月間支出額だけで1P/3Pを固定しないでください。以下の軸を先に整理してからチャネルを選びます。

評価軸	1P(直接)が有利な場合	3P(クラウド提供)が有利な場合
機能・リリース速度	最新モデル・エージェント機能が即座に必要	プラットフォームAPI範囲で十分、数日～数週間の遅延を許容
ネットワーク・コンプライアンス	Enterprise級の隔離のみで十分	VPC/リージョンガバナンス・既存認証の継承が必要
調達・コミット	クラウドコミットがほぼない	EDP/EA/CUDなどコミット消化が大きい
運用	モデル提供社のコンソール運用を許容	既存のクラウドIAM・可観測性・予算体系に統合
規模・クォータ	PoC・小規模、クォータに余裕がある	本番トラフィック・予約容量・プライベートオファーの交渉

国別のチャネル選択

国別の規制・主権要件に応じたチャネル選択は、各国ガイドを参照してください。

韓国 · FMプロバイダー比較（韓国）
米国 · EU · 日本 · シンガポール

料金プランとコスト管理

各提供社のライセンスティア(Seatプラン、APIティア)、3P予約容量(PTU、Provisioned Throughput)、コスト管理ツールとパターンはLLMライセンスとコスト管理で扱います。

よくある間違い

「3Pは高い」という思い込み — 公表されているトークン単価は概ね類似しています。既存のクラウドコミットがあれば、3Pが実効コストで有利になる場合があります。ただし、課金単位(CCUなど)と運用コストは別途確認が必要です。
単一チャネルへの一極集中 — 1Pのみを使うとクラウドガバナンスとの連携が弱くなる可能性があり、3Pのみを使うと最新機能の提供に遅延が生じる可能性があります。組織の状況に合わせて併用を検討してください。
クォータを事後に考慮 — 本番トラフィックを予測せずに開始すると、クォータ上限に達してサービス障害につながります。規模が大きい場合は事前に予約容量を確保してください。

チェックリスト

月間の想定トークン消費量を見積もったか
既存のクラウドコミット(EDP/EA/CUD)の有無を確認したか
データレジデンシー・隔離要件を対象管轄の基準で整理したか（国ガイドを参照）
必要な機能(Fine-tuning、エージェント、リアルタイム)がどのチャネルで提供されるかを確認したか
クォータ/Rate Limitが本番トラフィックに耐えられるかを確認したか
ハイブリッド(1P+3P)運用時のモデルバージョン同期戦略があるか