Model and Modality Playbooks2026年9月14日Flatkey Team

AIモデルカタログガイド: Provider、Endpoint、Group、価格の読み方

このAIモデルカタログガイドを使って、プロダクションのルーティング前にProvider、Endpoint、Group、提供状況、価格単位、使用実績を確認しましょう。

更新日: 2026年9月14日

AIモデルカタログガイド: Provider、Endpoint、Group、価格の読み方は、モデルカタログが単に名前を並べるだけではなくなった今、役立ちます。本番用のカタログはルーティングの表面です。どのproviderがそのルートを所有しているか、どのAPI形状がサポートされているか、どのgroupまたはplanが呼び出せるか、どの単位で課金されるか、そして本番トラフィックに十分な健全性があるかを、プロダクト、エンジニアリング、財務に伝えます。

高くつく失敗は、カタログをランキング表のように読むことです。著名なモデル名の行でも、endpointの形がSDKと一致しない、課金単位が比較可能でない、ルートが使っていないgroupに限定されている、あるいは可用性ステータスが本番対応ではない場合、ワークロードにとっては不適切であり得ます。

このAIモデルカタログガイドは、プロダクトチームが任意のAI API gatewayを通じてトラフィックを選定、テスト、またはルーティングする前に、モデルカタログを実用的に読むための方法を示します。ここではFlatkeyの公開モデルディレクトリとdocsを作業例として使いますが、このチェックリストは直接providerのカタログ、gatewayのカタログ、社内プラットフォームのカタログにも適用できます。

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

AIモデルカタログは次の順で読みます:

Provider: 上流のモデルまたはルートを誰が運用しているか。
Model ID: アプリケーションが送信しなければならない正確な文字列。
Endpoint support: ルートが受け付けるAPI形状。たとえばOpenAI互換のchat、Responses、Anthropic、Gemini、image、video、embeddings、またはネイティブルートなど。
Group or plan: どのaccount group、route group、quota group、またはbilling planがその行を利用できるか。
Availability status: ルートがlive、degraded、unknown、preview、early access、deprecated、またはcoming soonのどれか。
Pricing unit: 課金が1M input/output tokens、cached tokens、image、second、request、character、minute、または別の単位あたりか。
Usage evidence: テストリクエストが、期待したmodel、status、token counts、route、key、costとともにlogsに表示されるか。

このAIモデルカタログガイド: Provider、Endpoint、Group、価格の読み方における短い答えは、price列だけでモデルを選ばないことです。provider、endpoint、group、status、price unit、usage-log evidenceがすべてワークロードと一致してから選んでください。

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

Flatkeyの現在のdocsでは、1つのOpenAI互換base URL、https://router.flatkey.ai/v1、に加えて、chat completions、Responses、embeddings、image generation、video tasks、model listing向けのAPI endpointsが説明されています。/v1/models endpointはOpenAI互換形式でmodel IDとproviderを返し、公開Model Directoryはpricing、health、endpoint support、model detail pagesを確認するためのライブな場所です。

2026年9月14日、Flatkeyの公開model directoryでは、catalog reviewに直接関係する次の行フィールドが表示されていました:

カタログ項目	示している内容	公開ディレクトリで確認された例
`model_name`	テスト対象となる文字列またはモデル行。	`gpt-5.6-sol`、`deepseek-v4-pro`、`seedance-2.5`、`gemini-3-flash-preview`、`claude-sonnet-5`
`vendor_name`	ルートの背後にあるプロバイダーまたはカタログ所有者。	OpenAI、DeepSeek、ByteDance、Google、Anthropic、Flatkey catalog
`supported_endpoint_types`	そのモデルが受け付けられるリクエスト形状。	`openai`、`openai-response`、`anthropic`、`gemini`、`openai-video`、`video`
`availability_status`	現在、そのルートが利用可能に見えるかどうか。	`available`、`unknown_failure`
`display_pricing.billing_kind`	価格単位のファミリー。	`token`、`per_second`、`request`
`enable_groups` / group pricing	どのルートまたは商用グループがその行を呼び出せるか、また価格がどのように調整されるか。	公開ページデータ内の `plg` のようなグループ化されたルートエントリ

