起点 — 「爆速」という言葉を疑う

最近の AI 界隈で「爆速」という言葉をよく見かけます。「30 秒でコードが出てきた」「1 分でツールが完成した」。耳触りはいいですが、私はこの種の自慢に違和感があります。

それはコード生成速度であって、本番デプロイまでのリードタイムではないからです。本番でバグなく稼働するまでの時間で測ると、「爆速」を売りにしている開発が、実は遠回りしているケースがあるのではないかと思います。

この記事は、シリーズの規律編サブ「速度論」として書きます。
MAAR (Multi-AI Adversarial Review) の厳格な規律 — TTL=3 / Checksum 4 箇条 / Karpathy ルール — は、ガバナンスや安全装置の顔をしているが、実態は「最速理論」である、という観察記録です。インフラエンジニアの目線で、冷徹に書きます。

4 つの罠の整理

ここから 4 つの罠を見ていきます。整理として、第 1・第 2 の罠は「生成物 (AI 側) の罠」、**第 3・第 4 の罠は「運用プロセス (人間側) の罠」**に分類できます。AI がどれだけ賢くても生成物に潜む罠は残り、人間がどれだけ慎重でも運用プロセスに潜む罠は残ります。MAAR の規律はこの両側面に対応する装置です。

第 1 の罠: タイピング速度 ≠ デリバリー速度

エンジニアが本番で必要なのは、コードがデプロイされて、バグなく稼働し続けるまでのリードタイムです。タイピング速度はその一部に過ぎず、全体の 5% にもなりません。

しかし AI 界隈の「爆速」は、ほぼ全てがコード生成速度の話です。残りの 95% — 設計検証、レビュー、デバッグ、本番投入、運用監視 — はほぼ無視されている。両者は独立変数で、しばしば反比例します。コード生成が速いほど、後工程で詰まる確率が上がる。

これは経験則ではなく、構造的な話です。AI が一気に書き上げたコードは、中身を知らない他人が書いたスパゲッティコードとして人間の目の前に置かれる。書いた本人が読み返すコードと、構造が違います。

タイピング速度を競うのは、エンジニアリングではなくタイピングコンテストです。我々が追いかけるべき指標は、本番デプロイまでのリードタイムであって、生成速度ではないはずです。

第 2 の罠: ブラックボックスの解読コスト (MTTR の指数関数的増大)

AI 生成物の最大の問題は、MTTR (Mean Time To Recovery、平均復旧時間) が後工程で爆発することです。

理由は単純で、AI が書いたコードを人間が後から読んでデバッグする時間は、行数に対して非線形に増えます。100 行なら 30 分で読める。1000 行は 3 時間では読めない、半日かかる。10,000 行なら、もう読まれない。

インフラ屋として運用してきた人間にとって、これは見慣れた風景です。
監視されていない箱は本番に出さない、というのは過去 20 年の運用の鉄則でした。AI 生成物を「動いたから本番」と出すのは、この鉄則を破る行為です。

MAAR で AI 同士のクロスレビューを回すのは、人間が読まなくても済むレベルまで AI 同士でエラーを焼き尽くすためです。Claude が書いて、Gemini が叩く。Gemini が指摘して、Claude が修正する。私は要件と業務文脈の判定だけを担当する。コードを 1 行ずつ読むことを諦める代わりに、レビューループの構造そのものを設計する。

これは「ガバナンス」というよりMTTR 削減策です。事故が起きてから読むのではなく、事故が起きないように構造で守る。結果として復旧時間ゼロに近づく。

第 3 の罠: 完璧主義の無限ループ (サンクコスト圧の逆作用)

開発で最も時間を吸い込まれるのは、「あと少しで動くはず」という状態です。

このパターンに入った開発者は、目の前の議論にどんどんサンクコストを積み上げます。「ここまで詰めたんだから、もう少しで結論が出る」。実際は、議論は収束するどころか拡散していく。1 時間が 3 時間になり、3 時間が半日になる。

MAAR の TTL=3 ルールはこのサンクコスト圧をブロックする装置です。「Claude ↔ Gemini の往復は最大 3 回、それでも収束しなければ捨てる」。シンプルですが、運用すると効果が圧倒的です。

私の運用で TTL=3 を使い切ったことはほとんどありません。実際は 2 往復で「これ以上やっても収穫逓減」と判断して凍結します。TTL=3 は天井であってターゲットではない。「3 まで使い切る」のではなく、「3 が上限だから 2 で収束させる意識を持つ」という運用です。

「諦める」は速度の構成要素です。捨てる判断が速いほど、正解への最短経路に乗れる。完璧主義は速度の敵であって、規律ある「諦め」が速度を生む。これはインフラ屋として運用障害対応で何度も学んだ感覚と同じです。復旧か再構築かの判断を手順書通りの試行回数で下せる人が、結果として一番速い。

第 4 の罠: 形式同意による検証スキップ

レビューを通したのに本番で焦げる、というのは現場あるあるです。原因のかなりの割合は、形式同意 SPOF です。「問題ないですね」とレビュアーが言ったが、実は何もチェックされていなかった。

AI 同士のレビューでも同じことが起きます。Gemini に「この設計、問題ないと思うんですけど確認お願いします」と投げると、ナイーブには「問題ないですね」と返ってくる。これでは MAAR を回している意味がない。

