1. Databricks Apps で ログイン認証とUC権限を自動的に整合
させる
2. Serving Endpoint + Model Registry で モデル運用の型
を作る
3. 推論ログ/Trace を活用して 観測性（Observability）を確保
する
4. Microsoft AI Foundry の Red Teaming で 安全性の検証ループ
を回す
5. Claude Code で テンプレ化・自動デプロイの可能性
を探る
目次
6. 全体アーキテクチャ（今回作ったもの）
7. Claude Code：テンプレ化・自動デプロイの可能性
8. Claude Code のセッティング（最短手順）
9. Databricks Apps：ユーザー代理認証（Preview）
10. Serving Endpoint × Model Registry：生成AI Agentを“運用可能”に寄せる
11. Microsoft AI Foundry：AI Red Teaming Agentで検証する
12. ダッシュボード（Streamlit）で可視化する
13. 実務で効くポイント（落とし穴/運用Tips）
14. まとめ
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で可視化ポイントは 「認証/ガバナンス」 「モデル運用」 「ログ/可視化」 「安全性評価」 を同じ土俵に乗せていることです。
スクラッチ実装でよく発生する「別々の仕組みの寄せ集め」を避けやすくなります。
2. Claude Code：テンプレ化・自動デプロイの可能性
近年は Vibe Coding（UIイメージ提示→コード生成）も成熟してきて、Databricks でも Claude Code がネイティブに利用できます。
また Databricks コミュニティが活発で、サンプルデモが手に入りやすいのも良い点です。
Claude Code の推しポイントは、claude.md に
- コーディング規約
- ディレクトリ構成
- デプロイ手順/ルール
- 禁止事項（秘密情報の扱いなど）
を記述すると、それを前提としてコード生成・操作を進められるところです。
つまり、「人がレビューで何度も言うルール」を、最初からエージェントに埋め込める。
実際にコミュニティの Notebook 例を見ると、claude.md がかなり丁寧に作り込まれており、どれだけ明確な Markdown（指示）を用意できるかが重要だと分かります。
参考：
- Apps Cookbook（ギャラリー）
apps-cookbook.dev- Apps Cookbook（リソース集）
3. Claude Code のセッティング（最短手順）
こちらの記事を参考にしました。（弥生さんの記事にはいつもお世話になっております…）
qiita.com手順（ざっくり）：
15. サイドメニューの「サービング」→「コーディングエージェントを統合」
16. Claude Code を選択してテンプレ設定を取得
17. ローカルPCに ~/.claude/settings.json を配置
18. 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"
}
}4. Databricks Apps：ユーザー代理認証（Preview）
Databricks Apps には、アプリのログイン認証と Unity Catalog のアクセス権限を自動で紐づける ユーザー代理認証（Preview）があります。
メリットは大きく2つ：
- アプリ側で認証・認可をスクラッチ実装/運用しなくてよい
- Unity Catalog で定義したガバナンスを、アプリにそのまま持ち込める
認証基盤はミスのリスクが大きく、運用も重くなりがちです。
「アプリはアプリの仕事に集中しつつ、データアクセスはDatabricksガバナンスに寄せる」という分離ができるのは魅力です。
概念はこちら：
Streamlit 側：トークン取得
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()※ 環境変数の設定方法はこちらが参考になります：
5. Serving Endpoint × Model Registry：生成AI Agentを“運用可能”に寄せる
今回はせっかくなので、生成AI Agent を 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"},
)6. Microsoft AI Foundry：AI Red Teaming Agentで検証する
生成AIの本番利用では「作る」より「守る/測る」が難しいです。
Databricks 側にモデルを寄せたので、外部から Red Teaming を当ててみます。
Microsoft AI Foundry（Red Teaming）：
また、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}]}実務Tips：推論テーブルに Red Teaming リクエストが混ざる問題
通常利用と Red Teaming のリクエストが混ざると、利用分析や監査がやりにくくなります。
clientrequestid を付けると切り分けが楽です。
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」が後で効く
- clientrequestid
- 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 でも同様の運用構成を再現し、運用画面（検索・比較・ドリルダウン）まで含めて作ってみたいと思います。
