CheinTian / notes
Clipping · 10 分钟

コードを読まずにマージするために必要なこと

zenn.dev
#clippings#AI#agentic#code-review#code-review-agent#pull-request#human-in-the-loop#decision-rights#risk-based-approval#independent-verification#no-look-merge#ship-show-ask#organizational-consensus#TAKT#deterministic-scaffolding

📝 摘要

本文讨论「no look merge」——开发者完全不读代码就合并 AI 产出的 PR——究竟需要哪些前提。作者认为，仅把质量确认自动化（测试验证行为 + AI 做设计与安全评审、修正后重新验证、存在未执行验证或未解决指摘就不合并）并不足以移除人工审批，真正的障碍在于组织共识：如果漏检后开发负责人仍追究个人责任，那实际上等同于要求人继续读代码。文章引用 2021 年的 Ship / Show / Ask 模式说明「交换意见」与「合并前批准」可以分离，并给出两个实操案例（设计师生成的 PR 由 CI 中的 TAKT 评审工作流审查；TAKT 自身开发由 AI 决定是否合并），最后介绍 TAKT 这一确定性地控制 AI 操作的工作流引擎。

核心概念： no look merge 不是工具问题，而是责任分配问题——只有组织愿意以自动化验证结果为依据承担漏检后果，人的最终确认才能真正被移除。

关键技术栈 / 关键要点：

  1. 质量确认机制是前提 — 用测试确认行为符合要求、让 AI 承担设计与安全评审；指摘修正后需重新验证，未执行的验证与未解决的指摘都会阻止合并。
  2. Ship / Show / Ask — Show 模式在自动检查通过后不等他人反馈即合并，团队在合并后仍可讨论代码，从而把「就代码交换意见」与「合并前取得批准」解耦。
  3. 移除人工审批需要组织共识 — 若漏检仍按个人问责，开发者出于自保就会继续读代码；必须事先约定漏检责任归组织、由谁应对故障、如何调查原因并改进测试与评审。
  4. 评审其他角色的迁移 — 设计讨论前移到实现之前，变更内容用文档或可运行 demo 共享；若把设计判断也交给 AI，需就委托范围达成共识，否则仍会保留人力评审。
  5. 不做一刀切 — 由开发负责人与成员约定哪些变更适用 no look merge、什么情况下必须停下来等人判断，从而只在必要时人工确认。
  6. 实践案例 — 设计师用 Skill 改代码并提 PR，CI 运行 TAKT 评审工作流；作者按项目预定义需要自己确认的范围，该约定由开发、PM、设计师三人即可快速达成。
  7. TAKT 自身开发 — 单人组织最易达成共识，合并判断委托给 AI；作者偶尔抽样检查质量，关注点是目录结构与依赖关系，只有功能能跑但缺漏明显时才亲自读代码。
  8. TAKT 的定位 — 将步骤顺序与按判定结果的分支写成工作流，确定性地控制 AI 操作（评审发现问题就回到修正，通过则前进），同样适用于代码以外的操作；安装命令为 npm install -g takt 与 takt install claude-sdk。

关键结论 / 实践建议： 先挑一个日常已有明确步骤的操作交给 TAKT，再回头审视「以验证结果为据合并」这件事能否在组织内取得共识——技术上的验证可以被自动化，但接受验证结果的责任必须由组织显式承担。

251

101AI

