はじめに

こんにちは。システム部の今井です。最近SREに関心を持ち始めています。従来のシステム運用・監視をSRE（Site Reliability Engineering）へ転換する場合、どのようなアプローチができるのか実現方法をCursorと一緒に考えてみました。

※本記事の内容は筆者の理解に基づくものとなります。実際のSRE活動とは異なる部分があるかもしれませんがご容赦ください。

SRE（Site Reliability Engineering）は、Googleが提唱したシステム運用のアプローチです。従来の「人による運用監視」をツールによって「自動化・効率化」へシフトするとともに、サービスレベルを設定することで信頼性を定量化して開発と運用のバランスをとる手法です。

従来の運用監視の課題とSRE化で目指す姿

例えば、以下のような運用監視の課題を抱えている方もいらっしゃるのではないでしょうか？

SREの考え方を取り入れて以下のようなシステム運用に近づけることを目指して、実現の方針やタスクを洗い出すことをゴールに設定します。

今回、Cursorを使って実現方法やどのようなタスクがあるのかを考えてみました。モデルは当初最新だったClaude Sonnet 4を使いました。やったことは以下になります。

まずは正直に現状の課題と目指す姿をCursorにぶつけて全体的な案を作成してもらいました。そこから各テーマを深掘りして、実現方法についてひたすら壁打ちしつつ、実現方法をmarkdownの資料にまとめていきました。

前提条件など詳細にプロンプトを記載することでAIのアウトプットの精度が高い傾向にありますが、こういった自分があまりイメージできていない領域は壁打ちが適していると感じました。壁打ちしてAIの回答を確認することで、段階的に自分も理解が深まっていきました。

全部で1000行ほどの詳細な資料が出来上がりました。以下は作成した資料の一部抜粋です。現状とSRE実現に向けてのギャップ分析もしてくれました。

まとめ資料が1000行ほどになってしまったので、概要やポイントをプレゼンテーション資料にまとめました。

Cursorに「まとめ資料からmarpでプレゼンテーション資料を作成して」とそのまま依頼したら、8割程度の完成形が出来上がりました。かなり精度が良くて驚きました。ただ、画像の挿入がうまくいかずに結局手動で挿入しました（やり方はあるのだと思いますが）。

以下は作成したプレゼンテーション資料の一部抜粋です。

今度は実際に具体的なアクションに繋げるために、WBSの洗い出しをCursorにやってもらいました。まとめ資料をもとに、以下のように各テーマ別でタスクを抽出してもらいました。

タスクを洗い出す際には、親タスク・子タスクがわかるようにカテゴリ別に連番を振ってもらうように指示しました。何度か対話しながらタスクの洗い出しの精度を高めていきました。

以下がCursorと洗い出したWBSの一部抜粋になります。

洗い出したタスクを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と考えてみましたが、実際の業務でもこのアプローチは使えそうだなと感じました。

https://sre.google/
https://www.udemy.com/course/sre-training/?srsltid=AfmBOopB6LGgCmKJGG6S-hFXxlzuxVnIeZlbtblKFh_OBIYxeA3Jxlh9