SREや運用の現場では、AIがアラートを見て、原因を推測し、ログやメトリクスを調べ、場合によっては修復まで進める時代に入りつつあります。便利であるのは間違いないのですが、その裏で人間の側がシステムを理解する機会を失っていく、というのが今回の話です。事故対応の平均時間は短くなっても、複雑な障害に当たったときには、かえって人間が弱くなるかもしれない。著者はそこに強い危機感を示しています。単なるAI賛美でも反AIでもなく、運用の腕がどう鈍るのかをかなり具体的に掘っているのが面白いところです。
元記事の著者 Sylvain Kalache は、2012年にLinkedInでSREをしていたころ、自律的に自己修復し、過去の障害から学ぶシステムを設計したと振り返ります。当時は今ほどAI能力が高くなく、その仕組みは試作にとどまったものの、いまでは似た発想が現実のツールとして動いている、と述べます。これらのAI支援インシデント対応ツールは、アラートを確認し、仮説を立て、telemetryを問い合わせ、最近のデプロイと照合し、修正の実行まで担える。著者はその実力を認めつつも、運用担当者がシステムとの距離を失っているのではないかと心配しています。
彼の中心的な主張はかなり明快です。AIが定型的な障害をうまく処理するほど、人間はその種の障害を自分で扱う練習を積めなくなる。ところが本当に厄介なのは、AIでは解けない曖昧で深刻な障害です。そうした局面では、これまでより経験不足の人間が前に出ることになる。著者はこの構図を、1983年の Lisanne Bainbridge の論文「The Ironies of Automation」と結びつけています。自動化は、運転者やオペレーターが日常的な作業を練習する機会を減らす一方で、例外的で異常な状況への責任は人間に残す、という指摘です。
著者は将来、AI支援の事故対応によって平均MTTRは下がるが、複雑な障害の解決時間はむしろ伸びるだろうと予測します。理由は、応答担当者がシステムへの勘所を失い、調査そのものに手間取るからです。そこで彼が持ち出すのが航空業界です。飛行機は自動化が進んでいても、エンジン故障、計器不良、離陸中止、失速といった異常時はパイロットが対応しなければなりません。しかも、こうした事態は非常にまれです。たとえば現代のタービンエンジンは、100,000エンジン飛行時間あたり1回未満しか飛行中停止しないとされ、商業パイロットが一生に一度も実地では遭遇しないこともある。だからこそ、パイロットはシミュレーターで定期的に訓練する。米FAAの規則では、機長は6か月ごとに反復訓練か技能確認を受ける必要があり、離陸時のエンジン故障のようなシナリオも含まれる。
ソフトウェアの障害は人命に直結しないことが多いが、それでも技能の維持は軽視できない、と著者は言います。そこで彼が提案するのが、ソフトウェア業界にも事故シミュレーターを持ち込むことです。自身が働くRootlyでは、Uptime Labsと組み、現実味のあるインシデント演習を行っていると紹介します。参加者はシミュレートされたECサイト停止の場面でインシデントコマンダー役を担い、observabilityツールを使いながら、Slack上のLLM駆動の関係者たちと調整します。CEOやカスタマーサポートに対応しつつ、状況をさばかなければならず、情報の断片から意味をつかむこと、簡潔に伝えること、周囲をまとめることを実地で練習できる、というわけです。
さらに著者は、AIを「教師」として使う道もあると認めます。エージェントに、どういう手順を踏んだのか、どのシグナルを見たのか、なぜそう診断したのかを説明させることはできる。ただし、説明を聞くことと、実際に自分で動くことは別物だと強調します。テニス選手の試合を見て少しは学べても、上達するには自分でコートに立つしかない、という比喩です。著者自身も、かつてプログラミング学校を作り、講義より実践で学ぶ教育を重視してきたと明かします。Dropboxから、卒業生がトラブルシューティングにまだ弱いと聞いたときは、壊れたインフラを渡して診断・修復させる課題を作ったそうです。
最後に著者は、LLMが仕事を肩代わりするほど、チーム内には「comprehension debt」がたまると警告します。つまり、システムがどう動いているかと、担当者がどこまで理解しているかの間に、見えない借金のような差が広がる。だからこそ、日常的にシステムに触れ、知らない障害に向き合い、圧力下で対応し、SEV0のような重大障害で必要になる連携や説明を練習するべきだ、というのが記事全体の骨子です。
この文章でいちばん刺さるのは、AIの導入が「楽になる」こと自体を否定していない点です。むしろ著者は、平均MTTRが下がる未来をかなり自然なものとして受け入れている。そのうえで、楽になったぶんだけ人間の訓練機会が削られる、と見る。ここが単純な「AIは危ない」論と違います。現実には、夜間のアラート対応や定型障害の一次切り分けをAIに任せられるなら、現場は助かります。眠れる夜が増えるのは良いことです。ただ、その成功が積み重なるほど、担当者は「自分の手でログを追って、仮説を潰して、復旧判断をする」感覚を失う。便利さの代償が、能力の摩耗として後から効いてくるわけです。
ここで大事なのは、失われるのが単なる知識ではなく、状況判断の勘だということだと思います。障害対応は、手順書を読むだけでは終わりません。グラフのどこに違和感があるか、どのアラートを優先するか、何を切り捨てるか。そういう判断は、失敗を含む反復でしか身につきにくい。AIがうまく回るほど、人間は「考えなくても済む仕事」ばかり触るようになり、いざ曖昧な異常に当たると急に弱くなる。著者の言う ironies of automation は、まさにそこを突いています。自動化は、技能を置き換えるだけでなく、技能を育てる場まで奪うのです。
航空との比較は、少し持ち出しやすい例に見えるかもしれません。飛行機は人命に直結するから厳しく訓練するのであって、ソフトウェア運用を同列に扱うのは大げさだ、という反論はありえます。けれど著者が言いたいのは「死活問題だから同じようにせよ」ではなく、「極端にまれな失敗に備える仕組みは、他業界でも学べる」という点でしょう。エンジン停止が100,000エンジン飛行時間に1回未満という希少性は、逆にシミュレーター訓練の価値を示しています。実地で起きないからこそ、実地以外で練習するしかない。
ソフトウェア運用も似ています。日常的な再起動やロールバックは、AIでも人でもこなせる。でも、本当に困るのは、今まで見たことのない相関の崩れ方や、複数の変更が絡んだ障害です。そういう場面では、過去に何度も手を動かした人ほど強い。だから私は、事故シミュレーターという発想はかなり筋がいいと思います。机上の読書会やrunbookの読み合わせより、実際にSlackが飛び、ダッシュボードが揺れ、周囲から判断を迫られるほうが、ずっと本番に近い。LLMを相手役にするのも現実的です。人間のロールプレイでは毎回同じにはならないし、意地悪な状況を作るのも難しいからです。
著者は、AIに手順や根拠を説明させることはできるが、それは実践の代わりにはならないと書いています。この点は、いま多くの現場で見落とされがちだと思います。生成AIは、答えを返すだけでなく、なぜそうしたかも説明してくれる。そのため人は「理解した気」になりやすい。けれど、障害対応で必要なのは、説明を読んで納得することではなく、不完全な情報の中で次の一手を出すことです。説明は後から得られても、その瞬間の緊張感や優先順位づけは置き換えられません。
この違いは、教育の文脈でも重要です。著者が触れている progressive education は、知識を受け取るより、まず試して壊して直すことで学ぶ考え方です。運用技能もまったく同じで、画面越しの理解と、手を動かした理解の間には深い差がある。AIが「先生」役を強めるほど、現場は「生徒」でいられなくなる。だからこそ、説明は補助輪であって本体ではない、という線引きが必要です。私はここに、AI時代の運用教育の難しさが集約されていると思います。
この話を読むと、AI SRE をどう使うかより、チームがどう訓練するかのほうが本質に見えてきます。AIを入れたから終わり、ではなく、AIが日常障害を片づけてしまう前提で、どうやって人間の筋力を保つかを設計しないといけない。著者は tabletop exercise や chaos engineering も挙げていますが、今後はそれだけでは足りず、実際のAI運用を織り込んだ定期演習が必要になるはずです。AIが調査を進める一方で、人間は途中から引き継ぐ。あるいは、あえてAIを外して手動で復旧する訓練を挟む。そういう“手放し方”まで含めて、運用の設計になるのだと思います。
そして、これはSREだけの問題ではありません。コードレビュー、セキュリティ対応、社内IT、カスタマーサポートまで、AIがまず一次対応する現場は増えていくはずです。便利な道具は、使う人の身体感覚を鈍らせます。だから、何をAIに任せ、何を人間があえてやり続けるかを決めるのは、技術選定以上に大事です。著者が最後に言う「理解の借金」は、かなりいい表現だと思います。借金は放っておくと利子がつく。AI時代の運用も同じで、練習を先送りするほど、いざという瞬間の代償は大きくなるのではないでしょうか。
参考: AI handles incidents, engineers lose touch with their systems
