振り返ると最初に Python で実装した Sorane を公表したのは 2023 年 8 月頃だった。ちょうど GPT-4o あたりを使った vibe coding が流行り始めた頃で、わたしはマイナンバー紐付け誤り問題の善後策で氏名等の表記揺らぎ問題に直面し、行政事務標準文字を今後どうするかで悩んでいた頃だ。

大臣に行政事務標準文字の説明をしたところ「せっかくだからパソコンだけでなくスマホでも使えないのか」と聞かれ、担当者か「パソコンはフォントをインストールできるけど、スマホではできないので難しい」と応えるも「否、最近は WebFont とかもあるし、真面目に技術検証すればできるんじゃないの？」と気になり始めて、実証実験でもやるかといった話が浮上したものの、公共調達ともなれば半年がかりだし、みんな忙しくてどれだけ先になるか分からない。「ええい、面倒臭い。だったら自分でやってしまえ」と思い立って実装を試みたところ、思いのほか簡単にできてしまった。

なので、Sorane は大和言葉っぽい語感に漢字を当てて、それっぽい名前にしてはいるけれども、実際は「そら、ね。やればできるでしょ？」という軽いノリでつけた名前だったような気がする。IPAmj 明朝を WebFont に圧縮して怒られて、丸ごとだと重いので subsetting して、それはそれでライセンス上、元のフォントに戻せないから問題だと怒られて、PDF へのフォントの埋め込みは認められているのだから、HTML に DataURI で埋め込めば文句をいわれないだろうと今の方式に落ち着いたのだった。

本来そこまで意地になるべき話でもないが、もともと漢字の問題に深入りしたのは学生時代に Kondara MNU/Linux でいち早く UTF-8 ロケールによる I18N に取り組んだり、Windows Vista の発売準備で JIS X 0213:2004 対応で JIS2004 字形になると役所に説明に行ったところ CIO 補佐官に囲まれて、「点の数が変わっては困るから JIS90 字形に戻してくれ」と責め立てられて「いや JIS 規格って貴省の所管でいらっしゃいますよね」と腹を立てたあたりから始まっている。懇願されたところで古い規格に寄せる訳にもいかず、Windows 7 から Unicode IVS/IVD に対応したのだが、せっかく IVS をやるなら外字をなくすのに使おうじゃないかと IVS 提案者の故・樋浦秀樹さんから提案された矢先に、菅直人政権で市役所の窓口だけでなく霞が関が外字問題に悩まされることとなって、文字情報基盤の整備が軌道に乗ったのだった。

それからほどなくして東日本大震災が起こり、わたしが役所に入って少し経ってから政権交代を経てマイナンバー制度ができて、戸籍のマイナンバー対応に合わせて法務省が日本中の自治体から戸籍で使われている 163 万文字の外字を集めて文字同定を行ったことが行政事務標準文字を追加する契機となった。そして当時もう一つ大きな話題がオープンデータで、やれファイブスターだ、LOD だ、国のデータは全てオープンデータで提供すべきといった極論まで出てくる始末となって「いや、ニーズがあればデータクレンジングに投資をしてもいいかも知れないが、何に使うのか分かりもせずに投資するのは無理でしょう」と冷ややかに眺めることもあった。役所に入ってからはオープンデータを担当することになり、あまり当時と変わっていない議論に辟易しながらも、データを増やそうにもツールがないと、みんなが Excel しか使えない限りは CSV までしかいかないでしょう、けれども AI が出てくれば Markdown とか、読みもの系も重要になってくるのにどうするんだ？と頭を抱えていた。

そんな議論をしている間に分権提案で是非とも住民票の電子交付をやって欲しいという提案が出てきて、Verifiable Credentials の導入にも前向きな意見をいただいたのだけれども、Wallet 環境が整わないことには前に進まない。EU Digital Identity Wallet で一気に標準化が進むんじゃないかと期待することもあったけれども、標準化の動向を追っかけても混迷を極めるばかりで相互運用性が確保される見込みが立たない。

Machine Readable Data だって Selective Disclosure だって、世界中で騒ぎになっている PQC にしたって、鶏が先か卵が先かと堂々巡りの議論を続けて、口を開けて待っていたところで何も進まないじゃないか。まずはその依存関係を断ち切って、手元にあるものでどこまでやれるか試してみたらいいじゃないか。何百億円もする発行システムを新たに整備しようとかではなく、世の中で日々発行やれている明細やら領収書やら諸々の書類をまずは機械可読かつ改竄不可能な状況をつくってみたら何が起こるのか？とりあえず ssh とか pgp とか SSL くらいに簡単にできるようにしたらいいじゃん、色々課題はあるだろうけれども、やってみて考えたらいいじゃん、というノリでこの 10 日くらい Sorane を再実装していたところ、Typography とか Machine Readability やら PQC といった高尚な話題よりも手前に、わが国には紙 Excel 問題という根深い問題があったじゃないか！と再発見する契機が今週木曜日にあって、ここ数日で一気に実装を進める運びとなった。

ここから先は Web/A Form との統合をどう設計するかという話になる。ユーザーの入力を L2 として持ち、必要に応じて L2 を暗号化できるようにするのが現実的だと思っている。たとえばフォームの設定で「暗号化」を任意オプションとして用意し、オンにした場合は L2 ペイロードを受領者の公開鍵で暗号化して封筒化する。オンにしなければ従来通りの平文 L2 でよい。こうしておけば、既存の運用に大きな負担をかけずに「秘匿したい入力は秘匿する」という判断を現場に委ねられるし、受領側も鍵を持つ者だけが復号できる。いきなり WebAuthn や完全な HPKE 実装を前提にしなくても、まずは PoC として X25519 + AEAD のような最小構成で回し、必要になれば PQC や本格的な署名検証へと段階的に移行できる。