Andrew Tanによる
なぜこれを書いているのか
AIが現在話題になっているため、一部のCTOは「AIがデータエンジニアリングチームの半分を置き換えるべきか？」と自問しています。
これが現在のデータエンジニアリングにおけるAIの状況です。誰もが息を呑むようなコンテンツを発表していますが、具体的なことを述べている人はいません。そこで、私の見解を述べます。
AIが本当に役立つこと
SQL生成は最も明確な勝利です。Copilotスタイルのツールは、しっかりとしたSQLの基礎を持つエンジニアにとって、最初のドラフトの分析クエリを書く時間を50-70%短縮します。レビューは必要ですし、答えがどのように見えるべきかを知っている必要がありますが、白紙の問題はなくなります。
スキーマのドキュメント化は劇的に速くなります。「400のテーブルがあります」から「400のテーブルを文書化しました」に至るまで、以前はアナリストの時間が数か月かかっていました。良いLLMツールを使用すれば、チームはこれを数週間で達成できます。ドキュメントは完璧ではありませんが、以前は役に立たないことが多かったのに対し、十分に役立つものになっています。
アドホック分析は非エンジニアにとって意味のある変化をもたらしました。「クエリを書いてくれませんか」というチケットを提出していたビジネスアナリストが、今では自分で簡単な質問に対する答えを得ることができます。これは実際の生産性です。また、データエンジニアリングチームにとって、割り込み駆動の作業の意味ある削減でもあります。
コードレビューのドラフト。レビューの代替ではありませんが、明らかな問題（インデックスされていない結合、欠落しているnullチェック、型の不一致）を人間が見る前にキャッチすることで、全体の時間を節約します。
これらは現実であり、重要です。これを軽視したくはありません。
AIが信頼できないこと
ここで、ベンダーの主張と実際の運用現実とのギャップが開きます。
大規模なスキーマ進化
本番パイプラインを維持する最も難しい部分は、コードを書くことではなく、上流システムがフィールドタイプを変更したり、列を廃止したり、異なる形式でデータを送信し始めたときに何をすべきかを知ることです。これは、データの背後にあるビジネスロジック、下流の消費者、そのフィールドが存在する理由の歴史的背景を理解する必要があります。これらの決定が行われたときに部屋にいなかったLLMは、正しい対応について確実に推論することはできません。それは見た目には正しいものを提供しますが、しばしばそうではありません。
状態を持つストリーム処理
チームは、リアルタイムの不正検出パイプラインのために、遅延到着処理を伴うウィンドウ集約を正しく実装するために、LLMを3か月間試行することがあります。LLMはコードを書くことができます。コードも実行されます。しかし、特定の順序条件下で、異常なイベントボリュームの日にのみ本番で現れるエッジケースで誤った答えを生成します。これらのバグは難しい種類のもので、エラーを投げることはなく、静かにメトリクスを破損させます。モデルは、実際に直面するエッジケースに対して自分の出力をテストする方法を持っていません。
本番障害の回復
Kafkaコンシューマーが48時間遅れているときに、再生するか、ドロップするか、重複を排除するかを決定する必要がある場合、それはコード生成の問題ではありません。それは、ビジネス、SLA、および各オプションのコストを知る必要がある判断です。私はまだ、LLMが人間の大きな支援なしにその判断を正しく行うのを見たことがありません。
あるサイバーセキュリティ会社のリードエンジニアは私に言いました。「私たちは標準的なETLパターンの約70%を自動化しました。最後の30%が実際に本番で壊れる部分です。」彼は不満を言っているわけではありませんでした。彼はその理由を理解していました。しかし、その30%がデータエンジニアを雇用する理由です。
「80%自動化」の問題
Gartnerは昨年、2027年までにデータエンジニアリング業務の80%が影響を受けると予測を発表しました。彼らがそれを書いた理由は理解できます。
80%についてのことは、彼らが話している80%は足場です。ボイラープレートです。実際に80%自動化可能な部分は、すでに比較的速かった部分です。
残るのは、80%の時間を要する20%です。データが間違って見える理由をデバッグし、上流チームとスキーマ変更を交渉し、誰も予期しなかった条件下でのパイプラインの信頼性を推論することです。その20%は、間違った答えが高価な20%でもあります。
私はこれを悲観的に言っているわけではありません。80%は重要です。エンジニアリングチームを足場から解放することは本当に価値があります。しかし、この自動化がエンジニアを減らすことを意味する世界を計画しているチームは、高価な問題も簡単になるという特定の賭けをしています。そうなるかもしれません。私はまだその証拠を見ていません。
人員削減を検討しているチームに伝えること
まだやらないでください。技術が現実でないからではなく、間違った変数に賭けているからです。
AIツールを最大限に活用しているチームは、人員を削減しているチームではなく、同じ人員をより難しい問題に向けているチームです。日常的なETL作業に費やしていたエンジニアは、今ではデータ品質フレームワーク、スキーマガバナンス、リアルタイムパイプラインの信頼性に取り組んでいます。エンジニア1人当たりの出力は高くなっています。出力の質も高くなっています。チームは置き換えが難しくなっています。
これがストーリーです。AIはデータエンジニアにとって生産性の乗数です。それがデータエンジニアそのものではありません。
シンプルな概要
比較表形式を避けると言いましたが、これが最も明確に示す方法です：
| タスク | AIが助ける | AIが苦手なこと |
|---|---|---|
| SQL生成 | 最初のドラフト、50-70%速い | 微妙なビジネスルールを含む複雑なロジック |
| スキーマドキュメント | 最初のパス、数週間で完了 | ビジネスコンテキストなしでの正確な意味 |
| アドホック分析 | 非エンジニア向けの簡単な質問 | システム間のコンテキストを必要とする質問 |
| パイプラインコード | ボイラープレート、標準パターン | 状態を持つロジック、エッジケースの処理 |
| スキーマ進化 | — | ほぼ完全に人間の判断 |
| 障害回復 | — | ビジネスと運用の知識が必要 |
| 本番デバッグ | — | LLMは特定の履歴を知らない |
左の列は現実です。右の列がデータエンジニアリングチームがまだ存在する理由です。
layline.ioの役割
率直に言いますと、上記で説明したAIの生産性向上は、パイプラインがLLMが理解し拡張できる明示的な構造を持っている場合により簡単に達成できます。
layline.ioでは、宣言型の設定でパイプラインを構築しています。ロジックはカスタムコードに埋め込まれているのではなく、構造化されたオペレーターにあります（カジュアルなJavascriptやPythonを除いて、本当に必要な場合のみ）。これはAI支援の開発と相性が良いことが判明しました。エンジニアがLLMに処理ステップを追加するように依頼すると、LLMはそれを明確に推論できます。何かが壊れたとき、失敗は特定の場所にあり、カスタムコードに埋もれているわけではありません。
それが私たちがそれをそのように構築した理由ではありません。宣言型パイプラインは人間がデバッグしやすく、維持しやすいためにそのように構築しました。AIとの親和性は副次的な効果でした。
しかし、構造化された基盤の上に構築しているチームは、カスタムコードで作業しているチームよりもAIツールをより活用できるということです。2年後に重要になるアーキテクチャの選択を行う際に考慮すべきことです。
チームに尋ねる価値のある質問
これを試してみてください：最後の5つのデータインシデントを選びます。それぞれについて、AIがそれを防いだり、より迅速に診断したりできたかどうかを尋ねてください。
ほとんどのチームにとって、答えは「5つのうち1つかもしれない」です。他の4つは、LLMが信頼できる推論を行えない問題です。技術的には正しいコードであるが間違ったビジネスロジック、誰も発表しなかった上流チームからのスキーマ変更、特定のイベントボリュームでのみ現れるストリーム処理のエッジケース。
AIツールを評価する際、それが基準です。「AIがデータエンジニアリングを変えるかどうか」ではなく、もちろん変わります。しかし、「AIが実際に私たちを傷つける問題を解消するかどうか？」その答えは、まだ変わっていないことが変わらない限り、いいえです。
Andrew Tanは、layline.ioの創設者であり、バッチとリアルタイムの両方のワークロードを大規模に処理するエンタープライズデータ処理インフラストラクチャを構築しています。
