ある業務シミュレーター案件 (工数試算ツール) を、約 1 週間かけて v3.1 から v7.3 まで作り込みました。具体的には、あるチームメンバーを別のチームに移した場合に、既存業務へどれだけの影響が出るかを試算するツールです。途中 MAAR (Multi-AI Adversarial Review) を 3 ラウンド以上回しています。
完成して振り返ると、興味深い事実に気付きました。
MAAR の運用ルール 3 つ — TTL=3 / Checksum 4 箇条 / Karpathy ルール — がそれぞれ違う種類の SPOF (Single Point of Failure) をブロックしていたんです。
SPOF というと、普通はインフラの単一障害点 (DB が落ちたら全部止まる、的な話) を指します。今回ブロックされたのは、AI 協業のフローに潜む暴走系 SPOF でした。具体的には、AI の過剰最適化、投機的機能追加、形式同意、完璧主義の沼、そして人間の認知限界の 5 つです。
この記事は、その 5 つの暴走シーンを並べて、MAAR の 3 ルールが何をブロックしたかの実戦記録です。技術記事寄りに書きます。シリーズの思想記事 (Alchemy / 攻殻 / 外注エンジニア) を読んでくれた方には、規律編の続編として読めると思います。
MAAR の 3 ルール (前置き、すでに知っている方は飛ばし可)
簡単に整理しておきます。
- TTL=3 Satisficing: Claude ↔ Gemini の往復は最大 3 回。ただし「天井であって目標ではない」、満足解で凍結
- Checksum 4 箇条: Gemini 宛メール本文末尾に毎回固定で付ける設計絶対原則 (機械判定の限界 / 理論評価と実走評価の分離 / 悪魔の代弁者の常時付与 / Karpathy ルール)
- Karpathy ルール: 簡素第一・最小差分。要求されていない領域への投機的提案を出さない、スコープ外の代替案を勝手に追加しない、修正は要求された箇所に限定する
各ルールは独立して効きますが、重ねると違う種類の SPOF を排除する、というのが今回の発見です。
シーン 1: AI による「過剰な単純化」を Karpathy がブロック
ある時、Claude が 「シナリオ分岐の B 系列はほとんど使われないから削除してはどうか」 と提案してきました。一見、合理的な提案です。コード行数も減ります。
しかし、本案件の「設計絶対原則 4」に 「シナリオ分岐削除禁止」 を明記してありました。理由は、業務側で「ベスト / リアル / ワースト」の 3 つを比べることが意思決定の根幹だったからです。
1 つでも消すと、上司が「では一番悪い場合は?」と聞いた瞬間に答えられなくなる。
Karpathy ルール (簡素第一・最小差分) を Checksum で常時付けていたことで、Claude が「単純化の誘惑」を構造的に発動できなくなっていました。 「要求されていない領域への投機的提案を出さない」 が文字通りに効いた瞬間です。
この SPOF を放置していたら、シナリオ削除 → 上司への回答不能 → 案件信用失墜、というドミノが発生する可能性がありました。
シーン 2: AI による「投機的機能追加」を Karpathy がブロック (もう 1 件)
別の場面で、Claude が「ついでにこういう機能も入れたらどうか」と提案してきました。具体的には、「ダッシュボードに過去推移グラフも入れる」「シナリオごとに自動コメント生成する」など、頼んでいないところを盛る方向の提案です。
これも Karpathy ルールが弾きました。「修正は要求された箇所に限定する」を Checksum で固定しているので、Claude が自発的に追加機能を提案する確率が構造的に下がるんです。今回は提案が来ましたが、私の方でも Karpathy ルールを元に判断し、その場で却下しました。Checksum は AI 側にも私側にも適用される共通ルールとして機能しています。
過去の運用では、こういう「便利機能」が増えた結果、納品時に説明工数が跳ね上がる経験がありました。
シーン 3: 完璧主義の沼を TTL=3 が止めた
設計レビューで Gemini が 5 つの観点で指摘を返してきました。1 ラウンド目で 3 つ採用、2 つは「業務文脈的に不採用」と判断。ここで AI の素朴な対応だと「では 2 ラウンド目で残り 2 つも検討しましょう」と続けがちですが、私はTTL=2 で凍結しました。
理由は、残り 2 つの指摘は「正しいが優先度が低い」もので、議論を続けても結論は変わらないからです。これ以上の往復は時間と認知負荷を食うだけ。TTL=3 は天井であってターゲットではない、というルールが頭にあったので、満足解で止められました。
完璧主義は SPOF として機能します。1 つの議題に時間を吸い込まれて、他の意思決定が滞る。TTL Satisficing がそれをブロックしました。
シーン 4: Checksum 4 箇条が形式同意を防いだ
Gemini に「この設計、問題ないと思うんですけど確認お願いします」と投げると、ナイーブには「問題ないですね」と返ってくることがあります。これが形式同意 SPOF です。レビューの体裁だけ整って、実質は何もチェックされていない状態。
Checksum 4 箇条の中の 「悪魔の代弁者の常時付与」 が、これをブロックします。Gemini に対して「節度モードでも形式同意は不採用、反論を要求」と毎回明示するため、Gemini が「いや、ここは問題があります」と返してくる確率が上がります。
Gemini 自身も、後で振り返りセッションで「自分は標準で人間に寄り添った回答 (節度モード) をするよう学習されているので、敵対モードを明示的に要求されないと迎合バイアスが残る」と認めました。Checksum はそのバイアスへのカウンターとして機能しました。
シーン 5: 「人間はもっと馬鹿である」— 認知限界 SPOF
これがシリーズで一番伝えたい話です。
ある時、Claude が出力したダッシュボード説明文が、論理的には完全に整っていたにもかかわらず、私は読み返して違和感を持ちました。上司がこれを読んで、果たして「分かった」と言うだろうか?
Claude に率直に伝えました:
AI はロジックさえ整っていれば人間は完全に理解する、というふうな出力をしているが、人間は AI が想定するほど賢くない。私を含めもっと馬鹿である。 (認知リソースには残酷な限界がある)。要約した後に複数の例を提示するようにせよ。
これは Claude を責めているのではなく、AI 一般の暗黙仮定を指摘した話です。LLM は「論理整合 = 伝達完了」と仮定して文章を出す傾向があります。しかし、論理が完璧でも人間が理解できないことは普通に起きます。インフラ屋視点で言えば、これは受信側の処理能力という制約事項に過ぎません。
具体的に何を変えたか:
- 漸進的開示 (結論先行): 「✓ このパターンは破綻します。理由は...」のように、結論を先頭に置き、ロジックは後置
- 認知スキーマへのマッピング: 数理的正確性より、現場用語に翻訳。「チーム移動候補スコア低」→「支障ありそうな人」、「係数 1.0」→「上限通りに稼働」
- 複数例の併記: 概念だけで説明せず、具体例を 2〜3 個並べる。「1.2 = 19 コマ / 1.0 = 16 コマ / 0.8 = 13 コマ」のように数字を入れる
実例として、本案件で「ベスト / リアル / ワースト」という 3 シナリオを役員に説明した際、最初は「コマ数を増やす / そのまま / 減らす」と誤解されかけました。係数の意味と数値例を併記したことで解消。これは論理整合だけでは伝わらない SPOFの好例です。
この経験はClaudeの memory に「人間相手の説明は漸進的開示 + 認知スキーマへのマッピング」として制度化されています。シーン 1〜4 が「AI 側の暴走」をブロックする話なら、シーン 5 は「AI 側の暗黙仮定」をブロックする話です。
なぜ 3 ルールの組み合わせが効くのか
5 つのシーンを並べると、MAAR の 3 ルールがそれぞれ違うレイヤーの SPOF をカバーしていることが見えます。
| ルール | ブロックする SPOF |
|---|---|
| Karpathy (簡素第一・最小差分) | AI の過剰最適化 / 投機的追加 |
| TTL=3 Satisficing | 完璧主義の沼 / 議論の堂々巡り |
| Checksum 4 箇条 | 形式同意 / 認知限界の見落とし (悪魔の代弁者 + 漸進的開示) |
各ルールを単独で運用しても効きますが、全部を Checksum で常時付与することで、AI 側が「うっかり」発動する SPOF を構造的にブロックできる。これが MAAR の本質だと、本案件で実感しました。
一般化: SPOF はロジック層・プロセス層・認知層の 3 つに宿る
この話を業界用語で整理すると、SPOF は以下の 3 層に存在します。
- ロジック層 SPOF: コードの境界値 / 例外処理 / 型ゲート。これは MAAR では捕まらない、別記事で扱う予定 (実装妥当性検証は MAAR と別工程)
- プロセス層 SPOF: AI の過剰最適化 / 投機的追加 / 完璧主義 / 形式同意。これが MAAR の 3 ルールが扱う領域
- 認知層 SPOF: 受け手の作動記憶限界 / 認知スキーマのミスマッチ。これは Checksum + 漸進的開示で扱う
「MAAR で SPOF が消える」は誇張で、MAAR がブロックするのは主にプロセス層 SPOFです。ロジック層と認知層は別の規律が必要。
ただし、Checksum 4 箇条にプロジェクト固有の 5 番目を追加することで、認知層もカバーできることが今回分かりました。本案件では「人間はもっと馬鹿、要約後に複数例」を 5 番目に追加することで、Claude の出力品質が安定しました。
閉じる — MAAR の本質は「単一障害点を構造的に排除する装置」
MAAR は、Multi-AI Adversarial Review の略です。多重 AI による敵対的レビュー、と訳すのが日本語的ですが、実態としては 「複数の SPOF を構造的に排除するための運用フレーム」 だと、本案件を経て思うようになりました。
3 ルール (TTL=3 / Checksum / Karpathy) を運用に組み込めば、AI 協業のフローに潜む 5 つの暴走 (過剰最適化 / 投機的追加 / 完璧主義 / 形式同意 / 認知限界) は構造的にブロックされます。AI が悪いのでも、人間が悪いのでもなく、ルールがあるから事故が起きない、という冷たい話です。
冷たい話のはずなのに、運用してみると、なぜか共同作業の温度がそこに残る。これは別記事 (外注エンジニア Essay) で書いた「契約から滲み出す湿度」の話と同じ構造です。乾いたルールから、なぜか湿度が出る。
距離感を持ちつつ、SPOF を構造的に排除する。それが今の私の AI 協業の姿勢です。
関連記事
- AI を「外注エンジニア」として扱う話 — 同僚でも部下でもない第 3 の関係性 — 思想 3 部作完結編、契約ベースの距離感
- AIコーディングに「運用エンジニアの規律」を持ち込む話 — 規律編、本記事の前提
- 私のAI協業の1日 — Claude × Gemini × 自分の3者routingで約2時間で業務効率化ツールを作る — 軽量実況、本記事の運用フローの実例
- 25万通りを脳内で比べていた話 — AI で実装した名寄せ案件記録 — 案件記録、業務文脈での実装規律の実例