Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AIにレビューを任せる仕組みと見えてきた次の課題
Search
uo
May 19, 2026
Technology
64
0
Share
AIにレビューを任せる仕組みと見えてきた次の課題
uo
May 19, 2026
More Decks by uo
See All by uo
実装計画を活用しAIの効果を最大化する
uo
1
62
gRPCでの効率的なAPI開発とテストの進め方
uo
2
490
Other Decks in Technology
See All in Technology
[みん強]AIの価値を最大化するデータ基盤戦略:Self-Service型Data Meshへの転換とAgentic AI Meshに向けた取り組み with Snowflake他
y_matsubara
1
170
インプロセスQAのための要因から捉えるプロジェクトリスクマネジメントnano #1 開発リソース効率状態への対処 #jasstnano
barus_qa
0
220
20260516_SecJAWS_Days
takuyay0ne
2
550
Claude Code / Codex / Kiro に AWS 権限を 渡すとき、何を設計すべきか
k_adachi_01
6
2k
GitHub Copilot CLI の Rubber Duck 機能を使ってコーディングの品質をあげよう #techbaton_findy
stefafafan
1
270
SDDで⾒える、AIコーディングの"内訳"
lycorptech_jp
PRO
0
150
Orchestration Development Workshopを半期実施して
lycorptech_jp
PRO
0
130
RubyでRuby拡張を書いたらRubyより35倍速になったってどういうこと??
kazuho
3
490
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
4.5k
その英語学習、AWSで代替できませんか?
suzutatsu
1
200
10サービス以上のメール到達率改善を地道に継続的に進めている話 / Continue to improve email delivery rates across multiple services
yamaguchitk333
6
2.3k
JaSSTに関わることで変わった人生観 #jasstnano
makky_tyuyan
0
170
Featured
See All Featured
Paper Plane
katiecoart
PRO
1
50k
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
450
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
210
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
360
Why Our Code Smells
bkeepers
PRO
340
58k
Six Lessons from altMBA
skipperchong
29
4.2k
Raft: Consensus for Rubyists
vanstee
141
7.4k
Embracing the Ebb and Flow
colly
88
5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Documentation Writing (for coders)
carmenintech
77
5.3k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
570
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.7k
Transcript
AIにレビューを任せる仕組みと 見えてきた次の課題 株式会社カウシェ / バックエンドエンジニア 魚住伸
カウシェでは約80%のPRをAIレビューだけでマージしています 今日お話しすること 1. AIレビューの仕組み 2. AIレビューとAIマージの壁 3. AIマージを取り入れた結果
AIレビューの仕組み Claude Code ActionでAIでのレビューを実行 多視点設計: コーディネーター + 並列サブエージェント シニアGoエンジニア (実装品質)
シニアアーキテクト (設計妥当性) コーディネーターが総合判定 変更対象ごとに専用のレビューワークフロー コード系: backend / front / platform 設計・仕様系: PRD / DesignDoc / proto → 各ワークフローに専用プロンプト + 専用ナレッジ
自己改善の仕組み 5つのエージェントが毎日深夜に動き、改善を行う エージェント 役割 やっていること measure 計測係 昨日のAIレビューを採点、APPROVE/REJECTを数字で記録 explore 探検係
リポジトリ・本番メトリクスを調査、異常を発見 improve 実行係 ルール・プロンプト・ワークフローを書き換えてPR化 reflect 司令塔 明日は何に集中するかの作戦 (strategy.md) を書く audit 監査役 数字が嘘ついてないか観察、勧告のみ (コード変更なし) → 詳細は弊社テックブログを参照ください: 全PRの83%をAIレビューだけでマージできるようにした
AIレビュー ≠ AIマージ AIレビュー単体でも価値がある 型不整合 / nil 参照 / 既知のセキュリティパターン
AIは人間が見逃しそうなことを拾ってくれる でも、AIマージ (人間レビュー無しで本番投入) は別の話 AIレビューは 「確率論」 で動いている 同じPRでも、セッションが違えば判断が異なる 100%信用できるとは言えない、AIにマージまで任せて大丈夫なのか?
アプリケーションの何を守るべきなのか
何を守るか? 軸は 「失敗してもリカバリーができるか」 AIが間違っても、戻しやすい・修正しやすい箇所ならAIに任せる。 守る (人間もレビューする) ユーザー影響: クリティカルな振る舞い / セキュリティ
/ データ整合性 技術構造: DBスキーマ / APIの定義 / 共有ライブラリ AIマージ OK = リカバリーしやすいもの 実装の詳細、コードの可読性 人間がコードを読むことが少なくなったので、可読性の重要度は以前より下がった 仮に技術負債としてたまっても、AIと後からリファクタ可能
任せた箇所での責任の保ち方 AIにマージまでは任せるが、最終的なリリース責任は人間にしている。 品質を守る仕組み CUJ (Critical User Journey)で人間が見るべき重要な導線を定義 → ECなら、トップ画面 →
商品閲覧 → 購入完了 API仕様ファースト + E2Eテスト → protoにAPI仕様を記載、記載された仕様をE2Eテストで確認するフロー すぐ戻せる仕組み Cloud Runの素早いロールバック ── リビジョンをすぐ戻せる AIにマージを任せる判断ができたのは、ここの仕組みがあることが大きい
AIマージの結果 AI導入前 現在 open → レビューまで 2時間 20分 レビュー →
マージまで 5時間 40分 合計 (cycle time) 7時間 1時間 → 約7倍の高速化 → 特に「レビュー待ち」(open → レビュー) が大幅短縮 ── AIが一次レビューをしてくれる効果
課題① 理解負債 (Comprehension Debt) AIが生成したコードの仕組みを、開発者が理解できない状態が増えている 知識共有のサイクルがなくなった 以前: PRレビュー = チームメンバーがコードを理解する場
今: 実装レビューをAIに任せた結果、このサイクルがなくなった 非対称性 設計のレビュー = 人間 → 設計レベルの知識共有は残る 実装のレビュー = AI → 実装の詳細は、担当した人以外は誰も知らない 実際に動いているコードを、どうすればもっと深く理解した状態を維持できるか、が 次の課題
課題② レビュー精度 AIがApproveしたPRでも3割は人間指摘あり → AIレビューはまだ完璧ではない 人間が拾っている指摘で一番多いのはドメイン知識 「このサービスは過去にこういう判断をした」 「このドメインではこの命名が一般的」 「この外部APIはこの順序で叩かないと整合性が崩れる」 →
プロンプトでドメイン知識を渡しているが、漏れることがある
まとめ 失敗してもリカバリーができる領域はAIにマージを任せている リカバリーしにくいものは人間も見る コード生成を任せた箇所の責任は人間に残す 次の課題 ① 理解負債 ② AIレビュー精度
ご清聴ありがとうございました