このスナップショットは、カタログがどのように構成されているかを示す証拠として扱ってください。永続的な価格表ではありません。Flatkey のリファレンスドキュメントでは、読者を flatkey.ai/models、flatkey.ai/pricing、および flatkey.ai/status に明示的に戻しており、モデル行、価格、稼働状況はドキュメントのリリースなしに更新され得ます。

モデル名を読む前にプロバイダーを読む

プロバイダーが最初の項目なのは、モデル名だけでは、トラフィックがどこへ行くのか、どの契約が適用されるのか、どの運用上の制約が重要なのかが分からないためです。

プロバイダー項目を使って、次の点に答えてください:

質問	重要な理由
このルートは、元のモデル提供元、ゲートウェイ、推論クラウド、または内部プロキシのどれによって運用されていますか?	サポート、価格、ログ、データ処理、インシデントの責任者が変わります。
その行は公式エンドポイントを表していますか、それとも再提供されたモデルですか?	製品チームは、その挙動が提供元の公式 API と一致すべきかを知る必要があります。
異なるプロバイダーから、似た名前の複数の行がありますか?	`qwen`、`deepseek`、`gemini`、`claude` のラベルは、地域、互換性、またはプランの違いを隠している可能性があります。
財務はどのプロバイダーに対して照合すべきですか?	課金単位とリスト価格の参照はプロバイダー由来かもしれませんが、請求書はゲートウェイから発行される場合があります。

Flatkey では、承認された位置づけは、1つのキー、1つの残高、そして OpenAI、Anthropic、Google、DeepSeek、Alibaba、Z.ai、Moonshot、ByteDance といったプロバイダー横断の公式モデルアクセスです。そのため、プロバイダーの透明性が特に重要です。カタログ行でプロバイダーとルート種別が明確でない場合は、本番投入を承認する前に確認を求めてください。

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

Endpointのサポートは、あなたのアプリケーションとルートの間の契約です。これにより、現在のクライアント、リクエスト本文、ストリーミングハンドラー、tool-callパーサー、usage-accountingロジックを、書き直しなしで動作させられるかどうかが決まります。

FlatkeyのRESTドキュメントには、次の公開API endpointが記載されています:

Endpoint	一般的な用途
`/v1/chat/completions`	OpenAI互換のchatおよびテキスト生成
`/v1/responses`	互換モデル向けのResponsesスタイルの状態保持またはtool対応ワークフロー
`/v1/embeddings`	ベクトル埋め込み
`/v1/images/generations`	画像生成
`/v1/videos`	動画生成タスクの作成
`/v1/videos/{task_id}`	動画タスクのポーリング
`/v1/videos/{task_id}/content`	完了した動画のダウンロード
`/v1/models`	アカウントで利用可能なmodel一覧

openaiと書かれたcatalog行は、anthropic、gemini、openai-response、openai-video、またはvideoと書かれた行とは同じではありません。modelは複数のendpointファミリーをサポートする場合がありますが、それでもアプリケーションが実際に使用する正確なpathをテストする必要があります。

このAI model catalog guideでは、endpointフィールドを使って短い互換性契約を書きます:

catalog_endpoint_contract:
  workload: support_ticket_summary
  model_id: selected-model-id
  provider: provider-name
  endpoint_type: openai
  base_url: https://router.flatkey.ai/v1
  endpoint_path: /v1/chat/completions
  required_features:
    - streaming
    - tool_calls
    - structured_json
    - usage_fields
  pass_condition:
    - existing_sdk_initializes
    - response_parser_accepts_output
    - usage_log_matches_model
    - fallback_policy_is_documented

その契約の中の1項目でも失敗した場合、そのmodelは依然として有用かもしれませんが、そのworkloadに対するそのまま使えるルートではありません。

Groupsをルートとコストポリシーとして読む

