Databricks Apps × Claude Code × ユーザー代理認証 × Model Registry × Red Teaming で「ガバナンス付き生成AI運用」を最短で形にする

投稿日 2025年12月25日
更新日 2026年1月6日
著者 azure-recipe-user
カテゴリー Databricks
カテゴリー MLflow
カテゴリー Security
カテゴリー生成AI

久しぶりの投稿です。
先週末の自由研究で「Databricks上に生成AI Agent運用を寄せると、どこまで“楽に・安全に・運用可能な形”になるのか」を試しました。

結論から言うと、

Apps（UI）
ユーザー代理認証（アプリログイン＝Unity Catalog権限）
Serving Endpoint + Model Registry（ライフサイクル/バージョン管理）
推論テーブル + MLflow Trace（利用ログ/観測性）
AI Red Teaming（安全性評価）
Claude Code（テンプレ化/開発速度）

を組み合わせることで、「ガバナンス付きの生成AI運用」を短時間で“目に見える形”にできました。

本記事は、細部の実装というより「どう組むと、何が嬉しくて、何に詰まりやすいか」を中心にまとめます。
（詳細実装は、必要なら別記事に分解します。）

対象読者

Databricks Apps をこれから触る/検討している
Unity Catalog ガバナンスを アプリまで一貫させたい
生成AI（Agent/Serving）を 運用目線でまとめたい
Red Teaming を PoCではなく本番導入前提で考えたい

この記事のゴール

Databricks Apps で ログイン認証とUC権限を自動的に整合させる
Serving Endpoint + Model Registry で モデル運用の型を作る
推論ログ/Trace を活用して 観測性（Observability）を確保する
Microsoft AI Foundry の Red Teaming で 安全性の検証ループを回す
Claude Code で テンプレ化・自動デプロイの可能性を探る

全体アーキテクチャ（今回作ったもの）
Claude Code：テンプレ化・自動デプロイの可能性
Claude Code のセッティング（最短手順）
Databricks Apps：ユーザー代理認証（Preview）
Serving Endpoint × Model Registry：生成AI Agentを“運用可能”に寄せる
Microsoft AI Foundry：AI Red Teaming Agentで検証する
ダッシュボード（Streamlit）で可視化する
実務で効くポイント（落とし穴/運用Tips）
まとめ

1. 全体アーキテクチャ（今回作ったもの）

今回の構成はこれです。

                 [Foundation Model / 外部モデル]
                           ↑
[Databricks Apps(UI)] → [Serving Endpoint] ↔ [Model Registry]
        │                  │
        │                  ├─ 推論テーブル（Inference Tables）
        │                  └─ MLflow Trace（Observability）
        │
        └─ ユーザー代理認証（Appログイン＝Unity Catalog権限）
                 
（別系統）Microsoft AI Foundry / Azure AI Evaluation SDK
        └─ Red Teaming Scan → 結果をUCに格納 → Appsで可視化

				
					
				1
2
3
4
5
6
7
8
9
10
11
12

						                 [Foundation Model / 外部モデル]
                           ↑
[Databricks Apps(UI)] → [Serving Endpoint] ↔ [Model Registry]
        │                  │
        │                  ├─ 推論テーブル（Inference Tables）
        │                  └─ MLflow Trace（Observability）
        │
        └─ ユーザー代理認証（Appログイン＝Unity Catalog権限）
                 
（別系統）Microsoft AI Foundry / Azure AI Evaluation SDK
        └─ Red Teaming Scan → 結果をUCに格納 → Appsで可視化
 

					

			

ポイントは 「認証/ガバナンス」 「モデル運用」 「ログ/可視化」 「安全性評価」 を同じ土俵に乗せていることです。
スクラッチ実装でよく発生する「別々の仕組みの寄せ集め」を避けやすくなります。

2. Claude Code：テンプレ化・自動デプロイの可能性

近年は Vibe Coding（UIイメージ提示→コード生成）も成熟してきて、Databricks でも Claude Code がネイティブに利用できます。
また Databricks コミュニティが活発で、サンプルデモが手に入りやすいのも良い点です。

Claude Code の推しポイントは、claude.md に

コーディング規約
ディレクトリ構成
デプロイ手順/ルール
禁止事項（秘密情報の扱いなど）

を記述すると、それを前提としてコード生成・操作を進められるところです。
つまり、「人がレビューで何度も言うルール」を、最初からエージェントに埋め込める。

実際にコミュニティの Notebook 例を見ると、claude.md がかなり丁寧に作り込まれており、どれだけ明確な Markdown（指示）を用意できるかが重要だと分かります。

参考：

Apps Cookbook（ギャラリー）
https://apps-cookbook.dev/gallery
Apps Cookbook（リソース集）
https://apps-cookbook.dev/resources

