概念

知識リポジトリをブログ兼索引として運用する

記事・索引・タグを同一リポジトリで管理し、ブログと検索可能な知識基盤を兼ねさせる運用手法

定義

個人または組織の知識リポジトリを、そのまま公開ブログとして運用し、同時に「どの記事がどこにあるか」を引ける索引（インデックス）として機能させる設計・運用手法。記事本文の集積だけでなく、索引を一次成果物として明示的に管理する点が特徴である。

kurage-articles-index はその最も直接的な成果物で、600本の記事を「タイトル [topics: タグ列] → URL」の1行形式で列挙している。

出発点は「手入力をなくすことは、システム内製化の入口」「VWorkリポジトリを知識置き場兼ブログにする」という一連の主張で、vibe-coding の実践と表裏をなす。すなわち、

という認識が根底にある。vwork はこの運用のホストであり、kurage / exbridge の継続的なアウトプット基盤になっている。

層	役割	実装
記事層	個別の技術解説・日次ニュース	日付slugのHTML/Markdown
索引層	全記事のタイトル・タグ・URL	`kurage-articles-index` のような単一文書
タグ層	主題の横断分類	`topics:` 配列（日本語タグ／英語5点セット）

索引層を独立した文書として持つことで、全文検索なしでも「この話題の記事はあるか」「URLは何か」に即答できる。これは rag におけるPageIndex的発想（ベクトルDB以前に、まず構造で引く）と同型である。

索引は内容を保証しない。タイトルは「〜で読む」形式の見出し語連結で生成されることが多く、網羅性を示さない。
日次ダイジェストの速報性。ai-news 群は速報であり、後日訂正されうる。索引から引いた記事の事実性は別途検証が要る。
タグの表記ゆれ。初期の日本語タグ群と、後期の英語5点セット（ai / llm / vibecoding / web3 / startup）が混在し、タグ検索だけでは主題横断の把握が難しい。
索引の陳腐化。記事追加のたびに索引を更新する運用規律がないと、索引はすぐ古くなる。

索引で「引ける」状態を作った次の段階として、本Wikiのような編纂層（要約・概念・実体ページ）を重ねる構成が取られる。openkb はベクトルDB不要のRAGとしてこの編纂を自動化する試みであり、knowledge-repo-as-blog の自然な延長にある。

また、ブログを ai-search-optimization（AEO/GEO）の対象として設計する流れ（kgeo、Payload CMS によるOSSカタログ化）は、索引を「人間のため」から「検索エンジンとLLMのため」へ拡張するものである。

この運用手法の本質は、書く速度を上げるほど索引の価値が上がるという点にある。生成コストが下がった環境では、記事本数は自然に増える。増えた記事を人間が記憶で運用することは不可能であり、索引と編纂層の設計が知的生産性のボトルネックになる。