振り返ると最初に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や本格的な署名検証へと段階的に移行できる。