AIモデルカタログガイド：プロバイダー、エンドポイント、グループ、価格の読み方

AIモデルカタログが有用なのは、チームの本番判断に役立つ場合だけです。モデル名が並んだページだけでは十分ではありません。開発者は、最初の実ユーザーリクエストを通す前に、どのプロバイダーがそのモデルを所有しているのか、アプリがどのエンドポイントファミリーを呼び出すのか、どのグループまたはルート階層がトラフィックを処理するのか、その行が現在利用可能なのか、そして価格がどのように測定されるのかを把握する必要があります。

このAIモデルカタログガイドは、June 24, 2026 に、Flatkeyの公開ページ、稼働中のFlatkey pricing API、保存済みのAhrefs調査、Microsoft、Google、Vercel、OpenAIの公式モデルカタログドキュメントと照合しました。すべてのカタログ件数、ステータス、エンドポイントファミリー、価格フィールドは、その時点のスナップショットとして扱ってください。本番トラフィックの前に、Flatkey pricingを再度開き、正確なモデル行を確認し、低リスクのルートテストを実行してください。

実務上の目的はシンプルです。モデル閲覧を反復可能なレビューに変えることです。チームが同じAIモデルカタログレコードからプロバイダー、エンドポイント、グループ、ステータス、価格、オーナーを読み取れるなら、エンジニアリング、財務、サポート、調達にとってモデル判断の承認が容易になります。

クイックアンサー：AIモデルカタログの読み方

AIモデルカタログは左から右へ、まずプロバイダー、次にエンドポイント、3番目にグループ、4番目にステータス、5番目に価格、最後にルートテストの順で読みます。この順序により、見た目は魅力的でも、アプリケーションが実際に使うエンドポイント、グループ、予算ポリシーを通じて安全に呼び出せないモデル名をチームが選んでしまうのを防げます。

カタログフィールド	何が分かるか	判断すべきこと	Flatkeyでの確認
プロバイダー	モデルルートを供給またはホストしている主体。	このプロバイダーは、機能、リスク、サポートの期待に応えられるか。	ベンダーレコードと、プロバイダー固有の行メモを確認する。
Model ID	アプリがリクエストする正確な文字列。	エイリアスのずれや古いドキュメントに影響されず、このIDを使えるか。	記憶ではなく、/pricingからモデル行をコピーする。
エンドポイントファミリー	プロトコルの形：chat、responses、image generation、video、Gemini、Anthropic、または別のルート。	現在のSDK、リクエスト本文、ストリーミングモード、レスポンスパーサーに適合するか。	ベースURLを変更する前に、サポートされるエンドポイントファミリーを確認する。
グループ	リクエストを処理するルート階層またはリソースプール。	ステージング、本番、フォールバック、またはコスト重視のトラフィックをどのグループで処理すべきか。	ローンチ前に、正確なグループラベルとグループ比率を比較する。
ステータス	最新のカタログチェックが正常、未サポート、未解決のいずれか。	この行に本番トラフィック、スモークテスト、またはトラフィックなしのどれを適用すべきか。	ステータスとリクエストテストが一致するまで、表示されている行を利用可能と扱わない。
価格単位	利用量の課金方法：input、output、cache、image、video、second、または固定ジョブ形式の単位。	どの予算計算式とクォータを適用すべきか。	トークン形式のフィールドと非トークンの価格フィールドを分けて確認する。
ルートテスト	モデルが正確な機能パスで動作するかどうか。	エンジニアリング、財務、サポートが結果を受け入れられるか。	ステージングリクエストを実行し、利用量、コスト、ステータス、ログを確認する。

現在のFlatkey AIモデルカタログのスナップショット

この記事で使用した稼働中のFlatkey pricing APIスナップショットは、June 24, 2026 にsuccess: trueを返しました。そこには637 catalog rows、23 vendor records、5つの利用可能なグループラベル、6つのエンドポイントファミリーが含まれていました。レスポンス内のトップレベル価格バージョンはa42d372ccf0b5dd13ecf71203521f9d2でした。

