✨

OCFLによる長期デジタル保存の実践 - 入門ガイド

に公開
ipres
ocfl
tech

はじめに

デジタルデータの長期保存は、図書館、アーカイブ、研究機関にとって重要な課題です。データ形式の変化、ソフトウェアの陳腐化、ストレージ技術の進化など、様々な要因がデジタル情報の持続可能性を脅かしています。

本記事では、この課題に対する解決策の一つである**OCFL（Oxford Common File Layout）**について、その概念、意義、そして実装例を紹介します。

OCFLとは

OCFL（Oxford Common File Layout） は、デジタル情報を構造化され、透明で、予測可能な方法で保存するための仕様です。オックスフォード大学のボドリアン図書館とスタンフォード大学図書館を中心に開発され、現在はコミュニティ主導のオープンスタンダードとして発展しています。

OCFLの公式定義

"OCFLは、アプリケーション非依存のアプローチでデジタル情報を保存するための仕様であり、長期保存とデータの完全性を保証します。"

OCFLの5つの主要原則

  1. 完全性（Completeness） - リポジトリをストレージファイルから完全に再構築可能
  2. 解析可能性（Parsability） - 人間と機械の両方が理解できる構造
  3. 堅牢性（Robustness） - エラーや破損に対する耐性
  4. バージョン管理（Versioning） - オブジェクトの変更履歴を保持
  5. ストレージの多様性（Storage Diversity） - 様々なストレージインフラに対応

なぜOCFLが必要なのか

デジタル保存の課題

従来のデジタル保存には、以下のような課題があります：

  • ベンダーロックイン - 特定のシステムやソフトウェアに依存してしまう
  • 移行の困難さ - システム更新時のデータ移行が複雑
  • 透明性の欠如 - データがどのように保存されているか不明瞭
  • 長期的な可読性 - 数十年後もデータを読み取れる保証がない

OCFLによる解決

OCFLは、以下のアプローチでこれらの課題を解決します：

  • シンプルなファイル構造 - 標準的なファイルシステムを使用
  • JSONによるメタデータ - 人間が読める形式で管理情報を保存
  • ハッシュによる完全性検証 - データの破損を検出可能
  • 透明なバージョニング - すべての変更履歴が追跡可能

OCFLの基本構造

OCFLリポジトリは、以下のような階層構造を持ちます：

ocfl_root/
├── 0=ocfl_1.1                    # OCFL仕様バージョンを示すマーカー
├── ocfl_layout.json              # レイアウト情報
└── object-001/                   # OCFLオブジェクト
    ├── 0=ocfl_object_1.1         # オブジェクトバージョンマーカー
    ├── inventory.json            # オブジェクトの完全な履歴
    ├── inventory.json.sha512     # インベントリのチェックサム
    └── v1/                       # バージョン1
        ├── inventory.json        # このバージョンまでの履歴
        ├── inventory.json.sha512
        └── content/              # 実際のコンテンツ
            └── sample.txt

inventory.json - OCFLの心臓部

inventory.jsonはOCFLオブジェクトの最も重要な要素で、以下の情報を含みます：

{
  "id": "object-003",
  "type": "https://ocfl.io/1.1/spec/#inventory",
  "digestAlgorithm": "sha512",
  "head": "v2",
  "contentDirectory": "content",
  "manifest": {
    "4171fdae3bde...": ["v1/content/data.txt"],
    "2d3d718515b3...": ["v2/content/data.txt"],
    "de313e63171...": ["v2/content/additional.txt"]
  },
  "versions": {
    "v1": {
      "created": "2025-11-05T11:32:17.462453+00:00",
      "message": "Version 1: Initial data",
      "user": {
        "name": "Data Manager",
        "address": "manager@example.com"
      },
      "state": {
        "4171fdae3bde...": ["data.txt"]
      }
    },
    "v2": {
      "created": "2025-11-05T11:32:17.462568+00:00",
      "message": "Version 2: Updated data",
      "user": {
        "name": "Data Manager",
        "address": "manager@example.com"
      },
      "state": {
        "2d3d718515b3...": ["data.txt"],
        "de313e63171...": ["additional.txt"]
      }
    }
  }
}

inventory.jsonの主要な要素

  • manifest - ファイルのハッシュ値と物理パスの対応表
  • versions - 各バージョンの作成日時、メッセージ、ユーザー情報
  • state - 各バージョンにおける論理ファイルの状態

OCFLとGitの違い

OCFLはバージョン管理を行う点でGitと似ていますが、目的と設計思想が大きく異なります。

項目 OCFL Git
主な目的 長期デジタル保存 ソフトウェア開発の協調作業
設計思想 シンプルさと透明性 効率性と機能性
ファイル形式 標準的なファイル・JSON 独自のバイナリ形式
可読性 人間が直接読める ツールが必要
ブランチ サポートしない 中核的機能
マージ サポートしない 中核的機能
重複排除 コンテンツアドレッシング Packfileによる圧縮
保証 100年後も読める設計 現在のツールで最適
対象ユーザー アーカイブ・図書館 ソフトウェア開発者

なぜGitではダメなのか

Gitは優れたバージョン管理システムですが、長期保存には以下の課題があります：

  1. 複雑性 - .gitディレクトリの内部構造は複雑で、Gitツールなしでは理解困難
  2. ツール依存 - データを読み取るにはGitクライアントが必須
  3. バイナリ形式 - Packfileは効率的だが、将来のツール互換性に不安
  4. 機能過多 - 保存には不要な多くの機能を持つ

