AI にシステム月次レポートを書かせる ─ Claude Code × MCP で運用レポートを自動生成する

SRE / インフラ運用をやっていると、サービスごとの「システム月次レポート」を求められる場面があります。
先月のコストはどう推移したか、障害やエラーは増えていないか、EOL が近いものはないか ── こうした定点観測です。

これが、地味に時間を食います。
Cost Explorer を開き、CloudWatch を開き、デプロイ履歴を漁り、表にまとめ直す。サービスが複数あれば、その数だけ繰り返す。

この一連の作業を Claude Code のカスタムスキル + MCP に任せて、「AI が下書き → 人間は確認だけ」という形に変えた話を書きます。

何を作ったか

各サービスに対して、以下の構成の月次レポートを Claude Code が自動生成する仕組みを作りました。
レポートの末尾には常に 作成者: AI (Claude Code) + SRE確認 と入れています。AI が全部やるのではなく、AI が下書きを作り、人間が確認して締めるというワークフローを明示するためです。

レポートの章立てはこう固定しています。

0. 要対応サマリ      ← 全分析から自動生成。まずここだけ読めば対応要否が分かる
1. コスト           ← 月次推移 + 変動要因の深掘り + RI/SP 期限
2. パフォーマンス    ← SLO / レイテンシ / エラーレート / リソース使用量
3. デプロイ・実装変更 ← 当月マージされた PR の一覧と影響範囲
4. メンテナンス計画   ← EOL 一覧と残り日数
5. 前回アクションの進捗
6. 今月のアクションアイテム

ポイントは 冒頭の「要対応サマリ」 です。
レポートは長くなりがちですが、忙しい開発者がまず読むのはここだけで済むように、緊急度（🔴🟡🟢）・カテゴリ・推奨アクションを表にまとめさせています。

どう動いているか ── MCP で実データに当たる

このレポートのキモは、AI が推測で書くのではなく、実データを取りに行く点です。
Claude Code から各種 MCP サーバーを束ねて、横断的に情報を集めます。

MCP / ツール	役割
Cost Explorer 系	サービス別・Usage Type 別のコスト推移を取得
CloudWatch / Application Signals	エラーレート・失敗実行数・レイテンシ
Datadog（使っていれば）	メトリクスでリソース使用率を確認
GitHub	当月マージされた PR を収集し、デプロイ履歴を作る
Notion	生成したレポートをそのままページ化

コスト分析では、単に「S3 が高い」で終わらせず、3 段階で深掘りさせています。

Level 1: サービス別コスト     → 何が高いか
Level 2: Usage Type 別コスト  → コストの構成要素は何か
Level 3: 根本原因の特定        → なぜ高いか / どう減らすか

たとえば「S3 が前月比 +16%」だけでは打ち手になりませんが、
Level 2 まで分解すると「増えているのは標準ストレージの ByteHrs」、
Level 3 まで辿ると「特定バケットのデータ蓄積が主因。ライフサイクル未設定」── と、アクションに落とせる粒度まで自動で降りてくれます。

デプロイ履歴も、当月の PR を集めて「日付 / PR / 内容 / 影響範囲」の表に整形させているので、
コストやエラーの変動を、その月の変更と突き合わせて推論できます。
（「エラーが増えた時期が、ちょうど DB の接続先を切り替えた PR の直後だった」といった気づきが自動で出てきます）

一番こだわった設計：「取得失敗」を握り潰さない

自動生成レポートで一番怖いのは、取れなかったデータを、それっぽい数字で埋められることです。
これをやられると、レポートの信頼性が一気に崩れます。

なので、取得できなかった項目は無理に埋めず、

レイテンシ: [取得失敗] Application Signals は 24h 制限のため月次データ取得不可
GCP CUD: [取得失敗] コンソールで確認してください

のように [取得失敗] を明示させ、代わりに「どこで確認すればよいか」を併記させています。
「分からないことを分からないと書く」のは、地味ですが自動化レポートの信頼性を保つうえで一番大事な設計だと思っています。

API のレンジ制約は「窓をずらして」回避する

ここで一点補足しておきたいのが、[取得失敗] を出すのは「どうやっても取れないもの」に限る、という点です。

メトリクス API には 一度のリクエストで取得できる期間レンジに上限があるものがあります（例: 直近 24h までしか返さない、最大 N 日まで、など）。
これを「月次は取れない」と早合点して手動確認に倒すと、もったいない。

実際には、取得レンジをずらしながら複数回リクエストして連結すれば、1 ヶ月分まるまる取得できるケースが多いです。

1 回のレンジ上限が短くても…

  [5/1 0:00 – 5/2 0:00] → [5/2 0:00 – 5/3 0:00] → … → [5/31 0:00 – 6/1 0:00]

と窓をスライドさせて取得 → 連結すれば月次データになる。

スキル側にこのページング（窓スライド + 連結）を実装しておけば、
「API の制約上どうしても取れないもの」だけが [取得失敗] に残り、
“やればできるのに諦めた” という取りこぼしを防げます。

効果

• 作成時間：複数サービス分を手で作ると数時間規模だったものが、スキル実行 + 確認で大幅短縮
• 属人性の解消：「誰が作っても同じ章立て・同じ深さ」になり、レポートの品質が安定
• 横展開が容易：新しいサービスにも、同じスキルを向けるだけでレポートが出る
• 人間は判断に集中：「この差分は許容するか」「このアクションは誰がやるか」という意思決定だけに時間を使える

つまずいたところ・限界

万能ではありません。実際に運用してみての注意点。

• メトリクス API の制約：一度に取れる期間レンジに上限がある API は、窓をずらして複数回取得 → 連結すれば月次もカバーできる。実装していないと「取れない」と誤判定しがちなので注意（前述）
• 因果の取り違え：「コスト増と同時期の PR」を相関で結びつけるが、因果かどうかは人間が判断する必要がある
• コマンド（スキル）設計が品質を決める：何をどの順で取得し、どう構造化させるか。プロンプト設計の出来がそのままレポートの質になる

最後の点は強調しておきたくて、AI に丸投げするのではなく、良い問いの順番を人間が設計することが肝でした。
逆に言えば、レポートの型を一度きちんと設計してしまえば、あとは毎月それを再生産できます。

まとめ

• 定点観測系のレポートは、AI が下書き → 人間が確認の分業が効く
• MCP でコスト・メトリクス・PR を横断取得し、実データに基づいて書かせる
• コスト分析は「サービス → Usage Type → 根本原因」の 3 段階深掘りでアクションに落とす
• [取得失敗] を握り潰さない設計が、自動レポートの信頼性を支える
• 効率化の本質は「AI に任せること」ではなく「型を設計すること」

定型レポートに毎月時間を取られている人は、まず章立てとデータ取得元を固定するところから試してみると効果が出やすいです。

なお、この仕組みは Claude Code のプラグインとして切り出しています。
別途公開できる状態に整えられたら公開しようと思っているので、興味があれば気長に待っていてもらえると嬉しいです。