SRE × AI
おはようございます。tokuharaです。 estie で SRE とか Platform Engineeringをしてます。
日常業務にAIが当たり前のように入ってきてますね。設計の壁打ちや、集めた資料を丸投げして整理してもらうことから、コーディング作業と多岐にわたる範囲でAIと併走して働くことが増えてきました。実際ここ数ヶ月、自分はAIに書いてもらうコードの方が自分で書くより多くなっています。
これから立ち上げるプロダクトやスタートアップといった企業自体も、AIを前提にしたものになってくるでしょうし、ビジネスや、組織の形もAIネイティブ化され、面白そうな時代が当面続きそうな気配です。
それにしても日々新しいアップデートがありますね。皆さんはキャッチアップできてますか？
自分は正直追いかけ切れてないです。ですが、社内やXなどで騒がれてる所に関しては後からでも良いのでキャッチアップし、実際に使い、自分なりの肌感を持つことを大事にしています。
ちなみに今私が使っているAI関連ツールはこんな感じです。
- ChatGPT
- Perplexity
- Devin
- Cursor
- VSCode + GitHub Copilot Agent
- VSCode + Cline
- VSCode + Claude Code
- Amazon Q Developer
業務とプライベートで使い分けていたりするので、結構な数になっていますね。。
長年使っていたIntelliJも手放し、今はAIとの親和性を重視してVSCodeに全振りしています。コードを書く体験自体はIntellijの方が良いと思いつつ、自分で書く量も減ってきているので思い切ってみました。
(VSCodeのカスタマイズが面白くてeditor移行はそんなに苦ではなかったのが救い)
以降で私がAIとどう向き合っているかをもう少し深堀りしつつ、またどういった業務で使っているかも書いてみようと思います。
お断り
執筆時点の2025年6月15日 の活用方法や考えであり、明日には全くやりかたが変わってることがあります。
AIとの向き合い方
私はSREというロールで、Platform Teamに所属しています。このチームでの私の主な役割は、
- estieの各プロダクトが安定して動くインフラ
- 一日に何度もデプロイできるCI/CDパイプライン
- コードの変更をデフォルトブランチにMergeする前に動作確認可能なPreview機能
- 開発で後回しにされがちなセキュリティ運用
といったものを提供し、プロダクト開発チームが開発業務に専念できる状況を作り出すことです。SREとしての責務を担いながら、Platform Engineering、DevOps、Securityなど広く見ているイメージです。すべてを専門的に極めているわけではありませんが、プロダクトや組織のフェーズにあわせて柔軟に役割を変えながら進めるのは、自分の性に合っていて、楽しくやれています。
とはいえ、どんなに楽しいことでも、「少し腰が重くなる瞬間」というのはあるもので。。
たとえば最近でいうと、とあるクラウドサービスのTerraformの設計に着手しようとしたときがまさにそれでした。メインで使っているAWSなら運用イメージがあるので設計も楽なのですが、そのクラウドはどのような運用をしていくのが良いか具体的にイメージできておらず。そのため、Terraformの構成をどう切るべきか、どこまで共通化するかといった設計判断ができず、なかなか手が動かない状態が続いていました。
そこで、ChatGPTにいくつかの関連資料を読み込ませ、Terraformの実装例をいくつか提示してもらいました。いくつかのパターンを比較することで輪郭が見えてきて、「この構成なら一旦始められそうだ」と思える選択肢が見つかりました。そこからようやく、最初の一歩を踏み出すことができました。
こんな感じで、「最初の一歩を踏み出す」ことをAIに助けてもらうのはとてもよさそうです。考えの断片や、集めたリンク・資料を投げると、何かしらまとまったアウトプットが出てくるので、AIがない頃はなかなか踏み出せなかった最初の一歩のハードルがとても低くなったと感じています。
基本的にはハルシネーションが有るという前提で、出てきた情報を丸呑みにはしませんが、たたき台が有ることで、それをベースに深堀りや、探索を行い、最終的なアウトプットを作るという流れがここ最近はごく自然なワークフローになっています。こんな感じで、AIはすでに業務の中に自然と入り込んできています。
どこまでAIを活用できるのか？
こうした使い方が広がる中で、AIにどこまで任せられるようになるのか？と考えることがあります。現時点では、すべての業務をAIに置き換えるのはまだまだ先と思っており、その理由としては、最終的な責任を持つのは人間であり、業務の背景や文脈を踏まえた判断が必要な場面は多く残っているからです。
ただ、小さなタスク単位で見ると、AIを活用する場面から、まるっと任せる“置き換え”まで、少しずつ進んでいるように感じています。そうなってくると、人間が実際に手を動かす場面は減っていき、代わりに方向づけや品質の担保といった役割へ、徐々にシフトしていく流れになりそうです。
しばらくは、「AIに任せる部分」と「人が責任を持つ部分」のバランスをどう設計するかが良い感じにAIを使いこなす肝になってきそうです。
AI活用の事例
ここまでいろいろと書いてきましたが、実際にAIが入ってきて自分の考え方、仕事のやり方が変わったなという事例を紹介したいと思います。
事例1：インフラ運用効率化検討
最近、インフラ管理の効率化を検討する機会がありました。
estieでは、もともと各プロダクトごとに専用のTerraformリポジトリを用意したり、アプリケーションリポジトリ内の infra ディレクトリでインフラコードを管理していました。これは、各チームが自分たちでDevOpsを実践しやすくするための設計でした。
ただ、直近の運用状況を見てみると、初期構築後にインフラを頻繁に変更するケースは少なくなっており、またそういった状態なのでインフラが分かる人を増やすこともしてきませんでした。そもそも今はビジネスロジックに集中すべきフェーズだし、SREがやったほうが組織としてスピード出るよね。という判断をしてました。(自分もそう思っている)
そうなってくるとプロダクト数増加に伴うSREメンバーのインフラメンテナンス負担が顕著となり、効率化を図るための検討を開始しました。ちなみに数えてみたらestieでは30以上のterraformコードベースが存在してました。
この取り組みの中で、一案としてDevinを活用した方法で解決できないかを検証してみました。 内容としては、30以上あるコードベースに対して、以下の作業をお願いするものです。
- 設定が記載されたyamlファイルの編集
- Terraformの修正
多少なり元のコードに差分はありつつも基本的に同じ設定であり、また行う変更内容も同様の作業となります。
Devinへの作業指示内容としては、
「<対象リポジトリ> に対して、 <自分が手動で変更したPull Request URL> と同様の作業をお願いします。」
といった簡単なものです。
結果として初回で作成されるPull Requestのうち6〜7割は望んだ結果が出てきました。残りに関しては、編集対象が漏れていたり、修正した内容が指示したものと異なっているという事象が起きていました。
レビューで指示をすれば直るのですが、数が増えてくるとさすがにこれを回すのはやっぱりしんどい。それに加えてreviewが大量に発生するので、集中力切らしての見落としが怖く、Devinを使った方式では限界がそうそうに来るなという判断になりました。
ちなみにこの課題に関しては、Terraformコードをモノレポで管理する方式に変更するという結論に至っています。
結局ボトルネックは人間だった
この経験を通じて改めて感じたのは、AIがいくら優秀でも、判断・レビュー・連携が必要な場面ではやはり人間がボトルネックになるということです。ただ一方で、AIを活用したときの作業効率は圧倒的でした。対象リポジトリをghコマンドで一覧にして、ChatGPTにプロンプトの雛形とそのリストを渡して指示を生成する、それをSlackでDevinに投げるだけ。従来であればオフショアや業務委託の方にお願いしていたような作業が、今では自分ひとりとAIだけで完結できるようになっている現実に、ある種の衝撃もありました。
事例2: ログ調査の変化
estieでは、ECS Taskが異常終了した際に通知が届くようモニタリングを行っています。異常終了はバッチ処理などで夜間に発生することが多く、朝一にSlackを確認してその原因調査から業務が始まるといった日もあります。
原因調査の基本的な流れとしては、Datadog, CloudWatch Logsなどに記録されたエラーログを確認し、そこからそれっぽいキーワードを拾ってググる。類似のエラー事例や関連ライブラリのIssueを探したり、コードベースを辿って原因箇所を特定したりする、といった地道な作業を繰り返していました。数件程度でも対応に1〜2時間はかかることも珍しくなく、地味に時間がかかる作業でした。
そんな中で、Cursor, GitHub Copilot Agentを使い出して、このプロセスが大きく変わりました。今では、Cursor や VSCode を立ち上げて、エラーを出したアプリケーションのリポジトリを開いた状態で、エラーログをそのままコピペして「この原因は何？」と聞いてます。すると、数秒で「ここが原因では？」という回答が返ってくるようになっています。Agentモードだとそのまま修正までしてくれます。
これは、コードベースと一緒に使用できるAIを使ったアプローチです。estieでは使用している言語やフレームワークは統一されている方なのですが、自分が直接関わっていないコードなので、探索するのも一苦労です。ただ、AIだと、ログのスタックトレースから関数やモジュールを正確にたどってくれます。
もちろん、毎回完璧に原因を特定できるわけではありません。しかし「まずはこのファイル、この関数あたりを見ればよさそう」という、あたりが付くだけでも調査にかかる時間は圧倒的に短縮されました。実装したエンジニアと一緒に画面見ながら調査している感覚です。
ググって情報を探すというステップそのものをほぼやらなくなり、コードの探索もAIに任せているので、トータルで見た工数としては劇的に削減できています。
AI時代のSREが「今」すべきこと
AIに任せられることが増えてきた今、私たち人間側に求められるのは、「AIに任せられる状態をどう作るか」だと感じています。
特にSREのようなロールでは、サービスを安定して運用し続けることが何よりも重要です。
- モニタリング整備
- ガードレールとなるルールと逸脱した場合の検知
- アウトプットを検証する機能
書き出すと特にAIが来る前とやることは変わりませんが、今不足している機能はきっちりと使えるようにして、AIのアウトプットを評価できる仕組みを準備していくことが大事なのかなと思います。
最後に
少しでも興味を持ったそこのあなた！カジュ面しましょう！AIについてでも良いし、SREについてでも良いし何でも語らいましょう。
