AIに「書かせない」AI駆動開発｜Adobe Commerce開発の実践記録①

「AIでコードを速く書けるようになった。でも、手戻りは減らない」。こうした課題は、AI活用を進める多くの開発現場に共通します。

コウェルでは、Adobe Commerce（Magento）の開発において、要件定義からコードレビューまでの全工程にAIを組み込む取り組みを進めてきました。目指したのは、AIに速く書かせることではありません。手戻りを減らし、品質が担当者の力量に左右されない開発プロセスをつくることです。

本記事では、当社が支援する海外拠点でのECサイト開発案件（Magento）での実践をもとに、その仕組みと考え方をご紹介します。

EC開発の現場で起きる問題の多くは、コードを書く速さではなく、その前後で生まれます。

• 要件が曖昧なまま着手し、後工程で仕様の認識違いが見つかる
• レビューの観点や深さが担当者ごとに異なり、品質にばらつきが出る
• テスト観点の抜け漏れにより、不具合の発見がリリース直前にずれ込む

AIでコードを書く速度を上げても、これらの問題は残ります。むしろ、作る量が増えるほど、要件の確認不足やレビューの見落としの影響は大きくなります。

そこで当社は、AIを「コードを書く道具」としてではなく、開発の各工程で判断を支える存在として位置づけ直しました。

私たちの取り組みの前提は、AIは開発者の代わりではなく、開発者の判断を強化するものだという考え方です。最終判断と、その結果への責任は開発者が持ちます。

この考え方は、AIへの問いかけ方にも表れています。「このコードを書いて」と丸投げするのではなく、「この要件を分析して」「この設計のリスクは何か」と問いかけます。AIには分析と論点の洗い出しを任せ、何を採用するかは人が決めます。

AIの出力をうのみにしない前提で使うからこそ、AIは開発プロセスに安心して組み込めると考えています。

開発を6つの工程に分け、工程ごとに役割を与えたAIコマンドを用意しました。使い方を担当者任せにせず、「この工程では、AIにこれをさせる」という入口を標準化しています。

各コマンドには、Adobe Commerce特有の設計ルールや、見落としやすいケースの観点を組み込んでいます。汎用のAIに一般論を答えさせるのではなく、Adobe Commerce開発の知見を前提に分析させるための工夫です。

定型的な処理には軽量なモデル、推論が必要な工程には上位モデルを使い分け、運用コストも抑えています。

もう一つの特徴は、各工程のAIの出力が、次の工程でそのまま使える形になっていることです。AIを工程ごとの「点」で使うのではなく、プロセス全体の「線」として組み込んでいます。

1. 要件分析で洗い出した受入基準と確認事項が、計画のタスク分割の土台になる
2. タスクごとに、設計でモジュールの構造を固める
3. 設計と受入基準をもとに、テスト観点表を作る
4. 実装したコードを、決まった観点でレビューする

前工程の成果物が次工程の入力になるため、「要件では確認したはずなのに、テストで観点が漏れた」といった工程間の断絶が起きにくくなります。

工程ごとのコマンドは、出力の構成をあらかじめ決めた「型」になっています。たとえば要件分析では、AIは次の構成で結果を返します。

• 要件の要約
• ユースケース
• 受入基準
• Magento特有の考慮点（見落としやすいケース）
• 業務担当者への確認質問

ポイントは最後の「確認質問」です。AIは要件の曖昧な点を推測で埋めず、「確認が必要な点」として明示します。着手前に確認すべき点がそろうため、後工程での認識違いを減らせます。

出力の型が決まっているため、担当者が変わっても同じ粒度で分析結果がそろいます。

取り組みを通じて見えてきた効果は、大きく2つです。上流での確認が早まって手戻りが減ったこと、そしてレビューとテストの品質が担当者の力量に左右されにくくなったことです。

テストやレビューは決まった観点で行うため、誰が担当しても一定の水準を保てます。上流でも、設計書づくりや確認のやり取りにかかる時間が短くなり、仕様の認識違いを早い段階で防げるようになりました。

上流の設計・確認の変化と、日本側の要件を開発・QAへ正確に渡す仕組みは第2回で、レビューとQAの標準化は第3回で詳しくご紹介します。

AIを開発プロセスに組み込むうえで、仕組みと同じくらい重視しているのが運用ルールです。

• 最終判断は人が行う：AIの指摘や提案を採用するかどうかは、開発者が判断します。
• 曖昧な点は推測しない：要件やテスト観点で不明な点があれば、AIに推測させず、確認事項として残します。
• 機密情報は入力しない：個人情報やカード情報など、お客様の機密情報をAIに入力しないためのルールを、ログや権限の管理とあわせて明文化する取り組みを進めています。

とくに、ECサイトは個人情報や決済情報を扱います。AI活用の効果と同じくらい、「何をAIに渡さないか」を明確にしておくことが、お客様に安心して任せていただくための前提だと考えています。

本記事でご紹介した数値の一部は、担当者の実感値にもとづくものです。AI活用の効果を正しくお伝えするため、今後は作業時間やレビューの指摘件数などを継続的に計測し、実測値で示せるように取り組んでいます。

あわせて、今回の案件で整えた仕組みを社内の標準として展開し、役割ごとのプロンプトやルールの整備を進めていきます。

AI駆動開発で大切なのは、AIに速く書かせることではなく、開発プロセス全体の中でAIに役割を与えることです。工程ごとにAIの役割と出力の型を決め、最終判断は人が行う。この仕組みによって、手戻りを減らし、品質を担当者の力量に依存させない開発を目指しています。

関連リンク

• サービスページ「AI駆動開発」
• Adobe Commerce開発に生成AIを導入したら 何が変わったか（どこで使い、何が変わったかの概論）
• LIXIL様向け Claude Code 集中レクチャー実施レポート（お客様社内でのAI活用・内製化を支援した事例）
• 第2回：要件の「認識ズレ」をなくすBrSE×AI｜Adobe Commerce開発の実践記録②
• 第3回：コードレビューとQAを「人に依存させない」AI活用｜Adobe Commerce開発の実践記録③