JMAPが描くメールの未来

Transcript

1. JMAPが描くメールの未来 tascript @Fukuoka.go 2026/07/21
2. tascript(たすくん) •森 亘(もりた わたる) • さくらインターネット研究所 • 研究開発エンジニア 足 田 • おしゃれは 元から
3. いまやっていること • Webメールに関する研究および開発 • メールクライアントとメールサーバー間のデータ同期プロトコルにJMAPを採 用 心 • JMAPとはなにか？を中 にお話します
4. さくらインターネット研究所サイト • メールに関するブログも掲載していますので てもらえると嬉しいです 見 • https://research.sakura.ad.jp/
5. JMAPとは
6. JMAP(JSON Meta Application Protocol) • JSONを いたデータ同期プロトコル • メール、カレンダー、アドレス帳などのデータをJSONで管理 • 効率的なデータ同期と操作が可能 • RFC 8620にて標準化、RFC 8621でメール のデータモデルを定義 用 心 用 • 今回はRFC 8621のJMAP for Mailの話が中
7. JMAPの特徴 • Web APIを提供(HTTP/JSON) 取得、作成、検索、変更検知などをAPIで 意 構造化されたJSONオブジェクトで結果を取得できる • 複数のAPI呼び出しを1リクエストにまとめる 複数の操作を1リクエストで実現 ラウンドトリップの削減 • 統 されたデータモデル 用 一 メールをオブジェクトとして取り扱う メールのメタ情報をJSONオブジェクトで表現
8. 用 メールアクセス プロトコルといえば
9. • い歴史 RFC 1064(1988年 公開)を起源 改訂を経て2026年現在はRFC 9051(2021年 公開)として標準化 • 巨 なエコシステム 多くのメールクライアント、メールサーバーでサポートされている 用 い信頼性および多くの採 大 長 高 IMAPによるメールアクセスが主流 実績
10. なぜJMAPなのか？
11. 比 IMAPとJMAPを 技術的観点で 較
12. IMAPとJMAPの技術的な特徴 較 JMAP メールの操作 コマンド Web API データフォーマット テキスト JSON ラウンドトリップ 増加 削減可能 比 IMAP
13. メールの操作
14. IMAPによるメールの操作 • コマンドベースでリクエスト シンプルかつ対話型 サーバーとの接続状態に依存(ステートフル) データフォーマットはテキスト クライアント実装が複雑化 IMAPのコマンド(省略)
15. JMAPによるメールの操作 • Web APIにリクエスト HTTP上でAPIにリクエストを送る ステートレス ラウンドトリップの削減 クライアントの実装が簡潔 JMAPのリクエスト(省略)
16. データフォーマット
17. IMAPのデータフォーマット • テキスト形式 クライアントはテキストの解析が必要 構造化データではないため取り扱いが 倒 面 IMAPで取得したメールのメタ情報(省略)
18. JMAPのデータフォーマット • JSON 構造化データを取得できる Goであれば標準ライブラリで処理可能 型情報を付与しやすい JMAPで取得したメールのメタ情報(省略)
19. ラウンドトリップ
20. IMAPのラウンドトリップ • 増加する 処理の度にリクエストとレスポンスが発 ネットワーク遅延環境に弱い モバイル環境だとボトルネックに 生 通信が複数回往復する
21. JMAPのラウンドトリップ • 削減可能 • 複数の情報を 括で取得できる • ネットワーク遅延環境に強い 複数の処理を 括でリクエスト • Webとモバイル双 で最適化 方 一 一 一 複数情報を 括で取得
22. JMAPの魅 • Web APIでメールを操作 IMAP JMAP メールの操作 コマンド Web API データフォーマット テキスト JSON ラウンドトリップ 増加 削減可能 シンプルなメール操作 • 構造化データでメールを表現 クライアント実装がIMAPと 較して容易 • ラウンドトリップの削減できる 比 用 力 モバイルでもWebでも利 可能
23. JMAPの課題
24. エコシステムの規模 • JMAP対応メールサーバー(OSS) Stalwart、Cyrus IMAP Server、Apache Jamesなど(2026年 現在) IMAP対応のメールサーバーより少ない ≒ JMAP対応を強く推しているメールサーバが少ない 新規開発する際の選択肢が限られる • 学習コスト RFCを読むことがメイン jmap.ioがJMAPの関連情報を発信(ありがたい) 実践的な情報がIMAPより少ない 自 ベストプラクティスは 分たちで模索する必要がある
25. データモデルの違い • IMAPとは異なるデータモデル Thread、Mailbox、 EmailSubmission など すべてをオブジェクトで表現する とはいえ慣れかも？
26. 用 JMAPを いて実現したいこと
27. 様々なデバイスで利 できるWebメール • Webでもモバイルでも利 できる Web APIベース ラウンドトリップの削減 • メールサーバーへの負荷軽減 JSONオブジェクトとブラウザストレージとの相性がよい IndexedDBにメールのメタ情報をキャッシュ 用 用 頻繁にメールサーバーと同期しなくてもよい
28. AIによるアシスタント機能(検証中) • RAGによるメール検索、メール返信アシスタント ベクトル検索と相性がよいのでは？ メールの構造を正しくAIに伝達することができる 生 用 メールのメタデータから埋め込みベクトルを (JSON)を利 できる 成する際も構造化データ
29. ワークスペース化 • カレンダーおよび連絡先との連携 • JMAPはメール、カレンダーおよび連絡先の同期に使 される • Stalwartは機能としてサポートしている • オールインワンのアプリケーション作成が可能 用 • メールの内容から予定を作成して連絡先にカレンダーを同期するなど
30. まとめ
31. これだけ覚えて帰ってください • JMAPはメールクライアントとメールサーバー間のデータ同期に利 できる • Web APIから構造化データ(JSON)を取得可能 • Webでもモバイルでも利 可能 用 用 • JSONオブジェクトでメールを管理できるのでAIとの相性もよさそう
32. 参考 献 • RFC1064: Interactive Mail Access Protocol - Version 2 https://datatracker.ietf.org/doc/html/rfc1064 • RFC 8620: The JSON Meta Application Protocol (JMAP) https://datatracker.ietf.org/doc/html/rfc8620 • RFC8621: The JSON Meta Application Protocol (JMAP) for Mail https://datatracker.ietf.org/doc/html/rfc8621 • RFC 9051: Internet Message Access Protocol(IMAP) - Version 4rev2 文 https://www.rfc-editor.org/rfc/rfc9051.html
33. Thank you for listening!! tascript @Fukuoka.go 2026/07/21