DevOps Agent × MCP × GitHubで障害修復PRを自動作成 — Runbookの落とし穴も解説

「アラームの調査レポートは届くようになった。でも、結局そのあと人間が手で直してるんだよね」

前回の記事で、CloudWatch → EventBridge → DevOps Agent の自動調査パイプラインを構築しました。アラームが鳴れば3分で調査レポートが届く——ここまでは快適です。

しかし、レポートを読んだあとの「修復」はまだ人間の手作業です。深夜に起きて、レポートを見て、コードを直して、PRを出して、レビューして……結局オンコールの負荷は半分しか減っていません。

この記事では、DevOps Agent の調査結果から MCP + GitHub 連携で修復PRを自動作成し、人間は「PRの内容をレビューして判断する」フローを構築します。ただし、GitHub連携には2種類あり、Runbook登録時に思わぬ落とし穴があったので、そこも正直に共有します。

この記事で分かること

• DevOps Agent の調査結果から GitHub PR を自動作成するまでのフロー
• GitHub MCP Server のセットアップ手順（OAuth認証）
• Runbook（スキル）の書き方と登録方法
• GitHub連携2種類（パイプライン vs MCP Server）の違いと使い分け
• Runbook登録時のプライベートリポジトリ認証の落とし穴

前提知識を確認してから、構成の全体像に入ります。

前提知識

• 前回記事の構成（CloudWatch → EventBridge → DevOps Agent）が理解できている
• GitHub リポジトリの基本操作ができる
• MCP（Model Context Protocol）: AIエージェントが外部ツールを操作するための標準プロトコル。DevOps Agent はこれを通じて GitHub や各種ツールを呼び出します

関連記事 CloudWatchアラームから3分で自動調査開始 — DevOps Agent × EventBridge構成パターン 本記事の前提となる構成です。まだ読んでいない方はこちらから。

前回のおさらいと今回のゴール

前回構築したのは「アラーム → 自動調査 → レポート」まで。今回はその先、調査結果から修復PRまで自動化します。

ポイントは2つです。GitHub MCP Server がPR作成を担い、Runbook（スキル） が「この障害にはこの修復手順」という知識を提供します。

ただし、GitHubとの接続方法が2種類あって、ここが最も混乱しやすい部分です。先に整理しておきましょう。

GitHub連携は2種類ある（パイプライン vs MCP Server）

DevOps Agent には GitHub との接続方法が2種類あり、用途が全く違います。

	パイプライン連携（ネイティブ）	GitHub MCP Server
接続場所	Capabilities → Pipeline	Settings → MCP Servers → Capabilities → MCP Servers
主な用途	デプロイ履歴の取得、コードコンテキスト参照、Runbookインポート	PR作成、Issue操作、コード検索、Actions起動
認証	GitHub App or OAuth	OAuth（推奨） or Personal Access Token
プライベートリポジトリ	対応	対応（ただしRunbookインポートには使えない）

なぜ両方必要なのか。役割が根本的に違うからです。

• パイプライン連携 = 読み取り（コンテキスト収集）: デプロイ履歴やコミット履歴を読み取り、「誰のどのデプロイで壊れたか」を特定する
• GitHub MCP Server = 書き込み（アクション実行）: 原因判明後に修復コードを生成し、ブランチを切り、PRを作成する

トレードオフではなく相互補完の関係です。パイプライン連携でRunbookをインポートし、GitHub MCP ServerでPR操作を行う。片方だけでは不十分です（この使い分けが公式ドキュメントだけでは読み取りにくい）。

構造が分かったところで、Step 1 から順に設定していきます。

【Step 1】GitHub MCP Server を DevOps Agent に接続する

GitHub MCP Server（github/github-mcp-server）は、GitHub公式のMCPサーバーです。PR作成・Issue操作・コード検索・Actions起動など、GitHubのほぼ全機能をAIエージェントから呼び出せます。

今回は PAT ではなく OAuth 認証で接続しました。GitHub MCP Server のリモート版は OAuth をネイティブサポートしており、トークン管理が不要なのがメリットです。

セットアップ手順はこうなります（OAuth認証の場合）。

1. DevOps Agent コンソールで Agent Space を開く
2. アカウントレベルで MCP Server を登録: 「Settings」→「MCP Servers」→「Add MCP Server」
3. GitHub MCP Server のリモートエンドポイントを指定し、認証方式で OAuth を選択
4. GitHub の OAuth 認可画面にリダイレクトされるので、対象リポジトリへのアクセスを許可する
5. Agent Space で有効化: 「Capabilities」→「MCP Servers」で登録した GitHub MCP Server を有効化し、AIエージェントに許可するツールを選択
6. 接続テスト: Agent Space の Chat 機能で「GitHubのリポジトリ一覧を表示して」と入力し、レスポンスが返ればOK

