電⼦記録応⽤基盤に関する調査検討報告書 2012

別冊

電⼦記録マネジメント基盤システムの要件(100 要件)
電⼦記録応⽤基盤フォーラム（eRAP）

平成 25 年 3 ⽉

⼀般財団法⼈⽇本情報経済社会推進協会

目

次はじめに .................................................................................................................................... 1
記録管理 100 要件 ..................................................................................................................... 2
付録 1

主要概念と用語の解説 ............................................................................................... 12

1.1 主要概念 ........................................................................................................................ 12
1.1.1 記録と電子記録 ...................................................................................................... 12
1.1.2 信頼可能な記録 ...................................................................................................... 13
1.1.3 電子ファイル、サブファイル、ボリューム............................................................ 14
1.1.4 分類体系 ................................................................................................................. 15
1.1.5 クラス ..................................................................................................................... 16
1.1.6 電子記録管理システム（ERMS：Electronic Records Management System）.... 17
1.1.7 記録のキャプチャ ................................................................................................... 17
1.1.8 利用者と監理者の役割 ............................................................................................ 18
1.2 主要用語 ........................................................................................................................ 19
1.2.1 メタデータ（metadata） ....................................................................................... 20
1.2.2 記録（record） ....................................................................................................... 20
1.2.3 電子記録（electronic record） ............................................................................... 20
1.2.4 文書／ドキュメント（document） ........................................................................ 20
1.2.5 コンポーネント（component） ............................................................................. 21
1.2.6 ファイル（file） ..................................................................................................... 22
1.2.7 サブファイル（sub-file）....................................................................................... 22
1.2.8 ケース・ファイル（case file） .............................................................................. 22
1.2.9 ボリューム（volume） .......................................................................................... 23
付録 2

100 要件適用ガイド ................................................................................................... 24

2.1 必須要件 ........................................................................................................................ 24
2.2 組織の記録管理の成熟度に応じた要件選択 .................................................................. 25
2.2.1 成熟度モデル .......................................................................................................... 25
2.2.2

100 要件と成熟度モデルの関係 .............................................................................. 26

2.3 業務プロセス及び文書の類型に応じた要件選択 ........................................................... 27
参考文献 .................................................................................................................................. 38

-i-

はじめに
本別冊は、電子記録応用基盤フォーラム(eRAP)の活動成果である、電子記録管理システム基盤の要件(100 要件)をまとめたものである。
本 別 冊 で は 、 100 要 件 の 理 解 を 助 け る た め に 、 MoReq2(Model Requirements for the
management of electronic records) [1]仕様で定義される主要な概念と用語の解説を付録 1 として載せた。また、記録管理に関する組織の成熟度や記録の類型に応じて適切に 100 要件を適用するための参考として適用ガイドを付録 2 として載せた。

-1-

記録管理 100 要件
記録管理 100 要件は、記録管理が満たすべきベースラインとしての汎用的な要件として、MoReq2
で定義されている 794 要件のうち、必須要件を中心に関連する要件を統合し、100 要件に集約したものである。個々の要件は、分類、要件 No.、要件、MoReq2 の該当箇所、補足説明から構成され、分類は MoReq2 の分類を踏襲している。
従って、個別の電子記録管理システムに適用するには、その環境に応じた要件項目を取捨選択することが望ましい。電子記録管理システムは、単体の記録管理システムでもってその要件のすべてを満たしている必要はなく、他システムとの連携によって要件を満たすことも考慮すべきであるし、運用によってカバーすることも考慮すべきである。

-2-

表 1-1
No.
(a)

記録管理 100 要件

要件

MoReq2
の
該当箇所

補足説明

分類体系とファイル構成
分類体系の設定1

ファイルや記録を階層化されたクラスによる分類体系で表現できること※全てのクラス、ファイル、サブクラス、ボリュームにコンテンツとして何を含み、何を含まないかの説明（スコープノート）を入力できることが望ましい

3.1.4,
3.1.10分類体系:ファイルを構造的な方法で収集する表現方法。この構造はビジネス機能を反映している。共通用語(概念)での階層管理に必要不可欠。
クラス：分類階層中の任意の点からそれより下のすべてのファイルまでの階層(オブジェ
クト指向のクラスを指すものではない)。
ファイル：記録を収容する記録管理上の単位。IT の世界のファイルはコンポーネントと呼ぶ。
サブファイル：ファイルを目的別に分割したもの。
ボリューム：ファイル又はサブファイルを機械的に分割した単位。

2

分類体系の管理は監理者だけに許されるこ
と

3.1.5

監理者：システムそのものの監理者とシステムに登録された内容の管理者の二つの役割がある。前者をシステム監理者、後者をコンテンツ管理者と呼ぶ。本要件は、コンテンツ
管理者のみの変更権限として必要

3

分類体系の全て又は部分をインポートできること。分類体系をインポートするときは関連メタデータ、保持及び処分計画、監査証跡もインポートできること

3.1.12 ～3.1.13

システム更新など、システムの置き換え時に必要

4

分類体系の全てまたは部分をエクスポート
できることが望ましい。分類体系をエクスポートするときは監理者がエクスポートするメタデータを選べること。このとき監理者の選択で関連する保持及び処分計画、監査証跡もエクスポートできること

3.1.17 ～3.1.20

同上

5

別途規定される標準フォーマットでエクスポートすること

3.1.22

標準フォーマットは別途定義

6

分類体系の全て又は部分をコピーする場合
は関連メタデータ、全ての保持及び処分計
画を含むこと

3.1.23 ～3.1.24№4.5 と同様の意味

7

複数の分類体系が定義でき同時に使えること3.1.26

全社で管理する場合は複数の分類体系が必
要ファイルについては、必要と考える。クラス
については、詳細な定義化が必要と考える(たとえば、暫定ＰＪなどの場合は利用可能な期間の定めが必要など)。

クラスとファイル
8

クラス又はファイルのメタデータ内に、開始日（open）及び終了日（close）を格納す
ること

3.2.8

9

クラス又はファイルのメタデータ内に、新たなクラス、ファイル、サブファイル、ボ
リュームの作成日を格納すること

3.2.9

-3-

No.

要件

10

新たなクラス又はファイルを開始(open)したときはメタデータを継承すること。継承
したメタデータ値は許される範囲内で監理者が変更できること

MoReq2
の
該当箇所

補足説明

3.2.10 ～3.2.11

あると非常に便利な要件である。時系列でファイルを保持するためには有効な要件であ
る。

3.3.1

ファイルデータの整合性を保つためには、コ
ンテンツ管理者のアクセス権も必要

ボリュームとサブファイル
11

サブファイルやボリュームを監理者が作成できないようにも設定できること

12

新たなボリューム又はサブファイルを開始 3.3.9 ～したときは、開始日をメタデータに格納し、 3.3.10
上位集合のメタデータ値を継承することあると非常に便利な要件。時系列でファイルを保持するためには有効な要件分類体系の保守(b)

13

クラスの結合や分割ができること

3.4.1
3.4.3

14

再配置（別のクラス配下に付替え）や再分 3.4.11 ～類するとき、変更前の参照関係を保持する 3.4.12
こと（変更された体系に参照を付けること）
また、新たな親クラスからの継承ができる
こと

15

記録が再配置またはコピーされる時に監理者にメタデータとしてその理由の入力を要求すること

3.4.14

コンテンツ管理者の権限として必要

16

再配置又はコピー前の状態、及び再配置前のメタデータの値を記録すること

3.4.15 ～3.4.16

ファイル情報の履歴管理として必要

17

ユーザが関連ファイル間の相互参照を作成できることが望ましい

3.4.23

ただし、セキュリティ制約との調整が必要(本来閲覧権限が無い個人情報への参照作成
をしてはならない)

18

記録の重複なしに記録に対する複数エントリを作成できることが望ましい

3.4.24

時系列的に同名称のファイルの保持が必要な場合もある(第 1 回申請、第 2 回申請など)

19

ユーザはファイルや記録のコンテキスト（脈絡、たとえば属するクラス）を認識できること

3.4.27

セキュリティ制約との調整が必要(本来閲覧権限が無い個人情報への参照をしてはならない)

20

ファイルの検索用キーワードを変更するときは、変更前の状態の痕跡を履歴として残すとともに、監理者に理由の入力を求める
こと

3.4.28 ～3.4.29

コンテンツ管理者の要件として、必要識別され認証された認可(authorized)ユー
ザでない限りいかなる操作もできないこと

4.1.1

全組織で標準化した記録管理のためには必須要件操作やその時刻情報を自動的にキャプチャし格納した監査証跡を保持すること

4.2.1

ログ

～

コンテンツ管理者の権限として必要
変更前の参照と同時に、変更も可能とする必要がある。特に、組織分割や法律・社内規定の変更などの場合は、一括変更ではなく、個別判断を要することが多い。

コントロールとセキュリティ
アクセス
21
監査
22

-4-

No.

要件

MoReq2の該当箇所

23

監査証跡パラメタの変更、メタデータの変更、記録への注釈や変更、監理パラメタの変更が監査証跡に記録されること

4.2.5,
4.2.9 ～
4.2.11

ログ

24

アクセス制御の意図的違反行為をキャプチャし保存すること

4.2.16

ログ

補足説明

バックアップとリカバリ
25

自動バックアップを提供すること

4.3.1

大規模システムの場合、利用不可時間が無い
ように考慮することが必要

26

許可された監理者のみがリストア及びロー
ルフォワードできること

4.3.3,
4.3.5

全組織で標準化した記録管理のためには必
須要件

重要記録

(c)

27

重要記録を含むか重要記録として扱われるファイルや記録を監理者が表示できること。また、最早重要と扱われないファイルや記録を表示できること

4.4.1,
4.4.5

組織として、事前に重要情報としての定義化が必要

28

フルバックアップと重要バックアップの 2
つの独立した操作ができること

4.4.2№25 と同様の配慮が必要

保持と処分
保持及び処分計画
29

監理者のみが保持及び処分計画を作成し維持（含、修正）できること

5.1.1,
5.1.32

処分計画：保持期間満了時の処分計画。自動廃棄、承認後廃棄、移管、永久保存、満了時にレビュを実施して決定（レビュに提出）等を指定。
全組織で標準化された記録管理を管理・監査するためには必須要件

30

保持及び処分計画の変更履歴を改変できないよう維持すること

5.1.6

同上

31

保持及び処分計画の変更は直ちに適用されること。変更理由は保存すること

5.1.7
5.1.8

32

全てのクラス、ファイル、サブファイル、
ボリュームは 1 以上の保持及び処分計画をもつこと。
デフォルトの場合は上位階層の保持及び処分計画を継承すること※記録のタイプにデフォルトの保持及び処分計画を適用できることが望ましい

5,1,10,5.1.13,5.1.15

