AI/BIのMLOps: Databricks Genie移行の自動化

MLOps for AI/BI: Automating Databricks Genie Migrations | by AI on Databricks | Jan, 2026 | Mediumの翻訳です。

本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

著者: David Huang; Specialist Solutions Architect

イントロダクション

モダンなAIを活用する企業では、「生データ」と「ビジネス洞察」の間の距離は縮まっています。Databricks AI/BI Genieのようなツールによって、ユーザーは自然言語を用いて自身のデータに対して複雑な質問を行うことができます。しかし、組織が拡大すると彼らは古典的なDevOpsの課題に直面します: 手動の再設定なしに、どのようにしてGenieスペースを開発からプロダクションに移行するのか？

もし、手動で指示やサンプルSQLクエリー、テーブルのマッピングをワークスペース間でコピーアンドペースしたのであれば、それがヒューマンエラーのレシピであることを知っているはずです。

これを解決する助けになるように、企業の本番運用に使えるようにこのプロセスを自動化するために、Databricks Asset Bundlesと新たなGET、CREATE、UPDATE APIを用いたGenie移行サンプルコードを開発しました。

課題: なぜGenieの移行は難しいのか？

Genieスペースは単なるテーブルへの接続ではありません。キュレーションされた「知識ベース」です。この知識を手動で、開発、ステージング、プロダクションのワークスペース間で手動で移行することは、プログラムを用いない方法では管理が困難な以下のコンポーネントによって危険に満ちたものとなります:

• コンテキストに基づく指示: これらは特定のビジネスロジック、「基本ルール」であり、Genieがどのように自然言語のクエリーを解釈すべきかを説明するガードレールです。
• サンプルSQLクエリー: これらのキュレーションされたサンプルは、Genieが正確で最適化されたSQLを生成するようにするための重要な「few-shotの例」として動作します。これらのサンプルを手動でコピーすることは、面倒かつフォーマットのエラー、不意の省略の可能性が高まり、AIが生成するコードの品質に直接のインパクトを与えます。
• Unity Catalogのマッピング: Genieスペースには、ハードコードされたカタログ、スキーマ、テーブルへの参照が含まれます。典型的なMLOpsフローにおいては、これらの参照は変更されるべきです(dev_catalog.sales.dataからprod_catalog.sales.dataへなど)。UIを通じて手動でこれらを編集することは、環境の不適合や接続の破損の原因となります。
• ベンチマーク: これらは、Genieスペースがデプロイメント前後において期待した通りに動作していることを検証されるために用いられるテストの質問です。環境横断で一貫性のあるベンチマークのセットを維持することは、退行テストにおいて重要ですが、すべてのワークスペースでテストデータと期待するアウトプットを手動で確保することは、時間を浪費し、大規模においてはほとんど不可能となります。

これらの重要で相互接続する要素を、開発、ステージング、本番運用環境間で手動で移動させることは、遅く、ヒューマンエラーに対して非常に脆弱なものとなり、バージョン管理を完全に破壊し、誰がいつ何を変更したのを監査することを不可能にします。この厳密さの欠如は、AI/BIアプリケーションにおける企業レベルの信頼の確立の根本的な障壁となります。

ソリューション: プログラムによる移行ワークフロー

新たなGenie APIを用いることで、あなたの開発環境のGeniスペースをJSONフォーマットにシリアライズすることができるようになりました。DABによって、あなたの開発環境、本番運用環境に対するこの「シリアライズ」→コピー→「デプロイ」パターンを自動化することができます。また、このプロセスは、「ゴールデン」Genieスペースが更新された際にいつでも、デプロイメントをトリガーできるようにGitHub ActionsやAzure DevOpsに組み込むことができます。

動作原理: 内部動作

この移行プロセスは3ステップのパターンに従います:

#1 エクスポート(シリアライズ)

あらたなGET APIのおかげで、Genieスペースをserialized_space JSONオブジェクトにエクスポートすることができます。これには、指示、知識ベース、joinの仕様を含むあなたのGenieスペースの完全な設定が含まれています。

