# [34] 電子メール長期保存の課題: ePADD の有用性と問題点

○堀内暢行 ${ }^{1)}$ ，橋本陽 ${ }^{2}$

1）国文学研究資料館研究部, $\bar{\top} 190-0014$ 立川市緑町 10-3

2) 京都大学大学文書館, 〒 606-8305 京都市左京区吉田河原町 15-9

E-mail: hori6592no@gmail.com; hashimoto.yo.4a@kyoto-u.ac.jp
## The Challenges of Long-Term Email Preservation: The Usefulness and Problems of ePADD \\ HORIUCHI Nobuyuki1), HASHIMOTO Yo ${ ^{2}$}

1) Research Department at National Institute of Japanese Literature, 10-3 Midori-cho,

Tachikawa, 190-0014 Japan

2) Kyoto University Archives, 15-9 Yoshidakawara-cho, Sakyo-ku, Kyoto, 606-8305 Japan

## 【発表概要】

本報告では、日本で実践事例が見られない電子メールの長期保存対策について、ePADDを利用する方法を解説し、その有用性を明らかにする。ePADD はスタンフォード大学によって開発された Open Source Software（OSS）である。独自の自然言語処理（NLP）機能が備っており、電子メールの評価選別、整理、検索、提供という 4 つのモジュールから構成されている。電子メールは、ISO 15489 に漼拠した Electronic Document and Records Management System

（電子文書・記録管理システム、EDRMS）から独立したシステムで作成され、そのまま保管される場合がほとんどである。その結果、記録管理のライフ・サイクルから外れ、秘匿すべき情報、メタデータおよびフォーマットの管理が行き届かず、将来の保存と利用が危ぶまれることになる。この対策として、ePADD の4つのモジュールが有効であることを示すとともに、日本語の環境での使用が難しい現状を課題として挙げ、その解決の道筋を論じる。

## 1. はじめに

電子メールが組織の業務や個人の活動に必要不可欠な存在となって久しい。ISO 15489 などの国際標準において、記録は業務や活動の証拠となる文書と定義されるが、これと対照すれば、電子メールは記録というカテゴリ一の中に分類される。したがって、記録の長期保存を請け負らアーカイブズが電子メールの移管を受け、永続的な保管を行うことが求められる。

しかし、国内のアーキビストがこの点を取り上げることは稀である。電子メールの保管については、プリントアウトしてファイリングするという方式がよく見られるが、これでは、電子システム上でのみ残されるメタデー タが全て消失し、記録の存在要件である証拠能力が失われてしまう。実際に、アメリカの法廷ではそのように評価した判例が存在して
いる。一方で、電子メール特有の問題も存在する。記録管理の標準に準拠し、メタデータを付与しながら証拠能力を維持する電子記録専用の管理システムを構築したとしても、電子メールを作成・管理するアプリケーションは、そうしたシステムから独立している事例が数多い。そのため、電子メールを適切に保管するには、別の対応策が必要となる。

このような問題を解決するために作られたソフトウェアがスタンフォード大学で開発された ePADD である。ePADD には独自の自然言語処理 (NLP) 機能が備えられ、電子メー ルの評価選別、整理、検索、提供という 4 つのモジュールで構成されている。本報告では、日本で実践事例が見られない電子メールの長期保存対策について、ePADD の各モジュールを利用する方法を説明し、その有用性を明らかにする。同時に、英語圈で作られたソフト

ウェアであるため、日本語の環境での利用が難しいことを課題として挙げ、その解決に至る道筋について論じる。

## 2. 電子メール保存の障害

## 2. 1 記録管理システム

電子記録の長期保存を実現するための理論的基盤の一つに、ライフ・サイクル・モデルがある。これは、現用段階において記録の作成と管理を行う Electronic Document and Records Management System（電子文書・記録管理システム、EDRMS）を利用し、非現用段階では、歴史的価値をもつと判断される記録のみをアーカイブズの電子保存システムに移管し保管することで成立する。EDRMS は記録管理の国際標準である ISO 15489、電子保存システムは電子データ長期保存の国際標準である ISO 14721 にそれぞれ準拠していることが必須となる。

他の種類の記録と同様、電子メールも、このライフ・サイクルに則れば適切に管理されるはずである。しかし、現実はそうなっていない。電子メールの大半は EDRMS と異なるアプリケーションで作成され、そのまま管理される。電子メールをライフ・サイクルに加えるには、システムの利用者が保管すべきものを選択し EDRMS に取り込まなければならない。このような選択の判断と取り込みの作業が利用者の負担となるため、多くの電子メ一ルはライフ・サイクルから漏れ落ちる事態が生じている。アメリカ国立公文書館は、この状況を鑑み、Capstone という方式を採用し、重要な役職のアカウントにあるメール全体を永年保存する試みに着手している[1]。

