人間が時間を使うべきところはどこか

コードを書く仕事から、レビューする仕事へ

この 1 年で、筆者は自分でコードを書くことがほとんどなくなりました。代わりに増えたのがレビューです。同僚の PR だけでなく、AI が書いた plan ファイルを読むことも多いそうです。AI でコードを書くのが簡単になり、PR の数もコードの行数も増えました。そのため、人間が同時にさばける仕事の量が、開発の速さの上限になっています。

AI の段階と、ボトルネックの移動

記事では、Simon Willison のブログや The Five Levels という記事を引用しています。生成されたコードはレビューが必要なので、ボトルネックは「どれだけ速くレビューできるか」になるという考えです。The Five Levels では、人間が差分をひたすら見る段階（Level 3）で頭打ちになる人が多いとされ、Level 4 では人間が spec を書き、計画をレビューする側に回るとされています。

プログラムに任せられるところは任せる

筆者は、人間も LLM も判断しなくてよいものは、プログラムで自動判定する方がよいと考えています。時間の価値は、人間が一番高く、次に LLM、機械が一番安いからです。筆者の職場では conftest（設定ファイルを検査するツール）を使い、レビューで毎回出る指摘をポリシーにしています。Claude Code チームの例では、Low リスクなら自動チェックが通れば人間の承認は不要、Medium は 1 人、High は 2 人と、変更のリスクで承認の数を変えています。

数字で見るポイント

• Claude Code チームの承認ルール：Low は承認なし（自動チェックのみ）、Medium は 1 人、High は 2 人
• チェックは 2 種類：テストや linter など、速くて安い「computational」と、AI レビューなど、意味は判断できるが遅くて結果がぶれる「inferential」
• インフラでは terraform plan や kubectl diff の差分が構造化されていて、リスク判定をプログラムで行える可能性がある

なぜ大事なのか

AI が多くのコードを書く今、人間のレビュー時間は開発全体の速さを決めます。すべてを人間が見るのは限界があります。何を機械に任せ、何を人間が見るかを決めることで、人間の時間を本当に大事な判断に使えるようになります。さらに、コードそのものより plan を読む方が効率的だという考えもあります。筆者の言葉を借りると、悪い 1 行のコードは 1 行の問題ですが、悪い plan の 1 行は何百行もの悪いコードにつながるからです。