電子メールにメモ機能を追加する
手法についての提案
植 田 浩 光
力 宗 幸 男
１．はじめに 電子メールは，コミュニケーションの手段として，多く使用されているものである．総 務省の電気通信消費者情報コーナーに掲載されている2012年２月現在の「電気通信事業者 14社 1の全受信メール数と迷惑メール数の割合」［1］によると，電気通信事業者14社の１ 日あたりの全受信メール数は，18億4,606万通である．もっとも，このうち約64％（11億 8,807万通）は迷惑メールとされている．これは総務省が統計を取っているメール数であ り，日本全体，世界全体ではさらに大きな数値となる．ウェブサイトの監視サービスを提 供するアメリカ Pingdom 社によると，2010年に世界で送信された電子メール数は，約 107兆通であり，１日平均では，約2,940億通となる［2］［3］．このうち迷惑メール（spam） 数は，約89.1％にもなる． 両方の統計では，受信と送信に違いがあるものの，電子メールが多く使用されているこ とを示すものである．迷惑メールが多いのが問題点ではあるが，コミュニケーションの一 手段として，重要な役割を持っていることは否定することは出来ない． ２．背 景 2.1 電子メールの共有利用についての問題点 電子メールのアドレスを共有して利用している場合に，メンバー間の情報共有が問題と なる．例えば，企業のカスタマー窓口等，一つの代表メールアドレスを持ち，複数のメン 1 KDDI 株式会社，NEC ビックローブ株式会社，株式会社 NTT ぷらら，イー・モバイル株式会社，株式会 社インターネットイニシアティブ，株式会社ウィルコム，エヌ・ティ・ティ・コミュニケーションズ株式会 社，株式会社ケイ・オプティコム，ソネットエンタテインメント株式会社，ソフトバンクテレコム株式会社， ソフトバンクモバイル株式会社，株式会社テクノロジーネットワークス，ニフティ株式会社，ヤフー株式会社バーで対応を行っている場合のことである．その場合，相手へ返信した内容は送信時に控 えとしてコピーで残すことが出来るが，内部的に返信出来ない内容（顧客情報や企業情報 等）をメンバー間でメモとして残しておきたい場合にどうするかという問題である．この 問題は，通常メンバー間の引き継ぎとして行うが，これをメールシステムとして，メモの 引き継ぎをシステム的に行う場合を提案したい． 2.2 要望点 前項で述べたとおり，電子メールはコミュニケーションで重要な役割を持っており，企 業・個人で多く使用されている．便利なツールではあるが，標準で搭載されていない機能 として，電子メールのメッセージにメモを記入する機能がある．これは先の問題点で指摘 したとおりではあるが，このメモ機能の要望点を以下に二点上げる（表１参照）． 表１ 要望点 No 要 望 点 1 電子メールにメモを残しておきたい． 2 メモを複数で共有したい． 要望点について説明する．No.1は，電子メールのクライアントソフトには，各ソフト によって差があるが，電子メールのメッセージにフラグや色をつける機能がある．これは これで便利な機能ではあるが，フラグや色では表現出来ないこともある．また，フラグや 色だけだと，その定義ルールを決めておかないといけないし，その定義したルールを忘れ てしまう場合がある．そこで，分かりやすく文字や図版等でメモを残しておくことが出来 ないかということである．実際，メジャーな電子メールのクライアントソフトで，標準で 電子メールのメッセージにメモを記入する機能を搭載したものはない．No.2は，電子メー ルのメッセージにメモを記入出来るとして，そのメモの内容を一人だけではなく，複数で 共有しておきたいということがある．これは，問題点で指摘したことだが，一つの電子 メールアドレスを複数のメンバーで共有している場合があるからである． 2.3 一つの解決策 一つの解決策として，自電子メールアドレスにメモを書いて送信する方法がある．一番 簡単な方法である．タイトルに“Re:”を入れれば，電子メールのクライアントソフトで スレッド表示してくれる．複数のメンバーで運用する場合は，メモの書き方等のルールは 決めておく必要はあるが，新たな投資は必要としないのが長所である．短所として，メモ として電子メールのメッセージを送信する場合に，誤った宛先に送信してしまう場合があ
る．メッセージに書かれたメモの情報が相手先に知られてはいけない情報であると，情報 流出として大きな問題となる．メモでなくとも誤った宛先に電子メールを送信してしまう 事件［4］は多く発生している．また，受信した電子メールのメッセージとメモが混在す るので紛らわしい問題がある． 2.4 電子メールクライアントソフトの調査 電子メールのクライアントソフトにメモを記入する機能が標準でないことは先に述べた とおりである．では，本当に機能として搭載されているクライアントソフトがないのか， もしくは拡張機能として提供されているソフトがないかを調査する．調査結果を以下に示 す（表２参照）． 表２ 調査ソフト一覧 No 種 類 ソ フ ト 名
1 Google Chrome 拡張 Gmail Notes
2 Thunderbird アドオン XNote
3 Web アプリケーション サイボウズ メールワイズ４
No.1の“Gmail Notes”［5］は，Web ブラウザである“Google Chrome”の拡張機能 として提供されているフリーウェアである．ソフト名が示すとおり，Google 社が提供し ている“Gmail”用のソフトウェアである．“Gmail”上において，電子メールのメッセー ジに対し，メモを記入することが出来る．メモの内容は，クラウドである“Google ド キュメント（Google ドライブへアップグレード）”に記録される．そのため，複数のメン バーやパソコンから，オンラインでメモの内容を共有することが出来る． No.2の“XNote”［6］は，電子メールクライアントソフトである“Thunderbird”のア ドオンとして提供されているフリーウェアである．“Thunderbird”上で動作し，メール のメッセージに付箋紙を貼り付けるようにメモを記入出来るものである．メモの内容は， “Thunderbird”が動作するパソコンの記録装置に保存される． No.3の“サイボウズ メールワイズ４”［7］はサイボウズ社が提供する商用の Web アプ リケーションである．キャッチコピーの「お客様対応の全てが見えるメールシステム」と あるとおり，企業のメール対応を記録，管理が出来ることをうたい文句にしている．この ソフトウェアも受信した電子メールにメモを記入することが出来る．Web アプリケーショ ンであり，メモはサーバ上に記録されるため．複数のメンバーからオンラインでメモを共 有することが可能である．しかし，商用のソフトウェアだけあって高価である．
2.5 電子メールクライアントソフトの調査まとめ 前項での電子メールクライアントソフトの調査を踏まえ，まとめてみると，以下の三点 となる（表３参照）． 表３ 調査ソフトまとめ No ま と め 1 “Gmail Notes”，“サイボウズ メールワイズ４”はオンラインにメモを保存している ので，複数での共有が可能である．“XNote”はローカルに保存されるので，複数で の共有は出来ない．
2 “Gmail Notes”は Gmail 専用で，“サイボウズ メールワイズ４”，“XNote”はメー
ルアカウントに制限はない． 3 三つのソフトとも，メモはテキストのみ記入することが出来る． ３．目 的 前項の背景で述べたことを踏まえ，電子メールにメモを記入出来る機能を実現するため には，以下の点を満たしたものとする（表４参照）． 表４ 目 的 No 目 的 1 オンラインでメモを共有出来るようにする． 2 どのメールアカウントでも利用出来るようにする． 3 どの電子メールソフトでも利用出来るようにする． 4 無償（安価）で提供出来るようにする． 5 アプリケーションではなく、プロトコルでの実装を行う． No.1は，要望点を踏まえたものであり，複数のメンバーで電子メールのメッセージに 記入されたメモをオンラインで参照・作成出来るようにするものである．また，複数のメ ンバーで共有するだけでなく，一人の使用でも複数のパソコンやスマートフォンを所有し ている場合，各機種でメモを共有出来るようにすることである． No.2は，どのメールアカウント（メールプロバイダ）でも使用出来るようにすること である．“Gmail Notes”が“Gmail”専用であり，それ以外の電子メールアカウントを 使用している場合に対応するためである． No.3は，どの電子メールクライアントソフトでも使用出来るようにすることである． この機能を実現するには，既存ソフトウェアの改良が必要である．電子メールクライアン トソフトがサポートするプラグイン等拡張機能を使って実現することとなる．
No.4は，文字どおり，無償（安価）でメモ共有機能を提供できるようにすることであ る． No.5は，実装例としてのアプリケーションの開発を行う必要はあるが，電子メールク ライアントソフトは複数存在する．それらを全てサポートすることは困難であるので，プ ロトコルを公開し，標準化を働きかけることで，複数のソフトウェアでのサポートを可能 とする． ４．実装方法の検討 4.1 必要条件 実際に実装する方法の検討として，以下に必要条件を述べる（表５参照）． 表５ 必要条件 No 必 要 条 件 1 電子メールのメッセージに記入するメモはサーバ上に格納し，メモを共有出来るようにすること． 2 電子メール受信プロトコル IMAP4，POP3の両方に対応出来るようにすること． 3 格納するメモはアクセス制御を行うこと．必要に応じて暗号化を行う． 4 必要に応じて未読管理を行う． No.1は，電子メールのメッセージに記入するメモはパソコンやスマートフォンのロー カル記憶装置に記録するのではなく，インターネットもしくはイントラネット上のサーバ にオンラインで記録する．記録するサーバは，電子メールの IMAP4サーバや，“Google ドライブ（旧 Google ドキュメント）”，“Dropbox”といったクラウドのオンラインスト レージを使用する． No.2は，電子メールの受信プロトコルで多く使われている IMAP4，POP3の両方で使 えるようにする．IMAP4プロトコルには APPEND コマンドがあり，任意のメールフォ ルダに電子メールのメッセージを書き込む機能がある．これはメールのメッセージを書き 込むだけで，実際に送信されることはない． No.3は，電子メールのメッセージに記入するメモは必要に応じてアクセス制御を行う 必要がある．第一段階では平文でメモをサーバに格納するが，実際に運用となると，アク セス制御を用いて，メモを参照・作成する権限を設定する．その場合は，サーバへメモを 格納する際に暗号化を行う． No.4は，電子メールのメッセージに記入されたメモについて，未読管理を行う．これ
は，どのメンバーがメモを読んだ・読んでないをチェックすることで，メモの内容が周知 されているかを確認することである．第一段階では実装を行わないが，実際の運用となる と必要な機能であると考える． 4.2 前提条件 実装についての前提条件を以下に述べる（表６参照）． 表６ 前提条件 No 前 提 条 件 1 対応する電子メールクライアントソフトはプラグイン等で機能拡張が行えるものを対象とする（新規で電子メールクライアントソフトを開発する場合も含む）． 4.3 実装方法 実際の実装方法として，図に示す．大きく分けて，電子メール受信プロトコルに IMAP4か POP3 を使用しているかに分けられる．IMAP4の場合は，前述のとおり，プロ トコルの APPEND コマンドによって，任意のメールフォルダに電子メールのメッセージ を書き込む機能がある．この場合は，同じメールアカウントに，元となる電子メールの メッセージと作成したメモが格納されており，情報の集約という点では長所である． POP3ではそのようなコマンドはないため，同じメールアカウントにメモとして格納する ことが出来ない．そこでクラウドのオンラインストレージを利用する．イントラネット内 で全て完結したい場合は，イントラネットにファイルサーバを設置する． 4.3.1 IMAP4のフォルダにメモを格納する IMAP4のフォルダにメモを格納するパターンを以下の図に示す（図１参照）． 図１ IMAP4のフォルダに格納（方法１）
受信した電子メールは，振り分けのルールを設定していない限り，通常は受信フォルダ に格納される．作成したメモは，電子メールのメッセージの形を取って，新しく作成する メモフォルダに格納する．元の電子メールのメッセージとメモを結びつけるには，電子 メールのメールヘッダにある“Message-ID”を利用する．“Message-ID”については， 後述する． 4.3.2 別サーバにメモを格納する 電子メール受信プロトコルに POP3を使用している場合は，前項の方法が使用すること が出来ないため，別サーバにメモを格納する．別サーバとは，クラウド上のオンラインス トレージやイントラネット上のファイルサーバを使用することが出来る．要はファイルが 格納出来れば，サーバの種類は問わない．別サーバとしているが，別サービスという意味 であり，実際は同一筐体のサーバでも問題ない．別サーバにメモを格納するパターンを以 下の図に示す（図２参照）． メモは，サーバにファイルとして記録される．ファイルの内容は，前項の「IMAP4の フォルダにメモを格納する」で説明したとおり，電子メールのメッセージの形を取って格 納する．これは二つの方法で，記録方法を統一するためであり，互換性を保つためであ る． 4.4 “Message-ID”について 電子メールには，メールヘッダに“Message-ID”というフィールドを持つべきとされ ている．RFC2822［8］［9］では，“Message-ID”は，“Though optional, every message SHOULD have a“Message-ID:”field.”（日本語訳「任意であるとはいえ，すべての メッセージは“Messge-ID:”フィールドを持つべきである」）と定義され，電子メールの
メッセージには入れるべきとなっている．またそのフィールド値は，世界的に一意である ことを保証しなければならない．RFC2822では，“The“Message-ID:”field contains a single unique message identifier.”（日本語訳「“Message-ID:”フィールドは単一のユ ニークなメッセージ識別子を含む」）と定義されている．つまり，同じ“Message-ID”を 持つ電子メールは二つとないということである．以下は“Message-ID”の一例である （表７参照）． 表７ “Message-ID”の一例 Message-ID: <20120118113031.51F5.A8D3F6D6@example.com> 4.5 実装方法の検討まとめ 実装方法の検討にて，方法１（メモを IMAP4サーバに保存），方法２（メモを別サーバ に保存）についてまとめると，以下の表となる（表８参照）． 表８ 方法の検討まとめ No ま と め 1 方法１はメールとメモが同一サーバで管理されるので，バックアップや移行等が便利 である． 2 方法１は，IMAP4でしか使用出来ない．POP3は，方法２のみであるが，別サーバの IMAP4を利用することは出来る． 3 別サーバとしているが，同一サーバに収容することは可能である． 4 “Dropbox”等．別サーバには，クラウド上のサーバを使用することが出来る．ex“Google ドライブ”， ５．実 装 5.1 メモの格納 前項の方法１（メモを IMAP4サーバに保存），方法２（メモを別サーバに保存）両方と も，メモは電子メール形式で保存することとする．これは方法が異なっても，格納する手 法を統一するためである．電子メールの形式については，RFC2822の定義に従うことと する．方法２だと，ファイルに電子メールの形式で保存することとなる．ファイル名はユ ニークな名前を使用する．このメモを電子メール形式で保存することには以下の長所があ る（表９参照）．
表９ 電子メール形式で保存することの長所 No 長 所 1 方法１と２で保存するフォーマットが同一のため，互換性が保たれる．またそれぞれにフォーマットを設計する必要がない． 2 電子メールの添付ファイル機能を利用し，メモでも添付ファイルを付加することが出来る．それによって，画像等の情報をメモとして追加できる． 5.2 電子メールのメッセージとメモの関連 メモのメールヘッダに“Memo-ID”フィールドを追加し，そのフィールド値には，メ モをつけたい電子メールのメールヘッダの“Message-ID”のフィールド値と同じ値を入 れる．つまり，“Message-ID”と“Memo-ID”のフィールド値が同一のメッセージが， 電子メールのメッセージとメモの関連となる．関連性を図で表すと以下の図となる（図３ 参照）． 表７の“Message-ID" だと，対応するメモの“Memo-ID”は以下のとおりとなる（表 10参照）． 表10 “Memo-ID”の一例 Memo-ID: <20120118113031. 51F5. A8D3F6D6@example.com> 5.3 実装の問題点 前項で電子メールのメッセージとメモを関連づけるために，メモのメールヘッダに “Memo-ID”フィールドを定義したが，この定義が RFC の定義に則ったものかを確認す る．要は，RFC ではこのような定義を許容しているのか，勝手に定義して，電子メール のサーバ・クライアントソフトに影響が出ないかということである． 図３ 電子メールとメモの関連
5.3.1 RFC822での定義
RFC822［10］［11］は，ARPA インターネットテキストメッセージのための標準規約 であり，1982年に制定されている．そこでメールヘッダの拡張について定義されている．
4.7.4. EXTENSION-FIELD
A limited number of common fields have been defined in this document. As network mail requirements dictate, additional fields may be standardized. To pro-vide user-defined fields with a measure of safety, in name selection, such exten-sion-fields will never have names that begin with the string“X-”．
4.7.4. 拡張フィールド 一定数の共通フィールドがこの文書で定義されています．ネットワークメール要求が 指示するように，追加フィールドは標準化されるかもしれません．名前選択で適度に安 全な利用者定義フィールド（user-defined-fields）を提供するために，“X-”文字列で はじまる名前をもたない拡張フィールドを提供します． 新たにメールヘッダのフィールド名を定義することが出来る．これを利用者定義フィー ルドといい，そのフィールド名には“X-”を先頭に付与することである．よく使われて いるフィールド名としては，電子メールのクライアントソフト名を示す“X-Mailer”や， 電子メールの優先度を示す“X-Priority”といったところが上げられる． 5.3.2 RFC2822での定義 RFC2822は，インターネットメッセージフォーマットのための標準規約であり，2001 年に制定されている． 先の RFC822に取って代わるものである． 3.6.8. Optional fields
Fields may appear in messages that are otherwise unspecified in this stan-dard. They MUST conform to the syntax of an optional-field. This is a field name, made up of the printable US-ASCII characters except SP and colon, followed by a colon, followed by any text which conforms to unstructured. The field names of any optional-field MUST NOT be identical to any field name specified elsewhere in this standard.
3.6.8. オプションフィールド メッセージ内にこの文書で規定されていないフィールドが現れてもよい．そのような フィールドはオプションフィールドの文法に従わなければならない．オプションフィー ルドは，SP とコロンとを除く印刷可能な US-ASCII 文字から成るフィールド名の後に コロン，次に不定形の任意のテキストが続く．オプションフィールドのフィールド名 は，この標準で規定されている他のフィールド名と同じであってはならない． この標準の目的において，すべてのオプションフィールドはその内容を解釈されない． 新たにメールヘッダのフィールド名を定義することが出来る（オプションフィールド）． このフィールド名は，RFC2822で定義しているフィールド名と重複しなければ良い（表 11参照）．RFC822と異なり“X-”を先頭に付与する必要はない． 表11 RFC2822で定義のフィールド名 フ ィ ー ル ド 名
Date, From, Sender, Reply-To, To, Cc, Bcc, Message-ID, In-Reply-To, References, Subject, Comments,
Keywords, Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Bcc, Resent-Message-ID,
Return-Path, Received 5.3.3 実装の問題点まとめ RFC2822によると，“Memo-ID”フィールドを追加することは問題はない．RFC822は， RFC2822に継承されているため，現在は RFC2822に遵守することになっているからであ り，“X-”を先頭に付加する必要はない．また，他のメール関連の RFC で“Memo-ID” フィールドが定義されていなければ使用することは可能である．RFC のドキュメントを 検索した結果では該当はないことを確認している．実際に，このようなオプションフィー ルドを定義した例として，RFC3798（Message Disposition Notification）［12］では， “Disposition-Notification-to”がオプションフィールドとして定義されており，電子メー ルの開封確認を要求するために使われている． “Memo-ID”フィールドを追加したことで，メモ機能を追加していない電子メールクラ イアントソフトでは，RFC2822に遵守していれば，そのフィールドを解釈されることが ないので，誤動作が起きるということはない．電子メールサーバソフトには改良を加えな いが，これも“Memo-ID”フィールド追加によって誤動作が起こることは RFC2822に遵 守している限りない．
5.4 他のフィールド名について 表11で，RFC2822に定義されているメールヘッダーのフィールド名を挙げたが，その 中で電子メールのメモのメールヘッダーに使用するフィールド名とその働きを以下の表に 示す（表12参照）．必須のフィールド名には“○”を，本提案でサポートはするが必須で はないフィールド名には“×”を必須欄に入れている． 表12 メモのメールヘッダー No フィールド名 必須 メモ機能としての働き 1 Date ○ メモが作成された時間情報を示す．メモの並び順に使用される． 2 From ○ メモの作成者を示す． 3 To × メモを指定メンバーに送る．メンバーを限定するときに使用する． 4 Cc × メモを指定メンバーに送る（コピー）．メンバーを限定するときに使用する． 5 Bcc × メモを指定メンバーに送る（コピー）．メンバーを限定するときに使用する． 6 Message-ID ○ ユニークな文字列を指定する．メモのメモという場合は，この値がメモの“Memo-ID”にコピーされる． 7 Subject ○ メモのタイトルを示す． 8 Comments × メモについてのコメントを示す．タイトルとともに表示される． 9 Keywords × メモについてのキーワードを示す．関連するメモを検索する際に使用する． メモのメールヘッダーに“Message-ID”を入れているのはメモが電子メールとして発 信されることはないのだが，これは RFC2822に遵守しているためである．また，メモの メモといったツリー構造を可能とするためである（図４参照）． 図４ メモのツリー構造
5.5 実装のまとめ 電子メールのメッセージにメモを記入する実装方法について，問題点とともに定義を 行った．定義についてまとめると以下の表となる（表13参照）． 表13 実装のまとめ No ま と め 1 メモはメール形式で保存し，添付ファイルを一緒に保存出来る． 2 電子メールのメッセージとの関係性は，メールヘッダの Message-ID を使用し，メモ には Memo-ID に同一値を設定する． ６．まとめ 電子メールのメッセージにメモ機能を追加する手法について提案を行った．本提案での 長所はメモを電子メール形式で保存することにある．これにより，ファイルを添付するこ とで，画像や文書ファイルを一緒に保存することが出来るので，メモとして記述性が向上 し，電子メール管理に役立つ．これは今回調査したソフトには無い特徴である． ７．今後の課題 今後の課題としては，まだ電子メールのクライアントソフトの拡張機能を使って，本提 案での実装を行っていない．実装を実際に行うことで，問題点がないかを確認していく． 参考文献 ［1］総務省，“電気通信事業者14社の全受信メール数と迷惑メール数の割合（2012年２月時点）”， http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/pdf/110302_1.pdf, 2012
［2］Pingdom,“Internet 2010 in numbers”, http://royal.pingdom.com/2011/01/12/internet-2010-in-numbers/, 2011
［3］AFP BBNews，“2010年に世界で送信された電子メールは約107兆本”，http://www.afpbb.com/ article/environment-science-it/it/2782382/6669706, 2011
［4］アメリカンファミリー生命保険会社，“お客様情報の流出について”，http://www.aflac.co.jp/ news_pdf/2012030602.pdf, 2012
［5］Gmail Notes, “Gmail Notes”, http://gmailNotes.appspot.com/，2009-2012
［6］Pierre-Andre Galmes, nmweb, StarXpert,“XNote”, https://addons.mozilla.org/en-US/ thunderbird/addon/xNote/, 2008
［7］サイボウズ株式会社，“サイボウズ メールワイズ４”http://products.cybozu.co.jp/mailwise/, 2009
［8］The Internet Engineering Task Force,“RFC2822（Internet Message Format）”, http:// www.ietf.org/rfc/rfc2822.txt, 2001
［9］srgia.memo.space,“RFC2822（Internet Message Format）日本語訳”, http://srgia.com/docs/ rfc2822j.html, 2010
［10］The Internet Engineering Task Force,“RFC822（STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES）”, http://www.ietf.org/rfc/rfc0822.txt, 1982
［11］PHP SAMPLES & TIPS,“RFC822（STANDARD FOR THE FORMAT OF ARPA IN-TERNET TEXT MESSAGES）日本語訳”, http://www.spencernetwork.org/reference/rfc822-ja.txt, 2003
［12］The Internet Engineering Task Force,“RFC3798（Message Disposition Notification）”, http://www.ietf.org/rfc/rfc3798.txt, 2004
