コンプライアンスと監査：不変の台帳
SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security
デフォルトでSOC2およびGDPRコンプライアンスを実現する。追跡可能な実行履歴。
コンプライアンス税：なぜ監査はあなたを遅らせるのか
SOC2、ISO27001、あるいはHIPAAの監査を経験したことがあるなら、その痛みをご存知でしょう。監査官はこう尋ねます。「すべてのユーザーオフボーディングリクエストが24時間以内に処理されたことを証明する証跡を見せてください」と。
従来のシステムでは、これは慌ただしい宝探しの引き金になります。
- メールログを検索する。
- Splunkの中から「Deleted User」的なメッセージをgrepする。
- JIRAチケットのスクリーンショットを撮る。
- スプレッドシートでタイムスタンプを突き合わせる。
この手作業による証跡収集には、エンジニアリングの時間が何週間もかかります。これがコンプライアンス税です。最優秀の人材を機能開発から遠ざけてしまいます。さらに悪いことに、その証跡はしばしば状況証拠に過ぎません。スクリプトが実行されたことは証明できても、そのスクリプトが正確にどのデータに触れたかを証明できるでしょうか？
不変の台帳：デフォルトでの監査
SchemaBridgeでは、コンプライアンスは独立した活動ではなく、実行の副産物であるべきだと考えています。私たちのエンジンは追記専用のイベントログ（Append-Only Event Log）（第1回）を基盤としているため、あらゆるアクション、決定、変数の変更が不変の履歴として記録されます。
イベントソーシングの力
私たちは現在の状態だけを保存するのではなく、そこに至るまでの履歴のすべてを保存します。
- 追記専用：履歴テーブルのレコードを上書きすることは決してありません。すべての状態変化は新しい行として記録されます。
- 追跡可能性：ワークフローを最初から最後まで再生し、各ステップで入力が何だったか、ロジックが何を決定したか、出力が何だったかを正確に確認できます。
- 改ざんの検知：ログは順序どおりかつ不変であるため、欠落や改変があればただちに露見します。
GDPRと「忘れられる権利」
イベントソーシングにおける最も難しい課題の一つが、「忘れられる権利」（GDPR第17条）です。ログが不変であるなら、ユーザーのPII（個人を特定できる情報）をどうやって削除するのでしょうか？
フィールドマスキングと保持ポリシー
SchemaBridgeはこれを厳格な保持ポリシーによって解決します。
1. PIIの分離：開発者には、ワークフローコンテキスト内の機微なフィールドにフラグを立てることを推奨しています。
2. 自動パージ：ワークフローレベルで保持ポリシー（例：「ログを30日間保持する」）を設定できます。エンジンはプライバシー要件を満たすため、DynamoDBから古い履歴データを自動的にパージします。
3. フィールドマスキング：開発者に公開されるログでは、機微なフィールドはデフォルトでマスク（***）され、デバッグ作業中にPIIが不用意に閲覧されることを防ぎます。
SOC2証跡収集の自動化
SchemaBridgeワークフローを使えば、監査そのものを自動化できます。
「監査官ボット」
手作業でスクリーンショットを集める代わりに、毎週月曜日に実行される専用の「証跡収集」ワークフローを作成します。
1. スキャン：GitHub APIに問い合わせて、先週マージされたすべてのPRを一覧化します。
2. 検証：各PRにコードオーナーによる「承認済み」レビューがあるかを確認します。
3. スナップショット：コンプライアンス状況のJSONスナップショットを取得します。
4. アーカイブ：署名付きレポートをWORM（Write Once, Read Many）方式のS3バケットに書き込みます。
監査官が来訪した際には、そのS3バケットへの読み取りアクセス権を渡すだけで済みます。監査準備の時間は数週間からゼロへと短縮されます。
ケーススタディ：HIPAA準拠の患者オンボーディング
私たちは、患者の受け入れフォームを自動化する必要があったHealthTechスタートアップと協業しました。
課題
彼らは以下を証明する必要がありました。
1. 権限を持つ医師のみが患者の病歴を閲覧したこと。
2. すべてのアクセスがログに記録されていること。
3. データがSplunkやDatadogのようなサードパーティのロギングツールに一切露出しなかったこと。
SchemaBridgeによる解決策
1. アクセスログ：ワークフローの頂点が患者データの変数にアクセスするたびに、汎用的な「アクセスイベント」が台帳に書き込まれました。
2. 保管庫化されたロギング：生データがstdoutに送られることは一切ありませんでした。HIPAA_OFFICERロールを持つユーザーのみがSchemaBridgeダッシュボード上でそれを閲覧でき、その閲覧自体もすべて記録されました。
結果
彼らはゼロの不適合でHIPAA監査に合格しました。監査官は、データそのものを露出させることなく、患者データへのアクセス履歴を正確に再生できる能力に感銘を受けました。
比較：従来型のロギング vs. SchemaBridgeのコンプライアンス
| 項目 | Syslog / Splunk | データベース監査テーブル | SchemaBridge台帳 |
| :--- | :--- | :--- | :--- |
| 不変性 | 低い（削除可能） | 中程度（DBAが編集可能） | 高い（追記専用） |
| コンテキスト | 単一行 | 行の変更 | ワークフロー全体のコンテキスト |
| PII対応 | 手動マスキング | カラム暗号化 | 自動マスキング |
| 保持 | 限定的（コスト高） | 限定的（パフォーマンス制約） | 設定可能なポリシー |
コンプライアンスアーキテクチャのためのエキスパートチェックリスト
1. PIIをログに出さない：stdoutに出力する内容には十分注意してください。状態の永続化はエンジンに安全に任せましょう。
2. 証跡を自動化する：手作業で行えば、いずれミスをします。監査はスクリプト化してください。
3. 職務を分離する：ワークフローを書く人と、管理者キーを保持する人は別であるべきです。
4. 削除をテストする：「模擬GDPRリクエスト」を定期的に実行し、保持ポリシーが実際に機能しているか検証してください。
結論：信頼とはAPIである
コンプライアンスとは事務手続きの問題ではなく、信頼の問題です。検証可能で不変な履歴という基盤の上にシステムを構築することで、「私を信じてください、優秀なエンジニアですから」という状態から、「このシステムを信じてください」という状態へと移行できるのです。
第15回では、本シリーズの締めくくりとして「インテグレーションの未来」を取り上げ、AIエージェントがまもなくこれらのワークフローを私たちに代わって記述・管理するようになる様子を見ていきます。