前提
なぜ、避難所なのか
この使い方が最も強く効くのが災害時の配給である。三つの条件が重なる。
① 名簿災害直後は名簿が作れない。誰がどの避難所に来るか事前に分からず、他市からも人が流れてくる。「事前に配る」方式が使えない。
② 通信災害時は回線が落ちる。この方式はもともと国（J-LIS）に問い合わせないので、オフラインで成立する。回線が死んでも動く。
③ リスク一回の配給は低リスク。失効確認の穴が問題にならない（紛失から悪用までの隙が、短期の配給では狭すぎる）。
平時の設計より、災害時にこそ効く。
「あったら便利」ではなく「これでないと難しい」領域にあたる。
要件
配給に必要なこと、七つ
| # | 要件 |
|---|
| 1 | カードが本物か（政府発行の証明書か）を確かめる |
| 2 | 鍵が一意か（一人一枚に対応）を確かめる |
| 3 | 複製・使い回しでない（その場で署名した）ことを確かめる |
| 4 | 「この一意な人が、一回受け取った」を記録する |
| 5 | 記録に誰かを残さない（氏名・住所を出さない） |
| 6 | 複数拠点で、同じ人の二重受給を防ぐ |
| 7 | これらがオフラインで動く |
切り分け
三つのバケツ
七つの要件を、実現の重さで分ける。大半は、誰の許可も要らず今日作れる。開発者に頼む必要があるのは、ごく一部にとどまる。
A ― 今日できる。アプリ開発だけ（誰の許可も要らない）
- 1 真正性：証明書チェーンをオフラインで検証する。J-LIS の認証局の公開鍵は公開されているので、事前にダウンロードしておけば回線なしで確かめられる。
- 2 一意性：カードから公開鍵を読む。カードごとに違う。
- 3 複製防止：毎回ちがうチャレンジをカードに署名させる。手元に既にある雛形（AgeGateApplet）がこれをやっている。
- 5 軽いプライバシー：利用者証明用の証明書を使えば個人情報を含まない。記録に残すのは公開鍵をハッシュした値ひとつだけ。カード本人からは辿れるが、記録から個人には戻せない。
- 4・7 単一拠点の記録／オフライン：一つの避難所の端末に「受け取り済みハッシュ」を記録する。上記すべて回線不要。
B ― 今日できる。ただし設計判断が要る（中央 か チェーン か）
- 6 複数拠点の二重防止。三つの選び方がある。
・中央サーバ：一番簡単。ただし単一障害点で、通信が要る。
・Cardano L1 で信頼不要に：現行カードの署名は RSA なので、7/18 の Van Rossem（CIP-109）でオンチェーン検証が今日できる。validator が「この鍵は受け取り済み」を拒否できる。ただし公開鍵が台帳に載る＝一意な識別子が公開される（氏名は出ないが、同じ人だと分かる）。
- 6＋5 強いプライバシー付きの複数拠点：理屈上は ZK で、公開鍵を隠したまま「一意な誰かが一回」だけを示せる（Cardano L1＋CIP-381、zkFold と同じ型）。ただし避難所では、これは現実的でない。次節のとおり、証明の生成が重すぎてスマホで作れないためである。避難所のプライバシーは、上の A（利用者証明用＋ハッシュ）で足りる。
C ― 開発者・プロトコルに頼む必要がある
- Midnight 上でやりたい場合：Compact（Midnight の言語）は、今カードの署名を回路内で検証できない。→ 次節の依頼 1。
- 次期カード（2029・P-384）に備える場合：Cardano も Midnight も、次期カードの署名方式を読めない。→ 依頼 2。
- 失効を反映したい場合：これは頼んでも解けない（J-LIS に聞くしかない）。低リスク用途では割り切るのが前提。部分的な緩和として「奪われた」を後から共有する deny リストは、アプリ側で作れる。
いちばん大事な切り分け
現行カードで避難所の PoC を作るだけなら、開発者に何も頼まなくてよい。バケツ A（今日できる、アプリだけ）で、単一拠点なら完結する。複数拠点でも中央サーバか Cardano L1 で組める。
開発者に頼む話は「2029 年の次期カードに備える」ためのもので、着手を止めるものではない。
重さの所在
壁は「検証」ではなく「生成」にあった
この資料は当初、ZK を「証明の生成は端末側でやればいい、チェーンの制約ではない」と軽く書いていた。これは端末側の重さを見落としていた。ZK には非対称がある。
ZK 証明の非対称
WASM とシャーディングで、ブラウザ（PC）ではこの生成が回るようになってきた。しかしスマホの中では、まだ生成できないというのが現在地とされる。避難所で被災者が使うのはスマホである。ここに直撃する。
避難所にとっての結論
強いプライバシー（回数まで伏せる ZK）は、スマホで証明を作れない以上、避難所では成立しない。サーバで作れば秘密をサーバに渡すことになり、プライバシーの意味が薄れる。
だが困らない。避難所で守りたいのは「氏名・住所を出さない」程度で、それは重い ZK なしで足りる（利用者証明用の証明書＋公開鍵ハッシュ）。重い ZK は、そもそも過剰だった。
venue
だから、避難所に Midnight は要らない
理由が二つ重なる。どちらか一方でも、外す理由になる。
理由 1Compact（Midnight の言語）は、カードの署名を回路の中で検証できない。楕円曲線は JubJub だけで、ECDSA も RSA も無い（能力は下層の Rust にあるが、Compact 非公開・未監査）。
理由 2仮に検証できても、その ZK 証明の生成が重すぎてスマホで作れない（前節）。避難所の現場で回らない。
そして皮肉なことに、Midnight を外すと話がむしろ健全になる。避難所に必要なプライバシーは軽く、重い ZK は過剰だった。諦めて外すのではなく、最初から要らなかったものを外す。
では Midnight はいつ効くのか
「受け取った回数すら他人に数えさせない」「当局にだけ開示する」といった強い秘匿が本当に要る、別の用途で、かつ生成側の重さが解決したとき。避難所の配給は、そこまで要らない。今回の切り分けでは、Midnight は選択肢から外れる。
依頼
開発者に、具体的に何を頼むか
避難所に限れば、今すぐ頼む必要のあるものは無い。現行カードなら今日の道具で組める。頼む価値があるのは、次期カードに備える一点だけ。
依頼
宛先：Cardano（CIP プロセス）
NIST P 曲線（P-256 / P-384）の検証ビルトインを追加する CIP
P-256 はパスキー。P-384 は次期マイナンバーカード（2029 年度予定）。どちらも今の Cardano は読めない。現状、提案そのものが一件も存在しない。
前例は十分にある。Cardano は CIP-49 で secp256k1（Bitcoin／Ethereum 互換）を追加している。Ethereum はメインネットと L2 で P-256 を実装済み。そして「2029 年までに無いと次期カードに繋がらない」という外部の期限は、標準化の論拠として強い。
補足：現行カード（RSA）には Van Rossem／CIP-109 が既に効くので、この依頼は「将来」と「パスキー」のためのもの。避難所の着手には要らない。
Midnight への依頼は、この用途では取り下げ
当初はもう一つ「Compact から署名検証を呼べるように」という依頼を用意していた。避難所については取り下げる。前節のとおり、Midnight は理由が二つ重なって選択肢から外れたためである。
署名検証を Compact に公開する依頼が意味を持つのは、Midnight で強い秘匿が本当に要る、別の用途のときにあたる。避難所の切り分けからは外す。
境界
頼まなくていいもの
依頼を膨らませないために、これは開発者案件ではないと分けておく。
アプリ側でやること（プロトコルの話ではない）
- 証明書チェーンの検証、公開鍵の読み出し、チャレンジ署名 ―― 標準の暗号ライブラリでできる
- ハッシュで識別子を作って個人情報を伏せる ―― アプリの設計
- 単一拠点の受け取り記録、オフライン動作 ―― アプリの設計
- deny リストの共有、後からの申告窓口 ―― 運用の設計
設計で選ぶこと（頼む相手がいない）
- 複数拠点の二重防止を、中央サーバでやるか／チェーンでやるか
- プライバシーを、どこまで守るか（避難所はハッシュ止まりで足りる。ZK は生成が重くスマホで回らない）
- どの証明書を使うか（利用者証明用＝個人情報なし、を推奨）
段階
作るなら、この順
第 0 段単一拠点・オフライン。カードをかざす→本物・一意・その場署名を確認→端末にハッシュを記録して配給。チェーンも開発者依頼も要らない。手元の雛形とリーダーで組める。
第 1 段複数拠点の二重防止。まず中央サーバで。信頼不要にしたければ Cardano L1（現行カードの RSA を CIP-109 で検証）へ。
第 2 段将来。次期カード（2029・P-384）に備えるなら、Cardano への CIP（依頼）。ここで初めて開発者に頼む。避難所の着手には要らない。
要するに
第 0 段は今日、誰の許可もなく始められる。強い ZK も Midnight も、この用途には要らない。開発者への依頼が意味を持つのは第 2 段（次期カード）だけ ―― 「動くものを見せてから頼む」順番になっている。これは標準化の通し方としても正しい（実物のない提案は通りにくい）。
限界
正直に、残る問題
- 法律。署名検証者の枠組みの外でマイナンバーカードの証明書を使ってよいか、シリアル番号の利用制限が及ぶか ―― 未確立。グレーゾーン解消制度で聞くべき論点。ここが黒なら、着手以前の話になる。
- 失効。オフラインでは反映できない。低リスクの配給という前提でのみ成立する。
- Midnight の成熟度。依頼 1 が実現しても、メインネットはまだ許可制で本番 dApp はゼロ。すぐ本番投入できる状態ではない。
- PIN の手間。署名には暗証番号の入力が要る。災害時の高齢者にどこまで負担か、現場で確かめる必要がある。
この一枚の位置づけ
実装計画ではなく、頼む先を明確にするための切り分けである。技術的な見立てを含む。ZK 証明の生成コスト（スマホで作れない）は伝聞に基づく現在地であり、生成側の高速化が進めば前提は変わりうる。法律の可否も未確認。