Verifiable Credentials × 知識グラフ：NEXT-PFIFの信頼・推論基盤

1 はじめに：なぜこの2技術が「非常に重要」なのか

PFIF 1.4の最大の設計思想は「データの追跡可能性」と「オリジナルリポジトリの権威」でした。しかし、AIが自動的に被災者レコードを生成する時代において、「誰が」「どのような根拠で」「どの程度信頼できる情報」を生成したかを、機械的に検証・追跡する仕組みが不可欠です。

ここで中心的役割を果たすのが、Verifiable Credentials（検証可能な証明書、VC）と知識グラフ（Knowledge Graph, KG）です。VCは「情報の信頼性を数学的に保証」し、KGは「断片的な情報を意味的に統合・推論」します。両者は独立した技術ですが、NEXT-PFIFではVCで検証された事実をKGのノードとして組み込み、推論の信頼性を担保するという形で深く連携します。

2 Verifiable Credentials（VC）の技術的深掘り

2.1 W3C標準の全体構造

VCはW3C勧告（Verifiable Credentials Data Model 2.0、2024年）として標準化されています。核心的なデータ構造は以下の3要素です。

2.2 VCのJSON-LD表現（具体例）

以下は、救助隊が被災者の所在を確認したことをVCとして発行した場合の具体例です。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://pfif.example/ns/disaster-vocab/v1"
  ],
  "id": "urn:uuid:7e76fdd7-6c1c-4b3c-82e0-9f1c8f9f7c3e",
  "type": ["VerifiableCredential", "DisasterStatusCredential"],
  "issuer": {
    "id": "did:web:firedept.tokyo.gov",
    "name": "東京消防庁 救助隊A"
  },
  "validFrom": "2026-08-28T09:14:00Z",
  "credentialSubject": {
    "id": "did:pfif:person/abc123",
    "type": "DisasterVictim",
    "fullName": "山田太郎",
    "currentStatus": "believed_alive",
    "location": {
      "type": "GeoCoordinates",
      "latitude": 35.6586,
      "longitude": 139.7454,
      "accuracyMeters": 15
    },
    "confirmedBy": "did:web:firedept.tokyo.gov",
    "confirmationMethod": "visual_contact_drone_thermal",
    "confidenceScore": 0.94
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-08-28T09:14:30Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:web:firedept.tokyo.gov#keys-1",
    "proofValue": "z58D...xYf2Q"
  }
}

2.3 DID（分散識別子）：VCの発行者・対象者を特定する鍵

VCの issuer.id や credentialSubject.id にはDID（Decentralized Identifier）が使われます。DIDは中央管理型のID（メールアドレスやURL）とは異なり、以下の特徴を持ちます。

• 自己主権性：個人・組織が自分のIDを生成・管理できる。
• 検証可能性：DID Document（DIDドキュメント）に公開鍵・サービスエンドポイントが記録され、ブロックチェーンや分散型台帳（DID Method）から解決できる。
• Methodの多様性：did:web（Webサーバー上のDID Document）、did:key（自己完結型、オフライン検証可能）、did:ion（Bitcoin上のSidetree）等。

NEXT-PFIFにおけるDID設計案

2.4 オフライン検証：災害時の最重要要件

通信インフラが破壊された被災地では、VCを「オンラインで発行者のサーバーに問い合わせて検証する」ことはできません。ここで重要になるのがオフライン検証可能なVCの設計です。

オフライン検証の技術的実現方法

1. 事前配布された発行者公開鍵：救助隊の端末に、信頼する発行者（消防庁・警察等）の公開鍵を災害前にキャッシュしておく。did:webのDID Documentを事前にダウンロードし、有効期限（cacheUntil）を設定。
2. 自己完結型Proof（did:key + 埋め込み公開鍵）：did:keyはDIDそのものが公開鍵のハッシュであるため、DID Documentを外部から取得する必要がありません。DID文字列だけで公開鍵が復元でき、完全にオフラインで署名検証が可能です。
3. VCの持ち運び（QRコード・NFC・BLE）：被災者が自身のVC（避難所受入証明等）をスマートフォンに保存し、救助隊員の端末にQRコード・NFC・Bluetooth Low Energyで提示。端末内で署名検証を完結。
4. ステートメント証明（Status Listのオフラインキャッシュ）：VCの失効状態を示すStatus List（W3C VC Bitstring Status List）も、定期的に端末に同期しておくことで、オフラインで「このVCは失効していないか」を確認できます。

2.5 ゼロ知識証明（ZKP）との融合：プライバシー保護検証

VCは「内容をそのまま開示」する形式ですが、災害時には「年齢が65歳以上であること」のみを証明したいが、「正確な生年月日」は開示したくない、という場面があります。ここでBBS+署名やCoconut credentialsなどのZKP対応VCが活きます。

2.6 VCの信頼フレームワーク：Trust Registry

