デザイナーが不在の組織で、バナーデザインを生成する仕組み

banner-design-harness という仕組みを作りました。

Notion AI で要件定義するだけ。誰でも作れて、崩れず、全部残る。台帳に1行できると、その10秒後にバナーが生成され、Slack に投稿され、記録が同じ行に戻る仕組みです。

Claude Code / GitHub / Figma などのツールを何も触らずにクリエイティブが生成できるデザインハーネスです。

banner-design-harness/
├── CLAUDE.md                     AI の入口。読み順と、守るべき15のルール
├── README.md                     人の入口。何が動いて何が動かないか
├── config.json                   接続先（Notion 台帳の ID など）。トークンは書かない
├── requirements.txt              依存は Pillow のみ
├── slack-app-manifest.yml        Slack アプリの定義
├── .env / .env.example           手元の秘密。読み込み口は src/net.py の load_env() だけ
├── .gitignore
│
├── context/                      なぜこの形なのか（人が読む層）
│   ├── 01-design.md              設計の根拠。実装を書く前に読む
│   ├── 02-open-points.md         決まったこと／決まっていないこと
│   └── 03-status.md              いまここ。セッションをまたぐ入口
│
├── docs/
│   ├── banner-harness.html       設計図（構成図つき1枚）。まずこれを見る
│   └── reference/
│       └── figma-standard-1920.png   Figma 標準デザインの実測元
│
├── templates/                    ★ L1：決定的テンプレート
│
├── tokens/
│   ├── banner-tokens.json        バナー固有の幾何とタイポ。色は持たない
│   └── upstream-mirror.json      上流の色を丸ごと写した一方向のミラー
│
├── assets/                       ★ L3：承認済みアセット。AI は選ぶだけ
│   ├── manifest.json             選定の定義（when / avoid / keywords）
│   ├── brand/
│   ├── illustrations/
│   ├── backgrounds/
│   └── fonts/                    
│
├── data/
│   ├── campaigns/                L2 の入力。本番では Notion の1行にあたる
│   └── wordbreak-katakana.json   
│
├── prompts/
│   ├── notion-ai-hearing-skill.md    ★ 前段のヒアリング Skill 原稿
│   └── l2-copywriter.md              L2（予備）の文体と制約。版を台帳に記録
│
├── src/
│   ├── render.py                 L1 レンダリング＋記録の書き出し
│   ├── inpage-checks.js          ページ内の実測。測るだけで判定しない
│   ├── check.py                  決定的チェック18種。判定するが止めない
│   ├── sync.py                   台帳→L2→台帳→生成→台帳→Slack。本体の経路
│   ├── agent.py                  ★ L2：概要だけの行を救う予備。主経路ではない
│   ├── dates.py                  日時表記を開催日から組み立てる
│   ├── tokens.py                 色の正を読む唯一の口。上流が無ければ止まる
│   ├── mirror_tokens.py          上流 → upstream-mirror.json を書き出す
│   ├── figma.py                  Figma から実測値を読む（設計を測り直すときだけ）
│   ├── net.py                    外部との口。load_env() はここ1つ
│   ├── notion.py / slack.py      台帳と掲載先
│   ├── doctor.py                 別のマシンで動くかを先に確かめる
│   ├── verify_connections.py     トークンが通るかを確かめる（値は表示しない）
│   ├── diff_render.py            2つの環境の実測ジオメトリを突き合わせる
│   └── fetch_fonts.py            書体の同梱を作り直す
│
├── ops/
│   ├── schedule.sh               手元の定期実行
│   ├── linux-check/              環境の照合。Linux と突き合わせる
│   │   ├── Dockerfile
│   │   ├── entrypoint.sh
│   │   └── run.sh
│   └── notion-relay/             ★ 受け口。Notion → GitHub の形を作り直す15行
│       ├── worker.js
│       └── README.md
│
├── .github/workflows/
│   ├── render-check.yml          照合用
│   └── sync.yml                  本番
│
└── out/                          
    └── CMP-XXXX/  →  banner.png / record.json / checks.json

ブランド毀損ゼロのクリエイティブを、納期0日で提供する

最初に置いた条件は、品質・権利関係・色やロゴの崩れなどの発生を「ゼロ」にすることです。

社員数の多い組織で、全クリエイティブをレビューすることはそもそも不可能です。なぜなら、バナーなどは誰でも自分で作ってリリースできてしまう構造があるから。

そして、我々が長く悩みを抱えているのが「納期」です。納期が迫ってきている案件では、デザイナーが提示するリードタイムが採用されることはありません。常に、納期の決定権は"依頼者側"にあるのです。

ではどうするか。「ブランド毀損ゼロのクリエイティブを、納期0日で提供する」これを実現する仕組みを作りたいと考えました（現在も挑戦中です）。

"標準化への入り口"をディレクションする

仕組みを考えるにあたって世の中の動向を調べました。共通するのは、テンプレートを決定的にレンダリングし、AIが担うのは「流し込むパラメータ」と「素材の選択」だけ、という分業です。

よって、層を3つに分解しました。

🖼️ L1 テンプレート
→ デザイナーが作る層。AIに触らせない。16:9 / セーフエリア / ロゴ位置 / タイポスケール / 余白
🖼️ L2 パラメータ
→ AIが担う層。ただし出力は JSON であって、画像ではない
🖼️ L3 素材
→ 承認済みのアセットから選ぶだけの層。生成しない

「なんでも生成できる」というAIの魅力は、裏を返せば「なんでも生成できてしまう」ということ。組織にとって大きなリスクです。

