Brew がブランドの情報を、硬直したオブジェクトから、正確な値だけでなくデザインの意図まで説明できる編集可能なドキュメントに移した理由を紹介します。
16進数のカラーコードは、メールエージェントにどの青を使うべきかを教えてくれます。しかし、なぜそのブランドがすべての見出しの上に小さな等幅フォントのラベルを置くのか、なぜ区切りにボックスではなく細い線を使うのかまでは教えてくれません。
それが、Brew の最初のブランドモデルの問題でした。たくさんの値を取り込んでいたのに、ブランドをそのブランドらしく見せている細部は失われていたのです。
最初、ブランドは構造化データのように見えていました。私たちは、色、タイポグラフィ、アセット、そして膨大なスタイルのプロパティをモデル化しました。クローラーがフィールドを埋め、生成処理がそれらを組み合わせて、メールエージェントに渡すコンテキストにしていました。
その結果、色もフォントも正しいのに、ありきたりに見えるメールができることがありました。新しいブランドを扱うたびに、スキーマが想定していなかった細部が出てきます。フィールドを追加し続けることもできましたが、より有益な問いは、デザイナーなら同じブランドをほかの人にどう説明するか、でした。
デザイナーなら、ガイドを書くでしょう。重要なところには正確な値を、役に立つところには例を示し、その間にある判断を文章で説明するはずです。
そこで私たちは、抽出エージェントに作らせるものを変えました。
私たちはこれを email-design.md と呼んでいます。特定のブランドがメールの中でどう見えるべきかを記述した、編集可能なMarkdownドキュメントです。
以下は、架空の例を短くしたものです。
# Acme email design
## Voice
Write for engineers who want the setup instructions first.
Use short explanations and name the product action precisely.
## Signature details
- Put a small monospace label above the main headline.
- Use thin dividers between sections, without drop shadows.
- Reserve the accent color for the primary action.
- Use one product screenshot when it explains the task.
## Assets
Use the approved logo URL from the asset list.
Do not invent product images or customer logos.このドキュメントには、正確なカラー値の横に、「アクセントカラーは1通につき1か所だけに使う」といったルールも書けます。こうしたルールは、私たちが個別には想定していなかったケースでも、エージェントが従える指示になります。
ブランドの指示は目に見える形で示されます。修正は、次のブリーフの一部になります。
ここでMarkdownが役立つのは、専用のフォームがなくても人が読んで編集できるからです。見出しがドキュメントに構造を与え、新しいデザインのルールを追加するのに、データベースのフィールドを新しく作る必要もありません。これは実用面から選んだ形式です。MarkdownのほうがJSONより常にトークン数が少ないとか、どのモデルも主にMarkdownで学習されている、と主張しているわけではありません。
ウェブサイトとメールでは、レンダリングの制約が異なります。フォント、レイアウト、ダークモードへの対応は、メールクライアントによってまちまちです。ブラウザーのプレビューで正しく見えるデザインでも、受信トレイでのテストは必要です。
そのためブランドドキュメントには、メールに特化したガイダンスを入れています。代替フォント、コンテナの幅、テーブルで組みやすいレイアウトのレシピ、明るい背景と暗い背景それぞれでの選択などです。こうした指示は、エージェントが適切な判断を下す助けになりますが、どのクライアントでもまったく同じように表示されることを保証するものではありません。
画像には別の要件があるため、Brew は画像のガイダンス用に image-style.md も使っています。2つの関心事をはっきり分けておくほうが、デザイントークンの一覧ひとつで、あらゆる媒体を表現しようとするより簡単です。
公開中のウェブサイトは有用な手がかりですが、常に正解とは限りません。古いキャンペーンや、ブランドチームがもう使っていないスタイルの実験が残っていることもあります。
Brew は、ドメインに加えて、提供されたブランドガイド、ロゴ、画像などの参考資料も使えます。両者が食い違う場合は、ウェブサイトから推測した内容より、アップロードされたブランドのガイダンスが優先されます。出来上がったドキュメントは確認しましょう。元の資料が不完全だったり、一貫していなかったりする部分は特に注意が必要です。
ドメインと承認済みのファイルは、抽出処理にそれぞれ異なる種類の手がかりを与えます。
ボタンの形が違っていたら、指示を変えます。語り口が堅すぎたら、あいまいな形容詞を例文に置き換えます。こうした修正は、誰も編集したがらないフィールドだらけの巨大なオブジェクトよりも、ずっと話し合いやすいものです。
このドキュメントは、承認済みのアセットの場所、製品名、デザイン上の判断を、生成時のコンテキストに直接入れます。そのぶん、モデルが推測で埋めなければならない空白は減ります。ただし、誤った出力がなくなるわけではありません。
この取り組みの間に、私たちはメールエージェントのほかの部分も変更しました。条件をそろえた比較をしていない以上、全体的な品質の向上をファイル形式だけの成果だと言うつもりはありません。私が言えるのは、もっと控えめなことです。ブランドのブリーフが、確認しやすく、修正しやすく、再利用しやすくなった、ということです。
生成されたメールには、引き続き事実と見た目の両面からのレビューが必要です。主張をブリーフと照らし合わせ、リンクをテストし、受信トレイでの表示を確認しましょう。この引き継ぎについては、メールエージェントへのブリーフの書き方で説明しています。
Brew のMCPサーバーが利用できるようになりました。対応するアシスタントは、ドキュメントに記載されたツールを通じて、アプリと同じブランドの情報を使いながら Brew を操作できます。接続方法は、MCPの発表記事とセットアップのドキュメントで説明しています。
ブランドの指示に、はっきりとした置き場所ができたことを、私は気に入っています。メールに違和感があれば、該当する一文を指し示し、書き換えて、もう一度試せます。モデルに「もっとブランドらしくして」とまた頼むより、ずっと有益なやり取りです。
