PFIF 1.4の終焉後、AI偏重の災害時行方不明者検索インフラはどう進化するか
PFIF 1.4は2012年以来更新され、Google Person FinderのGitHubリポジトリも2025年9月にアーカイブ化されました。しかし、災害時の行方不明者・被災者検索のニーズは消えていません。むしろ、AI・ドローン・センサーネットワークの進化により、「人が手動で入力する」時代から「AIが自動検知・統合する」時代へと大きく転換しつつあります。
本稿では、PFIFの設計思想を継承しつつ、2026年以降の技術的・社会的要件に対応する「NEXT-PFIF」時代の技術スタックを、AI偏重の観点も含めて考察します。
本稿の性質：これは既存の公式標準や製品仕様ではなく、PFIFの現状と次世代技術動向を踏まえた技術的予測・考察です。
NEXT-PFIFを考える前に、現行PFIF 1.4の構造的限界を整理します。
| 側面 | PFIF 1.4の現状 | 2026年の要求 |
|---|---|---|
| データ形式 | XMLのみ | JSON, Protocol Buffers, バイナリストリーミング |
| スキーマ | 固定25フィールドのperson + note | 拡張可能なスキーマ（医療情報、センサーデータ等） |
| 位置情報 | 住所テキストのみ | GeoJSON, WGS84座標, リアルタイムGPS軌跡 |
| 更新モデル | source_date/entry_dateによる静的同期 | イベントソーシング, CQRS, リアルタイム差分配信 |
| メディア | photo_url（外部リンクのみ） | 埋め込み画像・動画・音声・LiDAR点群 |
| AI対応 | なし（人間入力前提） | AI生成メタデータ, 信頼度スコア, 出典追跡 |
| プライバシー | expiry_dateによる削 | 差分プライバシー, 暗号化, ゼロ知識証明 |
以下、レイヤーごとに「NEXT-PFIF」にふさわしい技術スタックを予測します。
JSON-LD（セマンティックWeb対応）＋ GeoJSON（位置情報）＋ スキーマ拡張機構
XMLからJSON-LDへの移行は、現代のWeb APIの主流に沿うものです。JSON-LDは「リンクトデータ」をネイティブに表現でき、複数の被災者レコードの関連（家族関係、同一人物の複数情報源）を機械可読にします。
さらに、医療分野で実績のあるFHIR（Fast Healthcare Interoperability Resources）の拡張機構を参考に、災害特有のフィールド（避難所ID、要支援度、センサーデータUUID等）を柔軟に追加できるスキーマ設計が求められます。
Apache Kafka or Redis Streams（イベント配信）＋ gRPC（内部通信）＋ GraphQL（クライアントクエリ）
PFIFの「増分エクスポート（min_entry_date）」は、実質的にイベントソーシングの原型でした。NEXT-PFIFでは、ドローン・センサーAIが秒単位でデータを生成するため、イベントストリームとしてのリアルタイム配信が必須です。Kafkaのパーティショニングで「地域×災害種別」に水平分散し、自治体・救助隊・NGOが必要なストリームだけをサブスクライブするモデルが考えられます。
RDF/OWLオントロジー（災害救援ドメイン）＋ Property Graph DB（Neo4j等）
「この人は避難所Aにいた」「避難所Aは浸水した」「家族Bも同じ避難所にいた」という関係性を、単なるテキストではなく知識グラフとして管理することで、AIが論理的推論を行えるようになります。例えば、「避難所A閉鎖されたら、そこにいた人々の新たな所在を推定する」といった推論が可能になります。
差分プライバシー（Differential Privacy）＋ HE（準同型暗号） or TEE（Trusted Execution Environment）
PFIFのexpiry_dateは「期限切れで削除」という原始的な仕組みでした。NEXT-PFIFでは、集計・統計処理は可能だが個人特定は不可能な差分プライバシーを標準装備すべきです。また、救助隊間で位置情報を共有しつつ、外部には秘匿するための準同型暗号やTEE（Intel SGX等）の活も検討に値します。
W3C DID（分散識別子）＋ Verifiable Credentials
「この人が本当にその人か？」という問題は、災害時にさらに深刻化します。政府のマイナンバーカードや、自己主権型ID（Self-Sovereign Identity）の考え方を部分的に取り入れ、本人確認の信頼性を高める仕組みが求められます。ただし、インフラ障害時の可用性を考慮すると、中央集権的なIDよりもオフライン検証可能なVCの方が現実的かもしれません。
NEXT-PFIFの最大のパラダイムシフトは、データの主たる生成主体が「人」から「AI」に変わる点です。以下、AI偏重の各概念を整理します。
従来は「人がWebフォームに入力」することでレコードが生まれました。NEXT-PFIFでは、以下のソースからAIが自動的に被災者レコードを生成します。
重要：AI生成レコードには必ず「AI出典メタデータ」（モデル名、信頼度スコア、入力ソース、推論根拠）を付与する必要があります。PFIFのsource_name/source_urlを拡張した、機械可読な「provenance（来歴）」記述が不可欠です。
PFIFは「同じ人の複数レコードをマージしない」ことを推奨していましたが、AI時代には大規模・高速な重複検出が可能になります。
ただし、PFIFの設計原則「オリジナルリポジトリの権威」を維持するため、AIは「統合ビュー」を生成しても、元レコードは保持したままにすべきです。これは「読み取り時の仮想統合（read-time materialized view）」のアーキテクチャで実現できます。
noteレコードの「text」フィールドは、PFIF時代は人間が読むための自由記述でした。NEXT-PFIFでは、AIがこれをリアルタイムに解析します。
入力テキスト：「母（80歳・糖尿病）が2階に取り残されています。階段が崩れています。」
AI抽出：
AIの最も先端的な応用は、「まだ発見されていない人がどこにいるか」の予測です。
倫理的警告：「生存確率が低いから救助を諦める」という判断をAIが自動化してはなりません。AIは「情報支援ツール」であり、最終判断は常に人間が行うべきです。
政府が開発中のSIP4D-GAIは「被災者支援策提案」に留まりますが、NEXT-PFIFでは生成AIが以下まで担う可能性があります。
AI偏重の最大のリスクは幻覚（Hallucination）です。「存在しない被災者」を生成したり、「生存している人を死亡扱い」にしたりする可能性があります。
対策技術スタック：
「AI偏重」とは言っても、通信インフラが破壊された災害現場では、クラウド中心のAIだけでは機能しません。以下のような階層的ハイブリッドアーキテクチャが現実的です。
エッジ → ローカル：メッシュWi-Fi / LoRa / BLE（非同期・遅延許容）
ローカル → クラウド：Kafka Connect over Starlink（帯域適応的圧縮）
クラウド → ローカル：GraphQL Subscription（プッシュ型更新）
PFIFの最大の功績は「誰でも読めるオープン標準」でした。NEXT-PFIF時代、各企業・政府機関が独自のJSONスキーマ・APIを作ると、情報のサイロ化が進みます。W3CやOASISのような標準化団体よる早急な取り組みが必要です。
「AIが常にすべての人を監視し、位置を把握する」システムは、平時に転用されれば監視国家のインフラとなり得ます。「災害時限定」「目的外使用禁止」の技術的保証（スマートコントラクトやポリシー自動実行）が必要です。
スマートフォンを持たない高齢者・子供・外国人労働者は、AI検知の「死角」になります。従来の「人が入力する」仕組み（紙の安否確認ボード、避難所での口頭確認）をAIと並行して維持する必要があります。
「AIが生存確率10%と判断したから救助を諦めた」という事態を、誰が説明責任を負うのか。AIの判断根拠の開示、訴訟に耐える監査ログの設計が、技術スタックの一部として求められます。
クラウド集中型AIは、通信障害時に完全に機能不全に陥ります。前述のエッジ重視アーキテクチャと、オフラインで動作する軽量AIモデルの配備が不可欠です。
| レイヤー | PFIF 1.4時代 | NEXT-PFIF予測 |
|---|---|---|
| データモデル | XML, 固定スキーマ | JSON-LD, GeoJSON, 拡張スキーマ（FHIR風） |
| 同期方式 | min_entry_dateによる静的ポーリング | Kafka/Redis Streamsによるリアルタイムイベント配信 |
| 知識表現 | person + noteの単純関連 | Knowledge Graph, オントロジーによる推論 |
| データ生成 | 人間の手動入力のみ | AI自動検知（ドローン・センサー・SNS解析）+ 人間入力 |
| 重複処理 | 手動判断、マージ禁止 | AIフェイス認識・NLPによる自動重複検出、読み取り時仮想統合 |
| プライバシー | expiry_dateによる削除 | 差分プライバシー, 準同型暗号, TEE, ゼロ知識証明 |
| AIの役割 | なし | 動レコード生成, 予測, 支援コーディネーション, 幻覚対策（RAG, HITL） |
| アーキテクチャ | 中央集権型Webアプリ | エッジ・ローカル・クラウドの階層的ハイブリッド |
| 標準化 | Google主導のオープン標準 | W3C/OASIS等による多国間標準化が急務 |
結論：NEXT-PFIFは「PFIFの設計思想（追跡可能性・分散型・プライバシー）を継承しつつ、AI・センサー・リアルタイムストリーミングを統合した、オープンで検証可能な次世代災害情報インフラ」となるべきです。AI偏重リスクを「RAG・HITL・監査ログ」で抑制しつつ、人間とAIの協調による「拡張防災（Augmented Disaster Response）」を実現することが、2026年以降の技術的・社会的課題です。