Moreq2010®

記録管理システムのためのモジュラー要件

第1巻
コアサービス及びプラグインモジュール
第 1.1 版

第 1 部 コアサービス

DLM
フォーラム財団

Moreq2010®

記録管理システムのためのモジュラー要件

第１巻
第 1.1 版

コアサービス及びプラグインモジュール
版権所有©2010 及び 2011 DLM フォーラム財団、不許複製・禁無断転載[本資料は、MoReq2010 Modular Requirements for Records Systems の Volume 1 Core Services & Plug-in Modules の 1、2章及び 3 章から 12 章のキーコンセプトを抜粋し、仮訳したものです。本資料を参照する場合は、正確を期するため原書をご確認ください。]

2
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

1．基本事項

1.1 重要情報
1.1.1 知的所有権
MoReq2010®仕様は、その中のすべての文章とオリジナル図表を含めて、DLM フォーラム財団 2010&2011
がすべての権利を保有する。
一部の図表は、Microsoft 社[http://www.microsoft.com/] の無料クリップアートを用いている。
本著作物を複製することは、商業利用を除いては、その出典が明記されていることを条件に認める。すべての出典元は DLM フォーラム財団 [http://www.dlmforum.eu/]とすること。
1.1.2 真正性
本文書の最新更新版は[http://www.moreq2010eu/ 又は http://www.dlmforum.eu/ ]からオンラインでのみ入手可能である。
DLM フォーラム財団はこれ以外のいかなるウェブサイト、サービスあるいは流通機構においても、
MoReq2010 の仕様を更新・保守・承認することはない。
1.1.3 引用
本刊行物の正式な引用は、次のようになされること。
DLM フォーラム財団, MoReq2010® : Modular Requirements for Records Systems – Volume 1: Core Services& Plug-in Modules, 2011,published online[http://www.moreq2010.eu/]
1.1.4 翻訳いかなる目的であれ、事前の許可なしに MoReq2010® の翻訳を出版又は配布してはならない。翻訳者は電子メールにて DLM 財団事務局に申請すること[secretariat@dlmforum.eu]。
MoReq2010® の翻訳の許可は、DLM フォーラム財団とその会員が、翻訳版を非営利的に利用可能であり、その翻訳文を MoReq2010® ウェブサイトへ掲載できることを条件とする。
1.1.5 ロゴ及び商標
DLM フォーラム財団 のロゴ、MoReq 管理委員会のロゴ、及び MoReq2010®のロゴは、1996 年から現在まで DLM フォーラム財団 が著作権を保有している。
以下の用語、「DLM Forum」、「MoReq」、「MoReq2」 及び 「MoReq2010」は、DLM フォーラム財団 の団体登録商標である。
原書において欧州委員会のシンボルマークは、許可を得て使用している。

3
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
1.1.6 本書中での凡例
本仕様では、識別の容易さを考慮し、要件とデータタイプの定義を表すには、以下ような接頭文字を付加することとした。
・ D: データ構造
・ E: エンティティタイプ
・ F: 機能定義
・ M: メタデータ要素定義
・ N: 非機能要件
・ R: 要件（機能的）上記の接頭文字をつけられた参照番号の目的は、文書検索に限られている。原書 MoReq2010® の
軽微な改訂の際に関連して付けられる。そのため、将来、大小の改訂が行われた場合には、これ
らの参照番号は変更される可能性がある。
MoReq2010®を実装している記録管理システムやその他のアプリケーションには、情報モデルによって規定される汎用一意識別子（UUID）を常に用いるべきである。
本仕様中の機能要件及び非機能要件には、各要件の明確化と強調を意図し、イタリック体で表示した箇所がある。

1.2

目的

1.2.1 目標
MoReq2010®が策定された目的は、統合的であるが簡単で理解しやすく、なおかつ様々な組織に適用し応用可能であるような電子記録管理システムの要件仕様を供給することにある。異なるタ
イプの記録システム同士が共有できないという従来の記録システムの定義ではなく、多様な記録
管理システムに共通であり、モジュラー形式で、柔軟性を有しており、なおかつ従来では記録管理システムと認識されなかったような高度に専門化したアプリケーションなどへも適応可能なコアサービスに関する定義を確立することにより、多目的利用に供する記録管理ソリューション
を実現する。
本書は、MoReq2010®準拠の記録システムに要求される最小限の機能要件を説明し、エクスポー
トや最終処分などの共通処理を定義し、エンティティタイプやデータ構造、メタデータ要素定義、機能定義を含む基本的情報モデルを確立し、標準化することを目的としている。ここに記されているすべての事項が実装されれば、製造元を問わず、別々に実装された高い信頼度を以てソリューションの間でライフサイクル過程におけるデータの転送や、マイグレーションを含む記録管理システムの相互運用性が確保されるであろう。
MoReq2010® の仕様で記述されている機能は、様々なマーケット、産業、国そして地域のニーズと要求に対応できるように、DLM フォーラムの MoReq 管理委員会の監督の下、 将来開発され得る汎用的なモジュールや特殊なトピックに対応するためのモジュールが拡張を考慮し、意図的に
4
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
構築されている。
また、MoReq 管理委員会から、MoReq2®から MoReq2010®へのアップグレードを希望する利用者に対し、MoReq2010®の互換性に関するガイダンスが別途行われると思われる。
1.2.2 読者
本仕様には、下記のように多様な利用方法が考慮されている。
事業における利用：
・記録システムを購入する際のサポート
・事業上及び法的義務を果たすことを目的とした記録システムを構成する際の支援ツール
・記録システムの実装の監査に係るガイド専門家による利用：
・研修現場における授業及び教材作成のための参考資料
・学術研究利用の教材
・伝統的な記録管理手法やアーカイブズ学を近代的なシステム要件に適用する事例
産業界による利用：
・製造側（サプライヤー）による記録管理システムの開発ガイド
・記録管理システムと業務システムの統合を図る際のガイド・認定の試験センターにおいて本仕様に準拠したソリューションのテストや認証を行う際の典拠
ユーザによる利用：・ユーザ本位でわかりやすい資料及び入門書・翻訳の原文献・記録管理に関する参照用語集
1.2.3 ベストプラクティス
MoReq2010®は、消費者の組織内で適切に策定された戦略的な枠組みの中で、包括的記録管理方
針の一部として利用されるのが最も望ましい。記録管理システムの自動化や、記録管理システム
を個々の業務環境に統合することと同程度に重要なことを、下次に挙げておく。即ち、ユーザを教育すること、記録管理システムの導入を進めること、記録及び情報にまつわるグッドプラクテ
ィスを企業文化として育成すること、組織内において情報ガバナンス要件に対する認識を高める
こと、全ての階層のスタッフに対し、セキュリティやプライバシー、データセンシティビティ、
情報公開、オープンデータイニシアティブ等の重要な項目について認識を高めること、品質保証
5
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
チェック項目を含んだ明解で実用的な手順マニュアルを導入することである。
良い記録管理システムの実現には、事前の計画や今後発生する問題の予測、後述の項目を補うための組織方針と手順を策定し、実施することがが求められる。即ち、保存すべき記録の明確化、記録の生成過程及び獲得過程の明確化、最終最終処分を含む記録など、現用段階のライフサイク
ルに係るすべての局面における個々の記録の保持・管理・アクセス方法の確立である。これらの事前プランは、技術やシステムソリューションにおける寿命の、その先まで検討しておく必要がある。また、記録を現状の記録管理システムへ捕捉する方法を検討と、現在管理している記録の
次世代企業記録管理システムへの移行は、同じウエイトを以て検討されるべきである。
上記のような環境を以て、MoReq2010® に準拠した記録管理システム及び業務システムを採用し利用することは、堅実な組織的投資となる。

1.3

背景
MoReq®

1.3.1

DLM フォーラムと欧州委員会との緊密な協力の結果、2001 年に最初の MoReq®仕様が発表された。
MoReq®は、汎ヨーロッパにおける電子記録を管理するコンピュータシステムの新しい仕様を提供したといえる。この発表以前には、欧州の中で記録管理に関する自国の標準を持つ国はわずかであった。
初期の発表段階から今に至るまで、MoReq®は次の様な特性を有している。
・ 世界的視野と応用：
MoReq®は国際的な仕様であり、欧州内外の多数の国で採用、利用されている
・ 多言語で入手可能：
MoReq®及びその後継版である MoReq2®は、12 以上の欧州言語と、いくつかの非欧州言語に全訳されている・ デファクト標準：
発表当初は、公式標準ではなく単なる仕様とされてきたが、その世界に向けたアピール、
容易に入手可能であることやその採用実績の故に、現在では MoReq®は事実上の標準（デファクトスタンダード）として広く認識されている「MoReq」という名称は、当初 Model Requirement (モデル要件) の略語として用いられており、当初はその仕様が個別ニーズに合わせてさらに変更することができるような、要件のテンプレー
トの役割を果すことが想定されていた。したがって、最初版には、章や要件の追加・編集・削除の方法のほか、それらを行った場合の仕様書内の相互参照に係る問題を適切に扱うことに関するガイダンスが含まれていた。

6
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
1.3.2

MoReq2®

2005 年、DLM フォーラム®はオリジナルの MoReq®仕様の更新・拡張を目的とした調査を完了した。この見直しの結果、MoReq2®が開発され、2008 年初頭に発表された。
MoReq2®の重要な特徴は、試験・認証の制度を取り入れたことにある。システムの供給者（サプライヤ）は、MoReq2®試験センターにおいて自らのソリューションを試験し、製品が MoReq2®仕様に準拠していることの第三者認証を受け取ることができるようになった。こういった試験・認証を支援すると共に、MoReq2®は仕様の中にメタデータモデルを導入し、異なる製品や実装の間で共通なインポート/エクスポートフォーマットを定義する XML スキーマを導入した。
試験・認証の過程の導入は、厳密性の確保に必要な要素と、品質の保証について仕様に取り込んだ、極めて重要で進歩的なステップであった。高品質の製品の供給者は、仕様への準拠性に係る検証を行い認証を得ることができ、なおかつ、消費者も公認の品質標準を満たす製品群の中から製品を選択することが可能になったのである。
しかしながら、この試験制度は「モデル」要件の概念そのものに結びついていたため、予期しなかった結果ももたらされた。仮にその製品が MoReq2®仕様への準拠が認証されていた場合、利用者側の組織は、その仕様をローカルなレベルで変更することがそれまでと比べて困難になる。
仕様への準拠が試験・認証されている汎用の市販ソフトウェア製品の供給側として、利用者側の組織によるローカルな要件の追加・変更あるいは削除をいかに予測できようか。一方で、そして、利用者側の組織は仕様の追加・変更・削除がもたらす仕様が複雑化するにつれ、軽微な問題が全体の仕様の整合性に及ぼす影響について、いかに確信を持てようか。
2008 年 12 月にトゥールーズで開かれた会議において、DLM フォーラム®は MoReq 管理委員会と呼ばれる常置委員会を設置した。MoReq 管理委員会は、MoReq®仕様の中の下記を含む項目のすべての側面について管理を行う役割を担っており、現在に至る。
・仕様の継続的な整備を行うこと、MoReq®のロードマップを発行すること、及び将来の仕様改訂を計画すること
・翻訳事業を管理すること、受領した翻訳の検証作業について調整すること、及び MoReq®翻訳者に指示すること・仕様に対するソフトウェア試験を実施する適合性試験センターに認定を与えること、認定試
験センターが実施するソフトウェア製品の MoReq®に対する試験と認証行為を監督すること・並行進行する教育プログラムを運営すること、ワークショップや研修の提供や追加ガイダン
スや教材を発行すること
・仕様のマーケティングを活発に実施し、ケーススタディを行い、仕様の採用を推奨する共に、
MoReq®のブランドを保護すること

7
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
1.3.3 MoReq®ロードマップ
2009 年、MoReq 管理委員会の作成した MoReq®のためのロードマップは、同年 11 月にスウェー
デンのヘルネーサンドにて開催された会員会合において、DLM フォーラム®の決議として採択された。
ロードマップ(図.1a) には、次のような事項が示されている。すなわち、産業界において、MoReq®
の仕様は、電子文書・記録管理システム(EDRMS)や統合文書情報管理 (ECM) のような事務的な分野における記録管理システムのための要件だとみなされていた。同時に、分野特有の問題を解決する専門的アプリケーションが存在している、医療・製薬・法律・金融サービスの分野での使用にはあまり適していないとされてきた。こういった産業分野では、概してその分野固有の法律や規制によって統制されており、その結果、各分野に特有の記録管理基準を考案し採用する傾向があった。
範囲

ロードマップ
医療
金融
防衛
法律

未来
時期

図.1a MoReq 統治委員会のロードマップ(2009 頃)
MoReq 管理委員会は、上記に加えてもう一つの傾向を示したことは。記録管理システムの設計における不統一性の増加である。元来 MoReq®は、概念的には単一の中央リポジトリモデルに基づいており、組織の独立した記録管理システムが、ユーザや他の業務システムを含む様々な外部からのデータを獲得し、記録システム内部に蓄積することとされていた。この伝統的アーキテクチ
ャは図.1b に示されている。

8
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

業務
システム

記録管理
システム

記録の捕捉
及び
集中管理

図.1b 記録管理システムの「伝統的」アーキテクチャには他の業務システムからの記録の獲得、及び記録システムによって制御されるレポジトリにおける中央集中型管理が含まれる。
MoReq 管理委員会のロードマップは、その代わりとなるアーキテクチャの採用が拡大していることを確認した。この勃興しつつあるモデルの一つ(図.1c) は、記録システムに蓄積機能が無く、対象の記録を複製して自身の集中レポジトリに取り込まずに、その記録が元々生成された業務システム内で管理するものである。

記録管理
システム

業務
システム

発生場所での記録管理

図.1c 代わりとなるアーキテクチャは記録管理システムに対して、記録が発生した場での制御・処理を可能にすることにより、記録をその場で管理する。
もう一つは、業務システム自体に記録制御機能を持たせる方法である。このような業務システ
ムは個々の業務システムによって捕捉又は生成された特定の記録を管理するだけであるが、実質的に記録管理システムを兼ねている。アプリケーションがそれ自体の記録管理システムそのものでもあるというこのアプローチは、「アプリ内」記録管理システムとも称すことができる。記録
管理システムを兼ねた業務システムについては、図.1d に示した。

9
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

業務システムと記録管理
システム

アプリ内記録管理システム

図.1d 記録管理・制御が簡素化、柔軟化し、解釈が進むにつれて、少なくとも業務システム
自身の中で生成された記録に対し、業務システムが記録管理システムの役割を果たす可能性が高まる。
MoReq® ロードマップはまた、大規模な管理システムにも小規模な管理システムにも等しく適応できる柔軟で適応力のある要件の必要性を認めた。MoReq2®の機能要件の数は MoReq®の 2 倍以上に増加し、ページ数は以前の 3 倍近くに増大している。分量と複雑性は、改訂の度に増大していくことが予想され、MoReq が一式の仕様として存続し続けることが不可能であることは明白であった。こういった形で存続を続けた場合、この仕様自身が、特に小規模のローカルでニッチな供給者にとってこの仕様を採用する上での乗り越えられない障害を、もたらすことになったであろう。
これらの理由から、2009 年のロードマップによって、MoReq®の進化における二つの将来フェーズが提された。
・短期的なフェーズとして、モジュラーラインに沿って再構成し、可能な限り簡素化し、そして代わりとなる記録管理システムのアーキテクチャへの対応を導入するための整理（リファクター）プロジェクトを 2010 年に始動した。
・長期的なフェーズとして、2012 年から、産業界の専門家からの支援を受け、よりモジュール重視のアプローチから得られる柔軟性に基づきながら、MoReq® の適用性を、堅実な記録管理が不可欠なあらゆる分野の活動へ拡大すること。
2010 年 5 月にマドリッドで開催された DLM フォーラム財団 AGM（DLM フォーラム財団年次総会）
において、MoReq2010®検討プログラムが正式に発足したことにより、第一の目的が実現した。
1.3.4 MoReq2010®
DLM フォーラム財団は、仕様に係る革新に加え、上記二つのフェーズに関する公開意見聴取を行い、新仕様開発に反映することを決定した。また、欧州委員会はこのプロジェクトへのアドバ
イスを提供する目的で、産業界の各分野を横断するにおける世界的に著名な専門家から構成される MoReq2010® Experts Review Group (専門家評価グループ)を設立した。一般からの意見聴取の10
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
フェーズを開始することで、それまで以上に広範な大学及び社会とのネットワーキングがこの開発計画にもたらされた。このようにして出来上がった仕様は、予想以上に多くの量と高い質の協力的意見に基づき、開かれた方法での開発や議論からの恩恵を受け続けている。
今日の記録管理は複雑な業務になりうる。柔軟で拡張性のあるアーキテクチャを持つ MoReq®は、供給者・利用者・消費者に等しく適して魅力がある記録管理システムの実装関する仕様を設定する際に生じる落とし穴を回避するために、可能なアプローチの一つを提供する。く。
MoReq2010®では「モデル」要件の概念は、「モジュラー」要件に置き換えられている。今や定着したソフトウェア製品の事前試験と認証の制度及び相互運用性の重要性が増加したため、個々の要件の変更やカスタマイズすることに対する価値はないとされている。このような状況にふさわ
しく、新しいモジュラーへのアプローチにより、消費者は単に組織のニーズに対応するモジュー
ルを適宜組み合わせることによって柔軟で総合的かつ整合性のある各自の組織における要件を設定することができるようになった。時間の経過とともに MoReq2010®のコアサービスのプラットフォームに組み込まれるモジュールの数と分野は着実に増加し、より多くの産業、その分野、業種に拡大するであろう。
ソフトウェア供給者もまた、MoReq2010®の整理(リファクター)により恩恵を受けるであろう。
拡張モジュールの追加は継続的になされ、より多くの専門的アプリケーションが採用されることが予想されるが、一方で、要件のコア部分はこれに対応して相対的に縮小するであろう。コアサービスは、ソフトウェア供給者にとって、すべての記録管理システムに共通であり、規定を遵守していること（コンプライアンス）を示さなくてはならない唯一の要件である。したがって、コ
アサービス以外のモジュールの実装及び認証は対象製品の特定の目的、対象分野、及びその特定化あるいは汎用化の程度に依存することとなる。したがって、システムの購入者が彼らにとって意味のあるモジュラー要件を選ぶのと同じ方法で、供給者も彼らの目標とする市場に合わせてモジュールを自由に選ぶことが可能となる。
MoReq2010®のアプローチから直接恩恵を受ける第 3 のグループとして、記録管理の専門家、実務者が挙げられる。MoReq2010®は、あらゆる側面において、記録管理の先端理論とベストプラク
ティス情報を直接仕様に結びつけようとしている。専門家は、MoReq2010®において使用される概念、用語、及びモデルは他の国際標準で用いられているものや指導的専門家により提唱されているものに緊密に結びついていることに気づくであろう。従って、本仕様は実用的応用の他に、優れた学習と教育のプラットフォームを形成している。
2011 年は DLM Forum®の 15 周年であり、MoReq2010®の 10 周年を記すものである。これらの重要な記念日にあわせて発表された次世代の「モデル要件」である MoReq2010®は、欧州及び世界中で、適切な記録管理に対する認識の向上と理解、導入を促す飛躍台として活用されるべく、まっすぐに将来を見据えている。

11
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

1.4

入門編

1.4.1 記録と情報
どのような組織や市民も、記録を持ち、それを利用している。
記録とは、あるものに対して証拠的価値があり、それ故に保存や安全な保管が必要とされるような本質的価値を有する情報の塊である。
例えば、大多数の人々は、彼ら自身のアイデンティティの証拠するような何種類かの記録を保有している。これらには、次のようなものが含まれるであろう。
・出生証明書・パスポート・運転免許・身分証明書上記の例において、記録の重要性と証拠性は明らかである。しかしながら、記録とは、常にそうであるとは限らない。通常、人々は自分の所有するすべての情報が必ずしも記録と考えている訳ではない。
例えば、買い物リストは記録とはみなされないが、その買い物リストに書かれていた品物を購入した店からの領収書は、その購入を証明するものであり、もしそれが個人にとって、又は営業にとって重要である場合には、記録として考えられるかもしれない。このような領収書は雇用主からの払い戻しに使われるかもしれないし、あるいは購入品が傷ついていたり、腐っていた場合には代金の払い戻しのために使われるかもしれない。この例は、図.1e に示されている。

図.1e おそらく一つは記録ではないが、もう一つは記録である。
情報と記録の区別は、組織に関しても個人の場合と同じである、即ち、いかなる組織においても、図.1f のベン図で示されるように、全ての記録の集合はその組織の情報資産の全集合の部分集合である。

12
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

情報記録

図.1f 記録は、個人又は組織が保持している全ての情報の部分集合である。
ある情報が記録であるかないかを決めるためには、その情報が持つ組織への関連性と重要性とともに、業務上のコンテキストが理解されなくてはならない。従って、全ての組織にとって重要な課題は、その業務に関する理解を獲得し、その理解を用いて、その業務において記録として保存され管理されるためにはどのような情報が必要であるかを評価することである。
初期の草案や不完全な帳票など、組織に所属する情報であるが記録としてはみなされないもの
は、一時的なものと判定されなければはならず、定期的に削除されなければならない。例えば、作成過程に保存されたドラフトは文書が発行された時点で削除できるし、部分的な取引情報は、取引が完了又は取り消された時点で削除することができる。
一時的な情報の削除をしない場合には、良くても、冗長なデータや不完全なコピーにより組織のデータ蓄積容量を浪費し、且つ、どのデータが完全で正しく、どれが不完全なのかを探索することに従業員の時間を浪費することになる。最悪の場合、それはプライバシー等の規制に違反することになり、法的手続き又は情報公開請求などの要求があった場合に、必要な情報をまとめるための高い金を払って作業をする破目に陥る可能性がある。
1.4.2 記録管理処理プロセスとシステム
記録管理に関して国際的に最も影響力のある標準は、おそらく、2001 年に発行された ISO
15489(ISO 15489-1:2001: Information and documentation – Records management –Part1:General,
情報及びドキュメンテーション―記録管理―第 1 部：総説)であろう。
記録として管理すべき情報を決定することは、この標準が識別している記録管理処理プロセスの中の最初の処理プロセスにすぎない。ISO 15489 で識別されている記録管理の全処理プロセスには次の項目が含まれている。
・記録保持期間の決定
・記録の作成と登録・記録の分類・記録の保管と取扱い・記録へのアクセスの制御
13
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
・記録の追跡・記録の最終処分
・記録管理処理プロセスの記録
上記の処理プロセスを実現するために、組織は記録管理システムを使用するべきである、と ISO
15489 は提案している。同標準は、記録管理システムを「長期間，記録を取り込み，維持し，ア
クセスを提供する情報システム」と定義している(ISO 15489-1:2001,3.17)。
MoReq2010®は、モジュラー要件の集合として表現される記録管理システムを定義するための仕様である。この仕様は、ISO 15489 で与えられている概要説明を超えた内容を持ち、これらの処理過程がどのようにして実行されるのが望ましいかについて、はるかに具体的な説明を加えている。MoReq2010®に準拠することは、単に ISO 15489 で記述されている処理プロセスを取り扱うための記録管理システムを独自の方法で実現するよりも、はるかに高い厳密性が求められる。
このことの利点の一つであり、また MoReq2010®の設計目標は、MoReq2010®準拠記録システム(MCRS：MoReq2010 compliant records systems)間の相互運用性である。MCRS は自身のエンティ
ティと処理過程を理解するだけではなく、それらを他の MCRS が理解することができる標準フォーマットにエクスポートすることができる。
相互運用性は、記録管理システムを用いて記録管理を行う上で必須である。現在の組織はその技術を 3 年から 5 年で更新するのが普通である。記録はそれよりもはるかに長く保持されるのがしばしばである。そうであるなら、もしある組織が特定の記録を 75 年間維持することを求められているとすると、その期間の終わりには、その記録は一つの記録管理システムから別のシステ
ムへと 15 回から 25 回移動されることになる。図.1g はこれを示している。もし各回の移動の度に記録に関する何らかのコンテキスト情報が失われるとすると、これほどの回数の移動は、記録の完全性に対して重篤な影響を与える恐れがある。

記録
作成

記録
移動

記録管理
システム

記録
移動

記録
移動

記録管理
システム

記録管理
システム

等々

図.1g 記録はその寿命中に記録管理システムの間を複数回移動されるであろう
インポートは MCRS のコアサービスには含まれていないが、すべての MCRS はその情報を
MoReq2010®共通 XML エクスポートフォーマットにエクスポートできなければならないということに留意するべきである。インポートはエクスポートに比べてアプリケーションのはるかな高度化を必要とし、それをすべての記録管理システムに要求するれば、多くの専用業務システムが14
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
MoReq2010®の適用を除外するであろう。
1.4.3 記録の性質
証拠的価値のある情報のうち、ほぼ全ての情報は。記録として管理可能である。記録とは、ISO
15489 によって「法的な責任の履行、又は業務処理における、証拠及び情報として、組織又は個人が作成、取得及び維持する情報」(ISO 15489-1:2001,3.15)と、正式に定義されている。。即ち、。
過去、記録は主に紙ベースであったが、21 世紀にはこれは指数関数的に増加する電子的情報へと容赦なく置き換えられてきている。しかしながら、例えば、生体医学的あるいは法医学的試料の跡を辿る等、紙媒体記録と他の物理的記録の双方に対して物理的な記録管理を行うシステムの必要性は、常に存続するであろう。
物理的であろうと電子的であろうと、すべての記録はある特性を持っており、ISO 15489 はこれらの基本的特性を次のように列挙している。
・真正性：記録した本人をによって作成され、作成当時に主張されていた通りであること
・信頼性：記録された情報について正確であると信頼できるもの。
・完全性：内容が完結しており、改ざんされていないもの
・利用性：存在場所が分かり、検索可能であり、表示可能であり、解釈可能なもの
上記の特性について MCRS は、その記録が記録管理システムの中で作成された時点でのみ保証可能である。ISO 15489 に述べられているように、「記録は、関連する処理又は事象の発生時に、又はその直後に、事実について直接知っている個人又は処理を行う業務で日常的に使われる機器によって作成されることが望ましい」(ISO 15489-1:2001,7.2.3)のである。
このステートメントは、記録が作成される方法が以下の２通りであることを示している。
・個人により作成される場合
・機器により作成される場合
MoReq2010®では、人間と業務システムの両方が記録管理システムの「ユーザ」となることが可能で、記録を作成することを認められる。MCRS は人間のユーザのみと、他の業務システムのみと、あるいはその両方とインターフェースをとるように開発することができる。
前に列挙した特性に加えて、記録管理システムの中のすべての記録は、それに付随するメタデータを持たなければならない。ISO 15489 によるとメタデータとは、「記録のコンテキスト，内容，構造，及びある期間の記録の管理について説明したデータ」(ISO 15489-1:2001,3.12)と定義されている。

15
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
1.4.4 エンティティとサービス
MoReq2010®準拠の記録管理システムは記録をエンティティとして管理する。記録とは、この仕様書で定義されたエンティティタイプの一つにすぎない。記録に加えて、MoReq2010®では多くの他のタイプのエンティティを定義している。例えば、MoReq2010®では、記録システムにアクセスするユーザを表現する「ユーザエンティティタイプ」、記録システムの分類体系の中のそれぞれのエンティティのための「クラスエンティティタイプ」などを定義している。エンティティタイ
プの全リストは 14.2

エンティティタイプに示されている。

MCRS で管理されるエンティティが異なるタイプであっても、MoReq2010®はそれらのメタデータの表現方法や、イベント履歴の管理方法、及びアクセス制御やエンティティライフサイクルが極力均一なものになるように努めている。他の情報システムにおけるエンティティと違い、MCRS でのエンティティは削除されるのではなく廃棄される。このために MCRS 内にエンティティが残留する。残留したエンティティはシステム中にかつて存在したエンティティを示すもので、記録シ
ステムにおいては重要な概念である。なぜなら、このような存在なしには、歴史的記録のコンテ
キスト完全に再現することは不可能であるからである。
MCRS 内部では、異なるタイプのエンティティは「サービスベースアーキテクチャ」では異なるサービスで管理されると簡単に説明されている。(2．システムサービスを参照のこと。)
・ユーザ及びグループサービスはユーザエンティティとグループエンティティを管理する(3．
ユーザ及びグループサービスを参照のこと)
・ロールサービスはロール（役割）を管理する(4．モデルロールサービスを参照のこと)。
・分類サービスは類型を管理する(5．分類サービスを参照のこと)。
・記録サービスは記録及び記録の集合を管理する(6．記録サービスを参照のこと)。
・メタデータサービスはメタデータ及びメタデータテンプレートを管理する(7．モデルメタデータサービスを参照のこと)。
・最終処分スケジューリングサービスは最終処分スケジュールを管理する(8．最終処分スケジューリングサービスを参照のこと)。
・最終処分保留サービスは最終処分保留を管理する(9．最終処分保留サービスを参照のこと)。
他のサービスは純然たる処理プロセスに基づくもので、エンティティを管理することはない。
これらには次のものが含まれる。
・探索及び報告サービス(10．探索及び報告サービスを参照のこと)。
・エクスポートサービス(11．エクスポートサービスを参照のこと)。
MoReq2010®は言語を使用しサービスベースアーキテクチャの採用を推進しているが、歴史的には記録管理システムは必ずしも個別のサービスモデルを用いた機能を提供してきたわけではな
いことを認識している。このような理由から、MoReq2010®は、単にその機能要件を論理的サービ
16
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
スとして束ね、機能要件のそれぞれの「サービス」（の束）に対して試験をすること以上のこと
は行っていない。実装において個別のサービスを提供しないような MCRS でも、依然として
MoReq2010®仕様に準拠していることが認証されるであろう。
それにもかかわらず、MoReq2010®で採られた方法は計画的であり、また将来を予測したものである。即ち、相互運用性というものが一つの MCRS から別の MCRS への記録の移動だけに限られるもではなく、異なる記録管理システムが同じサービスを共有することができるような将来である。
将来の組織においては、あらゆる記録管理システムがユーザ及びグループサービス、ロールサー
ビス、分類サービス、メタデータサービス、最終処分スケジューリングサービス、最終処分保留サービス、及び/又は探索・報告サービス等について、それぞれ単一のサービスを利用することができるようになるかもしれない。
このようなアプローチは、業務分類の体系をその組織内全体に渡って定義し、共用の分類サービスを用いて集中的に管理することを可能にするであろう(図.1h)。同じことが他のサービスにも等しく当てはまる。

記録管理
システム

集中型分類
サービス

記録管理
システム

記録管理
システム

図.1h 将来は複数の記録管理システムが単一の集中型分類サービスを共用することができるであろう。
共用サービスの利用は、必ずしも一つの組織内だけに制約されるものではない。例えば、規制当局が、広範にアクセス可能な最終処分スケジューリングサービスを主催することにより、その業界におけるすべての組織によって利用されるべき最終処分スケジュールの標準セットを発行・維持することが可能になる。また、訴訟当事者間で共有することができる最終処分保留サー
ビスは特定の法廷から発行された最終処分保留を管理することも考えられる。
1.4.5 分類と集合
MoReq2010®にはこの他に、分類と集合の区別等の、いくつかの新しい概念が存在する。ISO 15489
は分類を次のように定義している、「分類システムで示されている論理的に構成された規定、方法 及 び 手 順 に 従 っ た 分 類 に よ る 業 務 活 動 及 び / 又 は 記 録 の 系 統 的 な 識 別 及 び 配 列 (ISO15489-1:2001,3.5)。
17
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
分類というのは、記録に対して業務コンテキストを提供することにより、その記録とそれが作成された事務活動との関係を設定することであるのに対し、集合とは関連する記録を集める活動を述べるものである。分類とは異なり、集合は業務コンテキストだけでなく、組織のどのような要件及び基準に立脚してもよい。集合は下位の集合が上位の集合を構成するという層状の構造を持っている。記録管理システム全体を一つの最高位の集合と考えることもできるかもしれない。
一部の記録管理仕様では、歴史的に、それぞれの記録のクラスが常に集合を経由して受け継がれるように集合の層の上に階層型分類体系を結合している。図.1i に示されているこのアプロー
チは、上位の集合の代わりにクラスを用いている。このような構成は、もしそれが実現可能であ
るなら、その単純さのゆえに望ましくはあるが、同時にそれは柔軟性に欠けるため、必ずしも実際の役に立つとは限らない。このアプローチによって課せられる制約は、多くの場合に、組織や主題を基礎とする要素を機能的業務分類の仕組みに混入させ、ローカルな混成システムを作り上げるように導いてきた。

クラス

アグリゲーション(集合)

リレーションシップ

レコード
(記録)

(関係)

図.1i クラスと集合の両方が一つの構造に結合している伝統的な分類と集合の階層型モデル。このアプローチは MCRS により実現可能であるが、MoReq2010®はさらに大きな柔軟性を可能にする。
多くの組織は、共同の作業、ケースワーク又はプロジェクト主体業務などを実施する。これらの業務が始まる時、その組織では、その記録が作成される業務活動又はプロセスに純粋に基づいた集合ではなく、特定のプロジェクのような中心的トピックに基づく記録の集合を形成させがちである。
例えば、小規模な組織では、各メンバーに関する記録を、それぞれのメンバーに一つの集合で保存する可能性がある。各メンバーの集合の中には、次のようなものが発見されるかもしれない。
・メンバー登録票の原本、評価及び承認・身分証明書、様々な変更通知を含む銀行及びコンタクト先の詳細
・年間購読及び会員権更新
・組織内での応募、任命、及び地位
18
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
・そのメンバーによって行われた様々な関連活動に関する通信等の情報・経費及び払い戻し請求・契約書、証明書、法律文書及び権利放棄書
等々
この例では、メンバーの集合の中の記録はそれぞれ異なる機能、活動及び取引に関連している
ため、それぞれ異なる業務分類を必要とすることになる。これらの分類においては、各集合内のある記録は比較的長い法定保存期間中保管されなければならないのに対し、その他の記録は短期間の保管の後廃棄するべきものであるのはなぜか、ということに関しては法律上、規制上又は実務上の適切な理由があるかもしれない。
このような組み合わせ方は、広範な組織で見られることであるが、これを図.1i に示すような伝統的な階層的分類に基づく構造に押し込めることは困難である。これは、伝統的組み合わせ方
においては、集合の全メンバーが分類体系における単一のクラスに属さなければならないからである。
この結果、実用上及び運用上の効率と記録管理上の要件との間に必然的に軋轢が存在する。分類体系が、例えば、「ケースワーク」、「顧客」、「プロジェクト」、「スタッフ」、及び「イベント」のような多目的分類をとりいれた混成型であろうが、あるいは自然発生的集合を分割し、例えば、すべてのメンバーの登録記録が「メンバーシップ応募」という名の下で単一の分類/集合に属し、一方で全メンバーの年間契約記録は、「2011 年メンバーシップ更新」のように全く異なる分類/集合に属すというような場合であろうとも、いずれの妥協案も完全に満足できるものではないと見られる。
分類と集合という関連する概念の間の相違を明確にすることにより、MoReq2010®は、どの記録を一緒に保持するのか、また同時にどの分類体系を採用し、どう適用するのか、ということの決断をする上での計画を立てる際に、大きな柔軟性を与えてくれる。このことは転じて、MoReq2010®
の実世界の状況に対する適応性を高めている。この仕様では運用上の基準に基づいた集合を可能にしている一方で、分類はどの層の集合に対しても適用できるようになっている。この中には、もし必要であれば、記録個々に対してクラスを関連づけることも含まれている(このことは図.5dに示されており、また 5．分類サービスの章で検討されている)。同時に、図.1i に示されている
伝統的アプローチへの後方互換性は維持されている。
1.4.6 保存と最終処分
MoReq2010®は業務分類を保存及び最終処分とに緊密に関係づけている。これにより、それぞれのクラスは最終処分スケジュールを有し、デフォルトの場合には各記録はそのクラスの最終処分
スケジュールを承継する（「分類が運命を決する」という原理に基づく）。これは、最終処分ス
ケジュールは記録の集合から承継し、その分類からは間接的に承継しているに過ぎない一部のアプローチとは異なっている。
MoReq2010®における最終処分スケジューリングの重要な特色は、一つの記録が同時に複数の最
19
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
終処分スケジュールに従うことは許されていないことである。本仕様では、記録のクラスから承継したデフォルト最終処分スケジュールを無効にすることができるが、いかなる時点においても、唯一の最終処分スケジュールのみが特定の記録に適用される。したがって、ユーザの直接介入による解決が必要となるような最終処分スケジュールの矛盾が起こる余地はない。
一つの集合の中の記録はお互いに異なる分類に属することができ、また各記録はそのクラスで承継している最終処分スケジュールをそれぞれ有しているので、一つの集合の中の個々の記録がそれぞれ異なる最終処分時期を持つ可能性がある。この廃棄時期は、組織が用いている最終処分
スケジュールと最終処分トリガーの設定次第である。
MoReq2010®では、その集合の中のすべての内容が破壊され、集合が閉鎖された場合にのみ、その集合を廃棄するという、ボトムアップ原理を用いている。ボトムアップ廃棄については、その詳細が 8.2.9 ボトムアップ廃棄にて説明されている。
ボトムアップ廃棄の利点の一つは、集合が最終処分スケジュールを持つ必要がないことである。
MoReq2010®にはただ一つのタイプの最終処分スケジュールが存在し、それは記録と関連している。
MoReq2010®は最終処分措置を個々の記録に適用しているが、同じ最終処分措置を多数の記録に同時に適用することは可能である。例えば、MoReq2010®は一つの集合全体に対して一斉に同じ最終処分措置を適用する権限をユーザに与えている。このことは、簡単ではあるが柔軟性を保ちつ
つ、保存と最終処分措置における使いやすさを可能にしている。
1.4.7 イベント履歴と監査
ISO 15489 はメタデータ又はその代替としての監査証跡の使用について、「特定の記録に関して発生したすべての事務処理の完全かつ正確な説明」(ISO 15489-1:2001,8.3.2)として要求している。。MoReq2010®はこのアプローチを採用したが、さらに各記録に関するイベント履歴の概念
を ISO 23081(ISO 23081-1,2006：情報とドキュメンテーション-記録管理プロセス―記録のためのメタデータ Part 1:原理)から採用することにより拡張した。
記録のためのメタデータの国際標準である ISO 23081 は、イベント履歴について、「イベント
履歴メタデータのグループが、エンティティとそのメタデータ両方における過去の記録のイベン
ト及び他の管理的イベントを、記録する」事と説明されている。と。イベント履歴は、それぞれのイベントに関して、そのタイプ、何が起きたか、いつそれが起きたか、なぜ起きたか、そして誰がそれを実施したかを明記する。この要素におけるメタデータは、具体的イベントを記述する
シーケンスである。
MoReq2010®では、すべてのエンティティはそれに付随するイベント履歴を有する。このことは、
エンティティが一つの記録システムから別のシステムに移動されるような場合の相互運用性を支える上で特に重要である。それぞれのエンティティは、そのメタデータ、イベント履歴、アクセス制御等を含む全体として移動する。イベント履歴は、エンティティの重要な構成要素であり、このアプローチはそのエンティティが過去の記録システムの一部であった時に発生したイベントをインポートしそれを完全に理解することをすべての MCRS に対して可能にするものである。
イベント履歴はエンティティと結びついてはいるが、MoReq2010®ではユーザがすべてのエンテ
20
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
ィティに関して探索をし、それらを発生時期の順に整列させることが可能であるため、依然として MCRS 全体に「システム監査証跡」の観点を持たせることができる。
MoReq2010®においては、エンティティが ISO 15489 に沿って廃棄された場合には、そのエンテ
ィティのイベント履歴とメタデータは取り除かれる。ここで、ISO 15489 では次のように記述されている。即ち「監査証跡は、それが関連している文書（すなわち記録内容）が保存されている期間と同じかそれ以上は保持されることが望ましい」(ISO 15489-1,2001:8.3.2)。
1.4.8 モジュラー・アーキテクチャ
図.1j は MoReq2010®のモジュラー・アーキテクチャを示している。図の中のそれぞれの正方形
はサービス又はモジュールを代表している要件のまとまりを表現している。コアサービスは、仕様の第１巻で定義されており、MoReq2010®に準拠するための最小限の機能を提供している。言い拡張モジュール

プラス

プラス

第２巻以降

換えると、これらは可能な限り単純化された MCRS である。

プラス

プラス

プラス

プラス

第１巻

コアサービス

プラグイン
モジュール

又は

シリーズ
®

図.1j MoReq2010 仕様書の構成
コアサービスにより記述されている機能は、伝統的であるが等しく正しい手法を用いて実現することができるものがある。この場合には、MoReq2010®はプラグインモジュールを利用する。それぞれのプラグインモジュールは同シリーズ中の他のどのモジュールとも全く同じ機能を表している。MCRS は、シリーズ中の少なくとも一つのプラグインモジュールで記述される機能を実装しなければならない。また、複数ののプラグインモジュールを選択してもよい。
次の分野の機能に柔軟性をもたせるために、コアサービスによってプラグインモジュールが使われる。
・ インターフェースのタイプ

MCRS が人間/コンピュータインターフェースを介して直接管理されているか、又はマシンインターフェースを介した業務支援システムとして管理されているのか等。
・ 分類のタイプ MCRS が異なる分類方式、例えば、階層型分類体系を採用することを許容し
21
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービスている・ 記録コンポーネントのタイプ MCRS が、物理コンポーネントではなく電子コンポーネントのような、異なるタイプの記録をサポートすることを許容している
MoReq2010®仕様の第１巻で記述されているコアサービスとプラグインモジュールは、その上に異なる拡張モジュールを受け入れることができる必須のプラットフォームを形作っている。
MoReq2010®への拡張モジュールの範囲と多様性は広範であり、以下の事項を含むであろう。
・ インポートのような追加サービス
・ バイタル記録のような追加的概念
・ 電子メールのような特定の技術
・ 特定の産業と管轄用の記録管理システムに対する要件
図.1j に示すように、拡張モジュールはコアサービスを拡張するとともに、お互いに利用しあうこともできる。本仕様のそれぞれのモジュールにおける前書きには、あらかじめ満たすすべき条件と、同時に満たすすべき条件のリストが提示されている。
あらかじめ満たすべき条件とは、MCRS が拡張モジュールとともに、この条件のモジュールを実装しなければならない、という依存状態と定義している。同時に満たすべき条件とは、もしそれが拡張モジュールと一緒に実装された場合には、追加の機能要件を誘引するようなモジュールである。
1.4.9 モデルサービス
MoReq2010®の開発では、記録管理業界の現在の状態と、MoReq2010®仕様書と MoReq 管理委員会
によって推進されている将来像との間で折り合いを付けることが求められてきた。これは特に、ロールとメタデータの二つのサービスにおいて顕著である。
MoReq2010®は、相互運用性のためにエンティティのアクセス制御とそのメタデータ要素の両方を体系化し、これによって両者が適切にインポート、解釈、又は利用されるような新しい記録シ
ステムに移動できるよう成文化に努めている。アクセス制御については、それらが受信側システ
ムにて書き換えられてしまうにしても、元のシステムのどの記録に対して誰がアクセスしたのかという重要な知見を提供可能であり、メタデータ側としては元のエンティティに関する貴重なコンテキスト情報を記述可能である。
これまでの仕様はいずれも、これらの問題に標準化を通じて取り組んでこなかったため、製造者側は必要にせまられて、彼らの記録システムソフトウエアの中でメタデータ及びアクセス制御を適用するための個別で独自の方法を実装してきた。その結果、すべての MCRS に共通なメタデータモデル又はアクセス制御モデルをこれらの実存するソフトウェアの中で採用するためには、
非現実的な量の再構成が必要となるだろう。
このため、MoReq2010®はこれらの二つのサービスをモデルサービスとして指定している。モデ22
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
ルサービスとは見本サービス（an egamplar service）である。即ち、それは、現存の製品がMoReq2010®への適合性及びその認証を求めることへの障害とならずに、将来新しい記録管理ソフ
トウェアを開発するための適切な方法として採用されることを意図している。
MoReq2010®では、モデルサービスへの適合性の証明について、次の二通りの方法のどちらも認めている。方法 A はそのモデルサービスに対する機能要件を実装し、その要件に対し試験を実施するものである。方法 B は、主に既存のソフトウェアを対象として意図しており、製造者独自のソリューションが、モデルサービスと同程度に豊富な機能を持ち、構造とデータを変換することが可能で、あたかもモデルサービス実装システムから生じたたかのようにエクスポートされる場合である。
エンティティ、メタデータ、及びアクセス制御は、標準型 MoReq2010®、XML エクスポートフォ
ーマットに有意な形でエクスポート可能でなければならないという要件は、どのようなモデルサ
ービスに準拠する上でも必須である。この要件が達成できるのであれば、別の MCRS がモデルサービスに係るエンティティをインポートすることが可能となる。
1.4.10 試験と認証
DLM フォーラム財団は MoReq2010®のための試験・認証プログラムを開始した。このプログラム
によって、市販の記録管理システムの供給者のみならず、社内開発の記録システムも DLM フォー
ラム財団認可の MoReq2010®試験センターによる試験を受けることが可能である。
供給者はその製品に対して、コアサービスに関する試験を受けさせなければならない。また、
任意で、どのような追加の拡張モジュールの試験を受けさせることも可能である。MoReq2010®試
験の枠組みを用いた試験に合格すると、製品又は設備は DLM フォーラム財団により、MoReq2010®
準拠として認定を許可されるとも考えられる。
DLM フォーラム財団の会員は、試験報告へのアクセスができ、それにより MoReq2010®に準拠した種々の記録管理システムに関する事前調査を行うことが可能であり、また、供給者は自らの製品が MoReq2010®に完全に準拠していることを示せるだろう。
DLM フォーラム財団は MoReq2010®認可の試験センター及び MoReq2010®準拠の記録管理システムのリストを自身のウェブサイト(http://www.dlmforum.eu)に掲示する。

23
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

2．システムサービス

2.1

サービス情報MoReq2010®のそれぞれのコアサービスは、そのサービス名 (例、ユーザ及びグループサービス)、
サービスバージョン(例、1.0)、及び実装サービス識別子、又はプラグイン及び拡張モジュールの場合には実装モジュール識別子(Implements Module Identifier)により規定される。
これらの詳細は「サービス情報」に関するブロックで解説した(3.1 サービス情報参照)。実装
サービス識別子とは、そのシステムがどのサービスを実装しているかを示す、MCRS 内部で使われる汎用一意識別子ことである。
本節では、MoReq2010®のすべてのコアサービスに共通な機能を纏めており、したがって個別のサービス情報は含んでいない。個々のサービスついては、サービス情報のブロックを参照のこと。

2.2

主要概念

2.2.1 サービスベースアーキテクチャ
MoReq2010®コアの機能要件は図.2a に示すように 9 つのサービス定義に束ねられている。これ
らのサービス全体が MCRS により要求される機能を述べている。2．システムサービスと名付けられたこの初期モジュールはすべての MoReq2010®コアサービスにより要求される共通機能を説明している。
MoReq2010®のサービスベースアーキテクチャには、ソフトウェア供給者が多数の又は全てのコアサービスの機能を結合し、それを一つのアプリケーションから供給するようなソリューション
を開発することを妨げる意図はない。しかしながら、MoReq2010®のアーキテクチャを別個のサービスに分割することによって、各々のサービスがお互いに切り離され、複数の MCRS に共用されるような記録システムの開発が供給者により将来検討されることになる事も考えられる。
例えば、将来、ある組織内におけるそれぞれの記録システムを同じ分類サービスや同じ最終処
分保留サービスを共用することが可能になるかもしれない。また、将来、別々の供給者からの別々のサービスを調達し、それらを統合して一つの MCRS に組み立てることも考えられる。
単一のアプリケーションとして供給されたにせよ、緊密に統合された、又は緩やかに統合されたサービスの集まりとして供給されるにせよ、すべての MCRS ソリューションは同一の準拠基準に基づいて試験されなくてはならない。

24
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

MCRS のサービスベースアーキテクチャの核には、その記録サービスにある。記録サービスは、他の MCRS と共用できない唯一のコアサービスである。実際、記録サービスのみが文字通り、一つの MCRS を他と区別するものである。記録サービスをサポートする他のすべてのサービスは、同時に他の記録サービスをサポートすることができるため、数個の MCRS ソリューションの一部となることが可能である。

4. モデルロール
サービス

3.ユーザ及びグループ
サービス

インターフェース

5.分類
サービス

7. モデル
メタデータ
サービス

6. 記録サービス

コンポーネントストレージ

8. 最終処分
スケジュー
ルサービス

11. エクスポートサービス
10. 探索及び報告サービス

9. 最終処分
保留サービ
ス

コアサービス

構成物（サービスではない）

モデルサービス

プラグインモジュールをサポート

図.2a サービスベースアーキテクチャに基づく関連サービスのグループ化としての観点による MoReq2010®準拠記録システム(MCRS）(数字は、各コアサービスは仕様書の中で各自の章番号に対応)。
2.2.2 モデルサービスとプラグインモジュール
MoReq2010®のコアサービスの内の 2 つはモデルサービスである（これらは、4．モデルロールサービスと 7．モデルメタデータサービスである。）。仕様によりそれぞれのサービスの機能要件のデフォルトセットが提供されているものの、供給者がインポートモジュールのような高度のモジュールをサポートすることを欲している場合を除いては、MoReq2010®は供給者にこれらのサービスを正確に仕様通りに実装することを要求していない。
コアサービスの中にはまた、プラグイン機能が設定されている 3 つの分野がある。プラグイン
モジュールとは、同じ目的を異なる方法で達成する代替的でありながら同様に正しい機能セットを表している。供給者はどちらのアプローチを採用するのか選択することができる。各 MCRS は25
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

その機能の少なくとも一つの実装物のへサポートを供給し、またそれに対する認証を獲得しなけ
ればならない。また、同じシリーズ中の他の代替プラグインモジュールをサポートし、認証を獲得してもよい。MCRS へのインターフェースは、プラグイン機能が定められている一分野の例である。
2.2.3 ユーザとのインターフェース
MoReq2010®はユーザが常に記録システムと直接インターフェースすることを要求しているわけではない。
伝統的な記録システムの実装は、ユーザはグラフィカルユーザインターフェース(GUI)を通して直接記録システムとやり取りを行っていた（図.2b）。

グラフィカルユーザ
インターフェース(GUI)

図.2b ユーザは GUI を通して記録システムと直接情報交換する。
一つあるいは数個の異なる業務システムをサポートする記録システムが開発されつつある。これらの記録システムは GUI ではなく、アプリケーションプログラミングインターフェース(API)によって業務システムと直接やり取りを行う。図.2c に示されているこのシナリオでは、ユーザ
は、業務システム内でのユーザの行動の結果として、間接的にしか記録システム内での機能をはたしていない。ユーザは別個に記録システムがあることさえ気づかないかもしれない。

業務システムアプリケーション
プログラミング
インターフェース
(API)

図.2c ユーザは API を通じて記録システムと間接的に情報交換する。
MoReq2010®は MCRS がどのタイプのインターフェースをサポートするのかを指定できるようにすることにより、これら両方のタイプの記録システムへのサポートを提供している。
このとき MCRS は、複数のタイプのインターフェースを同時にサポートすることができる。
同様に、MoReq2010®の各々のコアサービスでは、それぞれ異なるインターフェースオプションをサポートすることが可能である。
例えば、探索及び報告システムは GUI を提供している一方で、

26第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

ユーザ及びグループシステムでは API を提供することが可能である。
MoReq2010®全体を通して、MCRS のユーザは必ずしも人間である必要はない、ということを心に留めておくことは重要である。代わりに、承認ユーザは業務システムのであることもありうる。
2.2.4 エンティティタイプとサブタイプ
各々の MoReq2010®コアサービスは、指定された数のエンティティタイプに属するエンティティを管理する。MoReq2010®コアサービスは下記のエンティティタイプを参照する。
・ アクセス制御リスト･･･4．モデルロールサービスにて定義
・ 集合･･･6．記録サービスにて定義
・ クラス･･･5．分類サービスにて定義・ コンポーネント･･･6．記録サービスにて定義
・ 最終処分保留･･･9．最終処分保留サービスにて定義
・ 最終処分スケジュール･･･8．最終処分スケジュールサービスにて定義
・ エンティティタイプ･･･2．システムサービスにて定義
・ イベント･･･2．システムサービスにて定義
・ 機能定義･･･2．システムサービスにて定義
・ グループ･･･3．ユーザ及びグループサービスにて定義
・ メタデータ要素定義･･･7．モデルメタデータサービスにて定義
・ 記録･･･6．記録サービスにて定義
・ ロール･･･4．モデルロールサービスにて定義
・ サービス･･･2．システムサービスにて定義
・ ユーザ･･･3．ユーザ及びグループサービスにて定義
これらの各々のエンティティの属性を示す表は 14.2

エンティティタイプに示されている。

アクセス制御リストとイベントは他のエンティティタイプと一緒にリスト化されているが、これらは独立したエンティティではない。アクセス制御リストとイベント以外のすべてのエンティ
ティはそれに付随して、イベント系列で構成されているイベント履歴とアクセス制御エントリーの系列で構成されるアクセス制御リストを持つ。
それぞれのサービスで管理されているエンティティタイプは 1.4.4

エンティティとサービス、及び R2.4.9 の原理に関する説明にて説明されている。例えば、最終処分スケジューリングサー
ビスが最終処分スケジュールを管理する一方で、記録サービスは集合、記録及びコンポーネントを管理する。MCRS の中でサービスが論理的に分離されていないところでは、その MCRS はすべての MoReq2010®においてエンティティタイプに属すエンティティ全体を管理しなくてはならない。
MoReq2010®では、それぞれのエンティティタイプの中の特化したサブタイプを認めている。例
えば、メタデータ要素の定義は次のように分けられる。

27
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

・ システムメタデータ要素の定義
・ コンテキストメタデータ要素の定義
これらはそれぞれ基本エンティティタイプメタデータ要素の定義のサブタイプである。サブタ
イプは通常、基本エンティティタイプに比較して余分のシステムメタデータを持っていることと、要件により設定される追加の規則により特徴づけられる。
MoReq2010®コアサービス内のいくつかのエンティティタイプは、エンティティ・サブタイプ（entity subtypes）の基本タイプとなるよう意図して設計されている。それらはメタデータ要素の定義に加え、次のように定義されている。
・ クラス：クラスサブタイプは MoReq2010®における 200．分類シリーズの異なるプラグイン
モジュールにより定義される・ コンポーネント：コンポーネントサブタイプは MoReq2010®における 300．コンポーネントシリーズの異なるプラグインモジュールにより定義される
201．階層型分類プラグインモジュールにおいて定義されている階層型分類はクラスエンティ
ティタイプのサブタイプの一例である。301．電子コンポーネントプラグインモジュールにおいて定義されている電子コンポーネントはコンポーネントエンティティタイプサブタイプの一例
である。
MoReq2010®への拡張モジュールは新しいエンティティタイプとサブタイプを追加することができる。
2.2.5 エンティティの構造
ほぼ全てのエンティティはそれに関連付けられる 3 セットの情報を持つ(図.2d)。
・メタデータ：エンティティを記述する情報であり、メタデータ要素定義に含まれている。また、システムメタデータ（MoReq2010®により定義される）、とコンテキスチュアルメタデー
タ（供給者、ユーザによって定義される）に分割されている。
・イベント履歴：エンティティに関連付けられるイベントの集合であり、エンティティに作用した様々な機能に関する情報を蓄積する。
・アクセス制御リスト：アクセス制御エントリーのリストであり、どのユーザとグループがそのエンティティの機能を実行できるのかを設定するものである。ここで機能の具体的なセッ
トは、ひとまとめにしてロール（役割）として定義される。

28
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

エンティティ

メタデータ

アクセス
制御リスト

イベント
履歴

図.2d それぞれのエンティティは関連するメタデータ、イベント履歴及びアクセス制御リストを有する。
ここではイベント履歴について述べるが、MoReq2010®においてメタデータがどのように管理されているかについては、7．モデルメタデータサービスを参照のこと。アクセス制御に関する情報は 4．モデルロールサービスを参照のこと。
イベントとアクセス制御のエントリーは、それらが属しているエンティティのイベント履歴及びアクセス制御リストを共用している。
MoReq2010®の各コアサービスは特定のエンティティタイプのエンティティのコンテナだけではなく、それ自体が、当該サービスにおけるすべてのエンティティを承継した独自のメタデータ、イベント履歴及びアクセス制御リストを持つエンティティとみなされる。エンティティの構成及びそれらのサービスとの関連が図. 2e にす。

エンティティ

エンティティ

メタデータ

イベント
履歴

アクセス

エンティティ

制御
リスト

サービス

エンティティ
メタデータ

イベント

アクセス

履歴

制御
リスト

図.2e サービスは、それ自体のメタデータ、イベント履歴及びアクセス制御リストのエンテ
ィティを持っているが、そのサービス自体がメタデータ、イベント履歴及びアクセス制御リストを持つ一つのエンティティと考えることが可能である。

29
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

2.2.6 エンティティの識別
あらゆるエンティティにおいて、おそらく最も重要なメタデータ要素は、そのシステム識別子
である。MoReq2010®はそれぞれの MCRS 中の各エンティティ及びサービスに対して、汎用一意識別子(UUID)を要求している。UUID を使用することは本仕様に準拠するための必須条件である。このことは、あらゆるエンティティが一つの MCRS からエクスポートされ、また別の MCRS にインポートされ、引き続き一意に識別されることを意味している。インポートした MCRS は、別の時間にエクスポートされたか、あるいは転送途中の MCRS を経由してきたオリジナルのエンティティの別のコピーと組み合わせることが可能である。また、すべてのエンティティは、それらが生成されたサービスの最初の発生時点まで遡ることが可能である。
2.2.7 機能の実行
ユーザは MCRS の下で機能を実行することにより、MCRS 中のエンティティを操作する。時には、システム設置時に MCRS が新しいシステム識別子を発行するように、機能を実行するのが MCRS 自体であることがある。
MoReq2010®は要件の仕様であり、MCRS 中のエンティティに対して実行できるそれぞれの機能は、この仕様の内のいくつかの機能要件にまで遡ることが出来る。
ユーザは、実行の権限を得ている場合に限り、エンティティに対する機能を実行することが許されている。
4．モデルロールサービスによれば、機能を実行する権限は、ロールとユーザ又はユーザが所属するグループとの関連で決められる。そして、サービス又はエンティティのアクセス制御リス
ト(ACL)の一部となるアクセス制御エントリーを用いて、ロールが個別のユーザ又はグループに割当られる。
2.2.2 モデルサービス及びプラグインモジュールで論じられたように、一部の MCRS ソリュー
ションはモデルロールサービスの特定の要件から逸脱してもよい。しかしながら、すべての MCRS
ソリューションは類似し、互換性のある機能を提供できなければならない。モデルロールサービ
スの意味は 4．モデルロールサービスにて更に論じる。
2.2.8 イベント履歴
MCRS のそれぞれのエンティティは、そのエンティティに発生した一連のイベントで構成されたイベント履歴を持っている。ユーザ又はシステムによって、ある機能が実行されると、それに参加しているエンティティではイベントが生成し、そのエンティティのイベント履歴に追加される。
したがって、そのイベント履歴の中のそれぞれのイベントは、MCRS で実行された単一の機能に対応している。
イベント履歴が過度に増大したり、瑣末なイベントで一杯になってしまうことを防ぐために、MoReq2010®では、その承認ユーザが選択した機能のイベント生成の遮断を認めている。

30
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

イベントのメタデータは常に MCRS によって設定され、ユーザによって変更されてはならない。
また、イベントはイベント履歴を持たない。
異なるイベントは、そのイベントを生成するのに実行された機能に依存して、異なるメタデー
タを持つことになる。つまり、一つのイベントが関連する複数のエンティティのイベント履歴に登場することになる。そのいくつかの例を下記に示す。
・ 承認ユーザが R6.5.3 の下で、集合の名称を変えた場合、ただ一つの参加エンティティ（当該集合）が存在することになる。そのイベントは（F14.5.17

集合―メタデータ修正）当該集合のイベント履歴にのみ現れることになる。
・ 承認ユーザが R6.5.10 の下で、集合の中で記録を作成した場合には、二つの参加エンティ
ティが存在し（集合と当該記録）、同じイベント(F14.5.121 記録―作成)が両方のイベン
ト履歴に現れることになる。
・ 承認ユーザが R6.5.13 の下で、記録を一つの集合から別の集合に移動した場合には、三つの参加エンティティが存在する（以前の親集合、新規の親集合、及び当該記録）。そのイベント（F14.5.3 集合―記録追加）は三つの参加エンティティを持ち、単一のイベントが三つのイベント履歴に同時に現れることになる。
・ R6.5.21 の下で、記録は常にそのコンポーネントに対して実行される機能の参加エンティ
ティである。これは発生したイベントが、そのエンティティが所属するコンポーネントと記録のイベント履歴の中に現れるようにするためである。
図.2f は一つのイベントがいかに複数のエンティティのイベント履歴に属することができるの
かを示す。

参加

参加

エンティティ

エンティティ

イベント
履歴

イベント
履歴

イベント

図.2f 同じイベントエンティティが複数のイベント履歴に現れることができる。
伝統的な監査証跡とは、MCRS 全体にわたった（タイムスタンプの順に）すべてのエンティティのイベント履歴の中の、すべてのイベントであるという見方に概念化できる。

31
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

2.2.9 タイムスタンプ
MoReq2010®は、それによって記録システムを世界レベルで相互運用できるようになるという特徴をもっている。その一つがタイムスタンプの使用である。
本仕様では MCRS が生成するすべてのイベントに対して、タイムスタンプをメタデータとして適用しなければならない。例えば、各エンティティは、それがいつ生成されたかを表示するタイムスタンプを有する。
タイムスタンプはタイムゾーン情報を含む完全で正確な日時データを含まなければならない。
これによりイベントを、それらが発生した順番に整列させることができる。もし MCRS が 1 秒間に多数のイベントを実行できるのであれば、タイムスタンプに基づいて整理した場合にイベントを順序よく整列させるためには、その MCRS はミリ秒より高い精度を提供できなければならない。
タイムスタンプは、エンティティを別のタイムゾーンにある別の MCRS に移動させることを可能にすることにより、相互運用性を補助している。
2.2.10

世界共通言語対応

MoReq2010®のもうひとつの世界共通性は Unicode への対応である。すべてのテキストメタデー
タ要素は Unicode フォーマットでなければならず、また言語識別子が付随されていなければならない。MCRS は、ただ一つの言語又は限られた少数の言語だけに対応いるだけでもよいが、相互運用性に対応するために言語識別子はすべてのテキストメタデータに取り込まれていなければならない。
2.2.11

エンティティのライフサイクル

エンティティタイプにかかわらず、MCRS 内のすべてのエンティティは類似のライフサイクルを持っている。エンティティのライフサイクルの概要が図.2g に示されている。
生成イベント
削除可能

廃棄イベント
初期使用

残留
時間

現用

図.2g MCRS のそれぞれのエンティティは類似したライフサイクルをたどる。

32
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

MCRS の中でそれぞれのエンティティは、その最初のイベントが常に作成イベントとなるように作成される。そのエンティティは、その後それが廃棄され、廃棄イベントを生成するまで現用状態にある。その廃棄の後、MCRS は残留エンティティを保持し、エンティティがかつて MCRS に 存在したことを表示する。
すべての MCRS ソリューションは残留エンティティを保持しなければならない。廃棄というのは、エンティティのすべての形跡を消してしまう削除とは異なるものである。MCRS からエンティ
ティを、あたかもそれが存在したことがないかのように削除することは、それらが使われる前に削除された場合を除いては、不可能である。すなわち、使用されたエンティティを削除することはできない。
いくつかのエンティティについて、最も重要なのは記録とそのコンポーネントであるが、同時にイベント、アクセス制御エントリー、システムメタデータ要素定義なども含めて、これらのエンティティは最初に使用したタイムスタンプを持っていないため、決して削除されることはない。
これらがひとたび生成されると、これらのエンティティタイプのエンティティは痕跡を残さずに、
MCRS から削除することは不可能と思われる。記録のライフサイクルは 6．記録サービスと 8．最終処分スケジューリングサービスにおいて詳細が説明されている。

2.4

機能要件

R2.4.1

下記の機能を実装しなければならない。

・ユーザサービス及びグループサービス
・ロールサービス
・分類サービス・記録サービス・メタデータサービス
・最終処分スケジュールサービス
・最終処分保留サービス
・探索サービス及び報告サービス
・出力サービス
それぞれのサービスは、各単体で実装されていても良いし、又は数個のサービスを束ねたものでも良い。

これらのサービスのそれぞれの機能要件は MoReq2010®コアサービスに提示されている。
MCRS はまた、MoReq2010®への拡張モジュールにおいて定義されている追加機能を実装してもよい。
MCRS は、記録サービスを除いては、どのサービスについても他の記録システムと共用してもよい。MoReq2010®は、記録システム間でのサービスの共用方法かについては規定していな
い。
MCRS は上記サービスにおいて記述されている機能を実装しなければならないが、それらを33
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

個別のサービスとして実装することは要求されていない。MCRS はそれぞれのサービスを別々に作成してもよいし、いくつかのサービスをまとめて、一つのサービスの束としてもよい。
MCRS 全体が一つのサービスを束ねたものでもよい。
R2.4.2設置に際しては、MCRS は下記のメタデータを各々のサービス（E14.2.14）又は、R2.4.1
におけるサービス束のために、

インストール時に以下のメタデータを初期化しなければならない。
・システム識別子(M14.4.100)
・実装サービス識別子(M14.4.42)
・実装モジュール識別子(M14.4.41)
・MCRS 認証識別子(M14.4.54)
・供給者情報(M14.4.99)
・デフォルト言語識別子(M14.4.12)
・タイトル(M14.4.104)
・記述(M14.4.16)
・所有者情報(M14.4.62)
また、個々のサービス又はサービスの束は下記の項目を持つ・サービス又は束により管理される各エンティティのエンティティタイプ
・サービス又は束により管理されるエンティティ・サービス又は束のイベント履歴
・アクセス制御リスト（又は同等のもの、4．モデルロールサービス参照）
そして、下記の項目を持つことがある。
・コンテキストメタデータ（又は同等のもの、7．モデルメタデータサービス参照）
それぞれのサービス又はサービス群は、自身のメタデータ、イベント履歴及びアクセス
制御リストを持っている。メタデータ要素の実装サービス識別子の それぞれの値はMoReq2010®仕様で出版されたサービスと一致しなければならない（識別子の値は 3．ユー
ザ及びグループサービス以降の各節の先頭にあるサービス情報ブロックに示されている）。
実装モジュール識別子はそれぞれ MoReq2010®仕様にて発表されたモジュールと一致しなければならない。また、それぞれの MCRS の認証識別子は、認定された試験センターの試
験に合格した MCRS に対して DLM フォーラム財団から発行された認証書と一致しなければならない。
供給者識別子は供給者、製品及び設置された製品のバージョンを示すべきである。供給者に関する連絡先情報や製品に関するサポートサイトのＵＲＬのような他の有用な情報を含めてもよい。
4．モデルロールサービスを実装する際に MCRS が用いるアプローチによっては、
MoReq2010®アクセス制御リストはシステム運用時には現れず、エクスポートの場合にのみ追加される可能性がある。

34
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

７．モデルメタデータサービスを実装する際に MCRS が用いるアプローチによっては、
コンテキストメタデータがサービスに追加される過程が異なる可能性もある。
R2.4.3MCRS は承認ユーザへそのサービスや R2.4.1 のサービスの閲覧（ブラウズ）

及び R2.4.2 のメタデータの検査（インスペクト）を許可しなければならない。
「閲覧（ブラウズ）」及び「検査（インスペクト）」という用語は 13. 用語集にて定義されている。
ユーザは各々のサービス又はサービスの束をブラウズすることができる。もし MCRS がすべての機能を一つの束にまとめた場合には、そのシステム全体としてただ一つのセットのメタデータがインスペクトすべきものとして存在することになる。

機能参照：F14.5.158
R2.4.4MCRS は承認ユーザがそれぞれのサービスや R2.4.1 に示したサービス群のメタデータの変更を許可しなければならない。また、それらメタデータには次のメタデータが含まれ
る。
・タイトル
・記述
・所有者情報・（もしあれば）コンテキストタデータ

所有者情報は組織又は MCRS を使用している組織に関する情報を提供される。これにはヘルプデスクや連絡先情報も含まれる可能性がある。タイトルと説明書には、MCRS の現場での名前と追加の記述情報を提供することが望ましい。
機能参照：F14.5.162
R2.4.5MCRS は承認ユーザが MoReq2010 適合性レポートを作成することを許可しなければならない。上記レポートには、アクティブなサービスのそれぞれか若しくは R2.4.1 のサービス群が列記され、サービスやサービス束に対する R2.4.2 のメタデータが列記されるものである。

この報告書はどのサービスが個別に実装されており、どこに数個のサービスが一緒に束ねられているのかを示すべきである。
この要件は承認ユーザに対して、設置された MCRS が特定の場所に特定の組織のために設置された時点で MoReq2010®に準拠していることを保証することを意図している。このため、それぞれのサービスに対して列記されている実装サービス識別子、実装モジュール識別子及び MCRS 適合識別子メタデータ要素の値はその特定の MCRS 施設の適合状態を正確に報告しなければならない。
報告書は MCRS がこれまでに MoReq2010®の適合性試験に合格したことがあることを示
す以上のことをしなければならない。すなわち報告書は、MCRS の設置及び運用条件の設

35
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

定が正しくなされ、また報告書が書かれた時点のサービスとモジュールに適合しているかどうかについても示さなければならない。MoReq2010®は個々の MCRS がその設置後にその内部の一貫性と構成をどのようにチェックするのが望ましいかは指定していないが、規制への適合性に関する環境で MCRS を運用する場合には重要な要件となる。
機能参照：F14.5.163
R2.4.6MCRS は、各々のサービス又は R2.4.1 のサービス群が MoReq2010 100.インタフェースシ
リーズのモジュールのひとつを実装するインタフェースを持つことを保証しなければならない。

MCRS 又は MCRS 内の異なるサービスは一つ以上の 100. インターフェースシリーズモ
ジュールを実装することができる。しかし、各サービス又はサービスの束は 100 シリー
ズの中の少なくとも一つのインターフェースモジュールに完全に準拠し、それが証明さ
れていなければならない。
R2.4.7MCRS が、システム自体又は承認ユーザから要求された機能の完了に失敗したとき、MCRS は少な
くとも以下に挙げるエラー情報を外部ログに書き出さなければならない。
・障害発生日時
・対象となった機能のシステム識別子
・当該機能を初期化した承認ユーザのシステム識別子
・ほかに参加しているエンティティのシステム識別子
・障害を説明する拡張エラー情報

この要件は、MCRS 自体の中では維持されないエラーログについて述べている。ログをシステムの外に置いておく目的は、MCRS が利用できない場合でもそれにアクセスすることができるようにするためである。
拡張エラー情報とは、一般的には次のように定義してもよい。即ち、診断情報でありその中には、エラーコード、エラー発生時のシステム状態の詳細、及び遭遇したソフト
ウェア例外処置が含まれる情報である。MoReq2010®は、どのような拡張エラー情報が提供されるべきであるのかについては指定していない。
機能は完全に実行されなくてはならないことに留意のこと。MoReq2010®は一部のみ実行を完了し、終了する機能は許容しない。、なぜならばそのような機能は MCRS を不確定の状態に置いてしまうからである。もしある時点で機能が不全に陥った場合には、
MCRS は当該機能により生じた内部状態の変化を、その機能が起動される前までロールバックしなければならない。MoReq2010®には、この実行方法については指定されていない。
R2.4.8ユーザが要求する機能の実行失敗の後、MCRS はユーザが外部ログにアクセスしなくても36
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

実行失敗した機能に関する拡張エラー情報を検索するための手段を R2.4.7 に則り提供しなくてはならない。

ユーザ要求機能の失敗に伴い MCRS が拡張エラー情報を提供する仕組みについては、
MoReq2010®は指定していない（この機能は 14.5 機能定義における機能定義には含まれていない）。
失敗した機能をユーザに通知する方法は、その MCRS が提供しているインターフェー
スのタイプに依存すると思われる。（R2.4.6 参照）。
R2.4.9MCRS は、承認されたユーザ又は各サービスや R2.4.1 のサービス群に関連するエンティ
ティタイプを閲覧し、それらのメタデータを検査することを許可しなければならない。

下記のエンティティタイプがそれぞれのサービスに関連づけられている。
・ユーザ及びグループサービスはユーザエンティティとグループを管理する
・ロールサービスはロール（役割）を管理する
・分類サービスはクラスを管理する
・記録サービスは集合、記録、及びコンポーネントを管理する
・メタデータサービスはメタデータ要素の定義及びテンプレートを管理する
・最終処分スケジューリングサービスは最終処分スケジュールを管理する
・最終処分保留サービスは最終処分保留を管理する
機能定義とイベントは、一つ以上のエンティティタイプを管理するすべてのサービスにおいて定められている。
これらのエンティティの詳細については、14.2 エンティティタイプを参照のこと。
機能参照：F14.5.83
R2.4.10 R2.4.9 の各エンティティタイプは、以下のメタデータを持たなければならない。
・システム識別子
・タイトル
・記述
また、各エンティティタイプは以下のものも持つ。
・当該エンティティタイプに対するシステムメタデータ要素定義
・当該エンティティタイプに対する機能定義
・イベント履歴・アクセス制御リスト（又はそれと同等のもの、４．モデルロールサービス参照）
MoReq2010®のすべてのエンティティタイプのシステム識別子はデフォルトのタイトル及び記述、14.2

エンティティタイプに記載されている。

MCRS は MoReq2010®によって供給されたシステム識別子を常に使わなければならず、エ37
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

ンティティタイプのための独自のシステム識別子を生成してはならない。ただしデフォ
ルトのタイトル及び記述を MCRS のローカルな値で置き換えてもよい。
R2.4.11 R2.4.10 における各エンティティタイプに対して、MCRS は、そのエンティティタイプに関連する機能定義エンティティを閲覧すること、及びそれらのメタデータを検査することを許可しなければならない。
各エンティティに関連する機能定義の総合リストについては、14.5

機能定義を参照のこと。
機能参照：F14.5.87
R2.4.12R2.4.11 における各機能定義は以下のメタデータを持たなければならない。
・システム識別子
・記述
・イベントフラグ生成
・廃棄状態維持フラグ
また、各機能定義は以下のそれぞれを持つ。
・イベントに追加されるシステムメタデータ要素
・イベント履歴・アクセス制御リスト（又はそれと同等のもの。４．モデルロールサービス参照）
MoReq2010®のすべての機能識別子は、デフォルトのタイトル、記述、及びそれらが適用されるエンティティタイプや、14.5

機能定義に記載されている。

®

MCRS は MoReq2010 によって供給されたシステム識別子を常に使わなければならない、
そして独自の機能定義のためのシステム識別子を生成してはならない。しかしながら、その機能のデフォルトのタイトル及び記述を MCRS のローカルな値で置き換えてもよい。
R2.4.13 R2.4.11 における各機能定義に対して、その機能が実行されたときに、MCRS によってイベントが生成されるかどうかを、承認ユーザが指定することを許可しなければならない。

その値はイベント生成フラグに格納される（R2.4.12 参照）。
この要件で記述された機能を実行し、イベント生成フラグの値を変更することは、
R2.4.14 で説明されているように、常にイベントが生成される結果にならなければならない。イベントは生成され、そして R2.4.15 に従いイベント履歴に追加される。
さらに、R2.4.21,R3.4.4,及び R7.5.7 で記述されている機能を実行することは、イベ
ント生成フラグの値にかかわらず、常にイベントが生成されることになる。
機能参照：F14.5.91
R2.4.14 R2.4.13 で記述された機能が実行された際、常にイベントは MCRS により生成されなけれ

38
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

ばならない。

この機能のためのイベント生成は抑制可能であってはならないため、この要件は
R2.4.13 にとっての例外である。
この要件の目的は、特定の機能がイベントとして捕捉されているか否かの設定に対するすべての変更の履歴及びその変更を行った承認ユーザについて MCRS が記録を保存していることを保証することである。
R2.4.15 MoReq2010 に記述された機能が MCRS におけるいずれかのエンティティに対して実行された場合で、且つ R2.4.13 に則った生成イベントフラグの影響下にあるとき、MCRS は、実行された機能を記述し、参加しているすべてのエンティティのイベント履歴に含める新
しいイベントを自動的に作成しなければならない。

MCRS はイベント履歴を MCRS 中のすべてのエンティティのメタデータの一部として維持しなければならない。
R2.4.16 実行されている機能により生成された、R2.4.15 における各イベントに対して、MCRS は
以下のメタデータを含めなければならない。
・システム識別子（M14.4.100）
・生成されたタイムスタンプ(M14.4.9)
・イベント発生タイムスタンプ(M14.4.27)
・イベント機能識別子(M14.4.26)
上記機能が MCRS によるものではなくユーザによって実行されたものである場合、そのイベントはさらに次のものを含む。イベントが MCRS 自身ではなく、ユーザによって実行される場合には、そのイベントはさらに下記を含む。
・ ユーザ実行識別子 (M14.4.83)
また、R2.4.18 の下で次を含む可能性がある。
・ イベントコメント (M14.4.25)
イベントが R6.5.16 の下で複製されている場合には、下記も含む。
・ 複製識別子 (M14.4.23)
R2.4.17 の下で、イベントが、エンティティのメタデータを変更する場合には、下記を含む。
・ メタデータ変更登録 (D14.3.3)
さらにイベントは、14.5 機能定義における各機能の記述にあるように、イベントが表す機能に依存して、下記に示す追加のシステムメタデータ要素の一つあるいは複数を持たなければならない。
・適用テンプレート識別子

39
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

・削除イベント機能定義識別子
・削除メタデータ機能定義識別子
・エクスポート開始タイムスタンプ
・エクスポート完了タイムスタンプ
・エクスポート識別子
・全体エクスポートフラグ
・付与ロール識別子
・履歴日時
・期限切れ最終処分活動コード
・期限切れ最終処分活動期限・期限切れ最終処分確認期限
・参加集合識別子
・参加クラス識別子
・参加コンポーネント識別子
・参加最終処分保留識別子
・参加最終処分スケジュール識別子
・参加複製識別子
・参加エンティティ識別子
・参加イベント識別子
・参加機能定義識別子
・参加グループ識別子
・参加メタデータ要素定義識別子
・参加新規親識別子
・参加従前親識別子
・参加記録識別子
・参加ロール識別子
・参加サービス識別子
・参加テンプレート識別子
・参加ユーザ識別子
・参加ユーザ又はグループ識別子
・廃止ロール識別子
・探索クエリー・総エンティティ

イベント機能識別子は、ユーザ実行識別子として参照される、ユーザにより実行された機能の機能定義に対するリファレンスでなくてはならない。イベント発生タイムスタ
ンプ(Event Occurred Timestamp)はいつ当該機能が実行されたかを反映しなければなら40
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

ない。これは MCRS により設定され、当該イベントが別の MCRS よりインポートされたものでない限り通常は生成タイムスタンプ(Created Timestamp)と同じである。
イベントに追加されるメタデータは実行された機能に依存し、それらは機能定義の一部としてリスト化され（R2.4.12 参照）、14.5 機能定義に記載されている。実行された機能次第で、そのイベントが追加のメタデータを必要とする場合がある。例えば、もしその機能がエンティティをエクスポートしようとするものであったならば、R11.4.8に則り、MCRS はイベントの中にエクスポート識別子及び全体エクスポートフラグを含んでいなければならない。
「参加…識別子」という形式の識別子で参照されるすべてのエンティティはそのイベントにおける参加エンティティである。機能は少なくとも一つの参加エンティティを持ち、数個の参加エンティティを持つものである。イベントはすべての参加エンティティのイベント履歴の中に現れなければならない。
R2.4.17 エンティティのメタデータが、機能実行の結果として、R2.4.15 における機能に対するイベント生成の結果として、修正される場合、MCRS は、修正された各メタデータ値に対するイベントにおいて、以下のメタデータを持つ、メタデータ変更エントリを含まなければならない。
・メタデータ要素定義識別子
・元値
・新値

メタデータ変更エントリーとは、D14.3.3 で定義されるデータ構造であり、そのエンティティに属するメタデータ要素の変更前後の状態を捕捉するものである。メタデータ
要素定義識別子(Metadata Element Definition Identifier)は修正されたメタデータ要
素へのリファレンスを持つ。前値(Previous Value)は機能が実行される前のメタデータ
要素の値を有する。新値（New Value）は機能が実行された後のメタデータ要素の値を有する。値が新たにエンティティに割り当てられた場合は、前値は存在しない、また前値が削除された場合には、新値は存在しない。
例えば、もしユーザがエンティティのタイトルを変えた場合、対応するイベントはタ
イトルメタデータ要素定義を参照するメタデータ変更エントリーを持つことになる(M14.4.104)。即ち、機能が実行される前の古い値とユーザから与えられた新しい値のことである。
機能により変更された各メタデータ要素はそのイベントに含まれているメタデータ
変更エントリーに帰結する。複数のメタデータ要素が単一の機能により同時に変更された場合、そのイベントは変更されたすべてのメタデータ要素に対するメタデータ変更エントリーを含むことになる。

41
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

R2.4.18 MCRS が、それ自体によるものではなく、ユーザからの要求によりエンティティのメタデータを変更する機能を実行する場合はいつでも、MCRS は、ユーザがなぜその機能が実行されたかを説明するコメントができなければならない。
そのコメントは R2.4.16 に則り、イベントコメントとして、イベントに含まれなければならない。

MCRS は、エンティティのブラウズやメタデータのインスペクトをする等、エンティテ
ィのメタデータの変更を伴わない場合には、ユーザがイベントコメントを入力できるよ
うな準備をすることを要求されていない。エンティティのメタデータの変更は、R2.4.17に則り、一つ以上のメタデータ変更エントリーを発生することになることに留意のこと。
コメントをすることはほとんどの場合任意である。しかしながら、一部の機能はユー
ザによるコメントを要求する。(例、R2.4.21, R2.4.26, R8.4.17, R8.4.18, R7.5.7 及び R11.4.10)
MCRS には、R2.4.16 に則り、それ自体が実行する機能に対するイベントコメントを行うことは求められていないが、そのような機能を実行している際に自動的にイベントコ
メントを生成し、それをイベントの中に含めるように MCRS を実装することは差し支えない。
R2.4.19 MCRS は、承認ユーザがエンティティのイベント履歴（ブラウズ）タイムスタンプの順に
閲覧し、それぞれのイベントを各イベントのメタデータを検査（インスペクト）することを可能にしなければならない。

「ブラウズ」と「インスペクト」という用語は 13.用語集にて定義されている。エンティティのイベント履歴は、最も一般的には、直近のイベントから古いイベントへと、
イベント発生タイムスタンプの降順にブラウズされる。MCRS は別の方法によるイベン
ト履歴のブラウズ機能を提供することも可能である。
機能参照：F14.5.14, F14.5.32, F14.5.45, F14.5.65, F14.5.79, F14.5.85, F14.5.89,
F14.5.103, F14.5.111, F14.5.133, F14.5.151, F14.5.160, F14.5.173, F14.5.189
R2.4.20 R2.4.11 における各機能定義に対し、その機能が実行された場合に、MCRS により生成されるイベントが属するエンティティが廃棄されるとき、そのイベントが維持されるべきかどうかについて指定することを、MCRS は承認ユーザに許可しなければならない。

その値は廃棄時保存フラグ(Retain On Destruction Flag)に格納される（R2.4.12 参照）。
廃棄時保存フラグが立っていない場合には、機能のイベントはエンティティが廃棄された時点でエンティティのイベント履歴から取り除かれる。それらは、残留エンティテ
ィのイベント履歴の一部とはならない。
下記を含むいくつかの理由により、残留エンティティから自動的にイベントを取り除いてもよいが、これに限定されるものではない。
・ 廃棄を保証するため―メタデータを含んでいるイベントを取り除くため、特に42第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

R2.4.17 に則ってメタデータ変更エントリーに格納されている情報の結果としてのイベントであり、これは部分的に、又は全面的にエンティティを復元することを可能にするため・ プライバシー―個人情報を蓄積する可能性のあるイベントを取り除くため・ 蓄積―残留エンティティの保管容量を削減するため

一旦エンティティが廃棄された後、残留エンティティを現用化することが可能であってはならないことに留意すること。自動的にイベントを取り除くことは、そのイベントの機能が当初実行された対象である参加エンティティを廃棄する際にのみ行われる（R2.4.21 の原理の説明を参照）。これは一つ以上の参加エンティティがあるイベントにのみ適用される。14.5 機能定義を参照のこと。
機能参照：F14.5.92
R2.4.21MCRS は、残留エンティティのイベント履歴からそのイベントを削除することを承認ユー
ザに許可しなければならない。ただし、これはユーザが削除の理由を示すことと、イベントが生成されていることを条件とする。

この要件は、例えば、裁判所から命令を受けた場合のように、個々のエンティティからメタデータ又はイベントを取り除くことが必要になった特別な状況を想定している。
日常の記録管理の過程の一部としてこの要件の実行が必要となるべきものではない。
この要件は、すでに破棄されている残留エンティティにのみ適用されるもので、破棄の際に発生したメタデータ及びイベントの自動削除に加えての要件である。
この機能のために、新しいイベントが必ず生成されなければならない。これは R2.4.13の要件に取って代わるものである。承認ユーザは、削除されたイベントの削除理由を示さなければならない、そしてその理由はイベントコメントとして新しいイベントの中に格納される。
新しいイベントはまた、削除済イベント機能定義識別子(Deleted Event Function
Definition Identifier)（M14.4.14 参照）を含まななければならない。これは、削除済
イベントの機能識別子を表し、また、どのタイプのイベントが、そのメタデータを全く保つことなしに削除されたのかを示すものである。
削除するイベントが一つ以上の参加エンティティを持つ場合、そのイベントはそれが当初実行された対象のエンティティから削除されなければはならない。これはイベント
削除通知(event notification of the deletion)に対する参加エンティティでもある。
例えば、記録が一つの集合から別の集合に移動した場合にイベントを削除するには、そのイベントは記録の新規親集合から削除されなければならない。なぜならば、これはその機能が実行され、そのイベントが生成された対象のエンティティであるからである（F14.4.3 集合―新規記録、参照）。
R7.5.7 も参照のこと。
機能定義：F14.5.7, F14.5.26, F14.5.39, F14.5.50, F14.5.59, F14.5.73,F14.5.97,

43
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

F14.5.122, F14.5.145, F14.5.167, F14.5.181
R2.4.22 承認ユーザがエンティティ集合を閲覧（ブラウズ）しているとき、ユーザが現用のエンティティと残留エンティティの両方を閲覧することを明確に選ばない限り、
MCRS は、デフォルトで、その集合を、現用のエンティティのみに制限しなければならない。「ブラウズ」という用語は 13.用語集にて定義されている。

デフォルトとして、すでに破棄されたエンティティは、ブラウズされることはない（R10.4.17 及び R11.4.2 参照）。
R2.4.23 MoReq2010 の仕様に付随するシステム識別子が提供されている場合、MCRS は、常に、そのシステム識別子を用いなければならない。

MoReq2010®は、従来下記のために生成されたシステム識別子を提供している。
・ サービス及びモジュール(参照 2.1 サービス情報)
・ エンティティタイプ（参照 R2.4.10 及び 14.2 エンティティタイプ）・ 機能定義（参照 R2.4.12 及び 14.5 機能定義）
・ システムメタデータ要素定義（参照 R7.5.1 及び 14.4 システムメタデータ要素

定義）
MoReq2010®で提供されるシステム識別子は、他の記録管理システムとの相互運用性を保証するために、必ず使われなければならない。
R2.4.24 MCRS は、汎用一意識別子(UUID)として、新しいエンティティにシステム識別子を生成しなければならない。また、その識別子を変更することを許可してはならない。

MoReq2010®には、システム識別子の生成のためにどのアルゴリズムを使用すべきかについては指定されていない。RFC4122 に列記されているアプローチは推奨される。
こ れ ら は 「 機 器 あ た り 最 大 毎 秒 1000 万 の 高 い 割 当 速 度 」 に 対 応 し て い る（RFC4122:2005,1）。
R2.4.25 MCRS は、生成の時点で自動的に生成タイムスタンプを設定しなければならない。また、全ての新しいエンティティに対する起算日時がもし存在するなら、それを設定しなければならない。

デフォルトでは、生成タイムスタンプと発生日時はいずれも、そのエンティティの生成日時を反映することになる。
機能参照：F14.5.5, F14.5.24, F14.5.38, F14.5.48, F14.5.57, F14.5.71, F14.5.95,
F14.5.121, F14.5.143, F14.5.165, F14.5.179
R2.4.26 発生日時が存在する場合、MCRS は、承認ユーザが変更の理由を提示する限りにおいて、

44第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

現用のエンティティの生成日時を生成タイムスタンプ以前の日時に変更することを可能にしなければならない。

デフォルトでは、発生日時は R2.4.25 に則り、生成タイムスタンプと同じ日時に設定される。承認ユーザはその後、現用エンティティに対するこの値をそれより早い日時に変更することができるが、遅い日時への変更はできない。ユーザが発生日時を早い日時に変更する場合には、常にその機能のために生成されたイベントの中にコメントをしなければならない。
発生日時は、R8.4.4 に則り、保持へのトリガーとなる可能性を持ち、また集合あるいは記録のためにそれを初期化することは、一つ以上の保持開始日の計算に影響を与えるということに留意のこと。
機能参照：F14.5.18, F14.5.36, F14.5.47, F14.5.54, F14.5.68, F14.5.82, F14.5.106,
F14.51361, F14.5.154, F14.5.176, F14.5.192
R2.4.27 MCRS は、W3C XML dateTimeStamp フォーマットと互換性があるタイムスタンプを生成しなければならず、常にタイムゾーン情報を含むタイムスタンプを生成しなければならない。

要 求 さ れ る フ ォ ー マ ッ ト は 、 W3C XML Schema Definition Language(XSD), 1.1
Part2:Datatypes に定義されている。この dateTimeStamp フォーマットは XML date/time
フォーマットの変形体であり、切り捨てられた、又は切り詰められたフォーマットを許容 し て い な い ISO 8601 の 部 分 集 合 で あ る 。 (ISO 8601:2004:Data elements andinterchange formats-informationexchange-Representation of data and times)。
タイムゾーン情報はイベント同士の相対的時間関係を決定し、異なるタイムゾーンにある記録システム間の相互運用性を保証するために、すべてのタイムスタンプに必須の項目である。
R2.4.28 MCRS は、全てのテキスチュアルメタデータ要素を、RFC5646 及び IANA 言語サブタグレ
ジストリに準拠した言語識別子で示される Unicode で蓄積しなければならない。

対応するメタデータ要素定義において、Is Textual Flag(テキスト型フラグ)が立っていれば、メタデータ要素はテキスト型と判断される（参照 R7.5.1）。
MoReq2010®は、テキスト型メタデータに使われている言語を、MCRS がどのような方法で識別するのかについては指定していない。その例を次に示す。
・ 単一言語のコンテキストでは、サービス又はサービスの束のデフォルト言語識別子から導いてもよい（参照 R2.4.2）
・ 運用手順の中で、又はメタデータの性質に基づいて指定してもよい
・ ユーザのクライエントオペレーティングシステム又はセッションの設定から導くことが出来る・ ユーザから追加情報として供給されてもよい

45
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

Unicode の使用により、すべての文字セットが表現されることが保証される。またこれは相互運用性のために必要である。最新の Unicode 標準のバージョンは 6.0 である。

46
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

3．ユーザ及びグループサービス

3.1

サービス情報サービス名称

ユーザ及びグループサービス

サービスバージョン

1.0

実装サービス

Cd532472-85b0-4c1c-82b4-5c8370b7d0e6

識別子（M14.4.42 参照）

3.2 主要概念
3.2.1 ユーザ及びグループ管理への MoReq2010®アプローチ
ユーザ及びグループの良好な管理は記録管理システムの運用を成功させる上で必須である。上記の事項は、すべての業務システムにおいて共通のニーズである。そのため、ユーザ及びグループを管理するための多数のシステムツールが入手可能である。多くの場合、上記の機能はコンピ
ュータのオペレーティングシステムに直接組み込まれている。また、ユーザ及びグループの管理、X.500 のような関連ディレクトリサービス及び OpenID のようなユーザ認証に関する実績のある標準が存在する。
このため、MoReq2010®は MCRS ソリューションがユーザ認証とユーザ及びグループ管理のために使用すべきプロトコルを規定していない。MoReq2010®におけるユーザ及びグループサービスは一式の要件であり、これにより外部の会社のディレクトリサービスを利用することもでき、MCRS に組み込まれた専用ディレクトリを利用することもできるというラッパー(Wrapper)のような役割を果たしている。ユーザとグループに関する基本的概念の他には、MoReq2010®には、ユーザとグ
ループの管理方法については規定されていない。
3.2.2 記録管理システムの要件
伝統的なディレクトリサービスは、記録管理の分野で必要とされるすべての機能を、ディレク
トリサービスのみで提供しているわけではない。ディレクトリサービス内に保持されているデー
タは、多くの場合過渡的性質のものである。過去のユーザをトレースする機能は、通常、ほぼ皆無である。ユーザ及びグループのシステム識別子は、外部ディレクトリサービスが複製されるかあるいは作り直される場合があり、普遍的でなく変更される可能性がある。重要なのは、記録を移動する際、独自のディレクトリサービスの中のデータは、別の記録管理システムによって容易に解読可能な共通フォーマットではない可能性がある点である。このような要素を含むと、どのユーザが特定の行動を実行し、且つ彼らはどのグループに属していたのかについて履歴的観点から判断することが困難になる可能性がある。
したがって MoReq2010®には、MCRS がユーザ及びグループに関する歴史的情報を含む追加の確固たるデータを保持することを要求されている。この要求には以下の項目が含まれる。MCRS 中のす
べてのユーザ及びグループを表すエンティティを生成すること、普遍的な MoReq2010®システム識47
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

別子を使用すること、エンティティのメタデータへの変更を追跡すること、及びそれらが現用ではなくなった際にはシステムから完全に削除するのではなくユーザ及びグループを廃棄して後に残留エンティティを残すこと等である。
MCRS がユーザ及びグループの管理のために外部ディレクトリを使用する場合には、この情報が捕捉され、定期的に更新される必要があり、外部システムから取り除かれた後にも保持されることを保証するために、そのディレクトリと同期をとるか又はそれと統合する必要がある。
MoReq2010®は、これがどのようにして実現されるかについては、指定していない。
3.2.3 ユーザ及びグループはどのように作用するのか
図.3a は MCRS におけるユーザとグループの間の多対多関係を示している。各ユーザは多くのグループに属してもよく、また多くのユーザは同じグループに属しても構わない。
ユーザ

グループ
属す

図.3a MCRS では、ユーザとグループは多対多の関係を持つ。

上記のフラットな構造は、ユーザとグループの間の関係について MoReq2010®によって要求されている情報の範囲を示す。図.3a に示されている数個のグループは、実際には別のグループの下
位グループであるかもしれないが、グループ間の関係を追う必要はない。
3.2.4 ユーザ及びグループの廃棄
ユーザ及びグループサービスでは、エンティティを廃棄し残留エンティティを残す、という
MoReq2010®仕様を通じて共通なアプローチを採用しなければならない。
これは、たとえエンティティがもはや機能していないとしても、記録としてそれらを保持するためである。ユーザ及びグループエンティティは、一旦それが使用されたら、MCRS から削除され48
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービスてはならず、その代わりにシステムによって管理される記録に対してコンテキストを提供するために保持されなければならない（2.2.10

エンティティのライフサイクルにおける検討を参照のこと）。
残留エンティティは、現用のエンティティと同様に機能するものではない。
すでに廃棄されたユーザエンティティの場合には、残留ユーザが MCRS にアクセスできるようにしてはならない。残留グループエンティティの場合は、現用中にそれらが認められてきていた
どのような役割(ロール)も適用されない。したがって、残留グループのメンバーであるアクティ
ブユーザはもはや、そのグループに割り当てられていた役割を引き継ぐことで生じる恩恵を受けることはできない（詳細については 3．モデルロールサービスを参照のこと。）

49
第１巻

コアサービス及びプラグインモジュール

第1 部 コアサービス
4．モデルロールサービス

4.1

サービス情報サービス名称

モデルロールサービス

サービスバージョン

1.0

実装サービス識別子

MoReq2010®モデルロールサービスを実装する MCRS

（M14.4.42 参照）

に対しては下記を使用：
2f6d05c6-51e6-4a32-a7fc-c0a6883eb85b
独自のパーミッションモデルを実装する MCRS に対しては下記を使用：
d945dcd9-dc2d-491d-965a-11ce936d044b

4.2

モデルロールサービスへの準拠

4.2.1 ロールとパーミッションに対する業界標準の欠如
MoReq2010®の本モジュールでは、モデルロールサービスの定義及び機能要件のほか、MCRS 内で機能を実行するための権限をユーザに付与する方法を記す。
MoReq2010®の発表時には、情報システムのエンティティにパーミッションモデルを適用するための業界全体の標準は存在していない。基本的なパーミッションモデルである、作成(Create)、
読み取り（Read）、更新（Update）、及び削除（Delete）のいわゆる CRUD は記録管理システムに直接適用するには単純すぎる。例えば、CRUD は削除と破棄を全く区別しておらず、記録管理シ
ステムに必要である残留エンティティの保持も許容されていなかった。
業界標準が存在しないため、供給者は当然のことながら、記録管理システムへのユーザのアクセスを制御するための独自のアプローチを開発してきた。このような独自技術方式は、しばしば非常に効果的であるが、ほとんどの場合、アプリケーションに特化されており、ある供給者のパーミッションモデルは簡単には別のシステムにマッピングできない可能性があるため、記録管理
システム間の相互運用には適していない。
4.2.2 モデルロールサービス
MoReq2010®モデルロールサービスは、記録管理システムの仕様書における具体的要件を扱う簡単な標準化モデルである。ここで扱うモデルロールサービスは中立的であり且つ現代の多くの情報システム全般に渡って定義されているアクセス制御リストやロール定義などのような共通概念等に確実に基づくよう留意されている。
それにもかかわらず、MoReq2010®のモデルロールサービスは、アクセス制御への一つの考えられるアプローチを示すだけであり、現存の記録管理システムにより採られているアプローチとはかなり異なっているかもしれない、と受けとめられている。そのため、既存の記録管理システム
は、アクセス制御方式の大がかりな再開発をしなければ、MoReq2010®に対する準拠性に関する試50
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

験を受けることができない状態である。このことは新しい記録管理システムがモデルロールサー
ビスを採用する機会がある一方で、市場の既存製品にとっては費用対効果が優れていることを証明できない可能性があるという二極化をもたらしている。
4.2.3 モデルロールサービスに対する試験と認証のアプローチ
前述の理由により、DLM フォーラム財団は記録管理システムの MoReq2010®モデルロールサービ
ス準拠に係る認証試験方法として、次の二通りのアプローチを認めている。
A. 記録管理システムに MoReq2010®モデルロールサービスを完全に実装し、このモジュールの要件に対し認証試験が実施されること
又は、
B. 記録管理システムに独自のパーミッションモデルが実装されている場合、アプリケ
ーションが下記の評価基準を満たすこと
・ 当該記録管理システムの独自パーミッションモデルが、柔軟性及び機能性の面で
MoReq2010®モデルロールサービスと同等であることを証明すること。
・ 当該記録管理システムにおいて、エクスポートの際に、その独自パーミッションをモ
デルロールサービスで用いられている XML フォーマットに変換できること。それによって、データが引き続き別の MCRS に移動される際に、ユーザおよびグループが、同等レベルのエンティティへのアクセスを維持し、機能を実行する際の同等の権限を保持することができ、相互運用性を保てること。
4.2.4 代替え要件（タイプ B）への対応方法
MCRS の独自パーミッションモデルが柔軟性と機能性において MoReq2010®モデルロールサービスと同等であることを示すためには、記録管理システムは下記の事項を立証しなければなららい。
・ あるエンティティへのアクセスの権限を認められない限り、ユーザは個人又はグループのメンバーとしてそのエンティティへアクセスできない、ということ。
・ ユーザのアクセス許可を任意に設定できる機能を含め、エンティティへのアクセスレベル
がユーザにより何段階にでも設定可能であること。これらにより次の項目が可能になる。
・ エンティティに、発見できるものとできないものがあること
・ 機能に、実行できるものと実行できないものがあること
・ エンティティへのアクセス及び機能の実行の権限を個別エンティティ又は記録集合のように、様々な部分においてエンティティ全体のレベルで設定することができること
・ MCRS 内のエンティティへのアクセスと機能実行権限が別々に設定できること。例えば、同51
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

じ分類サービスの内、あるクラスの機能を実行する権限を、同じユーザの他のクラスにおける権限とは異なったレベルで設定することが可能でなければならない。
・ 新しいエンティティが作成された場合、適切なセットのデフォルトパーミッションを与えられること。例えば、集合の中に捕捉された新しい記録は、その集合の中の他の記録と同レベルのパーミッションを与えられるべきである。
・ 特定のエンティティの所有者によって遮られることがないロール又はパーミッションが存在すること。これにより、このようなパーミッションを持ったユーザは MCRS 全体、又は一部を適切に運営することが可能となる。
エクスポートのためのメタデータを、記録管理システム独自のパーミッションから MoReq2010®
モデルロールサービスのメタデータフォーマットに変換する際には、次の項目を遵守しなければならない。
・ 当初の環境において承認されていたものより多くのエンティティへのアクセスは認められないこと
・ 当初の環境において実行できなかったエンティティへの機能については、継続して同じエンティティにおいて実行されないこと。
・ グループメンバーとして認められた権限を、個人に認められる複数事例に対する権限に変換してはならないこと
・ 記録管理システムは MoReq2010®モデルロールサービスの承継機能を可能な限り活用し、一式のアクセス制御エントリーを親エンティティに帰属させることができるのであれば、それがエクスポートするそれぞれの子エンティティのアクセス制御リストに、アクセス制御
エントリーを何度も追加するのは避けるべきである。
・ 供給者は、記録管理システムで使われる変換アルゴリズムについて解説し、どのようにロールとアクセス制御リストがモデルロールサービスをまねて作成されたのかという情報と実例をできるだけ詳細に提供しなければならない。
・ 供給者は、そのパーミッションマッピングスキーマを、製品の完全版試験報告書に記載されなければならない
供給者は更なる助言とガイダンスを DLM フォーラム財団を通して、MoReq 管理委員会に要求することができる。
本モジュールの以下の部分では、MoReq2010®モデルロールサービスの概念と要件について述べ
る。

52
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

4.3

主要概念

4.3.1 ロールの定義
エンティティ上の機能を実行する前に、MCRS は常に、その機能を要求するユーザが実行する権
限を持っているか否かを、事前に確認しなければならない。技能を実行する制限は、ロールを求められているユーザに与えられる。
機能を実行する権限を持って MCRS にアクセスしている適切に承認されたユーザ（R3.4.1 参照）
は、「承認ユーザ」(authorized user)と定義されている。
同じロールは MCRS 中のどのようなエンティティでも承認される可能性があり、又は数基の記録管理システムにわたって活用される可能性があるため、すべてのロール定義はロールサービス
により管理される。ロール定義とは、図.4a に示すように、機能定義のセットを表す。
ロール定義と機能定義は、多対多の関係にある。即ち、一つのロールは多数の機能定義がそれに関連づけられ、また同一の機能が複数のロールに関連付けられることがあり得る。
「ロール（役割）」という用語は、それが定義する一式の機能を、その組織内のスタッフの中の特定のメンバー、又は特定の職位によって求められる権限を集合的に記述するように、論理的に選ばれたものであり、例えば、「地方記録官」がある。
機能の整合性のある集合に基づき、このようにロールを構築するのは、記録管理システムにとって不可欠である。MoReq2010®仕様で定義されている機能は数が多く、それらを個別にユーザとグループに割り当てるのは実用的ではないであろう。

ロール１
ロール２

機能

機能

機能

機能

ロール３

機能

機能

機能

機能
ロール４

図.4a 機能はロールと関連付られている。
（すべての機能は少なくとも一つのロールに含まれなければならない。
）
4.3.2 ロールの付与
ロールは MCRS 内のサービスを含むエンティティに関するユーザ又はグループに対して付与さ53
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

れてもよい。ロールが付与されると、ユーザ又はグループを指名し、付与されるべきロールを列記しているアクセス制御エントリーが生成され、エンティティのアクセス制御リストに追加される。
エンティティに関してユーザにロールを付与することは、そのエンティティに適用されるロール定義にリスト化されている機能を、そのユーザが実行することを許可することである。
エンティティに関するグループにロールを付与することは、そのグループのメンバー各員に対してロールを付与する効果がある。
（3．ユーザ及びグループサービス参照）ロールが個別に付与
又は廃止されなければならないということなしに、グループに新たに参加するユーザは自動的にロールを承継する、一方グループを去るユーザは自動的に、そのロールへアクセスできなくなる。
個人よりむしろグループに対してロールを付与することは、推奨されるグッドプラクティスである。なぜならば、組織への加入・脱退、又は転職の際に MCRS 内のエンティティへのアクセス制御リストを更新する必要がなく、エンティティへのユーザのアクセスを管理しやすくなるからである。グループ管理は、個人ユーザに対して継続的にロールの付与と廃止を行うようなミクロ
管理よりも常に単純であり、誤りの少ない方法である。
図.4b はエンティティに対するアクセス制御リストに新しいアクセス制御エントリーを加える
ことにより、いかにしてユーザやグループがエンティティに関するロールを付与されるのかを示している。MCRS のすべてのエンティティ及びサービスはアクセス制御リストを持っている。

エンティティ

含む
アクセス
制御リスト

アクセス制御エントリー

ロール２

ロール４

ユーザ又はグループは付与される

図.4b アクセス制御リストは、ユーザ又はグループをロールに結び付けるアクセス制御エント
リーから構成されている。
4.3.3 ロールの承継
自身のアクセス制御リストの中のアクセス制御エントリーに加え、エンティティは、他のエン
ティティからユーザ及びグループに付与されたロールも承継することができる。MoReq2010®は、その具体的機能要件のなかで、このような承継がどこに適用されるのかを示している。仕様を一般的規則として、もしエンティティ間に親子関係が存在するならば、子のエンティティは親のアクセス制御リストを承継する。例えば、記録と同様に、子の集合は親の集合を承継する。4.3.5

54
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

多重承継に述べられているようにエンティティが複数のソースから承継するという状況も存在する。
ロールの継承は、単一のエンティティに対してロールを付与することが非実用的であるような大規模な記録管理システムを管理する上で大変重要な仕組みである。
また、アクセス制御エントリーの通常の形の承継は、もし要求されれば、いくつかのロールに分割することも可能である。MoReq2010®は、各アクセス制御リストの中に、親エンティティに割り当てられたロール・フラグは子エンティティによって承継されるかどうかを指定する承継付き
ロール・フラグ(Include Inherited Roles Flag) のための準備がされている。
もし、承継付きロールが、エンティティのアクセス制御リストの中でオフになっていると、管理者ロールのみが親エンティティから自動的に承継される。
4.3.4 管理的ロール
MoReq2010®には二つの異なるタイプのロールがある。
・管理者ロール
・非管理者ロール
ロールのタイプはロール定義の一部として指定されている。
管理者ロールは、サービス全体にわたって付与されるか、あるいは親エンティティに付与されるかに係らず、サービス又はエンティティから承継されるすべてのエンティティに常に適用される。こうして、管理者ロールは子エンティティの承継付きロールフラグに優越している。
これに対し、子のアクセス制御リストが承継付きロールを含むように設定されている場合には
非管理者ロールは子エンティティによってのみ承継される。
これを例示したのが図.4c である。この例では、ロール２は管理者ロールであるが、ロール４
は非管理者ロールと設定されている。子１エンティティは承継付きロールを含むように設定されており、それにしたがってロール２とロール４が承継されている。しかしながら、子２エンティ
ティは承継ロールを含んでいないため、管理者ロール２のみが承継されている。

55
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

ロール２
管理者ロールか＝YES

親
エンティティ

ロール４
管理者ロールか＝ NO子１はすべてのロールを承継する

子２は管理者ロールのみを承継する

ロール２

ロール２

ロール４

子２

子１
アクセス
制御
リスト

アクセス
制御
リスト

承継付きロールか＝YES

承継付きロールか＝NO

図.4c 管理者ロールは、承継付きロールフラグの運用に優先し、常に親エンティティから承継する。
4.3.5 多重承継
前述のように、MoReq2010®仕様において、エンティティが複数のエンティティからロールを承継してもよいとされる部分がある。
例えば、記録管理システムで維持されている集合と記録は、アクセス制御設定を、それらの親集合と分類の両方から承継するであろう。これは図.4d に示されている。これが起きた場合には、
エンティティは、その親と両方からロールを承継するであろう。もちろん、もし全ロール承継フラグ(Inherit All Roles Flag)がオフの場合は、子エンティティは管理者ロールのみをこれらのエンティティから承継する。この仕組みによって、異なる組織が分類及び集合のレベルにおいて、記録へのアクセスを設定することが可能となる。

56
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

サービス
または集合
クラス

親
アクセス
制御
リスト

アクセス
制御
リスト

集合
又は記録

子
アクセス
制御
リスト

図．4d アクセス制御リストが複数のソースから承継されることがある。
4.3.6 既設定ロール
組織の便宜のため、また設置後の迅速な使用のために、供給者があらかじめ設定したデフォル
トのロールを実装することは、記録管理システムではよくあることである。こういった場合、これらの既設定のロールの内のある部分について、承認ユーザは、変更、さらには（未使用の場合は）削除又は廃棄することができる。その一方で、既設定ロールの他の部分は供給者が固定することができ、特定の MCRS ソリューション内では変更不可能としてもよい。MoReq2010®は、供給者がその製品の中に固定ロールを含む一つ以上の既設定ロールを設けることを、ユーザが自身の専用ロール定義を組織の要件及び記録管理ポリシーに沿って生成、修正、及び廃棄する機能を MCRSに備えることやそれらが試験確認報告書の一部として記述されていることを条件に認めている。
既設定ロールには MCRS ソリューション内で供給者によって固定されているものがあってもよ
いが、エンティティとその関連ロールが別の MCRS に移動する場合には、そのようなロールは必
ずしも固定され続ける必要はないということに留意すること。

57
第１巻

コアサービス及びプラグインモジュール

第1 部 コアサービス
5．分類サービス

5.1

サービス情報サービス名称

分類サービス

サービスバージョン

1.0

実装サービス

10fea10e-9c2f-4760-9095-f4f9295f4b19

識別子（M14.4.42 参照）

5.2

主要概念

5.2.1 記録の分類
MCRS の中のすべての記録は分類されなければならない。MoReq2010®において、これはあらゆる
記録は作成された時点から常にクラスエンティティと関連づけられていなければはならない、ということを意味している。クラスは業務機能、活動及び処理を表し、クラスを記録に関連付ける
ことは、記録とそれを生み出した業務プロセスを関係づけ続ける明確な業務コンテキストを提供する。
MoReq2010®では、記録は集合の中にも位置付けられる。クラスとは異なり、集合は多数の様々な目的のために作成されてもよい。例えば、集合は伝統的な「ファイル」又は記録のフォルダーを指す。あるいは、特定のウェブサイトで閲覧することができるようにした記録の「オンライン
ライブラリ」を指すかもしれない。記録は取扱の便利さから、集合毎に整理し、それらを単一のエンティティとして管理したり、それらが同じアクセス制御のセットを共用することができたりする。集合については 6．記録サービスを参照のこと。
集合の中の記録が同じ業務コンテキストを共有する場合には、その集合のクラスを親集合から直接継承してもよい。MoReq2010®では、記録のように集合が分類されることが要求されている。
この継承による分類は、各記録を個別に分類することを避けられるため、大量の記録を管理する
場合に推奨される。しかしながら、このことは特定の集合内に存在する記録が均質である場合に限られる。
さらに、MoReq2010®では、異なる業務分類に属する記録を含んでいる異種集合も許容されている。これらの記録は、運用上の理由により、特定の人物、場所、プロジェクト、イベント、事件、又は事故に関係している等により一緒にまとめてもよい。（6.2.1

意図的集合参照）。

前に述べたオンラインライブラリにおいて、ライブラリ内の記録は、すべてが同じ業務プロセスから発生したものではないかもしれない。この場合は、集められた各々の記録は個別に分類され、それらの親集合から継承したデフォルトクラスを優先することになる。
記録を分類することは、業務コンテキストを記録に与える。それは、転じてデフォルトの最終処分スケジュールをもたらす。最終処分スケジュールは記録の保存と最終処分を管理する。このスケジュールは、当初は常に記録のクラスに由来する。最終処分スケジュールに関するより詳細
は 8．最終処分スケジュールサービスを参照のこと。

58
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

5.2.2 分類の継承
すべてのルートレベルの集合（6.2.2

ルート集合参照）は分類されなければならない。デフォルトでは、それぞれの子集合と記録は、その親集合のクラスを継承する。承継された分類は、集合や記録に対してクラスを直接割り当てることにより、覆すことが可能となる。

クラス

クラス

クラス

クラス

クラス

クラス

図．5a 説明上の目的で、このモジュールの図に現れる各クラスは、異なる形状と色で表示される。図．1i のような別のモジュールを伴っている図では、クラスのような同じタイプのエン
ティティはすべて同一の形状と色を割り当てられる。
図.5b は集合を分類するために、分類サービスから、クラスがどのように使われるのかを表した。同じクラスは、子集合と記録の両方を含めた、その集合のすべての子孫に自動的に継承される。
分類サービス

クラス
クラス

分類する
クラス
クラス

クラス

集合
クラス

継承する
集合

記録

記録

集合

記録

記録

記録

図.5b デフォルトにより、すべての子集合と記録はそれらの親集合からクラスを継承する。
図.5c はクラス継承が子集合を分類することによって覆される仕組みを示した。この例では、親集合から継承したクラスは、子集合に直接割り当てられたクラスにによって覆されている。そして、新たなクラスが、子集合の子孫たちによって継承される。

59
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

分類サービス

クラス
クラス
クラス
クラス
クラス

集合
クラス

覆される
集合

集合

記録

記録

記録

記録

記録

図.5c 子集合を分類することは、その親から継承したデフォルトクラスを覆すことである。
。
図.5d は記録の親集合からの継承と、個別の記録を直接分類することによるオーバーライドを表している。
分類サービス

クラス

クラス
クラス

クラス

クラス

集合
クラス

集合

個別分類

記録

記録

集合

記録

記録

図.5d 記録を個別に分類することにより、親集合から継承したデフォルトクラスが覆される。
5.2.3 再分類
記録管理システム内の記録を再分類する必要が随時生じる。このことは、業務分類が時とともに変化し、更新されるにつれ、どの記録管理システムでも起こり得ることである。二つの業務単位が合併する場合のように、異なるソースからの記録を持ち込んで一緒にするような場合には、なおさらである。
MoReq2010®は、それぞれの MCRS が承認ユーザに一つの指定クラスを別のクラスに置き換えることを許可することにより、MCRS 内で適用される箇所すべてに対して、少なくとも最小限の対応をするように要求している。

60
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

5.2.4 分類サービスと分類体系
多くの組織は、自らの業務全体に適用可能な分類体系を、独自に作るか又は業界共通のものを使用している。MoReq2010®のサービスベースアーキテクチャは、企業内全体にわたっての様々な記録管理システムが共通の集中型分類サービスを共用することを可能にする。単一の MCRS も複数の分類サービスを有することができる。
集中型であろうと MCRS に組み込まれていようと、それぞれの分類サービスは特定の分類体系に対応しなければならない。分類体系は、分類サービスにおいてクラスを整理するための異なる方法を表している。
例えば、最も単純でまた一般的な分類体系は、階層型分類体系である、ここでは図. 5e に示すように、クラスは簡単なツリー構造に整理される。
階層型分類
サービス

クラス

クラス

クラス

クラス

クラス

集合

クラス

集合

記録

記録

集合

記録

記録

記録

図.5e 階層型分類体系を採用した分類サービスの例
図.5e は階層型分類体系を用いた分類サービスの例である。このタイプの分類体系では、階層構造の底部のみが、集合と記録を分類するのに用いられる。
他のタイプの業務分類、例えば、ISO 2788 準拠の単一言語シソーラス(ISO 2788:DocumentationGuideline for the establishment and development of monolingual thesauri) から派生した
複合型階層構造により表現される分類体系である Keyword AAA のようなものも可能である。
Keyword AAA は関連語のような追加のクラス間結合を利用している。
様々な市場分野における様々な業界及び組織が、様々な分類体系を採用することを容易にする
ために、MoReq2010®は供給者が特定の分類体系と彼らの MCRS ソリューションが実装している体系との間での選択を可能にしている。それぞれのタイプの分類体系の要件は、異なる分類モジュールにおいて定義されている。
したがって、それぞれの MCRS は次節の要件とともに、MoReq2010® 200．
分類シリーズのプラグインモジュールの少なくとも一つを実装しなければならない。
内部の一貫性のために、各分類サービスは一種類のみの分類体系の構造を実装しなければなら61
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

ないが、MoReq2010®は、一つの MCRS がそれぞれ異なった分類体系を持つ複数の分類サービスを持つことを妨げるものではない。

62
第１巻

コアサービス及びプラグインモジュール

第6．記録サービス
1 部 コアサービス

6.1

サービス情報サービス名称

記録サービス

サービスバージョン

1.0

実装サービスced3d0df-3f9f-4807-9e96-b5b790ada4a

識別子(M14.4.42 参照)

6.2

主要概念

6.2.1 意図的集合
記録サービスは MCRS 中の記録を、様々なレベルの集合の下で管理する。それぞれの集合は、記録のグループ又は集合のグルーﾌﾟを表している。記録は、下記の理由のいくつか又は全てにより、集合の中に置かれる。
・ 同じ業務処理あるいはプロセスに関係している・ 同じ業務分類を持っている・ 同じテーマや話題を共有している・ 同じ人物、場所、プロジェクト、事件、顧客、イベント、又は事故に関係している・ 共通のメタデータを共有している・ 同じ情報源あるいはフォーマットを持っている・ 同じ業務単位によって管理されている・ 同じ読者を対象にしている
・ 同じレベルのセキュリティアクセス制御に服している
・ 同じ保持及び最終処分条件の下にある集合は、しばしば、意図的に記録を他の記録とともに意味のあるコンテキストに置くことにより、そこに置かれた記録の意味論的解釈を促進する。従って、集合全体は、その対象に関する鮮明な記述を集合的に行う可能性がある。
上記の理由により、集合は、より上位の集合に集約されてもよい。記録を格納している集合は、類似の集合のグループを代表する親集合に属してもよい。
いかなる MCRS においても、そこで可能な最高位の集合は記録サービスそのものである、すな
わちそれは、全体として捉えた場合、その記録サービスが格納しているすべての記録の単一の集合を表している。
ISO 23081 は、一つの組織内のすべての記録管理システムによって抽象的に更にそれを越えた上位の集合として抽象的に見られるような、単一の記録管理システム又はアーカイブを越えた集合の階層モデルを想定している。
集合に対する実用的な側面もある。集合は、運用上の考慮、又は管理されている記録の技術的63
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

制約により決定されてもよい。このことは記録が別の業務システムの中で管理されている場合には特にそうである。このような集合の性質は業務システムの性質によって決定するとも考えられる。例えば、業務システムが協力的チームワークのための作業スペースを提供する場合、これらの作業スペースは必然的に記録管理システムによって管理されるべき集合の基盤を形成することになる。同様に、もし記録管理システムが個人利用を目的としてモバイル機器上で遂行されるように設計されていたら、複数の政府機関の間で共用されることを意図したクラウドベース記録
管理システムよりもフラットな構造をもってもよい。システムの特化、ストレージの設置場所、容量及び大きさ、安全なアクセス制限等への考慮が、集合の実装、サイジング、及び管理方法を形成する上での役割の一部を担っている可能性がある。
6.2.2 ルート集合
記録サービスにおいて、他の集合の子ではない集合はルート集合と呼ばれる。一つの記録サー
ビスの中のルート集合の数には制限がない。このことは MCRS が複数の組織による利用を受入れることを可能にする、即ち、異なる組織又は組織内の異なる部門が、同じ記録サービス中の他の集合及び記録を参照することなしに、異なる集合と記録を管理するということである。
図.6a は複数集合がルートレベルに存在しうる記録サービス内部の集合及び記録の典型的構成
を示す。

ルート集合

集合

ルート集合

集合
記録

記録

記録

記録

記録

記録

記録

図.6a 単一集合を持たない記録サービスにおける異なるレベルの集合を示している。
6.2.3 集合に対する制約
MCRS において、記録及び集合は、同じレベルの集合にお互いに一緒に置くことはできない。これは図.6b に示されている。この構成は、一貫性のある管理方針を各々のレベルの集合に対して一様に適用し、記録がどこに作成されるべきかについてのあいまいさを排除することを可能にするような、各々のレベルにおける集合の完全性と独立した存在性を保つ。
この制約の必然の帰結は、記録は集合の外部には作成できないということである。このことも図.6b に示されている。記録サービスの内部に直接記録を作成することは、それらの記録を既存のルート集合と同じレベルの集合に置くことになるか、さもなければ MCRS の中に将来のルート

64
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

集合を作成することを阻止することになる。
記録サービス

ルート集合

記録は集合の外側に置くことはできない

集合

記録は集合と同じレベルには置くことはできない

記録

記録

記録

記録
記録
記録は最低レベルの集合に置かれなければならない

図.6b 記録は集合と同じレベルに保管することはできない。
6.2.4 集合と継承集合の主な利点の一つは、継承をサポートすることである。子エンティティが親集合から継承できる特性は下記の通りである。
1. 分類

集合又は記録は、そのクラスを親集合から継承することができる。

2. アクセス制御

集合又は記録は、その親のアクセス制御リストを継承することができる。

（4．モデルロールサービスを参照のこと。
）
3. メタデータ ユーザは、それらの親集合に割り当てられたメタデータに基づいて、集合と記録を検索することができる。
6.2.5 集合と分類
分類を様々なレベルの集合に適用することができる。デフォルトでは、各々の子集合又は記録は、そのクラスを親集合から継承することができる。しかしながら、それぞれ異なる分類を各々のレベルの集合や、直接各記録に対し適用することにより、5.2.2

分類の継承で述べられているように、このデフォルトを覆してもよい。
集合と分類は様々な方法で相互に作用し合うとも考えられる。これがどのように起きる可能性があるのか的確に理解するために、6.3集合と分類の例において様々なシナリオが解説されている。これらのシナリオは必ずしも記録管理の分野で推奨されているベストプラクティスを反映している訳ではないことに留意のこと。しかしながら、それらは実際の社会で一般的に遭遇する状況を想定している。

65
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

6.2.6 無秩序な拡大（スプロール）の抑制
MoReq2010®の集合機能は強力であり、記録サービス内において多様なレベルでの集合を可能にしている。特定の状況では、これは極めて有用である一方で、この機能が過剰に使用されないよ
うにすることが重要である。特に、多数のレベルの集合からなる深層構造にならないようにする
ことが望ましい。
一般的ルールとして、１レベル又は時には２レベルのみのフラットな構造であると管理しやすく好ましい。また、集合機能が疑似分類階層(pseudo-classification hierarchies)を構築してはならない。
このため、MoReq2010®は、どのルート集合に対しても、その下に追加してもよい集合のレベルの数の最大値をユーザが設定できるようにしている。この値を設定することにより、ユーザは、集合を何層設定できるかについて、制限を設けることができる。
MoReq2010®への拡張案では、レベル数が固定された集合機能をとりいれた特化型の集合が導入されるであろう。
6.2.7 原順序
記録を集合化することの重要な利点は、時間とともに記録を追加するという過程が、記録を線
形な時系列に並べることになり、ブラウズの助けになることである。自然な時系列化は、図.6cに示すように履歴のタイムラインを提供し、集合に対する重要な叙述的側面を付加する。
集合

最初の記録

最後の記録
記録

記録

記録

記録

時間

図.6c 発生日時に沿って並べることにより、集合の中の記録は、論理的な履歴の系列としてブラウズすることができる。
デフォルトでは、発生日時は記録が MCRS の中で作成された時点に適用されたタイムスタンプを反映する。しかしながら、記録が順不同に作成されたり、記録が即座に MCRS に加えられなかったりした場合、本仕様は順序の変更をサポートしており、発生日時をユーザの指示によって、より早い時期に修正することを可能にしている。

66
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

集合の中での時間を基準にした順序付けは、作業フローのような動的プロセスにより発生する
記録を捕捉する場合に、特に有用である。作業フローが進むにつれ、それぞれの主要な段階又は遷移によって、現在の作業状況のスナップショットが生み出され、それを集合の中に時系列的に取り込むことが可能である。これにより、集合において、プロセスの始めから終わりまでがどのように進められたかを履歴的に明らかにすることができる。
MoReq2010®において、同レベルの集合が記録と子集合の両方を含むことを許可していないもう一つの理由は、一つの集合の中で原順序を保存するためである（6.2.3

集合への制約を参照のこと）。複数の記録を様々なレベルの集合に置くことは、その集合における記録の自然な線形系
列を破ることになり、結果としてその叙述を阻害する。この複雑な問題に関しては、図.6d に示した。
集合最初の記録？
記録

記録

記録

最後の記録？

集合

記録

記録

記録

図. 6d 集合は、もしそれが記録と集合を異なるレベルに含んでいる場合には、その線形的叙述性を保つことができない。
6.2.8 記録の原子性と複製
MoReq2010®の各エンティティは、自己充足的又は原子的とみなされる。この特性が相互運用性を支え、異なる記録管理システム間のエンティティの移動を可能にしている。このことは、とりわけ記録について言える。それぞれの記録は、メタデータ、イベント履歴、コンポーネント、及びアクセス制御リスト(又はそれと同等のもの)から構成されている。特に、記録のイベント履歴
によって、その記録が最初に MCRS の中に作成された時以来に起きた主要なイベントを確認する
ことができる。これにより、記録の真正性を確立する上で重要な要素である記録の出所を提供する。
MCRS において、もしある記録が別の記録からコピーされたが、最初の記録のイベント履歴が複製されなかったとすると、２番目の記録は完全な記録を表すことはできない。これらが互いに全く同じコピーであったとしても、図.6e に示されるように、２番目の記録のイベント履歴にはそのコピーが作成される時点までのイベント履歴は失われた状態となるだろう。

67
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

作成イベント

コピーイベント

他のイベント

その後のイベント
オリジナル

コピーはこの履歴を失う

複製

時間異なるイベント

図.6e 記録のコピーが作成された場合、それはイベント履歴の一部を失っているため、オリジ
ナルと等価ではない。
このため、MoReq2010®は記録をコピー(copying)ではなく、その代わり、複製(duplication)過程を要求している。複製とは、元と同じメタデータにより新しい記録を作成するだけではなく、元の記録のイベント履歴のコピーも付け加えることである。複製の過程の後は、図.6f に示すよ
うに、どちらの記録も、片方がオリジナルであり、もう片方がコピーであるとみなすことはできず、またみなすべきではない。
作成イベント

複製イベント
その後のイベント

他のイベント
複製

共有履歴
時間

複製
異なるイベント

図.6f 記録が複製された場合、その結果は複製時点までの共有履歴を持った二つのオリジナル記録を持つことになる。
MCRS において記録を複製する主な目的は、同じ記録が複数の集合に存在できるようにするためである。この場合、それぞれの異なった場所での記録の出現は複製によるものでなければならない。このとき、それぞれの記録は、自己の分類、最終処分スケジュール、親集合、コンポーネン
トエンティティ、アクセス制御、イベント履歴、タイトル、記述、及び他のメタデータを備えた、
それ自身固有のものである。
記録が複製される場合、記録のコンテンツを複製するか、又は複製するたびに、同じコンテンツを使用するポインターシステムを維持するのかを選択してもよい。もし MCRS が二つの異なる記録のコンテンツの実体（インスタンス）を作成するのであれば、そのコンテンツは「物理的離68第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

散」と称される。もし MCRS がポインターを使うのであれば、そのコンテンツは「論理的離散」と称される（離散の原理については、6.2.10

コンポーネントコンテンツ管理の原理を参照のこと）。
いずれの場合でも、コンテンツが物理的離散か論理的離散かにかかわらず、一つの記録が廃棄された場合、残りの複製とそのコンテンツは全く影響を受けてはならない。もし MCRS がポイン
ターを使うことによりコンテンツを論理的にのみ分離しているのであれば、廃棄された記録とコンテンツを結びつけているポインターは削除されるべきであるが、コンテンツ自体は複製された
記録の最後のものが廃棄されるまで、削除するべきではない。
6.2.9 記録コンポーネント
MoReq2010®において「記録」と呼ばれているのは、実際は「エンティティ」である（すなわち、
MCRS により保存されるメタデータのセットであって、記録コンテンツを記述するものである）。
したがって「記録」という用語は抽象概念である。記録の実際のコンテンツ又はデータは MCRS
内の記録エンティティとは別であり、別のデータベース又は場所に格納されてもよい。
MoReq2010®においては、各々の記録のコンテンツは多様な形式をとることが可能で、異なるタ
イプの記録コンテンツを記述するプラグインモジュールを提供している。これらの形式は、データファイルのようなデジタルリソースを指す電子的カテゴリ、及び現実の世界の物を指す物理カ
テゴリに分類され、通常 2 つのカテゴリの 1 つに当てはまる。
下記の例は、MCRS によって管理される記録を構成するかもしれない様々なタイプのコンテンツを示す。ただしこれに限定されるわけではない。
電子的カテゴリの例


ワードプロセッシングアプリケーションによって作成された電子的文書のようなデジタ
ルデータファイル



ウェブブラウザの中でウェブページを描写するのに必要となる数種類のデータファイルのような、集合的な数個のデジタルデータファイル（例HTML、CSS、JavaScript、

JPEG/GIF/PNG 等）

データベーステーブルの列、又は、より現実的にはデータベース中の複数の異なる表の間で相互に関連する列の集合

業務システム内のエンティティへの参照（例、CRM システム内の顧客エンティティへのリンク）

物理的カテゴリの例


紙媒体の文書

物理的物体（例 CD、DVD、マイクロフィルム等）



生物医学的試料69
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

MoReq2010®では、一つの記録はそのコンテンツを構成するのに複数の分離したリソースを持つことができる。これらの異なるリソースは、別々の場所に保管されてもよい。記録とそのコンテンツの関連性は、コンポーネントエンティティにより提供される。各記録は複数のコンポーネン
トを持つことができる。各コンポーネントはコンテンツの一つの項目に対する参照である。これは図.6g に示されている。
記録

記録

記録

コンポーネントエンティティ
コンポーネントコンテンツ

図.6g それぞれの記録は一つかそれ以上のコンポーネントを持っており、そのそれぞれは特定のタイプのコンテンツの一つの項目に参照される。
図.6g において、各記録はそのコンポーネントを含めたものとして示されていることに留意のこと。コンポーネントエンティティはそれらが属している記録において不可欠な部分である。例
えば、これらは、別のアクセス制御を持ちながら、記録とそのメタデータと同じレベルのアクセスを持っている。
MCRS が対応できる記録コンポーネントのタイプは、MoReq2010® 300．コンポーネントシリーズ
によるプラグインモジュールの実装種類に種類によって決まる。これらの各モジュールは、「電子的コンポーネント」のようにそれぞれ異なるタイプのコンポーネントコンテンツを参照している。
MCRS は複数のタイプのコンポーネントに対応することができる。この場合、例えば、異なるコ
ンポーネントタイプの記録は同じ集合において自由に混ぜ合わせることができる。
6.2.10コンポーネントコンテンツ管理の原理

すべてのリソースがコンポーネントのコンテンツとして取り扱われることが適切というわけではない。MoReq2010®はコンポーネントコンテンツとその他の情報を区別する具体的特徴を定めている。これらの特徴は、コンテンツが電子的であろうと物理的であろうと、それがどの様な特別の形式を持とうと、適用される。
この仕様に準拠しているとされるためには、記録管理システムで管理されているコンポーネン
トによって参照されるコンテンツは次のような特性を有していなければならない。

70
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

・ 離散性
・ 完全性
・ 不変性
・ 廃棄可能性
分離の原理では、各コンポーネントのコンテンツは他のコンポーネントのコンテンツとは分離しており、かつ区別が可能でなければならないとされている。
コンポーネントが共有リソースとして作成された場合には、記録管理システムはそのリソース
がそのコンポーネントのみに属する分離コンテンツとして管理されていることを保証しなければならない。MoReq2010®はこの実施方法について規定していないが、例えば、リソースのコピーを取り、それを保存するというように、コンテンツを物理的に分離すると解釈してもよく、ポインターを使うことにより、コンテンツを論理的に分離すると考えてもよい。分離の原理は図.6h
に示した。

記録

コンポーネント記録

非準拠
記録は離散的ではない
コンテンツ

記録

コンポーネント

コンテンツ

記録

コンポーネント

物理的又は論理的に分離
していなければならない

準拠

コンテンツ

図.6h 分離の原理とは各コンポーネントがただ一つの記録に属し、そのコンテンツは分離され、区別されていなければならないということである。
MCRS ソリューションにとって、分離の原理を守りながら、6.2.8

記録の原子性と複製で述べられている記録複製プロセスの管理を可能とすることは重要である。記録が複製される時、記録
エンティティとそのメタデータ及びアクセス制御、イベント履歴の中のイベント、コンポーネン
ト、そして最も重要なことに、そのコンポーネントのコンテンツ等がそれぞれ複製されなければならない（先に説明したように、物理的又は論理的に）。
完全性の原理とは、記録のコンポーネントにより参照されているコンテンツは記録全体を構成し、他のリソースへの依存性が全くないということである。コンポーネントとそのコンテンツは、
記録管理システムの外部に保管された記録への依存してはならず、外部システムの記録及びその71
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

コンポーネントに含まれてはならない。同じ記録の中のコンポーネントは相互依存性を有していてもよいが、外部へ依存してはならない。完全性の原理は図.6i に示されている。

非準拠
記録

記録は完全ではない

コンポーネント

依存性
他のコンテンツ
を
必要とする

コンテンツ

準拠
記録

コンポーネントコンポーネント

依存性
コンテンツ

コンテンツ

図.6i 完全性の原理とは、各記録は完全に自己充足しており、自身の中のコンポーネントの全ての関連コンテンツを管理することである。
不変性の原理とは、一旦記録が作成されたら、記録のコンテンツを変えることができないということである。記録のメタデータやそのコンポーネントは変更してもよいが、そのコンテンツは
変更してはならない。コンテンツは改竄、入替え及び削除から守られていなければならない。
多くの記録管理システムが自身のコンテンツストアの中でコンテンツを管理している理由は、不変性の原理に準拠することにある。しかしながら、組織のすべての記録を一つのコンテンツス
トアに取り込むことは、不可能か非現実的であろう。したがって、MoReq2010®では、準拠システ
ムは不変性を保証するための適切な手段が講じられるという条件の下で、外部のコンテンツスト
アに収容されているコンテンツを管理することが可能である。不変性の原理は図.6j に示されて
いる。

72
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

非準拠
記録

コンポーネント

記録は修正可能である

コンテンツ

準拠
記録

コンポーネント

コンテンツ

図.6j 不変性の原理の下では、記録の作成後はコンポーネントのコンテンツが変更可能であってはならない。
廃棄可能性の原理とは、記録管理システムにおいてそのコンポーネントのコンテンツがあらか
じめ、又は同時にその記録が管理されているコンテンツストアから削除されていない限り記録が廃棄できないということである。セキュアな環境においては、廃棄可能性の原理は、紙媒体記録の細断又は焼却、電子的環境では、記録が読み取られないことを保証するために、磁気等の蓄積
媒体への上書き等にまで拡張される。廃棄可能性の原理は図.6k に示した。
廃棄の可能性の原理を実装して記録の廃棄を適切に計画することは、良好な記録管理の運用にとって非常に重要であり、且つ記録がその最終処分スケジュールに従って、適切な時点で実際に廃棄されることを保証するものである。
コンポーネントに属するコンテンツのタイプによっては、MCRS は、その廃棄を自動的に起動することができない可能性もある。特に物理的コンポーネントについてはそうであり、電子的コン
ポーネントでも、廃棄を実行するためにある種の人的介入が必要となる場合があるだろう。
このため、MoReq2010®は、コンポーネントに対して下記のいずれかの場合を認めている。
・記録管理システムはコンポーネントのコンテンツを自動的に削除することが可能である
場合・コンポーネントのコンテンツが、記録の廃棄の前に既に削除されており、そのコンポーネントエンティティが継続されることをユーザに確認することが必要となる場合
この情報は、個々のコンポーネントのメタデータの一部として保存されなければならない。
セクション 8．最終処分スケジューリングサービスでは、最終処分スケジューリングサービス
は、記録が廃棄される予定にある場合に、これらのタイプのコンポーネントコンテンツに対して73
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

どのように対応すべきかを述べている。

非準拠

記録

記録とコンポーネントより前にコンテンツが廃棄されていないコンポーネント

コンテンツ

準拠
記録

コンポーネント

コンテンツ

図.6k 記録の廃棄を可能にするには、廃棄可能性の原理に従い、対応するコンポーネントのコ
ンテンツがすべてのコンテンツストアから消去されなければならない。
6.2.11コンポーネントコンテンツ管理への設計アプローチ

コンテンツ管理の方法及び MCRS により管理できる異なるタイプのコンテンツは、記録管理シ
ステムの目的と想定する利用法によって変化するであろう。記録管理システムを開発する際には、供給者は下記の項目を検討しなければならない。
・ 各記録が持つコンポーネントの数―１、数個、又は可変・ 各コンポーネントに属するコンテンツのタイプ
・ コンテンツはどこに保管されるか―内部若しくは外部のコンテンツストア、又は、多数のコンテンツストアにまたがってか・ 記録管理システムにおける管理コンテンツの不変性の保証―とりわけ、もし記録がその場又は外部のコンテンツストアにおいて管理される場合
・ 記録管理システムにおけるユーザのコンポーネントのコンテンツにアクセスに関する許可方法・ 記録が廃棄された場合、記録管理システムがどのタイプのコンポーネンツに対してコンテンツを自動的に削除するのか、又は削除確認が要求されるのか。
MoReq2010®適合の記録管理システムは、特化された専用システムであってもよい、したがって必ずしもすべての形式のコンポーネントコンテンツを管理することは要求されていない。しかしながら、各々の MCRS は、他の設計目標の如何を問わず、電子的か物理的かに関わらず、それが74
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

提供する記録サービスの不可欠な構成要素としての内部又は外部コンテンツストア内の少なくとも一つのタイプのコンポーネントコンテンツを管理できなければならない。

75
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

7．モデル

7.1

メタデータサービス

サービス情報サービス名称

モデルメタデータサービス

サービスバージョン

1.0

実装サービス

MoReq2010®モデルメタデータサービスを実装している識別子（M14.4.42 参照）

MCRS は下記を使用のこと：
a600f8d0-2d58-418e-bb41-211d1fd42350
独自のネイティブコンテキストメタデータモデルを実装している MCRS は下記を使用のこと：
66bf4419-d92f-4358-8506-7ee9c06abdcd

7.2

モデルメタデータサービスへの準拠

7.2.１ 相互運用性とメタデータ
MoReq2010®の重要な目的は、準拠記録管理システム間の相互運用性を促進することである。相互運用性とは、エンティティがある MCRS からエクスポートされ、別の MCRS に直接インポート可能なことを言う。二つの記録管理システム間のデータの移動の際には、移動するエンティティの完全性とコンテキストが保存されなければならない。
相互運用性に関する上記の目標は、各エンティティとエンティティのメタデータ要素が普遍的に認識及び解釈される場合にのみ達成可能である。即ち、それは、メタデータ要素がどこでも同じであることを意味しなければならないということである。ワールドワイドウェブ(WWW)は異なるアプリケーションとシステム間の相互運用性の良い例である。今日では様々な供給者から提供される多様なウェブブラウザソフトウェアが使われており、それぞれが独自の機能や利点を持っている。しかしながら、ウェブブラウザが読み取って視覚的に表現するデータを保持しているウェブページは、良く知られている業界標準である HTML に従ってフォーマットされている。すべての準拠ウェブブラウザは、読みとり、解釈し、標準 HTML に従って描写することができる。
同様に、将来は、異なる供給者から提供される様々な機能を持った多くの異なる MCRS ソリューションが存在するようになるだろう。それらはすべて、標準化された MoReq2010®メタデータモ
デルとスキーマを用いることにより、記録や記録管理に関連することやその他のエンティティを交換することが可能となるだろう。
上記目標のため、各記録管理システムが保持しなければならないメタデータ要素や、特定のプ
ロセス、例えば、最終処分の実装方法等に関して、MoReq2010®は以前の仕様よりも規範的である、
この標準化により、すべての MCRS ソリューションで使われる普遍的に解釈可能なメタデータを設定することが可能になる。
7.2.2 モデルメタデータサービス
MoReq2010®全体を通して、各エンティティとサービスにより要求されるメタデータは、機能要件

76
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービスの一部として設定されており、その詳細は 14. 情報モデルで展開されている。この要求されているメタデータは「システムメタデータ」と呼ばれる。MoReq2010®は同じ手法により、システムメ
タデータを定義し、それが特定の実装に固有の追加メタデータ要素の作成を可能にしている。これらは、「コンテキストメタデータ」と呼ばれる。あらかじめ定義されたコンテキストメタデー
タ要素を一斉にエンティティに追加するために、MoReq2010®は、メタデータ要素の定義リストを持つメタデータテンプレートを定義することを認めている。メタデータテンプレートは特定のサービス又は分類の下で作成されていることの結果として作成段階にあるエンティティに適用できる。
したがって、メタデータ管理に対する MoReq2010®のアプローチは単純で理解しやすく、そして少数の異なるエンティティタイプで表現することが可能である。それは、システムメタデータを定義するのと同じアプローチにより作成されており、既存のほとんどの記録管理システムと十分に適合するようにすべきである。多くのシステムは MoReq2010®で要求されているものよりはるかに複雑なメタデータ管理のアプローチを用いている。
これと同時に、MoReq2010®は、既存の記録管理システムのある部分は、設定されたモデルメタ
データサービスとは内部的に適合しない技術を使って、メタデータを管理することを認めている。
おそらく、コンテキストメタデータをエンティティに適用するのに、メタデータテンプレートを使わずに、例えば、別の方法を使用しているからかもしれない。相互運用性を高めることの利益に鑑み、これらの記録管理システムは、モデルメタデータサービスを実装している記録管理シス
テムに対してエンティティを移動することが可能であるならば、MoReq2010®準拠記録管理システ
ムとして認証される。
将来的に、既存の記録管理システムの供給者は新しいバージョンのソフトウェアに、モデルメ
タデータサービスの側面を徐々に取り入れながら、漸進的にサポートを行う可能性もある。一方
で、新しい記録管理システムは MoReq2010®モデルメタデータサービスを全面的に導入する可能性もある。
7.2.3 モデルメタデータサービスの試験と認証へのアプローチ
DLM フォーラム財団は、記録管理システムが MoReq2010®モデルメタデータサービスに準拠しているか否かの試験と認証方法として、二通りのアプローチを認めている。
以下のいずれかA. 記録管理システムが MoReq2010®モデルメタデータサービスを完全に実装する場合、このモジュールの要件に照らして、試験と認証を実施する。
又はB. 記録管理システムが独自のメタデータモデルを実装し、アプリケーションが下記の評
価基準を満たす。
・ 当該記録管理システムにおいて、その独自メタデータモデルに柔軟性、機能及び情報

77
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービスの一貫性の面で MoReq2010®モデルメタデータサービスと等価であることが示される。
・ 当該記録管理システムにおいて、エクスポートの際に、その独自メタデータを、モデ
ルメタデータサービスで用いられているものと同じ XML フォーマットに変換することが可能であり、相互運用性に対応しなければならない。これはデータが引き続き別の
MCRS に移動される際に、メタデータ要素が同じデータで占められ、同じ意味論的解釈を持ち、同じ標準化された識別子とコードを持つようにするためである。
7.2.4 代替（タイプ B）要件の遵守方法
MCRS の独自メタデータモデルが柔軟性、機能及び情報の一貫性の面で MoReq2010®モデルメタ
データサービスと等価であることを示すには、記録管理システムについて下記の事項が証明されなければならない。
・ 記録管理システムが、MoReq2010®で定義されたエンティティタイプと等価のものを有しているということ。これらは、本仕様で設定されているものと同じ役割を果たさなければならない
つまり、それぞれのエンティティタイプに対して、仕様で設定されているものと同じデータタ
イプ、意味及び値域を持っており、MoReq2010®で定義されたシステムメタデータと等価のものを有しているということである。
・ 実体（インスタンス）固有又はコンテキストメタデータ要素を作成できなければならない。このメタデータ要素には、データの値を保持しているコンテキストメタデータ
要素とエンティティへの参照を保持しているコンテキストメタデータ要素の両方が含まれる。
・ 様々座エンティティタイプ、とりわけ集合及び記録は、MoReq2010®で定義されている
システムメタデータに加えて、コンテキストメタデータをその定義の中に含めることができなければはならない。
・ 供給者は、コンテキストメタデータ要素がどのように定義され、適用されるのかが実
証できなければならない。
・ 供給者は、コンテキストメタデータ要素の値がどのように入力、修正、及び削除されるのかを実証できなければならない。
・ メタデータサービスは、理論的に無制限の数の追加コンテキストメタデータ定義に対応できなければはならない。
・ 順序づけられたセット（MoReq2010®では、これをテンプレートと称している。
）のエン
ティティが最初に作成される際（後日の可能性もある。）、コンテキストメタデータ要
素は、それらに対して（個別にではなく）集合的に適用できなければならない。
・ 記録管理システムにおいて、様々な業務上の理由により、コンテキストメタデータ要78
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

素はエンティティに対して選択的に適用できなければならない。ただし、コンテキス
トメタデータ要素のセットを集合又は記録に適用する、少なくとも一つの理由は、その分類結果から導かれたものでなければならない。
（即ち、異なる分類として作成された別々の記録や集合は、クラスに応じて、それらと関連付けられる別々のメタデータのセットを持つことを許されなければならない。
）
・ 各メタデータ要素は、エンティティに対して一回のみ適用されるべきである。
・ メタデータ要素がエンティティに適用され、必須な値の供給を要求している場合には、その要素に対するデフォルト値又はその組み合わせによって正しい値が提供されるまでは、MCRS 内にエンティティが作成されてはならない。その値は記録管理システムによって自動的に計算された値及びユーザ供給の値である。
・ テキストメタデータ要素は常に、メタデータ要素の言語を識別する言語識別子を伴わなければならない。
・ 記録サービスは、エンティティが廃棄されたときに、そこからメタデータ要素を選択的に削除する機能を備えなければならない。これは、各メタデータ要素に対して例外なく設定され、承認ユーザによる再構成が可能である。
MoReq2010®モデルメタデータサービスフォーマットに従って、独自のメタデータをエクスポー
トのために変換する場合には、下記の事項が守られなければならない。
・ 記録管理システムは、すべてのエンティティとサービスに対するシステム識別子に
UUID を使用しなければならない。
・ 記録管理システムは、MoReq2010®標準識別子とコードが供給されている場合には、常にそれを使わなければならない。
・ 記録管理システムは、MoReq2010®仕様で定義されていない追加のエンティティタイプとサービスを加えてはならない。
・ MoReq2010®システムメタデータ要素は、メタデータ要素で宣言されている目的と合致しないデータ値を保存するために使うことはできない。
・ 供給者は、MoReq2010®のシステムメタデータについて詳細を述べてはいけないが、必要な場合には、MoReq2010®コンテキストメタデータ要素を使って、追加情報をエンテ
ィティやサービスに加えてもよい。
・ これらのコンテキストメタデータ要素は、記録管理システムの内部状況（例えば、記録管理システムが、それぞれのエンティティに関する内部識別子を持っているか否か。）
に関する追加情報を提供することを目的として、エクスポートの際に追加してもよい。
・ エンティティとサービスに追加されたすべてのコンテキストメタデータ要素は、コン
テキストメタデータ要素を持つエンティティがインポートされ、受領側システムによって解釈を行えるようにするために、関連する MoReq2010®準拠のメタデータ要素定義
を同じエクスポートに含まなければならない。
・ 記録管理システムはエクスポートの最中に、メタデータ要素のコンテンツの意味又は

79
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

その値のいずれも変えてはならない。
・ 供給者は、その製品で使われたメタデータとテンプレートのマッピングを説明し、どの内部要素がどの MoReq2010®要素に対応するか、エクスポートされたメタデータがどのようにモデルメタデータサービスを模倣するように作られたかを示す完全なマッピ
ング表を提供しなければならない
・ 供給者は、そのメタデータマッピングスキーマを、製品の完全版試験報告に含まれなければならない
供給者は、更なる助言とガイダンスを DLM フォーラム財団事務局を通して、MoReq2010®管理委
員会に請求することができる。
本モジュールについての以下の部分では、MoReq2010®モデルメタデータサービスの概念及び要件について述べる。

7.3

主要概念

7.3.1 システムメタデータとコンテキストメタデータ
MoReq2010®のコアな要件は、MCRS 内での記録管理に成功し、MoReq2010®エクスポートデータフ
ォーマットを用いて他の記録管理システムに移動する際に必要であり、且つメタデータ要素の簡単な、恐らく最小規模のセットを設定している。この MoReq2010®により設定されるメタデータの基本的ワーキングセットは、仕様を通じて「システムメタデータ」と呼ばれ、全ての MoReq2010®
準拠の記録管理システムによって維持されなければならない。システムメタデータは、MoReq2010®
の機能要件を実行するのに必要とされるメタデータ要素のみを表している。
MoReq2010®で述べられている記録管理機能をシステムメタデータを用いて実装することに加えて、記録管理システムは記録及び関連エンティティにそのエンティティの履歴的及び運用上のコンテキストを補強するメタデータ要素を付加することが可能である。
記録をマッピングする際に、この付加的な便益をもたらすメタデータには下記の事項が含まれるが、これに限定されるものではない。
・ エンティティのタイトルや記述では伝えられない追加の記述情報―

例えば、特定の地

理的特徴又は場所を参照している記録の GPS 座標
・ 外部の識別子又は参照番号―

例えば、アーカイブの受入番号又は法的召喚に関する裁判所事件番号
・ 記録のコンテンツから抽出された符号化情報―

例えば、住所確認アプリケーションで使えるようにフォーマットされた発注書のための供給者の名前と住所
・ 組織により非公式に、又は特定の法的若しくは規制的なコンテキストの中で使われたマーキング― 例えば、EC 指令 2003 年第４号（環境情報の公開に関する 2003 年 1 月 28
日の欧州議会及び欧州評議会の EC 指令 2003 年第４号）に則った情報公開のために記録の評価がなされたか否かを示すマーキング

80
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

・ 作業フローの状況― 例えば、記録がレビューされた場合には、レビューした人の名前、レビューの結果、及びレビューの日にち
・ 他の業務システムから捕捉したメタデータ― 例えば、電子メールの記録では、差出人、宛先、CC（カーボンコピー宛先）、件名等のコンテンツ、及び電子メールのヘッダにある他のメタデータ
・ 記録のコンポーネントから抽出されたメタデータ―

例えば、画像については、その大きさ、画素密度、使用されている色の数、圧縮形式などの詳細
・ ユーザとグループについて―

会社の名簿から抽出された追加情報であり、組織内での地位、オフィスの所在地、電子メールアドレス、及び電話番号等
7.3.2 MoReq2010®モデルメタデータサービス
MoReq2010®によって、エンティティタイプとその関連メタデータ要素定義を管理するメタデー
タサービスが規定される。メタデータサービスは、記録管理システム、又は業務システムにおいても共有・利用が可能であり、特定の記録管理システムに完全に組み込まれているが、このサービスが全体として MCRS との区別がつかなくてもよい。
7.3.3 メタデータエンティティの関係
モデルメタデータサービスにおけるメインエンティティ間の関係は図.7a に示されている。この図はエンティティ間のすべての関係を示している。さらにここからエンティティ間の個別の関係へと細分化される。
システム
メタデータ
要素定義

エンティティ
タイプ

テンプレート

コンテキスト
メタデータ
要素定義

システム
メタデータ
要素

コンテキスト
メタデータ
要素定義

エンティティ

図.7a モデルメタデータサービスにおけるエンティティ関係81
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

この図の中央にあるのは、エンティティとエンティティタイプの関係である。それぞれのエン
ティティは MoReq2010®で定義されているエンティティタイプのうち、ただ一つのエンティティタ
イプに属さなければならない。図.7b を参照のこと。エンティティとエンティティタイプは、適切なサービスの下で管理される（R2.4.9 参照）。

エンティティ
タイプ

エンティティ

図.7b 各エンティティは一つのエンティティタイプを持つ。
各エンティティはメタデータ要素で構成されている。MoReq2010®で義務付けられているメタデータ要素はエンティティのシステムメタデータ要素であるが、一方、MoReq2010®で参照されていない、追加の記述的メタデータ要素もまた、作成の時期又は事後にエンティティに加えてもよい。
エンティティとそのメタデータ要素の関係は図.7c に示されている。エンティティは多数のメタデータ要素を持ち、それぞれはそのエンティティに専属している。

システム
メタデータ要素

コンテキスト
メタデータ要素

エンティティ

図.7c 各エンティティはシステムメタデータ要素を持ち、それはまたコンテキストメタデータ要素も持つことができる。
エンティティがエンティティタイプ定義によって定義されるのと同じ方法で、メタデータ要素
は常にメタデータ要素定義にリンクされている。一つのエンティティに含まれる全てのメタデー
タ要素に対応するシステムメタデータ要素定義又はコンテキストメタデータ要素定義のいずれかがなければならない。これについては、図.7d を参照のこと。

82
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

システム
メタデータ要素定義

コンテキスト
メタデータ
要素定義

システム
メタデータ
要素

コンテキスト
メタデータ
要素

図.7d すべてのメタデータ要素はメタデータ要素定義と関連付けられる。
システムメタデータ要素定義は、
MoReq2010®により定義及び提供されており、それらは 14.4

システムメタデータ要素定義に列記されている。これらは図.7e に示すように、MoReq2010®の機能要件と厳密に一致する形で別々のエンティティタイプに関連付けられている。記録管理システム
は追加のシステムメタデータ要素又は追加のエンティティタイプを定義することはできない。
コンテキストメタデータ要素定義は、ローカルな要求に対応するために、承認ユーザにより作成される。これらのローカルに設定されたメタデータ要素定義は、特定のエンティティタイプのエンティティに適用されるテンプレートの中に含まれることにより、エンティティに追加される。

システム
メタデータ
要素定義

エンティティ
タイプ

図.7e システムメタデータ要素定義はエンティティタイプに関連付けられる。
各テンプレートはコンテキストメタデータ要素定義の集合を含み、一つかそれ以上のエンティ
ティタイプに適用してもよい。あるテンプレートが、あるエンティティタイプのためのエンティ
ティサービステンプレートと指定された場合や、そのタイプのエンティティが生成された場合は、常に MoReq2010®によりそのテンプレートが自動的に適用される。そのほかの場合には、テンプレートは承認ユーザにより選択的にエンティティに適用されるか、記録と集合の場合に限り、記録タイプに関連する特定のクラスに分類することにより適用される。
テンプレートとエンティティタイプの関係、及びテンプレートとコンテキストメタデータ要素
定義の関係は図.7f に示した。

83
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

エンティティ
タイプ

テンプレート

コンテキスト
メタデータ要素
定義

図.7f コンテキストメタデータ要素定義はテンプレートと関連付けられており、転じてそれはエンティティタイプに関連付けられる。
なお、図.7b から図.7f は、図.7a のエンティティの関係図を構成していることに留意のこと。

84
第１巻

コアサービス及びプラグインモジュール

第8．処分スケジューリングサービス
1 部 コアサービス

8.1

サービス情報サービス名

最終処分スケジューリングサービス

サービスバージョン

1.0

サービス識別子

fd05e284-181f-4f5d-bd8c-4bed835c8931（M14.4.42 参照）

8.2

主要概念

8.2.1 MoReq2010Ⓡ記録ライフサイクル
最終処分スケジュールは、全ての MCRS ソリューションで記録のライフサイクル管理に用いられる。
MCRS の中で一度記録が作成されると、それがあたかも存在しなかったかのように全部を削除することはできない。この挙証説明責任の概念は適切な記録管理のために重要である。完全な記録とそのコンテンツはもはや存在しないものの、残留記録が残り、かつて MCRS によって保持されていたことを示す。残留記録はシステムの寿命が続く限り、MCRS とともに残り、記録がかつて現用であったことを示すだけでなく、それより重要なものとして、適切な最終処分スケジュールの下で記録が適切に最終処分されたことを示す。
完全なメタデータ、エンティティ履歴、及びコンテンツを持つ現用のエンティティからの残留
エンティティへの遷移は、「廃棄」と呼ばれ、「削除」（エンティティのすべての痕跡が取除かれる。
）と区別される。MoReq2010®は、この概念を集合、クラス、最終処分スケジュールなど、記録以外のエンティティにも適用する。廃棄は不可逆的なプロセスである。なぜならエンティティのある部分は消去され、エンティティは現用の状態には戻らないからである。図.8a は MoReq2010®
記録ライフサイクルの簡単な概観となっており、２つのイベントのみが考慮されている。即ち、現用のエンティティとしての MCRS 内における記録の作成とその後の廃棄である。
図.2g ですでに示したような一般的なエンティティライフサイクルとは異なり、特に記録にとって「初回使用」概念はなく、記録が削除されるような場合も、作成直後の期間はないことに注目すべきである。図.8a に示した概略図は後で敷衍して説明する。そこではより詳細な記録ライ
フサイクルによるそれぞれの最終処分措置のバリエーションを示す。

85
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

廃棄イベント

作成イベント

現用

残留コンポーネント生成
イベント履歴が始まる
メタデータ捕捉コンポーネント廃棄イベント履歴削除
メタデータ削除時間

図.8a 記録のライフサイクルの概略図
図.8a のように、現用の記録が作成されると、そのコンポーネントとそれらのコンポーネント
コンテンツが同時に作成され、メタデータが記録とコンポーネントのために捕捉され、その記録のイベント履歴が作成イベントとともに始まる。その後現用記録が廃棄されると、そのコンポー
ネントのメタデータ及びイベント履歴とともに、記録のメタデータとイベント履歴は削除される。
ここで最も重要なことは、記録のコンポーネントコンテンツが削除されることである。
エンティティの廃棄の際に自動的に削除されるべきイベント及びメタデータ要素は承認ユー
ザにより設定可能である（R2.4.20 及び R7.5.6 参照）。記録の残ったメタデータはそれらのイベント履歴と共に残留記録とその残留コンポーネントを造りあげる。
削除は記録のコンテンツの適切な廃棄を確認する上で重要なプロセスである。特に機微な環境においては、これらのイベント及びメタデータが記録のオリジナルコンテンツの情報をさらけ出
すかもしれず、廃棄されたコンテンツが部分的（又は全体的）な再構築に使われるかもしれない。
例えば、病院記録のメタデータ又はイベント履歴には患者名又はその患者の医療履歴の特殊なインシデントがプライバシー事項に違反しながら、永久に含まれる可能性がある。
既に廃棄された残留記録からのイベントとメタデータの削除は、通常、裁判所命令や判決に応じる形で承認ユーザが行うことも考えられる（R2.4.21 及び R7.5.7 参照）。裁判所はそれらの存続が問題であるか不正であると感じているので、時々、メタデータとイベントを含む特定の記録を抹消しなければならない。
廃棄においてメタデータとイベント履歴を削除する時の記憶容量は二の次である。なぜなら残留記録は MCRS が存続する間保持されるからである。
8.2.2 最終処分スケジュールと最終処分措置
最終処分スケジュールは記録管理にとって大変重要である。なぜなら MoReq®2010 は MCRS の中にある記録についてその記録に割り当てられた最終処分スケジュールが管理する最終処分プロ

86
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

セスの一段階として、廃棄を規定するからである。どれ位の期間記録を保存するか、保存期間の後、どのように最終処分するかを決定するのは記録の最終処分スケジュールである。こうした理由からすべての記録には最終処分スケジュールが必要である。
すべての最終処分スケジュールは MoReq®2010 処分プロセスに適合しなければならないが、最終処分スケジュール自体は全く異なった振舞いを規定してもよい。ある記録の最終処分スケジュー
ルは永久保存とし、決して廃棄しないことを規定してもよい。一方、別の最終処分スケジュール
では記録の速やかな廃棄を規定してもよい。また別の最終処分スケジュールは保存期間の終わりに記録をレビューすることを規定してもよい。こうした例は異なる処分措置の結果である。
MoReq2010®はすべての最終処分スケジュールが、以下の４つのうちのいずれかを選択することを求める。
・ 永久に保存する。
・ 保存期間の終わりにレビューする。
・ 保存期間の終わりに移動する。
・ 保存期間の終わりに廃棄する。
8.2.3 保存期間の計算
各々の最終処分スケジュールには、年、月、週又は日の数で定義された保存期間が存在する。
保存期間は保存トリガーイベントで定義される特定の保存開始日から始まる。保存トリガーイベ
ントは各々の記録又は記録の親集合に関係付けることができる。
全ての集合とその最終処分を一括管理しようとする組織は、それらの最終処分スケジュールのための集合に関連した保存トリガーを指定するべきである。以下の保存トリガーは記録の親集合に関係がある。
・ 集合の生成日から。
・ 集合への直近の追加の日から。
・ 集合を閉鎖した日から。
・ 集合と関連したコンテキストメタデータ要素で指定された日から。
これに対して、以下の保存トリガーは、個別の記録に関係がある。これらの保存トリガーを使うと、親集合のなかの記録は選択的に異なる時点に最終処分されるが、同じ集合の他の記録は現用のままである。
・記録の発生日時から。
・記録が親集合に追加された日から。
・記録に関連するコンテキストメタデータ要素で指定された日付から。

87
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

以下の保存トリガーは個別記録又は集合に対し、等しく適用可能である。
・ 永久に保存する（保存トリガーはない。）。
・ 現在から（即時発効する）。
・ 最終レビューの日から。
記録の最終処分スケジュールが変更された場合や保存トリガーで参照された値が更新された
場合は、記録の保存開始日は MCRS によって再計算されなければならない。例えば、以下の場合
は常に再計算しなければならない。
・ 記録のデフォルト最終処分スケジュールが、変更により置き換えられた場合（R5.4.4 参照）、又は記録を再分類した場合（R5.4.8、R6.5.4 及び R6.5.12 参照）
・ 記録のデフォルト最終処分スケジュールが記録又はその親集合を新しい集合に移動することによって書き換えられた場合（R6.5.8 及び R6.5.13）
・ 記録のデフォルト最終処分スケジュールが、記録に直接適用されるスケジュールにより上書きされた場合（R6.5.15 参照）
これらのスケジュールに加えて、以下のものが、すべて可能な保存トリガーであり、それらを変更すると保存開始日の再計算が始まる可能性がある。
・ 記録の作成日時が変更される。
（R2.4.26 参照）
・ 記録の親集合がクローズする。
（R6.3.7 参照）
・ 集合に関連したコンテキストメタデータ要素が修正される。
（R8.4.4 参照）
MoReq2010®が最終処分を計画的な活動とみなしていることに留意しなければならない。従って、保存トリガーのチェックを必要とせず、保存開始日は 1 日に複数回再計算される。記録の新しい
バッチは最終処分の期限が到来する一日毎に表示される。これに基づいて記録管理ルーチンが計画される。しかし、R8.4.14 によって、承認ユーザは MCRS により個別に記録の最終処分状態の即時更新を要求することができる。
また MoReq2010®は、これらのエンティティのために、作成タイムスタンプではなく、記録と集合の作成日時を保存開始日の計算に使用するよう要求していることに留意すべきである。これによって、記録のライフサイクルを通じて連続性を保持しつつ記録システム間の相互運用性を保つことが可能になる。記録又は集合が新しい記録システムにインポートされるごとに、作成タイム
スタンプは再びそのシステム内で作成される。それは通常とは異なる作成タイムスタンプを持ち、新しい MCRS にインポートされた時期を反映している。しかし一方、記録又は集合がインポートされた時、前回の MCRS で設定された発生日時の値は更新されない。
このことにより、記録の保存開始日は記録の作成イベントよりも前になる。例えば、もし集合において新しい記録が作成され、親集合の作成日時に基づく保存トリガーで最終処分スケジュー88
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

ルが与えられたならば、記録の保存期間は記録が作成される前から開始されていることになる。
このケースは図.8c、図.8d、図.8e などの添付イラストには示しておらず、理解を容易にするために、記録作成日後に発生する保存開始日を示している。
8.2.4 記録の最終処分の確認
最終処分スケジュールは、最終処分措置、保存トリガー及び保存期間に加え、確認期間を規定しなければならない。確認期間は、最終処分措置を実行するための許容期間を表す。確認期間の長さは組織によって異なる。また、最終処分スケジュールごとに異なるとも考えられる。
確認期間の正確な意味は選択された最終処分措置に依存する。レビューという措置では、確認
期間はレビューを完了し、レビュー後の意思決定を適用するために割り当てられた時間を表す。
廃棄という措置では、確認期間は記録のコンテンツを削除し、それが削除されたことを確認するために割り当てられた時間を表す。
移動という措置には、二つの確認期間がある。第一に、記録を MCRS の管理外の新しい場所へ
移動しなければならない。これには通常、記録を MCRS からエクスポートすることが含まれる。
移動が完了したことを確認するとすぐに、最終処分措置は移動から廃棄に変化し、最終処分プロ
セスは第二の確認期間に入り、MCRS が保持する記録のコンテンツが廃棄されたことを確認する。
最終処分措置の完了に必要な確認を MCRS が受信せずに確認期間が経過した場合、MCRS は承認
ユーザに対し警報を発し、該当する記録の最終処分期限が超過したことを通知する。この対策は、記録が最終処分予定日後の、可能な限り短い期間の間に適時に最終処分されることを意図したものである。
8.2.5 永久保存ライフサイクル
記録管理の重要な側面は、重要な記録を非常に長期間保存することである。これには、決して捨て去ってはならない記録を指定する能力が含まれる。MoReq2010®では、これは永久的保存を指定する保存トリガーによる最終処分スケジュールを適用することによってなされる。このタイプの最終処分スケジュールは保存トリガーがなく、保存開始日とそれに続く保存期間の計算を抑止する効果を持つ。永久保存の効果は図.8b に示した。これは図.8a の単純なライフサイクルと比較するとよい。
作成イベント
永久保存

時間

現用

89
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

図.8b その最終処分スケジュールが永久的保存を指定する場合、記録に対して保存開始日は設定されない。その最終処分スケジュールは変更されず、MCRS の寿命が続く間、記録は現用状態となる。

8.2.6 ライフサイクルのレビュー
MoReq2010®は可能な限り分類に従い、分類によって最終処分を決定するよう奨励している。このことは、記録が保管される期間と最終処分方法は業務分類に基づくことを意味している。この
記録の適切な管理の原理は、「作成時宣告」とも呼ばれる。
しかし、記録が作成された時に記録の重要性と保存時間の長さが分からず、記録が格納された集合の閉鎖などのような、後続のイベントから単純に計算できない場合がある。いくつかの法域
では、保存期間が長いため、介在期間の中で保存のための指示が変化するように感じられるときもある。例えば、特定の記録クラスを 40 年後に廃棄することが必要だとすれば、記録管理者は
40 年のうちに 40 年で記録を廃棄するという規則を見直す可能性を論じてもよいということである。こうした状況の下では、記録の最終的な運命のについて合理的な疑いを差し挟む余地があり、記録は永久保存、移動、廃棄ではなく、その後もレビューのために保存することができる。
記録の最終処分措置がレビューに設定されている場合、記録は直ちに移動もしくは廃棄される
わけではない。むしろ、レビューの結果では、レビュー後の意思決定に基づき、最終処分スケジ
ュールを記録に適用しなければならない。新しい最終処分スケジュールが記録に関連した古い最終処分スケジュールに取って代わる。その新しい最終処分スケジュールは、記録の最終的な運命を指定することや、その後の再度のレビューのスケジュールを設定したり、その記録を永久に保存するために利用することが可能である。
図.8c はレビューの結果が新しい最終処分スケジュールを記録に適用するに当たってどのような影響を与えるかを示したものである。これによって、新しい保存開始日、最終処分措置、確認期間を算出することとなる。
その結果、最終処分プロセスは継続し、次のレビュー期間に至る場合がある。最終処分の保留
はレビュープロセスを中断しないことに注意されたい。ただ記録の最終的な廃棄を防止するのみ
である。

90
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

最終処分予定日（レビュー）
作成イベント
保存開始日

レビュー完了

保存期間

保存開始日
（新規）

保存期間
レビュー確認時間

新しい最終処分スケジ
ュール適用

現用

図.8c 最終処分スケジュールが記録のレビューを指定する場合、レビューの完了及びレビュー
後の意思決定実行の一部として新しい最終処分スケジュールを記録に適用しなければならな
い。

8.2.7 移動ライフサイクル
最終処分スケジュールによって、ある記録を、別の記録システムへ移動することを指定してもよい。例えば、より集中型の記録管理システム、二次保存施設又はアーカイブ等への移動である。
移動は、二つのフェーズで行われる。まず、記録を MCRS からエクスポートし、他の記録システ
ムにインポートしなければならない。移動が行われ、次のシステムが記録受領に成功したことを確認したらすぐに、MCRS は記録の最終処分措置を移動から廃棄へと変更し、その記録自体はその後廃棄される。
図.8d は移動という処分措置に適用される記録のライフサイクルを示している。移動が成功したことを承認ユーザが確認するまで記録は廃棄されない。記録が最終処分保留にある場合、移動の第一フェーズは継続するが、最終処分プロセスは、第二フェーズである記録の廃棄前に中断されなければならない。

91
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

保存期間

最終処分期限（移動）作成イベント

廃棄完了

移動確認及び
最終処分予定日（廃棄）

保存開始日
保存期間

移動確認

廃棄確認

残留
現用

最終処分保留はここでプロセスに介
入する。

時間

図.8d その最終処分スケジュールが記録の移動を指定する場合、記録は MCRS によって廃棄されるが、それは移動完了が確認された後である。
MoReq2010®は移動を取消すこともできる。移動が取消されたら、記録には新しい最終処分スケ
ジュールが与えられなければならない。結果は図.8c のレビューと同様となる。
8.2.8 廃棄ライフサイクル
図.8e は廃棄の最終処分措置における記録ライフサイクルを示している。廃棄という最終処分
措置への対応及び移動の第二フェーズとしての記録の廃棄には特殊な制限がある。もし記録が最終処分保留状態にあれば、MCRS は記録を保持するものとしてマークし、記録が廃棄されることを阻止しなければならない。この場合、廃棄確認スケジュール期間は、最終処分保留が解除されるまでは開始してはならない。最終処分保留に関する詳細は 9．最終処分保留サービスを参照のこと。
重要なことは、一度最終処分確認期間に入ると、最終処分保留の要求は記録の廃棄を防止できないことに留意することである。なぜなら、コンテンツの廃棄命令はすでに発令されたとみなされ、廃棄が行われたことの確認を待つのみだからである。その命令が発令されると、MoReq2010®
はリコールに備えていないため、記録の廃棄の防止は MCRS の制御外となる。

92
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

作成イベント

最終処分予定日（廃棄）
廃棄完了

保存開始日
保存期間

廃棄確認

残留
現用

最終処分保留はここでプロセスに介
入する。

時間

図.8e 最終処分スケジュールが記録の廃棄を指定する場合、通常は最終処分予定日に続く確認期間がある。
MCRS 内部における記録の廃棄方法は、各コンポーネントのコンテンツの性質によって異なり、且つ MCRS の設計及び目的に依存する。MCRS 内部で記録が作成される場合、記録のコンポーネン
トはコンテンツとともに作成される。このコンテンツは MCRS が自動的に削除したり、削除確認を要求したりすることができるものである。これはコンポーネントのメタデータ内部に含まれる
自動削除フラグによって決定されるものである。詳細は R6.5.19 参照。
それ自体のコンテンツレポジトリを直接管理する MCRS では、記録が廃棄される時、コンポー
ネントのコンテンツを自動的に削除できる可能性が高い。記録を別の業務システムの所定位置で管理する MCRS や、デジタルコンテンツよりも物理的コンテンツを持つ MCRS は、廃棄をスケジュール化された記録のコンテンツの廃棄に個別の確認を受信することとなっていることが多い。
MoReq2010®は MCRS ソリューションのアーキテクチャを束縛することがないので、自動的に記録
コンテンツを廃棄することができなければならない。また MoReq2010®は全ての MCRS ソリューシ
ョンが確認を必要とする、記録コンポーネントのサポートが可能であることを指定しない。多くの MCRS ソリューションはコンテンツの両方のタイプをサポートし、また異なるコンテンツタイ
プの構成を認めている。供給者は製品の中でこれらのオプションを構築し、サポートしてもよい。
こうした理由から、MoReq2010®の最終処分は、記録が廃棄されなければならない時、MCRS はコ
ンポーネントが自動的に廃棄し得るか、又は確認後に廃棄しなければならないかをチェックしな
ければならないとしている。そして、MCRS は残存したコンポーネント及び記録自体を廃棄する前に、自動的には廃棄できないコンポーネントのコンテンツの廃棄の確認を待つこととなる。
このアプローチは、廃棄スケジュールの属性として自動廃棄が指定されていない場合には、
MCRS の設計及び実装と同様に、記録のコンテンツの性質の機能は、MoReq®の以前のバージョンと異なることに注意しなければならない。

93
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

8.2.9 ボトムアップ廃棄
MoReq2010®の下では、最終処分スケジュールは記録に適用されるだけであり、集合には適用されない。これは以前のバージョンの仕様とは異なる。集合はクラスを持つが、最終処分スケジュールを持たない。その代わりに集合の廃棄は MCRS によってボトムアップ廃棄の原理で自動的に管理される。
この原理の下で、集合の各々の記録は異なる時点で廃棄することができる。廃棄が行われる時、廃棄された記録は残存記録になるが、同一の集合では現用であれ、残存であれ、他の記録に影響はない。集合で最後の現用記録が廃棄されるまで集合自体にも影響はない。
ボトムアップ廃棄とは、集合で最後の現用記録が廃棄された時、集合自体が自動的に MCRS によって廃棄されることを意味する。しかし、集合の自動廃棄は集合が閉鎖されているときのみに行われるものである。集合が開かれている場合、その集合は廃棄できない。最後の現用記録の廃棄の際、集合がすでに閉鎖されている場合、又は集合が後日、閉鎖された場合、それ以上の現用記録が追加されていなければ、集合は自動的に廃棄される。
また、集合が一度も使われていない場合、その集合が開かれていようと閉鎖されていようと、自動的に廃棄されないことを認識すべきである。しかし、使ったことのない集合は削除できる。
図.8f は集合の最後の記録が廃棄された時に、開かれている集合にも閉鎖されている集合にも適用されるボトムアップ廃棄を示している。

開かれて
いる

集合廃棄

集合は開か
れたまま
最終記録の
廃棄

集合

記録

記録

記録

閉鎖され
ている

最終記録の
廃棄

集合

記録

記録

記録

記録

記録

図.8f ボトムアップ廃棄の原理によれば、集合の最後の記録が廃棄された時、集合が閉鎖されていれば、自動的に廃棄される。
ボトムアップ廃棄は、記録を格納する集合に影響するだけでなく、他の集合を格納する集合にも影響を与える。子集合がすべて廃棄されると親集合は MCRS によって自動的に廃棄される。親集合が閉鎖されていなければならないという同じ規則も適用される。
図.8g に上方に連鎖する集合の廃棄が及ぼす累積的影響を示した。

94
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

閉鎖され
ている

親集合が廃棄される

最後の集合が廃棄された時

集合

集合

最終記録の
廃棄

集合

集合

記録

記録

記録

記録

図.8g 記録又は他の集合のいずれであっても子エンティティが廃棄されると、閉鎖されている集合は自動的に廃棄される。これは親集合廃棄のトリガーとなるとも考えられる。
8.2.10

最終処分の不一致

MoReq®の以前のバージョンを含めた記録管理システムの一部の仕様は、同一の記録に二つ以上の最終処分スケジュールが同時に適用されている場合等、最終処分の不一致を認めている。曖昧さを解決するためのユーザによる人的介入、又は対立する最終処分スケジュールのどちらがより重要で優先権を持つかというアルゴリズムの実行によって、結果として生じる最終処分の不一致を管理しなければならない。
MoReq®は、各々の記録がたった一つの最終処分スケジュール（随時、記録に適用される）を持つようにすることで、このような最終処分の不一致を回避するように慎重に設計されている。各記録に最初に適用された最終処分スケジュールはデフォルト最終処分スケジュールで記録のクラスに結びついている。このデフォルト最終処分スケジュールは異なる最終処分スケジュールを
記録自体に適用することで承認ユーザによって上書きされる。記録の持つ最終処分スケジュールが一つであれば新しい最終処分スケジュールは何度も上書きできる。
記録のデフォルト最終処分スケジュールが上書きされる最も一般的な理由は、レビュー後の意
思決定の結果、新しい最終処分スケジュールを適用するためである。
以下は、記録のライフサイクルの例である。
・ 「集合閉鎖から 2 年後のレビュー」のクラスから継承したデフォルト最終処分スケジュールとともに記録が作成される。
・ 記録の集合はその後閉鎖される。
・ ２年後、記録はレビューされ、その結果、新しい最終処分スケジュールが適用される。
「最終レビューから 1 年後のレビュー」
・ １年後、記録は再びレビューされ、３つ目の最終処分スケジュールが適用される。
「６ヶ月以内に廃棄」

95
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

・ ６ヶ月後又は記録の集合が閉鎖してから合計で３年半後、その記録は MCRS によって廃棄される。
この例では、デフォルト最終処分スケジュールとともに記録が作成される。その後最終処分ス
ケジュールは、記録が現用である間に二回上書きされる。しかし、どの時点でも記録はたった一
つの最終処分スケジュールに従い、たった一つの対応する最終処分プロセスに従う。このようにして、MoReq2010®は MCRS が最終処分の不一致や曖昧性を決して管理する必要がないよう保証しているのである。
8.2.11

最終処分プロセス

MCRS は最終処分プロセスが各々の現用記録に定期的に実行されるようにしなければならない。
これはリアルタイム又はスケジュール化された活動として行われるが、MoReq2010®は承認ユーザ
が毎日、最終処分期限の到来した記録に対する記録管理活動を日常的に行えるようにしている。
図.8h のフローチャートは各記録の最終処分プロセスの論理図である。様々な意思決定のポイントと必要な処理を示している。
このダイアグラムはこの章に記載された機能的要件を視覚的に示すためのものであり、論理図とみることができる。同一の入力データに対するプロセスで記述されたと同じ論理的帰結を MCRS
ソリューションがもららす限りにおいて、いかなる最適化もされてはおらず、コードで再現されることも意図していない。

96
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

開始
各記録について最終処分スケジュールをチェックする

いいえ
永久に保存
するか？

保存のトリ
ガーが発効
したか？

はい

最終処分予
定日を組み
直したか？

保存開始日、最終処
分予定日、最終処分
措置を設定

いいえ

はい

いいえ
終了

はい

終了
はい
最終処分措
置は廃棄
か？
最終処分保
留を設定し
たか？

いいえ

いいえ
すべてのコン
テンツは自動的に廃棄
されるか？

いいえ

最終処分確認日を設定

はい
はい

記録を保留として
マーク

最終処分を
確認した
か？

終了

いいえ

はい

はい

移動確認 最終処分
措置を廃棄に変更

はい

廃棄確認

いいえ

最終処分期限切れ
警報発動

はい

終了

はい

親集合により多くの現用エンティテ
ィがあるか？

いいえ

親集合は
閉鎖されて
いるか？

はい
集合廃棄

集合には親
があるか？

いいえ

はい
レビュー完了
新しい最終処分スケ
ジュールを適用

最終処分期限切れ警報が発
動したか？

いいえ

最終処分措
置は移動
か？
いいえ

記録、コンポーネント、
コンテンツを廃棄

はい

最終処分確
認日が到来
したか？

最終処分措
置はレビュ
ーか？

いいえ
終了

いいえ（廃棄の要あり）

図.8h 統合最終処分プロセスは MoReq2010®が提供する最終処分に係る全ての選択を表している。
8.2.12

サービスとしての最終処分スケジューリング

MoReq2010®は最終処分スケジューリングを MCRS が利用するサービスとして記述している。大部分の MCRS ソフトウェアはビルトイン最終処分スケジューリングサービスを持つ。しかし、将来
的には独立した最終処分スケジューリングサービスを作成することも可能である。これは複数の
MCRS ソリューションを通じた組織の最終処分スケジュールの集中管理を可能とする。こうしたサービスの一つの使用法は、インターネット上で利用でき、特定の部門で横断的に使用可能である
最終処分スケジューリングサービスとして産業全体の最終処分スケジュールのセットを、権限を有する機関が発行し維持管理するということである。

97
第１巻

コアサービス及びプラグインモジュール

第1 部 コアサービス
9．最終処分保留サービス

9.1

サービス情報サービス名

最終処分保留サービス

サービスバージョン

1.0

サービス識別子

2e4a8618-c4b3-470f-8ccb-03e2d5e07026（M14.4.42 参照）

9.2

主要概念

9.2.1 最終処分保留の実行
最終処分保留は現代の記録管理において重要かつ必要な部分である。最終処分保留は、法的又は他の行政上の命令であり、最終処分保留が行われている間、正常な最終処分プロセスに介入し、組織の記録の一部の廃棄を防止するものである。
MoReq2010®では、最終処分保留は MCRS 内部に最終処分保留サービスの一部として作成され、有効な最終処分保留は記録、集合、クラスのようなエンティティと関連している。
最終処分保留が個別記録と関連する場合、最終処分保留は有効なまま、記録の廃棄を防止する。
最終処分保留が廃棄された場合、記録の最終処分プロセスは継続する。
最終処分保留が全体として集合と関連する場合、それは集合の中のあらゆる記録や集合に由来する記録が廃棄されないようにする。保留がすでに集合と関連付けられた後は、集合に追加される新しい記録にも同じように適用される。しかし、保留された集合の外に移動した記録は最終処
分保留には関係しなくなる。ただし、保留が記録に個別に適用されている場合はこの限りでない。
最終処分保留がクラスと関連付けられている場合、保留はクラスによって分類された記録が廃棄されるのを妨げる。しかし、最終処分保留は保留された記録が最終処分保留に属さない異なる
クラスに再分類されることを妨げない。
9.2.2 最終処分保留の影響最終処分スケジューリングサービスに与える最終処分保留の影響は、8．廃棄スケジューリン
グサービスを参照のこと。最終処分保留は、最終処分プロセスを廃棄寸前に中断することによって、記録の廃棄を防止する。最終処分保留は、レビュー後の意思決定、記録の最終処分スケジュールにおける変更、MCRS によって記録が廃棄される寸前の記録移動を妨げない。
記録又は集合は複数の最終処分保留に同時に服することも考えられる。全ての関連する最終処
分保留は記録又は集合が廃棄される前に解除されなければならない。
9.2.3 最終処分保留の解除
最終処分保留は、記録等が廃棄されるまで、関連する記録や集合の廃棄を防ぐ。廃棄に至るこ
98
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービスとは、最終処分保留の「解除」と呼ばれる。
承認ユーザは保留された記録、集合、クラスの最終処分保留との関係を断つことが可能である。
しかし、この作業はこれらのエンティティ間の関係、誤って適用した最終処分保留、当事者が最終処分保留の範囲を狭めることへの合意を修正する目的においてのみ使用される。影響を与える
エンティティから最終処分保留を解除するには、通常のプロセスとして、最終処分保留を廃棄することが挙げられる。この場合、解除する時個別にエンティティを最終処分保留から分断する必要はない。連続した関係が有用な履歴情報を提供するであろう。
一度解除を実行すると、最終処分保留は廃棄され、残留処分保留となる。このプロセスを逆行することは不可能である。最終処分保留を誤って解除した場合、新たに最終処分保留を作成しなければならない。次に新たな最終処分保留を残留処分保留と関連していた同じエンティティと関連付けなければならない。この作業を行うまで、古い最終処分スケジュールと関連していた記録は最終処分プロセスで廃棄することはできない。
9.2.4 最終処分保留サービス
最終処分保留は、その適用範囲にある組織全体で行われ、法的及び財務的な罰則と負担を伴うことが多い。最終処分保留は組織の複数の異なる業務システムに保管されている情報と関連がある。
MoReq2010®のサービスベースアーキテクチャは組織の中の複数の記録管理システムによって共有される集中的な最終処分保留サービスの実行を可能にする。このようにして最終処分保留が集中的に作成、管理、及び解除され、同時に複数の MoReq2010®適合システムを通じて同時に適用さ
れる。

99
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

10．検索及び報告サービス

10.1

サービス情報
サービス名

検索及び報告サービス

サービスバージョン

1.0

サービス識別子F09984a5-dd31-44d8-9607-22521667c78a（M14.4.42 参照）

10.2

主要概念

10.2.1

発見

ユーザが MCRS 内部のエンティティを発見する方法は二つある。まず、ユーザが一つのエンテ
ィティから関連するエンティティをブラウズする方法である（例：親エンティティから子エンテ
ィティへ、集合からそのクラスへ、ユーザからグループへ、記録からそのコンポーネントへ）。
次に、ユーザが特定の検索クエリに一致するエンティティを検索する方法である。
経験上、検索は、多数のエンティティを持つ記録管理システムでの発見において遙かに拡張性のあるオプションであることが分かっている。一部の記録管理システムでは、ユーザがアクセス制御設定のためにブラウズによってアクセスできなくてもエンティティを発見することが可能である。例えば、ユーザが子エンティティを検査できるが、親エンティティはできないという場
合にこれが利用できる。この場合、アクセスできない親エンティティは、ユーザが子エンティテ
ィをブラウズにより検索する権限をブロックしている可能性がある。
しばしば、ユーザは、二つの方法を組み合わせる。まず、一般的な検索条件に合ったエンティ
ティを検索し、結果のエンティティの数が管理できる数に減少した後、さらにブラウズすることによって検索結果を絞り込むことが可能である。
MoReq2010®は、全ての記録管理システムがメタデータ要素の値に基づきエンティティを検索するための検索エンジンを有することを要求している。コア要件は、MCRS がユーザに記録コンテンツの中での検索能力を提供することを明記していない。しかし、多くの供給者はこの能力を記録
コンテンツのあるタイプに提供している。
MCRS を検索するための重要な非機能要件は、結果の一貫性と完全性である。これは特に記録管理環境で重要である。同じユーザが同じ検索を複数回行ったとき、下位データに変化がなければ、
MCRS は信頼性の高い方法でユーザに同じ検索結果のセットを同じ順番で提供しなければならな
い。

100
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
10.2.2 検索方法
MoReq2010®には、供給者による MCRS ソリューション内の検索に関する実装方法に関する指定はない。しかし、仕様で様々な方法の最低限のレベルのサポートを要求している。MCRS は下記のことが可能でなければならない。
・ イベントを含めて、システム又はコンテキストメタデータによってどんなエンティティタイプでも検索する。
・ システムとコンテキストメタデータを含めて、メタデータ要素定義のデータタイプに合った検索条件を定義する。
・ 全てのテキストメタデータ要素にわたって、一度入力した同一の検索用語を使った同時フルテキ
スト検索を実行する。
・ 指定メタデータ要素のための別の検索条件の組み合わせで検索する。
・ 複雑な検索を実施するため検索結果を結合する。
10.2.3 テキスト検索
MoReq2010®は、テキストベースドメタデータ要素の二つのタイプを区別する。
「テキスト形式」メタデー
タ要素はタイトル、説明及びコメントなど自然言語で表された情報又は説明的テキストを保存するためのものである。R2.4.28 の下では、テキストメタデータ要素には常に言語識別子が伴わなければならない。
他のメタデータ要素は、テキストベースの場合もあるが、特定の言語のコンテキストで単語や文を保存するためのものではない。その代わりに、識別子やコードなどを保存する。
MoReq2010®ではテキスト形式メタデータがフルテキスト検索で検索できることが必要である。フルテキ
スト検索とは、メタデータ要素の値の文字シーケンスによるものでなく、全ての単語による検索の意味である。Google のような現代のインターネット検索エンジンはフルテキスト検索の例である。
フルテキスト検索技術は非常に複雑になることがある。例えば、テキストの既知の言語に基づいて、別の綴り、異なる時制、多数の接尾辞や接頭辞に基づいて単語を発見する。MoReq2010®には、フルテキスト
検索に必要な高度化のレベルは指定されていない。しかし、メタデータ要素の言語がそのコンテンツとともに保存されていることを要求する。これによって、こうしたタイプの技術を適切な装備を備えた検索エンジンに適用することができる。
MCRS はテキストでないメタデータ要素を検索するための手段も提供しなければならない。これは、テキストベース又は数字、タイムスタンプ、他のエンティティの参照でもよい。
10.2.4 検索結果
ユーザは検索クエリに合致するエンティティを発見するために検索を行う。従って、検索結果は常にエンティティのリストとして表示される。MoReq2010®は、検索結果がユーザ設定可能なものであり、ユーザが検索結果のリストの中でどのようにエンティティを並べたら良いか、またリスト中のエンティティに属101
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
するメタデータ要素のどれを返すかを指定することができるようにすべきだとしている。
MoReq2010®は検索結果について特別のレイアウトを指定しない。しかし、検索結果は表フォーマットに忠実に、論理的に概念化される。ここで各エンティティは表の行を占有し、列は各エンティティに属する
様々なメタデータ要素の値を表す。この概念的レイアウトは図.10a に示した。しかし、繰返しになるが、MoReq2010®には、ユーザに検索結果を示すためのレイアウトは指定されていない。
メタデータ要素
エンティティ

識別子

タイトル

作成日

記述

非現用

図.10a どのように表示されようとも、検索結果のセットはエンティティのリスト及びユーザの定義した順番でそれらの選択されたメタデータとして、概念的に表示されている。
MCRS を検索する時、オリジナルクエリに一致する検索結果の総数は多数となる。そこで、MoReq2010®では、MCRS が検索結果の大規模なセットのページ付け等により分割するよう指定されている。ユーザには最初、全結果のサブセットだけが表示され、順に結果ページを要求することができる。
10.2.5 セキュリティ
検索結果はユーザに固有なもので、ユーザのアクセス制御設定に関連している。MCRS を検索するユーザ
は、調査のためアクセスを許されたエンティティのみ検索可能である。MoReq2010®は、ユーザが調査のためのアクセスを許されていないエンティティを含む検索結果を提供することを MCRS に対して認めていない。
フルにアクセスしたエンティティを検索及びブラウズしているユーザがエンティティを調査すると、時
折、ユーザがアクセスする権利を持たない他のエンティティへの識別子があることを発見してしまうことがある。これは親、子、又はその他の関連エンティティの可能性がある。例えば、記録に関連した最終処
分保留などが考えられる。こうしたことが発生した場合、MCRS は、ユーザがブラウズ、検索又は調査することにより、セカンドエンティティ又はそのメタデータのいずれかにアクセスできないようにしなければ
ならない。
102
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
可能であれば、エンティティは検索結果やブラウズしたリストに表示されないようにするべきである。
図.10a で示されているようなメタデータ表の列又は調査中のエンティティのメタデータにアクセスできないエンティティが当たり前のように現れる場合、MCRS はブランクスペースを残したり、そのタイトルを「未知のエンティティ」などの適当な表示と入替えしたりしてその存在を匿名化しなければならない。
10.2.6 保存された検索
ユーザは検索クエリを保存してもよい。それにより、ユーザはそれを後で利用することが可能になる。
こうしてユーザは同じ検索をもう一度実行することができ、前の検索条件を開始点として利用し、検索条件の新しいセットを作成することができる。
保存された検索は MoReq2010®によって管理されたエンティティとはみなされない。特定の MCRS に固有のものである。保存された検索に関係するエンティティタイプ定義やメタデータ要素のリストはない。保
存された検索を他の記録システムにエクスポートや移動したりすることは求められていない。
10.2.7 報告
MoReq2010®では MCRS が二つの異なるタイプの報告を行うことが要求されている。即ち、詳細報告と概略報告である。前述のように両タイプの報告は検索に関係がある。
詳細報告は通常検索を再現し、結果における各エンティティのためにメタデータのサブセットを返す単一検索クエリに基づいている。詳細報告は、通常、図.10a のような表レイアウトを取ることとなっている。
詳細報告は、検索とは異なり、すべての結果を共通の報告フォーマットの一つのドキュメントとして提供する。しかし、MoReq2010®には報告のフォーマットは指定されていない。
これに対して、概略報告は複数の検索クエリに基づいている。それらは各検索クエリのために結果のセットを返さない。むしろ、各検索クエリに一致する、発見されたエンティティの合計数を返す。詳細報告と同様に MoReq2010®には概略報告に特別な報告フォーマットは指定されていない。
10.2.8 保存された報告
保存された検索と同様に、報告定義は、一度構築されると保存可能である。それにより、報告定義は後で再実行することができるので、後の報告を構築する基礎として使用することができる。また、保存された検索と同じく、保存された報告は、エンティティタイプ定義に適合する必要が無く、他の記録システムに移動可能である。

103
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

11．エクスポートサービス

11.1 サービス情報
サービス名

エクスポートサービス

サービスバージョン

1.0

サービス識別子2777ab81-D57e-4aa4-9595-69459ec2dc1e（M14.4.42 参照）

11.2 主要概念
11.2.1 エクスポートの目的
MoReq2010®のエクスポートは、仕様に含まれ、MCRS 内部のエンティティを一般の XML データフォーマッ
トで十分に詳細記述可能な作業であり、メタデータ値、イベント履歴、アクセス制御及びコンテンツを保存し、別の MCRS に移動させることができる。
エクスポートと対をなす作業はインポートである。インポートの目的は、他の MCRS からエクスポートされた MoReq2010®フォーマットの XML データを取込むことである。これらの XML データは異なる MCRS に新しいエンティティを作成するために使用され、これにより従前の MCRS と同様にアクセスや管理を行うことが可能となる。
理想を言えば、エクスポートもインポートも、「ロスレス」な作業であるべきであり、エンティティからいかなる有意性、コンテンツ及びコンテキストを取り去らないようにするべきである。業務コンテキストを失わずに、MCRS からエンティティをエクスポートし他の MCRS にインポートする能力を、MoReq2010®では「相互運用性」の獲得と呼んでいる。
MCRS からエンティティをエクスポートする一般的な理由には、以下のようなものがある。
・ 移動 エンティティが異なるシステム、組織、又はアーカイブの管理下に再配置されることである。移動の多くは最終処分スケジュールに従ってその結果として実行される。8．最終処分スケジューリングサービスに記載の最終処分プロセスの一部である。
・ 移行 エンティティが組織内の一つの MCRS から別の MCRS の管理下に移ることである。オリジナ
ルの MCRS の交換、アップグレード、又は廃止に伴って生じることがある。
・ 二次ホスティング エンティティが日常的に一つ又は複数の二次（おそらく、読取り専用）シス
テムにコピーされることである。二次ホストがこのように定期的にアップデートされる場合、ソースシステムからは差分だけインポートすればよい。
・ 複製 MCRS のコンテンツの参照や安全確保のために、他の準拠記録管理システムに移動可能な非独占的かつ簡単に理解できる方法でコピーを供給する。MoReq2010®エクスポートサービスは、災害復旧サービスの一部である日常運用のバックアップを提供することを意図してもいないし最適化もされていないことに留意しなければならない。しかし、データが供給者のデータフォーマッ
トで作られ、それを作成したシステムにしか再保管できないシステムバックアップと異なり、エクスポートサービスは MCRS の全部又は一部のコピーを広く理解されている MoReq2010®XML フォー
104
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
マット化することを可能にする。
11.2.2 部分エクスポート
MoReq2010®エクスポートサービスは、欠損のないメタデータ、イベント履歴、アクセス制御及びコンテンツを持つ、完全なエンティティのエクスポートのために設定されている。MoReq2010®エクスポートサー
ビスからエンティティがエクスポートされる際には、そのエンティティのコンテキストを明らかにする他のエンティティの一部は、プレースホルダとしてエンティティと共にエクスポートされなければならない（11.2.7 エクスポートコンテンツ及びプレースホルダ参照）。これにより、エンティティの完全なコンテ
キストがシステムからシステムへと移される。ただし、上記の移動を確実に行うには、完全なデータのエクスポートサービスが必要である。
一部の記録管理システムは、それに加えてエクスポートの他のバリエーションが可能である。
そこでは、
MoReq2010®エクスポートサービスの要件の一部がサポートされている。これらのバリエーションには以下のものがある。
・ メタデータの一部のみ
・ イベント履歴におけるイベントの一部のみ
・ アクセス制御方法の一部のみ
・ 関連エンティティの一部のみ
エクスポートされるデータの整合性が不完全なため、MoReq2010®では、上記のアプローチを「部分エクスポート」の実行として記述している。本質的に、部分エクスポートは「ロスレス」とはいえず、「ロッシー」だからである。
部分エクスポートはある種の業務状況では適用性がある。例えば、外部当局への一時コピー又は記録のサマリーセットを提供する手段等である。
一般に、そういった例は適切な記録管理の実践に適していない。
エンティティのロスを伴う移動は、後になってその重要性が判明するかもしれない属性及び業務コンテキ
ストを失わせる可能性がある。特に長期間の場合、記録システム内部で保たれている情報の一貫性が保証できない。
こういった理由により、部分エクスポートは必須要件とされておらず、MoReq2010®との整合性は試験されない。しかし、数種類の部分エクスポートのフォームを製品の追加機能として提供する供給者があることは考えられる。また、MoReq2010®が提供するエクスポートデータフォーマットは XML ベースであるため、組織によっては後に XML 変換へ適用することによって、完全エクスポートから部分エクスポートを生成する場合も同様に考えられる。
MoReq2010®エクスポートサービスは、上記要件に定義されるように、コアサービスとの適合において必須の非常に重要な品質とみなされる。
11.2.3 XML の使用

105
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
MoReq2010®には、DLM フォーラム財団により公表・維持されている XML スキーマが付属している。このスキーマは、エクスポート及びインポートの事前条件（post-condition）としてデータを如何に記述するかを定義している。各 MCRS は、MoReq2010®拡張モジュールとプラグインが導入するコンテキストメタデー
タ要素とバリエーションについて、この定義に従ってキャプチャできるように、このスキーマを完全に実装していなければならない。
現在、MoReq2010®はエクスポートされるエンティティを XML データファイルへ書き込むこととエクスポ
ートサービスを定義している。しかしなから、エクスポートデータの XML データファイルへの書き込みは
少量のデータに適しており、以下の制約によって実用的には中規模又は大規模の MCRS 環境に拡張可能なソ
リューションとは見られていない。
・ 保管媒体の容量限界があるため、オペレーティングシステムはデータファイルサイズに制限を設けている。こういった理由から、大規模データは一つのデータファイルに書き込むことができな
いため、多くのデータファイルにわたって保存できるよう分割可能でなければならない。これに関する業界標準は存在していない。
・ 保管効率を上げるため、しばしば XML データファイルは圧縮される。XML 自体は標準化されている一方で、様々な圧縮アルゴリズムは標準化されていない。
・ XML データファイルは、一時的にでもどこかに保管されなければならない。その際、XML データフ
ァイルは、権限のないアクセス、事故による削除、改ざん等のセキュリティ上の脅威にさらされてしまう。
将来的には、より大きな MCRS ソリューションによって、数千、数万、数十万、さらには数百万の記録と関連エンティティを単一の安全なエクスポート/インポート作業で移動することが必要とされるであろう。
11.2.4 XML データストリーミング
前述の理由により、XML データファイルへのエクスポートは MCRS からのデータのエクスポート及びインポートに対する一時的ソリューションとみなされている。DLM フォーラム財団の MoReq 管理委員会は
MoReq2010®の将来のバージョンのエクスポートデータのためのストリーミングサポートオプションについて調査検討する予定である。
XML データストリームは XML データファイルと比べて以下の利点をがある。
・ ストリームは、必要に応じて一つ又は複数のデータファイルに捕捉可能であり、且つ固定された
データファイルサイズや物理的媒体の容量によって制限されない。
・ ストリームは、移動中のどの段階でも移動を中断・再開することができる。そのため、ストリー
ムは移動手段として堅牢といえる。
・ ストリームは、暗号化されたチャンネル間で送信することが可能でありシステム通信として安全性が高い。
・ ストリームは、データを移動する際、DVD 等のデータ移動用の物理的保管媒体を必要としない。DVD
106
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービスは紛失したり破損したりする恐れがあり、転送中に不法にコピーされる恐れがある。
・ ストリーミングは、リアルタイムに直接データを移動可能である。
結論として、ストリームデータ送信を遮断・妨害することは困難であり、リアルタイム通信の即時性とあいまって、ストリームによる転送記録の信頼性は高まっている。MoReq2010Ⓡエクスポートサービスに導入することのできる標準には、W3CEXI（効率的な XML 交換）規格がある。MoReq2010Ⓡの発表時、EXI はワ
ールドワイドウェブコンソーシアム(World Wide Web Consortium, W3C)の推奨事項ではなかったが、2009
年 12 月から推奨事項の候補となっている。
11.2.5 エンティティのインポート
MoReq2010®は、大規模で多目的な記録管理システムの実装及び小規模で単一目的のための記録管理シス
テムの実装のどちらの場合においても適切であるよう考慮されている。エクスポートは、MCRS によって提供されるコアサービスにおいて必要な部分であるが、それと対をなすインポートは仕様のコア要件ではない。これはインポートプロセスの複雑性を反映したためである。他の MCRS からデータをインポートするイ
ンポートサービスの実装は、データをエクスポートするだけのソリューションよりも高度なソリューションを必要とする。より高度なソリューションを構築しようとした結果、開発期間が長期化し、少なくともそうしたシステムが常識となるまでは末端消費者に高いコストを払わせてしまう可能性がある。同時に、
MoReq2010®に準拠した記録管理システムの数が減少することにつながる。
MoReq2010®は、その点で、全ての MCRS がエクスポートをサポートするよう指定し、記録管理システムに投入されたデータを誰も取り出せないという罠に陥らならないようにしている。だが、MoReq2010®は全ての MCRS が、インポートサービスに必ずしも備えなくてもよいように指定している。一部の特化したフロン
トラインの業務システムがインポート機能をサポートしないであろうが、その一方で、MCRS 供給者は、他の第 2 世代の MoReq2010®適合製品ついてはインポート機能を搭載するであろう。一般的に、そういったシステムは企業のミドルウェアより大型で汎用的な記録管理システムとなり、複数のフロントライン業務シ
ステムと統合し、それらをサポートするものとなる。この場合、MCRS の他のタイプよりもより早くインポート機能が必要となるだろう。
インポートサービスは MoReq2010®の拡張モジュールとして提供されるであろう。組織は、必要に応じてこの機能を指定することが可能である。
11.2.6 非準拠システムからのエクスポート
MoReq2010®準拠システムがより一般的になるにつれて、供給者はアダプターを作ってレガシーな情報シ
ステムの記録等のエンティティを MoReq2010®XML フォーマットにエクスポートすることを希望しはじめると思われる。これら旧式の非準拠システムは、MoReq2010®に準拠することのできる新バージョンにアップ
デートできない。しかし、システムを利用する組織は、元のシステムの供給者やサードパーティに対して、これらの記録管理システムのコンテンツを MCRS に移動するための移行ソリューションの提供を要望する
であろう。
107
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
一旦、記録とエンティティが MCRS に成功裏に移行又は再構築されると、全ての MCRS ソリューションはエクスポートサービスをサポートし、次世代記録システムに移動することが可能となるため、記録等は無期限に保持されるとも考えられる。
XML データフォーマットを提供する以外に、MoReq2010®には非準拠記録管理システムからの記録及びエンティティの移動に関するいかなる要件も定義されていない。各組織は個別に、レガシーシステムから記録とエンティティを抽出するためのライセンス又は開発された移行ツールの完全性及び正確性に留意しなければならない。
11.2.7 エクスポートコンテキスト及びプレースホルダ
MCRS におけるエンティティは十分に相互連携しており、各エンティティはコンテキストの中でエクスポートされなければならない。これは、一つのエンティティがエクスポートされる際、エンティティの情報と他の関連エンティティが共にエクスポートされることを意味している。
エクスポートの目的に関する各エンティティのフルコンテキストは以下の通り。
1. システムメタデータ要素とその値
2. コンテキストメタデータ要素とその値
3. メタデータ要素にあるシステム識別子により参照される関連エンティティ
4. 記録の最終処分スケジュールのような重要なエンティティ。ただし、メタデータ要素にあるシス
テム識別子により直接参照されるか否かを問わない。
5. 記録のコンポーネント、グループの中のユーザ、集合の中の記録のような格納されるエンティティ
6. エンティティのアクセス制御及びそのアクセス制御エントリー
7. 関連する重要エンティティのアクセス制御リスト及びそれらのアクセス制御エントリー
8. これらのアクセス制御エントリーで参照されるユーザ、グループ及びロール
9. エンティティのイベント履歴中のイベント
10. 各イベントに属するメタデータ要素が有するシステム識別子により参照されるエンティティ
コンテキストを有するエンティティを MCRS からエクスポートするには、
前述のリストにあるアイテム全部を、当該エンティティと共にエクスポートしなければならない。しかし、一部のアイテム、特に、３、４、６、７は、追加エンティティをエクスポートしなければならないことに留意のこと。もし、これらの関連するエンティティが前述のものと同じ規則で同様にエクスポートされると仮定すると、エクスポート
しなければならないエンティティは無限に増大するだろう。
これとは逆に、エクスポートするエンティティのセットに直接含まれない関連エンティティはコンテキ
ストを削減してエクスポートされる。これらのエンティティは前述のリストのうち以下の項目のみに含まれる。
1. システムメタデータ要素及びその値
108
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
4. 記録の最終処分スケジュールのような重要なエンティティ。ただし、メタデータ要素にあるシス
テム識別子により直接参照されるか否かを問わない。
6. エンティティのアクセス制御及びそのアクセス制御エントリー
7. 関連する重要エンティティのアクセス制御リスト及びそれらのアクセス制御エントリー
8. これらのアクセス制御エントリーで参照されるユーザ、グループ及ぶロール
完全なコンテキストと共にエクスポートされるエンティティは、「完全エクスポート」
として記述される。
削減したコンテキストとエクスポートされるエンティティは、「プレースホルダとしてエクスポート」されたと記述される。プレースホルダはコンテキストメタデータ、重要なエンティティを除く関連エンティテ
ィ及びイベント履歴を含まない。
エクスポートプレースホルダが有効なコンテキストを他のエンティティに提供しているうちは、そのプ
レースホルダは完全なエンティティとはみなされない。それら自体のコンテキストの一部が欠けているか
らである。それは、「生きた」エンティティというよりはむしろ特定の瞬間に採られた二次元のスナップシ
ョットである。
完全エクスポートされたエンティティは、別の MCRS でインポートでき、現用のエンティティとして管理できる。これに対し、MCRS がプレースホルダをインポートするとき、それは非現用のエンティティを作成する。
これは現用のエンティティでも残留エンティティでもない。
この非現用のエンティティについては、
MoReq2010® 501．インポートサービスのコンテキストと関連性があるのみである。インポートサービスは
MoReq2010®コアサービスの一部でもなく、コア要件の適合性を獲得するために実装する必要もない。
11.2.8 メタデータのエクスポート
各エンティティには、それと関連したメタデータ要素がある。あるものはシステムメタデータ要素であり、あるものはコンテキストメタデータ要素である。各メタデータ要素には、二つの重要な部分がある。
・ その関連するメタデータ要素定義
・ その値（又は複数の値）
メタデータ要素をエクスポートする際、システムメタデータ要素定義は、エクスポートされるデータに含まれていない。MoReq2010®によって指定されているため、MCRS のインポートは、前述の定義を前提としていると想定されている。従って、システムメタデータ要素は値としてのみエクスポートされる。
コンテキストメタデータ要素がエクスポートされる際には、対応するコンテキストメタデータ要素定義
をその値と共にエクスポートする必要がある。これにより、MCRS をインポートする際にメタデータ要素を「認識」できるのである。該当するコンテキストメタデータ要素定義は、必要に応じてプレースホルダとしてエクスポートされなければならない。
エンティティが完全エクスポートされる際は、そのシステムメタデータ値もそのコンテキストメタデー
タ値も、対応するコンテキストメタデータ要素定義もともにエクスポートされる。エンティティがプレー
スホルダとしてエクスポートされる際は、そのシステムメタデータ値のみをエクスポートする。
109
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
システムメタデータとコンテキストメタデータを含んでいる各データ要素は、次のうちのいずれかである。
・ テキスト値、数値、フラグ等の特定のデータタイプの値
・ MCRS の他のエンティティを参照するシステム識別子
メタデータ要素がデータタイプを含んでいる場合、その値はそのままエクスポートされる。しかし、メ
タデータ要素にシステム識別子が含まれる場合、参照するエンティティは、「関連エンティティ」として記述される。それが、コンテキストを与える関連エンティティ間の関係である。
エンティティが完全エクスポートされる場合、システムメタデータ又はコンテキストメタデータのいず
れかによって参照される関連エンティティは、プレースホルダとしてエクスポートされる。エンティティ
がプレースホルダとしてエクスポートされる際、そのシステムメタデータ値のみがエクスポートされ、それらの値が参照する関連エンティティはエクスポートされない。

11.2.9 重要エンティティのエクスポート
一部のエンティティは、エンティティのコンテキストを提供する上で、他のエンティティより重要とされる。MoReq2010®では、すべての関連エンティティが重要エンティティであるわけではなく、また全ての重要エンティティが関連エンティティであるわけではない。例えば、記録の最終処分スケジュールは非常に重要であるが、記録はそのクラスを親集合から継承してもよく、そのクラスから最終処分スケジュールを継承してもよい。従って、最終処分スケジュールは非常に重要であったとしても、記録に直接関係のあるエンティティではない。
クラスについては次のエンティティが重要とされる。
・ クラスの最終処分スケジュール
・ クラスと関係のある最終処分保留
集合については、次のエンティティが重要とされる。
・ 集合のクラス。継承されても直接集合に適用されてもよい。
・ 集合の親集合及び先祖集合。ルート集合を含む。
・ 集合と関わる最終処分保留
記録については、次のエンティティが重要とされる。
・ 記録のクラス。継承されても、記録に直接適用されてもよい。
・ 記録の最終処分スケジュール。そのクラスから継承されても、記録に直接適用されてもよい。
110
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
・ 記録の親集合及び先祖集合。ルート集合を含む。
・ 記録と関係のある最終処分保留
ユーザについては、下記のエンティティが重要とされる。
・ ユーザが属するグループ
図.11a に、記録についての重要なエンティティの一部を示す。

クラス

最終処分
スケジュール

ルート集合

集合

集合

記録

記録

記録

記録

記録

プレースホルダとしてエクスポート

記録

エクスポート対象

図.11a 記録のためのクラス、最終処分スケジュール、先祖集合などの重要なエンティティはプレース
ホルダとしてエクスポートされなければならない。
重要エンティティは非常に重要であるため、あるエンティティがプレースホルダとしてエクスポートされる際には、
その重要なエンティティもまたプレースホルダとして共にエクスポートしなければならない。
11.2.10 格納エンティティのエクスポート
一部のエンティティは他のエンティティを格納するとみなされる。これらは「格納」エンティティと呼ばれる。以下は格納エンティティの特徴である。

111
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
・ 記録の格納エンティティはコンポーネントである。
・ 集合の格納エンティティは子集合及び記録である。
・ グループの格納エンティティはユーザである。
・ テンプレートの格納エンティティはコンテキストメタデータ要素定義である。
・ 格納エンティティを持つエンティティが完全エクスポートされる場合、それらの格納エンティテ
ィもまた完全エクスポートされる。これは図.11b と図.11c に示されている。収容エンティティ
は決してプレースホルダとしてはエクスポートされない。
エンティティをプレースホルダとしてエクスポートする場合、その格納エンティティはエクスポートさ
れない。

クラス

ルート集合

集合

集合

記録

記録

記録

記録

記録

記録

プレースホルダとしてエクスポート

記録
エクスポート対象

コンポーネント
完全エクスポート

図.11b 格納エンティティが記録のコンポーネントである例。記録が全てエクスポートされる場合、コンポーネントもまた全てエクスポートされる。
すべての格納エンティティはいずれかの階層に流れ込みながら、完全エクスポートされなければならない。例えば、ルート集合が完全エクスポートされる場合、子集合も完全エクスポートされる。これらの子集合にある記録は完全エクスポートされ、これらの記録のコンポーネントも完全エクスポートされる。

112
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

エクスポート対象
ルート集合

集合

集合

記録

記録

記録

記録

プレースホルダとしてエクスポート記録

記録

記録

コンポーネント

完全エクスポート

図.11c 格納エンティティに関する別の事例として、子集合がある。全ての格納エンティティはそのま
まエクスポートされる。そのため、格納エンティティの格納エンティティは完全エクスポートされる。
あるエンティティが格納エンティティであるために、全てエクスポートされる場合、格納エンティティ
は当初からエクスポートされる予定のものであったエンティティと同じ効果をもたらす。全エンティティ
は完全エクスポートされ、格納エンティティに関係する重要エンティティもまたプレースホルダとしてエクスポートされる。図.11d を参照のこと。

113
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

エクスポート対象
ルート集合

クラス
集合

記録

記録

集合

記録

記録

プレースホルダとしてエクスポート

記録

記録

記録

クラス

コンポーネントクラス

完全エクスポート

図.11d 完全エクスポートされる格納エンティティとプレースホルダとしてエクスポートされる重要な
エンティティを示す。
11.2.11 アクセス制御リストのエクスポート
アクセス制御リストにはアクセス制御エントリーが格納されている。各エントリーは、一つ又は複数のロールを持った、特定のユーザやグループと関連付けられている。図.11e は、エンティティの典型的なアクセス制御リストである。
エンティティがプレースホルダとしてエクスポートされる際、それが含む情報へのアクセスを制御することもまた重要である。このため、MCRS は完全エクスポートされるエンティティ及びプレースホルダとしてエクスポートされるエンティティのアクセス制御リストをエクスポートしなければならない。
モデルロールサービスは、サービス、親エンティティ、クラスからのアクセス制御リストの継承をサポートするため、R4.5.11 に則り、MCRS は、エクスポートされるエンティティとプレースホルダに関するサービスのアクセス制御リストもエクスポートしなければならない。このように、エンティティの完全アクセス制御リストは、サービスの組み合わせや、プレースホルダとしてエクスポートされる親及びクラス等の重要なエンティティ、エクスポートされたエンティティ自体から、インポート時に組み立てることが可能となる。
完全エクスポートされたエンティティ又はプレースホルダエンティティのいずれについてであろうとも、
アクセス制御リストがエクスポートされるのであれば、アクセス制御リストによって参照される各エンテ
ィティもユーザ、グループ、ロールを含むプレースホルダとしてエクスポートされなければならない。
図.11f を参照のこと。

114
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
アクセス制御エントリー

ロール１

ユーザ X

ロール２

ロール４

ロール３

ロール４

グループ A

グループ B

アクセス制御リスト

図.11e 典型的なアクセス制御リスト：各アクセス制御エントリーはユーザ又はグループを一つ又は複数のロールと関連付ける。

ユーザ X

グループ A

グループ B
ロール４

ロール１

ロール２

ロール３

図.11f アクセス制御リストによって参照されるエンティティはすべてプレースホルダとしてエクスポ
ートされなければならない。
11.2.12 イベントのエクスポート
各エンティティのイベント履歴は、エンティティが参加しているイベントのセットから構成される。これらのイベントの各々に対して、他の参加エンティティや、様々な関連エンティティと関連するイベント
を参照するメタデータが存在している。
115
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
エンティティが完全エクスポートされる際、そのイベント履歴もエクスポートされる。このことは全てのイベントにエンティティが参加していたことを意味する。
イベントのメタデータをエクスポートに加え、全てのイベント関連エンティティはプレースホルダエンティティとしてエクスポートされるべきである。
エンティティがプレースホルダとしてエクスポートされる際、そのイベント履歴はエクスポートされな
い。エンティティが参加するイベントは、プレースホルダエンティティと共にエクスポートされることはない。
11.2.13 要約表のエクスポート
11.2.7 から 11.2.12 まで、MCRS におけるエクスポートの際、データセットを編集するために必要な事項を記載した。MCRS によって、ユーザが推薦するエンティティに始まり、関連エンティティのトレースや、
完全エクスポートするエンティティ、プレースホルダとしてエクスポートするエンティティ等が決定されなければならない。また、エクスポートとは、データの一貫したセットとなってなければならず、MCRS は
こういったデータをサービスによって編集し、複製を削除しなければならない。次の表は MCRS によるエク
スポートに関する決定事項をまとめたものである。

エクスポートするもの

完全エクスポートするエンティティ

プレースホルダ

システムメタデータ要素

値をエクスポート

値をエクスポート

コンテキストメタデータ要素

値をエクスポート

エクスポートしない

コンテキストメタデータ要素定義

プレースホルダとしてエクスポート

エクスポートしない

関連エンティティ（メタデータ要素により参照）

プレースホルダとしてエクスポート

エクスポートしない

重要エンティティ（記録のクラスなど）

プレースホルダとしてエクスポート

プレースホルダとしてエクスポート

収容エンティティ（集合の子エンティティなど）

完全エクスポート

エクスポートしない

アクセス制御リスト

値をエクスポート

値をエクスポート

アクセス制御エントリーにより参照されるエンティテ

プレースホルダとしてエクスポート

プレースホルダとしてエクスポィート

イベント及びそのメタデータ

値をエクスポート

エクスポートしない

イベントに関するエンティティ（メタデータにより参プレースホルダとしてエクスポート

エクスポートしない照）

11.2.14 エクスポートされないエンティティ
デフォルトでは、現用エンティティのみが MCRS からエクスポートされることとなっている。残留エンテ
ィティは通常エクスポートから除外されるが、エクスポートを行うユーザがオプションでエクスポートすることも考えられる。
10．検索及び報告サービスにおいて言及されている、保存された検索と報告は、MoReq2010®エンティテ
116
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
ィというよりもアプリケーション独自のオブジェクトとみなされる。本仕様では、それらのエクスポートに規定は設けられていない。
11.2.15 エクスポートのセキュリティ
ユーザは、調査を許可されていないエンティティを、完全エクスポートすることもプレースホルダとしてエクスポートすることもできない。MCRS は、エンティティが通常アクセス不能である時、ユーザによって MCRS からエンティティがエクスポートされることを認めてはならない。
MCRS において、ユーザが要求されたエンティティとそのプレースホルダをエクスポートする完全アクセスを持たない場合、エクスポートは実施不可能でなければならない。
11.2.16 エクスポートの完全性
MCRS ソリューションは様々なアーキテクチャの周囲に構築できる。仕様によれば様々なプロダクツがそれら自身のアクセス制御（4．モデルロールサービスを参照のこと。
）とコンテキストメタデータ定義（7．
モデルメタデータサービスを参照のこと。
）を実施することが許容されている。MoReq2010®もまた、異なるタイプのエンティティが厳密なサービスによって管理されている、サービスベースのアプローチを提供している。しかし、MoReq2010®はこのアプローチの使用を強制せず、各供給者は独自に MCRS の実行手法を選択することが可能である。これには単一の非モジュラーアプリケーションも含まれる。
前述のような自由度は、インポートサービス要件が実装されたどの MCRS でも利用可能であり、なおかつ理解可能な一般的なフォーマットに全てのデータがエクスポートする必要性とバランスが取られていなけ
ればならない。
つまり、エクスポートされるデータは常に以下の事後条件を満たしていなければならない。
・ MCRS ソリューションは、少なくともエクスポートされるデータにおいて、MoReq2010®に準拠した
アクセス制御リスト、アクセス制御エンティティ及びロールに従ってアクセス制御をエクスポー
トしなければならない。
・ MCRS ソリューションは、エクスポートされるデータにおいて、MoReq2010®に準拠したメタデータ
要素定義及びテンプレートに従ってシステム及びコンテキストメタデータをエクスポートしなけ
ればならない。
・ MCRS ソリューションは、少なくともエクスポートされるデータにおいて、エクスポートされるコ
ンテキストメタデータ要素定義に記述されていないカスタム、固有エンティティ、メタデータをエクスポートしてはならない
・ MCRS ソリューションは、少なくともエクスポートされるデータにおいて、固有グループ化された
エンティティをタイプ毎に個々のサービスにエクスポートしなければならない。
これらの要件のうち最後のものは、同一タイプのエンティティはグループ化され、サービスとしてエク
スポートされるというものだが、これはインポートサービスをサポートする MCRS ソリューションが複数の同じタイプのサービスをサポートできなければならないため、必要とされるのである。例えば、分類サー117
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
ビスを持つ MCRS であっても、分類サービスを別の MCRS からインポート可能である。インポートされた分類サービスは、それまでとは異なる分類体系構造を示すかもしれない（200．分類シリーズモジュールを参照のこと）。
MCRS が他の記録管理システムから分類サービスをインポートする際、その分類サービスの分類は、以下のいずれかの方法で行われている。即ち、独自の分類サービスでクラス毎にマッピングするか、元の記録システムからサービスが所属していた構造を反映した非現用クラスをインポートし管理するか、である。
これらのインポート方法を選択する能力によって、たとえエンティティがオリジナルの記録システムの通りに配置されていなくとも、インポートされるデータは、エンティティにおけるサービス属性を特定することが可能となる。
11.2.17 エクスポートプロセス
MCRS がエクスポートを行うごとに、
MCRS はエクスポートのためにエクスポート識別子を作成しなければならない。このエクスポート識別子は XML データと各エンティティのために作成されたエクスポートイベ
ントに含まれる（R2.4.16 参照）。単一のエクスポート作業の一部として同時にエクスポートされた全てのエンティティとプレースホルダには、同じエクスポート識別子が使われている。エクスポート識別子によって、ユーザは検索により任意のエクスポートイベントでどのエンティティが一緒にエクスポートされたか発見可能である。また、エクスポート識別子によって、インポートサービスはどのエンティティが単一の MCRS ソースから来たか追跡可能である。
それはちょうど時間の特定の瞬間を切り取るスナップショットのようなものである。
エンティティをエクスポートする時、すべての MCRS ソリューションは同一のエクスポートプロセスに従わなければならない。下記はエクスポートプロセスの概観である。
1. 上述のようにエクスポート識別子を作成する。
2. 各エンティティが完全エクスポートされるように、完全エクスポートされる関連エンティティ及びプレースホルダとしてエクスポートされる関連プレースホルダのリストを作成する。
3. エクスポートを開始し、MCRS に関する情報、適合するサービス、エクスポート識別子を含むヘッダー情報を書き出す。
4. 該当するサービスを順番にエクスポートし、各サービスの中で各エントリーのエクスポートを順番に実施する。プレースホルダのブロックをエクスポートし、各エンティティタイプごとのエン
ティティのブロックを完全エクスポートする。
5. 各エンティティがエクスポートされたら、エクスポートイベントを生成し、それをエンティティのイベント履歴に追加する。
6. エクスポートを完了する。
7. エクスポートが失敗・中断したりした時は、エラーを外部エラーログに書き出す（R2.4.7 を参照のこと。
）。
エクスポートするデータフォーマット及びエンティティ及びそのメタデータ要素をエクスポートする順
118
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
番は、MoReq2010®XML フォーマットのスキーマで決定される。
11.2.18 重複排除
エンティティをエクスポートする際は、MCRS はエクスポートする各関連エンティティがエクスポートされる際に、一度だけ含まれることを確認しなければならない。一つのエンティティが完全エクスポートされる場合、それは同じエクスポートでプレースホルダとしてエクスポートされるべきではない。多くのエンティティが同じエンティティを参照する場合、同じエンティティは何回参照されようとも、一回だけエクスポートするべきである。
11.2.19 一度エクスポートされたデータへのアクセス制限
エンティティが MCRS からエクスポートされる際、エクスポートされたエンティティは XML データのスト
リームに変換されるため、MCRS は通常の制御を実施することができない。このため、エクスポートサービ
スを使う組織が考慮すべき多数のセキュリティ問題が発生する。
・ エクスポートを行うユーザは、エクスポートに含まれる全てのエンティティにアクセスできることに留意しなければならない。ユーザは、MCRS でアクセス・検査できないエンティティをエクスポートすることはできない。
・ エクスポートとその情報内容を保護するために作業手順を整えなければならない。一度、MCRS からエクスポートされたら、エクスポートにより記述されるデータはシステムによって保護されず、
シンプルな XML フォーマットの中に存在する。組織は暗号化等の保護方法を検討すべきである。
・ XML データが読み取り可能なフォームである場合、安全に保管しなければならない。アクセスは
MCRS 内部でそれにアクセスできるユーザに限定されなければならない。
・ 機密データは対象記録管理システムにインポートしなければならない。対象記録管理システムの他のユーザが自動的にアクセスできないよう、インポートする MCRS が同時にその安全を確保しなければならない。このことは、ソース記録システムからのユーザ、グループ及びロールを含む
アクセス制御リストが対象記録システムでは尊重されないため、特に重要である。
MCRS 外にデータを長期間保管する場合は、これ以上の対策が必要である。できれば、特に機密データでは、XML エクスポートは一時的な保管にとどめ、移動が確認されたらできるだけ速かに削除するべきであ
る。

119
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス

12．非機能要件

12.1 主要概念
12.1.1 MoReq®の非機能要件
オリジナルの MoReq®が 2001 年に発表されて以来、非機能要件は常に MoReq®仕様の重要な部分であった。
非機能要件は記録管理システムの質的な側面を規定している。記録管理システムは必ずしも機能要件だけで明確化される訳ではない。
機能要件はシステムが必要とする特定の振る舞いに焦点を当てることが多い。
緊密に関係した環境、作業、インフラストラクチャー及び快適性要因に焦点を当てることはない。
その特性から、非機能要件は明確なものでなく、機能要件よりも主観的なものである。非機能要件は普遍的に適用可能な方法で規定することが難しく、説明が必要で、定量化、測定及び試験が困難である。
しかし、以前のバージョンの MoReq®の経験から、供給者と組織はしばしば重要かつ実際的な情報を仕様の非機能要件から引き出してきた。これは供給者が自らの製品の品質を高めるのに役立った。消費者組織
は自らの業務ニーズと環境に適合した記録管理システムを選択できた。MoReq2010®開発に向けた協議段階で協力者たちが非機能要件をカバーする仕様の一部を保持し増大させるという明白な選好を見せたことは興味深い。
12.1.2 MoReq2010®の機能要件及び非機能要件
要件の記述の中で仕様の純粋に機能的な側面と非機能的な側面との境界はしばしば主観的なものとなり明白に定義することは困難である。MoReq2010®はその非機能要件が機能要件とは異なる別の能力を充足するように意図的に設計されている。
MoReq2010®の二つのことなるタイプの要件の特徴は、次のように説明できるかもしれない。
機能要件
・ MoReq2010®の機能要件は閉じた言明で表されている。例えば、「MCRS は...しなければならない」、「MCRS は...してはならない」等
・ 各機能要件は MCRS が実行しなければならない一つ又は時には複数の明白な機能と直接関係がある
MoReq2010®のほとんどの機能要件は要件の更なる明確化を提供する論理的根拠を伴う・ 機能要件で記述される明白な機能は個別に特定でき、14.5 機能定義にリスト化されている。これらは MoReq2010®のアーキテクチャによって使用され、参照される。いずれもアクセス制御モデ
ル（4．モデルロールサービスを参照のこと。
）及びイベントモデル（2．システムサービスを参照のこと。
）に記載されている。MoReq2010®の機能要件は仕様に添付された試験枠組内の試験ケースとスクリプトで検証可能である。こうした認定試験センターによる製品や設備の機能要件に対する試験により DLM フォーラム財団から適合証明書を受領することができる。
非機能要件
・ MoReq2010®の非機能要件は MCRS の望ましい特性又は品質に関するものである。
120
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
・ MoReq2010®の各非機能要件の根拠、理由又は前提が最初にリスト化され、次に非機能要件が続く。
・ 各非機能要件は自由回答式質問又は選択回答式質問として表現されている。これらは MCRS ソリューションの供給者に向けられたものである。例えば、「どのように記録システムは...を確認しますか。
」又は「どのような条件を記録管理システムは生み出しましたか。
」等。
・ MoReq2010®は製品や設備が非機能要件に適合しているか否かという試験を要求しない。非機能要件
は試験の外で個別の組織によって評価されるかもしれないが、MoReq2010®試験には何の規則もない。
・ しかし、MoReq2010®の認定を受けるためには、各供給者は試験及び認証の評価前段階の一部として非機能要件に対する回答を文書化し提出しなければならない。なぜならそれらは試験に提出される製品やサービスに明確に関連しているからである（このプロセスは 12.2.4 非機能要件への対応に記載されている）。
12.1.3 非機能要件が対象とするもの
非機能要件は MCRS の以下の側面を考慮する。詳細は 12.3 記録管理システムの非機能側面に記載されている。各記録管理システムは以下の品質がなければならない。
。
・ 性能
・ 拡張性
・ 管理可能性・ ポータビリティ・セキュリティ・プライバシー・ 利用性
・ アクセシビリティ・ 信頼性
・ 復元可能性・ 保全性・ サポートされていること
・ 保証されていること
・ 適合性
MoReq2010®は、記録管理システムに必ずしもこれらの側面すべてを対象とした非機能要件の包括的且つ徹底的なリストを提供していない。多くの場合、これらは特定の組織、産業、システムタイプ、環境、立法、規制制度に固有のものである。それぞれの非機能要件の重要性は利害関係者によっても異なる。
12.1.4 非機能要件への対応
MoReq2010®仕様について製品と設備を認証する DLM フォーラム財団の手順は多数のステップを必要とする。製品又は設備の正式試験の前に、供給者は認証前プロセスを完了しなければならない。このプロセスの一部として、供給者は認証を受けるために提出する製品又は設備について記述しなければならない。即
121第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
ち、試験を受ける MoReq2010®のコアサービス及びモジュールのための機能及び非機能要件に対する詳細な回答文書を提出しなければならない。
このため、MoReq2010®の非機能要件は質問として表され、供給者は各製品又は設備についての各質問に文書で回答しなければならない。認定試験センターは次に、試験枠組を使って製品又は設備に対する
MoReq2010®の機能要件（それのみ）に関する試験を行う。
機能試験段階が成功裏に完了し、供給者の当初の回答に必要な修正を終えると、機能及び非機能要件に対する供給者の回答は試験結果、試験センターの推薦とともに完全な試験検証報告にまとめられる。様々な法的条件、MoReq 管理委員会による指定及び管理の下で、認証製品の試験検証報告書は DLM フォーラム
財団のメンバーによるアクセス及び閲覧が可能になっている。
従って、供給者の製品又は設備は、非機能要件が試験認定報告書に含まれていても、非機能要件に関しては、決して正式に試験がなされるわけではないが、供給者の非機能要件によって提出された質問に対する回答は重要な参考情報となる。供給者の回答は組織がその地域的、組織的必要性に適合しているか、市場で入手できる MoReq2010®認証ソリューションの幅を知るのに有益である。
非機能要件を認定プロセスに組み込むことは、正式には試験されなくとも、仕様の過去のバージョンにおいてを受け取られていた以上に、それらの重要性を強調し、MoReq2010®の下での検討における比重を増している。
12.1.5 非機能要件の試験
MoReq2010®試験枠組は記録管理システムの非機能側面に対して正式な試験項目を用意していない。しかし、非機能要件が経験的に試験されたり測定されたりしないと解釈すべきではない。多くの組織はこれを
地域評価基準に対する評価プロセスの一部として実施したいと思うかもしれない。
機能要件の試験とは異なり、記録システムが各個別基準でもって合格又は不合格になる場合は、非機能要件に対する適合又は非適合の評価はより主観的な行為となる。しばしばこれはスケール又は連続性の中で、記録管理システムに点数を与える結果となる。
例えば、非機能要件は記録管理システムが十分なユーザ向け文書を備えなければならないとしている。
これをどのように評価するか？ 「十分」とはどういった意味をもつ言葉であるか？ 各組織は自分自身でこれを判断しなければならない。
ユーザ向け文書の品質を評価する一つの方法は組織から抽出したサンプルグループに文書を与えてみることだ。彼らに評価を依頼し、様々な条件でシミュレーション試験としてそれを使用させる。次にそれを下記のような様々な規格にて評価させる。
・ 索引が付けられ、論理的に編成されていたか。
・ 該当部分を発見するのにどのくらいの時間がかかったか。
・ タスクを実行するのにどのくらいの助力が得られたか。
・ 文書に不備はなかったか。
・ 言葉遣いは適切か。専門用語を理解できたか。

122
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
その後、ユーザはユーザ向け文書化に関する経験を 5 段階リッカート尺度で等級付けするよう依頼されるかもしれない。下記に例を挙げる。
1. 使い物にならない、理解できない、欠落がある。
2. 悪い又はつぎはぎの文書である。
3. 一度該当部分を発見できれば、受け入れ可能であり、理解可能である。
4. 品質が良く、レイアウトもよく、索引も完備している。
5. 優れており、関連性があり、該当箇所を見つけやすく使、用に非常に便利である。
組織ユーザのパイロットグループでシステムを試し、彼らの回答を並べるこのプロセスは通常記録管理システムの「ユーザ受入試験」と呼ばれる。多数の評価アプローチの一つであり、下記のものが含まれる。
ただし、それに留まるものではない。
・ ユーザ受け入れ試験
・ セキュリティ/侵入試験
・ 負荷試験
・ ストレス試験・ 設備及び構成試験
・ 災害復旧試験・ 相互運用試験
・ 環境試験
また、記録管理システムの非機能側面は適応可能な場合、外部標準及び仕様に照らしても評価される。
例えば、情報セキュリティ標準 ISO/IEC27000 シリーズに対する評価（ISO/IEC27000：2009：情報技術－セキュリティ技術－情報セキュリティマネジメントシステム－概要及び用語）がある。各法域に適用される
地域的要件もある。例えば、英国では英国標準 BSI DISC PD0008 があり、これは電子的に保管される情報の法的有効性及び証拠性に関連しており、付属のワークブックにより、組織は各設備に対して独立して評価を実施することができる。
既に記載された該当する基準がある場合、それらはベンチマークを提供することが多い。これに照らして各製品及び設備が判定できる。あるいは、非機能要件の評価は絶対的であるよりも相対的であった方がよい。二つ又はそれ以上の記録管理システムを互いに比べるわけである。直接相対比較により、各非機能要件に照らして、どれが最も適合しているか判断するのである。
直接の観察及び評価から離れて、組織は MCRS ソリューションの非機能要件に対する供給者の回答を検証・判定してもよい。試験検証報告にも記載されているように、参照チェックを行い、すでに展開し、供給者のソリューションを使っている現存する設備の現場訪問を行う。他の同等の組織はしばしば非機能要件に対して有効な経験的データを提供することができる。例えば、・発生したサポート結果の数123
第１巻

コアサービス及びプラグインモジュール

第 1 部 コアサービス
・重大な問題への供給元の対応・必要とされるユーザ・トレーニングの量・特定の期間におけるシステム使用可能時間の割合
・製品アップグレードの頻度
・ユーザー・コミュニティにおける一般的な満足レベル
非機能的要件の評価や査定の際、組織によって考慮されている様々なステークホルダーのニーズは重要である。組織は、利用者とサービスに係る品質保証契約（SLA）を締結することによって、MoReq2010®の非機能要件においてパフォーマンスの適応するレベルを形式化することを希望するであろう。

124
第１巻

コアサービス及びプラグインモジュール