DatabricksにおけるModel Governance: 承認フロー・監査・再現性

モデルガバナンスとは、MLモデルのライフサイクル全体にわたって 「誰が・いつ・なぜ・どのモデルを本番にデプロイしたか」を管理・統制する仕組みです。 金融・医療・保険などの規制産業では、モデルの意思決定プロセスの監査が法的に求められるケースもあります。

Databricksでは、MLflow Tracking（再現性）、Unity Catalog Model Registry（承認フロー）、 UCの監査ログ（監査証跡）を組み合わせてモデルガバナンスを実現します。 この記事では3本柱の詳細と実務設計を解説します。

モデルガバナンスの3本柱

Unity Catalog Model Registry

UC Model Registryは、MLflowで学習したモデルをUnity Catalogの3層名前空間（catalog.schema.model_name）で 管理する仕組みです。旧Workspace版Model Registryとの最大の違いは以下の点です。

• 3層名前空間：catalog.schema.model_nameの形式で管理。 UCの権限モデル（GRANT / DENY）がモデルにも適用される
• エイリアス機能：固定ステージ（Staging/Production）の代わりに、 自由定義のエイリアス（例：Champion / Challenger / Baseline）を使用。 1つのバージョンに複数のエイリアスを付与可能
• クロスワークスペース共有：同一UCメタストア配下の複数ワークスペースから 同じモデルにアクセスできる
• リネージ追跡：モデルがどのテーブルから学習されたかを自動追跡

import mlflow

# UC Model Registryにモデルを登録
mlflow.set_registry_uri("databricks-uc")
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "prod_catalog.ml_schema.fraud_detector")

# エイリアスの付与
from mlflow import MlflowClient
client = MlflowClient()
client.set_registered_model_alias(
    name="prod_catalog.ml_schema.fraud_detector",
    alias="Champion",
    version=3
)

エイリアス運用の設計

MLflow Trackingでの再現性

モデルの再現性は、以下の4要素を記録することで担保されます。

承認フローの設計

本番モデルの昇格（Challenger → Champion）には、以下のような承認フローを設計します。

[データサイエンティスト]
  │
  ├─ 1. モデル学習 + MLflow Tracking記録
  │     └─ mlflow.log_param / log_metric / log_model
  │
  ├─ 2. UC Model Registryに登録
  │     └─ mlflow.register_model("runs:/{run_id}/model", "catalog.schema.model")
  │
  ├─ 3. Challengerエイリアスを付与
  │     └─ client.set_registered_model_alias(..., "Challenger", version=N)
  │
  [CI/CDパイプライン（自動）]
  │
  ├─ 4. バリデーションテスト実行
  │     ├─ 精度閾値チェック（AUC > 0.85）
  │     ├─ データドリフト検出
  │     ├─ レイテンシ要件チェック（p99 < 100ms）
  │     └─ フェアネス / バイアスチェック
  │
  ├─ 5. テスト結果をMLflow Runに記録
  │
  [MLリード / リスク管理者（手動承認）]
  │
  ├─ 6. テスト結果を確認し、承認 or 却下
  │
  ├─ 7. 承認された場合、Championエイリアスを付け替え
  │     └─ client.set_registered_model_alias(..., "Champion", version=N)
  │
  └─ 8. 旧ChampionをArchivedに変更

監査証跡

Unity Catalogの監査ログは、モデルに対する以下の操作を自動記録します。

• モデルの登録（CREATE_REGISTERED_MODEL）
• バージョンの追加（CREATE_MODEL_VERSION）
• エイリアスの変更（SET_REGISTERED_MODEL_ALIAS）
• 権限の変更（UPDATE_GRANTS）
• モデルの削除（DELETE_REGISTERED_MODEL）

これらのログはSystem Tablesのaudit_logsテーブルから検索可能であり、 「いつ・誰が・どのモデルバージョンをChampionに昇格させたか」を事後的に追跡できます。 規制対応（モデルリスク管理、SR 11-7等）で求められる証跡として活用できます。

実務での設計指針

• モデルの命名規則を統一：catalog.schema.{team}_{use_case}の形式で統一し、 検索性と管理性を確保する（例：prod_catalog.ml.fraud_detection_xgboost）
• autolog()を標準で有効化：チーム全体でmlflow.autolog()を有効にし、 パラメータ・メトリクスの記録漏れを防止する
• Deltaテーブルのバージョンを記録：学習データのDelta Versionを log_paramで記録し、同一データでの再学習を可能にする
• GRANTの最小権限原則：データサイエンティストにはモデル登録権限のみ付与し、 Champion昇格はMLリードまたはCI/CDパイプラインのみが実行できるようにする

試験で問われるポイント

• 「モデルの本番昇格を管理するDatabricksの仕組みは？」→ UC Model Registry + エイリアス
• 「モデルの再現性を担保するために記録すべき情報は？」→ コード・データ・環境・パラメータ
• 「エイリアスとステージの違いは？」→ エイリアスは自由定義・複数付与可能、ステージは固定3種
• 「モデルへの操作を監査するには？」→ UCのAudit Log（System Tables）

問題で確認

よくある質問