MotherDuck、AI時代のデータエンジニアリングを語る Chris Riccomini インタビューを公開

MotherDuck は 2026年5月21日、Chris Riccomini 氏へのインタビュー「Plan Mode All the Time, Substrait over SQL, and the End of the DE Role ft. Chris Riccomini」を公式ブログで公開しました。AI がデータ作業をどう変えるかを、正確性、SQL と Substrait、品質ゲート、エージェント権限管理、データエンジニアの役割という観点で掘り下げる記事です。

要点

• 金融など正確性が重い領域では、AI に任せる場所ごとに説明可能性、データ不変条件、レビュー方法を分けて考える必要があります。
• SQL ではなく Substrait のようなデータ変換表現を AI が扱う可能性が語られています。
• AI エージェントを使う開発では、計画の反復、コンテキスト管理、テストやカバレッジなどの品質ゲートが重要だと説明されています。
• エージェントにはリネージ、監査可能性、ロールベースアクセス制御、属性ベースアクセス制御のような権限・監査の仕組みが必要になるという見方が示されています。
• データエンジニアという専門職が、より広いデータ職能に再編される可能性にも触れています。

今回のブログ記事で語られていること

この記事は、MotherDuck の製品機能を直接発表する記事というより、AI とデータエンジニアリングの実務がどこへ向かうかを考えるための長いインタビューです。Chris Riccomini 氏は、WePay、LinkedIn、PayPal での経験や Apache Samza、SlateDB、Airflow への関わりを持つ人物として紹介され、AI をデータ作業に入れるときの期待と危うさを、かなり実務寄りに語っています。最初の論点は、金融データのように正確性が重要な場面で AI をどう扱うかです。リスク、詐欺、不正検知、コンプライアンスのような判断系では説明可能性が重く、データエンジニアリングでは台帳が合うことなどの不変条件を定義し、分析では人間との組み合わせで誤りを減らせるかが問題になります。つまり、AI を一括りに導入するのではなく、判断、パイプライン生成、分析支援でリスクを分ける読み方が必要です。

次に、LLM が SQL ではなく Substrait のような表現を使う可能性が取り上げられます。記事では、SQL が人間にも機械にも使われてきた一方で、Substrait はデータ変換を表す形式として、論理演算だけでなく物理的な実行方法も表現できると説明されています。AI が SQL を文字列として生成するだけでは、構文の揺れや幻覚、最適化の限界が残ります。Substrait のような中間表現を使えれば、より少ないトークンで変換を表し、クライアント側で物理計画まで考え、データベースへ渡す余地が出ます。ただし、インターネット上の学習材料は SQL の方が圧倒的に多く、Substrait を AI がどこまでうまく扱えるかは実験が必要です。

AI エージェントを開発やデータ作業に使う方法としては、計画作りと品質ゲートが強調されています。Chris 氏は、単に計画モードで一度計画させてから実装させるのではなく、計画を何度も掘り下げ、曖昧さが残らない状態まで反復する必要があると語っています。そのうえで、長い作業ではコンテキストを定期的に整理し、いわゆる Ralph Loop のように、外部テストや品質条件を通して失敗と修正を繰り返す方法に触れています。テストカバレッジ、コミット前の検証、フックによる強制など、人間の気合いではなく機械的な制約として品質を置くべきだという点は、データパイプラインや分析コードにもそのまま関係します。

セキュリティ面では、エージェントが CLI、API、スキル、ファイル、認証情報へアクセスする時代に、企業がどう管理するかが課題になります。記事では「エージェント向け Okta」という表現を使いながら、リネージ、監査可能性、ロールベースアクセス制御、属性ベースアクセス制御のような仕組みが必要だと説明されています。AI は漏えいした認証情報や PII を検出するのにも役立つ一方で、エージェント自身の権限が広がるほど、どのツールを使い、どのデータへ触れ、どの操作を実行したかを追跡できなければなりません。MotherDuck や DuckDB を含むデータ基盤の文脈では、AI が SQL やパイプラインを作るだけでなく、接続先、認証、監査、再実行性まで含めて設計する必要があると読めます。

最後に、データエンジニアという役割の将来にも踏み込んでいます。AI エージェントは、失敗した GitHub Actions やワークフローを調べ、SQL を実行し、Python を書き、監視と自動修復に接続される可能性があります。新しいパイプラインの追加も、インフラと接続情報が整えば AI が担える領域に近づくという見方です。その結果、データエンジニアリング、分析、機械学習、AI 活用がより一体化し、専門職の境界が変わる可能性があります。記事はこの変化を単純な職種消滅としてではなく、ツール、権限、品質、学習の仕方が変わる問題として扱っています。

今回のブログ記事が関係する人

データ基盤や分析基盤を運用するチーム、AI エージェントを開発作業やデータパイプラインに取り入れたいチーム、DuckDB / MotherDuck を AI 時代の分析基盤として見ている人に関係します。特に、AI に SQL、パイプライン生成、品質確認、障害調査を任せたい場合は、この記事の論点を導入前チェックリストとして使えます。

実務で確認したいポイント

AI をデータ作業に入れる前に、どの作業を任せるのかを分けて考えたいです。分析支援、SQL 生成、パイプライン生成、障害調査、権限付きの自動修復では、必要な品質ゲートと監査ログが違います。特にデータ移動や金融・顧客データに触れる処理では、不変条件、再実行性、レビュー、ロールバック手順を先に決める必要があります。

Substrait のような中間表現については、今すぐ SQL を置き換える話ではなく、AI がデータ変換をより安全に扱うための候補として見るのが現実的です。自社で検証するなら、AI が生成した SQL と中間表現を比較し、どちらがレビューしやすく、再現性が高く、実行計画を制御しやすいかを小さく試すのがよさそうです。

結局、今回のブログ記事をどう読むべきか

この MotherDuck Blog は、AI とデータエンジニアリングを楽観的に語るだけの記事ではありません。AI ができることは広がる一方で、正確性、品質ゲート、権限管理、監査、再実行性を設計しないまま使うと、データ基盤のリスクも大きくなります。MotherDuck / DuckDB 周辺を AI エージェントの作業基盤として見ているチームは、機能比較より先に、AI が触れるデータと操作をどこまで管理できるかを確認する材料として読むべき記事です。