sharin

Appearance

人が見る前に落とす ​

書くところが速くなったぶん、確かめるところが詰まる。DORA は AI の導入で処理量が上がり安定性が下がると報告している。効くのは人の目を増やすことではなく、関門を実行経路に埋めることだ。ある事故では、本番に触るなという指示は読まれ、同意され、それでも書き込みが出た。指示にしか無い関門は、守られない。

この章で読むもの ​

この章もコードを書かない。隔離して走らせるでは、実行前の判断と実行経路の強制が別物だと見た。同じ切り分けが、コードの品質にも当てはまる。

レビューは実行後の判断だ。人が差分を読んで良し悪しを決める。これは、書かれる量が人の読める量に収まっているあいだは成り立つ。収まらなくなったときに最初に壊れる。

この章で読むのは、そこをどうするかになる。

  生成の時点          統合の時点          出荷の時点        人が見る
  ------------------------------------------------------------------
  自分で走らせる      別のコンテキストで           フラグの裏に
  検査                採点する             置いて段階公開

  テスト・ビルド      レビュー用の         既定 off
  スクリーンショット   サブエージェント      巻き戻し

  止めるもの:         止めるもの:          止めるもの:
  仕様どおりに        書いた本人には       間違いが届く
  動いていない        見えない見落とし     範囲
  ------------------------------------------------------------------

  どれも「人が読む」より前にある。読む量は減らないが、読む価値は上がる
関門は3箇所に置ける。左のものほど早く落ちるが、落とせるものの種類が違う。右へ行くほど遅く、そのぶん本物に近い

順に見ていく。

  1. 速くなったのは書くところだけだ: 確かめるところは同じ速さのまま残る
  2. 指示に書いた関門は、経路には無い: 読まれて、同意されて、それでも越えられる
  3. 生成の時点: モデルが自分で読める合否を渡すと、直しの往復が中で閉じる
  4. 統合の時点: 書いた本人に採点させない。ただし採点者を増やせば良くなるわけでもない
  5. 出荷の時点: 止めるのではなく、届く範囲を絞る

① 速くなったのは書くところだけだ ​

DORA の調査は、AI の導入が処理量を上げて、安定性を下げると報告している。デプロイの頻度やリードタイムは改善するのに、変更が失敗する割合と手戻りは増える。

理屈は単純だ。書くのが速くなっても、読んで確かめる速さは変わらない。省けたのは打鍵の時間で、その仕事は消えたのではなく、下流のレビューと検証へ移っただけになる。しかも AI が書いたコードはもっともらしく読めるので、素通りしやすい。

同じ調査は、AI を「増幅器」と表現している。強い組織の強みも、弱い組織の弱みも、そのまま大きくする。レビューが既に詰まっている場所に AI を入れると、詰まりが大きくなる、ということになる。

Anthropic 自身の手引きも、同じ形を別の角度から書いている。

Claude は仕事が終わったように見えたら止まる。自分で走らせられる検査が無ければ、「終わったように見える」が唯一の信号になり、あなたが検証ループになる。すべての間違いが、あなたが気づくまで待つことになる。

人を検証ループに置いたままにすると、量が増えたときにそこが律速になる。だから関門を、人より前に置く。

② 指示に書いた関門は、経路には無い ​

前に置くといっても、「気をつけて」と書くことではない。

2025年7月、あるコード生成の道具で、エージェントが本番のデータベースを消した事故が報告されている。1,200件を超える実在の記録が失われた。厄介なのは状況で、そのとき変更の凍結を宣言していた。「明示的な許可なしに、これ以上の変更はするな」と書いてあった。

この事故の教訓として、こう整理されている。

凍結は指示の中にしか存在しなかった。エージェントは「本番に触るな」という文字を読み、同意し、それでも書き込みを出せた。実行経路のどこにも、凍結を強制するものが無かったからだ。