OAuth で接続すると、最初から全権限を渡す必要はありません。リモート版には Scope Challenges という仕組みがあり、権限が足りないツールを使おうとした時点でMCPクライアント側に追加スコープの認可を求めるチャレンジが返ります。Scope Challenges に対応したクライアントであれば、その場で承認するだけで OK です（権限を絞りすぎても即エラーにはならない）。なお、DevOps Agent と組み合わせた場合の具体的な挙動は未検証のため、実際に試す際は動作を確認しながら進めてください。

組織リポジトリの場合は Organization オーナーの承認が別途必要なこともあります。プロンプトが出ない場合は Organization の設定を確認してみてください。

PAT と OAuth で挙動が異なる部分もあるので整理しておきます。

	OAuth	Classic PAT
ツールの見え方	全ツールが見える	権限があるものだけ表示。それ以外は隠れる
権限が足りないとき	Scope Challenges でクライアントに認可を求める（クライアント依存）	ツール自体が見えないので、使えないことに気づきにくい
権限を追加するには	プロンプトをクリック	GitHub設定でPATを編集 → MCPサーバー再起動

この違いは Step 4 のハマりポイントでも出てくるので、頭の片隅に入れておいてください。MCP Server の接続が完了したら、次は Runbook を準備します。

【Step 2】Runbook（スキル）を作成・登録する

Runbook は DevOps Agent に「この障害にはこう対処する」を教えるための仕組みです。AWS では「スキル」と呼ばれ、SKILL.md ファイルとして記述します。

実際の SKILL.md はこんな感じです。

---
name: high-cpu-ecs-remediation
description: ECS タスクの CPU 高騰時に、タスク数をスケールアウトする修復手順
---

# ECS CPU 高騰の修復手順

## トリガー条件
- CloudWatch Alarm: ECS-CPU-High（CPU > 80% が5分継続）

## 調査手順
1. ECS サービスの現在のタスク数を確認
2. 直近のデプロイ履歴を確認（リグレッションの可能性）
3. CloudWatch Logs でエラーログを検索

## 修復手順
1. ECS サービスの desired count を現在値の 1.5 倍に変更する PR を作成
2. PR の description に調査結果サマリーを含める
3. Slack で oncall チャンネルに通知する

## 判断基準
- デプロイ直後の場合: ロールバック PR を作成
- 負荷増加の場合: スケールアウト PR を作成

ディレクトリ構成はこうなります。

remediation-runbooks/          # GitHubリポジトリ
├── high-cpu-ecs/
│   └── SKILL.md
├── disk-full-ec2/
│   └── SKILL.md
└── connection-timeout-rds/
    └── SKILL.md

SKILL.md はシンプルに書くのがポイントです。詳細な手順は同じディレクトリ内の別ファイル（investigation-guide.md 等）に分けておくと、後述のサイズ制限も回避できます。

登録時の落とし穴（プライベートリポジトリの認証）

ここが今回の検証で最もハマったポイントです。

Runbook を DevOps Agent にインポートするには、Agent Space の「Knowledge」→「Skills」→「Add skill」→「Import from repository」で GitHub のディレクトリ URL を入力します。

ところが、GitHub MCP Server 経由ではプライベートリポジトリから Runbook をインポートできません。

MCP Server は PR 作成やコード検索には使えますが、Runbook のインポート機能は MCP 経由ではなく Agent Space のネイティブ機能として動作します。このとき参照されるのはパイプライン連携（Capabilities → Pipeline → GitHub） の認証情報です。

回避手順はこうなります。

1. Agent Space の「Capabilities」→「Pipeline」→ GitHub を接続する（まだの場合）
2. 対象リポジトリへの読み取り権限（Read access） を許可する（この権限がないとインポート対象のリストにリポジトリが表示されません）
3. その後「Knowledge」→「Skills」から Runbook をインポートする

パイプライン連携さえ済んでいれば、プライベートリポジトリの Runbook も問題なくインポートできます。GitHub MCP Server とパイプライン連携は別々の認証チャネルなので、両方設定しておく必要があります（ここが一番「なんで？」となるポイントです）。

Runbook の準備が整ったら、いよいよ自動修復PRのフローを組み立てます。

【Step 3】自動修復PRのフローを組み立てる

パイプライン連携と GitHub MCP Server の両方が設定できたら、自動修復のフローが動きます。

全体の流れはこうです。

1. CloudWatch アラーム発火 → EventBridge → DevOps Agent が調査開始
2. Agent が Runbook（スキル）を参照し、該当する修復手順を特定
3. Runbook の指示に基づいて修復コードを生成
4. GitHub MCP Server 経由で PR を自動作成

自動生成される PR はこんな構成になります。

## 修復PR: ECS CPU 高騰 — スケールアウト対応

### 調査サマリー
- アラーム: ECS-CPU-High（CPU 92% / 閾値 80%）
- 原因推定: トラフィック増加による負荷上昇
- デプロイ直後ではない（最終デプロイ: 3日前）