私の実装では、以下のようにシリアライズされたスペースを取得するためにDatabricks SDKを使用するexport_genie_spaceスクリプトを実行します。

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.dashboards import GenieSpace

w = WorkspaceClient()
space_id = "your_genie_space_id"

space: GenieSpace = w.genie.get_space(
    space_id=space_id,
    include_serialized_space=True # to get the serialized space
)

serialized_space = space.as_dict().get("serialized_space")

そして、シリアライズされたスペーシウのJSONスキーマは以下のようになります:

{
  "version": 1,
  "config": {
    "sample_questions": [
      {
        "id": "string (hex)",
        "question": ["string"]
      }
    ]
  },
  "data_sources": {
    "tables": [
      {
        "identifier": "catalog.schema.table",
        "description": ["string"],
        "column_configs": [
          {
            "column_name": "string",
            "description": ["string"],
            "get_example_values": true,
            "exclude": false,
            "synonyms": ["string"],
            "build_value_dictionary": false
          }
        ]
      }
    ],
    "metric_views": [
      {
        "identifier": "catalog.schema.metric_view",
        "description": ["string"]
      }
    ]
  },
  "instructions": {
    "text_instructions": [
      {
        "id": "string (hex)",
        "content": ["string (markdown)"]
      }
    ],
    "example_question_sqls": [
      {
        "id": "string (hex)",
        "question": ["string"],
        "sql": ["string"],
        "parameters": [
          {
            "name": "string",
            "type_hint": "STRING | INTEGER | DATE | ...",
            "description": ["string"]
          }
        ],
        "usage_guidance": ["string"]
      }
    ],
    "sql_functions": [
      {
        "id": "string (hex)",
        "identifier": "catalog.schema.function"
      }
    ],
    "join_specs": [
      {
        "id": "string (hex)",
        "left": {
          "identifier": "catalog.schema.table",
          "alias": "string"
        },
        "right": {
          "identifier": "catalog.schema.table",
          "alias": "string"
        },
        "sql": ["join_condition --rt=RELATIONSHIP_TYPE--"],
        "comment": ["string"]
      }
    ],
    "sql_snippets": {
      "filters": [
        {
          "id": "string (hex)",
          "sql": ["string"],
          "display_name": "string",
          "instruction": ["string"],
          "synonyms": ["string"]
        }
      ],
      "expressions": [
        {
          "id": "string (hex)",
          "sql": ["string"],
          "display_name": "string",
          "synonyms": ["string"]
        }
      ],
      "measures": [
        {
          "id": "string (hex)",
          "sql": ["string"],
          "display_name": "string",
          "instruction": ["string"]
        }
      ]
    }
  },
  "benchmarks": {
    "questions": [
      {
        "id": "string (hex)",
        "question": ["string"],
        "answer": [
          {
            "format": "SQL",
            "content": ["string"]
          }
        ]
      }
    ]
  }
}

見てわかるように、これにはあなたのGenieスペースの完全な設定が含まれています。

#2 変換(JSONの更新)

これで、あなたのローカル開発環境にダウンロード可能なJSONオブジェクトとしてスペースの設定がシリアライズされたので、ターゲットの本番運用ワークスペースに適した特定の変数にするためにこの機会を活用することができます。例えば:

1. ターゲットのGenieスペースが本番環境の適切なオブジェクトをポイントするように、カタログ名、スキーマ名、テーブル名を更新する必要があるかもしれません。
2. また、本番環境に存在するサーバレスやPro SQLウェアハウスを使うようにする必要があるかもしれません。

#3 ロード(作成あるいは更新)

最後に、deploy_genie_spaceスクリプトは前のステップでシリアライズされたJSONを用いて、本番環境に新規のGenieスペースを作成、あるいは既存のスペースを更新します。これは、Databricks SDKを用いることで行われます。式スペースを作成する際には、Genieが作成されるワークスペースディレクトリを指定する必要があることに注意してください。そうでない場合には、更新を反映するために既存のGenieスペースのIDを提供する必要があります。