Groupsは内部プラットフォームのラベルのように見えるため、見落としやすいです。見落とさないでください。groupは、どの人がルートを使えるか、どの価格倍率が適用されるか、どのkeyが許可されるか、どのquotaが消費されるか、どのfallback poolが利用可能かを決めることがあります。

gateway catalogでは、groupsは次のようなポリシーの1つまたは複数を表すことがよくあります:

Groupの意味	確認すべきこと
商用プラン	このアカウントまたはチームは、表示されている価格へのアクセス権がありますか?
ルートプール	どの上流チャネル種別またはproviderアカウントがトラフィックを処理しますか?
製品環境	このルートは、dev、staging、production、または特定の顧客向けに承認されていますか?
予算スコープ	どのkey、team、workspace、または顧客の予算に課金されますか?
許可リスト	このmodelは、規制対象データ、公開機能、またはagentの自律動作に対して許可されていますか?
fallbackファミリー	このgroupは、品質やポリシーを損なわずに別のルートへfallbackできますか?

Flatkeyの製品ポジショニングには、サブキーのガバナンス、予算、モデルの許可リスト、利用ログ、そして共有残高が含まれます。つまり、カタログの行と利用ダッシュボードは一致している必要があります。プロダクトマネージャーがカタログ上でモデルを承認しても、本番キーが正しいグループに属していなければ、エンジニアリングはその問題を403、429、フォールバックの失敗、または請求上の想定外として発見することになります。

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

価格は、モデルカタログで最も読み違えられやすい項目です。AIモデルカタログガイドでは、誰かが価格を比較する前に、すべての価格を実際の単位に落とし込むべきです。

以下の単位を、同じものとして比較してはいけません。

価格単位	一般的なワークロード	カタログレビュー上のリスク
入力トークン	プロンプト重視のチャット、要約、検索拡張生成	長いプロンプトと検索で取得したコンテキストがコストの大半を占めることがあります。
出力トークン	推論、文章作成、コード生成、抽出	入力が安く見えても、長い出力がコストの大半を占めることがあります。
キャッシュされた入力トークン	再利用されるシステムプロンプト、プロンプトキャッシュ、コンテキストキャッシュ	キャッシュヒット率とキャッシュミス率は別々に測定する必要があります。
画像出力トークンまたは画像ごとの価格	画像生成と編集	解像度、品質、参照画像、再試行、受理率によって実コストは変わります。
秒単位	動画生成や一部のメディアルート	リクエスト数よりも、継続時間や失敗・編集されたクリップの方が重要です。
リクエストごと	検索、ツール、画像ユーティリティ、エンリッチメント、カスタムAPI	最終コストは、リクエスト成功率と再試行ポリシーで決まります。
分単位または文字単位	音声、文字起こし、テキスト読み上げ、OCR類似のワークフロー	チャンネル数、言語、追加機能、バッチモードによってコストが変わることがあります。

プロバイダーの価格ページでも、名称はさまざまです。OpenAI、Anthropic、Google Gemini、DeepSeekはいずれも、現在の公開価格ドキュメントで、入力、出力、キャッシュされた入力、キャッシュの読み取り/書き込み、またはキャッシュヒット/キャッシュミスの価格を何らかの組み合わせで区別しています。だからこそ、カタログレビューでは、1つの恒久的な価格をロードマップのチケットに書き写すのではなく、参照元のURLとレビュー日を保存すべきなのです。

以下の正規化された式を使います。

accepted_workload_cost =
  (primary_attempt_cost
   + retry_cost
   + fallback_cost
   + cached_or_uncached_delta
   + media_or_tool_addons)
  / accepted_outputs

次に、判断の文脈を加えます。

production_cost_decision =
  accepted_workload_cost
  + latency_penalty
  + manual_review_cost
  + incident_risk
  + data_policy_constraints

この2行目が、最も安い価格セルが最終的な答えになることはほとんどない理由です。

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

利用可能性のステータスは注記ではなく、ゲートであるべきです。モデルはプロバイダー、エンドポイント、価格の面では完璧に見えても、プレビュー専用、性能劣化、リージョン制限、廃止予定、アカウントに未登録、ヘルスチェック失敗であれば、本番の選択としては誤りかもしれません。

