【GitHub Copilot Agent × MCP GitHub, Atlassian】 AI Agent に障害調査・解決を代行させながら作業ログを残させるSRE活用事例

SRE AI活用 MCPサーバー Copilot Agent GitHub Confluence 技術本部

あいさつ

こんにちは！ 技術本部 技術戦略Div. リードエンジニアの関根です！
2024年9月にジョインして、コツコツSRE活動を進めておりますっ
最近は、SRE活動のスピードアップのため、AI Agent × MCPサーバーを活用した業務の効率化に取り組んでいます。

最近、長編小説がスイスイ読めるようになってきて、良い意味で「歳とったなぁ」と感じています。
『プロジェクト・ヘイル・メアリー』は、何も情報を入れずにぜひ読んでほしい大傑作です。

あとお酒が大好きなので、社内外問わず飲みに行きましょうね！！

この記事はなに？

想定読者

  • AI Agent × MCPサーバーをあまり使用したことがない人
  • AI Agent × MCPサーバーを触ったことはあるが、複数を組み合わせたことがない人
  • 実際の業務に近い、AI Agent × MCPサーバーの活用例がイメージできていない人

逆にAIに慣れ親しんでいる方は、「こんなカスタムインストラクション使っているんだな」といった視点で、参考になれば幸いです！

ゴール

  • 調査・運用などの業務をAgentに代行して対応させることをイメージできる状態

事前準備・前提

使用する IDE, AI Agent, MCPサーバー

  • IDE
    • VSCode（バージョン: 1.102.0）
  • AI Agent
    • GitHub Copilot Agent
      • GitHub Copilot（バージョン: 1.350.0）
      • GItHub Copilot Chat（バージョン: 0.29.1）
  • AI で使用するモデル
    • Claude Sonnet 3.7
  • リモートMCPサーバー
    • GitHub
    • Atlassian

前提として、すでに VSCode で GitHub Copilot Agent を使用できる状態を想定しています。

MCPサーバーのセットアップ

リモートMCPサーバーのセットアップ方法は、VSCode 拡張機能画面から対象のMCPサーバーを検索してインストールすればOKです。
もしうまくいかない場合は、下記の公式ページを参照して行なってください。

セットアップ完了している状態の mcp.jsonは下記のようになっています。

  {
    "servers": {
      "github": {
        "type": "http",
        "url": "https://api.githubcopilot.com/mcp/"
      },
      "atlassian": {
        "type": "http",
        "url": "https://mcp.atlassian.com/v1/sse",
        "gallery": true
      }
    },
    "inputs": []
  }

MCPサーバーのツールセット数の制限

MCPサーバーのツールセットは、120までしか使用できません。
GitHub と Atlassian のMCPサーバーを使用する場合、すべて合わせると132個のツールセットがあり、12個を無効化する必要があります。

特定のツールセットの無効化は Copilot chat のツールマークを押して、不要なツールセットのチェックを外すことで可能です。

その時に応じて、メインで GitHub MCP を使用する作業では、不要な Atlassian のツールセットを無効化するなど、必要なツールセットを選択してください。

ポイント

作業依頼時のポイント

  • AI Agentに、適切な指示（条件・ゴール設定）を与えること
  • AI Agentに、適切なコンテクストを与えること
    • 多過ぎず、少な過ぎないこと
    • コンテクストの形式が、Agentの理解しやすいデータ形式であること

カスタムインストラクションは、GitHub Copilot のベストプラクティスに下記のように書かれています。

リポジトリにカスタム指示を追加することで、プロジェクトを理解し、その変更をビルド、テスト、検証する方法を Copilot に指示できます。
リポジトリ内の単一のファイル.github/copilot-instructions.mdに指示を追加することも、リポジトリ内の異なるファイルやディレクトリに適用する1つ以上のファイル.github/instructions/**/*.instructions.mdを作成することもできます。

