プロバイダー請求とWordPressカウンターは一致しなくてよい――差異を調べる境界

完全一致という前提を捨てる

WordPressは外部呼び出しを試みた時点を数えられますが、プロバイダーは受理、処理、請求の定義で集計します。タイムアウトした要求、送信前に止めた要求、応答後に接続が切れた要求は、両者で同じ一件にならないことがあります。

さらにAI Cost Circuit BreakerはWordPress標準AI Client経由が対象で、別プラグインが独自SDKから直接送る通信は現在の対象外です。プロバイダー側にその通信が含まれれば、対象範囲が違うだけで差は生まれます。

UTC・対象モデル・単位をそろえる

月末のローカル時刻とプロバイダーのUTC締めをそのまま比べると、境界日の利用が別月へ入ります。両方から同じUTC開始・終了時刻でデータを出し、モデル名、プロジェクト、環境、通貨を固定します。

要求数とトークン数とUSDを同時に合否判定へ使わず、一つずつ照合します。まず要求の対応関係、次に入力・出力トークン、最後に当時の単価、割引、税、丸めを適用した金額という順なら、差が生まれた段階を特定できます。

説明可能な差だけを差異ポリシーへ移す

想定差異には、送信前ブロック、タイムアウト、再試行、直接呼び出し、集計時刻、推定トークンと確定トークン、価格表の更新遅れを列挙します。各項目に証拠元と担当者を付け、説明額を総差異から差し引きます。

許容幅は都合のよいパーセントを固定せず、通常3か月の照合結果から決めます。差額が小さくても対象外通信が継続的に増えているなら調査し、差額が大きくても価格改定で全額説明できれば監視故障とは判断しません。

小さくても危険な対応欠落を探す

第一は、プロバイダー要求IDに対応するWordPress相関IDがない状態です。これは対象外の直接通信、別環境、漏えいしたキーなどの可能性があるため、金額が小さくても発生源を割り当てます。

第二は、一つの相関IDに複数のプロバイダー要求IDが付く状態です。再試行やフォールバックによる二重処理の可能性があり、総額が許容差内でも、利用増時に拡大する構造なので修正対象です。

未説明差と保持範囲を確定する

照合の合格条件は数字の完全一致ではなく、総差異が証拠付きの要因へ配分され、未説明部分に担当者と期限があることです。推定カウンターを請求書の代わりにせず、請求書を通信診断の代わりにもしません。

想定差異ポリシーには対象範囲と保存項目も明記します。プロンプトや応答を照合のために保存する必要はなく、要求ID、時刻、モデル、トークン、状態、経路だけで十分な場合が多いため、プライバシー方針に沿って証拠を最小化します。

「プロバイダー請求とWordPressカウンターは一致しなくてよい――差異を調べる境界」の「想定差異ポリシー」を、最初の実環境導入に使ってください。AI Cost Circuit Breakerを無料でダウンロードし、Monitoringから始め、期待するシグナルと戻し方を確認してから制御を有効にしましょう。