次のステータス分類を使います。

Status class	対応方法
Available and tested	Usageログの確認後、段階的ロールアウトの候補。
Available but untested	本番トラフィックを割り当てる前にスモークテストを実施する。
Preview, beta, early access, or limited	製品がライフサイクルリスクを明示的に受け入れている場合を除き、実験用途に使用する。
Degraded or high latency	ワークロードが許容できる場合にのみ、非デフォルトまたはフォールバックとして維持する。
Unknown failure	ルートが検証されるまでブロック扱いにする。
Deprecated or shutdown scheduled	短期的な移行理由がない限り、新規作業は開始しない。
Coming soon	リリース計画には含めない。

Flatkeyのドキュメントでは、モデルのヘルスチェックをライブのステータスページに紐づけています。本番導入の判断では、ステータス欄を日付、モデルID、endpoint type、keyまたはgroup、そして実際のリクエストID 1件とともに保存する必要があります。

Flatkeyでのカタログレビュー手順

カタログ内のモデルを使って安全かどうかをプロダクトチームに確認されたら、毎回このワークフローを使ってください。

Flatkey Model Directoryを開く。
provider名だけでなく、正確なmodel IDを検索する。
provider、endpoint対応状況、利用可否ステータス、価格単位、groupアクセス権、現在のレビュー日を記録する。
Flatkey pricingと該当するproviderの料金ページを開く。
正規化したコスト単位を記載する: 100万input tokensあたり、output tokens、cached tokens、image、second、request、または別の単位。
意図したbase_url、endpoint path、model IDを使って、リスクの低いスモークテストを実行する。
期待したmodel、key、status、token数またはmedia unit、costで、そのリクエストがFlatkeyのusage logsに記録されていることを確認する。
実ユーザーに送信する前に、trigger、retry回数、許可するfallback models、quality gate、logging fieldsを定義する。
ルートをデフォルトにする前に、product、engineering、finance、securityでカタログレコードをレビューする。

重要なのは7番です。カタログの1行は約束です。usage-logの1行は、その約束があなたのaccount、key、group、workloadに一致していた証拠です。

テンプレート: AIモデルカタログレビュー記録

このテンプレートを社内のlaunch docにコピーしてください:

ai_model_catalog_review:
  review_date: 2026-09-14
  reviewer: product_owner_or_platform_owner
  workload: customer_support_summary
  business_owner: support_product
  environment: staging
  catalog:
    catalog_url: https://flatkey.ai/models
    model_id: selected-model-id
    provider: provider-name
    endpoint_types:
      - openai
    group_or_plan: approved-group
    availability_status: available
    pricing_unit: per_1m_input_and_output_tokens
  compatibility:
    base_url: https://router.flatkey.ai/v1
    endpoint_path: /v1/chat/completions
    sdk: openai-python
    streaming_required: true
    tool_calls_required: false
    structured_output_required: true
  cost:
    provider_pricing_url: provider-pricing-page
    flatkey_pricing_url: https://flatkey.ai/pricing
    cost_formula: accepted_workload_cost
    cache_assumption: measured_not_assumed
  evidence:
    smoke_test_request_id: req_example
    usage_log_verified: true
    output_parser_passed: true
    p95_latency_ms: measured
    fallback_tested: false
  decision:
    status: approve_for_limited_rollout
    rollout_limit: 5_percent_of_traffic
    fallback_route: selected-fallback-model
    next_review_date: 2026-09-21

このテンプレートは、AIモデルカタログガイド: Provider、Endpoint、Group、価格の読み方を実践的なものに保ちます。出力は優先順位リストではありません。監査可能な判断記録です。

一般的なAIモデルカタログのミス

ミス1: provider と model family を同じ項目として扱う

Provider は上流の所有者またはルートの所有者です。Model family は命名グループです。両者は関連していますが、互換ではありません。両方を記録してください。

ミス2: OpenAI互換ならすべての endpoint が動くと想定する

