こんにちは、データマネジメント部の馬渡です。
2025年12月から2026年1月にかけてデータチームは3回登壇しました。
それぞれ別のイベントですが、振り返ってみると共通しているテーマがありました。Databricksを軸にして、開発環境・権限管理・AIエージェント配布という3つの方向から「使いにくさを取り除く」という話をしていました。
本記事ではその全体像をお伝えします。
登壇一覧
「Databricks向けJupyter Kernelでデータサイエンティストの開発環境をAI-Readyにする」馬渡大樹
2025年12月12日に開催された「Databricks Data + AI World Tour Tokyo After Party」に登壇しました。
「M&Aで拡大し続けるGENDAのデータ活用を促すためのDatabricks権限管理」馬渡大樹
2025年12月22日に開催された「モダンデータ基盤の最前線：現場から学ぶ実践と挑戦 - Snowflake・Databricks・dbt等を用いた事例｜AEON TECH HUB #22」に登壇しました。
「Mosaic AI Gatewayでコーディングエージェントを配るための運用Tips」馬渡大樹
2026年1月27日に開催された「JEDAI 2026 新春 Meetup! AIコーディング特集」に登壇しました。
各登壇の詳細
Databricks向けJupyter KernelでデータサイエンティストをAI-Readyにする
本登壇では、Databricks向けにJupyterカーネル（jupyter-databricks-kernel）を自作し、ローカルのAIコーディングアシスタントからDatabricks Notebookを直接操作できる環境を構築する方法を紹介しました。
Databricks Notebookはクラウド上でしか動かないため、ローカルエディタのAIコーディングアシスタントを使いたいデータサイエンティストには悩みのタネです。スライドでは「AI時代の新たな課題」として提起し、jupyter-databricks-kernelによってその壁を取り除く具体的な構成を解説しています。
ローカルのVS CodeからDatabricksのコンピュートに接続できるようになり、jupyter execute notebook.ipynb でノートブックをCLI実行できます。AIコーディングアシスタントがローカルファイルとして扱えるのが重要なポイントです。
カーネル単体では実用的な開発環境にまでは至れないため、あわせて四つのベストプラクティスも紹介しました。
-
Skinny Notebook Wrapper + Pure Python
- ノートブックは薄いラッパーにして、メインロジックは .py に切り出すパターン
-
uvによる依存関係管理
- Pythonパッケージのバージョンを明示管理
-
mise + pre-commit + Renovateによるガードレール
- AIが触っても崩れにくいコード品質の自動担保
-
CLIでの実行例
jupyter execute notebook.ipynb
四つの構成はそれぞれ独立していますが、組み合わせることで「AIが書いたコードを自動検証しながらDatabricksを使い続けられる」環境になります。なかでも、mise + pre-commit + Renovateのガードレールは、AI生成コードの品質劣化を自動で防ぐ役割を担っています。
M&Aで拡大し続けるGENDAのデータ活用を促すためのDatabricks権限管理
本登壇では、M&Aで拡大し続けるGENDAが直面してきたDatabricks権限管理の課題と、現在取り組んでいる解決策を紹介しました。
GENDAはグループ企業が増えるたびに権限設計を見直す必要があり、ロール（データエンジニア・機械学習エンジニア・データアナリスト・ビジネスメンバー）ごとに必要な機能が異なるため、設計の複雑さが増し続けていきます。スライドでは、マルチワークスペース構成を前提に、そのロールごとの権限設計を具体的に解説しています。
今取り組んでいるのはワークスペースレベルの権限とUnity Catalogのデータアクセス権限を2層で管理する設計です。どちらもグループ単位で管理していて、新メンバーのオンボーディングはグループに追加するだけで完結します。新規M&A企業が増えてもグループを作ってテンプレートの権限を付与すればすぐ動けるようになります。
本番環境はService Principal（非人間アカウント）経由でのみ操作できる構造にしていて、人間が直接本番データを操作できないようにしています。現在は概ね想定通りに動作しています。
ロールごとの使い分けにも特徴があります。ビジネスメンバーにはDatabricks Oneのシンプルなビューを提供していて、Genieという機能で自然言語によるデータ分析ができます。SQLを書けなくてもデータを使える入口として機能します。データアナリストには行レベルセキュリティと列マスキングを組み合わせ、必要なデータのみアクセスできる構成にしています。
Mosaic AI Gatewayでコーディングエージェントを配るための運用Tips
本登壇では、インターン・外部協力者・非エンジニアメンバーへのAIコーディング環境配布を、管理コストを抑えながら実現する方法を紹介しました。
APIキー管理・利用量監視・環境セットアップのハードルを下げるのが主題で、スライド冒頭では「大量利用するヘビーユーザーには向かない」とスコープを明示したうえで、ライトユーザー向けの実用的な構成を解説しています。
Mosaic AI Gatewayを使うと複数のLLM（Claude、GPTなど）への接続を一本化できて、システムテーブルで利用量をモニタリングしながら予算超過時に自動遮断もできます。認証はOAuth U2Mで完結するのでPersonal Access Tokenを各自で管理してもらう必要がなく、運用負荷を下げる点で実用的な利点です。
予算超過時の自動遮断はDatabricks Jobで実装しています。「15分ごと」等の一定間隔でシステムテーブルの利用量を確認し、上限を超えた場合にRate Limit APIで遮断します。ライトユーザーが短時間に上限を使い切ることはほぼなく、ジョブとして管理できるので基盤管理者も把握しやすい構造です。
ローカル側はBlock社のOSSコーディングエージェントGooseをDev Containerに組み込む構成にしました。GooseはDatabricksをネイティブサポートしているのでOAuth U2M認証がそのまま通ります。Claude CodeやCodex CLIと比べると機能面で物足りない部分はありますが、Dev Container起動時にOAuth U2M認証を自動で済ませるスクリプトを用意しておけば、環境配布の手間がほぼゼロになるのが利点です。また、冒頭で紹介したjupyter-databricks-kernelと組み合わせると、ノートブックの読み取り・編集・実行もGooseに任せられます。
まとめ
今回紹介した三つとも「Databricksの機能を活用して、利便性を向上させる」という話でした。
データサイエンティストのAI活用の壁、M&A後のオンボーディングの壁、エンジニア以外へのAIツール配布の壁、その他課題についても引き続き改善しながら発信していきます。
Discussion