OpenAIの請求書には、先月4,237ドル使ったと書かれています。しかし、そのうち3,100ドルは暴走した要約エンドポイントから、700ドルは月に50ドル支払っている顧客から、437ドルは誰も使わない機能から発生したことは書かれていません。ダッシュボードは、価格設定、キャパシティ、ロードマップの決定に必要な情報が隠されています。
このガイドでは、OpenAI APIのコストを適切に割り当てる方法を説明します。すべてのリクエストにメタデータをタグ付けし、機能、ルート、顧客ごとに支出を集計し、キーごとの予算上限を設定し、コストが不明瞭な項目でなくなるようにプロンプトを設計します。LLM機能をリリースする場合、これはAIを暴走する費用から管理された製品コストに変える作業です。
TL;DR
すべてのOpenAI API呼び出しに構造化されたメタデータ（機能、ルート、customer_id、環境）をタグ付けし、トークン数と計算されたコストをキャプチャする構造化ログ行をリクエストごとに発行し、ウェアハウスでタグごとに集計します。OpenAIダッシュボードでキーごとの予算上限を設定し、時間ごとの支出異常を警告し、数値を信頼する前にApidogシナリオテストでラッパーをエンドツーエンドで検証します。
はじめに
火曜日に新しいAI機能をリリースしました。金曜日の朝には、CFOからDMで「OpenAIの利用料が40%も跳ね上がったのはなぜだ」と尋ねられています。ダッシュボードを開くと、合計支出が上昇していることが示されています。しかし、どの機能、どの顧客、どのルートが原因であるかは示されていません。あなたは推測を始めます。
これは、本番環境でLLMワークロードを実行するすべてのチームが直面するギャップです。OpenAIの請求インターフェースは、経理部門向けに構築されており、エンジニアリングの帰属には対応していません。日々の合計、モデルの内訳は表示されますが、それだけです。リクエストの形状、それをトリガーした顧客、モデルを呼び出した機能は表示されません。
その解決策は概念的には単純ですが、実行は容赦がありません。すべてのAPI呼び出しをメタデータレイヤーでラップします。すべてのリクエストを構造化されたストアに記録します。タグごとに集計します。上限を設定します。差分についてアラートを発します。この記事の終わりまでに、具体的なデータモデル、2つの動作するコードサンプル、Apidogを使用した検証ワークフロー、そしてOpenAI usage APIを構築、購入、または直接使用するかどうかを決定できるツール比較が得られるでしょう。
コスト計算を決定する価格設定のコンテキストについては、GPT-5.5の価格内訳を参照してください。開発者ツール側での関連する請求帰属の問題については、APIチーム向けのGitHub Copilot利用料請求を参照してください。OpenAI APIの基本については、公式のOpenAI APIリファレンスを参照してください。
OpenAIの課金ダッシュボードでは不十分な理由
今すぐOpenAIの課金ページを開いてください。日々の支出チャート、モデルの内訳、および使用制限が表示されます。これが表示されるすべての情報です。アプリケーションが1つ、顧客が1人、機能が1つの場合は問題なく機能します。しかし、同じ製品内に複数の機能、複数の顧客、複数の環境、複数の開発者がいると、ダッシュボードは役に立たなくなります。
不足している点は以下の通りです。
コンテキストのない総支出。 ダッシュボードには、昨日GPT-5.5に312ドルを費やしたと表示されます。それが、1人の顧客がサポートチャットのエンドポイントを5万回叩いたためなのか、あるいは誰かがフラグを立てっぱなしにしていたために知識ベース全体を再要約したバックグラウンドジョブによるものなのかは示されません。チャート上では両方とも同じに見えます。
機能ごとの内訳なし。 OpenAIはAPIキーとモデルでリクエストをタグ付けします。しかし、あなたの機能、ルート、顧客ID、環境ではタグ付けしません。これらが必要な場合は、自分で構築する必要があります。ダッシュボードには製品分析のためのネイティブなディメンションはありません。
レポートの遅延。 使用状況データは数十分から数時間の遅延を伴って表示されます。暴走ループがダッシュボードに表示される頃には、すでにクレジットカードを使い果たしているでしょう。履歴チャートではなく、リアルタイムの追跡が必要です。
アラート機能の欠如。 OpenAIは組織ごとに1つの予算上限と1つのソフトな通知メールを提供します。キーごとのアラート、機能ごとのしきい値、異常検出はありません。「チャットエンドポイントが1時間に50ドルを超えたら私に通知する」といった機能が必要な場合は、自分で構築する必要があります。
顧客帰属なし。 AI機能を備えたB2B SaaSを販売している場合、どの顧客がどの支出を発生させたかを知る必要があります。そうすることで、価格設定、スロットリング、またはアップセルを行うことができます。ダッシュボードは「今月、顧客Xにいくらかかっているのか」という質問には答えられません。財務チームは、顧客ごとの粗利益を計算するためにその数値が必要です。それがないと、あなたのユニットエコノミクスは推測になってしまいます。
サービスアカウントとプロジェクトレベルのキーは役立ちますが、部分的です。 OpenAIのプロジェクトキーを使用すると、プロジェクトごとに使用状況を分割できます。これにより、1レベルの帰属が得られます。しかし、機能ごと、顧客ごと、またはルートごとの帰属は得られません。重要な質問に答えるには、依然としてアプリケーションレベルのメタデータが必要です。OpenAI usage APIは、リクエストごとではなく、プロジェクトごとに集計されたデータを返します。
このパターンは、大規模にLLM機能を展開するすべてのチームで繰り返されます。Dev.toのスレッド「OpenAIはいくら使ったかは教えてくれる。どこで使ったかは教えてくれない。だから私はダッシュボードを作った」が拡散したのは、この問題を明確に指摘したからです。「測定できないものは管理できない」。ネイティブのダッシュボードは財務上の質問に答えますが、あなたは製品上の質問に答える必要があります。
コスト帰属のデータモデル
コスト帰属は1つの決定から始まります。それは、すべてのOpenAIリクエストに対して、タグ付きイベントがウェアハウスに書き込まれるということです。そのイベントが分析の単位となります。スキーマを正しく設定すれば、残りの作業（ダッシュボード、アラート、上限設定）はSQLクエリになります。
必要な最小限のスキーマは次のとおりです。
| カラム | 型 | 例 | 重要性 |
|---|---|---|---|
request_id |
uuid | 7a91... |
冪等性、重複排除、リトライ |
timestamp |
timestamptz | 2026-05-06T14:23:01Z |
時系列クエリ、異常検出 |
feature |
text | support-chat |
呼び出しをトリガーしたプロダクトの表面 |
route |
text | /api/v1/chat/answer |
HTTPルートまたはバックグラウンドジョブID |
customer_id |
text | cust_4291 |
顧客ごとの支出、粗利益 |
environment |
text | prod, staging, dev |
開発コストを顧客帰属から除外 |
model |
text | gpt-5.5, gpt-5.4-mini |
モデルによって価格が異なる |
prompt_tokens |
int | 15234 |
レスポンスからの入力トークン数 |
completion_tokens |
int | 812 |
レスポンスからの出力トークン数 |
reasoning_tokens |
int | 4500 |
推論トークン（出力課金としてカウント） |
cached_tokens |
int | 12000 |
プロンプトキャッシュヒット、50%で課金 |
latency_ms |
int | 2341 |
コストとユーザー体験の相関関係用 |
cost_usd |
numeric(10,6) | 0.045672 |
トークン数から書き込み時に計算 |
prompt_cache_key |
text | system-v3 |
機能ごとのキャッシュヒット率を追跡 |
error_code |
text | null, 429 |
リトライの二重カウントを避けるため |
コストはクエリ時ではなく、書き込み時に計算してください。価格は変動するため、リクエストが発生した日のレートを反映する固定の数値が必要になります。GPT-5.5の計算ロジックは次のようになります。
PRICING = { # USD per 1M tokens, as of May 2026
"gpt-5.5": {"input": 5.00, "cached": 2.50, "output": 30.00},
"gpt-5.5-pro": {"input": 30.00, "cached": 15.00, "output": 180.00},
"gpt-5.4": {"input": 2.50, "cached": 1.25, "output": 15.00},
"gpt-5.4-mini": {"input": 0.25, "cached": 0.125, "output": 2.00},
}
def compute_cost_usd(model, prompt_tokens, cached_tokens, completion_tokens, reasoning_tokens):
rates = PRICING[model]
uncached = max(0, prompt_tokens - cached_tokens)
input_cost = (uncached * rates["input"]) / 1_000_000
cache_cost = (cached_tokens * rates["cached"]) / 1_000_000
output_cost = ((completion_tokens + reasoning_tokens) * rates["output"]) / 1_000_000
return round(input_cost + cache_cost + output_cost, 6)
推論トークンは出力としてカウントされます。OpenAI APIはそれらを`usage.completion_tokens_details.reasoning_tokens`で返しますが、出力レートで課金されます。これを見逃すと、Thinkingモードのすべての呼び出しでコストを過少に見積もることになります。完全な価格計算については、GPT-5.5の価格内訳を参照してください。
次にOpenAIクライアントをラップします。すべての呼び出しは1つの関数を介して行われます。その関数はメタデータを受け取り、リクエストを行い、イベントを書き込みます。
import time, uuid, json, logging
from openai import OpenAI
client = OpenAI()
logger = logging.getLogger("llm.cost")
def call_with_attribution(
*, feature, route, customer_id, environment,
model, messages, **openai_kwargs
):
request_id = str(uuid.uuid4())
started = time.time()
error_code = None
response = None
try:
response = client.chat.completions.create(
model=model, messages=messages, **openai_kwargs
)
except Exception as e:
error_code = getattr(e, "code", "unknown_error")
raise
finally:
latency_ms = int((time.time() - started) * 1000)
u = response.usage if response else None
prompt_tokens = getattr(u, "prompt_tokens", 0)
completion_tokens = getattr(u, "completion_tokens", 0)
cached_tokens = getattr(getattr(u, "prompt_tokens_details", None), "cached_tokens", 0) or 0
reasoning_tokens = getattr(getattr(u, "completion_tokens_details", None), "reasoning_tokens", 0) or 0
cost_usd = compute_cost_usd(model, prompt_tokens, cached_tokens, completion_tokens, reasoning_tokens)
logger.info(json.dumps({
"event": "openai.request",
"request_id": request_id,
"feature": feature,
"route": route,
"customer_id": customer_id,
"environment": environment,
"model": model,
"prompt_tokens": prompt_tokens,
"completion_tokens": completion_tokens,
"reasoning_tokens": reasoning_tokens,
"cached_tokens": cached_tokens,
"latency_ms": latency_ms,
"cost_usd": cost_usd,
"error_code": error_code,
}))
return response
その単一のラッパーがあなたのコスト帰属の接点となります。製品内のすべての機能がこれを呼び出します。構造化されたログ行はあなたのウェアハウスへの入力です。ここから、既存のログパイプライン（Vector、Fluent Bit、Logstash、OTLPコレクター）を介して、BigQuery、ClickHouse、Snowflake、またはPostgresにログを送信します。追加のパイプラインもサービスも不要です。
Node.jsチームの場合も、構造は同じです。メタデータを受け取り、`response.usage`をキャプチャし、コストを計算してJSON行を書き込む関数でOpenAI SDKをラップします。プラットフォームがすでにイベントバス（Kafka、NATS、Pub/Sub）を運用している場合は、stdoutの代わりにそこにイベントを公開し、ダウンストリームのコンシューマがそれをウェアハウスとアラートシステムに拡散させることができます。
コスト追跡を構築し、Apidogでテストする
スキーマとラッパーは用意できました。次に、これを運用可能なものにしましょう。6つのステップです。
1. 直接のOpenAI呼び出しをラッパーに置き換える。 コードベースで`OpenAI(`と`client.chat.completions.create`をgrepしてください。すべてのヒットを`call_with_attribution(...)`呼び出しにします。`feature`と`route`を必須引数にし、グローバル変数ではなく呼び出しサイトで渡します。渡し忘れた場合、関数は「不明」とデフォルトにするのではなく、エラーを発生させるべきです。
2. 構造化ログを出力する。 各イベントにつき1行のJSON形式でstdoutにログを出力します。これらのイベントに特化してロガーレベルをINFOに設定します。デバッグノイズと混在させないでください。すでに構造化ロガー（structlog、pino、winston）を使用している場合は、それに組み込みます。
3. ウェアハウスで機能ごとに集計する。 イベントがBigQueryまたはClickHouseに到達すると、クエリは自動的に作成されます。
SELECT
feature,
DATE_TRUNC(timestamp, DAY) AS day,
COUNT(*) AS requests,
SUM(cost_usd) AS spend_usd,
SUM(prompt_tokens + completion_tokens) AS tokens,
AVG(latency_ms) AS avg_latency_ms,
SUM(cached_tokens) / NULLIF(SUM(prompt_tokens), 0) AS cache_hit_rate
FROM openai_events
WHERE environment = 'prod'
AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY feature, day
ORDER BY day DESC, spend_usd DESC;
4. ルートごとの支出をグラフ化する。 Grafana、Metabase、Looker、またはSupersetをテーブルに接続します。時間経過に伴う機能ごとの支出、時間経過に伴う顧客ごとの支出、および昨日の支出でソートされたトップ20ルートのテーブルという3つのビューを構築します。これがあなたの日々の運用ダッシュボードとなります。
5. リリース前にApidogでラッパーをテストする。 これは、ほとんどのチームがスキップして後悔するステップです。あなたのラッパーは構造化ログを書き込みます。スキーマが間違っている場合、ウェアハウスは密かに間違った情報を持ち、ダッシュボードは嘘をつきます。Apidogを使用して、サービスに対するエンドツーエンドテストを実行してください。
- 既知の`customer_id`と`feature`を持つリクエストをAIエンドポイントに送信するApidogシナリオを作成します。
- レスポンスとサイドチャネルログの出力（stdout、OTLP、ログエンドポイント）をキャプチャします。
- Apidogのレスポンスアサーションを使用して、ログペイロードに期待される`feature`、`route`、`customer_id`が含まれていること、および`cost_usd > 0`と`prompt_tokens > 0`であることを検証します。
- Apidog環境変数を使用して、ステージング環境と本番環境で同じシナリオを実行します。
- タグ付けされたリクエストをリプレイし、リトライされた呼び出しでコストが二重にカウントされないことをアサートします（ラッパーはリトライ時に`request_id`を再利用するべきです）。
この検証ステップに適したより広範なAPIテストアプローチについては、QAエンジニア向けのAPIテストツールを参照してください。コスト帰属カバレッジと組み合わせる契約優先アプローチについては、契約優先API開発を参照してください。
6. キーごとの予算上限とアラートを設定する。 OpenAIでは、環境ごとまたは機能ごとに1つのプロジェクトキーを作成できます。これを利用しましょう。`prod-support-chat`キー、`prod-summarization`キー、`staging-all`キーを作成します。OpenAIダッシュボードで厳格な上限を設定し、ある機能での暴走ループが組織全体の予算を使い果たさないようにします。さらに、独自のアラートを重ねて設定します。10分ごとに実行されるSQLクエリで、いずれかの機能が7日間の移動平均時間あたり支出の3倍を超えた場合にあなたに通知するようにします。PagerDuty、Opsgenie、またはSlack webhookのいずれも機能します。トリガーはOpenAIからではなく、あなたのウェアハウスから発生します。
ネイティブのキー上限とウェアハウス駆動型アラートの組み合わせにより、2層の防御が提供されます。ネイティブの上限は壊滅的な支出に対する最後の砦となり、ウェアハウスのアラートは上限が発動する前に緩やかな支出の増加を捉えます。
高度なテクニックとプロのヒント
基本的なパイプラインが稼働したら、最適化に進みます。
プロンプトキャッシング。 GPT-5.5では、キャッシュされたトークンに対して入力レートの50パーセントが課金されます。システムプロンプトを安定したプレフィックスとして構成し、リクエストごとの変数を最後に配置します。これを実行すると、チャットワークロードでのキャッシュヒット率が70パーセントを超えるのは一般的です。ダッシュボードで機能ごとの`cache_hit_rate`を追跡し、プロンプトの変更がヒット率を低下させるときを把握できるようにします。公式のOpenAIプロンプトキャッシングドキュメントには、適格性ルールが記載されています。
オフライン作業用のBatch API。 同期応答を必要としないものはすべてBatch APIを介して行われ、50パーセントの割引が適用されます。夜間要約、評価実行、埋め込みのバックフィル、ドキュメントの再処理などがこれにあたります。コストラッパーは引き続き適用されます。Batchエンドポイントを呼び出し、イベントに`batch_job_id`をタグ付けすることで、元のワークロードにそれらを帰属させることができます。
推論努力のチューニング。 GPT-5.5 Thinkingは、より高い`reasoning.effort`で同じモデルを使用します。各努力レベルは出力トークンを乗算します。機能を監査してください。`low`でも品質基準を満たすのに`medium`で実行していませんか？A/Bテストを実行し、品質とコストを追跡し、品質が維持される場合はより安価なオプションを出荷してください。詳細な計算については、GPT-5.5 APIの使用方法を参照してください。
コンテキストウィンドウの規律。 長いプロンプトは高価です。厳密な取得予算を持つRAGは、知識ベース全体をコンテキストウィンドウに詰め込むよりも優れています。機能ごとの平均`prompt_tokens`を追跡してください。機能変更がないのに週ごとに増加している場合、プロンプトが肥大化しています。
GPT-5.5の272Kトークンクリフに注意。 OpenAIは、272Kトークンを超えるリクエストに対して、入力に2倍、出力に1.5倍の乗数を適用します。ラッパーに、`prompt_tokens > 250000`の場合に警告をログに記録するガードを追加し、クリフに近づいているプロンプトを捕捉できるようにします。価格の詳細については、GPT-5.5の価格に関する投稿を参照してください。
顧客ごとの支出上限。 B2Bで、契約にLLMをバックエンドとする機能が含まれている場合、顧客ごとの上限が必要です。ウェアハウスから`customer_id`ごとの累積支出を計算し、各呼び出しの前にアプリケーションでそれをチェックさせます。上限に達した場合、「月間AIクォータを超過しました」というメッセージと課金CTAを含む429を返します。これにより、AI機能がマージンリスクからマージン製品へと変わります。
避けるべき一般的な間違い。
- 推論トークンを入力としてカウントする。それらは出力です。出力レートで課金してください。
- リアルタイムの意思決定のためにOpenAIダッシュボードを信頼する。遅延があります。自身のウェアハウスを使用してください。
- 呼び出しサイトではなく、SDKレベルでタグ付けする。タグはクライアントではなく、機能に属するものです。
- バックグラウンドジョブのタグ付けを忘れる。cronジョブ、キューワーカー、Webフックも同じOpenAI呼び出しを行います。`cron:nightly-summarize`や`queue:image-caption`のような合成`route`でタグ付けしてください。
- サンプリング。サンプリングしないでください。すべてのリクエストをログに記録してください。データ量は取るに足らないものですが、帰属の正確性はそうではありません。
- `customer_id`をnullのままにする。顧客が不明な場合は、nullではなく`internal`または`system`としてログに記録してください。nullは帰属のブラックホールになります。
代替手段とツール
これを自分で構築する必要はありません。正直な比較を以下に示します。
| アプローチ | 得意な点 | コスト | 使用すべき時 |
|---|---|---|---|
| OpenAI usage API | ネイティブ、セットアップ不要、1セント単位で正確 | 無料 | 1プロジェクト、1機能、顧客ごとの帰属不要の場合 |
| Helicone | ドロップインプロキシ、ダッシュボード、キャッシュ、ユーザーごとのコスト | 無料枠あり；月額20ドル〜 | ホスト型ダッシュボードを早く欲しい、パスにプロキシがあっても問題ない場合 |
| Langfuse | オープンソース、セルフホストまたはクラウド、トレース + コスト | 無料（セルフホスト）；月額29ドル〜（クラウド） | トレースとコストを1つのツールで、オープンソースを好む場合 |
| LangSmith | LangChainとの緊密な統合、評価 + コスト | 月額39ドル/ユーザー〜 | すでにLangChainを使用しており、ベンダーを統合したい場合 |
| カスタムウェアハウス | 完全な制御、既存スタックに適合、プロキシ不要 | エンジニアリング時間 | 大規模なワークロード、カスタムディメンション、厳格なデータ所在地の要件がある場合 |
考慮すべきトレードオフがあります。プロキシ（Helicone）はあなたのクリティカルパスにホップを挟みます。遅延コストは小さいながらも実在し、その可用性に依存することになります。セルフホスト型の可観測性スタック（Langfuse）は完全な制御を提供しますが、運用はあなたが行います。カスタムウェアハウスのパスは、ほとんどの大規模チームが最終的にたどり着く場所です。既存のデータスタックと統合されますが、クエリとアラートは自分で記述します。ネイティブのusage APIは、ニーズがシンプルな場合は問題ありませんが、そうでなくなると役に立ちません。
実際のLLMコスト可観測性がどのようなものかについてさらに深く知りたい場合は、HeliconeチームのLLMコスト追跡に関するガイドがプロキシベースのアプローチを解説しています。Langfuseのコスト追跡に関するドキュメントは、オープンソースのアプローチをカバーしています。
プラットフォーム規模でこれを運用する場合、このパターンは一般化されます。マイクロサービスアーキテクチャのためのAPIプラットフォームで、サービスメッシュ戦略にコスト帰属ラッパーがどのように適合するかを参照してください。
実世界のユースケース
顧客ごとのLLM支出を持つB2B SaaS。 ある企業はセールスインテリジェンス製品を販売しています。各顧客はブリーフィングをリクエストするたびにGPT-5.5呼び出しをトリガーします。帰属なしでは、同社はOpenAIに月に8万ドル費やしていることを知っています。顧客ごとの帰属を行うと、顧客の12パーセントが支出の71パーセントを占めていることが判明します。同社は段階的価格設定、最低層に対するソフトクォータ、およびシートごとの超過料金を導入します。その結果、AI機能の粗利益は1四半期で41パーセントから73パーセントに増加しました。
社内開発ツール追跡。 あるエンジニアリング組織は、すべての開発者にプライベートGPT-5.5チャットアシスタントへのアクセスを提供しています。開発者ごとのタグ（`customer_id`が`dev_email`になる）を使用すると、プラットフォームエンジニアリングチームは、3人の開発者が社内支出の50パーセントを占めていることを確認しました。そのうち2人は、消し忘れた自動エージェントループを実行していました。これを停止することで、月に1,800ドルの節約になります。3人目の開発者は正当な作業を行っており、データはその開発者に対して組織全体でのより高いクォータを正当化します。
AI機能の支出予測。 あるプロダクトチームが新しい要約機能のリリースを望んでいます。PMはコスト予測の方法を知りません。機能ごとの履歴データを使って、チームはモデルを構築します。呼び出しあたりの平均プロンプトトークン、平均出力トークン、アクティブユーザーあたりの予想呼び出し数、予想アクティブユーザー数。予測結果は、アクティブユーザーあたり1日0.04ドル、または月額1.20ドルとなりました。価格設定チームは、この機能をユーザーあたり月額5ドルと設定します。ユニットエコノミクスが明確であるため、財務部門は承認します。
結論
測定できないものは管理できません。OpenAIの課金ダッシュボードは財務上の質問に答えますが、機能ごと、顧客ごと、ルートごとの帰属は製品上の質問に答えます。ラッパーを構築し、イベントをログに記録し、ウェアハウスをクエリすることで、AIの費用は謎の項目ではなくなります。
5つの要点：
- **すべてのリクエストにタグ付けする**（機能、ルート、`customer_id`、環境）。呼び出しサイトでタグを必須にする。
- **書き込み時にコストを計算する**。そうすることで、履歴データはその日に支払ったレートを反映する。
- **環境ごとに1つのプロジェクトキーを使用する**。OpenAIダッシュボードで厳格な上限を設定し、最後の砦とする。
- ネイティブの上限に加えて**ウェアハウス駆動型アラートを重ねて設定する**。これにより、上限が発動する前に緩やかな支出の増加を捉える。
- リリース前に**Apidogでラッパーをテストする**。誤ったタグはサイレントな帰属エラーを意味する。
- **推論の努力とプロンプトのサイズを四半期ごとに監査する**。最も安価な最適化は、品質を維持しつつコストを抑えるものだ。
- **機能ごとのキャッシュヒット率を追跡する**。これにより、プロンプトの変更が密かに入力コストを2倍にしないようにする。
Apidogをダウンロードし、コスト帰属ラッパーのエンドツーエンド検証に使用してください。タグ付けされたリクエストでAIエンドポイントを駆動し、ログペイロードの形状をアサートし、複数の環境でシナリオをリプレイすることで、あなたのウェアハウスが信頼するデータがエンジニアが記述したデータであることを確認します。
関連するコスト管理の読み物については、GPT-5.5の価格内訳とAPIチーム向けのGitHub Copilot利用料請求を参照してください。
よくある質問
推論トークンは課金において入力としてカウントされますか、それとも出力としてカウントされますか？推論トークンは出力レートで課金されます。OpenAI APIはそれらを`usage.completion_tokens_details.reasoning_tokens`で返します。コストを計算する際には、`completion_tokens`にそれらを追加してください。努力ごとの乗数については、GPT-5.5の価格内訳を参照してください。
`response.usage`はOpenAIダッシュボードと比較してどの程度正確ですか？`response.usage`のトークン数は、ダッシュボードのトークンと一致します。古い料金表からコストを計算すると、価格変更によってわずかなずれが生じる可能性があります。モデルごとのレートを固定し、OpenAIが価格変更を行った日に更新してください。
OpenAIのプロジェクトキーだけで帰属を行うことはできますか？プロジェクトキーは、プロジェクトごとという1つの次元の帰属を提供します。機能ごと、顧客ごと、ルートごとの帰属は提供しません。環境分割と予算上限にはプロジェクトキーを使用し、その他すべてにはアプリケーションレベルのメタデータを使用してください。
リトライやレート制限エラーについてはどうですか？コストが二重にカウントされますか？モデルが実行される前に失敗したリクエスト（4xx、完了前のネットワークエラー）は`usage`オブジェクトを返さないため、コストはログに記録されません。成功した後にアプリケーション層でリトライされたリクエストは、`request_id`を再利用しない限り、2回ログに記録されます。冪等なリトライでは同じ`request_id`を渡し、ラッパーは書き込み時に重複排除を行うべきです。
OpenAI usage APIはどれくらいの速さでデータを返しますか？usage APIには数十分の遅延があります。リアルタイムの意思決定（アラート、キルスイッチ）には、ご自身のウェアハウスを使用してください。月次調整には、usage APIで問題なく、請求書と一致します。
ログ量を減らすためにリクエストをサンプリングすべきですか？いいえ。データ量は少ない（リクエストごとに1つのJSON行）ですし、サンプリングは顧客ごと、ルートごとの帰属を損ないます。すべてのリクエストをログに記録してください。
このアプローチは他のLLMプロバイダーにも使えますか？はい、このスキーマは一般化できます。`provider`カラム（`openai`、`anthropic`、`google`、`deepseek`など）を追加し、プロバイダーごとに1つの料金表を用意します。ラッパーはプロバイダー固有ですが、ウェアハウスとダッシュボードはそうではありません。比較点については、DeepSeek V4 APIの価格設定を参照してください。
これは埋め込みや画像生成の呼び出しにも機能しますか？はい、プロバイダー固有のコスト計算を使用すれば可能です。埋め込みは入力トークンごとに定額で課金され、画像は画像ごとに解像度別のレートで課金されます。スキーマに`endpoint`（例：`chat`、`embeddings`、`image`）を追加し、それに基づいてコスト計算を分岐させてください。