撤退基準を先に書く

土日にAIで作った問診票の下書きツールが、気づけば3ヶ月動いている。同僚にも配って、何人かは使っている。「続けますか」と聞かれたら、多くの人はこう答える。「手応えがあれば続けます」。

この一言が、あとで一番厄介になる。

「手応えがあれば」は条件ではない

条件とは、あとで誰が見ても同じ判定になるものを指す。止める・続けるを決めるのに一番向いていないのは、作った本人の主観だ。時間が惜しくて、続ける理由を後から探してしまう。

3行で書く

数字は仮でいい。判定日に事実だけで割り切れる形にしておくことが条件になる。「1ヶ月に◯回使ったか」「エラー報告が0件だったか」でもいい。

止める条件の4つの型

止める条件は、だいたい次の4つのどれかに分類できる。

最後の「本人」が一番効く。公開の作業だけが2ヶ月動かないのは、意志の弱さでなく優先順位が低いという事実だ。感情でなく事実として受け止めた方が判断は早い。

止める＝消すではない。凍結

「止める」と聞くと、コードを消して謝って回る場面を想像しがちだ。そうではない。

判定日を過ぎて判断しないこと自体が、止める側の事実

ここが一番忘れられがちな部分になる。

判定日を設定しても、忙しくて見なかった。そのまま3ヶ月経った。これは「まだ判断していない」のではなく、優先順位が自分の中になかったという「止める」側の答えがもう出ている。

判定日を過ぎても判断しなかったことを先延ばしとして扱わない。止める条件の「本人」の列が満たされた事実として読む。

AIが決めるのはどこまでか

続ける・止めるの最終判断は本人が下す。

この線引きがあることで、撤退基準は「AIに任せて自動で切られる仕組み」ではなく、「本人が判断しやすくするための下ごしらえ」になる。

今日のまとめ

• 「手応えがあれば」は条件ではない。続ける条件・止める条件・次の判定日を、判定日に事実だけで割り切れる形で3行に書く
• 止める＝消すではなく凍結。更新を止め、コストだけ止めて、気が変わればいつでも解凍できる
• 判定日を過ぎても判断しなかったこと自体を、止める側の事実として扱う。先延ばしを「保留」として見逃さない

次のレッスンでは、この撤退基準と同時に入れておく計測の設計に進む。判定日に何を見て条件を判定するか、そのイベント設計を実装と同時に組み込む。

参考

• 梶谷健人「AIとサービスを開発してリリースするまでの流れとポイント」（note, 2026-09-11）。このコースの骨格は同記事の後半3工程（価格設計・マーケ素材・計測設計）を起点に、撤退基準を先頭に足したAMPL版。記事本文は有料のため転載しない