Logo Design Skill

PDCAサイクルで反復改善するロゴデザインスキル。 1回で完璧なロゴは生まれない。何回もプロセスを回して最高のものに近づける。

コンセプト

Step 1 → Step 2 → Step 3 → ... → Final
 Plan     Plan     Plan              仕上げ
 Do       Do       Do
 Check    Check    Check
 Act      Act      Act
  ↓        ↓        ↓
 前回の   前回の   「これだ！」
 FB反映   FB反映    → 最終制作

• 毎ステップで5人の専門エージェントが議論し、SVGを5案生成
• ユーザーが見てフィードバック → 次のステップに反映
• 全ステップの議論・ロゴ・メモが履歴として残る
• 気に入るまで何回でも回せる

ディレクトリ構造

.claude/logo-design/{YYYY-MM-DD}_{project-name}/
├── context.md              # ブランド情報・制約・蓄積された知見
├── step-01/
│   ├── discussion.md       # エージェント5人の議論結果（全文）
│   ├── logo-notes.md       # アイコンごとのメモ（良い点・悪い点・改善案）
│   ├── review.md           # ユーザーFB + 次stepへの改善方針
│   ├── thinking-journey.md # 思考の軌跡（方向転換時に推奨）
│   └── logos/
│       ├── v1-{name}.svg
│       ├── v2-{name}.svg
│       └── ...
├── step-02/
│   ├── discussion.md
│   ├── logo-notes.md
│   ├── review.md
│   └── logos/
│       └── ...
├── step-03/
│   └── ...
└── final/                  # 最終承認後に作成
    ├── logos/              # 最終SVG（フルカラー + モノクロ）
    ├── report.md           # 最終レポート
    └── pencil/             # Pencil制作のスクショ等

各ファイルの役割

context.md — ブランド情報の蓄積ファイル（随時更新）

# {Project} - Logo Design Context

## ブランド情報
- アプリ名: {name}
- 概要: {description}
- ターゲット: {target}
- カラー: {colors}
- 用途: {usage}

## 制約・好み
- 好みの方向性: {preferences}
- 避けたいスタイル: {avoid}

## 蓄積された知見（ステップを経るごとに追記）
### Step 1 で学んだこと
- {insight_1}
- {insight_2}
### Step 2 で学んだこと
- {insight_3}

logo-notes.md — アイコンごとのメモ書き

# Step {N} - ロゴメモ

## V1: {コンセプト名}
- **ファイル**: logos/v1-{name}.svg
- **コンセプト**: {1行説明}
- **良い点**: {具体的に}
- **悪い点**: {具体的に}
- **改善アイデア**: {次にどうすれば良くなるか}
- **残す？**: ○ 発展させる / △ 要素だけ残す / × 捨てる

## V2: {コンセプト名}
...

review.md — ステップの振り返りと次への方針

# Step {N} レビュー

## ユーザーフィードバック
{ユーザーの生の声をそのまま記録}

## エージェント自己評価
{各エージェントの評価サマリー}

## 次ステップへの方針
- **続行する方向性**: {残すコンセプト}
- **捨てる方向性**: {やめるコンセプト}
- **新しく試すこと**: {次のステップで挑戦すること}
- **重点改善点**: {最も優先して直すべきこと}

Phase 0: 初期化

0-1. ブランドエッセンス読み込み

まず docs/brand-essence.md の存在をチェックする。

• ある場合 → 自動読み込みし、context.md に「ブランドエッセンス」セクションとして取り込む。全エージェントのプロンプトに含める。
• ない場合 → ユーザーに通知:

  docs/brand-essence.md が見つかりません。
  /brand-essence を先に実行すると、より的確なロゴが作れます。
  このまま続行する場合、最低限の情報をヒアリングします。
  

0-2. ヒアリング

以下を確認する（brand-essence.md で既に埋まっている項目はスキップ）:

ブランドエッセンス（brand-essence.md がない場合は必須）:

• カテゴリ帰属: 何のアプリか一言で（例: ポモドーロタイマー）→ ロゴのモチーフ選定に直結
• USP: 一番の売り（例: 強制打ち切り）→ ロゴの差別化要素に直結
• 差別化ポイント: 競合との違い（例: 他は無視できる、fptは無視できない）
• タグライン: ユーザーに一言で伝えたいこと

ロゴ固有の情報:

