「生成AIを開発に導入すれば、生産性が何倍にも跳ね上がり、爆速で機能がリリースできるようになる」
ここ1〜2年、技術系メディアやSNSではこのような景気の良い言葉が飛び交っています。しかし、実際に現場で手を動かしているエンジニアの皆さん、あるいはチームを率いるマネージャーの皆さん、本当にそんな魔法のようなことが起きているでしょうか。
私たちのチームでも、大きな期待とともに生成AIを開発プロセスに組み込み始めました。しかし、数ヶ月運用してみて開発セッションのデータを集計したところ、驚くべき、そして少し不都合な現実が突きつけられたのです。
全チームでベロシティ（開発速度）が低下している
さらに言えば、バグの発生数という定量的な品質指標を見ても、目に見えて改善したという実感はありません。
普通に考えれば、「AIの導入は失敗だった。今すぐやめよう」となるはずです。しかし、チームのエンジニアたちにヒアリングをすると、全員が全く逆のことを口にするのです。
「もう、生成AIのない開発環境には戻れない」
数値上のパフォーマンスは落ちているのに、現場のエンジニアはAIを手放せなくなっている。この矛盾（パラドックス）の正体は何なのか。私たちが直面した既存プロジェクトへのAI導入のリアルと、数値には表れない「開発体験（DX）」の本質について、等身大の事例とともにお伝えします。
丸投げは失敗する？生成AIが本当に機能する4つの活用法
よくある失敗として「仕様書を放り込んだら、システムが丸ごと出来上がる」という夢を見てしまいがちですが、既存プロジェクトに生成AIをまるごと適応することは、まず不可能に近いというのが私の結論です。長年積み重なったコンテキスト、独自のビジネスロジック、密結合したコンポーネントを、現在のAIにすべて理解させるのは認知コンテキストの限界を超えているからです。
そこで私たちは、システム全体ではなく「局所的」な領域からスタートしました。結果として、私たちのチームでは以下の4つのアプローチが、手始めとして非常にワークしやすい領域（打率の高い局所最適）として定着しています。
1. CIでのコードレビュー自動化
マージリクエスト（プルリクエストかも）が作成された際、のCI（継続的インテグレーション）と連携したAIが、自動でレビューを行う仕組みを導入しました。
シンタックスの不備、ケアレスミス、一般的なセキュリティリスク、命名規則の違和感などは、人間がレビューする前にAIが指摘してくれます。これにより、人間のレビュアーは「ビジネスロジックの妥当性」や「アーキテクチャの設計」といった、より本質的な議論に集中できるようになりました。
2. ユニットテスト・E2Eテスト（Playwright）の生成
ロジックを追加した際のユニットテストの骨組みや、PlaywrightによるE2E（End-to-End）テストの作成にAIを活用しています。
正常系だけでなく、境界値や異常系のテストケースをAIにリストアップさせるアプローチは非常に有効です。「この画面でボタンを押して、モーダルが開いて、文言を確認する」といった一連のブラウザ操作スクリプトを一から書くのは地味に時間がかかりますが、AIにベースを吐き出させることで、テスト作成のハードルは劇的に下がりました。
3. ブログ風紹介ページのベース作成
技術の紹介や新機能のアナウンスなど、チームでドキュメントやブログ風の紹介ページを書く際、AIは驚くほど威力を発揮します。
事前に書きたい要素やネタ（文脈）を十分に仕込んでおけば、一瞬で「いい感じ」のブログベース（文章や構成）を書き上げてくれます。ゼロから文章を組み立てる生みの苦しみがなくなり、人間は推敲とディテール修正に集中できます。
4. フロントエンドUIのサンプル・プロトタイプ作成
「React（あるいはVue/Next.jsなど）で、こういうバリデーションを持つフォームのUIを作って」と頼むと、モダンで綺麗なコンポーネントのコードを最初からかなり「いい感じ」に出力してくれます。
マークアップやCSSの微調整といった細かな試行錯誤の手間が減り、動くサンプルが瞬時に目の前に現れるため、フロントエンド領域のモックアップ作成においては、体感としてスピード向上に大きく寄与しています。
【リアルな検証結果】生成AI導入で開発ベロシティが低下した
このように、非常にスマートにAIを使いこなしているように見えるかもしれません。しかし冒頭で述べた通り、定量的なデータは非情でした。
AI導入前後でスプリントごとのベロシティ（消化ストーリーポイント数）を比較したところ、すべてのチームでベロシティが１割から２割、低下していたのです。また、QA（品質保証）フェーズや本番環境で検出されたバグの数を「品質」の指標として評価してみても、AI導入によってバグが激減した、というような劇的な変化は見られませんでした。
なぜ、AIを使ってコードや文章を自動生成しているのに、開発スピードが落ちてしまうのでしょうか。原因を分析すると、「AIの活用に伴う、新たな認知コストと周辺作業の発生」が見えてきました。
原因1：プロンプト調整と「AIの嘘（ハルシネーション）」の検証コスト
AIが吐き出したコードが「それっぽいけれど、実は微妙に間違っている」というケースは日常茶飯事です。コードをそのまま鵜呑みにすることはできないため、エンジニアはAIが書いたコードを一行ずつ精査（コードレビュー）しなければなりません。また、思った通りの出力を得るためにプロンプトを何度も書き直す時間も発生します。小さなクラスなどでは、自分で一から書いたほうが、結果として思考が整理されて早かった、というケースも少なくありません。
原因2：周辺作業への「こだわり」と本末転倒な時間消費
AIによって「テキストやアイデアの言語化」が一瞬で行えるようになった反面、それに付随する周辺作業に時間を取られるという現象が発生しました。
例えば、先述した「ブログ風の製品紹介ページ」をAIに作らせてみた時のことです。ネタを十分に仕込んでプロンプトを叩くと、AIは一瞬で非常に素晴らしいベースを書き上げてくれました。これにはチーム全員が感動しました。
しかし、問題はその先です。
「文章がこれだけいい感じなら、それに合わせるイラストやアイキャッチ画像も、生成AIで最高のものを作りたい」という欲が湧いてしまったのです。結果として、文章自体は数分でできたにもかかわらず、理想のイラストを生成するために画像生成AIのプロンプトを何時間もこねくり回すという、本末転倒な時間の取られ方をすることになりました。
こうした「AIの出力を調整・評価する時間」や「周辺のクリエイティブへのこだわり」が積もり積もった結果、純粋に機能をデリバリーする速度（ベロシティ）としては、数値上マイナスに振れてしまったのです。
なのに「もう生成AIのない世界には戻れない」理由
ベロシティは下がり、バグも劇的には減っていない。マネジメント層から見れば「生産性が落ちている」と判断されてもおかしくない状況です。しかし、現場のエンジニアたちに「AIの利用を禁止しようか？」と聞いてみると、全員に大反対されました。「もうAIなしの開発には戻れない」と皆が口を揃えるのです。
この認知のギャップはどこから来るのでしょうか。その正体は、数値には現れない「開発体験（Developer Experience = DX）」の劇的な向上にありそうです。
エンジニアが開発中に感じる「ストレス」や「精神的負荷」を、生成AIは極限まで削ぎ落としてくれているようです。
1.「真っ白なエディタ」に向き合う孤独からの解放
エンジニアにとって、新しいファイルを作成し、一からボイラープレート（定型コード）やテストのセットアップ、UIのモックを書く瞬間は、意外とエネルギーを消費します。
AIを利用すると100点満点ではなくても、瞬時に「60点〜70点の動くベース」を目の前に差し出してくれます。真っ白な画面から始めるのではなく、AIが作ってくれた叩き台を修正していく（リファクタリングする）というアプローチに変えるだけで、実装を始める際の心理的ハードルは驚くほど下がります。
2. 退屈な作業を肩代わりしてくれる安心感
ユニットテストの大量作成や、エラーハンドリングのバリエーションの記述、単調なデータ構造の変換など、エンジニアにとって「ロジックは分かっているけれど、書くのが面倒な作業」を AI は喜んで引き受けてくれます。
人間がクリエイティブな「設計」や「コアロジックの構築」に脳のリソースを100%割ける環境を作ってくれること自体が、エンジニアのモチベーションと精神的な快適さに直結するみたいです。
つまり、ベロシティという数字は「作業全体の時間」を示していますが、エンジニアが感じているのは「作業中の脳の疲労度の減少」なのです。数値上は同じ10時間、あるいは多少遅くなっていたとしても、その10時間の「心地よさ」が全く違う。これが、「戻れない」と言わしめる最大の理由だと考えてます。
3. 局所最適から見えた「文脈（コンテキスト）」の重要性
フロントエンドのUIサンプル作成やブログ執筆において、AIはめちゃくちゃ便利で手放せないツールですが、ここで重要な知見を得ました。それは、「事前にどれだけ密度の高いネタ（文脈・コンテキスト）を仕込めるか」で、AIの価値は天と地ほど変わるということです。
何も考えずに「いい感じの画面作って」「いい感じのブログ書いて」とだけ指示しても、当たり障りのない、使い物にならないアウトプットしか返ってきません。
-
- 既存のコンポーネント設計の思想やデザインシステム
- 画面が満たすべき厳密な仕様とユースケース
- ブログで本当に伝えたい独自の知見やターゲット層
これらの一貫したコンテキストを事前にしっかりとインプット（ネタ仕込み）した上で局所的に依頼する。このプロセスを徹底して初めて、AIは真の相棒になってくれます。
まとめ：スペック駆動の幻想と、これからの付き合い方
私たちがこの数ヶ月で学んだ最大の教訓は、「一からのスペック（仕様）駆動で、AIにすべてを丸投げして作らせるのはとても難しい」ということです。
AIに完璧なものを作らせようとすると、人間側が「完璧で、過不足のない、厳密な仕様入力（プロンプト）」をしなければなりません。しかし、そんな完璧な仕様が最初から言語化できるのであれば、エンジニアは苦労しませんし、それを書く労力はコードを書く労力と大差なくなってしまいます。
現時点における生成AIとの正しい付き合い方は、仕様を丸投げして全自動化を目指すことではありません。「人間が並走しながら、フロントのUIサンプル作成やテスト生成、ドキュメンテーションなど、局所的かつインタラクティブに優秀なアシスタントとして活用する」ことです。
全チームでベロシティが低下したという事実は、私たちがまだAIという新しい道具に慣れておらず、プロンプトの調整や画像生成での迷走といった「試行錯誤のコスト」を支払っている過渡期である証拠だと言えます。
しかし、数字のベロシティが少し落ちたとしても、チームのエンジニアが「戻れない」と感じるほど開発体験（DX）が向上している投資は、長期的には必ず組織の強みになります。なぜなら、エンジニアの精神的疲労が減り、不確実性に対する心理的ハードルが下がれば、より難易度の高い課題へ挑戦する活力が生まれるからです。
ベロシティの数字だけに一喜一憂するのではなく、現場の「楽しさ」や「快適さ」の裏にある本質的な変化を捉えること。それこそが、生成AI時代のエンジニアリングマネジメントに必要な視点なのではないでしょうか。
私たちのAIハックの旅は、まだ始まったばかりです。
