■ 1. no look merge という問い
- AI 実装がもたらすレビュー待ち:
- AI に実装を任せると PR が次々にできあがる
- 開発者が差分を読み、指摘を返し、修正後のコードを再度読む必要がある
- 実装が速くなった分だけレビュー待ちの PR がたまる
- no look merge:
- 人がコードを読まずに PR をマージすること
- これを実現するために何が必要かが本稿の問い
■ 2. 品質の確認とマージの承認
- 品質確認の仕組みは大前提:
- no look merge でもコードの品質を確認する仕組みは必要
- 要求どおりの動作をテストで確かめる
- 設計やセキュリティのレビューを AI に任せる
- 指摘された問題の修正後に再検証する
- 未実施の検証や未解決の指摘が残る PR はマージしない
- 議論の前提条件:
- 人がレビューで確かめていたことを仕組みに任せられる水準に達していること
- Ship / Show / Ask:
- Rouan Wilsenach が2021年に公開した、生成 AI 普及前からある運用の提案
- Show では自動チェック通過後、他人のフィードバックを待たずにマージする
- チームはマージ後もコードについて意見を交わせる
- 意見交換と承認の分離:
- Show は人のレビューをなくす提案ではない
- コードへの意見交換とマージ前の承認を分ける例になる
- AI に品質確認を任せる場合も、確認通過でマージし、共有や意見交換は別に行う運用が考えられる
- 残る問い:
- 品質確認の仕組みも承認を待たない方法もあるのに人の承認待ちが残るなら、何が足りないのか
■ 3. 人の承認を外す条件
- 責任追及が生む読む理由:
- テストと AI レビュー通過後に読まずにマージし、後から不具合が見つかった場合を想定する
- 開発責任者が「なぜ読まなかったのか」と担当者を責めるなら、実質的に人が読むことを求めている
- 担当者には自分を守るためにコードを読む理由が残る
- レビュー精度を上げても、見逃し時に同じ責任を問われるなら読むことはやめられない
- 組織のコンセンサスが必要:
- 品質確認の結果を根拠に人の承認を外すには組織の合意が要る
- AI レビューの指摘を参考にすることへの賛成は、マージ判断の委任への同意を意味しない
- マージ判断を組織が引き受けていなければ、人が最終確認する運用は変わらない
- 見逃しを組織が引き受けること:
- 人がコードを読んでいても不具合は出る
- no look merge でも採用した確認方法で不具合を見逃す可能性は残る
- 合意した手順に従った結果の見逃しを組織が引き受けられるかが争点
- 事前に取り決めるべき事項:
- 不具合への対応を誰が担うか
- 見逃しの原因をどう調べ、テストやレビューをどう改善するか
- その責は個人ではなく組織のものとすること
- こう取り決めれば「やはり人が読むべきだった」で終わらずに済む
- レビューが担っていた他の役割:
- コードレビューで設計方針の相談や変更内容の共有も行っているなら、その継続方法も関わる
- 設計の相談を実装前に行う方法がある
- 変更内容をドキュメントや動作デモで共有する方法がある
- 設計判断自体を AI に任せるなら、どの方針まで委ねるかを合意する
- 仕事の移し先が決まっていなければ、品質確認を自動化してもレビューを続ける理由は残る
- 対象を限定した適用:
- すべての PR で一律に人の承認を外す必要はない
- 対象とする変更と、人の判断を求めて止める条件を開発責任者とメンバーで合意する
- 人の判断が必要な変更を見分けられれば、その場合だけ人が確認する運用にできる
■ 4. 実務のケース
- デザイナの PR を AI がレビュー:
- 業務で no look merge を取り入れている
- デザイナが Skill を使ってコードを変更し PR を出す運用を以前の記事で紹介した
- CI で TAKT のレビュー用ワークフローを実行し、その PR をレビューしている
- 人の確認が必要な箇所の明示:
- 自分の確認が必要な箇所をプロジェクトごとに決め、該当時は連絡が来る
- 開発者がコードを確認せずマージまで進むプロジェクトもある
- 合意の容易さ:
- 開発者、プロダクトマネージャ、デザイナの3人ですぐに合意できた
■ 5. TAKT でのマージ判断
- 最も合意しやすい例:
- TAKT は組織として自分一人なのでコンセンサスがもっとも取りやすい
- 判断を移譲した AI が PR をマージするかどうかを決めている
- 抜き打ちのサンプリング確認:
- マージ判断を任せた後も、変更の一部をサンプリングしてコード品質を確認する
- その確認も AI と相談しながら進める
- 自分でコードを見る場面:
- 自分でコードを眺める頻度はかなり少ない
- AI が機能そのものを実装できずに困ることはない
- 機能は正しくても抜け漏れでうまく動かない部分が増えたときにコードを見る
- 着目するのはディレクトリ構造やコードの依存関係
■ 6. 確かな手順を TAKT に任せる
- 次に必要なのは組織の合意:
- TAKT による品質確認が十分機能したら、次は確認結果を根拠にマージすることへの関係者の合意
- AI に任せられないとされる仕事の再検討:
- 作業と確認の手順は用意できているのに、運用上人の承認を待つことになっている仕事がありうる
- それを AI に任せるには、人の確認なしで進めてよい条件についてのコンセンサスが必要
- TAKT の概要:
- 作業の順番や判定結果に応じた分岐をワークフローに定義するツール
- AI のオペレーションを決定論的に制御する
- 問題発見時は修正に戻り、確認通過時は次へ進む流れを定義できる
- コード以外のオペレーションにも利用できる
- 導入方法:
npm install -g taktとtakt install claude-sdkで本体と既定の Claude Agent SDK を導入できる- 認証設定や使い始めの手順は TAKT の README で案内している
- 最初の一歩:
- 日々の業務で手順が定まっているオペレーションをひとつ TAKT に任せることを勧める