7月19日、Toward Data Scienceが「Many Companies Use AI. Few Know How to Build an AI-Native Enterprise Data Platform.」と題した記事を公開した。この記事では、AIをアドオンとして扱うのではなく、データプラットフォームのアーキテクチャ自体をAIネイティブに再設計するための実践的な考え方について詳しく紹介されている。以下に、その内容を紹介する。

チャットボットとAIエージェントは根本的に違う

多くの企業がAIをすでに業務に取り入れている。社内チャットボット、CopilotやChatGPTによる文書要約、コード補助──これらは個人の生産性を確実に改善する。しかし、記事はそこで止まっている企業に警鐘を鳴らす。AIの最も重要な活用領域はエンタープライズデータエコシステムの変革にある、というのが著者の主張だ。

その中核を担うのがデータエージェントだ。従来のチャットボットが「会話で回答する」だけなのに対し、AIエージェントは自律的に環境を認識し、判断し、具体的なアクションを実行する。

例えばECプラットフォームのデータアナリストが「東南アジアで先四半期に最も売上に貢献したカテゴリは何か？」という質問を受けた場合、従来は：

業務質問 → SQL記述 → データ出力 → グラフ作成 → 説明

これをデータエージェントに委ねると：

業務質問 → セマンティック情報の取得 → SQL生成・実行 → 結果の説明

ユーザーには「AIと会話しているだけ」に見えるが、裏側ではエージェントが文脈の取得、SQL生成・実行、結果解釈、回答生成という一連のアクションを自律的にこなしている。

主要データプラットフォームもデータエージェントを統合済みだ。Microsoft FabricのFabric data agent、SnowflakeのCortex Analyst、DatabricksのAI/BI Genieが代表例として挙げられている。特定プラットフォームに縛られたくない場合は、Julius AIやTelliusのように主要プラットフォームに横断接続できるツールも選択肢になる。

データエージェント単体では限界がある

ただし、記事はデータエージェントを過信することに強く警告する。実運用でよく起きる問題として以下が列挙されている：

• 曖昧なビジネス用語の解釈
• 複数ステップにまたがる推論
• ビジネスルールの適用
• 同じ質問への回答の不一致
• データスキーマ変更への追随
• 異なるビジネスコンテキストにまたがる精度の維持

AIが間違えると、ユーザーが不満を持つだけでなく、誤った情報がビジネス意思決定に流れ込む。これが最大のリスクだ。

この問題意識から、記事はデータプラットフォームのアーキテクチャ自体を再設計することを提案する。AIをアドオンとして後付けするのではなく、データエージェント、AI QAエージェント、AIガバナンス＆オブザーバビリティの3要素を最初からアーキテクチャに組み込む必要があるという考え方だ。

AIによるデータ品質保証：ルールベースの「次の層」

記事で最も実践的なパートの一つが、AI活用によるデータQAの刷新だ。

医療系企業を例に取る。毎日数百万件の患者記録（検査結果、保険請求、処方ログ等）を処理する環境では、NULLチェック、重複検出、スキーマ検証、参照整合性など多数の品質チェックが必要になる。従来のルールベースQAは「あらかじめ想定した障害しか検知できない」という根本的な限界を抱えている。

AIを組み込んだQAはこのルールベースを置き換えるのではなく、「学習する層」を追加する。過去のパターンから「正常な状態」を学習し、事前定義されていない異常──分布のずれ、フィールド間の異常な相関、パイプライン上流の問題を示すデータドリフト──を検出する。

具体例として挙げられているのが、特定クリニックの検査値が過去平均の10倍に跳ね上がるケースだ。従来のQAはフォーマット・値域・NULL・重複のいずれにも問題がないため「パス」を返す。しかし、AIは「そのクリニックがこれまで出してきた値と違う」という文脈から異常をフラグする。

記事ではSodaを使ったルールベースとAI異常検出の組み合わせのコードサンプルも掲載されている：

from soda.scan import Scan
from soda.contracts.contract import Contract
from soda.contracts.check import AnomalyCheck, SchemaCheck, UserDefinedCheck

# 従来のルールベースチェック
traditional_contract = Contract(
    checks=[
        SchemaCheck(
            name="Schema validation",
            fail_if_missing_columns=["patient_id", "diagnosis_code", "lab_result"]
        ),
        UserDefinedCheck(
            name="No duplicate patient records per day",
            query="""
                SELECT patient_id, admission_date, COUNT(*)
                FROM patient_records
                GROUP BY patient_id, admission_date
                HAVING COUNT(*) > 1
            """,
            fail_if_rows_returned=True
        )
    ]
)

# AI異常検出チェック
ai_contract = Contract(
    checks=[
        AnomalyCheck(
            name="Anomaly: lab result distribution shift",
            metric="mean(lab_result)",
            anomaly_detection="ml",
            sensitivity=0.8,
            fail_if_anomaly_severity="critical"
        ),
        AnomalyCheck(
            name="Anomaly: record volume by source",
            metric="row_count",
            anomaly_detection="ml",
            group_by=["data_source"],
            fail_if_anomaly_severity="critical"
        )
    ]
)

他のツールとしてGreat Expectations（主にルールベース、カスタム拡張で異常検出も可）、Databricks Lakehouse Monitoring（ネイティブなプロファイリングとドリフト検出）、AWS Glue Data Quality（自動ルール推薦と異常検出）も紹介されている。

AIガバナンスは「セキュリティ」だけではない

記事のもう一つの重要な主張がAIガバナンスの再定義だ。多くの人はガバナンスをロールベースアクセスやデータマスキングだと捉えている。しかし記事は、AIがシステムに深く統合された後の真のガバナンス課題をこう定義する：「AIが出した答えをすべて説明し、責任を持てるか？」

投資会社のポートフォリオマネージャーが「先四半期にESG目標を超えたファンドはどれか？」と質問し、1か月後に同じ質問をしたら別の答えが返ってきた──クエリも変えていない、データも変えていない、にもかかわらず。これがAIガバナンスが必要な理由だ。

記事が挙げるAIガバナンスの具体的な要素はプロンプトのバージョン管理（ソフトウェアのリリース管理と同様にGitで管理し、どのバージョンがいつ動いていたかを記録する）、そして回答の品質測定と説明可能性の確保だ。

アーキテクチャの再設計という視点

記事全体を通じた主張は明確だ。従来のデータプラットフォームは「データを蓄積してレポートする」設計であり、AIと協調することを前提としていない。AIを後付けでアドオンするのではなく、データエージェント・AI QAエージェント・AIガバナンス＆オブザーバビリティを最初から組み込んだアーキテクチャ設計が必要だ、というのが著者の立場である。

一方で、AIがいかに高度になっても、その前提として人間のエンジニアが構築した信頼性とスケーラビリティを備えたデータ基盤が不可欠だという点も強調されている。AIはデータエンジニアリングを代替するのではなく、強化するものだという整理だ。

詳細はMany Companies Use AI. Few Know How to Build an AI-Native Enterprise Data Platform.を参照していただきたい。