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

Archivematica（Artefactual Systems 製のオープンソース・デジタル長期保存システム）には、受け入れた資料をすぐに保存するのではなく、いったん保留して内容を吟味してから保存対象を決める「評価選別」のための機能があります。Backlog（バックログ）と Appraisal（評価選別）です。

この機能をローカルの Docker 環境で試したところ、開発版（qa/1.x）では Appraisal タブが廃止されており、評価選別は Backlog の検索画面に集約されていることが分かりました。本記事では、評価選別がワークフロー上のどこに位置するのか、Appraisal タブがいつ・なぜ廃止されたのか、そして現行の Backlog 画面で何ができるのかを、実際に資料を投入しながら確認します。

この記事で扱う Backlog 画面の操作（検索・ファイル単位の横断検索・拡張子での絞り込み・取捨選択）は、デモ動画でも見られます（音声・字幕は生成AIによる自動生成です）。

backlog / appraisal とは

Archivematica のワークフローは、OAIS 参照モデル（Open Archival Information System、長期保存システムの国際参照モデル）に沿って Transfer → Ingest → Archival storage と進みます。SIP（Submission Information Package、提出用情報パッケージ）を作って取り込み、AIP（Archival Information Package、保存用情報パッケージ）にして格納する流れです。

評価選別は、この Transfer と Ingest の間に挟まる工程です。

Transfer →（Backlog / 評価選別）→ SIP 作成 → Ingest → AIP
  • Backlog（バックログ）: Transfer の処理（ウイルススキャン・フォーマット識別・チェックサム付与・特性抽出）は済んだものの、まだ AIP にしていない資料の保留場所です。バックログが保持するのは「転送（transfer）」であって、SIP ではありません。
  • Appraisal（評価選別）: アーカイブ学の中核概念で、「恒久保存する価値があるものを見極め、不要なものを捨てる」判断のことです。

公式マニュアルでも、Transfer の終盤に「SIP を作る」か「バックログへ送る」かを選べると説明されています。

Create SIP from transfer: gives users the chance to send the transfer to the Backlog tab, where it can be stored for processing later. Using the backlog also gives users a chance to carry out appraisal tasks. （Transfer — Archivematica 1.18 docs より）

つまり評価選別は SIP を作る「前」の工程で、選別の結果として SIP が作られます。SIP/AIP を作った「後」の修正ではない点に注意してください。なお、格納済み AIP を後から修正する場合は、評価選別とは別の Re-ingest（再取り込み） という機能を使います（メタデータのみ、あるいは再正規化を含む再処理）。

具体的な用途としては、次のような場面が想定されます。

  • 寄贈された HDD や共有ドライブのダンプなど、大量で雑多な受け入れから、重複・OS のシステムファイル・一時ファイル・機微情報などを間引く
  • 中身をレビューして、本当に残す資料だけを選ぶ
  • 選んだ資料だけで SIP を作って Ingest へ送る

注意：Appraisal タブは開発版で廃止されている

今回検証したのは Docker の開発用スタック（qa/1.x ブランチ、v1.18.0 + 開発版コミット）でした。この版では、かつて存在した独立した Appraisal タブが廃止されています。

/appraisal/ にアクセスすると 404 になり、トップナビにも Appraisal の項目はありません。

/appraisal/ にアクセスすると 404 になる

これは最近の変更で、コミット af70f1bc「Remove Appraisal tab」（Artefactual の Douglas Cerna 氏、2026-01-23）で行われました。このコミットは Appraisal タブのバックエンドと、レガシーな Angular 1.x 製のフロントエンドを削除し、SIP arrangement のデータモデル（SIPArrange / SIPArrangeAccessMapping / LevelOfDescription）もテーブルごと削除しています。

廃止の理由は、公式の Architectural Decision Record（ADR-0012「Remove appraisal」、ステータスは Proposed）と Issue archivematica/Issues#1776 に記述があります（artefactual/archivematica 側の #1776 は無関係な別 Issue なので注意）。要点は次の通りです。

  • Appraisal タブが依存する Angular などのツールが古く、セキュリティ上の懸念がある
  • 再実装・更新の労力が、現代のワークフローでの有用性に見合わない
  • 利用率が低く、より自動化された API 駆動のワークフローへ移行している

参考リンク:

重要なのは、この廃止が未リリースの開発ブランチ（qa/1.x）に限った変更である点です。確認した範囲では、最新の安定版 v1.18.0（2025-09-26 リリース）以前のリリースには Appraisal タブが残っており、公式ドキュメントにも記載があります。可視化（Analysis）やタグ付け、Arrangement によるドラッグ&ドロップでの SIP 作成といったリッチな評価選別 UI を使いたい場合は、安定版を利用することになります。

以下は、開発版で評価選別がどう統合されているかの記録です。

Docker 環境の起動

公式の開発用 Docker スタック（hack/）を使います。起動手順は別記事にまとめています（ArchivematicaをDockerで起動する）。

起動後、ダッシュボードと Storage Service は次の URL でアクセスできます（既定の認証情報は test / test）。

バックログへ資料を送る

