生成AIによるDatabricksの開発方法論を改めて考えてみた【JEDAI in Osaka】
-- Views
April 17, 26
スライド概要
JEDAI in Osaka 2026 春 (オンサイト+オンライン)での発表資料です。
https://jedai.connpass.com/event/383379/
関連スライド
各ページのテキスト
JEDAI in Osaka 2026 春 生成AIによる Databricksの開発方法論を 改めて考えてみた manabian
はじめに 本発表では、生成AIの開発手法（Skillsなど）に関する最新情報の共有ではなく、 Databricksを活用したシステム開発に役立てるための心構え（ほぼ決意）をお伝えします。 データ分析におけるコードは少量で複雑かつ分割が難しい場合が多く、 他のプログラミング技術をそのまま応用できないケースがあります。 ◼ 私の業務上、利用環境を固定できないことが多かったものの、 現在は整った環境下でデータ分析システムのライフサイクルにおける生成AI活用の検証を 進めています。今後は、その観点からの情報発信も行ってまいります。
自己紹介 【主業務】 レイクハウス・DWH・BI構築に関するSIベンダーにてフェローとして、 次の業務を実施。 • データエンジニアリングの実装論の整理とライブラリ開発 • データ分析基盤とアプリケーションの設計・構築に関する支援 • データ分析基盤に関する技術検証 @manabian 【趣味】 趣味がデータ分析基盤に関する調査や検証であり、 主に Qiita を中心に データ分析基盤プラットフォームに関する記事を 投稿。
生成 AI による開発論の現状
生成 AI の技術力は Copilot からホームズへ ◼ 生成AIによる開発は当初Copilot（副操縦士）から始まりました。 ◼ 現在では、アウトプットの品質が飛躍的に向上し、 私たちの多くの課題を解決してくれる名探偵ホームズのような存在へと進化しています。 GitHub Copilot
生成 AI のアウトプットの過信は禁物 AIエージェントを活用した継続的な機械学習モデルの精度向上を目指す autoresearch が 最近注目されました。 その施策の一つに seedの調整といった裏技的な手法も用いられており、 現段階では完全に自律して運用できる状況には至っていないと考えています。 引用元：GitHub - karpathy/autoresearch: AI agents running research on single-GPU nanochat training automatically · GitHub
生成 AI はホームズ、私たちはワトソンという関係が理想 ◼ 名探偵ホームズの助手であるワトソンの役割を担い、私たちは情報（コンテキスト）を収 集し、その重要度を判断してストーリー（システム）を構築する必要があります。 ホームズを例にした理由 非公開画像
名探偵と良好な関係を築ける ワトソンになる方法
＜問題＞生成 AI の出力を鵜呑みにして量産すること (1/2) 生成 AI の言いなりとなりコードを大量生産開を実施するケースがありますが、 ライブラリ化や回帰テスト等により品質をコントロールしたプログラムの開発が必要です。 コードの大量生産 データを データを UPSERT で データを UPSERT 連携する SQL で を データを UPSERT 連携する SQL で を 記述して UPSERT 連携する SQL で を 記述して 連携する 記述してSQL を 記述して データを データを UPSERT で データを UPSERT 連携する SQL で を データを UPSERT で 連携する SQL を 記述して UPSERT 連携する を 記述してSQL で 連携する SQL を 記述して 記述して 共通化
＜問題＞生成 AI の出力を鵜呑みにして量産すること (2/2) 宣言型によりデータエンジニアリングを実施できる機能を利用することも 品質のばらつきを抑えるためにはとても有効な選択肢です。 自作プログラムは柔軟だが、再利用・標準化・テスト・保守・参入障壁に課題が出てきた という事例 *1 もあります。 SDP 引用元：Lakeflow Spark宣言型パイプライン | Databricks on AWS dbt 引用元：GitHub - karpathy/autoresearch: AI agents running research on single-GPU nanochat training automatically · GitHub *1 Leveling up data engineering at Riot: How they transformed DevEx with dbt (Coalesce 2025) - YouTube
＜問題＞適切な開発方式や技術検証を持たずに進めること (1/2) システムのアーキテクチャの視点を欠いたまま開発を進めることはリスクが伴います。 特に Databricks を用いてシステムを構築する際には、 構造化データ・非構造化データを問わず、データ管理の方法が非常に重要となります。 誰も教えてくれない メダリオンアーキテクチャの デザインメソッド 非構造化データのメダリオンアーキテクチャで 加速するAIアプリケーション開発 引用元：誰も教えてくれない メダリオンアーキテクチャの デザインメソッド | ド クセル 引用元：非構造化データのメダリオンアーキテクチャで加速するAIアプリケー ション開発 - Vポイントマーケティング｜TECH LABの Tech Blog
＜問題＞適切な開発方式や技術検証を持たずに進めること (2/2) 重要なオプションや動作仕様が十分に考慮されずにコードが実装されることがあります。 ドキュメントの参照と動作確認による詳細な調査/検証の実施をおすすめします。 オプションが大量にあるため ドキュメントの読み込む必要あり 引用元：Auto Loaderオプション | Databricks on AWS 発表時週に調査した マルチテーブルトランザクション 引用元：Databricks のマルチテーブルトランザクション機能の基本的な検 証結果 #Databricks - Qiita
＜問題＞個人レベルでの活用方法にとどめてしまうこと(1/2) 個々のツール選定に注力するのではなく、高品質なコンテキスト（ナレッジ管理）を いかに継続的に提供するかを検討する必要があります。 検討対象 ツール コンテキスト（ナレッジ管理） Jira
＜問題＞個人レベルでの活用方法にとどめてしまうこと(2/2) ローカルでの開発方法論から含めて 開発ライフサイクルにおけるプロセスでどのように活用するかを検討する必要があります。 開発環境 開発環境 本番／検証環境 本番／検証環境 ローカル環境 （コードを記述） Databricks （コードを実行） Databricks Visual Studio Code Databricks Workspace Databricks Workspace コード コード 開発者 3. フィードバック 2. 同期と実行 1. コード開発 コード Genie Code レポジトリー 5. デプロイ 4. コミット Git
まとめ
まとめ ◼ 生成 AI は「ホームズ」、私たちは「ワトソン」— 情報を収集・判断し、ストーリー（シ ステム）を構築する役割分担になってきています。 ◼ AI の出力を鵜呑みにせず、組織（チーム）で拡張可能な方法論を一緒に考えましょう。
ありがとうございました 参考になった記事には いいねをお願いします manabian 𝕏: @manabian Qiita: manabian