AIモデル価格比較: トークン、画像、動画のコストを1つのダッシュボードで
AIモデル価格比較は、実際に製品がどのように費用を使っているかに合っていてこそ役立ちます。トークン価格の静的な表は出発点にすぎません。実際の推論コストは、入力トークン、キャッシュ済み入力、出力トークン、画像出力ユニット、動画秒数、ツール呼び出し、再試行、フォールバック、失敗したジョブ、そして生成結果のうちユーザーが実際に受け入れる割合によって変動します。
このガイドは、開発者、プロダクトチーム、調達チーム向けに、テキスト、画像、動画、そしてマルチプロバイダーAPIルートにまたがるAIモデル価格を比較するための実用的なダッシュボードを提供します。持続的に重要なのは、最も安いと表示されたリクエストではありません。受け入れられた結果あたりのコストです。
Flatkeyがこのワークフローに適しているのは、1つのAPIキー、1つの前払い残高、1つの請求書、そして300以上の公式モデルと1,000以上の従量課金ツールにまたがる共有使用台帳をチームに提供するからです。公式プロバイダーの価格は確認する必要がありますが、ルートを決定する前に別々のベンダーアカウントから各実験を突き合わせる必要はありません。
AIモデル価格比較のクイックフレームワーク
プロバイダーを切り替える前、より大きなモデル予算を承認する前、または本番トラフィックを新しいモデル経由にする前に、このフレームワークを使ってください。
| コスト層 | ネイティブの価格単位 | 正規化先 | ダッシュボード項目 |
|---|---|---|---|
| テキストおよびエージェント呼び出し | 入力トークン、キャッシュ済み入力、出力トークン、キャッシュ書き込み、バッチジョブ、ツール呼び出し | 受け入れられた回答または完了タスクあたりのコスト | accepted_task_cost_usd |
| 画像生成 | プロンプトトークン、画像入力、出力画像トークン、生成画像、解像度、受け入れられた画像 | 受け入れられた画像あたりのコスト | accepted_image_cost_usd |
| 動画生成 | 秒数、クリップ、解像度、キュー試行、失敗した非同期ジョブ | 受け入れられたクリップまたは受け入れられたクリップ秒あたりのコスト | accepted_clip_cost_usd |
| マルチモーダルワークフロー | テキスト、ファイル、画像、動画、ツール、再試行、フォールバックの混在 | 完了したワークフローあたりのコスト | workflow_cost_usd |
| 調達とガバナンス | キー、請求書、エクスポート、予算、許可リスト、監査要件 | ルートを安全に運用するためのコスト | operating_cost_note |
経営層向けの指標はシンプルにできます。受け入れられた結果あたりのコストです。エンジニアリング台帳は詳細なままにしておくべきです。なぜコストが変動したのかは、キャッシュミス、出力長の変化、再試行の急増、モデルのフォールバック、あるいはユーザー受容率の低下かもしれないからです。
なぜ表示価格だけでは不十分なのか
最も安いトークン行が、ローンチ後には最も高いルートになることがあります。入力トークン単価が低いモデルでも、より長いプロンプトを必要とする、より長い回答を生成する、キャッシュ機会を逃す、再試行が多い、あるいは過負荷時により高価なルートへフォールバックする場合は負ける可能性があります。
メディアコストは問題をさらに顕著にします。
- 画像モデルは、生成あたりでは安く見えても、ユーザーが多くの出力を拒否する場合は受け入れられた画像あたりでは高価に見えることがあります。
- 動画モデルは、秒単位では手頃に見えても、1本を保存する前に複数のプレビューを要求されると高くつくことがあります。
- コーディングやリサーチのエージェントは、チャットモデル自体は安くても、ツール、ブラウザ、画像、エンリッチメントのサイドコールが高額になることがあります。
- 直接プロバイダーのアカウントは、モデルの生価格は低くても、調達に個別のキー、請求書、使用量エクスポート、予算管理が必要な場合、運用コストが高くなることがあります。
だからこそ、AIモデル価格比較ではネイティブの価格単位を保持し、そのうえで各ルートを受け入れられた結果の経済性に正規化する必要があります。
確認すべき最新の価格ソース
プロバイダーの価格は頻繁に変わります。料金表を一度コピーして、長期的に有効だとみなしてはいけません。公式URL、確認日、モデルまたはルートID、単位、注記を含むソース表を維持してください。
| プロバイダーまたはルート | 確認する公式ソース | 取得すべき価格の次元 | ダッシュボードの注記 |
|---|---|---|---|
| OpenAI API | OpenAI API pricing | Input, cached input, output, batch mode, fine-tuning, image, audio, video, regional processing | 正確なモデルID、提供モード、バッチ料金が適用されるかどうかを確認する。 |
| Anthropic Claude API | Claude pricing | Input, output, prompt caching, batch pricing, model family, context window | キャッシュ書き込みとキャッシュヒットの挙動は、エージェントの繰り返し利用時の経済性を大きく変える可能性がある。 |
| Google Gemini API | Gemini API pricing | Free or paid tier, input, output, caching, batch mode, priority/flex options, search grounding, media | 特に検索やグラウンディングが有効な場合は、モデルファミリーと提供モードを記録する。 |
| DeepSeek API | DeepSeek API pricing | Input cache miss, input cache hit, output, peak or off-peak timing, model alias | 料金が時間帯やキャッシュヒットで変わる場合、リクエストログにはタイムスタンプとキャッシュ状態が必要。 |
| Alibaba Model Studio / Qwen | Alibaba Model Studio models | Model family, modality, region, token or media unit, console model ID | Qwen ルートを予算に組み込む前に、正確なモデル詳細ページとリージョンを確認する。 |
| Flatkey multi-provider API | Flatkey pricing and Flatkey models | Unified model routes, one balance, per-request ledger, tool calls, invoices, sub-key budgets | ルートの可用性、マルチプロバイダーのガバナンス、台帳ベースの比較に使用する。 |
すべての価格行について、確認日、モデルまたはルートID、単位の3つを必須項目として保存する。1ドル/トークンの値は、1ドル/画像、1ドル/動画秒、または1回のツール呼び出しあたりの支払い価値とは直接比較できない。
ダッシュボードのスキーマ
まずは1つのリクエスト台帳から始める。テキスト、画像、動画、ツールの利用を切り離された財務システムに分けないこと。
{
"request_id": "req_01j...",
"workspace_id": "wk_product",
"environment": "production",
"feature": "creative_generator",
"customer_id": "cus_123",
"provider": "flatkey",
"model_or_route": "example-route",
"route_type": "image",
"billing_unit": "output_image",
"input_tokens": 1240,
"output_tokens": 0,
"cache_read_tokens": 0,
"cache_write_tokens": 0,
"tool_calls": 0,
"images_generated": 4,
"images_accepted": 1,
"video_seconds_generated": 0,
"video_seconds_accepted": 0,
"retry_count": 1,
"fallback_count": 0,
"provider_cost_usd": 0.16,
"gateway_or_platform_cost_usd": 0.00,
"total_cost_usd": 0.16,
"accepted_result": true,
"latency_ms": 11800,
"pricing_source_url": "https://provider.example/pricing",
"pricing_checked_at": "2026-10-12"
}
このスキーマは、財務部門が照合できる数値を提供し、エンジニアリングには、なぜモデルルートがより安く、またはより高くなったのかを説明するために必要なフィールドを提供する。
使用するコスト計算式
テキストとエージェント呼び出し
テキストルートでは、まず生のリクエストコストを計算する:
raw_text_cost =
input_tokens * input_rate
+ output_tokens * output_rate
+ cache_write_tokens * cache_write_rate
+ cache_read_tokens * cache_read_rate
+ tool_call_costs
+ retry_and_fallback_costs
次に、それを正規化する:
accepted_task_cost =
sum(raw_text_cost for all attempts, retries, and fallbacks)
/ accepted_tasks
リクエストが失敗してユーザーが回答を受け取れなかった場合は、隠さないこと。失敗した呼び出しのコストは別々に追跡する。価格ダッシュボードは、失敗、再試行、フォールバックのトラフィックを可視化してこそ有用になる。
画像生成
画像APIの価格は、単一の普遍的な単位ではない。プロンプトトークンと画像出力トークンを公開するモデルもあれば、画像ごと、解像度ごと、編集ごと、またはプロバイダー固有の単位を公開するものもある。ネイティブの単位を保持し、受理された画像数に正規化する:
accepted_image_cost =
(prompt_cost + input_image_cost + output_image_cost + retry_cost)
/ accepted_images
images_generated と images_accepted を別々に追跡すること。受理された画像1枚ごとに4枚生成するルートは、ユーザーが1枚中1枚を受け入れるルートと直接比較すべきではない。
動画生成
動画の価格設定には、長さ、解像度、非同期ジョブの状態が必要になる。動画呼び出しは、キュー待ち、失敗、キャンセル、再生成、または後から承認される場合がある。
accepted_clip_cost =
sum(video_seconds_generated * per_second_rate by resolution)
+ retry_cost
+ fallback_cost
+ storage_or_tool_costs
製品判断のために、次も追跡する:
accepted_clip_secondspreview_countregeneration_countfailed_job_counttime_to_first_preview_mstime_to_accepted_clip_ms
動画モデルは、項目上の単位あたりでは安くても、ユーザーが2倍の頻度で再生成するなら、プロダクトにとってはむしろ悪くなることがあります。
直接のプロバイダーアカウントとマルチプロバイダーAPIを比較する
1つのモデルファミリーでワークロードの大半をこなし、個別請求の管理も容易であれば、直接のプロバイダーアカウントで十分です。継続的なモデル比較、フォールバックルーティング、または複数プロバイダーにまたがる単一の台帳が必要な場合は、マルチプロバイダーAPIのほうが有用になります。
| 判断ポイント | 次のような場合は直接のプロバイダーアカウントで十分かもしれません | 次のような場合はマルチプロバイダーAPIが役立ちます |
|---|---|---|
| モデル選択 | 1つのプロバイダーがほとんどのタスクで勝つ。 | さまざまなワークロードでOpenAI、Claude、Gemini、DeepSeek、Qwen、画像、動画、ツールのルートが必要。 |
| エンジニアリング工数 | すでにコードは1つのプロバイダーを呼び出しており、変更はめったにない。 | OpenAI互換のルーティングと、統合作業の書き直しを減らしたい。 |
| コスト管理 | 請求書が1つでダッシュボードも1つで問題ない。 | サブキー単位の予算、モデルの許可リスト、リクエストごとの使用量エクスポートが必要。 |
| 調達 | 個別契約でも管理できる。 | 重複契約、遊休席、分散したプロバイダーキーがチームの足を引っ張る。 |
| 信頼性 | 時々のプロバイダー障害は許容できる。 | フォールバックポリシーと、リトライおよびフォールバックコストの共有台帳が必要。 |
| エージェントのワークフロー | アプリはテキストモデルしか呼び出さない。 | エージェントがモデル、ウェブ検索、ブラウザー操作、拡張ツール、画像、動画を呼び出す。 |
Flatkeyは後者の列向けに作られています。1つのAPIキー、1つの残高、1つの請求書、そして多くの公式モデル・ツールルートにまたがるリクエスト台帳を提供します。これは公式プロバイダーの価格設定を置き換えるものではありません。チームがそれらのコストをルーティングし、計測し、統制し、突き合わせるための単一の場所を提供します。ゲートウェイ手数料と運用コストの観点については、AI gateway pricingをご覧ください。
5つのワークロード例
1. サポートチャット
サポートチャットは通常、入力は中程度、出力は短めで、件数は多くなります。次を比較してください。
- システムプロンプトとポリシーテキストのプロンプトキャッシュヒット率。
- 回答タイプごとの出力トークン予算。
- より強力なモデルへのエスカレーション率。
- メッセージ単価だけでなく、解決済み会話あたりのコスト。
このワークロードでは、安価で高速なモデルでも、解決品質を高く保てるなら勝てます。安いモデルによって引き継ぎや編集の割合が増えるなら、見かけ上のトークン節約は消えてしまいます。
2. コーディングエージェント
コーディングエージェントは、長いコンテキスト、ツール呼び出し、長文出力、複数回の再試行を伴うことがよくあります。次を比較してください。
- リポジトリ検索やファイル読み取り後のコンテキストサイズ。
- キャッシュ可能なプロジェクト指示。
- 承認済みタスクあたりのツール呼び出し回数。
- 過負荷ルートによる再試行の無駄。
- マージ済み変更または承認済みパッチあたりのコスト。
ここでは、ai model pricing comparison に台帳が必要になります。1回のエージェント実行には、モデル呼び出し、ツール呼び出し、フォールバック呼び出し、失敗した試行が含まれる場合があります。
3. RAG回答生成
RAGワークロードは、取得したコンテキストと回答の長さに大きく左右されます。次を比較してください。
- 取得された平均トークン数。
- 安定したプロンプト接頭辞の割合。
- 繰り返し文書に対するキャッシュ挙動。
- 引用またはグラウンディングのコスト。
- 事実性に関する評価通過率。
入力トークンが安いという理由だけでモデルを選ばないでください。必要なコンテキストが2倍になったり、評価に落ちる回答を生成したりするなら、承認済み回答あたりのコストは高くなる可能性があります。これが主な移行判断であれば、how to compare AI model prices の詳細なワークシートを使ってください。
4. バッチ分類
バッチ分類は、結果が遅れても問題ないことが多いです。次を比較してください。
- プロバイダーにバッチ、フレックス、または遅延処理の階層があるか。
- 最大バッチサイズと完了ウィンドウ。
- エラー再実行コスト。
- 出力スキーマ検証の通過率。
- 承認済み行あたりの総コスト。
プロバイダーがバッチ価格を低く提供していても、その節約は、ワークフローが待機可能で、再試行プロセスがきれいな場合にのみ適用されます。
5. 画像と動画の生成
画像と動画のAPIは、トークンだけのスプレッドシートにはほとんど収まりません。次を比較してください。
- 出力単位: 画像、秒、クリップ、解像度、トークン、またはクレジット。
- 生成失敗時の課金ルール。
- 編集と再生成の割合。
- 人手による承認率。
- 承認済みクリエイティブ資産あたりのコスト。
メディアパイプラインでは、トークンモデルと生成モデルを別々のワークシートタブに分け、その後、承認済みワークフローコストに集計してください。単位経済性があまりにも異なるため、1つの混在行にはできません。
7ステップの価格比較ワークフロー
- ワークロードを固定する。 サポート回答、コーディングエージェントのパッチ、RAG回答、バッチ分類、画像生成、動画生成など、実際のタスクファミリーを1つ選びます。
- 現在の公式価格を収集する。 プロバイダーの価格ページ、Flatkeyのモデルページ、確認日を使用します。出典URLのない転載された料金表は避けます。
- 代表的なトラフィックを再現する。 ルート間で同じプロンプト、入力、出力上限、ツールポリシー、検証器を使用します。
- 課金対象の単位をすべて記録する。 入力トークン、キャッシュ済みトークン、出力トークン、メディア単位、ツール呼び出し、再試行回数、エラー、ステータスを取得します。
- 受理された結果を採点する。 人手レビュー、自動検証器、またはタスク固有の合否チェックを使用します。
- 実効コストを計算する。 総ルートコストを総リクエスト数ではなく、受理された結果数で割ります。
- 運用上の制御を追加する。 勝ったルートが、予算上限、請求要件、キーガバナンス、データ保持、インシデント時のフォールバックも満たすかを判断します。
その結果、エンジニアリング、プロダクト、調達のいずれも説明責任を果たせる価格決定になります。
最小限のダッシュボード表示
ルート比較
テキスト、画像、動画のルートを1つの表で表示します。
| ルート | ネイティブ単位 | ネイティブコスト項目 | 受理項目 | 正規化KPI |
|---|---|---|---|---|
| テキストモデル | トークン | 入力、出力、キャッシュトークン | 受理された回答 | 受理された回答あたりのコスト |
| コーディングエージェント | トークン+ツール | トークンおよびツールコスト | マージされたPR、解決済みチケット、完了したタスク | 完了したワークフローあたりのコスト |
| 画像モデル | 画像またはトークン単位 | 生成画像、出力画像トークン | 受理された画像 | 受理された画像あたりのコスト |
| 動画モデル | 秒、クリップ、またはプロバイダー単位 | 解像度ごとの生成秒数 | 受理されたクリップ | 受理されたクリップあたりのコスト |
機能別予算
プロバイダーだけでなく、機能ごとにグループ化します。プロダクトチームにとっては、オンボーディング、チャット、クリエイティブ生成、検索、エクスポートのどれが支出を押し上げているかが分かるため、ベンダーの請求書よりも有用です。
推奨カラム:
featureroute_typerequestsaccepted_resultsacceptance_ratetotal_cost_usdcost_per_accepted_resultp95_latency_msfallback_rateretry_rate
プロバイダーとモデルの変化
各プロバイダーは、モデルの利用可能性、価格、ライフサイクルのステータスを変更します。以下を保存します:
- 価格ソースURL。
- 価格確認日。
- モデルバージョンまたはルートID。
- 単位タイプ。
- キャッシュポリシー。
- 使用している場合は、バッチ割引ポリシー。
- 廃止またはライフサイクルに関する注記。
これにより、ai model pricing comparison は初期のモデル選定時だけでなく、公開後も有用なものになります。
利益率のガードレール
すべてのAI機能に、簡単な利益率ルールを追加します:
max_ai_cost_per_customer_action =
expected_revenue_per_action * target_ai_cost_percentage
例:
もし顧客アクションで40セントの粗利が得られ
AIコストを20%未満に抑える必要があるなら、
ルート予算は受理された結果1件あたり8セントです。
これにより、モデル選定が抽象的なベンチマークスコアではなく、ビジネスに結びつきます。
よくある間違い
| 間違い | 代わりに行うこと |
|---|---|
| 入力トークン単価だけを比較する | 入力、キャッシュ済み入力、出力、メディア、ツール、再試行、受理結果を比較します。 |
| テキスト、画像、動画、ツールを1つの単位に混ぜる | ネイティブ単位を保持し、そのうえで各ルートを受理結果あたりのコストに正規化します。 |
| プロンプトキャッシュを無視する | 安定したプロンプト接頭辞とキャッシュヒット率を測定します。 |
| バッチ適格性を無視する | レイテンシーに敏感なワークロードとオフラインワークロードを分けます。 |
| 古いコピー済み価格表を信頼する | 公式ソースURLと確認日を保存します。 |
| ゲートウェイコストを単なる上乗せとして扱う | ガバナンス、フェイルオーバー、利用量エクスポート、請求書、エンジニアリング時間を含めます。 |
| 最安のリクエストを選ぶ | 品質と信頼性の要件を満たす、最も安い受理結果を選びます。 |
よくある質問
AIモデルの価格を比較する最良の方法は何ですか?
AIモデルの価格を比較する最良の方法は、各プロバイダーのネイティブな課金単位を保持し、そのうえで各ルートを受理結果あたりのコストに正規化することです。テキストでは、これは受理された回答あたりのコストかもしれません。画像では、受理された画像あたりのコストを使います。動画では、受理されたクリップあたり、または受理されたクリップ秒あたりのコストを使います。
AIモデル比較チャートには何を含めるべきですか?
AIモデル比較チャートには、モデルまたはルートID、プロバイダー、価格ソースURL、確認日、入力トークン、キャッシュ済み入力、出力トークン、メディア単位、ツール呼び出し、再試行率、フォールバック率、受理率、レイテンシー、受理結果あたりのコストを含めるべきです。
価格表にはプロバイダーの正確な価格を含めるべきですか?
内部のワークシートでは正確な価格を使い、各行の横にソースURLと確認日を記録してください。公開される静的な記事では、出典のない転載された料金表は避けるべきです。提供元の価格、モデル名、割引、ライフサイクルの状態はすぐに変わる可能性があるためです。
トークンコストと画像・動画コストをどのように比較しますか?
すべてのルートを無理にトークンへ変換しないでください。台帳ではネイティブの単位を保持し、そのうえで accepted_task_cost_usd、accepted_image_cost_usd、accepted_clip_cost_usd のような正規化フィールドを追加します。
AIモデル価格比較でFlatkeyはどこで役立ちますか?
Flatkeyは、多くのモデルやツールのルートにまたがって、1つのキー、1つの残高、1つの請求書、1つの使用台帳で運用したいときに役立ちます。これにより、個別の提供元アカウントを先に突き合わせることなく、テキスト、画像、動画、エージェントのコストを比較しやすくなります。
価格はどのくらいの頻度で再確認すべきですか?
大きなルーティング変更、契約レビュー、予算予測の前には、必ず価格を再確認してください。変化の速い本番ワークロードでは、重要なルートの価格を毎週更新し、さらに提供元があなたの使うモデルをリリース、改称、提供終了、または再価格設定した直後にも更新してください。
最終的なポイント
AIモデル価格比較は、見た目がきれいな価格表ではありません。モデル選定のためのオペレーティングシステムです。
提供元の単位を保持してください。受け入れトラッキングを追加してください。各ルートを受け入れられた結果あたりのコストに正規化してください。そのうえで、見かけ上もっとも安いルートではなく、製品マージン、信頼性、ガバナンスを改善するルートを選びます。
Flatkeyを使えば、その比較は1つのキー、1つの残高、1つの台帳の上に載せられるため、開発者、プロダクトチーム、調達チームは、分散した提供元の請求書からルート単位のコスト判断へ移行できます。



