AIはコードを書いていますが、インフラストラクチャは追いついていますか？

私たちは、ソフトウェアエンジニアリング史上最も奇妙な逆転の一つを経験しています。数十年間、目標は決定性だった。つまり、同じように動作するシステムを構築することです。現在、確率的なAIエージェントをその基盤の上に重ねて、コードを驚くほどのスケールと速度で生成しています。而且、ほとんどのインフラストラクチャはこれに対応していません。

私はDevOpsツール、共同研究、エンジニアチームのパフォーマンス向上を支援してきました。現在、AI駆動開発で見ているのは、単なる進化以上のものです。現行のワークフローのすべての欠陥を露呈しています。

問題はすでにここにあります

2025年のGitClearの研究によると、約7%のコミットにはAI生成コードが含まれています。以前の分析では、153百万行の変更コードを調査し、「コードの変化」(2週間以内に書き換えられたり削除されたコード)が2024年までにAI以前の基準と比較して2倍になったことが明らかになりました。

セキュリティ上の影響も同様に厳しいです。最近の分析では、100以上の大規模言語モデルを使用した80のカーディングタスクを調査し、AI生成コードが45%のケースでセキュリティ脆弱性を導入することがわかりました。実世界での影響は、5つのセキュリティ侵害のうち1つがAI生成コードによって引き起こされることをCISOが報告しています。

スピードの向上は実際ですが、安定性のコストも実際です。

増幅効果

私が学んだことの一つは、AIはすべてを増幅するということです。良い習慣がある場合、AIはそれをより良く、より速くします。プロセスが混乱している場合、AIはその混乱を悪化させます。これは、DORAの毎年のDevOpsレポートで年々現れるパターンと同じです。変数が少ないと、結果が良くなります。成功したチームは、オペレーティングシステム、プログラミング言語、行為のやり方を標準化しています。複雑さを意図的に減らしています。

AIエージェントも同じパターンに従います。彼らに一貫した環境を与えると、Pythonがすべての開発者のマシンで同じバージョンである場合、依存関係がロックされ追跡されている場合、彼らは優れています。17の異なる構成、各々に微妙な違いがある場合、彼らは環境の特性を理解するのにトークンを費やし、実際の問題を解決するのではなく、環境の特性を理解するのに時間を費やします。

決定性のパラドックス

これにより、面白い緊張が生じます。数年間、コンピューターサイエンスは決定性を究極の目標として追求してきました。現在、確率的なワークロード、AIモデルを、決定的なシステムの上に重ねています。これらのモデルは、同じ出力を2回保証することはできません。

私の答えは、可能な限りスタックを決定的に保つことです。インフラストラクチャの80%を決定的なレベルに保つことができると、AIエージェントは管理する変数が少なくなります。「なぜこの依存関係がインストールされなかったのか？」や「このビルドコマンドをもう一度試してみよう」ということについて考える時間を費やしません。彼らはあなたが彼らに依頼している実際の作業に集中しています。

考えてみてください。エージェントが何かをコンパイルしようとしても、ネイティブバインディングがImageMagickがインストールされていないために失敗する場合、それはトークンに高価な迂回路です。環境がすでに必要なすべて(コンパイラ、ライブラリ、依存関係ツリーの全て)を含んでいると、エージェントはただ動作します。デバッグは不要です。試行錯誤は不要です。進歩のみです。

仕様と検証は重要です

明らかになるのは、AI駆動開発が私たちに2つの歴史的に軽視されてきたスキルについて、より深く考えることを強いていることです。つまり、仕様と検証です。実際に何を構築しているかを明確にし、実際にそれを得たかどうかを検証する方法が必要です。

私は興味深いことに気づきました。製品管理または製品エンジニアリングの背景を持つ人は、現在AIエージェントで成功することが多いです。彼らはすでに要件、成功基準、トレードオフについて考えることを学んできました。彼らは「なぜあなたはその選択をしたのか？」と尋ね、理由に基づいて調整することに慣れています。

検証、つまり、実際に正しいかどうかを知ることは、常にソフトウェアエンジニアリングで最も難しい問題でした。QAは数十年間、軽視されてきましたが、それは最も難しい部分です。ユーザーの実際のニーズを解決するかどうかを判断することです。AIはこれを解決しません。むしろ、確率的な出力を決定的な要件に対して検証する必要があるため、より重要になります。

信頼するが、検証する（そしてコントロールする）

私が受け入れるようになった考えは、AIによって生成されたコードは、別の方法で証明されるまで、敵対的であると仮定するべきであるということです。AIが悪意を持っているわけではありません。ただし、すべての行を監査することはできないからです。エージェントが1日あたり数千行のコードを生成している場合に、開発時にすべてをゲートすることはできません。

これは、コントロールポイントをシフトすることを意味します。開発時にすべてをゲートすることができない場合、実行時に強力なコントロールが必要です。オペレーター、SRE、プラットフォームチーム、プロダクションを担当する誰でも、実行中のものを完全に把握し、依存関係を追跡し、すべてのアーティファクトについて明確な出典を必要とします。

ここで、再現性が重要になります。ローカルでテストしたアーティファクトが、実行中のものと同じであることを数学的に証明できる場合、賢い決定を下し始めることができます。もしかしたら、ローカルで実行したユニットテストをCIで再実行する必要がないかもしれません。もしかしたら、テストカバレッジをコードの変更にマップし、無関係なテストスイートをスキップできるかもしれません。

次に何が来ますか

私たちは、変化点にあります。すでに良い習慣を持っていたチームは、AIで大きな生産性の向上を実現しています。苦労していたチームは、今も苦労しています。

AI駆動開発を支えるインフラストラクチャは、再現性を基盤として構築する必要があります。スキャニングツールや監査で後から追加されるのではなく、開発者が最初から働き始めるように構築する必要があります。開発環境がMacとLinuxで同じである場合、すべての依存関係が追跡されロックされている場合、アーティファクトの完全な出典がある場合、AIエージェントは混沌を生み出すのではなく、倍増効果になります。

AIの時代に成功しようとするチームにとって、私の大きなアドバイスは次のとおりです。

• 無慈悲的に標準化します。変数が少ないと、パフォーマンスが高くなります。テクノロジースタックをロックダウンし、すべてのプラットフォームで一貫した環境を適用し、AIが拡大する前に構成のドリフトを排除します。Pythonのバージョンの不一致が現在問題を引き起こす場合、AIが大規模にコードを生成する場合、10倍の問題を引き起こすことになります。

• ワークフローに検証を組み込みます。人間がコードをレビューするよりもAIがコードを生成するのが速い場合、手動のコードレビューだけに頼ることはできません。コードが実行されるだけでなく、実際の要件を解決するかどうかを検証する自動テストを実装します。強力なゲートを実行時に持つCI/CDパイプラインをセーフティネットとして作成します。

• インフラストラクチャとしての再現性に投資します。環境の一貫性を第一級のインフラストラクチャの懸念事項として扱います。ローカル環境、CI環境、プロダクション環境がすべて同じであることを数学的に証明できる場合、すべての「私のマシンでは動作する」問題のクラスを排除します。この決定的な基盤が、確率的なAIワークロードを安全に重ねることを可能にします。

AIがほとんどのコードを書くかどうかという問題ではありません。多くのチームの場合、AIはすでにそれをしています。問題は、インフラストラクチャが追いつくかどうかです。