SOC 2監査が難しいのはコントロールが複雑だからではありません。エビデンスが分散しているからです。アクセスレビューはIDプロバイダーにあります。暗号化の詳細はインフラ設定に埋もれています。ベンダーリスク評価はスプレッドシートにあります。インシデント対応手順は前回の監査以来更新されていないWikiにあります。監査ログはデータベースにありますが、監査人が望むフォーマットに集約した人はいません。
四半期ごとに、誰かが6つの異なるシステムからデータを引き出し、レポートにフォーマットし、前回チェックした時から何も変わっていないことを祈って数日を費やします。
JieGouのSOC 2エビデンスアグリゲーターはその作業を排除します。1つのAPIコールで6つのエビデンスセクションをカバーする構造化レポートを返します — ライブプラットフォームデータから並列フェッチ、パフォーマンスのためにキャッシュ、いずれかのセクションが一時的に利用不可でもグレースフルにフェイルするよう設計。
レポート構造
単一のGET /api/soc2-evidence?accountId=Xで完全なレポートを返します。SOC 2監査人が重視するエビデンスカテゴリに基づいて9つのセクションで構成：
| セクション | 内容 | ソース |
|---|---|---|
| アクセスレビュー | ユーザーごとのロール、権限、部門割り当て、リソースアクセス数、最終アクティビティ | ガバナンスモジュール + 権限エンジン |
| セキュリティメトリクス | 認証失敗、ブロックIP、APIキーヘルス、使用量スパイクアラート | セキュリティアナリティクス |
| 暗号化インベントリ | アルゴリズム、鍵サイズ、スコープ、管理詳細を含む10の暗号化コントロール | 静的カタログ |
| ベンダーレジスター | リスクレベル、認証、データアクセス分類を含む11のサードパーティベンダー | 静的カタログ |
| インシデント対応 | 4フェーズにわたる6つの手順、重大度定義、SLA、ステップバイステップランブック | 静的カタログ |
| コンプライアンス設定 | アクティブなコンプライアンスフレームワーク、データレジデンシールール、PII検出設定 | アカウント設定 |
| データレジデンシー | カテゴリごとのレジデンシーモード（ローカルのみ、クラウド同期、クラウドリダクト） | アカウント設定 |
| 保持ポリシー | 監査ログ保持期間と設定 | アカウント設定 |
| 監査ログサマリー | 30日間のイベント数、アクション内訳、アクティビティ上位10アクター | Firestore audit_logs |
レポートはバージョン管理（1.0.0）とタイムスタンプ付きです。各セクションに独自のgeneratedAtタイムスタンプがあり、監査人が各エビデンスの収集時期を正確に確認できます。
アクセスレビュー
アクセスレビューセクションは監査人が最も時間を費やすものです。JieGouはライブプラットフォームデータから自動生成します。
アカウント内のすべてのユーザーについて：
- ID — メール、表示名、ユーザーID
- ロール — グローバルロール（Owner、Admin、Dept Lead、Member、Auditor、Viewer）と数値レベル
- 部門 — ユーザーが所属する部門
- 権限 — ロールが付与するきめ細かい権限の完全リスト（8カテゴリにわたる26権限）
- リソースアクセス — このユーザーがアクセス可能なレシピとワークフローの数
- 最終アクティブ — ユーザーの最新アクティビティのタイムスタンプ
レポートにはロール分布も含まれ、各ロールレベルのユーザー数を示し、監査人が権限割り当てが最小権限の原則に従っていることを検証できます。
APIキーサマリーがアクセスレビューを完結：総キー数、設定済みLLMプロバイダー、キーごとの詳細（プロバイダー、有効性ステータス、経過日数）。監査人は別のキー管理コンソールを掘り返すことなく、古いまたは孤立したキーが存在しないことを検証できます。
暗号化インベントリ
SOC 2 Trust Services Criteria CC6.1は暗号化コントロールの文書化を要求します。JieGouの暗号化インベントリは保存時と転送時のデータをカバーする10のコントロールをカタログ化：
| コントロール | アルゴリズム | スコープ |
|---|---|---|
| BYOK Key Encryption | AES-256-GCM | Firestoreに保存された顧客APIキー |
| Firestore Data at Rest | AES-256 | すべてのFirestoreコレクション |
| Session Cookie Signing | RS256 (JWT) | Firebase Authセッションクッキー |
| Password Storage | bcrypt / scrypt | ユーザーパスワードハッシュ |
| TLS — Istio Gateway | TLS 1.3 | *.jiegou.aiへのすべてのHTTPSトラフィック |
| TLS — Firebase Services | TLS 1.3 | Firestore & Auth APIトラフィック |
| TLS — Redis Cluster | TLS 1.2+ | Redisキャッシュ接続 |
| Document Freshness Hash | SHA-256 | URLドキュメント変更検出 |
| Session Cache Key Hash | SHA-256 | Redisセッションキャッシュキー |
| Container Image Verification | SHA-256 | ECR内のDockerイメージダイジェスト |
各コントロールには鍵サイズ、管理者（JieGou、Google Cloud、AWS、Firebase）、コードベース内のソースモジュール、保存時・転送時・その両方のいずれをカバーするかが含まれます。これはマーケティング上の主張ではなく、インフラに直接マッピングされる機械読み取り可能なインベントリです。
ベンダーレジスター
サードパーティベンダー管理はSOC 2要件です。JieGouのベンダーレジスターは構造化リスク評価付きの11ベンダーをカタログ化：
各ベンダーについて：
- リスクレベル — クリティカル、高、中、低
- SOC 2認証ステータス — ベンダーがSOC 2 Type IIを保持しているか
- その他の認証 — ISO 27001、FedRAMP、PCI DSS、HIPAA等
- データアクセス — ベンダーがアクセス・処理できるデータ
- 緩和策 — このベンダーのリスクを低減する具体的なコントロール
- レビュースケジュール — 前回のレビュー日と次回のレビュー日
ベンダーはクリティカル（GCP、AWS、Firebase Auth — データをホスト）から中（メール用Resend、キャッシュ用Redis）まで。LLMプロバイダー（Anthropic、OpenAI、Google AI）は高に分類 — 顧客プロンプトを一時的に処理しますが、BYOKサポートとノートレーニングポリシーがリスクを緩和。
レジスターには汎用的な記述ではなくベンダー固有の緩和策が含まれます。Stripeの場合：「PCI DSS Level 1認証 — カードデータはJieGouサーバーに触れない。」Redisの場合：「キャッシュオンリーモード（永続性無効） — PVなし。」これらは監査人が探す詳細です。
インシデント対応ランブック
SOC 2 CC7.3とCC7.4は文書化されたインシデント対応手順を要求します。ランブックには4フェーズにわたる6つの手順が含まれます：
フェーズ1：検出＆トリアージ（全重大度） — アラートを確認、重大度P1-P4を分類、インシデントチャネルを作成、初期エビデンスを保全。
フェーズ2：封じ込め — 重大度別の3つの手順：
- データ侵害（P1） — 影響を受けたアカウントを特定、侵害されたユーザーを無効化、APIキーをローテーション、セッションキャッシュをフラッシュ、監査ログを保全、GDPRに基づき72時間以内に顧客に通知
- 不正アクセス（P1） — セッションを取り消し、アカウントを無効化、IPブロッキングをチェック、アクセスレビューを実行、横方向移動を調査
- サービス停止（P2） — サーキットブレーカーをチェック、代替LLMプロバイダーにフェイルオーバー、Redisのフェイルオープンを検証、顧客ステータス更新を投稿
フェーズ3：根絶＆復旧（P1-P3） — 根本原因分析、修正デプロイ、本番検証、サービス復旧。
フェーズ4：ポストモーテム（P1-P2） — 48時間以内のブレームレスレビュー、インシデントタイムライン編纂、是正措置追跡。
各手順ステップには責任者（オンコールエンジニア、セキュリティリード、インフラエンジニア）、分単位のSLA、使用する具体的なツール（汎用カテゴリではなく実際のモジュール名とコマンド）、状況悪化時のエスカレーショントリガーが含まれます。
重大度定義には明示的な対応時間SLAがあります：P1クリティカル15分、P2高1時間、P3中4時間、P4低24時間。
監査ログサマリー
監査ログサマリーは過去30日間のアクティビティを2つのビューに集約：
アクション内訳 — アクションタイプごとのカウント。期間内のレシピ実行、ワークフロー実行、ロール変更、APIキー操作、設定更新、その他の監査可能イベントの数。監査人にプラットフォーム上で何が起きているか、アクティビティパターンが正常かを伝えます。
トップアクター — イベント数上位10の最もアクティブなユーザー。監査人はこれを使って高アクティビティアカウントが予想されるユーザー（自動化サービスアカウント、パワーユーザー）に対応し、異常な動作ではないことを検証します。
サマリーはパフォーマンスのため1,000イベントに制限されます。より大量のアカウントでは、生の監査ログはガバナンスモジュールを通じて常に利用可能です。
構築方法
エビデンスレポートはPromise.allを使用して全9セクションを同時に並列フェッチして生成されます。6セクションはライブクエリ（アクセスレビュー、セキュリティメトリクス、コンプライアンス設定、データレジデンシー、保持ポリシー、監査ログサマリー）。3つは静的カタログ（暗号化インベントリ、ベンダーレジスター、インシデント対応ランブック）。
フェイルオープン設計。 各動的セクションは.catch()ハンドラーでラップ。セキュリティメトリクスサービスが一時的に利用不可でも、レポートは他の8セクションが入力され、失敗セクションは安全なデフォルトで埋められて返されます。1つのサブシステムが遅いからといってレポート全体が失敗することはありません。
Redisキャッシング。 完全なレポートは5分間キャッシュされます。監査中、複数のチームメンバーが同じレポートを繰り返し取得する可能性があります。キャッシングが冗長なFirestoreクエリを防ぎ、応答時間の一貫性を保ちます。
セクションレベルアクセス。 常に完全なレポートが必要なわけではありません。?section=access-reviewを追加してアクセスレビューのみ、または?section=encryption-inventoryで暗号化カタログのみを取得。6つのセクションが個別にアドレス可能：access-review、security-metrics、encryption-inventory、vendor-register、incident-response、audit-log-summary。
権限モデル
エンドポイントにはaudit:read権限が必要で、Auditorロール（レベル15）以上にマッピングされます：
- Auditor、Dept Lead、Admin、Owner — レポートを取得可能
- Member、Viewer — アクセス不可
最小権限の原則に沿っています。コンプライアンスチームは管理者アクセスなしでエビデンスを生成できます。ワークフローの実行やレシピの編集ができるエンジニアリングチームメンバーは、ロールが正当化しない限りセキュリティ体制レポートへのアクセスはありません。
利用可能プラン
SOC 2エビデンス収集はEnterpriseプランで利用可能です。完全なエビデンスレポートAPI、個別セクションアクセス、アクセスレビュー、暗号化インベントリ、ベンダーレジスター、インシデント対応ランブック、監査ログサマリーを含みます。エンタープライズ機能の詳細またはトライアルを開始。