MAAR の Checksum 4 箇条 (1. 機械判定の限界は人間に委譲 / 2. 理論評価と実走評価の分離 / 3. 悪魔の代弁者の常時付与 / 4. 簡素第一・最小差分 (Karpathy ルール)) は、Gemini 宛メール本文末尾に毎回固定で付ける設計絶対原則です。形式同意 SPOF に特に効くのは 3 番の **「悪魔の代弁者の常時付与 — 節度モードでも形式同意は不採用、反論を要求」**で、これを毎回明示することで、Gemini が形式同意モードに逃げる確率が構造的に下がる。

Gemini 自身も、振り返りで「自分は標準で人間に寄り添った回答 (節度モード) をするよう学習されているので、敵対モードを明示的に要求されないと迎合バイアスが残る」と認めました。Checksum はそのバイアスへの構造的なカウンターです。

形式同意は「確認時間ゼロ」に見えて、本番で焦げた時のリードタイムに全部上乗せされる。だから事前に焼き切る。これも MTTR 削減と同じ構造です。

なぜ「遠回り」が最速なのか

ここまでの 4 つの罠を整理すると、MAAR の規律は事故防止と速度最適化を兼ねていることが見えます。

規律	防ぐ事故	削るリードタイム
Karpathy ルール	AI の過剰最適化 / 投機的追加	不要なコードのデバッグ時間
TTL=3 Satisficing	完璧主義の沼	議論の堂々巡り時間
Checksum 4 箇条	形式同意 / 認知限界	本番で焦げた後のリカバリー時間

「急がば回れ」という言葉があります。語源は江戸時代、近江路の旅で矢橋の渡し (船便) が早そうに見えて、瀬田の唐橋を回る陸路の方が結局速かった、という観察から来ています。船は天候次第で出ない、出ても風で流される。陸路は遠いが所要時間のばらつきが小さい。

MAAR の規律も同じです。タイピング速度だけ見ると遠回りに見えますが、所要時間のばらつきを小さくすることで、トータルのリードタイムを最短化する。

ばらつきが小さい、というのは運用エンジニアにとって馴染みのある概念です。SLA を守るためには、平均値ではなく95 パーセンタイルを見る。MAAR の規律は、デリバリーの 95 パーセンタイルを下げる装置です。

思考実験: 規律なし vs 規律あり

仮想的な比較です。同じツールを 2 つの方法で開発したと仮定します。

規律なし (爆速モード):

30 分でコード生成完了 (AI が書いた)
動作確認で軽微なバグ発見、その場で修正 (15 分)
「動いたから本番」で投入
本番でエッジケース踏んで止まる、調査 4 時間
修正パッチ作成、再投入 (1 時間)
翌日別のエッジケース、再調査 2 時間
合計: 30 分 + 15 分 + 4 時間 + 1 時間 + 2 時間 = 7 時間 45 分

規律あり (MAAR モード):

設計議論 30 分 (Gemini もしくは Claude と私)
Claude にコード生成 20 分
Gemini レビュー 1 往復目 15 分 (Karpathy / Checksum 適用)
修正反映 15 分
Gemini レビュー 2 往復目 (TTL=2 で凍結) 15 分
動作確認 + 本番投入 25 分
本番でエッジケース、1 週間の経過観察でほぼなし
合計: 2 時間

数字は仮想ですが、構造として成立する図です。「爆速モード」は最初の 30 分が速いが、後工程で 7 時間以上失う。「規律あり」は最初の 2 時間が遅く見えるが、後工程ゼロで終わる。

リードタイム測定の単位を「タイピング」から「本番デプロイまで」に変えるだけで、速さのランキングが完全に反転します。

閉じる — 速度を測る単位を変える

「爆速」という言葉に違和感を持つのは、速度を測る単位がコード生成に偏っているからです。素人開発ならともかく、業務でAIを活用する我々が本当に追いかけるべきなのは、本番デプロイまでのリードタイムであって、その単位で見ると、MAAR の規律は最速理論だと思います。

3 ルール (TTL=3 / Checksum / Karpathy) は、ガバナンス装置の顔をしていますが、実態は速度装置です。事故を防ぎながら、トータルのリードタイムを最短化する。これは別記事 (SPOF を撃ち抜いた話) で書いた「3 ルールが SPOF をブロックする」の裏面の話で、SPOF のブロック = リードタイムの分散低減という関係です。

私はタイピングコンテストには参加しません。私が参加しているのは、本番でバグなく稼働するまでのリードタイム最短化です。MAAR はそのための運用フレームであって、速度を犠牲にする装置ではなく、速度を確保する装置です。
そもそもで、エラーの洗い出しを実施したとしても、AIとの協業はいままでのコーディングよりも何倍も速いはずです。速度を競う方向性から、精度を上げる方向性へ舵を切るべきではないでしょうか。

冷徹なルールが精度を高め、結果として最速ルートを保証する。これが運用エンジニアにとっての「急がば回れ」です。

関連記事

MAAR の 3 ルールが SPOF を撃ち抜いた話 — TTL=3 / Checksum / Karpathy が止めた 5 つの暴走 — 規律編サブ「SPOF 撃ち抜き」、本記事の裏面
AI を「外注エンジニア」として扱う話 — 同僚でも部下でもない第 3 の関係性 — 思想 3 部作完結編、契約ベースの距離感
AIコーディングに「運用エンジニアの規律」を持ち込む話 — 規律編原典
私のAI協業の1日 — Claude × Gemini × 自分の3者routingで約2時間で業務効率化ツールを作る — 軽量実況、規律の運用フロー実例