Azure SRE エージェントの先に見る "エンジニア総 CTO 時代" 論
最近、運用の自動化 (AIOps) や AI エージェントによる DevOps (Agentic DevOps) の可能性を考える機会が個人的に増えています。AI を使ってシステム監視や障害対応を自動化する、みたいな話です。
たとえば、Microsoft が提供する SRE 向け AI エージェント製品「Azure SRE エージェント」は、このトピックで話題にあげられる製品の一つです。SRE エージェント を使うと、統合されたインシデント管理システムや Azure Monitor のアラートをトリガーにして、LLM でログ解析、根本原因特定、修復手順を提案/実行までを自動化できます。
もちろん、こうした技術の進歩は素晴らしいことです。私も大いに歓迎します。しかし、ネーミングも相まってか、同時にある種の危うさも覚えました。それは、「これを導入しただけで SRE が実践できるわけではないよな」 という直感です。
この違和感の正体は何なのか。そして、AI が実務をこなすようになった未来で、私たちエンジニアには一体何が残るのか。
今日は、Google の SRE の源流を振り返りながら、これからの時代に私たちが直面する 「エンジニア総 CTO 時代」 という新しい労働観について、考えてみたいと思います。
SRE とは何だったか
まず、私が感じた直感の正体から解き明かしましていきましょう。その鍵になるのは、SRE の根本的なミッションです。
Google における SRE の創始者 Ben Treynor Sloss 氏は、SREcon14 での発表 "Keys to SRE" の中で SRE の本質についてこう語っています。
- エラーバジェットによって開発と運用の対立を解消する: SLA を 100%未満に設定し、許容されるエラー率を「予算」として扱う。SLA 内であれば自由にリリースでき、超過したらリリースを停止する。これにより両チームが同じ目標に向かって協力できる。
- 運用作業を 50%以下に制限し、コードを書く時間を確保する: SRE は必ずコードが書ける人材を採用し、業務時間の 50%以上を自動化やシステム改善に充てる。手作業だけではスケールできないため、コードによる解決が不可欠。
- 障害から学び、同じ障害を繰り返さない: すべての障害に対してブレームレスなポストモーテムを実施し、人ではなくシステムやプロセスの改善に焦点を当てる。訓練 (Wheel of Misfortune) によって対応速度を向上させる。
- インセンティブ設計によって自己調整システムを作る: 開発と SRE で共通の人員プール、開発チームが運用作業の 5%を担当、過剰な運用負荷は開発チームへ戻すなど、構造的に協力を促す仕組みを設計する。
もちろん、SRE が Google 以外の組織に広まった現在では、組織ごとの「（最強かどうかわからないが）僕が考えた SRE」が誕生していて、定義のゆらぎは一定あると思います。
しかし、どんな SRE の定義であれ、現状を脱却し新たな組織的な仕組みと文化を作ることが必要である点は変わりません。Ben 氏がインセンティブ設計の重要性を強調しているのはこのためですね。
自動化ツールでは組織は変えられない
ここで冒頭の AI エージェントの話に戻ります。個別のインスタンスである Azure SRE エージェントが持つ機能は常に進化していくので、一旦議論から置いておき、変わりに、ある程度「これは実現できるよね」というコンセンサスが取れた機能 (例: ツール呼び出し、サブエージェントやファイルシステムによるコンテキスト最適化) を全部詰め込んだ、仮想的な SRE エージェントを想像してみることにします。
おそらくこの仮想 SRE エージェントは、SRE の日常業務の多くを自動化できると私は考えています。たとえば：
- インシデントのトリアージと優先順位付け
- ログとメトリクスの解析による根本原因特定
- 修復手順の提案と実行
- ポストモーテムのドラフト作成
しかし、こうした作業の自動化は SRE の本質だったのでしょうか？
答えはもちろん No です。
SRE の本質は、2014 年の Ben 氏を代弁するならば、 「組織の文化とインセンティブを変革し、開発と運用の対立を解消すること」 にあります。単なる自動化ツールの導入では、この根本的なミッションは達成できません。これがまさに私が感じた違和感の正体です。
自動化ツールは、作業（Toil）を減らしてくれますが、組織を変えることはできません。この意識を持たずに SRE エージェントを導入しても、限定的な効果しか得られないでしょう。
ツールの再定義
とまぁ長々とよくある「自動化ツールで組織は変わらない」論を展開しましたが、ここからが本題です。
ここまでの SRE エージェントの見方は「自動化ツール」としての視点でした。しかし、私はこれを 「意思決定支援ツール」 として捉え直すべきだと考えています。
なぜなら、LLM は単なる単体タスクの推論器ではなく、自然言語という接点でシームレスに私達に介入できるからです。
たとえば、「非難なきポストモーテム（Blameless Postmortem）」文化を定着させようとしても、人間同士だと感情が邪魔をしますが、LLM はここに介入できます。従来の自動化ツールではなし得なかった、以下のような支援が可能になります。
- 心理的安全性の担保: 人間が書いた事故報告書をレビューし、「この表現は個人を責めるニュアンスが含まれています。『プロセス』に焦点を当てた表現に書き直しましょうか？」と提案する。
- 客観的な調停: Dev と Ops が水掛け論をしているチャットログを読み込み、「議論が平行線です。論点は A と B に絞り、まずは A について SLO の観点から合意しませんか？」とファシリテートする。
これらはまさに、文化を変える具体的なアクションそのものです。「意思決定支援ツール」としての SRE エージェントは、SRE の本質的なミッションを支援する可能性を秘めています。
この意味で、Azure SRE エージェントは SRE のファーストステップとして "アリ" だと私は思っています（使い方を間違えなければ・・・）。
私たちは「作業者」から「承認者」になる
もう一歩進んで、このような意思決定支援ツールの性能が現在よりもさらに進化して、ソフトウェアに関連する様々な業務で普及した未来で、私たち IT エンジニアの役割がどう変わるのか考えてみましょう。
この世界では、ツールを「作る」人と「使う」人で役割が大きく異なります。
- 「作る」人: AI エージェントや自動化ツールを設計/実装し、組織やチームのニーズに合わせてカスタマイズする専門家。どのような文化やインセンティブ設計が必要かを理解し、それをファシリテートする AI エージェントを構築する。
- 「使う」人: AI エージェントや自動化ツールを活用し、システムの開発/運用業務を遂行するエンジニア。
ここでは「使う人」側の役割変化に注目します。作る人の役割は明確なのと、そこまで占める割合が大きくならないと思っているからです。
まずは、ある日の一幕を想像してみましょう。
[🤖] 今日の定期チェックを開始します。
[🤖] 運営中のサービス XXX でユーザー離脱率の上昇を検知しました。
[🤖] 原因は最近の UI 変更によるユーザビリティ低下のようです。過去の A/B テストデータを分析した結果、元の UI に戻すことで改善されると予測されます。
[🤖] 元の UI に戻すためのコード変更とデプロイ手順を考えると、2 つの切り戻しパターンがありそうです。
[🤖] パターンごとに検証環境を用意し、E2E テストまで通ることを確認しました。時間を計測するとパターン A が良さそうです。
[🤖] ただし、パターン A だと、特定メンバーしか理解していない旧インフラ構成を前提とするため、知識の属人化を助長します。パターン B を推奨することにします。[🤖] "人間さん、ユーザーの離脱がありました。理由は最近の UI 変更です。実装パターンを 2 つ考えたんですが、パターン B が良いと思います。なぜなら ... だからです。このまま実行して良いですか？"
[🧑] "理解しました。どちらのパターンも悪くなさそう。早く切り戻せるのはどっちなの？"
[🤖] "パターン A は 15 分、パターン B は 30 分です。"
[🧑] "じゃあ、パターン A でお願い。知識の属人化は後でドキュメント整備してカバーしよう。"
[🤖] "了解しました。パターン A を実行します。"
これはかなり極端な例ではあるものの、「使う」エンジニア 🧑 がどのように AI エージェント 🤖 と関わるかの最終形態のイメージをよく表しています。ここで注目すべき点は、２つあります。
- AI エージェントが日常業務の大部分を自律的にこなしている: 問題の検知、原因分析、解決策の提案、テストまでを AI エージェントが実行しています。エンジニアは最終的な意思決定と承認に集中できています。
- 人間からの指示がプロセスの起因になっていない: 現在の AI エージェントは、人間の指示を受取ることで動作を始める場面が多いですが、将来的には AI エージェントが自律的に状況を監視したり、定型業務をこなすなどする中で、人間に提案を持ちかける形態が主になると考えています。
つまり、AI エージェントを「使う」人の主な役割は、意思決定を効率的にこなすことにシフトしていきます。私たちは、作業の主体を AI エージェントに明け渡し、承認者 (approver) と化していきます。
「承認」という名の重圧
では、「使う」エンジニアの仕事は楽になると言えるのか？
私はますますつらくなるだろうと考えます。正しい意思決定は、困難で、責任を伴う行為だからです。しかも、作業自体に愛着が湧いているエンジニアにとっては、なおさらです。
AI が書いたコードを承認してデプロイした結果、もし本番データベースが吹き飛び、数億円の損害が出たらどうするのか？
あなたはそこで、「AI が書いたコードなので、私のせいではありません」と言えるでしょうか？
絶対に言えません。「それを承認したのは誰だ？」と問われたとき、手を挙げるのはあなた自身です。「なぜそれを承認したのか？」と問われたとき、理由を答えるのはあなた自身です。
あれ・・・これって誰かもうすでにやっている仕事なのでは・・・。
そう、経営者です。技術系の意思決定の話なので CTO（最高技術責任者）が一番イメージに合うでしょうか。
つまり、AI が日常業務をこなす未来の IT エンジニアは、「エンジニア総 CTO 時代」 を生きることになるのです。これがブログ記事のタイトルで言ってることの意味です。
権威主義に逃避しない覚悟
自動化によって作業が減り、意思決定の比重が増える未来において、価値を持つのは正しく悩み続けられる人です。
人間には、自由から逃れ、権威に頼ろうようとする性質があります。私自身も、ファッションにはあまり興味がないので、「とりあえずビームスで買っとくか」と思うタイプです。これは、まさにドイツの社会学者エーリッヒ・フロムが指摘した、人間の根源的な権威主義傾向そのものです。
これは、自由には意思決定が伴い、意思決定が本質的に“不安の受け入れ”だからです。未来はわからないし、どれほど合理的な選択をしても失敗しうる。それでも選ばなければならない。この不安と一緒に立ち続ける力があって初めて、自由な意思決定が可能になります。
AI が日常業務をこなす未来において、私たちエンジニアが真に価値を持つためには、この不安と向き合い続けることが必要です。「AI が一番良いと言ってるから」という安易な権威主義に逃げるのではなく、「なぜ AI はこれを良いと言っているのか？」 を問い続ける姿勢が求められます。AI に LGTM をしない覚悟を持てる人だけが、新しい時代の「CTO」として活躍できるでしょう。
まとめ
今日は、Azure SRE エージェントをきっかけに、SRE の本質と AI がもたらす未来のエンジニアの役割について考察しました。
なんだか壮大な話になってしまいましたが、要点をまとめると以下の通りです。
- SRE の本質は、組織の文化とインセンティブを変革し、開発と運用の対立を解消することにある。
- 自動化ツールの導入だけでは、SRE の本質的なミッションは達成できない。
- LLM を活用した AI エージェントは、意思決定支援ツールとして組織文化の変革を支援する可能性がある。
- AI が日常業務をこなす未来において、エンジニアの主な役割は意思決定を行う「承認者」になる。
- その世界でのエンジニアの価値は、正しく悩み続け、不安と向き合い続ける覚悟を持てることにある。
こんな未来が来るかどうかはわかりませんが、総 CTO 時代に向けた準備を始めてみるのも悪くはないかなと思います。
まずは、「書店のベストセラー コーナーから買う本を探すのをやめる」や「YouTube のおすすめ動画を見ない」ところから始めてみることにします。それではまた。
Discussion