Archivematica で backlog のファイルをフォルダに並べ替えて 1 つの SIP にしたとき、元の構造と並べ替え後の構造はどこに記録されるか

本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

Archivematica では、いったん backlog（バックログ）に送ったファイル群を Appraisal / Arrangement タブで自由にフォルダへ並べ替え（arrange）、その階層をそのまま 1 つの SIP（Submission Information Package）に束ねて取り込むことができます。

このとき素朴な疑問が出ます。

並べ替えてしまったら、「元はどういう構造だったか」は失われるのか？ そして 「並べ替え後の構造」はどこに、どんな形で記録されるのか？

結論から言うと、元の構造も並べ替え後の構造も、両方とも失われずに残ります。ただし「SIP の段階」と「AIP の段階」で記録される場所と形式が違うので、そこを実データで切り分けて整理します。

検証環境は Apple Silicon Mac 上の開発用 Docker スタック（Archivematica v1.18.0 相当）です。flat-demo という、objects/ 直下に notes.doc / report.pdf / scan.tif がフラットに3つ並んだ転送を backlog に入れ、それを arrange でフォルダ分けする、というシナリオで確認しました。

実際にこの「フラットな資料を Appraisal タブで配列して 1 SIP にする」操作を、デモ動画にしています（音声・字幕は生成AIによる自動生成です）。

前提：用語と全体の流れ

Transfer：取り込みの最初の単位。フォーマット識別やウイルスチェックを経て、自分専用の transfer METS を持つ。backlog にはこの単位で入る。
SIP：取り込み（Ingest）の作業単位。backlog から arrange して作る。
AIP：保存用パッケージ。Ingest の終盤で AIP METS が生成され、.7z 等に固められて Storage Service に保管される。

ポイントを先に表で示します。

	並べ替え前（before）	並べ替え後（after）
SIP 段階 / DB	`main_siparrange.original_path`	`main_siparrange.arrange_path`（作業用・非永続）
SIP 段階 / ファイル	SIP 内にコピーされた元 transfer METS（恒久）	SIP の物理ディレクトリ構造
AIP 段階 / METS	`submissionDocumentation/transfer-…/METS.xml`（元 transfer METS を同梱）	AIP METS の `structMap`（physical ＋ logical）

以下、SIP → AIP の順に実データで見ていきます。

SIP の段階：構造はどこに残るか

重要な前提として、「SIP という対象だけを指す専用 METS（METS.<SIPUUID>.xml とは別の SIP 専用ファイル）」は生成されません。

ただし誤解しやすいのですが、structMap 入りの METS 自体は Transfer 段階で既に作られています。Transfer の終盤で createTransferMETS_v1.0（クライアントスクリプト create_transfer_mets.py、ライブラリは metsrw）が metadata/submissionDocumentation/METS.xml を生成し、これには既に structMap（physical Archivematica default と logical Normative Directory Structure）が含まれます。実 AIP で確認したところ、この transfer METS の CREATEDATE は AIP METS より約1時間早い（先に存在する）ことが分かりました。

一方、Ingest の create_mets_v2.0（クライアントスクリプト create_mets_v2.py）が生成するのが AIP METS（data/METS.<SIPUUID>.xml）で、ここで初めて「並べ替え後の構造」が structMap として記録されます。つまり「SIP 段階で structMap がまったく無い」のではなく、並べ替え後の構造を structMap 化するのが AIP METS 生成のタイミング、という整理になります。

では SIP の段階で「並べ替え前後」はどこにあるのか。2系統です。

① 並べ替え前後のマッピング → DB の `main_siparrange` テーブル

arrange して SIP を作る瞬間の「元パス → 並べ替え後パス」が、このテーブルに入ります。

SELECT original_path, arrange_path, sip_created, aip_created, HEX(file_uuid) AS file_uuid
FROM MCP.main_siparrange ORDER BY arrange_path;

実際の中身（flat-demo の3ファイル。今回は各ファイルをルート直下に置いたケース）：

original_path（並べ替え前＝backlog の場所）	arrange_path（並べ替え後＝SIP 内の場所）	file_uuid
`originals/flat-demo-12cec7db…/data/objects/notes.doc`	`notes.doc`	`a565f459…`
`…/objects/report.pdf`	`report.pdf`	`a063d929…`
`…/objects/scan.tif`	`scan.tif`	`f45e5c3a…`

