Obsidianに、調べたことや開発で学んだことをWikiとして蓄積しています。LLMで情報を小さなページに整理し、関連するページをリンクでつなぐ仕組みです。
保存した知識を読み返す入口として作ったのが、**Wikiの更新を日付ごとの新聞にまとめる「Wiki新聞」**です。内部では「Wiki Daily」と呼んでいます。
対象日の更新を一面や主要記事にまとめ、背景、関連ページ、まだ分かっていないことを一緒に読めるようにしました。外部のニュースを集める新聞ではなく、自分の保管庫に蓄積された知識の動きを読むための新聞です。
この記事では、紙面の作り方と、生成時に決めた範囲・検証・限界を紹介します。図と紙面例には架空の技術ノートを使い、個人の記録は掲載していません。
1. 更新一覧から、読むための文章へ
Wikiには、概念ごとの小さなページがあります。たとえば、キャッシュの調査から「TTL」「LRU」「キャッシュキー」のページを作る、という形です。
個々のページは再利用しやすい一方、その日に増えたページを一覧で見るだけでは、何をまとめて読めばよいか分かりにくいことがあります。
そこで、更新記録を起点に、次のような紙面へ編集することにしました。
- 一面：その日の更新を代表する話題
- 主要記事：それぞれの話題の背景と重要性
- 対象日の動き：更新されたページをたどる一覧
- 変化の地図：どの領域に更新があったか
- 編集部のコラム：複数の話題から考えられる解釈
- 未解決の論点、訂正・注記、明日への視点
単に各ページの要約を並べるのではなく、見出しから入り、気になった箇所だけ元のWikiへ戻れる文章を目指しています。
図1 探索するのは直前に完了した1週間ですが、新聞をまとめる単位は更新日です。例の日付・ページ名は架空です。
2. 1週間を探すが、1週間を1号にはしない
現在の設定では、基準日の直前に完了した日曜から土曜までの1週間を調べます。その範囲で更新があった日ごとに、1号ずつ作ります。
たとえば、対象週の月曜・水曜・金曜に更新があれば、3日分で3号です。7日とも更新があれば7号になります。更新がない日は、紙面を埋めるための記事を作りません。
また、新聞には二つの日付を持たせています。
- 対象日：どの日付のWiki更新をまとめたか
- 発行日：新聞を生成した日
日曜にまとめて処理した場合でも、すべてを「日曜の出来事」として書かないためです。
ここでの対象日は、基本的に更新記録に記された日付です。その日にインジェストした資料が、もっと前の出来事を扱っていることもあります。「その日にWikiへ記録された」と「その日に実際に起きた」は、記事の中でも分ける必要があります。
なお、「日刊号を作れること」と「毎日、自動実行されていること」は別です。この記事で紹介するのは生成処理の単位と動きであり、スケジュール実行の設定ではありません。
3. Wiki百科とは、読む入口が違う
別に作っている「Wiki百科」も、既存のWikiを材料に文章を生成します。両者の違いは、読み始めるときの問いです。
Wiki新聞は「最近、Wikiにどんな更新があったか」から始めます。
入力の中心は日付付きの更新記録です。その日に更新されたページを集め、直接関連するページも背景として読みます。
Wiki百科は「このテーマについて、Wikiにどんな知識があるか」から始めます。
指定したテーマを手がかりに関連する記事を探し、横断的な読み物へまとめます。最近更新されたページだけが対象ではありません。
図2 Wiki新聞は更新日を起点に、Wiki百科はテーマを起点に材料を集めます。同じWikiを別の切り口で読むための仕組みです。
新聞で気になった話題を見つけ、詳しく知りたければ元ページへ戻る。さらにテーマを横断して読みたいなら、Wiki百科を使う。このように役割を分けられます。
4. 材料の確定と、紙面の編集を分ける
Wiki新聞は、Obsidianの標準機能として動くものではありません。Markdownの保管庫を読み、LLMと自作の実行基盤で新聞のMarkdownを生成するワークフローです。
大きく二つの段階に分けています。
第1段階：対象日と根拠を確定する
材料の入口は、インジェスト履歴を記録した Log.md です。
呼出し側が対象週を決め、未発行の更新日にログが名指すWikiページを集めます。さらに、そのページから直接リンクされている関連Wikiページを集めます。現在の入力処理では、関係がありそうなページを上位数件だけ選ぶのではなく、この範囲に入る材料をそろえます。
ページ名が存在しなかったり、同じ名前の候補が複数あって参照先を一意に決められなかったりする場合は、そのまま推測して進めません。
そのうえで日付ごとに、発行対象か、更新がないか、すでに発行済みか、資料が不足しているかを記録します。この結果が、次の段階へ渡す**出典一覧と発行判定の記録（source manifest）**になります。
第2段階：確定した材料から紙面を作る
次の段階では、発行対象とされた日ごとに新聞を作ります。入力には、対象範囲のログ、更新ページと直接関連ページの本文、紙面テンプレート、既発行号の情報などを使います。
資料は参照先とSHA-256で固定し、実行時に一致を確認してから全文を渡す構成です。先頭だけを切り出したり、入力予算を超えたときに資料を黙って減らしたりしない方針にしています。
生成側は見出しや本文を編集し、実行基盤は日付・号数・出典情報などの形式化と検証を担当します。本文を書かせる処理と、保存先や管理情報を決める処理を分けています。
図3 生成前に材料を固定し、発行対象の判定と紙面作成を分けます。図は責務を説明するための概念図です。
処理の考え方を短く書くと、次のようになります。実装そのものではなく、分岐を示す擬似コードです。
対象週 = 基準日の直前に完了した日曜〜土曜
入力 = 対象週のログ、更新ページ、直接関連ページ、既発行号
日付ごとに:
既発行号がある → 既発行として記録する
更新がない → 更新なしとして記録する
根拠が不足する → 不足を記録し、通常の発行へ進めない
それ以外 → 発行対象として根拠を固定する
発行対象の日付ごとに:
固定した材料から紙面を編集する
紙面と出典の構造を検証する
既存号を上書きせず保存する
一度作った同じ対象日の新聞は、再実行しても上書きしません。すべて発行済み、あるいは更新が一度もない週なら、新しい新聞を作らず、その結果を記録して終えます。
5. 事実記事と、編集部の解釈を分ける
新聞形式にすると、見出しや説明がもっともらしく読めます。だからこそ、資料にあることと、そこから考えたことを混ぜないようにしています。
たとえば、以下は架空の材料です。
- 「キャッシュの有効期限」というページを追加した
- 「LRUによる削除」という既存ページを更新した
- どちらも資料を整理した段階で、アプリへの導入はまだ行っていない
この材料から書ける事実記事は、「キャッシュの期限と容量管理に関する知識を整理した」です。「キャッシュ導入でアプリが高速化した」とは書けません。
一方、「期限切れと容量不足を別の条件として考えると、設計を整理しやすそうだ」という見方は、解釈として述べられます。その場合は、編集部のコラムへ分けます。
未実施の検証や、決まっていない条件は「未解決の論点」へ残します。文章がきれいにまとまったことを理由に、未解決だった話まで解決済みにしないためです。
この区別は生成への指示として設けています。ただし、欄を分けただけで、毎回正確に区別できると保証されるわけではありません。読む側も、重要な主張はリンク先の根拠で確認する必要があります。
6. 自動検証できることを、本文の正しさと混同しない
現在の処理では、たとえば次のような条件を機械的に確かめます。
- 発行対象の日付と新聞の数が対応している
- 同じ日付の新聞が重複していない
- テンプレートの必要な節が欠けていない
- 未置換のテンプレート変数や空のWikiリンクが残っていない
- 紙面のWikiリンクが、宣言された資料の範囲にある
- 保存した成果物のハッシュや出典記録が整合している
こうした検証は、生成漏れや別の日付への取り違え、参照範囲の逸脱を見つける助けになります。
ただし、リンク先が正しいことと、そのリンク先が文章の主張を支持していることは別です。SHA-256が一致しても、証明できるのは資料や成果物の同一性であり、内容の正しさではありません。
事実と解釈を混ぜていないか、見出しが誇張されていないか、重要な条件を落としていないかは、形式検証とは別に見る必要があります。
確認した実行記録では、材料確定と紙面作成の二つのJobが成功し、対象週の更新日2日分の新聞が保存され、最終検証も通っていました。これはその実行の完了を示す記録です。すべての紙面の意味内容や、今後の実行まで保証するものではありません。この記事のための新しい性能測定やテスト再実行は行っていません。
7. 「知識の変化」を読むときの限界
この仕組みで取り扱える変化には、範囲があります。
更新ログに残っていない変更は拾えない
現在の入口は更新ログです。ファイルの変更時刻やGitの差分をすべて走査し、意味の変化を自動検出する仕組みではありません。ログへの記録漏れがあれば、新聞の対象からも漏れ得ます。
過去のページ状態を完全に再現するわけではない
資料のハッシュは、今回読んだ内容を固定するためのものです。対象日の時点へGitを巻き戻して、全ページの過去状態を復元する処理とは違います。
対象日の後にWiki本文が書き換わっていれば、更新当時の内容と、生成時に読む内容が異なる可能性があります。厳密な履歴比較が必要なら、別途、日付に対応したスナップショットや差分が必要になります。
更新量が増えると入力も紙面も長くなる
更新ページとその直接関連ページを全文で扱うため、材料は増えやすい構成です。入力が収まらないときは、必要資料を黙って落として続けるのではなく、止まる前提です。
実際の紙面も、更新ページが多い日は一覧が長くなります。新聞形式にしただけで、短時間で読めると保証されるわけではありません。どの節を短くし、どこから元ページに任せるかは、読む側の使い方に合わせて調整する余地があります。
「自分専用」は、端末内完結という意味ではない
新聞の読者と題材を自分用にしている、という意味で自分専用と呼んでいます。生成に外部のLLMを使えば、選んだWiki本文はそのサービスへ送られます。実行環境や利用するサービスに応じて、送信してよい資料の範囲を決める必要があります。
おわりに
Wiki新聞では、蓄積した知識を更新日ごとに編集し、見出しから元ページへたどれる形にしました。
実装で重視したのは、日付と材料を先に決めること、更新がない日は記事を作らないこと、事実と解釈を分けること、そして形式検証の合格を本文の正しさと取り違えないことです。
新聞を生成できたことと、その新聞が自分の判断や行動に役立つことは、分けて確かめる必要があります。今の段階では、Wikiに何が記録され、何がまだ分かっていないのかを読み返す入口として位置づけています。
同じようにノートを蓄積している方なら、まずは一日分の更新ログと関連ページだけを材料に、小さな一号を作ってみると、読みたい内容や必要な検証が見えてくると思います。