仮想通貨ホワイトペーパーの書き方：構成、内容、よくある間違い

ホワイトペーパーはなぜ必要で、誰が読むのか？

ホワイトペーパーは、読者にプロジェクトの検証可能な説明を提供するために必要です。つまり、どのような問題を解決し、どのような方法で、実装について何がすでにわかっているかを示します。これは宣伝パンフレットではなく、ドキュメント、プレゼンテーション、法的資料の代わりにもなりません。執筆前に、読者が読了後にどのような判断を下すべきかを明確にします。製品を理解する、技術モデルを評価する、トークンの仕組みを学ぶなどです。

主要なオーディエンスは個別に定義します。ユーザーは使用シナリオを理解することが重要です。開発者はアーキテクチャと制約を理解する必要があります。パートナーは依存関係と統合の段階を理解する必要があります。1つの文書で複数のグループに対応できますが、全員が同じ詳細レベルを読み解く必要があってはなりません。簡潔な概要は素早く本質を理解するのに役立ち、特別なセクションは必要な人に深い情報を提供します。

計画を立てる前に、以下の質問に答えてください。

• 読者は製品とBlockchainについてすでに何を知っていますか？
• 現在の製品、コード、計算で確認できる主張は何ですか？
• 最初に使用する際に定義すべき用語は何ですか？
• 文書はウェブサイト、ドキュメント、ローンチ資料とどのように関連しますか？

最初の紹介用の短い概要が必要な場合、それは補足として提供できますが、重要な条件を隠してはいけません。より広範な準備計画については、トークンローンチチェックリストを使用してください。

プロジェクトを理解するのに役立つホワイトペーパーの構成とは？

実用的な構成は、読者を課題から解決策へと導き、その後メカニズムと制約を示します。順序は製品に応じて変更できますが、各セクションは特定の質問に答え、一般的なテーゼを別の言葉で繰り返してはいけません。

便利な文書の骨組み：

• 概要： 製品、オーディエンス、問題、提案された解決策。
• 背景と問題： 現在のアプローチがどこで機能せず、誰にとって重要か。
• 製品説明： ユーザーシナリオ、主要機能、開発状況。
• アーキテクチャ： コンポーネント、データフロー、使用されるネットワーク、外部依存関係。
• トークンと経済： 目的、配分、利用可能なメカニズム、条件（トークンが想定されている場合）。
• セキュリティと制約： 脅威モデル、講じられた対策、既知のトレードオフ、未解決の問題。
• 開発計画とガバナンス： 段階、依存関係、責任ある決定、文書更新方法。

各セクションについて、テーゼと確認事項（仕様、計算、図、担当者のコメント）のリストを作成します。事実がまだない場合は、未解決の問題や計画として明記し、確信を持った表現で空白を埋めてはいけません。内容は製品の実際の構造を反映するべきであり、汎用テンプレートではありません。プロジェクトが口頭でのアイデア提示用の資料を必要とする場合は、ピッチデッキの形式と目的を比較してください。

トークノミクスと技術的メカニズムをどのように説明するか？

トークンに関するセクションでは、製品におけるその役割と取引ルールをわかりやすく説明する必要があります。トークンが説明されたシナリオに不要であるか、その機能がまだ定義されていない場合は、複雑なスキームで不確実性を隠してはいけません。決定を未解決として記録し、チームと調整してください。

トークンの目的を、ユーザーまたはプロトコルのアクションを通じて説明します。どこで、どのような条件下で使用され、どのような権利や機能が関連し、どのような制限が適用されるかを明確にします。供給、配分、ロック解除、発行に関する情報を提供する場合は、最新のモデルと調整し、文書全体で用語を一貫して使用します。配分の割合、トークンの利用可能性、実際の流通を混同してはいけません。これらは異なる概念です。

技術的な部分では、以下を明らかにすると役立ちます。

• システムの主要コンポーネントとその相互作用。
• 通常のユーザーシナリオで何が起こるか。
• スマートコントラクトが実行するアクションと、オフチェーンで残るもの。
• 動作が依存する外部サービスやネットワーク。
• 選択されたアーキテクチャの前提条件とトレードオフ。

資産やデータの流れを追跡するのに役立つ場合は図を追加し、キャプションを付けます。各図はテキストおよび現在の実装と一致している必要があります。トークノミクスは資産の将来の価値を証明するものではありません。収益性に関する結論ではなく、仕組みと条件を説明してください。

元資料から完成したテキストまでの道のりは？

ホワイトペーパーは、事実を執筆前に収集し、チェックをセクション所有者に分散させると準備が容易になります。表現の洗練から始めてはいけません。まずモデルのギャップを見つけ、用語について合意し、チームメンバーが同じ製品を説明していることを確認します。

