openclaw cron automation git devops

OpenClawでマルチリポジトリ管理を自動化する実践パターン

2026年06月25日 · 約 2 分で読めます

OpenClawで複数リポジトリの状態確認や定期メンテナンスを自動化する手順を解説します。最小構成から始め、ログを見ながら安全に対象範囲を広げる実践パターンです。

複数のリポジトリを運用していると、ブランチの滞留、未取得の変更、CI設定の差分、依存関係更新の見落としが少しずつ増えていきます。OpenClaw Cron を使うと、こうした定期確認をジョブ化し、結果だけを人が確認する運用に寄せられます。

結論: OpenClaw でマルチリポジトリ管理を自動化するパターンは、最小構成で始めてログを見ながら段階的に広げるのが最短です。

Background

マルチリポジトリ管理で難しいのは、1つひとつの操作ではなく、同じ確認を継続して漏れなく実行することです。手作業では担当者や実行タイミングによって確認粒度がぶれやすくなります。

最初から全リポジトリに対して修正や自動プルリクエスト作成まで行うと、失敗時の影響範囲が大きくなります。まずは読み取り中心のヘルスチェックから始め、ログと通知の形を固めてから変更操作へ広げるのが安全です。

Step-by-step

  1. 目的と対象範囲を決める

最初の自動化対象は「複数リポジトリの状態を確認して要約する」だけに絞ります。たとえば、既定ブランチとの差分、未コミット変更、最後のコミット日時、リモート取得の成否を確認対象にします。

対象リポジトリは最初から全件にせず、運用上重要な2〜3件から始めます。成功条件は「毎朝9時に全対象リポジトリを確認し、失敗したリポジトリ名と原因をログで追えること」と定義しておくと判断しやすくなります。

  1. 最小構成で設定する

まず、OpenClaw から実行するシェルスクリプトを用意します。以下は、指定した複数リポジトリで git fetch と状態確認を行う最小例です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

#!/usr/bin/env bash
set -euo pipefail

repos=(
  "/srv/repos/api-server"
  "/srv/repos/web-client"
  "/srv/repos/infra-config"
)

for repo in "${repos[@]}"; do
  echo "== ${repo} =="

  if [ ! -d "${repo}/.git" ]; then
    echo "ERROR: Git repository not found: ${repo}"
    continue
  fi

  cd "${repo}"

  # リモート状態を取得し、取得失敗もログに残す
  if ! git fetch --prune --quiet; then
    echo "ERROR: git fetch failed"
    continue
  fi

  branch="$(git rev-parse --abbrev-ref HEAD)"
  status="$(git status --porcelain)"
  last_commit="$(git log -1 --format='%h %ci %s')"

  echo "branch: ${branch}"
  echo "last_commit: ${last_commit}"

  if [ -n "${status}" ]; then
    echo "WARN: working tree has local changes"
    git status --short
  else
    echo "working_tree: clean"
  fi

  echo
done

保存後、実行権限を付与します。

1

chmod +x /srv/repo-ops/scripts/repo-healthcheck.sh

次に、OpenClaw Cron に毎朝9時のジョブとして登録します。タイムゾーンを明示し、他ジョブの状態を持ち込まないように --session isolated を指定します。

1
2
3
4
5
6

openclaw cron add \
  --name "multi-repo-healthcheck" \
  --cron "0 9 * * *" \
  --tz "Asia/Tokyo" \
  --session isolated \
  --message "cd /srv/repo-ops && bash scripts/repo-healthcheck.sh を実行し、失敗したリポジトリ名、原因、対応候補を短く要約してください。"

登録後は、ジョブ一覧でスケジュールとタイムゾーンを確認します。

1

openclaw cron list
  1. 実行結果を検証する

初回実行後は、成功・失敗のどちらでもログを確認します。特に、対象リポジトリのパス、認証、リモート取得、作業ツリーの差分が期待通りに出ているかを見ます。

通知文は長くしすぎず、「どのリポジトリで」「何が失敗し」「次に何を確認するか」が分かる形に揃えます。運用に慣れるまでは、自動修正や自動 push は入れず、読み取りと要約に限定するのが無難です。

  1. 段階的に対象を広げる

ヘルスチェックが安定したら、対象リポジトリを追加します。追加時は1回の変更で大量に増やさず、数件ずつ増やしてログ量と実行時間を確認します。

次の段階では、依存関係ファイルの存在確認、CI設定ファイルの差分検出、古いブランチの一覧化などを加えます。変更を伴う処理は、必ずドライラン、差分出力、レビュー可能なプルリクエスト作成の順に進めます。

Common pitfalls

  • タイムゾーンを指定せず、想定と違う時刻に実行される
    --tz "Asia/Tokyo" を必ず指定し、openclaw cron list で登録後の表示を確認します。サーバーのローカル時刻に依存しない形にしておくと、移設時の事故を減らせます。

  • リポジトリごとの認証方式がそろっていない
    SSH鍵、GitHub App、HTTPSトークンが混在していると、一部のリポジトリだけ git fetch に失敗します。OpenClaw を実行するユーザーで、事前に各リポジトリへ読み取りアクセスできるか確認します。

  • ジョブがローカル変更を上書きする
    最初の段階では git pull や git reset を使わず、git fetch と git status に限定します。変更操作を入れる場合は、対象ブランチ、退避方法、失敗時の復旧手順を先に決めます。

  • 対象リポジトリを一気に増やしてログが読めなくなる
    10件、20件と増やす前に、ログの見出しとエラー形式を固定します。失敗したリポジトリだけを抽出できるように、ERROR: や WARN: の接頭辞を統一しておくと運用しやすくなります。

  • 依存サービスの停止をジョブ失敗と切り分けられない
    Gitホスティング、社内VPN、ローカルLLM、通知先など、外部依存を事前に列挙します。失敗時のログには、Git操作の失敗なのか、要約や通知の失敗なのかが分かる情報を残します。

Summary

OpenClaw でマルチリポジトリ管理を自動化するなら、最初にやるべきことは大きな自動修正ではなく、安定した状態確認です。対象リポジトリを絞り、読み取り中心のジョブを登録し、ログと通知の形を固めることで運用の土台ができます。

最小構成で開始し、ログを検証し、問題がない範囲で段階的に拡張する流れを守れば、複数リポジトリの管理を無理なく自動化できます。変更操作は最後に足すものとして扱うと、失敗時の影響を抑えながら実用的な運用に育てられます。

タグ: openclaw cron automation git devops