美団（Meituan）の技術チームが、Agent評価システムの大規模リファクタリング事例を公開した。題材になっているのは、2025年6月時点で5万行弱だったコードベースが、約1年で31万行規模まで膨らんだ業務システムだ。しかもチームでは、9割以上のコードがAI支援で書かれていたという。
この話で重要なのは、「AIでたくさんコードを書けた」という成功談ではない。むしろ逆で、AI Codingは放っておくと複雑さを自動では減らさない。既存コードの構造が乱れ、チーム内の設計判断もそろっていない状態でAIを使うと、AIはそのばらつきを増幅し、似て非なる実装を量産する。美団の事例は、AI Codingを本番開発に入れるなら、生成量より先に開発環境そのものを設計し直す必要があることを示している。
31万行のコードで何が起きていたか
対象システムはAgent評価業務を支える基盤で、データ生産、ワークフロー編成、品質管理、複数人協業を同時に扱う。業務側も探索期にあり、何をどう評価すべきかが固まりきらないまま、高い頻度で要件が変わる。美団の説明では、月平均16件ほどの要求が走り、その内訳は業務要求が約8割、技術要求が約2割だった。
複雑さはコード量だけではない。下層では6種類のマルチモーダルデータ評価を扱い、上層ではタスクビュー、業務アクション、十数種類の品質検査、タグ体系、動的な割り当てルールが組み合わさる。結果として、日々の変更は多数の業務フローに影響しうる状態になっていた。
旧アーキテクチャの問題は、典型的な「探索期プロダクトの成長痛」でもある。データモデルの拡張力が足りず、新しい業務形式が増えるたびに個別対応のコードが増える。パッケージも要件単位で積み上がり、Controller周辺に複雑なロジックが混ざり込む。31万行まで膨らんだ後では、小さな修正でも影響範囲が読みにくくなる。
そこにAI Codingが重なった。チーム規模は約3倍に増え、メンバーのバックグラウンドも高並行処理、機械学習、管理系バックエンド、インターンまで幅広い。全員が同じ設計経験を持っているわけではない状態で、AIが主要なコード生産手段になると、規範の欠如がそのまま新しい技術債になる。
まずAIに「見る」仕事をさせた
美団の第一段階は、いきなり書き換えることではなく、技術債の棚卸しだった。31万行を人が端から読むのは現実的ではない。そこでコア開発者が高リスク領域を定め、AIに呼び出し関係、データ量に起因する性能リスク、状態管理、インデックス周辺の問題を広く探索させた。
ここでの役割分担は明確だ。AIは網羅的に見る。人は何を重要と判断するかを決める。美団はこの段階で、P0級の技術債3件、P1級の技術債2件を整理し、さらに深い呼び出し階層に隠れていた性能リスクを複数見つけたという。
これは日本企業にもそのまま当てはまる。AI導入の初期議論は「どのモデルがよいか」に寄りやすいが、古い業務システムの改修では、まずどこに危ない結合があるか、どのクエリがデータ増加に耐えないか、どの仕様が暗黙知になっているかを洗い出すほうが効く。AIは意思決定者ではないが、調査半径を広げる補助者としてはかなり強い。
Agent評価の考え方をAI Codingに転用した
この事例で一番おもしろいのは、美団のチームが自分たちの本業であるAgent評価の発想を、開発プロセスに持ち込んだ点だ。彼らはAgent評価で、まず人間同士の基準をそろえ、その後にモデルや評価指標を調整して人と機械の判断を近づける、という順序を重視していた。
AI Codingでも同じ順序を採った。先にチーム内で工程分層、ドメインモデル、依存境界の合意を作る。そのうえで、その合意をAI RuleやSkillとしてAIが実行できる制約に落とす。逆に、人間側の判断基準がそろっていないままAI向けルールだけを整えても、メンバーごとに解釈が分かれ、AIの出力も安定しない。
この考え方は、AI Coding時代の開発規約を「協業マナー」ではなく「AI出力を制御する基盤」と見直すものだ。従来の規約は、レビューや新人教育を助ける意味が大きかった。しかし、AIが大量のコードを書き始めると、規約はAIが参照するコンテキストそのものになる。乱れたコードベースは、乱れた生成を呼ぶ。
リファクタは大きく切らず、SOPにして分散した
実行段階では、旧来の要件単位パッケージを、Starter、Application、Infrastructure、Commonといった層構造と業務ドメイン単位の構成へ移していった。狙いはディレクトリを整えるだけではない。データオブジェクトが上位層へ漏れ出す問題を抑え、変換ロジックを集約し、Application層で契約を作り直すことにあった。
美団のやり方は、最初から全員に丸投げしない。主担当者が複雑な2パッケージを先に移行し、その過程でAIにも実行可能な移行SOPを作る。そこからチーム全体に展開し、他のメンバーはSOPを使ってAIに移行作業を進めさせ、本人は業務意味の確認とレビューに集中する。これにより、十数個の中核パッケージ移行を並行して進めた。
もう一つの特徴は、専用の長期リファクタ期間を取らず、業務要件の中に技術債解消を織り込んだことだ。ある機能改修に合わせて新しい業務モデルを入れ、別の機能更新に合わせて品質検査モデルを移行する。これは単なる「ついで作業」ではない。どの業務要件ならどの技術債を安全に消化できるかを見極める設計判断が必要になる。
ボトルネックはCode Reviewへ移る
AIが実装速度を上げると、次に詰まるのはCode Reviewだ。美団はここで、人工レビューの役割を「コードが正しいかを全部見る」から、「正しい制約の下で正しい問題を解いているかを見る」へ寄せている。
具体的には、開発者が提出前にAIで複数回セルフレビューし、規約違反、例外処理、拡張性、性能上の問題などを先に潰す。提出時には、変更点、影響範囲、レビューで見てほしい業務ロジックを明示したPR文書を添える。さらに、高性能モデルで低性能モデルの出力をレビューしたり、異なるベンダーのモデルで相互チェックしたりする運用も試している。
テスト設計も同じ発想だ。美団のチームでは開発者がテストも担っており、AIに全自動でケースを書かせる方式と、人が範囲やリスクを決めてAIに補助させる方式を比較した。結論は後者だった。AIに丸投げすると、PRDの品質に引きずられ、隠れた高リスク経路を落としたり、価値の低いエッジケースを大量に出したりする。そこで、人がテスト対象とリスク等級を決め、AIが影響インターフェースの抽出、分岐の把握、ケース組み合わせ、手順生成、カバレッジ表の作成を補助するSOPに落とした。
日本企業が見るべきポイント
日本の大企業やSI現場でこの事例を読むなら、論点は「美団はAIで31万行を直した」ではなく、「AIが大量に書く前提で、開発組織の品質管理をどう作り直したか」だ。
第一に、AI Codingの前提として、人間側の設計合意が必要になる。分層、ドメイン境界、依存方向、DTOや永続化オブジェクトの扱いを曖昧にしたままAIを入れると、生成速度は上がっても保守性は落ちる。
第二に、AI向けのルールは文書ではなく実行制約にする必要がある。レビュー時に「本当はこう書くべきだった」と指摘するだけでは遅い。AIがコードを書く時点で、常時読み込まれるRuleや、文脈に応じて呼び出されるSkillにしておくほうが効く。
第三に、AI導入後のボトルネックはレビューとテストへ移る。実装が速くなるほど、PRの質、影響範囲の説明、事前セルフレビュー、テスト範囲の設計が差になる。AI Codingを個人の生産性ツールとして見るだけでは、この下流の詰まりを解けない。
この事例は、中国大手のAI導入が「AIで何ができるか」から「AIを前提に組織の開発システムをどう組み替えるか」へ進んでいることを示している。日本企業にとっても、PoCの次に必要なのは、モデル比較表ではなく、技術債の棚卸し、工程合意、AI実行制約、Pre-PR、テストSOPを一つの運用としてつなぐことだ。