1つのモデルだけでなく複数のモデルにまたがってプロンプトをテストしている場合、すべてのリクエストを単なるチャットトークンとして扱った瞬間に、コスト予測は破綻します。あるチームは gpt-5-mini で短いテキストプロンプトを実行し、claude-sonnet-4-6 で長めの評価スイープを回し、gpt-image-2 で画像バリエーションを試し、その後にローンチ前の動画テストをいくつか行うかもしれません。それは 1 種類の請求形状ではありません。異なるユニット種別、リトライパターン、承認ループが積み重なったものです。
このガイドでは、トラフィックが増える前の AI API 支出予測のための実践的な マルチモデルのプロンプトテストワークフローを紹介します。初日から完璧な財務精度を目指すのではありません。目的は、プロンプトテストを創業者、オペレーター、エンジニアリングリードの誰もが読める小さな予測ワークシートに変え、ローンチ週の想定外を防ぐことです。
2026年7月19日（日）時点で、Flatkey の公開ホームページには、製品が引き続き 公式 API のみ、1時間ごとに検証 と説明されており、1つのキーの背後に160以上のフロンティアモデル、および https://router.flatkey.ai/v1 という OpenAI 互換のベース URL があると記載されていました。公開価格ページにも、引き続き次のように書かれていました。
- すべてのチャージでボーナスクレジットが付与される:
$10で+$3、$20で+$8、$200で+$100 - 1つの残高で GPT、Claude、Gemini、DeepSeek、画像、音声、動画モデル全体にルーティングできる
- 使用量はモデル、トークン種別、リクエストログごとに計測される
この製品形態が重要なのは、優れた予測ワークフローが単なる価格表ではないからです。モデル行のためのライブソース、共有残高ビュー、そしてプロンプトテストが実際にどこで費用を消費しているかを示すログが必要です。
短い答え
次の順序で進めます。
- 価格を比較する前に、予測を テキスト、画像、動画 の各レーンに分ける。
- 実ユーザートラフィックとは別に、プロンプトテストのトラフィックを見積もる。
- 各レーンごとに、ベースラインモデル、フォールバックモデル、そして 承認ループの倍率 を1つずつ予測する。
- チャージ前に、リトライ、キャッシュミス、却下されたクリエイティブのためのバッファを追加する。
- ローンチ前にライブの価格ページを再確認し、その後はクォータ上限を固定し、トラフィック開始後にリクエストログを監視する。
これが中核となる マルチモデルのプロンプトテストワークフローです。多くのチームは 2 番目か 4 番目の手順を飛ばし、見た目は安価なベンチマークが高額な承認ループに変わってから驚きます。
なぜ多くのプロンプトテスト予測は失敗するのか
創業者はたいてい、次のような単純な問いから始めます。「ローンチ時にこのモデルを実行したら、いくらかかるのか？」
その問いは広すぎます。役に立つ予測は、5つの小さな問いに答えられなければなりません。
| 質問 | 何が変わるか |
|---|---|
| これらは社内のプロンプトテストですか、それとも実際のユーザーからのリクエストですか？ | テスト量は通常、突発的で反復的です。ローンチ時のトラフィックはより安定しており、予測が難しくなります。 |
| このレーンはテキスト、画像、動画のどれですか？ | 課金単位が変わるため、1つの混在シートではすぐに誤解を招きます。 |
| 1つの出力を出す前に、何種類のバリエーションを承認しますか？ | クリエイティブレビューのループは、トークンの増加だけよりも速く支出を増やすことがあります。 |
| デフォルトのモデルはどれで、フォールバックはどれですか？ | 信頼性ポリシーによっては、トラフィックが横ばいでも加重平均コストが変わることがあります。 |
| リクエストのうち、再試行、キャッシュミス、拒否が発生すると想定される割合は何パーセントですか？ | ここで、きれいなデモ用の計算はたいてい破綻します。 |
これらの質問を飛ばすと、予測にはなりません。せいぜい期待的な平均があるだけです。
公開日のソーススナップショット
以下のワークフローは、2026年7月19日の日曜日に再確認した公開 Flatkey の表面情報のみを使用しています。
| ソース | 確認日 | 有用な事実 |
|---|---|---|
https://flatkey.ai/ |
2026年7月19日 | 公開ホームページには、公式APIのみ、1時間ごとの検証、1つのキー、160以上のフロンティアモデルと、引き続き記載されています。 |
https://flatkey.ai/pricing |
2026年7月19日 | 公開価格ページには、トップアップのボーナスクレジットは永久、1つの残高でテキスト/画像/音声/動画をカバー、利用状況はモデル、トークン種別、リクエストログで計測されると、引き続き記載されています。 |
https://router.flatkey.ai/api/pricing |
2026年7月19日 | 公開価格APIは、pricing_version: group-model-ratio-v1、176行、175のトークン形式の行、1つの固定価格行、そして openai、anthropic、gemini、image-generation、openai-response、openai-video、video 向けの対応エンドポイントファミリーを返しました。 |
2026年7月19日時点のホームページのライブボードでは、概算のテキストレーン予算に役立つ入力側レートの例も公開されていました。
| モデル | 公開ホームページの入力レート |
|---|---|
gpt-5.5 |
$3.33 / M in |
claude-sonnet-4-6 |
$2.00 / M in |
gpt-5.4 |
$1.67 / M in |
claude-opus-4-8 |
$3.33 / M in |
deepseek-v4-flash |
$0.056 / M in |
これらは永続的な定数ではなく、公開日の例として扱ってください。この記事は予測についてのものなので、プロセスのほうが、価格のある1日分の数字よりも重要です。
マルチモデルのプロンプトテストワークフロー
ステップ1: テストトラフィックとローンチトラフィックを分ける
社内テストと公開トラフィックを混ぜないでください。プロンプトラボには、しばしば次のような特徴があります。
- 繰り返しの多いプロンプトが多い
- 手動での再実行が多い
- 長いプロンプトが多い
- 却下される出力が多い
ローンチ時のトラフィックには、しばしば次のような特徴があります。
- より短い、またはより正規化されたプロンプト
- より安定したボリューム
- 手動での再実行回数の削減
- より厳しいクォータ要件
まずは2つの別々のシートから始めます:
| シート | 目的 | 一般的な担当者 |
|---|---|---|
| プロンプトテスト予測 | ローンチ前の実験、モデル比較、承認ループ | プロダクト、オペレーション、AIエンジニア |
| ローンチトラフィック予測 | リリース後の想定ユーザー数 | 創業者、財務、エンジニアリングリード |
シートを1つしか作らないと、テスト予算は通常、本番予算の中に隠れてしまいます。
ステップ2: 計算を始める前にモダリティで分ける
ここで多くのチームが最初の本当のミスをします。テキスト、画像、動画のワークフローを、単純な「リクエストあたりのコスト」列ひとつで共有してはいけません。
| レーン | 主要単位 | 予測の主因 |
|---|---|---|
| テキストプロンプト | 入力トークン、出力トークン、キャッシュ済みトークン | プロンプト長、応答長、フォールバック率 |
| 画像生成 | モデル固有の画像価格と再レンダリング回数 | 承認済み画像1枚あたりのコンセプト数、編集ループ、解像度の選択 |
| 動画生成 | 秒数、またはプロバイダー固有の生成単位 | クリップの長さ、再レンダリング、キュー失敗、承認ループ |
Flatkey自身の公開ページも、この分離を裏付けています。料金ページには、1つの残高でテキスト、画像、音声、動画にまたがってルーティングできるとありますが、それは1つの予測式でそれらすべてをカバーすべきという意味ではありません。
ステップ3: コストを見積もる前にテストマトリクスを定義する
実際のマルチモデルのプロンプトテストワークフローは、価格表ではなくテストマトリクスから始まります。
次のような表を使います:
| レーン | 目的 | デフォルトモデル | フォールバックモデル | 1日あたりのテスト数 | 承認または再試行係数 |
|---|---|---|---|---|---|
| テキスト | 指示品質の比較 | claude-sonnet-4-6 |
gpt-5.4 |
500 | 1.10 |
| テキスト | 低コストの一括評価スイープ | deepseek-v4-flash |
gpt-5-mini |
2,000 | 1.05 |
| 画像 | クリエイティブなコンセプトテスト | gpt-image-2 |
ライブ料金ページの2つ目の画像モデル | 80 | 2.50 |
| 動画 | ローンチトレーラーのプロンプトスイープ | /pricingのライブ動画行 |
/pricingのバックアップ動画行 |
12 | 1.80 |
要点はシンプルです。すべてのモデルが1回だけ呼ばれ、常に承認されるという空想ではなく、実際に実行するワークフローを予測してください。
ステップ4: まずはテキストレーンのベースライン計算を使う
テキストプロンプトでは、入力側の保守的な見積もりから始めます。これは速く、完全なトークンモデルを構築する前に、明らかな予算問題を見つけるのにたいてい十分です。
ベースラインのテキスト式
baseline text spend
= requests
× average input tokens
× input-side price per 1M
÷ 1,000,000
× approval or retry factor
例1: Claude Sonnet 4.6で1日500件のテストプロンプト
500 リクエスト
× 1,800 入力トークン
× $2.00 / 100万入力
÷ 1,000,000
× 1.10 リトライ係数
= 1日あたりのベースライン入力費用 $1.98
例 2: DeepSeek V4 Flash での 1日 2,000 件の低コスト評価プロンプト
2,000 リクエスト
× 1,800 入力トークン
× $0.056 / 100万入力
÷ 1,000,000
× 1.05 リトライ係数
= 1日あたりのベースライン入力費用は約 $0.21
これは完全なトークン計算の代わりにはなりません。素早いふるい分けには役立ちます。ベースラインの時点で既に高すぎるようなら、完全な予測でも救えません。
ステップ 5: ベースラインを通過してから、完全なテキスト予測を追加する
ベースラインが許容範囲に見えたら、完全なトークン表に進みます。
| 変数 | 意味 |
|---|---|
| キャッシュされない入力トークン | 通常の入力レートで課金されるプロンプトトークン |
| キャッシュされる入力トークン | 対応している場合にキャッシュレートで課金される再利用可能なプロンプトコンテキスト |
| 出力トークン | 生成されたトークン |
| フォールバック比率 | バックアップモデルに送られるリクエストの割合 |
| リトライ係数 | 失敗、QAの再実行、またはプロンプトの書き換えによって発生する追加実行回数 |
完全なテキストの式
1日のテキスト費用
= リクエスト数
× (
キャッシュされない入力トークン × キャッシュされない入力レート
+ キャッシュされる入力トークン × キャッシュレート
+ 出力トークン × 出力レート
)
÷ 1,000,000
× リトライ係数
Flatkey の公開価格 API はここで便利です。行構造により、トークン型のコスト要素がすでに別々のフィールドとして公開されているからです。たとえば、2026年7月19日 には次のようになります。
| モデル | 入力側フィールド | 出力側フィールド | キャッシュフィールド |
|---|---|---|---|
gpt-5-mini |
0.02 |
8 |
0.12 |
claude-sonnet-4-6 |
1.5 |
5 |
0.1 |
gpt-image-2 |
3.325 |
6 |
0.251127819549 |
テストしている正確なモデルについては、実際の行を使ってください。見た目が「十分近い」からといって、近い別の行を流用しないでください。
ステップ 6: 画像テストは単発の出力ではなく、承認ループとして予測する
画像コストは、多くの運用担当者が予算を甘く見積もる領域です。完成した 1 枚の画像の裏に、複数の却下された試行が隠れていることがあります。
このワークシートを使ってください。
| 入力 | 例 |
|---|---|
| テストするコンセプト数 | 20 |
| コンセプトあたりの平均レンダリング回数 | 3 |
| 承認されたコンセプトあたりの平均編集回数 | 2 |
| 画像操作の合計 | 100 |
| ライブ価格行 | 公開日に /pricing から取得 |
| 却下された実行のバッファ | 15% |
画像予測の式
画像テスト費用
= 画像操作の合計
× ライブの画像モデル価格
× 却下バッファ
重要な運用ルールはこれです。画像の予測をテキストのトークン表に入れないでください。Flatkey の公開ページでは、1つの残高でテキストと画像の両方に対応できることが明確に示されていますが、社内の予算計算では、承認ループごとに別々の計算が必要です。
ステップ 7: 動画テストを尺と再レンダリング係数で予測する
動画のプロンプトテストは、承認済みのクリップの背後に複数の失敗生成や修正版が積み上がることが多いため、見積もりがさらに甘くなりがちです。
2026年7月19日に確認した公開ホームページでは、Flatkey は引き続き、動画生成をテキストモデルと同じ前払い残高で秒単位課金すると説明していました。つまり、動画用のワークシートは次のようになるはずです。
| 入力 | 例 |
|---|---|
| テストするコンセプト数 | 6 |
| コンセプトあたりの平均クリップ数 | 2 |
| 平均尺 | 8 sec |
| 再レンダリング係数 | 1.8 |
| ライブの秒単価 | ローンチ週に /pricing から取得 |
動画予測の式
video test spend
= concepts
× clips per concept
× seconds per clip
× live per-second price
× rerender factor
繰り返しますが、動画は必ず別扱いにしてください。クリップをテキストモデルのシートにおける単なる別リクエストだと見なしてはいけません。
ステップ 8: 入金前にローンチ用バッファを追加する
テキスト、画像、動画のテスト費用を合計したら、ローンチ用のバッファを追加します。2026年7月19日に確認した料金ページでは、Flatkey は前払い制であり、利用量はリクエストログを通じて計測されることが明記されています。そのため、バッファは単なる金額の整理ではなく、運用上も有用です。
次のようなバッファ表を使ってください。
| リスク | 推奨バッファ |
|---|---|
| テキストの再試行とキャッシュミス | 10% |
| 画像の拒否または追加編集 | 15% to 30% |
| 動画の再レンダリング | 20% to 40% |
| ローンチ週の未知要素 | 10% |
そのうえで、合計に合う入金額を選びます。
| 入金オプション | 2026年7月19日時点の公開料金ページの値 |
|---|---|
$10 |
$10 支払いで $13 分のクレジットを取得 |
$20 |
$20 支払いで $28 分のクレジットを取得 |
$200 |
$200 支払いで $300 分のクレジットを取得 |
小規模なプロンプトラボにとって、正しい問いは「最も安い入金額はいくらか」ではありません。「ローンチ準備の途中で運用停止を強いられずに、テストループを回し続けられる入金額はどれか」です。
再利用できるシンプルな計算表
本格的なプロンプトテストの各サイクルの前に、これをシートへコピーしてください。
| レーン | モデル | テスト量 | 単位入力 | 料金ソース | リトライ係数 | 推定支出 |
|---|---|---|---|---|---|---|
| テキスト | primary model | 平均入出力トークン | live pricing row | |||
| テキスト | fallback model | 平均入出力トークン | live pricing row | |||
| 画像 | primary image model | 承認済みアセットごとの操作回数 | /pricing |
|||
| 動画 | primary video model | 承認済みクリップごとの秒数 | /pricing |
|||
| バッファ | all lanes | 小計 × リスク係数 | internal rule |
この表が不完全なら、ローンチ予測も不完全です。
最初のライブトラフィック日後に確認すべきこと
料金ページでは、利用量はモデル、トークンタイプ、リクエストログごとに計測されると示されています。つまり、初日のレビューでは次の点に答えられる必要があります。
- 実際に最も多くのリクエストを処理したのはどのモデルか？
- フォールバックトラフィックは想定比率と一致していたか？
- 出力トークンはテスト仮定より実質的に多かったか？
- どのプロンプトファミリーが最も多くの再実行を生んだか？
- 画像または動画の承認ループはテキストレーンより高くついたか？
このフィードバックループこそが、マルチモデルのプロンプトテストワークフローを、単発のスプレッドシートではなく、再現可能なコストガバナンスの実践へと変えるものです。
よくあるミス
| ミス | なぜ問題か |
|---|---|
| テキストとメディアを1件あたりの平均コストに混ぜてしまう | 画像と動画の支出を左右する本当の要因を隠してしまう |
| デフォルトモデルだけを予測する | フォールバックが請求額に与える影響を無視してしまう |
| テスト量をローンチ量と同じだとみなす | 社内のバースト挙動と実際のユーザー行動を混同してしまう |
| 承認ループを無視する | 画像と動画のコストを最も大きく過小評価してしまう |
| リスクバッファなしで補充する | 回避可能なローンチ週の中断を招く |
FAQ
最も安いモデルから始めるべきですか？
自動的にはそうではありません。まずは作業内容に最も合うモデルから始め、そのうえで、リトライ、QA作業、フォールバック量を増やさずに安価なモデルがトラフィックの一部を担えるかをテストしてください。
なぜメディア費用をトークン用ワークシートの外に置くのですか？
画像と動画の承認は、別の形で増えるからです。テキストプロンプトは1回のリトライで済むかもしれませんが、動画コンセプトは誰かが承認するまでに複数回の再レンダリングが必要になることがあります。
予測はいつローンチ可能な十分な精度になりますか？
次の条件がそろったときです。
- ベースラインとテキスト全体の見積もりがある
- 必要に応じて画像と動画のワークシートを分けている
- 重要な各レーンにフォールバックモデルを明示している
- 前払い残高の判断が済んでいる
- 1日目に向けたクォータと利用ログの確認準備ができている
最終判断の前に、どこでモデル行を比較すべきですか？
現在のルートと請求コンテキストについては、ライブのFlatkey pricing pageを使用し、既存のAI model pricing comparison guideで隣接するオプションを比較してください。最初のページは立ち上げに役立ちます。2つ目のページは、どの行をテスト対象にするべきかの判断に役立ちます。
