本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。
概要
born-digital 資料を長期保存するワークフローでは、ファイルを保存パッケージ （SIP / AIP）にする前に、移管されてきた状態をいったん記録する工程があります。 OAIS（Open Archival Information System）やアーカイブ実務で アクセッション（accessioning、受入）と呼ばれる段階です。
DataAccessioner は、この受入の 段階で、メディアやフォルダから安全にファイルを移送しつつ、各ファイルの チェックサムと技術メタデータを取得して記録するデスクトップツールです。本記事では、 このツールが何をするのか、なぜ「SIP を作る前」というタイミングが意味を持つのか、 そして自分が触っている SIP 作成ツールとどう役割が分かれるのかを整理します。
ワークフロー上の位置づけ
デジタル保存の典型的な流れは次のようになります。受入（accessioning）は配列より 前に位置づけられ、DataAccessioner はこの段階を担当します。
ただし、役割分担を「時間軸できれいに分かれる」と捉えるのは正確ではありません。 Archivematica は ingest 以降「だけ」を担うのではなく、転送（Transfer）段階での 受入・特性記述（フォーマット識別・チェックサム付与）→ 配列（Arrangement）→ SIP 作成 → Ingest → AIP までを一貫して担います。つまり受入時の特性記述も、 配列も、SIP 作成も Archivematica の内側で行われ、DataAccessioner と機能的に重複する 部分があります。両者は時間ではなく、カストディの境界（保存システムに入る前か、 システムの内側か）で分かれると捉える方が実態に合います。
:::message OAIS の SIP（Submission Information Package）は固定された1工程の成果物ではなく、 「Producer が OAIS に Ingest 用に渡すパッケージ」という役割を表す概念です。 どこに OAIS の境界を引くか（Archivematica 単体を OAIS とみなすか、機関の パイプライン全体とみなすか）によって、「何が SIP か」「誰がいつ作るか」は変わります。 なお OAIS に「配列（arrangement）」という工程は無く、これはアーカイブ実務の概念で、 OAIS の Ingest の内側に重なります。 :::
編成（配列）のステップでは、archivist が受け取ったファイル群を意味のある階層に 並べ替えます。このとき、元のフォルダ構造（before）と並べ替えた後の構造（after）の 対応関係を残しておかないと、「このファイルは元はどこにあったか」を後から辿れません。
配列後の構造は SIP / AIP の側に記録されます。配列前の状態については、下流が
Archivematica の場合は各ファイルの originalName（受入時の原パス）や、AIP に
同梱される転送 METS として保持されます。一方、下流が異種・未定の場合や、特定の
保存システムに依存しない受入＝カストディの証跡が必要な場合には、受入の段階で
固定しておかないと後から復元しにくくなります。DataAccessioner はこの受入時点の
スナップショット（システム非依存のフィクシティと原状）を担当するツールと
位置づけられます。
DataAccessioner とは
調査した限りでは、以下のようなツールです。
- 最初のバージョンは 2008 年に Duke University Archives で Seth Shaw 氏が作成。
その後 Digital POWRR プロジェクトの支援でオープンソース化され、現在は
digitalpowrr/DataAccessionerで維持されています（Seth Shaw 氏・Scott Prater 氏らが貢献）。 - 公開されている範囲では、最新は v1.2（2024 年 2 月 17 日リリース）です。
- Java / Swing 製の GUI アプリで、コマンドラインなしでフォルダやメディアから ファイルサーバへの移送を行えます。
- 移送の際に FITS（File Information Tool Set）を ラップし、各ファイルのフォーマット同定と技術メタデータを取得します。
GUI で完結する点が特徴で、リソースの限られた小規模機関でも受入記録を作れる、 という Digital POWRR の趣旨に沿った設計になっています。FITS を直接扱うより敷居が 低く、「フォルダを選んで実行する」操作に落とし込まれています。
何を取得・出力するか
ドキュメントや解説を確認した範囲では、次のような動作です。
- フィクシティ（同一性）: コピーの前後で各ファイルの MD5 チェックサムを計算し、 両者を比較して転送エラーを検出します。MD5 は元ファイルとコピー先の双方について 作られます。
- メタデータ抽出: FITS で各ファイルからメタデータを抽出し、結果を XML として 保存します。メタデータ管理側で、既定では FITS の出力を PREMIS（Preservation Metadata: Implementation Strategies、v2.2）形式に変換します。この変換は XSLT を 差し替えて変更できます。
- レポート: ディレクトリパス、ファイル名、最終更新日時、サイズ（バイト）、MD5、 ファイルフォーマットといった項目を含みます。別配布の Metadata Transformation ツール（XSLT プロセッサ）で、この一部をスプレッドシートや HTML に変換できます。
つまり、フォルダやメディアを取り込むと、ファイルごとに 「元パス＋ MD5 ＋技術メタデータ」を 1 つの XML に集約し、受入記録として固定する、 という道具です。
近接するツールとの関係
受入時点で同一性とメタデータを取得して記録する、という役割で見ると、近接する ツールがいくつかあります。
| ツール | 役割 | 補足 |
|---|---|---|
| DataAccessioner | 受入時に FITS で技術メタ＋MD5 を取得し XML に固定 | Digital POWRR が維持。Java / Swing |
| Exactly（AVP ＋ケンタッキー大 Nunn Center） | BagIt ＋MD5 マニフェストで取得時にプロヴェナンス／フィクシティを確立 | 概念参照向き。現在の保守・入手性は未確認 |
| Archivematica | Transfer（受入・特性記述）→ 配列 → SIP 作成 → Ingest → AIP、METS / PREMIS 生成 | 受入から AIP までを内包。DataAccessioner と機能的な重複もある |
DataAccessioner と Archivematica は、単純な時間軸ではなくカストディの境界で 役割が分かれます。Archivematica も Transfer 段階で受入・特性記述を行い、配列も SIP 作成も内側で担うため、機能的には重複があります。DataAccessioner の固有価値は、 保存システムに入る前・メディアからの最初の接触時点で、特定のシステムに依存せず フィクシティと原状を固定する点にあります。
採用を検討する際に見ておく点
- 公開されている範囲では v1.2（2024 年 2 月）が最新で、GitHub の star は十数程度です。 更新の頻度はそれほど高くないようなので、現行の維持状況は導入前に確認しておくと よさそうです。
- 実行に Java ランタイムが必要です。
- チェックサムは MD5 です。受入時のエラー検出という用途では実用上の問題は小さい ようですが、新規に同一性アンカーを設計するなら SHA-256 を選ぶ場面もあります。
概念とフォーマットの参照実装として参照する価値が高い一方、そのまま本番ワークフローに 長期的に組み込むかは、機関の事情に応じて判断することになりそうです。
自分の SIP 作成ツールとの棲み分け
別途、軽量な SIP 作成ツールを触っている文脈で、「DataAccessioner 相当の機能を 自前で持つべきか」を検討しました。現時点での整理を共有します。
まず、METS の structMap を自前生成する必要はなさそうだ、という点です。Archivematica が
配列前後の構造を保持するのに structMap を使っているのはその実装の都合であって、
before↔after の対応に必要な情報は、各ファイルの「元パス＋同一性（ハッシュ）」に
集約できます。structMap や PREMIS の生成は下流の ingest に任せ、受入側でフルの METS を
出力するのは過剰になりがちです。ただしこれは、before↔after の復元を下流
（Archivematica など）が originalName 等で引き受けてくれることを前提にした
判断です。下流が保存システムを持たない・異種の場合は、受入側でより多くの原状情報を
保持する必要があります。
一方で見落としやすいのは、多くの SIP 作成ツールが「渡された 1 時点のフォルダを パッケージするだけ」で、配列前と配列後という区別を持たない点です。Finder などで 先に配列を済ませてからツールに渡すと、ツールは配列後しか見ないため、配列前の構造が 記録されません。
DataAccessioner が示しているのは、ここを埋める順序です。
- 配列前に一度走らせ、各ファイルの元パス＋チェックサム（＋任意で技術メタデータ）を 受入記録として固定する。
- その後、配列して SIP 化する。
- 両者をハッシュで突合して before↔after を辿る。
自分のツールに当てはめると、すでに出力している checksum.sha256（同一性）と
DFXML（Digital Forensics XML、パス情報）に、元パスを束ねた受入スナップショットを
足すことで、DataAccessioner の核心部分は表現できそうです。フル FITS や METS を
再実装しなくても、「下流では取り戻しにくい配列前の状態を固定する」という役割は
担えます。自分のツールでは、この方針（受入時点のスナップショットを残し、structMap
生成は下流に委ねる）を採用しています。
まとめにかえて
DataAccessioner は、配列や SIP 化の前に、MD5 と FITS による技術メタデータを取得して 受入を記録するためのデスクトップツールです。Archivematica とはカストディの境界で 役割が分かれ（Archivematica も Transfer 段階で受入・特性記述を行い、配列や SIP 作成も 内側で担うため機能的な重複はあります）、DataAccessioner は保存システムに入る前の、 システムに依存しない受入記録を担います。公開されている範囲では更新頻度は高くなく、チェックサムは MD5 ベースなので、概念とフォーマットの参照実装として捉えるのが扱いやすそうです。 自前ツールに取り込む場合も、フルの METS / FITS ではなく「元パス＋ SHA-256 の受入 スナップショット」で核心は再現できる、というのが現時点での見立てです。
コメント
…