R&D 効率の進化：UU Paotui が開発ライフサイクル全体に AI を組み込んだ方法

こんにちは。UU Paotui でエンジニアリング責任者を務める Yuan Zhao です。今回は、開発ワークフローのあらゆる段階に AI を組み込んだ方法を紹介します。

​

I. UU Paotui が開発ライフサイクル全体で AI を必要とした理由

​

技術的背景

オンデマンド配送の主要プラットフォームとして、私たちは毎日数百万件の注文を処理しています。技術スタックは典型的なマイクロサービスアーキテクチャで、フロントエンド、バックエンド、ビッグデータにまたがる800以上の中核サービスがあります。このように巨大で複雑なシステムで、開発速度とコード品質を両立することが常に中心的な課題でした。

AI Coding ツールが普及すると、新しい問題も現れました。AI がコードを書く速度は速いものの、スタイルが統一されず、コードレビューの負担がかえって増えたのです。さらに重要なのは、AI が複雑な業務ロジックやマイクロサービスアーキテクチャを理解しておらず、生成されたコードを利用する前に大幅な修正が必要だったことです。

私たちは4つの主要な課題を特定しました。

• 知識が人の頭の中にあり、効果的に蓄積、継承できない
• コーディング規約が文書にとどまり、実際の開発で徹底されない
• 設計案を再利用できず、同じ作業が繰り返される
• AI が常に修正を必要とする「外部支援者」にとどまり、共に働く「チームメイト」になっていない

これらの問題が重なり、開発効率のボトルネックになっていました。

​

II. 新しいパラダイム：「AI 支援コーディング」から「AI 組み込みワークフロー」へ

私たちが必要としていたのは、コードを数行補完するツールではありません。要件理解、設計、実装、レビュー、テスト、知識蓄積まで、開発ライフサイクル全体に参加できる AI でした。 Qoder の Repo Wiki、Rules、Skills を組み合わせることで、AI にコードベース、チーム規約、再利用可能な方法を与えられます。AI は「外から来た賢い人」ではなく、同じ文脈とルールを共有するチームメイトになります。

私たちは、企業 Wiki を知識基盤とし、その上に規約、設計、品質の各レイヤーを構築して開発フロー全体を再設計しました。AI はコードを生成する前に、社内の知識、規約、設計パターンを学習します。これにより、生成時点から品質と業務適合性を確保できます。

​

III. ワークフロー変革の実践

​

実践1：AI に「私たちの言葉」を教える

最初に、チームのコーディング規約、命名方法、アーキテクチャ原則、業務用語を Rules として整理しました。これにより、開発者が会話ごとに同じ背景を繰り返し説明しなくても、Agent が統一された基準でコードを生成できます。 頻繁に繰り返す作業は Skills としてパッケージ化しました。Skills には、実装手順だけでなく、参照すべきファイル、利用するツール、検証方法も含めます。一人の優れた実践をチーム全体が再利用でき、AI の出力も個人差に左右されにくくなりました。 規約を整理し、Rules として AI の生成工程へ組み込むことで、「生成した時点で規約に準拠する」状態を実現しました。その結果、コーディング規約の初回合格率は60%から95%へ向上しました。

​

実践2：AI によるコードレビュー

コードレビューでは、一般的な構文問題だけでなく、社内規約、マイクロサービスの境界、例外処理、セキュリティ、互換性を確認する必要があります。Rules とコードベースのコンテキストを Qoder に与えることで、レビューがチーム固有の基準に沿うようになりました。 AI は変更内容を分析し、影響範囲を確認し、潜在的な問題と修正案を提示します。人のレビュアーは単純な違反の確認から解放され、業務の正しさと重要な設計判断に集中できます。

標準化したラベルと自動化フローにより、エンジニアは煩雑なリリース操作から解放され、業務価値の提供へ集中できます。同時に、リリース工程の安全性と一貫性も維持できます。

​

実践3：AI にシステム全体を理解させる

800以上のサービスがある環境では、単一ファイルだけを見ても正しい判断はできません。Repo Wiki はリポジトリの構造、モジュール、主要フロー、依存関係を継続的に整理し、人と AI が共有できる知識に変換します。 新しいメンバーは、まず Repo Wiki でシステム全体を理解し、Ask モードで具体的な疑問を確認できます。Agent も同じ知識を使うため、既存の設計に沿った変更を行い、影響するサービスをより正確に特定できます。 Qoder は既存のマイクロサービスを解析してアプリケーション単位の Wiki を自動生成します。Quest Mode を使った一連の機能開発は約3時間で完了しました。文書作成に約1時間半、モデルによる生成に約30分、分単位のコードレビューと約30分の仕上げという内訳で、効率は大幅に向上しました。

都市バックエンドの API を MCP として整備し、AI Agent と都市業務システムを接続する標準化されたハブも構築しました。

従来はコーディング工程だけで断片的に AI を利用していました。新しいフローでは、設計、生成、レビューの各段階へ AI が深く入り、すべての作業が社内の知識基盤と規約の上で進みます。Wiki、Rules、Skills を人が一から書く必要はなく、企業コンテキストを正しく与えれば AI が生成できます。

• 開発開始：PRD を知識ベースへ取り込み、概要設計を生成する
• 詳細設計：概要設計とコードを基に詳細設計を生成する
• 実装：Rules の制約に従ってコードを生成する
• レビュー：Skills を使ってコードレビューを自動化する
• テストとリリース：単体テストと機能テストを生成し、CLI の一言の指示でリリースする。テストケースの採用率は70～80%に達した

この実践から得た最大の学びは、AI 導入では「ガバナンスを先行させる」必要があることです。規約のない AI は技術的負債を増やします。知識の蓄積が業務理解の基礎であり、単にツールを導入するより、プロセスを構築することの方が重要です。

​

IV. この新しいパラダイムの未来

この新しいパラダイムには、さらに大きな可能性があります。現在、次の方向を検討しています。

• インテリジェントテスト：既存の単体テストと機能テストに加え、UI 自動テストを強化し、業務ログから不具合を自動診断する
• MCP の適用拡大：バックオフィス機能を標準 API と MCP にし、業務担当者も小さなプラグインを作成して個人の効率を高められるようにする
• エンドツーエンド自動化：モデル能力の進歩に合わせてフローを継続的に最適化し、真のエンドツーエンド自動化を実現する

AI は今後、私たちの研究開発でますます重要な役割を担うと考えています。