AIは本当にデータパイプラインを構築できるのか？Apache SeaTunnel AI CLIを用いた7つの主要LLMの100タスクベンチマーク

大規模言語モデル（LLM）は、自然言語要件の理解、ETL構成の生成、構成ファイルの検証、実行後のトラブルシューティング支援など、現代のデータエンジニアリングワークフローに急速に組み込まれつつある。しかし、エンジニアリングチームにとって真の課題は、モデルに「構成を生成させる」ことではなく、一見正しく見えても本番環境で確実に動作しない構成を生成するモデルを避けることにある。

ETLシナリオでは、構成を生成できたとしても、静的検証を通過しても、データパイプラインが実際のデータソースに接続でき、Change Data Capture（CDC）などのランタイム前提条件を満たし、エンドツーエンドのデータ同期を完了できるとは限らない。汎用ベンチマークや単一の成功例だけに基づいてモデルを選択すると、本番環境で繰り返し発生する障害、手動によるトラブルシューティング、予測不能な運用コストにつながる可能性がある。

本稿では、Apache SeaTunnel AI CLIプロジェクトに基づき、7つの主要LLMを対象に100のETLタスクで階層型ベンチマークを実施した。構成生成と静的検証だけでなく、実際のデータ環境での実行も検証している。結果は、静的検証での高いパフォーマンスが必ずしも高いランタイム成功率に結びつかないことを示している。

このベンチマークは汎用LLMのランキング付けを目的とせず、AI支援ETLのための実用的な評価手法を提案する。エンジニアリングチームは、単一のベンチマークスコアに頼るのではなく、自社のワークロード複雑性、ランタイム成功率、エラー回復能力、全体的な運用コストに基づいて、継続的にモデルを評価・選択すべきである。

背景：Apache SeaTunnel AI CLIと正確性の重要性

Apache SeaTunnelは、Apache Software Foundationのトップレベルプロジェクトであり、バッチ処理、ストリーム処理、CDCワークロード向けのデータ統合機能を提供する。そのエコシステムは100以上のコネクタをカバーし、JDBC、Kafka、Amazon S3、Hive、リレーショナルデータベース、メッセージングシステムなど多岐にわたる。

この豊富なコネクタエコシステムによりSeaTunnelは幅広い統合シナリオをサポートする一方で、構成の複雑さも増大している。単一のコネクタで20～50の構成オプションが存在し、ユーザーはパラメータタイプ、必須フィールド、依存関係、実行モード、上流・下流システムの前提条件を理解する必要がある。さらに、SeaTunnelはHOCON構成形式を使用しており、初心者にとっては複雑なパイプラインの学習曲線が急峻になる。

コミュニティユーザーから最もよく寄せられる質問は次のように要約される：「SeaTunnelがデータ統合ニーズを処理できることは分かっているが、ドキュメントを何度読んでも構成ファイルを正しく作成できない。」この課題こそがSeaTunnel AI CLIが開発された理由である。

その目標は単に構成テキストを生成することではない。ユーザーが自然言語でデータ統合要件を記述できるようにすることである。例えば、「MySQLのordersテーブルをCDCを使用してStarRocksに同期し、timestamp列でパーティション分割する」といったリクエストに基づき、AI CLIはSeaTunnelのコネクタ知識、構成ルール、ランタイムフィードバックを組み合わせて、対応するデータパイプライン構成を生成、検証、反復的に改善する。

ユーザーエクスペリエンスの観点から、目標は構成ワークフローを「ドキュメントを読む→構成パラメータを組み立てる→試行錯誤→ログを分析→手動でエラーを修正する」から「要件を記述する→構成を生成する→実行を検証する→フィードバックに基づいて構成を改善する」へと変革することである。

理想的な成果は、単に見栄えの良いHOCONファイルを生成することではなく、可能な限り初回から実行可能で検証可能なSeaTunnel構成をユーザーが得る手助けをすることである。

この目標を達成するには、LLM APIを統合するだけでは不十分である。本番レベルのETLワークロードをサポートするには、モデルが100以上のコネクタのセマンティクス、データ型制約、パラメータ依存関係、CDC前提条件、複雑なDAGの構成を理解する必要がある。同時に、AI CLIはSeaTunnelのJavaコネクタ実装、OptionRule定義、構成検証結果、ランタイムエラーメッセージを、モデルが理解して行動できる構造化コンテキストに変換しなければならない。幻覚パラメータ、見落とされた前提条件、誤った修復戦略は、生成された構成の実環境での失敗を引き起こす可能性がある。

このため、問題は本質的に複雑で多次元的である。システムは既存のJavaコネクタの動作を理解しつつ、Python CLIで信頼性の高いAgentワークフローを調整し、モデルの生成能力を活用しつつ、モデルがコネクタの正しい動作を「推測」することに依存せず、さらに迅速に反復しながら、すべての変更を実際のデータ環境に対して検証する必要がある。

したがって、AI CLIにとって最も意味のある品質指標は、構成が生成できるか、静的検証を通過するかではない。真に重要な指標は正確性である。モデルが生成した構成が、指定されたデータソース、宛先、ランタイム条件下で、実際のデータ統合タスクを正常に完了できるかどうか。この疑問に答えるため、本稿では3層の検証フレームワーク（静的構成検証、CLI検証、実実行）を用いて異なるモデルを評価し、結果に基づいて本番環境でのAI支援ETLにおけるモデル選択戦略と今後のエンジニアリング改善について議論する。

評価手法：静的チェックから実実行までの3層検証フレームワーク

