はじめに
DTM Digest は、首相官邸・White House・各省庁など日米15情報源(2026/06/17時点)の公的一次情報を横断収集し、参考要約と出典付きで公開するサイトです。
なぜ作ったか・2か月運用で何が起きたかは Zenn 記事 を参照してください。
本記事は、AI 時代の一次情報収集基盤を実際に構築してみて、設計時の想定がどう裏切られたかをまとめたケーススタディです。内部モジュール名や取得制御の具体手法は、公開上の理由から抽象化しています。
結論
データソース → バッチ処理 → ビルド・配信 → ユーザー体験
| レイヤ | 技術 | 役割 |
|---|---|---|
| 収集・処理 | Node.js + Python + PostgreSQL | クロール、本文抽出、AI 要約、DB 保管 |
| AI | llama.cpp（ローカル推論） | 英日要約（外部 API 非依存） |
| 配信準備 | Python 静的エクスポート | フロント向け JSON 生成 |
| 公開 | Astro 6 + Cloudflare Workers | SSG + Pagefind 全文検索 |
最大の学びは一つ。 2026年時点では、AI 要約そのものより品質保証の方が圧倒的に難しい。収集基盤は「完成」に近づけるが、品質保証は「完成がない」——この非対称性が、パイプライン設計の中心課題になった。
設計時の予想と実際
設計前の想定
| 項目 | 想定 |
|---|---|
| 情報収集 | 比較的簡単 |
| AI 要約 | 難しい |
| 品質保証 | 補助的 |
実際
| 項目 | 結果 |
|---|---|
| 情報収集 | 想像以上に難しい |
| AI 要約 | 意外と安定 |
| 品質保証 | 最大の工数 |
なぜそうなったか
収集
「公開情報なら収集は簡単」と思っていた。実運用では、RSS経由であってもタイトルだけでなく、詳細内容(ページ本文)を取得するには、CDN・WAF・Bot 対策・reCAPTCHA 等によって、公開情報であっても機械取得は簡単ではなかった。一方、APIで構造化提供されている情報源は非常に扱いやすかった。取得経路の設計が、当初想定よりはるかに重要になった。
多くの記事は「取得済みデータ → AI 処理」しか語らない。しかし本プロジェクトで先に問題になったのは、そもそも取得済みデータをどう継続確保するかだった。
AI 時代になると、「要約できるか」より 「安定して取得し続けられるか」 の方が先に問題になるケースが多い——これが、本記事で最も再現性のある知見の一つだと考えている。
AI 要約
当初は最大のリスクと考えていた。しかし 十分なローカル推論環境と、適切な指示追従モデル があれば、要約そのものは比較的安定して生成できた。外部 API コストも固定化できる。記事の本質は特定モデル名ではなく、ローカル完結で要約パイプラインを回せることにある。
品質保証
人名・金額・日付の誤りは、そのまま誤情報になる。結果として 生成 → 検証 → 補正 → 再生成 のループ構築に、最も時間を使った。
要約を作る ＜ 要約を信用できる状態にする
digest パイプライン概要（STAGE 0〜4）
管理画面（FastAPI）から日次バッチとして起動する中核パイプライン。
| STAGE | 処理 | 概要 |
|---|---|---|
| 0 | LLM 起動確認 | ローカル推論の可用性チェック |
| 1 | 収集 + DB 直接登録 | 収集結果を DB に直接反映 |
| 2 | リンク展開（2フェーズ） | 一覧 → 記事 URL 展開 |
| 3 | 本文抽出 | 分析制御処理 |
| 4 | AI 要約・記事化 | ローカル LLM で要約生成 |
バッチ完了後は、図解生成・意思決定支援テキスト・重要度スコアリング等を連結実行する。バッチ要約と管理画面からの再要約は 共通の要約コア処理 を通し、ガードレール改修が一箇所で全パスに反映されるようにしている。
RSS 優先設計の理由
STAGE 2 では、RSS が有効な情報源は STAGE 1 のトップページ取得をスキップし、RSS 直接処理に委譲する。
技術的理由
- HTML 直接取得より 巡回コストが低い
- 更新検知の粒度が明確（フィードエントリ単位）
- 一覧ページの DOM 変更に左右されにくい
設計思想
RSS / Atom は、情報提供者側から見れば 「この情報は機械取得してよい」という意思表示 でもあると解釈できる。特に日本においては、行政機関・大手組織の多くが標準提供している。
RSS があるなら RSS を優先する
を設計原則とした。Phase 1（HTML 起点のリンク展開）と Phase 2（RSS 直接処理）の2フェーズ構成は、この原則をパイプラインに落とし込んだ結果である。
品質保証：AI要約より難しかった部分
一次情報では、以下3つが特に致命傷になる。
人名
White House の声明は一人称で書かれ、原文に大統領名がないことが多い。LLM は学習データから「○○大統領は」と補完する。
→ プロンプト禁止 + 人名検証モジュールで生成後検出 → 役職名へ自動置換
金額
財務省の入札結果など、表セルは裸の数値で 単位は表外。LLM は桁や単位を壊す。
→ 金額検証モジュールで原文照合 → 不整合時は再生成または金額省略
日付
和暦・西暦・英語表記・スラッシュ区切りなど省庁ごとにバラバラ。「今週日曜日」を具体日に推測変換するケースも多い。
→ 日付検証モジュールで数十パターン照合 → 厳格度は環境設定で制御
品質保証は終わらない
収集基盤は完成がある
品質保証は完成がない
新しい情報源、新しい表形式、新しい文体、新しい例外が継続的に発生する。システム開発というより 運用品質管理 に近い。ガードレールは一度書いて終わりではなく、失敗事例の蓄積とルール追加が常態化する。
ボツになった設計
画像比較による重複判定（初期案）
スクリーンショット取得 → 画像比較 → 重複検出
ページ更新の検知に visual diff を使う案だった。しかし 計算コスト・精度・保守性 のバランスが悪く、採用見送り。
中間ファイル経由のパイプライン（初期案）
Node 収集 → JSON ファイル → Python 処理 → DB 登録
ファイル I/O で段階を分けていたが、整合性管理・再実行・ファイル残骸 の運用負荷が大きかった。結果として DB 直接登録へ移行 した。
※重複判定の現行方式は、運用上の理由から本記事では割愛する。
静的配信まわり（要点のみ）
DB の記事データから 静的エクスポート処理 でフロント向け JSON を生成し、Astro ビルド時に SSG する。
- 新着差分検出（新規 / 更新）
- staging 経由のデータ入れ替え（古いファイル残留防止）
- Capacity-Aware Retention — ホスティング先のファイル数予算から保持件数を逆算
- Pagefind によるクライアントサイド全文検索（DB / Elasticsearch 不要）
- 構造化データ +
llms.txtによる AI Discovery 対応
フロントの UI ライブラリ選定や CSS フレームワークの詳細は、本記事の主題から外れるため省略する。
設計上のトレードオフ
| 選択 | メリット | デメリット |
|---|---|---|
| ローカル推論 | API コスト固定、データ外部流出なし | GPU / 運用の手間 |
| DB 直接登録 | 中間ファイル I/O 削減 | 言語間連携の複雑さ |
| RSS 優先 | 取得コスト低・更新検知明確 | RSS 非提供源は HTML 経路が必要 |
| 静的 JSON + SSG | 高速配信、SEO 向き | 更新のたびにビルド必要 |
| 生成後ガードレール | 一次情報の誤りを抑制 | 開発・保守が終わらない |
まとめ
DTM Digest の技術的な芯は、日米の公的機関サイトから一次情報を継続収集し、ローカル LLM で要約し、静的 JSON 経由で Astro サイトに載せる digest パイプラインだ。
ただし、「どう作ったか」より「何が想定外だったか」 の方が、再現性のある知見になる。
- 収集は公開情報でも想定以上に難しい——安定して取得し続けられるかが先に問題になる
- AI 要約はローカル推論環境が整えば比較的安定——特定モデル名より環境設計が重要
- 品質保証（人名・金額・日付）が最大工数——完成がない
- RSS 優先は技術的にも思想的にも合理的
- 画像比較・中間ファイルはボツ——DB 直接登録へ移行
構築前は、工数が必要な優先順位を 品質保証 ＜ 収集 ＜ AI要約 だと思っていた。実際は 収集 ≒ 品質保証 ＞＞ AI要約 だった。
AI 時代の一次情報インフラは、「要約できる」より 「説明責任を失わず要約できる」 設計が本番になる。
リンク
- サイト: https://dtmdigest.org/
- 仕組み: https://dtmdigest.org/how-it-works
- Zenn（構築背景等）: https://zenn.dev/anjim/articles/ea35f699fe22d0
- llms.txt: https://dtmdigest.org/llms.txt