• アプリ/サービス名: ロゴに含める名前
• ターゲット: 年齢層、地域、技術レベル
• ロゴの用途: アプリアイコン / ブランドロゴ / 両方
• 好みの方向性: ミニマル / ポップ / プロフェッショナル / 指定なし
• 好きなロゴの例: あれば参考として
• 避けたいスタイル: あれば
• 色の希望: あれば（ブランドカラー等）
• 競合/同業他社: 知っていれば

0-2. 作業ディレクトリ作成

mkdir -p .claude/logo-design/{YYYY-MM-DD}_{project-name}/step-01/logos

0-3. context.md 作成

ヒアリング結果を context.md に保存。 既存プロジェクトの継続なら、前回の context.md を読み込んで追記。

削る原則（最重要）

ロゴは「要素を足して説明する」より「核を残して削る」方が強い。

Step 1-3 は探索フェーズとして多くのモチーフを試してよい。 しかし Step 4 以降は、ユーザーが気に入った方向が見えたら 削る方向に切り替えること。

探索フェーズ（Step 1-3）:
  人・トマト・時計・植物... → 色々試す
  ↓ ユーザーが方向を選んだら

収束フェーズ（Step 4+）:
  選ばれた核を残し、それ以外を削る
  「もう1要素足したい」→ まず「本当に必要か？」を問う
  16px でも潰れないか？ ノイズにならないか？
  ↓ 削って削って削り切ったものが最強

よくある失敗パターン

❌ Step 6 で2色分割円が選ばれた
   → Step 7 で人のシルエットを追加
   → Step 8 でトマト形も試す
   → 結果: 主役がぼやけて16pxで潰れる

✅ Step 6 で2色分割円が選ばれた
   → Step 7 で分割線のカーブ違いを5案比較
   → Step 8 で太陽/月の有無・サイズを微調整
   → 結果: 核が研ぎ澄まされて16pxでも読める

収束フェーズの判断基準

ユーザーが以下のいずれかを示したら、収束フェーズに入る:

• 特定の案を「いいね」「これ」と指名した
• 特定の方向性を「これ系で」と指定した
• 新モチーフを「いらない」と否定した

収束フェーズでは:

• 新しいモチーフを追加しない（人・トマト・時計針等）
• 同じ核の微調整だけで5案作る（角度・サイズ・比率・位置）
• 「足す」提案より「引く」提案を優先する

Phase 1: PDCA サイクル（繰り返し）

Plan（計画）— エージェントチーム議論

TeamCreate でチーム作成。5エージェントを 1つのメッセージで並列に 起動。

name	役割	Step 1	Step 2+
brand-strategist	コンセプト方向性	新規提案	feedback反映して再提案
logo-designer	形状・構図の具体的設計	新規設計	feedback反映して再設計
color-type-expert	カラー・フォント設計	新規設計	微調整
trend-researcher	トレンド・文化調査	フル調査	必要時のみ（省略可）
competitive-analyst	競合調査・差別化	フル調査	必要時のみ（省略可）
quality-validator	品質ガイドライン検証	SVG生成後に検証	SVG生成後に毎回検証

起動設定

subagent_type: "logo-design:{agent-name}"
team_name: "{team-name}"
model: "opus"
mode: "bypassPermissions"
run_in_background: true

全ステップのプロンプトに必ず含めるもの（Step 1 含む）

品質ガイドラインは全エージェントに毎回送ること。 ロゴデザイナーだけでなく、 ブランド戦略家やカラー専門家にも品質基準を共有することで、提案の質が上がる。

# ロゴ品質ガイドライン（必ず従うこと）

## よいロゴの条件
- 太いストローク（strokeWidth 10px以上）
- ブランドカラー間の明度・彩度のコントラストを強く出す
- 1アイコン = 1アイデアに絞る
- シンプルな幾何学形状（円・Y字・M字等）
- 水平・垂直の線を基本にする
- 意図的な非対称で視覚的な動き・緊張感を出す

## 左右非対称のデザイン原則（重要）
完全な対称は退屈に見える。意図的な非対称を取り入れて洗練された印象を作る。
- 基本形は対称でも、1要素だけ崩す（切れ目、ズレ、色の偏り等）
- 視線の流れを作る非対称（左→右への動き、回転の方向性）
- ネガティブスペースを非対称に使い、意味を持たせる
- 非対称 ≠ バランスが悪い。視覚的重心は保つこと

## 線は滑らかに
- 直線(line)ではなく曲線(path/Bezier)を使う
- stroke-linecap="round", stroke-linejoin="round"
- 16px に縮小しても形が認識できること

