アジャイル・ソフトウェア・デリバリーにおいてAIが失敗する理由：エンジニアリングマネージャーのための事例と解決策
多くのCTOは、アジャイルなソフトウェアデリバリーにおけるAI活用に大きな期待を寄せています。より速く、より自動化され、より多くのアウトプット。これは短期的にはたいていその通りです。それでもなお、多くのチームやCTOは、この局所的な加速がどのように顧客価値やビジネス上の付加価値へとつながるのかを示すことに失敗しています。
問題は、企業がAI熱狂の中で間違ったものを最適化してしまうことです。顧客価値を高めるよりもトークン数を増やし、信頼を高めるよりもコード量を増やし、より良いデリバリーシステムを作るよりもエージェントを増やしてしまうのです。
この記事は、意図的に以下の2つの記事の内容を補完するように構成されています：
ここでは、その間の橋渡しを扱います。なぜ、アジャイルなソフトウェアデリバリーにおけるAIは実務でうまくいかないのか？ 具体例を通して、マネージャーが何をすべきか、そしてどの解決策が本当に有効なのかを示します。
TL;DR
- アジャイル・ソフトウェア・デリバリーにおけるAIの失敗は、ツールの活用不足ではなく、多くの場合、誤った管理ロジックに起因します。
- 「トークンマキシング（Tokenmaxxing）」はその最も顕著な兆候です。チームがフロー、品質、顧客価値ではなく、AIの消費量に対して最適化を行ってしまっています。
- 最も重要な対策は、明確な責任の所在、堅牢なエンジニアリング・ハーネス（Engineering Harness）、迅速な顧客フィードバックループ、そして組織的な学習です。
なぜアジャイル・ソフトウェア・デリバリーにおけるAIは、これほどまでに誤った目標を最適化してしまうのか
AIが生産性向上のレバーとして導入されると、多くの企業で非常に予測可能なことが起こります。測定できるものが目標になってしまうのです。それは新たなトレンドであるTokenmaxxingにも表れています。 Pragmatic EngineerによるTokenmaxxingのトレンドについて
それは、企業やチームが高いトークン消費を、暗黙的または明示的に、AI活用がうまくいっている証拠として扱うことを指します。これは経営的にも組織的にも危険です。なぜなら、トークンはせいぜい入力の指標であって、価値の指標ではないからです。
このパターンは昔からあります。かつては「Lines of Code」が指標として過大評価され、今ではトークン消費やAI利用ダッシュボードがその役割を担っています。どちらの場合にも、Goodhart’s Law の一種が当てはまります。指標が目標になった瞬間、その指標としての価値は失われるのです。 Martin Fowlerによる、Lines of Codeを指標とすることの問題, WikipediaのGoodhart’s Law
AIをアジャイルなソフトウェアデリバリーに活用するうえでは、短期的な活動量を最大化すると、AIの活動量が増えることがよくあります。しかし、それだけでアジャイルなソフトウェアデリバリーが改善するわけではありません。
これに関する調査結果は冷静なものです。個人レベルでは明らかな生産性向上の効果が見られるものの、チームや組織レベルでは、それほど確実な改善は見られません。詳細についてはこちらにまとめています： 2026年時点の、アジャイルなソフトウェア開発におけるAIに関する研究状況
AIがアジャイルなソフトウェアデリバリーで失敗する、典型的な4つの例
AIがアジャイルなソフトウェアデリバリーで失敗する方法 | 例1
1. コードは増えるが、理解は減る
最初の失敗は単純です。チームが生成する変更の量は大幅に増えますが、その内容を真に理解している割合は低下していきます。
マネージャーの目には、当初は順調に見えることが多いでしょう：
- プルリクエストの増加
- 初期実装のスピードアップ
- 「完了」したストーリーの増加
しかし、そのツケは後で回ってきます：
- レビューが形骸化する
- オーナーシップが希薄になる
- インシデント分析に時間がかかるようになる
- どこが壊れるか誰も確信が持てなくなるため、リファクタリングが避けられるようになる
Kent Beckは記事「Trust Factory」の中で、テスト、レビュー、リファクタリング、段階的リリースといった実践は、何よりも信頼を築くものだと述べています。AIが、チームが理解し、検証し、責任を持てる速度を超えて出力を生み出すと、この信頼がまさに失われてしまいます。 Kent BeckのTrust Factoryにおけるエンジニアリングの信頼について
Addy Osmaniはこれと似たリスクをComprehension Debtとして説明しています。チームが、もはや主体的に理解できないコードをどんどん出荷するようになると、変更のたびにシステムと理解のあいだの距離が広がっていきます。 Addy OsmaniによるComprehension Debt
文書化された例
WIREDの2025年夏のレポートでは、Notionが社内でAIコーディングをどのように活用しているかが紹介されています。特に示唆に富むのは、その速度だけではなく、仕事のあり方が変わっている点です。Notionの共同創業者は、コーディングアプリの利用を、比喩的に言えば多数のインターンを同時に管理するようなものだと説明しています。つまり、人間が外に追いやられるのではなく、出力をより強く確認し、位置づけ、修正する側へと回るのです。まさにここがポイントです。生成されるコードが、チーム全体の共通理解よりも速く増えると、仕事は実装から、監視、レビュー、修復へと移っていきます。 WIREDのNotionとAIコーディングに関するレポート
これは、実務から得られるより広い知見とも合致します。2026年に要約されたSonarの調査によると、ほとんどの開発者はAI生成コードの機能的正しさを完全には信頼しておらず、かなりの割合が、そのレビューを人間が書いた変更を確認するより手間がかかると感じています。問題は単なる品質の悪さではなく、追加の検証コストと理解コストなのです。 ITProによる、Verification Debtに関するSonar調査の報道
AIがアジャイルなソフトウェアデリバリーで失敗する方法 | 例2
2. 出力は増えるが、問題が違う
2つ目の失敗は、経営層にとってさらに高くつく。AI は生産のコストを下げるが、誤りのコストを自動的に下げるわけではない。
チームが要件を雑に切り分け、十分に検証せず、あるいは社内だけで調整していると、AIはただ間違った仕事を加速させるだけです。Kelsey HightowerはLinkedInの投稿でこれを非常に率直に言い表しています。「Productivity doesn’t matter if you’re working on the wrong thing.」 Kelsey Hightowerによる誤った生産性に関するLinkedIn投稿
まさにこの方向で、Andrew Ngも2025年に広く引用された対談で論じています。AIはコーディングを大きく加速したが、その結果、本当のボトルネックが移るのだと。今や主な問題は実装ではなく、プロダクトの問いになっている：
そもそも何を作るべきなのか、そして実際のユーザーフィードバックからどれだけ速く学べるのか？
出典： Andrew Ngとのプロダクトマネジメントのボトルネックに関するBusiness Insiderの対談
だからこそ、アジャイルなソフトウェアデリバリーにおけるAIは、真の顧客接点があってこそ成功できるのです。プロンプトからコードまでの道のりが速くなっても、コードから顧客フィードバックまでの道のりが遅いままなら、増えるのはアウトプットと変更量だけです。
アジャイルなプロダクト開発の研究でも、別のレベルでまさにこのパターンが示されています。Agile Epicsに関する業界ケーススタディでは、研究者たちが、定義の甘い要件が手戻り、遅延、品質問題、不要なコストを招くと述べています。AIはこうしたボトルネックを魔法のように解消することはできません。せいぜい、それらをより速く具現化するだけです。 Agile Epicsと要件品質に関するArXiv研究
したがって、盲目的なAI利用に対する決定的な対極は、AIを減らすことではなく、より良いアジャイルデリバリーです。そのための横断的なレバーを探しているなら、ここにあります： AI 支援アジャイルソフトウェア開発の未来へのガイド
AIがアジャイルなソフトウェアデリバリーで失敗する理由 | 例3
3. エージェントは増えるが、責任は減る
AI に関する多くの未来図は、アジャイル Software Delivery において魅力的に見える。なぜなら、責任を巧みに見えなくしてしまうからだ。1つの Agent がユーザーフィードバックを分析し、次の Agent が Requirements を書き、次の Agent が実装し、次がテストし、さらに次がデプロイする。
技術的には、これはかなり実現可能だ。だが組織的には、すぐに曖昧になる。
特にエージェント型ソフトウェア開発では、古くからあるマネジメントの問いを、より厳しく問わなければなりません。誰が決めるのか？ 誰が確認するのか？ 誰が結果責任を負うのか？ IBMは、AIの意思決定に関する読み応えのある概説の中で、この根本問題をこう表現しています。責任は人間に残る。とりわけ、システムが意思決定を準備したり加速したりする場合には。 IBMによるAIの意思決定における責任について
AI Agile Manifestoもここで正しい対比を示しています。人間の判断を伴わない機械知能の増加は進歩ではなく、誤った道です。 AI Agile Manifestoの原文
記録された事例
この問題は2025年、Replitをめぐる公開議論の中で特に明確になりました。記録されたAIコーディングエージェントの実験の最中、システムはコードフリーズを無視し、本番データベースを削除し、公開された報告によれば捏造データを生成し、その経緯を誤解を招く形で示しました。マネジメントとガバナンスにとって重要なのは、個々のエラーそのものよりも、そのエラーの構造です。システムは実際の影響を伴って動作した一方で、責任、承認、統制があまりに見えにくく、あまりに徹底されていませんでした。 AIエージェントをめぐるReplitの件に関するBusiness Insider報道
だからこそ、ツールの能力だけを語っていては不十分なのです。エージェントが要件を解釈し、変更を実施し、あるいは本番に近いアクションを引き起こすようになった瞬間から、責任は組織としてより明確かつ可視的でなければなりません。
AIがアジャイルなソフトウェアデリバリーで失敗する理由 | 例4
4. ローカルな生産性は増えるが、システムのエントロピーも増える
4つ目の失敗は、しばしば遅れてからしか見えてこない。個々の開発者やチームは極めて生産的に見える一方で、組織全体は重くなっていく。
これは、誰もがローカルでは AI で最適化する一方で、システム全体を強化する人がほとんどいないときに起こる:
- アーキテクチャ原則が一貫性なく適用される
- 同じ問題が並行して何度も解決される
- レビューとテストの仕組みが踏み越えられる
- Delivery パイプラインが渋滞のボトルネックになる
- インシデント対応の負荷と手戻りが増える
Birgitta BöckelerはInfoQでのHarness Engineeringに関する対談で、より高い自律性には常により高いリスクが伴い、適切なフィードフォワードとフィードバックの仕組みによって制限されなければならない理由を説明しています。 Birgitta BöckelerによるHarness Engineeringに関するInfoQポッドキャスト
それが単なる理論上のリスクではないことは、複数の公になった事例が示している。報道によれば、Amazonは2026年、重大なインシデントの連続を受けて内部のガードレールを強化し、その要因の一つとしてエージェント型、あるいはAIに近いシステムも挙げられた。そこから得られた教訓は示唆的だった。文書化された変更を増やし、承認を増やし、重要システムではより多くの「制御された摩擦」を入れる、というものだ。言い換えれば、局所的な加速がシステム全体を必ずしも改善するわけではない。場合によっては、弱点をより速く露呈させるだけだ。 Amazonの厳格化されたAIガードレールに関するBusiness Insiderの記事
AI支援の、いわゆるVibe Codingに見られる、同じエントロピーの第二の異なる形がある。Axiosは2026年、安全研究者の話として、公開アクセス可能な成果物が数十万件、その中に機微な企業データを含むものが数千件あると報じた。ここで主に失敗しているのは単一のプロンプトではなく、標準、アクセス権、デフォルト設定、セキュリティ理解、ガバナンスから成るシステム全体だ。 Vibe Codingと公開アクセス可能な成果物に関するAxiosの記事
要するに、AIが自律的であればあるほど、それが動く組織的・技術的な枠組みが重要になる。
短期的な生産性と Tokenmaxxing が、誤った AI 戦略である理由
一部の経営者は、AI の新たなレバレッジに対して単純な結論を下す。つまり、できるだけ早く、できるだけ多く AI 利用を強制すればいいのだ、と。
それはまさに間違ったマネジメント上の反応だ。
なぜか?
この文脈で「短期的生産性」がたいてい意味するのは、次のようなことだけだからです：
- より多く生成されたコード
- より多くのAIセッション
- より多いトークン消費
- より多くのローカルで解決されたタスク
しかし、これらすべては、AIがアジャイルなソフトウェアデリバリーにおいて実際に決定的な問いに比べれば、まだほとんど何も語っていません：
- 本当に適切な問題は解決されたのか？
- チームはこの変更を理解しているか？
- その変更は安全に展開できるか？
- 変更後にシステムはより良くなったのか、それともより脆弱になったのか？
- 組織はより速く学んでいるのか、それともただ慌ただしくなっているだけなのか？
だからこそ、Tokenmaxxingは非常に良い警告信号なのだ。企業がAIの利用を自己目的として扱うと何が起きるかを示している。そうなると従業員は、たとえコスト、エントロピー、手探り状態が増えても、目に見えて報われるものを正確に最大化してしまう。 Pragmatic EngineerによるTokenmaxxingトレンドについて
Jez Humbleは、現在のAIブームよりずっと前に、このマネジメント上の問題をすでに明確に説明していた。マネージャーが生産性だけを直接重視すると、長期的な改善はしばしばまったく行われない。AIを用いたアジャイルなソフトウェアデリバリーでは、この問題はさらに深刻になる。 Jez Humbleによる、生産性重視と長期的改善の未実施について
その代わりに何が有効か: アジャイルなソフトウェアデリバリーにおけるAIのための4つの堅牢な解決策
1. 責任を明確に人間に残す
AIは加速し、提案し、負担を軽減してよいものです。しかし、意思決定と品質の責任が曖昧になるための言い訳になってはいけません。
実際には、これは次のような意味です：
- アーキテクチャ、セキュリティ、そしてプロダクトに関わる意思決定について明確なオーナーを置くこと
- AIの活動だけを報酬する成果指標を設けないこと
- AI生成の変更に対する明確なレビューと承認のルール
2. 単にAIツールを導入するのではなく、エンジニアリング・ハーネスを構築する
多くのチームは、まずモデルに投資し、最後にそのモデルが安全に動作できる条件に投資します。まさにそれを逆にしなければなりません。
アジャイルなソフトウェアデリバリーにおけるAI向けの堅牢なハーネスには、たとえば次のようなものが含まれます：
- よい仕様
- 小さく、検証可能な作業パッケージ
- 自動テスト
- 静的解析
- 管理されたサンドボックス
- 明確なアーキテクチャコンテキスト
- CI、デリバリー、そして本番環境からの迅速なフィードバック
この考えに興味があるなら、AIを用いた仕様駆動の作業についての有用な参考資料として、OpenSpecとGitHub Spec Kitもある: 仕様駆動の製品開発のためのOpenSpec, spec-driven開発のためのGitHub Spec Kit
3. 顧客フィードバックをコード生成より速くする
AIが持続的なデリバリーレバーになるのは、学習サイクルも同時に加速される場合だけです。そうでなければ、現実からますます速く外れていくだけです。
具体的には、これは次を意味します：
- より小さなリリース
- 顧客との本当のフィードバックループを伴う、より多くの実験
- 機能利用データの、より徹底した分析
- サポートとユーザーのシグナルをより速く評価すること
コーディング速度だけを上げて、フィードバック速度とその質を上げないなら、AIネイティブな組織を作ることにはならず、John Cutlerの言うところの、単により速い「Feature Factory」を作るだけだ。参照: 「Feature Factory」で働いている12の兆候
4. レトロスペクティブと学習サイクルを真剣に受け止める
AIがアジャイルなソフトウェアデリバリーで失敗するとき、その原因はたいていシステム的です。その場合、個々のプロンプトやツールだけを最適化してもあまり役に立ちません。
チームには、繰り返し現れるパターンを可視化し、体系的に解決するためのルーティンが必要だ:
- どこで理解が失われているのか？
- どこでレビューの滞留が増えているのか？
- どこでAIが利益よりも手戻りを生んでいるのか？
- どこで全体システムを犠牲にして局所的な速度を最適化しているのか？
まさにそのために、レトロスペクティブは今も重要です。スクラムの過去の儀式としてではなく、変化頻度の高い環境における組織学習のメカニズムとして。
結論：AIをアジャイルなソフトウェアデリバリーで失敗させる原因は、AI不足ではないことがほとんどです
実際の皮肉は、多くの組織がAIで失敗するのは慎重すぎるからではなく、視野が狭すぎる運営をしているからだということです。
彼らは短期的な生産性を、持続的な価値創出とデリバリーシステムの改善と取り違えている。彼らはToken消費を価値創出と取り違えている。彼らは自律的なコード生成を組織成熟度と取り違えている。
だからより良い指針となる問いは、もはや「どうすればチームにもっとAIを使わせられるか？」ではありません。
むしろ：
- どのような条件下で、AIは私たちのデリバリーを本当に改善するのか？
- 今まさにAIは、バリューチェーンのどこで新たなボトルネックを生み出しているのか?
- AIは、私たちが修正すべきシステム的欠陥をどこで露呈させているのか?
- 加速がエントロピーに転じないようにするために、どの組織能力を強化する必要があるのか？
そのための冷静なエビデンスをまず知りたいなら、こちらを読み進めてほしい: AIとアジャイルなソフトウェア開発に関する研究状況 .
マネジメントのレバーを直接探しているなら、こちらを読み進めてほしい: アジャイルソフトウェア開発におけるAIについての、CTOとエンジニアリングマネージャー向けガイド .
アジャイルなソフトウェアデリバリーにおけるAIのFAQ
なぜAIは私のチームにより多くの成果をもたらすのに、より良いデリバリーにはならないのか?
より多くの成果が自動的により良いデリバリーを意味するわけではないからだ。レビュー、テスト、フィードバックが追いつかなければ、何より複雑性が増す。
AI支援のソフトウェア開発におけるTokenmaxxingとは何か?
Tokenmaxxingとは、AIの利用やToken消費を目的そのものにすることを指す。それは活動量は測るが、価値は測らない。
AIの生産性を押し上げることばかりでなく、エンジニアリングマネージャーは何をすべきか?
責任、テスト、レビュー、フィードバックループを強化すべきだ。それがあって初めてAIは長期的に役に立つ。
AI支援が非常に多いチームでも、アジャイルな儀式はまだ必要なのか?
必要だが、焦点は変えるべきだ。ステータス確認を減らし、フィードバック、学習、継続的改善を増やす。
エンジニアリングマネージャーとして、ソフトウェア開発においてKIが本当に効果を上げているか、どう測ればよいですか？
Lead Time、レビュー工数、エラー率、そして顧客価値を測ってください。純粋なアウトプットだけでは不十分です。
なぜ私のチームはKIで速くなるのに、成果は良くならないのでしょうか？
それは、コードが増えたからといって自動的により良い成果が得られるわけではないからです。適切なレビュー、テスト、フィードバックがなければ、エントロピーが増すだけです。
ソフトウェア開発において、KIのために本当に追跡すべきKPIは何ですか？
リードタイム、欠陥率、手戻り、デプロイの安全性、そして顧客からのフィードバックまでの時間を追跡してください。トークン数だけでは、あまりにも情報が少なすぎます。
KIが生成したコードのせいで、チームの足が後で引っ張られないようにするにはどうすればいいですか？
変更は小さく保ち、きちんとテストし、明確なレビューを徹底してください。KIはスピードをもたらしてよいですが、理解の代わりにはなりません。