OCFLは、シンプルさと透明性を優先し、特殊なツールなしでもデータにアクセスできることを保証します。

本リポジトリでの実装例

本リポジトリでは、PythonのOCFL Coreライブラリを使用して、OCFLの主要な機能を実装しています。

実装例1: シンプルなOCFLオブジェクトの作成

from ocflcore import OCFLRepository, OCFLObject, OCFLVersion

# リポジトリの初期化
repository = OCFLRepository(root, storage)
repository.initialize()

# オブジェクトとバージョンの作成
obj = OCFLObject("object-001")
v1 = OCFLVersion(datetime.now(timezone.utc))
v1._message = "Initial commit"
v1.files.add("sample.txt", file_stream, digest)
obj.versions.append(v1)

# リポジトリに追加
repository.add(obj)

実装例2: バージョン管理

本リポジトリのobject-003では、ファイルの更新履歴を管理しています：

  • v1: data.txtの初期バージョン
  • v2: data.txtの更新 + additional.txtの追加

この構造により、以下が可能になります：

  • 任意のバージョンへの復元
  • 変更履歴の追跡
  • ファイルの完全性検証

実装例3: 重複排除（Deduplication）

object-004では、同じ内容のファイルを異なる名前で追加しています：

# 同じ内容のファイルを3つ作成
v1.files.add("copy1/file_a.txt", file_stream_a, digest)
v1.files.add("copy2/file_b.txt", file_stream_b, digest)
v1.files.add("copy3/file_c.txt", file_stream_c, digest)

結果:

  • 論理ファイル数: 3
  • 物理ファイル数: 1

OCFLは、ハッシュ値が同じファイルを1つの物理ファイルとして保存し、ストレージを効率化します。

OCFLの利点

1. 長期的な持続可能性

  • シンプルな構造 - 複雑なツールに依存しない
  • 標準的な技術 - ファイルシステムとJSONのみ
  • 明確な仕様 - 公開されたオープンスタンダード

2. データの完全性

  • ハッシュベースの検証 - すべてのファイルの完全性を確認可能
  • 変更の追跡 - すべての変更が記録される
  • 破損の検出 - チェックサムによる自動検証

3. 柔軟性

  • ストレージ非依存 - ローカルファイルシステム、S3、Glacierなど
  • アプリケーション非依存 - 特定のソフトウェアに縛られない
  • 移行の容易さ - 単純なファイルコピーで移行可能

4. 透明性

  • 人間が読める - JSONファイルを直接確認可能
  • 監査可能 - すべての履歴が明示的
  • デバッグしやすい - 問題の特定と修正が容易

OCFLの使用シーン

適している用途

  • デジタルアーカイブ - 文化遺産のデジタル化
  • 研究データ管理 - 学術研究データの長期保存
  • コンプライアンス - 法的要件に基づくデータ保存
  • 機関リポジトリ - 大学や研究機関の出版物管理

適していない用途

  • 頻繁な更新 - リアルタイムなデータ変更
  • 協調編集 - 複数人による同時編集
  • ブランチ管理 - 並行開発ワークフロー
  • 一時的なデータ - 短期間だけ必要なデータ

実践のポイント

1. オブジェクトの設計

OCFLオブジェクトは、論理的にまとまったデータの集合として設計します：

  • 良い例: 1つの書籍とそのメタデータ、画像
  • 悪い例: 関連のない複数のファイルを1つのオブジェクトに

2. バージョニングの戦略

バージョンを作成するタイミング：

  • 意味のある変更があった時
  • 公開やリリースのタイミング
  • 定期的なスナップショット

3. ダイジェストアルゴリズムの選択

  • SHA-512 - 推奨（デフォルト）
  • SHA-256 - 代替オプション
  • MD5 - 非推奨（セキュリティ上の問題）

4. ストレージの検討

  • クラウドストレージ - S3、Azure Blob、Google Cloud Storage
  • テープストレージ - 大容量の長期保存
  • 分散ストレージ - 地理的冗長性の確保

まとめ

OCFLは、デジタル情報の長期保存のための実用的で強力なソリューションです。以下の特徴により、図書館、アーカイブ、研究機関にとって理想的な選択肢となっています：

  • シンプルさ - 複雑なツールに依存しない
  • 透明性 - すべてが人間に読める形式
  • 持続可能性 - 数十年後も読める設計
  • 柔軟性 - 様々なストレージに対応

本リポジトリの実装例を通じて、OCFLの基本的な概念と実践方法を理解していただけたと思います。デジタル保存の課題に直面している方は、ぜひOCFLの導入を検討してみてください。

参考リンク

付録: 用語集

  • OCFL Object（OCFLオブジェクト） - 一意のIDを持つデジタルコンテンツの集合
  • Inventory（インベントリ） - オブジェクトの履歴と状態を記録したJSONファイル
  • Manifest（マニフェスト） - ファイルのダイジェスト値と物理パスの対応表
  • Version（バージョン） - オブジェクトの特定時点での状態
  • State（状態） - あるバージョンにおける論理ファイルパスの集合
  • Digest（ダイジェスト） - ファイルのハッシュ値（整合性検証用）
  • Content Directory（コンテンツディレクトリ） - 実際のファイルが保存されるディレクトリ
  • Deduplication（重複排除） - 同一内容のファイルを1つの物理ファイルとして保存する仕組み

Discussion