設問と背景
あるB2B SaaSのエンタープライズ顧客は、権限や設定の変更を調査する際、サポートチケットを起票するしかありません。営業は監査ログが契約更新に役立つと考えていますが、エンジニアリング側はストレージ、プライバシー、誤解の懸念を抱いています。これを開発すべきかどうか、どのユーザーを最初に対象とすべきか、初期リリースのスコープと判定基準（ゲート）を決定してください。
これはプロダクトに関する意思決定であり、単にログテーブルを設計する課題ではありません。「ログがほしい」という要望を、調査、コンプライアンスの証拠提示、インシデントのトラブルシューティング、内部セキュリティタスクへと分解して考えます。
面接官が見ているポイント
優れた回答は、顧客のタスクとリスクから出発し、どのイベントが重要か、誰が閲覧できるか、いつまでクエリ可能か、改ざんや漏洩をどのように防ぐかを定義します。Amazonのプロダクトマネージャー準備でも顧客セグメンテーション、ビジネスモデル、成功指標が強調されるように、監査ログ製品は顧客価値とプラットフォームコストのバランスを取る必要があります。
最初に確認すべき質問
対象アカウントにセキュリティ管理者、コンプライアンス監査人、一般管理者がいるか、顧客が調査するのは権限かデータアクセスか設定か、契約や業界規制で保持期間が定められているか、ソースはAPI、コンソール、自動化、サポートによる代理ログインをカバーしているか、そして誰が個人情報や機密性の高いリソース名を閲覧できるかを確認します。
また、プロダクト内のイベント表示画面と、長期的で改ざん不能なエクスポート用監査アーカイブを区別します。Google Cloud Audit LogsやAWS CloudTrailは、イベントタイプ、クエリ、長期ストレージを明確に区別しており、これらは異なるプロダクト課題です。
30秒の回答構成
上位3つの顧客タスクを確認した上で、価値が高く機密性の低い管理イベントから着手します。バージョン1では「誰が・いつ・どのリソースに・何をしたか」を回答できるようにし、フィルター、エクスポート、アクセス制御を備えます。機密データアクセスや長期保持は後続フェーズのゲートとします。チケット削減率、セルフサービス解決率、クエリ成功率、修正フィードバック、ストレージコストを検証します。ソースのカバレッジや権限分離が不十分な場合は、コンプライアンスを約束するのではなく内部ベータを実施します。
ステップごとの分析
ステップ1：タスクと顧客によるセグメンテーション
「どの管理者が設定を変更したか」「どのIDがデータにアクセスしたか」「監査期間中に何が起きたか」を区別します。タスクごとに必要なフィールド、権限、保持期間、エクスポート形式が異なります。まずは業務コンテンツを露出させない、頻度の高い検証可能な管理イベントから始めます。
ステップ2：イベントスコープと可読性の定義
すべてのイベントは「誰が、いつ、何を、どこで、どうなったか（主体、日時、アクション、リソーススコープ、成功または拒否）」に答える必要があります。内部サービス名を顧客向けのリソース名に変換し、ユーザーアクション、自動化、サポートの代理ログインを区別します。Google CloudはAdmin Activity、Data Access、System Event、Policy Deniedログを分けています。「すべてのログ」は適切なプロダクトの境界線ではありません。
ステップ3：権限、プライバシー、テナント境界の設計
アクセスは監査権限を持つロールに制限し、テナント、組織、サブアカウント間の境界を定義します。個人データ、トークン、リクエストパラメータ、コンテンツをマスキング（レダクション）します。ログを閲覧すること自体も監査イベントとして記録されるべきです。リスクの高いData Access記録については、機密詳細を通常の管理画面に表示するのではなく、要約のみにするか顧客のセキュリティプラットフォームへエクスポートする形から始めます。
ステップ4：ソース、整合性、クエリ体験の担保
「対象外」「閲覧権限なし」「イベントが存在しない」を明確に区別し、ソースカバレッジと取り込みレイテンシの目標を設定します。追記専用（append-only）または読み取り専用ストレージを使用し、削除や変更を制限します。バージョン1には時間、実行者、アクション、リソース、結果によるフィルターが必要です。大規模アカウント向けには、ブラウザですべてのイベントを読み込むのではなく、ページネーション、エクスポート、APIの提供が不可欠です。
ステップ5：価値とコストの評価
価値を顧客タスクに結びつけます。「誰が権限を変えたか」というチケットの削減、調査時間の短縮、セキュリティ機能の導入率向上、契約更新への信頼などです。コストには収集、インデックス作成、ホット/コールドストレージ、レプリケーション、権限サポート、誤認によるサポート負荷が含まれます。長期アーカイブやリアルタイムアラートに投資する前に、エンタープライズ顧客のコホートで高頻度クエリを検証します。
ステップ6：Go/No-Goゲートによる段階的ロールアウト
社内でリハーサルを行い、5〜10社の顧客に管理イベントの検索とCSVエクスポートを公開します。Goの条件は、ソースカバレッジ、権限テストの合格、説明可能なレイテンシ、画面とエクスポート結果の一致です。主要なアクションが確実に記録されない場合、テナント間アクセスが境界を超える場合、あるいは顧客がこの画面を完全なフォレンジックシステムと誤解する恐れがある場合はNo-Goとします。まずは境界と説明文を修正します。
質の高い回答例
このニーズを完全なSIEMの要求としてではなく、「誰が・いつ・どのリソースに対して・何を行ったか」に対する信頼できる回答として定義します。最初のユーザーはセキュリティ管理者および権限を制限された組織管理者とします。バージョン1では権限、SSO、APIキー、重要な設定の変更を対象とし、詳細なデータアクセスや長期アーカイブは将来のスコープとします。
初期リリースでは、実行者、日時、アクション、リソース、結果、ソースを記録し、フィルター、マスキング、ロールベースアクセス制御、CSVエクスポートを提供します。イベントは追記専用とし、ログの閲覧自体も記録します。社内でリハーサルを行った後、5〜10社のエンタープライズアカウントでベータテストを実施し、関連チケット数、セルフサービス解決率、クエリレイテンシ、ソースカバレッジ、ストレージコストを測定します。
画面とエクスポートの結果が異なる場合、主要なソースが欠落している場合、または権限テストでテナント間アクセスが確認された場合は、拡大を一時停止します。カバレッジとアクセスのゲートを通過した後に、不変保持、APIアクセス、リアルタイムアラートを検討します。提供する価値は検証可能な調査能力であり、汎用的なコンプライアンスの保証ではありません。
よくある間違いと改善策
- 監査ログを生ログすべてと混同する：顧客のタスクとイベントスコープを定義する。
- ユーザーとタイムスタンプのみを一覧表示する：リソース、アクション、結果、ソース、権限を含める。
- コンプライアンスを安易に確約する：カバレッジ、保持期間、顧客責任の境界を明記する。
- ログ閲覧の機密性を無視する：ログへのアクセス自体を記録する。
- ページ閲覧数のみを測定する：チケット削減率、クエリ成功率、レイテンシ、コストを含める。
追加の質問と回答
初回バージョンですべてのデータアクセスイベントを表示すべきですか？
いいえ。フィールドと権限が信頼できる高価値な管理イベントから始めます。データアクセスイベントはプライバシー、ストレージ、エクスポートの制御をより厳格にする必要があり、別途リリース判定ゲートを設けるべきです。
管理者によるログ改ざんをどのように防ぎますか？
追記専用または不変（immutable）ストレージを使用し、削除や設定権限を制限し、ログ自体へのアクセスを記録して、顧客が独自に保持できるエクスポート経路を提供します。整合性の保証範囲を正確に伝えます。
イベントが欠落している場合はどうしますか？
ソースがカバーされていないのか、閲覧者に権限がないのか、取り込みが遅延しているのかを表示します。ソースカバレッジと取り込みラグを追跡し、「ログが存在しないこと」を「アクションが発生しなかった証拠」として表示してはなりません。
この機能がコストに見合うことをどのように証明しますか？
調査時間、監査関連チケット、セルフサービス解決率、採用率、エクスポート量、ストレージコストについて、エンタープライズ顧客のコホート間で比較します。セキュリティ管理者にインタビューし、単にページを開いたかどうかではなく、ログが実際の意思決定に役立ったかを確認します。