表現の自由度は、民主化の壁となる側面があります。狭く切るほど、誰でも使えるようになる。デザイナーの役割は、この"標準化への入り口"をディレクションすることです。

生成物を決定的にすると、グラフィックにもlinterが書ける

コードの linter が成立するのは、対象が決定的だからです。ならば、生成物の側を決定的にしてしまえばいい。これが設計の軸です。

L1 が決定的である限りレイアウトは崩れようがないため、チェックすべき対象が「崩れたかどうか」から「値が正しいかどうか」に変わります。

L1 は HTML + CSS を headless Chrome でレンダリングする形にしました。レンダリング後の実測ジオメトリが取れるからです。文字のはみ出しやセーフエリアへの侵入を、推定ではなく実測で判定できます。

現時点で決定的に判定しているのは18種類。コントラスト比、ロゴ周囲の余白、指定外カラー、書体、はみ出し、最小フォントサイズ、そして台帳の入力とバナー上の文言の一致。

ひとつ徹底したのは、計測と判定を混ぜないことです。ページ内で測るスクリプトは測るだけで合否を持たず、判定は別のコードが持ちます。混ぜると、判定基準を変えたいときにテンプレート本体まで触ることになり、「テンプレは決定的」という前提のほうが崩れます。

崩れないのは、チェッカーが弾いているからではありません。L1 が決定的だからです。チェッカーは、値が正しいかどうかの所見を返す役に徹しています。

原稿を確定させる工程を、生成の外に置く

何のための施策で・誰に・何をしてほしいクリエイティブなのか。私が最も重視しているのが"要件定義"です。

この工程を仕組みの外に出しました。原稿は Notion AI のヒアリング Skill で人が確定させる。台帳に入った文言は、以降の工程で一言一句変えない。「台帳に行があること＝人が原稿を確定したこと」という意味を持たせました。

作るのはヒアリング、写すのが仕組み側。これは他の仕組みを作るときも同じ。いかなるクリエイティブも、精度を決めているのは生成エンジンではなく"要件定義の工程"です。AIに何を書かせるかより、人が何を決めたかのほうが先にあります。

和文の改行位置を、機械に決めさせる

改行位置はクリエイティブの品質を決める重要要素のひとつです。「デザイン推進メン／バー募集」のような改行は避けなければいけません。

そこで、自動改行を止めたうえで、自然な切れ目にだけ「ここで折ってよい」と教える仕組みにしました。判定は3段階で足していった。

✂️ 助詞と句読点
→ 最初の版。ただし助詞が1つも無いタイトルは、折る場所がゼロになる
✂️ 文字種の変わり目
→ 日本語では意味の切れ目でもある。ただし3つ外した（数字が絡む境目は採らない / 両側が2文字以上のときだけ採る / 英字とカタカナの境目は採らない）
✂️ カタカナ語の定義
→ たとえば "コミュニケーションデザイン" は語を知らないと当てられず、位置を機械的に決めると語の途中で割れる

そして、人が「｜」を入れた位置だけで折れるようにしました。1つでも入っていたら、機械の判定は一切使いません。人の意思のほうが常に強いという順序です。

生成も登録も自動化する"ボタンを作らない"設計

生成の条件は1つ「台帳の asset_id が空であること」。クリックする手間を作らない設計です。

修正する場合は、内容を訂正して asset_id を消す。それが引き金になって次の版が出ます。「再生成ボタン」は用意していません。asset_id が空なら、まだ生成されていない行です。

記録も同じ考え方。誰が、いつ、何を入力して、どのテンプレ版で作ったのか。生成物を自動記録していくことは、最初から重要視していた観点です。

1,600名規模の組織で「生成したら登録してください」というルールは守られない。よって、登録工程の自動化は必須です。

10秒で生成される起動設計

当初の起動設計は、10分ごとに台帳を見に行き、asset_id が空の行を見つけたら生成（待ち時間最大10分）というもの。私は、残っていた工程の「台帳を見に行く役割」を自分の PC から外す作業を進めていました。

そのとき、定期実行が成功していなかったことが発覚しました。すぐに改善策を考え、台帳に行ができた瞬間と、asset_id が消された瞬間に、Notion のほうから知らせてもらう形に変えました。実装は、受け口として Cloudflare を間に置きました（Cloudflare Workers によって、常時動かすサーバーを持たずに済む）。

結果、待ち時間は体感10秒程に。引き金は2つとも「状態」のままで、ボタンは最後まで1つも作りませんでした。

デザインハーネスの設計は、デザイナーにしかできない

この仕組みは「デザイナーがいなくても作れる」「デザインツールを開かずに作れる」を目的にしたものです。もし、デザイナーが手を動かせるのであれば、Figmaで作れば済む話です。

私は、全てのクリエイティブが自動化できるとは思っていません。狙っているのは、デザイナーが作らなくても、施策の目的が達成可能なクリエイティブの自動化です。これは「品質が高いことが全ての目的で求められるのか」という自分への問いに対する、実験記録です。

もうひとつ、最近意識していることは「レビューを前提にしないこと」。デザイナーは、他職種が作ったものをレビューしようとします。それ自体は絶対に正しい。ただ私は、その前提を一旦疑いたい。大規模組織で全てを確認することは不可能。だとすると、レビューで担保するのではなく、リスクを構造的にゼロにする解を探りたいのです。

「レビューしなければならない」と考えるとき、自分の仕事を増やそうとしている自分がいます。しかし組織においては「いかに自分を不要にできるか」がミッションです。

そのうえで、デザインを生成する仕組みの、どこに制約を持たせ、どこを許容するかを決める設計は、デザイナーにしかできないでしょう。