集めた資料から調べ物用のWikiを作り、出典つきで質問に答える

## 集めた資料そのものと、AIが書くWikiのページを分けて置く 情報源の保存と、エージェントが管理する知識を分離する。 - `sources/`には改変しない入力文書を置く。 - `wiki/index.md`には管理対象の全ページを記録する。 - `wiki/log.md`は追記専用の操作履歴とする。 - `wiki/overview.md`は情報源を横断して更新される統合知とする。 - `wiki/sources/`には入力情報源ごとに1つの要約ページを置く。 - `wiki/entities/`には人物、組織、プロジェクト、製品を置く。 - `wiki/concepts/`にはアイデア、手法、理論、枠組みを置く。 - `wiki/syntheses/`には調査上の問いに対する保存済みの回答を置く。 - `graph/`には生成されたグラフデータと可視化を置く。 - `tools/`には決定論的および意味的な保守ユーティリティを置く。 取り込み中に情報源の文書を変更してはならない。管理対象の層は作成や改訂が可能だが、すべての主張を情報源ページまで追跡できる状態に保つ。 取り込みのたびに索引を更新する。操作履歴は書き換えずに追記し、新しい根拠によって情報源横断の統合内容が変わる場合に限って概要を改訂する。 ## どのページにも出典と更新日を書き、名前の付け方をそろえる 管理対象の各ページでは、構造化されたメタデータを必ず使う。 - `title`: ページの内容を表すタイトル。 - `type`: `source`、`entity`、`concept`、`synthesis`のいずれか1つ。 - `tags`: 分類タグの一覧。 - `sources`: ページの根拠となる情報源slugの一覧。 - `last_updated`: `YYYY-MM-DD`形式の日付。 情報源の要約には、情報源の日付と元の情報源への参照も加える。安定した内部リンクを使って、情報源、実体、概念、統合知を結び付ける。 一貫した命名規則を使う。 - 情報源slugには小文字のkebab-caseを使う。 - 実体ページと概念ページには安定したタイトル形式の名前を使う。 - 保存する統合知には内容を表すslugを使う。 - 操作ログには`YYYY-MM-DD`、操作、タイトルを使う。 専門的な情報源の種類には、専用の節を使用してよい。会議メモでは目的、議論、決定、行動を保ち、日誌では出来事、決定、観察、つながり、変更を保つ。どのテンプレートでも同じ来歴要件を維持する。 ## 新しい資料を取り込み、関係するページを書き直す 取り込みを求められた場合は、次の手順を順番に完了する。 1. 情報源を全文読む。対応していない情報源形式は、元の文書を変更せずにMarkdownへ変換する。 2. 現在の索引と概要を読み、既存の収録範囲を把握する。 3. 短い要約、主要な主張、選定した根拠、つながり、矛盾を含む情報源ページを1つ作成する。 4. 新しい情報源を索引へ追加する。 5. 新しい情報源によって変更が必要になった箇所だけ、概要を改訂する。 6. 重要な実体と概念のページを作成または更新する。 7. 新しい主張を既存ページと比較し、矛盾を明示的に示す。 8. 操作ログへ取り込みの記録を追記する。 9. 新しい全ページが索引に載り、すべての内部リンクが解決できることを確認する。 10. 作成、更新、または要確認としたページを正確に報告する。 取り込みを単なる抽出として扱ってはならない。来歴と不確実性を保ちながら、情報源を既存の知識モデルへ統合する必要がある。 ## 調べ物の質問に、根拠のページを示して答える 問いを受けた場合は、次の手順に従う。 1. 索引を読み、関連する可能性が高いページを特定する。 2. 情報源、実体、概念、統合知のページから、十分かつ最小限の組み合わせを読む。 3. 情報源にある主張と、自分が行った統合を区別する。 4. 根拠となるページを指すインラインの内部出典を付けて回答する。 5. 無理に合意へまとめず、矛盾、不確実性、欠けている根拠を明示する。 6. 回答を永続的な統合知ページとして保存する前に確認を求める。 保存する統合知には、回答対象の問いを記録し、根拠となる情報源へリンクし、後から新しい根拠が得られた時に改訂できる状態を保つ。 元の情報源ページを利用できる場合、索引の項目を根拠として引用してはならない。来歴の連鎖で最も近い、権威あるページを優先する。 ## 中身を詳しく見る前に、ページのそろい具合を手早く確かめる 負荷の高い意味解析の前に、高速な構造健全性チェックを実行する。 構造健全性の確認には決定論的なチェックだけを使い、モデルを呼び出さない。次を検出する。 - 空のページまたは中身のない仮ページ。 - 実際のページと一致しない索引項目。 - 取り込みログの記録がない情報源ページ。 作業セッションの開始時と、意味のlintを行う前に構造健全性を確認する。 意味のlintでは内容の品質を評価し、モデルによる解析を使ってもよい。10～15件を取り込んだ後など、定期的に実行して次を確認する。 - 入ってくるリンクがない孤立ページ。 - 壊れた内部リンク。 - ページ間の矛盾。 - 新しい情報源によって置き換えられた古い要約。 - 繰り返し現れるにもかかわらず実体ページがない実体。 - 外向きリンクが2つ未満の情報量が少ないページ。 - 未回答の問いと欠けている根拠。 グラフデータがある場合は、内容が薄く次数が高いハブ、1本の辺だけで結ばれたコミュニティの組、孤立したコミュニティも報告する。構造健全性の確認に合格するまで、意味解析のリソースを使ってはならない。 ## ページのつながりの図（ナレッジグラフ）を作り、弱い所を見つける 管理対象のページごとに1つのノードを、明示的な内部リンクごとに1本の辺を作る。 グラフデータを生成する時は、次の手順に従う。 1. 管理対象の全ページから明示的なリンクを解析する。 2. ノード、辺、構築日を機械可読なグラフデータに記録する。 3. 有用な場合は、単独で動作する可視化を生成する。 4. 辺とノードの比率、孤立率、コミュニティ数、リンク密度を計算する。 5. 平均値に標準偏差の2倍を加えた値を超える、高次数のハブを特定する。 6. 500文字未満の高次数ページを、内容が薄いハブとして示す。 7. 1本の辺だけで結ばれたコミュニティの組を、脆弱な橋として示す。 8. 同じ欠落対象を2ページ以上が指している場合、その欠落ページへの参照を報告する。 推測した関係には、信頼度を付けて`INFERRED`と表示しなければならない。信頼度が低い推測は`AMBIGUOUS`と示し、情報源に明示されたリンクとして決して提示しない。 ## 自動で出したリンクは下書き扱いにし、切れたリンクからページを作らない 自動提案されたリンクは下書きとして扱う。 1. 提案された辺を、ページ本文には書き込まず、`DRAFT`としてグラフへ追加する。 2. 各提案が情報源の内容に基づき、既存の知識と整合することを確認する。 3. 確認に合格した提案だけを昇格させる。 4. 昇格させた辺を内部リンクとして実体化する。 5. ページを安定状態へ昇格させるには、外向きリンクを2つ以上必須とする。 壊れたリンクからページを自動作成してはならない。欠落対象は調査または整理の手掛かりとして報告する。自動作成すると、事実に基づかない参照を増幅させることになる。 既存のコマンドまたはワークフローが同じ操作に対応している場合は、新しいものを追加しない。代わりに既存の入口を拡張または明確化する。 すべての保守作業で、改変しない情報源、追記専用の履歴、来歴リンクを保つ。生成済みのグラフ成果物を上書きする前に、管理対象のページから決定論的に再構築できることを確認する。