トークンローンチチェックリスト：T-60からT+30までに準備すること

T-60：ローンチ日を発表する前に決めること

T-60までに、チームはローンチの目的、トークンのパラメータ、プロジェクトの公開バージョンを合意する必要があります。この段階では、広告フォーマットを選ぶよりも、プロダクト、法的レビュー、トークノミクス、コミュニケーション間の依存関係を解消することが重要です。

タスク、オーナー、期限、ステータスを含む作業ドキュメントを作成します。次のフェーズを開始できない項目（例：承認済みのドキュメント、監査済みのコントラクト、トークン配分の合意済み手順）を別途マークします。TGEの日付がまだ暫定的な場合は、それを確定または延期できる条件を明記します。

プロモーションに進む前に、以下を確認します：

• ウェブサイト、ドキュメント、ソーシャルチャネルでのプロジェクトの説明が一致しているか。
• トークンの目的、機能、制限が明確か。
• プロダクト、コミュニティ、上場、公開対応の責任者が割り当てられているか。
• 資料の承認プロセスと緊急変更の手順が定義されているか。

チームは、推測で答えてはいけない質問（例：プラットフォームによる申請の審査期間、特定市場の利用可能性）をすぐに書き留めておくと便利です。上場基準を事前に確認し、確認のための余裕を持って申請を計画します。準備は、CoinMarketCap上場ガイドとCoinGecko上場ガイドで補完できます。

T-30：プロジェクトの運用準備を確認する方法

T-30までに、チームは資料、サポートチャネル、合意済みのローンチシナリオを準備している必要があります。この段階で戦略を実行可能な計画に変換します。各公開アクションについて、時間、オーナー、必要なアクセス、バックアップオプションを指定します。

公式リンク、プロジェクトの説明、ビジュアル資料、FAQ、エスカレーション用の連絡先を単一のパッケージにまとめます。チームが古いバージョンのメッセージをチャットからコピーするのではなく、単一の情報源を使用していることを確認します。プロダクトのユーザー、トークン保有者、パートナー、メディアなど、異なるオーディエンス向けに短い説明を準備します。

また、ユーザーの導線（アナウンスからウェブサイト、ドキュメント、ウォレット接続、サポートチャネルまで）を事前に確認します。モバイルデバイスとコンピュータの両方でチーム内でテストします。プロダクト、コントラクト、アクセス、公式チャネルに関する質問をどこに誘導するかを決定します。

インフルエンサーやコンテンツクリエイターの投稿が必要な場合は、トピック、フォーマット、期限、開示、ファクトチェックのプロセスを確認します。KOLキャンペーンの計画では、選定基準と資料の承認を別途照合すると便利です。コミュニティ向けには、投稿スケジュールだけでなく、モデレーションルールと当番を準備します。メッセージを修正または延期する必要がある場合に誰が決定するかを記録します。

トークンローンチにはどのチャネルを選ぶべきか？

チャネルは、プラットフォームの人気ではなく、タスクとオーディエンスに基づいて選択します。Telegramは迅速なサポートとコミュニティとの対話に適しており、Xは公開アップデートと短いメッセージの拡散に適しています。両チャネルには、それぞれ編集役割と応答ルールが必要です。

各投稿に1つの主要なメッセージ、関連リンク、明確な次のステップが含まれるように計画します。まだチームが確認していないことを約束しないでください。投稿が上場日に関連する場合は、延期の場合のテキスト更新手順を残します。チャネルのタスク比較はTelegramとXのプロモーション分析にあり、Xのトレンドに合わせた投稿準備はXハッシュタグガイドにあります。

取引・分析プラットフォームについては、まずユーザーがそこでどのような情報を探しているかを決定します。「DEXTools vs DEXScreener」や「CoinMarketCap vs CoinGecko」という検索は選択の質問として有用ですが、プラットフォーム自体の要件と利用可能なフォーマットの確認には代わりません。特に、DEXTools Nitroを類似の名前の他の掲載と同一視しないでください。現在のインターフェースと特定のオプションの説明で条件を確認してください。

T-7とTGE当日：公開前に確認すること

TGEの1週間前には、ローンチに関わる各参加者の準備状況を確認し、公開資料への未承認の変更を停止します。チームは最新のシナリオ（誰が公開するか、誰がリンクを確認するか、誰がコミュニティに応答するか、誰が計画変更を伝える権限を持つか）を把握している必要があります。

開始前に、以下のリストで簡単なチェックを行います：

• コントラクトアドレスと公式リンクがすべてのチャネルで一致しているか。
• ウェブサイト、ドキュメント、問い合わせフォーム、プロジェクトページが機能しているか。
• 計画通りのローンチ、遅延、技術的インシデントのためのテキストが準備されているか。
• モデレーターが公式チャネルと外部メッセージを区別する方法を知っているか。
• 責任者がアクセス権を持ち、その引き継ぎ手順が明確か。

ローンチ当日は、イベントログ（公開時刻、変更内容、ユーザーの質問、決定事項）を記録します。修正の文脈を削除せず、置き換えられたバージョンと訂正が公開された場所を示します。プロダクト、コミュニティ、技術チームからのシグナルを収集する担当者を1人任命し、重要な情報が個別のチャットで失われないようにします。

問題が発見された場合は、まず担当スペシャリストに事実を確認し、その後、既知の情報と次の情報がいつ提供されるかを示す短いアップデートを公開します。未確認の復旧時期を公開しないでください。この手順により混乱が減り、チームとオーディエンスの単一の情報源を維持できます。

