AIコーディングツールを使い始めてしばらく経つと、ある違和感に気づきます。
Claude CodeでもCursorでも、「UIを作って」と頼むと、なんとなく同じ顔のページが出てくる。
ヒーローセクションがあって、3つの特徴を並べて、CTAで締める。
フォントはInterで、グラデーションはpurpleからcyanへ。
これは気のせいではなく、構造的な問題です。
そしてlintを厳しくしても、コンポーネントライブラリを整備しても、この問題は解決しません。
原因と、それに対して hallmark がどんな設計判断を下しているかを読み解いていきます。
AIが「同じ顔」を生成する理由
LLMは、学習データの統計的な平均に収束する性質を持っています。
大量のWebページを学習したモデルは、「UIを作れ」と言われたとき、学習データの中で最も頻出したパターンを選びます。
明示的に禁じられていない限り、モデルは「最も無難な選択肢」を取り続けます。
その結果として現れるのが、purple-cyanのメッシュグラデーション、Interフォント、そしてhero→3-feature→CTAというリズムです。
これらは「AIスロップ」と呼ばれる現象の典型例で、個々の要素は間違っていないのに、組み合わさると量産品の匂いがする。
ここで「lintルールを厳しくすれば解決するのでは」と思うかもしれません。
でも、lintはコードの正しさを担保するもので、選択の多様性には干渉しません。
ESLintがどれだけ厳格でも、「Interを使うな」「グラデーションを禁止する」とは言ってくれない。
コンポーネントライブラリも同じで、使える部品を提供するだけで、どう組み合わせるかの判断はモデルに委ねられます。
問題の本質は、禁止されていないから平均を選ぶ、という構造にあります。
モデルに「個性を出せ」と頼んでも、その指示自体が曖昧なので、結局また平均的な「個性っぽい何か」が返ってきます。
解決策は、具体的な行動指示として制約を渡すことです。
hallmarkの設計思想と構造
hallmarkはUIライブラリでも、lintルールでも、コンポーネントシステムでもありません。
Together AIが開発したオープンソースのプロジェクトで、AIエージェントのコンテキストに乗せる 行動指示ファイル です。
リポジトリの構造はシンプルで、役割がはっきり分かれています。
- SKILL.md ：モデルへの行動規範。「何をしてはいけないか」「どう判断するか」を記述した制約の本体。
- references/ ：構造・タイポグラフィ・カラーなどの参照資料。SKILL.mdが参照する補足情報として機能する。
- slap test gates ：57項目の品質ゲート。生成したUIが「AIスロップ的な選択をしていないか」をモデル自身がセルフチェックするための基準。
- custom-theme.md ：既存の22テーマでは対応できないブリーフに対して、ゼロからパレット・タイポグラフィ・レイアウトを設計するフォールバックプロトコル。
hallmarkが自己説明に使っている言葉が面白くて、「opinionated, short, and boring on purpose」と書いてあります。
意図的に退屈に作ってある、という宣言です。
ルールは薄く鋭く、余計なことを言わない。
そして核心的な設計判断が、 structural variety（構造的多様性） の強制です。
視覚的な多様性——色やフォントを変えること——だけでは不十分で、ページの骨格レベルから別物にすることを目標にしています。
hallmarkで2つの異なるブリーフからページを作ると、同じテンプレートの色違いではなく、まったく別のサイトに見えるはずだ、というのがゴールです。
ルールを読み解く：distribution defaultsを拒否するとはどういうことか
SKILL.mdの冒頭近くに、こんな記述があります。
Hallmark is opinionated, short, and boring on purpose. It encodes a tight set of rules
— drawn from the consensus of the anti-AI-slop design field — and refuses to let the
model fall back to the defaults every LLM was trained on.
The differentiator: Hallmark insists on structural variety, not just visual variety.
Two pages by Hallmark for two different briefs should not share the same
hero → 3-feature → CTA → footer rhythm.
They should feel like different sites, not different colour-swaps of the same template.
「distribution defaults」という表現が鍵です。
モデルは訓練データの分布から、最も頻出した選択肢を「デフォルト」として身につけています。
hallmarkはそのデフォルトを明示的に拒否する、という立場を取っています。
これは単純な禁止リストとは少し違います。
「Interを使うな」という禁止だけでなく、「なぜその選択が量産品に見えるのか」という理由を含めて記述することで、モデルが類似の判断を自分でできるようになる設計です。
ルールの背後にある意図を伝えることで、列挙されていないケースにも対応できる。
たとえばグラデーションに関しては、purple-cyanのメッシュグラデーションが「AIスタートアップ美学」の象徴として明示的にフラグが立てられています。
タイポグラフィについても、Interをデフォルトで選ぶことへの禁止が入っています。
そして構造については、hero→3-feature→CTAというリズムを繰り返さないことが、ルールの中心に据えられています。
slap testという名前も面白くて、「これを見た人が思わず画面を叩きたくなるか」という感覚的な品質基準を57項目に落とし込んでいます。
生成後にモデル自身がこのゲートを通過するかセルフチェックを走らせる、という設計です。
プロジェクトへの組み込みと自前ルールの育て方
インストール自体は一行です。
npx skills add nutlope/hallmark
これを実行すると、使っているエージェントに応じて適切な場所にファイルが配置されます。
# Claude Code
~/.claude/skills/hallmark/
├── SKILL.md
└── references/
# Cursor
.cursor/rules/hallmark.mdc
（SKILL.mdの本文のみ。フロントマターは含めない）
# Codex（個人スコープ）
~/.codex/skills/hallmark/
# Codex（プロジェクトスコープ）
.codex/skills/hallmark/
ただし、「全部入れる」ことが目的ではありません。
hallmarkのルールはWebサイト・ランディングページを念頭に設計されています。
SaaSのダッシュボードや業務システムのUIに全ルールをそのまま適用すると、ミスマッチが起きる場面もあります。
自プロジェクトへの取り込みで先にやるべきことは、 自分のプロジェクトで何がデフォルト化しているかを特定する ことです。
「うちのAI生成UIはいつもどんな顔をしているか」を言語化してから、hallmarkのどのルールが刺さるかを選ぶ順序が正しい。
CLAUDE.mdへの部分取り込みはこんな形になります。
## UI生成の制約
以下はAIスロップを防ぐための行動指示です。
hallmark（Nutlope/hallmark）のSKILL.mdから抜粋・カスタマイズしています。
### 構造の多様性
- hero → 3-feature → CTA → footer のリズムを繰り返さない
- 同じプロンプトで複数ページを作る場合、骨格レベルで別物にする
### 禁止するデフォルト選択
- purple-cyan のメッシュグラデーションは使わない
- フォントのデフォルトとしてInterを選ばない
- floating 3D shapes や glassmorphism を安易に使わない
### セルフチェック
生成後、以下を自問すること：
- このレイアウトは他のAI生成ページと同じ骨格を持っていないか
- デフォルトの選択肢を選んだ理由を説明できるか
hallmarkのルールをそのままコピーするのではなく、自プロジェクトの文脈に合わせて言葉を選び直すことが大事です。
モデルはコンテキストを読むので、プロジェクト固有の言葉で書いたルールの方が、汎用的なルールより精度が上がります。
そしてルールは、最初から完璧にしようとしないことが大事です。
hallmarkが「opinionated, short, and boring on purpose」と自己説明しているのは、ルールを薄く鋭く保つことへの意志表明でもあります。
長大なルールファイルを作ろうとすると、モデルが重要な制約を見落とすリスクが上がります。
書けば書くほど良いわけではなく、核心的な制約を短く鋭く書く方が効く。
「禁止リスト」を並べるより、「なぜそれを避けるのか」という理由を一緒に書いた方が、モデルへの伝達精度が上がります。
「Interを使うな」とだけ書くより、「Interはデフォルトで最も選ばれるフォントであり、それを選ぶことは量産品の匂いを強める」と書く方が、モデルは類似の判断を自分でできるようになります。
理由を渡すことで、列挙されていないケースへの汎化が起きる。
実際に生成物を見て、「またこのパターンが出た」と気づいたときにルールを追記する。
そのサイクルを回すことで、ルールファイルは自プロジェクトの個性を言語化したドキュメントになっていきます。
「自社の個性を言語化する」というのは、ポジティブな定義（こういうUIにしたい）だけでなく、ネガティブな定義（これだけは避けたい）の積み重ねでもあります。
hallmarkが「distribution defaultsを拒否する」という形で設計されているのは、そのネガティブな定義の方が、モデルへの制約として機能しやすいからです。
hallmarkのリポジトリはMITライセンスで公開されており、SKILL.mdをそのまま使うことも、フォークして自社向けにカスタマイズすることも自由です。
まずは Nutlope/hallmark のSKILL.mdを読んで、自分のプロジェクトに刺さるルールを3つ選ぶところから始めてみてください。
株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援を手がけています。
AIコーディングツールの導入や制約ファイルの設計など、実務レベルの相談にも対応しています。
ご興味があれば お問い合わせページ からどうぞ。