異動でメンバーが減ったチームが、企画・レビュー・監視・振り返りという4つの定常業務をAIとGitHub Actionsに任せ直した設計と、その前後の数値を追う。
「AIに全部を任せる」のではなく「検知・通知・下ごしらえはAI、最終判断は人間」に線を引くという設計原則と、一人〜少人数の運用にもそのまま応用できる4つの自動化の型。
ZOZOのWEAR開発部Webブロックが公開した事例が具体的だった。異動でメンバーが減ったチームで、日々こなしていたはずの4つの業務が同時に苦しくなっていた、という話。
特別なトラブルが起きたわけではなく、どれも「これまで誰かが時間を割いて回していた」タスクだった。人が減ればその時間が消える——という、規模を問わずどの個人開発・小規模チームにも起こりうる話として読める。
出典: ZOZO TECH BLOG「チームの人数が減っても仕事を回す」（2026年9月公開）。以下、記事内の設計と数値を要約・翻訳して紹介する。
1つ目の解決策は、企画のたたき台をAIに出させる仕組みだった。ポイントは、ただAIに「アイデアちょうだい」と聞くのではなく、過去の採用・不採用の経緯まで読ませたうえで、9つの基準で自己採点させているところにある。
Confluence上に、チーム共通のコンテキストとテーマ別のコンテキストを蓄積。AIに丸投げするのではなく、「このチームがこれまで何を試して何を見送ったか」を先に読ませる。
テーマとの接続性・対象規模・データの根拠・測定可能性・自社で解決可能か、といった観点で加点方式の採点をAI自身にやらせ、上位5件だけを人間に提案する。「思いつきの羅列」を人間が選別する手前で、AI側に一段フィルタをかけている。
不採用になったアイデアの「なぜ見送ったか」もフィードバックとして与える。同じ質の低い提案を繰り返させないための、地味だが効く仕組み。
実際に採用された23個のアイデアのうち、8個がAIの提案だった。約35%が「AIが先に見つけていたもの」に置き換わったということで、思いつきの生成ではなく、蓄積されたコンテキストに基づく採点付きの提案だからこそ現場で採用に耐えている。
2つ目と3つ目の課題は、どちらもPRレビューまわり。ここは1つの仕組みで解決せず、放置の検知と承認の重さの調整を別レイヤーとして切り分けているのが読みどころ。
GitHub Actionsを平日10・12・14・16・18時の5回動かし、GitHubのタイムラインAPIでレビュー依頼が出た時刻を追跡。依頼から3時間以上反応がなければ、担当者へメンションで通知する。人間の記憶や善意に頼らず、機械的に「置き去り」を検知する設計。
すべてのPRに同じ重さのレビューを課すと、レビュアー側の負荷が積み上がる。そこでルールベースの判定とAIによるリスク評価を組み合わせ、軽微な変更はApprove 1件、リスクが高い変更はApprove 2件と動的に必要数を変える。依存パッケージの更新（Renovate経由）はAIが自動でApproveし、AIコードレビューの重要度判定で問題なしと出た変更もAIが承認する。
ただし、レビュー基準そのものを定義しているファイル（.claude/配下）の変更だけは、AIではなく人間2名のApproveを必須にしている。「基準を自動化する仕組み自体」は自動化の対象から外す、という線引きが具体的で参考になる。
成果: PRレビュー着手までのリードタイムが、30時間超だったものが20時間以内に収束した。
朝会前に3つの監視ツールを順番に開いて確認する、という作業自体が時間を食っていた。ここでは各ツールに「異常とみなす閾値」を先に決めておき、AIに並列でチェックさせてから、1本の統合レポートに集約している。
それぞれの検知結果は、直近のリリース時刻と突き合わせて「関連しそうなPR」まで自動で候補に挙げ、1つのSlackメッセージにまとめて朝会に投げる。人間がやるのは3画面を見比べることではなく、絞り込まれた候補を見て最終判断することだけになる。
成果: 朝会のエラー確認にかかる時間が、1時間からおよそ20分（約67%減）に短縮された。
4つの施策に共通しているのは、AIに意思決定そのものを渡していない点。渡しているのは、検知・通知・スコアリング・複数ソースの集約という、人間がやると時間がかかるが判断の難易度は高くない工程だけで、採否や最終承認は人間に残している。
チームの規模が変わっても、日々の定常業務にかかる時間を圧縮する考え方はそのまま持ち出せる。特に一人運用の個人開発では、レビュー相手がいない代わりに「自分が忘れる」ことが放置の主因になりやすい。締切ルールを自分自身に適用する仕組みとして応用できそうだ。