「署名が数学的に正しい」ことと「発行者を信頼する」ことは別問題です。災害時に突然現れた「自称救助隊」のVCを受け入れるべきか？　ここでTrust Registry（信頼レジストリ）が必要です。

• 階層的Trust Model：内閣官房がTrust Registryのルートを管理し、各都道府県・消防本部・警察署のDIDを登録。救助隊員のDIDは消防本部のVCで認証されたもののみ有効。
• 災害時の動的Trust Onboarding：隣接県からの応援隊や自衛隊、海外救援隊（USAR等）のDIDを、災害発生時に緊急登録する仕組み。事前登録に加えて、災害宣言時の動的追加が必要です。
• Trust Registryのオフライン配布：Trust Registry自体を、災害前に全国の端末に分散キャッシュ（CRDT等で同期）しておく。

2.7 VCの失効・更新・履歴管理

災害時の状況は刻一刻と変わります。「生存確認済み」のVCが、後に「死亡確認」のVCで上書きされることもあります。

• Bitstring Status List（W3C標準）：VCの失効状態をビット列で管理。1つのStatus List VCで数万件のVCの失効状態を表現でき、帯域を節約。
• 履歴VCチェーン：同一被災者に対するVCを、previousVersion リンクで連鎖させる。KG側で「最新の有効なVC」を追跡。
• 有効期限の短縮化：災害時はVCの validUntil を24時間〜72時間に設定し、陳旧情報の蔓延を防ぐ。

3 知識グラフ（KG）の技術的深掘り

3.1 RDF/OWL vs Property Graph：どちらを選ぶか

知識グラフには大きく2つのパラダイムがあります。NEXT-PFIFでは、両者を使い分けるハイブリッドアーキテクチャが現実的です。

3.2 災害救援ドメインのオントロジー設計

NEXT-PFIFのKGを支えるオントロジーは、以下の主要クラス・プロパティで構成されます。

@prefix pfif: <https://pfif.example/ontology/v1/> .
@prefix sio: <http://semanticscience.org/resource/> .
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

pfif:DisasterVictim a owl:Class ;
  rdfs:subClassOf foaf:Person ;
  rdfs:label "災害被災者" .

pfif:RescueTeam a owl:Class ;
  rdfs:label "救助隊" .

pfif:Shelter a owl:Class ;
  rdfs:label "避難所" .

pfif:confirmedAt a owl:ObjectProperty ;
  rdfs:domain pfif:DisasterVictim ;
  rdfs:range pfif:Shelter ;
  rdfs:label "確認された場所" .

pfif:hasStatus a owl:DatatypeProperty ;
  rdfs:domain pfif:DisasterVictim ;
  rdfs:range xsd:string ;
  rdfs:label "安否状態" .

pfif:requiresAssistance a owl:DatatypeProperty ;
  rdfs:domain pfif:DisasterVictim ;
  rdfs:range xsd:boolean ;
  rdfs:label "支援要否" .

pfif:hasFamilyMember a owl:ObjectProperty ;
  rdfs:domain pfif:DisasterVictim ;
  rdfs:range pfif:DisasterVictim ;
  rdfs:label "家族関係" .

pfif:locatedAt a owl:ObjectProperty ;
  rdfs:domain pfif:DisasterVictim ;
  rdfs:range geo:Point ;
  rdfs:label "所在位置" .

pfif:confirmedBy a owl:ObjectProperty ;
  rdfs:domain pfif:DisasterVictim ;
  rdfs:range pfif:RescueTeam ;
  rdfs:label "確認者" .

pfif:hasCredential a owl:ObjectProperty ;
  rdfs:domain pfif:DisasterVictim ;
  rdfs:range <https://www.w3.org/2018/credentials#VerifiableCredential> ;
  rdfs:label "関連VC" .

3.3 推論エンジン（Reasoner）の役割

OWL Reasoner（Pellet, HermiT, RDFox等）は、明示的に記述されていない事実を論理的に導出します。

推論の具体例

3.4 時空間推論：災害KGの核心

災害KGの最も重要な特徴は、「時間」と「空間」がファーストクラス概念であることです。

時間オントロジー（OWL-Timeの拡張）

W3C OWL-Timeを拡張し、災害特有の時間概念を表現します。

• ValidTime（有効時間）：「Aさんが避難所Xにいた」という事実が成り立つ時間区間。
• TransactionTime（記録時間）：その事実がシステムに登録された時間。
• DisasterPhase（災害フェーズ）：発災直後・避難期・復旧期等のフェーズ概念。同じ行動でもフェーズによって解釈が変わる（例：発災直後の「建物内」は要救助、復旧期の「建物内」は自主避難）。

空間推論（GeoSPARQL）

OGC GeoSPARQL標準を用い、以下の空間推論を実行します。

• sfWithin（包含）：Aさんの位置が「浸水区域」内にあるか。
• sfIntersects（交差）：救助隊の進行ルートと土砂崩れ区域が交差するか。
• sfBuffer（バッファ）：Aさんの最後の確認位置から半径500mの探索範囲を生成。
• sfDistance（距離）：被災者と最も近い救助隊の距離を計算し、優先順位付け。

