AI駆動開発の事例から学ぶ！現場エンジニアのリアルな成果と失敗

AI駆動開発を自社にも取り入れたいけれど、「本当にうまくいくのか」「どこでつまずくのか」がいまひとつ見えてこない、と感じている方は多いのではないでしょうか。

この記事では、海外大手企業の成功談だけでなく、実際にAI駆動開発を実践している国内エンジニアのZenn・Qiitaの投稿やブログを取材源として、成果と失敗の両方をリアルな一次情報で整理しました。

開発責任者の方はもちろん、これから自社プロダクトへの導入を検討しているエンジニアの方にも役立つ内容です。

大手の成功談だけでは見えてこない「現場のリアル」

AI駆動開発（AI-Driven Development、AIDD）とは、要件定義から設計・実装・テストまでのソフトウェア開発工程に、生成AIエージェントを主体的に組み込みながら進める開発手法のことです。この記事で扱う「事例」とは、実際にAI駆動開発を導入した企業やエンジニアが、どんな成果を得てどこでつまずいたかを記録した一次情報を指します。

「事例」と聞くと、GoogleやIndraのような海外大手企業の生産性向上率をイメージする方も多いかもしれません。実際、IPA（情報処理推進機構）の2024年度ソフトウェア動向調査でも、AIを活用したソフトウェア開発の動向は国を挙げて調査されるテーマになっています。ただ、こうした大企業の数字だけを眺めても、「自社の開発チームで同じことが再現できるのか」までは正直つかみにくいのではないでしょうか。

次の章からは、実際に手を動かしている国内エンジニアの記録をもとに、数字と一緒に見ていきましょう。

生産性はどれくらい変わった？数字で見るAI駆動開発の事例

まず気になるのが、AI駆動開発によって開発生産性がどう変わったかという点ではないでしょうか。国内エンジニアの発信からは、次のような数字が確認できます。

発信元	実践内容	報告されている成果
SecureNavi開発チーム（Zenn）	新規プロダクト立ち上げをAI駆動開発で全面的に実施	生成AIが書いたコードの割合が99.9％以上に達し、開発生産性は2倍以上になったと報告（使用モデルはClaude 3.5 Sonnet）
edash Tech Blog（Zenn）	フロントエンドエンジニアが3か月間AI駆動開発に取り組んだ体験記	実装者から「AIの成果物を判断する観察者」へと役割が変化したと報告
Findy社の書籍（日経BOOKプラス）	開発チーム全体でのAI活用体制づくり	AI適用前と比べてプルリクエストの作成数やコミット数などの指標が2倍になったと紹介

これらに共通しているのは、単純に「AIにコードを書かせた」だけでなく、レビュー体制やチームの役割分担まで含めて開発プロセスそのものを見直している点です。

数字の大きさだけを追いかけると自社での再現性が見えにくくなるため、どんな体制変更とセットで成果が出ているのかまで確認しておくと、事例をより実践的に読み解けるはずです。

「思った通りにいかなかった」個人エンジニアが語るAI駆動開発の壁

実際にAI駆動開発を運用しているエンジニアの発信には、うまくいかなかった経験も率直に綴られています。ここでは、「つまずきのリアル」を紹介します。

生産性2倍でも「試行錯誤の連続」だった

SecureNaviのエンジニアは、AI駆動開発への全面移行を「笑えないけど笑うしかない日々」というタイトルでZennに投稿し、生産性が2倍以上になった一方で、完璧ではないAIとうまく付き合うための試行錯誤が続いたことを明かしています。

単純な生産性向上の数字だけでは見えない、AIとの協業に伴う苦労や工夫がうかがえる事例です。

スピードと引き換えに、設計の一貫性が崩れやすい

また、Zennに投稿された「AI駆動開発を全力で試して得られた、10の実践テクニックと知見について」では、AI駆動開発は開発スピードを高められる一方で、AIが目の前のタスク解決に集中するあまり、全体設計やコードの一貫性への配慮が難しくなり、業務ロジックが各所に散らばりやすくなるという課題が指摘されています。

その対策として、機能開発中は多少のコードの粗さを許容しつつ、定期的にリファクタリングの時間を確保するという運用方針が紹介されていました。

⚫︎設計品質を保つ「仕様駆動開発（SDD）」

こうした「AIに任せきりにすると設計品質がぶれやすい」という課題への一つのアプローチとして、近年注目されているのが仕様駆動開発（SDD）です。

仕様駆動開発では、コードを書き始める前に仕様を明文化し、その仕様をもとにAIへ指示を出します。あらかじめ開発の方向性を定めておくことで、AIへの指示のブレを抑え、実装の一貫性を保ちやすくするという考え方です。

