■ 1. コードを読まなくなった開発者の問い
- 発端となった出来事:
- AI が書いたコードを最近ほとんど読まなくなった
- 1 日に 13 本ほど PR が出るため、全部読むと人間の工程が詰まる
- チームのレビューと QA プロセスは残したまま、コードを読むことをやめた
- ある日、6 体の AI がレビューしていたのは自分の変更が 1 行も入っていないコードだった
- 指摘はどれももっともらしく、エラーも出ていなかった
- 根本の問い:
- コードを書かず読まなくても PR は毎日出ていく
- では自分はいったい何をしているのかという疑問が生じた
■ 2. 劇的に変わった開発プロセス
- AI エージェントへの移行:
- この 2 年で開発プロセスは劇的に変わった
- チケット、コード、レビュー、QA のほぼすべてを AI エージェントが担っている
- PR の量:
- 2026 年 9 月 24 日から 10 月 16 日までの 16 営業日で、main にマージした PR は 211 本
- 1 日 8 時間換算で約 36 分に 1 本のペース
- 1 本を 36 分で作るのではなく、複数本を並行で走らせている
- 2 年前は平均 1 日 1 本マージされれば仕事の早いエンジニアだった
- 適用範囲の注意:
- これは自分の担当範囲でのやり方にすぎない
- チームのレビューと QA があって成り立つため、どの現場にもそのまま勧めるものではない
■ 3. 4 つの skill による開発フロー
- 全体構成:
- チームのレビューの仕組みを使い、Claude Code の skill を組み合わせた流れ
- skill は AI に渡す作業手順書のようなもの
- レビューの一部には OpenAI の Codex も混ぜて相互レビューさせている
- 使う skill は ship / plan-checker / pr-checker / devqa の 4 つ
- ship:
- チケットからマージまでを一気に走らせる、最も働いている skill
- PdM が AI に書かせて Notion に積んだチケットから 1 枚拾って渡す
- 調査、実装、テストを経て PR を出す
- その後 CI の修正やレビュー指摘への返答を行い、通ればマージまで走る
- 細かい選択は事前に許可した範囲で自ら決め、最後に何を決めたかを報告する
- 仕様は勝手に決めさせない:
- 完了条件を満たせないときは途中でも PdM に戻して止まる
- 既存の設計とぶつかるときも同様に止まる
- 顧客から見える振る舞いに選択肢があり決め手がないときも止まる
- 迷ったら、PdM がその PR を見て「そう決めたつもりはない」と言いそうかで判断させる
- plan-checker:
- 難しいチケットでは実装の前に方針を立ててレビューする段階を挟む
- 対象は DB の migration、認証認可、パッケージ横断、やり方が何通りもあるもの等
- チームで作っている skill で、先に実装方針を書かせる
- コードを書いた後に前提が違ったと判明するのが最も高くつく
- 別のエージェントたちにセキュリティ、性能、既存への影響等を見てもらい、方針を直してから実装する
- pr-checker:
- コードレビューを担う、チームで育てている skill
- 変更を観点ごとに分けて並列にレビューさせる
- 出た指摘は別のエージェントに本当に起きるかを疑わせてから直す
- AI のレビューはたまに非常に自信満々に間違える
- 並列実行:
- 多いときは 10 並列で tmux の pane に区切って走らせている
■ 4. 人が関与する approve と本番前確認
- 同僚の approve:
- pr-checker は何周もレビューを回して指摘を潰してから PR を出す
- 211 本のうち 9 割ほどは同僚が approve している
- 同僚も程度の差はあれ下読みの大部分を AI に任せている
- approve の省略:
- 残り 1 割ほどは人の approve を省いている
- 対象はチームで決めた条件に当てはまり、契約上も問題がないもの
- さらに AI のレビューで影響が小さいと判定されたものに限る
- どこまで省くかはチームで今も話し合っている
- devqa:
- マージ後に QA 手順書のシナリオを開発環境で自動で流す
- 画面は使わず、エージェントとのやりとりやワークフローを一通り動かす
- バグがあれば起票まで行う
- 10 月上旬の 9 日間で、リリース前に 7 件のバグを拾った
- 本番前の最終確認:
- マージしてもすぐ本番には出さない
- リリース前に QA チームの最終確認を通してから出す
■ 5. コードを読まないもう 1 つの理由
- AI が書くコードの出来:
- 担当範囲では 2026 年 10 月時点の Claude Opus 5.5 が自分より良いコードを書くことが多い
- しかも速い
- 10 年以上コードを書いてきた身としては少し悔しい
- 残る責任:
- それでも何かあれば責任を取るのは自分である
- レビューの負担が同僚に寄っているのも事実
- せめて見送った指摘とその理由は PR に書くようにしている
■ 6. software factory と light / dark
- software factory:
- 2026 年の夏、海外で software factory という言葉がよく流れていた
- エージェントを並列に回し、作業を流し込み、レビューを通して出す仕組み
- 自チームも概ね似た動きになっている
- ただし電気を消しているのは自分の手元だけで、先には同僚の approve と QA チームの確認という明かりがある
- dark factory と lit factory:
- Addy Osmani は「Software Factories, Light and Dark」でこの区別を論じている
- 人がコードを読まず機械の検証だけで出荷する工場を dark factory と呼ぶ
- 製造業で人がいないため照明を消したまま動かす無人工場に由来する
- 人がコードを読み、設計やプロダクトの判断にも関わるほうを lit factory と呼ぶ
- Dex Horthy の失敗談:
- HumanLayer の Dex Horthy は「Why Software Factories Fail」で、2025 年夏に実際に電気を消した経験を書いた
- サイトが落ち、何か月も読んでいなかったコードを掘る羽目になることが何度も起きた
- 最後は手で書き直した
- 締めの助言の最後は "Read the dang code"（いいからコードを読め）であり、読んでいない身には耳が痛い
- 計画の前倒し:
- Horthy は計画を前倒しして人のレビューを安くすることも提案している
- これは plan-checker でやっていることに近く、コードを書く前の方針なら数ページで読める
- ただし Horthy はそれでコードを読まなくてよいとは言っていない
- そこから先は自分の判断で踏み込んでいる領域である
- 社内の意見:
- バックエンドチームでもレビューの下読みはほぼ AI に任せている
- それでも全自動化の話の際、一部の同僚からコードを読んで品質を確かめたいという声が出た
- その意見にも共感しており、どこまで人が読むかはまだ答えが出ていない
■ 7. 壊れたときの対処
- AI への質問攻め:
- 障害時は AI にログやコードを読ませて徹底的に質問する
- どこを通ったのか、状態をどこで持っているのかを問う
- その説明でほかの症状も全部辻褄が合うかを徹底的に確認する
- 具体例:
- ある経路を通したときだけツールの呼び出しが失敗する不具合があった
- AI はツールを 1 本ずつ試して、原因と回避策まで持ってきた
- その説明に穴がないかを確かめ、同僚の調査と突き合わせた
- 皆が「うちの子はこう言っています」と前置きして報告していたのが少し面白かった
- 質問できる理由:
- 1 行ずつ読まなくても、システムの形がなんとなく頭に入っているからだと考える
- その理解は Design Doc や障害のたびに見るログで自然と形成されている
■ 8. 手元の電気を消した代償
- worktree の事故:
- AI が worktree で編集したはずのファイルが、メインの作業ツリーに書き込まれていた
- commit は成功していたが、肝心のファイルが入っていなかった
- 気づいたのは 2 時間後にテストが落ちたときだった
- そのファイルが抜けた commit の上に、さらに 4 本の commit が積み上がっていた
- 冒頭のレビュー事故:
- 1 週間後、並列で走らせていた別のセッションがメインの作業ツリーのブランチを切り替えた
- レビュアー 3 体と検証役 3 体が、自分の変更が 1 行も入っていないコードを読んだ
- それでももっともらしい結果を返してきた
- 結局レビューは 1 周まるごとやり直しになった
- 教訓:
- どちらも差分をきちんと見ていればもっと早く気づけた
- その後の対策:
- 長い作業は最初から専用の worktree に入れる
- commit のたびに git show --stat を開き、ファイル名と行数を確認する
- 見るようになったのはコードではなく、AI が何を読み何を commit したかである
■ 9. 画面を自分で触る
- devqa と手動確認:
- devqa は速く、何回流しても結果がぶれにくいので手放せない
- 全部ではないが、気になるものは「確認完了」が並んだ後に自分でも触る
- 初期設定案内エージェントの例:
- ある機能の初期設定を案内するエージェントの最初の案は AI に任せた
- 社内で触ると、きちんと動いた
- しかし要望が全部入っていて、結局何をしてくれるエージェントなのかが分からなかった
- テストはもちろん全部通っていた
- 最終的に PdM が自分で触り、気持ちいいと思える形に作り直した
- どれを残すかは今も PdM と一緒に触りながら決めている
■ 10. 監督は味見をする
- 小島秀夫監督のたとえ:
- ポッドキャスト「コジ10」の ep.9 で、小島秀夫監督は自分を料理長にたとえていた
- 班ごとに作っている料理を味見し、最後は店に並べて順番に食べてみる
- 肉の後にまた肉が来たら魚に変える
- 自分の役割:
- 自分がやっている工程はこれに近い
- 作るのはうちの子（AI エージェント）で、自分は味見をしている
- おかしければ PdM と一緒に献立から考え直す
- 味見の今後:
- 味見の仕方はまだ手探りである
- PR に何を決めて何を確かめたかを残すことを当たり前にしたい
- 人の approve をどこまで省くかもチームで詰めている途中
- 変化と違和感:
- コードを読まなくなり、前より画面を触る時間が増えた
- 先ほども、AI が自信満々に出した料理を試食して手が止まった
- 配膳の流れは三つ星レストランのように滑らかで、見た目も綺麗だった
- それでも、お願いした料理はこういうものだったかという違和感が残った