[

Orchestration

](https://zenn.dev/topics/orchestration)[

Claude Code

](https://zenn.dev/topics/claudecode)[

Codex

](https://zenn.dev/topics/codex)[

TAKT

](https://zenn.dev/topics/takt)[

tech

](https://zenn.dev/tech-or-idea)

AI に実装を任せると PR が次々にできあがります。
その差分を開発者がひとつずつ読み、指摘を返して修正を待ち、修正後のコードをまた読む。
実装が速くなった分だけレビュー待ちの PR がたまっていきます。

人がコードを読まずに PR をマージする「no look merge」を実現するには何が必要でしょうか。

品質の確認とマージの承認

大前提として no look merge でもコードの品質を確認する仕組みは必要です。
たとえば要求どおりの動作をテストで確かめ、設計やセキュリティのレビューを AI に任せる方法があります。
指摘された問題を修正した後に再検証し、未実施の検証や未解決の指摘が残る PR はマージしない。
人がレビューで確かめていたことを仕組みに任せられる水準に達していることが、ここからの話の前提です。

こうした仕組みで品質を担保できれば、人がコードを読まずにマージできるのではないでしょうか。

人の承認を待たずに変更を取り込む運用は生成 AI が普及する前から提案されています。
Rouan Wilsenach が2021年に公開した Ship / Show / Ask の Show では、PR の自動チェックを通過したら他人のフィードバックを待たずにマージします。
チームはマージ後もコードについて意見を交わせます。

Show は人によるレビューをなくす提案ではありませんが、コードについて意見を交わすこととマージ前に承認を得ることを分ける例になります。
AI に品質確認を任せる場合にも、必要な確認を通過したらマージし、変更内容の共有や意見交換は別に行う運用が考えられます。

品質を確認する仕組みがあり、承認を待たずに進める方法もある。
それでも人の承認待ちが残るとしたら、何が足りないのでしょうか。

人の承認を外す条件

たとえば必要なテストと AI レビューを通過した PR を人がコードを読まずにマージし、後から不具合が見つかったとします。
このとき開発責任者が「なぜ不具合を起こしたのか」と担当者の責任を問うなら、実際には人が読むことを求めているのと同じです。
担当者にとっては自分を守るためにもコードを読む理由が残ります。
レビューの精度をさらに上げても、不具合を見逃したときに同じ責任を問われるなら、人がコードを読むことをやめられないでしょう。

つまり、品質確認の結果を根拠に人の承認を外すには、組織のコンセンサスが必要ということです。
AI レビューの指摘を参考にすることに賛成でも、マージ判断まで委ねることに同意しているとは限りません。
AI レビューを導入しても、その結果を根拠にマージする判断を組織が引き受けていなければ、人が最終確認する運用は変わりません。

人がコードを読んでいても不具合は出ます。
no look merge に移行した後も、採用した確認方法で不具合を見逃す可能性は残ります。
合意した手順に従った結果として見逃しが起きたとき、組織がその結果を引き受けられるのかが争点です。
不具合への対応を誰が担うか、見逃しの原因をどう調べてテストやレビューを改善するかまで話し合い、その責は個人にあらず、組織のものとする。
このように取り決めれば、「やはり人が読むべきだった」で終わらせずに済みます。

コードレビューで設計方針の相談や変更内容の共有も行っているなら、その役割をどう続けるかも関わってきます。
設計の相談を実装前に行い、変更内容をドキュメントや動作デモで共有する方法もあります。
設計の判断自体を AI に任せるなら、どの方針まで委ねるのかを合意することになるでしょう。
品質の確認を自動化できても、レビューで担っていた役割の移譲先が決まっていなければ、人力のレビューを継続することになります。

なお、すべての PR で一律に人の承認を外す必要もありません。
どの変更を no look merge の対象とし、どんな場合に人の判断を求めて止めるのかを開発責任者とメンバーで合意する方法もあります。
人の判断が必要な変更を見分けられるなら、その変更があるときだけ人が確認する運用にできます。

実務のケース

私の業務でも no look merge を取り入れています。
以前の 「なぜ Skill は使ってもらえないのか」 ではデザイナが Skill を使ってコードを変更して PR を出す運用を紹介しました。
CI で TAKT のレビュー用ワークフローを実行し、デザイナが出した PR をレビューしています。

私の確認が必要な箇所はプロジェクトごとに決めてあり、該当する場合は私に連絡が来ます。
開発者がコードを確認せずにマージまで進むプロジェクトもあります。
この運用については開発者である私、プロダクトマネージャ、デザイナの3人ですぐに合意できました。

TAKTでのマージ判断

もうひとつの例として、TAKT の開発も挙げます。

TAKT は組織としては私一人なのでコンセンサスがもっとも取りやすい例です。
私が判断を移譲した AI が PR をマージするかどうかを決めています。

マージの判断を任せた後も、たまに変更の一部をサンプリングしてコードの品質を抜き打ちで確認しています。
その確認も AI と相談しながら進めます。

自分でコードを眺めることもありますが頻度はかなり少ないです。
TAKT の開発で AI が機能そのものを実装できずに困ることは幸いありません。
機能自体は正しく実装されていても、抜け漏れがあってうまく動かない部分が多くなったときは自分でコードを見ます。
そのときに着目するのはディレクトリ構造やコードの依存関係です。

確かな手順を TAKT に任せる

TAKT による品質確認の仕組みが十分に機能するようになったら、次に必要なのは組織の合意です。
その確認結果を根拠にマージすることについて、関係者のコンセンサスが取れているかを考えてみるとよいでしょう。

AI に任せられないとされる仕事の中にも、作業と確認の手順は用意できていて、運用上は人の承認を待つことになっているものがあるかもしれません。
そのオペレーションを AI に任せるには、どの条件なら人の確認なしで進めてよいのかについてコンセンサスが必要です。

TAKT は作業の順番や判定結果に応じた分岐をワークフローに定義し、AI のオペレーションを決定論的に制御するツールです。
レビューで問題が見つかったら修正に戻り、確認を通過したら次へ進むといった流れを定義できます。
コード以外のオペレーションにも利用できます。

以下のコマンドで TAKT 本体と既定の Claude Agent SDK をインストールできます。

plaintext
npm install -g takt
takt install claude-sdk

認証設定や使い始めの手順は TAKT の README で案内しています。

まずは日々の業務で手順が定まっているオペレーションをひとつ TAKT に任せてみてください。

101

返回 Clippings