必須要件

33

保持及び処分計画は保有期間及びトリガ事
象または処分日、処分行為と理由を含むこと。処分行為として少なくとも永久保存、レビュに提出、自動廃棄、管理者承認後の廃棄、移管が許されること※保持及び処分計画は説明と業務規程を含
むことが望ましい5.1.19 ～5.1.21,5.1.24

上位については、参照機能の方が有効

-5-

～

同上

MoReq2
の
該当箇所

No.

要件

34

保持及び処分計画に従って保存期間が満了した場合は自動的に処分決定プロセスを起動すること。自動処理は監査ログをとり監理者に通知すること。レビュに提出の場合は監理者に自動的に通知すること

5.1.22,
5.1.29 ～5.1.30

データ管理者の要件として、必要35

監理者はレビュを委任することができること5.1.31

コンテンツ管理者要件としては必要だが、初期判断はユーザが行うことが一般的(ファイルごとの個別対応が必要)

36

許可されたユーザによる処分保留が許されること。処分保留の適用及び解除の場合はその日付、許可されたユーザの ID、理由を
キャプチャし保存すること

5.1.34,5.1.38

コンテンツ管理者は上位権限者にのみ、委譲できる

処分期間に入ることを管理者に知らせる

補足説明

処分のレビュ
37

計画が特定の期間に入ることを監理者に通
知すること

5.2.1

38

メタデータと計画情報によりレビュプロセ
スを支援すること※同じ記録のレンディション間のリンクを維持し処分行為を同時に行えること。レビ
ュワが、廃棄、移管、更なるレビュ、永久保存のマーク付けをできること※自動的にレビュ日のログが採れること

5.2.2
5.2.5

39

レビュ決定の理由を記録するためにレビュワ
がメタデータにコメントを入れられること

5.2.6

全組織で標準化された記録管理を管理・監査するためには必須要件

40

レビュ期間の理由を含むレビュワの決定の不変履歴を保持すること

5.2.7

同上

～

レンディション：例えば、同じ内容の PDF
文書と HTML 文書
同じ記録のレンディション間のリンクを維持しながらの管理（難易度大）移管、エクスポート、廃棄41

記録をエクスポートできること。記録を移管またはエクスポートする場合は全てのコンポーネントの関係を維持したまま移管またはエクスポートすること

5.3.2

電磁的記録を公文書館へ移管する場合は必要42

他のシステム又は他の組織に記録と関連メ
タデータと監査証跡情報を移管する定義されたプロセスを提供すること

5.3.3

基幹システムとの連携を図ることが前提の場合、ファイル保管のシステムが複数存在することのリスク検証が必要

43

エクスポートするメタデータ、監査証跡は選択できること。エクスポートまたは移管する場合はインプリシットなメタデータを
含むこと

5.3.5
5.3.6

～

文書管理機能を有するシステムを複数保持することについてのリスク検討が必要。次期システムへの移行時等には必要な要件(№3.4.5 と関連)

44

エクスポート又は移管先システムでの再適用のために、記録と一緒に保持及び処分計
画、アクセスコントロールをエクスポート
または移管すること

5.3.7
5.3.8

～

文書管理システム単独の要件ではない

45

ポインタではなく完全な記録をエクスポー
トまたは移管すること。記録はキャプチャ
時のフォーマット及びレンダリングされた
フォーマットでエクスポート又は移管でき
ること

5.3.10 ～5.3.12-6-原則。完全な記録のエクスポート及び移管に対するリスク想定が必要。データ管理者以上の権限者による、選択・修正機能は必要（たとえば、部門横断でのエクスポートや移管の際、表現の整合や統一をはかる場合もある）。

(d)MoReq2
の
該当箇所

No.

要件

46

記録が廃棄されるときは全てのレンディシ
ョンも廃棄されること

5.3.18e-Discovery 対応では要求される要件

47

廃棄または移管されたクラス、ファイル、
サブファイル、ボリューム、記録のメタデータスタブを保存できることが望ましい。
メタデータスタブは少なくとも廃棄日または移管日、分類コード、タイトル、説明、
廃棄または移管理由、参照を含むこと

5.3.19 ～5.3.20

スタブ：記録廃棄の痕跡（各レンディションに要求さる廃棄期限管理と整合を取ることが難しい）

補足説明

全組織で標準化した記録管理のためには必須要件

キャプチャ及び記録の宣言
キャプチャ
48

キャプチャプロセスはユーザに、記録のキ 6.1.1
ャプチャ、分類体系への関連付け、ファイルと関連付けられた記録のためのコントロールと機能を提供すること※対象はデスクトップ AP 出力（オフィス）、
e メール、音声、DB、PDF、ビデオ、Web
ページ、blog、ソースコード、構造化デー
タ（EDI)、Wiki 等

49

キャプチャする記録が複数コンポーネントで構成されるときは関連を保存し 1 単位として管理すること※保存や表示に必要なら一部をモディファ
イ（例えば、HTML ページのリンク先のグ
ラフィックを取り込む）できることが望ま
しい

6.1.4
6.1.5

50

キャプチャ時に記録内の参照を変更する場
合は、監査証跡に自動的に記録されること

6.1.6

必須機能

51

各コンポーネントのファイルフォーマッ
ト、バージョンは自動的にキャプチャしメ
タデータに格納する

6.1.7

必須機能

52

メタデータ要素の幾つかの値は承認されたユーザと監理者のみが更新できる

6.1.15

承認されたユーザ（コンテンツ管理者）による権限制限が必要

53

記録はキャプチャされたときに適切なクラス又はファイルに割り当てられること

6.1.16

必須機能

54

特定のファイル（フォルダ）にドロップされた記録に属性を自動付与することが望ましい－必須機能。特に有効である。

55

記録のキャプチャ日時がメタデータ及び監査証跡として記録されること。自動キャプ
チャできないメタデータ入力をユーザに促すこと

6.1.19,6.1.22

記録管理上、メタデータの入力を促す機能があると望ましい。

56

クラス、ファイル、サブファイル、記録の複数キーワード又は語彙の割り付けを支援すること

6.1.23

辞書機能なども考慮する必要がある。

57

制御された語彙から選ばれるキーワード値
及び他のメタデータ要素値を提供すること

6.1.28

辞書機能なども考慮する必要がある。

-7-

全組織で標準化した記録管理のためには必須要件～

MoReq2
の
該当箇所

No.

要件

58

キャプチャ時又はそれ以降にも追加の記述などのメタデータ登録ができること。監理者や権限を与えられたユーザが記録のタイ
トルを修正する余地があること※（組織の Op.）

6.1.29,6.1.31

原則、権限を与えられたユーザ（コンテンツ管理者）のみの権限とする必要がある。

59

複数バージョンの文書をキャプチャした場
合は全てを 1 記録とする、1 つを特定、全て別の記録とするかを選べること

6.1.32

ただし、データ管理者以上の権限者での選択が必要

60

監理者はクローズしたボリュームに（クローズ以前の日付がある）記録を追加できること。この時、例外理由がメタデータに追記されると共に監査証跡に自動記録される
こと

6.1.41

完結したボリュームに対する変更の記録は、全組織で標準化された記録管理を管理・監査するためには必須要件

補足説明

バルクインポート
61

記録のバルクインポートを実行すること

6.2.1

メタデータ構造の標準化が前提

62

他のシステムで生成された取引記録をキャ
プチャできること（バッチファイルなど）

6.2.2

同上

63

バルクインポートの間に関連記録のメタデータを自動キャプチャできること。キャプ
チャしたメタデータはルールを使って検証
すること

6.2.3
6.2.4

～

同上

64

インポートされた記録の履歴を表す監査証
跡記録をインポートすること。監査証跡記録をその監査証跡にインポートしないこと（別々に格納）

6.2.5
6.2.6

～

同上

e-メール管理65

出入りする E メールキャプチャ時自動的に 6.3.5
メタデータ（日付、受信者、主題、送信者、署名など）を抽出すること

メールは通信手段としての活用に専念すべきとの考えもある

66

ユーザがドラッグによって E メールをサブ
ファイル、ファイル、クラスにキャプチャ
できることが望ましい

6.3.6

コミュニケーション記録としての保管は必要だが、運用ルールを確実にしないと、情報が混乱するリスクと、ウイルス感染などのリ
スクも高い

67

添付を別の記録としてキャプチャする場合
はメタデータ値のキャプチャ又は入力を要
求すること

6.3.9

添付資料をキャプチャする場合に、メールとの関連などのメタ情報のキャプチャまたは入力が求められることが望ましい

68

プロプラエタリフォーマットでキャプチャ
した E メールメッセージをオープンフォー
マットで格納できること

6.3.17№65 と同様

記録タイプ
69

記録タイプを定義しメンテナンスすること※記録タイプは、記録の特性（メタデータ
属性、保存要件、アクセス制御、文書の種類など）によって特徴付けられる

6.4.1

記録管理の要件として、必要70全ての記録は 1 つの記録タイプをもつこと

6.4.2

全組織で標準化した記録管理のためには必
須要件

-8-

No.

要件

MoReq2
の
該当箇所

補足説明

スキャニング及びイメージング

(e)

71

少なくとも 1 つのスキャニングソリューシ
ョンとの統合が可能なこと

6.5.1

入手手段をスキャニングとした場合、スキャ
ニングデータが原本と同等のものとなる。このデータが重要な記録の場合は、タイムスタ
ンプなども含めて記録化することが必要

72

OCR 機能をもつときスキャンイメージとOCR 結果のテキストは 1 つの記録として管
理すること

6.5.8

全組織で標準化した記録管理のためには必須要件

73

イメージの注釈、注釈者、日付は記録として保持され変更と削除から保護されること

6.5.16 ～6.5.17

電子化データの安全性確保のためには必須
要件

7.1.1
7.1.2

№17 と同様。ただし、セキュリティ制約との調整が必要(本来閲覧権限が無い個人情報
への参照作成をしてはならない)。

参照
分類コード
74

クラス、ファイル、サブファイル、ボリュ
ーム、記録、コンポーネントに分類体系の階層内でユニークな分類コードを関連付けること～システム ID75(f)

分類コード、クラス、ファイル、サブファ 7.2.1,
イル、ボリューム、記録、レンディション、 7.2.4
保持及び処分計画、文書に対してグローバ
ルにユニークなシステム ID（UUID）を生成すること

全組織で標準化した記録管理のためには必
須要件

検索、取り出し、及び表示
検索及び取り出し(g)76

アクセスが制限されているユーザにはいかなる情報も暴露しないこと

8.1.1

全組織で標準化した記録管理のためには必須要件

77

記録やファイル、関連メタデータ（含、署名情報）を検索し取り出し、また表示でき
ること。

8.2.2

全組織で標準化した記録管理のためには必
須要件

77
a

