毎日情報収集するAIシステムのフォルダ設計 ─ 「巨大化するMarkdown」問題の解決構造

もっちゅりん

投資テーマ（全固体電池・人型ロボット・AI データセンター・核融合・量子コンピュータ）の情報を毎日自動収集し、週次・月次でレポート化する。そんな長期リサーチシステムを設計したときの、最大の論点は意外にも「フォルダ構成」でした。

https://claude.ai/referral/NhRD9YalWQ?s=android
1週間のclaude code無料チケット
早い者勝ち３名まで

素朴な設計はすぐ破綻する

最初の構想は「テーマごとに 1 つの Markdown に毎日追記していく」でした。これはすぐ問題が見えます。

  • 数ヶ月で数千行〜数万行に膨張する

  • AI に読ませるたびに巨大ファイルを処理することになる（コンテキストとコストの無駄）

  • 人間も読めなくなる

かといって「結論だけ残して古い記録を消す」と、今度は「なぜその結論に至ったか」の歴史が消える。 全部残すと読めない、要約だけだと歴史が消える 。このジレンマの解決が設計の核心でした。

採用した構造：役割別の4層

最終的に採用したのは、ファイルの役割を分離する構造です。

theme_name/
  daily/        ← 毎日の生データ。全部残す（1日1ファイル）
  weekly/       ← 週次の集約レポート
  archive/      ← 古くなったdailyの退避先
  summary.md    ← 常に最新の結論だけ。コンパクトに保つ

  • daily には全データを残す（歴史の保存）

  • summary.md は「今の結論」だけを常に小さく保つ（AI と人間の常用参照先）

  • 週次処理が daily を要約して weekly に落とし、古い daily は archive へ

日常のAI処理は summary.md + 直近の daily だけを読めばよく、深掘りが必要なときだけ archive まで遡る。 「よく読むもの」と「たまに掘るもの」を物理的に分ける ことで、読み込みコストと歴史の保存が両立します。

この構造の汎用性

これは投資リサーチに限らず、「AI が毎日何かを蓄積するシステム」全般の基本形です。

  • 競合ウォッチ（競合サイト・競合チャンネルの変化記録）

  • 商品トレンドの定点観測

  • 自分のプロジェクトの作業ログ

いずれも「生データの層」「集約の層」「現在の結論の層」の 3 層 + アーカイブで設計すれば、半年後も回り続けます。

あわせて確認した運用の現実

設計時に確認した実運用の注意点も残しておきます。

  • 完全自動化には外部スケジューラ（タスクスケジューラ、GitHub Actions 等）との組み合わせが必要で、実現度は 8〜9 割。スクレイピング依存の情報源は壊れる前提で監視する

  • 情報源は S〜C のランク付けをして、ノイズの多い情報源は最初から絞る

  • API コストは要試算。この規模なら中位モデル利用で月数ドルのレンジに収まる試算だった

まとめ

  • 追記型の巨大 Markdown は必ず破綻する

  • daily（全部残す）/ weekly（集約）/ summary（今の結論）/ archive（退避）の 4 層に分ける

  • AI の常用参照は summary + 直近 daily に限定して、コストと速度を守る

  • 蓄積系システムはこの構造をテンプレとして使い回せる

データの構造設計は、コードより先に決めるべき「システムの背骨」です。ここを最初に議論しておいたおかげで、このシステムは設計変更なしで運用に入れました。

いいなと思ったら応援しよう！