名前付けルール(ファイル名・フォルダ名)の完全マニュアル
フォルダ構造の作り方|アーカイブで失敗しないための原則
デジタルアーカイブの構築において、最も残酷な現実は「完成した瞬間から劣化が始まる」ということです。データの増加、OSやブラウザのアップデート、そして何より担当者の交代。これらの変化に耐えられないアーカイブは、数年も経てば「開かずの間」のようなデータの墓場と化してしまいます。
未来に耐えうるアーカイブとは、単に現在の資料を整理するだけのものではありません。10年後の担当者が迷わず運用でき、20年後の最新AIが情報を読み解ける、「拡張性」を内包した骨格を持つものです。本記事では、長期運用を見据えた持続可能なアーカイブ構造の作り方を解説します。
アーカイブは「点」ではなく「線」のプロジェクトです。時間が経過するほど、初期設計の甘さが露呈し、運用を圧迫し始めます。
運用開始当初は数百件だったデータも、数年も経てば数千、数万件へと膨れ上がります。初期に「とりあえず」で作ったフラットなフォルダ構造や、曖昧な分類は、データ量が増えるほど検索性を著しく低下させます。また、ストレージの容量不足や、一覧表示の遅延など、物理的なパフォーマンス低下も必ず発生します。増加を前提としたスケーラブルな構造が不可欠です。
アーカイブの最大の敵は、初代担当者の退職です。「あの資料はどこにあるか」「この数字はどういう意味か」といった暗黙知が引き継がれないと、アーカイブは維持できなくなります。特に、特定の個人にしか分からない独自の命名ルールや、マニュアル化されていないワークフローは、組織としての記憶を消去してしまうリスクを孕んでいます。
システムの寿命は、アーカイブの寿命よりも圧倒的に短いです。サーバーの保守期限、PHPなどの言語バージョンの終了、あるいは利用しているクラウドサービスの終了など、外部要因による強制的な変化が必ず訪れます。特定のシステムに依存しすぎた構造を作ってしまうと、技術的な寿命が来た瞬間に全てのデータが凍結される恐れがあります。
メタデータの項目(フィールド)は、アーカイブの「遺伝子」です。後から変更するのは極めて困難なため、最初から「足せる・引ける」柔軟性を持たせます。
独自の項目を勝手に作るのではなく、「ダブリン・コア(Dublin Core)」などの国際的なメタデータ標準をベースにします。タイトル、作成者、日付といった共通の「型」を守ることで、将来的に外部のデータベースと連携したり、別のシステムへデータを移行したりする際の互換性が保証されます。独自項目は最小限に留め、標準項目との紐付けを明確にしましょう。
データ項目には「必須項目」と「任意項目」を明確に設けます。最初から100個の項目を埋めようとすると、入力コストが高すぎて運用が破綻します。まずは5〜10程度の必須項目で運用を開始し、資料の種類や必要性に応じて「拡張項目」を付け足せる構造にします。データベースの設計段階で、後からのフィールド追加が容易な形式を採用することが重要です。
「日付を和暦にするか西暦にするか」「作家名を苗字と名前の間で空けるか」といったルールを厳密に定めます。可能であれば、自由入力ではなく選択式(プルダウン)や、外部の典拠データ(国立国会図書館の著者名典拠など)とのリンクを活用します。データの記述形式が統一されていることは、将来の高度な検索やAI解析を可能にするための必須条件です。
ファイル名やディレクトリの構造は、システムがなくても「人間が中身を理解できる」最後の生命線です。
ファイル名に「ポスター_2024年_展示会.jpg」のような日本語名を使うのは避けましょう。OSの違いによる文字化けや、システム読み込みエラーの原因になります。推奨されるのは、不変のID(例:ART_0001_v1.jpg)をベースにした命名です。意味のある情報はメタデータに持たせ、ファイル名はシステムの「住所」として機能させるのが、最も確実な管理手法です。
サーバー上のフォルダ階層を、あまりに細かく分類(例:/2024/05/Exhibition/A-Artist/Photo/)しすぎないようにしましょう。資料の分類が変わるたびにフォルダ移動が発生し、リンク切れを招きます。物理的なフォルダは「登録年」や「一連番号」などのシンプルな管理用とし、複雑な分類はシステムの「カテゴリ機能」や「タグ」で表現する設計が、長期的なメンテナンス性を高めます。
オリジナルデータ(RAWや高解像度TIFF)と、公開用データ(JPEGやWebP)を明確に分けて保存します。また、ファイルを上書きせず、修正が必要な場合は「_rev01」のように世代管理を行うルールを徹底します。10年後に「もっと高画質で書き出したい」と思ったとき、オリジナルのマスターファイルがどこにあるか即座に特定できる構造が必要です。
現在のシステムは、いつか必ず捨てるときが来ます。その際に「データだけを綺麗に救い出せるか」が勝負です。
システム固有の機能(特定のプラグインなど)にデータを閉じ込めないようにしましょう。理想的なのは、いつでも「CSV」や「XML」「JSON」といった汎用的な形式で全データを一括書き出しできる状態です。定期的にバックアップを兼ねてデータを書き出し、別のシンプルなスプレッドシート等で内容が再現できるかを確認する「避難訓練」を行っておくべきです。
画像配信において、国際規格である「IIIF」を採用しておけば、将来システムを入れ替えても、ビューアの互換性や外部サイトへの画像埋め込みを維持しやすくなります。特定のシステム専用の画像管理方法に依存せず、世界標準のプロトコルに乗ることで、アーカイブの「公共性」と「持続性」が飛躍的に向上します。
YouTube動画や外部SNSの埋め込みなどは、外部サービスの仕様変更によってリンク切れを起こすリスクがあります。アーカイブの本体データと、これら外部のリソースは「疎結合(ゆるい繋がり)」にしておき、外部サービスが止まってもアーカイブの根幹(メタデータとマスター画像)には影響が出ないように設計します。
今後10年で、アーカイブは「人間が探すもの」から「AIが解析し、繋ぐもの」へと進化します。
AIがデータを正しく理解するためには、情報の構造化が不可欠です。「1990年代の作品」という曖昧な記述だけでなく、「制作開始年:1992」「制作終了年:1994」といった数値データとして独立させておきます。AIは構造化されたデータを好みます。項目を細かく分け、データ型(数値、日付、真偽値など)を正確に定義することが、AI時代のアーカイブの準備となります。
自館のデータだけで完結させず、外部の概念と繋がるための「URI(一意の識別子)」を意識します。例えば、作家名に「ウィキデータ」のIDを紐付けておくことで、AIは「この作家は誰か」を外部の膨大知識と結びつけて解釈できるようになります。情報の「孤島」を作らず、世界のデータ網の一部になる設計こそが、未来の拡張性をもたらします。
高品質なアーカイブデータは、将来、生成AIや解析AIの学習用データセット(コーパス)として価値を持ちます。そのためには、データの偏りをなくし、精度の高い「正解ラベル(正確な説明文)」が付与されていることが重要です。将来のAIが、あなたのアーカイブから新たな美術史の発見をするかもしれない。そのための「良質な教科書」を作る意識が求められます。
どんなに優れたシステムも、ルールがなければ「ゴミ溜め」になります。マニュアルはアーカイブの「憲法」です。
「新しい資料が届いたら、まずどこに置くか」「スキャンの解像度は何dpiか」「メタデータの空欄はどう埋めるか」。これらを網羅したガイドラインを、図解入りで作成します。マニュアルは紙やPDFで放置せず、アーカイブの管理画面からいつでも参照できる場所に配置(またはWiki形式で運用)し、常にアップデートし続ける仕組みを作ります。
半年に一度、あるいは一年に一度、データの「棚卸し」を行う期間を設けます。重複データの削除、表記揺れの修正、リンク切れのチェック。この地味なメンテナンス作業をスケジュールに組み込むことで、アーカイブの鮮度が保たれます。システムの自動チェック機能(バリデーション)を導入し、不正な形式のデータが入力されないよう物理的に制限をかけることも有効です。
アーカイブの重要性を、担当者レベルではなく組織全体(あるいは作家であればその親族やエージェント)で共有しておきます。予算の確保、データのバックアップ保管場所の共有、そして次代への引き継ぎ期間の設定。これらを「組織のルール」として明文化しておくことが、システム設計以上にアーカイブを長生きさせる秘訣です。
未来の拡張を見据えたアーカイブ構造とは、「変化を受け入れる余白」を持った構造のことです。
最初に手間をかけて「骨格」を正しく設計することは、未来の担当者への最大の贈り物であり、あなたの作品や活動が、100年後の未来でも「発見可能」であるための唯一の保証なのです。