更新履歴

  • 2025-12-26: 初版発行
  • 2025-12-29: Layer 2 Encryption (L2E) による回答データの機密性保護について追記
  • 2025-12-30: 返信メタデータと返信ポリシー、Folio保存形式を追記

1. はじめに：SaaSモデルの限界と「隙間」の業務

業務のクラウド化が進み、固定メンバーが日々利用する基幹業務やコミュニケーションツールにおいて、SaaS（Software as a Service）は最適解となりました。 しかし、その一方で「SaaSモデルがなじまない業務」も明確になりつつあります。 特に、不特定多数の組織に対する調査や、頻度の低い申請業務において、IDベースの課金モデルやアカウント管理の手間が、デジタルの恩恵を阻害しています。

具体的な課題：だれにIDを渡せばよいのか？

例えば、自治体が管轄内の数千の事業所に対して「実態調査」を行うケースを考えます。 システム化のためにクラウド・フォームを採用しようとすると、以下の壁に直面します。

  • 担当者の特定困難: 照会の発出元は、相手組織の「誰」が回答担当者かを知りません。人事異動で担当者は毎年のように変わる場合もあります。そのたびに「ID発行依頼」を受け付け、管理するのは現実的ではありません。
  • 組織内コラボレーションの壁: 1つの調査票に回答するために、経理担当、現場責任者、法務担当など、組織内の複数人が関与する場合があります。1つのIDを使い回すのはセキュリティリスクがあり、かといって全員分のIDを発行するのはコストも手間もかかります。
  • コスト対効果の不均衡: 「年に1回」しか提出しない書類のために、年間を通じたサブスクリプション費用を支払うことは、財政的に正当化しにくいものです。

Web/A Form は、こうした**「SaaSの隙間（エアポケット）」**にある業務を、最もシンプルで汎用的な技術——HTMLファイル——で解決する提案です。

2. Web/A Form とは何か？

Web/A Form は、単一の HTML ファイルとして動作する、サーバーレスなフォームアプリケーションです。 専用のランタイムや閲覧ソフトは不要。ブラウザさえあれば、PCでもタブレットでも動作します。

2.1. 仕組み：ファイルだから、自由になれる

  1. 配布 (Distribute): 管理者は「フォーム定義（Markdown）」から HTML ファイルを生成します。これをメール添付やWeb公開で配布します。「誰が担当か」を知る必要はなく、組織の代表窓口にファイルを投げるだけで済みます。
  2. 回覧・入力 (Circulate & Input): 受け取った組織内では、ファイルをメールやチャットで自由に回覧できます。「経理部分はAさん、現場部分はBさん」といった連携も、ファイルをリレーするだけで完結します。アカウント設定は一切不要です。
  3. 保存 (Freeze & Bake): 入力が完了したら「保存」ボタンを押します。アプリケーションは現在の入力値を HTML 属性として焼き付け（Bake）、スクリプトを無効化した**「静的な Web/A 文書」**として再出力します。
  4. 提出 (Submit): 保存されたファイルを、指定された方法（メール返信やアップロードフォーム）で提出します。

2.2. Web/A Maker: 誰でも作れるフォーム

Markdown ベースの定義ファイルにより、高度なバリデーションや計算式を含むフォームを容易に作成できます。 行政の複雑な申請書から長期計画策定まで、あらゆる帳票をデジタル化可能です。

2.3. 既存資産からの高速移行：AIによる変換

組織内には「紙Excel」と呼ばれる大量の帳票資産が眠っています。これらの移行コストを最小化するために、LLM (大規模言語モデル) の活用を推奨します。

  1. テキスト化: Microsoft markitdown 等のツールで、Excelファイルを汎用的なMarkdownに変換します。
  2. Web/A化: LLMに対し「このMarkdownをWeb/A記法に変換せよ」と指示します。
  3. ロジック実装: LLMは表の構造から意図を読み取り、[calc:sum] のような計算式や、必須入力チェックを自動的に提案・実装します。

このプロセスにより、手作業での再設計を行うことなく、既存の業務フローを維持したまま、媒体を「Excel」から「Web/A」へスムーズに移行できます。

3. Web/A Form が提供する3つの価値

3.1. Zero Admin (管理コストの極小化)

