データエンジニアリングにおけるAI活用戦略：縦と横のハーネスエンジニアリング
AI要約
AIの生産性を左右する「ハーネスエンジニアリング」を縦（データフロー全体へのAIアクセス拡大）と横（非エンジニアへの知識スケールアウト）の2軸で整理し、データエンジニアリングを労働集約から資本集約へ転換する戦略を論じている。
AIが力を発揮できるように周辺環境を整備するエンジニアリングのことを「ハーネスエンジニアリング」と呼ぶらしい。*1
- AIがBigQuery MCP Serverを経由してBigQueryにアクセスし、データを解釈できるようにしたり
- データ不整合に関する調査ドキュメントを読み取り可能なコンテキストの中に配置し、過去の調査結果を参照できるようにしたり
- AIがログ・メトリクスを閲覧して、エラー探知から修正を行うループを回せるようにしたり
ハーネスエンジニアリングの出来によりAI利用による生産性は大きく変わるのを、最近は実感している。
ハーネスエンジニアリングは、データエンジニアリングの領域を労働集約から資本集約の構造へ変えるポテンシャルがある。
-
（外部からのイメージに反して）データエンジニアリングの仕事は実に労働集約的だ。
-
例：
- 既存のSQLで変な箇所を調査する→労働集約的だ
- dbtで書かれたSQLを変更する→労働集約的だ。コンパイルが通るのを確認し、SQLFluffが通るのを確認し、データ上の変更をチェックする。
- BIに記述された指標定義を確認し、変な箇所がないかを確認する→労働集約だ。個々の作業に高い技量はいらない
- 人間からの問い合わせを理解可能な言語に落とし込む→あまりにも労働集約的だ。人間が言語を習得するより、AIが言語を習得する方が早かったのは、人間の知能の限界を示す良い例だろう
上にあげた操作の一つ一つはAIにより代替可能である。従って、複合的な動作もAIにより代替可能である。
AIに対する環境の整備は資本の蓄積だ。一度整備した権限はずっと使えるし、Agent Skillが忘れられることはないし、人間と相性が悪いから使えなくなるわけでもない。資本を蓄積し、労働集約故のコストを乗り越えたいと思い、最近はハーネスエンジニアリングに取り組んできた。
一度振り返り、知見を書き留めておきたい。
2つの方向性
「ハーネスエンジニアリング」の概念は未成熟だ。しかしデータエンジニアリングの分野に絞れば、ハーネスエンジニアリングの方向性は大きく2つに分けられる：
- 縦方向のハーネスエンジニアリング：AIが活用できるデータの流れの範囲を増やす
- 横方向のハーネスエンジニアリング: データから恩恵を受けられる人間の数を増やす
詳細を書いていく。
縦方向のハーネスエンジニアリング
データが従うライフサイクルは、ざっくり言えば以下のような流れになる。
データの発生 → データの保管 → 加工 → 集計 → 表示
この流れのうち、AIが把握できる「流れ」の範囲を拡大するのが「縦方向」だ。
- プロダクションのコードに対するアクセスを行うことで、データ収集を行うロジックにアクセスできるようになる
- BigQuery MCP Serverなど、DWHへの直接アクセスをする
- dbt MCP Serverで変換ロジックをAIが辿れるようにする
dbtやBigQuery、あるいはTableauなどは、公式・非公式を問わず公式のMCPサーバーやAgent Skillが存在していて、権限上の懸念を解消できれば簡単に実現できる。Looker Studioなど、CLIどころかAPIが存在しないBIは面倒だが、Playwrightなどのブラウザ操作系のツールを使って、BIの画面を探索させ、データソースや指標の定義をメモとして書き出す方法がある。
縦方向のポイントは、データソースから最終的なBIまでの全体の流れをAIが一貫して辿れる状態を作ることだ。個別のMCPサーバーやAgent Skillを繋ぎ合わせ、複合的な動作を構築する。環境が整備できれば、ミーティング中に指摘された指標のずれについてその場で対話的に解決！のようなこともできるようになる（なった）。
横方向のハーネスエンジニアリング
データに関する知識をスケールアウトさせ、恩恵を受けられる人の数を増やすのが「横方向」だ。プロダクト方面のエンジニアリングとは異なり、非エンジニアに対して影響を発揮できるデータエンジニアリング分野特有の方向性になる。
まだ取り組みが浅く、知見が溜まっていないが、方向性だけ書いておく
- BtoB SaaSの場合、顧客に導入効果を出す必要がある。顧客と実際に向き合っている営業やカスタマーサクセスは、指標の定義を理解し、効果改善のサイクルを回す必要がある。彼らに向けた知識の提供経路としてAIを使うことはできる。エンタープライズサーチと接続し、データの知識を提供する
- PdMや他のエンジニアなど事実に基づく意思決定のサイクルを回す
- Devinなどを使い、Claude Codeなどローカルでの環境構築が必要な形態から脱する
おわりに
AIによるトレンドは確定的だ。「AI時代にエンジニアは生き残れるか？」などの転職サイト運営業者が好きそうな浅い議論をする意味はない。重要なのは、実際に仕事に取り組んでいる人間が、「AIがやるのと人間がやるのと、どちらがマシか？」を問いかけることだ。コメンテーターがあなたの仕事をなんとかしてくれるわけはない。
目の前の仕事を改善するのは、その仕事に取り組んでいる人間がやるのが一番確実だ。
*1:https://openai.com/index/harness-engineering-leveraging-codex-in-an-agent-first-world