はじめに
こんにちは、アプリケーションサービス本部ディベロップメントサービス１課の森山です。
2026 年 3 月 31 日に AWS DevOps Agent が GA しましたね！
去年の re:invent で発表されて以降、しばらく触っていなかった方は、下記サイトをご確認ください。 最新情報が詳細にまとめられています。
今回私の方では、普段開発に利用している Backlog との連携を探ってみます。
この記事で学べること
- DevOps Agent に外部 MCP サーバーを接続する構成と技術選定
- nulab 公式 backlog-mcp-server を Lambda + API Gateway でホスティングする方法
- Skills を活用して Agent を自律的に動かす方法
- MCP と Skills を組み合わせた運用手順書の自動参照シナリオ
前提知識・条件
- 2026 年 4 月時点の内容です
- リージョン: ap-northeast-1（東京）
- CDK: v2 系（aws-cdk-lib 2.250.0）、TypeScript
- Backlog のスペースと API キーを保有していること（今回は個人契約のものを利用しました）
やりたいこと・シナリオ
今回は以下のようなシナリオを準備し、検証・動作確認してみます。
- EC2 インスタンスで CPU 使用率が高騰
- DevOps Agent のインシデントレスポンスで状況確認を依頼
- Agent が AWS 側の状況を確認
- Agent が Backlog MCP で Wiki から対応手順書を検索・取得
- AWS 側の状況と Wiki の手順書をまとめて回答
Agent に投げるプロンプトは以下のような感じです。
EC2 インスタンスの CPU 使用率が高くなっています。状況を確認して、対応手順書があれば教えてください。
後述する Skill の仕組みにより、プロンプトに「Backlog」と明示しなくても Agent が自律的に Backlog Wiki を探しにいくシナリオです。
技術選定
今回は Backlog との接続に MCP を使います。 下記資料の通り、MCP での接続には Streamable HTTP トランスポートプロトコルおよび認証のサポートが必要です。
これに対応するための構築作業が必要なので、選定した技術を紹介します。
MCP サーバーの選定
今回は、以下の理由により、nulab 公式 backlog-mcp-server を採用しました。
- Streamable HTTP トランスポートにネイティブ対応（
--transport httpまたはMCP_TRANSPORT=http） - フィールド選択（
--optimize-response）やトークン制限（--max-tokens）など運用向け機能が充実 - ツールセットの選択が可能（
--enable-toolsets project issue wikiのようにスペース区切りで指定）
2026-04-22にリリースされた v0.11.0 で 公式 Docker イメージがStreamable HTTP トランスポートに対応しているので、これを利用します。
今回有効にしたツールセットは --enable-toolsets project issue wiki です。
ホスティング
今回のホスティングは、以下の理由から Lambda(Lambda Web Adapter) + API Gateway(REST) を採用しました。
- DevOps Agent からの呼び出し頻度は低いため、従量課金のコストが最適
- Lambda Web Adapter（v1.0.0 GA）を使えば公式 MCP サーバーをそのまま動作可能
- REST API Gateway のレスポンスストリーミングに対応しており、SSE レスポンスをそのまま流せる
- コールドスタートがあるが、 DevOps Agent の用途なら許容範囲
- API キーが利用できる (理由は後述します)
認証
MCP サーバーをインターネット上に公開する以上、誰でもアクセスできる状態は避ける必要があります。
今回は DevOps Agent が API キー認証に対応しているため、API キーで簡易的に構成しました。
API Gateway の API キーは本来スロットリング（使用量制御）を目的とした機能であり、認証・認可のための仕組みではありません。あくまで検証用途としての構成です。
（その他、OAuth クライアント認証情報 OAuth 3LO の認証にも対応しています。）
なお、DevOps Agent には Private connections という新機能があります。 VPC Lattice 経由でプライベートなエンドポイントへ接続できます。
未検証ではありますが、API Gateway をプライベートにして VPC エンドポイント経由でアクセスさせれば、インターネットへ公開せずに利用できそうです。
準備
では、環境を作っていきます。
CDK でデプロイする
今回はほぼ全てのリソースを CDK で構築しています。
現時点（2026/04）の対応状況は以下をご確認ください。
ソースコードは以下で公開しています。
CDK のスタック構成は以下のとおりです。
| スタック | 内容 |
|---|---|
| BacklogMcpServerStack | Lambda + API Gateway + API キー + カスタムリソース（API キー値取得） |
| DevOpsAgentStack | Agent Space + MCP 登録 + AWS Association |
| Ec2DemoStack | VPC + NAT Gateway + EC2（負荷試験用） |
BacklogMcpServerStack では、前述の MCP サーバーを Lambda + API Gateway でホスティングしています。
DevOpsAgentStack では以下が自動作成されます。
- Agent Space
- Agent 用 IAM ロール
- AWS Association（監視対象アカウント）
- MCP サーバー登録（Backlog MCP、API キー認証）
- MCP Association（読み取り専用ツールの allowlist）
DevOps Agent 側の Agent Space では、読み取り専用ツールのみを allowlist しました。
- get_project_list, get_project
- get_issues, get_issue, count_issues, get_issue_comments
- get_wiki_pages, get_wikis_count, get_wiki
- get_priorities, get_categories, get_issue_types, get_resolutions
これは下記のページの通り、MCP は読み取り専用であることが求められているためです。
なお、デプロイ前に Backlog に関するパラメータを SSM Parameter Store へ登録しておく必要があります。
aws ssm put-parameter --name /backlog-mcp/BACKLOG_DOMAIN --value "xxx.backlog.com" --type String aws ssm put-parameter --name /backlog-mcp/BACKLOG_API_KEY --value "your-backlog-key" --type SecureString
あとは CDK でデプロイするだけです。
DevOps Agent Skills を設定する
Skill がない場合、Agent は MCP ツールの存在は知っていても、どんな場面で使うべきかの判断材料がありません。
プロンプトに「Backlog の Wiki を探して」と毎回明示すれば動きますが、Skill を設定しておけば「対応手順書を探す → Backlog Wiki を確認する」という行動パターンを Agent が自律的に判断してくれます。
Skills の詳細については、下記の記事で詳しく紹介されていますのでそちらをご参照ください。
では、Skill を作成していきます。 Skills は現時点で CloudFormation リソースが未提供のため、CDK での管理ができません。
Operator Web App の UI から手動で作成します。
今回作成した Skill
今回は以下の内容で Skill を作成しました。
| 項目 | 値 |
|---|---|
| Name | backlog-wiki-runbook-lookup |
| Description | EC2やAWSリソースの障害・アラート発生時に、Backlog Wikiから対応手順書を検索して提示する。CPU高負荷、ディスク容量不足、ネットワーク障害などの運用イベント発生時に使用する。 |
| Agent Type | Generic |
| Status | Active |
Instructions はこんな感じです。
# Backlog Wiki 運用手順書の検索 AWSリソースに関するアラートや障害が発生した場合、 Backlog Wikiに対応手順書がないか確認する。 ## Step 1: AWS側の状況確認 対象リソースの現在の状態を確認する: - CloudWatchメトリクス（CPU、メモリ、ディスクなど） - アクティブなアラームの有無 - 直近のイベントやステータスチェック ## Step 2: Backlog Wikiから手順書を検索 1. get_wiki_pagesでWikiページ一覧を取得する 2. ページタイトルから、対象リソースや症状に関連するページを特定する - 例: 「EC2」「CPU」「高負荷」「対応手順」などのキーワード 3. 該当ページが見つかったらget_wikiで内容を取得する ## Step 3: 結果の提示 以下をまとめて報告する: 1. AWS側の現在の状況（メトリクス、アラーム状態） 2. Backlog Wikiで見つかった手順書の内容 3. 手順書が見つからなかった場合はその旨を報告
Backlog Wiki に手順書を用意する
次に、Backlog Wiki 側に手順書を作成します。
内容はこのような簡易な手順を用意しました。
# EC2 CPU高負荷時の対応手順 ## 確認事項 1. CloudWatchでCPU使用率の推移を確認 2. topコマンドで負荷の高いプロセスを特定 3. 直近のデプロイや設定変更がなかったか確認 ## 対応手順 1. 一時的な対応: インスタンスタイプのスケールアップを検討 2. プロセスの特定: SSM Session Managerで接続しtopを確認 3. 恒久対応: Auto Scalingの設定見直し、アプリケーション側の最適化 ## エスカレーション - 30分以上改善しない場合はインフラチームに連絡
やってみた
準備ができたので、実際に試してみます！
EC2 に負荷をかける
まず EC2 に Session Manager で接続して、stress コマンドで CPU 負荷をかけます。
aws ssm start-session --target <インスタンスID>
stress --cpu 2 --timeout 300 &
top コマンドで負荷がかかっていることを確認します。
top
CloudWatch への反映に数分かかるので、少し待ちます。
DevOps Agent に聞いてみる
DevOps Agent のチャットからプロンプトを投げてみます。
EC2 インスタンスの CPU 使用率が高くなっています。状況を確認して、対応手順書があれば教えてください。
Agent が動き始めました。
スキル読込み、EC2インスタンスの調査、Backlogから対応手順書の検索ができていますね。
結果
最終的に、AWS 側の状況と Backlog Wiki で見つかった手順書の内容をまとめて回答してくれました。
想定通りに動いてくれてそうです！
まとめ
AWS DevOps Agent と Backlog MCP を連携して、Skill 経由で自律的に運用手順書を参照させる構成を作ってみました。
- DevOps Agent は Streamable HTTP トランスポートのみ対応なので、MCP サーバー側の準備が必要
- nulab 公式 backlog-mcp-server と Lambda Web Adapter の組み合わせで、比較的シンプルに Lambda ホスティングできた
- Skill の description を具体的に書いておくことで、プロンプトに明示しなくても Agent が自律的に動く
Skill と MCP を組み合わせることで、DevOps Agent に自社の運用ナレッジを取り込めるので、使えそうかなと思います！
誰かのお役に立てると幸いです。最後まで読んでいただきありがとうございました！
