6月25日、diginomica.comが「AI now touches three-quarters of enterprise code – New Relic's Ashan Willy on agent debt and the re-defining of observability」と題した記事を公開した。この記事では、AIが企業コードの大半に関与する時代において、オブザーバビリティの役割がどう再定義されつつあるかについて詳しく紹介されている。

AIが「企業コードの75%に関与」という現実

New Relicが調査会社Hanover Researchに委託し、米国のテクノロジーリーダー200人を対象に実施した2026 State of AI Coding Reportによれば、67%のリーダーが「週次コードの51〜75%をAIが生成している」と回答した。New Relic自身のデータも裏付けとして挙げられており、2025年11月にGitHubのコミット数がベースラインを3標準偏差上回る急増を記録している。CopilotやClaude、Cursorの普及が直接の要因だ。

New RelicのCEOであるAshan Willyは、この数字を次のように読んでいる。

「75%のコードが、とは言わない。ただ、全体として書かれるコードの75%はAIが関与している。これはかなり大きな数字だ。」

問題はその先にある。AIが書いたコードが本番環境で壊れたとき、オンコールに呼ばれるエンジニアはそのコードを一行も書いていない、というのが統計的な実態だ。「コードを読む」ことがシステムを理解する主要な手段として機能しなくなっている。

「エージェント負債」──10倍生産性の主張に待った

業界で喧伝される生産性向上の数字について、WillyはCEOとして珍しく公の場で異議を唱えている。AnthropicはエンジニアのAI利用率80%・生産性約10倍を主張しているが、Willyの顧客データはそれを支持しない。

「私が話す人のほとんどは『今は1.3倍くらい』と言う。30%増えているのは確かだが、同時に大量のスロップや負債も生み出している。エージェント負債を積み上げているんだ。」

「スロップ（slop）」とはLLMが生成する低品質・粗雑なアウトプットを指す業界用語で、コードの文脈では動作するが保守性や可読性に著しく欠ける生成物を指すことが多い。

エージェント負債（agent debt）とは、New RelicのCPOであるBrian Emersonが定義した概念で、「速く出荷しようとする中で、ガバナンスが追いつかなければ運用コストが雪だるま式に積み上がる構造的問題」を指す。Emersonは同週のプレスリリースでより直截的に述べている。

「AIコーディングアシスタントが約束する生産性向上は、ボトルネックを開発者からSREに移し替えるだけなら幻想に過ぎない。」

コスト面でも具体的な数字が出ている。Willyによれば、本番障害1件あたりのコストは過去1年で約2倍、100万ドルから200万ドルに上昇している。

大手金融企業での実例──テレメトリを「垂れ流す」と何が起きるか

Willyは大手金融顧客でAnthropicのClaudeを広く展開した際の失敗例を具体的に語っている。

まず、AI生成コードを自分で検証しようとしたエンジニアたちが、New Relic AIのMCPサーバーから大量のオブザーバビリティデータをIDE内に直接引き込み始めた。

「大量のデータを引っ張ってきて、そのデータをどう扱えばいいか理解できず、独自の結論を出した。その結論が間違っていることもあり、コードに戻したときに壊滅的な事態になった。全員がそのデータの専門家ではないから。」

次に、コスト問題。エンジニアがあらゆるデータをモデルのコンテキストに詰め込もうとし、トークンコストが急騰した。

Willyの結論は明快だ。「我々が提供したいのはデータではなく、インサイトだ。解決に素早く到達できるよう。」テレメトリを無加工でAIアシスタントに食わせても、事態を悪化させる可能性がある、という教訓はベンダーを問わず適用される。

この考え方を実装したのが、6月23日にGAとなったオープンソースツール**Preflight**だ。開発者のローカルマシンに約5分でデプロイでき、サブエージェントの挙動、モデル使用状況、トークンコスト、コンフリクトを監視してNew Relicプラットフォームに送信する。

チームの縮小と「マイクロチーム」時代

組織構造への影響についても、Willyは具体的な観測を示している。

「話すCTOの誰もが聞いてくる──従来の『2ピザボックス』チーム（8〜16人規模）から、どうすれば『1ピザ』あるいは『半ピザ』チームに移行できるか、と。今はチームが4人規模になっている。マイクロサービスのように、マイクロチームがサービスを構築している。だからシステム全体を理解する人間の重要性が増す。」

さらに、プロダクトマネージャーが要件定義書を書くのではなくAIでプロトタイプを作り、場合によっては自らファーストカスタマー向けコードを出荷しているというケースも複数のCEO・CTOから聞いているという。

オブザーバビリティの次の役割

競合にあたるHoneycombの共同創業者兼CTOであるCharity Majorsも、6月17日に刊行したObservability Engineeringの第2版で同じ主張を展開している。

「エージェントがdiffの大半を生成するなら、全行を読んで検証することはできない。根拠は本番テレメトリから得るしかない。」

ベンダーとして競合する立場の2社が、アーキテクチャも異なりながら同じ結論に至っていることは、この議論に一定の重みを与えている。

この流れを踏まえてWillyが見据える次のステップは、「コード→本番→ビジネスKPI」というループの完全クローズだ。AIが生成したコードの品質は、もはやコードレビューの段階では担保しきれない。品質の最終的な根拠は本番環境の挙動に求めるほかなく、それはシステム指標にとどまらずビジネス指標とも接続されなければならない。ショッピングカートのコンバージョン低下がシステム障害によるものかマーチャンダイジングの問題かを区別できるオブザーバビリティ──「ビジネスパフォーマンスとシステムパフォーマンスを結びつけることが、本来のオブザーバビリティの姿であるべきだ」とWillyは述べる。

詳細はAI now touches three-quarters of enterprise code – New Relic's Ashan Willy on agent debt and the re-defining of observabilityを参照していただきたい。