検索は、全文検索および属性検索が可能なこと-

全文検索によるリスク(定型業務におけるノイズの増加)を考える必要がある
また、キーワード変更を制限する必要がある

78

オリジナルフォーマットとは別のフォーマット（レンディション）を表示できること－

システムの利用目的により、必要機能か否かの判断が必要監理上の機能一般監理
79

コンフィグ時に設定した値を監理者が再設定できること9.1.1

システム管理者要件として必要

80

ユーザと役割に対して監理者が機能を割り当てできること

9.1.2

同上

-9-

No.

要件

MoReq2
の
該当箇所

補足説明

報告
81

監理者が定期的又は臨時の報告書を作成できるようにすること※処分計画の成功及び失敗の結果、エクス
ポート処理の結果、処分作業、アクセス制
御への試みやセキュリティポリシ違反行
為、移管、エクスポート、破棄、消去の失敗の詳細、インポート時の失敗の詳細など

9.2.1,9.2.
20～
9.2.22,9.2.24,
9.2.03 ～9.2.31

ログ採取が前提。違法・不適切行為の監視は不可欠

変更、削除、及びリダクション（墨塗り）

(h)

82

一旦キャプチャした記録を削除又は移動できないオプションをもてること。
※監理者が削除した記録はメタデータにマークされ記録内容とメタデータは隠され監
査証跡に記録されること

9.3.1,
9.3.3

厳格なデータ管理が必要な場合は必要

83

削除を破棄、移動を再構成とする代替をコ
ンフィグオプションとしてもてること※メタデータもメタデータスタブを除いて削除される

9.3.2,
9.3.4

データ管理者の要件として必要

84

監理者は処分プロセスの外でクラス、ファイル、サブファイル、記録を削除できるこ
と

9.3.5

処分プロセス外で削除が許されるケースのみ可

85

利用者は削除候補のクラス、ファイル、サ
ブファイル、ボリューム、記録をマークで
きること

9.3.6

同上

86

削除事象では削除を監査証跡に記録し監理者への報告を作成しコンテンツを削除し変更なら削除せず又他のファイルとのリンク
をハイライトしメタデータの完全性を維持
すること

9.3.7

特に、むやみな削除を防止する要件はあると
望ましい。

87

監理者はユーザが入力したメタデータ要素を変更できること。メタデータ要素への変
更は監査証跡に格納されること

9.3.8
9.3.9

～

システム管理者の要件として必要。ただし証跡を遺すなどの管理が必要。

88

監理者は、オリジナル記録が保存されている間に 1 以上のリダクションを作成できること。また、組織の要請でリダクション内の機微情報を削除又は隠すことができること9.3.10 ～9.3.11

情報公開法に基づく請求に対して、電磁的記録で対応する場合は不可欠。

89

リダクションを作成した時は記録とリダク
ション内のメタデータに作成、日時、作成者、作成理由を格納すること※リダクションにオリジナルとの相互参照を格納することが望ましい

9.3.12,9.3.17

情報公開法に基づく請求に対して、電磁的記録で対応する場合を考慮するとあると望ましい。

10.1.1

紙の文書管理をシステム上で行う場合は必
須要件

オプション
物理的ファイル及び記録の管理
90

物理的コンテナ（バインダーなど）として存在するクラスやファイルを監理者が識別できること- 10 -

MoReq2
の
該当箇所

No.

要件

91

監理者やユーザが物理的コンテナとしてのクラスやファイルのメタデータの入力や保守ができること10.1.2

同上

92

場所、保管者、日付のログによるチェック
イン/アウトで物理コンテナと記録の追跡を支援することが望ましい

10.1.9同上

10.2.4運用での対応可

補足説明

物理記録の処分
93

移管、エクスポート、廃棄を管理上完了させる前に物理的な移管、エクスポート、廃棄を確認すること

文書管理及び共同作業
94

文書と記録を同じ分類体系且つ同じアクセス制御下で監理することが望ましい
この場合、文書と記録を明確に表示すること10.3.1 ～10.3.2

95

記録の内容をコピーし新たな文書を生成できること

10.3.7

ケースワーク96

ケースワーククラス及び非ケースワークク
ラスの為に異なるアクセス許可をもつケースワーカー（ケースファイルの生成・利用者）の役割を構成できること

10.5.1

データ管理者の要件として必要

97

ケースファイルは特有のメタデータ要素で構成されること

10.5.13

ケースファイルの活用が前提

98

分類コードの替わりにケースファイル ID
により取り出しや実行など正当なアクションがとれること

10.5.14

ケースファイルの活用が前提

電子署名
99

キャプチャ時に電子署名と証明書をキャプチャし必要なら検証し保存できること。保
存に際しては、長期署名措置が可能なこと

10.7.1,
11.7.8

電子文書を、法的証拠能力を有するものとして活用する場合は、重要な要件

100

電子署名された記録の検証メタデータを保存すること

10.7.3

同上

101

エクスポート又は移管処理の間のファイ
ル、記録、移管メッセージに第三者検証可
能な電子署名を適用できることが望ましい

10.7.9

同上- 11 -

付録 1

主要概念と用語の解説

以下では、MoReq2 仕様で定義される主要概念と用語の解説を行う。文中の斜体表記の用語は、付録で解説されていることを意味している。
〔主要概念〕
・記録と電子記録
・信頼可能な記録
・電子ファイル、サブファイル、ボリューム・分類体系 (classification)
・クラス (class)
・ERMS
・記録のキャプチャ (capture)
・利用者の役割〔主要用語〕
・メタデータ（metadata）
・記録（record）
・電子記録（electronic record）
・文書／ドキュメント（document）
・コンポーネント（component）
・ファイル（file）
・サブファイル（sub-file)・ケース・ファイル（case file）
・ボリューム（volume）

1.1

主要概念

1.1.1 記録と電子記録
記録は以下から構成されると見ることができる。
・コンテント・構造・コンテクスト・表示
コンテントは、記録のメッセージ（情報提供の内容）を伝達する、1 つまたは複数の物理的ま
たは電子的（またはその両方の）ドキュメントに存在している。ドキュメントは、将来の利用者
がドキュメントとそのコンテクストを理解できるような形で保存される。このような視点からは、十分に管理された記録とは、ドキュメントのコンテントに加えて、構造に関する情報、及びコンテクストに関する情報を提供するメタデータ、並びに利用者への表示から構成されることが示唆される。
- 12 -

しかし MoReq2 では、記録という用語はメタデータを持たない情報提供の内容、すなわち記録を構成するドキュメントを意味するために使っている。表示は、記録のコンテント、構造、及び（電子記録の場合に）提示のためのソフトウェアとの組み合わせに依存している。
物理的記録の世界では、大多数の記録は紙の上にあって、ファイルに収められている。ファイルは記録の 1 つまたは複数のボリュームから物理的に構成され、紙のフォルダに入れられている。手続き的管理によって、利用者が記録やファイル内でのその位置を変更することを防ぐ必要がある。
同様の概念が電子記録にも適用される。記録は、1 つまたは複数の電子ドキュメントから構成されている。これらのドキュメントはワープロ文書、電子メール・メッセージ、表計算シート、
動画や静止画、音声ファイル、その他のデジタル・オブジェクトのことがある。ドキュメント
は取り込まれたとき、つまり ERMS に『キャプチャ』されたときに記録となる。キャプチャに際して記録は「分類」され、つまり属する分類体系のクラスに相応したコードが付加されて、ERMS による管理が可能となる。一般に、記録はファイルに対応付けられるが、次のようにそうでない場合もある。
保存を目的とした場合に、電子記録はしばしば複数のコンポーネントから構成されるという認識が必要になる。記録管理の『ファイル』と混同する可能性をなくすため、MoReq2 では IT
用語の『ファイル』を避けて『コンポーネント』という用語を使用している点に注意が必要である。
各コンポーネントはコンピュータのオペレーティング・システムが管理するオブジェクトであり、異なった形式のこともある。しかし、記録を構成するためには全部がそろって必要になる。また、すべての記録が複数のコンポーネントを持つわけではない。たとえば、多くのワープロ文書は 1 つのコンポーネントからだけ構成されている。複数のコンポーネントを持つ記録としては、テキスト、グラフィック、スタイルシートを伴ったウェブページの例がある。ウェブ
ページが 1 つの HTML コンポーネント、多数の JPEG 画像コンポーネント、少数の CSS（Cascading Style Sheet）コンポーネントを含んでいることは珍しくない。
記録に必要不可欠な特性は、その情報提供内容が固定されていることである。その帰結として、コンポーネント間の関係を損なういかなる行為も、電子記録上で行うことは許されない。
言い換えると、電子記録上で行うすべての行為は、その全コンポーネント間の正しい関係性を保つものでなければならない。そのため、たとえばどの記録でもそれを移動したりコピーした
りする場合には、全コンポーネント及びそれらの全関係性を保つ方法で移動またはコピーしなければならない。
1.1.2 信頼可能な記録
ISO 15489 では、「信頼可能な記録」とは以下のような特性を持った記録として説明されてい
る。
・真正性
・信頼性
・完全性
・利用可能性- 13 -

ISO 15489 が説明するように、すべての記録管理システムは、それに保存された記録が信頼可能であることの保証を目的とする必要がある。
要約すると、信頼可能な記録は次の機能を持たなければならない。
・それが主張する内容であることを証明できる
・それを作成あるいは送信したと主張する人物によって作成あるいは送信されたことを証明できる
・主張される時間に作成あるいは送信されたことを証明できる
・それが証明しようとする取引、行為、事実の十分で正確な表現として、その内容が信頼可能なために依存できる・完全であり改ざんされていない
・検索、取り出し、表示、解釈が可能である
MoReq2 が示す要件は、MoReq2 準拠 ERMS に保存された記録が信頼可能であることを保証するように設計されている。しかし、これらの要件に適合することだけでは十分でなく、企業
ポリシの存在と、それへの準拠も必要になる。
1.1.3 電子ファイル、サブファイル、ボリューム
紙の記録は一般に紙のフォルダに収容することにより、物理的なファイルに蓄積される。このような紙ファイルが、ある構造、あるいは分類体系へと収集される。ERMS では、あたかも電子的なファイルに蓄積し電子的なフォルダに収容するようにして、電子記録の管理を行うことができる。厳密には、電子的なファイル及びフォルダは実際の存在である必要はない。これらは、実際には何も「収容」しないという意味で仮想であり、事実上は記録に付与されたメタデータ要素によって構成されている。更に、多くの場合に電子システムにおいて、ファイルとフォルダを実際に区別する必要もない。しかし一般に、このような詳細は ERMS の利用者には見えない。ERMS のアプリケーション・ソフトウェアによって、利用者は、論理的にファイルに割り当てられたドキュメントを物理的に収容するかのようにフォルダを見て、管理することができる。このような利用者中心の視点が、MoReq2 では推進されている。従って、理解しやすい
ように MoReq2 では、記録を「収容している」ものとして電子ファイルを説明している。しかし、
MoReq2 は電子ファイル管理の機能的要件を提供するものの、電子ファイルの概念の実装方法を規定するものではない。
状況によって、ファイルをサブファイルに分割するのが有用なことがある。ファイルのサブ