### 修復内容
- ECS サービス `api-service` の desired count を 3 → 5 に変更

### 根拠
Runbook `high-cpu-ecs-remediation` に基づく対応。
調査レポート: [Investigation #12345 へのリンク]

人間がやることは、このPRの内容が正しいかレビューし、問題なければマージすることです。Agent が環境を直接変更することはない安全設計は前回と同じですが、PRの中身を確認せずにマージすると意図しない変更が本番に入る可能性があります。自動化で手間は減っても、最終判断は人間の目で行うことが大切です。

フローが動くことを確認したら、次は費用感を把握しておきましょう。

コストと制限

項目	コスト
GitHub MCP Server	無料（オープンソース）
MCP Server 接続	DevOps Agent の調査時間に含まれる（追加課金なし）
Runbook のインポート	無料
PR 作成の GitHub API	無料（GitHub の API レート制限内）
DevOps Agent 全体	$0.0083/秒（前回記事参照）

MCP Server 周りの追加コストは実質ゼロです。かかるのは DevOps Agent の調査+修復判断の時間だけです。Runbook を参照して PR を作成するまで、調査時間に +2〜3分程度の上乗せになります（変更するコードの規模や GitHub API とのやり取り回数によって変動します）。

全ての障害に Runbook を書くのは現実的ではありません。まずは頻発する既知障害の上位3〜5個から始めるのがおすすめです。オンコール対応の中で「また同じ障害か」と思うものから着手すると、費用対効果が出やすいです。

費用感を踏まえた上で、実際に構築してハマりやすいポイントを共有します。

ハマりポイント3選

1. Runbook登録のプライベートリポジトリ認証

本記事で詳しく解説した通り、Runbook のインポートには GitHub MCP Server ではなくパイプライン連携（ネイティブ） が必要です。GitHub MCP Server の PAT や OAuth が設定済みでも、Runbook インポートの認証には使われません。

→ Runbookインポートの前に、Capabilities → Pipeline → GitHub の接続を済ませておいてください。

2. OAuth / PAT の権限スコープ不足

OAuth 認証の場合、対象リポジトリへのアクセス許可が不足しているとPR作成時に 403 が返ります。特に組織リポジトリでは Organization オーナーの承認が別途必要です。

PAT を使う場合は権限スコープが重要です。Fine-grained PAT なら Pull requests: Read and write と Contents: Read and write、Classic PAT なら repo スコープが必要です。

→ OAuthならリポジトリのアクセス許可を、PATなら権限スコープを見直すと解消します。

3. SKILL.md のサイズ制限超過

Runbook のインポートには明確なハードリミットがあります。

制限	上限値
スキルディレクトリ全体（ZIP・リポジトリインポートともに）	6 MB
ディレクトリ内のファイル数	100個

また、scripts/ ディレクトリ内のスクリプトファイルは現在非対応で、インポート時に拒否されます（将来対応予定）。

→ SKILL.md はコンパクトに書き、詳細情報は同じディレクトリ内の別 Markdown ファイルに分けてください。ログダンプのような大きなファイルは入れないようにするのが無難です。

ハマりポイントを押さえれば、構成自体はシンプルです。最後にまとめます。

まとめ

前回の「アラーム → 自動調査 → レポート」に加えて、今回は MCP + GitHub 連携で「調査結果 → 修復PR自動作成」までのフローを構築しました。構成のキモは GitHub 連携が2種類ある点で、パイプライン連携（Runbookインポート用）と GitHub MCP Server（PR操作用）の両方を設定する必要があります。

Runbook 登録時のプライベートリポジトリ認証問題は公式ドキュメントでは読み取りにくい部分で、PoC で実際にハマりました。同じところで止まっている方の助けになれば嬉しいです。

まずは最も頻発する障害の Runbook を1つ書いて、Agent Space にインポートするところから試してみてください。

関連記事 AWS DevOps Agent の導入、自社でどこから始めるか 規模・体制別の導入ロードマップをまとめています。Runbook整備の優先順位付けにも使えます。

参考文献

• AWS DevOps Agent — About — DevOps Agent の概要・安全設計
• Connecting GitHub — AWS DevOps Agent — パイプライン連携（Capabilities → Pipeline）の設定手順
• Connecting MCP Servers — AWS DevOps Agent — MCP Server の登録・有効化手順
• DevOps Agent Skills — AWS DevOps Agent — Runbook（スキル）の作成・インポート仕様・サイズ制限
• AWS DevOps Agent Pricing — 料金体系（$0.0083/秒）
• GitHub MCP Server — github/github-mcp-server — GitHub公式MCP Server のリポジトリ
• Remote GitHub MCP Server is now GA — GitHub Blog — リモート版 OAuth サポート
• GitHub MCP Server Scope Filtering — Scope Challenges の仕組み
• Building an end-to-end agentic SRE — AWS Blog — DevOps Agent + MCP の統合アーキテクチャ