本記事では、Alfresco Governance Services Community Edition（以下AGS）の最新版（25.3.0）をDockerで起動し、REST APIを使ってレコード管理の一連のライフサイクルを体験します。
具体的には、以下の業務シナリオを想定します。
シナリオ: 契約書管理
- 業務部門が契約書を作成・登録する
- レコード管理者がレコードとして宣言し、ファイルプランに分類する
- 保持スケジュール（Retention Schedule）を設定する
- 契約終了後、カットオフ（現用→非現用）を実行する
- 保持期間（3年）の経過後、廃棄する
- 訴訟対応が発生した場合、ホールド（凍結）により廃棄を停止する
以下の前回の記事をベースに、最新版での構築手順とAPIの使い方を紹介します。
- acs-deployment: v10.2.0（2026年2月リリース）
- Alfresco Governance Repository Community: 25.3.0
- Alfresco Governance Share Community: 25.3.0
- Alfresco Search Services: 2.0.17
- Traefik: 3.6
- PostgreSQL: 16.5
セットアップ#
リポジトリのクローン#
compose fileの作成#
community-compose.yamlをベースに、Governance Services用のcompose fileを作成します。変更点は以下の3つです。
1. イメージの差し替え
| サービス | 変更前 | 変更後 |
|---|
| alfresco | alfresco/alfresco-content-repository-community:25.3.0 | alfresco/alfresco-governance-repository-community:25.3.0 |
| share | alfresco/alfresco-share:25.3.0 | alfresco/alfresco-governance-share-community:25.3.0 |
2. 認証チケットのタイムアウト対策（後述）
3. DBコネクションプールの検証設定（後述）
以下が、作成したcompose fileです。
起動後、すべてのコンテナがhealthyになっていることを確認します。
以下のURLでアクセスできます。デフォルトのログイン情報は admin / admin です。
Alfresco Shareのログイン画面が表示されます。
ログイン後のダッシュボードです。Records Managementサイトが表示されています。
Content Appからもアクセスできます。
Control Centerでは、ユーザーやグループの管理が可能です。
REST APIによるレコード管理の体験#
ここからは、REST APIを使って、契約書管理の業務シナリオを一通り体験します。
すべてのAPIコマンドはcurlで実行できます。認証はBasic認証（admin:admin）を使用します。
1. 接続確認#
まず、APIへの接続とログインユーザーの確認を行います。
2. Records Managementサイトの作成#
Governance Services の機能を使うには、まずRMサイトを作成する必要があります。通常のサイト作成APIではなく、GS専用のAPI を使用します。
!
complianceはSTANDARDとDOD5015から選択できます。DOD5015は米国国防総省の記録管理規格に準拠したモードです。今回はSTANDARDを使用します。
3. ファイルプランの確認#
RMサイトを作成すると、ファイルプラン（File Plan）が自動的に作成されます。ファイルプランはレコード管理の最上位の構造で、分類体系のルートとなります。RMサイトのダッシュボードは以下のように表示されます。
0
Share UIでファイルプランを確認すると、以下のように表示されます。
ファイルプランの中には、以下の構造が自動生成されています。
| 1 ノードタイプ | 名前 | 説明 |
|---|
rma:recordCategory | Contracts | レコードカテゴリ（後で作成） |
rma:holdContainer | Holds | ホールド（法的保全）コンテナ |
rma:transferContainer | Transfers | 移管コンテナ |
rma:unfiledRecordContainer | Unfiled Records | 未分類レコードコンテナ |
4. レコードカテゴリの作成#
業務の分類体系に合わせて、レコードカテゴリを作成します。ここでは「契約書」カテゴリを作成します。
2
3
5. レコードフォルダの作成#
カテゴリの中にレコードフォルダを作成します。レコードフォルダは、実際にレコードを格納する場所です。
4
5
Share UIでは、Contractsカテゴリの中に2026-Activeフォルダが作成されていることが確認できます。
6. ドキュメントのアップロード#
まず、通常のドキュメントライブラリ（サンプルサイト）にファイルをアップロードします。業務部門がShareやContent Appからファイルを登録する操作に相当します。
6
7
サンプルサイトのドキュメントライブラリにアップロードされたファイルは、以下のように表示されます。
7. レコードとして宣言（Declare as Record）#
アップロードしたドキュメントを「レコード」として宣言します。これにより、通常のドキュメントがレコード管理の対象となります。
8
レスポンスを見ると、以下のaspect（属性）が付与されています。
| Aspect | 説明 |
|---|
rma:record | レコードとして認識 |
rma:recordOriginatingDetails | 元のファイルの情報（場所、作成者、日時） |
rma:recordComponentIdentifier | レコード管理用の識別子 |
rma:filePlanComponent | ファイルプランの構成要素 |
この時点では、レコードは「Unfiled Records」（未分類）に配置されています。
レコードの詳細画面では、プレビューやメタデータを確認できます。
8. レコードのファイリング（分類）#
未分類のレコードを、先ほど作成したレコードフォルダに移動（ファイリング）します。
9
ファイリングが完了すると、rma:dateFiled（ファイリング日時）が設定されます。
0
ファイリング後、レコードフォルダ内にレコードが格納されていることを確認できます。
9. 保持スケジュール（Retention Schedule）の設定#
保持スケジュールは、レコードのライフサイクルを定義するものです。カテゴリに対して設定し、その配下のフォルダ・レコードに適用されます。
9-1. 保持スケジュールの作成#
1 !
isRecordLevelは、保持スケジュールをレコード単位で適用するか、フォルダ単位で適用するかを指定します。今回はフォルダ単位（false）を選択しています。既にフォルダが存在するカテゴリでは、レコードレベル（true）は設定できません。
9-2. 保持アクションの追加#
保持スケジュールに具体的なアクション（ステップ）を追加します。ここでは、Legacy APIを使用します。
!
保持アクションの追加は、v1のGS REST APIではperiodのフォーマットに問題があり、500エラーが発生する場合があります。Legacy API（/alfresco/s/api/...）を使用することで確実に動作します。
2
3
4
保持スケジュールの全体像を確認します。
5
6
使用可能な保持アクションは以下の5種類です。
| アクション | 説明 |
|---|
cutoff | カットオフ（現用→非現用への移行） |
retain | 保持（指定期間の保管） |
transfer | 移管（別の保管場所への移動） |
accession | 受入（アーカイブへの移管） |
destroy | 廃棄 |
10. レコードの完了（Complete Record）#
カットオフを実行するには、フォルダ内のすべてのレコードが「完了」（Complete）状態である必要があります。
7
8 !
Alfrescoでは「declare」という用語が2つの意味で使われます。
- Declare as Record （レコードとして宣言）: 通常ドキュメントをレコードにする操作（GS API
/files/{id}/declare） - Declare Record / Complete Record （レコード完了）: レコードのメタデータ入力が完了し、変更不可にする操作（Legacy API
declareRecordアクション）
11. カットオフの実行（現用→非現用）#
業務シナリオにおいて、契約が終了した場合を想定します。「Case Closed」イベントを完了させ、カットオフを実行します。
11-1. イベントの完了#
9
次のアクションの状態を確認すると、eventsEligibleがtrueになっています。
0
1
11-2. カットオフの実行#
2
3
カットオフ後、レコードには以下の変化が生じます。
rma:cutOff aspectが付与されるrma:cutOffDate が設定される- レコードの内容・メタデータが変更不可になる
4
確認すべき主要プロパティ:
5
11-3. 次のアクションの確認#
6
7
次のアクションは Retain（保持） で、asOfが 2029年2月15日 （3年後）に設定されています。この日付以降に保持期間が満了し、次のステップ（廃棄）が実行可能になります。
12. ホールド（法的保全）#
訴訟対応などの理由で、特定のレコードの廃棄を一時停止する必要がある場合、「ホールド」機能を使用します。
12-1. ホールドの作成#
8
9
12-2. レコードをホールドに追加#
0
ホールドに追加されたレコードは、保持期間が満了しても廃棄できなくなります。
12-3. ホールドの内容確認#
1
Share UIのHolds画面では、作成したホールドとその中のレコードを確認できます。
12-4. ホールドからの解除#
訴訟が解決した場合、レコードをホールドから解除します。
2
HTTP 204（No Content）が返れば成功です。
13. ユーザーとグループの管理#
実際の運用では、レコード管理に関わるユーザーとグループを適切に設定します。
13-1. ユーザーの作成#
3
13-2. グループの作成とメンバー追加#
4
14. 監査ログの確認#
Records Management の操作は自動的に監査ログに記録されます。RM管理コンソールからも確認できます。
5
6
15. レコードの内容取得（ダウンロード）#
7
8
ライフサイクルの全体像#
今回体験したレコード管理のライフサイクルを図にすると、以下のようになります。
9
各段階でのレコードの状態変化#
| 段階 | 操作 | 付与されるAspect | 主なプロパティ |
|---|
| レコード宣言 | declare | rma:record | rma:identifier |
| ファイリング | file | - | rma:dateFiled |
| レコード完了 | declareRecord | rma:declaredRecord | rma:declaredAt, rma:declaredBy |
| カットオフ | cutoff | rma:cutOff | rma:cutOffDate |
| ホールド | hold | rma:frozen | rma:frozenAt |
API一覧#
本記事で使用したAPIの一覧です。
GS REST API（v1）#
| 操作 | メソッド | エンドポイント |
|---|
| RMサイト作成 | POST | /api/-default-/public/gs/versions/1/gs-sites |
| ファイルプラン取得 | GET | /api/-default-/public/gs/versions/1/file-plans/-filePlan- |
| カテゴリ作成 | POST | /api/-default-/public/gs/versions/1/file-plans/-filePlan-/categories |
| レコードフォルダ作成 | POST | /api/-default-/public/gs/versions/1/record-categories/{id}/children |
| レコード宣言 | POST | /api/-default-/public/gs/versions/1/files/{id}/declare |
| レコードのファイリング | POST | /api/-default-/public/gs/versions/1/records/{id}/file |
| 保持スケジュール作成 | POST | /api/-default-/public/gs/versions/1/record-categories/{id}/retention-schedules |
| ホールド作成 | POST | /api/-default-/public/gs/versions/1/file-plans/-filePlan-/holds |
| ホールドにレコード追加 | POST | /api/-default-/public/gs/versions/1/holds/{id}/children |
| ホールドからレコード解除 | DELETE | /api/-default-/public/gs/versions/1/holds/{holdId}/children/{recordId} |
| ホールド内容確認 | GET | /api/-default-/public/gs/versions/1/holds/{id}/children |
Legacy API#
| 操作 | メソッド | エンドポイント |
|---|
| 保持アクション追加 | POST | /alfresco/s/api/node/workspace/SpacesStore/{id}/dispositionschedule/dispositionactiondefinitions |
| 保持アクション更新 | PUT | /alfresco/s/api/node/workspace/SpacesStore/{id}/dispositionschedule/dispositionactiondefinitions/{actionId} |
| 保持スケジュール確認 | GET | /alfresco/s/api/node/workspace/SpacesStore/{id}/dispositionschedule |
| 次アクション確認 | GET | /alfresco/s/api/node/workspace/SpacesStore/{id}/nextdispositionaction |
| アクション実行 | POST | /alfresco/s/api/rma/actions/ExecutionQueue |
| 監査ログ確認 | GET | /alfresco/s/api/rma/admin/rmauditlog |
| 利用可能な値一覧 | GET | /alfresco/s/api/rma/admin/listofvalues |
Alfresco REST API（v1）#
| 操作 | メソッド | エンドポイント |
|---|
| ユーザー情報取得 | GET | /api/-default-/public/alfresco/versions/1/people/-me- |
| ファイルアップロード | POST | /api/-default-/public/alfresco/versions/1/nodes/{id}/children |
| ノード情報取得 | GET | /api/-default-/public/alfresco/versions/1/nodes/{id} |
| コンテンツ取得 | GET | /api/-default-/public/alfresco/versions/1/nodes/{id}/content |
| バージョン履歴 | GET | /api/-default-/public/alfresco/versions/1/nodes/{id}/versions |
| ユーザー作成 | POST | /api/-default-/public/alfresco/versions/1/people |
| グループ作成 | POST | /api/-default-/public/alfresco/versions/1/groups |
| グループメンバー追加 | POST | /api/-default-/public/alfresco/versions/1/groups/{id}/members |
| サイト一覧 | GET | /api/-default-/public/alfresco/versions/1/sites |
時間が経つとログインできなくなる問題#
前回の記事で使用したAzure仮想マシン（8 GiB RAM）では、時間が経過するとログインできなくなる事象が確認されました。この原因について調査した結果をまとめます。
原因: メモリ不足によるスワッピング#
各コンテナのmem_limitの合計は以下の通りです。
| サービス | mem_limit |
|---|
| alfresco | 1,900 MB |
| transform-core-aio | 1,536 MB |
| share | 1,024 MB |
| solr6 | 2,048 MB |
| activemq | 1,024 MB |
| postgres | 512 MB |
| content-app | 128 MB |
| control-center | 128 MB |
| proxy (traefik) | 128 MB |
| 合計 | 約 8.4 GB |
8 GiBのVMでは、OS自体が1-2 GB使用するため、コンテナに割り当て可能なメモリは実質 6-7 GB しかありません。この結果、以下の連鎖が発生します。
0
1. VMのメモリを増やす（推奨）#
最低 12 GB 、推奨 16 GB のメモリが必要です。
2. 認証チケットの有効期限を延長する#
デフォルトでは認証チケットが 1時間 で失効します。以下の設定で延長できます（本記事のcompose fileには設定済み）。
1
3. DBコネクションプールの検証を有効にする#
長時間稼働でコネクションがリークし、認証リクエストが処理できなくなる場合があります（本記事のcompose fileには設定済み）。
2
4. 診断手順#
問題が発生した場合の確認手順です。
3
まとめ#
本記事では、Alfresco Governance Services Community Edition 25.3.0を使って、レコード管理の一連のライフサイクルをREST APIで体験しました。
- ファイルプラン → カテゴリ → レコードフォルダ の分類体系を構築
- ドキュメントの レコード宣言 → ファイリング → レコード完了
- 保持スケジュール の設定（カットオフ → 保持 → 廃棄）
- カットオフ の実行による現用から非現用への移行
- ホールド による法的保全（廃棄の一時停止）
- ユーザー・グループ管理 と 監査ログ の確認
GS REST API（v1）とLegacy APIの使い分けが必要な点など、実際に試してみて初めてわかることも多くありました。特に、保持アクションの追加はLegacy APIのほうが安定して動作するという点は、実運用でも役立つ知見です。
また、メモリ不足によるログイン不能問題の原因と対策についても整理しました。Docker環境でAlfrescoを運用する際は、十分なメモリの確保が重要です。