丁寧に作られた間違いは、捨てられない。
背景
Claude Code などのエージェントに方法論フレームワークを載せ、長時間の自律実行をさせる運用が広がっている。代表例が superpowers（obra/superpowers）で、brainstorm → plan → TDD による実装 → レビュー、という工程をエージェントに強制するもので、2026年1月には Anthropic 公式のプラグインマーケットプレイスにも採用され、スターは26万を超えた。
まずはじめに、superpowers を否定する文書ではない。効く人には効くし、元の水準が「いきなり書き始めて迷走する」だった場合には明確な改善になるうえ、チーム内のばらつきも抑えられる。批判者ですら捨てずに fork しているあたりに、その実体はよく表れていると思う。
ただし効かない条件と、逆に有害に働く条件があると思っていて、それが見えにくいのは、合わずに使うのをやめた人がわざわざ理由を書き残さないからで、結果として出回る話はどうしても効いた人のものに偏ってしまう。
この文書は、いま導入済みのスキルやフレームワークを見直すための判断材料である。何を残し、何を外し、どのタスクでだけ有効にするかを決める基準として使ってほしい。
要約
生産コストだけが暴落し、評価コストは一切下がっていない。
コードを書くコストはこの2年で桁で下がったが、それが正しいか、必要か、保守できるかを人間が判断するコストのほうは1ミリも下がっておらず、起きている問題はほぼすべてここから導けると思う。
これまでは「書くのが大変」であること自体が量の歯止めになっていたわけで、その歯止めだけが外れれば、誰も評価していないコードの比率は上がり続けるだろう。話としては単純だが、効き方は大きいはずだ。
フレームワークはこれを手順の強制で解こうとするが、一部は解ける代わりに一部はむしろ悪化するのではないか、というのがこの文書の見立てである。
1. 追いつかないのは量ではなく速度
コードを生成する速度は桁で上がったのに、人間が新しい概念を吸収する速度のほうは変わっていない。
新しい抽象が増えること自体は悪くないし、良い抽象なら覚えるコストを払う価値もあるが、問題はその時間がないことだ。吸収は読んで終わりではなく、使い、間違え、直して初めて身につくもので、どうしても実時間がかかるので、速く読んだところで縮まらない。
しかも遅れは一定に留まらない。理解は積み上げなので、取りこぼした概念の上に次の概念が乗る。 1つ取りこぼせば次を吸収する速度も落ちて、差は放っておいても広がっていく。
厄介なのは、遅れている自覚を持ちにくいことだ。差分を1行ずつ追えば変更そのものは理解できるし、読むだけなら生成の速度にも追いつける。ただ、行の意味が分かることと、そこで使われている考え方が身についていることは別なので、追いつけているのはレビューだけで、理解のほうは離されたままになる。
2. 「理解していないコード」自体は問題ではない
理解していないコードは昔から出荷されてきた。依存ライブラリ、退職者の遺産、外注の納品物と、いくらでも例はあるが、それで回っていたのは境界が安定していて、中身を読まずに扱えたからである。
危険なのは理解の欠如ではなく、境界がどこにあるか誰も言えなくなることだ。
判定は、壊れたときにどうするかを考えれば付く。
中を読まずに直せる、あるいは丸ごと取り替えられるなら問題なくて、外部ライブラリがまさにこれにあたり、境界が安定しているうえ直すのも外部のメンテナである。中は読めなくても、仕様がこちらにあって作り直せるならこれも問題ない。読まなくていいものは負債にならない。
負債になるのは、そのどちらでもないときだ。中を読まないと直せないのに、作り直すこともできない。
最悪なのは、失われたら復元できない判断が、コードの中にしか存在しない状態である。
3. 規律は、悪いアイデアを捨てにくくする
ここが一番見落とされやすい点だと思う。
雑に作られた間違いは早期に崩壊して放棄されるが、規律正しく作られた間違いのほうは生き残ってしまう。テストがグリーンで、設計文書があり、例外ケースが網羅されていて、検証済みに見えるからだ。
プロセスの品質は、方向の正しさを保証しない。方向が間違っているとき、丁寧さはむしろ撤退を遅らせてしまう。
残ってしまうコードは、悪いから残るのではない。良く見えるから残る。
superpowers が強制する TDD、仕様適合レビュー、例外ケースの網羅も、方向が正しければ品質を上げるが、間違っていれば間違いの寿命を延ばすほうに働く。
4. 前提を疑う工程が、どの手順にも入っていない
superpowers の brainstorm は要件を詰める工程だが、質問が始まる時点で問題の枠組みは固定されている。「A と B のどちらを実装するか」は問われても、「そもそもこの問題は実在するのか」は問われないままで、plan も実装もレビューも、すべて枠組みの内側の話に留まる。
たとえば、使っているモデルや API の制約を回避するために複雑なロジックを設計・実装し、例外ケースを潰すためにコードが膨らんでいくが、実際にはモデルを変えるだけで制約自体が消える、といった失敗が起きる。
実装の前に一度問う：
- この制約は、モデルや設定を変えれば消えるか
- 一番単純な解は何で、それでは具体的に何が足りないのか
- 要求そのものを削れば、この機能は不要にならないか
削除も選択肢に入れる。ただし、この問いをエージェントに答えさせて人間が承認する形にすると意味を失うので、人間が自分で答えること。
5. テストは要求を検証していない
エージェントが書いたテストが検証しているのは要求ではなくエージェントの要求解釈であって、その解釈がずれていれば、間違った前提のままテストが通ってしまう。
これはテストがない状態よりも悪質で、テストがない状態なら人は慎重になるが、オールグリーンのテスト結果は油断を生んでしまう。
検証全般に同じことが言える。仕様に対して計画を、計画に対して実装を検証する連鎖は自己参照で閉じていて、仕様適合レビューは仕様が正しいことを前提にしている。この連鎖は、隅々まで筋が通ったまま丸ごと間違っていられる。
現実と突き合わせる機会は、人間が最初に枠組みを決める一点しかない。
6. 文書は、静かに間違う
コードには失敗の信号がある。コンパイラが落ち、テストが赤くなり、本番で壊れるので、レビューが不完全でも外側に検証装置がある。
設計文書にはそれが何もなく、実行できない文書は間違っていても静かなままで、微妙に間違った計画と正しい計画は読んだときの手触りが同じだ。
にもかかわらず、この工程には「上流だから効く」という理由で最大の権限が与えられている。検証装置が一つもない工程に、である。
承認にも非対称性があって、「良さそう」はゼロコストで済むのに、反対するには対抗する論を自分で組み立てなければならず、しかも生成された文書は代替案の検討も例外処理も網羅した形で書かれていて、文章として隙がない。
分量は、正しさと無関係に反論コストを上げる。
3行のスケッチなら「もっと単純にできる」と言えることが、40ページの plan.md には言いにくくなる。長い文書を読んでレビューできたと勘違いするとき、それは注意力の問題ではなく、そう錯覚させるように出来ている。
7. よくある反論
「『みんな中身を理解しなくなる』はコンパイラ、GC、フレームワーク、Stack Overflow で繰り返され、そのたびに外れてきた。今回も同じでは」
半分は正しいと思う。ただ、条件が違う。
過去の抽象化が隠したのは、安定していて、共有されていて、外部にメンテナがいる境界だった。libc も GC も React も世界中が同じものを使っていて、バグを踏むのが自分だけではないから、中身を読まずに済んでいた。
いま生成されているのは、そのプロジェクト専用で、誰とも共有されず、メンテナもいないコードである。議論の形は同じでも成立条件が違うので、過去の例はここでは当てにならないと考えている。
では、どうするか
手順を足しても評価コストは下がらないので、できるのは人間が握る範囲を絞ることだけである。
着手前
決めるのは成果物の予想寿命と、境界を誰が引くかの2つだ。数週間で捨てるものなら理解しなくていいが、数年動くなら境界だけは人間が握る。内側の充填はエージェントに任せて構わないものの、境界の設計まで任せた時点で作り直せなくなる。
レビュー時
差分の行を追うのをやめて、新しく増えた概念（抽象・パターン・語彙）だけを見る。前回の分がまだ身についていないなら、そこで止める。この見方なら数千行でも成立する。
フレームワークの使い分け
常時 on にする必要はない。単純なタスクでは工程のオーバーヘッドが上回ってしまい、曖昧さのない問題への確認質問も、1ファイルで済むものへのアーキテクチャ計画も、そのまま無駄になる。効くのは複数ファイル・数時間規模で正しさが重要なタスクなので、そこに限定して使う。debugging skill だけ、brainstorming だけ、といった部分採用も現実的だ。
効果を数字で確かめるのは諦めていい。公開されている数値はタスクの分布に強く依存していて流用できないし、自分の環境で測り直すのも実際には難しいので、工程が無駄になった場面を覚えておく方が早い。
自律実行を使う条件
「レビューできる量に抑える」ではなく、再生成可能な単位に切る。境界の内側で、捨てられる単位に対して中断なく走らせる。この形なら利点はほぼ取れて、収拾がつかなくなる事態は避けられる。
自律実行の魅力は、正確には 長時間 ではなく 中断されないこと。
最後に
悲観的な話ではない。希少資源が生産から判断へ移った、というだけの話である。
書ける人の価値は下がった一方で、評価できる人の価値は上がっていて、問題の構造を把握していて「この制約はモデルを変えれば消える」と指摘できる人の需要は、これまで以上に増加すると思う。
手順は判断より安く、チェックでき、外注できるので、そこに需要が集まるのは自然なことだ。ただし手順は判断の代替物ではない。ここを取り違えなければ、フレームワークは素直に効くと思う。