見出し画像

AIでブランドを守る"視覚言語"の作り方

azshi

この記事は、視覚言語を「実際にどう作って、どう使うか」の実践編です。



視覚言語の構成

視覚言語は1つの長いプロンプトではなく、
抽象度ごとに分けたファイル群として持っています。全体像は次の3層です。

  • 大きな方向性 
    どんな空気感で見せるか、どんな構造を基本にするか、何をよしとし、何を避けるかを定義する層。

  • 制作ルール
    上位の視覚方針を、色・shape・タイポグラフィなど、実際の制作で使えるルールに変換する層。

  • 実行時の指示
    今回の制作物では何を作るのか、どのルールを強く効かせるのか、どこを例外的に調整するのかを指定する層。

上の層ほど抽象的で安定、下の層ほど具体的でその場限り。

私の場合は、次のファイルに分けています。

◆大きな方向性ファイル
design.md
視覚言語の中心。ブランドの方向性・トーン・固定ルール・NG方向を書く

visual-language.json
design.md をAIが参照しやすいよう構造化したもの

◆制作ルールファイル
color ファイル
使ってよい色や配色パターンを定義する。

shape ファイル
使ってよいshapeや、その使い方を定義する。

typography ファイル
文字の扱いを定義する。見出し・本文・ラベルの方向性や、避けたい文字表現を書く。

この層では、上位の視覚方針を、実際の制作で使えるルールに落とします。
詳しいファイル構成や作り方は長くなるので、この記事では役割の紹介に留めます。

◆実行時の指示ファイル
実行時の指示は、生成時にAIへ渡すプロンプトです。
よく作る制作物の指示は、テンプレートとして保存しておくと再利用しやすくなります。

使い方

すべてのファイルを毎回使うわけではありません。
実際の運用では、作りたいものに合わせて、必要なファイルだけを選んで渡します。

まず大きな方向性だけ合わせたいときは、design.md や visual-language.json を使います。デザイン案を広げたい段階では、あまり細かく縛りすぎない方がよいこともあります。

ただし、案出しでも「色だけはブランドに寄せたい」場合は、color file を追加します。逆に、shapeに強くこだわらないなら、shape asset までは渡しません。

文字を使わないビジュアルなら、typography file も不要です。
登録済みshapeを使って厳密に仕上げたいときだけ、shape library や source inventory、SVG asset を渡します。

最後に、実行時のプロンプトで調整します。

たとえば、
「今回は案出しなので自由度を残す」
「色はブランドルールに寄せる」
「shapeは厳密に使わなくてよい」
「UI表現は抑える」
といった指示を加えます。

ここからは、上位ファイルである design.md と visual-language.json の中身を見ていきます。

design.md の書き方

design.md は、視覚言語のいちばん上位に置く方針書です。
テンプレートにしたので、 [ ] カッコの中を書き換えて使えます。

# Design System / Visual Direction 
## [視覚言語の名前]

## 1. このファイルの役割
このファイルは、[ブランド名] の制作物に共通する上位の視覚方針を定義する。
目的は、個別の制作物ごとに細かい見た目を固定することではない。 
どの制作物でも、[ブランド名] らしい判断ができるようにするための基準を与えることである。 
ここで決めるのは、細かい色や素材IDではなく、 
どんな空気感で見せるか、何をよしとし、何を避けるか、という判断基準である。


--- ## 2. Core Idea
[ブランド名] の視覚言語は、
[対象サービス / プロダクト] を、
[こう見せたい] ものとして見せるためのものである。

[ブランド名] の本質は、特定のパーツそのものではない。 
本質は、[構造 / 色 / 余白 / タイポ / 形 / トーン] によって成立する。


--- ## 3. Core Tone 
### 目指すトーン 
[- 明るい - 整理されている - 親しみやすい - 信頼感がある] 

### 避けるトーン
[- かわいすぎる - 無機質すぎる - 安っぽい]


--- ## 4. Visual Roots / Source Lineage
この視覚言語は、以下の視覚的な源流を参照する。
[- neo-brutalism の輪郭線 - 例：幾何学的なグラフィック表現]

ただし、それらをそのまま再現しない。
避けるものは以下である。
[- ネオンやグローに寄せすぎる]

目指すのは、参照元の雰囲気をそのまま真似ることではなく、 
[ブランド名] に合う形で再構成することである。 


--- ## 5. Fixed Principles
以下は、媒体や制作物が変わっても基本的に維持する。
### 5.1 構造 
[- モジュール構造を基本にする]

### 5.2 タイポグラフィ
[- 見出しは太く、読みやすくする]

### 5.3 色
[- アクセントカラーは制御して使う]
 
### 5.4 線・面・質感
[- フラットで明快な面を基本にする]
 
