メールというプロトコルは、AIアプリの最適なUIXかもしれない.

AIエージェントを組織に配布する際、デフォルトの課題は常に同じだ。アプリケーション導入、アカウント作成、使い方習熟という三段階の障壁があり、ここで大半のユーザーが脱落する。従来のAI UI設計では、Slack/LINE/専用アプリへの統一が「正解」と見なされてきた。だが提案は異なる。メールプロトコルこそが、AIエージェント配布の最適なUIなのではないか、という視点である。すでに全員が持ち、毎日開き、使い方を知っているメール。そこへAIエージェントを招待する。To/CC欄に agent@example.com を加えるだけで、スレッド参加者として最初から文脈を共有している状態が成立するのだ。

ここの逆転は深い。メールが「終わったUI」と貶められたのは、構造化入力（フォーム・ボタン）が得意でなかったからである。だがLLM時代、自然言語が直接インターフェースになると、その弱点が強みに反転する。加えてエージェント実行には数十秒から数分を要する。Webは200ミリ秒以下の応答を前提とするが、メール返信なら待機が自然だ。最後の勝負は実装コストの落差にある。新規アプリ導入ゼロで参加者密度100%を達成できるプロトコルは、メール以外に存在しない。To/CC欄に1アドレス足すだけで、全員が参加者になる仕組みの強度は過小評価されている。Message-ID、In-Reply-To、References という3つのヘッダが会話を木構造として永続化し、状態管理をメールクライアントが肩代わりする。ユーザーは何も覚えなくてよい。

技術的には catch-all メール受信で *@example.com のローカルパートをAPIパラメータとしてルーティング、Message-ID/In-Reply-To ヘッダで会話状態を管理、DKIM署名で送信ドメインの真正性を暗号検証する。つまりメールは単なる通知チャネルではなく、分散型アプリケーション基盤そのものなのだ。社内チーム・業界団体・地域コミュニティのAIエージェント配布を考える実務担当者にとって、メール中心の設計は「古い選択肢」ではなく「最強の選択肢」になりつつある。Slackやテレグラムに統一するより、メール返信という既存習慣に寄生するほうが、実装時間も運用コストも爆発的に低い。到達性とセキュリティの運用を疎かにしなければ、メールという40年前のプロトコルは、AI時代の最も優れた配布基盤になり得るのだ。