## チェックリスト
- 1秒見ただけで「何を表しているか」がわかるか
- 16x16px に縮小しても形が認識できるか
- ブランドカラーのコントラストが十分に効いているか
- モノクロにしても成立するか
- 意図的な非対称が含まれているか

Step 2+ のプロンプトに追加で含めるもの

# 前回までの経緯
{context.md の全文}

# 前ステップの議論
{前step/discussion.md のサマリー}

# 前ステップのロゴメモ
{前step/logo-notes.md の全文}

# 前ステップのレビュー（最重要）
{前step/review.md の全文}

# あなたのタスク
上記のフィードバックを踏まえて、改善案を提案してください。
特に「次ステップへの方針」に記載された改善点を重点的に反映すること。

Do（実行）— SVG生成 + 目視確認 + 品質バリデーション

エージェントの議論結果を discussion.md に保存した後:

1. logo-designer の提案に基づき SVG を5案生成
2. step-{N}/logos/ に保存（命名: v1-{concept-name}.svg）
3. logo-notes.md に各アイコンのメモを記録
4. SVG目視確認（必須）:

   # XMLバリデーション
   for f in step-{N}/logos/*.svg; do xmllint --noout "$f"; done
   # PNGレンダリング（256px + 16px で確認）
   mkdir -p /tmp/logo-previews
   for f in step-{N}/logos/*.svg; do
     base=$(basename "$f" .svg)
     rsvg-convert -w 256 -h 256 "$f" -o "/tmp/logo-previews/${base}-256.png"
     rsvg-convert -w 16 -h 16 "$f" -o "/tmp/logo-previews/${base}-16.png"
   done
   

   • 256px版を Read ツールで目視確認（形の崩れ、三日月の向き等）
   • 16px版で潰れていないか確認
   • 問題があればSVGを修正してから次に進む
5. quality-validator を起動し、全SVGを品質チェック
   • 7基準（視覚的意味、ストローク、コントラスト、非対称性、シンプルさ、スケーラビリティ、SVGコード）でスコアリング
   • 不合格（6点以下）のSVGは修正指示に従い即修正してから Check に進む
   • 条件付き合格（7-9点）は修正指示を logo-notes.md に追記
   • バリデーション結果を step-{N}/validation.md に保存

Check（評価）— フィードバック収集

1. ユーザーに SVG を見せる（ファイルパスを提示）
2. ユーザーの感想を聞く
   • 「どれが好き？」「何が気になる？」「もっとこうしたい？」
3. review.md に記録:
   • ユーザーの生の声
   • 各ロゴの評価
   • 次に向けた改善方針

Act（改善判断）

ユーザーに確認:

このステップの結果を踏まえて:
1. もう1ラウンド回して改善する
2. この中から最終候補を選んで仕上げに入る
3. 方向性を大きく変えてやり直す

• 1を選んだ場合 → context.md の「蓄積された知見」に追記 → 次の step ディレクトリを作成 → Plan に戻る
• 2を選んだ場合 → Phase 2（最終仕上げ）に進む
• 3を選んだ場合 → review.md に「方向転換の理由」を記録 → context.md 更新 → Plan に戻る（ただしリサーチ系エージェントも再起動）

Phase 2: 最終仕上げ

2-1. Pencil 制作

エージェントの最終提案に基づき、リーダーが Pencil で制作:

1. get_style_guide_tags → get_style_guide でスタイル参考を取得
2. find_empty_space_on_canvas でキャンバス配置を計画
3. 最終候補を batch_design で作成:
   • 各バリエーションを横に並べて配置（比較しやすく）
   • フルサイズ版 + アプリアイコン版を両方作成
   • 明るい背景版 + 暗い背景版
4. get_screenshot で各バリエーションを確認

2-2. SVG 出力

1. Pencil のデザインを基に SVG コードを最適化
2. フルカラー版とモノクロ版の2種類
3. final/logos/ に保存
4. プロジェクトの assets/ にもコピー

2-3. 最終レポート

テンプレートは references/report-template.md を参照。 final/report.md に出力。追加で以下を含める:

• PDCAの経過サマリー: 何ステップ回したか、各ステップで何が変わったか
• 却下された案とその理由: 将来のリデザイン時の参考に

Phase 3: クリーンアップ

1. 全エージェントに shutdown_request を送信
2. 全員シャットダウン後に TeamDelete でチーム削除
3. 作業ディレクトリは 削除しない（履歴として残す）

---

既存プロジェクトの継続

前回のセッションで作成した作業ディレクトリがある場合:

1. .claude/logo-design/ 配下の既存ディレクトリを確認
2. 最新の context.md と最後の step の review.md を読み込む
3. 次の step 番号から継続（例: step-03 まであれば step-04 から）
4. Phase 1 の PDCA サイクルに入る

Pencil batch_design の必須ルール

フレームには必ず layout: "none" を指定すること。

Pencil のフレームはデフォルトで Flexbox（自動レイアウト）モードになる。 この状態では子要素に x, y を指定しても完全に無視される。

// ❌ 悪い例: x/y が無視される
I(document, {type:"frame", x:100, y:200, width:500, height:400})

// ✅ 正しい例: layout:"none" で絶対座標配置モードになる
I(document, {type:"frame", x:100, y:200, width:500, height:400, layout:"none", placeholder:true})

適用対象: 絶対位置を使う全フレーム（セクションフレーム、各カード、アイコンコンテナすべて）

ロゴ品質ガイドライン

大前提: 意味が読み取れること

Step 1-3 では具体的なモチーフから始める。しかし、削って洗練された結果が ミニマルになることは許容する。

最初から抽象を狙うのはNG。しかし「具体から始めて削った結果の抽象」はOK。

❌ NG: 最初から抽象的な円弧や線だけのデザイン
       → 「おしゃれだけど何のアプリかわからない」
❌ NG: 説明されないと意味がわからないシンボル
       → 「この傾きには成長の意味が...」← 伝わらない
❌ NG: 具体モチーフを無理に詰め込む
       → 「時計の針を入れたら汎用タイマーアプリと同じになった」

✅ OK: 時計アプリなら時計に見えること（初期段階）
✅ OK: 削った結果、2色分割だけで「昼と夜」が読み取れるミニマルな形になった
✅ OK: 最小限の記号（丸=太陽、三日月=月）で意味を補強する

探索フェーズ（Step 1-3）のチェック:

• 5歳児に見せても「何の絵？」に答えられるか
• アプリのカテゴリが一目で伝わるか
• 円弧だけ、線だけの純粋な抽象デザインになっていないか

収束フェーズ（Step 4+）のチェック:

• 核となるモチーフが何か明確か
• 追加した要素が16pxで潰れないか
• 「もう1要素足したい」→ 本当に必要か？ 削れないか？
• ユーザーが選んだ方向性を壊していないか

抽象と具体のバランス:

• 初期ステップ: 具体的なモチーフから始める（時計、ストップウォッチ等）
• 中期以降: ユーザーの好みに合わせて削る（削った結果のミニマルはOK）
• 最終段階: 核 + 最小限の補助記号（例: 2色円 + 小さな太陽と月）

よいロゴの条件（メリハリを出す）

❌ 避けること              ✅ やること
─────────────────────────────────────────
抽象的な図形のみ          具体的なモチーフをベースにする
細い線を多用              太いストローク（strokeWidth 10px以上）
似た色のみで単調          ブランドカラー間の明度・彩度のコントラストを強く出す
要素を詰め込む            1アイコン = 1アイデアに絞る
複雑な形状                シンプルな幾何学形状（円・Y字・M字等）
斜めの直線を多用          水平・垂直の線を基本にする
完全な左右対称            意図的な非対称で視覚的な動き・緊張感を出す

左右非対称のデザイン原則

完全な対称は退屈に見える。意図的な非対称で洗練された印象を作る。

優れたロゴは完全に対称であることは少ない。左右非対称（アシンメトリー）を 意図的に取り入れることで、視覚的な動き・リズム・緊張感が生まれ、 記憶に残りやすいロゴになる。

❌ NG:  完全な左右対称の形状のみ → 退屈・汎用的・記憶に残らない
✅ 推奨: 基本形は対称でも、1要素だけ崩す（切れ目、ズレ、色の偏り等）
✅ 推奨: 視線の流れを作る非対称（左→右への動き、回転の方向性）
✅ 推奨: ネガティブスペースを非対称に使い、意味を持たせる
✅ 注意: 非対称 ≠ バランスが悪い。視覚的重心は保つこと

非対称のテクニック例:

• 円形モチーフの一部を欠ける・切る → 動きと意味が生まれる
• 文字の1文字だけ色・サイズ・位置を変える → アクセントになる
• シンボルをグリッドの中心から意図的にずらす → 緊張感が出る
• 左右で線の太さや長さを変える → リズムが生まれる

⚠️ 線は滑らかに（SVG・Pencil共通）

直線(line)ではなく曲線(path/Bezier)を使って滑らかに描く。 直線の斜めstrokeはアンチエイリアスでギザつき・歪みが出やすい。 曲線で滑らかに描くことで、小サイズでも美しく見える。

❌ NG:   line要素の直線を組み合わせてアイコンを構成する
✅ 推奨: path + Bezier曲線（C / Q コマンド）で滑らかなカーブにする
✅ 推奨: stroke-linecap="round", stroke-linejoin="round" で端・角を丸める
✅ 代替: polygon / path の塗り面で表現する（面は歪みにくい）
✅ 検証: 必ず小サイズ（32px, 16px）で実際にレンダリングして歪みがないか確認

<!-- ❌ 直線の組み合わせ → 角がカクつく、小サイズで歪む -->
<line x1="70" y1="130" x2="36" y2="44" stroke="white" stroke-width="11"/>

<!-- ✅ Bezier曲線 → 滑らかで美しい -->
<path d="M70,130 C70,100 50,70 36,44" stroke="white" stroke-width="11"
      fill="none" stroke-linecap="round"/>

各バリエーションのチェックリスト:

• 1秒見ただけで「何を表しているか」がわかるか
• 16x16px に縮小しても形が認識できるか
• ブランドカラーのコントラストが十分に効いているか
• モノクロにしても成立するか
• 斜め線が歪んで見えないか（Pencilスクリーンショットで必ず確認）
• 要素が多すぎないか（「削る原則」に反していないか）
• ユーザーが選んだ方向性に沿っているか（収束フェーズの場合）

過剰複雑性チェック（収束フェーズで特に重要）

❌ 要素を足しすぎのサイン:
- SVG の path 要素が 8 個以上
- 白い要素（#F0F0F2）が 4 個以上
- 円・矩形以外の複雑な形状が 3 個以上
- 16px に縮小すると「何かの塊」にしか見えない

✅ 適切な複雑さ:
- 主役: 1つ（例: 2色分割された円）
- 補助: 1-2個（例: 太陽ドット + 三日月）
- 装飾: 最小限（例: ごく薄い外周リング）

SVGパターン集（再利用可能）

2色S字分割パターン

円を2色に非対称S字カーブで分割する。clipPath で円の外にはみ出さないようにする。

<defs>
  <clipPath id="circClip">
    <circle cx="64" cy="64" r="52"/>
  </clipPath>
</defs>
<rect width="128" height="128" rx="28" fill="#141414"/>
<circle cx="64" cy="64" r="52" fill="{明色}"/>
<path d="M82 12 C72 28 66 44 64 64 C62 84 56 100 46 116 L116 116 L116 12 Z"
      fill="{暗色}" clip-path="url(#circClip)"/>

S字カーブの調整方法:

• 上部の始点(M)のX座標を大きくする → 暗い面が広がる
• Bezier制御点のX座標を変える → S字の深さが変わる
• 下部の終点のX座標を変える → 分割の角度が変わる

三日月パターン

白い円 + 背景色の円を重ねて三日月を作る。

<!-- 三日月（右下配置の例） -->
<circle cx="84" cy="84" r="7" fill="#F0F0F2" opacity="0.90"/>
<circle cx="88" cy="81" r="7" fill="{背景に合わせた色}"/>

三日月の向き調整:

• 欠ける円の位置をずらす方向で三日月の向きが変わる
• 上にずらす → 下弦の月（下が光る）
• 右にずらす → 左が光る三日月

最小限の太陽パターン

小さな白い円だけで太陽を表す。光線は16pxで潰れるので不要。

<!-- 太陽（左上配置の例） -->
<circle cx="42" cy="42" r="5" fill="#F0F0F2" opacity="0.92"/>

thinking-journey.md テンプレート

各ステップで思考の軌跡を記録するためのテンプレート。 ステップごとに必須ではないが、方向転換や収束が起きたステップでは推奨。

# Step {N} Thinking Journey

## 目標
- このステップで達成したかったこと

## 試した方向
- {方向1}
- {方向2}

## 捨てた方向とその理由
### {方向名}
- 捨てた理由

## 残すべき核
- {核となる要素}

## 収束した考え
- なぜこの形に落ち着いたか

## 次に詰めるなら
- {具体的な微調整ポイント}