スナップショットフィールド	June 24, 2026 の値	使い方
総カタログ行数	637	AIモデルカタログを静的なプロバイダー一覧ではなく、行単位の情報源として使う。
ベンダーレコード	23	プロバイダーの識別は、サポート、コンプライアンス、フォールバック判断に重要です。
エンドポイントファミリー	openai, gemini, image-generation, anthropic, openai-response, openai-video	エンドポイントファミリーは、現在のリクエスト形式が機能するかどうかを示します。
可用性ステータス	available, official_unsupported, unknown_failure	ステータスは、トラフィックのゲート制御とスモークテストの優先順位を決めるべきです。
利用可能な行	132	それでも、エンドポイント、グループ、プロンプト、クォータに対するルートテストが必要です。
公式未サポートの行	37	より新しい検証済みステータスがない限り、本番では使用しないでください。
不明な失敗の行	468	ルート、アカウント、上流、またはステータスの根拠を確認するまで未解決として扱います。

Flatkeyの公開ホームページでは、1つのAPIキー、OpenAI互換のベースURL https://router.flatkey.ai/v1、明確な価格、統合請求、キー、利用量、ルーティングを管理する1つのダッシュボードを中心に製品を位置づけています。これらの主張によりAIモデルカタログは運用上有用になりますが、製品が呼び出す特定の行を検証する必要がなくなるわけではありません。

モデル名より先にプロバイダーを読む

モデル名は、ベンダー、ゲートウェイ、ドキュメント、エイリアスの間を移動します。プロバイダーの識別は、最初に安定させるべきフィールドです。誰がモデルルートを供給しているのか、どのアカウントまたは上流が関係する可能性があるのか、サポートの期待がどこから来るのか、そしてそのモデルが直接プロバイダープラン、ゲートウェイルート、または制限付き評価パスのどこに属するのかを示します。

公式クラウドカタログも同じ問題を重視しています。Microsoft Foundry Modelsは、Azureが販売するモデルをパートナーおよびコミュニティモデルから分け、モデルを選択する前にモデル説明、モデルカード、ドキュメント、法的条件を確認するよう顧客に促しています。Google Model Gardenでは、チームがモデルコレクションとプロバイダーでフィルタリングし、モデルカードを開いて詳細を確認できます。どのAIモデルカタログにも同じ教訓があります。プロバイダーは飾りではなく、運用契約の一部です。

Flatkeyを評価する際は、次を書き留めてください。

• プロバイダーまたはベンダー：その行に関連付けられたベンダーレコード。
• モデル行：Flatkey pricingに表示される正確なモデルID。
• オーナー：モデルをリクエストしているチーム、機能、顧客、または予算オーナー。
• 選定理由：品質、コスト、レイテンシ、モダリティ、コンテキスト、ツール利用、画像、動画、またはフォールバック挙動。
• 代替ルート：プロバイダー行のステータスが変わった場合にアプリが使用すべきもの。

エンドポイントをラベルではなく契約として読む

エンドポイントファミリーは、アプリが想定すべきリクエストとレスポンスの形を示します。openaiエンドポイントファミリーに表示されるモデルは、OpenAI互換SDKのフローに適合する可能性があります。anthropic、gemini、image-generation、openai-response、またはopenai-videoに表示されるモデルは、異なるリクエスト本文、パーサー、ストリーミング挙動、ファイル処理パス、または利用量の解釈が必要になる場合があります。

だからこそ、有用なAIモデルカタログは移行計画と一緒に読むべきです。アプリがすでにOpenAI互換クライアントを使っている場合は、OpenAI互換API移行ワークフローから始めます。ステージングでベースURLを変更し、モデルIDを明示したまま、小さなリクエストを実行し、レスポンスを確認してから、ログとコストをレビューします。すべてのモデル行がすべてのエンドポイント形式をサポートしていると仮定しないでください。

