## 1. 背景と根本的な課題：なぜ現在のAIシステムは「脆い」のか

現在のAIアプリケーション開発（特にRAG）は、データエンジニアリングの視点から見ると**「設計の空白地帯」**にあります。

### A. チャンク分断による「文脈の不可逆な喪失」

従来のRAGは、ドキュメントを数百トークン単位の「チャンク（断片）」に分断します。これは「本を一ページずつシュレッダーにかけ、質問に関係ありそうな紙屑だけをAIに渡す」ようなものです。

* **「木を見て森を見ず」問題:** 個別の事実（木）は拾えても、ドキュメント全体の要旨、データの時間的推移、複数のデータ間にまたがる相関関係（森）を捉えることが構造的に不可能です。
* **セマンティック・ノイズ:** ベクトル検索は「意味の近さ」で抽出しますが、これは「理解」ではありません。似たような言葉が並んでいるだけの無関係な断片が混入し、AIの推論を狂わせるノイズとなります。

### B. オンデマンド加工の限界と「推論リソースの浪費」

「データを取り出してから、プロンプトの中でAIに整形させる」という現在の主流（Compute on Read）には無理があります。

* **不安定な出力:** 実行時のプロンプトで整形を強いると、AIの機嫌やコンテキストの長さに依存して出力形式がブレます。これはシステムとしての安定性を著しく損ないます。
* **トークンの無駄遣い:** 構造化されていない生の断片を大量に流し込むことで、コンテキストウィンドウが埋まり、肝心の「思考（推論）」に使えるリソースが削られています。

### C. 実装とデータの「密結合」による開発硬直化

現在は、AIにどうデータを渡すかのロジック（チャンクサイズ、プロンプトでの整形指示など）が、アプリケーションのコードベースの至る所にハードコードされています。

* **イテレーションの鈍化:** 「AIの回答が悪い」と感じたとき、コード、プロンプト、データストアのどこを直すべきかが不明瞭であり、一箇所の修正がシステム全体に予期せぬ影響を及ぼします。
* **「AI用ビュー」の不在:** プログラムにはSQLビューがあるように、AIにも「AIが最も理解しやすい形」に事前加工された専用のデータソースが必要であるにもかかわらず、その中間層が存在しません。

---

## 2. 実現したいコア・コンセプト：AIのための「マテリアライズド・ビュー」

このプロジェクトが目指すのは、AIをアプリケーションの「おまけ」としてではなく、**「第一級のデータ消費者」**として再定義するアーキテクチャです。

### A. 「Compute on Write（事前計算）」へのパラダイムシフト

AIへのデータ提供を、実行時の「検索」から、事前ビルドによる「提供」へと転換します。

* **AI専用ビューの永続化:** Raw Dataから「AIが最も読みやすい構造（例：階層化されたMarkdown、推論済みの要約、関係性を記述したグラフ）」を事前に構築し、Context DBに格納しておきます。
* **レンダリング済みコンテキスト:** AIからの要求に対し、DBは「加工済みテキスト」を返すだけで済みます。これにより、回答の安定性とレスポンス速度を劇的に向上させます。

### B. 「Builder（変換ロジック）」によるデータエンジニアリングの独立

「どうやってAIに理解させるか」という知見を、Builder層のコードに集約・カプセル化します。

* **ロジックのイテレーション:** 開発者が改善したいのは、プロンプトではなく「データの変換ルール」です。Builderを修正し、Context DBをリビルドするだけで、AIの知識構造をアップデートできる環境を構築します。
* **内部構造の抽象化:** 裏側でベクトルDBを使おうが、グラフDBを使おうが、あるいは単なるMarkdownファイルの集合体であろうが、Interface層からは隠蔽されます。

### C. 疎結合な「マルチ・インターフェース」の提供

Context DBへのアクセスを標準化し、AIが「道具（Tool）」としてデータを扱えるようにします。

* **サーバーレスCLIからMCPまで:** ローカルでの stdin / CLI 引数ベース動作を基本としつつ、同じDBをAPIやMCPサーバーとして即座に公開可能にします。
* **ポータビリティと再現性:** SQLite等の軽量なデータ基盤を採用し、「データと変換ロジックさえあれば、どこでも同じAIのコンテキストが再現できる」状態を実現します。
