運用10年弱のプロダクトを変革する：AI開発シフトによってチームはどう進化したのか

GREE Tech Conference 2026で発表された資料です。
https://techcon.gree.jp/2026/session/TrackA-5

Transcript

1. 運用10年弱のプロダクトを変革する AI開発シフトによってチームはどう進化したのか グリーエックス株式会社 AIX推進室 エンジニア 村田 翔
2. 村田 翔 グリーエックス株式会社 AIX推進室 エンジニア 経歴 2018年から「Aumo」をはじめとするメディア・コマース領 域の開発・運用を担当。 現在は「Axeff AI」シリーズの開発に注力。 趣味 愛犬たちを愛でること 2
3. 今日話すこと 1. 運用10年弱のプロダクト「Aumo」の現実 2. 気づき：コンテキストがないと、人もAIも「判定」できない 3. 打ち手①：機能を消して、コンテキストを減らす 4. 打ち手②：持つ人が地ならし、新しいメンバーとAIが建てる 5. 結果と、持ち帰り ── うまくいかなかったことも含めて 3
4. Aumo：2017年リリース 運用10年弱 対象：コア・管理ツール・比較サイト 現物コード：4リポジトリで約71万行 累計1.5万PR。他にもリポジトリ多数 PR差分：追加107万行、削除37万行 4
5. 10年分の「なぜ」が、コードの外にある • Nginxに2017年当時のリダイレクト設定が267件。代替済みでも誰も「消せる」と言えない • 「.internal ドメインだけHTTPS扱いにする」設定。理由はどこにも書かれておらず、消したら即ログ アウト • 2019年に入れたAMP対応コード。2024年に不要になっても、削除できたのは2026年 • 1つの変更が最大3リポジトリ・2言語にまたがる。テーブル1つ消すにも別リポジトリの停止確認が 要る • 答えはコードにもドキュメントにもなく、人の頭の中にある • 新しく入った人は、誰かが横につかないとPRが出せない 5
6. コンテキストを持たない側に、自分がなってみた • AI駆動開発というワードが出始めた頃、別の10年もののプロダクトへ • コードは出てくる。それっぽい。 • でも、正しいかどうかが自分には判定できない • 間違ったPRを作り、コンテキストを持つメンバーに横についてもらった • Aumoでは自分が「横につく側」。同じ自分なのに、立場でこれだけ変わる 6
7. 速くなったのは「生成」 開発ではなかった AIで「生成」は確実に短くなった でも、出てきたものが「正しいか」を判定する時 間が伸びた 判定できるのはコンテキストのある人 ボトルネックは生成から判定に移った AIの精度の問題ではない。コンテキストを持 たない者は判定できない 7
8. だから、消すことにした コンテキストを教えるより、コンテキストを減らす方 が早い 2025年5月にPdMへ提言：売らない機能から消す 基準：利用店舗数と直近3ヶ月の利用／今後も売る か／代替手段があるか（ALB・S3で代替できる 等） 機能ごとに「残す／移す／消す」を要件書で決め、 顧客連絡 → クローズ → データ削除の順に段階化 8
9. 何を消したか 1年で19機能・約7.2万行を削除 チラシ・クーポン・商品掲載、決済、電子チケッ ト、求人 など 比較サイト：17万行 → 1.4万行に 比較サイト2本をコアに統合（−2本）。変更は1 本で完結 消えたのは機能だけではない。「なぜ」を知 らないと触れない場所も減った 9
10. 役割の再配置：Before → After • Before • After • コンテキストを持つ人：新規開発の中心 • コンテキストを持つ人：消して地ならし • 新しいメンバー：レビュー待ち・伴走 • 新しいメンバー：分離領域で建てる • AI：補助ツール。出力の判定は人間 • AI：両方に生成と一次レビュー 10
11. 分けたのは「コンテキスト判断が要るか、要らないか」 • コンテキスト判断が要る仕事 • コンテキスト判断が要らない仕事 • 既存機能の削除・統合 • 分離された領域の新規開発 • 暗黙の依存を解くリファクタ • 基本的なコード品質のレビュー • 「消していいか」の判断・PdM交渉 • 定型的な実装・テスト • → 新しいメンバーと、AIへ 11
12. AIレビューの位置づけ：人間はビジネスロジックだけを見る • AIエージェントによる自動レビューを導入 • 目的は、人間の見る場所を変えること • AIが見る：nullチェック、命名、型、規約、典型的なバグパターン • 人間が見る：ビジネスロジック。「この条件、この顧客の場合どうなる？」 • 運用：AIレビューが先に読み、人間はその後に指摘の妥当性と設計を見る 12
13. レビューの会話が変わった • Before（2024）：人間が全部見る • After（2026）：AIが先に見る、判断は人間 • 「original_ids だと何のIDか分からないので original_shop_ids に」 • AI：「prepend が安全」「乱数の衝突」 • 人間：「ログは別テーブルにすべき？」 • 人間→AI：「この指摘は現コードに該当しない。 対応不要」 • 1PRあたり AI約3件・人間約1件。人間の1件 が設計と判定の会話になった • 「ファイル末尾は空行を入れてほしい」 • 「requests spec 追加したいです」 • 1PRあたり 人間約1.1件、AI 0件 13
14. 新機能を作る仕事を手放して、 自分は「消す側」に回った。 14
15. ありのまま：綺麗には進まなかった • 提言から方針決定まで半年。5月「消したい」→ 11月「利用店舗が少ないので無くす」 • 「クーポンだけ保留にできないか」— 結論は「今の機能は落として別で検討」 • Nginx撤去 → 本番で即ログアウト → 当日切り戻し。原因は設定の中だけの暗黙知 • 翌日、同じ意図をミドルウェアとして明示して再適用。暗黙知が1つ、コードになった • 消す判断は多くの合意が要り、消したあとに分かる「なぜ」もある。それでも進んだ 15
16. 結果 2026年、初めて削除が追加を上回った 純増 +7.2万行（2024）→ ±0（2026） 19機能・7.2万行を削除。比較サイト2本をコアに統 合（−2本） マージまでの中央値 3.6時間 → 2.5時間 レビュー：AIが先に約3件、人間の約1件は設計と判 定に コンテキストが簡潔になり、AIの出力が当た り、人が判断できる範囲が広がった 16
17. まとめ 判定できないのは、コンテキストの問題 だから、持つ人が消して簡潔にした 持つ人が地ならし、新メンバーが建てる 10年で初めて、コードが純減した 一歩目は、持つ人が消して整えること 17
18. 明日、コンテキストを持たない人がチームに入ってきて、 AIを渡せば戦えますか。 ご清聴ありがとうございました 18