エンドポイントファミリー	確認すべきこと	よくある失敗モード
openai	ベースURL、モデルID、messages形式、ストリーミング、ツール呼び出し、JSONモード、利用量フィールド。	SDK呼び出しは構文上成功するが、その機能をサポートしないモデル行を使っている。
openai-response	Responses形式のリクエスト本文、出力解析、ツール挙動、マルチモーダル入力。	Chat completionsの前提がResponses形式のワークフローに混入する。
anthropic	Messagesリクエストの形、システムプロンプト処理、画像入力の挙動、利用量フィールド。	OpenAI形式の本文が、適応なしにAnthropic形式のルートへ送信される。
gemini	Geminiリクエストの形、マルチモーダル入力、安全設定、レスポンス解析。	モデル選定がプロバイダー固有の機能差やレスポンス差を無視する。
image-generation	入力画像ルール、出力サイズ、品質、モデレーション、形式、受け付けられる結果数。	リクエスト数で予算化すると、画像品質とリトライのコストが隠れる。
openai-video	長さ、アスペクト比、非同期ジョブ状態、ポーリング、失敗処理、利用単位。	動画ジョブが安価な同期テキスト呼び出しのように扱われる。

グループをルートとコストのポリシーとして読む

統合ゲートウェイでは、グループは単なるラベルではありません。ルート階層、リソースプール、アカウントパス、または価格ポリシーを表すことがあります。June 24 のFlatkeyスナップショットでは、Economy、Standard、Claude Economy、Claude Official、Seedance2.0 Officialなどの利用可能なグループラベルが公開されていました。レスポンスにはグループ説明とグループ比率も含まれていました。

AIモデルカタログを読むとき、グループはモデル名だけでは答えられない問いに答えます。

• ステージングにはどのグループを使うべきか。統合テストには低リスクのルートで十分な場合があります。
• 本番にはどのグループを使うべきか。本番では、異なるプロバイダーパス、コストプロファイル、またはサポート期待が必要になる場合があります。
• フォールバックにはどのグループを使うべきか。フォールバックルートは、品質、レイテンシ、予算要件と互換性がなければなりません。
• 財務はどのグループをレビューすべきか。グループレベルの比率によって、同じモデル名の実効コストが変わる場合があります。
• 調達はどのグループを承認すべきか。直接または公式ルートは、エコノミールートとは異なる根拠を必要とする場合があります。

安全な習慣は、モデルIDだけでなく、モデル判断にグループを記録することです。あるグループで妥当に見えたモデル行が、別のグループでは異なるコストや運用パスを持つことがあります。

行を比較する前に単位別に価格を読む

価格フィールドは、モデルファミリーごとに異なる単位が公開されるため誤読しやすいものです。テキストモデルでは、多くの場合、input、cached input、outputが分かれています。画像と動画の行では、品質設定、生成メディア単位、ジョブ時間、または固定のmodel-price形式フィールドが追加されることがあります。たとえばOpenAIの公開価格ページでは、各モデルについて1M tokensあたりのinput、cached input、output価格が分けられています。Google Model Gardenは、オープンソースモデルの利用にはチューニングとデプロイ用コンピュート料金が伴う場合があると示しています。Microsoft Foundryは、サーバーレスデプロイは通常、API入力と出力に対して、多くの場合トークン単位で課金される一方、マネージドコンピュートは仮想マシンのコア時間を使うと述べています。

FlatkeyのAIモデルカタログレビューでは、行を比較する前に価格の形を分けてください。

価格の形	確認するフィールド	予算上の問い
トークン形式のテキスト	model_ratio, completion_ratio, cache_ratio	その機能は、プロンプト、出力、キャッシュ済みコンテキスト、またはリトライのどれに多く費用を使うか。
マルチモーダルチャット	エンドポイントファミリー、入力トークン、出力トークン、画像/動画入力、キャッシュ挙動。	非テキスト入力が実効コストを変えているか。
画像生成	モデル行、エンドポイントファミリー、出力設定、リトライ回数、採用された画像数。	失敗と編集を含めた後、採用画像1枚のコストはいくらか。
動画生成	モデル行、長さ、品質、ジョブ状態、リトライポリシー、存在する場合はmodel_price。	予算インシデントの前に、クォータで高額なジョブを止められるか。
グループ調整済みルート	グループラベル、グループ比率、本番ルート、フォールバックルート。	チームは実際に使うグループを比較しているか。

より深いコストワークフローには、行を絞り込んだ後にAIモデル価格比較ガイドを使ってください。このAIモデルカタログガイドは、そもそもどの行を価格分析の対象にするべきかを決めるのに役立ちます。

本番トラフィックの前にステータスを読む