### 5.5 プロダクト / ブランドとしての説得力 
[ブランド名] の制作物は、偶然できた装飾ではなく、
意図を持って設計されたように見えることを重視する。 


--- ## 6. 表現の強度 
制作物の目的に応じて、表現の強度を切り替える。

### 抑える場合 
[記事内の抽象挿絵、ブランドイメージ、ノベルティなど] 
この場合は、[使わない要素] を避ける。 
ブランドらしさは、[色 / 構造 / 余白 / タイポ / 形] で表現する

### 中程度に使う場合 
[LPの補助ビジュアル、機能紹介、説明図など] 必要な要素だけを使い、
装飾になりすぎないようにする。 

### 強く使う場合 
[プロダクト画面、機能説明、操作イメージなど] 
実際に使えそうな構造として見せる。 
ただし、テンプレート的で無個性な見た目にはしない。 


--- ## 7. Variable Rules
以下は、制作物の目的に応じて変えてよい。
[- レイアウト - 情報密度 - コピー量 - アクセントカラーの主従 - 図形や装飾の量 - UI表現の強度 - 媒体形式]


--- ## 8. Element Library
### 常に使いやすい要素
[- 太い輪郭線 - フラットな幾何学面]

### 必要な場合だけ使う要素
[- cards - panels - browser frame]


--- ## 9. Output Guidance 
### バナー
[- 一目で読める構成にする]

### LP / Web
[- ブランドイメージではUIを抑える]

### 記事内挿絵 / 抽象グラフィック
[- 解説図になりすぎない]

### ノベルティ / グッズ - - - 
[- UI画面をそのまま載せない]


--- ## 10. What Makes This Work
この視覚言語が成立する理由は以下である。
[1. 構造が強い 2. 色が遊んでも骨格が崩れない 3. UIがなくてもブランド感が残る 4. 幾何学文法が統一感を生む 5. 楽しいが制御されている]


--- ## 11. What Breaks It
以下をやると、ブランドらしさが壊れやすい。
[- 輪郭線が弱い - 色数が多すぎる - かわいさが強すぎる - UIパーツを入れすぎる]


--- ## 12. Hard NG Directions
以下は明確に避ける。
[- 強いグラデーション - ネオン、グロー - ガラスモーフィズム]


--- ## 13. Fixed vs Variable Summary
### Fixed
[- 明るいニュートラル背景 - 濃色の輪郭線]

### Variable
[- レイアウト - 情報密度 - UI表現の強度]


--- ## 14. Operational Guidance 
### 出力がかわいすぎる場合
[- 丸さを減らす - 輪郭線を強くする]

### 出力が冷たすぎる場合
[- アクセントカラーを足す]

### 出力が散らかる場合
[- 要素数を減らす - 余白を増やす - 色数を絞る]

### 出力がテンプレート的に見える場合
[- ブラウザ枠やカードを減らす]


--- ## 15. Suggested Prompting Workflow
AIに制作させるときは、以下の順番で参照する。
[- design.md を読む - visual-language.json を読む - 必要に応じて、色・shape・タイポグラフィの具体ファイルを読む…]

確認項目：
[- ブランドらしい構造になっているか - 色がぶれていないか… ]


--- ## 16. Short Definition for Reuse
[ブランド名] は、[対象となるサービス / プロダクト] を、
[主要な視覚要素] によって、
[目指す印象] として見せる視覚言語である。


--- ## 17. AI向け短いスタイルタグ
[ブランドらしさを表す短い言葉]
[構造を表す言葉]
[トーンを表す言葉]
[避けたい方向の逆を表す言葉]
[制作物に共通する印象]

各セクションの意味はこちら

* **このファイルの役割** … 何を定義するファイルかを書く
* **Core Idea** … ブランドをどう見せたいかを書く
* **Core Tone** … 目指す印象と避ける印象を書く
* **Visual Roots / Source Lineage** … 参考にする視覚的な源流を書く
* **Fixed Principles** … どの制作物でも守る基本ルールを書く
* **UI Expression Level** … UI表現をどの程度使うかの基準を書く
* **Variable Rules** … 制作物ごとに変えてよい要素を書く
* **Element Library** … 使いやすい視覚要素を整理する
* **Output Guidance** … 媒体ごとの注意点を書く
* **What Makes This Work** … この見た目が成立する理由を書く
* **What Breaks It** … ブランドらしさが崩れる条件を書く
* **Hard NG Directions** … 明確に避ける表現を書く
* **Fixed vs Variable Summary** … 固定要素と可変要素をまとめる
* **Operational Guidance** … 出力がずれたときの直し方を書く
* **Suggested Prompting Workflow** … AIに渡すファイルの順番とレビュー方法を書く
* **Short Definition for Reuse** … 視覚言語を短く説明できる定義を書く
* **AI向け短いスタイルタグ** … 生成時に補助的に使う短いタグを書く