個人の電子メールとなると、EDRMS で管理されることはほとんどなく、より一層ライフ・サイクルから乘離する形で保管されることなる。そのため、Capstone のようにアカウント単位で捕捉していく手法は、個人の電子メールについても試行する価值があると言える。

## 2. 2 電子メール固有の問題

電子メールをアカウント単位で扱う場合、考慮しなければならない特有の問題がある。1 つ目は、個人情報や機密情報などの秘匿事項である。EDRMS を運用していれば、現用段階でそれらを管理し、アーカイブズに移管後の非現用段階でも、その管理情報を引き継いだ上で公開と非公開の判断が可能となる。しかし、組織であれ個人であれ、電子メールのアプリケーションを使用する場合、一貫した秘匿設定がなされた状態でアーカイブズに移管されることは到底望めない。さらに電子义一ルが膨大な数になることを考えれば、移管を受けた後に、アーキビストが内容を読んで秘匿事項を把握することも現実的ではない。 したがって、アーカイブズの方で秘匿すべき情報を自動的に処理するための技術的な対策を準備しなければならない。2つ目は、アー カイブズにおける保存の問題である。既存の電子データ長期保存のアプリケーションは、 ライフ・サイクル・モデルを基礎として開発されており、そこから外れた電子メールには対応できないところがある。返信および転送メールを紐づけるスレッド表示や添付ファイルを一括して維持するために、電子データ長期保存のアプリケーションに加え、別の技術的対策が必要となる。最後に現用段階からのアプローチである。非公開基準の設置や長期保存すべきメールの選別などは、作成者と連絡が取れなくなった後では、処理が極めて難しくなる。作成者との共同作業を可能とする技術的対策が望まれる。

以上にあげた技術的対策は、どのように実装することができるだろうか。近年開発されたアプリケーションである ePADD を通じて検討する。

## 3. ePADD の機能と特徴

## 3. 1 基本的特徵

ePADD の最大の特徴は、開発者であるスタンフォード大学図書館が Open Source Software（OSS）として公開している点にある。これにより、ユーザーは無料で利用できることはもちろん、プログラミングの知識があれば、ニーズに合わせて容易に改変が可能

となる。また、本 OSS は Windows・MacOS

（他に Ubuntu16.04）に対応し、操作は汎用

