自作ツールに、廃止論を全力で書かせた——/goal時代に「開発の型」は生き残るか

dev-agent-teamシリーズの13本目。 前回（不具合は分割の境界に落ちる）は 実プロジェクトの知見を型に還流させる話だった。 今回はシリーズ4本目とまったく同じ問いを、2か月後にもう一度—— ただし今度は、自分に不利な形で答えさせた。

Claude Code本体に /goal（自律ループ）、/loop（定期再実行）、 Dynamic Workflows、Agent Teams、Scheduled Tasks が揃ってきた。 ここで、作った本人から素朴な疑問が出る。

このプラグイン、Goal や loop が増えても存在してて価値あるものなのかな？

同じ問いには、シリーズ4本目で一度答えている。 「冗長ではない。型とエンジンはレイヤーが違うから、競合せず積み重なる」。 この結論は今でも大筋で正しいと思っている。だが、2か月分の本体アップデートを浴びたあとでも 同じことが言えるかは、別の話だ。

そして厄介なのは、この問いを自分で検証すると、まず結論が先に決まることだ。 自作ツールに「もう要らない」と言い渡すのは、誰にとっても気が進まない。 だから今回は、その気の進まなさを構造で潰すやり方を取った。

1. 手法——自分を殴らせる4並列分析

やり方はsteelmanだ。藁人形論法（strawman——相手の主張をわざと弱く作って叩く）の逆で、 相手の主張を本人以上に強い形で組み立ててから検証する。 今回でいえば、AIに「『このツールはもう不要だ』を、考えうる最強の形で構築しろ」と指示する。

Dynamic Workflowsで下位モデル4体を並列起動し、統合だけをFable 5にやらせた。 合計28万トークン・約4分（effortはモデルに使わせる思考量の設定）。

① 廃止論 steelman   （Sonnet / effort: high）
   「もう不要だ」を最強の形で組み立てる。遠慮禁止

② 擁護論            （Sonnet / effort: high）
   ただし根拠なき擁護は禁止。エンジンが提供しないものだけ挙げる

③ 重複マトリクス    （Sonnet / effort: medium）
   構成要素21個を中立に判定
   （置換済み / 部分 / 未置換 / 包含）

④ 実績監査          （Haiku  / effort: medium）
   CHANGELOGから「実運用由来」と「机上の整理」を仕分け

           ↓

     統合（Fable 5）

肝は①と②を同じ土俵で戦わせ、勝敗の判定を別の中立エージェント③に出させた点だ。 自己批評より独立検証——これはこのキット自身の設計原則であり、 公式のプロンプティングガイドとも一致する。 自分のツールの存廃を決めるのに、自分のツールの原則を使った格好になる。

2. 先に、廃止論が正しく突いてきた弱点を書く

結論から言えばキットは生き残ったのだが、順番として負けたところを先に書く。 こういう検証は、都合のいい結果だけ持ち出した瞬間に検証ではなくなる。

2-1. ドキュメント自身が「もう要らない」と4箇所で自認していた

最も痛かった指摘がこれだ。キットのドキュメント内に、 「ランタイムが保証済み、キット側の変更不要」と自ら書いている箇所が4つあった。 つまり承認まわりの防御は、すでに本体のランタイムに吸収されつつある。 その領域のキットの記述は、もはや防御層ではなく注釈だ。

さらに、Anthropic公式のFable 5ガイドが挙げるcheckpointパターン （破壊的・不可逆／スコープ変更／本人にしか出せない入力）は、 キットのHuman Decision Point（人間が判断を下すべき地点）の定義とほぼ一致している。 キットがなくても、モデルがデフォルトでそう振る舞う方向に進んでいるということだ。

2-2. 維持コストが、キット自身の戒めと同じ形をしていた

69コミットのうちかなりの割合がベンダーのリリース追随で、バージョンピンは10個を超えていた。 単独メンテナがClaude Codeのリリース速度に追随し続ける構図は、 キット自身が「発火点（自動で走り出す起点）を増やすな」と戒めているものと同型だ （この戒めの出どころはルーチン暴走の事故にある）。 自分の型を、自分に適用できていなかった。

2-3. ただし、「最強の形で」と指示した以上、数字は盛られる

廃止論は「4500行の常識テンプレ」と断じてきたが、実測すると2528行だった。 しかも agents / skills は既に「原則＋なぜ」の粒度まで削られていて、 「常識をだらだら書いた文書」という像とは違う。

ここで強調したいのは、AIが嘘をついたという話ではないということだ。 「最強の形で組み立てろ」と指示された以上、主張を強く見せる方向に数字が寄るのは steelmanの必然であって、指示した側の責任に属する。

だから設計として、「主張する係（①廃止論・②擁護論）」と「数える係（③重複マトリクス・④実績監査）」を 最初から分けておく必要があった。 廃止論だけを回していたら、この4500行という数字は誰にも検算されないまま結論の根拠になっていた。

3. それでも、吸収されないもの

3-1. 完全置換は21個中0件

中立の重複マトリクスによる判定結果がこれだ。 fully_replaced（ネイティブ機能に完全に置き換わった）は0件。 多くは「ネイティブ機能を包んで、適用範囲とガードレールを付け足す」積層構造だった （判定ラベルでいうと kit_wraps_native＝キットがネイティブを包んでいる、に分類される）。

