システムは知識が変わったことをどう把握するのか

知識とシステム — 02

文書が更新される。新しい版がシステムに取り込まれる。次の回答は、その版を使うようになる。

一見すると、知識は更新されたように見える。けれど古い版は、別の場所に残り続けるかもしれない。キャッシュ、以前に生成された要約、別の記録、あるいは過去の判断の根拠の中に。

そのため、知識が変わるという問題は、ファイルの変更に気づくことよりも広い。

システムは、何が変わり、その変更がどの利用に影響するのかを、どう追跡するのか。

KLMとnageに取り組む中で、この問いは二つの水準で現れる。知識の足跡をどう記録するか。そして、その知識を使うシステムがどう振る舞うべきか。

変わったものは、正確には何か

簡単な仮定の例を考えてみよう。

ある組織の指針で、申請期間が10日と定められていたとする。新しい指針では7日に短縮し、指定の日から有効になるとする。

変わったのは文章だけではない。規則の有効条件も変わった。

古い指針は、その指針が有効だった時期の手続きを説明するために、今も必要かもしれない。一方、新しい申請への回答には新しい指針を使うべきである。

したがって、システムには一つの「現在の文書」欄以上のものが必要だ。どの情報源のどの版を保持しているのか、それはいつ有効なのか、どの処理で使われたのかを区別できる必要がある。

また、すべての変更が同じ重みを持つわけではない。誤字の修正、日付の変更、判断条件の変更は、それぞれ異なる結果をもたらし得る。

ファイルの内容ダイジェスト、つまりハッシュが変われば、内容が異なることは検出できる。しかし、その差の意味と影響を判断するには、別の評価が必要になる。

KLM：変更の足跡を読めるようにする

KLMは、回答の背後にある知識、主張、証拠の関係を明示的に記録するための契約を開発する取り組みである。

ここで重要なのは、情報源のアドレスを保存することに加えて、使われた特定の版を区別できることである。

あるリンクが今日別の文書を示しているなら、そのリンクだけでは過去の回答の根拠を復元できないかもしれない。情報源の識別子、版、内容ダイジェストなどを記録すれば、その区別が可能になる。

KLMの仕様では、知識単位の有効期間の開始と終了、版、以前の単位を置き換える関係が定義されている。新しい記録は、どの古い記録を置き換えたのかを表現できる。

これらの項目だけで、意味の変化を自動的に検出する仕組みができるわけではない。アプリケーション側で、変更をどう検知し、どの根拠に基づいて項目を埋めるのかを、別途定める必要がある。

KLMがここで提供するのは、変更について下した判断の足跡を保存する枠組みである。

新しい版が来たら、古い版を削除すべきか

例の古い指針を完全に取り除けば、過去の回答を説明しにくくなるかもしれない。古い指針と新しい指針を区別せずに併用すれば、新しい回答がどの規則に従うべきかが曖昧になる。

過去を保存することと、現在の利用条件を定めることは、一緒に考える必要がある。

知識単位は、有効な状態にある場合も、新しい版に置き換えられた場合も、期限切れの場合も、撤回された場合もある。それぞれ異なる状態である。

KLMは、こうしたライフサイクル上の区別を扱う。情報源を削除したと主張する場合には、削除の範囲も明示することを求める。知識ストアから取り除いた記録が、キャッシュ、推論ログ、派生した出力からも取り除かれているとは限らない。

「削除済み」という言葉が、システム全体で同じ処理が完了したという前提を含むべきではない。

nage：記録上の判断を稼働するシステムへつなぐ

nageでは、この区別を運用中にどう保つかという問いに進む。

新しい知識の取り込みでは、情報源の記録を作る、処理する、検索可能にする、利用可能にするなど、複数の処理が行われ得る。どの処理も、それぞれの地点で失敗する可能性がある。

新しい版がストアに書き込まれても、検索インデックスが更新されていなければ、システムはどの版を使うのか。古い版がアーカイブされてもキャッシュに残っていれば、何が起きるのか。二つの更新が同時に来たら、どちらを有効な版とするのか。

nageの設計では、管理される知識単位を、その情報源、版、ライフサイクル、利用できる機能とともに扱う。文書が存在すること、検索できること、利用のために受け入れられていることは、別々の状態である。

この区別を一つの「準備完了」フラグにまとめると、未完了の処理が利用可能に見えてしまうことがある。

ここでの運用上の問いは、次のとおりだ。

新しい版を利用できる条件を、どう検証するのか。

nageでは、製品全体のライフサイクルの受け入れ検証は、まだ未完了の課題である。そのため、この説明はすべての更新・削除シナリオが完了したと主張するものではなく、検証すべき振る舞いを記述している。

情報源の変更は、どこまで届くのか

ある回答の特定の主張が、古い指針を根拠としていたとする。その回答が後に要約され、その要約が別の作業で使われたかもしれない。

情報源が変わったとき、影響は最初の回答だけにとどまらない。

だからこそ、情報源から出力へ足跡をたどれることが重要になる。この版を使った主張はどれか。その主張から派生した出力はどれか。

KLMの証拠関係と派生関係は、この影響の足跡を記録する基盤となる。ただし、影響を受けた記録を見つけても、それを自動的に誤りと判定することにはならない。

過去に有効だった規則に従って生成された回答は、当時の文脈では正しいままであり得る。同じ回答でも、今日の新しい手続きには適さないかもしれない。

システムには、この二つの利用を区別する方針が必要になる。再評価する記録も、歴史的な記録として残すものも、新たな利用を停止するものもあり得る。

関係の記録は、その判断がどの記録を対象とすべきかを可視化する。

情報の新しさについて、何が分かっていないのか

情報源が今日システムに取り込まれたからといって、その内容が今日有効であるとは限らない。最近の日付のファイルが、古い規則を伝えている場合もある。

情報源の取得時刻、変更時刻、有効になった時刻は、それぞれ異なる情報を持つ。

どれかが不明なら、その欠落を明示したままにする必要がある。不明なシグナルを理由とともに保存するKLMの考え方は、ここでも意味を持つ。測定していない新しさに数値を与えても、情報の欠落はなくならない。

冒頭の問いに戻ると、「システムが理解する」という表現は、変更を検出する、新しい記録を古い記録に結び付ける、利用条件を定める、影響を受けた出力を見つけるという、具体的な作業に分かれる。

それぞれの作業には、別々の根拠と限界が必要だ。

知識の更新を評価するときには、この問いも加える必要がある。

新しい知識を追加した。では、古い知識がどこで使われ続けているかを見られるのか。

---

出典について — 2026年10月15日： 本文は、KLM仕様の知識ライフサイクルと影響の系譜に関する節、およびnageの設計と現在の実装に関する文書に基づく。指針の例は仮定である。新たな実装結果や受け入れテストの結果を示すものではない。

KLMのプロジェクトページ · nageのプロジェクトページ · 不明はなぜゼロではないのか