3. Claude Code のセッティング（最短手順）

こちらの記事を参考にしました。（弥生さんの記事にはいつもお世話になっております…）
https://qiita.com/taka_yayoi/items/b5d2b3e286a8952573be

手順（ざっくり）：

サイドメニューの「サービング」→「コーディングエージェントを統合」
Claude Code を選択してテンプレ設定を取得
ローカルPCに ~/.claude/settings.json を配置
IDE のコンソールから claude コマンドで利用

例：

{
  "env": {
    "ANTHROPIC_MODEL": "databricks-claude-sonnet-4-5",
    "ANTHROPIC_BASE_URL": "https://XXXXXX.azuredatabricks.net/serving-endpoints/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "XXXXXX",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "databricks-claude-opus-4-1",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "databricks-claude-sonnet-4-5"
  }
}

				
					
				1
2
3
4
5
6
7
8
9

						{
  "env": {
    "ANTHROPIC_MODEL": "databricks-claude-sonnet-4-5",
    "ANTHROPIC_BASE_URL": "https://XXXXXX.azuredatabricks.net/serving-endpoints/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "XXXXXX",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "databricks-claude-opus-4-1",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "databricks-claude-sonnet-4-5"
  }
}

					

			

4. Databricks Apps：ユーザー代理認証（Preview）

Databricks Apps には、アプリのログイン認証と Unity Catalog のアクセス権限を自動で紐づける ユーザー代理認証（Preview）があります。

メリットは大きく2つ：

アプリ側で認証・認可をスクラッチ実装/運用しなくてよい
Unity Catalog で定義したガバナンスを、アプリにそのまま持ち込める

認証基盤はミスのリスクが大きく、運用も重くなりがちです。
「アプリはアプリの仕事に集中しつつ、データアクセスはDatabricksガバナンスに寄せる」という分離ができるのは魅力です。

概念はこちら：

Databricks アプリで認可の設定をする | Databricks on AWS

docs.databricks.com

Streamlit 側：トークン取得

import streamlit as st
user_access_token = st.context.headers.get("x-forwarded-access-token")

import streamlit as st

user_access_token = st.context.headers.get("x-forwarded-access-token")

ローカル開発のコツ：

ローカルではヘッダが無いので、環境変数からダミー/開発用トークンを読む分岐を入れておくと動作確認が楽です。

Databricks SQL でデータ取得（ユーザー権限のまま）

access_token = get_user_token()
conn = sql.connect(
    server_hostname=os.getenv("DATABRICKS_HOST"),
    http_path=os.getenv("WAREHOUSE_HTTP_PATH"),
    access_token=access_token,
)

with conn.cursor() as cursor:
    cursor.execute(f"""
        SELECT *
        FROM {CATALOG}.{SCHEMA}.kyoto_agent_payload_view
        LIMIT 1000
    """)
    logs_df = cursor.fetchall_arrow().to_pandas()

    cursor.execute(f"""
        SELECT *
        FROM {CATALOG}.{SCHEMA}.redteam_joined
        LIMIT 1000
    """)
    redteam_df = cursor.fetchall_arrow().to_pandas()
    
conn.close()

				
					
				1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

						access_token = get_user_token()
conn = sql.connect(
    server_hostname=os.getenv("DATABRICKS_HOST"),
    http_path=os.getenv("WAREHOUSE_HTTP_PATH"),
    access_token=access_token,
)
 
with conn.cursor() as cursor:
    cursor.execute(f"""
        SELECT *
        FROM {CATALOG}.{SCHEMA}.kyoto_agent_payload_view
        LIMIT 1000
    """)
    logs_df = cursor.fetchall_arrow().to_pandas()
 
    cursor.execute(f"""
        SELECT *
        FROM {CATALOG}.{SCHEMA}.redteam_joined
        LIMIT 1000
    """)
    redteam_df = cursor.fetchall_arrow().to_pandas()
    
conn.close()
 

					

			

※ 環境変数の設定方法はこちらが参考になります：

シークレット管理 | Databricks on AWS

docs.databricks.com

Databricks アプリで環境変数を定義する | Databricks on AWS

docs.databricks.com

5. Serving Endpoint × Model Registry：生成AI Agentを“運用可能”に寄せる

今回はせっかくなので、生成AI Agent を Databricks に寄せます。

参考にしたノートブック：

simple-agent-mlflow3 – Databricks

docs.databricks.com

ここで重要なのは、「作れた」ではなく

バージョンが管理され
ライフサイクルを持ち
利用ログ/Traceが取れ
後から監査・分析できる

運用の形になることです。

Experiment を Notebook に紐づけたくない場合

from databricks import agents

