三つの指標は、同じものを別名で呼んでいるわけではない
推定費用（米ドル）は財務負担の見込み、トークン数は処理の重さ、成功件数は利用者へ届いた成果を示します。呼び出し回数が同じでもモデル価格が変われば費用は動き、トークン数が少なくても失敗ばかりなら成果は増えません。一つの指標ですべてを判断しようとすると、原因を見誤ります。
たとえば1,000回、合計200万トークンで20ドルだった週と、800回、同じ200万トークンで35ドルだった週を比べます。件数は減っても高価なモデルや出力比率の増加で費用は上がります。『何回使われたか』だけを会議資料に出すと、最も重要な変化が隠れます。
金銭的な損失を止める主指標は、費用に近いものを選ぶ
請求リスクを限定する目的なら、最終的には金額（米ドル）を基準にするのが説明しやすいでしょう。ただしWordPress側で見える金額はモデル名とトークン数からの推定であり、割引、キャッシュ、価格改定、為替を完全には反映しない場合があります。プロバイダー請求を正として定期照合します。
金額上限を作るときは、推定と実請求の差も余裕として持ちます。直近3か月で推定が実請求より最大8％低かったなら、限度額ぎりぎりまで使わせず10〜15％の安全幅を置きます。価格改定日や新モデル導入日は過去差分を使えないため、短い観察期間へ戻します。
- 推定費用（米ドル）：最大損失と予算説明に向く
- トークン：入力肥大化や長文出力の原因分析に向く
- 呼び出し回数：ループや二重送信の発見に向く
- 成功回数：顧客価値と単位原価の評価に向く
運用画面では、主指標一つと補助指標二つに絞る
すべてを同じ重要度で並べると、異常時に判断できません。たとえば主指標を推定費用、補助指標を成功1件あたりのトークン数と失敗率にします。費用が増えたとき、成功件数も増えたなら需要、トークン数だけ増えたなら入力肥大、失敗率が増えたなら再試行を疑えます。
経理向けには月額と予算差、開発向けにはトークン・再試行・モデル、事業向けには成功成果と単位原価を出します。元データは同じでも、問いに合わせて順番を変えます。部門ごとに別の『正解』を作るのではなく、主指標と補助指標の関係を共通の一枚にします。
指標を変えるときは、旧ルールと並走させる
トークン上限から金額上限へ変更する場合、少なくとも一つの請求期間は両方を記録します。モデルごとの単価差や、入力・出力の価格差により、同じトークン数でも費用が変わるからです。旧指標なら止まった日、新指標なら止まる日を比較して、顧客影響を確認します。
移行表には、日付、旧ルールの残量、新ルールの残額、成功件数、どちらか一方だけが発動した理由を残します。差が出た日を3件以上レビューしてから切り替えると、しきい値の取り違えを減らせます。一度にモデルも変えると比較不能になるため、計測単位の変更とモデル更新は別日に行います。
最初のダッシュボードは、問いを一つに絞る
『今月の費用暴走を防ぐ』が目的なら、まず標準のAI Clientを通るリクエストの推定費用と基本のハードストップ保護を無料版で確認します。その後、原因説明にトークンと成功回数を加えてください。AI Cost Guardrails-CNXTの推定額だけを会計記録にせず、必ずプロバイダーの実請求を照合します。
最終成果物は『指標一覧』ではなく、異常時に読む判断カードです。主指標が境界を超えたら、補助指標AとBを確認し、需要なら維持、失敗なら制御、と一行で書きます。カードには確認順、担当者、次の判断時刻を記載し、3分で次の操作を選べないグラフは日常分析用へ分けます。初版は実際の当番者に読んでもらい、迷った語句だけを書き換えて完成させます。
AI Cost Guardrails-CNXTをダウンロードし、「AI利用の上限は、推定費用・トークン数・成功件数のどれで決めるべきか」のうち製品が対応する境界をWordPress上で動かします。Freeはサイト全体・呼び出し元別の月間USD・リクエスト試行数・トークン、Proは対応する短時間・失敗パターンを制御できます。