AI駆動開発（AIDD）で中規模機能の開発期間を1.5ヶ月から3週間に短縮した話

大規模な Web 開発プロジェクトに GitHub Copilot を使った AI 駆動開発（AIDD）を導入したところ、中規模機能の開発期間が 1.5ヶ月から3週間に短縮されました。この記事では、スピードが改善した仕組みと、導入して2ヶ月で見えてきた運用上の課題・対策、そしてコスト管理の実践を共有します。

導入の前提

対象は、フロントエンドに React・Next.js を採用した規模の大きい Web 開発プロジェクトです。複数のプロダクトを並行して開発する体制で、AI ツールとしては GitHub Copilot を使っています。以降の内容はすべて GitHub Copilot を前提とした話です。

AIDD は全プロダクトに一斉導入したわけではありません。要件定義の複雑さや外部との調整が必要なプロダクトは対象から外し、まず一部のプロダクトから段階的に始めています。この記事の数値も、その先行導入したプロダクトの実績です。

PRD を核にした開発フロー

開発フローには Amazon が提唱する Working Backwards の考え方を取り入れ、PRD（製品要求仕様書）を要件定義の核に置いています。上流から下流まで、次の流れを AI で組み立てています。

PRD 生成 → UI 設計 → API 仕様 → 開発・テスト → リリース

会議の録音などをもとに AI でたたき台を作り、そこからブラッシュアップして PRD を仕上げます。ここで PRD をしっかり作り込めるかどうかが、後工程がスムーズに進むかを左右します。要件が固まっていれば、設計以降は AI が一貫した形で組み立ててくれるためです。

開発期間が1.5ヶ月から3週間に

導入から2ヶ月時点の実績は次のとおりです。

ベロシティの推移でも、5月中旬あたりから消化スピードが上がってきているのが確認できました。スピードが改善した要因は、大きく3つあると考えています。

1. Q&A の往復が減った。PRD の書き方には人によるばらつきがあり、要求の抜けが開発フェーズで発覚して何度も確認をやり取りすることがありました。AI が PRD を生成することで表現が統一され、往復が減りました。
2. 設計の迷いが減った。PRD が固まっていれば設計も AI が一貫して組み立てるため、人による判断のブレや記述ミスが減りました。
3. バックエンドとフロントエンドの API を同時に作れる。従来はバックエンドを作ってレビュー、フロントエンドをつなぎ込んでまたレビュー、と繰り返して1ヶ月以上かかっていました。AI で両方を同時に構築できるようになり、レビュー回数も減って1週間かからずに終わるケースが出てきました。

運用で見えた4つの課題と対策

スピードが上がった一方で、運用面の課題も出てきました。ここが導入して2ヶ月でいちばん学びの多かった部分なので、正直に共有します。

1. 非エンジニアの AI 活用とガードレール

PRD や UI の生成を担当するのは PM が中心で、その中には非エンジニアもいます。AI が処理の途中で不要なライブラリを入れようとしたとき、エンジニアなら入れるべきか判断できますが、非エンジニアには判断が難しく、そこで手が止まってしまうことがありました。プロンプトインジェクションのリスクもあります。

対策として、まず禁止事項を明文化しました。

• 不要なライブラリの導入禁止
• 外部入力への直接操作の禁止
• Git 操作の禁止

あわせて、Git フックで技術的なガードレールを敷いています。不要なライブラリやコマンドが入ってきそうなときは、その場で処理を止めます。GitHub Copilot CLI にはフックのトリガー設定があり、外部へのリクエストを検知したタイミングで処理を中断する仕組みも用意できます。

2. デプロイエラーの検知遅延 → Slack 通知

非エンジニアがデプロイする場面では、エラーが出ても気づけない、気づいてもログの場所や直し方がわからない、という状態がありました。

そこで Slack 通知を導入しました。デプロイでエラーが出たら、必要なログの部分だけを Slack に通知します。担当者はそのログをコピーして GitHub Copilot に渡し、修正を指示するだけでデプロイまで進められます。AI に任せつつ、人が自然に気づいて動ける導線を作ることを意識しています。

同じ考え方で、ソースコードとドキュメントの不整合を AI が検知して修正のプルリクエストを自動生成する仕組みも入れました。ただし自動生成のプルリクは放っておくと積み上がり、誰がいつレビューするのかという別の課題を生みます。これも Slack で担当者に通知し、気づいてすぐマージできるようにしています。

3. ドキュメント生成の標準化

設計書のようにテンプレートがある文書とは別に、その都度作りたい資料には決まった型がなく、生成がばらつきがちでした。共通化できるところはスキルとして用意し、標準化を進めています。

図については、Draw.io と GitHub Copilot を組み合わせています。AWS アーキテクチャ図のような図を Draw.io 上で生成させると、適切なアイコンを使い、説明文まで添えてくれるので便利に使えています。ときどき意図しない説明が出ることもあり、この辺りはまだ改善の余地があります。

4. レビュー運用の停滞

AI で開発・修正を進めると、人が意図していない修正も混ざることがあり、レビュー担当がプルリクの内容を理解するのに時間がかかるようになりました。変更の意図の把握や、アルゴリズムの詳細を説明するコストも増え、レビュー待ちのプルリクが積み上がっていました。

対策として、次のような工夫を進めています。

• 開発プロセスを自動で記録する
• プルリクの概要を AI で要約し、レビュー時間を削る
• 軽微な修正は、プルリク上で GitHub Copilot をメンションしてコードエディタを開かずに直す

GitHub Copilot のコスト管理

2026年6月から、GitHub Copilot の料金体系がトークン数 × モデル単価の従量課金に変わりました。以前のリクエスト単位の定額に近い体系から変わったため、使い方を意識しないとコストが膨らみます。

ある1ヶ月の利用実績では、モデルによって金額に大きな差が出ました。

高性能モデルは効果が大きい反面、チーム全体で使うと一気に費用がかさみます。そこで、次の方針で運用しています。

• 高性能モデルは効果が見込める場面に絞る。迷ったら低コストモデルを選ぶ
• テンプレートやスキルを活用し、不要なコード生成を避ける

まだ残っている課題

導入は進んでいますが、課題も残っています。

• スキルの整備：バッチのみの開発要件に対応できるスキルがまだ整っていません。AWS Amplify Gen 2 や CDK は AI がまだうまく対応しきれない領域があり、スキルのカスタマイズが必要です。
• セキュリティの強化：ガードレールは敷いていますが、商用環境のリリースに向けてセキュリティ要件を洗い出し、対応を強化していく方針です。
• PRD 間の整合性：複数の PRD をまたいだ整合性の確保は難しいテーマです。開発着手前にユーザー体験やデータフローの設計を管理チーム側で押さえることで対応していますが、開発側から整合性の状態が見えづらい面は残っています。もっとも、AIDD でスピードが出ている分、仮に整合性がずれて手戻りが発生しても、以前ほど時間をかけずに開発に戻れるようになりました。

まとめ

AIDD を導入した結果、開発スピードには明確な改善傾向が見られました。一方で、非エンジニアの AI 活用、エラーの検知、レビューの停滞といった運用面の課題も同時に見えてきました。ガードレールと Slack 通知のような仕組みで、AI に任せる部分と人が気づいて動く部分をつなぐことが効いています。