「記録がない」は、利用がないことを意味しない
サイト上では文章生成が成功し、AIプロバイダーの管理画面にも利用量が出ている。それなのに保護画面は0件――この組み合わせでは、まず通信がどこを通ったかを疑います。画面が空であることだけを見て『費用は発生していない』『すべて保護されている』と判断してはいけません。
AI Cost Guardrails-CNXTの対象は、WordPress標準のAI Clientを経由したリクエストです。プラグインが独自にAPIキーを保持して直接送信する経路や、SaaS・別サーバーが実行する処理は対象外です。これは不具合ではなく、導入時に明示すべき保護範囲の違いです。
通信経路を三つの仮説に分ける
原因候補を『標準のAI Clientを通っているが記録されない』『プロバイダーへ直接送信している』『外部サービスが代理で送信している』の三つに分けます。推測でコードを直す前に、各仮説を支持・否定する証拠を決めると、調査が短くなります。
- WordPress標準のAI Client経由：WordPress側のログに実行時刻を残し、監視モードの集計と同じ時間帯で突き合わせる
- 直接API経由：対象プラグインの設定にプロバイダー用認証情報がある可能性。送信先ホストと設定責任者を確認する
- 外部サービス経由：WordPressからはWebhookやジョブ送信だけが見える可能性。外部側の実行履歴と課金主体を調べる
- ブラウザ直接送信：フロントエンドの通信先がWordPress以外になっている可能性。開発者ツールでは認証情報を表示・共有しない
一回のテスト操作を、時刻で端から端まで追う
テスト用の入力を一つ決め、秒まで記録した時刻とともに一回だけ実行します。その直後に、WordPressの該当プラグイン、保護画面、プロバイダーの利用履歴を同じ時間帯で照合します。連打や複数人での同時テストは、どの記録がどの操作かを分からなくするので避けます。
ソースコードや設定を確認するときは、APIキーそのものをチケットやスクリーンショットへ残さないでください。必要なのはキーの値ではなく、『どのコンポーネントが認証情報を持ち、どのホストへ送るか』という構造です。
具体例として、14時03分10秒に『テスト商品Aを50字で要約』を一度だけ送ります。14時03分台にプロバイダーで1件増え、監視モードの集計が0件なら、標準のAI Clientを通っていない仮説が強まります。反対に集計は1件なのに期待する表示へ反映されない場合は、表示期間、サイト時刻、絞り込み条件を確認します。このように一つの結果で即断せず、次に否定できる仮説を選びます。
導入判定表には、守れる経路と守れない経路を併記する
調査結果は、機能名、実行契機、通信元、経由コンポーネント、送信先、保護対象か、確認方法の列を持つ『対象内・対象外・未確認の通信経路一覧』へ整理します。対象外の経路が見つかった場合は、標準のAI Clientへ移せるかを開発側と検討し、すぐに移せないならプロバイダー側の上限や別の監視を併用します。この一覧は運用引き継ぎにも使います。新しいAI機能を追加するときは行を追加し、経路確認が終わるまで『未確認』から動かさない運用にします。
重要なのは『プラグインを入れた』を導入完了条件にしないことです。顧客が使う主要機能を実際に一回動かし、そのリクエストが監視モードに現れたことを確認して初めて、その経路の観測ができたと判断します。
通信経路の証明を、導入完了条件にする
プラグインを導入しただけでは、コードが存在することしか証明できません。AI機能を保護対象と説明する前に、顧客画面から制御した通信を一件実行し、ブラウザー操作、WordPressの処理、標準AI Clientのイベント、プロバイダーのリクエストID、管理画面の記録を対応付けます。
各機能を、対象内確認済み、対象外確認済み、未確認に分けます。プロバイダーSDKの直接利用、外部サーバー、独自通信は別の予算・信頼性制御が必要な場合があり、同じページの別機能から保護範囲を引き継ぎません。
対象経路ごとに、正常な追跡、意図的な上限試験、顧客の代替導線、戻し方を確認して受け入れます。未確認の行には責任者と確認日を付け、保護済みとは表示しません。
| 機能 | 確認した経路 | 保護状態 | 受入証拠 |
|---|---|---|---|
| 顧客向け支援 | 画面→WordPress→標準AI Client→プロバイダー | 対象内確認済み | 通信と管理画面の記録が一致 |
| 編集ツール | 管理画面→プロバイダーSDKへ直接 | 対象外 | 別の制御を記録 |
| 夜間処理 | 外部Worker→プロバイダー | 対象外 | 外部予算と通知担当 |
| 未確認プラグイン | 経路を再現できていない | 未確認 | 追跡完了まで保護を断定しない |
0件のまま強制停止へ進まず、まず対象範囲を確定する
記録されていない通信に対して停止条件を調整しても、保護は強くなりません。まず監視モードを維持し、対象内・対象外・未確認の三分類を完成させます。未確認を対象内として扱わないことが、運用担当者と顧客の双方を守ります。未確認の各行には、確認を依頼する相手、必要な資料、回答期限、期限までの暫定対策を付けます。たとえば開発元の回答待ちなら、その機能についてはプロバイダー管理画面を毎日確認し、別の費用上限を置くという形です。調査中の空白を運用上の空白にしないことが重要です。
次にサイトで確かめるのは、主要なAI機能を一回実行した時刻と監視モードの記録が一致するかです。一致しなければ、その機能の通信経路を開発元へ確認してから次の設定へ進みましょう。一致した機能も、管理者操作、一般ユーザー操作、定期処理の実行契機が違うなら別々に試します。同じプラグイン内でも、一部機能だけが独自経路を持つことがあるためです。三種類の結果を通信経路一覧へ添えれば、障害時に『どこまでは見えていたか』を即座に説明できます。
「AIは動いているのに、保護画面の記録が0件。通信経路を切り分ける方法」の「対象内・対象外・未確認の通信経路一覧」を、最初の実環境導入に使ってください。AI Cost Guardrails-CNXTを無料でダウンロードし、Monitoringから始め、期待するシグナルと戻し方を確認してから制御を有効にしましょう。