表示されているカタログ行は、本番対応のルートと同じではありません。June 24 のFlatkeyスナップショットでは、637行のうち最新の可用性ステータスがavailableだったのは132行だけでした。残りの行はofficial_unsupportedとunknown_failureに分かれていました。これは未解決の行がすべて恒久的に使えないという意味ではありません。その行がユーザートラフィックを担う前に、現在のルート根拠が必要だという意味です。

ステータスをゲートとして使います。

1. Available：正確なエンドポイント、グループ、リクエスト本文、プロンプト形状でステージングのスモークテストを実行する。
2. Official unsupported：より新しい情報源がステータス変更を証明しない限り、本番トラフィックを開始しない。
3. Unknown failure：問題が上流ステータス、アカウント権限、ルート設定、リージョン、クォータ、一時的な失敗のどれなのかを調査する。
4. 明確なステータスなし：ダッシュボードまたはAPIテストで根拠が作られるまで、その行を未承認として扱う。
5. ステータス変更：ユーザーを再ルーティングする前に、モデル判断レコードを更新し、オーナーへ通知する。

ステータスフィールドは財務管理にもなります。フォールバックルートが、正常な低コスト行から未解決またはより高額な行へ静かに移動すると、モデル実験がインシデントに変わる可能性があります。すべてのAIモデルカタログレビューで、ステータス、グループ、価格を一緒に管理してください。

カタログレビューのためのFlatkeyワークフロー

1つのキーの背後にモデルを追加または変更するようチームから依頼されたときは、このワークフローを使います。

1. 現在のカタログを開く：Flatkey pricingから始め、正確な行をコピーする。
2. プロバイダーとグループを記録する：モデル名だけで行を承認しない。
3. エンドポイントファミリーを確認する：ルートをSDK、リクエスト本文、ストリーミング計画、パーサーに合わせる。
4. ステータスを確認する：ステータスとライブリクエストが一致した後にのみ本番トラフィックをルーティングする。
5. 価格単位を分類する：トークン、キャッシュ、画像、動画、時間、固定価格、またはグループ調整済みルート。
6. 低リスクのテストを実行する：https://router.flatkey.ai/v1または該当するルートファミリーを通じてステージングリクエストを送信する。
7. 利用量とコストを確認する：ダッシュボードでモデル、利用量、コスト、ステータス、ルーティングの根拠を確認する。
8. クォータとオーナーを設定する：行をキー、予算オーナー、上限、アラート、ロールバックルートに接続する。
9. 判断を保存する：カタログ行、日付、ステータス、グループ、価格フィールド、テスト結果、オーナー承認をまとめて保持する。

これは、エンジニアリングと財務の間の明確な引き継ぎにもなります。エンジニアリングはルートが動作することを証明します。財務は単位とオーナーが妥当であることを証明します。サポートは、顧客が機能変更の理由を尋ねたときにモデル判断を説明できることを証明します。

テンプレート：AIモデルカタログレビューレコード

ステージングまたは本番に到達するすべてのモデル行について、コンパクトな記録を残します。これにより、AIモデルカタログの閲覧が運用習慣になります。

AIモデルカタログレビューレコード
レビュー日:
依頼者:
機能またはワークフロー:
環境: development / staging / production / batch / customer-facing

モデル行:
プロバイダーまたはベンダー:
エンドポイントファミリー:
グループ:
可用性ステータス:
価格フィールド:
想定単位: input tokens / output tokens / cached input / image / video / duration / fixed job

ルートテスト:
リクエストパス:
SDKまたはクライアント:
レスポンス受理: yes / no
利用量表示: yes / no
コスト表示: yes / no
クォータ設定済み: yes / no

オーナー:
予算オーナー:
サポートオーナー:
フォールバックルート:
ロールバック条件:
次回レビュー日:

AIモデルカタログでよくあるミス