username = (
    dbutils.notebook.entry_point.getDbutils().notebook().getContext().userName().get()
)
experiment_path = f"/Users/{username}/KyotoAgent"
experiment = mlflow.set_experiment(experiment_path)

agents.deploy(
    UC_MODEL_NAME,
    model_version=logged_agent_info.registered_model_version,
    tags={"endpointSource": "docs"},
)

				
					
				1
2
3
4
5
6
7
8
9
10
11
12
13
14

						from databricks import agents
 
username = (
    dbutils.notebook.entry_point.getDbutils().notebook().getContext().userName().get()
)
experiment_path = f"/Users/{username}/KyotoAgent"
experiment = mlflow.set_experiment(experiment_path)
 
agents.deploy(
    UC_MODEL_NAME,
    model_version=logged_agent_info.registered_model_version,
    tags={"endpointSource": "docs"},
)
 

					

			

6. Microsoft AI Foundry：AI Red Teaming Agentで検証する

生成AIの本番利用では「作る」より「守る/測る」が難しいです。
Databricks 側にモデルを寄せたので、外部から Red Teaming を当ててみます。

Microsoft AI Foundry（Red Teaming）：

AI Red Teaming Agent をローカルで実行する (Azure AI 評価 SDK) – Microsoft Foundry

AI Red Teaming Agent を使用して、Azure AI Evaluation SDK を使用して Generative AI アプリケーションのローカル自動スキャンを実行する方法について説明します。

learn.microsoft.com

また、Azure AI Evaluation SDK を使うとローカル実行できます。
Serving Endpoint を呼び出す場合は、ドキュメントの「複雑なコールバック」を参考にカスタムすると対象にできます。

async def advanced_callback(messages, stream=False, session_state=None, context=None):
    messages_list = [{"role": m.role, "content": m.content} for m in messages]

    def _call():
        return client.responses.create(
            model=ENDPOINT_NAME,
            input=messages_list,
            max_output_tokens=256,
        )

    try:
        resp = await asyncio.to_thread(_call)
        assistant_text = getattr(resp, "output_text", None)
        if not assistant_text:
            try:
                assistant_text = resp.output[0].content[0].text
            except Exception:
                assistant_text = str(resp)

    except Exception as e:
        assistant_text = f"[model_call_error] {type(e).__name__}: {e}"

    return {"messages": [{"role": "assistant", "content": assistant_text}]}

				
					
				1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

						async def advanced_callback(messages, stream=False, session_state=None, context=None):
    messages_list = [{"role": m.role, "content": m.content} for m in messages]
 
    def _call():
        return client.responses.create(
            model=ENDPOINT_NAME,
            input=messages_list,
            max_output_tokens=256,
        )
 
    try:
        resp = await asyncio.to_thread(_call)
        assistant_text = getattr(resp, "output_text", None)
        if not assistant_text:
            try:
                assistant_text = resp.output[0].content[0].text
            except Exception:
                assistant_text = str(resp)
 
    except Exception as e:
        assistant_text = f"[model_call_error] {type(e).__name__}: {e}"
 
    return {"messages": [{"role": "assistant", "content": assistant_text}]}
 

					

			

実務Tips：推論テーブルに Red Teaming リクエストが混ざる問題

通常利用と Red Teaming のリクエストが混ざると、利用分析や監査がやりにくくなります。
client_request_id を付けると切り分けが楽です。

モデルの監視とデバッグのための推論テーブル – Azure Databricks

エンドポイントにサービスを提供するモデルを監視するための推論テーブルについて説明します。ログに記録される内容や機能の制限事項も含まれます。

learn.microsoft.com

7. ダッシュボード（Streamlit）で可視化する

ここまでで取得した推論ログ（Serving Endpoint / 推論テーブル）と Red Teaming 結果を、Claude Code の Vibe Coding で運用向けダッシュボードとして可視化しました。狙いは「見た目」ではなく、観測→原因特定→改善→再検証を回せる状態にすることです。

① 何ができるか（運用の問いに答える）

いま何が起きているか：リクエスト数・エラー率・レイテンシ（必要ならコスト指標）を期間別に把握
どこが危ないか：Red Teaming の Fail/重大度/カテゴリ別の傾向を俯瞰
次に直すべきか：頻度×重大度で優先度を決め、改善後に再スキャンで差分確認

② 画面の構成（迷わない導線）

Ops View（運用サマリー）：KPI → 時系列 → 異常ログの明細（フィルタ：期間/endpoint/model_version/status）
Risk View（Red Teaming）：重大度別件数 → 失敗カテゴリTop → 失敗ケース明細（入力/出力/判定）

