AI処理の待ち時間はどこにあるか：トレースとログで運用を見直す

一次情報から

トレースの文脈と、関数の実行ログは役割が異なる

W3CのTrace Contextは、サービス間で分散トレースの文脈を伝えるHTTPヘッダーと値形式を定めています。今回確認した文書は2021年11月の勧告です。[1] 複数の処理を関連付ける規格であり、それだけでAIの品質や利用料金が分かるものではありません。

Supabaseの現行資料は、Edge Functionsの呼び出し情報としてステータスコードや実行時間を確認でき、独自のログも記録できると説明しています。[2] 新しいリリースを紹介する記事ではありません。以下の計測区分と調査手順は、これらを運用へ適用する編集部の提案です。

出典：[1][2]

編集部の実務提案

利用者が待っている範囲を先に決める

最初に、いつからいつまでを待ち時間と呼ぶかを合意します。例えば依頼を受け付けてから下書きが表示されるまでと、人が承認して公開されるまででは、測っている仕事が異なります。前者が短くても承認待ちが長ければ、利用者の目的は完了していません。画面に結果が見えた時刻と、業務が確定した時刻を分けると、改善の対象が具体的になります。

一つの依頼に識別子を付け、関連するキュー、モデル呼び出し、ツール、保存結果をたどれるようにします。外部サービスをまたぐ場合は、そのサービスで使える関連付け方法を確認します。内部の識別子だけでは照会できない場合には、外部の受付IDとの対応を保存し、担当者が別の処理を混同しない形にします。

編集部の実務提案

処理・待機・確認待ちを混ぜずに残す

開始時刻と終了時刻だけでは、長かった理由までは説明できません。運用上の区切りを決め、キューで待った時間、モデルを呼んだ時間、ツールへ問い合わせた時間、保存した時間を分けます。並行処理がある場合に、それぞれの時間を単純に足して全体時間と呼ばないことも必要です。

次の表は、依頼から下書きまでを調べる場合の例です。記録時刻のタイムゾーンや各環境の時計の扱いもそろえます。通信の呼び出し側と受け側で測った時間が違うときは、どちらが利用者の待ち時間に近いかを確認し、説明できない差をモデルの処理時間へ押し込まないようにします。

編集部の実務提案

遅い一件と、通常の一件を同じ区切りで比べる

オフショアチームへは、「遅いので直して」ではなく、処理の識別子、期待する時間、影響した操作を渡します。担当者には、同じ業務の通常例と遅い例を並べ、どの区間に差があるかを報告してもらいます。入力の大きさや呼び出すツールが違えば、その差も条件として記載し、単純な性能差と混同しません。

一度の長い処理だけで全体の傾向を決めず、代表的な条件をそろえて比較します。改善では、例えば検索範囲や不要な呼び出しを一つずつ見直し、同じ課題で再計測します。速度が改善しても必要な情報が欠けていれば採用できないため、時間、結果の確認、利用量を一緒に残し、変更の採否を判断します。

編集部の実務提案

ログに残す情報を絞り、調査の責任を決める

調査できるようにすることと、入力や認証情報をすべてログへ保存することは別です。記録する項目、閲覧できる担当、保持期間を定め、個人情報や秘密が混ざる欄は必要性を確認します。本文を残さなくても、処理種別、件数、状態、識別子で調査できる場合があります。確認に必要な情報が足りない場合も、無条件に記録範囲を広げないようにします。

定例レビューでは、遅延した区間、調べた根拠、実施した変更、未解決の依存先を短くまとめます。毎回発注者が生ログを読む運用から、担当チームが比較と次の判断材料を用意する運用へ移します。記録を追加した後は、取得できることに加え、実際に一件の調査を完結できるかまで確かめます。