SREの仕事は、AIが得意そうに見える領域とかなり重なっています。アラートをさばき、ログを読み、障害の原因を切り分け、既知のトラブルには素早く対処する。だからこそ今、AIはSREの味方なのか、それとも静かに技能を削っていく存在なのか、という問いが現実味を帯びています。元記事は、単に「AIが人間を代替するかどうか」ではなく、「AIに任せすぎることで、人間側の対応力が落ちないか」を真正面から扱っています。しかもその話を、1980年代の自動化研究と結びつけてかなり踏み込んでいます。
元記事の中心にあるのは、1983年にLisanne Bainbridgeが発表した「The Ironies of Automation」という論文です。工場や産業システムの自動化が進むほど、人間のオペレーターは普段ほとんど仕事をしなくなり、いざ自動化が失敗した瞬間にだけ、しかも難しい状況で対応を求められるようになる。ところが、その「いざという時」に必要な経験は、日常の手を動かす機会が減るほど失われていく。元記事は、この逆説をそのままSREに当てはめます。
具体的には、AIがすでに肩代わりしている、あるいはしやすい仕事として、アラートのノイズ削減とグルーピング、既知の障害に対する runbook の実行、ログパターンの検出、過去の障害データを使った初歩的な root-cause の示唆、クラッシュした pod の再起動や負荷の高い service のスケーリングのような自動復旧を挙げています。一方で、これから狙われる領域として、metrics・logs・traces をまたいだ相関分析、部分的にしか理解されていない障害の自律的な原因分析、ユーザー影響が出る前の予測検知、変更リスクの評価、ロールバックの自動化などを並べています。
ここで元記事は PagerDuty の tier 分けも紹介します。Tier 1 は既知の問題で、修正も分かっているので完全自動化。Tier 2 はある程度分かっている問題で、AI が提案し人間が確認する。Tier 3 は複雑で前例のない障害なので、人間が主導しAIは補助役に回る、という整理です。ただし著者は、もし人間のSREが Tier 3 だけにしか触れなくなったら、その「未知の障害」を解く勘や直感はどこで育つのか、と疑問を投げます。障害対応の直感は、深夜の呼び出しや、何度も似たような火消しをする中で育つものだという見方です。
そのうえで、著者は医療と航空の例を持ち出します。医療では、AI補助つきで大腸内視鏡を行った endoscopist が、補助なしの polyp detection 率を28%から22%へ落とした研究を引用しています。航空では、autopilot に頼る長距離パイロットの状況認識や手動操縦能力が落ちることが示され、FAA が対策として手動飛行時間を義務づけていると述べます。つまり、道具が便利になるほど、その道具なしでやる力は落ちうる、というわけです。
元記事の後半は、deskilling だけでなく never-skilling という言葉も使います。deskilling は「一度はできたが、今は弱った」状態ですが、never-skilling は「最初から十分に身につける機会がない」状態です。若手SREが、最初からAIに incident response を任せる環境に入ると、土台になる経験そのものが積みにくい。著者はこれを、回復しにくい訓練パイプラインの問題だと見ています。最後に、対策としては、あえて一部の障害を人間の練習機会にする「deliberate inefficiency」や、人間が承認だけする形ではなく、AIと並走して問題に関わる human-in-the-loop を勧めています。書き手自身が属する SigNoz は observability platform を作っており、将来的には AI を強めつつも、人間が重要な決定を握り続ける設計を目指すと説明しています。
この文章でいちばん刺さるのは、AIをめぐる議論を「置き換え」から「劣化」にずらした点だと思います。多くの人は、AIがSREを代替するか、しないか、という二択で考えがちです。でも現場で本当に起きやすいのは、その中間にある静かな変化でしょう。すぐ答えを返してくれる仕組みが入ると、人はまずそれを見るようになる。するとログを自分で追う回数が減り、仮説を立てる前に答えを見てしまい、結果として「自分で考える筋肉」が弱る。これはSREに限らず、検索、翻訳、コードレビューにも広く起きる現象だと思います。
ただ、ここで少し慎重でいたいのは、deskilling を「悪いこと」とだけ決めつけるのも単純すぎるからです。専門職には、実際には使わない知識や手順を抱え込む負担もあります。障害対応の多くは既知パターンで、そこにAIを入れて人間の手を減らすのは合理的です。問題は、効率化で浮いた時間が本当に学習に回るのか、それとも単に「便利だから全部AIでいい」に流れてしまうのか、という点です。元記事はその分岐をかなり鋭く突いている。私はここが一番重要だと思います。
PagerDutyの tier 分けは直感的で、よくできています。既知の障害は自動で直し、曖昧なものはAIが補助し、未知のものだけ人間が主導する。運用の理屈としてはきれいです。でも実際には、そのモデルは人間の学習曲線をかなり細くしてしまう恐れがあります。Tier 1 と Tier 2 をAIに渡しきると、若手も中堅も「普段の手触り」を失いやすい。障害対応の現場で大事なのは、答えそのものより、どこを疑い、どこを捨てるかの感覚です。そこはカタログ化しにくい。
ここで面白いのは、著者が「人間を残すべきだ」と言うだけでなく、「人間を残し方」が重要だと言っていることです。単なる承認ボタン係では駄目で、AIの提案を見ながら自分で観察し、問いを立て、切り分けを進める必要がある。これは教育の話でもあります。医師やパイロットと同じで、訓練と本番の境目が薄くなった職種では、ただ見ているだけでは上達しません。SREも同じで、AIがあるからこそ「どう関わるか」を設計しないと、将来の事故対応力を前借りしてしまうのではないかと思います。
元記事が挙げる deliberate inefficiency は、かなり現実的な処方箋です。普通は、効率化のために自動化します。逆に、あえて一部は人間がやる前提を残す。これは一見むだに見えますが、保険としては理にかなっています。航空が手動飛行時間を義務づけたのも、平常時の生産性より、非常時の能力維持を優先したからです。SREでも同じで、すべてをAIに最適化すると、短期的には見栄えがよくても、長期的にはチームの回復力が落ちるかもしれません。
ただし、ここには運用上の難しさがあります。現場は忙しいので、「練習のためにAIを使わない時間」を確保するのは簡単ではありません。しかも、プロダクション障害でわざわざ人間にやらせるのは、リスクがあるように見える。だからこそ、訓練用の小さな障害演習や、影響の小さい領域での手動対応、あるいは AI の提案を人間が自分で再構成する練習が必要になるのだと思います。効率を少しだけ捨ててでも、チーム全体の「いざという時の底力」を残す。ここは、AI導入の議論で軽く扱われすぎている論点ではないでしょうか。
元記事は、自社の立場もかなり率直に書いています。SigNoz は observability platform を作っていて、metrics・traces・logs を直接持っていることが強みだと述べます。多くのAI SRE製品は observability ツールに API 経由でつながるだけなので、データが二次的になりやすい。対して、自分たちはデータ層そのものに近いので、より深く、文脈を理解したAI機能を作れる、と主張しています。ここは営業的な文脈もありますが、同時に重要な示唆でもあります。AIの精度は、モデルだけでなく、どれだけ現場の文脈に触れているかで大きく変わるからです。
一方で、著者は「AIがSREを置き換える未来」を売ってはいません。むしろ、人間が決めるべきところは残し、そのうえでAIが人間を sharp に保つように設計したい、と言っています。私はこの立場は比較的健全だと思います。誇張された自動化の未来像より、実際の運用で何が壊れやすいかを見ているからです。AIを導入する企業は増えても、技能の維持まで設計している例はまだ少ない。だからこの文章は、SREの話であると同時に、AI時代の職能訓練をどう守るかという問いを投げているのだと思います。
