第1章：データエージェントの設計 ― 正しさとサイズの分離
―「意味的に正しいデータ」は、エージェントに渡すには大きすぎる
1.1 既存アーキテクチャ ― Medallion Architecture と Gold レイヤー
データレイクの標準設計である Medallion Architecture は、データを三層で管理する：
- Bronze — 生データ。外部から取り込んだまま、変換なし
- Silver — クレンジング・正規化済み。形式は整っているが意味は未整理
- Gold — ビジネス意味が付与された最終レイヤー。「何が正しいか」が確定している
Gold レイヤーはデータの意味的正しさの終着点として機能する。どのテーブルを結合すれば「売上」なのか、どのフラグが「有効な顧客」を意味するのか——そうした解釈のゆらぎを吸収し終えた場所が Gold である。ここまでが既存の標準であり、これ自体に不備はない。
1.2 それでも生じる問題 ― データエージェントはなぜ実行不能になるか
ここで扱うデータエージェントとは、ユーザーの自然言語の問い（「先月の有効顧客の売上は？」等）を受け取り、それを SQL クエリへと解釈・生成し、データレイクに対して実行し、結果を人間可読な答えとして返す LLM ベースの存在を指す。エージェント自身は Gold の中身を書き換えない——読んで、問いに応じて絞り込み、答える。この「解釈して問い合わせて答える」というループそのものが、以下で述べる実行不能の影響を直接受ける。
Gold が正しくても、エージェントは SQL クエリの性質によって実行不能になる。理由は複数ある：
- 行数の爆発 — 結合やフルスキャンを含むクエリが巨大な結果セットを返す
- コンテキスト超過 — トークン上限を超えた時点でパイプライン全体が止まる
- ページングの欠如 — 集約や絞り込みなしにデータをそのまま返すクエリ設計
- （症状として）サイレント切り詰め — エラーが出ず「成功」が返るが、データは途中で切られている
最後の「サイレント切り詰め」は、他の3つと性質が異なる。行数の爆発やコンテキスト超過は失敗として観測できる。しかしサイレント切り詰めは失敗として観測されない——切り詰められて消えた部分は、もはや何とも相互作用しない。存在の公理（本シリーズが依拠する Core 第1章）に照らせば、これは「無だけが非システムである」という条件に該当する状態そのものだ。消えた行・消えた列は無であり、無であるにもかかわらず、応答は「成功」という観測可能な秩序を装って返ってくる。無が存在を僭称している——これがサイレント切り詰めの正体であり、単なるバグではなく、この章が取り組む中心的な病理である。
「どの SQL を投げるか」によって実行可否が変わる。データ層の正しさとは独立した問題である。
1.3 新アーキテクチャ ― Platinum：正しさとサイズの分離
1.3.1 核心命題 ― 正しさとサイズを、別の関心として分離する
先に要点だけ述べておく。Platinum とは、エージェントと Gold の間に問いのたびに一時的に開く実行時ウィンドウであり、正確な定義は次項 1.3.2 で行う。ここではまず、なぜこの分離が必要なのかを述べる。
意味的に正しい Gold レイヤーは、エージェントのコンテキストに対して大きすぎる。
実務に近い比較として、SQL の一時テーブル（temp table）がある。セッション終了時に自動的に破棄され、他セッションから見えないという点では Platinum と同じ性質を持つ。しかし temp table は開発者が CREATE TEMP TABLE として明示的に作成し、スキーマも用途ごとに人手で設計するのに対し、Platinum は問いが来るたびにエージェントの解釈から自動的に生成され、スキーマも 1.3.3 の階段に従って毎回組み立て直される。永続化しないという性質は共通だが、生成の主体と頻度が違う——temp table は「人が都度作る道具」であるのに対し、Platinum は「問いのたびにエージェントが自動的に開閉する窓」である。
Core 第3章からの読み Gold は粒子的自己（境界が確定し、恒常性を保ち、「何が正しいか」を防御する）、Platinum は波動的自己（一つの問いのために立ち上がり、問いかけに応じて形を変え、答えが出れば消える）にあたる。粒子が支配すれば秩序は硬化し、波動が支配すれば境界が崩壊する。動的平衡はどちらか一方に宿るのではなく、Gold と Platinum が振動しながら共存し続けることで保たれる系全体の状態である。Platinum の寿命を統治することは、その平衡を保つための温度制御にあたる。以降の 1.3.2（恒常性と流動の対比）と 1.3.6（寿命の統治）は、この読みを実務の語彙で展開したものである。
1.3.2 Platinum は Gold の「実行時ウィンドウ」である
Platinum を永続層にしない。一つの問いのために開き、答えが出たら閉じる一時的な投影として設計する。
データエージェントの視点で見ると、これは次のループになる：(1) 自然言語の問いを受け取る、(2) 問いの意図を解釈し、1.3.3 のスリム化の階段に従って Gold から絞り込むクエリを組み立てる、(3) そのクエリを Platinum として実行し、有限で応答可能なサイズの結果を得る、(4) 結果を読んで人間可読な答えを返す、(5) ウィンドウを閉じる。エージェントが直接触れるのは常に (3) の Platinum であり、Gold そのものではない——エージェントにとって Gold は「Platinum を通してしか見えない」層になる。
Gold が「恒常性」を体現するのに対し、Platinum は「流動」を体現する——この対比が、次に述べる具体的な縮小手順（スリム化の階段）の設計原理になる。
1.3.3 スリム化の階段
Platinum という実行時ウィンドウを実際に開くとき、何をどの順番で削るかには階段がある。意味損失の少ない順に削る：
- 行を絞る（無損失） — 問いに関係する行だけに絞る。情報は減らない。
- 列を絞る（無損失） — 問いに関係する列だけに絞る。情報は減らない。
- 加算集約で畳む（条件付き安全、Kimball 分類） — SUM・COUNT のように可逆性のある集約軸で畳む。畳んだ粒度は失うが、値そのものは歪まない。
- 密度・精度を落とす（最後の手段、宣言必須） — サンプリングや丸めなど、値そのものが変わる操作。必ず「何を、どれだけ落としたか」を宣言する。
「分割して処理する」（クエリを複数回に分けて投げる）は、総量そのものを減らさないためこの階段には入らない。あくまで一つの応答に収まるサイズへと絞り込む手順である。
この階段は、1.2 で挙げた実行不能の理由それぞれに対応している：
| 1.2 の実行不能要因 | 対応する階段のステップ |
|---|---|
| 行数の爆発 | ①行を絞る |
| コンテキスト超過 | ①②③（絞ってなお超える場合は③まで） |
| ページングの欠如 | 階段そのものがページングに代わる設計原理になる |
| サイレント切り詰め | ④のみが切り詰めを許容するが、必ず宣言を伴う。宣言のない切り詰めは、階段のどのステップにも属さない不正な状態であり、1.2 で述べた「無の僭称」に該当する |
言い換えれば、Platinum の設計とは「①〜③で足りるか、④まで必要か」を問いごとに判定し、④を使うときは必ず宣言する仕組みそのものである。宣言があるかないかが、正当な精度低下とサイレント切り詰めを分ける唯一の境界線になる。
この階段を降りるのは、Gold でも Platinum でもなく、データエージェント自身である。「先月の有効顧客の売上は？」という問いを受け取ったエージェントは、まず①有効顧客テーブルと当該月の期間で行を絞り、②売上額・顧客ID・日付以外の列を落とし、③顧客単位ではなく月単位の SUM に畳む——ここまでで応答可能なサイズに収まれば、エージェントは④に進まず答えを返す。収まらなければ、初めて④のサンプリングや丸めを検討し、その旨を応答に明記する。どの段で止まったかはクエリごとに変わり、それを都度判定するのがエージェントの仕事であって、階段そのものは判定手順を用意するだけである。
1.3.4 非決定性を一点に封じ込める
意図の解釈（LLM が「何を知りたいか」を汲み取る部分）は本質的に非決定的である。同じ問いを二度投げても、解釈がわずかに揺れることがある。これに対し、窓を開ける処理（1.3.3 の階段を実際にテンプレート化されたクエリへ落とす部分）は決定論的にする。
この対比は、非決定性を「どこに置くか」の設計問題として捉え直すと分かりやすい。非決定性そのものを消すことはできない——意図の解釈は本質的に揺らぐ。だからそれを消そうとするのではなく、影響範囲を一点（意図解釈のレイヤー）に封じ込め、その外側（クエリの生成・実行）を決定論的な操作の連鎖として固定する。探索が非決定でも、元データ（Gold）は無事に保たれる。仮に意図解釈が誤っていても、誤りは「間違った問いに正しく答えてしまった」という形で現れ、「データが静かに壊れる」という形では現れない。この違いが、次節以降の zero sync・短命設計と組み合わさって、Platinum 全体の安全性を支える。
エージェントの内部で起きていることとして述べ直すと、「有効顧客」を先月解約者まで含むか、「売上」を返金前か後かで解釈する部分——ここだけが同じ問いに対して揺れる余地を持つ。一方、解釈が確定した後にその解釈をテンプレート化された SQL へ落とし、Platinum として実行する部分には揺れが入り込まない。エージェントが毎回「新しく考え直す」のは意図の理解までであり、そこから先は決まった手順をなぞるだけになる。
1.3.5 zero sync ― 同期しないから壊れない
Platinum は Gold を読むだけで書き戻さない。同期すべき相手が存在しないため、複数の問いが並行しても衝突しない。
ここで「Platinum は観測のみである」という言い方を、より正確に述べ直しておく。これは Gold と Platinum の間に完全な一方向遮断があるという意味ではない。両者の関係は、二つの有限性によって精密に境界づけられている。
- 範囲の有界性（bounded scope） — 一回の問いが触れる Gold の部分集合は、常に有限・限定されている。どの問いも、Gold の全域を無限定に見るわけではない。
- 時間の有界性（bounded duration） — Platinum が観測を続ける期間そのものが有限である。ウィンドウは開き、答えを返し、閉じる。
「観測のみ」とは、この二重の有限性のもとで一方向の読み取りが行われる、という意味であり、境界が存在しないという意味ではない。境界（有限性）があるからこそ、書き戻しがなくても衝突が起こらないという性質が成り立つ。
ただし、この観測には限界もある。ウィンドウを開いている間に Gold 自体が更新されれば、窓の中身はその瞬間から陳腐化する——これは 1.2 で定義したエージェントのループが必然的に抱える staleness であり、先に述べた時間の有界性（窓が短命であること）が、その陳腐化の影響を有界に留めている。次節で述べる寿命の統治は、この陳腐化を避けられないものとして引き受けたうえで、窓をどれだけ生かすかを決める営みである。
1.3.6 短命であることの意味
短命だから元データが汚染されない。短命だから「この窓は今この問いのための窓」という意味が時間が経っても保たれる。
ただし「短命」は無条件に良いわけではない。寿命には統治機構が要る。
- 短すぎる寿命 — 答えが出る前にウィンドウが閉じてしまい、探索そのものが凍結する。Platinum が担うべき流動（探索を続けるための可変性）そのものが失われた状態である。
- 長すぎる寿命 — ウィンドウが閉じずに居座り続け、事実上の第二の Gold として硬化する。一時的な投影であるはずのものが恒常的な層に転じる倒錯であり、1.3.2 で述べた「Platinum を永続層にしない」という設計原則そのものへの違反になる。
したがって寿命は、固定の TTL のような一律の値ではなく、その問いのライフサイクル（セッション・タスクの境界）に紐づけて宣言されるべきものであり、かつ「宣言された寿命を超えて生き続けていないか」を外形的に監視できる必要がある。寿命の統治とは、短すぎず長すぎない一点を探し続ける運用そのものであり、Core 第3章のカオスの淵——最も創発的な温度——を、データ層の時間軸に置き換えたものだと言える。
1.3.7 選択基準のサイレント化という新しい失敗モード
ここまでの設計は、「データそのもの」が静かに失われる失敗（サイレント切り詰め）を防ぐことに焦点を当ててきた。しかし、Platinum の導入はもう一つの、より捉えにくい失敗モードを生む可能性がある——何を残し何を落とすかという選択基準そのものが誤っていて、しかもその誤りが静かに埋没するというケースである。1.3.3 の階段を正しく踏み、④で宣言までしていても、そもそも「どの行を残すべきか」「どの粒度に集約すべきか」という判断が問いの意図とずれていれば、返ってくる応答は「宣言通りに縮小された、しかし的外れなデータ」になる。これはデータの欠落ではなく判断の欠落であり、1.3.3 の宣言メカニズムはこの種の誤りを検出できない。
この章はこの失敗モードの解決までは扱わない。ただし、範囲外として無視してよい問題だとも考えていない。最低限の要請として、選択基準（何を残すか、どの集約軸を使ったか）を宣言と同じ扱いで応答に付随させ、後から検証・監査できる状態にしておくこと——透明性の仕組みとして選択基準を「見える化」しておくことだけは、この章の設計原則の延長として明記しておく。基準そのものの正しさをどう保証するかは、後続の章に委ねる。
先の例で言えば、エージェントが「有効顧客」を解約者除外で解釈したなら、その解釈をデータそのものとは別に「有効顧客＝解約日が期間内に存在しない顧客」として答えに添える。人間はこの一文を読んで初めて、階段の縮小が正しく行われたかとは別に、そもそも入口の解釈が問いに合っていたかを確認できる。
この章のまとめ
- 既存アーキ: Medallion Architecture の Bronze→Silver→Gold は意味的正しさの積み上げ
- 問題: Gold が正しくても、SQL クエリの性質でエージェントは実行不能になる。中でもサイレント切り詰めは、無が存在を僭称する形で「成功」を装う点で他の要因と質が異なる
- 新アーキ: Platinum = Gold の実行時ウィンドウ。恒常性（Gold）と流動（Platinum）の分離として、正しさとサイズを別の関心に切り分ける
- スリム化の階段: 行→列→集約→精度低下の順で、1.2 の各失敗要因に対応する形で縮小する。宣言のない縮小はどのステップにも属さない不正な状態である
- 非決定性の封じ込め: 意図解釈（非決定）と窓の生成・実行（決定論的）を明確に分離する。この対比があるからこそ、探索が揺れても Gold は無事に保たれ、誤りは「間違った問いへの正答」として現れ「データの静かな破損」としては現れない
- zero sync: 同期しないから壊れない。「観測のみ」は完全な一方向遮断ではなく、範囲の有界性と時間の有界性という二重の有界性のもとでの一方向読み取りである
- 短命であることの意味: 短すぎれば探索が凍結し、長すぎれば第二の Gold として硬化する。寿命は問いのライフサイクルに紐づけて宣言し、外形的に監視できる状態を保つ
- 残された課題: 選択基準そのものの誤りがサイレント化する失敗モードは、この章では解決せず、透明性の仕組み（選択基準の見える化）として最低限の要請だけを示す
関連シリーズ
- AIエージェント設計概論 第6章：レポート化アーキテクチャ — データ分析の出力設計との対比
- AIエージェント設計概論 第7章：エージェントの安定性設計 — Platinum の安定性設計との接続
Last Updated: 2026-09-20