HENKAKU Initiation 開発計画

状態

元メモ(思いつき段階)を開発計画に整理したもの。フェーズ 0〜1 の範囲は実装前提、フェーズ 2 以降は検証結果を見て確定する。 実装着手時は、各フェーズごとに実装計画(タスク分解・テスト計画)を別途作成する。

1. 背景と目的

現在のオンボーディングは Dework に依存している。ここでのオンボーディングとは次の二つを指す。

• Allowlist に追加される
• 最初の HENKAKU トークンを受け取る

HENKAKU トークンは JIBOT などへのアクセスも含めてコミュニティ参加の鍵になっている。単なる登録作業ではなく、コミュニティに入る小さなイベント「Initiation」として入口を設計し直す。

目的(検証したい仮説)

• ゲーム的な Initiation 体験が、Dework ベースの手続きより参加を生むか
• 質問箱 + AI 回答案が、人の参加のきっかけとして機能するか

自動化は最初から広げず、体験の手応えを見てから増やす。承認・配布は当初は人が行う。

2. 既存資産: omise-interface /shiniri の機能

omise.henkaku.org/shiniri(henkaku-center/omise-interface)は「新入り」向けのウォレットセットアップページで、次の 3 ステップを案内している。

1. MetaMask ウォレット接続
2. Polygon ネットワークへの切り替え(switchNetwork)
3. HENKAKU トークン(ERC20)をウォレットのアセット一覧に追加(wallet_watchAsset)

この機能は本アプリの Initiation フロー冒頭に同等機能として再実装する(移植ではない)。既存実装は wagmi 0.x + Chakra UI と古く、新スタックでは接続 UI ライブラリと wagmi v2 で同じ体験を作る方が安全で速い。

3. スコープ

MVP-1 に含める

• ウォレット接続と署名認証(SIWE)
• ウォレットセットアップ導線(shiniri 相当: Polygon 切り替え + HENKAKU トークン追加)
• Initiation 画面: いくつかの質問・クエスト、進捗の保存
• チェックイン
• Allowlist 追加と HENKAKU 配布の「申請」(承認・配布は人が手動で行う)

MVP-1 に含めない

• Allowlist 更新・トークン配布の自動実行
• コミュニティ向け質問箱(投稿・閲覧・人による回答)
• AI による関連資料探索と回答案の作成
• 何でも実行するエージェント型 AI
• ポイント・報酬設計(回答を増やすためのインセンティブ設計はしない)
• Dework の全面置き換え(入口部分のみ)

質問箱はフェーズ2、AI 回答案はフェーズ3で検証結果を見て着手する。

4. アーキテクチャ方針

• ホスト: Vercel。常時稼働プロセスは置かず、すべてリクエスト駆動(API Routes / Server Actions)で構成する。AI が止まっていても投稿と人の回答は続く。常時稼働が本当に必要になった時点で VPS を検討する。
• 技術スタック案: Next.js(App Router)/ TypeScript / wagmi v2 + viem / SIWE。
• DB: Supabase / Google Spreadsheet / VPS 上の PostgreSQL を候補とし、フェーズ0で選定する。DBアクセスは Repository 層に隔離し、スキーマと migration はリポジトリで管理する。Google Spreadsheet は管理用ミラー・エクスポートとして使う案を含め、VPS は運用要件が明確になった場合に再評価する。
• AI: さくらの AI Engine。利用上限を設け、上限到達時は従量課金に移行せず停止する。利用量の単位・上限・月次リセット・停止時のふるまいは未決定事項としてフェーズ3開始前に決める。
• チェーン: Polygon(既存 HENKAKU トークンに合わせる)。
• OSS: リポジトリは公開し、コミュニティメンバーが機能を追加できる形にする。

データモデル(最小案)

• members — ウォレットアドレス、表示名、初回認証日時。アドレスは正規化して一意に扱う。
• initiation_progress — 質問・クエストごとの回答/完了状態
• applications — Allowlist 追加・トークン配布の申請。審査状態(pending / needs_info / approved / rejected)、Allowlist 状態(pending / added / failed)、配布状態(pending / sent / failed)を分けて持つ。重複申請を防ぐキー、配布トランザクションID、理由、作成・更新日時を記録する。
• application_events — 申請状態の遷移、実行者、時刻、理由、トランザクションIDを記録する監査履歴
• checkins — メンバーのチェックイン履歴
• questions / answers — 質問箱。回答には種別(公式に決まっていること / メンバーのアイデア / 意見が分かれている / 古い可能性あり)と AI 回答案フラグを持たせる
• ai_usage — AI 利用量(計測期間・単位は未決定)

認証・ウォレット導線

• SIWE メッセージはサーバーが発行する一回限りの nonce と有効期限を持ち、domain、URI、chain ID、署名対象アドレスをサーバーで検証する。
• 認証後は HttpOnly・Secure・SameSite 属性を付けたサーバーセッションを発行する。ログアウト、アカウント変更、チェーン変更時はセッションを無効化する。
• 管理画面は一般メンバーのセッションと別の管理者ロールで保護し、申請一覧・承認操作を一般メンバーに公開しない。
• ウォレット接続は MetaMask を基準にしつつ、対応ウォレットを明示する。Polygon が未登録の場合は wallet_addEthereumChain を案内し、接続拒否・ネットワーク切替拒否・アカウント変更・未対応ウォレットを復帰可能なエラーとして扱う。
• wallet_watchAsset の結果はトークン表示の補助情報として扱い、追加成功を認証や Initiation 完了の条件にしない。トークンコントラクトアドレス、chain ID、symbol、decimals、ロゴURLは設定値として固定する。