original_path … 並べ替え前（取り込み元 backlog のパス）
arrange_path … 並べ替え後（SIP 内の相対パス）。もし a/ b/ c/ というフォルダに振り分けて 1 SIP にまとめれば、ここが a/notes.doc / b/report.pdf / c/scan.tif になります。
file_uuid … ファイル UUID。これは後段の AIP METS の FILEID="file-a565f459-…" と同一で、SIP→AIP を貫く不変キーになっています。

:::message alert main_siparrange は 運用上の作業データ であって、恒久的な来歴（provenance）記録ではありません。DELETE で消せますし、arrange をやり直すときには実際にクリアして入れ直すこともあります。したがって「永続的に残る並べ替え前後の構造」の本体は、次の②と、後述の AIP METS です。 :::

② 並べ替え前の構造 → SIP 内にコピーされる元 transfer METS（恒久）

SIP を作るとき、元 transfer の METS が SIP の中へコピーされます。

<SIP>/objects/submissionDocumentation/transfer-flat-demo-12cec7db…/METS.xml

この元 transfer METS の中に、並べ替え前のフラットな構造がそのまま残っています（実データ）：

<mets:structMap TYPE="physical" LABEL="Archivematica default">
  <mets:div LABEL="flat-demo-12cec7db-…">
    <mets:div LABEL="objects">
      <mets:div TYPE="Item" LABEL="notes.doc"/>
      <mets:div TYPE="Item" LABEL="report.pdf"/>   <!-- 元は3つフラットに並んでいた -->
      <mets:div TYPE="Item" LABEL="scan.tif"/>

つまり「並べ替え前の姿」は SIP の段階ですでに SIP の中に同梱されており、そのまま AIP へ持ち越されます。

③ 並べ替え後の構造 → SIP の物理ディレクトリそのもの

SIP は「arrange の結果のディレクトリ」として物理的に組み立てられます（objects/a/ objects/b/ objects/c/ …。実装上は arrange 確定時に arrange_path を destination としてファイルが実際に shutil.move されます）。ただし繰り返しになりますが、この並べ替え後のレイアウトが METS の structMap という形式の記録になるのは Ingest の create_mets_v2.0 以降であり、SIP 段階ではあくまでファイルシステム上の構造として存在するだけです（前述のとおり、structMap 入りの METS 自体は transfer METS として既に存在しますが、それが表すのは並べ替え前の構造です）。

AIP の段階：構造はどう固定されるか

Ingest が進むと create_mets_v2.0 によって AIP METS（data/METS.<SIPUUID>.xml）が生成され、ここで構造が METS の structMap として正式に記録されます。典型的には次の 2 種類の structMap が書かれます。

:::message 厳密には「常に2種類」ではありません。physical の Archivematica default は必ず書かれますが、logical の Hierarchical は SIP Arrange で並べ替えた SIP のときだけ出力されます（SIPArrange 行が無ければ build_arranged_structmap() が None を返す）。逆に、設定によっては Normative Directory Structure など別の logical structMap が加わることもあります。本記事は「arrange して 1 SIP にまとめた」ケースを前提にしています。 :::

並べ替え後（物理）→ `structMap TYPE="physical"`

ディスク上の実レイアウト、すなわち arrange で組み替えた結果です。

<mets:structMap TYPE="physical" LABEL="Archivematica default">
  <mets:div TYPE="Directory" LABEL="objects">
    <mets:div TYPE="Item" LABEL="notes.doc">
      <mets:fptr FILEID="file-a565f459-…"/>

a/ b/ c/ に振り分けて 1 SIP にまとめた場合は、ここが objects/a/notes.doc のように入れ子の div になります。

並べ替え後（知的構造）→ `structMap TYPE="logical" LABEL="Hierarchical"`

Arrangement ペインで組んだ階層が、物理パスとは独立に記録されます。

<mets:structMap TYPE="logical" LABEL="Hierarchical">
  <mets:div LABEL="objects">
    <mets:div LABEL="notes.doc">
      <mets:fptr FILEID="file-a565f459-…"/>

並べ替え前 → AIP 内に同梱された元 transfer METS（恒久）

SIP 段階で同梱された元 transfer METS は、そのまま AIP の中に残ります。

data/objects/submissionDocumentation/transfer-flat-demo-12cec7db…/METS.xml

これにより「arrange する前にどう並んでいたか」が AIP 単体で永久に追跡可能になります。