実践的な作業手順：

• 元資料を収集する： 製品説明、仕様、トークノミクス、図、開発状況、未解決の決定事項のリスト。
• 責任者を割り当てる： 技術的、プロダクト的、経済的な各主張には、それを確認できる所有者が必要です。
• 内容を調整する： セクションの計画を作成し、どの事実がすでに確認され、どれが計画のままかをマークします。
• 草稿を作成しチェックする： まず論理と完全性、次にスタイル、用語、相互参照、視覚要素。
• リリースを確定する： バージョンと更新日を記載し、その後の変更の責任者を割り当てます。

準備期間はページ数ではなく、専門家の可用性、資料の完全性、調整の速度によって決まります。コメントを1つの文書に集約し、指摘を事実、技術、編集に分類することで遅延を減らします。編集者は構造と明確さを改善できますが、製品の仕組みを確認するのはプロジェクトチームです。

ホワイトペーパーを弱くする間違いとは？

弱いホワイトペーパーは通常、約束された解決策が実際にどのように機能するかを説明していません。読者は用語、計画、派手な主張を見ますが、問題、製品、主張されたメカニズムの間の関連性を確認できません。

草稿を典型的な間違いについてチェックします。

• 問題に関するテーゼが広すぎる。 具体的なユーザー、シナリオ、既存のアプローチの欠点を特定します。
• 定義なしの技術用語。 最初に使用する際に用語を説明し、すべてのセクションで同じように使用します。
• 計画を実際の機能として提示する。 完成した実装、現在の開発、可能な方向性を区別します。
• トークノミクスが製品から切り離されて説明されている。 トークンが解決する課題を示すか、その役割がまだ検討中であることを正直に明記します。
• 値と用語の不一致。 テキスト、表、図、公開資料を1つのデータソースと照合します。
• 制約の議論がない。 システムの使用に影響を与える可能性のある依存関係とトレードオフを特定します。

役立つ編集チェックは簡単です。チーム外の人物に、概要を読んだ後、プロジェクトの目的と1つの主要シナリオを言い換えてもらいます。彼らが事実を自分の仮定で置き換える場合は、テキストを明確にし、不足している関連性を追加します。印象づけるためにボリュームを追加してはいけません。各主張はシステムの理解に役立つものでなければなりません。

ホワイトペーパー公開前に何をチェックすべきか？

公開前に、文書をプロジェクトに関する情報源としてチェックします。読者は事実と意図を区別し、用語を理解し、重要な主張の確認を見つけられる必要があります。チェックは編集者だけでなく、製品、開発、経済モデル、パブリックコミュニケーションを担当する人々が参加します。

最終チェックリストを実行します。

• すべての技術説明を最新のアーキテクチャと開発状況と照合します。
• テキスト内のトークンモデルが計算と決定と一致していることを確認します。
• 予測と計画を計画としてマークし、既成事実として扱いません。
• 表と図が読みやすく、テキストと矛盾しないことを確認します。
• 日付、バージョン、リンク、名称の表記、用語の定義をチェックします。
• 修正を報告する場所と最新バージョンを探す場所を指定します。

ホワイトペーパー自体はプロジェクトの品質を確認するものではなく、スマートコントラクト、製品、法的モデルのチェックに代わるものではありません。文書の公開はプラットフォームの決定を制御しません。CoinMarketCapやCoinGeckoの上場とモデレーションは、それぞれの基準と手順に従って行われます。テキストに基づいて上場承認、オーディエンスの注目、市場結果を約束することはできません。チームは文書の正確性とタイムリーな更新に責任を持つことができますが、外部プラットフォームの決定には責任を持ちません。製品変更後に公開情報が更新される場合は、CoinMarketCap上場申請を含む他の資料と調整します。

料金

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

仕組み

1. 事実を収集する仕様、図、最新のトークンパラメータ、ユーザーシナリオの説明を要求します。チームがまだ解決策を持っていない質問は別途マークします。
2. 読者を定義する主要なオーディエンスを選択し、それぞれに必要な説明を決定します。プレゼンテーションやドキュメントと混同しないように、文書の目的を明確にします。
3. 構成を調整する問題と製品からアーキテクチャ、経済、制約へとセクションを配置します。各テーゼについて、その正確性を確認する専門家を割り当てます。
4. 草稿を準備する確認された資料に基づいて書き、現在の機能と計画を区別します。定義と値がセクション間で変わらないことを確認します。
5. チェックとリリースを実行するチームと事実を照合し、テキスト、図、リンクを編集します。文書のバージョンを指定し、更新の責任者を割り当てます。