Hallmarkデザインスキル実践ガイド：AI Slop UIを避け、ルールをセンスと混同しない

AIコーディングエージェントなら、ランディングページを短時間で作れます。困るのは、完成品がどれも同じマンションの住人のように見えがちなことです。中央揃えの大見出し、光るグラデーション、3枚の機能カード、仕上げのピル型ボタンが並びます。Hallmarkは、こうした定番から抜け出すための、インストール可能なデザインスキルです。ただし、先に明記しておきます。本記事のプロジェクトにはHallmarkを実際に導入しておらず、同じ要件を使ったA/Bテストも行っていません。ここで確認できるのは公式ルールと操作手順であり、「導入すればデザイナーのセンスが手に入る」という効果保証ではありません。

TL;DR

Hallmarkはデザインのガードレールであり、センスを提供するAPIではありません。よくある定番を制限できますが、製品の文脈、実際の内容、ブランド上の判断までは補えません。
参考素材がある新規ページでは、study → 要件を確定 → buildがおすすめです。既存ページではまずauditを行い、部分修正かredesignかを判断します。
公式READMEには現在、20種類のテーマと57個のslop-test gateが記載され、現行SKILL.mdには58個と書かれています。数はまだ変動しており、どちらのチェック項目を通過しても、使いやすさ、アクセシビリティ、中核タスクの通過を意味しません。

AI UIが「見た瞬間に生成物だと分かる」理由を先に診断する

問題は紫のグラデーションだけではありません。要件に「きれいなSaaSホームページを作って」としか書かず、対象ユーザー、実際の文言、ブランド上の制約、必要な状態を渡さなければ、エージェントは確率の高い組み合わせから無難な答えを選ぶしかありません。Anthropicのフロントエンド美学クックブックも、フォント、色、動き、背景を具体的に指定して出力を制約しています。

AI slop UIの実践的な診断方法：まず要件に欠けている製品情報を探し、次に画面上の視覚的な癖を確認します。グラデーションやカードグリッドだけを削除し、コンテンツの階層を補わなければ、多くの場合は一つのテンプレートを別のテンプレートに置き換えるだけです。

着手前に、この不足項目を埋めてください。

要件の項目	記入する内容	未記入の場合に起きること
対象ユーザー	誰が、どの状況で使うか	トーンと情報密度の焦点がぼやける
中核タスク	ユーザーがこのページで何を完了するか	ヒーロー画面がスローガンだけになる
実際の文言	見出し、機能、制限、エラーメッセージ	仮の文言でしか成立しないレイアウトになる
ブランド上の制約	フォント、色、禁止するスタイル	エージェントが汎用的な美意識に戻る
必要な状態	読み込み中、空、エラー、成功	きれいなスクリーンショットのまま公開できない
参考素材	2〜3個の方向性と、気に入った理由	曖昧な形容詞をまねるしかなくなる

Hallmarkとは何か、何を保証できないのか

Hallmarkはnutlope/hallmarkが公開するオープンソースのデザインスキルです。公式READMEでは、Claude Code、Cursor、Codex向けと位置づけられ、MIT Licenseを採用しています。build、audit、redesign、参考素材の分析を一つのルールセットにまとめています。

公式資料から確認できること	公開されている証拠では現時点で保証できないこと
4つの操作と配置先が示されている	完成品が従来の進め方より必ずプロらしくなる
テーマ、構造ルール、slop-test gateがある	ユーザーのタスク成功率が上がる
`study`はピクセル単位の複製と有料テンプレートを拒否する	すべてのエージェントが同じ方法で読み込み、実行する
`audit`は指摘一覧のみを返し、編集しない	コンバージョンや満足度が改善する

公式ホームページには、異なる要件から生成した複数の出力例があります。作者が構造の違いを目指していることは分かりますが、独立したユーザビリティ検証ではありません。Hallmarkはよくあるデザインの定番を減らせますが、製品の内容、デザインシステム、人による受け入れテストは自分たちで用意する必要があります。

安全にインストールし、小さな範囲で動作を確認する

2026年7月20日時点で、公式READMEに掲載されているインストールコマンドは次のとおりです。

npx skills add nutlope/hallmark

READMEには手動で配置する場所も記載されています。Claude Codeは~/.claude/skills/hallmark/、Cursorは.cursor/rules/hallmark.mdc、Codexは個人単位の~/.codex/skills/hallmark/またはプロジェクト単位の.codex/skills/hallmark/です。これは当時の公式説明であり、今後変わる可能性があります。実行前に元のリポジトリを確認してください。

