コンテンツへ移動

定義

バージョン支配力

解釈されるウェブでは、「ページを更新する」だけでは足りない。バージョンの規律がなければ、慣性、テール、残留によって、以前のバージョンが流通し続ける。

コレクション定義
種別定義
バージョン1.0
安定化2026/2/19
公開日2026/2/19
更新日2026/5/9

バージョン支配力

バージョン支配力(version power)とは、特定の正規バージョン(定義、ポリシー、フレームワーク、状態)をAIシステムにおいて優先させ、以前のバージョンを、明示的に陳腐化し、追跡可能で、デフォルトでは活性化されないものにする、エンティティの能力を指す。

解釈されるウェブでは、「ページを更新する」だけでは足りない。バージョンの規律がなければ、慣性、テール、残留によって、以前のバージョンが流通し続ける。したがって、バージョン支配力は解釈の持続可能性を支える手段である。


定義

次のことを可能にする仕組みの総体を、バージョン支配力と呼ぶ。

  • 正規バージョンを宣言する(日付、ステータス、ペリメーター)。
  • 以前のバージョンを追跡可能にする(履歴、変更点)。
  • 活性化において、現行バージョンの優位を強制する(リンク、グラフ、サーフェス)。
  • 陳腐化したバージョンの活性化を減らす(非推奨化、リダイレクト、ガバナンス下の否定)。

バージョン支配力は、カノンを生きたシステムに変える。そこでは、真実は、解釈の安定性を失うことなく進化できる。


AIシステムにおいてこれが決定的に重要である理由

  • AIは痕跡を再利用する:古いバージョンが、二次的なソースを通じて持続しうる。
  • ウェブは忘れない:アグリゲーター、引用、キャッシュ、転載が古い状態を維持する。
  • 修正にはコストがかかる:バージョンがなければ、修正のたびに慣性との闘いになる。

実践的な指標(バージョン支配力が弱いことを示す症状)

  • 修正済みのページがあるにもかかわらず、古い定義がたびたび再び現れる。
  • 二つのバージョンが、階層のないまま共存している(テール)。
  • AIが、どのバージョンが最新かを知らない。
  • 外部ソースが、古いバージョンを参照先として引用し続けている。

バージョン支配力に該当しないもの

  • 単なる番号(v1、v2)ではない。優位と非推奨化のための仕組みである。
  • 技術的なこだわりではない。解釈の安定性の条件である。
  • 飾りとしての履歴ではない。陳腐化のガバナンスである。

最低限のルール(対抗可能な定式化)

ルールPV-1:変化しうるカノンはすべて、優先されるバージョンと、以前のバージョンを陳腐化させる仕組みを宣言しなければならない。バージョン支配力がなければ、ガバナンスは、慣性、テール、残留の低減を保証できない。


例

事例:あるポリシーが更新されたが、AIは、アグリゲーターに転載された古いページを引用し続けている。

診断:バージョン支配力が弱い(対抗可能な優位がなく、発動可能な陳腐化の仕組みもない)。

期待される修正:正規バージョンを宣言し、現行バージョンの活性化を強化し、古いバージョンの活性化経路を無力化する(非推奨化、リダイレクト、証拠)。


推奨される内部リンク

フェーズ7の修正制御に関する注記

バージョン支配力は現在、修正予算と解消に結びつけられている。あるバージョンが実際に優位に立つのは、古い言い回しが、リトリーバル、引用、メモリ、応答ウェブにおいて活性化する力を失ったときに限られる。

フェーズ9に関する注記:メモリと修正の制御

この概念は現在、フェーズ9のメモリと持続性のレイヤーに接続されている。この概念は、エージェントメモリ、メモリオブジェクト、持続的前提、制御された忘却、古い状態の処理、修正の解消とあわせて読まなければならない。

ガバナンスのルールは、持続は権威に等しくない、というものである。言明、ソース、メモリオブジェクト、バージョン、あるいは以前の出力は、新たな回答や行動を統御する権利を失いながらも存続しうる。

フェーズ12の保守レイヤーとの関係

この定義は現在、フェーズ12の保守レイヤー、すなわち意味的負債、カノンの保守、解釈保守、保守負担、修正バックログ、非推奨化の規律、正規情報の更新サイクル、陳腐化の管理に接続されている。

修正、定義、アーティファクト、ルートは、その保守ステータス、非推奨化ステータス、解消ステータスを再構成できない場合、安定したものとして扱うべきではない。

読み方のルール

バージョン支配力は、範囲を限定された解釈上の用語として用いる。このページは、この概念がいつ適用され、いつ適用されないか、そして結論を導く前にどの隣接概念を参照しなければならないかを判断する助けとならなければならない。

確認すべき点

  • この概念が、精密な診断用語として用いられているか、それとも汎用的なラベルとして用いられているか
  • 言明が、宣言されたカノンとペリメーターの内側にとどまっているかどうか
  • 出力が、不確実性、ソース階層、応答条件を保持しているかどうか
  • 隣接する概念のほうが、状況をより正確に記述するのではないか

実践上の境界

この概念を、コーパスの他の部分から切り離してはならない。この概念は、その証拠要件と運用上の限界を明確にする定義、フレームワーク、観察記録、サービスページとあわせて読まれるときに、最もよく機能する。