OpenAI API / 運用・コスト診断
0の理由を切り分け、
費用まで確かめる。
読了時間の目安
- しっかり読む
- 約34分
- 要点を読む
- 約17分
文字量と図表からの目安です。操作・実践・X投稿の閲覧時間は含みません。
OpenAI Responses APIのcached_tokensが0なら、まず対象条件とdiagnosticsを確認します。比較結果がなければ同条件の2リクエストを記録し、診断理由に応じて1項目ずつ見直します。改善は再利用量だけでなく、書き込みを含む総入力コストで判断してください。
プロンプトキャッシュとは、入力の共通部分について計算結果を再利用する仕組みです。本記事では、Responses APIの使用量と診断結果を同じ票へ記録し、「修正する」「必要な変更を維持する」「追加調査へ進む」を決めます。
こんな人におすすめ
- 長い共通入力を繰り返しているのに、
cached_tokensが0か想定より少ない。 - 設定変更で再利用量は増えたが、実際の入力コストが下がったか分からない。
診断結果を取得済みなら、type別の対応へ進み、cache_missではreason別の修正候補を選びます。まだ比較結果がなければ、同条件のA・Bを記録してください。2回は比較の出発点で、初回の0や2回目のヒットを保証するものではありません。
cached_tokensが0なら何を確認するか
OpenAI Responses APIのキャッシュ比較は、利用モデル・固定プレフィックス・比較条件を確認してから始めると、対象外と設定差を分けて調べられます。まず「長い入力を送った」ことと「再利用できる共通部分がある」ことを分けて確認しましょう。
Responses APIと診断対応モデル
本記事の比較診断は、Responses APIのGPT-5.6以降の対応モデルを対象にします。Responses APIとは、アプリからモデルへ入力を送り、応答や使用量を受け取る開発者向けAPIです。診断の対応範囲は2026年9月28日に確認しました。OpenAIの診断対応条件
旧モデルを使っている場合は、保持設定や再利用の条件をこの例へそのまま移さず、利用モデルの仕様に戻ってください。ChatGPTの月額契約とAPIの従量課金も別です。OpenAIの課金区分の案内/ChatGPT内のクレジットとAPI請求の違い
固定部の長さ・比較間隔・境界をそろえる
比較を始める前に、固定部の長さと再利用の境界をそろえ、直近の完了した応答を基準にします。プレフィックスとは、入力の先頭から続く共通部分です。後ろに同じ文章が残っていても、先頭側の変更を飛び越えて同じプレフィックスとは扱えません。
- 長さ:対象世代の最小キャッシュ可能長は1,024トークンです。総入力の長さだけで判断せず、固定部を対象モデルで数えます。短い固定部を無意味な文章で水増しする方法は、本記事では勧めません。
- 間隔:
prompt_cache_options.ttlの30mは、直近の書き込み・再利用後の最小寿命です。比較は間を空けずに行います。30分は削除期限でも、診断記録の有効期限でもありません。 - 境界:同じ固定文があっても、可変入力まで含む長い範囲だけを書き込んだ場合、その可変部分を変えると短い固定部を再利用できないことがあります。固定部末尾の境界を両方のリクエストに置くことを確認します。
上記の長さ・TTL・境界条件は2026年9月28日確認。プロンプトキャッシュの条件と注意点。トークンは文字数と同じではありません。入力トークンの公式計数ガイド
ここでの判断:対象外・固定部不足・境界不一致が分かれば、先にその条件を整えます。条件を満たしてもヒットを保証するものではないため、次にAとBの実際の使用量を比べます。
Responses APIの2リクエストをどう比べるか
OpenAI Responses APIの比較記録は、同条件の2リクエストを基準に、response ID・使用量・診断結果を同じ診断票へ残す形にすると、変更前後を追えます。Aを基準、Bを同条件の比較先にし、必要な場合だけCで1項目を変えます。
基準と比較先を同じ診断票に記録する
既存アプリを再現する場合:A・Bには、そのアプリのmodel・tools・設定・固定部を引き継ぎます。下の例のモデルや設定へ一括変更せず、同条件の記録を取ってから、Cで1項目だけ変えてください。
Aの完了後に応答のidを保存し、Bのprompt_cache_options.comparison_response_idへ指定します。この比較IDは診断を求める指定です。過去の会話を読み込んだり、キャッシュ利用を強制したりしないため、Bにも比較する入力を送ります。比較IDの公式仕様
usageとは、応答に付く使用量の記録です。実際の再利用量はusage.input_tokens_details.cached_tokens、書き込み量は同じ階層のcache_write_tokensで確認します。取得できない項目を0へ置き換えず、「未取得」と残してください。Responses APIの使用量フィールド
OpenAI APIキャッシュ診断票〈2リクエスト比較サンプル付き〉
| 記録項目 | A:基準 | B:同条件 | C:1項目変更・任意 |
|---|---|---|---|
| 対象・確認日 | Responses API/GPT-5.6以降の診断対応モデル。公式条件:2026-09-28確認。未取得と0を区別する。 | ||
| 比較の前提 | 固定部1,024トークン以上。長さの計数方法と境界を記録。直近の完了応答を基準に同じ組織・処理地域で比較する。結果はベストエフォート。 | ||
| 送信日時・タイムゾーン | 未記入 | 未記入 | 未実施 |
| response ID/完了状態 | 未記入 | 未記入 | 未実施 |
| comparison_response_id | 指定なし | AのIDを記入 | AのIDを記入 |
| 今回変えた1項目 | 基準 | キャッシュ条件の変更なし | 未実施 |
| model:要求/応答 | 未記入 | 未記入 | 未実施 |
| service tier:要求/応答 | 未記入 | 未記入 | 未実施 |
| 組織・処理地域 | 設定を確認して記入 | 設定を確認して記入 | 未実施 |
| tools定義の版/照合用hash | 未記入 | 未記入 | 未実施 |
| reasoning.effort | 未記入 | 未記入 | 未実施 |
| text.verbosity/text.format | 未記入 | 未記入 | 未実施 |
| 固定プレフィックス:tokens/計数方法 | 未記入 | 未記入 | 未実施 |
| 固定部の版/可変入力の位置 | 未記入 | 未記入 | 未実施 |
| cache mode/境界/TTL | 未記入 | 未記入 | 未実施 |
| prompt_cache_key | 未記入・指定なしも記録 | 未記入・指定なしも記録 | 未実施 |
| 総入力:input_tokens | 未取得 | 未取得 | 未実施 |
| 再利用:cached_tokens | 未取得 | 未取得 | 未実施 |
| 書き込み:cache_write_tokens | 未取得 | 未取得 | 未実施 |
| diagnostics:type/reason | 比較指定なし | 未取得 | 未実施 |
| 適用単価の条件・確認日 | モデル/実際のservice tier/長文・地域条件/通貨/確認日を記入。価格だけの変更なら保存済みusageで再計算可能か確認。 | ||
| 通常/読み取り/書き込み単価 USD・100万tokens当たり | 未記入 | 未記入 | 未実施 |
| 総入力コスト(USD) | 未算出 | 未算出 | 未実施 |
| 費用の条件 | 出力・ツール費用は含めない。diagnosticsの推定値を課金計算に使わない。比較回数・仕事量をそろえ、初回書き込みも合算する。 | ||
| 必要な出力条件/満たすか | 未判定 | 未判定 | 未実施 |
| 結論・理由・次の1行動 | 修正を採用/必要な変更を維持/追加調査から選び、使用量・費用・出力条件を根拠に記入する。 | ||
比較の注意:初回Aでも既存キャッシュを使う場合があります。AとBでmodel・tools・設定・固定部をそろえ、Cの比較IDもAへ固定します。診断自体に追加料金はありませんが、基準・再試行を含むAPI呼び出しは通常どおり課金・レート制限の対象です(2026年9月28日確認)。診断の料金と比較条件
2リクエストのPython例(未実行)
下のPython例は、固定部を1回だけ読み込み、同じリクエスト内容をA・Bへ送ります。モデル候補はgpt-6-lunaです。reasoning.effort="none"を含む設定とアカウントの利用可否を確認してから使い、別モデルへ替える場合はそのモデルの対応値に合わせてください(2026年9月28日確認)。GPT-6 Lunaの公式仕様
- 自分の共通指示をUTF-8の
fixed-prefix.txtへ保存します。比較中はファイルを変更しません。 - 対象モデルで固定部を事前計数し、その数を環境変数
FIXED_PREFIX_TOKENSへ設定します。計数方法はFIXED_PREFIX_COUNT_METHODに残せます。コードは申告値を検査するだけで、自動でトークン数を数えません。 OPENAI_API_KEYを環境変数で渡し、コードをcache_check.pyとして保存してpython3 cache_check.pyを実行します。既定では生成リクエスト2回です。事前計数はこの2回に含みません。- 出力されたA・BのJSONを診断票へ転記します。自分の要求したモデルと、応答に返ったモデル・tierを分けて確認してください。
この例はexplicitモードとprompt_cache_breakpointで、developerメッセージの固定部末尾を境界にします。explicitを指定しても境界を置かなければ読み取り・書き込みは行われません。implicitから切り替える場合も、新旧の境界が一致するかを先に確認します(2026年9月28日確認)。キャッシュモードと明示的な境界
未実行・課金あり:このコードによるAPI実測は行っていません。ヒットや診断理由の返却を保証しません。費用の自動計算は、実際のモデル・tier等に合う3単価とPRICE_CONDITIONを設定した場合だけ行い、未設定ならnullを返します。nullは0円ではありません。
# 未実行サンプル。既定で有料の生成リクエストを2回送ります。
# Python 3の標準ライブラリだけを使用。自動再試行はしません。
# 先にOPENAI_API_KEYを環境変数へ設定してください。
# fixed-prefix.txtに実際の共通指示を保存し、対象モデルで事前計数します。
# FIXED_PREFIX_TOKENSにはそのトークン数を設定します(文字数ではありません)。
import copy
import hashlib
import json
import os
from datetime import datetime, timezone
from decimal import Decimal
from pathlib import Path
from urllib.request import Request, urlopen
model = os.getenv("OPENAI_MODEL", "gpt-6-luna")
fixed = Path("fixed-prefix.txt").read_text(encoding="utf-8")
fixed_tokens = int(os.environ["FIXED_PREFIX_TOKENS"])
if not fixed or fixed_tokens < 1024:
raise SystemExit("対象モデルで固定部を計数し、1,024トークン以上を用意してください。")
base = {
"model": model,
"service_tier": "default",
"reasoning": {"effort": "none"},
"text": {"verbosity": "low"},
"max_output_tokens": 256,
"store": False,
"tools": [{"type": "function", "name": "lookup_note",
"description": "Look up a note by key.",
"parameters": {"type": "object", "properties": {
"key": {"type": "string"}}, "required": ["key"],
"additionalProperties": False}, "strict": True}],
"tool_choice": "none",
"prompt_cache_options": {"mode": "explicit", "ttl": "30m"},
"input": [{"role": "developer", "content": [{
"type": "input_text", "text": fixed,
"prompt_cache_breakpoint": {"mode": "explicit"}}]},
{"role": "user", "content": "Reply with exactly OK."}],
}
# 費用は手動で確認した3単価と適用条件を設定したときだけ計算します。
# INPUT_USD_PER_M / READ_USD_PER_M / WRITE_USD_PER_M: USD/100万tokens
# PRICE_CONDITION: モデル・実際のtier・長文/地域条件・確認日
price_names = ["INPUT_USD_PER_M", "READ_USD_PER_M", "WRITE_USD_PER_M"]
rates = [os.getenv(name) for name in price_names]
price_condition = os.getenv("PRICE_CONDITION")
prices = [Decimal(value) for value in rates] if all(rates) and price_condition else None
if prices and not all(value.is_finite() and value >= 0 for value in prices):
raise ValueError("単価には有限の非負数を指定してください。")
def input_cost(n, r, w):
if not prices or not all(value is not None for value in (n, r, w)):
return None
if min(n, r, w, n - r - w) < 0:
return None
amount = sum(Decimal(tokens) * price for tokens, price in
zip((n - r - w, r, w), prices)) / Decimal(1000000)
return str(amount)
def run(label, body, tools_version, change):
request = Request("https://api.openai.com/v1/responses",
data=json.dumps(body).encode("utf-8"),
headers={"Authorization": "Bearer " + os.environ["OPENAI_API_KEY"],
"Content-Type": "application/json"}, method="POST")
sent_at = datetime.now(timezone.utc).isoformat()
with urlopen(request, timeout=120) as response:
result = json.load(response)
usage = result.get("usage") or {}
details = usage.get("input_tokens_details") or {}
diagnostic = result.get("prompt_cache_diagnostics") or {}
n, r, w = (usage.get("input_tokens"), details.get("cached_tokens"),
details.get("cache_write_tokens"))
record = {
"case": label, "sent_at_utc": sent_at, "changed_item": change,
"response_id": result.get("id"), "status": result.get("status"),
"comparison_response_id": body["prompt_cache_options"].get("comparison_response_id"),
"model_requested": body["model"], "model_returned": result.get("model"),
"service_tier_requested": body["service_tier"],
"service_tier_returned": result.get("service_tier"),
"tools_version": tools_version,
"tools_sha256": hashlib.sha256(json.dumps(body["tools"], sort_keys=True).encode()).hexdigest(),
"reasoning_effort": body["reasoning"]["effort"],
"verbosity": body["text"]["verbosity"], "text_format": body["text"].get("format"),
"fixed_prefix_tokens": fixed_tokens,
"count_method": os.getenv("FIXED_PREFIX_COUNT_METHOD", "事前計数・方法は診断票へ記入"),
"fixed_prefix_sha256": hashlib.sha256(fixed.encode("utf-8")).hexdigest(),
"variable_input_position": "固定部の境界より後",
"cache_options": body["prompt_cache_options"],
"cache_breakpoint": "developerの固定部末尾", "prompt_cache_key": body.get("prompt_cache_key"),
"input_tokens": n, "cached_tokens": r, "cache_write_tokens": w,
"diagnostics_type": diagnostic.get("type"), "diagnostics_reason": diagnostic.get("reason"),
"prices_usd_per_m": dict(zip(price_names, rates)), "price_condition": price_condition,
"total_input_cost_usd": input_cost(n, r, w),
}
print(json.dumps(record, ensure_ascii=False, indent=2))
if result.get("status") != "completed" or not result.get("id"):
raise SystemExit("完了したresponse IDを得られないため、次の比較を中止しました。")
return result["id"]
baseline_id = run("A", copy.deepcopy(base), "tools-v1", "基準")
second = copy.deepcopy(base)
second["prompt_cache_options"]["comparison_response_id"] = baseline_id
run("B", second, "tools-v1", "キャッシュ条件の変更なし・診断用比較IDのみ追加")
# 任意の3回目。実行する場合だけRUN_TOOL_NAME_TEST=1を設定します。
if os.getenv("RUN_TOOL_NAME_TEST") == "1":
third = copy.deepcopy(base)
third["tools"][0]["name"] = "lookup_note_v2"
third["prompt_cache_options"]["comparison_response_id"] = baseline_id
run("C", third, "tools-v2-name-only", "tools[0].nameのみ変更")
標準ライブラリによるHTTP例です。APIキーや入力本文はログに出力しませんが、ID・設定情報・hashも共有先を選んで扱ってください。HTTPエラー時の自動再試行はなく、途中で止まった場合は既に送信した呼び出しと課金を確認してからやり直します。リクエスト項目の根拠:Responses API作成リファレンス。
tools名だけを変える説明用記入例
toolsの影響を見るなら、A・Bを保存した後、Cで関数名だけを変更します。上の例ではRUN_TOOL_NAME_TEST=1を指定した実行時に、A・Bに続いてCを送ります。合計3回の生成呼び出しになり、Cだけを後から単独送信するスクリプトではありません。
説明用の記入:AとBはtools-v1、Cはtools-v2-name-only。変更項目はlookup_note → lookup_note_v2だけです。Cにcache_miss / tools_changedが返った場合にそのまま記録し、返っていない理由やトークン数は書き足しません。
推論設定や入力の位置も同時に変えると、どの変更が効いたか分けられません。次の試験は新しいA・Bの組で1項目だけ変えます。
diagnosticsの結果から何を直すか
OpenAIのprompt_cache_diagnosticsは、まずtypeで比較の可否を読み、cache_missのreasonから次に見直す項目を選ぶために使います。diagnosticsとは比較診断の結果、typeは結果の種類、reasonは特定された差分の理由です。
原文抜粋:“See what’s being reused and what’s preventing cache hits.”
日本語訳(抜粋):「何が再利用され、何がキャッシュヒットを妨げているかを確認する」
投稿の要約:OpenAIは、Prompt Caching Dashboardでキャッシュヒット率を追い、診断APIで再利用を妨げた変更と影響を受けたトークン数の推定値を調べる使い分けを案内しています。
投稿が触れる推定トークン数は、実際の再利用量や課金額そのものではありません。以下の表で診断のtype・reasonを読み、再利用量は応答のusage、費用は後半の計算で確認します。
埋め込みが表示されない場合も、上の原文抜粋・日本語訳・要約は読めます。Xで投稿全文を読む
typeで再利用・差分・判定不能を分ける
typeが判定不能なら、設定を片端から戻す前に比較条件を整えます。cache_hitでも全入力を再利用したとは限りません。実際の量はusageで読み、診断の推定トークン数と分けて扱ってください。
| type | 判断すること | 次の対応 |
|---|---|---|
cache_hit | この比較でミスが検出されていない。 | cached_tokensと費用を確認する。 |
cache_miss | 再利用を妨げた差分がある。 | reasonの項目を1つ調べる。 |
comparison_response_not_found | 比較に使える診断記録がない。 | 同じ組織の直近の完了応答を選ぶ。 |
unavailable | ヒット・ミスを結論づけられない。 | 対応モデルと別の直近応答を確認する。 |
reasonごとに変更候補を1つ選ぶ
reasonと一致する差分を見つけ、不要な変更ならそろえ、必要な変更なら費用面から維持を判断します。診断はベストエフォートで、最初に分類された理由を返します。1つ直した後も別の原因が残る可能性があるため、同じ基準へ再比較します(2026年9月28日確認)。診断の制約と修正後の確認
| reason | 診断票で比べる箇所 | 修正候補・維持する条件 |
|---|---|---|
model_changed | 要求・応答のモデル。ルーティングや代替選択。 | 意図しない切り替えを直す。品質上必要なら維持。 |
prompt_cache_key_changed | キーの値と、分離する必要のある単位。 | 同じグループは同じキーへ。usage上のミスと物理的なミスを同一視しない。 |
service_tier_changed | 要求値だけでなく応答のtier。 | 同じ処理条件へそろえる。応答値が異なる場合は要求値だけで同条件としない。 |
tools_changed | 名前・説明・schema・順序・設定。 | 不要な定義変更を戻す。実行を止めるだけなら定義を消さずtool_choiceを検討。 |
text_format_changed | text.formatと出力schema。 | 出力要件が同じ場合にそろえる。必要な形式変更は残す。 |
reasoning_effort_changed | リクエスト直下のreasoning.effort。 | 比較時はそろえる。再利用量だけを理由に推論設定を下げない。 |
verbosity_changed | text.verbosity。 | 同じ用途なら固定。必要な回答の詳しさを優先する。 |
context_compacted | 会話の圧縮前後と総入力量。 | 圧縮を即座に取り消さず、少ない入力での総費用を比べる。 |
input_changed | 時刻・IDの混入、過去メッセージの編集・順序。 | 可変部分を固定部と境界の後ろへ。保存した固定部の版と照合する。 |
GPT-6で推論量を変える場合:対応モデルでは、リクエスト直下のreasoning.effortを元の値に保ち、入力の末尾へconfiguration_updateを追加して推論量を変更すると、以前のプレフィックスを再利用可能なまま維持できます。上の表が扱う設定値の直接変更とは区別し、利用モデルの対応条件を確認してください(2026年9月28日確認)。推論量の変更とキャッシュ再利用の公式説明
候補と確定を分ける:たとえば時刻が固定部へ入った可能性は、入力の差分を読む前には推測です。reasonが示した分類から実際の変更箇所を照合し、未知のtype・reasonや判定不能は「直った」「壊れた」と断定しません。
FAQ|比較不能・Dashboard・データ保存
応答を取得できるのに、比較の診断記録が見つからないのはなぜですか?
OpenAIの診断記録は応答本体とは別に短期間で失効するため、応答を取得できてもcomparison_response_not_foundになる場合があります。
診断記録の具体的な有効時間は公式には明記されていません(2026年9月28日確認)。診断記録の制約
アプリ全体のキャッシュ利用が落ちた場合は、どこを見ますか?
アプリ全体の傾向はPrompt Caching Dashboardで確認し、影響を受けたリクエストを選んで個別の診断票へ戻します。
Prompt Caching Dashboardは全体監視、diagnosticsは1件の比較に使い分けます。機能の役割は2026年9月22日のOpenAI公式発表で案内されています(2026年9月28日確認)。認証後の画面表記や権限別表示を本記事で再現していません。
複数機能で同時に異常が出た場合はOpenAI Statusも確認します。ただし、障害情報だけで個々のキャッシュミスの原因を確定しないでください。
store:falseや応答の削除で、キャッシュも削除されますか?
store:falseはResponses APIの応答保存に関する設定なので、キャッシュや監視ログを含む全データの即時削除指定とは扱えません。
応答の保存、診断用の記録、キャッシュの状態は別の対象です。応答削除をキャッシュ削除の手段として案内せず、組織の保持条件を確認してください(2026年9月28日確認)。OpenAI APIのデータ保持条件
修正で総入力コストは下がったか
OpenAI APIのキャッシュ修正は、cached_tokensの増加だけで評価せず、書き込みを含む総入力コストと、必要な出力条件を満たすかを合わせて判断します。ヒットした入力だけを見ると、初回や変更後の書き込み費用を見落とします。
通常入力・読み取り・書き込みを分けて計算する
総入力コストは、通常入力・キャッシュ読み取り・キャッシュ書き込みの3区分に、それぞれの単価を掛けて合計します。総入力をN、cached_tokensをR、cache_write_tokensをWとすると、通常入力はN−R−Wです。
総入力コスト(USD)
={(N−R−W)×通常入力単価 + R×読み取り単価 + W×書き込み単価}÷1,000,000
単価はいずれもUSD/100万tokens。出力トークン・ツール等の料金は含みません。
この式は対象世代の区分に従います。診断のcache_missed_tokensなどの推定値をRやWへ入れず、応答のusageを使ってください。取得できない値やN−R−Wが負になる記録は、そのまま費用未判定とし、フィールドと対象モデルを確認します。キャッシュの使用量と費用計算
同じ仕事量・比較条件で修正前後を見る
同じ仕事量・呼び出し回数で、初回書き込みも含めた合計を比べます。次の表はGPT-6 LunaのStandard・Short context、USD/100万tokensの通常入力0.10・読み取り0.01・書き込み0.125を使った計算例で、実測値ではありません(2026年9月28日確認)。OpenAI API公式料金表
| 項目 | A:初回書き込みの仮定 | B:再利用の仮定 | C:再利用+書き込みの仮定 |
|---|---|---|---|
| 総入力 N(tokens) | 10,000 | 10,000 | 10,000 |
| 読み取り R(tokens) | 0 | 8,500 | 8,600 |
| 書き込み W(tokens) | 10,000 | 0 | 1,400 |
| 通常入力 N−R−W | 0 | 1,500 | 0 |
| 計算の分子 | 10,000×0.125 | 1,500×0.10+8,500×0.01 | 8,600×0.01+1,400×0.125 |
| 総入力コスト(USD) | 0.001250 | 0.000235 | 0.000261 |
CはBより100トークン多く再利用していますが、書き込みを含めると入力コストは高くなります。共通の初回Aを含む2回分でも、A+Bは0.001485 USD、A+Cは0.001511 USDです。キャッシュ量だけで改善とせず、同じ仕事量の合計で判断する理由はここにあります。
実際には長文条件・処理tier・地域条件が異なれば、適用単価も確認し直します。短くした入力が要件を落としていたり、必要な推論設定を下げていたりする場合は、安くても採用しないのが本記事の判断基準です。費用と出力条件の両方を満たした変更だけを診断票の結論に残してください。
まとめ|キャッシュ診断の結論と再確認条件
OpenAI APIのキャッシュ診断は、比較記録と費用判断をそろえ、修正を採用する・必要な変更を維持する・追加調査へ進む、のいずれかを診断票に残して区切ります。次の行動は、今回の比較について結論欄を1つ埋めることです。
- 修正を採用:不要な差分を直し、必要な出力条件と費用改善を確認できた。
- 必要な変更を維持:モデル・推論・出力形式などの変更が用途に必要で、再利用量より要件を優先する理由がある。
- 追加調査:比較不能、使用量の欠落、複数の差分が残り、判断の根拠が足りない。
追加調査へ回すときは、次に変える1項目と比較先を記録します。共有する診断票からAPIキーや機密入力を除き、response IDや設定情報も必要な相手にだけ渡してください。
モデル・tools・入力テンプレート・推論設定・処理条件を変えたときは、診断票の基準を取り直してください。単価だけが変わったときは、保存済みのusageと新しい適用単価で総入力コストを再計算します。
コメント