最初から主要製品で試してはいけません。テスト用ブランチを作り、重要度の低いページを選び、画面とGitの基準状態を保存します。インストール後、「hallmark auditでこのページを監査し、ファイルは変更しないでください」のように明確なタスクを与えます。次に3点を確認します。返答が操作名を認識しているか、Hallmarkのルールを参照しているか、git diffが「auditは編集しない」という境界を守っているかです。

異なるエージェント、バージョン、プランで実際に表示される読み込みメッセージは検証していません。モデルの使用量や完了時間も推測しません。動作したという証拠は、インストール成功の表示ではなく、自分の環境で得た出力と差分から判断してください。

4つのモードの判断フロー：`build`、`audit`、`redesign`、`study`をどう選ぶか

まず3つ確認します。ページはすでに存在しますか。構造の変更を許容できますか。利用可能な参考素材はありますか。

状況	選択	変更範囲
新しいUIをゼロから作る	通常の`build`	構造とテーマを選び、新しいUIを生成する
既存ページの問題点だけを探す	`audit`	優先順位を付けた指摘一覧を返し、編集しない
既存の内容を保ち、視覚構造の変更を許容する	`redesign`	文言、情報アーキテクチャ、ブランドの意図を保つ
スクリーンショットまたはURLがある	`study`	構造、フォントの組み合わせ、基準色を抽出する

作業途中のUIでは、どれを選べばよいですか？ 何が問題かまだ分からなければ、まずauditを行います。指摘一覧の内容が余白、文字の階層、不完全な状態だけなら、部分的に修正します。構造のリズム自体が成立しておらず、大きな差分を受け入れられる場合に限ってredesignへ進みます。

たとえば、個人開発のランディングページにフォームとアクセス解析がすでに組み込まれている場合、いきなりredesignすると、動いている操作まで影響を受ける可能性があります。先にauditを行い、「文字の階層が不明瞭」と「情報アーキテクチャ全体を並べ替える必要がある」を分けるほうが、「全部高級にして」と頼むより安全です。

手戻りを抑えるSOP：`study`で方向性を固めてから`build`と`audit`へ進む

以下は、公式の操作と、参考素材を先に決める考え方をもとに本記事で整理した推奨手順です。Hallmark公式が削減効果を数値で約束しているわけではありません。

実際の内容を用意する：少なくとも実際の見出し、主なCTA、機能上の制限、エラーメッセージを入れます。
参考素材を選ぶ：気に入った点が情報密度、レイアウトのリズム、色のどれなのかを明記します。「この感じにして」だけでは不十分です。
studyを実行する：デザインの特徴を抽出します。ピクセル単位のコピーを避け、許諾のない素材も使いません。
要件を確定する：維持すべきルート、コンポーネント、文言の意図、ブランド、情報アーキテクチャを確認します。
buildを実行する：既知の境界内でエージェントにページを生成させ、ファイルごとに差分を確認します。
auditを実行する：結果を指摘一覧にまとめ、人が各修正を一つずつ承認します。

この順番の狙いは、「studyなら必ずトークンを節約できる」ということではありません。現時点では、それを裏づける公開比較データがないからです。実際に減らせるのは、判断の曖昧さです。家の用途と間取りを先に決め、その後で壁の仕上げを選べば、完成してからキッチンにドアがないと気づく事態を避けられます。

AI slop対策を新しいテンプレートにしない

共通の悪い癖を避けようとすると、別の共通パターンが生まれがちです。今日、全員が紫のグラデーションを避けても、明日には同じエディトリアル調の書体、大きすぎる見出し、ずらしたグリッドを使い始めるかもしれません。Hallmarkのテーマ一覧は出発点になりますが、あなたのブランドが存在する理由までは理解していません。

試行後に実際に役立った選択は、プロジェクト独自のDESIGN.mdに記録してください。

文字サイズの階層と許容するフォントウェイト
余白トークンとコンテンツの最大幅
基準色、コントラスト、禁止色
コンポーネントの管理責任と8つの操作状態
ブランド文言のトーン、実際のデータ長、禁止するパターン

Hallmarkはプロジェクト固有の設計ルールに従うべきで、上書きするものではありません。単発のキャンペーンページなら、外部のガードレールだけでも十分に役立ちます。数年間保守する製品では、独自のトークン、コンポーネント、状態を一貫して管理する必要があります。

