アートアーカイブや資料管理の現場では、
「とりあえずWordPressで始めたが限界を感じている」
「AtoMを導入したが公開向けにOmekaへ移行したい」
といったシステム乗り換えが必ず発生します。
しかし、データ移行はアーカイブ事業の中でも最も失敗が多い工程です。
理由は単純で、「データはあるが、構造が整理されていない」状態で移行に突入してしまうからです。
本記事では、AtoM・Omeka・WordPressを想定しながら、
システム移行で本当につまずくポイントと、
事前にやっておくべき準備を、実務ベースで整理します。
結論から言えば、データ移行は作業ではなく設計です。
準備が9割を占めます。
データ移行が最難関と言われる理由
システム移行が失敗する原因は、技術よりも「認識のズレ」にあります。
データ量より“構造の違い”が問題になる
多くの現場では「点数が多いから大変」と考えがちですが、実際の難所はそこではありません。問題になるのは、移行元と移行先でデータの考え方（階層・項目・粒度）が異なる点です。WordPressはフラット構造、AtoMは階層構造、Omekaはリソース＋プロパティという思想を持っています。この違いを理解せずに移行すると、項目が迷子になります。
「今あるデータ＝使えるデータ」ではない
フォルダに画像があり、Excelに情報が書いてあっても、それがそのまま移行できるとは限りません。表記揺れ、空欄、重複、意味不明な項目が混ざっていることがほとんどです。移行作業の多くは「データを運ぶ」ではなく「データを整える」作業になります。
途中で仕様変更が起きやすい
移行作業を始めてから、「やっぱりこの項目はいらない」「この情報も入れたい」という話が出がちです。これが頻発すると、CSVの作り直しや画像の再整理が発生し、現場が疲弊します。最初に仕様を固めないことが、最大の失敗要因です。
責任の所在が曖昧になりやすい
データ移行は、担当者・外注・システム会社の境界が曖昧になりがちです。「どこまでが誰の仕事か」を決めないまま進めると、ミスが起きたときに原因不明になります。
まず決めるべき5つのこと（仕様・項目・運用）
移行作業に入る前に、必ず決めておくべき前提条件があります。
移行後の“使い方”を明確にする
まず決めるべきは、「移行後に何をしたいのか」です。公開が主なのか、内部管理が主なのか、検索重視なのか。これが曖昧だと、必要な項目も構造も定まりません。システムは目的に従属します。
必須項目と任意項目を分ける
すべての情報を移そうとすると失敗します。タイトル、作家名、制作年などの必須項目と、余裕があれば入れる項目を明確に分けます。必須以外は、移行後に追加入力する前提で問題ありません。
公開・非公開の範囲を決める
移行時に混乱しやすいのが公開設定です。特に販売情報、購入者情報、連絡先などは、移行段階で分離しておかないと事故につながります。最初から「これは非公開」と決めておくことが重要です。
移行後の運用ルールを想定する
移行はゴールではなくスタートです。移行後、誰が入力し、誰がチェックし、どう更新するのかを想定しないと、せっかく移したデータがすぐ陳腐化します。
やらないことを決める
今回の移行では「やらないこと」を明確にします。過去の未整理資料をすべて移さない、古い画像は除外するなど、割り切りが必要です。
移行元のデータの“棚卸し”のやり方
データ移行は、棚卸し作業から始まります。
データの所在をすべて洗い出す
クラウド、ローカルPC、外付けHDD、USBなど、データが散在しているケースがほとんどです。まずは「どこに何があるか」を一覧化します。この作業を省くと、必ず漏れが出ます。
データ種別ごとに分類する
画像、テキスト、PDF、音声、動画など、データの種類を分けます。システムによって扱える形式が異なるため、後工程を楽にするための重要なステップです。
重複・不要データを整理する
同じ作品の画像が複数バージョン存在することは珍しくありません。どれを正式データとするかを決め、不要なものは移行対象から外します。
情報が不足しているデータを把握する
タイトル不明、制作年不明など、欠損データを洗い出します。移行前に埋めるのか、移行後に対応するのかを判断します。
CSV形式での移行時の注意点
AtoM・Omekaともに、CSV移行は基本手段です。
列名はシステム仕様に合わせる
CSVの列名がそのまま項目名になります。Dublin Coreやシステム仕様に合わせないと、正しく取り込まれません。自己流の列名はトラブルの元です。
空欄とNULLの扱いを統一する
空欄をどう扱うかは重要です。意図的に空なのか、未入力なのかを区別しないと、検索や表示で問題が出ます。
改行・記号に注意する
説明文に改行や特殊記号が含まれていると、CSVが壊れる原因になります。事前にテキストの整形が必要です。
小規模テストを必ず行う
いきなり全件移行せず、数件でテストします。これを怠ると、大量の修正作業が発生します。
画像ファイルの移行方法（命名ルール・紐付け）
画像とデータの紐付けは、移行トラブルの温床です。
ファイル名で紐付けるのが基本
CSV内のIDと、画像ファイル名を一致させる方法が最も安全です。感覚的な対応は通用しません。
命名ルールを移行前に統一する
制作年_作家名_作品名_番号など、明確なルールに揃えてから移行します。
サムネイルと原画像を分ける
公開用と保存用を分けないと、後から差し替えが困難になります。
画像欠損チェックを必ず行う
移行後、画像が表示されないケースは非常に多いため、必ず全件チェックします。
AtoM→Omeka、WordPress→AtoMの移行パターン
よくある移行パターンごとの注意点を整理します。
AtoM→Omeka：公開向け再構成が必要
AtoMの階層構造を、そのままOmekaに移すことはできません。展示単位で再設計が必要です。
WordPress→AtoM：構造の再定義が必須
WordPressの投稿はフラットなため、シリーズや資料群をどう階層化するかを決め直します。
段階移行という選択肢
一気に移さず、主要データから順に移行する方法も有効です。
移行チェックリスト（コピペ可）
最後に、最低限の確認項目です。
仕様確定チェック
目的、項目、公開範囲が決まっているか。
データ整備チェック
重複・欠損・表記揺れが整理されているか。
テスト移行チェック
小規模テストを実施したか。
運用引き継ぎチェック
移行後の担当・ルールが決まっているか。
まとめ：データ移行は“準備が9割”
データ移行の成否は、作業量ではなく準備で決まります。
移行は「整理の機会」
移行は過去を整理し、未来に備えるチャンスです。
完璧を目指さない
まず移し、育てていく視点が重要です。
設計できる人が成功させる
技術よりも、設計力が移行を成功させます。
▶ デジタルアーカイブ化を「導入すべきかどうか」から検討したい方はこちら
※現状の運用を前提にご相談を承ります