5. フェーズ計画

フェーズ 0: 技術検証(スパイク)

体験を作り込む前に、リスクの高い部分だけ小さく確かめる。

• [ ] ウォレット接続 + SIWE 署名認証が成立することを確認する(domain、nonce、期限、セッション、アカウント/チェーン変更を含む)
• [ ] Polygon 切り替えと wallet_watchAsset によるトークン追加(shiniri 相当)を新スタックで動かす。拒否・未対応・チェーン未登録時から復帰できることを確認する
• [ ] さくらの AI Engine を API から呼び、利用量の取得・上限判定ができるか確認する
• [ ] DB候補(Supabase / Google Spreadsheet / VPS上のPostgreSQL)を比較し、接続・migration・バックアップ/復旧・同時更新の扱いを確認して選定する

完了条件: 上記が全部つながった捨ててよいプロトタイプが 1 つ動く。

フェーズ 1: Initiation MVP-1

• [ ] Initiation の質問・クエスト内容を決める(紙・画面で先に定義)
• [ ] ウォレットセットアップ導線(接続 → Polygon 切り替え → トークン追加)
• [ ] 質問・クエスト画面と進捗保存
• [ ] チェックイン
• [ ] Allowlist 追加・HENKAKU 配布の申請フォームと、承認者が申請一覧を見られる画面(承認・配布の実行は人)
• [ ] 手動運用フロー(誰が承認し、どう配布するか)を文書化する

完了条件: 新入りが自分で Initiation を完走し、申請が承認者に届き、人手で Allowlist 追加とトークン配布まで一巡できる。

フェーズ 2: 質問箱(MVP-2候補)

• [ ] 質問の投稿・閲覧・回答(まず人だけで回る形)
• [ ] 未回答の質問の可視化
• [ ] 回答の状態表示(公式 / アイデア / 意見が分かれている / 古い可能性)
• [ ] 匿名投稿・表示名の扱いを決める(ウォレットは確認しつつ表示名は伏せる案を含めて)

完了条件: AI なしで質問→人の回答→蓄積のループが回る。

フェーズ 3: AI 回答案(質問箱の検証後)

• [ ] 過去の議論・ドキュメントの探索と回答案生成(AI は回答案・参考情報の提示まで。確定回答は人)
• [ ] 利用上限管理と停止時のふるまいを、フェーズ3開始前に決めた仕様に沿って実装する
• [ ] AI 停止中も投稿・人の回答が普通に続くことを確認する

フェーズ 4: 検証結果を見て拡張

体験として面白いか、実際に参加が生まれるかを見てから着手する。

• アクティブメンバーの可視化(チェックイン・回答・補足を参加として扱う)
• Allowlist 更新・トークン配布の段階的自動化
• FAQ・ナレッジベース化(AI の回答を正解として固定しない)

6. セキュリティ・運用

• 重要な処理(Allowlist 更新、トークン配布)はアプリ本体から分離し、当初は人の手動承認・手動実行にする
• トークン配布の権限を持つ鍵・アカウントを限定する
• 申請の承認フローと承認者を明文化する(フェーズ 1 の成果物)
• OSS として公開する前提でコードレビューを回し、配布まわりを自動化する段階で監査を検討する
• ウォレットアドレス・表示名・質問内容のプライバシー方針をデータ収集開始前に決める

7. 成果の見方(仮)

• Initiation の完走率と、完走からトークン受領までの所要時間
• 質問箱の投稿数・人による回答率・未回答の滞留
• チェックインの継続(Initiation 後に戻ってくるか)

数値目標と判定基準は未決定事項として定め、まずは「体験として面白いか」「人の参加が生まれたか」を定量・定性の両面で見る。

8. オープンクエスチョン

• Dework から何を置き換え、何を残すのか
• Initiation の質問・クエストの中身と、ゲーム化の度合い
• 最終確認する人と承認フローの具体
• Allowlist 更新とトークン配布の権限分離の方法
• ウォレット・表示名・質問内容のプライバシーの扱い
• FAQ・ナレッジの状態と古さの表示方法
• さくらの AI Engine の利用枠・コストの実際
• Vercel と VPS の境界(常時稼働が必要になる条件)
• 参加の成果指標の置き方

未決定事項

• プライバシー方針: 公開範囲、表示名とウォレットの紐付け、匿名投稿、保存期間、削除・訂正、AI への送信範囲をデータ収集開始前に決める。
• AI 利用上限: リクエスト数・入力/出力トークン・embedding 回数のどれを計測単位にするか、月次リセットのタイムゾーン、同時実行時の上限超過、429/障害時の扱い、費用上限をフェーズ3開始前に決める。
• 検証指標とテスト条件: イベント計測、完走率・回答率の分母、Deworkとの比較方法、観察期間、数値目標、継続/中止の判断基準、定性フィードバックの取り方を決める。

9. 次の一歩

• [ ] Initiation の最小フロー(質問・クエスト含む)を紙や画面で定義する
• [ ] フェーズ 0 の技術検証に着手する(ウォレット接続 + SIWE + shiniri 相当機能)
• [ ] 質問箱の投稿・閲覧・回答の最小モデルを決める
• [ ] Allowlist とトークン配布を手動で回す運用を決める
• [ ] AI の資料探索と回答案作成を小さく試す
• [ ] 最初に分離すべき処理(配布権限まわり)を洗い出す