Hallmark、Anthropicのプロンプト、taste-skill、独自のDESIGN.mdをどう選ぶか

方法	適した状況	主なトレードオフ
Hallmark	4つの操作で新規作成、`audit`、`redesign`、`study`を管理したい	ルールは包括的だが、既存ルールとの優先順位を整理する必要がある
Anthropicのクックブック	スキルをインストールせず、1回のプロンプトだけを改善したい	軽量だが、完全な監査手順ではない
taste-skill	ランディングページ、ポートフォリオ、`redesign`	公式の対象範囲ではダッシュボード、データテーブル、多段階UIを明示的に除外している
独自のDESIGN.md / デザインシステム	長期運用するブランド製品やチームでの共同作業	初期の整理には時間がかかるが、その後の一貫性を管理しやすい

これは品質ランキングではありません。同じ要件を使った独立したA/Bテストがないためです。今夜中に1ページのキャンペーンサイトを作るだけなら、クックブックかHallmarkを試せます。製品に完全なコンポーネントライブラリがすでにあるなら、まず独自ドキュメントを補い、Hallmarkは監査時の助言役として扱うのがよいでしょう。

57個でも58個でも、チェック項目の数は使いやすさを意味しない

公式READMEには現在57個のslop-test gateがあると書かれ、現行SKILL.mdには58個とあります。どちらの数字もHallmark独自ルールのカバー範囲を示すだけで、アクセシビリティ、コンバージョン、タスク完了率、満足度ではありません。きれいなヒーロー画面は評価材料として特に弱いものです。実際の製品で最も見栄えが悪くなりやすい場面を避けているからです。

テスト層	必ずテストする項目	合格基準
Hallmarkルール層	アンチパターン、トークン、構造、自己チェック	`audit`の指摘一覧を人が処理済み
コンテンツ状態	実際の文言、長い文字列、空、エラー、読み込み中	重要情報が切れず、状態を理解できる
ビューポート	320、375、414、768 pxとデスクトップ	横スクロールがなく、中核操作が見える
操作	キーボード、フォーカス、無効状態、動きを抑える設定	マウスなしでもフローを完了できる
ユーザータスク	実際の中核タスクを1つ完了する	成功でき、復旧でき、エラー時に次の手段がある

Hallmark自身のスキルは現在、複数の狭い画面幅で出力を検証するよう求めています。これは有用な最低ラインです。ただし、「コード上で検証済みと宣言されている」ことと、対象ブラウザで実際の内容を使って自分の目で確認したことは同じではありません。最後のクリックは人が行う必要があります。

高リスクな領域：Hallmarkに全面的に任せないほうがよいプロジェクト

以下はHallmark公式が全面的な対象外として挙げたものではなく、導入時に慎重になるための停止条件です。

成熟したデザインシステムと厳格なブランド規定がある
ダッシュボード、データテーブル、情報密度の高い管理画面
多段階の決済、申請、医療、金融フロー
法規、アクセシビリティ、監査要件が厳しい製品
ルート、コンポーネントの管理責任、データ状態を自由に変更できない

一つでも該当する場合はauditだけから始めます。視覚的な余白やトークンの提案なら、エージェントに小さな差分を作らせてもよいでしょう。情報の階層、項目の削除、エラーからの復旧、キーボードの順序、法規に関わる文言は、人が承認する必要があります。他ツールの制限をHallmark公式の制限として扱ってはいけません。たとえばtaste-skillは一部の複雑なUIを明示的に対象外としていますが、それはあくまでそのツールの対象範囲を示すものです。

1時間以内に試行を始められるが、時間枠を約束にしない

今日の試行に1時間を確保することはできます。ただし、それは投入時間を制御する時間枠であり、インストール、audit、修正がすべて完了する保証ではありません。元に戻せるページを選び、試行前のスクリーンショットとGitの基準状態を保存します。新規ページに参考素材があればstudy、既存ページならまずauditを使います。理解できる変更だけを少数採用し、2層の受け入れテストを実行してください。

最後に3列で記録します。採用した提案、却下した提案、DESIGN.mdに残すべきルールです。次回のエージェントはこの記録から、どの選択がその製品らしいのかを判断できます。

単発のランディングページを作っているなら、小さなブランチでHallmarkを試し、適切な操作を選んで素早く方向性を絞り込みます。成熟した製品を保守しているなら、デザインシステムを守り、auditの指摘一覧は外部意見としてのみ使います。ツールは今後も変わります。どのルールが製品に合い、どのルールが合わないのかを記録しておきましょう。