実感として、作業依頼時に作業条件を明示、カスタムインストラクションに成果物のフォーマットを明示することで、高い質のアウトプットが得られます。
たとえば人間同士でも、若手エンジニアに高い質のアウトプットを求める際に、ベテランエンジニアが作ったガイドラインやアウトプットフォーマットを参照することがあります。
逆に、「なんとなくいい感じでやっといて」と依頼すると、レビュアーの指摘が山のようになったりしますよね。
基本的にはそれと同じ理屈で、Agentに対してもコミュニケーションが明確であれば驚くほどに「これが欲しかった」というアウトプットが出てきます。

コンテクストに関しても同じことです。
結局、質の高いアウトプットとは、依頼者と作業者の認識のズレが少ないものであり、それをいかに無くすかの勝負だと思います。
（良い意味で予想を超えるものが出てくることはもちろんありますが、まずはズレを無くすところからという意味合いです。）

作業依頼後のポイント

基本的に、AI Agentが行った作業でも、最終的な質の担保として人間の確認・承認が必要と考えています。
つまり、AI Agentに作業を依頼した後は、アウトプットの確認が必要です。

その際、アウトプットフォーマットをカスタムインストラクションで定義してあれば、80点以上は取れる印象です。
しかし、残りの差分を埋めるためには、「AI Agent がどのような思考・作業過程でアウトプットを作成したのか」に着目する必要があります。

そのために、作業ログを残すことが重要と考えています。
作業ログの意義は、下記です。

  • Agentが誤った判断をした場合に、その過程を追うため
  • それを追うことで、何がわかっていないのかを明確にして、指示やカスタムインストラクションの改善に役立てる
  • 誤った作業の戻しを行う際に、どのような作業を行ったかを確認するため

Copilot Agent に作業ログをつけさせながら障害対応を代行させる

概要

ここから、GitHub Copilot Agent と MCPサーバーを使用して、障害調査・解決の業務を代行させながら作業ログを残す方法について例示します。
例ですので、単純に解決できるものを選んでいます。実際の業務に合わせてアレンジしてみてください。

また、今回は Agent の Auto Approve 機能は使用せずに行います。

発生した事象・対応シナリオのイメージ

あるリポジトリにおいて、定期実行しているCIパイプラインが失敗していることがSlackに通知されました。
運用担当であるあなたは、まだそれが失敗したことしか知りませんが、障害調査・解決をする必要があります。

Agent に対応させたいこと

  • 障害調査
    • 失敗したパイプラインを読み込む
    • 原因と解決法を提示する
  • 障害の解決
    • コード修正
    • ローカルで単体テスト
    • 影響範囲の分析
    • コミット・プッシュ
  • アウトプットを適切な場所へ格納し直す
    • 作業ディレクトリにあるファイルを、コンフルエンスへコピーする
  • PR作成
    • PR の Overview に、アウトプットのリンクを貼る

アウトプット・成果物のリスト

  • 作業ログ
  • 障害調査報告書
  • 単体テスト結果
  • 影響範囲分析結果
  • PR

カスタムインストラクションのディレクトリ構成

.github/
  copilot-instructions.md # 共通設定
  /instructions/
    work-log-instructions.md # 作業ログ
    investigation-instructions.md # 障害調査報告書
    development-process-instructions.md # 開発フロー
    /development-process/
      python-unit-test-instructions.md # Pythonの単体テスト
      impact-analysis-instructions.md # 影響範囲分析
      commit-message-instructions.md # コミットメッセージ
      pr-overview-instructions.md # PR

できるだけその作業に必要な指示のみを与えるため、ファイルを分けています。
こんなに分けなくても良いのでは、と思うかもしれませんが、自分としては分けたほうがより正確に作業してくれるという実感があります。

copilot-instructions.md は、下記のように書かれています。
このファイルは毎回読み込まれます。

## 概要
Copilot Agentで作業する場合のルールを記載

## 共通

### 言語ルール
- 日本語を使用する
- ですます調や冗長な表現は避ける

## 作業ログ
作業ログは、アウトプットに指定がなくても必ず作成する
そのため、下記のルールを作業開始時に必ず読み込むこと
ルール: [作業ログの作成・編集ルール](./instructions/work-log-instructions.md)

