請求書にない『利用元』をサイト側で補う
問い合わせ要約、商品説明生成、検索補助などが同じAPIキーを共有していると、AI事業者の明細には合計しか出ないことがあります。そこで、ユーザー名ではなく『どの機能が、どの経路から呼び出したか』を識別できる運用ラベルを用意します。
目的は人物の追跡ではなく、費用の責任範囲を分けることです。機能名、処理種別、サイト環境といった最小限の情報から始めます。
まずAIを呼ぶ経路を棚卸しする
管理画面のボタンだけでなく、フォーム送信、REST API、Ajax、Cron、Webhook、外部連携まで洗い出します。プラグイン名と画面名だけでは、更新後に実装が変わったとき追えないため、実際のフックやエンドポイントも併記します。
たとえば『お問い合わせ要約』がフォーム送信時と管理画面表示時の両方で動いていれば、担当者が一覧を開くたびに同じ要約を作り直しているかもしれません。画面上は一つの機能でも、起点は複数あります。テスト操作を1回行い、WordPressログの時刻とAI事業者側の呼び出し回数増加を突き合わせると、見落としていた起点を発見しやすくなります。
- 機能の名称と事業上の目的
- 呼び出しの起点となる画面・イベント
- WordPress内のフックまたは通信経路
- 使用モデルと、おおよその1回あたり費用
- 停止した場合の代替手段
個人情報ではなく、機能単位の識別子を残す
ログへ残すのは、例えばfeature=support_summary、source=contact_form、environment=productionのような固定ラベルです。メールアドレス、入力本文、IPアドレスを安易に追加しないでください。調査に不要な個人情報は、漏えいや開示請求時の負担を増やします。
外部AI事業者へ任意のメタデータを送れるかはサービスごとに異なります。送れない場合でも、WordPress側のリクエストIDと時刻を対応させれば、集計に使えることがあります。
費用上位だけでなく、成果も横に置く
機能別の呼び出し回数と推定費用を出したら、成功件数や顧客成果も並べます。費用が最大の機能でも、売上や解決件数を生んでいれば、単純に止めるべきとは限りません。一方、失敗と再試行ばかりの機能は優先して修正できます。
月間推定費用が商品検索120ドル、記事下書き80ドル、問い合わせ要約40ドルだったとしても、優先順位は金額順とは限りません。商品検索が300件の購入を支え、記事下書きは半数が未使用、問い合わせ要約は25％がタイムアウトなら、まず後二つの処理方法を直します。機能別台帳には費用と成果、失敗率を同じ行へ置いてください。
- 機能別の推定費用
- 成功処理と失敗処理の件数
- 再試行による重複率
- 問い合わせ解決・購入などの成果
- 止めた場合に影響する顧客導線
今週は上位3経路だけ特定する
最初から完全な観測基盤を作る必要はありません。推定費用の大きい3機能について、起点、経路、結果を一週間だけ記録してください。発生元が分かる状態になれば、サイト全体を止めず、問題のある機能だけを見直せます。
完成させる成果物は『AI呼び出し台帳』です。1行に機能名、起点、エンドポイント、固定ラベル、使用モデル、推定単価、成功の定義、停止時の代替を記します。翌週、ラベルの付かない呼び出し回数が全体の5％を超えるなら、未知の経路を追加調査するという基準も置くと、棚卸しが一度きりで終わりません。プラグイン更新日と台帳の最終確認日も持たせ、更新後24時間は未分類呼び出し回数の割合を再確認します。削除した機能のラベルが残り続ける場合は、停止済みCronやWebhookが動いていないかを調べる手掛かりになります。
「AI費用を最も発生させているWordPress機能を特定する方法」の「機能別のAI呼び出し台帳」は、同じ指標を継続して集めることで判断材料になります。AI Cost Guardrails-CNXTを無料でダウンロードし、WordPress上のCalls・Token・推定USDを計測し始めましょう。