AI投資で良いリターンを得る

先週、O'Reillyは2026年最初のInfrastructure & Opsスーパーストリーム「AI時代のプラットフォームエンジニアリング」を開催しました。スピーカーたちは、独自のインフラ要件、予測不能なコスト、新たなセキュリティ上の懸念を持つAIワークロードをサポートするためのさまざまなトピックを探求しました。Google CloudのAbdel Sghiouarは、AIのための優れたプラットフォームの姿を聴衆に示しました。Cockroach LabsのJordan Lewisは、企業AIプラットフォームを展開する際の教訓を共有しました。SyntassoのDaniel Bryantは、優れたプラットフォームを構築するための3層モデルを概説しました。テクノロジーリーダーのSarah Wellsは、ガバナンスの重要性とそれをより管理しやすくする方法について議論しました。ThoughtworksのBen O'Mahonyは、評価を可観測性の一部にすべき理由を説明しました。ハイライトはこちらでご覧いただけます。

イベントは、SamとDORAチームを率いるNathen Harveyとの間の炉辺談話で締めくくられました。DORAは10年以上にわたってソフトウェアデリバリーのパフォーマンスを追跡しており、多くのテクノロジートレンドを見てきました。彼らの中心的な問いは常に同じでした：チームはどれだけ迅速かつ安全に変更を本番アプリケーションに展開できるか？

AIはその問いを変えていませんが、答えをより難しくしています。DORAは最近、「AI支援ソフトウェア開発のROI」レポートを公開し、AIが現在どのようにチームに貢献しているか、そしてそれが組織の収益にどの程度寄与しているかを示しています。Nathenはその発見を出発点として、AIがどのようにプラットフォームエンジニアリングとソフトウェア開発全体を変えているかを掘り下げました。

生産性のギャップ

Samはまず、DORAの2025年のデータから最も注目すべき発見の一つを指摘しました：組織は実際に本番システムにリリースされるコードで約10%の改善を見ました。開発者はより生産的になったと感じたかもしれませんが、それが自動的に本番環境に反映されるわけではありません。DORAのデータは、スループットの向上と同時に不安定性の増加を示しています。つまり、チームはより多くをリリースしていますが、変更をロールバックしたり修正を実装したりする頻度も高くなっています。個人レベルでの利益は実際にあり（10%はかなり良い数字です）が、これらの利益は「見出しにあるような劇的な改善」ではありません。

AIは良いプロセスを増幅する（悪いプロセスも同様に）

Nathenは、AIは増幅器であり鏡であり、良い面も悪い面も等しく反映すると説明しました。変更のリリースがすでに容易なチームでは、AIは物事をうまく機能させ続ける傾向があります。変更を本番環境に導入するのが困難なチームでは、AIはさらに多くの変更を生成し、既存の摩擦をより一層顕著にします。しかし、この結果に対する彼の見解は慎重に楽観的です：「痛みがより顕著になれば、私たちはその痛みに対処するための投資をするかもしれません。」問題は、投資が実際に行われなければならないことです。Nathenは、パフォーマンスの低い組織では、AIツールはプロセスを修正するための招待ではなく、期待のリセットとしてもたらされることが多いと指摘しました：新しいツールです。今、私たちはあなたにもっと期待します。この問題に対処するには、「AIは人々をより生産的にするのか？」という問いを再定義する必要があります。本当に問うべきは、「どのような条件でAIが生産性を向上させるのか、そしてその条件を作り出す責任は誰にあるのか？」です。そしてそれは組織にあり、テクノロジーではありません。

検証はチェックボックスではない

生成AIにおける大きな課題は信頼です。DORA調査回答者の約30%はAI出力をほとんどまたはまったく信頼していません。約46%は「ある程度」信頼しています（Nathenもその一人です）。生成AIの進歩にもかかわらず、これらのツールは依然として間違いを犯します。もしコード生成能力を拡大しただけで、検証能力を拡大することをしなければ、状況は悪化するだけで改善しません。

Nathenはこれを「検証税」と呼び、AIの生産性への影響を正直に評価する際には常に考慮されるべきだと述べました。パイプラインの適応も同様に考慮されるべきです：現在押し通そうとしている変更の量を考えると、配信パイプラインは目的に適しているでしょうか？これらのコストは、10倍の開発者生産性という見出しには現れません。それらは3ヶ月後のインシデントレポートに現れます。

DORAは最近、AI支援ソフトウェア開発のためのROIフレームワークと計算ツールを公開しました。Nathenは、普遍的な数値を提供することはできず、計算ツールもそのようなふりはしないと明確に述べました。それが行うのは、チームが学習への投資、検証のオーバーヘッド、必要なパイプラインの変更など、実際のコストをモデル化する方法を提供することです。

コンテキストスイッチとバーンアウト

生産性が上昇するにつれて、AI誘発性のバーンアウトが深刻な懸念事項になりつつあります（Steve Yeggeはこれを「AI吸血鬼」と呼んでいます）。DORAの2025年のデータは、AIの採用がバーンアウトと強く関連しているわけではないことを示しましたが、注意点として、DORA調査回答者の約64%がエージェンティックワークフローで働いたことがないと答えています。これらの発見は2026年に大きく変わる可能性があります。

