N2 · Crypto Product
不可逆性、署名、合成可能性という三つの制約のもとでプロダクト作りを学び直し、失敗経路も操作できる PRD とプロトタイプを作る。
この Track は、プロダクトマネージャー、デザイナー、転職を目指す人を対象とします。
前提は第 27 章の言葉です。ブロックチェーンを加えた Web2 プロダクトではなく、制約がまったく異なるプロダクトです。従来の手順の前提が失われているため、そのまま模倣できません。この Track では、三つの制約を設計時の標準の考え方にします。
この Track に向いている人
肩書きではなく、今取り組んでいる仕事を見てください。
長年 Web2 のプロダクトを作り、初めてオンチェーンの要件を受けると、慣れた方法が使えない。 事前検査、段階公開、ロールバック、サポートによる返金は、存在しないか、費用がまったく異なります。違和感はあっても、何が欠けているかを説明できません。
オンチェーンのチームで PRD を書いているが、公開のたびに未記載の失敗が起こる。 クリックしても反応しない、三回クリックする、成功表示の後も資金が届かない、意味の分からないポップアップに署名する。後から文書を補い、いつも問題の後を追っています。
デザインがウォレットのポップアップで止まっている。 最も重要な確認が、自分で制御できない画面で行われ、設計稿がそこで途切れています。
プロダクト職へ移りたくて、プロトタイプは描けるが、オンチェーンと通常のアプリの違いを説明できない。 面接で「この段階が失敗したらどうするか」と聞かれて、具体的な対応を答えられません。
オンチェーンの複雑さをすべて隠す方法を期待する場合は、注意してください。隠せる部分は限られ、残りは隠すのではなく、理解できる言葉へ置き換える必要があります。
前提
Part A の八章が必読です。三章は世界の捉え方、五章は仕事の方法を与えます。
| 必読の章 | この Track での役割 | 読まない場合 |
|---|---|---|
| 第 5 章 · Crypto は誰のものか | 秘密鍵、署名、誰が保管するか | 自分が保管者になったと気付かず機能を設計する |
| 第 6 章 · オンチェーン取引で何が起きるか | ファイナリティは瞬間ではなく曲線である | ブロックに含まれただけで成功を表示する |
| 第 9 章 · Smart Contract は何を変えたか | 合成可能性、更新、権限 | 他者の接続を通常ではなく例外と考える |
| 第 20 章 · Tokenomics | インセンティブはプロダクトの一部である | 望まない行動に報酬を与える規則を作る |
| 第 23 章 · オンチェーンデータ | 自分で取得することと、定義に関する六つの問い | 公開後に見るべき三つの数字を選べない |
| 第 27 章 · Crypto Product はなぜ異なるか | Track の主軸：三つの制約、六状態、十の失敗経路、四種の署名 | 後の内容を結び付ける土台がない |
| 第 28 章 · Crypto Growth の本質 | 買えるのは最初の四層で、継続利用は買えない | 人を受け止められないプロダクトへ報酬を積む |
| 第 30 章 · PMF を見つけるには | 補助金を除いた四つの兆候 | 補助金が作る曲線を需要の証拠と考える |
なぜこの八章なのか。 オンチェーン PRD の各節と対応します。主経路は第 6・27 章、署名と承認は第 5・27 章、合成可能性の仮定は第 9 章、報酬規則は第 20・28 章、受け入れ指標は第 23・30 章です。
一つの Lab は必ず実践してください。第 27 章の「DApp の初回利用を段階ごとに撮影する」です。特に最後の、与えた承認を確認して取り消す段階が重要です。 実践した人としなかった人では、承認要件の既定値がまったく異なります。
学ぶ内容
十のテーマを五群に分けます。アイデアから公開まで、実際の機能開発の順序に沿っています。
- 誰のために作るか
- 仕組みもプロダクトの一部
- 三つの制約下の画面
- 検証と成長
- AI をプロダクトに加える
| 群 | 含むテーマ | 解決する問い | 接続する章 |
|---|---|---|---|
| 誰のために作るか | Market Research、User Research | 誰のどんな困り事を解決し、どう確認するか | 第 25、30 章 |
| 仕組みもプロダクトの一部 | Protocol Logic、Tokenomics | 基礎の規則が画面の選択肢をどう制約するか | 第 9、20 章 |
| 三つの制約下の画面 | Wallet UX、PRD | 不可逆性、署名、合成可能性のもとでどう要件を書くか | 第 27 章 |
| 検証と成長 | PMF、Growth、Analytics | 公開後に何を測り、補助金に騙されないか | 第 23、28、30 章 |
| AI をプロダクトに加える | AI Product | 何をモデルに任せ、どこに境界を置くか | 第 31、32、34 章 |
この五群で学び直すべき三つのこと
仕組みの群は、Web2 のプロダクト担当が省きやすく、影響も大きい部分です。 Web2 ではバックエンドの細部をエンジニアに任せられますが、ここではプロトコルの規則がプロダクトの規則です。清算の閾値、手数料の分配、パラメーターの変更権限、コントラクトの更新可否は、画面に何を表示し、警告し、禁止するかを直接決めます。清算の発動条件を知らなければ、貸付プロダクトのリスク表示は書けません。
画面の中心は、手順の短縮より、十分な理解を確保することです。 第 27 章の「署名を一回にまとめ、承認額と有効期限を限定し、自分の画面で分かる言葉へ翻訳する」を標準にします。まとめてクリック数を減らしても、理解を減らしてはいけません。 六状態、十の失敗経路、四種の署名を習慣にし、取引要件では毎回この三表を確認します。
AI は、機能を論じる前に境界を描きます。 モデルの用途には、説明（コントラクト呼び出しの説明、文書の要約）と実行（行動の決定、資金の操作）があります。前者の誤りは誤解、後者の誤りは金銭の損失を招きます。Crypto OS における AI の位置の等級と、第 34 章の権限表は、付録ではなく必須の要件です。
第 27 章の十項目です。ネイティブトークンなし、残高不足、承認不足、スリッページ超過、先回り実行、メモリプールで停滞、実行失敗、利用者による取消、混雑、チェーン再編です。
この Track ではすべての PRD に必須の節です。十項目のうち七つは署名前に防げるため、署名前の追加確認は、オンチェーンのプロダクトで費用対効果が最も高い対応の一つです。
モデルにオンチェーン PRD を書かせると、この節を構造的に省くことが確認されています。時々忘れるのではなく、学習したテンプレートに存在しないのです。 この一覧は人が用意する必要があります。
何を承認しているかを理解するための利用者の注意と、それを伝えるための画面領域や手順です。
操作コストとは別の予算です。よくある失敗は、理解のためのコストを削って操作コストを減らすことです。三回の署名を一回にまとめても、含まれる内容を自分の画面で説明しません。
境界を越えたかは、利用者が後から承認内容を知ったら、騙されたと感じるかで判断します。感じるなら、省いたクリックは理解から借りたものです。
卒業成果物
署名、失敗、取消の全経路を含む完全な PRD と、操作可能なプロトタイプ。
成果物の三つの言葉、署名、失敗、取消に注意してください。主経路に付け足す部分ではなく、作品が検証される中心です。主経路は誰でも描けます。
卒業プロジェクトとの違い。 Technical の卒業プロジェクトは、他者が開いて動かせるシステムを作り、実現可能性を示します。この Track は実装不要ですが、望ましくない経路をすべて設計し、現実でどう失敗するかを理解していることを示します。
受け入れ基準は五つです。
六つの取引状態すべてに画面と文言を用意し、成功を表示する状態と判断基準を明記する。
構築、署名待ち、送信済み、確認待ち、確認済み、最終確定を省きません。確認待ちには現在の確認数と必要数を表示します。確認不足のまま成功と表示すると、この項目は不合格です。
十の失敗経路ごとに、発動条件、利用者に見える文言、プロダクトの対応を書く。
「分かりやすい通知」ではなく、実際の文章を書きます。署名前に防ぐ項目も示します。その数が PRD の品質指標です。
各署名に種類、金額、有効期限を示し、自分の画面で一文の説明を付ける。
送金、承認、メッセージ、オフライン注文の四種類を区別します。承認は必要な金額と有効期限に限定し、過去の承認を確認・取消できる場所を設けます。無制限の承認を既定とする案は不合格です。
主経路だけでなく、失敗経路もプロトタイプで操作できる。
最低でも、ネイティブトークンなし、ウォレットで利用者が取消、メモリプールで停滞の三経路を実行できます。正常系しか動かないプロトタイプは、この Track の訓練対象を扱っていません。
「ここでは取消が存在しない」の説明と、公開後の観測計画を各一ページ付ける。
前者では、利用者が期待する取消、チェーン上で成立しない理由、代わりの事前対応を説明します。後者では、見るべき三指標、定義、継続利用をどの層で数えるかを書きます。この二ページが、プロダクト能力と調査能力を接続します。
達成したかを判断するには
達成していれば、各署名の四種類の分類、金額、有効期限、最悪時の損失を説明できます。
未達の典型は、承認署名と送金署名を混同する、必要な承認額を説明できない、無制限を選択したことに気付いていない、です。
第 27 章の基準は、「署名後の最悪の事態は何か、誰が損失を負うか」を書けない機能は公開すべきでないというものです。
達成の目安は七項目前後で、それぞれ残高検査、承認額検査、取引シミュレーション、入力上限など、方法を説明できます。
中心的な指標なのは、離脱、損失、問い合わせを同時に減らすためです。失敗する取引を署名前に止めれば、手数料だけでなく挫折も防げます。
未達の典型は、失敗してからエラー表示するだけの事後対応です。Web2 では通常、失敗が無料なので許容できても、ここでは失敗しても手数料がかかります。
達成していれば、アクティブアドレス数ではなく、第 28 章の四層の第三・第四層、報酬なしの有料操作を完了したアドレス、またはキャンペーン後も戻るアドレスを使い、取得方法と定義を説明できます。
未達なら第一層や使用回数を報告します。どちらも報酬施策でよく見えるため、情報を与えません。
見落とされがちな指標は初回利用の完了率です。失敗経路の処理品質が最も直接的に表れます。
達成していれば、アドレス単位か人単位かの制限、まとめた呼び出しへのリスク管理、集約サービスを一人として数えるか、画面の事前検査を迂回した結果を個別に検討できます。
これは第三の制約を問います。第 27 章の例では、人が独自画面から一件ずつ呼ぶと仮定したプロトコルが、数か月後に他者のシステムへ接続され、三つの仮定を同時に失いました。
「呼び出すのがコードでも、この仮定は成立するか」を PRD のチェックリストへ入れてください。
正解は一つではありません。次を確認します。
- 六状態の文言は具体的な文章ですか。「読み込みを表示」のような指示だけですか。
- 失敗への対応に、チェーンでは実現できないものはありませんか。よくある例は「自動再試行して手数料を返す」です。
- 承認額と有効期限は具体的な決定規則がありますか。「必要分だけ」だけですか。
- プロトタイプで失敗経路へ進めますか。
- 主要な三つのウォレットでの表示差にどう対応するかを書いていますか。
- 三つの観測指標をどこで計測するか、エンジニアに分かりますか。
有効な検証は、質問を受けずに PRD だけを読んで、取引状態機械を描いてもらうことです。想定と異なれば、その欠落部分が公開後の事故になりやすい箇所です。
よくある誤解
誤解 1：オンチェーンのプロダクトを、ウォレットログイン付き Web2 と考える。
最も根本的な誤解で、他の問題を生みます。ファネル、段階公開、サポート手順をそのまま移し、成立しない場所を後から補います。
三つの制約を機能差と扱っている点が誤りです。それらは機能ではなく環境です。すべての判断は、その環境の中で行います。書く前に、誤りを直せるか、サーバーが利用者の代わりに動けるか、インターフェースや利用者を制御できるかを確認します。すべて否なら、慣れた手順の前提はありません。
誤解 2：Token と報酬でプロダクトの穴を埋める。
継続率が低いからポイントを配り、転換率が低いからエアドロップへの期待を加えると、数字はすぐによく見えます。
第 28 章の通り、報酬で買えるのは初回利用で、継続利用はプロダクト自身が作ります。 最初の四層は買えても、第五層は買えません。第五層がゼロなら、最初の四層が強いほど後の崖も急になります。
順序を守り、第五層で人を受け止められるようにしてから、最初の四層で人を集めます。 プロダクト担当が確保すべき予算は、最初の手数料の肩代わり、失敗経路の整備、三回の署名を一回にまとめるなど、効果が遅く帰属を測りにくいものになりがちです。
誤解 3：正常系だけをプロトタイプに描く。
レビューでは滑らかに見えても、公開後の問い合わせは、デモにない場所へ集中します。
オンチェーンでは望ましくない経路も通常の状態です。 手数料不足、承認不足、スリッページ超過、ポップアップで迷って取消などは毎日起こり、実際の離脱や損失につながります。
まず三つの失敗経路を見せ、その後で主経路を見せます。 レビューの順序を変えるだけで、案の弱い部分がすぐ分かります。
誤解 4：利用者数を需要の証拠とする。
上昇する曲線を見て、利用者が機能を好んでいると述べても、その期間に報酬施策が動いているかもしれません。
第 30 章の通り、Web2 のすべての PMF の兆候は、ここでは補助金で作れます。 利用者数、継続率、自然成長、有料転換も例外ではありません。
補助金の影響を除き、自費の継続利用、支払意思、自然流入、継続の深さの四つを見ます。第四が最も作りにくい兆候です。自分の資金を一週間コントラクトに置く行動は、百回のクリックより多くを示します。
次に進むには
まず二つを実践してください。第 27 章の撮影 Lab（最後の承認点検を含む）と、第 30 章の五回の実際の対話です。前者は既定の考え方、後者は推測で要件を立てない姿勢を鍛えます。
卒業プロジェクトの Crypto Research OS も実践します。 自分でデータを取れなければ、公開後に何が起きたかも他者の話に頼るしかありません。調査能力は加点項目ではなく、観測計画の前提です。
AI に関する二ページも読んでください。Crypto OS における AI の位置が能力等級と安全経路を定義し、第 34 章が権限表の書き方を示します。モデルが資金に触れる要件は、必ずここから書き始めます。
組み合わせられる Track：
| 組合せ | 相性の理由 |
|---|---|
| N3 · Crypto Growth & Operations | プロダクトは第五層、成長は最初の四層を担当します。同じファネル表を使い、別々にすると責任を押し付けやすくなります |
| N1 · Crypto Research & Investment | 観測計画は調査能力です。自分でデータを取れれば、競合判断で他者の分析を待つ必要がありません |
| N5 · Crypto Founder | 創業者の最初の文書は、この卒業成果物に Token の必要性の論証を加えたものです |
実装まで進むなら、T1 · EVM Engineerと、フロントエンド連携を扱う T13、T14が最も近い次の段階です。署名と状態処理の実装が具体的になります。