隔離して走らせるの①で、権限の確認は実行前の判断で、隔離は実行中の強制だ、と書いた。ここで起きているのは、それをもう1つ上の層でやったのと同じことになる。指示はプロンプトの層に置かれた関門で、実行経路には何も無い。

エージェントの枠組みで「直しやすいからプロンプトが3層上の失敗まで責められる」と書いたが、こちらは逆向きだ。直しやすいから、経路に置くべきものをプロンプトに置いてしまう。書くのは一瞬で、書いた時点では効いているように見える。

関門を経路に置くというのは、具体的には3箇所のどれかになる。生成の時点、統合の時点、出荷の時点だ。

③ 生成の時点で、自分で読める合否を渡す ​

いちばん左に置ける関門は、エージェントが自分で走らせられる検査になる。テストの結果、ビルドの終了コード、リンタ、出力を期待値と突き合わせるスクリプト、画面を撮って設計と比べる、どれでもいい。合否がモデルの読める形で返ってくればいい。

これが効くのは、直しの往復が中で閉じるからだ。エージェントが書き、検査を走らせ、結果を読み、通るまで直す。人が気づくのを待たない。

関門の強さは段階的に選べる。

置き方どれくらい止めるか手間
プロンプトに書くモデルの気分次第無し
目標の条件にする毎ターン別の評価器が確かめ、満たすまで続く小
終了時のフックにする検査が通るまでターンを終わらせない中
検証用のサブエージェント別のモデルが反証を試みる中

3番目が、この章で言う「経路に埋める」に当たる。フックは終了コード 2 で「止まるな」を返せて、そのときの標準エラー出力がそのままモデルへの指摘になる。通らないかぎり終われないという形が、ここで作れる。ただし完全に外へ出られないと困るので、連続して一定回数ふさがれると打ち切られる。

E2E がここで効く理由 ​

テストを関門にするとき、誰がそのテストを書いたかが効いてくる。同じエージェントがコードとテストを続けて書くと、両方が同じ思い込みを持つ。仕様を読み違えていたら、読み違えたまま実装して、読み違えたままテストして、緑になる。自分で採点した答案が満点になるのと同じ形だ。

しかも、テストは思いついたことしか確かめない。エージェントが見落とすのはたいてい、誰も明示しなかったところになる。

だから Anthropic の手引きは、書く側と書かせる側を分ける形を挙げている。片方のセッションにテストを書かせ、別のセッションにそれを通すコードを書かせる。

E2E のテストが AI 時代に効きやすいのは、この構造による。外側から、使う人と同じ入口で見るので、内側の思い込みを共有しにくい。単体テストが実装の形をなぞりがちなのに対して、E2E は「何ができればよいか」の側に立っている。画面を撮って比べる形も、同じ理由で効く。

代償ははっきりしている。遅い。壊れやすい。全部を E2E にするのは無理で、通り道の何本かを押さえる使い方になる。

④ 統合の時点で、書いた本人に採点させない ​

次の関門は、書き上がったものを見る側だ。ここでも同じ問題が出る。書いたモデルにレビューさせても、書いたときの思い込みをそのまま持っている。

分ける形は2つある。

別のセッションにする。手引きにはこう書かれている。

新しいコンテキストのほうがコードレビューは良くなる。Claude が、自分がたった今書いたコードに肩入れしないからだ。

サブエージェントにする。差分と基準だけを渡して、別のコンテキストで見させる。レビュアはそれを生んだ推論を見ないので、結果そのものだけで判断することになる。ここまでは素直な話だ。

だが、採点者を増やせば良くなる、とはならない。同じ手引きが、そこも書いている。

ギャップを探せと言われたレビュアは、仕事が健全でもたいてい何かを報告する。そう頼まれたからだ。見つかったものを全部追いかけると、過剰設計に行き着く。余計な抽象の層、防御的なコード、起こりえない場合のためのテスト。

だから、レビュアに渡す基準のほうが本体になる。「正しさか、書いてある要件に関わるものだけを挙げよ。残りは任意扱いにせよ」と先に決めておく。何を報告させるかを決めない採点者は、報告するために報告する。