評価選別を試すには、まず資料をバックログへ送る必要があります。Transfer の処理設定（processing configuration）で、SIP 作成の判断を「Send transfer to backlog（バックログへ送る）」にすると、AIP 化せずバックログに滞留します（処理設定については transferにおいて、processing_configを使う を参照）。

:::message Archivematica に組み込みの処理設定は default と automated の2つだけです。バックログ送りを自動化したい場合は、ダッシュボードの Administration → Processing configuration で default を複製し、「Create SIP(s)」の選択を Send to backlog にした設定を自分で作成・保存する必要があります。以下の例ではその設定を backlog という名前で保存した前提です。 :::

今回はフォーマットが混在したサンプル（documents/ に doc・pdf・rtf、images/ に svg・gif・png・tif）を用意し、上記の自作 backlog 設定を指定して、Dashboard の API（v2beta）から転送を開始しました。

# Transfer source location の UUID と、自作したバックログ送りの処理設定名を指定して転送開始
curl -s -X POST "http://127.0.0.1:62080/api/v2beta/package/" \
  -H "Authorization: ApiKey test:test" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "appraisal-demo",
    "type": "standard",
    "path": "<base64 of \"<location-uuid>:/home/appraisal-demo\">",
    "processing_config": "backlog",
    "auto_approve": true
  }'

転送が一通りのマイクロサービスを通過すると、ステータスは Move transfer to backlog で COMPLETE になり、バックログに入ります。Storage Service の API でも、package_type=transfer のパッケージとして確認できます。

Backlog 画面での評価選別

ここからが本題です。開発版では、評価選別の操作は /backlog/（トップナビの Backlog）に集約されています。

Backlog 画面。トップナビに Appraisal は無く、評価選別はこの検索画面に統合されている

画面上部に検索ボックス、検索対象フィールドのプルダウン（Any / File name / File extension / Accession number / Ingest date / Transfer UUID）、一致方法（Keyword / Phrase）、Search transfer backlog ボタン、そして Show files? チェックボックスが並びます。一覧には、バックログ送りにした転送が、名前・転送 UUID・サイズ・取り込み日とともに表示されます（投入した appraisal-demo が 3.1 MB で見えています）。右端のアクションからは、中身のダウンロードと削除が行えます。

ファイル単位で横断検索する

Show files? にチェックを入れて検索すると、検索の粒度が転送単位からファイル単位に切り替わります。バックログ全体に含まれる個々のファイルを、転送の枠を越えて一覧できます。

Show files? でファイル単位の横断検索に切り替わる

フォーマット単位で絞り込む

検索対象フィールドを File extension にすると、拡張子で横串の絞り込みができます。たとえば doc を指定すれば、バックログ全体から古い Word 文書だけを抽出できます。

拡張子 doc で旧 Word 文書を抽出

同様に tif を指定すれば TIFF 画像だけを一覧できます。

拡張子 tif で TIFF 画像を抽出

長期保存に向くフォーマットか、提供用コピーへの正規化が必要か、といった判断はフォーマット単位で進めることが多いため、この絞り込みは評価選別の実務に直結します。

確認して、残す・間引く

気になる資料は Download で手元に取り出し、中身を開いて保存する価値があるかを確認できます。逆に、保存しないと判断した資料は削除（行末の赤いボタン）で間引きます。残すものと捨てるものを切り分け、本当に守るべき資料だけを保存工程へ送り出す、という流れです。

開発版では、旧 Appraisal タブにあった可視化グラフやドラッグ&ドロップによる SIP 編成といった操作は無く、評価選別は「検索・確認・取捨選択」を中心とした構成になっています。

なお、この開発版の Backlog 画面で行えるのは 検索・ダウンロード・削除までです。そもそも「選んだ資料からSIPを作って Ingest へ送る（保存工程へ promote する）」操作は、もともと Backlog 画面ではなく Appraisal タブ側の機能（「Create SIP」「Finalize arrangement」ボタン。安定版では filesystem_ajax の copy_to_arrange / copy_from_arrange と SIPArrange データモデルが支えていた）でした。開発版ではその Appraisal タブごと廃止されたため promote 操作も失われており、Backlog 画面にも当然ありません。前述の「用途」で挙げた配列・SIP 化は、評価選別一般の説明であり、その実行には次節で触れる安定版の Appraisal タブが必要です。

原状の保存 ── 配列で構造を変えても原状は記録される

評価選別では、受け入れた資料を間引いたり、Appraisal タブの配列（Arrangement）でフォルダ階層を付与したりします。ここで気になるのが「受け入れた時のままの情報や構造は失われないのか」という点です。結論としては、捨てると決めたファイルは保存されませんが、残す資料については受け入れ時の原パス・原構造・来歴が記録・保存されます。

Archivematica はファイルごとに、受け入れ時のパス（originalLocation、不変）と、正規化や配列で変わる現在のパス（currentLocation）を別々に保持します。METS を生成するとき、PREMIS の originalName には原位置の方が書き込まれます（create_mets_v2.py）。

etree.SubElement(
    object_elem, ns.premisBNS + "originalName"
).text = f.originallocation.decode()   # 受け入れ時のパス（不変）