従来の構成生成ベンチマークは、多くの場合、構文の正確性、テキスト類似性、手動スポットチェックの評価で終わっていた。しかし、Apache SeaTunnelのようなデータ統合プラットフォームでは、正しく見える構成が実際の本番環境でデータパイプラインを正常に実行できるとは限らない。

このため、本ベンチマークは「HOCON構成を生成する」ことを最終目標としない。代わりに、各モデルが生成した構成を段階的に厳格化された検証パイプラインに通す。まず基本的な構成構造を検証し、次にSeaTunnel CLIルールとコネクタ制約に照らして検証し、最後に実際のデータサービスを含むDocker化環境で実行する。

これら3つの段階を、それぞれL1静的検証、L2 CLI検証、L3ランタイム検証と呼ぶ。

ベンチマークタスクとカバレッジ

ベンチマークは100のApache SeaTunnel ETLタスクで構成され、タスクの複雑さに基づいて3つの層にグループ化される。カバレッジはバッチETL、CDC、データ形式処理、フィールドマッピング、変換ロジック、複雑なDAGワークフローなど多岐にわたる。ランタイム環境にはMySQL、PostgreSQL、Kafka、ClickHouse、Elasticsearch、MinIO、Doris、StarRocksなどのコンポーネントが含まれる。

各ベンチマークタスクには、データ統合要件の自然言語記述、期待されるソースからターゲットへのデータフロー、必要なランタイム環境、タスクが正しく完了したか判断するための成功基準が含まれる。

L1：静的構成検証

L1は、モデルが自然言語リクエストから構造的に有効なApache SeaTunnel構成を生成できるかを評価する。この段階では、HOCON構成が正常にパースできるか、env、source、transform、sinkの必須セクションが存在するか、コネクタ名、必須フィールド、フィールドタイプが基本構成要件を満たしているか、構成が初期静的検証ルールを通過するかを検証する。L1が答えるのは「モデルは構造的に正しいSeaTunnel構成を生成できるか？」という単純な問いである。この検証段階は高速で、大規模ベンチマークや定期回帰テストに適している。ただし、その限界も明らかである。構文的に有効で必須セクションをすべて含むHOCONファイルでも、コネクタパラメータの誤り、パラメータの無効な組み合わせ、ランタイム前提条件の欠落、外部システムへの接続失敗、CDC要件の未達などにより失敗する可能性がある。L1合格は構成が有効に見えることを示すだけで、実際に実行できることを保証しない。

L2：CLIとルールベース検証

L1に加え、L2段階ではdry-runまたは--checkオプションによるSeaTunnel CLI検証と、OptionRuleで定義されたコネクタ固有の検証ルール、パラメータ制約、DAG検証を導入する。L1と比較して、L2は構成が実行前に検証可能な実行ルールに準拠しているかに焦点を当てる。これらのチェックには、コネクタパラメータが完全で無効な組み合わせがないか、ソース、トランスフォーム、シンクコンポーネント間の関係が有効か、DAG構造と実行モードが正しく構成されているか、CDC、データ形式、スキーマ、チェックポイントに関連する既知の制約が満たされているかが含まれる。L2が答えるのは「構文的に正しいだけでなく、構成はSeaTunnelの実行ルールとコネクタ検証要件に準拠しているか？」という異なる問いである。この段階では、テキスト的には妥当に見えるがコネクタルールに違反する多くの構成を捕捉できる。例えば、モデルがMySQLソースとStarRocksシンクを正しく生成しても、必須のコネクタオプションを省略したり、CDCパイプラインに互換性のないパラメータ組み合わせを使用したりする可能性がある。それでも、L2はランタイム検証を完全に置き換えることはできない。多くの問題は、外部サービスへの接続、実際のデータの読み取り、完全なパイプラインのトポロジーの実行後にのみ明らかになる。

L3：Docker化環境でのランタイム検証

L3は本ベンチマークの中核である。前の2段階を通過したすべての構成について、Docker Composeを使用して完全なテスト環境を起動する。これにはデータソース、メッセージングシステム、ターゲットデータベースまたはストレージシステム、Apache SeaTunnelランタイム自体が含まれる。その後、生成された構成を使用して実際のSeaTunnelジョブを送信し、期待されるデータ同期タスクが正常に完了するかを検証する。CDCワークロードの場合、正常な実行は、データベースのbinlogや論理レプリケーション、ユーザー権限、パブリケーション、server-id設定、チェックポイント構成、コネクタバージョンの互換性など、多くのランタイム前提条件に依存する。複雑なDAGワークフローの場合、実際の実行のみが、データが複数のソース、トランスフォーム、シンクを正しく通過し、ターゲットシステムに書き込まれるかを検証できる。L3ワークフローは6つのステップで構成される：必要なDocker Compose環境を起動する、ソース側のテストデータ/CDC状態/メッセージデータを準備する、モデル生成構成を使用してApache SeaTunnelジョブを送信する、ジョブの起動、実行、完了ステータスを監視する、期待されるデータがターゲットシステムに正しく書き込まれたか検証する、失敗した各タスクの実行ログ、エラーメッセージ、修復記録を保存する。

結論

本ベンチマークは、AI支援ETLにおいて、ランタイム成功率がモデルの正確性を測定する重要な指標であり、静的検証結果のみに依存すべきでないことを示している。エンジニアリングチームは階層的検証アプローチを採用し、自社のワークロード特性に合わせて、生成の正確性とランタイム信頼性のバランスが取れたモデルを選択すべきである。今後の取り組みとして、タスクカバレッジの拡大、エラー回復メカニズムの最適化、より効率的なモデル評価プロセスの探索が挙げられる。