ミス	リスクを生む理由	より良いレビュー
モデル名だけで選ぶ	エイリアス、プロバイダー、エンドポイントファミリー、グループが異なる場合がある。	正確な行を承認する：プロバイダー、エンドポイント、グループ、ステータス、価格、オーナー。
OpenAI互換ならすべての機能が動くと仮定する	ツール利用、ストリーミング、画像、動画、レスポンス形式はルートによって異なる場合がある。	ローンチ前に機能レベルのスモークテストを実行する。
グループラベルを無視する	同じモデル名でも、グループによってコストやルート挙動が異なる場合がある。	本番グループを記録し、グループ比率を比較する。
未解決ステータスを無害と見なす	不明な失敗は、ルート、権限、上流、またはアカウントの問題を隠している場合がある。	ステータスとリクエストの根拠が正常になるまでトラフィックを止める。
単位なしで価格を比較する	入力トークン、出力トークン、キャッシュ済みトークン、画像、動画ジョブは同じ方法では予算化できない。	比較表を使う前に価格単位を分類する。

統合AIモデルカタログが最も役立つ場面

統合AIモデルカタログが最も役立つのは、製品がすでに複数のプロバイダー、モダリティ、または運用オーナーにまたがっている場合です。単一プロバイダーのプロトタイプは、多くの場合、1つの公式ドキュメントページから始められます。本番のAI製品には通常、より耐久性のあるビューが必要です。GPT、Claude、Gemini、DeepSeek、Qwen、画像モデル、動画モデル、ルーティンググループ、ステータス、クォータ、利用量、コストを1つのレビューループで扱う必要があります。

Flatkeyは、1つのAPIキー、1つの互換ベースURL、統合された価格と請求、キー、利用量、ルーティングを管理する1つのダッシュボードを求めるチーム向けに設計されています。カタログレビューは、その価値が具体化する場所です。プロバイダーポータルやスプレッドシートに判断を分散させる代わりに、1つの運用パスで行を比較し、ルートを選び、エンドポイントをテストし、クォータを設定し、利用量の根拠を保持できます。

正しい次のステップは、行を盲目的に信頼することではありません。現在のモデル価格ページから始め、正確なモデルとグループをコピーし、ステージングでルートをテストしてから、自社アプリケーションでワークフローを評価する準備ができたときにキーを取得してください。

FAQ

AIモデルカタログとは何ですか。

AIモデルカタログとは、モデルを選択、テスト、運用するために十分な文脈を持つ、検索可能なモデル行の一覧です。有用なカタログは、プロバイダー、モデルID、エンドポイントファミリー、グループまたはルート階層、可用性ステータス、価格単位、ドキュメントまたはダッシュボード上の根拠を示すべきです。

AIモデルカタログでプロバイダーが重要なのはなぜですか。

プロバイダーの識別により、誰がルートを供給またはホストしているのか、どの条件やサポート期待が適用される可能性があるのか、どのフォールバックまたは調達レビューが必要なのかが分かります。モデル名だけでは本番承認には不十分です。

エンドポイントファミリーはどのように比較すべきですか。

エンドポイントファミリーは、リクエスト形状、SDK互換性、ストリーミング挙動、ツールサポート、マルチモーダル入力、レスポンス解析、利用量フィールドで比較します。chatで動作する行が、image、video、Gemini、Anthropic、またはResponses形式のリクエストで動作するとは限りません。

モデルグループとは何ですか。

モデルグループとは、コスト、上流パス、サポート期待、またはフォールバック挙動に影響する可能性があるルートまたはリソースのラベルです。Flatkeyでは、ルートを承認する前に、モデルIDと価格フィールドとあわせてグループを読みます。

チームはAIモデルカタログをどのくらいの頻度で再確認すべきですか。

本番ローンチ、モデル差し替え、フォールバック変更、大規模な価格レビュー、またはインシデント後のフォローアップの前には毎回再確認してください。AIモデルカタログはすばやく変化するため、日付付きのスナップショットを恒久的な可用性または価格保証として扱うべきではありません。

最後のカタログレビューステップ

モデル行が本番に到達する前に、AIモデルカタログレコード内の各フィールドにオーナーを割り当てます。エンジニアリングはエンドポイント適合性とルートテストを担当します。財務は価格単位と予算を担当します。サポートは顧客向けの影響を担当します。プラットフォームはクォータ、フォールバック、ロールバックを担当します。これにより、カタログはモデルメニューではなくインフラになります。

Flatkey版のレビューを実行するには、Flatkey pricingを開き、モデル行を選択し、プロバイダー、エンドポイント、グループ、ステータス、価格単位を確認してから、キーを取得し、トラフィックを拡大する前にルートをテストしてください。