2026年6月1日～4日にサンフランシスコで開催されたSnowflake社によるグローバルで最大のイベント「Snowflake Summit 2026」に参加しました。
データ基盤の構築やデータにまつわるPoCの担当者が、本イベント内のセッションで語られた「AIエージェント時代にエンジニアの働き方がどう変わるか」 についてレポートします！

会場にて撮影した写真

今年のセッションを通じて感じたのは、AI活用に関する議論が「何ができるか」から「どう定着させるか」へと移りつつあることです。
これまでは生成AIの性能やデモンストレーションに注目が集まっていましたが 、今年は「業務で継続的に活用し、成果につなげるために何が必要か」が主要なテーマとなっていました。
実際、多くの企業ではPoCまでは成功しても、本番運用の段階で利用が定着しないという課題を抱えています。その要因として繰り返し語られていたのが、「測定の仕組み」「コスト管理」「運用プロセス」の重要性です。
本ブログでは、これらの観点から具体的な数値とともに紹介されていた3つの実装パターンを取り上げます。

AIエージェント時代にエンジニアの働き方 ポイントその①：成功条件を「メトリクスとして」先に実装する

1つ目はevolv Consulting社の製造業へのAI活用の事例紹介でした。
彼らはAI活用において、成功条件を先にメトリクスとして定義することで、効果を数字で示しながら導入を高速に回すことを実現していました。
同社は、AI活用を

• 業務オペレーション
• 技術デリバリー
• 人材・生産性

の3領域で並行して進めていました。

会場にて撮影した写真

特に注目したのは、ROIを後追いの報告値にせず、初日からメトリクス*として計測ラインに組み込む考え方です。機能を作る前に「何が動けば成功か」を計測可能な指標に落とし、パイプラインや業務フローに最初から計測点を仕込んでおく、各マイルストーンで削減コストや追加収益が数字で出るので、次の投資判断も実測値で回せます。
＊メトリクス：システムの状態、業務のプロセス、プロジェクトの進捗などを定量化し、評価・管理しやすくした数値データや指標

また、印象に残ったのは工程の回し方です。
Discovery → Build → Scale → Repeat のサイクルで、従来数か月かかっていた要件整理〜優先順位づけを数週間に圧縮していたとのことでした。

会場にて撮影した写真

しかし、どのデータ・指標が意思決定に効くか、どこに計測点を置くかを設計するのは引き続き人の領域です。
手を動かす工程をAIに寄せるほど、この「何を測るかを定義する」工程の重要性が増す、と感じました。

AIエージェント時代にエンジニアの働き方　ポイントその②：移行の費用対効果を「compute削減」で説明する

2つ目は米国のある自動車マーケットプレイスのデータ移行事例についてです。
彼らはAI活用において、移行前に現状の「ムダ」を定量化することで、投資判断と成果を数字で回すことを実現していました。

ポイントは、ツール選定の前に「いま何にムダな時間とcomputeを払っているか」を定量化していたこと、削減できる工数とコストを先に見積もっていた点です。
その結果がこちらです。

• 投資回収まで5か月
• 保守・運用で約3,500時間を削減し、回収した時間は計6,000時間超

投資回収を生んだ肝が「dbt State」です。dbt Stateは、「前回から変わったところだけ」を賢く見つけて処理する機能です。変わっていない部分の無駄な再計算をやめることで、処理時間とコストを削減できます。

変更があったモデルだけを選択的にリビルドする運用に切り替え、毎回フルビルドしていたSnowflakeのcompute代を削減。「dbt Stateだけで元が取れた」と言い切っていました。差分実行の結果が、そのままコスト削減の根拠になる、これは経営に説明を通しやすい形です。

会場にて撮影した写真

会場にて撮影した写真

浮いた工数は、増員ではなくAIエージェントやアプリ開発といった「より価値の高い実装」へ回していました。
「まずキャパシティを空けてから、AIに取り組む」という言葉は、エンジニアとして、運用負荷の低いシステムづくりを通じて、企業が攻めの投資に踏み出せる余力を生み出していきたいと思わせられました。

AIエージェント時代にエンジニアの働き方　ポイントその③：データ基盤に「SDLC」を持ち込む

3つ目はNOV社による財務（FP&A）デジタル化の事例紹介でした。
彼らはAI活用において、データの更新に開発と同じ管理プロセス（SDLC）を持ち込むことで、エンジニアが整えた仕組みの上に、非エンジニアの財務ユーザーも安全に乗れる基盤を実現していました。

NOVは116年・200件超の買収で複雑化した企業で、Sigmaを導入して財務データの分析・更新を進めていました。
特に注目したのは、データの更新に「開発と同じ昇格プロセス」を持ち込んでいた点です。すべての変更を記録するテーブルで追跡し、development → QA → prototype → 承認後に本番へ昇格という流れを敷く。これにより、Excelの自由さでは失われがちな変更履歴とガバナンスを、現場の柔軟性を保ったまま担保していました。

会場にて撮影した写真

また、印象に残ったのは「コメント機能」です。データの横に直接コメントを残せることで、メールやExcelに散っていたやり取りが基盤上に集約され、変更の文脈もそのまま記録に残るようにしていました。

会場にて撮影した写真

とはいえ、バージョン管理・承認・昇格といったSDLCの仕組みそのものを設計し、整えるのはエンジニアの領域です。この土台があるからこそ、SQLを書けない財務ユーザーでも統制を壊さずにデータへ関与できる。AIや非エンジニアが触れる範囲が広がるほど、その受け皿となるSDLCを設計するエンジニアの役割がむしろ重要になる、と感じました。

まとめ

3社に共通していたのは、ツールそのものより「計測点を先に仕込む」「computeコストの構造で費用対効果を語る」「変更管理をSDLCに乗せる」という設計の作法が、PoCの定着を分けていたことでした。
私たちが関わるのは、たいていデータ基盤やPoCの実装フェーズです。この3つの作法を最初から織り込めるかどうかが、「動いたのに使われない」で終わるか運用に乗るかを大きく左右します。この前提を見極めて提案に組み込んでいきたい、そう感じたSummitでした。
次のブログでは、もう少し現場寄りに「エージェント時代のデータエンジニアリング」をご紹介します。

 本記事は、2026年6月4日時点の情報をもとに作成しています。製品・サービスに関する詳しいお問い合わせは、弊社Webサイトからお問い合わせください。
https://data-management.dentsusoken.com/snowflake/inquiry/

本サイトのブログ記事に加え、Snowflakeを中心としたデータエンジニアリング関連の技術的な情報を掲載したテックブログもWeb公開しております。
是非、こちらのテックブログもご覧ください。
https://zenn.dev/p/datatechblog