Web ブラウザー (Google Chrome・Mozilla Firefox 等）のインターフェース上で行うことができることから、通常業務との親和性が高い。したがって、同 OSS の導入は容易である。 ePADD が汎用の電子メール管理ソフトウエアより優れているのは、後述するように電子メールの評価選別・整理・検索・提供といったアーカイブズの業務を単一の OSS で処理することが可能な点にある。また、独自に開発した NLP を採用し、固有名詞や特定項目表現の抽出・処理が実行できるシステムとなっている。保存については、処置データを“MBOX”形式（電子メールの保存ファイルフォーマット）でエクスポート可能な仕様となっている。 この機能を介し、ISO 14721 で示される長期保存の要件を満たしながら、大量の電子メー ルを保存できる。

例えば、著名な国際機関や大学などでは、電子記録の長期保存に、OSS ・

Archivematica（Artifactual Systems 社）を用いる事例が散見される[2]が、ePADD で整理と処理を経た後のデータを用いて

Arvhivematica 上で対応している[3]。

以下では、その機能を具体的に確認することとしたい。

## 3.2 各種モジュール$\cdot$他の利便性

ePADD を構成する 4 つのモジュールは、

同 OSS の機能の根幹といえる。それぞれのモジュールは、次のような特徼をもっている。

- 評価選別(Appraisal): 保存処置を行う前に寄贈者・アーキビストともにデータの内容を確認し、評価選別作業を行うことができる。

- 整理(Processing)：メールデータを整理し、 アーカイブズに必要な記述を付すことができる。

- 検索(Discovery) : 制限下のユーザーがメー ルの事項群などを検索することができる。

・提供(Delivery) : 閲覧室などでユーザーがメ ールコレクション情報にアクセスすることができる。

図 1 評価選別モジュール立上時

以上のモジュールは、評価選別段階から、 メールの返信・受信、さらに添付ファイルにいたるまで一括で対応している。よって、前記「2.2」で示した問題に対応することができる。

評価選別の際に、寄贈者の協力は必須である。図 1 に示したとおり、評価選別モジュー ルでは処理結果が可視化され、その際に寄贈者の負担を減らすことができる。具体的には、評価選別時に“NLP” ・ “Lexicon”によって個人情報等が専用の項目に振り分けられる。 それを基に、寄贈者の協力を得ながら選別を進めることが可能となる。電子メールは書簡と異なり、膨大且つ複雑な体系が一括データとなっていることから、こうした機能は整理遂行上、大変有効となる。

その他にも、電子メールをコレクションとして提供するまでの過程を web ブラウザー上で一貫して処理できるため、PC に関する特別な知識を必要としない。これも大きなアドバンテージであろう。

## 4. 多言語対応

以上のように、電子メールをアーカイブズで処置するための機能を有している ePADD だが、日本で導入するには大きなハードルを越える必要がある。現状(Ver.7.3.4)では日本語（多言語）に対応させるためには、コードを改変する必要がある。

## 4.1 日本語化-Lexicon

まず、Lexicon だが、評価選別モジュールにおいてデフォルトで設定されている

“Lexicon Search”で編集可能である。しか

し、運用の利便性から ePADD を立ち上げた際に作成されるディレクトリ“epaddappraisal”内“user”>"data”の"lexicons”ディレクトリで、各テキストファイルを編集することが推奨される。評価選別モジュールの動作時にファイル( .lex.txt)に設定したキーワードが Lexicon に反映される仕様となっている。日本語に対応させるためには、“lexicons”ディレクトリに新規テキストファイル (ここでは “test.japanese.lex.txt”) を作成し、再度メー ルデータをインポートすることで、可能となる。

図 2 test.japanese.lex.txt 反映図

## 4.2 日本語化 $-\mathrm{NLP$}

上記のように Lexicon は容易に日本語へ対応させることが出来るが、NLP の対応はハー ドルが高い。ePADD は Wilipedia や

DBpedia などの外部データセットを活用した Apache OpenNLPを基に開発されている。この点を日本語対応させる必要がある。多言語対応について“EnglishDictionary.java”には 「“util” ・“class”に辞書を作成することで、簡単に他の言語に展開することができる」と記されているが[4]、実際はその対象は広範囲であり、且つ、プログラムコードの知識が必須である。また、管理者のニーズに合わせて NLP を反映させるためには、事前に必要なクラスとプロパティ・マッピングを計画的に構築することが求められる。このようにコードを書き換えることができれば、日本語で語句・区切りを認識させることが可能であり、多言語でのアーカイブズ整理はもちろん、ユ一ザーにも大きな利点となる。

## 5. おわりに

ここまで電子メール保存に関する諸問題を提示し、その解決策となり得る ePADD の機能とその問題について確認してきた。

電子メールは我々が社会生活を行ううえで必須であるが、その多くは、EDRMS の管理を受けていないのが現状である。電子メールのような記録を長期的に保存するには、

EDRMS のような組織統制の枠組みを超えたものをも包含して処置を施す必要がある。保存の対象となるメールの量は膨大であるのに加え、メールそのものだけに完結せず、返信や転送、添付ファイルなどもケアしなければならず、独自の問題を抱えている。ePADD はそうした問題解決に現時点で有効である。 とはいえ、本報告では ePADD が全てを解決するといったことまで提唱する意図はない。同 OSS の肝といえる NLP の多言語対応の必要性とその方策が容易ではないためである。 そもそも日本では、電子メールの長期保存システムの運用が進んでいない。本報告がその進展への契機となることを願う。

## 参考文献

[1] James Lappin, Tom Jackson, Graham Matthews and Ejovwoke Onojeharho. "The Defensible Deletion of Government Email." Records Management Journal. Vol. 29, No. 1/2. 2019. pp. 42-56.

[2] Artifactual Systems 社 web サイトを参照のこと。https://www.archivematica.org/en/ (参照 2021-02-28).

[3] 例えば Canadian Center for Architecture. CCA Digital Archives Processing Manual (参照 2021-02-28).

[4] src $>$ java $>$ edu $>$ Stanford $>$ muse $>$ ner $>$ dictionary> ( https://qr.paps.jp/eCDNU) (参照 2021-02-28).

この記事の著作権は著者に属します。この記事は Creative Commons 4.0 に基づきライセンスされます(http://creativecommons.org/licenses/by/4.0/)。出典を表示することを主な条件とし、複製、改変はもちろん、営利目的での二次利用も許可されています。