2026年もインターネットは壊れ続ける、アイはその一因である

2025年はインターネットが壊れ続けた年だったように感じる人も多いと思います。2026年も同様の年になる可能性が高いです。アウトエージ、インシデント、プロダクションの障害は、エンジニアリングチームを驚かせる稀な出来事ではなくなりました。現代のソフトウェア開発の背景にある定常的な条件になっているのです。

アウトエージトラッカーのIsDown.appなどのデータによると、2022年以降、インシデントは年間で増加しているということです。この傾向に反する兆候は見られません。また、独立した調査でも同様の結果が報告されています。1,000人以上のCIO、CISO、ネットワークエンジニアを対象にした世界的な調査では、84%の組織がアウトエージの増加を報告しており、そのうち半数以上の組織では2年間で10〜24%の増加が見られたということです。

ThousandEyesの調査でも同様の波動が見られ、隔月的な大きな変動が見られます。これは、単発の障害ではなく、継続的な圧力の増加を示唆しています。気になるのは、毎日の生活に欠かせないシステムが、クラウドインフラストラクチャー、観測可能性、自動化への投資にもかかわらず、耐久性を増しているのではなく、むしろ脆弱性を増しているということです。

大手プラットフォームがダウンすると、影響は即時に広がります。支払いが失敗し、消費者アプリがフリーズし、内部ツールが停止し、サプライチェーン全体が影響を受けます。さらに、経済損失の見積もりは、たびたび100億ドルを超えることがあります。たとえば、アマゾンは、ECのリーダーであり、ジェネレーティブAIの導入によりインシデントが増加したと報告しています。このため、アマゾンは最近のアウトエージの増加について、エンジニアリングチームで深く検討することになりました。

大きなアウトエージの度に、冗長性、多クラウド戦略、ベンダー集中リスクについての議論が繰り返されます。これらの議論は重要ですが、大きな絵は見えていません。

インフラプロバイダーが仕事を悪くしているのではなく、ツールが成熟しているにもかかわらず、インシデントが増加しているのはなぜでしょうか？

AIがソフトウェアの出荷方法を変えた

アウトエージの増加と同時に起こっている大きな変化の一つは、AI支援ソフトウェア開発の普及です。AIコーディングツールは、実験的なものではなくなりました。IDEやCLIに組み込まれており、AIでコードを生成することが容易になりました。

業界全体で、開発者1人当たりのプルリクエスト数が大幅に増加しており、一部の分析では、AIがアウトプットを加速させているため、約20%の年間増加が見られたということです。同時に、プルリクエストあたりのインシデント数も、23%以上増加しています。

これは、因果関係を証明するものではありませんが、無視することは難しいでしょう。AIはコードを書くことを速くするだけでなく、リスクの形を変えます。現在、ほとんどのチームは、AI支援コードに経験豊富なエンジニアが独自に導入しなかったであろうバグの連続的な流れに出会っています。

これらは、劇的な構文エラーや明らかに壊れた変更ではありません。むしろ、繊細な論理的間違い、設定ミス、ガードレールの欠如、エッジケースの障害です。これらは、一見すると妥当に見えますが、実際には問題があります。

AI生成コードは、クリーンにコンパイルされ、基本的なテストに合格し、妥当なコードのように読めます。問題は、AIが新しい種類のバグを生み出すのではなく、既知のバグをより頻繁に、そして既存のレビューとQAプロセスを圧倒するスケールで生成することです。

AIがより多くのコードを書くときにデータが示すもの

私たちは、AI vs. Human Code Generation Reportのために、数百のオープンソースプルリクエストを分析し、この直感に数字を付けることを試みました。AIと共同で作成された変更は、人間だけで作成されたプルリクエストと比較され、サイズで正規化された場合、AI支援PRには約1.7倍の問題が含まれていることがわかりました。

より心配なのは、これらが1.4〜1.7倍の重大な問題を示したことです。論理的および正確性の問題、つまり、制御フローの欠陥、依存関係の不正使用、設定エラーは約75%増加しました。エラーハンドリングのギャップ、たとえばnullチェックの欠如、例外パスの不完全性、ガードレールの欠如はほぼ2倍の頻度で発生しました。

セキュリティ上の問題も増加し、一部のカテゴリでは2.7倍の頻度で発生しました。特に、資格情報の取り扱いと不安全なオブジェクト参照についてです。コンカレンシーと依存関係の正確性の問題も約2倍の頻度で増加しました。

人間も同じミスを犯しますが、AIが関与すると、これらの欠陥はより頻繁に発生し、より大きなコードベースで、伝統的なコードレビューの速度を超えるペースで発生します。これらは、セキュリティインシデントやアウトエージとして現れる可能性のある、すでに知られている欠陥です。

2026年が異なるものになるかどうかを決定するもの

セキュリティの観点から見ると、この傾向は無視できないものです。論理的欠陥、安全でないデフォルト、設定エラーは、単独では壊滅的な脆弱性には見えませんが、攻撃面を拡大します。エラーハンドリングのギャップや依存関係のミスは、障害が安全に劣化するのではなく、連鎖的に発生する可能性を高めます。

厳格な分離、最小限の特権実行、短期間の資格情報、暗号化は、何かが間違った場合の被害を制限できますが、開発ライフサイクルの早期に導入された欠陥を補うことはできません。セキュリティと信頼性は、インフラストラクチャーの問題だけでなく、ソフトウェアがどのように構築され、レビューされ、テストされるかによって直接影響を受けるものです。

この不均衡が続く限り、2026年もインターネットは壊れ続けるでしょう。これは、AIに反対するものではありません。AIはすでに存在し、消えることはありません。AIを避けるのではなく、AIに合わせてガードレールを調整するチームが最もよくなるでしょう。

そのためには、レビューとQAチームに高い出力をもたらすためのリソースを確保し、開発ループの早期にテストと検証を配置し、AI生成の問題に深い検討を必要とするものを明示し、AI支援コードをデフォルトで信頼できる出力ではなく、分散した入力として扱う必要があります。

教訓は簡単です。責任を自動化で解決することはできません。AIがより多くのコードを書くにつれて、チームはコードをより多くレビューする時間、ツール、人員が必要になります。AIの次のイノベーションの段階は、コードがどれだけ速く生成されるかではなく、どれだけ自信を持って出荷できるかによって定義されるでしょう。

レビューがボトルネックになっている

AIはコード生成能力を劇的に増加させました。しかし、レビュー能力は自動的に増加しません。このギャップがリスクを生み出します。AIの次の採用段階は、コードがどれだけ速く生成されるかではなく、チームがコードをどれだけ自信を持って出荷できるかによって定義されるでしょう。

そのためには：

• レビューとQAを高い出力に合わせてリソースを確保することです。
• 開発ループの早期に検証を配置することです。
• プルリクエストにシグナルを増やすことです。
• AI支援コードを軽い監視ではなく、深い検討に値するものとして扱うことです。

インターネットは壊れ続ける必要はありません。AIは根本的な問題ではありません。レビューされていないAI生成コードが問題です。AIが生産ソフトウェアの増加する割合を書くのであれば、出荷前に同じくらい厳格なものがレビューする必要があります。

その変化が、AIコードレビューがオプションのツールではなく、基盤となるインフラストラクチャーになる理由です。CodeRabbitのようなプラットフォームは、コンテキストを認識したAIレビューを直接Gitワークフローに組み込み、チームが論理的エラー、セキュリティギャップ、エッジケースをインシデントになる前に捕捉できるようにします。

コード生成がスケールする場合、レビューもスケールする必要があります。

そうでない場合、2026年は2025年と同じように見えます。ただし、スピードは速くなります。