こちらが、Databricks SDKの動作を示す例となります:

# to update an existing space 
result: GenieSpace = w.genie.update_space(
    space_id=existing_space_id,
    title=title,
    description=description,
    serialized_space=serialized_space,
    warehouse_id=target_warehouse_id
)

# to create a new space
result: GenieSpace = w.genie.create_space(
    warehouse_id=target_warehouse_id,
    serialized_space=serialized_space,
    title=title,
    description=description,
    parent_path=target_parent_path
)

オーケストレーションと実行

Databricksアセットバンドル(DAB)は、このソリューションにおいて重要なInfrastructure as Code (IaC)レイヤーとして動作します。Genieスペースの設定をコードとして取り扱うことで、DABは設定自身に対する3ステップのETLのようなパイプラインを管理するオーケストレーションエンジンとして動作します。これらは、(databricks.ymlファイルを通じて)ワークフロー全体を宣言的に定義し、ワークフローのステップが開発、ステージング、本番環境において、信頼性を持って繰り返し実行されることを確実なものとします。

私の実装例では、自分のローカルIDEと(Databricksノートブックとして)リモートでLakeflowジョブとしてDatabricksで実行される独立した2つのPythonスクリプトを用いたDABを使用しています。上述したように、これらのスクリプトは開発環境からGenieスペースをシリアライズ、コピーし(export_genie_spaceスクリプト)、本番環境に新たなGenieスペースをデプロイ、作成します(deploy_genie_spaceスクリプト)。

こちらが、このワークフローをオーケストレート、実行するために、私のローカルIDEでどのようにDABを使用したのかを図示したものです。

DABの詳細については、こちらのドキュメントをご覧ください。

なぜこれが企業で重要なのか

この移行ワークフローは、Genieスペースを開発、本番運用に投入するための堅牢かつプログラムを用いた方法を必要とする企業においては重要なものとなります:

• 一貫性: 最も重要なメリットは、すべての環境横断でAI/BIアプリケーションが全く同じ挙動をすることを保証できることです。プログラムを用いて、 - コンテキストに基づく指示、サンプルSQLクエリーを含む完全かつシリアライズされた設定を移行することで、企業では「四半期の収益」や「顧客生涯価値」の計算のようなコアのビジネスロジックが、開発、ステージング、本番環境で全く同じであることを保証できます。これによって、AIが生成する洞察の確立の主要な障壁である環境ドリフトのリスクを排除することができます。
• スピード: この自動化は、本番環境への新機能のプロモーションや更新に必要な時間を劇的に削減します。UIの移動、指示のコピー&ペースト、環境編集の手動での編集を含む手動での移行はデプロイメントごとに多大なる時間を要する場合があります。プログラムを用いたアプローチは、これを数分で完了する完全に自動化されたスクリプトの実行に削減し、チームは自信を持って1日に複数回の更新をデプロイすることができ、新たなAI/BIの機能の市場投入を加速することができます。
• 監査可能性: Genieスペースの設定をコードとして取り扱い、エクスポートしたGenieのJSONをGitのようなバージョン管理システムに格納することで、企業は完全かつ検証可能な監査証跡を手に入れることができます。これによって、誰がどの指示をいつ、なぜ変更したのかを正確に追跡できるようになるので、問題が検知された場合には以前の「ゴールデン」設定にロールバックすることがシンプルに行えるようになります。この厳密性は、企業レベルの信頼の確立とコンプライアンスリスクの管理において重要なものとなります。

使い始める

私のGitHubリポジトリでPythonスクリプトとDABコードを含む完全な実装を確認できます。AI/BIは進化し続けているので、ETLコードと同じ厳密性を持って「Genieの指示」を取り扱うことが、ビジネスステークホルダーとの信頼を確立する唯一の方法となります。あなたのワークフローの助けになるのであればスターをください！

はじめてのDatabricks

はじめてのDatabricks

Databricks無料トライアル

Databricks無料トライアル