可観測性と監査ログ：誰が何を、なぜ変更したのか？

一文で定義

監査ログは、状態変化の実行者、対象、変更前後の値、時刻、相関関係を追跡する運用記録です。

要点：エラーログだけでは、顧客の結果にどの入力や承認プロセスが関わったのかを説明しにくいものです。一方、機密情報を過剰に記録することにもリスクがあります。

なぜこの技術が必要なのか？

エラーログだけでは、顧客の結果にどの入力や承認プロセスが関わったのかを説明しにくいものです。一方、機密情報を過剰に記録することにもリスクがあります。

仕組み

構造化ログでは request・job・tenant の correlation ID を使用し、業務イベントは追加式監査ログ（append-only audit log）に記録します。秘密情報や個人情報の原文は最小限に抑えます。

設計時に考慮するのは精度だけではありません。遅延時間、コスト、データ境界、更新頻度、障害時の動作もあわせて定義することで、運用時に再現可能な結果が得られます。自動化による確信が不十分な値を 0 や成功に置き換えず、未測定または要確認の状態として残すほうが安全です。

SAGの技術との関連

SAGは、Goalの作成、jobの実行、reportのrevision、専門家の承認、exportの各イベントを、tenantの監査記録に関連付けます。結果のprovenanceと運用監査は、それぞれの目的に応じて分離します。

実務チェックリスト

• 業務イベントとシステムエラーを区別します
• 機密情報をログから取り除きます
• jobから承認・exportまで追跡できるか確認します
• 失敗・空の結果・権限エラーの状態を成功と区別します
• 変更前後を同じ条件で再検証します

研究および公式文書

• Google AI検索機能の公式ガイド

参考文書は、原理や推奨事項の根拠となるものです。検索結果での表示、AIによる言及、順位、売上を保証するものではありません。実際の適用効果は、サービスデータを用いて同じ条件で観測し、確認する必要があります。

テーマ別の技術参考資料

• OpenTelemetryのトレースに関する概念

この技術をさらに読むには

テナント権限、jobの再試行、キャッシュ、承認履歴について確認します。

• 安定した顧客スペースの設計
• 機能案内FAQ