ファイルへの分割は「知的な」分割であり、（一般に）記録をどのサブファイルへ保存するべきか決めるための、人間による入力が必要になる。サブファイルは、ほとんどの場合にケース処理の環境で使用される。たとえば土地販売に関するファイルで、販売にかかわるそれぞれのビ
ジネス活動（広告、契約、弁護士との交渉など）に対してサブファイルを持つ。
従ってサブファイルは、コンテントのタイプによるファイルの分割である。その結果、ファイル内の一連の記録に対して異なった保存・廃棄のスケジュールを適用可能なようにして、サブファイルを使用できる。
サブファイルを使用するかどうかにかかわらず、ファイルを所定の慣例に従ってファイル・
ボリュームへと「機械的に」分割する場合もある。この「機械的に」という語は、「ファイルの- 14 -

知的な内容ではなくサイズ、収容されている記録の数、時間間隔などにもとづいて」、それらの慣例の単純な順守を示唆している。このような方法は、処理しやすいサイズや重さに制限するという、紙ファイルの場合に起因している。電子ファイルの場合でも、評価や転送などの取り扱いを目的に処理しやすい大きさに制限するなど、この方法を継続できることがある。特に、長期間にわたってオープンされる場合や、収容する記録数が多くなる場合があるようなファイル管理では、この方法が適切になる。
ファイルとファイル・ボリュームとの区別は明白だが、その意味合いはそれほど明確ではない。これは、ファイルのボリュームへの分割を選択する意味合いは、実装のニーズによって異なるからである。
この相違は以下のように発生する。
・ファイルによっては一定期間のうちにクローズされるため、管理目的に使用される単位はファイルとなる（いくつかのボリュームがファイルを構成していても）。たとえば特定の小規模な調達、1 プロジェクトのためのファイルなど・ファイルによっては無期限の（あるいはほとんど無期限の）ライフスパンを持つため、管理目的に使用される単位はボリュームとなる。たとえば、地理的領域に関する記録のファイ
ル、ポリシなど時間が問題にならない主題を扱うファイル、毎年新たなボリュームが開始される送り状ファイルなど
以下にクラス、ファイル、サブファイル、ボリューム、記録、コンポーネントの関係を図示
する。

図 1-1

分類体系とファイル構成

1.1.4 分類体系
記録管理はファイルを構造的な方法で収集するが、優れたプラクティスは、この構造がビジネス機能を反映すべきことを示唆している。このような収集の表現が「分類体系」と呼ばれる。
分類体系は一般に階層構造を持っており、MoReq2 では、この階層ビューに焦点を当てている。
その他のアプローチは MoReq2 のスコープ外であり、階層的配置は MoReq2 準拠のための必須条件となっている。
実際には記録の集合であるにもかかわらず、ファイルが存在するかのように見えるのと同様に、分類体系階層の上位レベルも、ファイルや下位レベルの集合であるにもかかわらず、存在- 15 -

するかのように見えている。MoReq2 ではファイルの場合と同様、実装方法を規定することなしに階層のための要件を述べている。

ファイルは、階層構造のどのレベルでも存在できる。これを、仮想的な分類体系を表す「図1-2

分類体系（Classification）」で示している。ここではクラスと、最下位レベルのクラスに割り当てられたファイルが示されている。この仮想体系は、実際の分類体系となるものよりも、
かなりシンプルなものである。

Classification Scheme

Class

Class

Class

Class

Class

Class

Class

Class

Class

Class

File

File

File

Class

Class

Class

File

File

Recs.

Recs.

Recs.

File

File

File

Recs.

Recs.

Recs.

Recs.

Recs.

Key: Recs. Records

図 1-2

分類体系（Classification）

注：この図はレベル、ファイル、記録の考えられる選択された関係性を示すもので、可能なすべてのレベルや配置を表すものではない。
1.1.5 クラス
MoReq2 が使用する「クラス」は、IT 用語のオブジェクト指向のクラスを指すものではない。
分類階層中の任意の点からそれより下のすべてのファイルまでの階層の部分を言う。クラスはクラスに割り当てられたすべての記録を意味するためにも使用する。
視覚的に、階層構造におけるクラスは木の枝に相当している（木構造）。従って、木構造の、あるノードの下位に複数のノードを持つように、クラスも他のクラスを含むことがある。上記の例を続けると、「図 1-3クラスの説明」の影付きボックスと太い線がクラスの例を示している。一番内側の点線内が最下層のクラスで、中心の点線内の最上位のクラスが中間ノード以下を示すクラス、一番外側の点線内の最上位のクラスが内側の各クラスを包含するクラスとなる。

- 16 -

Classification Scheme

Class

Class

Class

Class

Class

File

File

File

Class

Class

Class

Class

Class

File

File

File

Class

Class

Class

File

Class

File

Class

File

図 1-3

クラスの説明MoReq2 では、あるクラスに割り当てられたすべてのファイル、記録などを意味するのにも、「クラス」という用語を使用している。これは、「ボトル」という語によって容器と、液体で満たされた容器の両方を表すのに似ている。この二重使用は意図的なもので、用語の適切な解釈はコンテクストから常に明らかである。
MoReq2 は、エンティティ間の関係を表すために「子供」と「親」という用語を使用している。
あるエンティティの「子供」とは、階層中でその下に位置するエンティティである（言い換えれば子孫のエンティティ）。あるエンティティの「親」とは、階層中でその上に位置するエンティ
ティになる。従って、たとえばクラスの子供が他のクラス、ファイル、あるいは（まれな場合に）記録のことがある。
MoReq2 では記録がファイルであることなしに、クラスに割り当てられる、あるいはクラスに直接に格納されることが可能である。これは MoReq2 の本文が説明するように、比較的まれな状況を対象にしている。
1.1.6 電子記録管理システム（ERMS：Electronic Records Management System）
ERMS はおもに電子記録を管理するためのアプリケーションだが、物理的記録の管理にも使用できる。
ERMS は、電子文書管理システム（EDMS：Electronic Document Management System）あるいはビジネス・アプリケーションと密接に統合されていることも多い。技術的には、ERMS
は記録を管理し、EDMS はドキュメント（記録ではない）の管理を行う。しかし、特に日常的業務の支援においては、これらの機能性を分離することは難しい。
1.1.7 記録のキャプチャ
MoReq2 では、「記録のキャプチャ」は、ある記録をある ERMS へ入れることに関係したすべてのプロセスを意味する。つまり、登録、分類、メタデータの付与、ソース・ドキュメント- 17 -

の内容の凍結などを指す。より一般には、この用語は ERMS への入力や、メタデータ値など他の情報を保存することにも使われる。
業務過程で作成あるいは受領されたドキュメントは取り込まれたとき、つまり ERMS に「キャプチャ」されたときに記録となる。キャプチャに際して記録は「分類」され、つまり属する分類体系のクラスに相応したコードが付加されて、ERMS による管理が可能となる。また、ユニークな識別子も付与される。
多くの場合、キャプチャされたドキュメントは、ワークフローでよく起こるように業務プロセスと結び付くことによって記録となる。たとえばインボイスが発生すると、記録が自動的にキャプチャされる必要がある。または、正式に業務のプロセスに関与しないものでも、業務関連のドキュメントはすべて記録にするという方針が存在することもあるだろう。一方で、キャプチャの手順は利用者が選択的に開始するという場合もある。どのドキュメントを記録システ
ムにキャプチャするかの判断は、規制環境、業務・説明責任の要件、記録をキャプチャしない
ことの危険性などの分析にもとづく必要がある。たとえば、政策問題を取扱う組織でのメモがあるとする。その組織では、重要とみなされるメモだけを記録とするように決めているだろう（会議の段取りに関するなど、重要でないメモは記録とならない）。ある状況では、下書きは重要とみなされ記録になることもあるし、逆に記録にはならない状況もあるだろう。MoReq2 は、
これらどのような状況にも対応することを目的としている。言い換えると、MoReq2 は単に特殊利用のためや、アーキビストや監理者による専門的利用のための記録管理システムではなく、汎用的なオフィス・システムについて説明している。
1.1.8 利用者と監理者の役割
MoReq2 が用いるコンセプトでは、ERMS を使って仕事をする正式な許可を得た人間は、誰でも「利用者」を意味している。ERMS へのログインが認められている者は誰でも利用者である。
しかし、ERMS の利用者の中には、純粋な「利用者」と、記録を監督・管理する役目をもつ「利用者1」、システムのメンテナンスを行う「利用者2」が存在する。そのため、MoReq2 は多くの要件を規定する場合に「役割（ロール）」という概念を使用している。
MoReq2 では、純粋な利用者の役割を「User Roles」、記録の管理、システムの管理を行う役
割を「Administrative Roles」としている。そこで本書では前者を「利用者役割」、後者を「監理者役割」と呼ぶ。
(1) 監理者役割
監理者役割は、記録の管理そのものに関連した活動を行う。その関心は、記録の内容や業務のコンテクストよりも、エンティティとしての記録の管理である。監理者役割は ERMS のハー
ドウェア、ソフトウェア、ストレージの管理も行い、バックアップの確認、ERMS の性能の管理も行う。
一方、組織によって、ERMS の実装形態は異なる。たとえば、小さな組織が実装する ERMS
では監理者が 1 名のこともあるし、大きな組織では、それぞれが異なるアクセス許可を持った複12

記録の管理者
データのバックアップやリストア等を行う、日本で一般に言われているシステム管理者- 18 -

数の監理者職を必要とすることもある。
多くの組織がこれらの役割に対し複数の人間を割り当てるだろうし、多くの組織で追加的な役割も規定されるだろう。
このような理由から、この汎用的仕様で具体的なアクセス・プロファイルを特定することは有用ではない。そのため、MoReq2 では「役割」という概念を用いている。
しかし要約すれば、MoReq2 が規定する「役割」は利用者プロファイルのようなものである。
これは職や地位ではなく、何人かの利用者によって共有された、責任と職務上許可の集合と言える。
大きな組織では、監理者は、レコードマネージャ、アーキビスト、レコードオフィサーなど
いくつかの役割に割り当てられる。MoReq2 の“監理者”はいくつかの機能を有し、複数の役割に振り分けることができるようになっている。
複数の役割を有する“監理者”については、各要件上の役割及びその組織上の位置付けを明確にしておくことが必要である。
このため、本報告書においては“監理者”をシステムそのものの監理者とシステムに登録された内容の管理者の二つの役割を有しているものとした。
100 要件の“監理者”の役割、機能、組織上の位置付け、該当する要件は表 1-1 の通りであ
る。

