はじめに
dAppsの要求定義を整理しました。
実はこれは途中経過で、Vibe Codingに最適なNext.js & Claude Codeのテンプレートを作成中です。
ただ、これをPromptやdocsファイルとしてそのままAIに与えるだけでも、Vibe Codingの効率化に役立ちます。
本記事では、実際のdApps開発で培った知見を基に、MVP開発に特化した要求定義書を公開します。
この要求定義書は、開発の初速を重視し、小規模チームでも効率的にdAppsを構築できるよう設計されています。
なお、この要求定義書を基にしたNext.js & Claude Codeのテンプレートは、2025年8月中に公開予定です。
対象読者
本記事は以下の方々を想定しています。
- Web3のエンジニア・PM: dApps開発の効率化や技術選定に悩んでいる方
- ハッカソンのビルダー: 短期間で機能するdAppsを構築したい方
- Vibe Codingの最適な構成について模索している方: AIツールを活用した開発フローを構築したい方
特に、複雑な機能よりもスピードを重視し、ブロックチェーンネイティブな機能に集中したい開発者に有用な内容となっています。
また、FBやTipsをシェアは大歓迎なので、ぜひお気軽にコメントしてください。
「ここはバッドプラクティスでは？」などのツッコミもぜひ。
開発方針の解説
MVP重視の迅速開発アプローチ
前提として、MVPを素早くマーケットに投入することをゴールとしています。
よって、web2のDB管理や複雑な機能は排除し、ブロックチェーンネイティブな機能に集中することで開発工数を最小化します。
小規模チームでの効率的な開発を実現するため、機能の取捨選択を厳格に行い、本質的でない機能は後回しにします。本質的な価値提供に不要な機能要件は積極的に切り捨てます。
外部ツール活用によるコスト削減戦略
web3 の最大の長所は、オンチェーンデータが世界で共有されていることです。これは実質的に DB や Web API が自動で共有されているのと同じ効果があります。そのため、多くの機能を外部ツールに委託することで、内製開発のコストを大幅に削減できます。
VM別のリポジトリ分離の実践
dApp一つにつき、一つのVMで対応します。EVM互換であれば対応は容易ですが、Solana、AO、Suiのように異なるVMのチェーンに対応する場合は、リポジトリを分けるべきです。
コード資産の共有は手動でのコピペで十分対応可能です。ウォレットやTxのハンドリングについて、抽象化したアダプターの実装なども試しましたが、開発初速・保守性を大きく損なうと実感しました。
技術スタック選定の理由と構成
主なライブラリ
技術選定では「AIフレンドリーな構成」を重視しています。十分に成熟した「枯れた技術」を採用し、Type SafetyでシンプルなライブラリのAPIを重視することで、AIツールとの親和性が高く、開発効率を最大化できる技術構成としています。
具体的な構成：
- 言語: TypeScript
- フレームワーク: Next.js App Router
- スタイリング: TailwindCSS + shadcn/ui（radix-uiとlucide-reactも自動的に併用）
- toast: sonner（react-hot-toast等は併用しない）
- 状態管理: zustand + react-hook-form
- ホスティング: Vercel
- 開発環境: GitHub + Claude Code + VSCode（Cursorも併用） + pnpm
- web2 DB: Supabase or Firebase（必要であれば。ただし、使用しないに越したことはない）
- Data Fetch: @tanstack/react-query（標準のFetch APIを使用するため、axios等は不要）
このアプローチにより、開発チームは本質的な機能開発に集中でき、技術的な複雑さを最小限に抑えながら、堅牢で保守性の高いdAppsを構築できます。
ディレクトリ構成
シンプルなfeatureベースのディレクトリ構成を採用します。複雑な階層構造は避け、機能ごとにファイルを整理することで、開発効率とコードの可読性を向上させます。
ディレクトリ構成については、次の記事にて詳述しますが、src/は主に下記となります。
src/
├── app/ # 🚀 Next.js App Router - ルーティングのみ
│ ├── mint/
│ │ └── tag:qiita.com,2005:PublicArticle/2054055/page.tsx # 動的ルート
│ ├── about/page.tsx
│ ├── profile/page.tsx
│ ├── globals.css # グローバルスタイル
│ ├── layout.tsx # ルートレイアウト
│ └── page.tsx # トップページ
│
├── components/ # 🧩 再利用可能コンポーネント
│ ├── layout/ # レイアウト専用
│ │ └──Header.tsx
│ │ └──HeaderNavigation.tsx
│ │ └──Footer.tsx
│ ├── providers/ # Context Provider
│ ├── shared/ # 機能横断共有
│ └── ui/ # shadcn/ui + v0コンポーネント
│
├── constants/ # 📋 定数・設定
│ ├── chain-info/ # ブロックチェーン情報
│ ├── contracts/ # スマートコントラクト情報
│ ├── meta/ # SEO・SNS メタ情報
│ │ ├── brand-copy.ts
│ │ ├── site-metadata.ts
│ │ ├── social-links.ts
│ │ ├── external-links.ts
│ │ └── team-members.ts
│ ├── common/ # 汎用定数
│ │ └── social-platforms.ts
│ └── index.ts # 統一エクスポート
│
├── features/ # 🎛️ 機能別モジュール
│ └── mint/ # Mint機能パッケージ
│ ├── components/ # 機能専用コンポーネント
│ ├── hooks/ # 機能専用フック
│ ├── types/ # 機能専用型定義
│ └── utils/ # 機能専用ユーティリティ
│
├── hooks/ # 🎣 グローバル共有フック
├── lib/ # 📚 ライブラリ・ユーティリティ
├── stores/ # 🏪 Zustand状態管理
├── types/ # 📝 グローバル型定義
└── utils/ # 🔧 グローバルユーティリティ
機能要件の解説
dAppsにおいて実装する機能は実は限られており、パターン化することができます。
大雑把に言えば、ウォレットを接続して、ブロックチェーン上のデータ（主にトークン）に対してCRUDを行うだけです。Web2 DBやSNSとの連携は実は必須ではなく、あくまでアプリケーションのパフォーマンス向上やグロースハック施策のための追加実装です。
さらに言えば、Web3特有の多くの機能は内製化せず、外部に委託することができます。なぜなら、ブロックチェーンとは「世界で一つのDB & Web API & ストレージを共有する」仕組みだからです。
例えば、NFTコレクションの表示はOpenSea上のページへ飛ばし、トークンのスワップはUniSwapのスマートコントラクトを呼び出すなどが可能です。既存の成熟したエコシステムという巨人の肩に乗る方が、基本的にはベストプラクティスと言えるでしょう。
主要機能の構成
-
ウォレット接続: 接続・切断機能、接続ステータスのグローバル状態管理、接続状態のキャッシュによるUX向上
-
NFT Mint機能: 簡単Mint（決められた設定でワンクリック）、カスタムMint（ユーザーがフォームで設定）、操作状態管理
-
NFTデータ表示: コレクション一覧、コレクション詳細、NFTアイテム詳細
-
トークンClaim機能: ユーザーに割り当てられたトークンの確認・Claim機能
-
プロフィールページ: ユーザー情報の表示
-
SNSシェア機能: Twitterシェアボタンによるグロースハック施策、SNS認証不要での成果シェア
これらの機能に集中することで、開発工数を最小化しながら、ユーザーにとって価値のあるdAppsを構築できます。
要求定義書の全文
原文
以下が、dApps MVP開発のための要求定義書全文です。
AIツールに与えることで、効率的な開発が可能になります。
ただ、実際に使用する際は英語に翻訳してから与えることをお勧めします。
（「Claudeは英語に最適化されているため英語使用が推奨」とAnthorpic公式が度々言及しています）
また、文章の書き方自体も冗長なので、圧縮することが望ましいです。
# dApps 要求定義・機能仕様書
## 開発方針
### **MVP 重視の迅速開発**
最小限の機能で素早くマーケットに投入し、小規模チームで効率的な開発を実現します。web2 の DB 管理や複雑な機能は排除し、ブロックチェーンネイティブな機能に集中することで開発工数を最小化します。
### **外部ツール活用によるコスト削減**
web3 の最大の長所は、オンチェーンデータが世界で共有されていることです。これは実質的に DB や Web API が自動で共有されているのと同じ効果があります。そのため、多くの機能を外部ツールに委託することで、内製開発のコストを大幅に削減できます。
具体的な例は別記事にて紹介します。
### **VM 別のリポジトリ分離**
dApp 一つにつき、一つの VM で対応します。EVM 互換であれば対応は容易ですが、Solana、AO、Sui のように異なる VM のチェーンに対応する場合は、リポジトリを分けるべきです。コード資産の共有は手動でのコピペで十分対応可能です。
ウォレットや Tx のハンドリングについて、抽象化したアダプターの実装なども試しましたが、開発初速・保守性を大きく損なうと実感しました。
## 技術スタック
### npm ライブラリ
**AI フレンドリーな構成**:
十分に成熟した「枯れた技術」を採用し、Type Safety とシンプルな書き方を重視します。これにより、AI ツールとの親和性が高く、開発効率を最大化できる技術構成となっています。
このアプローチにより、開発チームは本質的な機能開発に集中でき、技術的な複雑さを最小限に抑えながら、堅牢で保守性の高い dApps を構築できます。
- **言語**: TypeScript
- **フレームワーク**: Next.js App Router
- **スタイリング**: TailwindCSS + shadcn/ui（radix-ui と lucide-react も自動的に併用される）
- toast: sonner（react-hot-toast 等は併用しない）
- **状態管理**: zustand + react-hook-form
- **ホスティング**: Vercel
- **開発環境**: GitHub + Claude Code + VSCode + pnpm
- **web2 DB**: Supabase or Firebase（必要であれば。ただし、使用しないに越したことはない）
- **Web ライブラリ・API**: チェーンごとに用意するので、それぞれについて記事を書きます。本稿では扱いません
- **Data Fetch**: @tanstack/react-query。（標準の Fetch API を使用するため、axios 等は不要）
### ディレクトリ構成
- シンプルな feature ベース
## 機能要件
実は dApps において実装する機能は限られており、パターン化できます。
大雑把に言えば、ウォレットを接続して、ブロックチェーン上のデータ（主にトークン）に対して CRUD を行うだけ。
Web2 DB や SNS との連携は実は必須ではなく、あくまでアプリケーションのパフォーマンス向上やグロースハック施策のための追加実装です。
さらに言えば、Web3 特有の多くの機能は内製化せず、外部に委託することができます。何故なら、ブロックチェーンとは「世界で一つの DB & Web API & ストレージを共有する」仕組みだからです。
例えば、NFT コレクションの表示は OpenSea 上のページへ飛ばす、トークンのスワップは UniSwap のスマートコントラクトを呼び出すなどが可能であり、また、既存の成熟したエコシステムという巨人の肩に乗る方が基本的にはベストプラクティスです。
### 1. ウォレット接続
- ウォレット接続・切断機能
- 接続ステータスのグローバル状態管理
- 接続状態のキャッシュによる UX 向上
### 2. NFT Mint 機能
- **簡単 Mint**: 決められた設定でワンクリック Mint
- **カスタム Mint**: ユーザーがフォームで設定項目を入力して Mint
- **操作状態管理**: Mint 処理のステータス表示、エラーハンドリング、成功時の通知
### 3. NFT データ表示
- **コレクション一覧**: Collection Name、Banner Image、Mint Status、Description 等を表示
- **コレクション詳細**: 個別ページで Collection 情報、Total Minted、NFT 一覧等を表示
- **NFT アイテム詳細**: Name、Image、Owner、Creator、Trade 履歴等を表示
### 4. トークン Claim 機能
- ユーザーに割り当てられたトークンの確認・Claim 機能
### 5. プロフィールページ
- ユーザー情報の表示
### 6. SNS シェア機能
- Twitter シェアボタンによるグロースハック施策
- SNS 認証不要で、Mint・Claim 等の成果を簡単シェア（これなら Firebase や Supabase が不要になるため）
## セキュリティ要件
ウォレットによってセキュリティはある程度担保できるが、アプリケーション側でも対応するべき。
### スマートコントラクト通信のセキュリティ
- スマートコントラクトの ABI やアドレスを環境変数やコンフィグファイルで適切に管理し、フロントエンドでの改ざんを防ぐ仕組みを構築する
- トランザクション実行前に、ユーザーが実行しようとしている操作の概要を dApps 側で分かりやすく表示し、ウォレットの署名画面と併せてユーザーの理解を促進する
- 想定外のネットワークへの接続や、設定されていないコントラクトアドレスへのアクセスを防ぐためのフロントエンド側での事前チェック機能を実装する
- トランザクション実行後の結果検証や、エラー時の適切なユーザーへの通知機能を実装する
### ウォレット情報の適切な管理
- ウォレットアドレスや署名情報などの機密データを、フロントエンドのローカルストレージに長期間保存することを避ける
- セッション管理においてウォレット接続状態を適切に管理し、不要な権限の永続化を防ぐ
- ユーザーがアプリケーションから離れる際の自動ログアウト機能や、セッションタイムアウトの設定を行う
- 複数のウォレットプロバイダーを使用する場合の、各プロバイダー固有のセキュリティ要件への対応を行う
## パフォーマンス最適化要件
### NFT データの効率的な取得・表示
- 大量の NFT コレクションやアイテムを表示する際に、ページネーション機能を実装してデータ取得量を制限し、初期表示速度を向上させる
- ユーザーがスクロールやページ遷移を行う際の、段階的なデータ読み込み機能を実装する
- NFT メタデータの取得において、失敗した場合のリトライ機能や、タイムアウト設定を適切に行う
- 頻繁にアクセスされる NFT コレクション情報については、適切なキャッシュ戦略を実装して再取得の頻度を最小化する
### 画像・メタデータ表示の最適化
- IPFS 経由での画像取得時の遅延を軽減するため、複数の IPFS ゲートウェイを使用したフォールバック機能を実装する
- Arweave 経由でのメタデータ取得時において、Arweave ゲートウェイの応答速度を考慮した最適化処理を実装する
- IPFS、Arweave、従来の HTTP URL など、異なるプロトコルでのリソース取得を統一的に処理し、各プロトコルの特性に応じた最適化を行う
- 分散ストレージからのデータ取得失敗時に、代替のゲートウェイやプロトコルへの自動切り替え機能を実装する
- 画像の遅延読み込み（lazy loading）機能を実装し、ユーザーの表示領域に入った画像のみを優先的に読み込む
- 画像サイズの最適化と圧縮を行い、通信量を削減してユーザーエクスペリエンスを向上させる
- 画像読み込み中のプレースホルダー表示や、読み込み失敗時の代替画像表示機能を実装する
- Arweave と IPFS の両方からメタデータを取得する場合の、並列処理による読み込み速度の最適化を行う
### ウォレット接続状態の最適化
- ウォレット接続状態をアプリケーション全体で効率的に管理し、不要な再接続処理を避ける
- ユーザーがアプリケーションを再訪問した際の、過去の接続状態の復元機能を実装する
- 複数のタブやウィンドウでアプリケーションを使用する際の、接続状態の同期機能を検討する
- ネットワーク切り替え時の自動再接続機能や、接続エラー時の適切な再試行機能を実装する
## スコープ外要件
### 除外する機能
- **ユーザー認証**: メールアドレスや SNS ログイン等の web2 認証は排除（ウォレット接続に一本化）
- **UI/UX 拡張**: ライト・ダークモード切り替え、多言語対応
- **web2 DB 機能**: メールアドレス登録、その他 DB 管理を必要とする機能
- **外部ツール機能**: ウォレット、ブロックエクスプローラー、NFT マーケットプレイス等の自社開発
- **リッチ UI**: 複雑でリッチなフロントエンドや CSS（シンプルな UI で完結）
### 除外理由
開発工数の肥大化を防ぎ、ブロックチェーンネイティブな機能に集中することで、MVP 開発の効率化を図る。
圧縮後の例（日本語）
# dApps MVP開発 要求定義書
## 基本方針
### 1. MVP優先の迅速開発
- 最小限の機能で素早くマーケット投入
- 小規模チーム（1-3名）での効率的な開発
- web2のDB管理や複雑な機能は排除
- ブロックチェーンネイティブな機能に集中
- 開発工数の最小化を最優先
### 2. 外部ツール活用戦略
- オンチェーンデータは世界で共有されている（実質的にDB・Web API・ストレージが共有）
- 内製開発ではなく外部ツールに委託して開発コストを削減
- 成熟したエコシステムを活用（OpenSea、UniSwap等）
- 具体例：
- NFTコレクション表示 → OpenSeaページへリンク
- トークンスワップ → UniSwapスマートコントラクト呼び出し
- ウォレット機能 → MetaMask等の既存ウォレット使用
### 3. VM別リポジトリ分離
- 1つのdAppにつき1つのVMで対応
- EVM互換チェーンは同一リポジトリで対応可能
- Solana、AO、Suiなど異なるVMは別リポジトリで管理
- コード共有は手動コピペで十分
- 抽象化レイヤーは開発初速・保守性を損なうため不採用
## 技術スタック
### 言語・フレームワーク
```
言語: TypeScript
フレームワーク: Next.js App Router
スタイリング: TailwindCSS + shadcn/ui
状態管理: zustand + react-hook-form
ホスティング: Vercel
開発環境: GitHub + Claude Code + VSCode + pnpm
```
### ライブラリ選定基準
- **AI親和性重視**: 成熟した「枯れた技術」を採用
- **Type Safety**: TypeScriptの型安全性を最大限活用
- **シンプルなAPI**: 複雑な設定や学習コストを避ける
- **ドキュメント充実**: AIが参照しやすい豊富なドキュメント
### 推奨ライブラリ
```
UI: shadcn/ui（radix-ui + lucide-react自動併用）
Toast: sonner（react-hot-toast等は併用禁止）
Data Fetch: @tanstack/react-query
HTTP: 標準Fetch API（axios等は不要）
web2 DB: Supabase or Firebase（可能な限り使用しない）
```
### ディレクトリ構成
```
src/
├── app/ # Next.js App Router
├── components/ # 再利用可能なコンポーネント
├── features/ # 機能別ディレクトリ
│ ├── wallet/ # ウォレット関連
│ ├── nft/ # NFT関連
│ └── token/ # トークン関連
├── lib/ # ユーティリティ関数
├── hooks/ # カスタムフック
└── types/ # TypeScript型定義
```
## 機能要件
### 核心概念
dAppsの機能は以下にパターン化できる：
1. ウォレット接続
2. ブロックチェーン上のデータ（主にトークン）に対するCRUD操作
3. web2 DB・SNS連携は必須ではない（パフォーマンス向上・グロースハック用）
### 必須機能リスト
#### 1. ウォレット接続機能
```
基本機能:
- ウォレット接続・切断
- 接続ステータスのグローバル状態管理
- 接続状態のキャッシュによるUX向上
- 複数ウォレットプロバイダー対応
実装要件:
- MetaMask、WalletConnect等の主要ウォレット対応
- 接続状態の永続化（セッション管理）
- ネットワーク切り替え対応
- エラーハンドリング（接続失敗、ネットワークエラー等）
```
#### 2. NFT Mint機能
```
簡単Mint:
- 決められた設定でワンクリックMint
- プリセット価格・数量での実行
- 最小限のUI（ボタン1つ）
カスタムMint:
- ユーザーがフォームで設定項目を入力
- 価格、数量、メタデータの設定
- リアルタイムバリデーション
共通要件:
- Mint処理のステータス表示
- エラーハンドリング
- 成功時の通知（toast + SNSシェア）
- トランザクション確認・完了の表示
```
#### 3. NFTデータ表示機能
```
コレクション一覧:
- Collection Name
- Banner Image
- Mint Status（進行中/完了）
- Description
- Total Supply / Minted数
コレクション詳細:
- 詳細情報表示
- NFTアイテム一覧（グリッド表示）
- ページネーション
- フィルタリング機能
NFTアイテム詳細:
- Name、Image、Description
- Owner、Creator情報
- Trade履歴
- 外部マーケットプレイスへのリンク
```
#### 4. トークンClaim機能
```
基本機能:
- ユーザーに割り当てられたトークンの確認
- Claim可能数量の表示
- ワンクリックClaim実行
- Claim履歴の表示
実装要件:
- Merkle Tree等を用いたClaim権限の検証
- 処理状態の表示
- エラーハンドリング
- 成功時の通知
```
#### 5. プロフィールページ
```
表示項目:
- ウォレットアドレス
- 保有NFT一覧
- 保有トークン残高
- トランザクション履歴
- アクティビティ履歴
機能:
- 外部ブロックエクスプローラーへのリンク
- NFTの詳細表示
- フィルタリング・ソート機能
```
#### 6. SNSシェア機能
```
シェア対象:
- NFT Mint完了
- トークンClaim完了
- コレクション作成
- その他アチーブメント
実装方針:
- Twitter/X専用（他SNSは不要）
- 認証不要（リンクベース）
- 画像付きシェア
- ハッシュタグ自動付与
```
## 除外機能（スコープ外）
### 絶対に実装しない機能
```
ユーザー認証:
- メールアドレス認証
- SNSログイン
- 独自ユーザー管理システム
理由: ウォレット接続で十分
UI/UX拡張:
- ライト・ダークモード切り替え
- 多言語対応（i18n）
- 複雑なアニメーション
理由: 開発工数の肥大化
web2 DB機能:
- メールアドレス登録
- ユーザープロフィール保存
- いいね・コメント機能
理由: ブロックチェーンネイティブに非該当
独自開発:
- ウォレット機能
- ブロックエクスプローラー
- NFTマーケットプレイス
- DEX機能
理由: 既存の成熟したツールを使用
```
### 除外理由
- 開発工数の肥大化防止
- ブロックチェーンネイティブな機能への集中
- MVP開発の効率化
- 小規模チームでの実現可能性確保
## セキュリティ要件
### スマートコントラクト通信
```
設定管理:
- ABI・アドレスを環境変数で管理
- フロントエンドでの改ざん防止
- ネットワーク別の設定分離
事前チェック:
- 想定外ネットワークへの接続防止
- 未設定コントラクトアドレスのアクセス防止
- トランザクション実行前の操作概要表示
事後検証:
- トランザクション結果の検証
- エラー時の適切な通知
- 失敗時のロールバック処理
```
### ウォレット情報管理
```
データ保護:
- 機密データの長期保存回避
- セッション管理の適切な実装
- 自動ログアウト機能
接続状態:
- 不要な権限の永続化防止
- セッションタイムアウト設定
- 複数ウォレットプロバイダー対応
```
## パフォーマンス最適化
### NFTデータ処理
```
データ取得:
- ページネーション実装
- 段階的データ読み込み
- メタデータ取得のリトライ機能
- 適切なキャッシュ戦略
画像最適化:
- 複数IPFSゲートウェイのフォールバック
- Arweaveゲートウェイの応答速度考慮
- 異なるプロトコルの統一処理
- lazy loading実装
- 画像圧縮・最適化
- プレースホルダー表示
```
### 接続状態最適化
```
ウォレット接続:
- 不要な再接続処理回避
- 接続状態の復元機能
- 複数タブでの状態同期
- 自動再接続機能
```
## 実装指針
### 開発優先順位
1. ウォレット接続機能
2. 基本的なNFT表示機能
3. NFT Mint機能
4. トークンClaim機能
5. プロフィールページ
6. SNSシェア機能
### コード品質
- TypeScript型安全性の徹底
- ESLint + Prettierによるコード統一
- 単体テストの実装（Jest + React Testing Library）
- エラーハンドリングの統一
### デプロイ・運用
- Vercelでの自動デプロイ
- 環境変数による設定管理
- エラー監視（Sentry等）
- パフォーマンス監視
Views: 0
