最近数ヶ月、Discourse のさまざまなグループにおいて、受信メールの解析機能の改善を求める複数のリクエストが寄せられています。これらはユーザーストーリーとして表現すると、おおむね以下のカテゴリに分類できます：
- 「ウェブサイトで投稿する際と同じ HTML 機能を使って、メールで返信したい。」
- 「メーリングリストからのメッセージを表示し、検索したい。」
- 「メール返信や一括インポートを通じて作成されたコンテンツが、一貫して美しくフォーマットされ、正確に解析されるようにしたい。」
これらのリクエストの実際の例については後ほどリンクを貼りますが、現時点で理解しておくべき重要な点は、これら 3 つの「異なる」リクエストは、実際には同じ根本的なものを求めているということです。つまり、より正確な受信メールの解析です。
数ヶ月前、私は当社の提供する商用 メール解析 API を Discourse で利用可能にするよう @sam にメールを送りました。サムは、当社の API との統合が、Discourse の既存の受信メール解析ソリューションよりもどのようなメリットをもたらすか、また当社の API をプラグインとしてどのように統合できるかを説明するための探索的な投稿をここで作成することを提案しました。
私はこれら 2 つのトピックを詳しく取り上げますが、まずは Discourse の現在のメール解析ソリューションの現状から始めます。また、過去数年間メール解析について考えてこなかった方のために、この問題に関する背景情報もいくつか含めます。
この投稿は長いものになりますが、好きなところから読み進めていただいても構いません。以下にカバーする内容を示します：
- Discourse におけるメール解析の現状
- より優れたメール解析のメリット
- 利害関係者としてのユーザーペルソナ
- FWD:Everyone メール解析 API
A. シグネチャと返信の除去
B. HTML マークアップの正規化
C. 言語サポート
D. CSS によるスタイリング - 提案される統合方法
- API のテスト
Discourse におけるメール解析の現状
Discourse には、ユーザーからのメール返信をトピック内の新しいフォーラム投稿に変換する「メール返信」機能が既に存在します。この機能は以下のように動作します：
- ユーザーが監視しているフォーラムのトピックに関する新しい投稿を含むメール通知を受信します。
- ユーザーはそのメールに返信します。
- このメール返信が、関連するフォーラムのトピック内の新しい投稿に変換されます。
概念的には、これは非常に価値のある機能です。多くの人にとって好ましいワークフローであり、Discourse への移行を検討しているメーリングリストベースのコミュニティにとって必須の機能です。
しかし、問題点は、これらのメール返信がフォーラム投稿に変換される際、フォーマットが欠落したり誤っていたり、あるいはテキストそのものが欠落していることがよくあることです。これは、後で詳しく説明する理由から、非常に深刻な問題です。
一般的な問題には以下のようなものがあります：
- 箇条書きが正しくレンダリングされない
- テキスト間の改行が欠落している
- テキスト間に不要な改行が入っている
- ユーザーが書いたテキストが完全に削除されている
ここで「一般的な問題」と言うとき、私は外国語で特殊なメールクライアントを使ってメールを送信した場合に偶発的に起こることを意味しているのではありません。むしろ、Gmail や Outlook で英語の基本的なメール返信を送信した場合にも、これらが頻繁に発生することを意味しています。
以下は、[Python-Dev] メーリングリストからの、これらの問題について不満を述べるユーザーの 2 つの実際の例です：
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-5
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-36
（Prettyfwd は FWD:Everyone メール解析 API を使用しています。）
既存のメーリングリストからコンテンツを Discourse にインポートした経験はありませんが、メール返信におけるエラー率がどれほどであれ、メールスレッド全体をレンダリングする場合のエラー率は、少なくともその 10 倍以上になると経験上言えます。これは、シグネチャや返信を除去し、インライン返信を考慮し、深くネストされたマークアップに対処する際の複雑さが増すことに起因します。
実際の例として、LLVM ファウンデーションの会長である Tanya Lattner 氏によって書かれた Mailman から Discourse への移行の振り返り記事では、技術的な懸念のセクションでこれらの問題に言及しています：
私が尋ねたところ、彼らが不満に思っている具体的な点は、早期に切り捨てられてコンテンツが欠落しているメールの割合が高いことであることが分かりました。過去 19 年間のメーリングリストアーカイブに含まれる既存の議論やドキュメントは非常に貴重であるため、この問題が完全に解決されるまで Mailman を廃止できないと感じています。
では、Discourse における現在のメール解析の状態が「十分か」どうを知るにはどうすればよいでしょうか。私はこれを 3 つの部分からなる試金石として提案します：
- ユーザーは、メール返信機能を使用すれば、そのコンテンツが正確に解析され、ウェブインターフェース経由で投稿した場合と全く同じように表示されることを完全に信頼する必要がある。
- フォーラム管理者は、メール返信を許可しても、追加の仕事や苦情が生じないことを信頼する必要がある。
- Discourse の従業員は、この機能を第一級の参加方法として積極的に推進するに足るほど信頼している必要がある。
これらすべての条件が満たされていると完全に自信を持って言えない限り、メール返信という機能が存在していても、潜在的なメリットの大部分は決して得られることはありません。
これが現在起きていることです。
つまり、既存のメール解析コードを 80-20 の法則 に基づくソリューションと表現することはできますが、この文脈では 80-20 の法則はあまり意味を成しません。なぜなら、たとえ例えば 80% のメールが正しく解析されたとしても、潜在的なメリットの 10% すら得られない可能性が高いからです。
したがって、メール返信（および一括メールインポート）は既に存在しているにもかかわらず、ユーザーは最終的に求めていた体験を得られず、モデレーターやスタッフには追加の仕事が生じ、コミュニティは貴重なコンテンツやユーザーの成長を逃しています。
より優れたメール解析のメリット
ソーシャルソフトウェアが成功するのは、それが人間のニーズを満たす度合いに限られます。
ウェブフォーラムに投稿する理由には、他の人々と知識を共有したい、意見に影響を与えたい、一般的に知的であると思われるようにしたい、専門知識を持っていると思われるようにしたい、現実世界で価値ある貢献をしていると思われるようにしたい、などがあります。
そして、テキストベースのコミュニケーションにおいて、これらの成果を達成する可能性は、何を言うかだけでなく、それをどのようなタイポグラフィで言うかにも依存します。
これが、シェイクスピアにおける空白（ホワイトスペース）について本が書かれている理由です。これが、ニューヨーク・タイムズがニューヨーク・ポストよりも真剣に受け止められる理由の一部です。また、Facebook が MySpace を打ち負かした大きな理由の一つでもあります [1]。
ユーザーが書いたテキストが、本人のせいではないにもかかわらずひどくフォーマットが崩れてしまった場合、ソーシャルソフトウェアを利用する動機となる人間のニーズはもはや満たされません。むしろ、逆のことが起こっています。ユーザーは愚かに見えてしまうのです。
メール返信機能を使っていない人であっても、トピック内（およびより大きなフォーラム全体）の他の投稿がゴミ箱火事のように見える場合、権威や尊敬を失うことになります。
利害関係者としてのユーザーペルソナ
投稿が一貫して審美的に魅力的なタイポグラフィでレンダリングされれば誰もが恩恵を受けますが、特に受信メールの解析の改善から恩恵を受ける可能性のあるユーザーペルソナには以下が含まれます：
- [Python-Dev] や [Django-Dev] などのメーリングリストの現在のメンバーで、Discourse のメリットを十分に理解し、コミュニティが Discourse に移行することを喜んでいますが、GNU Mailman や Google Groups などと区別できない方法で引き続き参加できる場合に限り移行を希望する人々。この種のリクエストの実際の例：https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-89
- 基本的に Discourse への移行を喜んでいますが、過去数十年分の既存のコンテンツを同じプラットフォーム内から簡単に検索できれば、より熱心に移行するであろう、メールベースのコミュニティのメンバー。
- 断続的にフォーラムをチェックするカジュアルユーザー。例えば、Growing Fruit では、北米のパオパウ（pawpaw）の栽培に関するすべてのトピックをメールで購読しています。夏と秋には、これらのトピックの新しい投稿の絶え間ない流れを読むために毎日数回そのフォーラムを訪れますが、これらの月以外では、これらのトピックに関するメール通知が主に私の関与を維持しています。
- ウェブを断続的にしか使わない人々。ウェブを定期的に使用しないことは、デジタルデバイドに関連していると考えられがちですが、実際にはそうではないことが多いです。非常に知的で技術的な人々でも、分野の頂点にいるため、定期的にウェブを使用する必要がないように囲い込まれている人々が大勢います。実際の例として、世界トップクラスのコンピューター科学者の一人であるドナルド・クヌースがいます。彼はウェブを定期的に使用していません。あらゆる分野にこのような人々がおり、彼らに知識を共有してもらうことは非常に価値があります。私の経験では、これらの人々はどのフォーラムでも定期的な貢献者になることは少ないですが、自分が興味を持つトピックについて人々が議論していると伝えられれば、その特定のトピックにメールで購読し、貢献することがよくあります。
全体像として、受信メールの解析を改善することは、既に定期的なアクティブな Discourse 貢献者である人々のエンゲージメントを高めるだけでなく、そうでなければ移行を望んでいる多くのコミュニティの足かせを解き、そうでなければ貢献しない人々から非常に価値のあるコンテンツを引き出すことにもつながるはずです。
FWD:Everyone メール解析 API
FWD:Everyone のメール解析 API は以下の 2 つのことを行います：
- インライン返信を許可しつつ、各メールメッセージからシグネチャと返信を正確に除去します。
- メールクライアントによって生成される極めて複雑な HTML マークアップを取り、ユーザー生成コンテンツサイトで一般的に許可されている約 12 種類の HTML タグに正規化します。これにより、著者の意図を可能な限り最大限に維持します。
両方について詳しく説明しますが、まずは実世界のメールスレッドを示してこの問題を説明する私が作成した動画をご覧ください：https://www.youtube.com/watch?v=nPb3NQlz6V4
シグネチャと返信の除去
FWD:Everyone のメール解析 API は、テキストベースのメールと HTML メール双方において同等の精度で動作します。API は、利用可能な場合は優先的に HTML メッセージ部分を使用します。その理由は以下の通りです：
- 著者が使用する HTML フォーマット機能（太字、イタリック、引用、コードスニペットなど）は、テキスト自体と同じくらい重要であり、著者のメッセージの本質的な一部です。
- メールクライアントがメッセージの HTML バージョンをテキストベースのバージョンに変換する際、誤って変換することがよくあります。例えば、メールクライアントはテキストで箇条書きリストなどの HTML 機能をレンダリングしようとするどころか、HTML フォーマット要素内のテキストが完全に欠落していることさえあります。
もちろん、テキストベースのメールを好むユーザーもいます。そのため、テキストベースのみのメールでも、シグネチャと返信を同等の精度で除去する必要があります。
FWD:Everyone メール解析 API はこれを行い、テキストベースと HTML の両方のメールでインライン返信を正しく処理します。
精度に関しては、シグネチャと返信を除去する際にメール解析ライブラリで発生しうる 2 種類の誤りがあります：
- 偽陽性 — メッセージに含めるべきテキストが誤って除外されること。
- 偽陰性 — メッセージに含めるべきではないテキストが誤って含まれること。
異なる Discourse コミュニティ（小文字の d）がメールをどのように使用するかによって異なるため、正確な精度統計を示すのは困難です。しかし、Discourse の現在の解析ソリューションと比較した場合、現実的な期待値は以下のようになるかもしれません：
- シグネチャと返信の除去における偽陽性が 100 倍減少
- 返信の除去における偽陰性が 10 倍減少
- シグネチャの除去における偽陰性が 1 倍〜10 倍減少（おそらくより良いですが、1 つのオーダーの改善ではありません）。
参考までに、偽陽性は一般的に偽陰性よりもはるかに悪いです。なぜなら、それは人が書いた内容を誤って表現するからです。しかし、偽陰性も非常に悪く、投稿者（およびフォーラムの他の全員）が少なくとも不格好に見え、最悪の場合は愚かに見えてしまいます。
FWD:Everyone が取るアプローチは、偽陽性につながる可能性のあるトリックを避けてシグネチャを除去することです。これにより偽陽性が増加する可能性がありますが、その増加は、正当な方法でアルゴリズムを動作させるために膨大な作業を行ったことで大部分相殺されます。つまり、手抜きはしません。
FWD:Everyone メール解析 API が Discourse の現在のソリューションよりも一般的にはるかに正確であるという大きな理由は、当社の API が個別のメール返信ではなく、メールスレッド全体を解析するように設計されているためです。これは、単一の返信を解析するよりもはるかに困難な問題です。その結果、当社の製品は、Discourse の要件と既存の先行技術の両方に対して、過剰設計されていると言えます。
HTML マークアップの正規化
メール経由で送信された返信（およびインポートされたメールスレッド）が、他のユーザー生成コンテンツと同じように見えるためには、最終的にウェブ経由で返信する際に許可されているのと同じ HTML のサブセットを使用してレンダリングされなければなりません。
これは驚くほど複雑です。
Gmail や Outlook などのメールクライアントで作成されたメールは、約 50 種類の HTML タグ、約 25 種類の HTML 属性、約 175 種類の CSS スタイルの何らかの組み合わせでエンコードされています。さらに、このマークアップはしばしば大きく難読化されています。テキストの段落は以下のようなものになると期待するかもしれません：
<p>Some text!</p>
しかし、実際には、単純な段落でさえも、div、span、テーブル、リストなどの深くネストされ、完全に意味をなさない組み合わせでエンコードされていることがよくあります。これが、返信の除去とマークアップの正規化の両方における複雑さの主な源泉です。
いずれにせよ、解析後、各メッセージは以下のマークアップのみを使用してレンダリングされます：
許可されたブロック要素: <p>, <ul>, <ol>, <li>, <blockquote>, <pre>
許可されたインライン要素: <code>, <a>, <b>, <i>, <u>, <s>, <span>
注：
<a> タグを除き、許可される属性は‘style’と’dir’` のみです。- 許可されるインラインスタイルは
'font-weight'のみです。 <a>タグには'href'、'rel'、'title'、'target'属性も設定できます。<span>要素は、フォントウェイトが正しくカスケードするように限定的な場合にのみ使用されます。したがって、これらは常にインラインの'font-weight'と共に使用されます。- 将来、
<img>タグもインライン画像の表示に使用される予定です。
この制限された HTML サブセットで投稿をレンダリングすることで、メール経由で送信された投稿を、ウェブインターフェース経由で送信された投稿と全く同じタイポグラフィで簡単にレンダリングできます。
これは、段落間に数十の不要な改行を追加するなど、著者が意図しないことをできないようにしつつ、著者の意図を可能な限り最大限に維持して行われます。
詳細については、以下の「CSS スタイリング」セクションも参照してください。
言語サポート
EmailReplyTrimmer は現在、13 言語の完全または部分的なサポートを提供しています：
英語、ノルウェー語、フランス語、ドイツ語、ポルトガル語、スペイン語、イタリア語、オランダ語、スウェーデン語、中国語、ロシア語、ポーランド語、ウクライナ語
これに対し、FWD:Everyone メール解析 API は現在 30 以上の言語をサポートしており、Discourse が現在サポートしているすべての言語が含まれています：
英語、スペイン語、ポルトガル語、カタロニア語、オランダ語、フランス語、ドイツ語、イタリア語、ノルウェー語、デンマーク語、スウェーデン語、フィンランド語、ロシア語、ポーランド語、ウクライナ語、トルコ語、チェコ語、ルーマニア語、ハンガリー語、ヘブライ語、アラビア語、ペルシア語、中国語、日本語、韓国語、ヒンディー語、インドネシア語、タイ語、フィリピン語、アフリカーンス語
FWD:Everyone メール解析 API は、RTL（右から左）言語を完全にサポートしています。つまり、アラビア語などの言語でテキストが正しく右から左に流れるだけでなく、箇条書きなどの機能がページの正しい側にレンダリングされるように、HTML マークアップに適切な属性が適用されます。
API は使用するメールクライアントによっては追加の言語でも動作することがありますが、公式にサポートされている言語セットは、最低限 Gmail、Outlook、Apple Mail で動作することがテストされています。あまり普及していないメールクライアントは、それらが最も使用されている言語で明示的にテストされています。また、API は公開メーリングリストからの数千のメールスレッドに対してテストされているため、未知の出自による実世界の不安定な動作に対する無数の修正が含まれています。
なお、多様な言語をサポートすることは、単にそれらの言語でテキストを表示するためだけでなく、重要です。英語でテキストを書きながら、メールクライアントを例えばヘブライ語に設定している人は非常に一般的です。そのため、このような場合、英語の返信を正しく解析するには、ヘブライ語を完全にサポートするだけでなく、RTL 言語全般をサポートする必要があります。
多様な言語ファミリーからの言語をサポートすることは、将来より多くの非西洋言語のサポートが追加された際に問題を引き起こす可能性のある方法ではなく、Unicode が正しく処理・保存されることを保証するのにも役立ちます。
CSS スタイリング
前述のように、当社の API の主要な強みは、思慮深く論理的な方法で HTML マークアップを正規化する能力です。この正規化プロセスは、読みやすさとアクセシビリティを最適化しつつ、元の著者の意図を可能な限り最大限に維持するように設計されています。
そのため、すべてのテキストはインライン要素またはブロック要素内（浮遊テキストなし）にのみ表示され、すべてのインライン要素はブロック要素内に表示されます。これにより、テキストのスタイリングが容易になります。例えば、異なる要素間に適切な量のホワイトスペースがあることを保証できます。
これがどれほど価値があるかの例として、メールクライアントでは、行の直前または直後に改行なしで箇条書きリストを挿入するなど、ばかげたことをユーザーに許可します。その際、メールクライアントによって生成される（大幅に単純化された）コードは以下のようになるかもしれません：
<div>
Some text
<div> </div>
<span> • A bullet point</span>
<div> </div>
Some more text
</div>
FWD:Everyone メール解析 API は、上記のマークアップを以下のように正規化します：
<p>Some text</p>
<ul>
<li>A bullet point</li>
</ul>
<p>Some more text</p>
この正規化されたマークアップは理解しやすくスタイリングが容易であり、視覚的にも箇条書きリストの前後に改行が表示されるようになりました。このようなアフォーダンスにより、テキストはより美しく読みやすくなり、著者の意図も維持されます。このようなユーザーアフォーダンスにより、メール経由で送信された優れたコンテンツが一貫して社会的地位を付与し、それを損なうことがなくなります。
当社の API によって生成される単純化された正規化されたマークアップにより、テキストのスタイリングについて考える際、デザイナーや開発者は元のメールがどのようにフォーマットされていたかではなく、API が許可する出力についてのみ考えればよくなります。また、API からの許可される出力は、Discourse のウェブクライアントが許可するものと事実上同一であるため、これはほぼそのまま導入可能なソリューションとなるはずです。
提案される統合方法
メール返信機能は、Discourse のプラグインとして統合され、その後、ホストされたすべての Discourse インスタンスでデフォルトで有効にできるようになります。
このプラグインが有効になっていない Discourse インスタンスでは、既存のメール解析コードが使用されます。
さらに、FWD:Everyone メール解析 API が一時的に利用不可能になった場合、受信メッセージは既存のメール解析コードを使用して処理されます。その後、API がオンラインに戻ったら、投稿後ウェブインターフェース経由で編集されなかったメッセージを API で再処理できます。
このプラグインは、自己ホスト型の Discourse インスタンスにもオプションで有効化できるように提供されます。
既存のメーリングリストから Discourse へ移行するグループの場合、メーリングリストの各メールスレッドも API を介して解析できますが、これはおそらくプラグイン経由ではなく、Discourse の既存の移行スクリプトおよびプロセスに統合されるでしょう [2]。
API のテスト
この API は、認証されていないユーザーには非常に低いレート制限付きで、誰でも完全にテスト可能です。
Gmail アカウントをお持ちの方にとって、API をテストする最も簡単な方法は以下の通りです：
- https://www.prettyfwd.com にアクセスし、G Suite アドオンをインストールする。
- https://api-demo.fwdeveryone.com にアクセスし、クライアントサイド OAuth を使用して API を試す。
これら 2 つのウェブベースのツールと実際の API の主な違いは、前者は以下の点で制限があることです：
- HTML テーブルを使用してスタイル設定されたメッセージを含むスレッドは処理しない。
- スレッド内の最初のメッセージの返信を除去しない。（例：スレッドに 100 以上のメッセージがあり、Gmail がそれを複数のスレッドに分割する場合など。）
コードを介して API を直接テストするには、Python と Ruby の両方のスタータースクリプトがあります：
また、既知の問題や製品ロードマップを含む関連ドキュメントはこちらです：
[1] Viewing American class divisions through Facebook and MySpace.
[2] 既存のメーリングリストからコンテンツを一括インポートする際、いくつかのスレッドで簡単な健全性チェックを行い、正しく解析されていることを確認することをお勧めします。一部のグループはそのままほぼ完璧な精度で解析されますが、他のグループは数時間の事前作業から大きく恩恵を受ける可能性があります。例えば、一部のメーリングリストソフトウェアでは、各メッセージの下部に付加されたテキストを除去するために、リストごとに少しのカスタムコードが必要ですが、他のメーリングリストソフトウェアでは、そのプラットフォームでホストされているすべてのリストに適用できる予測可能な方法で行うことができます。このような潜在的な問題があるため、一括インポートプロセスは、プラグイン経由で行うのではなく、監督された移行の一部として実行するのが望ましいでしょう。