ダイキン・アプライド・アメリカズがGenie Codeを活用し、一貫性のあるデータパイプラインを大規模に構築する方法

エージェンティック・データエンジニアリングがパイプラインの構築方法を変革

ダイキン・アプライド・アメリカズ（DAA）は、北米全域で業務用HVACシステムの製造およびサービスを提供しています。これは、機器のテレメトリやサプライチェーンデータからフィールドサービスの記録に至るまで、システム全体にわたる膨大な量の運用、製造、サービスデータを管理することを意味します。

同社のデータチームは、エンジニアリング、運用、カスタマーサービスにわたるアナリティクスやAIのユースケースをサポートしており、これらはすべて、信頼性が高く適切に構造化されたパイプラインに依存しています。

これらの需要が高まるにつれ、データチームへのプレッシャーも増大し、パイプラインやユースケースの増加、チーム間でのさらなる調整が必要になりました。これに対処するため、チームはパイプラインの設計、構築、ガバナンスを行うための、より構造化された運用モデルを定義し、そのモデル内での実行を加速させるためにDatabricks Genie Codeを活用しました。

同チームは、データエンジニアリングへのAI支援アプローチとしてGenie Codeを活用しました。Unity Catalogでガバナンスが適用されたデータに対して直接作業を行うことで、ワークフロー全体にわたるマルチステップのパイプラインの計画と生成を支援できます。これにより、エンジニアはツールを切り替えたり、コンポーネントを手動で繋ぎ合わせたりすることなく、アイデアから実際に稼働するパイプラインへと迅速に移行できるようになります。

このスピードは、チームの働き方を根本から変えました。以前はプロトタイプの作成に数日かかっていたパイプラインが、わずか数分で生成できるようになりました。イテレーションサイクルが短縮され、エンジニアはボイラープレートコードの作成に費やす時間を減らし、ロジックや成果の洗練により多くの時間を割けるようになりました。

同時に、大規模で共有されたデータ環境での運用には一貫性が求められます。パイプラインは共通のアーキテクチャパターンに従い、共有された定義を使用し、チーム間で予測可能に動作する必要があります。

この文脈において、大規模言語モデルは構造的な課題をもたらします。チームが多様なプロンプトや曖昧に定義された指示に依存していると、同じ要求であっても一貫性のない出力が生成され、時間の経過とともにアーキテクチャの乖離（ドリフト）を招く可能性があります。

これに対処するため、DAAチームはプロンプトエンジニアリングだけに頼るのではなく、ガバナンスが適用されたエンタープライズ環境内でAIがどのように動作すべきかを定義することに注力しました。

ダイキン・アプライド・アメリカズのデータ＆アナリティクス部門シニアディレクターであるTrent Lezer氏は、次のように述べています。「Genie Codeは、仕事は早いが、他の全員と同じアーキテクチャ上の制約を遵守しなければならないジュニアエンジニアのように扱うのが最も効果的です。『AIだから』という特別な例外はありません」

再利用可能なスキルによるデータエンジニアリングのスケール

Genie Codeの初期の使用法は、よくあるパターンに従っていました。それは、アーキテクチャルール、命名基準、変換ロジック、ドキュメント要件を1つのテキストブロックに詰め込もうとする長いプロンプトでした。

このアプローチはスケールしませんでした。指示はチームごとに異なり、プロンプトの維持管理は困難になり、同様のタスクでも一貫性のない出力が生成されました。

これに対処するため、チームはMECE（Mutually Exclusive, Collectively Exhaustive）なスキルフレームワークを導入しました。Trent氏は次のように説明します。「私たちはMECEなスキルフレームワークを導入しました。各スキルは1つの一貫した能力を定義し、スキル同士の重複はなく、全体としてデータエンジニアリング業務のライフサイクル全体をカバーしています」

各スキルは、データエンジニアリングのライフサイクルにおける特定の機能を定義します。これらのスキルは互いに重複せず、ワークフロー全体をカバーします。これらには、メダリオンアーキテクチャ設計、ソースの準備状況と粒度の定義、変換パターン、標準的な整合、ガバナンス基準などが含まれます。

プロンプト内にルールを埋め込む代わりに、チームはGenie Codeが実行時に適切なスキルをロードし、計画と実行の段階でそれらを適用するように環境を構築しました。これにより、アドホックな指示を解釈する動作から、定義された実行モデル内で動作する形へとシフトしました。

ガバナンスの観点からも、これにより基準の適用方法が変わります。DatabricksのソリューションアーキテクトであるJames VanGordon氏は次のように指摘しています。「Genie Codeでよく見られるパターンは非常にシンプルです。プロンプトは使い始めるのには適していますが、チームの基準を強制する場所としては不適切です。同じルールが複数回重要になる場合は、ワークスペース内にスキルとして配置し、Genie Codeが実際にそれを利用できるようにすべきです」

