概要
「JEDAI in Osaka 2026 春」にて「生成AIによるDatabricksの開発方法論を改めて考えてみた」というテーマで発表しました。本記事では、その発表内容の補足情報を説明します。
資料
発表内容の補足
生成AIはホームズ、私たちはワトソンという関係が理想
生成AIによる開発は、当初Copilot（副操縦士）という位置づけから始まりましたが、現在ではアウトプットの品質が飛躍的に向上し、私たちの多くの課題を解決してくれる名探偵ホームズのような存在へと進化しています。ただし、シャーロック・ホームズだけでは物語が完結しないように、私たちはワトソン役を担おう、という話をしました。なお、「ワトソン」と聞いてIBM社のIBM Watsonを連想される方がいましたが、本発表で言及しているのはそのサービスではありません。
autoresearchについては、下記のリポジトリで情報が公開されています。
生成AIの出力を鵜呑みにして量産すること
生成AIが出力したコードをそのまま利用しすぎると、コントロールが難しいコードが量産され、いわゆる技術的負債となるコードが大量に残ってしまうリスクがあります。共通ロジックの記述量を減らすためにライブラリ化を行い、それらのコードに対してはpytestで回帰テストを書こう、というお話をしました。
- 構造化データのメダリオンアーキテクチャ
- 非構造化データのメダリオンアーキテクチャ
適切な開発方式や技術検証を持たずに進めること
Databricks Auto LoaderにはignoreMissingFilesという重要なオプションがあり、利用する機能についてはドキュメントの参照と動作検証を行うことが重要です。
出所：Auto Loaderオプション | Databricks on AWS
私はプロジェクトの要件定義開始前に技術検討を実施することがあります。少なくとも実装開始前には、利用する技術の仕様を把握しておくことをおすすめします。
- Databricks のマルチテーブルトランザクション機能の基本的な検証結果 #Databricks - Qiita
- Databricks における Databricks Utilities taskValues サブユーティリティの基本的な動作確認 #Databricks - Qiita
- Snowflake の CHANGES 句（STREAM）と Databricks の CHANGES 句の動作差異に関する調査結果 #Databricks - Qiita
個人レベルでの活用方法にとどめてしまうこと
開発ライフサイクルにおいて、どのようなコンテキストに基づきどのツールを使うかが重要であると考えています。
どこかで上記のテーマを発表したような気がしていたのですが、下記の記事として投稿していました。Claude CodeやCodexを利用する場合は、ローカルでの開発環境の導入を検討する必要があります。