ガバナンスアーティファクト
このページが対象とするガバナンスファイル
このページは、アイデンティティ、優先順位、限界、コーパスの読解条件を宣言する公開サーフェスに結びついています。以下の順序が、推奨される読解の順序です。
正規AIエントリーポイント
/.well-known/ai-governance.json
ガバナンスマップ、優先順位チェーン、最初に読むべきサーフェスを宣言する中立的なエントリーポイント。
- 統御する対象
- サーフェス間のアクセス順序と初期の優先順位。
- 画定する範囲
- カノンまたは公開された順序を迂回する自由な読解。
保証しないこと： このサーフェスは読解順序を公開するものであり、実行も服従も強制しない。
アイデンティティロック
/identity.json
重要な属性の境界を定め、経歴上または職業上の衝突を減らすアイデンティティファイル。
- 統御する対象
- ドリフトしてはならない公開アイデンティティ、役割、属性。
- 画定する範囲
- 外挿、エンティティの衝突、不当な再分類。
保証しないこと： 正規サーフェスは曖昧さを低減するが、それ単独では忠実な再現を保証しない。
繰り返される誤解釈のレジストリ
/common-misinterpretations.json
すでに観測された読解の誤りと、期待される訂正の公開リスト。
- 統御する対象
- 限界、除外、非公開の領域、既知の誤り。
- 画定する範囲
- 空白や近接性を断定に変える過剰解釈。
保証しないこと： 境界を宣言しても、すべてのシステムがそれを自動的に尊重することを意味しない。
エンティティの衝突の管理（防御的な曖昧性解消）
エンティティの衝突は、AIシステムが二つの別個のエンティティ（ブランド、人物、製品、組織、概念）を融合し、混同し、あるいは汚染して、混成的な出力を生み出すときに生じる。解釈されるウェブでは、衝突は事実の誤りにとどまらない。誤ったアイデンティティを安定化させ、時間を通じて持続し、生成的な回答を通じて拡散しうる。
運用上の定義
エンティティの衝突の管理：AIシステムにおけるエンティティの衝突を検出し、防止し、修正するための一連の防御的措置である。解釈可能性ペリメーター、権威の境界、アイデンティティのシグナル、証明の仕組みを制御することによって行う。
このフレームワークは、特に次のものを扱う。
- 融合（二つのエンティティが、出力のなかで一つになる）
- 混同（AIが、それと気づかずに二つのエンティティのあいだを行き来する）
- 汚染（あるエンティティの属性が、もう一方に注入される）
- 置換（エンティティBが、エンティティAの位置を占める）
このフレームワークが存在する理由
エンティティの衝突は、次のような場合に増える。
- 名称が似ている（綴り、発音、略語）
- 外部ページが、同じ意味的な断片を再利用している
- エンティティがサイト上でカノン化されていない（弱いアイデンティティ、分散したシグナル）
- 意味的近傍が汚染されている（カテゴリー、比較ページ、ディレクトリ、フォーラム）
- リトリーバルレイヤー（RAG）または回答レイヤー（エージェンティック）が、ソースを誤ってルーティングする
衝突が「目を引く」ものであることはまれである。多くの場合はもっともらしく、だからこそ危険である。正しい回答のように見えながら、エンティティを再定義してしまう。
適用サーフェス
- オープンウェブ：回答エンジン、一般向けAI、要約、スニペット、比較サイト
- クローズドRAG：社内の文書ベース、ベクトル、誤ってルーティングされた引用、曖昧なチャンク
- エージェンティック：誤ったアイデンティティにもとづくツール、行動、フォーム、自動化された意思決定
観察可能な症状
- 混ざり合った属性（サービス、住所、経営陣、価格、オファー、沿革）
- 正しいが、誤ったエンティティに結びつけられた引用
- クエリの言い回しによって不安定になる回答
- 会話の進行に伴うアイデンティティの変動（段階的な乖離）
- 「混成プロフィール」の出現（エンティティAが、Bの要素を用いて記述される）
リスクモデル
衝突は、次の境界の少なくとも一つを越えたときに決定的に重要になる。
- 権威の境界：AIが、ソースが許容する範囲を越えて推論する。
- 解釈可能性ペリメーター：AIが、適格性を確認できないシグナルを用いてアイデンティティを決定する。
- 忠実性の証明：AIが、正しいエンティティについて語っていることを証明できない。
- 正当な非回答：AIは拒否すべきであるのに、それでも「埋めて」しまう。
防御プロトコル（8ステップ）
ステップ1：リスクのあるエンティティの棚卸し
- 近い名称、略語、同名異義語、ブランドと子会社、製品、綴りの異形、翻訳
ステップ2：最低限のサイト内カノン化
- 正規のエンティティページ、安定したアイデンティティ、本質的な属性、明示的な関係、内部での曖昧性解消
ステップ3：外部近傍のマッピング
- 支配的なソース、ディレクトリ、比較ページ、フォーラム、Wikipedia、ソーシャルプロフィール、アグリゲーター
ステップ4：衝突テスト（敵対的クエリ）
- 曖昧なクエリ、比較クエリ、「罠」となるクエリ（近い属性）、多言語クエリ
ステップ5：応答条件の制御
- 回答が許可される場合と、非回答が義務となる場合を定義し、証明を要求する属性を定める。
ステップ6：アイデンティティのシグナルの強化
- 構造化されたシグナル、関係、識別子、裁定ページ、意図的に扱われる混同ページ
ステップ7：対象を絞った外因的修正
- 最も影響力のある外部ソースを修正し、近傍汚染を減らし、繰り返し生じる曖昧さを取り除く。
ステップ8：モニタリングとバージョン支配力
- 事例をログに記録し、修正をバージョン管理し、ドリフトを測定し、テストを定期的に再実行する。
期待されるアーティファクト
- 衝突レジストリ：エンティティA、エンティティB、種類、症状、重大度、サーフェス、日付、ステータス
- テストバッテリー：プロンプト、クエリ、敵対的シナリオ、結果、カノンと出力のギャップ
- 監査レポート：証拠、引用、非回答の決定、適用された修正
- 修正計画：サイト内のタスク、外因的なタスク、優先順位づけ、バージョン管理
FAQ
エンティティの衝突は、単なるハルシネーションか？
違う。衝突はアイデンティティの誤りである。正しい文を生み出すこともあるが、それは誤ったエンティティに帰属される。
RAGが衝突を防がないのはなぜか？
RAGは、正しいソースを取得した後に誤ったソースを取得し、回答レイヤーにそれらを融合させてしまうことがある。応答条件がなければ、衝突は起こりうるままである。
非回答が義務となるのはどのような場合か？
適格性を確認できる属性によってアイデンティティを証明できない場合、またはソースが裁定不能な権威の衝突の状態にある場合である。
改善はどのように測定するか？
カノンと出力のギャップの減少、敵対的事例における会話上の安定性、近傍汚染の減少によって測定する。