「とりあえずRAG」が失敗する本当の理由：金融知識ゼロの個人がバフェット流DCF投資をAIでハックするためのドメイン特化データパイプライン設計

対象読者: RAGを実務（財務分析、論文処理、創作）に投入し、ハルシネーションや文脈破綻、「とりあえずRAG」の精度限界に悩んでいる実践派開発者 難易度: 中級 テーマ: ドメイン特化データ（高品質データ）パイプラインの設計

:::message この記事の要点 (TL;DR)

• 課題: 「とりあえずRAG」を繋ぐと、返答はそれらしくなるが数字が間違っている。意思決定に使えない。
• 原因: RAGの精度はチャンキングよりも前に、**「どの生データを、どう正規化して持っているか」**で決まる。PDF投げやスクレイピングで済ませたデータは、LLMに誤った仮定を植え付ける。
• 解決策: SEC EDGAR / EDINET の法定開示から正規化した財務数値をDuckDB/Parquetに蓄積する。汎用モデルを専門家に変貌させるのは、クリーンなドメイン特化データである。 :::

---

1. はじめに：RAGの精度は、チャンキングで決まらない

「RAGの精度はデータの前処理とチャンキングで決まる」——この言説は、半分正しく、半分誤りです。

正しいのは「前処理が重要」という点。誤りは、多くの人が「前処理」をチャンキング戦略や埋め込みモデルの選定だと思い込んでいる点です。

しかし実際には、その前に決着していることがあります。

あなたは、何をRAGの燃料として持っているのか。

PDFをそのまま放り込み、表をテキストに無理やり変換し、単位系を揃えず、期間定義を曖昧にしたままベクトルDBに突っ込む—— これをいくら精巧なチャンキングで飾っても、LLMは誤った仮定に基づいた回答を、自信たっぷりに生成します。

私は財務分析でこの問題に正面から衝突しました。

---

2. 実体験：金融知識ゼロの個人がDCF投資をAIで回そうとした

2.1 目的設定

私の興味は実に具体的でした。

金融の専門知識がない個人が、ウォーレン・バフェット流のDCF（Discounted Cash Flow）による本質的価値計算を、AIの助けを借りて回せるか。

DCFは「企業が将来生み出すキャッシュフローを割り引いて、現在の理論価値を出す」という手法です。 理屈は単純ですが、正確にやるには一次資料に基づく正確な数字が必要です。

2.2 「とりあえずRAG」の失敗

最初に取ったのは、ごく標準的なアプローチでした。

1. 決算短信や10-K（年次報告書）のPDFを貯める
2. テキストに抽出して、ベクトルDBに入れる
3. 「この企業のフリーキャッシュフローの推移は？」と聞く

結果は、散々でした。

• 単位の混乱: 百万ドルなのか億円なのか、抽出段階で失われる

• 期間定義の曖昧さ: 「FY2024」が会計年度なのか暦年なのか、企業ごとに違う

• 表の崩壊: 複雑な財務諸表をテキスト抽出すると、行列関係がめちゃくちゃになる

• 改訂の追跡不能: 修正後の報告書と元の報告書が区別できない

そして最も危険だったのは——LLMがこれらの欠陥に気づかず、堂々と間違った計算を提示することです。 ハルシネーションではなく、燃料が汚染されていたのです。

2.3 核心に気づいた

ここで気づきました。

「RAGの精度が頭打ちになるのは、検索が下手だからではない。正しい一次情報を持っていないからだ。」

チャンキングをどう弄っても、*間違った数字/ は間違った数字**のままです。 問題は検索アルゴリズムの層ではなく、その下のデータ資産の層にありました。

---

3. 解決策：ドメイン特化データパイプラインの構築

モデルを弄るのではなく、正しい特化データを冴えない形で積む——これが私の結論でした。

3.1 法定開示を正規化する

私が構築したのは、法定開示に基づく財務数値の正規化パイプラインです。

• 米国SEC EDGAR: 10-K / 10-Q のXBRLタグ付データ
• 日本EDINET: 有価証券報告書の構造化データ
• J-Quants: 株価・指標系

重要なのは、決算短信やサマリー記事をスクレイピングしないことです。 企業が法定義務として提出する、正規の構造化データを使います。 この選択により、元データの信頼性問題が根本から消えます。

