AIプロバイダーを能力表ではなく運用の層として選ぶ

一社を選んだだけでは、製品はできない

モデルAPIを呼べばAI機能は完成する、という感覚は最初のデモでは役に立つ。しかし実際に利用者が触るものには、認証、入力制限、秘密情報、データの根拠、失敗時の表示、観測、費用上限、配信がある。OpenAI、Anthropic、Googleはモデルと開発者APIを提供する。ElevenLabsは音声生成・音声会話の部品になり得る。Databricksは企業データとガバナンスの面を強く扱う。VercelとCloudflareはアプリの配信・実行・AI統合を選ぶ場所になる。この分類は企業の全製品を言い表すものではなく、設計で責任を置くための地図である。

1. 1利用者
2. 2Web UI
3. 3認証・入力検査
4. 4アプリのサーバー

1. 1サーバー
2. 2モデル提供者
3. 3生成結果

1. 1サーバー
2. 2検索・業務データ
3. 3根拠

1. 1サーバー
2. 2監査・評価・費用記録
3. 3改善判断

ここで大事なのは、モデル提供者を「正解を返すデータベース」として扱わないことだ。生成モデルは候補を作る。事実性が必要な回答は、検索・許可・引用・検査というアプリ側の仕組みが作る。公式SDKが便利でも、利用者の権限をモデルへ丸投げしない。モデルが言ったURL、ツール名、金額をそのまま実行しない。必ずアプリの許可表とvalidatorを通す。

七つの公式入口をどう読むか

OpenAI API docs、Anthropic docs、Google Gemini API docsでは、モデル名の一覧より先に認証、入力・出力形式、ストリーミング、レート制限、データ取り扱い、モデル更新の節を読む。いずれもドキュメントは更新されるので、特定モデルの可用性や料金をこの教科書で断定しない。実装時はモデルIDとドキュメントURLを設定と一緒に記録する。

ElevenLabs docsを音声UIに使う時、品質だけでなく同意・声の権利・生成物の扱いを設計に含める。音声クローンは技術的に可能な場合でも、対象者の明確な許可と提供元の規約を満たすとは限らない。会話アプリでは文字起こしの誤認識、遅延、途中キャンセル、音声が聞けない人のための文字UIまでを一つの体験として扱う。

Databricksの生成AI文書は、データ基盤の上でモデルを使う時の検索、評価、ガバナンスを検討する入口になる。企業データに接続できることは、何でも入力してよいことではない。Unity Catalogなどの製品機能を採用する場合でも、データ分類、最小権限、利用者ごとのフィルタ、監査保持期間は組織の方針で確認する。

Vercel AI SDK docsは、複数のモデルプロバイダーを共通的に呼び、ストリーミングUIを作る道具として読める。抽象化は切替を助けるが、各提供者のtool calling、画像入力、usage、エラー意味論まで同一にする保証ではない。Cloudflare Workers AI docsは、エッジでの推論やWorkersとの統合を検討する入口である。対応モデル、地域、持続時間、費用、バインディングの制約は実装時に当該の最新ページで再確認する。

選定表は能力、制御、回復の三列で作る

能力の列には、入力種別、構造化出力、ツール使用、文脈長、ストリーミング、言語を置く。ここには「できる」と「実際に自分の例で通った」を分けて書く。制御の列には、認証方式、リージョン、データ保持、監査、権限、キーの保管、上限を置く。回復の列には、timeout、rate limit、部分出力、モデル停止、提供者障害の時にUIとジョブがどう振る舞うかを書く。

1. 1要求
2. 2予算と権限を確認
3. 3一次提供者へ

1. 1timeout・429・5xx
2. 2再試行条件を判定
3. 3利用者へ状態を返す

1. 1品質不合格
2. 2根拠を追加/人へ渡す
3. 3自動実行しない

一つの設定済みproviderと直接の経路を使い、フォールバックや自動のprovider切替を実装しない。providerの失敗は明示的なエラーとして返し、依存する操作を止める。providerの設定を変更するのは、実際の必要性を観測し、品質・データ処理・費用を評価した後に限る。費用もリクエスト数だけではなく、入力長、出力長、再試行、音声秒数、検索、ログの保存を含める。

実習：一つの質問を安全に通す

1. UIから直接APIキーを送らない。ブラウザは自分のアプリのサーバーだけを呼び、秘密はサーバー側のsecret管理へ置く。
2. 入力上限、出力上限、timeout、利用者ごとの一日予算を先に決める。初期値は実測で見直す前提の安全な小ささにする。
3. サーバーはrequest ID、選んだモデルID、入力・出力token等の使用量、失敗種別を記録する。原文を保存する必要があるかは別途判断する。
4. モデルの返答をschemaで検査し、外部操作はアプリが生成したallowlistからだけ選ぶ。人名・URL・金額を生成結果だけで確定しない。
5. 正常、429、timeout、壊れたJSON、途中切断を擬似的に返し、利用者が再送してよい状態か確認する。ここを通って初めてデモが製品に近づく。

プロバイダー比較の結論は固定しない。使うデータ、許される遅延、停止時の影響、運用者が直せる範囲が変われば選択も変わる。だからこそ、公式ページのURLと実測条件を残すことが、次の更新を楽にする。

小さな製品では、まず一つのproviderと一つの失敗経路を完成させる。複数provider対応は、同じ評価セット、同じusage記録、同じ権限検査が共有できる時に加える。切替の自由を先に作っても、品質の基準がなければ、障害時にどちらが正しいか判断できない。

評価セットには、提供者の切替前後で同じ入力を使う。モデル名・版・出力上限・時刻を保存し、差が品質の変化なのか、設定や通信条件の差なのかを切り分ける。

2024〜2026年の変化: 選定は単一呼び出しから管理された経路へ

2024年のチャット補完デモから、2025〜2026年のツール利用・マルチモーダルなシステムへの移行により、プロバイダー境界は製品境界になりました。OpenAIの2026-09-21の標準に関する記事とGoogleの2026-09-15の言語に関する記事は各社の取り組みと方向性の記述であり、持ち運べる品質、可用性、価格の保証ではありません。

2社目を加える前に決定記録を残します。どの評価ケースが失敗したか、何の入力が境界を越えるか、どのID・保持ルールか、モデル／ツール版をどう固定するか、ユーザーに見える失敗をどう返すかです。ルーティング規則は決定的かつ観測可能にします。リクエストは明示設定された経路を選ぶか、安定したエラーで失敗します。1回目が失敗したからといって機密内容を別プロバイダーに黙って送ってはいけません。言語も一般タスク成功と別に評価します。日本語、英語、文字種混在、拒否、構造化出力、失敗すべき未対応ロケール／地域のfixtureを作ります。

2026-09-20 のFP4推論についての r/LocalLLaMA 議論はコミュニティの経験であり、benchmark ではない。精度やruntimeを変える前後で同一task suiteを測り、throughput主張を品質の証拠と扱わないという実務上の制御を補強する。

OpenAIの2024年9月のo1 releaseはtest-time computeを明示的な製品変数にした。provider比較では正答率だけでなく、prompt、tool、retrievalを固定し、許容するreasoning設定ごとにlatencyと総request costを記録する。これは測定設計であり、後のmodelがo1と同じ挙動を持つ主張ではない。