AIに負けないスキル。データのエンジニアリング

データには関心が持てないAI

コーディングエージェントは、驚くほど強くなりました。ロジックを書き、APIを叩き、関数を切り、テストを生成し、リファクタまでこなす。「コードを書く」という作業は、急速にコモディティ化しています。

ところが、同じエージェントに実際の業務データを扱わせると、途端に頼りなくなります。答えられない問いが、山ほど出てくるのです。

• このデータは何を意味するのか
• 誰が作り、誰が責任を持つのか
• どの業務イベントから発生したのか
• どの粒度・鮮度・容量で流れているのか
• JOINしてよい正本（マスター）データなのか
• この異常値はバグなのか、業務上の例外なのか

原因は、LLMの仕組みそのものにあります。LLMは、コンテキストを渡されて初めて動く受け身の存在です。渡された枠の外にある現実——目の前のデータベースが今どんな状態か、この値がどの業務から来たのか、鮮度は落ちていないか——に、自分から関心を持ちようがありません。聞かれたことには答えても、聞かれていない現実を自発的に確かめにはいきません。これは「やる気がない」という意志の問題ではありません。仕組みとして、目の前のデータやデータベースシステムという「現実」を気にすることができないのです。

近年のデータエンジニアリング向けAIエージェントの議論でも、正確な処理には metadata・lineage・context layer が前提であり、LLM単体では足りないと繰り返し指摘されています（Atlan: AI Agents for Data Engineering）。

結論を先に言えば、AI時代に価値が上がるのは「コードを書く人」より、データの意味・品質・流れ・責任範囲を設計できる人です。

根っこにあるのは「AIに身体性がない」こと

この話の根っこには、以前のキャリアシリーズでも出発点に置いた「今のAIには身体性がない」という事実があります。

AIは、世界について書かれたテキストを大量に読んでいても、その世界を身体で生きたことはありません。現場での試行錯誤も、業務を回した経験も、責任をともなう判断も持っていない。

一方でデータは、抽象的な数字の羅列ではなく、現実の業務イベントが残した痕跡です。誰が、いつ、どの現場で、どんな意図で発生させたのか——その背後には、身体と経験に根ざした文脈が必ずあります。AIには、こうしたデータのライフサイクルというものに「実感」が持てないのです。

だから、身体性を持たないAIは、データの「意味・来歴・責任範囲」を本質的に持てません。値は読めても、その値が現実の何を指し、どこまで信じてよいのかは分からない。データ文脈とは、AIに欠けている「身体性」の領域そのものです。コードという抽象は書けても、現実に接地したデータは扱いきれない。この非対称が、以下で見る潮流の根っこにあります。

エージェントが強い領域、人間に残る領域

得意・不得意を並べると、境界がはっきりします。

コーディングエージェントが強い	人間に残る（データ文脈）
ロジック・関数・API	データの意味・定義
テスト・リファクタ	来歴（どこから来たか）
定型的な変換・整形	責任者・所有権・権限
アルゴリズム実装	粒度・鮮度・容量・流量
構文的な正しさ	正本か、JOINは妥当か

左側は「処理が構文的に正しいか」の世界。右側は「その処理が、現実のデータに対して正しいか」の世界です。前者はAIが肩代わりできますが、後者は現実の業務・組織・歴史を知らないと判断できません。

品質問題は「モデル問題」ではなく「コンテキスト問題」

ここで効いてくるのが、品質の捉え方の転換です。

LLMパイプラインで精度が出ないとき、つい「モデルが悪い」と考えがちです。しかしAtlanは、これをモデル問題ではなくコンテキスト問題として整理しています（Data Quality in LLMs: A Context Problem, Not a Model Problem）。見るべき品質は、上流と下流で分かれます。

• 上流（データ側）: accuracy / completeness / freshness / consistency / metadata completeness
• 下流（生成側）: groundedness / faithfulness / retrieval recall / hallucination rate

面白いのは、下流のハルシネーションの多くが、上流のメタデータや鮮度の欠落に起因することです。モデルをいくらチューニングしても、データ文脈層が貧しければ精度は頭打ちになる。ここを設計できる人が、そのままAIの成果を左右します。

いま伸びているのは「意味」を扱う領域

具体的に、どの領域が伸びているのか。最近の議論で繰り返し出てくるのは、次の6つです。

領域	何を見るか
Data Governance	データ所有者・品質・権限・規制・監査
Data Observability	パイプライン異常・鮮度・欠損・品質劣化
Semantic Layer	業務指標・用語・テーブルの意味対応
Knowledge Graph / Ontology	データ同士の概念関係
Data Product	データを利用者向けプロダクトとして設計
Data SRE	データ基盤の信頼性運用

どれも共通しているのは、「バイト列としてのデータ」ではなく「意味を持ったデータ」を扱う、という点です。

「意味」を扱う職種が強くなる

この流れで価値が上がるのは、アナリスト、ストラテジスト、Data Architect、Data Engineer、Analytics Engineer、Data Product Manager、Knowledge Engineer、Ontology Engineer、Enterprise Architect、Business / Systems Analyst——いずれも「意味」と「責任範囲」を扱う仕事です。

たとえば Data Product Manager は、もはや単なるダッシュボード管理者ではなく、価値・ガバナンス・AI連携・企業KPIに責任を持つ役割として語られ始めています（Data Product Managers sit in the boardrooms）。

そして企業AIでは、Semantic Layer が急速に重要になっています。異なるチームが「アクティブユーザー」や「顧客生涯価値（CLV）」を別々に定義していると、AIも人間も判断を誤る。だからメタデータ・定義・関係を統一する層が要る、という議論です（Alation: Build Data Products for AI）。指標の定義を握る人が、AIの答えの正しさを握るのです。

結局、どんな職能なのか

一言でいえば、Data Context Engineer / Semantic Data Architect / Data Product Strategist とでも呼ぶべき職能です。既存の職種で近いのは、この重なりでしょう。

Data Architect ＋ Analytics Engineer ＋ Knowledge Engineer ＋ Business Analyst

AI時代には、これらが「周辺職」ではなく、AIに現実のデータを正しく扱わせるための中核職能になります。私自身、統合データベースエンジン（Alopex DB）を作っていて痛感するのは、エンジンがどれだけ賢くなっても、「そのデータが何を意味し、誰の責任で、どの鮮度で流れるか」を設計するのは人間の仕事だ、ということです。

まとめ

• コーディングエージェントは「処理」は書けるが、「その処理が現実のデータに対して正しいか」は保証できない
• 精度の壁の多くは、モデルではなく データ文脈（メタデータ・来歴・鮮度・定義） の問題
• だから人間に残る中核は、データの意味・来歴・責任者・容量・鮮度・業務例外・指標定義・正本・品質劣化——つまり データを業務・意味・運用・戦略に接続する設計
• 職種でいえば、Data Architect × Analytics Engineer × Knowledge Engineer × Business Analyst の重なり
• 単なるDBエンジニアではない。AI時代に、むしろ価値が上がる領域です

コードを書く速さは、これからますますAIが引き受けていくはずです。そのぶん、人間が腰を据えて向き合う価値があるのは、データの意味と責任を設計する領域だと考えています。