並べ替え前↔後を結ぶリンク → ファイル UUID と PREMIS `originalName`

同じファイル UUID が元 transfer METS と AIP METS の両方に現れるので、1 ファイルごとに「元どこ → 今どこ」を辿れます（METS の FILEID 属性は file-<UUID> という形。bare な UUID は DB の不変キー＝PREMIS objectIdentifierValue で、FILEID はそれに file- を前置したもの）。なお、保存用の派生ファイル（preservation derivative）は新しい UUID を持ち AIP METS にだけ現れます。リンクされるのは元ファイル同士です。
各ファイルの PREMIS に originalName が刻まれます（実データ）：
```
<premis:originalName>%transferDirectory%objects/notes.doc</premis:originalName>
```
物理的にどこへ動かしても、取り込み時の元パスは PREMIS に残ります。
さらに data/logs/arrange.log に並べ替え操作のログも残ります。

まとめ

「並べ替えで元構造が失われる」ことはない。 元（before）と並べ替え後（after）が同じパッケージに併存し、ファイル UUID で相互リンクされる設計になっている。
SIP の段階では、
- before/after の対応は DB の main_siparrange（ただし作業用・非永続）、
- before の構造は SIP 内にコピーされた元 transfer METS（恒久）、
- after の構造は SIP の物理ディレクトリそのもの、
- 「SIP という対象だけを指す専用 METS」は生成されない（ただし structMap 入りの METS 自体は Transfer 段階で transfer METS として既に存在し、それが表すのは before の構造）。
AIP の段階で初めて、after の構造が structMap（physical Archivematica default ＋、arrange した場合は logical Hierarchical）として AIP METS に固定され、before の構造は同梱された元 transfer METS として保持される。

「並べ替えても来歴は残るのか？」という不安に対しては、並べ替え後の構造が METS の structMap という確定形になるのは AIP 生成（create_mets_v2.0）のタイミングで、そこで physical ＋ logical の structMap ＋元 transfer METS の同梱という形に落ちる、と理解しておくと挙動がすっきり追えます。

🗂️Archivematica で backlog のファイルをフォルダに並べ替えて 1 つの SIP にしたとき、元の構造と並べ替え後の構造はどこに記録されるか

前提：用語と全体の流れ

SIP の段階：構造はどこに残るか

① 並べ替え前後のマッピング → DB の `main_siparrange` テーブル

② 並べ替え前の構造 → SIP 内にコピーされる元 transfer METS（恒久）

③ 並べ替え後の構造 → SIP の物理ディレクトリそのもの

AIP の段階：構造はどう固定されるか

並べ替え後（物理）→ `structMap TYPE="physical"`

並べ替え後（知的構造）→ `structMap TYPE="logical" LABEL="Hierarchical"`

並べ替え前 → AIP 内に同梱された元 transfer METS（恒久）

並べ替え前↔後を結ぶリンク → ファイル UUID と PREMIS `originalName`

まとめ

📚METSFlaskを試す

📥DataAccessioner：受入時点でチェックサムと技術メタデータを固定するツール

🗃Archivematica の Backlog による評価選別と、開発版で廃止された Appraisal タブ

コメント

前提：用語と全体の流れ

SIP の段階：構造はどこに残るか

① 並べ替え前後のマッピング → DB の main_siparrange テーブル

② 並べ替え前の構造 → SIP 内にコピーされる元 transfer METS（恒久）

③ 並べ替え後の構造 → SIP の物理ディレクトリそのもの

AIP の段階：構造はどう固定されるか

並べ替え後（物理）→ structMap TYPE="physical"

並べ替え後（知的構造）→ structMap TYPE="logical" LABEL="Hierarchical"

並べ替え前 → AIP 内に同梱された元 transfer METS（恒久）

並べ替え前↔後を結ぶリンク → ファイル UUID と PREMIS originalName

まとめ

関連記事

📚METSFlaskを試す

📥DataAccessioner：受入時点でチェックサムと技術メタデータを固定するツール

🗃Archivematica の Backlog による評価選別と、開発版で廃止された Appraisal タブ

コメント

① 並べ替え前後のマッピング → DB の `main_siparrange` テーブル

並べ替え後（物理）→ `structMap TYPE="physical"`

並べ替え後（知的構造）→ `structMap TYPE="logical" LABEL="Hierarchical"`

並べ替え前↔後を結ぶリンク → ファイル UUID と PREMIS `originalName`