なお、現時点の画面は不完全で、取り込み途中の影響により一部データが破損している状態のまま載せています（後続で整形・欠損対策が必要です）。
それでも、短時間で「ログ（実運用）と Red Teaming（安全性評価）を同じ土俵で見られる」形まで到達できたことで、以降は UIを作り込む前に、まずデータを正規化して改善サイクルを回す方針が取りやすくなりました。

Streamlit は実装が早い一方、検索導線やドリルダウンなど体験の作り込みには制約が出やすいので、次は Next.js で運用ワークフロー（Traceや関連ケースへの遷移）まで含めて試したいです。

8. 実務で効くポイント（落とし穴/運用Tips）

最後に、今回の学びを「実務で効く形」に圧縮します。

① 認証・認可は “アプリに持ち込まない” 方が早い

ユーザー代理認証を使うと、

認証基盤の実装/運用コストを削減
Unity Catalog のガバナンスをそのまま適用

が可能になります。
アプリは UI/体験に集中し、データアクセスは Databricks 側に寄せるのが良い分離でした。

② 「ログを取る」ではなく「後で分析できる形で取る」

推論テーブルや Trace を入れると、あとから

どのユーザーが
どのモデル（どのバージョン）を
どんな入力で呼んだか
応答はどうだったか

が整理しやすい。
Red Teaming を回すほど、ここが効きます。

③ Red Teaming の結果は “可視化して初めて運用に乗る”

レポートを読むだけだと改善が止まりがちです。
Apps 側で「スキャン結果を検索/フィルタ/傾向表示」できると、改善ループに入りやすいです。

④ クイックに作れるほど「命名・タグ・ID」が後で効く

client_request_id
environment（dev/stg/prod）
endpoint version / model version
scan種別（normal vs redteam）
この辺りを早めに揃えると、後工程で詰まりにくいです。

9. まとめ

今回の検証で得た結論はシンプルで、「生成AIを使う」だけでなく「運用できる形にする」ことが成果を左右するという点です。
Databricks Apps を使うと、ダッシュボードでは難しい入力フォームやインタラクションをアプリとして提供でき、ユーザー体験を要件に寄せやすくなります。

さらに、ユーザー代理認証や Unity Catalog を軸にしたガバナンス、Serving/Registry、推論ログやトレースといった運用要素をマネージド機能に寄せることで、スクラッチで抱えがちな“重たい領域”を軽くできます。

ありがたいことにこれまで、データ基盤、生成AI活用、数百万ユーザー規模のアプリなど、性質の異なる案件に携わる機会がありました。その中で一貫して感じるのは、スクラッチで揃えるほど「必要機能」よりも「周辺の運用（認証・権限・監査・保守）」が重くなり、価値提供までの時間を押し上げやすいということです。
PaaS/マネージド機能を活用してこの負担を早めに外に逃がせると、余白が生まれ、実装の手数ではなくビジネスニーズ/KPIに対してどう価値を最大化するか（安全性評価を含む）に時間を使えるようになる.. ここが実務的には一番効くと感じました。

次は、UI の自由度が高い Next.js でも同様の運用構成を再現し、運用画面（検索・比較・ドリルダウン）まで含めて作ってみたいと思います。

この記事を書いた人

azure-recipe-user

記事一覧

Databricks Apps × Claude Code × ユーザー代理認証 × Model Registry × Red Teaming で「ガバナンス付き生成AI運用」を最短で形にする

対象読者

この記事のゴール

目次

1. 全体アーキテクチャ（今回作ったもの）

2. Claude Code：テンプレ化・自動デプロイの可能性

3. Claude Code のセッティング（最短手順）

4. Databricks Apps：ユーザー代理認証（Preview）

Streamlit 側：トークン取得

Databricks SQL でデータ取得（ユーザー権限のまま）

5. Serving Endpoint × Model Registry：生成AI Agentを“運用可能”に寄せる

Experiment を Notebook に紐づけたくない場合

6. Microsoft AI Foundry：AI Red Teaming Agentで検証する

実務Tips：推論テーブルに Red Teaming リクエストが混ざる問題

7. ダッシュボード（Streamlit）で可視化する

① 何ができるか（運用の問いに答える）

② 画面の構成（迷わない導線）

8. 実務で効くポイント（落とし穴/運用Tips）

① 認証・認可は “アプリに持ち込まない” 方が早い

② 「ログを取る」ではなく「後で分析できる形で取る」

③ Red Teaming の結果は “可視化して初めて運用に乗る”

④ クイックに作れるほど「命名・タグ・ID」が後で効く

9. まとめ

この記事を書いた人

azure-recipe-user

Koalas: Easy Transition from pandas to Apache Spark 記事翻訳してみた

Microsoft 責任あるAI Ver.2 解説その3（信頼性と安全性、プライバシーとセキュリティ、包括性）

Databricks事例紹介　～医療編～

Azure Databricks: 1. リソースの作成