組織の93%が「AI起因のインフラ障害」を経験——調査が映す“導入後”の現場

AIにインフラ構築のコードを書かせる動きが広がるなか、調査対象になった組織の93%が「AIが原因のインフラ障害」を少なくとも一度は経験していた——そんな結果が、インフラ管理ツールを手がけるSpaceliftの年次レポートで報告されました。効率化の華やかな話の裏で、運用の現場では何が起きているのか。数字から見えてくるのは、AIの速さに運用側の体制が追いついていない、という地味だが切実なズレです。

「インフラをコードで書く」という前提

話の土台にあるのは「IaC（Infrastructure as Code＝インフラのコード化）」という考え方です。サーバーやネットワーク、クラウドの設定を、管理画面を手で操作して作るのではなく、設定の中身をコードに書いて自動で構築する。同じ環境を何度でも正確に作り直せて、変更の履歴も残るので、いまの大規模なシステム運用ではすっかり定番になっています。

そこにAIが入ってきました。最近は「バイブコーディング」——AIに指示を出して、中身を細かく確認しないまま“とりあえず動くコード”を作らせるやり方——が、アプリ開発だけでなくインフラの設定にまで染み出しています。書くのが速くなるぶん、人の目を通っていないコードが本番環境に届きやすくなる。今回の調査は、その「速くなった側」と「それを受け止める側」のあいだに生まれたひずみを、数字にしたものです。

93%という数字の中身

レポートのいちばん目を引く数字が、冒頭の93%です。調査に答えた組織の9割超が、AIが原因と思われるインフラ障害を過去1年のうちに少なくとも一度は経験した、と答えています。中身は幅広く、やり直し作業の発生から、設定ミスによるセキュリティ上の穴、コンプライアンス違反、それに「構成のドリフト」——実際のシステムの状態が、本来こうあるべきと決めた設定から少しずつズレていってしまう現象——まで含まれます。

背景には、開発の速度だけが先に上がっている事情があります。回答者の67%が「AIの活用はインフラ部門より開発部門のほうが先行している」と答え、86%が「AIによってインフラ部門への負荷が増えた」と感じています。その負荷は具体的な形になって表れていて、セキュリティ上の弱点が以前より早く現れるようになった（40%）、ガバナンス（統制）が難しくなった（40%）、変更の量が増えた（37%）、処理の流れに負担がかかるようになった（35%）、構成のドリフトが増えた（35%）、と続きます。開発側がAIで一気に加速したぶん、しわ寄せが運用側に集まっている構図です。

「確認せずに通す」がどこまで来ているか

では現場は、AIが書いたコードをどれくらい信用して通しているのか。ここがこの調査のいちばん刺さるところです。レポートによれば、78%の組織がインフラ用のコードをAIに生成させ、それをきちんとレビュー（中身の確認）せずに使っているといいます。さらに、AIが書いたインフラコードを、ほとんど確認せずに本番へ反映してよいと考える割合は76%にのぼりました。内訳を見ると、33%は「まったく確認せずそのまま本番に適用する」と答え、別の43%も「ごく軽い確認だけで通す」としています。

こうした“確認せずに通す”姿勢は、特定の領域に偏っているわけではありません。アプリのコード（79%）、インフラのコード（78%）、ルールや権限を定めるコード（78%）と、ほぼ横並びでした。一方で、AIが生成したインフラコードがどれだけ流れているかを把握している組織は15%、AIによる変更のエラー発生率を測っている組織は20%にとどまります。つまり、任せている量も、その結果も、ほとんど誰も数えていない。それでも障害は起きる、というのが93%という数字の正体です。

自信と備えのズレ

この調査がうまく突いているのは、「うまくやれている」という感覚と、実際の備えとのあいだに開いた溝です。インフラ部門のリーダーの86%が「自社はAIをきちんと統制できている」と自信を見せた一方で、AIに関する正式なガバナンス方針を実際に用意できている組織は30%でした。「まだ大きな問題が起きていないから、たぶん大丈夫」という思い込みが、いちばん備えの薄い組織でいちばん強い、という指摘もされています。

レポートは回答組織を、AIへの成熟度で4段階に分けています。最も整っている「先行組（Pioneer）」は全体の19%。残りは段階を追って分布しています。面白いのは、先行組のほうがAIにインフラコードを書かせる割合はむしろ高い（先行組86%に対し、最も備えの薄い層は69%）こと。違いは、使うかどうかではなく、統制された仕組みの中で使っているかどうかにあります。問題のある出力が本番に届く前に自動で止まる仕組みがあれば、速さはそのまま強みになる——レポートはそう整理しています。アプリの不具合なら一つの機能が壊れるだけで済むことも多いのに対し、インフラの設定ミスは影響範囲がずっと広がりやすい、という違いも、現場の緊張感を高めています。

この調査の出どころと、読むときの注意

数字を受け取るときに、いくつか頭の隅に置いておきたい点があります。まず、このレポートを出したSpacelift自身が、ここで言う「統制された仕組み」——インフラのコードを安全に流すためのオーケストレーション基盤——を売っている会社だということ。調査の実施はPanterra Groupという別の調査会社ですが、結論が「だからガバナンスが要る」に着地する構造は、自社製品の必要性とぴったり重なります。数字そのものが操作されているという話ではなく、何を強調し、どう枠づけるかには発信元の立場が乗りうる、という当たり前の前提です。

もう一つ、対象の偏りも見ておきたいところです。回答者は北米の、従業員250人以上の組織で、しかもインフラのコード化に詳しい人に絞られています。世界中のあらゆる組織を映した数字ではなく、ある特定の層の話です。「障害を経験した」というのも自己申告で、定義が広い。だから「9割が大事故を起こした」と読むのは行きすぎで、「AIを急いで取り込んだ層では、大小さまざまなトラブルがほぼ全員に一度は起きている」くらいに受け止めるのが妥当です。それでも、AIに任せる速さと、それを点検する仕組みのあいだに開きが生まれている、という大枠は、ほかの調査や現場の声とも重なっており、無視はしにくい傾向だと言えます。