実録　値付けが空のまま止まった三つ

ここまで4本で、撤退基準・計測・値付け・届けるの型を見てきました。このレッスンには新しい型は出てきません。代わりに、その型を実際に運用した結果を、隠さずに見せます。

書いているのは架空の失敗談ではありません。AMPLの経営体制の中核に据えている3本、minaton・pedia・tokyo-speedの現在地です。3本とも本番相当まで作り込まれています。そして3本とも、値付けか公開のどこかで止まっています。

出す工程の、空いている場所

AMPLでは製品が出るまでの流れを11の工程で見ています。企画・試作・実装までの⑥は、何本も通っています。止まるのは決まって⑦値付け、⑩届ける、⑪計測の3つです。

この3つが空洞だという事実は、プロダクト進捗ボード（01_社長室/01_経営/プロダクト進捗ボード.md、最終更新2026-09-13）にそのまま書かれています。以下は、そこに記録されている事実だけを並べたものです。推測や後付けの理由づけは入れていません。

minaton: 計測は先に来た。値付けだけ空いている

minaton（港区の子育て情報サイト）は本番稼働中で、⑪計測までAMPLの中で唯一到達しています。PostHog、GA、web_vitalsを組み合わせた計測基盤が実際に動いており、これはこのコースの02で説明した「計測は実装と同時に入れる」がそのまま形になった例です。

キッズデザイン賞のマークも日英トップページに掲出済み（8/20）。iF 2027へのエントリーも9/13に済ませています。これは賞を受賞すれば€2,900の支払いが確定する、コスト側の意思決定です。

その一方で、⑦値付けだけが空いたままです。minatonは今も無料で提供されています。ボード上の「次の判定日」欄は「要設定」、つまりまだ日付が入っていません。

このコースの01で扱った撤退基準のルールを思い出してください。続ける条件・止める条件・判定日を先に書く、というものでした。minatonの値付けについては、その判定日そのものがまだ書かれていない状態です。計測という一番難しい工程を突破していながら、値付けの着手日が決まっていない。これは技術の壁ではなく、優先順位が実際にはどこにあるかを示す事実として読めます。

pedia: 機能を削ったら、赤字構造が消えた

pedia（小児科専門医試験の問題演習、888問）は⑥実装が完了し、9/13に⑪計測へ着手しています。決済ゲートはすでに実装済み（コミットdc361bad0）。計測は外部SDKに頼らず、自社の計装（lib/analytics.tsからSupabaseのeventsテーブルへ)で行っています。

pediaにはこのコースの03で説明した「手順0、その機能を落とせないか」の実例があります。AIチューター機能は、当初の構想に含まれていましたが、売り物から外されました。ship-productスキルの記録によれば、この機能を外したことでGate A(値付け)の赤字構造がそのまま解消しています。従量課金を生む機能が製品から消えたことで、原価の裾を気にする必要自体がなくなったということです。

pediaの本人ゲートは、Stripeの価格作成、本番環境の設定、デプロイとpushです。加えて、このプロダクトをどう回すかという事業の方向そのものも、まだ決まっていません。次の判定日は「計測から2週間後に⑦を判断する」と、具体的に設定されています。3本の中で唯一、撤退基準のルール通りに次の判定日が書かれているのがpediaです。

tokyo-speed: 二重ゲートで止まっている

tokyo-speedは⑥が完了し、有料チケットとホストの受け取りをprovider-readyの形で本番に反映済みです(mainブランチ、テスト606件が緑)。実装としては動く状態にあります。

それでも実課金は動いていません。決済側の接続（Stripe Connect）がまだ有効化されていないからです。計測も、Plausibleを使う宣言だけがあって実際には接続されておらず、⑪はゼロのままです。

本人ゲートはStripe Connectの有効化、手数料率の決定、法務確認、DNSの4つ。ボードはこの状態を「⑦が二重ゲートで休眠」と表現しています。値付けを機能させるための前提(Connect)と、値付けを許可するための前提(法務)が両方止まっている、という意味です。実装は終わっているのに、値付けの手前にもう一段、ゲートが重なっています。

三つに共通するもの

3本とも⑥実装は終えています。3本とも、止まっている場所は⑦かその手前です。そして3本とも、止めているのはAIではなく本人ゲートです。

• minaton: 値付けの方向そのものが未決
• pedia: Stripe価格・本番環境の設定・deploy・push、事業の方向
• tokyo-speed: Stripe Connect有効化・手数料率・法務・DNS

このコースの05で見た「AIが越えない線」がそのまま並んでいます。価格の最終決定、本番公開、外部への告知は本人にしかできません。AIは原価と選択肢を並べるところまでしかできません。3本の現在地は、その線が絵に描いた餅ではなく、実際に運用されていることの記録でもあります。

ここに書いていないこと

このレッスンは進捗ボードに書かれている事実だけで構成しています。各プロダクトで実際に何を迷ったか、値付けの候補としてどんな数字を検討したか、といった判断の中身は書いていません。

[要確認: minaton・pedia・tokyo-speedそれぞれで実際に迷った論点と検討した価格帯は、本人からの聞き取りが済み次第この節に追記する]

推測で埋めないのは、このレッスンが教えている型そのものです。事実と推測を混ぜた記録は、後で読み返したときに何が確認済みで何が仮説だったか分からなくなります。撤退基準を「手応えがあれば」で書かないのと同じ理由で、実録も分かっていることと分かっていないことを分けて書きます。

今日のまとめ

• AMPLの本気3本は、いずれも⑥実装を終えながら⑦値付けかその手前で止まっている
• 止めているのは技術ではなく本人ゲート。minatonは値付けの方向、pediaはStripe設定と事業方向、tokyo-speedはConnectと法務
• 撤退基準の「次の判定日」が具体的に書かれているかどうかで、そのプロダクトが実際にどこまで動いているかが分かる。pediaのように判定日が書かれている例と、minatonのように「要設定」のままの例が、同じボードの中に並んでいる

次のセクションはありません。ここまでで、撤退基準を先に書き、計測を実装と同時に入れ、原価の裾から値をつけ、6点セットで届け、本人ゲートの線を引き、そして実際に止まった記録まで見てきました。自分のプロダクトが今どの工程で止まっているか、進捗ボードと同じ形式で3行に書き出してみてください。段階、到達工程、本人ゲート。それが埋められないなら、埋められないという事実そのものが、次に何をすべきかを教えてくれます。