Confluence Cloud大規模移行の罠！データ容量肥大化を防ぐアーカイブ戦略とガーベッジコレクション術
こんにちは！現場で泥臭くアジャイルコーチやシステム統合を担当している、皆さんの先輩エンジニアです。
長年、組織の「知の灯台」として活躍してきたオンプレミス版（Server/Data Center版）のConfluence。これを「いざ、Cloud版へ移行しよう！」となったとき、多くのチームが共通して陥る恐ろしい罠があります。
それは、「過去10年分の『秘伝のタレ』や『ゴミデータ』も一緒に引っ越してしまい、移行直後から検索が全く機能せず、動作が重くなり、クラウドの容量制限に引っかかる」という問題です。
Confluenceは素晴らしいツールですが、その「書きやすさ・運用のしやすさ」ゆえに、使えば使うほど不要なデータが雪だるま式に膨らんでいきます。特にCloud移行期は、この「データのメタボ化」にメスを入れる最大のチャンスです。
この記事では、Confluence Cloudへの移行を控えている、あるいは移行直後でカオスに直面しているあなたに向けて、データ容量の肥大化を防ぎ、検索性を劇的に蘇らせる「アーカイブ戦略」と「自動ガーベッジコレクション（データ整理）術」を、どこよりも丁寧に、ステップ・バイ・ステップで解説します。
これをマスターすれば、毎日の情報検索やドキュメント管理が劇的に楽になりますよ。さあ、一緒に一歩を踏み出しましょう！
—
1. なぜConfluence Cloudは「メタボ化」するのか？ その原因と罠
まずは、敵（データの肥大化）の正体を知りましょう。Confluenceのデータ容量が爆発する理由は、主に以下の3つに集約されます。
① ページ履歴（バージョニング）の無限蓄積
Confluenceは、ページを1回更新するたびに新しい「バージョン」を作成し、裏で過去のデータをすべて保持しています。
たとえば、「100MBの動画ファイルを添付したページを、ちょっとした誤字修正で10回保存し直した」とします。このとき、裏側ではなんと1GB（100MB × 10バージョン）に近い容量が消費されているケースがあるのです。
② 誰も見ない「ゴーストスペース」と「ゾンビページ」
プロジェクト終了後に放置されたスペース、退職したメンバーが作った下書き、数年前の日報……。これらが検索結果（インデックス）を汚染し、本当に見たい「今、必要な最新情報」を奥底に沈めてしまいます。
③ Cloud版特有の仕様：検索インデックスのコントロール
オンプレミス版ではシステム管理者が「インデックスの再構築」を強制実行できましたが、Cloud版ではアトラシアン側のマネージドサービスとなるため、ユーザーが自由にインデックスを再構築することはできません。つまり、「ゴミを減らして検索ノイズを減らす」という運用の重要性が、オンプレミス時代よりも遥かに高まっているのです。
—
2. 解決へのロードマップ：アーカイブ戦略とガーベッジコレクション
この問題に立ち向かうため、私たちは2つのアプローチを組み合わせます。
1. アーカイブ戦略（ルール設計）: 「どのデータを、いつ、どうやって保管庫に移すか」のルール作り。
2. ガーベッジコレクション（自動化）: ルールに沿って、システムが自動で古いデータや不要データを整理する仕組み。
難しく考える必要はありません。まずは「最も簡単で、最も効果の高い最小構成（Hello World）」から作っていきましょう！
—
3. 実践1：Confluence Automationで構築する「自動アーカイブ」
Confluence Cloudには、プログラミングなしで高度な自動処理が組める「Automation（自動化）」という神機能が標準搭載されています。これを使って、「最終更新から365日以上経過したページを、自動で『アーカイブ』状態にする」仕組みを作ってみましょう。
これが、私たちの最初の「Hello World」です！
ステップ1：Automation管理画面を開く
1. Confluenceに管理者権限でログインします。
2. 画面右上の 「設定（歯車マーク）」 をクリックします。
3. 左メニューの「グローバル自動化」または、特定のスペースの「自動化」を選択します（まずはテスト用に、特定のスペースで試すのをおすすめします）。
ステップ2：トリガー（いつ実行するか）を設定する
1. 「ルールを作成」 をクリックします。
2. トリガーの一覧から 「スケジュール済み（Scheduled）」 を選択します。
3. 以下のように設定します。
- 実行間隔: 「毎日」または「毎週1回」（例: 毎週日曜日）
- JQL（Confluenceの検索クエリ）を実行: ここにチェックを入れ、以下のCQL（Confluence Query Language）を入力します。
/ 最終更新が365日前、かつ、すでにアーカイブされていないページを対象にする /
lastModified < "-365d" AND type = "page" AND status != "archived"
> 💡 先輩のアドバイス
> まずテストするときは、`-365d`（365日前）を `-1d`（1日前）などにして、自分がテスト用に作った古いページが引っかかるか試すと安全ですよ！
ステップ3：アクション（何をするか）を設定する
1. 「新しいアクションを追加」 をクリックします。
2. アクション一覧から 「ページをアーカイブ（Archive page）」 を選択します。
ステップ4：名前をつけて公開する
1. ルール名に `[GC] 365日未更新ページの自動アーカイブ` と入力します。
2. 「有効にする」 をクリックします。
これで、システムが毎日裏側で「1年以上放置されたゾンビページ」を見つけ出し、自動的に検索結果のノイズにならない「アーカイブ」領域へ格納してくれます。これだけで、メンバーの検索ノイズは劇的に減少します！
—
4. 実践2：REST API + Pythonで古い「添付ファイル履歴」を大掃除する（ガーベッジコレクション）
Automationではページのアーカイブはできますが、「ページ履歴に紐づく、古いバージョンの巨大な添付ファイル」を一括削除することはできません。
そこで、エンジニアの出番です！
Confluence Cloudが提供している強力な REST API と Python を使って、古い添付ファイルのバージョンをスッキリ削除する「ガーベッジコレクタ（ゴミ回収スクリプト）」を動かしてみましょう。
準備：APIトークンの発行
APIを実行するには、あなたのアカウントの「APIトークン」が必要です。
1. [Atlassian API Tokens](https://id.atlassian.com/manage-profile/security/api-tokens) にアクセスします。
2. 「API トークンを作成する」 をクリックし、生成されたキーを安全にコピーしておきます。
Pythonスクリプトの実装
以下のスクリプトは、指定したページの「古いバージョンの添付ファイル」を検出し、最新バージョンだけを残して過去の不要なファイル履歴を削除（ガーベッジコレクション）するサンプルです。
import requests
from requests.auth import HTTPBasicAuth
import json
================= ユーザー設定エリア =================
DOMAIN = “your-domain.atlassian.net” # あなたのConfluence Cloudのドメイン
USER_EMAIL = “your-email@example.com” # あなたのログインメールアドレス
API_TOKEN = “your-api-token” # 発行したAPIトークン
PAGE_ID = “12345678” # テストしたいページのID
=====================================================
auth = HTTPBasicAuth(USER_EMAIL, API_TOKEN)
headers = {
“Accept”: “application/json”
}
def get_attachments(page_id):
“””ページに紐づく添付ファイルの一覧を取得する”””
url = f”https://{DOMAIN}/wiki/api/v2/pages/{page_id}/attachments”
response = requests.get(url, auth=auth, headers=headers)
if response.status_code == 200:
return response.json().get(‘results’, [])
else:
print(f”エラー: 添付ファイルの取得に失敗しました。ステータスコード: {response.status_code}”)
return []
def clean_old_attachment_versions(attachment_id, keep_version=1):
“””
指定された添付ファイルの古いバージョンを削除する。
keep_version=1 の場合、最新バージョンのみを残す。
“””
# 添付ファイルのバージョン履歴を取得
url = f”https://{DOMAIN}/wiki/api/v2/attachments/{attachment_id}/versions”
response = requests.get(url, auth=auth, headers=headers)
if response.status_code != 200:
print(f”エラー: 添付ファイル {attachment_id} のバージョン取得に失敗しました。”)
return
versions = response.json().get(‘results’, [])
# バージョン番号の大きい順（最新順）にソート
versions.sort(key=lambda x: x[‘number’], reverse=True)
# 最新バージョン(keep_version分)を除外した、古いバージョンを特定
old_versions = versions[keep_version:]
for old_v in old_versions:
v_num = old_v[‘number’]
# 古いバージョンを削除するAPIをコール
delete_url = f”https://{DOMAIN}/wiki/api/v2/attachments/{attachment_id}/versions/{v_num}”
del_response = requests.delete(delete_url, auth=auth)
if del_response.status_code == 204:
print(f”成功: 添付ファイル {attachment_id} の バージョン {v_num} を削除しました。”)
else:
print(f”失敗: バージョン {v_num} の削除に失敗しました。コード: {del_response.status_code}”)
— メイン処理の実行 —
if __name__ == “__main__”:
print(“🧹 ガーベッジコレクションを開始します…”)
attachments = get_attachments(PAGE_ID)
if not attachments:
print(“対象のページに添付ファイルは見つかりませんでした。”)
else:
for att in attachments:
print(f”対象ファイル: {att[‘title’]} (ID: {att[‘id’]})”)
clean_old_attachment_versions(att[‘id’])
print(“✨ ガーベッジコレクションが完了しました！”)
動作確認の手順
1. 上記のコードを `confluence_gc.py` として保存します。
2. 必要ライブラリをインストールします（`pip install requests`）。
3. スクリプト内の `your-domain`、`your-email`、`your-api-token`、およびテスト用の `PAGE_ID` を書き換えます。
4. コマンドラインから実行します。
python confluence_gc.py
5. 「成功: 添付ファイル…のバージョン…を削除しました。」と表示されれば、クリーンアップ成功です！
—
5. 組織を動かす！「データダイエット」を定着させる運用ルール
どんなに素晴らしい自動化スクリプトを書いても、メンバー全員が「とりあえず何でも大容量ファイルをアップロードして放置する」というマインドのままだと、いつか再び限界を迎えます。
技術的な解決と同時に、以下の「3つの運用ルール」を組織に優しく提案してみましょう。
ルール1：巨大なバイナリはConfluenceに直接置かない
動画マニュアルや重いデザインデータ、インストーラー（.exe, .dmgなど）は、Confluenceに直接添付するのではなく、SharePointやGoogleドライブ、AWS S3などの「クラウドストレージ」に格納し、Confluenceにはそのリンクを貼るルールを徹底します。これだけで容量肥大化の9割を防げます。
ルール2：スペースの「オーナー（管理者）」を必ず1名アサインする
「誰の持ち物でもないスペース」は、必ずゴミ溜めになります。すべてのスペースに必ず主担当者を決め、半年に1回、その人に「このスペースはまだ現役ですか？」とAutomationで自動通知を送る仕組みを作りましょう。
ルール3：移行時は「過去3年分」だけを移行対象にする
オンプレミスからCloudへの移行プロジェクトを進める際は、「すべてのデータを移行する」のではなく、「直近3年以内に更新されたページのみを移行し、それ以前のものはアーカイブとしてオンプレミスの読み取り専用バックアップに残す」という割り切り（スコープ制限）を強く推奨します。
—
まとめ：軽やかなドキュメント基盤で、チームのベロシティを最大化しよう
お疲れ様でした！
今回は、Confluence Cloud移行時に直面する「データ肥大化」というリアルな課題に対して、以下の武器を手に入れましたね。
- 課題の理解: なぜConfluenceは肥大化するのか（バージョン履歴と検索インデックスの罠）
- Automationによる自動化: 1年以上更新のないページを自動でアーカイブする設定
- REST APIによるガーベッジコレクション: Pythonを使った添付ファイル履歴のクリーンアップ手法
- 運用のベストプラクティス: 大容量ファイルは別ストレージへ逃がすルール
これらを実践することで、Confluenceは常に「今、チームが本当に必要としている最新の知見」だけが研ぎ澄まされた、最高のナレッジベースへと生まれ変わります。
検索スピードが上がり、欲しい情報に1秒でアクセスできるようになれば、開発チームのベロシティ（開発速度）は間違いなく向上します。
「ツールの美しさは、情報の美しさから」。
ぜひ、今回学んだテクニックを使って、あなたのチームのConfluenceを軽やかで使いやすいものに整えてみてくださいね。応援しています！