Web/A Form は、利用にあたってユーザー登録やログインを必要としません。 「ファイルを送る」こと自体が、アプリケーションへのアクセス権の付与と同義になります。 これにより、発出元は膨大なID管理業務から解放され、回答側も「パスワードを忘れた」「担当者が変わってログインできない」といったトラブルから解放されます。

3.2. Machine Readable First (データ入力の民主化)

Excelファイルでの調査票回収で起きがちな「セル結合によるデータ崩れ」や「勝手な行追加による集計不能」は起きません。 Web/A Form は、見た目は人間が見慣れた帳票ですが、裏側には厳格な構造化データ (JSON-LD) が埋め込まれています。 回収したファイルからスクリプトで一括してデータを抽出でき、RPAや基幹システムへの連携もスムーズです。

3.3. Logic Embedded (Excelの利便性をWeb標準で)

現場がExcelを好む理由は、その場で見栄えを整えられ、計算もできる機能性にあるからです。 Web/A Form は、Web標準技術（HTML/CSS/JS）でこれを再現・強化します。

  • 自動計算: 合計や消費税計算などをリアルタイムに実行。入力ミスを未然に防ぎます。
  • 動的テーブル: 行の追加・削除が自由自在です。
  • マスター参照: 外部データを埋め込み、数千の選択肢からサジェスト入力が可能です。

3.4. オプション暗号化（L2 Encryption）

Web/A Form は、任意オプションとして L2（回答データ）を暗号化できます。これにより、フォームの提出ファイルが第三者に渡っても、受領者の鍵がない限り中身は読めません。
暗号化はオン/オフを選べる設計であり、既存の運用を壊さずに機密性が必要なフォームだけを保護できます。

実現できること:

  • 回答データの秘匿（受領者のみが復号可能）
  • テンプレートとの強い紐付け（回答の差し替え攻撃を抑止）
  • PQC（ML-KEM）への段階的移行に備えた設計

3.5. 返信メタデータと返信ポリシー

Web/A Form の提出は「片方向」に閉じることが多いため、返信が必要なケース では、返信先メタデータと返信ポリシーを明示的に定義します。

3.5.1. 返信先メタデータ

送信メッセージに reply_to メタデータを含め、少なくとも以下を定義します。

  • did: 返信先の DID（送信者識別）
  • endpoint: 返信先エンドポイント（HTTPS / DIDComm / ファイル投函先など）
  • broker_id: ブローカー経由の場合の識別子（任意）
{
  "message_id": "msg_01H...",
  "thread_id": "thr_01H...",
  "reply_to": {
    "did": "did:web:example.org",
    "endpoint": "https://example.org/weba/reply",
    "broker_id": "broker:weba-primary"
  }
}

3.5.2. 返信先が不明なケース

返信先が提供されていない場合、以下のいずれかを明示します。

  • ブローカー経由返信: broker_id のみを指定し、ブローカーが宛先を解決
  • 返信不可（片方向）: 返信不能であることを UI に明記

3.5.3. 返信時の認証方式

返信の真正性と機密性を担保するため、次の構成を標準とします。

  • 送信者 DID 署名: 元の提出者が返信主体であることを証明
  • 受信者署名（応答署名）: 返信側が受領・応答した事実を証明
  • L2E 再暗号化: 返信本文を返信先の公開鍵で再暗号化

3.5.4. 返信経路のスコープ

返信は「どこまで許可するか」をスコープとして明示します。

  • チャネル制約: 同一チャネルのみ返信可能（メール返信のみ等）
  • 期限付き返信: expires_at を設定し、期限超過は拒否
  • 代理返信: 代理応答を許可する場合は delegation: allowed を付与

3.5.5. Folio 側の保存形式

Folio では message_id と thread_id を軸に履歴を関連付けます。

  • message_id: 個別メッセージの識別子（重複不可）
  • thread_id: 一連のやり取りを束ねる識別子
  • reply_status: pending / sent / failed の状態

メタデータの一例:

{
  "message_id": "msg_01H...",
  "thread_id": "thr_01H...",
  "reply_status": "pending",
  "reply_to": {
    "did": "did:web:example.org",
    "endpoint": "https://example.org/weba/reply"
  }
}