## 障害調査
障害調査が依頼された場合 または アウトプットに障害調査報告書が指定された場合は、下記のルールを読み込んでから作業を開始すること
ルール: [障害調査報告書の作成・編集ルール](./instructions/investigation-instructions.md)

## 開発
開発が依頼された場合は、下記のルールを読み込んでから作業を開始すること
ルール: [開発フロー](./instructions/development-process-instructions.md)

また、どの作業でも作成すべき作業ログのルールは、下記のように書かれています。

# 作業ログの作成・編集ルールについて

## 作業ログの作成・編集ルール

Copilot Agent で作業する場合、必ず下記のように作業ログを残す

- agent/work-log/YYYY-MM-DD 下に作業ログファイルを格納する
  - YYYY-MM-DD/作業タイトル のディレクトリを作成して、その中に作業ログを格納する
- 作業ログは、YYYY-MM-DD_作業タイトル.md の形式で作成
- Agentへ依頼・回答がなされるたびに、作業ログを更新する
  - 作業ログは、Agentとのやりとりの履歴を含む

## 作業ログのフォーマット

作業ログの内容は、以下の項目を含める

- 作業日
- 作業内容の概要
- 作業の背景
  - なぜその作業を行うのか
- 作業のゴール
  - 何を達成することを目指すのか
- Agentへの依頼内容リスト
- Agentが行った作業リスト
  - ex. コマンド操作とその結果など
- 作業結果のアウトプット
  - 作業依頼時にアウトプットを指定された場合、作業ログと同じ階層にアウトプットを保存する

その他のカスタムインストラクションは、基本的にアウトプット結果を見れば、そのフォーマット通りになっているので割愛します。

障害調査

今回は、CIの失敗ですので、下記のようにしました。

下記の障害対応をお願いします
まずは、調査を行い、コードの修正は行わないでください

失敗したジョブ:
https://github.com/<org名>/<repo名>/actions/runs/<id>/job/<id>

必要に応じて、MCPサーバーを使用してください

アウトプット: 障害対応報告書

アウトプットは長いので、中略して記載します。
わかりやすい結果ですね。protobuf の version アップで解決しそうです。

# 2025-07-31_障害対応報告書_Snyk依存関係脆弱性

## 現象

GitHub Actionsのワークフローが失敗している。失敗したジョブ: [GitHub Actions Job](リンク)

### なぜこの現象を知ったか？

GitHub Actionsの自動テストが失敗し、報告された。

### 情報源

- GitHub Actions ワークフロー実行結果
- ワークフローログ

## 実際の現象

### いつどこで起こったのか

- 2025/mm/dd 11:46 に GitHub Actions の `python-check / check` ジョブで発生

### 期待される動作

- Snykセキュリティテストがパスし、ワークフローが正常に完了する

### 実際の動作

- Snyk セキュリティテストが失敗し、CI/CD パイプラインのワークフローが失敗した
- エラーメッセージ: `protobuf@6.30.2` に High Severity の `Uncontrolled Recursion` 脆弱性が存在する

（中略）

### 対応案

#### 案１：`protobuf` パッケージを明示的に最新の安全なバージョン 6.31.1 に更新する

**案の内容：**

1. `scripts/Pipfile` に `protobuf = "==6.31.1"` を追加して明示的に安全なバージョンを指定する
2. `pipenv local` を実行して依存関係を更新する
3. 更新後、再度 CI/CD パイプラインを実行して、Snyk テストが通ることを確認する

障害の解決

カスタムインストラクション - 開発フロー

Agentに実行して欲しくないことは、そのように明示しておきます。

開発フロー
.github/instructions/development-process-instructions.md

# 開発フロー

Agentにより開発を進める場合、次の通り進める
依頼主が、どこまでの作業を依頼しているかを判断して、依頼されていないことは実施しない

1. ローカルでの開発とテスト
2. 影響範囲の分析
3. GitHub へのプッシュ
4. GitHub Actions によるチェック
5. テスト環境での動作確認
6. PR作成

