四半期ごとのAIシステム監査はパフォーマンスレビューではない。スコープドリフトのチェックだ。
スコープドリフトは静かに進行する。システムは壊れない。ただ、設計時に想定していなかった処理を——フォールバックパス、蓄積されたプロンプトパッチ、精度チェックなしに肥大化したリトリーバルセットを通じて——こなし始める。4ヶ月後には、1ヶ月目とは実質的に異なる動作をしている。誰もそれを計画していない。誰もドキュメント化していない。
この監査は2時間以内で完了する。四半期ごとに実施すること。
本番環境におけるスコープドリフトの兆候
繰り返し現れるパターンが3つある。
フォールバックパスの蓄積。 クエリがシステムの主要なルーティングロジックにマッチしない場合、デフォルトハンドラにフォールバックする。散発的なエッジケースであれば問題ない。しかし本番クエリの15%がフォールバックにヒットしているなら問題だ——それは15%のクエリが元のスコープ外にあり、システムが即興で対応していることを意味する。
プロンプトパッチの蓄積。 特定の入力でプロンプトが失敗する。誰かが条件節を追加して修正する。さらに追加する。また追加する。6ヶ月後、プロンプトには11個の条件節があり、バージョン履歴はなく、元のロジックを説明できる人間もいない。個々のパッチは合理的だった。しかし全体としてはメンテナンス不能だ。
精度チェックなしのリトリーバルセット拡張。 ナレッジベースが成長する——新しいドキュメント、新しいデータソース、新しいインテグレーション。リトリーバルのカバレッジは向上する。リトリーバルの精度は通常向上しない。システムはより多くを取得するが、一般的なクエリのtop-k結果はノイズが増える。拡張後に精度サンプルを実施した人間はいない。
四半期監査チェックリスト（5項目）
1. スコープ境界レビュー
過去30日分のクエリログを取得する。各クエリをスコープ内・エッジケース・スコープ外に分類する。各バケットの割合を計算する。前四半期の同じ計算と比較する。
スコープ外クエリが5パーセントポイント以上増加していれば、システムのスコープがドリフトしている。定義済みスコープを意図的に拡張するか、新しいクエリタイプに対してハード拒否パスを追加するかを決定する。
所要時間：30分。
2. リトリーバル精度サンプル
20件のクエリを選択する——最も一般的なクエリクラスタから10件、最大ボリュームのエッジケースクラスタから10件。各クエリを現在のリトリーバルシステムに対して実行する。各クエリについて、上位3件の取得結果を手動で検査し、関連あり・部分的に関連あり・無関連でスコアリングする。
目標：top-3結果の85%が「関連あり」または「部分的に関連あり」であること。この閾値を下回る場合、次の四半期までにリトリーバルセットのプルーニングまたは再ランキングが必要だ。
所要時間：30分。
3. プロンプトバージョンの差分確認
現在のプロンプトと90日前のプロンプトを比較する。バージョン履歴がない場合、それが最初の発見事項だ——次の四半期までに実装すること。
各変更について、何の入力が変更を引き起こしたか、変更内容は何か、リグレッションセットに対してテストされたかをドキュメント化する。記録されたトリガーまたはテストのない変更はリスクだ。
所要時間：20分。
4. 承認ゲートログの分析
システムに承認ゲート——出力が実行される前の人間によるレビューステップ——がある場合、四半期分のゲートログを取得する。承認率・拒否率・最も一般的な拒否理由を計算する。
拒否率の上昇は、システムの出力がオペレーターの許容範囲からドリフトしていることを示す。拒否率の低下は自動的に良いことではない——レビュアーがゴム印を押しているだけかもしれない。どちらのトレンドも調査が必要だ。
所要時間：20分。
5. ベースラインとのレイテンシパーセンタイル比較
現在の四半期のp50・p90・p99レイテンシを取得する。システムの本番稼働初月のベースラインと比較する。
p99でのレイテンシ増加は通常、システムがより複雑なクエリを処理していること、インデックス最適化なしにリトリーバルセットが成長したこと、またはパッチ蓄積によりプロンプト長が増加したことを意味する。原因ごとに対処法が異なる。次の四半期までにどれが該当するかを特定する。
所要時間：20分。
5つのチェックを2時間以内に実施する
ツールは高度である必要はない。
- クエリログ：既存のオブザーバビリティスタック（Datadog、Grafana、CloudWatch——どれでも）からエクスポートする。日付範囲でフィルタリングする。CSVにエクスポートする。
- リトリーバル精度：本番エンドポイントに対してクエリを手動で実行する。スプレッドシートで結果をスコアリングする。ドメインを知っていれば20件のクエリは約25分で完了する。
- プロンプトの差分：プロンプトをバージョン管理に保存する。90日前のタグとHEADの間の
git diffで十分だ。 - ゲートログ：承認ワークフローを管理するシステムからエクスポートする。スプレッドシートで割合を計算する。
- レイテンシ：既存のAPMツールから取得する。p50/p90/p99はすべての主要なオブザーバビリティプラットフォームの標準メトリクスだ。
2時間という目標は、ログにアクセス可能で、監査を実施する人間がシステムを把握していることを前提とする。どちらの条件も満たされていない場合は、まずそれを修正する。
結果をどう活用するか
監査は短いドキュメントを生成する：5つのセクション、各セクションに1つの発見事項、各発見事項に1つの推奨アクション。そのドキュメントはシステムのオーナーに渡す。経営層向けのレポートではない——次のスプリントへのオペレーショナルインプットだ。
同じ発見事項が2四半期連続で解決されずに現れた場合、それはもはや発見事項ではない。設計上の欠陥だ。それに応じて対処すること。
AI Brand Presenceのようなシステムは、こうしたオペレーショナルな規律を最初から組み込んで構築されている——定義されたスコープ境界、リトリーバル精度のベースライン、プロンプトバージョントラッキングが、後から追加されるのではなく、デリバリープロセスに組み込まれている。
ほとんどのチームは、目に見えて壊れているものがないという理由で四半期監査をスキップする。それこそがスコープドリフトが最も見えにくく、最も修正しやすいタイミングだ。