コンプライアンスと監査：副産物としてのエビデンス

SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security

記録された実行履歴でSOC2のエビデンス収集とGDPRの消去対応を容易にし、保証しない点も正確に示します。

コンプライアンス税：監査が開発を遅らせる理由

SOC2、ISO27001、HIPAA の監査を経験したことがあれば、その苦労はご存じでしょう。監査人はこう尋ねます。「ユーザーのオフボーディング要求がすべて 24 時間以内に処理されたことを示すエビデンスを見せてください。」

従来のシステムでは、これが慌ただしい宝探しの始まりになります。

メールログを検索する。
Splunk で「Deleted User」のようなメッセージを grep する。
JIRA チケットのスクリーンショットを撮る。
スプレッドシートでタイムスタンプを突き合わせる。

こうした手作業のエビデンス収集は、エンジニアリング時間を何週間も奪いかねません。これがコンプライアンス税です。最も優秀なメンバーを機能開発から引き離してしまいます。さらに悪いことに、エビデンスは状況証拠にすぎないことがよくあります。スクリプトが実行されたことは証明できても、それが正確にどのデータに触れたかを証明できるでしょうか？

監査証跡：副産物としてのエビデンス

SchemaBridge では、エビデンスは実行の副産物であるべきで、別個の作業であるべきではないと考えています。エンジンは動作しながら監査証跡を書き込みます。対象は、実行の開始・リプレイ・オペレーターによる解決、ワークフロー・頂点・エッジの変更、デプロイ、設定と保持期間の変更、権限とロールの変更、そして承認の判断です。

証跡から得られるもの

記録された状態遷移：実行の状態そのものは PostgreSQL に保持され、実行の進行に伴って更新されます。それと並行して、すべての状態遷移が実行トレースに追記されるため、「どうしてこうなったのか」に後から答えられます。監査証跡に記録されるのは実行の開始とそれに対するオペレーターの操作であり、すべての遷移ではありません。
トレーサビリティ：任意の実行について、各ステップの記録済みの入力と出力を確認できます（保持期間内に限ります）。違いに注意してください。SchemaBridge の Replay は、ワークフローを新しい実行として再実行するもので、副作用も含みます。読み取り専用の履歴再生ではありません。
クエリ可能な履歴：監査証跡は API を通じてワークスペース単位およびワークフロー単位でクエリでき、運用データベースとは分離された専用のカラムナストア（内部監査サービスの背後にある ClickHouse）に格納されます。

証跡ではないもの

保証内容については監査人に正確に伝えてください。監査証跡はアプリケーションレベルで追記専用ですが、改ざん検知可能（tamper-evident）ではありません。ハッシュチェーンや署名はなく、監査ログの書き込みはベストエフォートであるため、書き込みに失敗しても検出可能な欠落としては表面化しません。WORM レベルのエビデンスが必要な場合は、自社で管理する追記専用（write-once）ストレージに証跡をエクスポートしてください。

GDPR と「忘れられる権利」

履歴を保持するシステムにとって最も難しい課題の一つが「忘れられる権利」（GDPR 第 17 条）です。履歴を残しているなら、ユーザーの PII（個人を特定できる情報）をどう削除すればよいのでしょうか？

消去と保持

SchemaBridge はこれに消去パスと保持期間で対処します。

1. 消去：ワークスペースを削除すると専用の消去パスが実行されます。これは、取り消し不能な削除の前に記録され、削除後に検証される義務台帳（obligation ledger）に支えられています。個々のユーザーのデータは別のパスで消去されます。

2. 自動パージ：保持期間はワークスペースごとに設定されます（またはプランから継承されます）。期限を過ぎた実行行、トレース、ペイロードは自動的に削除されます。

3. 認証情報のマスキング：認証情報の形をしたフィールド（API キー、シークレット、トークン）は、実行ログ上で としてマスクされます。PII のマスキングは自動では行われない*ため、最善の防御策は、個人データを必要としないステップにそれを流さないことです。

