AI駆動開発とは | 品質と信頼を支える技術基盤 | NTTデータSBC
当社はAI駆動開発を、開発効率化の延長ではなく、AIを前提に開発の進め方を見直す転換点として位置付け、実運用に向けた体制整備に取り組んできました。
これまでの試行で、既存の開発にAIを組み込むだけでは効果に限界があると認識し、開発プロセス全体をAIに最適化する方向へ舵を切りました。
scroll
商用適用への課題
AI駆動開発では、従来型システム開発とは異なる新たなセキュリティ対策が不可欠です。
「情報漏えい・誤動作・改ざん」 のリスク許容度が極めて高いシステムにおいては、特に重要となります。
AIによる ”静かなる事故” - AIには ”暗黙知” が通じない -
AIの自律的な最適化により、気づきにくい形で重大な不具合が発生するリスクがあります。
AIは、仕様やコードを改善する過程で、重複排除や統合などの最適化を行います。
しかしその過程で、本来維持すべき制約や前提条件が削除・変更されてしまう場合があります。
これらは一見すると合理的な変更であるため見落とされやすく、結果として品質やセキュリティに影響を及ぼす「気づきにくい事故（サイレント障害）」につながる可能性があります。
データ保護・アクセス管理の複雑化
AI活用の拡大に伴い、データ管理とアクセス統制の重要性が一層高まります。
外部AIサービスの利用やAIエージェントの自律的な処理により、データの取り扱いやアクセス制御の設計がより複雑になります。
こうした環境下では、従来の静的なセキュリティ対策に加え、動的な振る舞いを前提とした統制設計や監視の仕組みが求められます。
AI生成コードの激増による検証の難化
生成量の増加により、従来の手法では十分な品質検証が困難になります。
AIの活用により、コードや設定の生成量は飛躍的に増加します。
このため、テストの自動化やAIを活用した検証の高度化など、品質保証プロセスそのものの再設計が重要なテーマとなります。
当社におけるAI駆動開発
当社は、AIのメリットを最大化しつつ “壊さない” ―― 多層防護壁 × 安全基盤 × ヒト主導により、堅牢なシステム開発をスピーディに提供します。
AI駆動開発を安全に実現するためのアプローチとして以下の対策を行っています。
多層防護壁による品質保証
AI特有の “静かなる事故” を多層防御で防ぎます。
独自の仕組みによる安全基盤
権限管理と変更統制により、データを守りながら安全にAIを活用します。
ヒト主導で意思決定
「AI任せ」ではなく、ヒト主導 × AI補完で高品質な開発を実現します。
AI駆動開発を支える基盤・体制
独自のフレームワーク・技術力・検証体制を土台に、AI駆動開発を実務で機能する形へ落とし込んでいます。
AI駆動開発
フレームワーク
AIに自由に開発させるのではなく、作業範囲と共通基盤をフレームワークで制御し、安全に機能を追加・修正できる構造を実現します。
scroll
AI実装を支える技術力
組込み、モバイル、クラウドまでの開発知見を土台に、AIを実装・運用につながる形へ落とし込みます。実装可能性と現場適用性を高め、AI駆動開発を実務につなげます。
専門の検証チーム
組込みからソフトウェアまで、検証を専門に担ってきた知見を活かし、AI駆動開発の成果物を多面的に確認します。長年の実績に基づく検証力により、実案件に耐えうる品質を担保します。
AI駆動開発プロセス
AIと人が役割分担しながら、品質とスピードの両立を図ります。課題に応じて工程を遡り、見直し・再試行を繰り返しながら品質を高めます。
1
要件整理
業務要件の整理・構造化
不足要件や整合を確認し、後続工程につながる要件へ整えます。
人が担うこと
業務目的や優先度の見極め
AI提案の採否判断
2
設計
アーキテクチャ・UIの具体化
要件をもとに、AIが参照しやすい設計情報へ落とし込みます。
人が担うこと
設計方針や構成の妥当性判断
AI案の過不足、実務的合成の見極め
3
仕様統合・検証
要件・設計情報の統合と整合検証
AIを活用して矛盾や不足を洗い出し、参照する仕様を一つにまとめます。
人が担うこと
統合時の要件漏れ・省略の見極め・反映判断
要件・設計間の不整合に対する最終判断
4
実装計画
実装順序、影響範囲を整理
実装漏れを防ぎ、機能間・API間の整合を取りやすくします。
人が担うこと
優先順位の決定
AI適用範囲と変更禁止範囲（FROZEN SCOPE）の設定
影響範囲の見極め
5
AI実装
ルール・計画に基づくAI実装
ガードレールを適用しながら、品質と整合性を保って実装します。
人が担うこと
実装レポートの確認
逸脱時の差し戻し
6
品質検証
テスト・静的解析・レビューによる
多面的な検証
セキュリティや性能などの非機能面も含めて確認します。
人が担うこと
AI検証結果の妥当性確認
テスト計画の承認
機能・非機能を含めた品質の最終判断
プロセスを支える仕組み
各工程を横断して品質・安全性・開発の安定性を支えます。
AI品質ガバナンス
ESLintやRuff等の静的解析ツールと連携したAI Guardrailsにより、一貫したコード品質を維持します。品質のばらつきや技術的負債を抑え、安定した実装につなげます。
多角的なAIセキュリティ検証
「防御視点(ブルーチーム)」と「攻撃者視点(レッドチーム)」の両面から システムを多面的に検証します。設計段階から安全性を組み込み、実運用に備えます。
開発アセットの統制
アセットの重複防止、データベースの整合性維持、API設計の重複・矛盾抑止を行う自動統制により、チームでのAI開発でもコードや設計の乱雑化を防ぎます。
システム最適化支援
データベース構成やアルゴリズムの効率を分析し、システム全体を最適化します。商用環境でのスケーラビリティを見据え、拡張性や性能の改善につなげます。
PMダッシュボードによる可視化
開発プロセスと意思決定の履歴をダッシュボード上で共有します。
ブラックボックスになりがちなAI駆動開発の透明性を高め、進捗・課題・人間の介入タイミングを見える化します。
当社のAI駆動開発について、動画でもご覧いただけます。
検証事例
※上記事例・数値は当社の社内検証／PoCに基づく試算・結果です。案件の特性・仕様・規模により効果は異なり、同様の成果を保証するものではありません。
※ツール名は例示です。顧客環境・要件により採用ツールは異なります。
※Kiroは、Amazon.com, Inc.またはその関連会社の商標または登録商標です。
※Bolt.newは、StackBlitz, Inc.の商標または登録商標です。
INSIGHT
AI駆動開発の現場から見えてきた、人とAIの新しい開発のかたち
「AIが開発を行う時代、エンジニアの仕事はどう変わるのか。」
AI駆動開発を進める中で見えてきたのは、単なる開発効率化にとどまらない、新しい開発のあり方でした。現場での試行錯誤や品質への向き合い方、そして人間に求められる役割の変化について、実際にプロジェクトに携わるメンバーに話を聞きました。
■AI駆動開発を実践して、最初に見えてきたもの
Q：まず、今回のAI駆動開発の検証では、どのような取り組みを行ったのでしょうか。
社頭AIに開発の実装部分をどこまで任せられるかを、実際の業務アプリ開発で検証しました。
完全に任せてしまうと、仕様の空白をAIが「それらしく」補ったり、テスト完了を自己申告したりするという課題が見えていました。そこで、商用利用に必要な条件を明らかにするため、当社のAI駆動開発フレームワークが実運用に耐えられるかを社内実証（PoC）で確認しました。井上題材は営業管理システム（CRM）です。仮想顧客を設定し、AI活用による要件定義、AI駆動開発フレームワークを用いた開発実装、AIによるE2Eテストと人による動作確認。そしてそこから見えてきた課題を踏まえたフレームワークの改善に取り組みました。社頭約2か月で4サイクルの検証を行いました。1～2サイクル目で課題を洗い出し、3サイクル目で改善したスキルとプロセスの効果を検証。4サイクル目では完成コードを参照せず、要件定義書と画面仕様書だけでAI駆動開発を実施しました。最終的に約12万行のWebアプリを約4日で製造し、自動テスト2,347件の全件合格とAWS環境へのリフトアップまで到達しました。Q：実際に取り組んでみて、当初のAI駆動開発に対するイメージとのギャップはありましたか。
井上おおむねは想定どおりでしたが、実際に取り組んでみると、「AIに作らせる」こと以上に、「AIをどう使うか」を考えることの比重が大きかったですね。コード生成は速い一方、不具合修正や仕様漏れへの対応には時間がかかります。AIに正しく作らせるには、要件定義の段階で細部まで決めておくことが重要だと実感しました。社頭象徴的だったのは1サイクル目です。機能を分割してAIに並行実装させたところ、単体では動いても統合できず、設計書間の不整合により、画面機能が想定通りに動かないといった問題が発生しました。機能間の「接続点」を先に固めないと破綻してしまうため、実装の速さ以上に工程設計が重要だと分かりました。
もう一つのギャップは、進捗の読みにくさです。全体の8割は非常に速く進む一方で、残り2割の最後の詰めが読みにくい。従来とは異なる進捗管理や計画の立て方が必要になることも、今回やってみて初めて分かりました。
■AI駆動開発は「ツールの話」ではなく「プロセス設計の話」だった
Q：AI駆動開発に取り組む中で、最も大きな気づきは何でしたか。
井上最も大きな気づきは、AI駆動開発は“ツールの話”ではなく“プロセス設計の話”だということです。
どのツールを使うかよりも、どの工程をAIに任せ、どこを人が守り、何をもって完了とするかが成果を左右します。今回の取り組みで、機能単位で作り上げる進め方やガードレール設計の有効性も確認でき、プロセスの作り込みが重要だと改めて実感しました。社頭実際、初期サイクルでの失敗から立て直せたのは、ツールを替えたからではありません。機能間の接続点を整理し、実装AIと検証AIを分け、証跡に基づいて完了を判定する。こうした仕組みを、スキル体系と標準プロセスに組み込んだからです。フレームワークは万能ではなく、AIを適切に活用するためのガードレールであり、案件ごとの設計が必要だと分かりました。
■AIに任せるだけでは品質はつくれない
Q：AI駆動開発を進める中で、特に苦労したことは何でしたか。
社頭一番苦労したのは、実は実装ではなく要件定義です。人間同士なら通じる暗黙知がAIには通用せず、KPIの計算式や運用ルールが未定義のまま実装されることがありました。
また、自動テストが全件通過していても、権限管理に関する重要な欠陥がすり抜けるなど、セキュリティ面の課題も見えました。認証・権限・異常系の評価観点を明文化し、多層的なテスト戦略に落とし込むことに苦労しました。井上最も苦労したのは、AIの「完了しました」という報告をそのまま信じられないことです。テスト通過を申告していても、静的解析が未実施だったり、全体確認でエラーが残っていたりしました。さらに、セッションが変わると同じミスを繰り返すため、過去の失敗を“教訓集”として記録し、作業のたびに参照させる仕組みにしました。Q：AI駆動開発を実践する中で、品質保証の重要性も明らかになってきました。当社ならではの強みはどこにあると思いますか。
社頭当社の強みは、「AIで速く作る」だけでなく、AIで作成した成果物を「どのように品質保証するか」まで踏み込んでいる点です。
カバレッジ率やミューテーションスコアなどの指標を用いた品質計測、AIが作成した成果物を客観的に確認する仕組みや、独立した検証チームによる第三者検証などを、再現可能なプロセスとして体系化しました。長年の受託開発と検証で培った知見を組み合わせられることが、当社ならではの強みだと考えています。
■AIが進化するほど、人間の役割は重要になる
Q：AIと一緒に開発を進める中で、人間の役割はどのように変わると感じましたか。
井上エンジニアの役割は、コードを書くことから、仕様を決め、品質を見極める役割へ変わったと感じています。
今回、実装や不具合修正はAIに任せ、人間は修正方針の判断、進行管理、仕様漏れが見つかった際の対応を担いました。AIに任せる範囲が広がるほど、それを見極める人間の判断が重要になります。社頭同じく人間の役割は、「プロセス品質を見極める人」へ変わったと感じます。
AIは優秀ですが、指示が曖昧だと意図しない方向へ進むことがあります。そのため、仕様と成果物を突き合わせ、AIの自己申告だけに頼らず証跡から完了を判断する仕組みが必要です。人間には、より高度な判断力と開発知見が求められます。
■AIと人がそれぞれの強みを活かす未来へ
Q：今回の取り組みを通じて見えてきた、AI駆動開発の未来について教えてください。
井上今回、個人の能力を超える規模のアプリケーションを、約1か月で作り上げることができました。今後は、こうしたAIを前提とした開発が広がっていくと思います。その中で重要になるのは、前工程の高精度な要件定義と、後工程の人間の感覚に近い動作検証です。エンジニアの役割も、コードを書くことから、要件を定め品質を見極めることへ移っていくと考えています。社頭今回の検証で、「AIで作れるか」への答えは出ました。次のテーマは「商用化」です。開発標準やスキル、評価・検証観点を全社の資産として展開し、外部システムとの連携、大規模開発への対応、商用水準の品質保証といった課題に対する検証を続けていきます。あわせて、保守対応などビジネス面の整備も必要です。
その先にあるのは、AIが人を置き換える未来ではありません。AIは速さと網羅性を、人は判断、プロセス改善、品質保証を担う。こうした役割分担を前提に、開発の進め方そのものが変化していくと考えています。当社では、この変化を見据えてAI駆動開発のプロセスや品質保証の仕組みを整備しており、実案件で活用できる形で確立を進めています。AI駆動開発は、AIと人がそれぞれの強みを活かしながら、より高い品質と価値を生み出していく開発です。今回の取り組みで得た知見を活かし、私たちはこれからもAI駆動開発の可能性を追求していきます。
※本ページに記載されている会社名、製品名、サービス名等は、各社の商標または登録商標です。
AI駆動開発