同氏はまた、実行環境に直接基準を埋め込むことの重要性を強調しています。「これこそが、単なる絵に描いた餅ではなく、現実のものにする要因です。スキル、Unity Catalogのコンテキスト、そしてGenie Codeが同じ場所で動作しています。ガイダンスは、後で誰かが思い出さなければならないようなレビュープロセスとして脇に置かれるのではなく、作業が作成されるその場所に存在しているのです」

メダリオンアーキテクチャを活用したパイプライン開発のガイド

チームはまた、ガバナンスと推論の両方のフレームワークとして、メダリオンアーキテクチャの役割を強化しました。Bronze、Silver、Goldの各レイヤーはすでに存在していましたが、今回の変化は、これらを単なるストレージ層としてではなく、パイプライン生成時における明確な意思決定の境界線にしたことです。

Bronzeは生のソースデータを表し、Silverはクレンジングおよび適合されたデータを表し、Goldはビジネスにすぐに活用できるアナリティクスデータを表します。

この構造を実用化するために、チームはレイヤー間にチェックポイントを導入しました。データが次のレイヤーに進む前に、ソースの粒度定義、結合の検証、データの安定性チェックなどの要件を満たす必要があります。

これらのチェックポイントは、下流のレビューステップとしてではなく、開発ワークフロー自体の中で適用されます。Genie Codeは、パイプラインが生成および変更される際に、これらの制約内で動作します。

これにより、迅速な開発においてアーキテクチャの近道（手抜き）をしてしまうリスクを軽減しながら、チーム間の一貫性を確保できます。

パイプラインとビジネスコンセプトの連携

エンタープライズデータエンジニアリングにおける共通の課題は、技術的なモデルをビジネス言語と一致させることです。

DAAでは、関係者はテーブル、結合、変換ではなく、機器、顧客、サービスイベント、契約といった観点で考えます。

これに対処するため、チームはパイプラインの設計を安定したビジネスエンティティに紐付けました。技術的な構造から始めるのではなく、エンジニアはまずデータが何を表しているのか、そして時間の経過とともにどのように変化するのかを特定することから始めます。

このシフトにより、下流工程の取り組みが改善され、データセットがドメイン間で再利用される際の曖昧さが軽減されます。

時間の経過とともに、SilverレイヤーのモデルとGoldデータセットは、個別の技術的な決定ではなく、共有されたビジネスコンセプトに基づいているため、より一貫したものになります。

チームにもたらされた変化

この運用モデルが導入され、AIが組み込まれたことで、チームは業務の実行方法に明確な変化を実感しました。

特に初期の探索やイテレーションにおいて、パイプライン開発が加速しました。エンジニアはボイラープレートコードの作成に費やす時間を減らし、ビジネスロジックの洗練により多くの時間を割くようになりました。

また、チーム間での出力の一貫性も向上しました。同様のユースケースが同様の構造パターンに従うようになり、メンテナンス性と再利用性が向上しました。

重要な点として、生成された出力に対する信頼性が高まりました。エンジニアは構造の正確性を検証する時間を減らし、より迅速にイテレーションを行えるようになりました。

開発ワークフロー内での意思決定の標準化

これらの成果を再現可能なものにするために、チームは開発プロセスにおける主要な意思決定を標準化しました。

暗黙の知識に頼るのではなく、何がBronze、Silver、Goldデータに該当するのか、ソースの粒度がどのように定義されるのか、どの変換パターンが再利用可能なのか、ビジネスエンティティがどのように表現されるのかなど、定義を明確にしました。この構造はスケールさせるために不可欠でした。これにより、ユースケースが進化しても、AIがチーム間で一貫したフレームワーク内で動作することが保証されます。

その成果：大規模なスケールで実現したこと

修正の削減による迅速なデリバリー

エンジニアは、構造的に誤ったパイプラインの修正に費やす時間を減らし、ロジックやビジネス成果の洗練により多くの時間を割くことができます。

チーム間におけるアーキテクチャの乖離の抑制

スキルとガバナンスチェックポイントを一貫して適用することで、同様のデータの課題に取り組むチーム間での乖離を防ぎます。

エンジニアリングとビジネスの連携強化

パイプラインをビジネスコンセプトに基づかせることで、明確性が向上し、下流工程での手戻りが減少します。

手動のオーバーヘッドを伴わない、スケーラブルなガバナンス

ガードレールがシステムに直接組み込まれているため、手動での強制への依存が軽減されます。

AI生成出力に対する信頼性の向上

定義されたスキルとチェックポイントが出力を制限するため、AIは本番ワークフロー内で信頼性高く動作します。

Trent氏は次のようにまとめます。「目標は、AIにより多くのルールに従わせることではありません。正しいルールを無視できないようにすることです」

結論

ダイキン・アプライド・アメリカズでは、構造化された運用モデルとAI支援開発を組み合わせることで、データチームが一貫性、明確性、制御を維持しながら、より迅速にスケールできるようになりました。

パイプラインの構築方法を定義し、それらのルールを開発環境に直接組み込むことで、チームはスピードとガバナンスが競合するのではなく、互いに補強し合うシステムを構築しました。

詳細は、Genie Codeをご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事