SOC2 エビデンス収集の自動化

SchemaBridge のワークフローを使って、監査そのものの一部を自動化できます。

「監査ボット」

スクリーンショットを手作業で集める代わりに、毎週月曜日に cron スケジュールで実行される専用の「エビデンス収集」ワークフローを作成します。

1. スキャン：GitHub API に問い合わせ、前週にマージされたすべての PR を一覧化します。

2. 検証：各 PR に code owner による「Approved」レビューがあるかを確認します。

3. スナップショット：コンプライアンス状況の JSON スナップショットを作成します。

4. アーカイブ：監査人が読めるストレージにスナップショットを書き込みます（自社で管理する HTTP エンドポイント経由。理想的には追記専用ストレージ）。

監査人が来たら、スクリーンショットの山ではなくアーカイブを案内すればよく、その分だけ監査準備の時間が短縮されます。

{
  "week": "2026-W03",
  "mergedPullRequests": 42,
  "withCodeOwnerApproval": 42,
  "exceptions": []
}

例示シナリオ：規制環境における患者受付

患者の受付フォームを自動化する必要がある、仮想の HealthTech スタートアップを考えてみましょう。

課題

次のことを示す必要があります。

1. 受付ワークフローを変更・実行できたのは権限のあるスタッフだけであること。

2. ワークフローへのすべての変更と、すべての実行結果が記録されていること。

3. データがサードパーティのログツール（Splunk/Datadog）に一切公開されていないこと。

アプローチ

1. ロールベースのアクセス：ワークスペースのロール（admin、writer、reader）と権限スコープによって、ワークフローを編集・デプロイ・実行できる人を制限し、すべてのロール変更は監査証跡に記録されます。

2. 記録された実行：各受付実行の開始とオペレーターによる解決は監査証跡に残り、ステータスの全履歴は実行履歴に保持されます。各ステップのペイロードは stdout に出力されるのではなく、プラットフォーム内で確認できます。

3. 引き続き自社で担うべきギャップ：SchemaBridge は誰がペイロードを閲覧したかを記録せず、HIPAA 専用のロールもなく、HIPAA 認証も取得していません。閲覧単位のアクセスログと規制対応の書類作業は、引き続き同社の責任となります。

見込まれる効果

このような構成であれば、監査のうち変更管理と実行履歴に関する部分の負担は大幅に軽減されるでしょう。同時に、プラットフォームがカバーしない部分についても正直であることができます。

比較：従来のロギング vs. SchemaBridge 監査証跡

| :--- | :--- | :--- | :--- |

コンプライアンスアーキテクチャのためのエキスパートチェックリスト

1. PII をログに残さない：stdout に何を出力するか、ステップ間で何を受け渡すかに注意してください。個人データを必要としないペイロードには含めないようにします。

2. エビデンスを自動化する：手作業で行えば、必ずミスが起きます。監査をスクリプト化しましょう。

3. 職務を分離する：ワークフローを書く人と、管理者キーを保持する人は別にすべきです。

4. 削除をテストする：定期的に「模擬 GDPR リクエスト」を実行し、消去パスと保持パスが実際に機能していることを検証してください。

5. プラットフォームの限界を把握する：私たちを含むすべてのベンダーに、何がどのくらいの期間記録されるのか、そして改ざん検知が可能かを正確に尋ねてください。その回答をコントロールの記述に書き込みましょう。

結論：信頼は API である

コンプライアンスの本質は書類仕事ではなく、信頼です。記録されたクエリ可能な履歴を基盤にシステムを構築し、その履歴が何を保証し何を保証しないかを正確に示すことで、「信じてください、私は優秀なエンジニアです」から「こちらがエビデンスです」へと移行できます。

Building the Bridge シリーズの一部です。あわせてお読みください：インテグレーションの未来。