表 1-1
MoReq2の用語
監理者

監理者の役割役割

機能

組織上の位置付け

該当要件№

システム監理者シ ス テ ム その ものの監理者

情報システム部門

4、26、79、80、82、84、86、87、88

コンテンツ監理者

シ ス テ ム に 登 録されて い る コ ン テ ンツの管理者

各部門の責任者

2、10、11、15、20、27、29、
34、35、37、52、58、60、81、
90、91(2) 利用者役割
利用者役割は、監理者役割と違って記録を扱うときにオフィスワーカーや調査員が必要とす
るような設備にアクセスする。これにはドキュメントの追加、記録の検索や取り出しなどが含まれる。利用者役割の関心は、記録の管理よりも、主にその内容である。言い換えれば、利用者役割は、記録が証拠を与えるような業務のプロセスに関心を持っている。

1.2

主要用語

MoReq2 の仕様で定義される用語は記録管理分野で一般に使用される用法と一致しているが、一部に MoReq2 に特有な用法もあるため、概念説明に加えいくつかの用語について補足説明を行う。

- 19 -

1.2.1 メタデータ（metadata）
記録管理における記録のコンテクスト、コンテント、構造、更に時間経過におけるそれらの管理を説明するデータ（原典： ISO 15489）。
1.2.2 記録（record）
法的義務に従って、あるいは業務取引において、組織団体や個人が証拠及び情報として作成、受領、保持する情報（原典： ISO 15489）。
国固有のローカルな定義の適用もある。
記録は 1 つまたは複数のドキュメントを組み込んでいることがあり（たとえば 1 ドキュメント
が添付情報を持つ）、また、メディアやフォーマットにかかわらない。結果として、記録は 1 つ
または複数のコンポーネントから構成されることがある。ドキュメントのコンテントに加えて、記録はコンテクスト情報と、適切な場合に構造情報（たとえば記録のコンポーネントを説明する
情報）も含む必要がある。記録の重要な特徴は、その変更が可能でないことである。
ERMS において、電子記録と物理記録の両方の管理が可能。
1.2.3 電子記録（electronic record）
電子形式の記録。
アプリケーション・ソフトウェアにより作成された結果、あるいはスキャニングなどのデジ
タル化の結果として電子形式をとることがある。
1.2.4 文書／ドキュメント（document）
1 ユニットとしての取り扱いが可能な、記録された情報やオブジェクト（原典：ISO 15489）。
ドキュメントは紙、マイクロフォーム、磁気メディア、その他の電子メディアの形をとることがある。またテキスト、データ、画像、音声、動画、その他の情報形式の組み合わせのことがある。1 つのドキュメントは、1 つまたは複数のコンポーネントにより構成されることがある。
ドキュメントは、いくつかの重要な点で「記録」とは異なっている。MoReq2 では、記録としてキャプチャされていない、つまり分類、登録、変更防止ロックなどがされていない情報を意味するときに、ドキュメントという用語を使用する。定義中の「記録された」という語は、「記録」の特性を示唆するものではない。しかし、ドキュメントによっては「記録」となるものもある。

備考：文書と記録
要件 94「文書と記録を同じ分類体系且つ同じアクセス制御下で監理することが望ましい」、95「文書と記録を同じ分類体系下で監理するときは文書と記録を明確に表示すること」とあり、“文書”と“記録”を明確に分け、同一の体系で管理する場合はその区別を明示することが求められている。
しかし、記録管理の国際標準である ISO 15489 を JIS 化した JIS X0902-1 の用語の定義中に参考として「記録管理（records management）の管理対象は、記録（records）であるが、わが- 20 -

国で一般に使われている文書管理は、記録（records）のほかに文書（documents）をも管理対象としており、その範囲が広い。」と記述しているように、わが国では管理対象として“文書”、“記録”を明確に区別せず、“文書管理”の中で定義上の“文書”、“記録”を含めて管理する場合が多い。このため、MoReq2 の要件にあるような“文書”と“記録”の明確な区分及びその区分に応じた管理は、現状ではなじみにくいものであると考えている。
平成 23 年度の報告書[1] の“文書”、“記録”の定義を再掲する。

文書（document）：一つの単位として取り扱われる記録された情報、又はオブジェクト
注：文書は、記録としてキャプチャされていない情報を意味する。

記録（record）：法的な責任の履行、又は業務処理における、証拠及び情報として、組織、又は個人が作成、取得及び維持する情報。
注：記録は 1 つ以上のコンポーネントから構成される。記録は、内容（content）に加えて、文脈上の情報、及び適用可能な場合、構造情報（例えば記録のコンポーネントについて記述する
情報）を含む。記録の重要な特徴はそれを変更することができないことである。
なお、JISX0902-1 では“文書”、“記録”を以下のように定義している。

文書（document）：一つの単位として取り扱われる記録された情報、又はオブジェクト
記録（records）：法的な責任の履行、又は業務処理における、証拠及び情報として、組織、又は個人が作成、取得及び維持する情報
1.2.5 コンポーネント（component）
この用語は標準的用法ではなく、MoReq2 固有の用法である。
コンポーネントは単独で、あるいは他のビット・ストリームとともに記録またはドキュメン

トを構成する、個別のビット・ストリームである。
「個別のビット・ストリーム」とは、IT 分野で通常呼ばれている「ファイル」を示している。
ここでは、記録管理における「ファイル」との混同を避けるために、そのような「ファイル」という語を使用していない。概念として重要なのは、「コンポーネント」は別個の処理や管理が可能であるにもかかわらず、ある記録の内容の不可分な部分を構成している点である。
以下にコンポーネントの例を示す。
・ウェブページを構成する HTML 文書と JPEG 画像・記録が、表計算シートへの埋め込みリンク（ハイパーリンク）を持ったワープロ文書によって構成される場合に、そのワープロ文書及び表計算シート
コンポーネントは明確に区別が可能、つまり互いが別個である必要がある。もし、表計算シートへの埋め込みリンクでなくワープロ文書の中に表計算シートが埋め込まれていれば、その場合に表計算シートはコンポーネントとはみなさない。表計算シートが埋め込まれたワープロ
文書が、1 つのコンポーネントから構成された 1 つの記録となる。
また添付情報のある電子メール・メッセージは、その保存形式によって 1 つのコンポーネント、
複数のコンポーネント、または複数の記録とみなされる。
以下に添付情報とコンポーネントの関係例を示す
・メッセージが、その本文及び全添付情報を含む形式で保存されていれば、それらは 1 つのコ
ンポーネントとなる- 21 -

・添付情報が電子メール・メッセージの本文とは別に保存され、その内部でリンクされている場合には、各添付物及びメッセージの本文がコンポーネントとなる・添付情報が電子メール・メッセージの本文とは別に保存され、その内部でリンクされていな
い場合には、各添付情報及びメッセージの本文は別個の記録となる。適切なプラクティス
として、これらの記録は互いに手動でリンクする必要があるだろう
1.2.6 ファイル（file）
同じ主題や行為、トランザクションに関係するためにグループ化された、「記録」の組織化ユニット（原典：ISAD(G)からの改変・短縮）。
これはファイルという語の記録管理上の用法である。IT 分野での通常の用法とは異なる。IT
分野でのファイルは MoReq2 においては、用語「コンポーネント」を使用する。
1.2.7 サブファイル（sub-file）

ファイルの知的認識における下位区分。
サブファイルは、ケース・ファイル管理環境で使用されることが多い。一般に各サブファイ
ルには名前が付けられ、それぞれが「送り状」、「査定」、「通信」など、ケースの 1 事例における特定種類の記録（1 つまたは複数）の保存に使用される。しかしサブファイルは、同じ方法
で、非ケース・ファイルの環境でも使用されることがある。
1.2.8 ケース・ファイル（case file）
本用語は MoReq2 の理解のために定義された語であり、ERMS で管理される他のファイルとケース・ファイルの違いについて、広く一般に認められた定義はない。
MoReq2 でケース・ファイルは構造化された、または部分的に構造化された方法で完全に、または部分的に実行される 1 つまたは複数の具体的なプロセスや行為の結果としてのトランザクシ
ョンに関係したファイルであると定義される。
なお、ケース・ファイル内の記録は構造化されている場合もされていない場合もある。
次にケース・ファイルの主な特徴であるが、少なくとも部分的に構造化され、繰り返し可能なプロセスの結果として作成されることが挙げられる。
以下にケース・ファイルの例を挙げる。
・許可の申請・所定のサービスに関する問い合わせ
・事件の調査・規制上の監視またケース・ファイルは典型的に、以下の特徴を持つ場合が多い。
・その内容のための予見的構造を持つ
・数が多い
・構造化されている、または部分的に構造化されている・既知で規定のプロセスにおいて使用され、管理されている・法律や規制にもとづき、特定期間の保管が必要- 22 -

・管理者の承認を得ることなしに、専門職、エンドユーザ、データ処理システムなどによるオープンとクローズが可能
1.2.9 ボリューム（volume）

サブファイルの下位区分。
この下位区分は、管理のために大き過ぎない単位を作成することによって、サブファイル内
容の管理を容易にするために作成される。この下位区分は知的というより、機械的なものである（たとえば記録の数、数の範囲、時間間隔など）。

- 23 -

付録 2100 要件適用ガイド

100 要件を個別の電子記録管理システムに適用するには、その環境に応じた要件項目の取捨選択が必要となる。
個別の電子記録管理システムに対する要件は、大きく 2 つの要因によって左右される。一つ目の要因はその組織の業務内容並びに記録の目的及び特性である。業務内容が研究開発なのか日常業務なのか、目的が知財保護なのか内部統制なのかなどによって要件は異なる。二つ目の要因は、導入組織における記録管理の成熟度である。成熟した組織に最適であっても未成熟な組織には過剰な要求となることから、成熟度に合致した要件設定が必要である。
図 2-1 はその考え方を示している。
一つ目の要因については、組織における記録管理の類型に従って、各々の類型毎に必要な要件を特定する。これにより、類型に従って機械的に電子記録管理システム要件を抽出できる。
二つ目の要因については、記録管理の成熟度モデルに従って個々の成熟度を満たすために必要となる要件を特定する。これにより、目標とする成熟度に応じて機械的に電子記録管理シス
テムの要件を抽出できる。

記録管理
の成熟度

汎用の
記録管理要件

記録管理
の類型

記録管理
の類型
個別の
記録管理要件
図 2-1

2.1

個別の記録管理要件抽出の概念

必須要件

