2025 was the year the internet broke: Studies show increased incidentsの意訳です。
増え続ける障害、拡大するリスク：データが示す現実
10月、www.IsDown.app の創業者がReddit上で 衝撃的なグラフ を公開しました。
同サイトは「あるWebサイトがダウンしているかどうか」を確認するための信頼性の高い情報源で、2022年以降の障害発生状況を継続的に追跡しています。
そこで示された統計は非常に不安を覚えるものでした。2025年の障害発生数は、過去のどの年よりも多く、しかもその数は2022年以降、継続的に増加しているというのです。
彼は Reddit上の投稿 の中で、この傾向を引き起こしている可能性のある要因について言及しています。AIが生成したコードは繰り返し話題に上がりましたが、一方で、オフショア開発や過度な人員削減が原因ではないかと指摘する声もありました。
明らかなのは、2025年は過去と比べて、バグがより頻繁に本番へ流入し、それがダウンタイムにつながっているという点です。
このサイトのデータは、複数の調査や研究結果とも一致しています。
複数国にまたがる 1,000人以上のCIO、CSO、ネットワークエンジニア を対象とした 調査 では、84%の企業が近年ネットワーク障害が増加していると回答し、そのうち半数以上が 2年間で10〜24%の増加 を経験していました。
ThousandEyesのブログ によると、2025年1月の世界的な障害件数は1,382件でしたが、2月には1,595件（+15%）、3月には2,110件（+32%）まで増加し、その後5月には1,843件までやや減少するなど、上昇圧力の強い不安定な推移 を示しています。
では、実際に何がこの障害急増を引き起こしているのでしょうか。そして、開発者として私たちは何ができるのでしょうか。
数十億ドル規模の障害と、解決策を探す企業たち
巨大企業で障害が発生すると、多くの企業が巻き添えになります。
今年初めにAWSがダウンした際、Webサイトは停止し、決済は拒否され、さらに悪いことに Fortnite のゲームまで中断されました。
障害後、人々は US-EAST-1 の機能停止によって、どれほどの経済活動が失われたのかを推計し始めました。
Amazonはかつて、レイテンシが100ミリ秒増えるだけで売上の1%を失う と主張しています。では、数時間に及ぶ障害は、Amazon自身や、その上で動いている企業群にどれほどの影響を与えたのでしょうか。
Forbesの試算 では 数十億ドル規模の損失 が発生し、あるCEOは 数千億ドルに達する可能性すらある と述べています。
この出来事を受けて、マルチクラウドは 新しくもあり、古くもあるバズワード として再浮上しました。
企業は、単一のクラウドプロバイダに過度に依存するリスクをどう管理すべきかに頭を悩ませています。
しかし、仮にマルチクラウドへ移行したとしても、決済プロセッサが障害を起こせば、収益は同じように止まります。あるいは、自社コードのバグによって運用が停止する可能性もあります。
本質的な解決策は、ダウンタイムやインシデントが増加し続けているこのトレンド自体を、業界全体として改善する方法を見つけることです。
なぜなら、この増加を引き起こしている要因は、業界として完全に制御可能な範囲にあるからです。
AI、コード品質、バグはどう関係しているのか
では、このトレンドに何が寄与しているのでしょうか。
多くの人が真っ先に思い浮かべるのは、「インシデント増加の原因はAI生成コードではないか」という点でしょう。
私たちはすでに、人間のエンジニアであれば単独では入れなかったであろう大量のバグが、AI生成によるコード（以下、AI生成コード）から見つかっていることを経験しています。
これは単なる体感ではありません。データも明確に裏付けています。
私たちの最近の AIと人の、コード生成に関するレポート では、AIコードは問題やバグが1.7倍多いことが分かりました。特に、インシデントにつながりやすい ロジック／正しさの問題（最も多いカテゴリ） や セキュリティ問題（1.5〜2倍） が増加しています。
2025年8月に公開された大規模な学術研究
“Human-Written vs. AI-Generated Code: A Large-Scale Study of Defects, Vulnerabilities and Complexity” では、50万件以上のPythonおよびJavaコードを比較し、AI生成コードは高リスクな脆弱性を含む傾向が強いことが示されました。
これが障害・インシデントに対して意味すること
これらを総合すると、インシデントや障害の発生頻度は明確に増加傾向にあります。
チームがAI生成・AIサポートによるコードに依存するほど、次のような新たなリスクにさらされます。
潜在的な脆弱性の増加
生成されたコードの可視性低下
スピードに追いついていないQA／テスト／レビュー体制への過剰な負荷
要するに、高速なリリース、AIへの強い依存、成熟しきっていないプロセス が組み合わさることで、「何かが壊れる」確率が高まっているのです。
問題は内側から来ている：障害を例外扱いするのをやめるべき理由
データが示す通り、これは構造的な問題です。しかし私たち開発者は、各インシデントを個別の出来事として捉えがちです。
その見方には問題があります。
すべての障害を「どこか別のチームで起きた一過性の事故」として扱っていると、変化失敗率、環境の複雑化、ツールチェーンの脆弱化 といった大きな流れを見逃してしまいます。
そこにAI生成コードの利用拡大が重なることで、リスクの性質自体が変わっています。
信頼性の根幹は、もはやインフラだけではありません。どのようにソフトウェアを作り、レビューし、テストし、デプロイし、運用し、その中にAIをどう組み込むか にかかっています。
AWSのような大規模障害が覆い隠している事実は、「問題はサードパーティだけではなく、私たち自身の内部にもある」ということです。
業界として何をすべきか（※これは営業ではありません）
通常であれば、ここで「もしAWSが自社製品を使っていれば障害は起きなかった」という売り文句が出てきます。しかし、それでは何の解決にもなりません。
構造的な問題は、新しいツール1つでは解決できないからです。
7月、私たちは懸念すべきトレンドについて書きました。
企業が コードの何パーセントがAI生成によるものか を価値ある指標のように語り始めていたのです。GoogleやMicrosoftは、新規コードの30%がAI生成だと主張していました。
当時、私たちは次のように書いています。
「量だけに基づく指標は、AI生成コードのデバッグやレビューにどれだけ時間がかかったかを示さない。こうした文脈がなければ、30%という数字は実際の効率や品質をほとんど語らない」
私たちの提案は、AI生成コード＝良いこと という単純な見方から脱却し、次のような指標に目を向けることでした。
現場のワークフローを理解するエンジニアと共同で設計されている
表面的な導入率ではなく、実際の生産性やビジネス成果と結びついている
硬直的な強制ではなく、文脈を踏まえた柔軟な実験を促す
例えば、AIを使ったコーディング時間とデバッグ時間の比率を測る、あるいはAI利用拡大とともにインシデント数や深刻度、コストを追跡する、といった指標です。
AI導入のリスクを下げる方法
多くのチームはすでにAIツールを有効活用しています。問題はAI自体ではなく、導入の仕方にある場合が少なくありません。
以下は、AIコーディングツール導入を考える上での現実的なアプローチです。
レビュー・QA体制を適切に強化する
AIが開発者の時間を削減すると聞けば、人員削減を考えるのも無理はありません。しかし、それは下流工程への影響を無視しています。
AI導入で最も見落とされがちな点は、生成されるコード量が爆発的に増えることです。
PR数が倍増してもレビュアーが増えなければ、どんな優れたプロセスでも破綻します。
AI時代の開発を安全に進めるには、レビュー・QA・テスト体制も同じペースで強化する必要があります。
何を見るべきかを理解する
これまでAIがバグを増やすことは分かっていましたが、どの種類のバグが多いのかは明確ではありませんでした。
AIと人の、コード生成に関するレポート により、AIは アルゴリズムやビジネスロジックの誤りを2.25倍、並行処理制御の誤りを2.29倍 起こしやすいことが分かっています。
設定ミス、エラー処理、依存関係の誤りも、ほぼ2倍です。
テストとレビューを左にシフトする
AI生成コードは、一見正しく見え、コンパイルも通り、表面的なチェックも通過します。しかし、微妙な論理ミスやエッジケースの欠陥を隠していることがあります。
そのため、テストとレビューをできる限り上流に移す必要があります。AI提案の段階で軽量な検証を行い、人のレビューに入る前に問題を検出します。
カオス／レジリエンステストを拡張する
AI生成コードは予測不能な失敗をすることがあります。
意図的に障害を注入することで、負荷時や異常系での挙動を確認し、弱点を露呈させることが重要です。
AIリテラシーとセキュアコーディング教育を統合する
AIは直感的に使えますが、新しい失敗モードを内包しています。
プロンプト設計、モデルの限界、幻覚的なAPI呼び出し、不安全なデフォルトなどを理解する教育が不可欠です。
2026年には状況を好転させられる（希望はあります）
2025年の教訓は明確です。責任から自動化で逃げることはできません。
AIがより多くのコードを書くなら、人間はより多くのコードをレビューするための時間・ツール・人員を必要とします。
正しいテスト、強靭なレビュー体制、オーナーシップ文化を持つチームは、ダウンタイムを犠牲にせずAIの力を活かせます。
CodeRabbitがどのように役立つか興味がありますか？
Clerkを支援した事例 を読むか、AIレビューを今すぐ試してください。