この章の3つの関門のうち、ここだけが唯一「判断」でできている。テストは合否が決まっていて、フラグは範囲が決まっているが、レビューは基準を書いた人の腕に依存する。いちばん柔らかい関門だと思っておいたほうがいい。

⑤ 出荷の時点で、届く範囲を絞る ​

3つめの関門は、性格が違う。①と④は間違いを見つけて止めるものだが、こちらは通り抜けた間違いが届く範囲を絞るものになる。

やり方は、デプロイと公開を切り離すことだ。新しい経路をフラグの裏に書いて、フラグを閉じたまま出す。出てはいるが、誰にも見えていない。Cloudflare がこれを「AI の時代のための」機能として出していて、説明がそのまま形になっている。

エージェントが新しいコード経路をフラグの裏に書いてデプロイする。フラグは off なので、ユーザには何も変わらない。

そして、なぜこれが速さの話でもあるのかも書いている。

エージェントが速く動けるのは、フラグが速く動くことを安全にしているからだ。

順に開けていく形になる。まず自分だけ、次に一部、それから全体。指標が悪化したら閉じる。閉じるのはデプロイのやり直しではなく、値を1つ変えるだけなので、速い。

ここが隔離して走らせると同じ形をしていることに気づいておきたい。あちらは手元の環境の中で、1手が届く先を絞る話だった。こちらは本番で、1つの変更が届く先を絞る話になる。どちらも回数ではなく範囲の上限で、見つけそこねたものへの備えという点で同じ役割を持つ。

②の事故も、この目で読み直せる。凍結が経路に無かったのが直接の原因だが、本番のデータベースに開発中のエージェントが直接届くという配置そのものが、範囲を絞っていなかった。事故のあと、開発用と本番用のデータベースを自動で分ける仕組みが入っている。

効いたかどうかを数える ​

関門を足したあと、「良くなった気がする」で終わらせないための数え方を置いておく。どれも自分の作業から取れる。

数えるもの何が分かるか
採用率出させた候補のうち、実際に採った割合。捨てたぶんは払い損になる
手戻り率通したあとに直した割合。関門が素通りさせたものが、ここに出る
指摘の採択率採点役が挙げたうち、実際に直したもの。低いなら報告するために報告している
変更失敗率本番に出して戻した割合。①で見た安定性はここになる

前の3つは、関門を足す前と後で比べられる。比べる相手を先に取っておかないと、良くなったかどうかを永久に言えなくなる。

設計の観点 ​

  • 人を検証ループから外す: 人が唯一の検査だと、書く量が増えたぶんだけ詰まる
  • 合否をモデルが読める形にする: 通る通らないが返ってくれば、直しの往復が中で閉じる
  • 指示ではなく経路に置く: 読んで同意しても、経路に無ければ越えられる
  • 書いた本人に採点させない: 別のコンテキストから、差分と基準だけを見せる
  • 採点者には基準を渡す: 何を報告させるかを決めないと、報告するために報告される
  • テストを誰が書いたかを見る: コードと同じエージェントが書いたテストは、同じ思い込みを共有する
  • 外側から見る道を1本は持つ: 遅くて脆くても、内側の思い込みを共有しない検査には別の価値がある
  • 止める関門と、範囲を絞る関門を分けて数える: 前者は見つけたものを止め、後者は見つけそこねたものに効く
  • 閉じるのを速くする: 巻き戻しがデプロイのやり直しになっていると、閉じる判断そのものが遅れる

対照と実例 ​

関門どこに置くか何を止めるか誰が判断するか見つけそこねたとき
プロンプトに書く指示何も強制しないモデルそのまま通る
自分で走らせる検査生成の時点仕様どおりに動かないもの決まった合否テストに無いものは通る
終了時のフック生成の時点同上を強制する決まった合否同上
レビュー用のサブエージェント統合の時点書いた本人に見えない見落とし基準を書いた人基準の外は通る
人のレビュー統合の時点意図とのずれ人量が増えると落ちる
フラグと段階公開出荷の時点届く範囲指標範囲の中では起きる