## 1. ローカルでの開発とテスト

まず、ブランチを作成して、移動してから開発を開始します
適宜、feature/ や fix/ などのプレフィックスをつけてください

### 単体テストのアウトプット

単体テストを行った場合、作業ログと同じディレクトリに、単体テスト結果.md というファイルを作成してください
ファイルの内容は、実行したコマンドとその結果を漏れなく記載してください

### Python スクリプトの単体テスト

pythonの単体テストが必要な場合は、下記のルールを読み込んでから行うこと
ルール: [Python スクリプトの単体テスト](./instructions/development-process/python-unit-test-instructions.md)

## 2. 影響範囲の分析

影響範囲の分析を依頼された場合 または アウトプットに影響範囲分析結果が指定された場合は、下記のルールを読み込んでから作業を開始すること
ルール: [影響範囲分析の作成・編集ルール](./instructions/development-process/impact-analysis-instructions.md)

## 3. GitHub へのコミット・プッシュ

ローカルでの開発と単体テストが終わり、依頼を受けた場合のみ、GitHub へコミット・プッシュします。

### コミットメッセージのルール

コミットやプッシュを依頼された場合、下記のルールを読み込んでから作業を開始すること
ルール: [コミットメッセージのルール](./instructions/development-process/commit-message-instructions.md)

## 4. GitHub Actions によるチェック

基本的に、Agentでは行いません。

## 5. テスト環境での動作確認

基本的に、Agentでは行いません。

## 6. PR作成

### PRのOverviewのフォーマット

PRを作成を依頼された場合には、下記のルールを読み込んでから作業を開始すること
ルール: [PR作成ルール](./instructions/development-process/pr-overview-instructions.md)

単体テストやPRのルールは、プロジェクトによって異なるので適宜用意してください。

コード修正・単体テスト

指示は下記になります。

インプット: agent/work-log/2025-07-31/障害調査_Snyk依存関係脆弱性/障害調査報告書_Snyk依存関係脆弱性.md

インプットを確認して、対応案1の方針で、開発フローに従って対応を行ってください
まず、開発フローのルール確認からお願いします

・必要に応じて、MCPサーバーを使用してください

結果として、作業ログに残っているように、下記のような変更をしてくれました。

対応案1に基づいて、以下の作業を実施:

scripts/Pipfileにprotobuf = "==6.31.1"を追加

pipenv lockを実行してPipfile.lockを更新

単体テストを実行して問題がないことを確認

さらに、単体テストの結果もアウトプットされましたが、具体的な内容はコマンドの実行結果なので割愛します。

変更点に関する影響範囲分析

指示は下記です。
チャットが長くなると、ルールを忘れることがあるため、毎回読み込んでもらうようにします。
動きとしては、development-process-instructions.md を読んだ後に、
impact-analysis-instructions.md にジャンプして、そちらも読んでくれます。

次に、今回の分析に関する、影響範囲の分析を行ってください

ルールの再確認をお願いします
.github/instructions/development-process-instructions.md

アウトプット: agent/work-log/2025-07-31/障害調査_Snyk依存関係脆弱性/影響範囲分析結果.md

作業ログは既存を更新でOKです（作業ログ_Snyk依存関係脆弱性.md）

結果として、下記がアウトプットされました。
今回は、間接的な影響範囲として、tftest関連の別ファイルでも同様の修正をすべきことがわかりました。
これについても AI Agent で修正しましたが、それに関する指示やアウトプットは割愛します。

# 影響範囲分析結果

## 修正ファイル一覧

- scripts/Pipfile
  - protobufパッケージのバージョンを明示的に指定
- scripts/Pipfile.lock
  - 依存関係の更新により自動的に変更

## ファイル詳細分析

### scripts/Pipfile

- 修正されたロジックの説明
  - 間接的な依存関係として使用されているprotobufパッケージのバージョンを明示的に指定
