📚 参考書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
『ゼロから触ってわかった！Databricks Agent Engineering実務入門 』
～AI Gatewayでつなぎ、Agent Skillsで標準化・量産し、MLflowで運用する ～
https://link.amazon/B03g0YUiI
『Databricks──ゼロから触ってわかった！Databricks非公式ガイド（2026年更新版）』
クラウド時代の分析基盤を “体験的” に学べるベストセラー入門書。
Databricksの操作、SQL／DataFrame、Delta Lakeの基本、ノートブック操作、SDP（宣言型パイプライン）
Serverless、Genieなどを初心者でも迷わず進められる構成で解説しています。
https://amzn.to/4uIqEj4
「データパイプラインを人が作る」から「Agent Skillで量産」へ
データ基盤では、新しいデータソースやテーブルが増えるたびに、データパイプラインを開発する必要があります。
たとえば、新しい業務システムから顧客データを取り込む場合、データエンジニアはテーブル定義を確認し、取り込み方法を決め、SQLやPythonを実装し、データ品質チェックやテストを追加します。
生成AIを利用すれば、こうしたコードを書く時間は短縮できます。
しかし、開発の単位が「パイプライン1本」のままであれば、対象が増えるたびに、人間が同じような判断と指示を繰り返すことになります。
本書では、この開発モデルそのものを変えていきます。
従来はパイプラインごとに開発していた
たとえば、100個のテーブルをデータ基盤へ取り込むケースを考えてみましょう。
従来であれば、テーブルごとに次のような作業が発生します。
- ソーステーブルの構造を確認する
- ターゲットテーブルを設計する
- BatchかStreamingかを判断する
- 初回ロードや増分ロードの方式を決める
- SQLやPythonを実装する
- データ品質チェックを追加する
- テストを作成する
- レビューを受けて修正する
もちろん、共通ライブラリやテンプレートによって効率化することはできます。
それでも最終的には、データエンジニアが個々の要件を読み取り、「このパイプラインでは何を実装すべきか」を判断する必要があります。
パイプラインが増えるほど、開発工数だけでなく、レビューや品質管理の負担も増えていきます。
コード生成だけでは「量産」にはならない
ここで、生成AIにSQLを書かせれば解決するのでしょうか。
たしかに、
「このテーブルを増分ロードするMERGE文を書いてください」
と指示すれば、コードは短時間で生成できます。
しかし、別のテーブルを取り込むときには、再びPromptを書かなければなりません。また、担当者によって指示の内容が異なれば、生成されるコードの設計や品質にもばらつきが生じます。
つまり、
人間が毎回設計し、AIが毎回コードを書く
だけでは、従来の開発プロセスを高速化したにすぎません。
本書で目指す「量産」は、もう一段階異なります。
繰り返される判断をAgent Skillへ移す
多くのデータパイプラインを見比べると、すべてが完全に異なるわけではありません。
組織の中では、同じような設計や実装が繰り返されています。
たとえば、
- CatalogやSchemaの命名方法
- Bronzeテーブルへの取り込み方法
- 更新日時を利用した増分ロード
- 主キーを利用したMERGE
- NULLや重複のデータ品質チェック
- テストコードの作り方
といったものです。
これらは、個々のパイプラインの要件というより、企業として繰り返し利用する開発標準や実装パターンです。
そこで、こうした知識や手順をAgent Skillとして定義します。
Agent Skillに「この会社ではデータパイプラインをどのように作るのか」を持たせれば、Agentは毎回ゼロから方法を考える必要がなくなります。
人間は「何を作るか」を指定する
Agent Skillを利用する開発では、人間が指定する情報をできるだけ要件に集中させます。
たとえば、人間が次のような情報を与えたとします。
- source：sales.orders
- target：bronze.orders
- load mode：incremental
- key：order_id
- updated column：updated_at
Agentはこれらの要件とAgent Skillを組み合わせ、
「incrementalであれば、この企業ではこのパターンを使う」
「主キーが指定されているため、このMERGE方式を使う」
「Bronzeレイヤーなので、この命名規則と品質チェックを適用する」
といった判断を行います。
そして、テーブル定義、取り込み処理、MERGE、データ品質チェック、テストなどの成果物を生成します。
次のテーブルでは、入力となる要件だけを変更します。
開発方法そのものは、Agent Skillから再利用します。
「コードの再利用」から「開発能力の再利用」へ
従来の開発でも、関数、ライブラリ、テンプレートなどを再利用してきました。
Agent Skillによるアプローチでは、その対象をさらに広げます。
再利用するのはコードだけではありません。
設計方針、判断基準、実装手順、テスト方法まで含めた「仕事のやり方」そのものを再利用します。
この違いは重要です。
100本のパイプラインを作るときに、「100回開発する」のではなく、共通する開発能力をAgent Skillとして一度整備し、それを100個の要件へ適用するからです。
これが、本書でいうAgent Skillによる量産です。
データエンジニアの役割も変わります。
個々のSQLを書くことだけでなく、
「組織として、どのようなパターンでデータパイプラインを作るべきか」
を設計し、その知識をAgentが利用できる形にすることが、より重要になります。
次節では、この考え方をさらに広げ、コードやテンプレートだけではなく、API、データ、業務ルール、開発標準などをAgentが利用できる「能力」として再利用する考え方を整理します。