3.5 大規模KGの実装技術スタック

3.6 LLM + KG：RAGの強化と「幻覚」対策

生成AI（LLM）をKGと組み合わせることで、以下の強化が可能です。

KG-augmented RAG（GraphRAG）

従来のRAGは「文書をベクトル化して類似検索」でしたが、GraphRAGではKGの構造を検索に活用します。

• Entity Linking：LLMの出力中の「山田太郎」をKGのノード pfif:DisasterVictim/abc123 に紐付け。
• Subgraph Retrieval：質問「山田太郎の家族はどこにいるか？」に対し、KGから「山田太郎」ノードの1-hop（家族関係）サブグラフを抽出し、LLMのコンテキストに注入。
• Fact Checking：LLMが生成した回答がKGのトリプルと矛盾しないかを、推論エンジン検証。

LLMによるKG構築（Inverse Direction）

逆に、LLMを使って非構造化テキスト（SNS投稿・119通報・ニュース記事）からKGのトリプルを自動抽出することも可能です。

4 VC × KG の連携アーキテクチャ

4.1 連携の基本概念

VCとKGは以下のように連携します。

4.2 VCをKGの「信頼付きエッジ」として扱う

KGのエッジ（例：Aさん --[confirmedAt]--> 避難所X）に、VCのURIをプロパティとして付与することで、「この関係はどのVCによって裏付けられているか」を追跡できます。

pfif:DisasterVictim/abc123 pfif:confirmedAt pfif:Shelter/shinjuku-01 ;
  pfif:hasEvidence <urn:vc:7e76fdd7-6c1c-4b3c-82e0-9f1c8f9f7c3e> .

<urn:vc:7e76fdd7...> a <https://www.w3.org/2018/credentials#VerifiableCredential> ;
  pfif:issuerTrustScore 0.98 ;
  pfif:verificationMethod "Ed25519Signature2020" ;
  pfif:verifiedAt "2026-08-28T09:14:30Z"^^xsd:dateTime .

これにより、KGの推論エンジンは「信頼度0.98の消防庁VCによる確認」と「信頼度0.45のSNS投稿由来の未確認情報」を区別して扱えます。

4.3 信頼度の伝播（Trust Propagation）

KG上で、VCの信頼度が関係性を通じて伝播するモデルを設計できます。

伝播ルールの例（Datalog表現）

(1) trust(person, "location", T) :- 
      VC verifies person.location,
      VC.issuerTrustScore >= T.

(2) trust(person, "family", 0.8 * T) :-
      trust(person, "location", T),
      person.hasFamilyMember(family),
      family.lastConfirmedAt == person.lastConfirmedAt.

(3) inferredRisk(person, "high") :-
      trust(person, "location", T), T > 0.7,
      person.locatedAt geo:within DisasterZone.flooded,
      person.hasStatus "believed_alive",
      person.requiresAssistance true,
      now - person.lastConfirmed > 12 hours.

ルール(2)は「Aさんの所在が高信頼度で確認されていれば、同じ場所にいる家族の所在も間接的に信頼できる（ただし信頼度は減衰）」という推論を表します。

4.4 プライバシー保護されたままのKG推論

VCにZKP（BBS+等）を用いる場合、KG側で「属性の存在」を知りたいが「属性の値」を知りたくない、という要求が生じます。

• 匿名化ノード：KG上では pfif:DisasterVictim/_anon_001 のような匿名IDで管理。実名・生年月日はVC内にのみ保持。
• 選択的開示トリプル：ZKPで「65歳以上である」という証明だけをKGに提出し、「正確な年齢」は開示しない。
• 安全な推論（Secure Multi-Party Computation, SMPC）：複数の組織（自治体A・自治体B・医療機関）が、データを開示せずに共同でKG推論を実行。例えば「避難所Aと避難所Bの重複被災者数」を、個人情報を開示せずに計算。

5 実装上の課題と推奨アーキテクチャ

5.1 技術スタックの統合提案

5.2 災害時の運用フロー（統合シナリオ）

5.3 課題と対策のまとめ

6 まとめ：VC × KG が NEXT-PFIF にもたらすもの

参考文献・技術仕様

• W3C Verifiable Credentials Data Model 2.0 — VCの公式標準
• W3C Decentralized Identifiers (DID) 1.0 — DIDの公式標準
• W3C OWL 2 Web Ontology Language — OWLオントロジー標準
• OGC GeoSPARQL — 地理空間推論標準
• W3C OWL-Time — 時間オントロジー
• BBS+ Signatures (DIF) — ZKP対応署名
• Veramo — VC発行・検証フレームワーク
• ACA-Py — Aries Cloud Agent Python
• neosemantics (n10s) — RDF→Neo4j連携
• RDFox — インメモリ高速推論エンジン
• Microsoft GraphRAG — KG-augmented RAG