空音の由来と Web/A の契機 で、Sorane の実装が「ええい、面倒臭い。だったら自分でやってしまえ」という勢いから始まったことを書いたけれども、その勢いのままに作っているのが Web/A Form だ。
Web/A Form は、一言で言えば「入力フォーム機能を持った単一の HTML ファイル」だ。サーバーサイドのプログラムも、データベースも必要ない。HTML ファイルを相手に送るだけで、相手はブラウザで入力をし、その結果をファイルとして保存したり、メールで送り返したりできる。
「それって、ただの HTML フォームじゃない？」 「Excel 方眼紙を HTML にしただけでは？」
そう思われるかもしれない。しかし、Web/A Form には Excel や既存の PDF フォームにはない強力な機能がある。それが Layer 2 Encryption だ。
紙ExcelとPPAPの悪夢#
日本の行政や大企業の現場には、根深い「紙 Excel 問題」がある。 Excel で作られた調査票がメールで送られてくる。入力して印刷し、ハンコを押して郵送する。あるいは、Excel ファイルにパスワードをかけてメールに添付し、別のメールで「パスワードをお送りします」とやる（いわゆる PPAP）。
この運用がなぜなくならないのか。それは「手軽で、なんとなく安心感がある（と信じられている）」からだ。何億円もするシステムを導入しなくても、ファイルを送るだけで仕事が回る。
しかし、そのセキュリティは脆弱極まりない。Excel のパスワードは共有鍵（合言葉）であり、メールが盗聴されればパスワードも一緒に漏れる可能性が高い。それに、集める側は送られてきた大量の Excel ファイルを開き、パスワードを入力し、中身を転記して集計しなければならない。これは苦行だ。
Web/Aの「Layer 2」とは？#
「Layer 2 Encryption」と聞いて、「あぁ、OSI 参照モデルのデータリンク層（Ethernet や Wi-Fi）の話？」と思ったネットワークエンジニアの皆さん、ごめんなさい。Web/A における「Layer 2」は、それとは全く関係がない。
Web/A は、信頼できるドキュメントを作るために独自の「3 層構造（3-Layer Trust Architecture）」を持っている。
- Layer 1 (Issuer-Signed Core): 発行者が署名した「問い」や「枠組み」。アンケート用紙そのもの。
- Layer 2 (User-Signed Context): ユーザーが署名した「答え」や「入力データ」。ここに回答が入る。
- Layer 3 (Portable Presentation): それらをどう表示するかという「見た目」（HTML/CSS）。
つまり、Layer 2 Encryption とは、「ユーザーが入力したデータ (Layer 2) だけを 暗号化して送り返す」仕組みのことだ。 フォームの土台（Layer 1）は誰でも見られる状態でいいが、ユーザーの回答（Layer 2）は秘匿したい。だから Layer 2 だけを暗号化する。
受領者だけが開封できる「デジタル封筒」#
Web/A Form の Layer 2 Encryption は、この問題を 公開鍵暗号 によって解決する。
仕組みはこうだ。 フォームの作成者（調査の実施者など）は、あらかじめ自分の「公開鍵」を HTML ファイルの中に埋め込んでおく。これが「受領者だけが開けられる鍵穴」になる。
ユーザーがブラウザで入力し、「暗号化」をオンにしてデータを保存すると、Web/A はそのデータをこの公開鍵で暗号化する。 一度暗号化されたデータは、ユーザー本人でさえも二度と復号できない（ユーザー側の鍵で署名もしつつ、中身は見えないように封をする）。これを開けることができるのは、対になる「秘密鍵」を持った受領者だけだ。
つまり、入力済みの Web/A ファイルは、中身が透けない、受領者本人しか開封できない頑丈な封筒 に入った状態になる。
これなら、メールで平文のまま送ってもいいし、Dropbox や Google Drive に放り込んでもいい。なんなら掲示板に貼り付けたって構わない。秘密鍵を持たない中間者（メールサーバーの管理者や、誤送信先の相手）には、絶対に中身を盗み見ることができないからだ。
Excelよりも強く、SaaSよりも手軽に#
Excel のパスワード（共通鍵暗号）と違い、パスワードを別送する必要などない。 高価な SaaS や専用システムを導入しなくても、ただファイルを配るだけ で、金融機関レベルの強力な暗号化（X25519 + AES-GCM + HPKE）によるデータ交換が実現できる。
しかも、Web/A は単なる JSON データを出力するので、受け取った側はパスワード入力の手間なく、秘密鍵一発で大量のデータを復号し、CSV やデータベースにそのまますぐに取り込める。転記ミスも起きないし、文字化けや外字の問題も（前の記事 の通り）Sorane が解決してくれる。
デモ機能でお試しください
Web/A Maker には、この暗号化フローを体験できる「Personal Mode」を搭載した。「🔑 Setup Encryption (Passkey)」ボタンを押して自分の Passkey を登録すると、専用の暗号化フォームが作成される。暗号化されたファイルを再び読み込み、「🔑 Decrypt with Passkey」で復号する一連の流れを、実際に手元で試すことができる。
実は、Web/A Form の暗号化機能にはもう一つ、隠された（あるいは将来のための）強力な機能がある。それが 耐量子計算機暗号 (PQC) への対応だ。
現在使われている暗号技術（RSA や楕円曲線暗号）は、近い将来、量子コンピュータによって破られる可能性があると言われている。Web/A Form の L2 Encryption は、現在の標準的な暗号（X25519）に加えて、NIST によって標準化された PQC アルゴリズムである ML-KEM (Kyber) を組み合わせて使う「ハイブリッド暗号」をサポートしている。
「今の Excel ファイルを守るのに、そこまで必要？」と思うかもしれない。けれど、今日暗号化したデータが、10 年後に復号されて漏洩してしまう「Harvest Now, Decrypt Later」攻撃のリスクは現実のものになりつつある。 Web/A は、ファイルの配布者が「PQC も使う」と設定しておけば、ユーザーが意識することなく自動的に PQC で二重に鍵をかけてデータを守るようになっている。
「やってしまえ」の精神で#
「電子署名法がどうこう」「システムの調達がどうこう」と言っている間に、現場は今日も Excel を印刷し、PPAP でパスワードを送っている。 そんな現状を嘆くよりも、ブラウザで動く標準技術だけで「ほら、こうすれば安全で便利でしょ？」と動くものを見せてしまった方が早い。
Web/A Form は、そんな「vibe coding」の精神から生まれた、現場のためのツールなのだ。 暗号化機能をオンにするかどうかはオプションなので、普段は普通のアンケートとして使い、マイナンバーや口座番号のような機微な情報を扱うときだけ「暗号化」スイッチを入れる、といった運用もできる。
技術的には、最新の暗号技術（HPKE + PQC）を使いつつ、現場の運用は「ファイルを送るだけ」というレガシーな作法に寄せている。このギャップこそが、今の日本の DX に必要な「実用的な解」なんじゃないかと、わたしは思っている。