―― 本格アーカイブは「土台」で9割決まる
AtoM（Access to Memory）は、国際標準に準拠した本格的なアーカイブシステムとして、世界中の公文書館・資料館・大学・自治体で利用されています。一方で、「インストールが難しい」「サーバー要件が厳しい」といった印象を持たれることも少なくありません。
しかし実際には、AtoMが“難しい”のではなく、最初のサーバー設計や技術要件を軽視した導入が失敗を招いているケースがほとんどです。
AtoMは「簡単に始めるCMS」ではなく、「長期保存を前提とした情報基盤」であり、その思想に合った環境を用意することが不可欠です。
この記事では、AtoM導入時に必ず押さえておくべきサーバー要件・技術的前提・構成判断のポイントを、非エンジニアでも理解できるレベルで整理します。
AtoMのサーバー要件まとめ（最新版）
AtoMは単なるWebアプリケーションではなく、「検索エンジン」「メタデータ管理」「画像配信」を組み合わせた複合システムです。そのため、一般的なWordPressよりも明確なサーバー要件が定められています。まずは、AtoMが前提としている技術スタックを理解することが重要です。
OS：Linux系が前提となる理由
AtoMは公式に Linux環境（Ubuntu LTSなど） を前提として設計されています。Windows Serverでの運用は非推奨で、トラブル時の情報もほぼ存在しません。
特に自治体や資料館では「長期保守」を考える必要があるため、サポート期間の長い Ubuntu LTS（20.04 / 22.04） を選ぶのが現実的です。
PHP：バージョン依存に注意する
AtoMはPHPベースのアプリケーションですが、対応バージョンが比較的シビアです。
新しすぎるPHPでは動作しないことがあり、公式ドキュメントで指定されたバージョンに合わせることが必須になります。
「とりあえず最新のPHPを入れる」という判断は、AtoMでは失敗の元です。
Elasticsearch：AtoMの“心臓部”
AtoM最大の特徴であり、同時に最も重要なのが Elasticsearch です。
AtoMの高速検索・階層構造の横断検索は、すべてElasticsearchによって支えられています。
Elasticsearchが正しく動作しない場合、
- 検索が極端に遅くなる
- 結果が正しく表示されない
- 管理画面が不安定になる
といった問題が発生します。AtoM導入＝Elasticsearch導入と考えて差し支えありません。
メモリ要件：最低ラインを誤解しない
AtoMはメモリを比較的多く消費します。
公式には「最低2GB」と書かれていることもありますが、実運用では最低4GB、できれば8GB以上が推奨されます。
特に、検索インデックスの再構築や大量データ投入時には、メモリ不足が即トラブルに直結します。
クラウドにするかオンプレにするか？比較
AtoM導入時に必ず議論になるのが、「クラウドに置くべきか」「庁舎内サーバー（オンプレミス）にするべきか」という点です。これは技術の問題だけでなく、運用体制・予算・リスク管理にも深く関わります。
クラウドのメリットと注意点
クラウド（VPS・IaaS）の最大のメリットは、初期構築の柔軟性と拡張性です。
資料数が増えた際にスペックを上げやすく、バックアップや障害対応も比較的容易です。
一方で、自治体の場合は「クラウド利用ポリシー」「データの所在」に関する内部規定を必ず確認する必要があります。
オンプレミスの安心感と現実的な課題
オンプレミスは「自分たちの施設内にデータがある」という安心感がありますが、実際には
- ハードウェア更新
- 障害時対応
- 担当者不在時のリスク
といった運用負荷が非常に大きくなります。
小規模自治体・資料館では、オンプレはおすすめしにくいのが現実です。
ハイブリッド構成という選択肢
一部の成功事例では、
というハイブリッド構成を採用しています。
情報公開と保存の役割を分けることで、AtoMの強みを最大限に活かすことができます。
推奨スペック（資料数10,000件以上の場合）
AtoMは資料数が増えるほど真価を発揮しますが、その分サーバーへの要求も高まります。ここでは、資料数10,000件以上を想定した現実的な推奨スペックを紹介します。
CPUとメモリのバランス
CPUは高クロックよりもコア数が重要になります。
4コア以上、メモリ8GB以上を確保することで、検索・管理画面のレスポンスが安定します。
ストレージ設計の考え方
画像・PDF・動画を扱う場合、ストレージは急速に増加します。
最低でも SSD 200GB以上 を想定し、将来的な拡張余地を残す設計が必要です。
バックアップを含めた容量計算
AtoMでは「本体データ＋検索インデックス＋バックアップ」が必要になります。
実際に必要な容量は、想定の 1.5〜2倍 と考えておくのが安全です。
専門業者に依頼する際のチェックポイント
AtoM導入を外注する場合、「サーバーを立てられる業者」と「AtoMを理解している業者」は別物である点に注意が必要です。
AtoM実績の有無を必ず確認する
過去にAtoM導入実績があるかどうかは最重要項目です。
Elasticsearchやインデックス構造を理解していない業者は、後々トラブルを残します。
アップデート・保守を含めた契約か
AtoMは定期的なアップデートが前提です。
初期構築だけでなく、「その後の保守」を含めた契約かどうかを必ず確認しましょう。
属人化を防ぐドキュメント提供
構成図・設定内容・バックアップ手順などのドキュメントが残らない導入は、将来的なリスクになります。
「引き継げる形」での納品が重要です。
AtoMの技術的な注意点（アップデート・保守）
AtoMは一度入れたら終わりではありません。
長期保存を目的とする以上、継続的な保守が前提になります。
安易なアップデートは危険
PHPやElasticsearchを不用意にアップデートすると、AtoMが動かなくなるケースがあります。
必ずテスト環境で検証してから本番反映する運用が必要です。
検索インデックスの再構築タイミング
大量データ投入後や項目変更後は、インデックス再構築が必要になります。
この作業を知らずに放置すると、「検索できないアーカイブ」になってしまいます。
担当者交代を前提にする
自治体・資料館では担当者交代が避けられません。
運用手順を文書化し、「人が変わっても回る設計」にしておくことが重要です。
まとめ：AtoM導入は“基盤設計”が成否を決める
AtoMは、
という強力な特徴を持つ一方で、適当なサーバー設計では確実に失敗するシステムでもあります。
だからこそ重要なのは、
- 最初に要件を正しく理解する
- 保存と公開の役割を整理する
- 無理のないスペックと体制を組む
という「基盤設計」の段階です。
AtoMは“難しいシステム”ではありません。
「本気で残す覚悟がある組織」に応えてくれるシステムなのです。
▶ デジタルアーカイブ化を「導入すべきかどうか」から検討している方はこちら
※現状の運用を前提にご相談を承ります
