AI駆動開発とは？業務システムの要件定義・設計・実装を変える進め方

業務システムの検討では、長く『標準製品へ業務を合わせるか、費用と期間をかけて個別に作るか』が大きな選択肢でした。生成AIを開発工程へ組み込む動きが広がり、この二択の境界が変わり始めています。要件の整理、設計案の比較、実装、テスト、文書化までをAIが補助できれば、従来は費用対効果が合わず見送っていた固有要件も、対象を絞って検討しやすくなるためです。

ただし、AIを使えば開発が自動的に速く、高品質になるわけではありません。曖昧な要件、複雑な既存システム、確認されないコードをAIが増幅すれば、手戻りや運用リスクも増えます。本記事では、AI駆動開発を単なるコード生成ではなく、業務理解から運用改善までをつなぐ方法として整理し、標準SaaS・個別拡張・スクラッチをどう選ぶかを解説します。

本記事でいうAI駆動開発は、要件定義から運用までの各工程でAIを補助的に利用し、成果物を人と自動テストで検証する進め方です。AIによる無人開発や、期間・費用・品質の一律な改善を意味しません。

AI駆動開発とは何か

AI駆動開発は、開発者がコード補完を使うことだけではありません。業務ヒアリングから要求を整理し、設計と受入条件へ落とし、実装・テスト・レビューを行い、稼働後の利用データから次の改善を決める一連の工程でAIを使います。各工程の成果物を次工程の入力にし、判断理由と変更履歴を残すことが重要です。

要件定義そのものが不要になるわけではありません。IPAの解説でも、要件定義は利用者となる企業と開発者の認識を合わせ、ビジネス要求とシステム化要求を合意する工程とされています。AIで文書を速く作れても、誰のどの業務をどう変えるか、何を満たせば受入可能かは当事者が決める必要があります。

参考：要件定義とは？ 失敗しないための進め方（IPA・DX SQUARE）

開発の経済性は、どこで変わるのか

個別開発の費用は、画面や機能を作る時間だけでは決まりません。業務の聞き取り、要件の文書化、設計の整合確認、テストデータ作成、レビュー、移行、マニュアル、変更対応が積み重なります。小さく見える固有要件でも、周辺工程を含めると投資対効果が合わず、標準機能に業務を合わせる判断が合理的な場合がありました。

AIは、この周辺工程にある反復作業をまとめて支援できます。既存資料から論点を抽出し、要件とテストを対応付け、変更に合わせて設計書やテストケースを更新できれば、個別実装を検討できる範囲は広がります。重要なのは、削減できる可能性がある作業と、業務判断・承認・検証のように残る作業を分けることです。

ここで変わるのは『すべてを個別開発できる』という結論ではなく、事業価値の高い固有要件へ投資を集中しやすくなる点です。個別要件ごとに、期待効果、初期開発、継続保守、変更頻度、停止時の影響を比較し、価値が費用とリスクを上回る範囲だけを実装します。

標準基盤と個別実装を分ける

顧客・ユーザー管理、認証、権限、監視、バックアップなど、業務システムに共通する機能を毎回ゼロから作る必要はありません。実績のある標準基盤を利用し、その会社に固有のデータ変換、連携、判定、AI処理だけを個別に実装すると、開発対象と保守対象を絞れます。

この境界は導入時だけでなく、標準製品の更新や組織変更のたびに影響します。個別実装を標準機能へ戻せる条件、API変更時の担当、テストの自動化、データ出力を契約・設計段階で確認します。

AIが速度と品質を同時に高めるための条件

2025年のDORA調査は、AIを組織の強みと弱みを増幅する存在として整理し、AI投資の成果はツール単体ではなく、基盤となる組織システムに依存すると報告しています。つまり、要件、レビュー、テスト、開発基盤、フィードバックが整った組織ではAIを活かしやすく、整っていない状態では変更量だけが増える可能性があります。

参考：State of AI-assisted Software Development 2025（DORA / Google Cloud）

GitHubが実施した202人の経験者による無作為化比較試験では、指定されたAPI実装課題において、Copilotを使った参加者のコードが全テストを通過する可能性や、読みやすさなどの評価で改善を示しました。一方、これは限定された課題での製品研究であり、複雑な業務システム全体の納期や品質を保証する結果ではありません。自社では実際の業務シナリオを使って検証する必要があります。

参考：Does GitHub Copilot improve code quality?（GitHubによる比較試験）

