本文へ
Archival Packager

既知の限界

既知の限界

README に戻る

できないことを先に書く。 実運用で「できるはず」と思って使われると困るため。

正規化（保存用フォーマットへの変換）の範囲が狭い

組み込みの規則は 2 系統だけで、それ以外は原本のまま保存される。

入力 出力 使う道具 実際に動くか
PNG / JPEG / GIF / BMP（16 PUID） TIFF Pillow（アプリ内蔵） 常に動く
PostScript / EPS（8 PUID） PDF Ghostscript 同梱していないので、PATH に gs がある環境だけ

つまり、既定では Office 文書・音声・動画・CAD は変換されない。 原本のまま保存され、その旨が report に記録される。

規則は利用者が足せる。 書式と置き場は docs/rules.md を参照。 足せるのは「利用者の環境に既にあるコマンドを呼ぶ」規則で、アプリが外部のコードを 読み込むことはない。使った規則表そのものは AIP に同梱されるので、後から 「どの規則で作られたか」をパッケージ単体で辿れる。

ただし足りないのは規則表ではなく、変換する道具のほうである。範囲を広げるには LibreOffice（Office → PDF/A）や ffmpeg（音声・動画）が要るが、同梱すると 「インストール不要」が壊れ、ライセンスの判断も要る（Ghostscript を同梱しない理由は development.md）。

PDF/A は作らない

組み込みの postscript-to-pdf が作るのは、ふつうの PDF である。 PDF/A を作る機能は、2026年11月6日に見送った（Issue #50）。

難しいのは技術ではない。Ghostscript で PDF/A-2b を作る引数は分かっている。 問題は、それが動く機械が限られることである。

そこで、組み込みにはせず、利用者が足せる規則の例として docs/rules.md に載せた。 gs を入れられる環境で PDF/A が要る人は、それを写して使える。 その場合も、できた PDF の適合はアプリでは確かめないので、veraPDF で確かめる必要がある。

Archivematica と a3m も、適合までは確かめていない。 2026年11月7日に、両者の 規則の一覧（FPR。Archivematica main の 973c421 と a3m main の ebe6c1d の初期データ）を読んだ。

つまり、Archivematica が「PDF/A にした」と記録する PDF も、条件を満たしている保証は無い。 AP がこれに合わせて同じ規則を組み込むと、同じ不確かさを持ち込むことになる。

見直すのは、Ghostscript 以外に同梱できる PDF/A の作り方が見つかったときか、 PDF/A を求める利用者が実際に出てきたときとする。

利用用の派生物とサムネイルは作らない

DerivativePurpose に ACCESS を定義してあるが、作らない。

利用用の派生物とサムネイルは DIP（提供用情報パッケージ）に属するものであり、 このアプリが作るのは SIP と AIP だけである。品質を落とした派生物を AIP に入れても 保存上の価値はなく、容量が増えるだけになる。提供は下流のシステムの役割と考えている。

形式の適合性検査（validate）は、TIFF と PDF だけ

識別（これは何形式か）と検証（その形式として正しいか）は別の工程である。 変換で作った TIFF と PDF は、JHOVE で検証している（Archivematica が 変換後の派生物に行っている検査に相当する）。JHOVE は Java 製なので、 Java の実行環境ごと同梱している（「外部ツールの同梱方針」）。

検証は 2 段ある。

  1. 開き直し。 TIFF は Pillow で、PDF は pypdf で、もう一度開いて読めるか
  2. 形式の適合性。 JHOVE の TIFF-hul / PDF-hul で、仕様に適合しているか （”Well-Formed and valid” だけを適合とみなす）

どちらかに通らなかった派生物は AIP に入れず、原本のまま保存して report に 警告を出す。中途半端な派生物を保存用として記録するほうが、変換できなかったと 記録するより悪いため。結果はどちらも PREMIS の validation イベントとして METS に残る（成功・失敗・確かめていない、の 3 通りを書き分ける。何で確かめたかは 道具の名前と版で分かる）。

原本の TIFF・PDF・WAVE・GIF も JHOVE で検証する。ただし不適合でも捨てない。 派生物は捨てても原本が残るが、原本には代わりが無い。結果を validation イベントとして残し、report に「形式の仕様に適合しない原本」として警告を出す。 検査するのは AIP に複写した側で、入力側のファイルには触れない。

確かめていないこと:

Archivematica には実際に読み込ませていない

パッケージ構造と記述メタデータは、Archivematica と AtoM の公式仕様と項目単位で 突き合わせてある（docs/interoperability.md）。 AtoM には、2026年10月28日に AtoM 2.10.2 で実際に取り込ませた。 記述の CSV（atom-import.csv）が検査を通り、階層つきで入ることを確かめた。 手順は docs/atom-verification.md にある。 Archivematica は、まだ動かしていない。 転送の構造と AIP の構造は、 仕様の文面と合わせただけである。

個人情報の検出は 5 種別だけ

マイナンバー、クレジットカード番号、電話番号、メールアドレス、郵便番号。 氏名・住所・生年月日・口座番号などは見ていない。

適合率・再現率の実測値と、原理的な限界（12 桁は約 1/11 で検査用数字を偶然通る、など）は docs/pii-accuracy.md にある。 「検出されなかった」は「個人情報が無い」ではない。

その他