tommyパイセン🚴🏼フリーランス10th.ITエンジニア

NFT所有証明サイト 開発プロンプト Firebase Spark無料版・事前登録NFT限定方式 1. AIの役割と最重要指示 あなたは、Firebase、React、TypeScript、Web3、EVM、Solana、ウォレット署名、セキュリティ、UI/UXに精通したフルスタック開発エージェントです。 これから「NFT所有証明サイト」を新規開発してください。 開発者は非エンジニアです。専門知識がなくても構築・公開・運用できるように、環境構築から公開まで、すべての手順を日本語で具体的に説明してください。 可能な作業は実際にファイルを作成・修正・テストし、実行できなかった操作だけユーザーに手順を案内してください。 説明だけで終わらず、実際に動作するWebサイトを完成させることを目標にしてください。 絶対条件 Firebase Spark（無料版）を使用する。 Blazeプランへの変更を前提としない。 Firebase AuthenticationでGoogleログインを実装する。 Cloud Firestoreでサイトのデータを管理する。 Firebase Hostingで静的Webサイトを公開する。 Cloud Functions、Cloud Storage for Firebase、Cloud Run、Firebase App Hostingは使用しない。 外部の有料APIを必須としない。 秘密鍵やリカバリーフレーズを要求・保存しない。 ユーザーのウォレットでNFTの転送や承認を行わない。 NFTの発行・購入・販売機能は実装しない。 無料環境で実現できないことを、実現できたと報告しない。 開発時点の公式ドキュメントとライブラリの互換性を確認する。 セキュリティ上の問題を残した機能を、検証済みと表示しない。 2. サイトの目的 サイトの管理者がNFTを事前に登録する。 登録時には、対象のブロックチェーン、コントラクトアドレス、トークンIDなどのNFT識別情報と、表示する画像を関連付ける。 一般利用者はGoogleアカウントでログインし、自分のウォレットを接続する。 ウォレットは複数登録できる。 利用者のマイページでは、管理者が登録したNFTのうち、接続・確認済みのウォレットが実際に保有しているNFTだけを表示する。 コレクションページでは、管理者が登録したNFTを、コントラクト単位またはチェーン固有のコレクション単位で一覧表示する。 NFT詳細ページでは、作品画像、NFT情報、現在の所有者情報を表示する。 現在の所有者がサイトにプロフィール情報を登録し、そのウォレットとの関連が確認できる場合は、公開を許可したプロフィール情報だけを表示する。 それ以外の場合は、確認できたウォレットアドレスのみを表示する。 3. NFT取得対象の厳密な定義 非常に重要な仕様である。 本サイトは、ウォレットが保有するすべてのNFTを自動収集するサイトではない。 管理者が事前登録したNFTだけを証明対象とする。 例えば、管理者が次のNFTを登録した場合を考える。 Ethereum / Contract A / Token ID 1 Polygon / Contract B / Token ID 25 Base / Contract C / Token ID 100 利用者がウォレットを登録した際、この3つの対象NFTについてだけ保有状況を確認する。 ウォレット内にほかのNFTが存在しても取得対象にしない。 コントラクト内の全トークンを自動列挙しない。 NFTインデックスAPIによる全件取得、トークンID総当たり、全Transferイベント解析、未登録NFTの自動追加は実装しない。 管理者が登録したNFTが100件であれば、対象はその100件である。 ただし、保有状況の確認処理は、同時リクエスト数を制限し、画面表示に必要な分から順番に実行すること。 4. 技術構成 以下を基本とする。 React TypeScript（strict） Vite React Router Tailwind CSS Firebase JavaScript SDK Firebase Authentication Cloud Firestore Firebase Hosting Firebase Emulator Suite viem wagmi EVMウォレット接続に必要な互換ライブラリ Solana Wallet Standard対応ライブラリ Vitest Playwright 実装前に推奨LTS版のNode.jsと、それに対応する依存ライブラリのバージョンを確認する。 Reactの静的SPAとして構築する。 SSRや常時稼働バックエンドを必要とする構成は採用しない。 UIは日本語を基本とし、スマートフォンとPCの両方に対応する。 5. ユーザー権限 一般閲覧者 ログイン不要。 コレクション一覧、登録済みNFT一覧、NFT詳細、公開プロフィールを閲覧できる。 登録ユーザー Googleログイン必須。 複数ウォレットを関連付けられる。 公開プロフィールを編集できる。 マイNFT一覧を閲覧できる。 ウォレットの追加・解除ができる。 自分の非公開情報を他人に閲覧させない。 サイト管理者 管理者は1人。 管理者のFirebase Authentication UIDを、一般ユーザーが変更できない設定として管理する。 管理画面では、コレクションとNFTの登録、編集、公開・非公開設定、画像選択を行う。 管理者判定は画面上の表示制御だけでなく、Firestore Security Rulesでも行う。 管理者権限を自分で付与できる仕組みは禁止する。 6. 対応ブロックチェーン EVM系 Ethereum、Polygon、BaseなどのEVM互換チェーンに対応する。 対応ネットワークは設定ファイルで定義する。 各ネットワークにChain ID、RPC URL、エクスプローラーURLを設定する。 NFTはChain ID、コントラクトアドレス、トークンIDで特定する。 ERC-721とERC-1155を扱う。 コントラクトアドレスは検証・正規化し、トークンIDは数値精度を失わない文字列で保存する。 Solana Solanaのウォレットを接続できるようにする。 Solana NFTにはEVMのコントラクトアドレスとトークンIDをそのまま当てはめない。 対象規格に合わせてMintアドレス、Asset ID、Collection Assetなどの識別情報を保持する。 Classic NFT、Metaplex Core、圧縮NFTは、識別と保有確認の方法が異なるため個別のアダプタとして扱う。 実装可能な規格を明示し、未対応規格は「未対応」と表示する。 その他のチェーン 将来追加できるアダプタ構造を用意する。 未指定チェーンを推測で実装しない。 アダプタは少なくとも、アドレス形式の検証、NFT識別、保有確認、署名検証、エクスプローラーURL生成のインターフェースを持つ。 7. 管理者によるNFT登録 管理画面でコレクションを作成できるようにする。 コレクションには、名称、説明、チェーン、コントラクトなどの識別子、画像、公開状態を登録する。 NFT登録画面では、コレクションを選択し、トークンIDまたはチェーン固有のAsset IDを登録する。 作品名、説明、画像、必要に応じた属性を登録する。 同じチェーン、同じコントラクト、同じトークンIDの重複登録を防ぐ。 NFTの登録時に、対応RPCでそのトークンが存在するか確認できる場合は確認する。 通信エラーの場合と存在しない場合を区別する。 NFTを登録しただけで、所有者が確認されたものとして扱わない。 作品情報は管理者の登録内容を優先する。 作品の公開・非公開を設定できる。 登録済みNFTを編集・削除できる。 8. 画像管理 Firebase Storageは使用しない。 サイトのソースコード内に画像を配置し、Firebase Hostingへのデプロイ時に画像も一緒に公開する。 基本フォルダ構造は次のとおり。 public/ images/ collections/ nft/ placeholders/ image-manifest.json 画像追加の基本操作は以下とする。 管理者がPC上の画像フォルダへファイルを保存する。 画像一覧を生成するスクリプトを実行する。 開発環境で画像が表示されることを確認する。 サイトを再ビルド・再デプロイする。 管理画面から追加した画像を選択する。 選択した画像パスをFirestoreに保存する。 画像選択画面には、サムネイル、ファイル名、選択状態、プレビューを表示する。 実際に存在しないファイルを選択できないようにする。 画像ファイルはWebP、PNG、JPEGなどに対応する。 推奨サイズと容量上限を設定し、必要に応じて開発時に最適化する。 同名ファイルの上書きやキャッシュによる古い画像表示を避けるため、ファイル名変更やハッシュ付きファイル名を検討する。 管理画面から画像を選択する機能と、ブラウザから画像ファイルをサーバーへアップロードする機能は区別する。 今回実装するのは前者である。 9. Googleログイン Firebase AuthenticationのGoogleプロバイダーを使用する。 ログイン前後の画面を切り替える。 Firebase AuthenticationのUIDをユーザー識別子として扱う。 Googleのメールアドレスを勝手に公開しない。 ログイン後、初回利用時にプロフィール設定画面へ案内する。 ログアウト後は本人専用ページを閲覧できないようにする。 スマートフォンでのログイン動作も確認する。 10. ウォレット接続 EVMとSolanaのウォレット接続に対応する。 PCの拡張ウォレットとスマートフォンのウォレットアプリを想定する。 EVMはMetaMaskなどに対応する。 WalletConnectを採用する場合は、現在の利用条件と無料枠を確認する。 SolanaはWallet Standardに対応したウォレットを採用する。 ひとつのGoogleアカウントに複数のウォレットを登録できる。 ウォレットの一覧では、チェーン種別、アドレス、確認状況、追加日時を表示する。 アドレスを入力しただけで登録済み本人ウォレットとして認定しない。 署名確認とウォレット登録を別処理にする。 ウォレットアカウント切り替え、接続解除、署名拒否、ネットワーク切り替えに対応する。 11. 署名とウォレット紐づけ 秘密鍵を取り扱わず、メッセージ署名によりウォレット操作権限を確認する。 EVMではEIP-4361（SIWE）を基本にする。 Solanaでは対象ウォレットが対応する署名方式を使用する。 署名するメッセージには、ドメイン、操作目的、ウォレット識別子、チェーン、Google UIDに対応する識別情報、発行日時、有効期限、nonceなどを含める。 署名内容は利用者に分かるように表示する。 EVMのEOAとスマートコントラクトウォレットでは、適切な署名検証方式を使い分ける。 署名の検証には、署名値だけでなくメッセージ全体、対象アドレス、ドメイン、時刻、Google UIDとの対応を使用する。 Sparkプランでのセキュリティ境界 Firebase SparkにはCloud Functionsがない。 そのため、サーバー側での署名検証とGoogle UIDへの確定登録をFirebaseだけで完結できると仮定しない。 Firestore Security Rulesはブロックチェーン署名を直接検証できない。 署名付きの紐づけ証拠を保存し、閲覧側が独立して検証する方式を実装候補とする。 この方式を使用する場合、保存済みの紐づけ情報自体を信頼せず、署名・UIDとの対応・対象ドメイン・有効期限などを検証する。 署名のコピーによる別UIDへの付け替えを拒否する。 同じウォレットが複数のGoogleアカウントへ登録された場合の動作と優先順位を明文化する。 ウォレットの解除や署名の失効を完全に保証できない場合は、その制約を明示する。 安全性を確認できないときは、プロフィールを検証済み所有者として表示しない。 信頼できるバックエンドによるnonce管理と署名検証が必要になった場合は、別途追加要件として記載し、Sparkのみで実装済みと偽らない。 12. NFT保有確認 本サイトでは管理者が登録したNFTだけを照合する。 ERC-721 ownerOf(tokenId)で現在の所有者を取得する。 マイNFT一覧では、そのアドレスと登録済みウォレットを比較する。 一致した場合のみ保有中として表示する。 ERC-1155 balanceOf(walletAddress, tokenId)で保有数量を調べる。 数量が1以上なら保有中として表示する。 同じトークンIDを複数のウォレットが保有できる構造にする。 ERC-1155では、トークンIDだけから全保有者を取得できると仮定しない。 Solana 登録済みのMintアドレスやAsset IDについて、採用したNFT規格に適した保有確認を行う。 圧縮NFTなどは一般的なRPCだけでは確認できない可能性があるため、外部インデックスAPIの必要性を検証する。 共通 NFTの所有権照会と署名によるウォレット操作権限の証明を混同しない。 RPC障害、タイムアウト、レート制限、非対応規格、存在しないNFTを適切に扱う。 所有確認に失敗した場合は「未所有」ではなく「確認できません」と表示する。 古いキャッシュを最新の所有証明として扱わない。 NFTを譲渡した後は、次の確認時に現在の所有状態が反映されるようにする。 13. 画面構成 トップページ / サービス説明、コレクション一覧への導線、Googleログインボタンを表示する。 コレクション一覧 /collections 管理者が登録した公開コレクションを一覧表示する。 コレクション名、画像、チェーン、説明、登録済みNFT件数を表示する。 検索、チェーン別の絞り込みを実装する。 コレクション詳細 /collections/:id 対象コレクションに登録されたNFTのみを表示する。 作品画像、作品名、トークンIDなどをカード表示する。 NFTを選択すると詳細画面へ移動する。 件数が多くても動作するようページネーションを実装する。 NFT詳細 /nft/:id NFT画像、作品名、説明、チェーン、NFT規格、コントラクトアドレス、トークンIDなどを表示する。 Solanaなどでは対応する識別子を表示する。 現在の所有者情報をチェーンから確認する。 ERC-721の場合は現在の所有者アドレスを表示する。 ERC-1155の場合は、保有が確認できたアドレスと数量を表示できるようにする。ただし全保有者を特定したと誤表示しない。 所有者アドレスに対応する検証済みプロフィールがある場合のみ、公開許可された情報を表示する。 それ以外はウォレットアドレスだけを表示する。 エクスプローラーへのリンクを設ける。 所有者の確認日時を表示する。 マイNFT /my-nfts Googleログイン必須。 本人の登録済みウォレットと、管理者が登録したNFTを照合する。 現在保有しているNFTだけを一覧表示する。 ERC-1155は保有数量も表示する。 チェーン、ウォレット、コレクションによる絞り込みを実装する。 判定不能のNFTがある場合は、別途件数や状態を表示する。 マイページ /mypage Googleログイン必須。 表示名、自己紹介、プロフィール画像URL、X、Instagram、Webサイトなどを編集できる。 項目ごとに公開・非公開を設定できる。 登録済みウォレットの一覧を表示する。 ウォレットの追加、署名確認、解除を行える。 管理画面 /admin 管理者のみアクセス可能。 コレクションの作成・編集・削除、NFTの登録・編集・非公開化、画像選択を行う。 登録時に入力値検証を行う。 NFTが登録された時点で、必要に応じて保有情報の確認を行う。 管理者以外はFirestoreの管理情報を書き換えられない。 14. Firestoreのデータ構造 以下を基本として設計する。 users/{uid} 本人用ユーザー情報 publicProfiles/{uid} 公開プロフィール情報 users/{uid}/walletClaims/{claimId} ウォレット関連付けの主張と検証可能な証拠 collections/{collectionId} コレクション登録情報 tokens/{tokenIdKey} 管理者が登録したNFTの識別情報と表示情報 siteConfig/admin 管理者設定 必要に応じてプライベート設定や署名証拠の格納場所を分離する。 Firestoreの公開情報と非公開情報を明確に分ける。 公開プロフィール用ドキュメントには公開許可された情報だけを格納する。 非公開のSNS URLやGoogleメールアドレスを公開ドキュメントに混在させない。 NFTの画像パスと所有権情報は区別する。 NFTの現在所有者をFirestoreの固定値として確定扱いしない。 各フィールドの型、最大文字数、必須条件を定義する。 必要な複合インデックスを設定する。 15. Firestore Security Rules 必ず本番用セキュリティルールを作成する。 すべてのコレクションについて権限を定義する。 原則として許可した操作以外を拒否する。 一般利用者が管理用NFT情報を変更できないようにする。 管理者権限の設定を書き換えられないようにする。 本人だけが非公開プロフィールを編集・閲覧できるようにする。 公開プロフィールには公開情報しか保存しない。 利用者が自分で「署名検証済み」というフラグを設定しただけで認証済みとみなさない。 ルールはFirebase Emulator Suiteでテストする。 未認証ユーザー、通常ユーザー、他人のUID、管理者それぞれについてテストを作成する。 16. パフォーマンスと無料枠 登録NFTの件数と登録ウォレット数によってRPC呼び出しが増えることを考慮する。 通信を無制限に並列化しない。 バッチ呼び出しに対応するネットワークでは、安全に利用できる範囲で最適化する。 画面を開くたびに不必要なFirestore読み取りを繰り返さない。 キャッシュには確認日時と有効期限を付ける。 所有権の確定表示では、必要に応じて再確認できるようにする。 Firestoreの読み取り・書き込み量、Hostingの転送量、外部RPCの使用量を監視できるようにする。 無料枠超過を防ぐため、取得件数、同時実行数、タイムアウト、リトライ回数を制限する。 17. デザイン NFT作品画像を主役としたギャラリー型デザインとする。 スマートフォンを優先し、PCでも使用できるレスポンシブデザインにする。 ライトモードとダークモードを設ける。 長いウォレットアドレスは省略表示し、コピーできるようにする。 作品カード、詳細表示、ローディング、エラー表示、空状態を設計する。 Googleログインとウォレット接続の違いを初心者にも分かる文言で説明する。 NFTの状態は「所有確認済み」「確認中」「確認不能」「未対応」を明確に区別する。 18. 非エンジニア向け環境構築 以下の操作を省略せず説明する。 Node.jsのインストール Gitのインストール VS Codeのインストール 作業フォルダ作成 React・Viteプロジェクト作成 必要ライブラリのインストール Firebaseコンソールへのアクセス Firebaseプロジェクト作成 Sparkプラン確認 Webアプリ登録 Firebase設定情報取得 Google認証有効化 認証許可ドメイン設定 Firestore作成 Firestore Security Rules設定 必要インデックス設定 Firebase CLIインストール Firebase CLIログイン Hosting初期設定 環境変数設定 RPC接続先設定 EVMウォレット接続確認 Solanaウォレット接続確認 画像配置 画像マニフェスト生成 管理者設定 テストNFT登録 ローカル動作確認 セキュリティテスト 本番ビルド Firebase Hosting公開 Googleログイン本番確認 NFT保有確認 公開後の運用と更新方法 各操作について、画面上の選択場所、入力内容、実行コマンド、正常時の結果、失敗した場合の対処法を明記する。 Firebaseの管理画面が変更されている可能性があるため、必ず現在の公式ドキュメントを参照する。 19. テスト 次の動作を確認する。 一般閲覧者がコレクションを見られる 未登録NFTが表示されない 管理者がNFTを登録できる 管理者以外がNFTを登録できない Googleログインとログアウト 複数ウォレットの接続 ウォレット署名の成功・失敗 署名の改ざん・期限切れ・別UIDへの再利用 ERC-721所有者照合 ERC-1155保有数量照合 対応Solana NFTの所有照合 NFT譲渡後の表示変化 非保有NFTの非表示 RPCエラー時の確認不能表示 所有者プロフィールの公開・非公開 未検証プロフィールの誤表示防止 画像選択と画像の再デプロイ スマートフォンのウォレット接続 Firestore Security Rulesの権限テスト 本番ビルド Firebase Hosting公開 失敗したテストを成功扱いしない。 20. 納品するファイル 完全な実装コードに加えて、次のドキュメントを生成する。 README.md SETUP_GUIDE.md FIREBASE_SETUP.md WALLET_SETUP.md NFT_REGISTRATION.md IMAGE_MANAGEMENT.md SECURITY.md FREE_PLAN_LIMITATIONS.md TEST_REPORT.md DEPLOY_GUIDE.md TROUBLESHOOTING.md 設定ファイルにはfirebase.json、firestore.rules、firestore.indexes.json、.env.exampleなどを含める。 秘密情報をGitに含めないための.gitignoreも設定する。 21. 開発フェーズ Phase 1：無料枠・技術仕様・セキュリティ調査 Phase 2：ReactとFirebaseの環境構築 Phase 3：公開コレクション一覧とNFT詳細 Phase 4：管理画面と画像選択機能 Phase 5：Googleログインとプロフィール Phase 6：EVMウォレット接続と署名確認 Phase 7：登録済みERC-721・ERC-1155の保有照合 Phase 8：複数ウォレットとマイNFT一覧 Phase 9：Solanaウォレットと対応NFT規格 Phase 10：公開プロフィールとの検証可能な関連付け Phase 11：Firestoreセキュリティ・テスト Phase 12：本番公開・運用マニュアル フェーズごとに実際にコードを作成してテストする。 ユーザー操作が必要な段階だけ、具体的な操作を案内する。 重大な問題が残っている場合は、次へ進む前に問題と影響を説明する。 22. 最終受け入れ条件 Firebase Sparkプランでサイトを公開できる。 管理者が対象NFTを登録できる。 画像フォルダに配置した画像を管理画面から選べる。 一般閲覧者が登録済みNFTを閲覧できる。 Googleログインが動作する。 複数ウォレットを扱える。 対応チェーンで登録済みNFTの保有確認ができる。 NFTの保有状況をFirestoreへの自己申告だけで判定しない。 NFT詳細に現在のオンチェーン所有情報を表示できる。 検証できないプロフィールを所有者情報として掲載しない。 未登録NFTを自動収集しない。 管理者以外がNFT登録情報を変更できない。 Firebase無料枠の制限を明記する。 非エンジニアが手順に従って再構築・更新できる。 23. 最初に実行する指示 最初に、現在の公式情報を使ってFirebase Sparkプランの制限、ウォレット署名検証、対応するNFT規格、RPCの無料枠を調査してください。 次に、実現可能な機能と制限がある機能を区別してください。 その後、具体的なフォルダ構造と開発手順を示し、Phase 1から順番に実装してください。 できない機能を無理に実装したり、見かけ上動くだけの危険な仕組みを完成版としたりしてはいけません。