はじめに
こんにちは。SUZURI・minne事業部 minneグループにてエンジニアリングリードをしているkazuです。
minneでAI前提のプロダクト開発組織づくりを進めています。これまでは個別の仕組みについて書いてきました。
- PRのレビューが追いつかない！もう人間がボトルネックなので、気合いではなく仕組みで少しずつなんとかしていく
- Claude Code Actionで複数リポジトリを横断して情報を参照し調査・実装を進めてもらおう
整備してきたのは次の2つです。
- PRサイズラベルの自動付与・AIレビューによるApprove・条件付きauto mergeの3段構えを入れたこと
- Claude Code Actionがリポジトリを横断してソースコード・issue・PRを参照できるようにしたこと
前者は人のレビューが追いつかなくなったためです。エンジニアはエージェントを並列に動かし、CSやディレクターもClaude Code Action経由でPRを出すようになりました。後者はminneのコードがRails・Next.js・iOS・Androidに分かれており、片側だけでは調査を完結できないためです。
これらの仕組みを整備したうえで、組織とプロセスの側がどう変わってきたかを短くまとめます。2026年9月時点の現在地です。
AI自律マージ率
詳細は前回の記事に書きました。AIのレビューでリスクを評価し、ユーザー影響が小さいものはAIエージェントが自律的にマージできるよう進めています。その仕組みが「PRサイズラベルの自動付与 → AIレビュー＆Approve → 条件付きauto merge」の3段構えです。
人間の手を介さずAIのApproveからマージまで完了したPRの割合は、直近30日で次のとおりです。
| プラットフォーム | AI自律マージ率 |
|---|---|
| Android | 94% |
| iOS | 65% |
| サーバーサイド | 74% |
| 全体 | 83% |
分母は、その期間にマージされたPRの全件です。auto mergeの対象条件を満たしたPRだけに絞ってはいないので、そもそも自動マージの対象外だったPRも含んだ数字になります。
Webとモバイルで越境する
いまのチームはWebエンジニア2人、モバイルエンジニア5人です。
以前は「WebはRails、モバイルはiOS/Android」という職能の分かれ方でした。いまは設計をWebエンジニアとモバイルエンジニアで一緒に行い、そこで決まったサーバーサイド（Rails / GraphQL）の実装はモバイルエンジニアが進めています。最近は、モバイルエンジニアが作ったサーバーサイドの設計を最終的にWebエンジニアがレビューする形になってきています。
AIが既存コードの規約に沿った実装をかなり担えるようになった結果、「そのフレームワークを書いた経験があるか」が越境の障壁になりにくくなりました。
丸投げを避けるために気をつけているのは次の3点です。
- テーブル設計・APIの切り方・データ移行のような後戻りコストの高い意思決定は、Web側と一緒に決めてから実装に入る
- レビューは越境先の人が見る
- 判断基準を
CLAUDE.mdや.claude/skills/に文章として置く。人とエージェントの双方に同じものが効く
モバイルのリリースを2週間に1回から1週間に1回へ
PRのスループットが上がっても、ユーザーに届くのが2週間後ならリードタイムは縮まりません。そこでモバイルのリリースサイクルを週1回に変えました。
- 1リリースに載る変更が減るので、問題が起きたときの切り分けが速い
- 「次のリリースに間に合わせないと2週間後になる」という駆け込みマージの圧力がなくなる
- 頻度を上げるにはリリース作業の省力化が前提になるので、その整備を進める強制力にもなる
一方で、リリースのたびに必要な検証作業の頻度も倍になりました。週1サイクルのうちリリースと検証に日数を取られるので、実装に充てられるのは実質2日ほどです。それでも、AI前提の開発によって、かつての1週間1スプリントで出せていたアウトプットと同程度かそれ以上をデリバリーできています。
とはいえ検証の負荷は確実に増えているので、モバイルの検証作業をどこまで自動化できるかが今後の課題です。
自動マージのバックテスト
AIがApproveしてauto mergeする以上、その判定が妥当だったかを後から説明できる必要があります。内部統制の観点でも、サイズ判定の根拠がPRに残っているか、導入時点からの期間を抜けなくカバーできているか、サンプリングでなく全件を対象にできているかが論点になりました。
そこで月次のモニタリングとは別に、サイズ判定の妥当性を後から再検証するバックテストを整備しました。手順は次の4ステップです。
- 対象期間中にbot名義でマージされたPRを全件リスト化する（人が対象を選ばない）
- 全件に対して機械で一次スクリーニングし、疑うべきものにフラグを立てる
DIFF_OUTLIER：付与されたサイズラベルに対して差分行数が外れ値REVERT_CANDIDATE：revertや打ち消しに見える変更NO_RATIONALE_COMMENT：判定根拠のコメントがPRに残っていない
- フラグの立ったPRだけを、人がサイズ定義と目視で照合する
- 照合結果をissueにコメントで記録する。全件のチェックリストもissueに残し、全件から候補に絞った経路を辿れるようにしておく
設計上のポイントは2つあります。
行数で判定はしないが、行数は検知に使う。 サイズラベルは差分行数ではなく影響範囲で決めています（1行の決済ロジック変更はXSではない）。一方で「XSなのに600行消えている」という乖離は見直す価値のあるサインです。判定に使っていない指標を検知に使うことで、AIの判定を同じ物差しで確かめる構造を避けられます。
人が目視する量をゼロにはせず、絞る。 全件を人が見る運用は続きませんし、検証まで自動化すると同じ仕組みを同じ仕組みで確かめることになります。全件は機械が見て、怪しいものだけ人が見る二段構えにしています。
このバックテストは、サーバーサイドとモバイルのそれぞれで月1回の頻度で定期的に実施しています。（この仕組みを推進してくれているのは tossy で、詳細は近日テックブログに書いてくれると思います）
おわりに
この半年で変えたのは次の3点でした。
- 実装言語の壁が下がったので、職能を越境して設計と実装を進められるようにした
- 作る速度が上がったぶん、届ける速度（リリース間隔）も上げた
- 自動でマージするなら、後から妥当性を検証できる形をセットで用意した
ツールの使い方よりも、チームの分け方・リリースの刻み方・自動化した判断をどう検証し続けるかといったプロセス側の設計のほうが効いている、というのが現時点の実感です。まだ途中なので、越境の範囲も自動マージの対象サイズも広げていきます。
