深夜のアラートが自動で復旧するようになった、という報告は歓迎されます。当直の呼び出しが減り、翌日の生産性が上がり、運用費の見通しも良くなります。ここまでは提案どおりです。
問題が出るのはその先です。半年ほど経って、AIが直せない種類の障害が来ます。原因が複数にまたがっていて、症状も過去と一致しない。対応にあたった担当者が、そこで初めて気づきます。この半年、自分はこのシステムのログをまともに読んでいなかった、と。
これは能力の問題ではありません。練習の機会がなくなっていたという、構造の問題です。
1983年に指摘されていたこと
この現象には名前があります。人間工学の研究者リサン・ベインブリッジが1983年に発表した論文「Ironies of Automation（自動化の皮肉）」で示された指摘です。
要点はこうです。自動化は簡単な仕事から順に引き受けます。結果、人に残るのは自動化できない難しい仕事だけになります。ところが人は、簡単な仕事の繰り返しを通じて難しい仕事に必要な勘を養っていました。簡単なほうを取り上げると、難しいほうへの備えも一緒に失われます。
システム運用に置き換えると、こうなります。ディスクが埋まった、プロセスが落ちた、証明書が切れた——こうした定型的な障害は、担当者が「このシステムはこう壊れる」という感覚を安全に身につける機会でした。その機会を、いちばん最初にAIが引き受けます。
航空業界の答えは「訓練を義務にする」
同じ問題に先に直面したのが航空業界です。自動操縦の普及で手動操縦の機会が減った一方、自動操縦が対応できない事態への備えは必要でした。
米国の規則では、旅客機の運航乗務員に対して6ヶ月ごとの定期訓練が課されています。訓練には、離陸中のエンジン故障のような、実機ではまず起こしたくないが、起きたら対処しなければならないシナリオが含まれます。
順序が重要です。訓練を「余裕があればやるもの」ではなく、資格の維持条件にしています。余裕があるときにやる形にすると、忙しい月から順に飛びます。
ソフトウェアの運用でも同種の取り組みが始まっています。インシデント管理の Rootly は Uptime Labs と組み、ECサイトの障害を模した演習環境を提供しています。参加するエンジニアは実際の監視ツールを使いながら指揮役を務め、関係者への報告や判断を求められます。関係者役はLLMが務めるため、人を集めずに実施できる形になっています。
委託する側が契約に書いておくこと
保守を外部に委託していて、そこにAIによる自動対応が入ってくる場合、見積書に出てこない項目があります。削るとしばらく何も起きないので、削られやすい項目でもあります。
1. AIが対応した障害の事後共有。 自動で直った障害の内容が、月次の報告に出てくるかどうかです。「自動復旧 47件」という数字だけでは、システムがどう壊れているのかが誰にも伝わりません。何がどう壊れて、どう戻したのかが読める形で残る必要があります。何を正常と定義しているかを委託先と揃えていない場合、ここが最初に曖昧になります。
2. 手順書の更新責任。 AIが対応できた分だけ、人向けの手順書は更新されなくなります。1年後、AIが対応できない障害が来たときに開かれる手順書が2年前のものだった、という状態は避けたいところです。誰が、どの頻度で更新するのかを決めておきます。
3. 人が対応する演習の頻度。 年1回でも構いません。「AIを使わずに一次切り分けを行う」時間を意図的に作るという約束が契約にあるかどうかです。ここが空欄だと、実施されません。
| 項目 | 見積書での扱われ方 | 削ったときに起きること |
|---|---|---|
| 自動対応の事後共有 | 「レポート」に含まれる扱い | 障害の傾向が誰にも見えなくなる |
| 手順書の更新 | 初期構築に含まれ、その後は無し | 非常時に古い手順が出てくる |
| 人による演習 | そもそも項目が無い | 対応できる人が社内外からいなくなる |
3行目は、保守契約の作業時間や範囲を見直すタイミングで足すのが現実的です。新規の契約時にゼロから交渉するより通りやすくなります。
AIを入れないほうがよい、という話ではない
念のため書いておくと、自動対応を入れない選択のほうが安全だ、とは考えていません。定型障害の自動化は、担当者を消耗から守ります。夜中に叩き起こされる回数が減ることの価値は大きいものです。
脆弱性の修正を自動生成する仕組みについても同じ整理になります。導入すると人の作業は減りますが、減った作業の中に「見て理解する」工程が含まれていたかどうかで、その後に必要な補いが変わります。
区別すべきは次の2つです。
- 作業の削減（手を動かす時間が減る）は、そのまま利益になる
- 理解の削減（何が起きているか見なくなる）は、あとで請求書が来る
自動対応の導入が前者だけで済んでいるかを、半年に一度確認する。それだけで、上に挙げた3項目が抜け落ちていることに気づけます。
次にやること
直近3ヶ月で自動的に復旧した障害の件数と、その内容を委託先に出してもらってください。件数しか出てこない場合は、その時点で1つ目の項目が欠けています。
出てきた内容を読んで、社内の誰か1人が「これはどう対処したのか」を説明できるかを確認してください。説明できる人がいないなら、次の契約更新で演習の項目を足す番です。
保守運用の体制の見直し、AIによる自動対応を入れたあとの引き継ぎ設計、障害対応の手順書の整備については、グリームハブの開発・AI・自動化のご相談で承っています。現在の運用体制と委託の範囲によって進め方が変わるため、お問い合わせからご相談ください。
