Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
AIレビュー時代に必要なのは、SLOで引く撤退ライン
Search
nobuoooo
August 26, 2026
Technology
170
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AIレビュー時代に必要なのは、SLOで引く撤退ライン
nobuoooo
August 26, 2026
More Decks by nobuoooo
See All by nobuoooo
「すごい会議」で 振り返りが "変えることを宣言する場"になった話
nobuoooo
0
150
エンジニアよ痛みを知れ
nobuoooo
0
530
新規学習のハードルを下げる方法とは?/ How to Make Learning Something New Easier?
nobuoooo
1
350
チームにとって最適なスキルアップ施策とは何か/what-is-the-best-skill-up-approach-for-team
nobuoooo
0
410
1つのHowに固執しない 場面に応じた最適な選択とは?
nobuoooo
0
48
Other Decks in Technology
See All in Technology
山手線を徒歩で一周してわかった、 位置情報アプリは「足」が最強のデバッガー
hinakko
0
150
GoCon2026 - Open Source, Open World
sanposhiho
4
4.3k
技術的負債から考える、AI時代のエンジニアリング投資 — ビズリーチの技術的負債と向き合った経験から、変更し続けられるソフトウェアを考える/ technical-debt-con2026
visional_engineering_and_design
2
1.6k
安心して変更できるWebフロントエンドの作り方
pirosikick
4
2.2k
TinyGo 開発サイクルを高速化する:Go で作るエミュレータ入門
zozotech
PRO
1
720
The Agent Builder Loop from Daily Work to OSS
minorun365
PRO
3
190
AI 時代のスタートアップエコシステ厶から考究する技術的負債との向き合い方
m3m0r7
PRO
2
1.5k
2026-09-09 【sigma_ucj#1】Sigma を IaC 管理したい! / IaC for Sigma
civitaspo
0
130
AI時代、データエンジニアが一番おもろい
genshun9
0
560
Genieを崇めよ
kameitomohiro
0
120
SQL文一行も書けない人事がCortexもろもろを使って人事業務を楽にしてみる
ponponmikankan
1
240
LTのテーマ どうきめてる?〜5つの型と私のやり方〜
yama3133
1
100
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
900
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Done Done
chrislema
186
16k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
720
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Ruling the World: When Life Gets Gamed
codingconduct
0
330
Unsuck your backbone
ammeep
672
58k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
HDC tutorial
michielstock
2
870
Raft: Consensus for Rubyists
vanstee
141
7.7k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.3k
Transcript
AI CODE REVIEW × SLO AIレビュー時代に必要なのは、 SLOで引く撤退ライン D-Plus Tokyo #26「AI時代にどう決める?スピードと質を両立する意思決定」
2026.08.26
INTRODUCTION 土橋 展之 Nobuyuki Tsuchihashi 株式会社ビットエー ourlyカンパニー バックエンドエンジニア インターン時代から ourly
に参画 Ruby / Rails, AWS を業務で扱う #サウナ #シーシャ X: @ourly_nobuo #サッカー観戦 #ドライブ
結論 今日の結論 レビューのボトルネックは、SLOで外せる。 スピードと質は、トレードオフではない。 ※ まだ思考実験です。導入も、運用の設計もこれからです。
問い プロダクトの価値を高める道は、2つある 道 A 道 B 1つあたりのアウトカムを上げる 大量に作って、早く出す じっくり作り込んで、1つの当たりを大きくする 数を出して、当たりを引く回数を増やす
今日は、道 B を選べるようになったあとの話をします。
現状 ソフトウェア開発は、一品生産から大量生産へ これまで いま 毎回、違うものを1つずつ作る 違うものを、大量に作れる 車輪の再発明を避けるため Claude Code などの生成AI
生成AIの進化で、ソフトウェアでも大量のアウトプットが出せるようになった。
現状 出せる量は増えたのに、レビューは人間が全部見ている 人間のレビュー 捌けた分だけ進む 大量に出てくる PR ここが詰まる AIにもレビューさせている。それでも最後は人間が全部見るので、PRを捌き切れない。
製造業に学ぶ 大量生産の現場は、全部を検査していない 全数検査 抜き取り検査 全部を人が見る 決めた割合だけ見る 量が増えると、成り立たない 実際の大量生産の現場はこちら 全部を見るのは、量が増えた時点で無理になる。だから一部だけ見て、あとは出荷する。
製 造 業 に 学 ぶ · S LO と
は 出荷したあとの結果で、ラインを止めるかを決める 不良の発生確率は 0.02% まで許容する(10万個 出荷して 20個) この「0.02%まで」が SLO = Service Level Objective どこまでの失敗を許すかを、先に確率で決めておくもの 不良の発生確率 0.02% ─ 許容ライン内 不良の発生確率 0.03% ─ 許容ラインを超えた ▶ ベルトは動き続ける ▪ ベルトを止める そのまま出荷を続ける 出荷を止めて、原因を直す 検査で止めているのではない。出したあとの不良の発生確率で、ラインを止めるかを決めている。
転用 ソフトウェアに持ち込むための前提は2つ 01 出したあとに、問題を検知できること – BE:立ち上げ時からテストを書いており、カバレッジは 80〜90% 程度 – FE:途中から着手のためカバレッジは低いが、手動テストで一部カバー
– Sentry / Datadog / CloudWatch でエラー検知と監視を導入済み 02 問題が起きても、素早く直せること – 生成AIの進化で、本番で起きた問題の修正も速くなった ※ 障害が起きることが許されないサービスは、この話の対象外です。
転用 同じ構造を、レビュープロセスに持ち込む 製造業 ソフトウェア開発 抜き取り検査 AIレビュー + 人間は一部だけ見る 出荷後に見つかる不良 本番で起きる障害
ラインを止めて、原因を直す AIレビューだけの運用を止めて、人間が前工程に入る 止める基準は、一定期間に許容する障害の発生確率。これが SLO にあたる。
転用 SLOの具体的な仕組み 一定の期間に許容する障害の発生確率を決めておく。その残りを追いかける。 100% り残の量容許 割らなければ、今の比重を維持 50% SLO = 撤退ライン
0% 割った時点で、人間が前工程に入る 一定の計測期間 ──▶
転用 止めるのは、後退ではない SLOの閾値を 超える 人間が前工程に 入る レビュープロセスを 改善する また人間を 外す
1周ごとに、AIへ任せられる範囲が広がる 緑=AIに任せる範囲 1周目 2周目 3周目 止めたタイミングが、レビュープロセスを改善するタイミング。人間は入りっぱなしにならない。
まとめ 今日の結論(再掲) レビューのボトルネックは、SLOで外せる。 スピードと質は、トレードオフではない。
補足 ここまでは、まだ思考実験です 抜き取る割合は、どう決めるの 障害の発生確率を、何を分母に 何を改善すれば「また任せられ が妥当か して測るか る」と言えるか まだ導入していません。この3つを懇親会で議論させてください。 X:
@ourly_nobuo