3.5.6. 返信不能時の UX

返信不能時は「なぜ返信できないか」を明確に伝えます。

  • 通知: 返信先不明／期限切れ／認証失敗を明示
  • 次善策: ブローカー経由や別チャネルへの誘導を提示
  • ログ: Folio の履歴に失敗理由を保存

4. 比較：業務特性に応じた使い分け

特徴 Web/A Form 固定業務向けSaaS 一般的なアンケートフォーム
最適な対象 不特定多数の組織、低頻度業務 特定の従業員、日常業務 コンシューマー向け簡易調査
ID管理 不要 (ファイル依存) 必須 (厳格な管理) 不要 (ただし途中保存困難)
作業分担 容易 (ファイル回覧) ID単位での権限設定が必要 原則1人での回答
コスト構造 作成費のみ (ランニング0) ユーザー数 × 月額 回答数従量 or 定額
データ構造 JSON-LD (標準化) サービス固有DB CSV (フラットデータ)

5. データの回収と集計戦略

ファイルとして分散したデータを、いかに効率的に統合するか。Web/A Form はそのための「インターフェース」を内包しています。

5.1. ローカル・バッチ処理（小規模・個人向け）

数百件程度のファイルであれば、特定のフォルダに集約し、単純なスクリプト（PythonやNode.js）を実行するだけで十分です。 Web/A ファイルは標準的な JSON-LD を含んでいるため、複雑なスクレイピングは不要です。ごく短いコードで、すべてのファイルを読み込み、1つの CSV や Excel ファイルに変換できます。

5.2. ドロップ・ゾーン（中規模・組織向け）

メール収集が繁忙な場合、シンプルな「アップロード専用サイト（ドロップ・ゾーン）」を用意します。 ユーザーは作成した HTML ファイルをドラッグ＆ドロップするだけで提出が完了します。 サーバー側では、受け取った HTML から即座に JSONデータを抽出し、データベースに格納します。Web/A はバリデーション済みデータしか出力しないため、サーバー側のチェック処理も大幅に簡素化できます。

5.3. AI エージェントによる自律集計（大規模・先進的）

将来的には、人間がメールを開封する必要すらないかもしれません。 Gemini や Claude といった AI エージェントが、受信トレイの Web/A 添付ファイルを自動的に検知・読み取りし、基幹システムへの登録や集計レポートの作成を自律的に行います。 「人間が見るための帳票（HTML）」と「AIが読むためのデータ（JSON）」が同居する Web/A は、AI エージェントにとって最も扱いやすい入力フォーマットとなります。

6. 導入上の留意点と制約

Web/A Form は万能ではありません。ファイルベースゆえの制約を理解した上で適用する必要があります。

6.1. 作業途中データの扱い（端末依存性）

SaaS と異なり、入力中のデータはクラウドではなく「ユーザーのブラウザ（ローカルストレージ）」に自動保存されます。

  • 制約: 自動保存された「書きかけの状態」は、その作業を行っている端末（ブラウザ）の中にしか存在しません。配布された元の HTML ファイルをメールで転送しても、入力中のデータは引き継がれません。
  • 対策: 作業場所を変える場合や、他者に作業を引き継ぐ場合は、「作業保存（Save Draft）」ボタンを使用します。これにより、現在の入力状態を保持した新しい HTML ファイルが生成・ダウンロードされます。この「下書きファイル」を共有することで、別の端末でも作業を継続できます。

6.2. ファイルサイズの肥大化

すべてのリソース（画像、スクリプト、フォント）を1ファイルに埋め込むため、高解像度の写真を大量に添付するとファイルサイズが数MB〜数十MBになる可能性があります。

7. 結論：適材適所のデジタル化

DX（デジタルトランスフォーメーション）は、すべての業務を一律に同じツールでカバーすることではありません。 固定メンバーによる高頻度な業務には SaaS が最適であり、流動的なメンバーによる低頻度・多組織間の業務にはファイルベースのアプローチが適しています。

Web/A Form は、ファイルの手軽さとWebの堅牢性を融合させることで、これまで SaaS ではカバーしきれなかった「業務の隙間」を埋め、全体最適を実現するための現実的かつ効果的なソリューションです。