T+1—T+30：ローンチ後の運用方法

TGE後、チェックリストはアナウンスからサポート、モニタリング、継続的なアップデートに切り替える必要があります。最初の1ヶ月で、チームは繰り返し発生する質問に対処し、ユーザー導線の可用性を確認し、約束したアクションのうち完了したものと新しい期限が必要なものを記録します。

チーム向けの定期的なサマリーを作成します。プロダクトのステータス、コミュニティからの問い合わせ、公開情報、申請状況、オープンなリスクを反映するのに十分です。メッセージのリーチとサポートの質を混同しないでください。プロジェクトが回答した質問と未解決の問題を別々に記録します。

期間終了時に、以下を分析します：

• ユーザーから頻繁に寄せられる質問と、ドキュメントに不足しているもの。
• 有意義な問い合わせをもたらすチャネルと、見直しが必要なチャネル。
• プロダクトや条件の変更後に更新が必要な公開情報。
• 次の開発計画に引き継ぐタスクと、それを受け取る担当者。

コミュニティとの作業では、投稿頻度だけでなく明確なルールを使用します。Telegramコミュニティ成長ガイドで、チャネル構造と参加者との関わり方を確認できます。プロジェクトがトレンドセクションへの掲載を検討している場合は、それを個別のアクティビティとして全体カレンダーに含めます。DEXToolsとDEXScreenerには独自のフォーマットがあり、申請前に調査する必要があります。

掲載や上場でチームが制御できないこと

チームは申請の品質、データの正確性、公開されたルールの遵守を管理しますが、プラットフォームの最終決定は管理できません。CoinMarketCapとCoinGeckoは、上場とプロフィール更新を独自に審査します。審査期間と決定の事実はプラットフォーム側にあります。トレンドセクションでは、可視性はプラットフォームのルール、ランキングシグナル、ローテーションに依存するため、特定の位置や表示期間を事前に約束することはできません。

これは計画時に重要です。未確認の上場にプロダクトのアナウンスを依存させず、申請を承認として提示しないでください。カレンダーで、チームの確認済みアクションと外部プラットフォームの決定が必要なイベントを分けてください。外部ステップごとに、バックアップのコミュニケーションシナリオ（例：申請ステータスに言及せずにプロダクトの可用性を公開する）を指定します。

注文または自己申請の前に、サービスの公式ページで現在のルール、データフォーマット、特定のオプションの条件を確認してください。送信確認とやり取りを保存し、チームが追加情報の要求に応答できるようにします。条件が変更された場合は、次の公開前に内部チェックリストとプロモーション資料を更新します。

ここでの良い仕事の基準は、透明な範囲です。何が準備され、送信され、掲載されたか、どのステータスが確認されたか、どの決定が外部にあるか。この記録により、チームが制御できない結果をプロジェクトに帰属させることなく、実行を評価できます。

チェックリストを実用的なドキュメントに変える方法

実用的なチェックリストは、タスクだけでなく、完了条件も示す必要があります。各項目について、オーナー、期限、資料へのリンク、完了の確認、他のチームへの依存関係を記録します。結果は検証可能な形で記述します。例えば、「Telegramを準備する」ではなく、「ルールを公開し、公式リンクを固定し、当番スケジュールを確認する」とします。

ドキュメントを3つの層に分けます：必須のローンチ条件、TGEを停止せずに延期できるタスク、ローンチ後のアクション。ステータスを更新し、変更を伝えるコーディネーターを1人任命します。他のメンバーは、最新バージョンがどこにあるか、ブロッカーを誰に報告するかを理解している必要があります。

最終承認の前に、プロダクト、マーケティング、技術、コミュニティのオーナーとチェックリストを確認します。各オーナーに未解決の依存関係とその確認方法を尋ねます。ステータスを確認できない場合、資料が審査に送られたという理由だけでタスクを完了とマークしないでください。

さらなる準備には、Memecoinローンチガイド、上場ハブ、KOLキャンペーンハブの資料を使用します。これらは計画の個々のブランチを詳細化するのに役立ちますが、T-60—T+30の統一カレンダーの代わりにはなりません。チェックリストは、チームが変更時に定期的に見直し、決定を保存する場合に有用であり、イベント前に項目をチェックするだけでは不十分です。

料金

開始価格はUSD表示です。カスタムバンドルやボリュームディスカウントはご相談ください。USDT、USDC、BTC、ETH、SOL、TON、またはプロジェクトトークンでのお支払いが可能です。

仕組み

1. T-60 — 基盤を合意するプロジェクトのパラメータ、ローンチの目的、オーナー、日付確認の条件を確定します。プロダクト、トークノミクス、コミュニケーション間の依存関係を記録します。
2. T-30 — 資料をまとめる公式リンク、説明、FAQ、コンテンツ、サポートシナリオを準備します。ユーザー導線とチームの役割を確認します。
3. T-7 — 準備状況を確認するコントラクトデータ、アクセス権、テキスト、延期やインシデント時の行動計画を照合します。責任者が対応可能であることを確認します。
4. TGE — イベントログを記録する公開情報、変更、問い合わせ、決定を1か所に記録します。オーディエンスには確認済みの情報のみを提供します。
5. T+1—T+30 — フィードバックを分析する質問、約束したアクションのステータス、ドキュメントのギャップを追跡します。次のプロダクトおよびコミュニケーション計画に結論を引き継ぎます。