はじめに
こんにちは。システム部の今井です。最近SREに関心を持ち始めています。従来のシステム運用・監視をSRE（Site Reliability Engineering）へ転換する場合、どのようなアプローチができるのか実現方法をCursorと一緒に考えてみました。
※本記事の内容は筆者の理解に基づくものとなります。実際のSRE活動とは異なる部分があるかもしれませんがご容赦ください。
SREとは
SRE（Site Reliability Engineering）は、Googleが提唱したシステム運用のアプローチです。従来の「人による運用監視」をツールによって「自動化・効率化」へシフトするとともに、サービスレベルを設定することで信頼性を定量化して開発と運用のバランスをとる手法です。
従来の運用監視の課題とSRE化で目指す姿
従来の運用監視の課題
例えば、以下のような運用監視の課題を抱えている方もいらっしゃるのではないでしょうか？
- 有人でシフトを組んで監視している
- 手動での確認作業が多い（エラー確認と調査、ナレッジ検索、電話・メール連絡）
- 属人的な対応になりがち
- ユーザーからアピールはないけどサービスやシステムに本当に問題がないか不安
SRE化で目指す姿
SREの考え方を取り入れて以下のようなシステム運用に近づけることを目指して、実現の方針やタスクを洗い出すことをゴールに設定します。
- 自動化を前提とした監視・対応（手作業をなくす）
- SLI/SLOに基づく信頼性の定量化（サービスやシステムに問題がないかを定量化）
- オンコール体制への移行（有人監視からの脱却）
- 予防型エンジニアリング（根本解決をしてエラー自体をなくす）
Cursorを利用した実現方針からタスク（WBS）の洗い出し
今回、Cursorを使って実現方法やどのようなタスクがあるのかを考えてみました。モデルは当初最新だったClaude Sonnet 4を使いました。やったことは以下になります。
- SREの実現に向けての壁打ち、アイデア出し
- 壁打ちした結果をもとにmarkdownで実現方針の資料作成
- まとめ資料からmarpプラグインを使って方針のプレゼンテーション資料を作成
- まとめ資料をもとにSRE実現に向けてのWBSをmarkdownで洗い出し
- WBSをGitHub CLIを使ってGitHubのissueに登録し、issueをGitHub Projectに紐付け
SREの実現に向けての壁打ちと資料作成
まずは正直に現状の課題と目指す姿をCursorにぶつけて全体的な案を作成してもらいました。そこから各テーマを深掘りして、実現方法についてひたすら壁打ちしつつ、実現方法をmarkdownの資料にまとめていきました。
前提条件など詳細にプロンプトを記載することでAIのアウトプットの精度が高い傾向にありますが、こういった自分があまりイメージできていない領域は壁打ちが適していると感じました。壁打ちしてAIの回答を確認することで、段階的に自分も理解が深まっていきました。
全部で1000行ほどの詳細な資料が出来上がりました。以下は作成した資料の一部抜粋です。現状とSRE実現に向けてのギャップ分析もしてくれました。
まとめ資料からmarpでプレゼンテーション資料の作成
まとめ資料が1000行ほどになってしまったので、概要やポイントをプレゼンテーション資料にまとめました。
Cursorに「まとめ資料からmarpでプレゼンテーション資料を作成して」とそのまま依頼したら、8割程度の完成形が出来上がりました。かなり精度が良くて驚きました。ただ、画像の挿入がうまくいかずに結局手動で挿入しました（やり方はあるのだと思いますが）。
以下は作成したプレゼンテーション資料の一部抜粋です。
まとめ資料からタスク（WBS）の洗い出し
今度は実際に具体的なアクションに繋げるために、WBSの洗い出しをCursorにやってもらいました。まとめ資料をもとに、以下のように各テーマ別でタスクを抽出してもらいました。
- サービスレベルの導入
- 自動化
- オンコールと有人監視の脱却
...
タスクを洗い出す際には、親タスク・子タスクがわかるようにカテゴリ別に連番を振ってもらうように指示しました。何度か対話しながらタスクの洗い出しの精度を高めていきました。
以下がCursorと洗い出したWBSの一部抜粋になります。
GitHub CLIでissueへのタスク登録とprojectの紐付け
洗い出したタスクをGitHub CLI（ghコマンド）を使ってCursorにissue登録してもらい、さらにプロジェクト管理することを想定してGitHub Projectにも登録してもらいました。
いきなりghコマンドで登録を依頼したら思ったようにissueに登録されなかったため、Cursor上でissue登録用のディレクトリを作成し、一旦その中にWBSごとにmarkdownファイルを作成しました。このファイルを1つずつissueに登録するようにお願いしたら、意図した通りに登録できました。
さらに、GitHub上でprojectを作成（これは手動です）した後、Cursorにissueとprojectを紐付けてプロジェクト管理できるようにしてみました。以下issueを紐づけたGitHub projectの一部抜粋です。
まとめ
今回、Cursorを利用して、従来の運用監視からSREへの転換について実現方針やタスクの洗い出しを行いました。
一から人力でやろうとするよりも明らかに短時間で具現化できたのではないかと思います。特に対話しながら段階的に深掘りができるため、自分の理解が不十分な領域でも効率的に検討を進めることができました。
今回は想定でCursorと考えてみましたが、実際の業務でもこのアプローチは使えそうだなと感じました。