「デプロイのたびにSlackで手動報告している」「PRが放置されてレビューが溜まっている」「本番障害時のロールバックに時間がかかる」——CI/CDパイプラインの運用課題は、多くの開発チームが抱えています。
**OpenClawとGitHub Actionsを統合すれば、これらの課題を根本から自動化できます。**Webhookでパイプラインのイベントを受信し、AI駆動でPRレビュー、デプロイ通知、ロールバック判断までを自動実行するワークフローが構築できます。
本記事では、OpenClawのスキル・cron・Webhook機能を活用したGitHub Actions統合の実装方法を解説します。

アーキテクチャ概要
統合パターン
OpenClawとGitHub Actionsの統合には、主に3つのパターンがあります。
| パターン | トリガー | ユースケース |
|---|---|---|
| Webhook受信型 | GitHub → OpenClaw | PRイベント、デプロイ通知 |
| API呼び出し型 | OpenClaw → GitHub API | ステータス確認、コメント投稿 |
| cron監視型 | 定期実行 | ビルド状況監視、メトリクス収集 |
必要なコンポーネント
- OpenClaw:エージェント基盤(スキル、cron、Webhook処理)
- GitHub Actions:CI/CDパイプライン実行
- GitHub CLI (
gh):API操作 - Slack/Discord:通知チャネル
OpenClawのスキル開発とWebhook連携の基礎を理解していることを前提に進めます。
パターン1:PR自動レビューシステム
GitHub Webhook → OpenClawのフロー
PRが作成・更新されたときに、OpenClawがコード変更をレビューし、結果をPRコメントとして投稿するフローです。
# OpenClaw スキル定義: github-pr-review/SKILL.md
---
name: github-pr-review
description: GitHub PRの自動AIレビューを実施
triggers:
- webhook: github.pull_request
---
# GitHub PR Auto Review Skill
## トリガー
GitHub Webhookの`pull_request`イベント(opened, synchronize)を受信したとき実行。
## 手順
1. Webhook ペイロードからPR番号とリポジトリを取得
2. `gh pr diff`で差分を取得
3. CLAUDE.md/AGENTS.mdの規約に基づいてレビュー
4. 結果をPRコメントとして投稿
5. 重大な問題がある場合はSlackに通知
レビュースキルの実装
#!/bin/bash
# github-pr-review/scripts/review.sh
set -euo pipefail
PR_NUMBER="${1:?PR番号が必要です}"
REPO="${2:?リポジトリ名が必要です}"
# 差分の取得
DIFF=$(gh pr diff "$PR_NUMBER" --repo "$REPO")
# 差分が空の場合はスキップ
if [ -z "$DIFF" ]; then
echo "差分なし、レビューをスキップ"
exit 0
fi
# PR情報の取得
PR_INFO=$(gh pr view "$PR_NUMBER" --repo "$REPO" --json title,body,files)
PR_TITLE=$(echo "$PR_INFO" | jq -r '.title')
CHANGED_FILES=$(echo "$PR_INFO" | jq -r '.files[].path' | head -20)
# AIレビューの実行
REVIEW_RESULT=$(cat <<EOF | claude --print
以下のPR変更をレビューしてください。
## PRタイトル: $PR_TITLE
## 変更ファイル:
$CHANGED_FILES
## 差分:
$DIFF
## レビュー観点:
1. バグの可能性がある箇所
2. セキュリティ上の懸念
3. パフォーマンスへの影響
4. コーディング規約への準拠
5. テストカバレッジの十分性
## 出力形式:
- 各指摘は「⚠️ 重要」「💡 提案」「✅ 良い点」で分類
- 具体的なコード修正案を含める
- 全体評価を5段階で
EOF
)
# PRコメントとして投稿
gh pr comment "$PR_NUMBER" --repo "$REPO" --body "## 🤖 AI Code Review
$REVIEW_RESULT
---
*OpenClawによる自動レビュー | [設定方法](https://ses-base.com/articles/openclaw-github-actions-cicd-guide/)*"
# 重大な問題があればSlackに通知
if echo "$REVIEW_RESULT" | grep -q "⚠️ 重要"; then
CRITICAL_COUNT=$(echo "$REVIEW_RESULT" | grep -c "⚠️ 重要" || true)
echo "重大な指摘が${CRITICAL_COUNT}件あります。Slackに通知します。"
fi
レビュー品質の向上テクニック
プロジェクト固有のルールを適用
# AGENTS.md にレビュー規約を追加
## コードレビュー基準
### 必須チェック(違反でブロック)
- SQL直書き禁止(SQLインジェクション防止)
- 環境変数のハードコード禁止
- console.log/print文の本番コード残存禁止
- 未使用のimport禁止
### 推奨チェック(警告)
- 関数の行数: 50行以下
- ネストの深さ: 3段以下
- マジックナンバー: 定数化を推奨
- コメント: 公開APIには必須
パターン2:デプロイ通知と監視
GitHub Actionsからの通知受信
デプロイワークフローの各ステージでOpenClawに通知を送り、Slackへのリッチな通知を実現します。
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Notify Deploy Start
run: |
curl -X POST "${{ secrets.OPENCLAW_WEBHOOK_URL }}" \
-H "Content-Type: application/json" \
-d '{
"event": "deploy_start",
"repo": "${{ github.repository }}",
"sha": "${{ github.sha }}",
"actor": "${{ github.actor }}",
"message": "${{ github.event.head_commit.message }}"
}'
- name: Build
run: npm run build
- name: Deploy to Production
run: npm run deploy:prod
- name: Notify Deploy Success
if: success()
run: |
curl -X POST "${{ secrets.OPENCLAW_WEBHOOK_URL }}" \
-H "Content-Type: application/json" \
-d '{
"event": "deploy_success",
"repo": "${{ github.repository }}",
"sha": "${{ github.sha }}",
"duration": "${{ steps.deploy.outputs.duration }}",
"url": "https://example.com"
}'
- name: Notify Deploy Failure
if: failure()
run: |
curl -X POST "${{ secrets.OPENCLAW_WEBHOOK_URL }}" \
-H "Content-Type: application/json" \
-d '{
"event": "deploy_failure",
"repo": "${{ github.repository }}",
"sha": "${{ github.sha }}",
"error": "デプロイに失敗しました"
}'
OpenClawでの通知処理
// openclaw スキル: deploy-notifier
async function handleDeployEvent(event: DeployEvent) {
const { event: type, repo, sha, actor, message } = event;
switch (type) {
case 'deploy_start':
await sendSlackMessage({
channel: '#deployments',
blocks: [
{
type: 'section',
text: {
type: 'mrkdwn',
text: `🚀 *デプロイ開始*\n📦 \`${repo}\`\n👤 ${actor}\n💬 ${message}\n🔗 <https://github.com/${repo}/commit/${sha}|${sha.slice(0, 7)}>`,
},
},
],
});
break;
case 'deploy_success':
await sendSlackMessage({
channel: '#deployments',
blocks: [
{
type: 'section',
text: {
type: 'mrkdwn',
text: `✅ *デプロイ成功*\n📦 \`${repo}\`\n⏱️ ${event.duration}\n🌐 <${event.url}|本番環境を確認>`,
},
},
],
});
// ヘルスチェック実行
await runHealthCheck(event.url);
break;
case 'deploy_failure':
await sendSlackMessage({
channel: '#deployments',
blocks: [
{
type: 'section',
text: {
type: 'mrkdwn',
text: `❌ *デプロイ失敗*\n📦 \`${repo}\`\n⚠️ ${event.error}\n🔗 <https://github.com/${repo}/actions|GitHub Actionsを確認>`,
},
},
{
type: 'actions',
elements: [
{
type: 'button',
text: { type: 'plain_text', text: '🔄 ロールバック' },
action_id: 'rollback',
style: 'danger',
},
],
},
],
});
break;
}
}
パターン3:ビルド状況の定期監視
cron監視スキル
OpenClawのcron機能でGitHub Actionsの実行状況を定期的に監視し、異常を検出します。
# cronジョブ設定(15分ごと)
# openclaw cron add --name github-actions-monitor --schedule "*/15 * * * *"
#!/bin/bash
# github-actions-monitor/scripts/check.sh
REPOS=("org/frontend" "org/backend" "org/infra")
ALERTS=""
for repo in "${REPOS[@]}"; do
# 最新のワークフロー実行を取得
RUNS=$(gh run list --repo "$repo" --limit 5 --json status,conclusion,name,createdAt)
# 失敗した実行を検出
FAILURES=$(echo "$RUNS" | jq '[.[] | select(.conclusion == "failure")]')
FAILURE_COUNT=$(echo "$FAILURES" | jq 'length')
if [ "$FAILURE_COUNT" -gt 0 ]; then
ALERTS="$ALERTS\n⚠️ $repo: ${FAILURE_COUNT}件のワークフロー失敗"
# 連続失敗の検出
CONSECUTIVE=$(echo "$RUNS" | jq '[.[] | select(.conclusion == "failure")] | length')
if [ "$CONSECUTIVE" -ge 3 ]; then
ALERTS="$ALERTS\n🔴 $repo: 3回連続失敗 — 要対応"
fi
fi
# 長時間実行中のジョブを検出
IN_PROGRESS=$(echo "$RUNS" | jq '[.[] | select(.status == "in_progress")]')
for run in $(echo "$IN_PROGRESS" | jq -c '.[]'); do
CREATED=$(echo "$run" | jq -r '.createdAt')
ELAPSED=$(( $(date +%s) - $(date -d "$CREATED" +%s 2>/dev/null || date -j -f "%Y-%m-%dT%H:%M:%SZ" "$CREATED" +%s) ))
if [ "$ELAPSED" -gt 1800 ]; then
NAME=$(echo "$run" | jq -r '.name')
ALERTS="$ALERTS\n⏰ $repo: '$NAME'が30分以上実行中"
fi
done
done
if [ -n "$ALERTS" ]; then
echo -e "$ALERTS"
# Slackに通知
fi
自動ロールバック機能
デプロイ後のヘルスチェック
#!/bin/bash
# rollback/scripts/health-check.sh
URL="${1:?URLが必要です}"
REPO="${2:?リポジトリ名が必要です}"
MAX_RETRIES=5
RETRY_DELAY=10
check_health() {
local status
status=$(curl -s -o /dev/null -w "%{http_code}" "$URL/health" --max-time 10)
[ "$status" = "200" ]
}
echo "ヘルスチェック開始: $URL"
for i in $(seq 1 $MAX_RETRIES); do
if check_health; then
echo "✅ ヘルスチェック成功 (${i}/${MAX_RETRIES})"
exit 0
else
echo "⚠️ ヘルスチェック失敗 (${i}/${MAX_RETRIES}) - ${RETRY_DELAY}秒後にリトライ"
sleep "$RETRY_DELAY"
fi
done
echo "❌ ヘルスチェック全回失敗 — ロールバックを開始"
# 前回成功したデプロイのSHAを取得
LAST_GOOD_SHA=$(gh run list --repo "$REPO" \
--workflow "deploy.yml" \
--status success \
--limit 2 \
--json headSha | jq -r '.[1].headSha')
if [ -n "$LAST_GOOD_SHA" ] && [ "$LAST_GOOD_SHA" != "null" ]; then
echo "ロールバック先: $LAST_GOOD_SHA"
# ロールバックワークフローをトリガー
gh workflow run rollback.yml \
--repo "$REPO" \
--field sha="$LAST_GOOD_SHA" \
--field reason="automated-health-check-failure"
echo "🔄 ロールバックワークフローを起動しました"
else
echo "⚠️ ロールバック先のSHAが見つかりません — 手動対応が必要です"
fi
メトリクスダッシュボード
デプロイ頻度とリードタイムの自動集計
#!/bin/bash
# metrics/scripts/collect.sh
# DORA メトリクスの自動収集
REPO="${1:?リポジトリ名が必要です}"
PERIOD="${2:-30}" # 日数
echo "📊 DORA メトリクス集計 (過去${PERIOD}日)"
echo "================================="
# デプロイ頻度
DEPLOY_COUNT=$(gh run list --repo "$REPO" \
--workflow "deploy.yml" \
--status success \
--created ">$(date -v-${PERIOD}d +%Y-%m-%d 2>/dev/null || date -d "-${PERIOD} days" +%Y-%m-%d)" \
--json createdAt | jq 'length')
echo "デプロイ頻度: ${DEPLOY_COUNT}回/${PERIOD}日 ($(echo "scale=1; $DEPLOY_COUNT / $PERIOD" | bc)回/日)"
# 変更リードタイム(PR作成 → デプロイ)
MERGED_PRS=$(gh pr list --repo "$REPO" \
--state merged \
--limit 50 \
--json createdAt,mergedAt)
if [ "$(echo "$MERGED_PRS" | jq 'length')" -gt 0 ]; then
AVG_HOURS=$(echo "$MERGED_PRS" | jq '
[.[] |
((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600
] | add / length | floor
')
echo "変更リードタイム: 平均 ${AVG_HOURS}時間"
fi
# 変更失敗率
TOTAL_DEPLOYS=$(gh run list --repo "$REPO" \
--workflow "deploy.yml" \
--created ">$(date -v-${PERIOD}d +%Y-%m-%d 2>/dev/null || date -d "-${PERIOD} days" +%Y-%m-%d)" \
--json conclusion | jq 'length')
FAILED_DEPLOYS=$(gh run list --repo "$REPO" \
--workflow "deploy.yml" \
--status failure \
--created ">$(date -v-${PERIOD}d +%Y-%m-%d 2>/dev/null || date -d "-${PERIOD} days" +%Y-%m-%d)" \
--json conclusion | jq 'length')
if [ "$TOTAL_DEPLOYS" -gt 0 ]; then
FAILURE_RATE=$(echo "scale=1; $FAILED_DEPLOYS * 100 / $TOTAL_DEPLOYS" | bc)
echo "変更失敗率: ${FAILURE_RATE}% (${FAILED_DEPLOYS}/${TOTAL_DEPLOYS})"
fi
echo "================================="
SES現場での活用シナリオ
シナリオ1:新規参画プロジェクトへの導入
SESエンジニアとして新しいプロジェクトに参画した際、OpenClaw × GitHub Actionsの自動化を提案するステップです。
- 現状分析:既存のCI/CDパイプラインを確認(GitHub Actions/Jenkins/CircleCI)
- クイックウィン:デプロイ通知のSlack自動化から始める(導入障壁が低い)
- 段階導入:PR自動レビュー → テスト品質監視 → ロールバック自動化
- 効果測定:DORAメトリクスで改善効果を定量化
シナリオ2:既存チームの生産性改善
OpenClawのチームコラボレーションと組み合わせて、チーム全体の開発効率を向上させます。
- レビュー待ち時間削減:AIレビューで即座にフィードバック → 人間レビューの負荷軽減
- デプロイ頻度向上:自動テスト + 品質ゲートで安心してデプロイ
- インシデント対応高速化:自動ロールバック + 障害通知で平均復旧時間を短縮
トラブルシューティング
よくある問題
Q: Webhook通知が届かない
- OpenClawのWebhookエンドポイントがパブリックに公開されているか確認
- GitHub Webhookの「Recent Deliveries」でHTTPステータスを確認
- ファイアウォールがGitHubのIPレンジを許可しているか確認
Q: gh CLIの認証が失敗する
GITHUB_TOKENがSecretに正しく設定されているか確認- トークンのスコープが
repo,workflowを含んでいるか確認 - Fine-grained tokenの場合、対象リポジトリが指定されているか確認
Q: AIレビューのコストが高い
- 差分サイズに応じてモデルを切り替える(小さい変更はSonnet、大きい変更はOpus)
- Draft PRはレビュー対象外にする
- 月次コスト上限を設定し、超過時はスキップ
OpenClawのコスト最適化とエラーハンドリングも参考にしてください。
まとめ|OpenClaw × GitHub Actionsで開発ワークフローを自動化
OpenClawとGitHub Actionsの統合は、SES現場の開発効率を大幅に改善します。
- PR自動レビューでコード品質を維持しつつレビュー待ち時間を削減
- デプロイ通知でチーム全体のデプロイ状況を可視化
- cron監視でビルド失敗を早期検出し、対応を迅速化
- 自動ロールバックでインシデント影響を最小化
- DORAメトリクスで改善効果を定量的に測定
段階的に導入し、まずはデプロイ通知から始めることをおすすめします。小さな成功を積み重ねて、チームの信頼を得ながら自動化範囲を拡大しましょう。
OpenClawの活用法をさらに深く学びたい方は、OpenClaw完全攻略シリーズをご覧ください。最新のテクニックを随時更新しています。