visual-language.jsonの書き方

visual-language.json は、design.md に書いた視覚方針を、AIが参照しやすい形に構造化するファイルです。

文章で長く説明するのではなく、トーン、構成、色、タイポグラフィ、UI表現、避ける方向などを項目ごとに分けて持たせます。

{
  "visual_language_name": "[視覚言語の名前]",
  "version": "1.0",
  "summary": "[この視覚言語を一文で説明する]",

  "core_idea": {
    "japanese": "[このブランドをどう見せたいか]",
    "english": "[AI生成時に使いやすい英語の短い説明]"
  },

  "emotional_tone": {
    "primary": [
      "[目指す印象1]",
      "[目指す印象2]",
      "[目指す印象3]"
    ],
    "avoid": [
      "[避けたい印象1]",
      "[避けたい印象2]",
      "[避けたい印象3]"
    ]
  },

  "typography_system": {
    "headline_role": "[見出しの役割]",
    "body_role": "[本文や小さな文字の役割]",
    "principles": [
      "[文字で守ること1]",
      "[文字で守ること2]",
      "[文字で避けること]"
    ]
  },

  "color_system": {
    "base_logic": "[色の基本方針]",
    "principles": [
      "[色で守ること1]",
      "[色で守ること2]",
      "[色で避けること]"
    ]
  },

  "composition_philosophy": {
    "core": "[構図の基本方針]",
    "principles": [
      "[構成で守ること1]",
      "[構成で守ること2]",
      "[構成で避けること]"
    ]
  },

  "graphic_language": {
    "universal_elements": [
      "[常に使いやすい視覚要素1]",
      "[常に使いやすい視覚要素2]",
      "[常に使いやすい視覚要素3]"
    ],
    "contextual_elements": [
      "[必要な場合だけ使う要素1]",
      "[必要な場合だけ使う要素2]",
      "[必要な場合だけ使う要素3]"
    ]
  },

  "ui_expression_level": {
    "default": "contextual",
    "rule": "[UI表現をどう扱うか]",
    "levels": {
      "none": "[UIを使わない場合]",
      "low": "[UIを弱く使う場合]",
      "medium": "[UIを中程度に使う場合]",
      "high": "[UIを強く使う場合]"
    }
  },

  "non_negotiables": [
    "[絶対に守る要素1]",
    "[絶対に守る要素2]",
    "[絶対に守る要素3]"
  ],

  "avoid_rules": [
    "[明確に避ける表現1]",
    "[明確に避ける表現2]",
    "[明確に避ける表現3]"
  ],

  "review_checklist": [
    "[生成後に確認すること1]",
    "[生成後に確認すること2]",
    "[生成後に確認すること3]"
  ]
}

各項目の役割はざっくりこうです。

visual_language_name … 視覚言語の名前
summary … 視覚言語を一文で説明する
core_idea … ブランドをどう見せたいかを書く
emotional_tone … 目指す印象と避ける印象を書く
typography_system … 文字の役割と避ける表現を書く
color_system … 色の使い方の方針を書く
composition_philosophy … 構図やレイアウトの考え方を書く
graphic_language … 使いやすい視覚要素を整理する
ui_expression_level … UI表現をどの程度使うかの基準を書く
non_negotiables … 絶対に守る要素を書く
avoid_rules … 明確に避ける表現を書く
review_checklist … 生成後に確認する項目を書く

ポイントは、design.md の内容をそのままJSONに貼るのではなく、AIが判断しやすい単位に分解することです。

たとえば design.md で、
「楽しいが幼くしない」と書いていたら、
visual-language.json では、

{
  "emotional_tone": {
    "primary": ["playful", "friendly"],
    "avoid": ["childish", "toy-like", "overly cute"]
  }
}

のように、目指す方向と避ける方向を分けて書きます。

visual-language.json は、人間に読ませる説明書というより、AIが制作時に参照する判断表です。そのため、長い文章よりも、短い項目と配列で整理しておく方が使いやすくなります。

おわりに

今回は、視覚言語を1つの長いプロンプトではなく、複数のファイルに分けて持つ考え方を書きました。

design.md と visual-language.json は、AIに細かく命令するためのものではなく、ブランドらしい判断に戻るための上位ファイルです。

流れ的にはこの上位方針を実制作で使えるルールの作り方ですが、
そのまえに、そもそも視覚言語使うことは意味あるのか？を実際に生成した画像をふまえて見てみたいと思います。　

つづく。

関連記事


いいなと思ったら応援しよう！