記録管理に関する組織の成熟度や文書の類型に係らず記録を管理する上で必要不可欠な要件として、分類支援及びメタ情報の付与、アクセス制御、バックアップ、保持・処分計画が挙げられる。これらは、e-文書法（「民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律）や個人情報保護法(個人情報の保護に関する法律)対応の要件でもある。対応分類
支援及びメタ情報の付与は記録を整理して保存する上で不可欠であり、アクセス制御は機密保護や個人情報保護に欠かせない。また、バックアップは災害への備えとして、保持・処分計画
は記録を適切な期間（例えば、法定保存期間）保存するために必須となる。

- 24 -

要件 01 分類体系/階層化：ファイル（この用語は MoReq2 に合わせて用いている。フォルダに類似。以後同様）、や記録を階層化されたクラスによる分類体系で表現できるこ
と

要件 21

アクセス/制限：識別され認証された認可ユーザでない限りいかなる操作もでき
ないこと

要件 25

バックアップ：自動バックアップを提供すること

要件 26

リストア権限：許可された管理者のみがリストア及びロールフォワードできるこ
と

要件 29

保持・処分/計画作成権限：管理者のみが保持及び処分計画を作成し維持（含む、修正）できること

要件 30

同/履歴保護：保持及び処分計画の変更履歴を改編できないよう維持すること

要件 31

同/計画変更：保持及び処分計画の変更は直ちに適用されること。変更理由は保
存すること

要件 32

同/計画設定：全てのクラス、ファイルは保持及び処分計画をもつこと。記録のタイプにデフォルトの保持及び処分計画をもつことが望ましい

要件 39

処分レビュ/決定理由設定：レビュ決定の理由を記録するためにレビュワがメタ情報にコメントを入れられること

要件 40

同/レビュ記録保持：レビュ期間の理由を含むレビュワの決定の履歴を保持する
こと

要件 50

キャプチャ/自動変更記録：キャプチャ時に記録内の参照を変更する場合は監査証跡に自動的に記録されること

要件 51 同/メタキャプチャ：各コンポーネント（この用語は MoReq2 に合わせて用いている。いわゆるファイル）のファイルフォーマット、バージョンは自動的にキャ
プチャしメタ情報に格納する
要件 53

同/クラス割付：記録はキャプチャされた時に適切なクラス又はファイルに割り当てられること

要件 54

メタ自動付与：特定のファイル（フォルダ）にドロップされた記録に属性を自動付与することが望ましい

2.2

組織の記録管理の成熟度に応じた要件選択

2.2.1 成熟度モデル
組織の記録管理が進まない理由の一つとして、組織の記録管理の現在の状態や目指すべき記録管理の状態が見えない、認識できないということがある。状態が見えることにより、どこに問題があるか、目標とする状態とのギャップはどこにあり、このギャップをうめるための具体的な対応を組織で計画し、進めていくことが可能となる。
このように、組織の現在の状態を見える化するための評価軸の設定や、PDCA サイクルを使った改善の仕組みを行うマネジメント手法は、他の分野で多くの試みが行われ、CMMI や- 25 -

JRMS（JIPDEC が作成したリスクマネジメントシステム評価システム） など成功した事例が多くみられる。
特に、JRMS は JIPDEC が ISO 31000 のリスクマネジメントの規格を参考に、組織のリスク
マネジメントの評価を行うために、組織のリスクマネジメントの状態を表す成熟度モデルを作成し、組織のリスクマネジメント評価に貢献した実績があり、この成熟度モデルを参考に、表2-1 に示す、組織における記録管理の成熟度モデルを策定した。

表 2-1

記録管理の成熟度モデル

成熟度の評価レベル

定義

摘要例

0

未認識・未対応

記録管理の対応が個人、組織とも行われていない・記録を管理するという認識もなく、記録管理の対応方法について知識を持っている要員もいない
・紙の記録を中心に管理している・記録管理に対する認識や対応は個人に依存している・紙の記録を中心に管理している

1

個人ごとによる対応

記録管理の対応が個人ごとによる対応に留まっている

・記録管理に対する認識や対応は個人に依存している

2

部門ごとによる対応

記録管理の対応が部門ごとに統一されているが、全組織で統一した対応は行われていない

・記録管理に対して、支店等の部門ごとに対応が定められ、文書化もされている

3

全組織による対応

記録管理の対応が全組織で標準化され、組織的な承認を得ている

・記録管理に対して、全組織としての対応が定められ、文書化もされており、手続き等も定め
られている

4

全組織による管理
された対応

全組織での標準化された記録管理の対応に加え、記録管理が基準通り実施されているかを管理している・記録管理のばらつきやぶれが、基準からの逸脱として把握されている

5

全組織による最適化された対応全組織による管理された対応に加え、記録管理を組織として継続的に改善している・全組織による最適化された対応

2.2.2

100 要件と成熟度モデルの関係

成熟度モデル導入の目的は、記録管理システムの要件仕様である「主要 100 要件」の適用にあたって、組織における文書管理の成熟度のレベルを評価することによって、そのレベルに見合った記録管理システムの要件を示すことにある。別の見方をすれば、文書管理の成熟度モデルの各レベルに到達するための要件と捉えることもできる。
表 2-4 では、評価レベルは成熟度モデルのレベル 3～5 の 3 段階とした。各レベルとの関係は薄いが、記録管理システムが有しておくと望ましい機能については“オプション”と表記した。
なお、具体的な評価基準と指標については、ARMA International の“ARMA International
Maturity Model for Information Governance”及び Standards Australia の"HB 278—2009
Recordkeeping Compliance"を参照されたい。これらの概要については、本報告書本文に解説を- 26 -

掲載した。

2.3

業務プロセス及び文書の類型に応じた要件選択「業務プロセス」は業務の流れを類型として捉えたものであり、本ガイドでは、表 2-2 の「商品開発プロセス」、「研究開発プロセス」、「日常処理プロセス」を対象としている。
一方、「文書モデル」は業務上作成される文書を類型化したものであり、「企業統治モデル」、「内部統制モデル」、「マネジメントシステムモデル」、「営業情報管理モデル」、「技術継承モデル」、「知的財産保護モデル」、「物品製造モデル」、「設備情報管理モデル」、「建造物維持管理モデル」の 9 種を設定している。これらの文書モデルの特徴及び代表的な文書について
表 2-3 に示す。
表 2-4 では、それぞれの類型ごとに「主要 100 要件」の大分類単位で「必要」、「あった方が望ましい」、「必要性が低い」、の 3 レベルで指針を示してある。この狙いは、記録管理（レコードマネジメント）の視点から、上述した業務プロセスの類型または文書モデルに対し、記録管理システムにどのような要件が重要視されるかを示すことにある。記録管理システムを導入する際の要求仕様作成の目安となり、利用しやすい記録管理システムの構築の一助となると幸い
である。

表 2-2
カテゴリ

業務プロセスの類型

説明（キーワード）

該当する文書モデル

商品開発プロセス

商品の企画、研究及び決裁に係る一連の文書
知的財産に関する文書が多い

マネジメントシステムモデル、知的財産保護モデル

研究開発プロセス

商品の企画、研究及び決裁に係る一連の文書
研究結果の蓄積＝長期保存が必要であり、その継承が求められる文書が多い

マネジメントシステムモデル、知的財産保護モデル、技術継承モデル

日常処理プロセス

毎日定例的に処理が必要なプロセス。会計処理など
適切な処理が行われたかどうかエビデンスとなる文書が多い

内部統制モデル、営業情報管理モデ
ル

表 2-3

文書の類型

カテゴリ

文書類型

説明

文書内容

企業経営
（外部）

企業統治モデル

組織の外部に対し、法的責任、社会的責任を果たしていることを担保するために重要な記録である
記録管理上、特にシステム登録後に変更、改ざんされていないことが重要になる規定、マニュアル、株
主総会議事録、取締役
会議事録、取締役の職
務執行に関わる記録、
広報- 27 -

カテゴリ

企業経営
（内部）

訴訟対応

維持管理

文書類型

説明

文書内容

内部統制モデル

組織内部の会計処理が適正に行われていることを担保するために重要な記録である
記録管理上、特に記録がもれなく保存されていること、システム登録後に変更、改ざんされていないことが重要になる
記録管理システムにはスキャニングデータとして登録されることが多いことが特徴である

帳簿、契約書、会計データ、納品書、発注書、請書

マネジメントシステムモデル

組織の外部に対し、組織内のリスク対応や品質を保証するためのマネジメントシステムで必要かつ重要な記録である
記録管理上、作成・承認の時間などの証明に加えて、万が一の場合に即検索できることも重要である

品質計画書、作業報告
書、実施報告書、業務手順書、業務分類、各種作成したリスト類

営業情報管理モデル

現在進行している営業案件はもとより、過去の営業案件の蓄積や、その際に作成・提出したドキュメントの管理も重要である

営業日報、交渉議事録、連絡・対応記録、顧客要求事項の記録

技術継承モデル

営業情報、技術検討経緯、設計記録など企業活 議事録、検討メモ、提動で蓄積された“情報資産”の集約と活用は、 案資料、入手資料、重要情報の URL など
企業にとっての財産に繋がる

知的財産保護モデル

知財保護のために、蓄えられた情報資産に対してのアクセス権、秘密保持の設定が重要になる

申請書、研究開発に発生した際のメモ・文書
やラボノート

物品製造モデル

品質保証（消費者保護）のために、製品設計・製造に関わる記録について、適切な保管管理が重要である。特に、製品寿命が長期間にわたる
もの、取扱い不備による人命事故に繋がるもの
では重要な記録となる

設計企画書、設計図、試験記録、販売計画、
発送記録、クレームなど

設備情報管理モデル

設備の安全運転と安定稼動のためには設計から設置・施行、性能試験、保守点検などのメンテナンスが不可欠である。その際の記録と保修工事をする際のもとデータとして、設備情報は重要な記録である
また、万が一の事故、災害時には、復旧対策の初動に大きく影響するので、最新版の管理は必要不可欠となる

設備設計書、設置計画書、取扱説明書、設計図、配置図、不具合記
録、点検記録、監督官
庁への提出書類など

建造物維持管理モデル

施設の安全と予防保全のためには設計から部
品製造、建設施行、耐用試験、保守点検などのメンテナンスが不可欠である。その際の記録と予防計画をする際のもとデータとして、施設情報は重要な記録である
また、万が一の事故、災害時には、復旧対策の初動に大きく影響するので、施工当初の設計図の長期保存が重要になる

施設設計書、工事計画書、取扱説明書、設計図、機械配置図、不具合記録、点検記録監督
官庁への提出書類など- 28 -

表 2-4

環境に応じた主要 100 要件の適用

成熟度モデルのレベル 3：全組織による対応、4：全組織による管理された対応、5：全組織による最適化された対応、Op.：成熟度モデル各レベルとの関係は薄いが、記録管理システムが有しておくと望ましい機能◎：絶対に必要、○：必要(有った方が望ましいを含む)、×：必要性が低い
日常処理プロセス