- 修正内容
  - `protobuf = "==6.31.1" # 脆弱性対応: SNYK-PYTHON-PROTOBUF-10364902` を追加
- 修正による影響
  - Pipfileに記載された依存関係を使用するスクリプトに対して、安全なバージョンのprotobufパッケージが使用されるようになる
  - google-cloud-storageパッケージを通じて間接的に使用されているprotobufパッケージのバージョンが6.30.2から6.31.1にアップグレードされる

### scripts/Pipfile.lock

- 修正されたロジックの説明
  - `pipenv lock` コマンドによる依存関係の解決
- 修正内容
  - protobufパッケージのバージョンが6.30.2から6.31.1に更新
  - パッケージのハッシュ値が更新
  - パッケージのソースが「index」に指定され、明示的に指定されたことを示す
- 修正による影響
  - アプリケーションの実行環境で使用されるprotobufパッケージが安全なバージョンになる

## 影響を受ける可能性のある関連コンポーネント

### utils.py

- 関連性
  - google.cloud.storageモジュールをインポートしており、このモジュールは間接的にprotobufパッケージに依存している
- 影響の可能性
  - protobufのバージョン変更による機能的な影響は見られない
  - 単体テストでも問題なし

### terraform/modules/test/tftest/Pipfile および Pipfile.lock

- 関連性
  - 同じくgoogle-cloud-storageパッケージを依存関係として使用しており、間接的にprotobufパッケージに依存している
- 影響の可能性
  - 現在の修正ではこのファイルは変更されていないため、引き続き脆弱性のあるバージョンのprotobufに依存している可能性がある
  - テスト環境のみで使用されるコードであるため、リスクは限定的
  - ただし、同様の修正を適用することが推奨される

## 結論

- この修正はscripts/ディレクトリ内のPythonスクリプト実行環境にのみ適用されている
- アプリケーションのコード自体に変更はなく、依存関係のセキュリティ向上のみを目的としている
- 単体テストの結果から、機能的な影響はないことが確認されている
- terraform/modules/test/tftest/ディレクトリ内のPipfileにも同様の修正を適用することが推奨される

コミット、プッシュ、CIが通ることの確認

上記も行いましたが、大体わかるかと思いますので割愛します。
ちなみに、作業ログなどのアウトプットは、ディレクトリごと gitignore しているので、プッシュされていません。

アウトプットをコンフルエンスにコピー

今までのアウトプットはローカルにしかないため、コンフルエンスにコピーして正式にドキュメント化します。
ドキュメント管理ルールにより異なるので、必要な場所に格納できるようなMCPサーバーを利用するのが良いでしょう。

次に、agent/work-log/2025-07-31/障害調査_Snyk依存関係脆弱性 にあるすべてのファイルをコンフルエンスのドキュメントとして新規作成してください

完了したら、それぞれの.mdファイルの先頭に、対応するコンフルエンスのドキュメントのリンクを記載してください

コンフルエンスの作成場所は、下記ドキュメントの下でお願いします
<コンフルエンスドキュメントの場所リンク>

・必要に応じてMCPサーバーを使用してください

PR作成

指示は下記です。

次に、今回の変更に関するPRを作成してください。

作成ルールは下記で確認してください
.github/instructions/development-process-instructions.md

作成時に、下記のPRのOverviewの項目に対応させて、先ほど作成したコンフルエンスのドキュメントリンクを貼ってください
インプット
影響箇所
テスト

・必要に応じて、MCPサーバーを使用してください

下記のようなPRが作成され、アウトプットに関してもコンフルエンスのリンクが貼ってある状態です。
（terraform/modules/test/tftest/Pipfileの修正は、影響範囲分析で見つかったものを追加修正した分です。）

ひとこと

自分ひとりで作業するよりも、確実に効率的だと感じました。
作業ログが逐一更新されることで、何を行ったかが明確になり、人間が確認して質を担保しながら進めやすいですね。

今回は、auto approve は使いませんでしたが、より決まった作業の運用業務などは完全に任せてしまってもいいと思います。

みなさんも快適なAIライフを！