Nathenは、エージェントが標準になるにつれてエスカレートすると予想されるバーンアウトの一因として、コンテキストスイッチを強調しました。彼が指摘したように、ソフトウェア開発者はフローを維持する必要がある深い作業のために保護された集中時間を求めて何年も議論してきました。エージェンティックワークフローは今、同じ開発者に一度に十数ものエージェントを自発的に実行させ、1時間に何度もコンテキストスイッチを強いることを促進しています。彼は冗談めかして、「自分たちはかなり優れたマルチタスク能力者であると感じているが、実際には誰もそうではないという研究はたくさんあります。」結果は近づいており、私たちはそれを自分自身で引き起こしています。

認知負債の問題

Sam Newmanは関連する「認知負債」の概念、特にMargaret-Anne Storeyの議論を取り上げました（「生成・エージェンティックAIが技術負債から認知負債へ関心を移す方法」および「技術負債から認知・意図負債へ：AI時代のソフトウェア健全性の再考」を参照）。Storeyは彼女のブログ投稿で問題を次のように説明しています：

速く進むことから生じる負債は開発者の脳内に存在し、彼らの生活経験や「速く進む」能力、変更を加える能力に影響を与えます。AIエージェントが理解しやすいコードを生成したとしても、関係する人間は単に全体像を見失い、プログラムが何をするべきか、意図がどのように実装されたか、変更する方法を理解していないかもしれません。

そしてSamが指摘したように、これはチームや組織全体に蓄積されます。開発者が互いにではなくAIと並行して作業するようになると、人々が一緒にソフトウェアを構築することから生まれる共有理解を失います。Kent Beckはかつて「ソフトウェア設計は人間関係の練習である」と言いました。エージェンティックワークフローは、私たちがようやく見え始めた方法でこれに圧力をかけています。

Nathenは、認知負債が最も懸念する点であり、労働者とアーキテクチャの両方がそれによって苦しむだろうと同意しました。8ヶ月前に下したアーキテクチャ上の決定の影響を理解するには何年もの運用が必要であり、AIはその点を全く助けません。

今すぐプラットフォームに投資せよ

AI支援チームの一部をハイパフォーマーにしている要因を考慮して、Nathenは次のように説明しました：「重要なのはAIを使っているかどうかではなく、どのように使っているかです。」この観察から、DORAはAI導入と組み合わせた場合に優れた結果をもたらす7つのケイパビリティを開発しました。Nathenはリストを簡単に説明し、最後に高品質の内部プラットフォームに言及しました。そして彼は、ソフトウェアエンジニアリングへの投資について、彼の言葉を借りれば「少しワイルドな」主張をしました：

あなたの組織のすべてのプロダクトエンジニア、つまり現在機能の構築に集中しているすべてのエンジニアは、おそらく機能構築をやめてプラットフォームに集中すべきです。

彼の主張は、AIが組織のほぼ誰でも何かを構築できるようにする環境では、プラットフォームはより重要であり、より重要でなくなるわけではないということです。顧客やビジネス問題に最も近い人々が、今や動作するソフトウェアを生成できます。しかし、彼らができないのは、そのソフトウェアが耐久性、安全性、プロダクション対応であることを保証することです。

Nathenは、今日のソフトウェアエンジニアリング投資の最良のレバレッジは、これらのガードレールを提供するプラットフォームを構築し、プロダクション対応の複雑さをインフラに押し下げ、その上に構築する誰もが無料で安全ネットを得られるようにすることかもしれないと示唆しました。彼は、すべてのプロダクトエンジニアをプラットフォーム作業に移すことはやり過ぎかもしれないと認めました。しかし、進むべき方向性は現実的です。プラットフォームはまた、Newmanが指摘したように、AIがより非決定的にしたプロセスに決定論を取り戻す場所でもあります。

これはO'Reillyでよく耳にすることです。構築できる人の拡大は、深いエンジニアリング専門知識の必要性を減らしません。それはその専門知識が最も価値を持つ場所を変え、プラットフォームはその良い答えです。

DORAの研究が教えてくれること

うまくいっているチームは実験を実行し、そこから学び、その教訓を広めています。Nathenが提案する尺度は、消費したトークンの数ではなく、実行した実験の数と、学んだことをどれだけ効果的に分配しているかです。

ツールは十分に速く進化しているため、特定のツールに関して固定されたポリシーを固守する組織は行き詰まります。必要なのは学習を続ける能力であり、それは学習を可視化し、伝達可能にする文化とプロセスを構築することを意味します。

DORAのすべての研究はdora.devで無料で入手可能であり、2025年の年次報告書とROIフレームワークも含まれます。DORAコミュニティは、実践者がこれらの質問に一緒に取り組むためのスペースを提供します。あなたがチームとこれらをナビゲートしようとしているなら、そこで時間を過ごすことを検討してもよいでしょう。

NathenとSamの会話をさらに深く掘り下げたい場合や他のセッションを探求したい場合は、O'Reilly学習プラットフォームでInfrastructure & Opsスーパーストリーム全体を視聴できます。次のイベントは9月9日で、エージェンティック可観測性を扱います。こちらから無料で登録し、O'Reillyの他のすべての無料ライブイベントもチェックしてください。