生データ（法定開示・XBRL）
    │
    ▼  泥臭いクレンジングと正規化
    │  ・単位系の統一（百万円/百万ドルの正規化）
    │  ・期間定義の正規化（会計年度↔暦年マッピング）
    │  ・科目名のマッピング（企業ごとの呼称差を吸収）
    │  ・改訂・訂正の履歴管理
    ▼
DuckDB / Parquet の単一ファイルレイク
    │
    ▼  冪等に積む（再実行しても壊れない）

3.2 なぜ PostgreSQL クラスタを建てなかったか

ここで重要な設計判断があります。スケールを夢見なかったことです。

❌ 世間がやりがちな「足し算の暴走」:
   PostgreSQLクラスタ + FastAPI中継サーバー8個 + 外販SaaS機能 + 管理画面

✅ 私の選択:
   DuckDB + Apache Parquet（単一ファイルOLAP）
   「正しい特化データを冪等に積む」という単一責務に絞る
   Web外販をしないフェーズではサーバーもAPI層も置かない

DuckDBはシングルファイルのOLAPデータベースであり、Apache Parquetは列指向ストレージの標準です。 この2つのディファクトスタンダードに乗ることで、正しいデータを積むという本質的な作業に集中できました。 分析側はレイクを直接参照します。

3.3 同じ設計を論文データにも適用した

同じ設計思想を、arXivの論文データにも適用しました（strata）。

• 対象: arXiv 15.7万本の論文
• 処理: ノイズとなる数式重複を剥がし、LaTeXアノテーションを抽出
• 蓄積: DuckDB / Parquet のデータレイク

論文の場合も同じです。PDFからむりやりテキストを引くのではなく、 ソースのLaTeX構造を正しく抽出することが、質の高いRAG燃料になります。

---

4. なぜこのデータ資産が「最強」なのか

4.1 RAGの燃料として即座に機能する

クリーンなドメイン特化データがあれば、汎用モデルを即座に専門家に変貌させられます。

私の場合、正規化された財務数値レイクがあれば、

• 「この企業の過去5年の売上成長率と利益率の推移を計算して」
• 「同業他社と比較して、この企業のマージンはどう位置づけられる？」
• 「DCFに必要なFCFの推移を、改訂履歴を考慮して抽出して」

という問いに対し、専門家レベルの精度で答えられるようになります。 モデルをFTする必要はありません。正しいデータを渡すだけです。

4.2 将来FTの種にもなる

さらに重要なのは、このデータ資産が将来FTが必要になったときの種にもなるということです。

RAGで足りる場合はRAGで運用し、ある領域でFTが有利だと判明したら、 同じクリーンデータをFTデータセットとして使い回せます。 投資が無駄になりません。

逆に、汚いデータでFTしても、汚いモデルができるだけです。

4.3 モデルが変わっても資産は残る

そして最後に——これが最も重要な点です。

あなたが構築したドメイン特化データは、モデルのアップデートでは陳腐化しません。

ハイパースケーラーが新しいモデルを出しても、 財務レイクは財務レイクのまま、正しい数字のままです。 モデルを交換し、ハーネスだけを薄く維持すれば、システムは動き続けます。

---

5. 結論：「とりあえずRAG」をやめ、特化データを積め

RAGが実務で失敗する本当の理由は、あなたが正しい一次情報を持っていないからです。

チャンキング、埋め込みモデル、リランキング——これらはすべて、良い燃料があれば初めて意味を持つ最適化です。 汚い燃料に最先端の検索技術を適用しても、整理された間違いが返ってくるだけです。

巨大テックが数千億円を投じるAIモデル開発に、中途半端な規模のコストで消耗戦を挑むのは愚策である。

だからこそ、AIモデルを作るな。ハーネスとドメイン特化データを作れ。

金融知識ゼロの個人がバフェット流DCF投資をAIで回せるのは、 モデルが賢いからではありません。正規化された法定開示データという、クリーンな一次情報を持っているからです。

そのデータは、時代が変わっても価値が目減りしない、あなたの永続資産です。

---

6. 次に読むべきもの

• なぜファインチューニングは失敗するのか — モデル開発の消耗戦をやめるという判断
• 小説特化LLMのプリトレを断念した話 — 整合性監査ゲートの実装
• Architecture Showcase — strata / finance のデータパイプライン解剖
• Manifesto — 旗印の全文と2つの永続資産