はじめに#
AtoM (Access to Memory) は、アーカイブ機関向けのオープンソースWebアプリケーションです。世界中の図書館・文書館・博物館で、資料記述の管理に利用されています。
AtoMの操作は通常Web UIから行いますが、REST APIを使えば外部システムとの連携やバッチ処理が可能になります。本記事では、現実的な業務シナリオ に沿ってAPIを一通り試し、Web UIでの反映も確認していきます。
APIプラグインの開発経緯や実装の詳細は、別記事 AtoMのREST APIを拡張するプラグインを開発した話 をご覧ください。
利用するAPI#
- arRestApiPlugin （AtoM標準）: 資料記述（Information Object）のCRUD
- arExtendedApiPlugin （独自開発）: 所蔵機関・典拠レコード・受入記録・タクソノミー・機能記述・デジタルオブジェクトの操作
全28エンドポイントの一覧は開発記事を参照してください。
事前準備#
APIキーはAtoMの管理画面（Settings > Global）で設定・確認できます。
業務シナリオ：「橋本市立図書館デジタルアーカイブの構築」#
ストーリー#
橋本市立図書館が、郷土史研究家の山田花子氏から寄贈された橋本市の古写真コレクション（明治〜昭和期）のデジタルアーカイブを構築する。
以下の手順で、アーカイブの構築に必要な一連の作業をAPIで実行していきます。
| Step | 業務内容 | API |
|---|
| 0 | 初期状態を確認する | GET /api/summary |
| 1 | 所蔵機関を登録する | POST /api/repositories |
| 2 | 所蔵機関の情報を確認する | GET /api/repositories/:slug |
| 3 | 連絡先情報を追加する | PUT /api/repositories/:slug |
| 4 | 寄贈者を登録する | POST /api/actors |
| 5 | 寄贈者の情報を確認する | GET /api/actors/:slug |
| 6 | 受入記録を作成する | POST /api/accessions |
| 7 | 処理ステータスを更新する | PUT /api/accessions/:slug |
| 8 | タクソノミー（分類語彙）を確認する | GET /api/taxonomies |
| 9 | 主題分類を追加する | POST /api/taxonomies/:id/terms |
| 10 | 分類名を修正する | PUT /api/taxonomies/terms/:id |
| 11 | 資料記述を作成する | POST /api/informationobjects |
| 12 | デジタル画像を添付する | POST /api/informationobjects/:slug/digitalobject |
| 13 | 最終状態を確認する | GET /api/summary |
シナリオ完了後、「追加機能の紹介」セクションで以下も解説します：
- 機能記述（ISDF）の管理: POST /api/functions
- 場所タクソノミーの管理: POST /api/taxonomies/42/terms
- 階層的な資料記述: POST /api/informationobjects（parent_id指定）
- 所蔵機関ロゴ画像: POST /api/repositories/:slug/logo
以降のcurlコマンドはすべて実行済みで、レスポンスは実データです。
Step 0: 初期状態を確認する#
まず、現在のAtoMに登録されているデータの件数を確認します。
Web UIでの確認 : トップページ
Step 1: 所蔵機関を登録する#
橋本市立図書館をアーカイブ所蔵機関として登録します。
desc_detail_id と desc_status_id はタクソノミー用語のIDです（Step 8で確認方法を説明します）。
Web UIでの確認 : 所蔵機関一覧
Step 2: 所蔵機関の情報を確認する#
作成した所蔵機関の詳細を取得します。
Step 1で指定した全フィールドが正しく登録されています。
Web UIでの確認 : 所蔵機関詳細ページ
Step 3: 連絡先情報を追加する#
所蔵機関に住所・電話番号などの連絡先情報を追加します。
Web UIでの確認 : 所蔵機関詳細ページ（連絡先情報付き）
Contact area に住所・電話番号が反映されています。
Step 4: 寄贈者（典拠レコード）を登録する#
古写真コレクションの寄贈者である山田花子氏を典拠レコードとして登録します。
0
entity_type_id: 132 は “Person”（個人）を意味します。他に 131=Corporate body（団体）、133=Family（家族）が選択できます。
Web UIでの確認 : 典拠レコード一覧
Step 5: 寄贈者の情報を確認する#
1
2
Web UIでの確認 : 典拠レコード詳細ページ
Identity area に「山田花子」「Person」、Description area に「1950年〜」「橋本市在住の郷土史研究家…」「和歌山県橋本市」が表示されています。
Step 6: 受入記録を作成する#
寄贈資料の受入記録（Accession record）を作成します。アーカイブ業務では、資料の受入れを記録・管理するために不可欠な手続きです。
3
4
主なフィールドの意味：
date: 受入日（必須項目）source_of_acquisition: 取得元（必須項目）location_information: 保管場所（必須項目）acquisition_type_id: 332 → Gift（寄贈）processing_status_id: 339 → Incomplete（未処理）resource_type_id: 330 → Private transfer（個人移管）creators: [487] → Step 4で作成した山田花子のID
Web UIでの確認 : 受入記録一覧
Step 7: 処理ステータスを更新する#
デジタル化作業を開始したので、ステータスを “In-Progress” に変更します。
5
6
確認:
7
8
Processing status が “In-Progress” に、processing_notes にデジタル化作業開始の記録が追加されています。
Web UIでの確認 : 受入記録詳細ページ
Step 8: タクソノミー（分類語彙）を確認する#
AtoMでは、エンティティ種別・記述レベル・受入種別などの値がタクソノミー（分類語彙）として管理されています。これまでのステップで使用した entity_type_id や acquisition_type_id の値は、すべてタクソノミー用語のIDです。
9
0
よく使うタクソノミー用語IDの対応表：
| タクソノミー | ID | 用語 |
|---|
| Actor Entity Types (32) | 131 | Corporate body（団体） |
| 132 | Person（個人） | |
| 133 | Family（家族） | |
| Levels of description (34) | 236 | Fonds（フォンド） |
| 239 | Series（シリーズ） | |
| 242 | Item（アイテム） | |
| Description Detail (31) | 233 | Full（完全） |
| 234 | Partial（部分） | |
| Description Status (33) | 230 | Final（最終） |
| 232 | Draft（下書き） | |
| Accession acquisition type (63) | 332 | Gift（寄贈） |
| 333 | Purchase（購入） | |
| Accession processing status (65) | 338 | Complete（完了） |
| 339 | Incomplete（未処理） | |
| 340 | In-Progress（処理中） | |
Web UIでの確認 : タクソノミー管理画面
Step 9: 主題分類を追加する#
コレクションの主題分類として「古写真」を Subjects タクソノミー（id=35）に追加します。
1
2
i18n フィールドで多言語対応が可能です。日本語名は作成時のカルチャ設定で自動保存されます。
Web UIでの確認 : Subjects タクソノミー
Step 10: 分類名を修正する#
用語名をより具体的に変更します。
3
4
Step 11: 資料記述を作成する#
いよいよ、コレクションの資料記述（Information Object）を作成します。これは既存の arRestApiPlugin の API を使います。
5
6
level_of_description_id: 242 → Item（アイテム）publication_status_id: 160 → Published（公開）repository_id: 466 → Step 1 で作成した橋本市立図書館のID
Web UIでの確認 : 資料記述一覧
Step 12: デジタル画像を添付する#
スキャンした写真画像をbase64エンコードしてアップロードします。
7
8
アップロード後、AtoMは自動的に参照用コピー（reference）とサムネイル（thumbnail）を生成します。
URLから直接インポートすることも可能です：
9
Web UIでの確認 : 資料詳細ページ
Identity area にタイトル「橋本市古写真コレクション 第1巻：明治期の橋本」や識別子「HASH-PHOTO-001」、Digital object metadata にアップロードしたファイルのメタデータが表示されています。Master file、Reference copy、Thumbnail copy が自動生成されていることも確認できます。
Step 13: 最終状態を確認する#
全ステップ完了後のデータ件数を確認します。
0
1
Step 0 の初期状態と比較すると、所蔵機関・典拠レコード・受入記録・資料記述・デジタルオブジェクトが増加しています。
Web UIでの確認 : トップページ
追加機能の紹介#
基本シナリオに加えて、arExtendedApiPlugin で利用できるその他の機能を紹介します。
機能記述（ISDF）の管理#
ISDF（International Standard for Describing Functions）に準拠した機能記述を管理できます。アーカイブ機関の業務機能を体系的に記録するための仕組みです。
2
type_id: 323 → Function（機能）。他に 324=Subfunction（副機能）が選択可能- ISDF の各フィールド（classification, dates, description, history, legislation）に対応
Web UIでの確認 : 機能記述一覧
Web UIでの確認 : 機能記述詳細
Identity area に「文化財保護」「Function」「行政機能 > 教育文化 > 文化財保護」、Context area に日付・説明・法令情報、Control area に Description identifier が表示されています。
場所（Places）タクソノミーの管理#
主題分類（Subjects）と同様に、場所（Places）タクソノミーにもタームを追加できます。
3
Web UIでの確認 : Places タクソノミー
階層的な資料記述#
AtoMでは、Fonds（フォンド）> Series（シリーズ）> Item（アイテム）という階層構造で資料を記述できます。parent_id を指定して親子関係を構築します。
4
Web UIでの確認 : 資料記述詳細（階層ツリー付き）
左側のツリーに Fonds > Series > Item の階層構造が表示されています。
所蔵機関のロゴ画像#
所蔵機関にロゴ画像をアップロードすると、一覧ページでカード表示されます。
5
Web UIでの確認 : 所蔵機関一覧（ロゴ付きカード表示）
Web UI 確認URL一覧#
各ステップで確認すべきWeb UI画面のURLをまとめます。
まとめ#
本記事では、図書館のデジタルアーカイブ構築という現実的な業務シナリオに沿って、AtoMのREST APIを一通り試しました。
APIを使うことで：
- バッチ処理 : 大量の資料データをスクリプトで一括登録できる
- 外部連携 : 他の図書館システム、デジタル化業者のシステムとのデータ連携が容易になる
- 自動化 : 受入→記述→デジタル化→公開の一連のワークフローを自動化できる
- 品質管理 : APIのレスポンスを検証することで、データの整合性チェックを組み込める
AtoMは世界中のアーカイブ機関で利用されている実績あるソフトウェアです。REST APIによる操作を活用することで、より効率的なデジタルアーカイブ運営が実現できます。
本記事の検証環境: AtoM 2.8.x (Docker), PHP 7.4, Percona 8.0, Elasticsearch 5.6