ロボットのための工場に灯りは要らない

1. ロボットのための⼯場に 灯りは要らない
2. 今回のテーマ：コードレビュー > ソフトウェア開発者がお互いのコードを検査し、 合意された⼀連の⼿順を満たしているかを確かめる プロセスです。 (出典： Looks Good To Me - Adrienne Braganza)
3. コードレビューは儀式だ
4. 儀式について https://kobun.weblio.jp/content/%E5%84%80%E5%BC%8F
5. コードレビューは儀式だ 何故なら妨害してはならないからだ
6. 儀式の妨害について ⽇本での整理 - 刑法188条2項（説教等妨害） - 刑法188条1項（礼拝所不敬） - 軽犯罪法1条24号（公私の儀式妨害）
7. 妨害されたコードレビュー Ghostty(Mitchell Hashimoto)の事例 OSSメンテナの憂鬱 ―― “AI Slop”がもたらす疲弊 https://findy-code.io/media/articles/modoku20260206-yusuktan
8. ”AIを使った低労⼒のコンテンツを助ける義務はない” GhosttyにおけるAI usage policy https://github.com/ghostty-org/ghostty/pull/10412
9. AI産のPRをAI Slop(⽣ゴミ)として扱う例 https://x.com/jarredsumner/status/2005566445808239030
10. ⽣ゴミによる実害 https://x.com/yusukebe/status/2020472189363831097
11. ”儀式の妨害”を防ぐ機能 2026/02 GitHubがPull Requestへのアクセス制御を追加 New repository settings for configuring pull request access https://github.blog/changelog/2026-02-13-new-repository-settings-for-configuring-pull-request-access/
12. 儀式の妨害をするのならば、 AIによる実装は不要なのではないか
13. AIによる実装は避けられない https://x.com/onoyamayoichi/status/2028968845407600867
14. Vibe Codingの転換点 https://x.com/karpathy/status/2026731645169185220 (和訳) > (2026年)2⽉以前は基本的に機能して いなかったのに、それ以降は基本的に 機能しています。モデルの品質、⻑期的 な⼀貫性、そして粘り強さが⼤幅に向 上し、⼤規模で⻑時間のタスクを⼒強 くこなすことができます。 Andrej Karpathy Vibe Codingの提唱者
15. 転換点とは何か https://x.com/karpathy/status/2026731645169185220 Simon Willison Djangoの共同開発者 (和訳) > 2025年11 ⽉の GPT-5.2 と Opus 4.5 は、 本当に転換点を表しているように感じます。
16. 参考：ベンチマーク(SWE-bench Verified) https://www.anthropic.com/news/3-5-models-and-computer-use https://www.anthropic.com/news/claude-opus-4-5 https://openai.com/ja-JP/index/introducing-gpt-5-2/ 2024/10 SWE-bench Verified：49% 2025/11 SWE-bench Verified：80%
17. AIが実装するのならば、 コードレビューは不要なのではないか
18. 儀式の⽋席理由 https://x.com/rui314/status/2029487243015213166
19. これから紹介する記事について - boris tane「The Software Development Lifecycle Is Dead」 - https://boristane.com/blog/the-software-development-lifecycle-is-dead/ - 3⾏で - AI AgentはSDLCを⾼速化しない代わりに、⼯程を崩壊させた - ”コードレビューは諦めてください” - 今後、必要なスキルは⽂脈(コンテキスト)と可観測性
20. Software Development Lifecycle(SDLC) の崩壊 The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/ 「従来のSDLC」の⼯程 エージェント前提のSDLC
21. 「従来のSDLC」の⼯程 独⾃の道具、独⾃の儀式 - 要件定義 - →設計 - →実装 - →テスト - →コードレビュー - →デプロイメント - →監視 The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
22. エージェント前提のSDLC どの⼯程が崩壊するか - 実装‧テスト‧デプロイが 1つの⼯程になった - エージェントの動き⽅を 考慮すると、これら3つの⼯程 を分離する必要性がない The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
23. 崩壊した⼯程 「従来のSDLC」の⼯程 - 要件定義 - →設計 - →実装 - →テスト - →コードレビュー - →デプロイメント - →監視 The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
24. コードレビューが存在していない 崩壊後の⼯程 - 要件定義 →「Intent」 - →設計 →「Agent」 - →実装 - →テスト - →コードレビュー →「- 」 - →デプロイメント - →監視 →「Does It Work?」 The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
25. コードレビューが存在していない The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
26. Code review: give it up (コードレビューは諦めてください)
27. コードレビューは諦めてください Pull Requestのない世界 神聖な儀式の順守 The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
28. 神聖な儀式の順守 ”この図は存在するべきではありません。” - 儀式を機械へ押し付けると滞留する - Agentの速度は500PR/day - チームのレビュー能⼒は10PR/day - 儀式の⾒直し案 - レビューをコード⽣成の⼀部とする - Agentが⾃⾝の作業を検証する - 敵対的なAgentにレビューさせる The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
29. Pull Requestのない世界 引継ぎと待機が取り除かれたサイクル - エージェントがmainへcommit - ⾃動化された以下のすべてが 合格すれば、⾃動リリース - Check,Test,Type,Security,Diff - 何か問題があれば、Agentが修正 - 本当に⽴ち⾏かない場合にのみ、 ⼈間が介⼊ The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
30. boris tane⽒の想定する姿 The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
31. 意図、構築、観察 次の3つだけがループされる - Intent：「意図」と「⽂脈」を エージェントに伝える - ⽂脈(Context)の質に⽐例する - Build： これまで⼈間が⼿を 動かしていたプロセス - Observe：実装されたものを観測 - セーフティネット The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
32. AIが実装するのならば、 コードレビューは不要なのではないか
33. コードレビューという儀式の必要性について ”Pull Requestは廃⽌されるべきである” - AIコーディングと、OSSコミュニティが同じ結論に達した - ⽂脈は違えど”AIの書いたコードのレビューは避けるべき”とい う点で同意している - > AIを使った低労⼒のコンテンツを助ける義務はない - > コードレビューは諦めてください - とはいえ、開発者としては「コードレビュー」という伝統のあ る儀式を諦めることに、抵抗があるのは事実
34. 儀式を取り除いた例：strongDM社 How StrongDM’s AI team build serious software without even looking at the code https://simonwillison.net/2026/Feb/7/software-factory/ > In rule form: ▪ Code must not be written by humans ▪ Code must not be reviewed by humans — - コードは⼈間が書いてはならない - コードは⼈間がレビューしてはならない
35. strongDM社が構築した「ソフトウェア⼯場」 How StrongDM’s AI team build serious software without even looking at the code https://simonwillison.net/2026/Feb/7/software-factory/ > We built a Software Factory: non-interactive development where specs + scenarios drive agents that write code, run harnesses, and converge without human review. [...] — 私たちはソフトウェアファクトリーを 構築しました。これは、仕様とシナリ オに基づいてエージェントがコードを 記述し、ハーネスを実⾏し、⼈間によ るレビューなしで収束する⾮対話型開 発です。
36. 「⾃動補完」から「Dark Software Factory」への道のり レベル0：GitHub CopilotやChatGPT からの コピー&貼り付け レベル1：⾮重要箇所をAgentが書き、 ⼈間の完全なレビュー レベル2：Agentとペアプログラミングし、 すべての⾏をレビュー レベル3：コードをほぼAgentが⽣成し、 ⼈間の担当者がレビュー レベル4：⼈間がEMとなり、Agentが実際の 作業を⾏う レベル5：仕様をソフトウェアに変換する ブラックボックス = Dark Software Factory The Five Levels: from Spicy Autocomplete to the Dark Factory https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/
37. ダーク‧ソフトウェア‧ファクトリー The Five Levels: from Spicy Autocomplete to the Dark Factory https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/ Dark Software Factory = 従来のソフトウェア開発プロセスを⽤い ず、仕様をソフトウェアに変換するブラックボックス。
38. strongDM社のDigital Twin Universe Agentへ振る舞いをフィードバックさせる、SaaSのデジタルツイン Software Factories And The Agentic Moment https://factory.strongdm.ai/
39. ”暗い工場”について
40. なぜソフトウェア⼯場が”暗い”のか？ 広がる暗闇工場＝ダークファクトリー。工場は無人化されて、人はいなくなる https://tamakino.hatenablog.com/entry/2024/09/10/080000 Dark Software Factoryは無⼈⼯場である「Dark Factory」に由来する - 鞍⼭鉱業(中国)：鉄鉱⽯の選鉱⼯場 - ファナック：ロボット「の」完全無⼈⼯場 Robots, the maker of robots, in FANUC’s dark factory https://www.organizedergi.com/News/5493/robots-the-maker-of-robots-in-fanuc-s-dark-factory
41. Dark Factoryとは 忘備録　まじですか？？→ダークファクトリー https://note.com/izuku_idea/n/nb16f8d3ee446
42. 「監視‧例外対応中⼼」に置き換わる例を既に知っている The Software Development Lifecycle Is Dead https://boristane.com/blog/the-software-development-lifecycle-is-dead/
43. コードレビューという儀式は簡素化され ”暗い工場”の建設を目指すことになる
44. 儀式と儀礼の違い 儀式論 https://www.koubundou.co.jp/book/b251711.html 儀礼と儀式の違い【儀式論　第一章「儀礼と儀式」】 https://note.com/raru3105/n/nd1d7663209a4 > 儀礼とは⽂化を⽂化たらしめるもの、限り なく「⽂化」の同義語に近いものと考えるこ とができる。そして儀式とはそれを具象化す るもの、つまり⽂化の「核」になるものと ⾔ってもいいだろう。 出典：⼀条 真也 (2016) 『儀式論』 弘⽂堂
45. 儀式の簡素化 葬儀費用の平均は 131万6000円 : コロナ禍で密を避け家族葬にシフト https://www.nippon.com/ja/japan-data/h00774/ 儀礼(⽂化の核)を残せば、儀式⾃体は簡素化しても良い
46. 儀式を簡素化するためのスイスチーズモデル How to Kill the Code Review https://www.latent.space/p/reviews-dead AIのための承認ゲート - Layer 1:複数オプション の⽐較 - Layer2: 決定論的 ガードレール - Layer3: 受⼊基準の定義 - Layer4: 権限制御 - Layer5: 敵対的検証
47. ”暗い⼯場”に辿り着くまでに何が⾜りていないか なぜAIは組織を速くしないのか 令和の腑分け https://speakerdeck.com/sugino/nazeaihazu-zhi-wosu-kusinainoka-ling-he-nofu-fen-ke
48. アムダールの法則 儀式を簡素化しても、外部のボトルネックに律速される なぜAIは組織を速くしないのか 令和の腑分け https://speakerdeck.com/sugino/nazeaihazu-zhi-wosu-kusinainoka-ling-he-nofu-fen-ke
49. 同じ轍を踏まないように https://www.sentaku.co.jp/articles/view/25865 https://gigazine.net/news/20260311-china-ai-dark-factory/
50. まとめ - AIの実装速度において⼈間向けのプロセスはただのゲートになる - コードレビューという儀式を「⼀度」諦める - 決定論的チェックの強化‧コードレビューのシフトを進め て、本来の⽬的に基づく形に簡素化‧再構成される - 必然的に他のレビューもエージェント向けに再構築される - 「運転の完全⾃動化」から「ダークファクトリー」に向け、⾜り ない部分を埋めていく必要がある。 - ⾃分たちの役割について、これまで信じてきたプロセスの 「核」を⾒つけて作り直す - 結果的にボトルネックは他にあるかもしれない