デザイナーと開発者が使うブランドブックの作り方
ここ数年で数十のブランドブックを見てきました。見事なタイポグラフィ、厳選されたカラーパレット、インスピレーションあふれるムードボードを備えた美しいPDF。そしてほぼ全てが納品後3ヶ月以内に無視されることになります。
問題はチームがブランドの一貫性を気にかけていないからではありません。ほとんどのブランドブックが実装を担当する人々のためではなく、役員会議のためにつくられているからです。つまり朝9時にFigmaを開くデザイナーや真夜中にCSSを書く開発者のためではなく。検索もコピーも、ワークフローへの統合もできない47ページのPDFにブランドガイドラインが入っていたら、ツールではなく博物館の展示物を作ったことになります。
実際に使われるブランドブックの作り方をご紹介します。理論的な話ではなく、開発者が数秒でデザイントークンを取得でき、デザイナーがSlackで質問することなくスペーシングルールを確認でき、新しいチームメンバーが初日からブランド一貫性のある成果物をリリースできるような、本当に実用的なブランドブックです。
目次
- ほとんどのブランドブックが失敗する理由
- 機能的なブランドブックに含めるべきもの
- 形式の問題：PDF対ウェブ対両方
- デザイントークン基盤の構築
- 実際に読んでもらえるガイドラインの書き方
- デザインとコードを橋渡しするコンポーネント文書
- ボイス＆トーン：みんなが飛ばす部分
- ブランドブックを生きたものにしておく
- ブランド文書化用のツールとプラットフォーム
- 実運用のブランドブックアーキテクチャ
- よくある質問
ほとんどのブランドブックが失敗する理由
失敗のパターンについて正直に考えましょう。エージェンシー、社内チーム、フリーランサーから受け継いだブランドガイドラインを見てきましたが、同じ問題が繰り返し現れています。
動的な世界の中の静的な文書
2010年にはPDFが意味をなしていました。2026年では、ブランドはウェブアプリ、モバイルアプリ、メールテンプレート、ソーシャルメディア、ドキュメンテーションサイトなど、ブランドブックが書かれた時点で存在していなかったプラットフォームも含めて、複数の場所に存在しています。静的な文書はこの変化に追いつけません。
ブランドブックがPDFの場合、更新のたびに再度エクスポート、再度アップロードして、誰もが新しいバージョンをダウンロードすることを願う必要があります。スポイラー：ダウンロードしません。
デザイナー言語は話すが開発者言語は話さない
ほとんどのブランドブックはブランドデザイナーやエージェンシーによって作成されます。基本的な青色が「Pantone 2935 C」であることを指定しますが、16進数では#0057B8、RGBではrgb(0, 87, 184)、HSLではhsl(212, 100%, 36%)であることを記載しません。角丸のボタンを表示しますが、border-radiusが8pxであることや、ホバー状態が10%暗くなることを記載しません。
開発者は視覚的なリファレンスではなく、実装の詳細が必要です。
間違った質問に答えている
ロゴの余白に6ページを費やしているが、ロゴがモバイルナビゲーションバーの暗い背景に表示される場合の対処方法を記載していないブランドブックは、優先順位が間違っています。最高のブランドブックは、日々実際に人々が尋ねる質問に答えています。
単一の信頼できる情報源がない
Figmaライブラリのブランドカラーがブランドブックと異なり、さらにそれが本番環境のCSS変数と異なるプロジェクトで働いたことがあります。明確な正規の情報源がないと、各チームが独自の解釈を発展させます。これがどのようにして5つの異なる色合いの「ブランドブルー」が生まれるかです。
機能的なブランドブックに含めるべきもの
ここに含めるべきもの、それぞれが誰に必要で、どの程度の緊急性で必要かを整理しています：
| セクション | 主要対象者 | 更新頻度 | 形式の優先度 |
|---|---|---|---|
| ブランド基盤（ミッション、価値観、パーソナリティ） | 全員 | ほぼ更新なし | 記述的な説明 |
| ロゴ使用方法 | デザイナー、マーケティング | 時々 | ビジュアル例+ダウンロード |
| カラーシステム | デザイナー+開発者 | 時々 | トークン+ビジュアルスウォッチ |
| タイポグラフィ | デザイナー+開発者 | 時々 | トークン+サンプル |
| スペーシング＆レイアウト | 開発者+デザイナー | 時々 | トークン+グリッド仕様 |
| アイコノグラフィ | デザイナー+開発者 | 頻繁 | ライブラリ+使用ルール |
| コンポーネントパターン | 開発者+デザイナー | 頻繁 | ライブ例+コード |
| ボイス＆トーン | ライター、マーケティング、サポート | ほぼ更新なし | 記述ガイド+例 |
| 写真とイラスト | デザイナー、マーケティング | 時々 | スタイル例+推奨/非推奨 |
| モーション＆アニメーション | 開発者+デザイナー | 時々 | 仕様+ビデオ例 |
「頻繁に更新される」セクションは簡単に更新できる形式が必要であることに注目してください。これは次のセクションのヒントになります。
形式の問題：PDF対ウェブ対両方
これは最も重要な決定であり、私は強い意見があります：ブランドブックはウェブサイトであるべきです。
理由は以下の通りです：
- 検索可能。セカンダリカラーパレットについて疑問を持つデザイナーは、30ページをスクロールする代わりにCmd+Fを使うことができます。
- リンク可能。正確なセクションへのURLを共有できます。「brand.company.com/components/buttonsのボタンの仕様を確認してください」は、「PDFの34ページにあります」よりもはるかに便利です。
- 常に最新。一度更新すれば、全員が即座に変更を見ることができます。
- インタラクティブ。ライブコード例、カラーピッカー、トークンジェネレータ、コンポーネントプレビューを埋め込むことができます。
- コピーしやすい。開発者は16進数コード、CSS変数、コードスニペットを直接コピーできます。
私たちはNext.jsとAstroの両方を使ってブランド文書化サイトを構築しており、どちらもこのユースケースに適しています。ブランドブックはほぼコンテンツで、いくつかのインタラクティブなアイランドがあります。これは正確にAstroのアーキテクチャが設計されているものです。
それでも、誰かがオフラインリファレンスが必要な場合やクライアントが何か印刷したいものが欲しい場合のためにPDFエクスポートを保つことをお勧めします。しかしPDFは、プライマリな成果物ではなく、セカンダリな成果物である必要があります。
実践的なアーキテクチャ
ウェブベースのブランドブックでは、次のような構造にします：
brand-docs/
├── src/
│ ├── content/
│ │ ├── foundations/
│ │ │ ├── mission.mdx
│ │ │ ├── colors.mdx
│ │ │ ├── typography.mdx
│ │ │ └── spacing.mdx
│ │ ├── identity/
│ │ │ ├── logo.mdx
│ │ │ ├── photography.mdx
│ │ │ └── illustration.mdx
│ │ ├── components/
│ │ │ ├── buttons.mdx
│ │ │ ├── forms.mdx
│ │ │ └── cards.mdx
│ │ └── voice/
│ │ ├── tone.mdx
│ │ └── writing-guidelines.mdx
│ ├── tokens/
│ │ ├── colors.json
│ │ ├── typography.json
│ │ └── spacing.json
│ └── components/
│ ├── ColorSwatch.astro
│ ├── TokenTable.astro
│ └── ComponentPreview.astro
MDXを使用するということは、コンテンツチームはMarkdownで書くことができ、必要な場所にインタラクティブなコンポーネントを埋め込むことができるということです。tokens/ディレクトリは、文書化サイトと本番環境のコードの両方に供給される単一の情報源になります。
デザイントークン基盤の構築
デザイントークンはブランドブックと実際のコードベースの間の橋です。まだ使用していない場合、それらはビジュアルデザイン決定を保存する名前付きエンティティです。色、フォント、スペーシング、シャドウなど、複数のプラットフォームで使用できる形式で。
トークンファイルの実践的な例はこちらです：
{
"color": {
"brand": {
"primary": {
"$value": "#0057B8",
"$type": "color",
"$description": "Primary brand blue. Use for primary actions, key UI elements, and branded accents."
},
"primary-light": {
"$value": "#3385D6",
"$type": "color",
"$description": "Lighter variant of primary. Use for hover states and secondary emphasis."
},
"primary-dark": {
"$value": "#003D80",
"$type": "color",
"$description": "Darker variant of primary. Use for active/pressed states."
}
},
"semantic": {
"success": { "$value": "#16A34A", "$type": "color" },
"warning": { "$value": "#EAB308", "$type": "color" },
"error": { "$value": "#DC2626", "$type": "color" },
"info": { "$value": "{color.brand.primary}", "$type": "color" }
}
},
"spacing": {
"xs": { "$value": "4px", "$type": "dimension" },
"sm": { "$value": "8px", "$type": "dimension" },
"md": { "$value": "16px", "$type": "dimension" },
"lg": { "$value": "24px", "$type": "dimension" },
"xl": { "$value": "32px", "$type": "dimension" },
"2xl": { "$value": "48px", "$type": "dimension" },
"3xl": { "$value": "64px", "$type": "dimension" }
}
}
これはW3Cデザイントークンコミュニティグループの形式に従っています（2025年に候補勧告になりました）。Style Dictionary、Tokens Studio、または新しいCobalt UIなどのツールは、これらのトークンをCSS custom properties、Tailwind config値、iOS Swift定数、Android XMLリソースなど、プラットフォームが必要とするものに変換できます。
キーの洞察：ブランドブックと本番コードは同じトークンファイルを使用する必要があります。 ブランドブルーが変わったら、1つのJSONファイルを更新すれば、すべてのところに反映されます。
/* トークンから生成 */
:root {
--color-brand-primary: #0057B8;
--color-brand-primary-light: #3385D6;
--color-brand-primary-dark: #003D80;
--spacing-xs: 4px;
--spacing-sm: 8px;
--spacing-md: 16px;
/* ... */
}
実際に読んでもらえるガイドラインの書き方
ここで厳しい真実です：誰もブランドブックの長い文章の説明を読みません。彼らはスキャンします。具体的な質問への答えを探します。書き方がこれを考慮に入れる必要があります。
Do/Don't形式を宗教的に使用する
すべてのルールには、正しい使用法と正しくない使用法の視覚的またはテキストの例が付属する必要があります。単に「ロゴの周りに適切なクリアスペースを維持してください」ではありません。正しいスペーシングでロゴを表示してください。ロゴを隅に詰め込んでください。1つに「Do」、もう1つに「Don't」というラベルを付けてください。完了です。
スキャン用に書く
- 箇条書きを大量に使用する
- 各段落のキー情報を太字にする
- 段落を最大2～3文に保つ
- 仕様に表を使用する
- 各ページの上部にクイックリファレンスセクションを含める
理由を説明する
これは、従うブランドブックとそれを迂回する人々が作成するブランドブックを分ける要素です。「忙しい写真の背景にロゴを配置しないでください」と言う場合、また理由を言います。「ロゴの細い細部が失われ、小さいサイズで認識が低下します。」
人々が理由を理解している場合、ブランドブックが予想していなかった状況で良い判断を下すことができます。そしていつもあなたが予想していなかった状況があります。
エッジケースを含める
ブランドブックは最小ロゴサイズが24px高さであると言っています。素晴らしい。しかしファビコン、アプリアイコン、ソーシャルメディアアバター、メール署名はどうですか？理想的なシナリオではなく、実際の人々がつまずく本当の世界のエッジケースに対処してください。
デザインとコードを橋渡しするコンポーネント文書
ここでほとんどのブランドブックは止まり、デザインシステムが始まります。しかし、ブランドブックには少なくとも基本的なコンポーネントが含まれるべきだと主張します。ボタン、フォーム入力、カード、ナビゲーションパターン。すべてのページに表示される構成要素。
各コンポーネントについて、文書化してください：
ビジュアル仕様
| プロパティ | 値 |
|---|---|
| Border Radius | var(--radius-md) / 8px |
| Padding | var(--spacing-sm) var(--spacing-md) / 8px 16px |
| Font Size | var(--font-size-sm) / 14px |
| Font Weight | var(--font-weight-semibold) / 600 |
| Min Height | 40px |
| Transition | all 150ms ease-in-out |
状態定義
Default、hover、active、focus、disabled、loading。各状態について、正確なビジュアル変更を指定します。開発者に何が「hover」のように見えるかを推測させないでください。
コード例
// React例
<Button variant="primary" size="md">
Get Started
</Button>
// HTML + CSSクラス例
<button class="btn btn-primary btn-md">
Get Started
</button>
使用ガイドライン
プライマリボタンとセカンダリボタンをいつ使用するか。ページあたりのプライマリボタンの数（ヒント：1つ）。ラベルの規則が何であるか（「Save Changes」ではなく「Save」など、またはブランドが決定するもの）。
ヘッドレスCMSセットアップを操作している場合、これらのコンポーネントパターンは特に重要です。コンテンツ編集者が利用可能なコンポーネントとその使用方法を知る必要があるからです。
ボイス＆トーン：みんなが飛ばす部分
開発者はこのセクションをスキップする傾向があり、それは間違いです。エラーメッセージ、ツールチップ、確認ダイアログ、プレースホルダテキスト、または404ページを書いたことがあるなら、ブランドボイスライターでした。開発者は、ほとんどの人が気付いているよりも多くのユーザーに表示されるコピーを書きます。
良いボイス＆トーンセクションには以下が含まれます：
ブランドボイス属性
ブランドがどのように伝わるかを説明する3～5つの形容詞を選択します。それぞれについて、スペクトラムを提供します：
| 私たちは... | しかし...ではない |
|---|---|
| フレンドリー | カジュアルまたはずさんな |
| 知識のある | 居丈高 |
| 直接的 | ぶっきらぼうまたは冷たい |
| 自信のある | 傲慢 |
文脈別のトーンのバリエーション
ボイスは一貫性を保ちますが、トーンは文脈に応じて変わります。購入後の成功メッセージはチェックアウト中のエラーメッセージと異なる感じがするべきです。
- 成功状態： 温かい、簡潔で、喜びに満ちているが、やり過ぎではない。「Your order is confirmed!」であって「WOOHOO! 🎉🎉🎉」ではありません。
- エラー状態： 共感的で明確で、解決志向。「We couldn't process your payment. Check your card details and try again.」であって「Payment failed.」ではありません。
- 空状態： 有用で励ましになる。「No projects yet. Create your first one to get started.」であって「No data.」ではありません。
ワードリスト
これは地味ですが、非常に有用です。好みの用語のテーブルを作成してください：
| 使用 | 使用しない |
|---|---|
| Sign in | Log in |
| Email address | |
| Free trial | Trial period |
| Dashboard | Home page |
| Team members | Users |
用語の一貫性は、ほとんどのチームが認識するよりも重要です。
ブランドブックを生きたものにしておく
最大のリスクは、悪いブランドブックを構築することではありません。誰もそれを維持しないために徐々に関連がなくなってしまう良いものを構築することです。
所有権を割り当てる
誰かはブランドブックを所有する必要があります。「デザインチーム」ではなく、特定の人。彼らはすべての変更を自分で行う必要はありませんが、変更をレビュー、競合を解決し、精度を確認する責任があります。
バージョン管理を使用する
ブランドブックがウェブサイトの場合（そうあるべき場合）、Gitに保存してください。これにより、次が可能になります：
- すべての修正の変更ログ
- マージ前に変更をレビューする能力（プルリクエスト）
- 提案された更新がステークホルダーの承認を必要とする場合のブランチング
- 何か問題が発生した場合のロールバック
四半期ごとのレビューをスケジュールする
ブランドブックのレビューのための定期的なカレンダーイベントを置いてください。各セクションを見直してください。それはまだ正確ですか？文書化する必要がある新しいパターンがありますか？ブランドブックがルールが実装で機能しないため、人々が回避しているガイドラインがありますか？
貢献を簡単にする
最高のブランドブックはチーム全体からの貢献を受け入れます。開発者がドキュメント化されたボタンパディングがアイコンボタンを考慮していないことに気づきます。修正を提出できるようにします。オープンソースプロジェクトと同様の貢献モデルを使用してください：変更を提案し、レビューを取得し、マージしてください。
ブランド文書化用のツールとプラットフォーム
ここに2026年で実際に検討する価値があるものがあります：
| ツール | 最適 | 価格帯 | アプローチ |
|---|---|---|---|
| Supernova | FigmaからのデザインシステムドキュメンテーションDocs | $49-199/月 | デザインツールから自動化 |
| zeroheight | ブランド+デザインシステムドキュメント | $79-299/月 | ハイブリッド：ビジュアルエディタ+Figma同期 |
| Storybook | コンポーネント文書化 | 無料（オープンソース） | コード優先、コードベースと一緒に動作 |
| Astro + MDX | カスタムブランドブック | 無料（セルフホスト） | 完全な制御、開発者フレンドリー |
| Next.js + MDX | 動的機能を備えたカスタム | 無料（セルフホスト） | 完全な制御、Reactエコシステム |
| Notion | 軽量/初期段階 | 無料-$10/ユーザー/月 | セットアップが高速、カスタマイズが制限される |
| Frontify | エンタープライズブランド管理 | カスタム価格 | 完全なDAM+ガイドライン |
ほとんどのチームの場合、AstroまたはNext.jsを使用したカスタムビルドソリューションは長期的な投資として最良の結果になります。より多くの初期作業が必要ですが、エクスペリエンスを完全にコントロールでき、デザイントークンを直接統合でき、定期的なSaaSビルを持たなくてすみます。その方向を探索したい場合、アーキテクチャについて喜んで議論させていただきます。
この週内で何か実行する必要があるチームの場合、zeroheightはFigma統合が意味するため、設計者がコードに触れることなく寄稿できるため、大幅に改善されています。
実運用のブランドブックアーキテクチャ
複数のクライアントプロジェクトで成功した使用したアーキテクチャを説明させてください。それは固有の意見を持っていますが、機能します。
レイヤー1：デザイントークン（信頼できる情報源）
W3Cデザイントークン形式でJSONトークンファイルを含むGitリポジトリ。これらはStyle Dictionaryを介して変換されます。プラットフォーム固有の出力：CSS custom properties、Tailwind config、Figma variables (Tokens Studioを介して)、Swift/Kotlin定数。
レイヤー2：Figmaライブラリ
Tokens Studioを介してトークンをConsume するFigmaコンポーネントライブラリ。デザイナーはFigmaで作業し、そこのコンポーネントはトークンと一致します。トークンの変更（レビュー付き）はFigmaに反映されます。
レイヤー3：コードコンポーネントライブラリ
トークンから生成されたCSS custom propertiesを使用するReact（またはフレームワーク不可知）コンポーネントライブラリ。これは独自のパッケージまたはモノレポワークスペースに存在します。
レイヤー4：文書化サイト（ブランドブック）
Astroサイトであり、以下を行うサイトです：
- トークンJSONファイルを読み取り、ビジュアルドキュメンテーションを自動的に生成
- コードコンポーネントライブラリからライブコンポーネントプレビューをレンダリング
- ブランドナラティブ、ボイス/トーン、使用ガイドラインのMDXコンテンツを含める
- 下部のレイヤーが変更されるたびに自動的にデプロイ
graph TD
A[Design Tokens JSON] --> B[Style Dictionary]
B --> C[CSS Custom Properties]
B --> D[Figma Variables]
B --> E[Tailwind Config]
B --> F[Mobile Constants]
C --> G[Component Library]
G --> H[Brand Documentation Site]
A --> H
このアーキテクチャの美しさは、ブランドブックが手動で更新する必要がある別のドキュメントではないということです。それは本番環境を強化するのと同じソースから生成されます。トークンが変更されたら、次のデプロイで文書化が自動的に更新されます。
これは、ヘッドレスCMSプロジェクトとNext.jsビルドのために定期的に行っている工学的な種類です。原則は、スタートアップのためのデザインシステムを構築しているか、エンタープライズのためにそれを構築しているかに関わらず同じです。
よくある質問
ゼロからブランドブックを作成するのにどのくらい時間がかかりますか？ デザイントークン、コンポーネント文書化、ウェブベースの形式を備えた完全なブランドブックの場合、4～8週間の集中的な作業を見込んでください。これは、定義されたブランドアイデンティティ（ロゴ、色、タイポグラフィの選択）が既にあると仮定しています。ブランドアイデンティティの発見とデザインフェーズから開始する場合は、さらに4～6週間を追加してください。最小限のブランドブック（色、タイポグラフィ、ロゴ使用方法、基本的なボイスガイドライン）は2週間で実行できます。
開発者はブランドブック作成に関与すべきですか？ 絶対に。これは見かけられる最大の逃す機会の1つです。チーム全体の少なくとも1人のシニア開発者を関与させます。彼らは初期段階で非実用的な仕様をキャッチし（「このフォントはコードブロック用のモノスペース変形がありません」）、トークン構造が実装にとって意味があることを確保し、実際に使用する文書化の種類を提唱してください。最高のブランドブックはデザインとエンジニアリングによって共著されています。
ブランドブックとデザインシステムの違いは何ですか？ ブランドブックはブランドがどのように見えるか、どのように聞こえるか、どのように感じるかを定義します。デザインシステムは実装を提供します。つまり、ブランドを構築するために必要な実際のコンポーネント、パターン、コードです。実際には、線はぼやけており、最良のアプローチは両方を組み合わせています。ブランドブックに実装の詳細を含めるのに十分な詳細が含まれるべきであり、デザインシステムはコンポーネントの背後にあるブランド原理を参照すべきです。
ブランドが進化するときにブランドブックのバージョンをどのように処理しますか？ セマンティックバージョニングをトークンに使用し、重大な変更を明確に文書化します。マイナーなカラー調整はパッチです。パレットに新しい色を追加することはマイナーバージョンです。プライマリブランドカラーを変更することはメジャーバージョンです。ブランドブックがGitに存在する場合、これは無料です。リリースにタグを付け、変更ログを作成し、コードリリースに使用するのと同じチャネルを通じて変更を伝達してください。
デザイントークンとは何であり、本当に必要ですか？
デザイントークンは、デザイン決定を表す名前付きの値です。color-brand-primary: #0057B8の代わりにハードコードされた16進値。複数の開発者、複数のプラットフォーム、または時間をかけて一貫性を維持する意向がある場合は、それらが必要です。それらはブランドブックをリファレンスドキュメントから執行可能なシステムに変わるメカニズムです。W3Cデザイントークン仕様は2025年の候補勧告以来、大幅に成熟しており、2026年のツールサポートは堅牢です。
SaaSツールまたはカスタムブランドブックサイトを使用すべきですか？ チームサイズとテクニカル容量に依存します。専任のフロントエンド開発者がいない10人未満？zeroheightまたはNotionを使用して何か迅速に生きれます。複数の製品を備えた10人以上、または自分を維持できる開発チーム？カスタムサイトを構築してください。カスタムルートはフロントアップでより多くの費用がかかりますが、柔軟性、トークンパイプラインとの統合、定期的なライセンス費用なしで支払われます。カスタム文書化サイトビルドが何を伴うかについて、価格ページを確認してください。
ブランドブック内のコンポーネント文書化はどの程度詳細である必要がありますか？ 新しい開発者が質問をせずにコンポーネントを正しく実装できるほど詳細です。つまり、すべての状態のビジュアル仕様、プライマリフレームワーク内のコード例、使用ガイドラインの場合（使用する場合、使用しない場合）、アクセシビリティ要件、レスポンシブ動作メモ。コンポーネントについて同じSlack質問に2回答える場合、答えはブランドブックに入るべきです。
ブランドブックの実際の使用をどのように取得しますか？ うまくいく3つのタクティック：まず、ブランドブックをチェックするのがSlackで尋ねるよりも高速にします。つまり、良い検索、明確なナビゲーション、コピーペースト対応の値。第二に、それをワークフローに統合します。PRレビューチェックリスト、Figmaファイルの説明、オンボーディングドキュメントにブランドブックリンクを追加します。第三に、人々がそれに貢献させます。チームが集合的にブランドブックを所有している場合、彼らはその成功に投資されています。最悪のことはそれを誰もが上からの命令として扱う対象として扱うことで、誰も入力を持っていません。