Meituan 技術チームのブログに 2026-05-07 に「业务研发平台」の署名で公開されたこの記事は、チームのコードの 90% 以上が AI で書かれている状況で、月平均 16 件の要件をこなしながら、2025 年 6 月には 5 万行未満だったコードが 31 万行にまで膨らんだエージェント評価システムをリファクタリングした当事者の記録である。出発点となる観察は、AI コーディングはそれだけでは複雑さを収束させないというものである。共通の基準がなければ、異なる人が AI で書いたコードはスタイルがばらばらになり、システムの劣化は遅くなるどころか速くなる。
チームは、ビジネスのデリバリーを止めずにリファクタリングを行った経験から得た 3 つの教訓を示している。第一に、AI コーディングの管理は、チームが取り組んでいるエージェント評価と同じ論理に従うということ。まず人と人を基準について合意させ（「人人对齐」）、次にその合意を AI が実行する制約に変える（「人机对齐」）。第二に、AI は経験の価値を塗り替えつつあるということ。AI を使うエンジニアは、深く隠れていた 10 件のパフォーマンスリスクを短期間で見つけ出した。記事は、経験の価値は、システム全体を見渡せることから、何が重要かを判断することへと移りつつあると論じている。第三に、技術的負債はビジネス要件と同じように、反復的に吸収できるということである。
要点
- チームは自らの手法を、評価の実践の再利用として位置づけている。まず基準について「人と人のアラインメント」を行い、次に AI Rules と Skills でモデルを制約することで「人と機械のアラインメント」を行う。これはチーム自身の経験に基づく、チーム独自の捉え方である。
- 記事は、順序が重要だと論じる。まずチームの合意がなければ、よく書かれた AI Rules であっても人によって解釈が異なってしまう。記事の言葉では、ボトルネックはツールではなく人である。
- AI がコードの主な供給源になると、コーディング規約は主として協働を助けるものではなくなり、AI の出力を制約するためのインフラになる、と記事は論じる。コードを生成するモデルは既存のコードパターンに大きく依存し、不整合を正すのではなく増幅してしまうからである。
- 技術的負債の発見には「専門家による方向づけ＋ AI による調査支援」を用いた。中核となる開発者が高リスクの境界と優先順位を定め、AI が網羅的なスキャンを行った。チームは、限られたリソースでこの方法により P0 の負債項目を 3 件、P1 を 2 件特定したと報告している。
- チームは自らの基準（エンジニアリングの階層化、ビジネスドメインのモデル規約、リポジトリ層の規約）を、コーディング中とプレレビューの段階で適用される「always」レベルの AI Rules に落とし込み、合意したドメインの責務分担を、コーディング中に段階的に読み込まれる Skill として取り込んだ。
- 4 層構造（Starter / Application / Infrastructure / Common）への移行は、すべて AI で行われた。リファクタリングのリーダーが最も複雑な 2 つのパッケージを自ら移行し、そのプロセスを AI が実行できる SOP にまとめ、チームの残りのメンバーがそれを 10 以上の中核パッケージに適用しつつ、ビジネス上の意味の受け入れ確認とコードレビューに注力した。
- 全面的な書き直しや専用のリファクタリングプロジェクトを行うのではなく、チームは技術的負債を、優先度の高いビジネス要件に付随する「ついでの作業」に分割した。そして、専用のリファクタリング時間は 1 日たりとも要求しなかったと報告している。
- AI によってコーディング時間が短縮されると、コードレビューが最も混雑する段階になった。これが記事のいう「木桶効果」（ドベネックの桶）であり、記事は、レビューが速くならない限り、生産性の向上分はレビューに飲み込まれてしまうと論じている（レビューのボトルネック を参照）。
- その対策として、開発者が PR 文書を提出する前に AI によるセルフレビューを何回か行い、AI が見つけたものをすべて修正する Pre-PR の仕組み、上位モデルが下位モデルのコードを審査するジャッジ役を務めること、そして異なるベンダーのモデル同士で互いの出力をレビューさせることを導入した。チームは、これにより実際にレビューのカバレッジが広がったと報告している。
- 開発者がすべての要件について QA も兼ねる AI 支援テストでは、完全に AI が生成したテストケースは暗黙的に関連する高リスクのシナリオを見落とし、価値の低いエッジケースを大量に生み出すことがわかった。チームは最終的に、人が範囲とリスクレベルを定め、AI がコードをスキャンしてケースを埋める、5 ステップのヒューマン・イン・ザ・ループの SOP に落ち着いた。
- 記事は、コードの 90% が AI 生成になると、エンジニアの関心は、コードを書くことから、AI が確実にコードを生み出せるエンジニアリング環境を設計・維持することへと移るべきだと結論づけている。
背景
この記録は、1 つのチームが 1 つの社内システムで得た経験であり、その数値（10 件のパフォーマンスリスク、P0／P1 の件数、コード行数の増加）は、測定による比較ではなくチーム自身の報告である。記事は他のチームに向けた 4 ステップのガイドで締めくくられている。AI に網羅的なスキャンをさせて技術的負債を洗い出すこと、基準について合意し、それを AI Rules と Skills として符号化すること、リーダーに再利用可能な移行 SOP を作らせること、そして人間のレビューがビジネス上の意味に集中できるよう Pre-PR の仕組みを確立することである。