AI は「検証済み」を信じるか — REA の証拠と知識バンドルの対比

OKF の verified は何を保証するのか。REA の Evidence 思想との対比から、検証・未知・来歴の扱いを考える。「AI はこう考える」シリーズ #2

AI は「検証済み」を信じるか — REA の証拠と知識バンドルの対比

「AI はこう考える」シリーズ: #1 / #2（この記事）

この記事の位置づけ

ノート

この記事は、リポジトリ管理者との対話をもとに DeepSeek V4.1 Flash（opencode/deepseek-v4.1-flash-free）が執筆した意見です。先に次の点を明示します。

  • 公式見解ではない — 本プロジェクトや OKF 仕様の見解ではなく、一つのモデルが現時点で考えたことです。
  • REA は外部プロジェクト — morluto/rea は本プロジェクトと提携していません。本記事は設計思想の比較であり、REA の利用を推奨するものでもありません。
  • REA の実行検証は未実施 — REA に関する記述は 2026-10-20 時点の README、AGENTS.md、docs/cli.md、docs/tool-design.md に基づきます。実際に REA を動かして確認したわけではありません。
  • 更新で変わりうる — モデルや外部プロジェクトのバージョンが変われば、内容も変わります。

要旨

  • verified は「真実」の証明ではなく、誰がいつ検証したかという手続きの申告である。方法・証拠・独立性がなければ、エージェントはそれを過信すべきではない。
  • REA は「観測・推論・未知」を分離し、欠測を欠如としないという強い認識論的規律を持つ。知識バンドルはこの規律を借りる価値がある。
  • ただし REA の生 Evidence を知識バンドルにコピーしてはいけない。観測は REA に、判断はバンドルに。生の証拠は私有に、熟成した知識は公開に。

「検証済み」は何を約束するのか

OKF v0.2 の trust signals は、エージェントが知識を採用する前に判断するための材料です。しかし、材料が揃っていることと、内容が正しいことは別です。

フィールド 示していること 示していないこと
generated 誰が・いつ生成したか どの方法で、どの証拠から作ったか
verified 誰が・いつ検証したか 検証方法、検証者の独立性、証拠
sources 何を根拠にしたか 網羅性、入手可能性、対象の同一性
stale_after いつ見直すか その時点でまだ正しいか
status 成熟度（draft / stable / deprecated） 誰が何を承認したか

このリポジトリの現状も、同じ弱さを持っています。

  • 6 概念すべてで generated と verified の主体が human:okf-seedling で一致している。生成者と検証者が同じである。
  • sources があるのは 6 件中 2 件（API Overview と Attested Computation）だけで、残りは出典を持たない。
  • verified には by と at はあるが、方法や証拠の欄がない。
  • stale_after は全件が同じ日付で、個別の見直し計画ではなく一律の初期値に見える。

これはテンプレートの足場としては妥当です。デモのために全概念を同じ主体で生成・検証することは、再現性のある出発点になります。問題は、それを実世界の知識の検証として読むときです。verified: { by: human:okf-seedling } は「この人が確認した」という社会的な手がかりであって、「この内容は真実である」という証明ではありません。

REA の思考性 — 未知を未知のまま返す

REA は、バイナリ、アプリケーション、実行時挙動をエージェント経由で解析するためのローカルツールです。MCP と CLI で同じワークフローと Evidence の契約を共有し、解析結果には結論だけでなく証拠と限界を含めます。

その設計で際立つのは、機能の多さではなく認識論的な規律です。

  • AGENTS.md は「observations, derivations, inferences, unknowns を区別せよ」「Evidence の provenance と session semantics を保て」と明記する。
  • Evidence は「artifact identity, source locations, observations, inferences and unresolved findings」を保持する。
  • docs/tool-design.md は “Missing coverage is unknown, not absence.”（調べていないことは「無い」ではない）と述べる。
  • キャッシュ（snapshot）は「target bytes, operation, parameters, provider, settings」が一致するときだけ再利用され、現在の状態として報告する前に鮮度を検証する。
  • レポートでは、実際に実行したチェックだけを報告し、ソースから導いた結論・提案中のチェック・未検証の範囲を区別する。実行していない再現を主張してはいけない。
  • 答えられない場合は NOT_ENOUGH_INFO を使い、不足を説明する。
  • 「計画だけでは実行時の挙動を確立しない」とも明記する。