AI駆動開発と仕様駆動開発の違いとは？セキュリティ観点から見る選び方でも、両者の違いや使い分けについて詳しく整理されています。

「AIで生産性が下がる」という指摘との向き合い方

AI駆動開発をめぐっては、「AIを使えば必ず生産性が向上する」とは限らないことを示す研究もあります。

たとえば、METRの研究では、AIツールを利用した熟練エンジニアの作業が、AIを使わない場合よりも遅くなったという結果が報告され、AIによる開発生産性向上をめぐる議論を呼びました。

一方、Zennの「AIは本当に開発者の生産性を下げるのか？」では、この結果について、AIの応答を待ちながら一つのタスクだけを進める「シングルタスク型」の使い方が、生産性低下の一因になっている可能性を指摘しています。

そのうえで、AIを単なるコード生成ツールではなく、自律的に動く同僚のように捉え、複数のタスクを並列して進めることが重要だという考え方が示されています。

チーム開発の現場に見るAI駆動開発の実践パターン

AI駆動開発を組織として取り入れる際、どこで成果が出て、どこでつまずきやすいのか。ここではチーム開発の現場から報告されている成功事例と失敗事例を見ていきます。

成功事例：複数リポジトリにまたがるリプレースを短期間で実現

Qiitaに投稿された「【AI】AI駆動開発事例まとめ」では、受注管理システムのリプレースプロジェクトにおいて、チームでAPIの移植やバグ修正・機能追加を5日間で実施し、高い生産性を発揮したという事例が報告されています。複数リポジトリにまたがる開発対応も遂行できた点は、タスクの進め方を工夫できたチームならではの成果だと言えそうです。

成功事例：ツール比較で自社の開発フローに合う進め方を見極める

iimon社のテックブログ「AI駆動開発の新常識「SDD」- Spec Kitとcc-sddを実際に使って感じたこと」では、代表的なSDDツールである「Spec Kit」と「cc-sdd」を実際に比較検証し、それぞれの特徴を整理できたことが報告されています。導入前にツールを試して自社のフローに合うものを選べた点が、チーム開発ならではの成功パターンと言えるでしょう。

失敗事例：大きすぎるタスクは分割が前提

先ほどのQiitaの投稿では、大規模・長大なタスクをそのままAIに指示しようとすると対応しきれず、タスク分割の重要性を実感したという振り返りも記録されています。チームでAIを活用する場合ほど、AIに渡す指示の粒度をあらかじめ細かく設計しておくことが成否を分けるポイントになっているようです。

失敗事例：複数リポジトリ・チームルールの壁

タイミー社の開発ブログ「AI活用で生産性は上がる？仕様駆動開発(SDD)の実践と課題」では、cc-sddを導入した際に、複数のリポジトリをAIが横断的に操作できない、チーム固有のタスク分割ルールがなくAIの出力が開発フローに合わない、といった課題に直面したことが報告されています。既存のルールやリポジトリ構成とAIをどう噛み合わせるかが、チーム開発では壁になりやすいようです。

こうした成功・失敗の両方から見えてくるのは、AI駆動開発が「ツールを導入すれば終わり」ではなく、開発プロセスをAI前提で設計し直す取り組みだということです。AWSが提唱する「AI-DLC（AI駆動開発ライフサイクル）」のように、開発工程全体をAI中心に再構築する考え方も登場しています。

詳しくはAI-DLCとは？AWSが提唱するAI駆動開発ライフサイクルをわかりやすく解説！でも解説しています。

よくある質問

まとめ｜AI駆動開発を成功させるために

AI駆動開発の華やかな数字だけを見て、「自社でも同じようにできるはず」と考えるのは少し危険かもしれません。実際にAI駆動開発に取り組んだエンジニアの事例を見ると、成果の裏には、タスクの分割方法やレビュー体制、リファクタリングの時間確保など、さまざまな工夫があります。

AI駆動開発を成功させるために重要なのは、特定の事例をそのまま真似することではなく、自社の開発体制や課題に合わせて、AIをどこに組み込むのが効果的かを考えることです。

まずは現在の開発フローを見直し、「どの工程ならAIを活用できそうか」「AIに任せる部分と人が担う部分をどう分けるか」といったところから、小さく検討してみるとよいでしょう。

カスタメディアでは、AIを活用したプラットフォーム開発について、こうした初期の整理や開発方針の検討段階からご相談を承っています。

⇒ 【短納期・低価格】最小限の機能から市場の反応を確かめる「カスタメディアプラットフォーム」の詳細はこちら