3-2. /goal は空の器

これが今回いちばん腑に落ちた整理だ。

/goal は「終了条件を満たすまで回す」機構であって、 何をもって終了とするかは持っていない。 だから /goal はこのキットの競合ではなく、 このキットが手綱をつける対象だ。

3-3. 逆説——エンジンが強くなるほど、境界の空白は増える

前回の記事で入れた無主物リスト （単位分割の境界で担当者不在になる関心事を、設計と同時にあらかじめ列挙しておく仕組み）は、 並列実行エンジンが強くなるほど必要性が上がる。

エンジンは分割を加速する。だが分割の境界にできる空白は埋めない。 むしろ速く細かく分割できるようになった分、境界の総延長は伸びる。 ネイティブ機能の進化が、キットの一部を陳腐化させると同時に、別の一部の価値を上げていた。

3-4. 事故由来のルールは、汎用ガードレールでは拾えない

自己再発火の禁止—— 2日間・185回のルーチン暴走から作ったルールがある。 これはネイティブの汎用ガードレールでは拾えない。 「終了条件が原理的に存在しないループを検出して止める」機構は、ランタイムに存在しないからだ。

実績監査の結果も同じ方向を向いていた。 CHANGELOGのうち実運用フィードバック由来のエントリ15件は、すべて 「賢いモデル＋ネイティブ機能だけでは構造的に防げない」型だった。 「確認事項がない」は「承認済み」ではない。依頼者の頭の中にしかない情報がある。目視と実測は違う—— どれもモデルが賢くなれば消える種類の失敗ではない。

4. 結論——価値の重心が移った

4体の結果を統合して出た答えは、存続でも廃止でもなく重心移動だった。

「賢い進め方の明文化」としての価値は、確かに薄れつつある。本体がやってくれるようになったからだ。 一方で「現場固有の判断・事故・罠の蓄積装置」としての価値は、むしろ増している。 前者は吸収されるが、後者は原理的に吸収されない—— あなたの現場で何が起きたかを、Anthropicは知らない。

5. 対応その1——判断の置き場を作る（Decision Log）

ここから実際の対応。1本目は、外部の発表に殴られて気づいた穴を埋めるものだ。

これを自分のキットに当てて、わりと間抜けな事実に気づいた。 キットにはHuman Decision Pointが15個あるのに、そこで人間が下した答えの置き場がなかった。 残るのは踏んだ罠（Known Risks）だけ。つまり失敗は記録されるが、判断は蒸発していた。

Project Rulesに Decision Log（判断 / 理由 / 再利用条件）を新設し、 Phase 8で書き、Phase 0で読むループを追加した （PR #29）。

理由を必須にしたのが要点だ。判断だけを残すと、 前提が変わったときに見直す手がかりがなくなり、ただの縛りになる。 「なぜそう決めたか」があって初めて「その前提はもう成り立たない」と言える。

6. 対応その2——追随コストに上限を設ける（再定位リファクタ）

2本目（PR #30、 #29の上にstacked）は、4の結論をそのままキットの構造に落とすものだ。

2が2-2への回答だ。取り込み基準を絞ることで、追随コストに構造的な上限がかかる。 「新機能が出たら検討する」だと発火点が無限に増える。 「人間ゲートが動くものだけ」なら、本体がどれだけ機能を出しても仕事量は増えない。 これは「発火点を増やさない」という自分のルールの、自分への適用だ。

3も同じ発想で、監査そのものを追随コストにしないための処置だ。 agents 7本・skills 8本は既に適正粒度だと記録して打ち切る。 ついでに脂肪が集中していた adopt-project.md の重複と開発メモを削除した（751 → 725行）。

なお両PRとも、その後 main にマージ済み。 キットの現在の全体像は次の記事で通しで再掲した。

7. まとめ

• 自作ツールの存廃は、自分では検証できない。結論が先に決まるからだ。AIに廃止論をsteelmanさせ、判定を中立の第三エージェントに出させる構造で潰した
• ただし「最強の形で」と指示した以上、数字は盛られる（4500行 → 実測2528行）。主張する係と数える係を分けるのは、手法上の必須要件
• 完全置換は21個中0件。/goalは終了条件の器であって中身ではない
• それでも負けはあった。承認まわりの防御はランタイムに吸収されつつあり、その領域の記述は防御層ではなく注釈になっていた
• 答えは存続でも廃止でもなく重心移動——「賢さの明文化」から「現場でしか得られない判断と事故の台帳」へ
• エンジンが強くなるほど、境界の空白は増える。ネイティブの進化はキットの一部を陳腐化させ、同時に別の一部の価値を上げる

シリーズ4本目で「レイヤーが違うから積み重なる」と書いたときは、正直なところ 自作ツールを守りたい気持ちが混ざっていたと思う。 今回、同じ問いに全力で「不要だ」と言わせてみて、結論の骨格は残ったが、 守るべき場所は明確に変わった。

自分で作ったものを、自分で疑うのは難しい。 だが疑う役を外に出す仕組みは作れる——それが今回いちばんの収穫だった。