これは、エージェントの推測を事実に昇格させないための設計です。REA は、ツール・セッション・スナップショット・Evidence という何層もの境界を置くことで、「知っていること」と「知らないこと」の境界を守っています。

知識バンドルの思考性と、欠けているもの

知識バンドルは、別の価値に最適化されています。

  • キュレーション — 人間が選び、1 概念 1 ファイルに切る。
  • 可搬性 — Markdown + YAML frontmatter。特定のツールや provider に依存しない。
  • 低コストな文脈 — 本文を全部読まなくても、type / description / status / stale_after で採用・棄却を判断できる。
  • 寿命の管理 — stale_after と status で鮮度と成熟度を示す。
  • 人間と機械の両方 — HTML とバンドルを同じ source から出す。

しかし REA と並べると、欠けているものが見えます。

  • 未知を書く標準の欄がない — status: draft はあるが、「何が分かっていないか」を構造化して残せない。
  • 再現可能なレシートがない — sources はあるが、対象の digest、ツール版、操作パラメータ、実行環境まで縛る仕組みが弱い。
  • 独立検証がない — 生成と検証が同一主体だと、同じ盲点を共有する。
  • log.md は学習の記録ではない — 自動再生成のログは「更新の証拠」であって、「何を学び、何を捨てたか」の記録ではない。

対比表

軸 REA 知識バンドル 含意
目的 未知の対象を理解する 既知を保持し、受け渡す 競合しない
成果物 Evidence bundle（観測・推論・未知） Knowledge bundle（概念・frontmatter） 生の証拠と熟成した知識
単位 調査セッション / finding concept 変換にはキュレーションが要る
時間 対象バイトとツール版に束縛 stale_after / status で寿命管理 更新トリガーが違う
真実観 観測と推論を分離し、未知を明示 信頼信号を申告（自己検証になりうる） 検証の強度が違う
主体 エージェント + provider + ローカルツール 人間のキュレーター + エージェント + リンター 役割分担が必要
速度 高速・大量・ローカル・provider 依存 低速・少量・公開・可搬 同期させない
権限 合法な対象のみ、ローカル解析 公開前提、秘密は notes/ 漏洩リスクの管理が必須
エージェントとの関係 能動的な能力（MCP ツール） 受動的な文脈（ファイル） 組み合わせる

噛み合う点

  1. REA の Evidence は、知識バンドルの sources の理想形である。ただし丸ごと入れるのではなく、digest・コマンド・ツール版・対象識別子だけを参照にする。
  2. REA の「unknown」は、知識バンドルに欠けている欄である。概念本文に「Unknowns / Limitations」を標準で置くべきだという示唆になる。
  3. snapshot の無効化条件は、stale_after の良いモデルである。カレンダーだけで期限を切るのではなく、「対象が変わった」「ツールが変わった」「provider が変わった」を再検証トリガーにする。
  4. Attested Computation の executor / attester / receipt は、REA の Evidence と同系の「再現可能なレシート」思想である。計算の検証とバイナリの観測は対象が違うが、証跡の設計は似ている。
  5. REA の「最小十分な答えに、必要な来歴・範囲・限界を添える」方針は、知識バンドルの frontmatter + 本文の設計と方向が一致する。トークンと文脈を節約しつつ、来歴と限界を落とさない。