建造物維持管理 モ
デル
設備情報管理モデル
物品製造モデル
知的財産保護モデル
技術継承モデル
営業情報管理モデル
マネジメントシステムモデル
内部統制モデル

企業統治モデル分類体系とファイル構成

研究開発プロセス(a)

要件

商品開発プロセスNo

成熟度モデルの
レベル

区
分

企業経営
訴訟対
企業経営(内部)
維持管理
(外部)
応

分類体系の設定1

ファイルや記録を階層化されたクラスによる分類体 3系で表現できること※全てのクラス、ファイル、サブクラス、ボリュー Op
ムに説明（スコープノート）を入力できることが望ましい

2

分類体系の管理は監理者だけに許されること

3

3

分類体系の全て又は部分をインポートできること。分類体系をインポートするときは関連メタデータ、保持及び処分計画、監査証跡もインポートできること

3

4

分類体系の全てまたは部分をエクスポートできることが望ましい。分類体系をエクスポートするときは監理者がエクスポートするメタデータを選べること。このとき監理者の選択で関連する保持及び処分
計画、監査証跡もエクスポートできること

5

別途規定される標準フォーマットでエクスポートす
Op.
ること

6

分類体系の全て又は部分をコピーする場合は関連メ
タデータ、全ての保持及び処分計画を含むこと

3

7

複数の分類体系が定義でき同時に使えること4◎ ◎ ○ ○ ○ ○

◎

◎ ○

○ ○

○

○ ○ ○ ○ ○ ○

○

○ ○

○ ○

○

3

クラスとファイル
8

クラス又はファイルのメタデータ内に、開始日（open）及び終了日（close）を格納すること

3

9

クラス又はファイルのメタデータ内に、新たなクラス、ファイル、サブファイル、ボリュームの作成日を格納すること

3

10

新たなクラス又はファイルを開始（open）したとき
はメタデータを継承すること。継承したメタデータ
値は許される範囲内で監理者が変更できること

3- 29 -

日常処理プロセス

建造物維持管理 モ
デル
設備情報管理モデル
物品製造モデル
知的財産保護モデル
技術継承モデル
営業情報管理モデル
マネジメントシステムモデル
内部統制モデル

企業統治モデル

研究開発プロセス

要件

商品開発プロセスNo

成熟度モデルの
レベル

区
分

企業経営
訴訟対
企業経営(内部)
維持管理
(外部)
応

ボリュームとサブファイル
11

サブファイルやボリュームを監理者が作成できないOp.
ようにも設定できること

12

新たなボリューム又はサブファイルを開始したとき
は、開始日をメタデータに格納し、上位集合のメタデータ値を継承すること○ ○ ○ ○ ○ ○

○

○ ○

○ ○

○

◎

◎ ○

○ ○

○

◎ ◎ ◎ ◎ ◎ ◎

◎

◎ ◎

◎ ◎

◎

○ ○ ○ ◎ ○ ○

○

○ ◎

○ ○

○

3

分類体系の保守(b)

13

クラスの結合や分割ができること

3

14

再配置や再分類するとき、変更前の参照関係を保持すること（変更された体系に参照を付けること）また、新たな親クラスからの継承ができること

3

15

記録が再配置またはコピーされる時に監理者にメタデータとしてその理由の入力を要求すること

316

再配置又はコピー前の状態、及び再配置前のメタデータの値を記録すること

3

17○ ○ ○ ○ ○ ○ユーザが関連ファイル間の相互参照を作成できるこOp.
とが望ましい18

記録の重複なしに記録に対する複数エントリを作成
Op.
できることが望ましい

19

ユーザはファイルや記録のコンテキスト（脈絡、たとえば属するクラス）を認識できること

3

20

ファイルの検索用キーワードを変更するときは、変更前の状態の痕跡を履歴として残すとともに、監理者に理由の入力を求めること4

コントロールとセキュリティ
アクセス
識別され認証された認可（authorized）ユーザでな
い限りいかなる操作もできないこと

3

22

操作やその時刻情報を自動的にキャプチャし格納した監査証跡を保持すること

4

23

監査証跡パラメタの変更、メタデータの変更、記録への注釈や変更、監理パラメタの変更が監査証跡に記録されること424

アクセス制御の意図的違反行為をキャプチャし保存
すること

4

21
監査

- 30 -

日常処理プロセス

建造物維持管理 モ
デル
設備情報管理モデル
物品製造モデル
知的財産保護モデル
技術継承モデル
営業情報管理モデル
マネジメントシステムモデル
内部統制モデル

企業統治モデル

研究開発プロセス

要件

商品開発プロセスNo

成熟度モデルの
レベル

区
分

企業経営
訴訟対
企業経営(内部)
維持管理
(外部)
応

バックアップとリカバリ
25

自動バックアップを提供すること

326

許可された監理者のみがリストア及びロールフォワ
ードできること3◎ ◎ ◎ ◎ ◎ ◎

◎

◎ ◎

◎ ◎

◎

重要記録を含むか重要記録として扱われるファイル
や記録を監理者が表示できること。また、最早重要 Op.
と扱われないファイルや記録を表示できること
× ◎ ○ ○ ○ ○

○

○ ◎

◎ ○

○

○

○ ○

○ ○

○

重要記録
27

28
(c)

フルバックアップと重要バックアップの 2 つの独立Op.
した操作ができること

保持と処分
保持及び処分計画
29

監理者のみが保持及び処分計画を作成し維持（含、修正）できること

430

保持及び処分計画の変更履歴を改変できないよう維
持すること

4

31

保持及び処分計画の変更は直ちに適用されること。
変更理由は保存すること

4

32

全てのクラス、ファイル、サブファイル、ボリュー
ムは 1 以上の保持及び処分計画をもつこと
デフォルトの場合は上位エンティティの保持及び処分計画を継承すること※記録のタイプにデフォルトの保持及び処分計画を適用できることが望ましい

3

33

保持及び処分計画は保有期間及びトリガー事象または処分日、処分行為と理由を含むこと。処分行為として少なくとも永久保存、レビューに提出、自動廃棄、管理者承認後の廃棄、移管が許されること※保持及び処分計画は説明と業務規程を含むことが
望ましい

34

保持及び処分計画に従って保存期間が満了した場合は自動的に処分決定プロセスを起動すること。自動Op.
処理は監査ログをとり監理者に通知すること。レビューが必要なときは監理者に自動的に通知すること

35

監理者はレビューを委任することができること

Op.

36

許可されたユーザによる処分保留が許されること。
処分保留の適用及び解除の場合はその日付、許可されたユーザの ID、理由をキャプチャし保存すること

3- 31 -○ ◎ ○ ◎ ◎ ◎4

日常処理プロセス

建造物維持管理 モ
デル
設備情報管理モデル
物品製造モデル
知的財産保護モデル
技術継承モデル
営業情報管理モデル
マネジメントシステムモデル
内部統制モデル

企業統治モデル

研究開発プロセス

要件

商品開発プロセスNo

成熟度モデルの
レベル

区
分

企業経営
訴訟対
企業経営(内部)
維持管理
(外部)
応

処分のレビュー
37

計画が特定の期間に入ることを監理者に通知するこ
と

4

38

メタデータと計画情報によりレビュープロセスを支援すること※同じ記録のレンディション間のリンクを維持し処分行為を同時に行えること。レビュワが、廃棄、移管、更なるレビュー、永久保存のマーク付けをできること※自動的にレビュー日のログが採れること

5

39

レビュー決定の理由を記録するためにレビュワがメ
タデータにコメントを入れられること

4

40

レビュー期間の理由を含むレビュワの決定の不変履歴を保持すること

4○ ○ ○ ○ ○ ○

○

○ ○

○ ○

○

○ ○ ○ ◎ ◎ ○

○

○ ○

◎ ○

○

移管、エクスポート、廃棄41

記録をエクスポートできること。記録を移管またはエクスポートする場合は全てのコンポーネントの関係を維持したまま移管またはエクスポートすること

342

他のシステム又は他の組織に記録と関連メタデータと監査証跡情報を移管するよく定義されたプロセスを提供すること

543

エクスポートするメタデータ、監査証跡は選択できること。エクスポートまたは移管する場合はインプ
リシットなメタデータを含むこと

3

44

宛先システムでの再適用のために、記録と一緒に保持及び処分計画、アクセスコントロールをエクスポートまたは移管すること

345

ポインタではなく完全な記録をエクスポートまたは移管すること。記録はキャプチャ時のフォーマット
及びレンダリングされたフォーマットでエクスポー
ト又は移管できること

5

46

記録が廃棄されるときは全てのレンディションも廃棄されること

547

廃棄または移管されたクラス、ファイル、サブファ
イル、ボリューム、記録のメタデータスタブを保存できることが望ましい。
メタデータスタブは少なくとも廃棄日または移管
日、分類コード、タイトル、説明、廃棄または移管理由、参照を含むこと

3- 32 -

日常処理プロセス

建造物維持管理 モ
デル
設備情報管理モデル
物品製造モデル
知的財産保護モデル
技術継承モデル
営業情報管理モデル
マネジメントシステムモデル
内部統制モデル

企業統治モデル

研究開発プロセス

商品開発プロセス

成熟度モデルの
レベル

企業経営
訴訟対
企業経営(内部)
維持管理
(外部)
応

区
分

No

(d)

キャプチャ及び記録の宣言（※全組織で標準化した記録管理のためには必須要件）

要件

キャプチャ

48

キャプチャプロセスはユーザに、記録のキャプチャ、
分類体系への関連付け、ファイルと関連付けられた記録のためのコントロールと機能を提供すること
3※対象はデスクトップ AP 出力（オフィス）、e メー
ル、音声、DB、PDF、ビデオ、Web ページ、blog、
ソースコード、構造化データ（EDI）、Wiki 等

49

キャプチャする記録が複数コンポーネントで構成されるときは関連を保存し 1 単位として管理すること※保存や表示に必要なら一部をモディファイ（例えば、HTML ページのリンク先のグラフィックを取り込む）できることが望ましい

550

キャプチャ時に記録内の参照を変更する場合は、監査証跡に自動的に記録されること

3

51

各コンポーネントのファイルフォーマット、バージ
ョンは自動的にキャプチャしメタデータに格納する

3

52

メタデータ要素の幾つかの値は承認されたユーザと監理者のみが更新できる

3

53

記録はキャプチャされたときに適切なクラス又はファイルに割り当てられること

454

特定のファイル（フォルダ）にドロップされた記録に属性を自動付与することが望ましい

355

記録のキャプチャ日時がメタデータ及び監査証跡として記録されること。自動キャプチャできないメタ
データ入力をユーザに促すこと

5

56

