本番が燃えている。でもマージできない。
土曜日の昼下がり。本番環境のバッチ処理が80時間以上ハングしていた。
原因はわかっている。BigQueryの job.result() にタイムアウトが設定されていない。BQ側でジョブが異常終了すると、Pythonプロセスが永遠にレスポンスを待ち続ける。Cloud Runは「RUNNING」のまま、ログも出ない、エラーも出ない。ただ電気代だけが燃えていく。
修正はClaude Codeと一緒に30分で終わった。
# Before: タイムアウトなし = 無限待ち
job = self.client.query(query, job_config=job_config)
result = list(job.result())
# After: 30分タイムアウト + リトライ
for attempt in range(max_retries + 1):
job = self.client.query(query, job_config=job_config)
try:
result = list(job.result(timeout=timeout))
break
except concurrent.futures.TimeoutError:
job.cancel()
if attempt < max_retries:
continue
raise BigQueryClientError(...)環境変数で調整可能にして、既存インターフェースは変えない。影響範囲は1ファイルだけ。PRを作成した。CIも通った。
あとはマージするだけ——なのに、マージできない。
「人間の承認」という壁
GitHubのブランチ保護ルール。「At least 1 approving review is required by reviewers with write access.」
write権限を持つcollaboratorは自分だけ。自分のPRを自分でApproveすることはGitHubが許さない。管理者権限でのオーバーライドもブロック。mainへの直接pushも拒否。
週明けにチームメンバーが出勤してApproveボタンを押すまで、このPRはマージできない。
本番は燃え続けている。コードは完成している。でも「人間の承認」がないと、何も進まない。
その「人間のレビュー」は何を見るのか
ここで、ふと考えた。
週明けに来るレビュアーは、このPRの何を見るのだろう。
concurrent.futures.TimeoutErrorのハンドリングが正しいか？job.cancel()の例外処理が適切か？- リトライロジックに競合状態がないか？
- 既存のメトリクス収集やログ出力との整合性は取れているか？
正直に言う。自分にはこのレベルのコードレビューは難しい。
PMでありデザイナーであり、インフラも触るしコンサルもやる。12年間一人で全領域をやってきた。コードは書ける。だが「このPythonコードのスレッドセーフティを保証できるか」と聞かれたら、自信を持ってYesとは言えない。
一方、このコードを書いたClaude Codeは——
- 既存コードのシングルトンパターン、ラベルマージロジック、メトリクス収集の仕組みを全部読んだ上で
- 既存インターフェースを一切変えずにtimeout+リトライを追加し
BigQueryClientErrorの既存のコンストラクタ仕様に合わせてエラーを投げ- 環境変数でチューニング可能にした
このコードを「レビュー」できる人間が、チームに何人いるだろう？
「そのへんのエンジニア」の話
誤解のないように書いておく。AIそのものを開発しているエンジニア——大規模言語モデルを訓練し、推論パイプラインを最適化し、GPU上のメモリ管理を手書きするような人たち——は別だ。彼らは間違いなくAIの上位にいる。
だが、世の中のエンジニアの大半は、そういう仕事をしていない。
- APIを叩いてデータを変換してDBに入れる
- フレームワークの上にCRUDを書く
- 既存コードにパラメータを追加する
- CI/CDパイプラインを設定する
こういう「普通のソフトウェア開発」において、Claude Codeはもう普通のエンジニアより正確で、速くて、既存コードとの整合性に注意を払う。
今回の修正を人間のエンジニアに依頼していたら、こうなる。
- Slackで状況を説明する（15分）
- エンジニアがコードベースを読む（30分〜1時間）
- 修正方針を相談する（15分）
- 実装する（30分）
- PRを作る（10分）
- 別のエンジニアがレビューする（翌日）
- 修正→再レビュー→マージ（さらに翌日）
Claude Codeなら、1から5まで30分。しかもコードベースの理解は人間より正確だった。既存のエラーハンドリングパターン、メトリクス収集の仕組みまで把握した上で書いている。
信頼の構造がズレている
今の開発プロセスは「人間がコードを書き、別の人間がレビューする」という前提で設計されている。
- ブランチ保護ルール → 人間のApproveが必要
- PRテンプレート → 人間が読むことを想定
- CIチェック → 人間が確認することを想定
だが、コードを書いているのがAIで、そのAIの出力品質が平均的なエンジニアを超えているなら、「人間の承認」は品質ゲートとして機能しているのか？
むしろ逆だ。
人間のレビュアーが見落としたバグを、Claude Codeは最初から作らない。人間のレビュアーが「LGTM」と5秒で承認するPRの中に、Claude Codeなら指摘するはずの問題が埋もれている。
信頼すべき相手が逆転しているのに、プロセスだけが昔のまま残っている。
では、どうするのか
「人間のレビューを廃止しろ」と言いたいわけではない。
だが、少なくとも以下は考えるべきだ。
AIが書いたコードに対する承認プロセスを分けるべき。
人間が書いたコードと、AIが書いたコードでは、見るべきポイントが違う。AIが書いたコードのレビューは「意図通りか」「ビジネスロジックが正しいか」に集中すればいい。構文エラーやパターン逸脱はAIの方が少ない。
「一人チーム」向けのブランチ保護ルールが必要。
collaboratorが一人しかいないリポジトリに、チーム向けのレビュー必須ルールを強制するのは設計ミスだ。GitHubはここを改善すべきだろう。
AI Reviewerを正式なレビュアーとして認めるべき。
Claude Code GitHub Appがインストールされていれば、AIがPRをレビューしてApproveできる。技術的にはもう可能だ。あとは組織がそれを「正式なレビュー」として認めるかどうかの問題にすぎない。
これが2026年の現実だ
土曜日の午後。本番が燃えている。コードは30分で書けた。でもマージには、月曜日まで待たなければならない。
なぜなら、「人間の承認」が必要だから。
その人間は、このコードをClaude Code以上の精度でレビューできるのか？
たぶん、できない。でもルールがそうなっているから、待つしかない。
コードは30分で直せる。マージに3日かかる。
ソフトウェア開発のボトルネックは、もうコードじゃない。人間だ。