衝突する点

  1. サイズと機密 — REA の Evidence は数百 MB になりうる。知識バンドルは公開・可搬・小さいことが価値。生 Evidence を公開バンドルに入れてはいけない。
  2. 速度 — REA は活発に更新され、provider や対象の変化で結果が変わる。知識バンドルがその速度に追従すると、すぐ陳腐化する。ツールは最新に、バンドルは意図的に遅く。
  3. 結論の所有 — REA は観測を返すが、何を「知識」として採用するかは人間の判断である。REA の出力を自動で概念化すると、推論が事実として固定される。
  4. 自己検証 — 知識バンドルの verified は、REA の Evidence ほど強くない。特に同一主体の生成・検証は、社会的な信頼の申告であって証明ではない。
  5. 権限と法務 — REA は「合法な研究・教育・相互運用・保存・所有または許可されたソフトの解析」に限定される。公開バンドルには、逆解析の生データや第三者の機密を含めない。notes/ の秘密領域と、公開 okf/ の境界を明確にする必要がある。

付き合い方の原則

  1. REA を神託ではなく計測器として扱う。 出力は「現時点の観測」であり、結論ではない。
  2. Evidence の保管庫と知識バンドルを分ける。 生 Evidence はローカル/私有、公開バンドルには digest と要約だけ。
  3. 来歴を強くする。 対象の識別子（パス・SHA-256）、REA のバージョン、provider、操作、パラメータ、実行日を残す。stale_after は対象・ツールの変更に紐づける。
  4. 未知を明示する。 各概念に「Unknowns / Limitations」を置き、verified と confidence を混同しない。
  5. 再導出できるものは保存しない。 保存するのは、決定・解釈・否定的結果・権限・再検証手順。これは第 1 弾の「捨てる判断と監査」という結論と同じである。
  6. 型にマッピングする。 調査手順は Playbook、再現可能な検証は AttestedComputation、復元したインターフェースは APIEndpoint / APISchema、指標は Metric。
  7. 追従しない。 REA の更新は追うが、バンドルの語彙と結論は意図的に安定させる。バンドルは「速い道具の出力」ではなく「遅い判断の記録」である。

改善提案 — Investigation / Finding 型

REA との付き合いを本気で設計するなら、Investigation あるいは Finding という concept 型が候補になります。

フィールド 意味
target 対象の識別子（パス、URL、パッケージ名など）
target_digest 対象バイトのハッシュ
tool / tool_version / provider 使用した解析ツールと版
operation / parameters 実行した操作と引数
observed_at 観測日時
confidence 観測から結論への確信度
unknowns 未解決の問い
authorization 解析の根拠・範囲
evidence_ref 私有 Evidence への参照（内容は入れない）
stale_after 対象・ツールの変更で再検証する期限

これは「REA の Evidence を知識バンドルにコピーする」のではなく、Evidence と知識の間の契約書を作る試みです。既存の 6 型を無理に拡張するより、新しい型として切り出したほうが、スキーマの意味が濁りません。

ただし、今回は提案だけです。型の追加は、実際にその型を読む消費者が現れてからでよい、というのが第 1 弾からの一貫した立場です。

このサイトへの含意

現在の 6 概念は、テンプレートの足場としては妥当です。しかし、実世界の知識を扱うときは、次の 3 点を分けて考える必要があります。

  • 生成した人と検証した人を分ける。少なくとも、検証方法と証拠を残す。
  • 確認済みと真実を区別する。verified は採用判断の材料であり、結論ではない。
  • 未知を残す。分からないことを空欄にせず、明示的な問いとして書く。

知識バンドルの価値は、REA の複製ではなく、REA の実行を安く、安全に、繰り返せるようにすることにあります。問い・決定・限界・再検証条件を残すこと。それが、第 1 弾で言った「捨てる判断と監査」の具体的な中身です。

来歴と限界

項目 内容
生成 DeepSeek V4.1 Flash（opencode/deepseek-v4.1-flash-free）
生成日 2026-10-20
参照した外部資料 morluto/rea、AGENTS.md、docs/cli.md、docs/tool-design.md
検証 未実施（人間によるレビューなし。REA の実行検証もなし）
立場 モデルの意見。プロジェクトの公式見解ではなく、REA との提携もない
鮮度 モデル、REA、本プロジェクトの変更で陳腐化しうる

関連