これを実際に確認するため、フラット（サブフォルダ無し）の3ファイル notes.doc / report.pdf / scan.tif を転送し、AIP まで処理しました。

生成された flat-demo の AIP（Stored）。METS file の View、Re-ingest アクションが見える

生成された AIP の METS を見ると、物理構造（structMap）には、原ファイルに加えて正規化された保存用コピー（report-<UUID>.pdf 等）も含まれています。

<mets:structMap TYPE="physical" ID="structMap_1" LABEL="Archivematica default">
  <mets:div TYPE="Directory" LABEL="flat-demo-30c32387-…">
    <mets:div TYPE="Directory" LABEL="objects">
      <mets:div TYPE="Item" LABEL="notes.doc">
        <mets:fptr FILEID="file-15404e14-…"/>
      </mets:div>
      <mets:div TYPE="Item" LABEL="report.pdf">
        <mets:fptr FILEID="file-18c095a7-…"/>
      </mets:div>
      <mets:div TYPE="Item" LABEL="report-8eb58fbb-….pdf"><!-- 正規化された保存用コピー -->
        <mets:fptr FILEID="file-8eb58fbb-…"/>
      </mets:div>
      <mets:div TYPE="Item" LABEL="scan.tif">
        <mets:fptr FILEID="file-c7c5ac2a-…"/>
      </mets:div>
      <mets:div TYPE="Item" LABEL="scan-9cdc87f1-….tif"><!-- 正規化された保存用コピー -->
        <mets:fptr FILEID="file-9cdc87f1-…"/>
      </mets:div>
    </mets:div>
  </mets:div>
</mets:structMap>

そして各ファイルの PREMIS originalName には、受け入れ時のフラットなパスが記録されています。

<premis:object xsi:type="premis:file">
  <premis:objectIdentifier>
    <premis:objectIdentifierType>UUID</premis:objectIdentifierType>
    <premis:objectIdentifierValue>15404e14-2584-47af-bcec-b24714731167</premis:objectIdentifierValue>
  </premis:objectIdentifier>
  <!-- ...formatName: Microsoft Word など... -->
  <premis:originalName>%transferDirectory%objects/notes.doc</premis:originalName>
</premis:object>

%transferDirectory%objects/notes.doc が、受け入れ時の原パスです。なお、ここで示した METS は配列を行わずに作成したフラットな AIP のものなので、originalName がフラットであること自体は当然です。ポイントは、配列で階層を後付けした場合でも originalName は変わらないという点で、これはソース上の仕組みから言えます。配列（SIP arrangement）は各ファイルの currentLocation（現在のパス）だけを書き換え、originalLocation（＝originalName の元）には手を付けません。originalName が受け入れ時のフラットなパスのまま残るのは、この originalLocation が書き換えられないからです（物理構造 structMap の組み立て方とは無関係）。一方、物理構造（structMap）の方は currentLocation を辿って組み立てられるので配列後の階層を反映し、配列した知的構造は別の logical な structMap（Hierarchical）に記録されます。こうして「現在の構造」と「原状」は別々の値から独立に作られ、「元はフラットだった」という事実は METS から復元できます。

加えて、配列して SIP を作っても、バックログにある受け入れ時の BagIt バッグはそのまま残ります（実体としての原状の保管）。保存後に AIP を修正したい場合は、評価選別ではなく Re-ingest（上の AIP 詳細画面の Actions にある機能）を使います。

なお、配列（Arrangement）の操作自体は、Appraisal タブを持つ安定版（v1.18.0）や公式サンドボックスで行えます。今回、別途ローカルに安定版を立てて実際に試したところ、フラットに受け入れた3ファイルを、新規作成した 2024 フォルダの下にドラッグして配列できました（2024 (3 objects)）。この状態から「Create SIP」を押すと、配列した階層構造のまま SIP が作られ、Ingest に送られます。

安定版の Appraisal タブで、フラットな転送を新フォルダ「2024」の下に配列した様子（2024 (3 objects)）

（安定版をローカルに立てる過程は別記事にまとめています。）

Playwright での操作・録画

今回の検証では、Backlog 画面の一連の操作（ログイン → 検索 → Show files → ファセット絞り込み → Download/Delete の確認）を Playwright で自動化し、操作の様子を録画しました。qa/1.x には /appraisal/ が無いことや、検索ボックスが type 属性を持たない input であること（input[type=text] ではマッチせず role=textbox で取得する必要があること）などは、実際に DOM を調べて初めて分かった点です。

まとめ

  • 評価選別（appraisal）は、SIP を作る「前」に、保存対象を見極めて選び出す工程です。SIP/AIP 作成後の修正ではありません（後者は Re-ingest）。
  • バックログは、処理済みでまだ AIP 化していない「転送」の保留場所です。
  • 開発版（qa/1.x）では独立した Appraisal タブが廃止され、評価選別は Backlog の検索画面に統合されています。廃止の理由（セキュリティ・低利用率・API 駆動への移行）は ADR-0012 に記述があります。
  • リッチな Appraisal UI を使いたい場合は、安定版（v1.18.0 以前）を利用します。

関連記事