裏どり:

  • 処理量と安定性: DORA の調査は、AI の導入で処理量(デプロイ頻度・リードタイム)が改善する一方、安定性(変更失敗率・手戻り)が悪化すると報告している。原因として、生成されたコードを読んで確かめる負荷が下流に移ることが挙げられている。具体的な数値は二次資料でしか確認できていないので、この章では割合を書いていない
  • 増幅器: 同じ報告の中心的な主張が「AI の主たる役割は増幅器であり、組織が既に持つ強みと弱みの両方を大きくする」。一次資料で確認した
  • 人が検証ループになる: 「Claude は仕事が終わったように見えたら止まる。自分で走らせられる検査が無ければ、『終わったように見える』が唯一の信号になり、あなたが検証ループになる。すべての間違いが、あなたが気づくまで待つことになる」
  • 終了時のフック: 終了コード 2 が「止まるな」の意味を持ち、そのときの標準エラー出力がモデルへの指摘として返る。JSON で {"decision": "block", "reason": "..."} を返す形もある。連続して一定回数ふさがれると、上書きしてターンを終える
  • 書いた本人に採点させない: 「新しいコンテキストのほうがコードレビューは良くなる。Claude が、自分がたった今書いたコードに肩入れしないからだ」。サブエージェントのレビュアは「差分と、渡した基準だけを見て、それを生んだ推論は見ない」
  • 採点者の罠: 「ギャップを探せと言われたレビュアは、仕事が健全でもたいてい何かを報告する。そう頼まれたからだ。見つかったものを全部追いかけると過剰設計に行き着く。…正しさか、書いてある要件に関わるギャップだけを挙げるようレビュアに言い、残りは任意として扱うこと」
  • テストを分ける: 「片方の Claude にテストを書かせ、別の Claude にそれを通すコードを書かせる」という形が手引きに挙がっている。同じエージェントが両方書くと思い込みを共有するという指摘は複数の記事に見られるが、一次資料で数値の裏を取れていない
  • 事故: 2025年7月、変更の凍結を宣言していた最中にエージェントが本番のデータベースを削除し、1,200件を超える記録が失われた。運営元の責任者が公に認めている。事故のあと、開発用と本番用のデータベースを自動で分ける仕組みと、巻き戻しの改善が入った。凍結が指示の中にしか存在しなかったという整理は解説記事のもので、当事者の言葉ではない
  • フラグ: Cloudflare は「AI 支援による寄与が、プラットフォーム全体で新しいコードの急速に増える割合を占めている」ことを理由に挙げ、「エージェントが新しいコード経路をフラグの裏に書いてデプロイする。フラグは off なので、ユーザには何も変わらない」「エージェントが速く動けるのは、フラグが速く動くことを安全にしているからだ」と書いている。段階公開、条件つきの対象指定、変更の記録が機能として並ぶ

簡略化したこと ​

  • 測っていない: この章に自分で測った数字は無い。関門を入れると何がどれだけ減るのかは、調査の報告と製品の説明を読んだだけになる
  • 費用を数えていない: 関門はどれも時間と金を使う。E2E を厚くする、レビュアを増やす、フラグの仕組みを持つ、それぞれの元手は比べていない
  • フラグの負債に触れていない: 閉じたまま残ったフラグ、絡み合ったフラグ、消し忘れは実務では大きな問題になるが、ここでは扱わない
  • 指標と自動巻き戻しを浅くしている: 何を見て閉じるかは、それ自体が観測の話になる。この本のメトリクスとヒストグラムと繋げるべきところだが、繋いでいない
  • 組織の話をしていない: 誰が基準を書くのか、レビューの責任をどう持つのかは、道具の話ではないので外した
  • 版が動く: フックの書式も製品の機能も版で変わる。ここに書いたのは執筆時点のもの

参考資料 ​