8月27日、Thoughtworksのプリンシパルデータエンジニアらが「Making Your Data Ready for Agentic AI」と題した記事を公開した。AIエージェントが信頼して活用できるデータ基盤を設計するために何が必要かを、具体的なアーキテクチャパターンとコード例を交えて論じている。

人間向けデータ設計の限界

30年以上、データシステムは「人間が画面の前に座って使う」前提で作られてきた。ダッシュボード、レポート、アナリストクエリ——すべてに共通するのは、人間が持つ「暗黙知」への依存だ。

熟練したアナリストは「revenue」が自社のコンテキストで何を指すかを知っている。数字が怪しければ立ち止まり、ダブルチェックする。休日に落ちる売上を異常値と見なさず、文脈で判断できる。

AIエージェントにはこれが一切ない。 人間が「なんかおかしい」と感じて手を止めるところを、エージェントは確信をもって誤った値に基づき行動する。この「失敗モードの違い」が本記事全体の核心だ。

最大の問題：エージェントは悪いデータを嗅ぎ分けられない

記事が最も力を入れて論じているのが、データ品質とデータコントラクトの重要性だ。

具体的なシナリオで考えるとわかりやすい。価格エージェントが商品Xの価格を問われる。実際には$49.99から$59.99に更新済みだが、エージェントのデータソースはまだ古い値を返す。エージェントは$49.99を顧客に提示し、顧客は購入する。会社は1件あたり$10を失う。エージェントのワークフローは完璧に動いていた。問題はデータだ。

人間の営業なら「先週更新しなかったっけ?」と立ち止まる。エージェントは立ち止まらない。

この問題の規模感を示すデータとして、記事はPreciselyとDrexel大学LeBow経営大学院による505名のデータ・分析リーダーを対象とした調査（2026年State of Data Integrity and AI Readiness）を引用している。それによれば、87%が「自社データはAI対応済み」と自信を持つ一方、43%が「データの準備不足が最大の障壁」と回答している。 自信と実態のギャップそのものが、組織規模の「価格エージェント問題」だ。

データコントラクトをコードとして書く

この問題への処方箋がデータコントラクト——スキーマを「お作法」ではなく「法律」として扱う設計思想だ。

Open Data Contract StandardとData Contract CLI（Thoughtworks Tech Radar 33でも推奨）を使えば、以下のような制約をYAMLで明示できる。

apiVersion: v3.1.0
kind: DataContract
id: product-pricing
name: Product Pricing
version: 1.0.0
status: active
schema:
  - name: product_pricing
    physicalType: table
    properties:
      - name: price
        logicalType: number
        physicalType: decimal
        required: true
        quality:
          - type: sql
            description: Every price must be greater than zero
            query: SELECT min({property}) FROM {object}
            mustBeGreaterThan: 0
      - name: currency
        logicalType: string
        physicalType: varchar(3)
        required: true
        quality:
          - type: sql
            description: Currency must be a supported ISO code
            query: SELECT count(*) FROM {object} WHERE {property} NOT IN ('USD', 'EUR', 'GBP')
            mustBe: 0
      - name: ingested_at
        logicalType: timestamp
        physicalType: timestamp
        required: true
slaProperties:
  - property: latency
    value: 24
    unit: h
    element: product_pricing.ingested_at

重要なのは末尾のslaPropertiesだ。「直近24時間以内にリフレッシュされていなければコントラクト違反」と定義することで、先の価格シナリオをアーキテクチャのレベルで防止できる。エージェントが古いデータを見る前に、そのデータ自体が弾かれる。

コントラクトの検証は3軸で行う：

• スキーマ強制：型・制約の明示的な検証
• フレッシュネスSLA：データセットごとに許容される最大陳腐化時間を定義。バッチ更新では不十分なケースに対処
• 品質ゲート：CI/CDでコントラクトを検証し、違反時はデプロイをブロック

違反データはエージェントに見せない：検疫パターン

コントラクトを定義しても、違反データは必ず発生する。その対処が検疫パターン（Quarantine Pattern）だ。

生データはまずバリデーションゲートを通過する。スキーマ・フレッシュネスSLA・品質ルールの3つすべてをパスしたデータだけが「認定済み・エージェント対応」ストアに流れ込む。1つでも失敗したデータはデッドレターキューに隔離され、アラートが発火し、人間がレビューする。

エージェントは悪いデータを決して目にしない。 先の価格シナリオでは、ingested_atが24時間を超えた時点でレコードが検疫され、エージェントは「現在の価格データがありません」と返す。誤った数字を自信満々に返すよりはるかにマシな失敗モードだ。

この仕事はモデルではなくデータアーキテクチャの責務だ。より良いモデルは、悪いデータからあなたを救わない。

メダリオンアーキテクチャにエージェント専用層を追加する

Databricksが普及させたメダリオンアーキテクチャ（Bronze→Silver→Gold）をエージェント向けに拡張する提案も興味深い。

• Bronze：生データをそのまま保存（監査・リネージュ用）
• Silver：スキーマ適用・重複排除・コントラクト検証（検疫パターンが機能する層）
• Gold：認定済み。セマンティックモデルが参照し、アクセスが統制される

記事はここに第4層「Adaptive Gold」を追加することを提案する。エージェントが自身のクエリパターンを監視し、頻繁にアクセスされるデータの組み合わせを特定して最適化されたデータセットを自動で生成する層だ。エージェントが受動的な消費者から能動的なデータキュレーターになる。

Figure 1: データはBronze→Silver→Gold→Adaptive Goldと流れ、エージェントはGold以上のみアクセスできる

エージェントが見ていいのはGold以上だけ。 BronzeとSilverはリネージュ・デバッグ・人間調査用であり、エージェントに生データや部分検証済みデータを渡すことは「価格問題の再招待」に等しい。

AI対応データの5条件

記事は、エージェントに渡すデータが満たすべき属性を5つに整理している。

1つでも欠ければ、エージェントは人間のように「緩やかに劣化」しない。確信をもって失敗する。

詳細はMaking Your Data Ready for Agentic AIを参照していただきたい。