AI駆動開発

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駆動開発の可能性を追求していきます。

  close