GAP GX AI Protocol — wire version gap/0.1

何を変えるのか

データが人間の手を経るたびに、証拠は失われる

従来の開示は、基幹システムから投資家に届くまでに集計・整形・再入力を通る。 最後に残るのは数値だけで、それがどの測定に由来するかを受け手が確かめる手段はない。

測られている数字

これは「解析がうまくなれば埋まる差」ではない

PDF は、ISO 32000-2:2020 の序文が掲げる目的からして 「デバイス・プラットフォーム・ソフトウェアに依存しない文書の忠実性の保存」のための形式であり、 制作段階は「最終利用者への配布のための最終状態の形式」と位置づけられている [S4]。位置は正確に保つが、その位置が何を意味するかは標準では運ばない。 その先で何が起きているかは、すでに測られている。

出典の詳細と確認範囲は evidence-sources.json にある。 これらは執筆中の書籍『証拠なき非財務情報』（三部作第3部）第7章 「PDF開示で失われる出所・座標・計算過程」の証拠台帳から、実際に引用した分を抜き出したもの。 同書は未公刊。

名前が指す 3 つの GAP

閉じようとしている断絶は 3 つある

Zero-Embellishment Constraint

非化粧制約 — 派生排出量を含む payload は受理しない

GAP が運ぶのは活動量に限る。metric および meta のキーに 派生排出量を示す語（co2 / co2e / ghg / emission / scope1|2|3 / tco2 / carbon_footprint）を含む payload は、 ノードが受理してはならない。

{
  "spec": "gap/0.1",
  "source_id": "jp-demo-plant-chiba-meter-01",
  "seq": 1,
  "metric": "electricity_kwh",
  "period_start": "2026-07-01T00:00:00Z",
  "period_end": "2026-07-01T01:00:00Z",
  "value": 812.4,
  "unit": "kWh",
  "quality": "measured",
  "prev_hash": null,
  "meta": { "line": "A", "tariff": "peak" }
}

{
  "spec": "gap/0.1",
  "source_id": "jp-demo-plant-chiba-meter-01",
  "seq": 1,
  "metric": "scope2_co2e_t",
  "period_start": "2026-07-01T00:00:00Z",
  "period_end": "2026-07-01T01:00:00Z",
  "value": 0.351,
  "unit": "tCO2e",
  "quality": "measured",
  "prev_hash": null,
  "meta": { "line": "A", "tariff": "peak" }
}

レイヤー構成

意味 / クエリ / 証明 の 3 層

MCP Tools

投資家側 Agent に見えるのはこの 6 つ

すべて read-only / idempotent。同一ロジックの REST も /api/v1/gap/* に用意されている。

検証可能性

実装は公開テストベクタで自己診断できる

正規化・ハッシュ・チェーン・署名の固定ベクタを配布している。 署名鍵は RFC 8032 §7.1 TEST 1 の公開テスト鍵で、実運用には使えない値を意図的に使っている。

{"metric":"electricity_kwh","period_end":"2026-07-01T01:00:00Z","period_start":"2026-07-01T00:00:00Z","prev_hash":null,"quality":"measured","seq":1,"source_id":"jp-demo-plant-chiba-meter-01","spec":"gap/0.1","unit":"kWh","value":812.4}

node scripts/health/gap-selftest.mjs   # 正規化・ハッシュ・署名のテストベクタ検証
node scripts/gap/e2e-local.mjs         # 署名 → ingest → 算定 → 検証 → MCP を一気通し

Granular Access Control

機密は「隠す / 全部見せる」の二択にしない

工場のリアルタイム電力は生産稼働率・原価に直結する機密になり得る。 GAP は時間粒度を落として開示し、落とした後も検証可能性を保つ（bucket_hash）ことで折り合いをつける。

engagement の source は grant がない鍵にも 存在だけは見せる（access.granularity = "none"）。隠すとエンゲージメントの入り口が消えるため。

効き方の見取り図

GAP が閉じる歪みと、閉じない歪み

「グリーンウォッシュ」という一語に潰されている現象は、少なくとも 8 つに分かれる [B1]。GAP が届くのは 3 類型で、そのいずれも「登録済みの記録を事後的に こっそり書き換える」という一経路に限られる。2 つは部分的、残る 3 つは通信規約が原理的に持つ 守備範囲の外にある [B2]。

v0.1 の意図的な非対応

やらないと決めていること

以下は v0.2 以降の論点として開いている。「できる」と書かないために列挙する。

• Zero-Knowledge Proof / 差分プライバシー — 現状の機密対応は時間粒度の粗視化まで。「生データを明かさずに正当性のみ証明する」までは踏み込んでいない
• 鍵ローテーションの手続き — public_key_hash を reading に記録しており過去分の再検証はできるが、ローテーション自体のプロトコルは未定義
• 複数ノード間のクロス検証 — input_hash により同一入力からの同一結果は照合できるが、ノード間の相互監査プロトコルはない
• Scope 3 / サプライチェーン連鎖 — 他社ノードの活動量を参照する連鎖構造は未定義。現状は 1 ノード内の source に閉じる
• ストリーミング購読 — 現状はポーリング。webhook / SSE による push は未定義
• 制度マッピング（CSRD / SSBJ / GHG Protocol） — GAP は活動量と係数を分離するだけで、どの制度のどの項目に対応するかの写像は持たない。写像は受け手側の責務とする

Status

いまどこにあるか

標準としての狙い

固定するのは 4 点だけ

個別企業がばらばらの MCP を実装すると、投資家側 Agent の統合コストが企業数に比例して増える。 GAP が固定しようとしているのは以下だけで、それ以外は各社の自由に任せる。

1. 署名対象のバイト列（正規化規則）
2. チェーンの張り方（prev_hash + seq）
3. Tool の名前と入出力の意味（6 tools）
4. 「排出量ではなく活動量を出す」という制約

この 4 点が揃っていれば、投資家側の 1 つの Agent 実装が、 どの企業の GAP Node に対しても同じコードで接続・検証・横断比較できる。