カナリーがCocodaで公開したUI生成の事例は、AIにブランドの見た目を守らせた、その先の話です。Claude Codeを使い、要件からUIを生成するフローはすでに運用できている。それでも、仕様を満たすだけの似た画面が並んでしまう。そこで加えたのが、デザイナーの思考方法を記した「デザイナー人格」のSkillsでした。
面白いのは、装飾を増やすのではなく、案を考える順番を変えていることです。
デザインシステムで整える前に、別の案を出す
もともとのフローは、PRD（プロダクト要求仕様書）から情報設計を行い、デザインシステムを通してUIへまとめる形でした。デザイン哲学やガイドラインを読ませればカナリーらしい見た目にはなるものの、使い心地への一工夫が足りなかったといいます。
記事の例は退会手続きです。確認モーダルとして成立していても、退会によって失うものや、手続き後の見通しまで伝わるとは限りません。「機能として正しい」と「不安なく使える」の間に、まだ設計の余地があります。
変更後は、情報設計の次にデザイナー人格を使った発散を挟みます。複数の案を出してからデザインシステムに照らして調整し、突飛すぎる案を除く。通常の案と、一工夫を加えた案を比較できる形で出力します。統一感を捨てるのではなく、統一する前に選択肢を広げる順番です。
「人格」の中身は、思考の手順
この人格は、単に「優秀なデザイナーとして振る舞って」と頼むものではありません。カナリーではリードデザイナーに過去のUIをどう考えて作ったかを聞き、思考方法を言語化したうえで、LLMがたどれる具体的なプロンプトへ落とし込んでいます。
例えば「Detour」は、要件や仕様をいったん考慮から外して発想し、得られたアイデアを元の設計へ持ち帰る方法です。最終成果物まで要件を無視してよい、という意味ではありません。
もう一つの「Persona」は、利用者の視点を変える方法。複数のペルソナの文脈を用意し、それぞれのエージェントを並列に動かして、その人にとって何が大事かを再評価し、UI構造を組み直します。遠回りして考えることと、利用者を変えて考えることでは、同じ画面でも探る方向が違います。
Claude Codeの公式ドキュメントでは、Skillsは指示を記したSKILL.mdとして定義されます。プロジェクト内の.claude/skills/<skill-name>/SKILL.mdに置けば、リポジトリでチームに共有する形も取れます。ただし、これは公式仕様の補足であり、カナリーの実際の配置構成を示すものではありません。
Anthropicの公開frontend-design Skillにも、定型的な見た目を避け、設計案を依頼内容に照らして見直す手順があります。カナリーの事例で注目したいのは、そこからさらに、自社のデザイナーが案を広げる考え方を言葉にしている点です。
案を増やすことと、採用を決めることは分ける
記事では、人格を介した生成例として、退会時の注意点や、その後のデータ削除予定まで含む画面を紹介しています。一工夫のある案が出やすくなったという報告ですが、ユーザーにとって最適な案を選ぶところには人の目を残しています。生成例の改善を、そのまま利用者への効果が実証された話として読むべきではありません。
自分のチームで試すなら、まず一つの画面について「なぜこの説明を足したのか」「別の案をどこで捨てたのか」を聞き取るところから始めたい。人格の名前を増やすより、判断の手順を残す。その手順で案の違いが生まれるかを比べれば、Skillsに何を任せ、人が何を確かめるかも見えやすくなります。