AIは短時間で大量のコードを生成できますが、開発全体が同じ割合で速くなるとは限りません。限定された実装課題では大幅な時間短縮が確認された一方、既存の大規模なソフトウェアを変更する実験では、AIの利用によって所要時間が増えた例もあります。今回は、コード生成の速さが開発成果へ直結しない理由と、人とAIの仕事を組み直す具体的な方法、Superpowersが変えようとしている開発工程について解説します。
【関連記事】エンジニアリングリーダーに必要なのは「捨てる覚悟」？チームを守る決断力とは
AI開発はなぜ失敗するのか
AIを使うと、実装そのものは目に見えて速くなります。しかし、ソフトウェア開発には、仕様の確認、設計、既存機能との統合、レビュー、テスト、運用準備も含まれます。コードを書く時間だけを測ると大きな効果が見えても、完成した変更を安全に運用できる状態へ持っていくまでを測れば、異なる結果になることがあります。
相反する実験結果が示しているもの
GitHub Copilotの生産性を調べた実験では、Upworkを通じて採用した95人のプログラマーを無作為に2群へ分け、JavaScriptでHTTPサーバーを実装させました。Copilotを利用できたグループは、利用できなかったグループより課題を55.8％速く完了しています。AIが実装速度を高めたことを示す結果ですが、対象は要件と完成条件が限定された単一の課題です。既存システムへの統合、長期的な保守、運用設計まで含めた開発プロジェクト全体が55.8％短縮されたわけではありません。
METRが2025年に実施した比較実験では、異なる結果が出ました。対象は、大規模なオープンソースソフトウェアへ複数年にわたって貢献してきた16人の開発者です。参加者は、自分たちが使い慣れたリポジトリで246件のバグ修正、機能追加、リファクタリングに取り組みました。課題ごとにAIを利用できるかどうかを無作為に割り当てたところ、主にCursor ProとClaude 3.5／3.7 Sonnetを利用できた条件では、所要時間が19％増えました。こちらは、既存の仕様や暗黙の慣習、品質基準を理解しながら変更する実務に近い課題です。
この2つの結果を並べて、「AIは速い」「AIは遅い」と結論付けることはできません。GitHub Copilotの実験では、完成条件が明確な局所的な実装能力が問われました。METRの実験では、蓄積された文脈を読み取り、既存の設計と整合させる能力まで必要でした。仕様と完成条件が明確な作業ではAIの生成速度が生きやすく、既存システムの文脈や検証を含む仕事では、その速度がそのまま成果にはなりません。
METRも、2025年の結果をソフトウェア開発全体へ一般化していません。2026年の追跡調査では、元の参加者10人と新規参加者47人が、143のリポジトリにある800件を超える課題へ取り組みました。元の参加者では18％、新規参加者では4％の時間短縮という推定が出たものの、いずれも信頼区間が0をまたいでいます。AIを使わずに作業したくない開発者や、AIの効果が高そうな課題が調査対象から抜ける選択バイアスなども生じたため、METRは効果の大きさを信頼できる精度で測定できなかったと説明しています。AIの性能向上によって状況が改善した可能性はありますが、短縮率を確定できる段階ではありません。
作業者の負担は後工程へ移る
DORAは、2025年第3四半期にGoogleのソフトウェアエンジニアから得た1,110件の自由記述を分析しました。コード生成、情報探索、コードレビュー、テストなどで速度が上がったという回答がある一方、すべての用途で出力の検証やハルシネーションへの対応が負担として挙げられています。コードを書く時間が短くなった分、監査や検証へ時間が再配分される傾向や、AIが生成した大きな変更によってレビュー担当者の認知負荷が増えるという回答もありました。
AIは休まずにコードを生成できますが、レビュー担当者が変更の意図を理解し、仕様への適合を確認できる量には限界があります。生成量だけを増やせば、レビュー待ちや修正待ちが積み上がります。複数のエージェントを同時に動かした場合には、別々に作られた変更の競合や統合作業も増えます。実装が速く終わっても、後工程で待ち時間と手戻りが発生すれば、開発全体のリードタイムは短くなりません。
DORAは、AI利用の増加がソフトウェアデリバリーのスループット増加と不安定性増加の双方に関連したと説明しています。これは、AIが不安定性を直接引き起こしたと証明するものではありません。ただし、作成能力だけが高まり、確認能力が追い付かなければ、開発量と同時に管理すべきリスクも増えるという問題を示しています。短時間で動くプロトタイプを作ることと、既存システムへ統合し、例外処理や運用準備を終えた製品を作ることは分けて評価する必要があります。
コード生成量は生産性に直結しない
AI開発がうまくいかない原因は、次の4点に整理できます。
- コード生成量を生産性と誤認する：生成行数や実装件数が増えても、レビュー待ち、手戻り、障害が増えれば、開発全体は速くなりません。
- 曖昧な要件のまま先へ進む：AIは業務上の前提や完成条件が不足していても、もっともらしい解釈を選んで実装できます。その解釈が誤っていれば、動くコードでも要求を満たしません。
- 作成と検証を同じ判断へ依存する：同じAIが誤った仕様解釈に基づいてコードとテストを作れば、テストが通っても正しい成果とは限りません。
- AIの処理速度に管理能力が追い付かない：実装量が承認、レビュー、統合の処理能力を超えると、後工程が新しいボトルネックになります。
開発成果は、生成したコードの量ではなく、要求への適合、レビューに要した時間、手戻り、障害、運用可能性まで含めて評価する必要があります。AI開発の問題は、モデルのコード生成能力だけにあるのではありません。コードを書く工程だけを高速化し、要件確認、設計、レビュー、テスト、運用準備を従来のまま残したため、負担と待ち時間が後工程へ移っています。
人とAIの仕事をどう組み直すべきか
AIの導入後も、従来と同じ人数、同じ承認方法、同じ変更単位で開発を続ければ、速くなった実装工程と、それ以外の工程との間に差が生まれます。必要なのは、担当者の仕事をそのままAIへ置き換えることではなく、目的を定める仕事、実装する仕事、結果を検証する仕事を分け直すことです。
AIと担当者の分担
開発責任者や技術者が担うのは、何を実現するのかという目的、業務上の制約、優先順位、受け入れ条件、設計とリスクに関する判断、最終承認です。これらは、利用者や事業の事情を踏まえて決める必要があります。AIが複数の選択肢を提示することはできても、どの利害を優先し、どのリスクを受け入れるかという責任まで移すことはできません。
AIには、既存コードと関連資料の調査、選択肢と影響範囲の提示、限定された範囲の実装、テストの実行、差分と検証結果の収集を任せます。目的と完成条件を先に明文化し、AIが設計案を提示した段階で担当者が内容を確認します。承認された設計をレビュー可能な作業へ分割し、それぞれの変更について証拠を確認してから次へ進める形です。
この分担では、担当者がコードを一切読まなくてよいわけではありません。担当者の中心的な役割が、すべてのコードを手で入力することから、AIが正しい対象を変更しているか、結果が受け入れ条件を満たしているかを判断することへ移ります。 実装をAIへ任せる範囲が広いほど、目的と判定基準を明確にする必要があります。
変更量をレビュー可能な範囲に抑える
作業を小さく分ける目的は、進捗を細かく管理することだけではありません。1つの変更に含まれる目的を限定すれば、差分を理解しやすくなり、テスト結果と仕様の対応も確認しやすくなります。問題が起きたときには、原因を調べる範囲を狭められます。DORAも、小さな単位での変更はフィードバックを速め、問題の特定と修正を容易にすると説明し、AI導入に伴う不安定性への対策として挙げています。
複数のAIエージェントを利用するときも、同時作業数を増やすほど開発が速くなるとは限りません。5件の変更を並行して作れても、レビュー担当者が1件ずつしか確認できなければ、4件は待ち状態になります。さらに、複数の変更が同じコードへ触れれば、統合時の競合や再テストも必要です。進行中の作業量は、AIが生成できる量ではなく、チームがレビューして安全に統合できる量を基準に制御しなければなりません。
完了の判定も、コードを作ったAIの自己評価だけで閉じないことが重要です。受け入れ条件に対応したテスト、既存テスト、静的解析、ビルド結果、実際の差分、別のレビュー担当者による確認を組み合わせます。コードとテストを同じAIに作らせる場合でも、テストが要求を正しく表しているかは別に確認します。「実装しました」という報告ではなく、何を実行し、どの結果を確認したかを完成の証拠にします。
「注意力」ではなく「仕組み」で工程を守る
自然言語で「必ずレビューする」「テストに合格してからマージする」と指示するだけでは、見落としや工程の省略を完全には防げません。GitHubの保護ブランチでは、承認レビューや必須ステータスチェックをマージの条件に設定し、直接書き込める利用者、チーム、アプリも制限できます。必須チェックが失敗していれば、権限を持つ主体であってもマージできない構成にできます。
デプロイにも別の統制が必要です。GitHub Actionsの環境には必須レビュー担当者を設定でき、承認されるまでジョブを進めないようにできます。自己承認を禁止し、デプロイ可能なブランチを限定し、保護規則を通過するまで秘密情報へアクセスさせない設定も可能です。AIが実装とテストを高速に進めても、本番反映や機密情報へのアクセスは、別の権限と承認で管理できます。
CI、ブランチ保護、権限制御、承認ゲートは、担当者やAIが手順を覚えていることに依存せず、通過条件を技術的に定める仕組みです。自然言語の指示は行動を誘導し、技術的な制御は許可されない操作を止めます。両者は代替関係ではなく、役割が異なります。
Superpowersは何を変えようとしているのか
Superpowersは公式に、複数の組み合わせ可能なSkillと初期指示から成る「コーディングエージェント向けのソフトウェア開発方法論」と説明されています。AIへ新しいプログラミング知識を追加するものではありません。作者のJesse Vincentは、「自分が実践してきた開発手順を抽出して体系化し、エージェントを適切な流れへ誘導するために作った」と説明しています。
Superpowersは、AIが依頼を受けてすぐ実装を始める行動を抑え、目的と仕様の確認、設計の提示と承認、作業分割、失敗するテストを先に確認するTDD、レビュー、完了前の検証を順番に通そうとします。その真価はまったく新しい開発理論を作ったことではなく、AIが省略しやすい既知の工程を、エージェントが再利用できる開発手順として組み込んだことです。
Superpowersが扱う問題と方法は、次のように対応します。
- 曖昧な要件のまま実装する問題：設計を提示し、利用者の承認を得てから実装へ進みます。
- 大きな依頼を一度に処理する問題：作業をレビュー可能な単位へ分割します。
- 原因を確認せず修正する問題：エラーと再現条件、直近の変更、データの流れを調べ、原因仮説を検証してから修正します。
- 実装後に都合のよいテストを作る問題：失敗するテストを先に確認し、その後で実装します。
- AI自身の完了報告を信用する問題：テスト、ビルド、差分の結果を証拠として確認します。
Superpowersは、AIに何を任せるかという機能の一覧ではなく、AIをどの順序で働かせるかを定める方法論です。ただし、この流れだけで開発管理のすべてが完結するわけではありません。AIの行動を誘導する工程と、CIや権限制御によって操作を止める仕組みを組み合わせることで、初めて開発の速度と統制を両立しやすくなります。
SuperpowersでAI開発の課題は解決するのか
Superpowersは、AI開発で発生しやすい工程の省略を減らす方法として有力です。しかし、工程を定義することと、正しい製品を作れることは同じではありません。改善できる問題、解決できない問題、導入によって増えるコストを分けて評価する必要があります。
改善する問題と改善しない問題
Superpowersによって改善を期待できるのは、必要な工程が分かっているのに省略される問題です。要件を確認せずに実装を始める、変更範囲を広げすぎる、原因を調べずに修正案を試し続ける、実行結果を確かめずに完了と報告するといった行動には、明確な手順が有効です。体系的なデバッグ手順では、エラー、再現条件、直近の変更、コンポーネント間の証拠、データの流れを調べ、原因仮説を最小の変更で検証してから修正します。場当たり的な修正を抑え、レビュー可能な証拠を残しやすくなります。
工程を厳格にしても、要件そのものの誤り、業務知識の不足、受け入れ条件とテストの不備、誤った技術判断は解決できません。誤った要件を正確に実装することも、利用者の要求を表していないテストをすべて通すことも可能です。セキュリティ上の判断、組織内の承認、レビュー能力の不足も、開発手順を追加するだけでは補えません。工程化によって改善できるのは実行の規律であり、目的や判断の妥当性ではありません。
この違いを無視すると、TDDを実施した、レビューを通した、計画どおりに作業したという事実だけで、開発に成功したと判断してしまいます。必要なのは、工程を守ったかという確認に加えて、要件が業務上の目的に合っているか、テストが受け入れ条件を表しているか、運用上のリスクを許容できるかを判断することです。
自然言語の指示は強制できない
SuperpowersのようなSkillに「この工程は必須」と書くことと、AIが物理的に工程を飛ばせないことは異なります。公式リポジトリのIssueには、プロジェクトの指示でTDDと専用Skillの利用を必須としていたにもかかわらず、エージェントが実装を先に書き、後からテストを追加した事例が報告されています。実装ファイルを編集する前にフックで処理を止める提案もありましたが、このIssueは「not planned」として終了しています。
これは1件の報告であり、すべての環境で同じ問題が起きることを示すものではありません。ただし、自然言語の指示が行動を誘導する仕組みであり、CIの必須チェックや権限制御と同じ強制力を持つとは限らないことが分かります。Claude Code、Codex、Cursorなどでは、Skillの読み込み方、フック、サブエージェント、承認機能が異なります。Superpowersに対応しているという理由だけで、すべての環境が同じように工程を守ると想定してはいけません。
工程を確実に通過させるには、AIへの指示と技術的な制御を分けて設計します。Superpowersで設計、TDD、レビュー、検証の順序を示し、リポジトリ側では必須チェックと承認レビューを設定します。本番環境への反映や秘密情報の利用には、さらに権限制御と承認ゲートを設けます。機密情報、外部サービス、デプロイ権限の管理は、Superpowersとは別に必要です。
工程とコストの増加
設計、作業分割、TDD、レビューを実施すれば、当然ながら処理時間とトークンを消費します。作者自身、従来のSuperpowersは、事前計画、厳格なTDD、仕様適合とコード品質の2軸レビューを行うため、Superpowersを使わない開発より遅く、トークン消費も多かったと説明しています。工程を増やせば、コードの生成だけを終えるまでの時間は長くなる場合があります。
2026年6月に公開されたSuperpowers 6では、レビュー用の差分と情報の事前生成、レビュー構成、作業に応じたエージェントの使い分けなどが見直されました。作者側の評価環境では、旧版と比べて最大50％高速になり、トークン消費も最大60％削減されたと説明されています。ただし、これはSuperpowers 6と旧版を比較した作者側の評価です。Superpowersを使わない開発との独立した比較結果ではなく、導入すれば開発時間や費用が同じ割合で減ることを示す数値でもありません。
小さな使い捨ての試作や、完成条件が単純な作業では、Superpowersの全工程にかかる時間と費用が、コード生成の時間を上回る場合があります。複数のファイルを変更する開発、既存システムとの整合が必要な開発、レビュー、テスト、運用可能性が求められる開発では、工程の省略を防ぐ価値を期待できます。対象となる仕事に応じて、必要な工程と確認の深さを調整する必要があります。
何で導入効果として測るべきか
Superpowersを比較対象に含む定量評価も始まっています。2026年6月公開のRigorBench v2は、100件のベンチマーク課題を使い、Agent-Rigor、Superpowers、Agent-Skills、Baseline ReActを比較しました。Superpowersの工程スコアは0.41、成果スコアは0.70、Baseline ReActはそれぞれ0.40と0.64でした。一方、同じハーネス内では、工程スコアと個々の成果の相関が統計的に有意ではなかったと報告されています。
この結果だけで、Superpowersが有効または無効と判断することはできません。RigorBenchの著者2人は、比較対象であるAgent-Rigorの共同開発者です。論文内でも、直接的な利益相反と、評価軸がAgent-Rigorの設計と循環する構成概念上の偏りを認めています。評価にはLLMによる判定も含まれ、人の専門家による妥当性確認は今後の課題です。実際の開発プロジェクトにおける成功率、欠陥率、手戻り、運用負荷を測った研究でもありません。
Superpowersの比較評価は始まっていますが、実務での導入効果を確定できる段階には達していません。自社で導入する場合には、生成行数や実装件数ではなく、要求の見落とし、レビュー時間、手戻り、変更失敗率、障害、リードタイム、トークン費用を導入前後で比較する必要があります。導入効果は、AIがどれだけ多く書いたかではなく、チームが正しい変更をどれだけ安全に完了できたかで測ります。
Superpowersは、工程の省略を減らす有力な方法ですが、要件やテストの妥当性、最終判断、組織のレビュー能力まで保証するものではありません。自然言語による手順と技術的な強制を組み合わせ、対象業務に対して工程コストが見合うかを確認する必要があります。
まとめ
AI開発の成否は、コードを生成する速さや量だけでは判断できません。仕様が明確な局所作業ではAIの速さが生きますが、既存システムの変更では、文脈の理解、統合、レビュー、テスト、運用準備まで含めて成果を評価する必要があります。目的と受け入れ条件を先に定め、変更を小さく分け、作成と検証を分離し、テスト、ビルド、差分、レビューを完了の証拠にする工程が必要です。
Superpowersの価値は、新しい開発理論を作ったことではなく、AIが省略しやすい既知の工程をエージェントの行動へ組み込もうとしたことにあります。ただし、正しい目的や判断を自動的に与えるものではなく、CI、権限制御、承認ゲート、レビュー能力の代わりにもなりません。導入効果は対象業務と工程コストを含めて測り、自社の開発に適した範囲を見極める必要があります。AIに開発を任せるほど、担当者の役割は実装から目的設定、判断、検証へ移ります。
参考文献
The Impact of AI on Developer Productivity: Evidence from GitHub Copilot
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Superpowers: How I’m using coding agents in October 2025
RigorBench: Benchmarking Engineering Process Discipline in Autonomous AI Coding Agents, version 2
この記事を書いた人