クラス、ファイル、サブファイル、記録の複数キー
ワード又は語彙の割り付けを支援すること357制御された語彙から選ばれるキーワード値及び他のメタデータ要素値を提供すること

358

キャプチャ時又はそれ以降にも追加の記述などのメ
タデータ登録ができること。監理者や権限を与えられたユーザが記録のタイトルを修正する余地があること※（組織の Op.）

3

59

複数バージョンの文書をキャプチャした場合は全てを 1 記録とする、1 つを特定、全て別の記録とするかを選べること

560

監理者はクローズしたボリュームに（クローズ以前の日付がある）記録を追加できること。この時例外
理由がメタデータに追記されると共に監査証跡に自動記録されること4- 33 -○ ○ ○ ○ ○ ◎

○

○ ○

○ ○

○

日常処理プロセス

建造物維持管理 モ
デル
設備情報管理モデル
物品製造モデル
知的財産保護モデル
技術継承モデル
営業情報管理モデル
マネジメントシステムモデル
内部統制モデル

企業統治モデル

研究開発プロセス

要件

商品開発プロセスNo

成熟度モデルの
レベル

区
分

企業経営
訴訟対
企業経営(内部)
維持管理
(外部)
応

バルクインポート
61

記録のバルクインポートを実行すること

62

他のシステムで生成された取引記録をキャプチャでOp.
きること（バッチファイルなど）

63

バルクインポートの間に関連記録のメタデータを自動キャプチャできること。キャプチャしたメタデー Op. ○ ○ ○ ○ ○ ○タはルールを使って検証すること

64

インポートされた記録の履歴を表す監査証跡記録をインポートすること。監査証跡記録をその監査証跡 Op.
にインポートしないこと（別々に格納）

Op.

○

○ ○

○ ○

○

○ ○ ○ × × ×

○

× ×

× ×

×

○ ◎ ◎ ◎ ◎ ◎

○

○ ◎

◎ ◎

◎

○ ◎ ○ ○ ◎ ○

○

○ ○

○ ○

○

e-メール管理65

出入りする E メールキャプチャ時自動的にメタデー
タ（日付、受信者、主題、送信者、署名など）を抽 Op.
出すること

66

ユーザがドラッグによって E メールをサブファイ
ル、ファイル、クラスにキャプチャできることが望 Op.
ましい67

添付を別の記録としてキャプチャする場合はメタデ
Op.
ータ値のキャプチャ又は入力を要求すること

68

プロプラエタリフォーマットでキャプチャした電子
メール・メッセージをオープンフォーマットで格納 Op.
できること

記録タイプ

69

記録タイプを定義しメンテナンスすること※記録の特性（メタデータ属性、保存要件、アクセ 3
ス制御、文書の種類など）を記述

70全ての記録は 1 つの記録タイプをもつこと

3

スキャニング及びイメージング
71

少なくとも 1 つのスキャニングソリューションとの統合が可能なこと

372

OCR 機能をもつときスキャンイメージと OCR 結果のテキストは 1 つの記録として管理すること

3

73

イメージの注釈、注釈者、日付は記録として保持され変更と削除から保護されること

3- 34 -

日常処理プロセス

建造物維持管理 モ
デル
設備情報管理モデル
物品製造モデル
知的財産保護モデル
技術継承モデル
営業情報管理モデル
マネジメントシステムモデル
内部統制モデル

企業統治モデル

参照

研究開発プロセス(e)

要件

商品開発プロセスNo

成熟度モデルの
レベル

区
分

企業経営
訴訟対
企業経営(内部)
維持管理
(外部)
応

分類コード
74

クラス、ファイル、サブファイル、ボリューム、記録、コンポーネントに分類体系の階層内でユニークな分類コードを関連付けること○ ○ ○ ○ ○ ○

○

○ ○

○ ○

○

○ ○ ○ ○ ○ ○

○

○ ○

○ ○

○

◎ ◎ ○ ○ ○ ◎

◎

◎ ◎

○ ◎

◎

◎ ◎ ○ ○ ○ ○

○

○ ○

○ ○

○

○ ○ ○ ○ ○ ○

○

○ ○

○ ○

○

3

システム ID75(f)

分類コード、クラス、ファイル、サブファイル、ボリューム、記録、レンディション、保持及び処分計
画、文書に対してグローバルにユニークなシステム
ID（UUID）を生成すること

3

検索、取り出し、及び表示
検索及び取り出し(g)76

アクセスが制限されているユーザにはいかなる情報も暴露しないこと377

記録やファイル、関連メタデータ（含、署名情報）を検索し取り出し、また表示できること

3

77a

検索は、全文検索及び属性検索が可能なこと

478

オリジナルフォーマットとは別のフォーマット（レOp.
ンディション）を表示できること

監理上の機能一般監理
79

コンフィグ時に設定した値を監理者が再設定できる
こと

3

80

ユーザと役割に対して監理者が機能を割り当てできること

3

監理者が定期的又は臨時の報告書を作成できるようにすること※処分計画の成功及び失敗の結果、エクスポート処理の結果、処分作業、アクセス制御への試みやセキュリティポリシ違反行為、移管、エクスポート、廃棄、消去の失敗の詳細、インポート時の失敗の詳細
など

4

報告

81

- 35 -

日常処理プロセス

建造物維持管理 モ
デル
設備情報管理モデル
物品製造モデル
知的財産保護モデル
技術継承モデル
営業情報管理モデル
マネジメントシステムモデル
内部統制モデル

企業統治モデル

研究開発プロセス

要件

商品開発プロセスNo

成熟度モデルの
レベル

区
分

企業経営
訴訟対
企業経営(内部)
維持管理
(外部)
応

変更、削除、及びリダクション（墨塗り）

(h)

82

一旦キャプチャした記録を削除又は移動できない
Op.をもてること※監理者が削除した記録はメタデータにマークされ記録内容とメタデータは隠され監査証跡に記録され
ること

5

83

削除を破棄、移動を再構成とする代替をコンフィグ
Op.としてもてること※メタデータもメタデータスタブを除いて削除され
る

3

84

監理者は処分プロセスの外でクラス、ファイル、サOp.
ブファイル、記録を削除できること

85

利用者は削除候補のクラス、ファイル、サブファイOp.
ル、ボリューム、記録をマークできること

86

削除事象では削除を監査証跡に記録し監理者への報告を作成しコンテンツを削除し変更なら削除せずまた他のファイルとのリンクをハイライトしメタデー
タの完全性を維持すること

5

87

監理者はユーザが入力したメタデータ要素を変更できること。メタデータ要素への変更は監査証跡に格納されること

488

監理者は、オリジナル記録が保存されている間に 1以上のリダクションを作成できること。また、組織Op.
の要請でリダクション内の機微情報を削除又は隠すことができること89

リダクションを作成した時は記録とリダクション内のメタデータに作成、日時、作成者、作成理由を格
納すること
Op.
※リダクションにオリジナルとの相互参照を格納することが望ましい○ ◎ ◎ ◎ ○ ○

○

○ ○

○ ○

○

90

監理者が物理的コンテナとして存在するクラスやフOp.
ァイルを識別できること

91

監理者やユーザが物理的コンテナとしてのクラスや
Op. ○ ○ ○ ○ ○ ○ファイルのメタデータの入力や保守ができること

○

○ ○

○ ○

○

92

場所、保管者、日付のログによるチェックイン／ア
ウトで物理コンテナと記録の追跡を支援することが Op.
望ましい

オプション
物理的ファイル及び記録の管理- 36 -

日常処理プロセス

建造物維持管理 モ
デル
設備情報管理モデル
物品製造モデル
知的財産保護モデル
技術継承モデル
営業情報管理モデル
マネジメントシステムモデル
内部統制モデル

企業統治モデル

研究開発プロセス

要件

商品開発プロセスNo

成熟度モデルの
レベル

区
分

企業経営
訴訟対
企業経営(内部)
維持管理
(外部)
応

物理記録の処分○ ◎ ○ ○ ○ ○

○

○ ○

○ ○

○

94

文書と記録を同じ分類体系かつ同じアクセス制御下で監理することが望ましい。この場合、文書と記録 Op. × ○ ○ ○ ○ ○を明確に表示すること

○

○ ○

○ ○

○

95

記録の内容をコピーし新たな文書を生成できること

○

○ ○

○ ○

○

×

× ◎

○ ×

×

93

移管、エクスポート、廃棄が完了する前に物理的なOp.
移管、エクスポート、廃棄を確認すること

文書管理及び共同作業

Op.

ケースワーク96

ケースワーククラス及び非ケースワーククラスのために異なるアクセス許可をもつケースワーカーの役 Op.
割を構成できること

97

ケース・ファイルは特有のメタデータ要素で構成さ
Op.
れること

98

分類コードの替わりにケース・ファイル ID により取Op.
り出しや実行など正当なアクションがとれること○ ○ ○ ○ ○ ○

電子署名
99
100
101

キャプチャ時に電子署名と証明書をキャプチャし必
要なら検証し保存できること。保存に際しては、長 Op.
期署名措置が可能なこと
× ◎ ○ ○ ○ ○電子署名された記録の検証メタデータを保存するこOp.
とエクスポート又は移管処理の間のファイル、記録、
移管メッセージに第三者検証可能な電子署名を適用 Op.
できることが望ましい- 37 -

参考文献[1] MODEL REQUIREMENTS FOR THE MANAGEMENT OF ELECTRONIC
RECORDS UPDATE AND EXTENSION, 2008
http://www.dlmforum.eu/index.php?option=com_jotloader&view=categories&cid=
10_f56391a0c9ea9456bf24e80b514f5dda&Itemid=175&lang=en[2] ARMA International Maturity Model for Information Governancehttp://www.arma.org/garp/metrics.cfm[3] HB278:2009

Recordkeeping Compliance

http://trove.nla.gov.au/version/38670495- 38 -

電⼦記録応⽤基盤に関する調査検討報告書 2012

別冊

-電⼦記録マネジメント基盤システムの要件(100 要件)電⼦記録応⽤基盤フォーラム（eRAP）
平成 25 年 3 ⽉ 29 ⽇
発

第 1 刷発⾏

⾏：⼀般財団法⼈⽇本情報経済社会推進協会〒106-0032

東京都港区六本⽊⼀丁⽬ 9 番 9 号

TEL 03-5860-7557 FAX 03-5573-0561
印

六本⽊ファーストビル内
http://www.jipdec.or.jp/

刷：株式会社美⾏企画©JIPDEC, 2013
本書の全部または⼀部を無断に引⽤・転載することは、著作権法上での例外を除き、禁じられています。
本書からの引⽤・転載を希望される場合は、下記宛ご連絡下さい。
問合先
総務部普及広報課
TEL 03-5860-7555

ISBN978-4-89078-031-0
C3004