定義：Semibot のナレッジライブラリは Karpathy LLM Wiki プロトコルの上に構築されています。生のソース資料は raw/ ディレクトリに保存され、Agent は整理された主題記事を wiki/ ディレクトリで維持します。これは「一度レポートを生成する」ワークフローではなく、継続的なナレッジメンテナンスです。Agent は新しい資料を取り込み、既存の記事を更新し、リビジョンログを維持できます。ユーザーは知識が形になっていく様子を見守ることができます。このアプローチの核心は、ナレッジを「出来上がりの成果物」ではなく「育つ過程そのもの」としてう点にあります。
ひとつのワークスペースに 3 つのモード
ナレッジライブラリは同じワークスペースに 3 つの機能を持ちます。これらは独立したツールではなく、同じデータを異なる角度から見るための 3 つの窓です。
- Browse：実際のフォルダツリーとファイルプレビュー。ユーザーのディレクトリとファイルのメンタルモデルを保持します。ファイルシステムの構造をそのまま見える形にするため、自分が何を持っているかを直感的に把握できます。
- Search：1 つまたはすべてのワークスペースを横断するハイブリッド意味検索。生の資料と Wiki 記事の両方から関連コンテンツを見つけます。キーワード検索と意味検索を組み合わせることで、用語の一致だけでなく概念的な関連性も捉えます。
- Wiki：出典をたどれる形で継続的に整理される主題記事。Agent が Ingest/Query/Lint ライフサイクルを用いて維持します。単なるメモではなく、構造化された出典付きの知識記事です。
raw/wiki プロトコル
プロトコルはシンプルです。ディレクトリ構造と命名規則だけでワークフローが定義されます。
- raw/：スキルが取得・保存したソース資料。トピック別に整理されます。Web ページのキャッシュ、PDF のテキスト抽出、API レスポンスなど、元の形式をできるだけ保持します。
- wiki/：スキルが維持するナレッジ記事。Markdown 形式で、出典リンクと最終更新日時を持ちます。
- wiki/index.md：人間が読めるグローバルインデックス。すべての記事へのリンクと簡単な説明を含みます。
- wiki/log.md：スキルのメンテナンス履歴とブレークポイントノート。何がいつ更新され、なぜその判断がされたかを記録します。
Ingest は新しい資料を取得します。ソースからテキストを抽出し、raw/ に保存します。Triage は取得した資料をどう扱うかを決定します。既存の記事を更新すべきか、新しい記事を作成すべきか、あるいはまだ記事にするには早いかを判断します。Compile は記事を生成または更新します。raw/ の複数のソースから情報を統合し、構造化された記事として wiki/ に書き出します。Query は Wiki コンテンツを参照して質問に答えます。Lint は既存の記事をチェックし修復します。リンク切れがないか、出典がまだ有効か、記事間の矛盾がないかを確認します。スキルはこれらのディレクトリに直接操作します。ステージングエリアも、生成パイプラインも、自動ロールバックもありません。
ユーザーのメンタルモデル：知識が形になるのを見守る
ユーザーは Wiki 更新中に一時的に半完成状態を目にするかもしれません。これは意図的です。ナレッジメンテナンスの実際の作業状態を反映しています。代替案である「すべての中間作業を隠し、完成した記事だけを提示する」という方法は、ユーザーがナレッジベースに何が含まれ、どのように進化したかのメンタルモデルを構築できない「生成して忘れる」サイクルを生み出します。
「生成して忘れる」パターンの問題は、生成されたレポートがその時点のスナップショットに過ぎないことです。時間が経ち、情報が更新されると、レポートは古い情報のまま放置されます。ユーザーはどの部分が古く、どの部分がまだ有効かを判断できず、結局レポート全体を信用できなくなります。Wiki モデルでは、記事は継続的に更新されるため、常に最新の状態に近づけています。更新の過程が見えることで、ユーザーは「この記事は最近新しいソースで更新された」「この部分はまだ古いまま」といった判断ができるようになります。
この透明性は信頼の基盤にもなります。ブラックボックスの中でレポートが突然変わるのではなく、どのソースからどの部分が更新されたかがログに残るため、ユーザーは変更の理由を理解できます。不正確な更新があれば、ユーザーはログを参照してどのソースが問題だったのかを特定し、手動で修正できます。これは「完全に自動化する」のではなく「自動化と人間の監視が協調する」モデルです。
検索プロジェクション
検索インデックスは派生プロジェクションです。raw/ と wiki/ からいつでも再構築できます。検索プロジェクションの更新に失敗しても、Wiki 更新には影響しません。この分離により、ナレッジメンテナンスと検索インデックスは互いを壊すことなく独立して失敗できます。
この設計は、検索インデックスの構築が時間のかかる処理であることを考慮しています。大量の資料をベクトル化し、インデックスを構築するプロセスは、Wiki 記事の更新とは異なるタイミングで走ります。もし検索インデックスの更新が失敗しても、Wiki の記事はそのまま残り、次の機会にインデックスが再構築されます。逆に、Wiki の更新が失敗しても、既存のインデックスは引き続き機能します。この独立性により、部分的な障害がシステム全体の可用性に影響することを防いでいます。
ローカルファーストのナレッジ
Wiki はワークスペースの .semibot/knowledge/ ディレクトリに存在します。Agent のワーキングディレクトリはこの場所に固定されます。生の資料、記事、インデックス、ログはすべてローカルファイルです。ユーザーが後で別のツールに切り替えても、元のファイルは自分のマシンに残ります。
これはデータの所有権に関する明確な保証です。クラウドベースのナレッジツールでは、サービスをやめるとデータも失われます。Semibot では、すべての知識資産がディスク上のファイルとして存在するため、サービスとの関係を切っても知識は残ります。Markdown ファイルは人間が読める形式であり、他のツールにインポートすることも、単にテキストエディタで開くこともできます。将来のツール選定においても、データの移行コストを気にする必要がありません。ファイルをコピーするだけで、新しい環境に知識を持ち込めます。
限界
- Wiki の品質はモデルの要約・整理能力に依存します。質の悪いソース資料は質の悪い記事を生みます。曖昧な情報や矛盾する情報をそのまま記事にすると、知識ベース全体の信頼性が低下します。
- 人間の編集者はいません。Agent は自律的に記事を維持します。ユーザーはファイルを手動で編集できますが、共同編集インターフェースはありません。手動で編集した内容は、次の Lint サイクルで Agent に認識されます。
- 「資料なし」という結果は有効な成果です。スキルは薄いソースから記事作成を強制しません。十分な証拠がない場合、「まだ結論を出すには早い」と正直に記録されます。
- リビジョン履歴はログベースであり、バージョン管理されていません。差分表示やロールバック UI はありません。過去の状態に戻す必要がある場合は、log.md を手動で確認する必要があります。
- 大量のソースを一度に処理する場合、処理時間が長くなる可能性があります。Wiki 更新は非同期的に行われますが、膨大な量の資料を取り込むと完了までに時間がかかります。また、ソースの品質が低い場合、生成される記事の品質も低下します。ゴミを入れればゴミが出ます。ソースの選別は最終的にはユーザーの判断に委ねられます。
直接保守と、真実と派生物の分離
Semibot のナレッジ Wiki の中核的なアーキテクチャ決定は「直接保守」です。生の資料（raw/）と知識記事（wiki/）が唯一の真実の状態であり、ステージング領域も、生成後の公開も、自動ロールバックもありません。整理の過程はユーザーにリアルタイムで見え、更新途中の半完成状態は欠陥ではなく Wiki の正直な作業状態として扱われます。中断された実行は完了した部分を保持し、その場から再開します。この設計の賭けは、整潔さより透明性——見えているものが、システムが実際にやっていることだ、というものです。
組織化の契約は Karpathy の LLM-wiki の実践を借用します。二つのアンカーファイル（全体インデックスと保守ログ）、資料は「取得 → ふるい分け → 必要に応じて編纂」の流れで記事になり、各記事は出典の引用と相互リンクを維持し、一つの資料に対する結論は常に四つだけ——新しい知識、更新、係争中、材料なし（最後は合法的な結果であり失敗ではない）。出典は UI で一級の存在です。記事はソースと更新時刻を示し、ソースをクリックすれば元文書が開きます。
二つの実装詳細は独立して記録する価値があります。第一に、SQLite が保存するのは実行状態とソースごとの改訂カーソルだけで、検索インデックスと埋め込みはいつでもファイルから再構築できる派生物です。真実は常に Markdown です。第二に、増分更新はソースごとに独立した処理セッションを作り、プロンプトに含まれるのは変化の種類と相対パスだけで、文書の本文は含まれません。これは「数百のファイル名を一つのプロンプトに詰め込んで全体をうわべだけ処理する」という失敗モードへの直接的な防御です。検索では、Wiki 記事は信頼されたシステムソースとして生の資料と共にハイブリッド検索（意味検索とキーワード検索、ランク融合）に入ります。Wiki は原文を置き換えません。二つの経路が並存し、結論はどちらにも溯れます。
FAQ
RAG システムと同じですか？
いいえ。RAG はリトリーブしてモデルにコンテキストを渡す技術です。Wiki モデルは整理された記事を永続的なナレッジ構造として維持します。両者は連携できます。Wiki が構造化知識を提供し、RAG が生の検索を提供します。RAG が「探して渡す」技術であるのに対し、Wiki は「育てる」仕組みです。
Wiki 記事を編集できますか？
はい。ディスク上の通常の Markdown ファイルです。Agent は次のインジェストサイクルであなたの編集を認識します。手動で加えた修正は、Lint サイクルで確認され、整合性が保たれます。
新しい情報が届いたとき、古い記事はどうなりますか？
Lint サイクルが既存の記事を新しいソースと照合し、更新・拡大・矛盾の指摘を行います。記事は凍結されません。新しい情報が既存の記事の内容を覆す場合、矛盾が指摘され、必要に応じて記事が修正されます。
Wiki はローカルに残りますか？
はい。Wiki はワークスペースのローカル .semibot/knowledge/ ディレクトリにあります。モデル API の呼び出し（クラウドモデル使用時）のみネットワークに関与します。記事の内容やソース資料はすべてローカルファイルシステム上に存在します。
どのくらいの頻度で Wiki が更新されますか？
ユーザーが新しい資料を追加したとき、または明示的な更新指示を出したときに更新されます。自動的な定期更新ではなく、ユーザーの操作に応じたオンデマンドの更新です。ユーザーが新しい資料を投入すると、Agent は自動的に取り込みと整理を開始します。
記事の品質をどうやって確認できますか？
各記事は出典リンクを持ちます。出典をクリックして元のソースを確認することで、記事の内容が正確かどうかを検証できます。また、log.md で記事の更新履歴を確認することもできます。変更の理由とタイミングがすべて記録されています。