• 要件IDと受入条件を先に決め、AIが作った成果物と結び付ける
• コードは静的解析、依存関係検査、単体・結合・権限テストを通す
• 本番データをそのまま外部AIへ入力せず、利用条件と処理先を確認する
• AIが出した設計・コード・文書は、担当者とレビュー者を分けて確認する
• 小さな変更単位で本番反映し、失敗時に戻せる手順を用意する
• 変更量ではなく、リードタイム、手戻り、不具合、利用結果を継続計測する

AI機能そのものを実装するときの追加要件

開発工程でAIを使うことと、業務システムの機能としてAIを提供することは分けて考えます。後者では、入力データ、出力の利用目的、人による確認、誤りの訂正、利用停止、ログ、委託先、モデル変更時の再評価までが製品要件になります。

経済産業省・総務省のAI事業者ガイドラインは、AIの開発・提供・利用におけるリスクベースの対応と、関係者間の情報提供・ガバナンスを整理しています。個別AI機能の要件には、精度だけでなく、データ、透明性、安全性、責任分担、運用後の監視を含めます。

参考：AI事業者ガイドライン検討会・第1.2版（経済産業省）

FDE型のチームと相性がよい理由

AIで実装の反復を短くできても、業務理解の距離が遠ければ、誤ったものを速く作るだけになります。FDE型の進め方では、業務とデータを現場に近い位置で確認し、標準機能で解く部分、運用を変える部分、連携・個別実装が必要な部分を同じチームで整理します。

この進め方の価値は、開発者を常駐させること自体ではありません。要望を機能一覧へ変換する前に、実際の業務、例外、データ、判断者を確認し、動く成果物を使って認識差を小さくすることです。AIは、議事録からの論点整理、試作、テスト、文書更新を補助し、チームは採否と受入に集中します。

投資判断は3年間の総額と変更速度で行う

AI駆動開発の採否を、初期見積もりの安さだけで判断すると危険です。標準ライセンス、AI利用量、要件整理、個別実装、移行、連携、テスト、運用担当者、変更対応、契約終了時のデータ出力を同じ期間で比較します。AIによって初期実装が短くなっても、仕様を理解できる人がいない、テストがない、毎月多くの修正が必要なら総コストは下がりません。

AI駆動開発を始める7ステップ

• 対象業務を一つ選び、現在の時間・情報欠落・手戻りを測る
• 標準機能で満たせる範囲と、固有要件を分ける
• 固有要件ごとに事業価値、変更頻度、停止時の影響を評価する
• 代表データと例外を用意し、受入条件を先に決める
• AIの利用範囲、入力可能な情報、人のレビュー責任を定める
• 小さく実装し、業務・権限・性能・セキュリティを検証する
• 限定展開の結果から、拡大・修正・停止を判断する

最初から開発工程の全自動化を目指す必要はありません。要件とテストの対応付け、既存仕様の検索、定型的な変換処理、文書更新など、効果を測りやすく、失敗時の影響が限定される作業から始めます。

よくある質問

AI駆動開発なら、要件定義は不要になりますか？

不要にはなりません。AIは要求の整理や矛盾候補の抽出を補助できますが、対象業務、優先順位、受入条件、責任分界は当事者が決めます。曖昧な要件のまま実装量だけを増やさないことが重要です。

スクラッチ開発より必ず安くなりますか？

一律には言えません。標準基盤を再利用でき、固有要件を絞れれば初期開発と保守の範囲を抑えやすくなります。一方、独自要件が大部分を占める、標準基盤との互換維持が難しい、検証データが不足する場合は費用が増えることもあります。

品質はAIが保証してくれますか？

保証しません。受入条件、レビュー、自動テスト、セキュリティ確認、段階展開を組み合わせて品質を確認します。利用するAIツールの出力、学習利用、保存条件も確認します。

どの要件を個別実装すべきですか？

事業上の差別化、法令・契約、重要な判断、既存資産との接続など、標準化しにくく価値の高い要件を優先します。単なる慣習や、利用頻度の低い例外は、運用変更や標準機能で代替できないかを先に確認します。

まとめ：作れる範囲ではなく、投資できる範囲が変わる

AI駆動開発が変えるのは、コードを書く速度だけではありません。要件、設計、実装、テスト、文書、運用をつなぐ反復コストを下げられれば、標準機能では足りない一方、全面的なスクラッチ開発ほどの投資はできなかった領域にも選択肢が生まれます。

有力なのは、安定した標準基盤を土台に、事業価値のある固有要件だけを個別に実装し、実際の利用結果から継続判断する方法です。AIを前提にしても、業務理解、受入条件、人の責任、セキュリティ、保守性は省略できません。それらを短い検証サイクルで確かめられることが、これからの業務システム開発を選ぶ基準になります。