クラウドネイティブ会議 登壇レポート
Agentic AIの急速な進化により、コード生成から障害の復旧処理に至るまで、システム開発～運用の多くが自律化されつつあります。
こうした技術革新を前に、「SREという仕事は不要になるのではないか」という問いを抱くエンジニアも少なくないでしょう。
2026年5月14日・15日に開催され、SHIFTがダイヤモンドスポンサーを務めたイベント「クラウドネイティブ会議」に登壇したAIアジャイル開発部 SREエンジニア 島田は、「SREの価値は失われるどころか、より重要で本質的なものへと変化していく」と指摘します。
実行や最適化をAIが自律的に行う時代だからこそ、私たち人間に求められるのは「どこまでAIに任せ、どこから人間が責任をもつか」という境界線を動的に引きつづけることです。
本記事では、事業会社のSREを経て、現在はSHIFTで「伴走支援SRE」としてさまざまな組織のシステムと向き合ってきた島田の経験を踏まえ、これからのSREに求められる「壊れ方を設計する覚悟」と、新しい時代の責任のあり方をひも解いていきます。
-
AIアジャイル開発部 リードSRE 島田
2007年に独立系SIerへITエンジニアとして新卒入社。メーカー／商社／官公庁／教育機関などさまざまな業界業種のインフラシステム構築を経験した後、BtoC向けWebサービスのSREエンジニアとしてインフラ～MW～アプリ領域にまたがったSRE活動に従事。
2023年3月にSHIFTに入社し、QCDのブロッカーになりがちなIT領域がビジネス貢献の立ち位置を確立させるためのSREのあり方を発信中。尊敬する人はランディ・パウシュ。
目次
Agentic AIが私たちに抱かせる、SRE不要論
ここ数年、私たちが目にする技術トレンドの多くはAIに関連するものです。Gartneriiiの予測によれば、2028年までに企業の意思決定の少なくとも15%がAgentic AIによって自律的に行われるようになるとされています。
本当にすごい時代になりました。私もそうですし、みなさんも思ったことがあるのではないでしょうか。「もうSREは、いらないのではないか」と。
この“SRE不要論”は、AIが優れているから生まれたのか。私はむしろ、私たちSRE自身が「自分たちの真の価値を言語化してこなかったから」ではないかと考えています。
そこで、今日は「SREの真の価値とは何か」を考えていこうと思います。
AIにできること・できないこと。“判断”には3つのレイヤーがある
「実行が自律化する世界」において、判断はどこに属するのか、というのが本日の問いかけです。では、そもそも判断とは何を指すのでしょうか。私は、判断には大きく分けて3つのレイヤーがあると考えています。
1. 最適化の判断：与えられた条件の中で正解を探すための判断を行います。AIが得意なプロセスです。
2. 判断の評価：そもそも正解とは何か。何を成功とみなすか。 その基準をつくり、育て、更新するプロセスです。
3. 責任を伴う判断：最終的な結果に対して「誰が責任を負うのか」を確定させる判断です。
“最適化の判断”はAIがもっとも得意な領域です。
問題は、2番目のレイヤーです。
「AI Slop」という言葉を聞いたことがありますか。PoC環境では素晴らしい結果を出すのに、本番環境に入った途端、低品質な出力を吐き出しつづけ、ユーザーの信頼を失ってしまいます。
なぜそうなるのか。多くの場合、評価の設計が追いついていないからです。
最近、AIを“ツール”ではなく“協働者”として扱おうという話を耳にすることがありますが、私は“優秀な新入社員”として扱うべきだと考えています。
どれほど優秀な新入社員でも、教育し、フィードバックを与え、評価するプロセスがなければ組織で活躍することはできませんよね。教育し、評価し、フィードバックすることではじめて戦力になる。
私たちは、その「教育者」の役割を果たせているでしょうか。
評価の手段は、Evals、Observability、Human-in-the-loopということになりますが、重要なポイントは評価には完全には自律化できないということです。
AIの出力を測ることはできる。でも、何を「よい」とするか、その基準を決め、更新していくのは人の仕事です。これは「教育」であり「見守り」でもあります。
この話の詳細は、New Relicを使ったAIオブザーバビリティの実践としてブログに書いていますので、興味のある方はぜひご覧ください。
そして3つ目。責任を伴う判断です。ここが、今日一番伝えたいことの核心に近づいてきます。
AIは合理的な提案ができます。しかし、最適化された結果が必ずしも正しさを保証するわけではありません。速く、それらしい答えを出せることと、その答えに責任をもてることは、まったく別の話です。
多くの企業がAgentic AIを試しています。しかし全社展開できている企業はまだ限定的です。「パイロットの壁」と呼ばれる現象です。
SLOは単なる数値か、それとも責任か
実は、私たちはSLOを管理していたのではなく、SLOを通じて動的な責任境界線を引いていたのだと気づきました。
SLOが99.9%の青サービスと、99.99%の赤サービスがあるとします。月間ダウンタイム許容時間は、青が43分、赤が4分。この違いは、数値の精度の話ではありません。
同じように、エラーバジェットも単なる失敗の許容量ではありません。失敗の許容量ではなく、SLOを“運用する”ための装置です。
つまり、SLOやエラーバジェットは数字ではなく、組織のスタンスを示すとともに、「責任を運用する装置」ともいえます。
合理性は、責任を代替してくれません。AIがどれだけ優れた提案をしても、「誰がそれを選んだのか」は消えません。そして、この「選ぶ」という行為にこそ、私たちの存在理由がある。
つまり、 どれだけ自律化が進んでも、 責任の所在は、どこかに残りつづけます。
では——その責任は、どこに属するのでしょうか。
この図を見てください。AIは実行を担い、最適化の判断まで担い、人は評価の判断と、責任を伴う判断を担います。
そして注目してほしいのが、この境界線です。波線になっているのは意図的です。この線は固定されていません。
左側を見てください。AIが出力し、人が評価し、フィードバックをAIに返す。この協働のループの中で、境界線の位置は動いていきます。
つまり、境界線は「どこにあるか」ではなく、「どこに引くか」の問題です。そして、その線を引く基準は、ロジックではなく、責任の確定です。
だから、責任の確定の仕方次第で、境界線がどこに引かれるかは変わります。自律化が進むほど、境界線はより意識的に設計されるものになっていきます。放っておいたらあいまいになるだけです。
ここを設計するのが、これからのSREの仕事だと、私は考えています。
誰に対して責任を引き受けるのか？SREの4つの立ち位置
では、SREは具体的に誰に対して責任を引き受けるのでしょうか。私は自身の経験から、SREの立ち位置を「責任の届け先」の違いによって4つのモデルに分類しています。
1. プロダクト直結型：PdMやユーザーに直接責任を届ける
2. 機能単位型：複数チームのリードに対して横断的に責任を届ける
3. 基準設計型：SDKやガイドラインを通じて、全開発チームの基準の底上げに責任をもつ
4. 組織設計型：ポリシーや標準化を通じて、組織全体に責任を届ける
これらは役割の違いではなく、「自分がいま、どの責任を引き受けているか」という違いです。
私自身、プロダクト直結型のSREから機能単位型のSREへと立ち位置が変わった際、大きな変化を経験しました。同じ「SRE」でも、届け先が変わると、判断の中身が変わります。
プロダクト直結型の時は、開発チームの一員として自らSLOを決め、問題があればPdMを巻き込んでユーザーに直接説明に行くという動き方でした。
一方、機能単位型として横断的なオブザーバビリティやチューニングを担うようになると、各チームのリードエンジニアと議論を交わしながら基準をあわせていく必要がありました。
扱っている技術スタックは同じでも、説明する相手が変われば、求められる判断の質は変わります。何を優先し、どのリスクをどこまで許容するか。相手にあわせた責任の取り方が求められるのです。
もう1つ印象的な出来事として、SHIFTの「伴走支援SRE」としてお客様の現場に入ったときのことをご紹介します。
そのシステムでは可用性が低下し、SLOに抵触している状態がつづいていました。
しかし、長年の慣習や組織の構造的なむずかしさからSLOが形骸化してしまい、見直しや再設計の判断を下すことがむずかしく、運用が硬直化してしまっていたのです。
真の課題は技術ではなく、「判断の持ち主が不在であること」でした。そのため、私は単なる技術支援にとどまらず、体制や意思決定プロセスの整理にまで領域を広げて働きかけを行いました。
当時は「SREの役割を超えているのでは」という戸惑いの声もありましたが、粘り強く対話を重ねていきました。
組織の内側にいると、この境界のあいまいさには気づきにくいものです。組織の外から入るからこそ見抜ける課題があります。これは、さまざまな現場を横断してきたなかで、何度も感じたことです。
改めて4つのパターンを見てみましょう。この分類は、みなさんが日頃使っている言葉とも繋がっています。
たとえば、Embedded SREは、プロダクト直結型のど真ん中です。開発チームの中に入り込んで、プロダクト単位で責任を引き受けます。
Platformエンジニアリングは、機能単位型を前提としながら、基準設計型へ責任を押し上げる位置にあります。プラットフォームとは、責任の確定単位を上げる装置だと言えると思います。
そしてCCoE（Cloud Center of Excellence）のような取り組みは、組織設計型。組織全体の方針と標準を設計し、構造で責任を届ける立場です。
大事なのは、どれが正解ということではありません。自分がいま、どこに立っているのか。そして、どこに立つことを選ぶのか。その選択自体が、すでに「責任を引き受ける」ということです。
“壊れない”から、“壊れ方を設計する”へ
ここで少し、私個人の話をさせてください。
2026年に、私は下垂体卒中という病に倒れました。一時は「エンジニア人生は終わったかもしれない」と絶望しました。
入院中、なんとか「壊れない体」を取り戻そうと必死にもがいていた私に、担当の医師はこう言いました。
「元に戻すのではなく、いまの体のままでどう生きるかを一緒に考えましょう」
この言葉を聞いたとき、私はハッとしました。これは、私がいままでSREとしてやってきたこととまったく同じだったからです。
病気を完全に克服するのではなく、病気とともに生きていく。この考え方は、「システムは必ず障害を起こす」という前提に立つクラウドネイティブの思想と重なります。
そしてそれは、私たちSREが日々向き合っている考え方そのものです。
これからのSREに求められるのは、「システムが壊れないこと」を誇るのではなく、「壊れ方を設計すること」だと私は考えています。つまり、信頼性の基準を自分たちで定義し、その責任を負うことです。
AIは、システムの最適化や運用を猛スピードで加速させるエンジンのようなものです。しかし、AIというエンジンが搭載された船の舵を握るのは私たち人間です。
AIという強力なツールを使いこなしながら、「壊れ方を設計する覚悟」をもてるか。それこそが、AIの自律化が進む時代においても決して揺るがないSREの価値だと考えます。
技術を学ぼうとするエンジニアのみなさまの熱意は、本当にすばらしいものです。ご家族や周りのサポートにも感謝しながら、このエンジニアリングという世界で、世の中をいっしょによくしていけたらいいなと思っています。
（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）