OpenAI互換の設定は移行作業を減らせますが、すべてのモデルで各 endpoint、ストリーミングイベント、tool-call の形式、usage フィールド、またはメディアパラメータが動作することを証明するものではありません。カタログ行の正確な endpoint ファミリーをテストしてください。

ミス3: トークン価格とメディア価格を比較する

トークン単位、画像単位、秒単位、リクエスト単位の課金は、1つの価格列にまとめるべきではありません。ワークロードに対する受け入れ済み出力あたりのコストに正規化してください。

ミス4: ロールアウトまで group を無視する

本番キーが、承認した group を呼び出せない場合、カタログ上の判断は不完全です。実際に本番へ出すキーで group アクセスを検証してください。

ミス5: レビュー日なしで価格行をコピーする

Provider と gateway の価格は変更される可能性があります。ソースURL、レビュー日、model ID、pricing unit、そしてテストリクエストからの usage-log 証跡を保存してください。

ミス6: カタログのステータスだけでリリースする

カタログのステータスはスモークテストの実施を促すべきです。スモークテストの代わりにはなりません。本番承認には、同じキー、endpoint、model、group を通した少なくとも1回のリクエストが必要です。

統一されたAIモデルカタログが最も役立つ場面

統一されたモデルカタログは、チームが次のいずれかを複数抱えているときに最も役立ちます:

複数の provider key が、サービス、エージェント、環境にまたがって散在している。
プロダクトは、text、image、video、embedding、tool の route を 1 つの workflow で比較したい。
Finance は、個別の provider 請求書ではなく、request レベルの cost 証跡を必要としている。
Platform engineering は、fallback ルール、health check、model allowlist を必要としている。
Security は、どの route がどの workload を処理したのかを把握する必要がある。
Teams は、すべての client を書き直すことなく、ある model から別の model へ移行する必要がある。

Flatkey はこのパターンに適している: 1 つの API key、1 つの OpenAI-compatible router、ライブの model directory、usage logs、1 つの balance を通じた model/tool access、そして teams 向けの operational controls。これは due diligence を不要にするものではない。team に、それを実施する 1 か所を与える。

FAQ

AI model catalog とは何ですか?

AI model catalog は、model route とその metadata の検索可能な一覧です: model ID、provider、supported endpoints、pricing unit、availability、groups または plans、そして場合によっては context window、modality、health、limits、usage links です。

provider field が重要なのはなぜですか?

provider field は、上流の model または route を誰が所有しているかを示します。これは、support、pricing reference、limits、lifecycle notice、region の挙動、data handling、incident response に影響します。

model catalog における endpoint support とは何を意味しますか?

endpoint support は、model row が受け付ける API 形状を示します。たとえば、ある row は OpenAI-compatible chat、Responses、Anthropic-compatible requests、Gemini-native requests、image generation、video generation、または embeddings をサポートする場合があります。SDK と parser は、選択した endpoint に一致している必要があります。

groups は pricing tiers と同じですか?

場合によっては同じですが、常にそうとは限りません。groups は、commercial plans、route pools、access policies、key scopes、budget scopes、fallback families を表すことがあります。platform owner が正確な意味を確認するまでは、groups を route policy として扱ってください。

team は model prices をどのように比較すべきですか?

model prices は、単純な catalog row ではなく workload 単位で比較してください。input tokens、output tokens、cached tokens、images、seconds、requests、retries、fallback attempts、accepted outputs を 1 つの cost formula に正規化します。

テストなしで model catalog row を信頼すべきですか?

いいえ。catalog row は有用な出発点ですが、本番承認には、使用予定の正確な key、base URL、endpoint、model ID、group を通した smoke test を含めるべきです。

Flatkey は model catalog review にどう役立ちますか?

Flatkey は、team が model row を確認し、OpenAI-compatible base URL 経由で route し、live pricing surface を比較し、model health を確認し、usage logs をレビューするための 1 か所を提供します。これにより、catalog の判断を product、engineering、finance 全体で監査しやすくなります。