バックアップや成果物のアップロードを手作業に頼ると、実行漏れや転送先の設定ミスが発生しやすくなります。OpenClawからAWS CLIまたはGoogle Cloud CLIを定期実行すれば、転送と結果確認を一つのジョブにまとめられます。
結論: OpenClawとS3／GCSを使ったデータ転送の自動化は、転送対象を一つに限定した最小構成から始め、ログを確認しながら段階的に広げるのが最短です。
Background
最初に、転送元、転送先、実行時刻、成功条件を明確にします。例えば「毎日9時に前日分のファイルをS3へ同期し、コマンドが終了コード0で完了すること」のように定義します。
自動化する前に、対象ホスト上でCLIから転送できることを確認してください。OpenClawのジョブだけを先に設定すると、認証や権限の問題を切り分けにくくなります。
必要なCLIが利用できるか確認します。
1
2
3
openclaw --version
aws --version
gcloud --version
S3を使用する場合はIAMロールなど、GCSを使用する場合はサービスアカウントなど、対話操作を必要としない認証方式を推奨します。長期的なアクセスキーをスクリプトへ直接記述しないでください。
Step-by-step
1. 転送対象と成功条件を決める
初回は一つのディレクトリと一つの転送先だけを対象にします。削除同期や複数バケットへの転送は、通常の同期が安定してから追加します。
例として、次の条件で設定します。
- 転送元:
/srv/export - 転送先: S3またはGCSの専用バケット
- 実行時刻: 毎日9時（日本時間）
- 成功条件: 同期コマンドが終了コード0で完了する
- 失敗時の対応: ログを確認して手動で再実行する
2. 転送スクリプトを用意する
Amazon S3へ転送する場合は、次のスクリプトを /usr/local/bin/sync-to-s3.sh として配置します。転送先のURIは実際のバケット名へ変更してください。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#!/usr/bin/env bash
set -Eeuo pipefail
readonly SOURCE_DIR="/srv/export"
readonly S3_URI="s3://example-backup/export"
if [[ ! -d "${SOURCE_DIR}" ]]; then
echo "ERROR: 転送元が存在しません: ${SOURCE_DIR}" >&2
exit 1
fi
echo "S3への同期を開始します: ${SOURCE_DIR} -> ${S3_URI}"
aws s3 sync "${SOURCE_DIR}/" "${S3_URI}/" --only-show-errors
echo "S3への同期が完了しました"
Google Cloud Storageへ転送する場合は、次のスクリプトを /usr/local/bin/sync-to-gcs.sh として配置します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#!/usr/bin/env bash
set -Eeuo pipefail
readonly SOURCE_DIR="/srv/export"
readonly GCS_URI="gs://example-backup/export"
if [[ ! -d "${SOURCE_DIR}" ]]; then
echo "ERROR: 転送元が存在しません: ${SOURCE_DIR}" >&2
exit 1
fi
echo "GCSへの同期を開始します: ${SOURCE_DIR} -> ${GCS_URI}"
gcloud storage rsync --recursive "${SOURCE_DIR}/" "${GCS_URI}/"
echo "GCSへの同期が完了しました"
使用するスクリプトへ実行権限を付与し、OpenClawを実行するユーザーで手動テストします。
1
2
3
4
5
6
sudo chmod 0755 /usr/local/bin/sync-to-s3.sh
/usr/local/bin/sync-to-s3.sh
# GCSを使用する場合
sudo chmod 0755 /usr/local/bin/sync-to-gcs.sh
/usr/local/bin/sync-to-gcs.sh
初期運用では、転送先からファイルを削除するオプションを追加しないでください。設定ミスがあると、必要なバックアップまで削除される可能性があります。
3. OpenClawへ定期ジョブを登録する
S3転送を毎日9時に実行する場合は、次のように登録します。
1
2
3
4
5
6
openclaw cron add \
--name "daily-s3-sync" \
--cron "0 9 * * *" \
--tz "Asia/Tokyo" \
--session isolated \
--message "/usr/local/bin/sync-to-s3.sh を実行し、成功または失敗と、その理由を簡潔に要約してください"
GCSを使用する場合は、ジョブ名とスクリプトを変更します。
1
2
3
4
5
6
openclaw cron add \
--name "daily-gcs-sync" \
--cron "0 9 * * *" \
--tz "Asia/Tokyo" \
--session isolated \
--message "/usr/local/bin/sync-to-gcs.sh を実行し、成功または失敗と、その理由を簡潔に要約してください"
--session isolatedを指定すると、定期ジョブを通常の対話セッションから分離できます。ジョブの指示には、実行するスクリプトの絶対パスと、期待する報告内容を明記します。
4. 実行結果を検証する
初回実行後は、OpenClawの実行結果だけでなく、転送先にもファイルが存在することを確認します。
1
2
3
4
5
# S3の場合
aws s3 ls "s3://example-backup/export/" --recursive
# GCSの場合
gcloud storage ls --recursive "gs://example-backup/export/**"
少なくとも数日間は、開始時刻、終了時刻、転送件数、エラー内容を確認します。失敗時に同じスクリプトを手動実行できる状態にしておくと、復旧手順も単純になります。
Common pitfalls
- タイムゾーンがUTCのままになっている:
--tz "Asia/Tokyo"を明示し、初回実行時刻を確認します。ホストOSのタイムゾーンだけに依存しないでください。 - OpenClawの実行ユーザーに認証情報がない: 対話中のユーザーではなく、実際にジョブを動かすユーザーで転送スクリプトを実行して検証します。
- バケット権限が広すぎる、または不足している: 転送先のプレフィックスに必要な読み書き権限だけを付与します。権限変更後は小さなテストファイルで確認します。
- 相対パスを使用している: cronジョブでは作業ディレクトリが想定と異なる場合があります。スクリプト、転送元、ログには絶対パスを使用します。
- 削除同期を最初から有効にしている:
--deleteなどの削除オプションは、転送方向と対象範囲を十分に検証してから追加します。 - 一時ファイルを転送してしまう: アプリケーションが書き込み中のファイルは、別ディレクトリへ確定後に移動してから同期します。
- 依存サービスが停止している: OpenClaw、AWS CLIまたはGoogle Cloud CLI、ネットワーク接続を監視対象に含めます。ローカルLLMを利用する構成では、そのプロセスの稼働状態も確認します。
Summary
OpenClawとS3／GCSを組み合わせると、定期的なデータ転送と結果の要約を自動化できます。まずCLIによる転送を単独で検証し、その後OpenClawのcronジョブへ登録する順序が重要です。
一つの転送処理から開始し、ログ、認証、転送先の実データを確認してから対象を広げてください。この流れを守ることで、設定ミスやデータ削除のリスクを抑えながら安定した運用へ移行できます。