結論: 「作る」が安くなった分、「やめ方」を先に決める
機能やプロジェクトに着手する前に、撤退する条件を言葉にしておく。これだけで「ダラダラ続けて気づいたら 3 ヶ月」が減ります。私が最近いちばん効いた運用は、これでした。
なぜ今この話かというと、AI で「作る」コストが急に下がったからです。アイデアを思いついた夜に、Claude に投げれば翌朝には動くプロトタイプが手元にある。便利です。けれど「やめる」コストは 1mm も下がっていません。むしろ作るのが速くなった分、手元に中途半端な実験が溜まりやすくなった。私の node_modules ならぬ「やりかけ repo フォルダ」は、この半年で静かに肥えました。
この記事では、撤退基準（Kill Criteria、何がどうなったら撤退するかを事前に決めた条件）の書き方と、私が AetherEchoes の auto-publish 運用にこれを持ち込んだ実例を書きます。元ネタは Zenn で読んだ Kill Criteria の実践ガイドで、読んで「これは自分の運用に足りていなかった視点だ」と素直に思いました。
なぜ私たちはやめられないのか — 2 つの脳のクセ
結論から言うと、やめられないのは意志が弱いからではなく、人間に共通する 2 つの認知バイアスのせいです。原因が性格ではなく仕組みなら、対策も仕組みで打てます。
1 つ目は埋没コスト（サンクコスト、既に払って戻ってこない時間や金）。「ここまで 2 週間かけたんだから」という理由で、本来は損切りすべき実験を続けてしまう。2 つ目はエスカレーション・オブ・コミットメント（コミットメントの深追い）です。これは厄介で、失敗の証拠が増えるほど、なぜか投資を増やしてしまう傾向を指します。「あと少しで report が直るはず」と言いながら、直らない GSC レポートの整形スクリプトを夜中にいじり続けた私には、身に覚えがあります。
大事なのは、この 2 つが「判断するその瞬間」に効いてくることです。すでに走り出した後の自分は、損切りの判断者として信用できない。だから判断を、まだ冷静な「始める前の自分」に前借りしておく。撤退基準の本質はこの一点に尽きます。
撤退基準の書き方 — 「状態」と「期限」をセットにする
撤退基準は、観測できる「状態」と、待つ「期限・上限」をセットで書きます。どちらか片方だけだと機能しません。状態だけだと永遠に待ててしまい、期限だけだと「もう少しで届きそう」を握りつぶせないからです。
悪い例は「うまくいかなかったらやめる」。これは何も決めていないのと同じで、「うまくいかない」の定義がその場の気分に委ねられている。良い例は、こうです。
- 状態: 公開した動画 10 本の平均視聴維持率が 20% を下回る
- 期限: 公開から 3 週間
- 判定: 両方を満たしたら、その動画フォーマットは撤退（次の改善案へ移るか、止める）
この 3 点が揃うと、判断が「今日の私の機嫌」から「先週の私が決めた線」に移ります。私は実際に kill-criteria を 1 ファイルに書き出して repo に置く運用にしました。形式はゆるくて構いません。
# kill-criteria.yml
experiment: short-video-hook-ab
started_at: 2026-05-20
kill_when:
state: "avg_retention < 0.20 over latest 10 videos"
deadline: 2026-06-10
action: "hook 強調案を撤回し、次の改善 1 本に絞る"
review_at: 2026-06-03 # 中間レビュー日
ポイントは review_at（中間レビュー日）を別に持つことです。期限当日にいきなり「KILL か CONTINUE か」を迫られると、人は CONTINUE に逃げます。途中で一度立ち止まる日を置くと、判断が連続的になって、損切りの心理的ハードルが下がりました。
私の auto-publish に撤退基準を入れてみた
結論。撤退基準は「派手な新規プロジェクト」より、むしろ日々回している運用の細部にこそ効きました。私の場合は AetherEchoes の auto-publish（記事と動画を曜日ごとに自動で起稿し、私のレビューを経て公開する仕組み）です。
具体例を 1 つ。新ドメインを立ち上げた直後、私は速報記事を 1 日 4 回投稿していました。露出を増やせばインデックスも早かろう、という素朴な期待です。ところが 2026 年 5 月 31 日、これを 1 日 1 回に減らしました。理由は、被リンクがほぼゼロの新ドメインで本数だけ増やしても、インデックスは進まず、むしろ薄い記事が増えるだけだと判明したからです。このとき効いたのが、事前に「3 週間でインデックス率が伸びなければ本数戦略は撤退」と決めていたことでした。決めていなければ、たぶん「もう少し本数を増やせば」と逆方向に深追いしていた。エスカレーションの典型コースです。
もう 1 つ。私は「測ってから自動化する」を別の記事でも書きました（自動化の対象は勘ではなく測定で決める）。撤退基準はその裏返しで、「測った結果が基準を割ったら、自動化ごと畳む」を先に約束しておく仕組みです。作る前提と、やめる前提を両方そろえて、はじめて運用が一周します。要件を「思想と仕様」に分ける話（要件定義を思想と仕様に分ける）とも地続きで、撤退基準は仕様側に書ける「やめ方の仕様」だと私は捉えています。
プレモーテムで「やめる条件」を先に絞り出す
撤退基準を書こうとすると、最初は「何を状態に置けばいいのか分からない」で詰まります。ここで使えるのがプレモーテム（事前検死、まだ始まっていないのに『これは失敗した』と仮定して原因を洗い出す手法）です。
やり方は単純です。着手前に「半年後、この実験は無残に失敗しました」と完了形で言い切ってしまう。そのうえで「なぜ失敗したと思うか」を 5 つ書く。出てきた失敗理由を、観測できる指標に翻訳すると、それがそのまま撤退基準の「状態」になります。「誰も見なかった」は「30 日でセッション 100 未満」に、「メンテが重すぎた」は「週あたり保守時間が 2 時間を超えた」に変換する、という具合です。
プレモーテムは Gary Klein が提唱した手法で、Harvard Business Review にも短い解説が載っています。チームでやる前提の手法ですが、個人開発でも 1 人プレモーテムとして十分機能しました。私は新しい skill を 1 本足す前に、ノートアプリに「これが失敗するとしたら」を箇条書きする習慣にしています。何を選んだかだけでなく、なぜ選び、いつやめるかまで未来の自分に渡す。これは以前書いたツール選定ジャーナルの発想とほぼ同じで、撤退基準はその「終わり方」版です。
余談ですが、プレモーテムを書いていると、たまに「失敗理由が思いつかないほど自信がある」案件に当たります。私の経験上、そういう時こそ要注意で、だいたい想定していない方向から転びます。自信は撤退基準を省く理由にはならない、というのが正直な実感です。
まとめ: 始める前の自分に、やめる権利を渡しておく
撤退基準は、走り出した後の自分が下せない損切りを、まだ冷静な始める前の自分に前借りしておく仕組みです。持ち帰る点を並べます。
- 「作る」が安くなった時代に希少なのは「やめる判断」で、やめられないのは意志ではなく埋没コストとエスカレーションという仕組みのせい
- 撤退基準は「観測できる状態」と「期限・上限」をセットで書く。片方だけでは機能しない
- KILL の手前に REVIEW（中間レビュー日）を挟むと、損切りの心理的ハードルが下がる
- 何を状態に置くか迷ったら、プレモーテムで「失敗した理由」を先に書き、それを指標に翻訳する
私はこれを派手な新規開発ではなく、日々の auto-publish 運用の細部に入れていちばん効きました。次に何かを始めるとき、最初に開くファイルが kill-criteria.yml になってから、やりかけ repo フォルダの増殖はだいぶ落ち着いています。始めるのが速い時代だからこそ、やめ方を先に決めておく。それだけの話ですが、効きます。
よくある質問
- 撤退基準（Kill Criteria）とは何ですか？
- 何がどうなったら撤退するかを着手前に決めておく条件です。「観測できる状態」と「期限・上限」をセットで書きます。走り出した後の自分は埋没コストで損切り判断が鈍るため、まだ冷静な始める前の自分に判断を前借りしておく仕組みです。
- 撤退基準はどう書けばいいですか？
- 悪い例は「うまくいかなかったらやめる」です。良い例は「公開3週間で平均視聴維持率が20%未満なら撤退」のように、観測できる状態と期限を必ずセットにします。KILLの手前にREVIEW（中間レビュー日）を挟むと運用しやすくなります。
- プレモーテムとは何ですか？
- まだ始めていないのに「これは失敗した」と仮定して原因を先に洗い出す手法です。Gary Klein が提唱しました。出てきた失敗理由を観測できる指標に翻訳すると、そのまま撤退基準の「状態」になります。個人開発でも1人で機能します。
- 撤退基準は新規プロジェクトだけに使うものですか？
- いいえ。むしろ日々回している運用の細部に効きます。私はAetherEchoesのauto-publishで「3週間でインデックスが伸びなければ投稿本数戦略は撤退」と決めておき、本数を深追いせず1日1回へ減らす判断ができました。