Hallmarkは無料ですか。ライセンスと更新方法はどうなっていますか？

Hallmarkの公式GitHub repositoryは、現在MIT Licenseで公開されています。READMEにはnpxによるインストールコマンドがあり、再実行すれば更新できると説明されています。ただし更新前にはrepositoryとファイルの差分を確認し、新しいルールがプロジェクト既存の制約を上書きしないか確かめるべきです。

heroのスクリーンショットだけでなく、Hallmarkの結果をどう評価すればよいですか？

まずHallmark独自のルールを通過しているか確認し、次に実際の文言、長い文字列、empty、error、loadingの各状態でテストします。そのうえで狭い画面、キーボード操作、コントラスト、reduced motionを確認し、製品の中核タスクを自分で一度完了してください。

Hallmarkのstudyで、気に入ったWebサイトをコピーできますか？

ピクセル単位のコピーには使うべきではありません。公式skillはstudyをmacrostructure、フォントの組み合わせ、color anchorの抽出手段と位置づけ、pixel cloneと有料テンプレートを明確に拒否しています。素材のライセンスとブランドとして十分な違いを確保する責任は、引き続き利用者にあります。

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

AI coding agentならlanding pageを短時間で作れます。困るのは、完成品がどれも同じマンションの住人のように見えがちなことです。中央揃えの大見出し、光るgradient、3枚の機能card、仕上げにpill型buttonが並びます。Hallmarkは、インストール可能なdesign skillで、こうした定番から抜け出そうとするものです。ただし、先に明記しておきます。本記事のプロジェクトにはHallmarkを実際に導入しておらず、同一briefによるA/B testも行っていません。ここで確認できるのは公式ルールと操作手順であり、「導入すればデザイナーのセンスが手に入る」という効果保証ではありません。

TL;DR

Hallmarkはデザインのガードレールであり、センスを提供するAPIではありません。よくある定番を制限できますが、製品の文脈、実際の内容、ブランド上の判断までは補えません。
参考素材がある新規ページでは、study → briefを確定 → buildがおすすめです。既存ページではまずauditを行い、部分修正かredesignかを判断します。
公式資料には現在、21個のnamed themesと57個のslop-test gatesが記載されています。ただしgateの通過は、使いやすさ、アクセシビリティ、中核タスクの通過を意味しません。

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

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

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

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

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

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

Hallmarkとは何ですか？ Hallmarkはnutlope/hallmarkが公開するopen-sourceのdesign skillです。公式READMEでは、Claude Code、Cursor、Codex向けと位置づけられ、MIT Licenseを採用しています。build、audit、redesign、参考素材の分析を一つのルールセットにまとめています。

公式資料から確認できること	公開されている証拠では現時点で保証できないこと
4つの操作とインストール先が存在する	完成品が従来の進め方より必ずプロらしくなる
themes、構造ルール、slop gatesがある	ユーザーのタスク成功率が上がる
studyはpixel cloneと有料テンプレートを拒否する	すべてのagentが同じ方法で読み込み、実行する
auditはpunch listのみを返し、編集しない	conversionや満足度が改善する

公式ホームページには、異なるbriefから生成した複数の出力例があります。作者が構造の違いを目指していることは分かりますが、独立したusability benchmarkではありません。妥当な期待値は、Hallmarkがスタート地点を引き上げてくれることです。最後の仕上げは、製品の内容、design system、人による受け入れテストが担います。

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

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/です。これは当時の公式説明であり、今後変わる可能性があります。実行前に元のrepositoryを確認してください。

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

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

4つのモードのdecision tree：build、audit、redesign、studyをどう選ぶか

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

状況	選択	変更範囲
新しいUIをゼロから作る	default build	構造とthemeを選び、新しいUIを生成する
既存ページの問題点だけを探す	`audit`	優先順位を付けたpunch listを返し、編集しない
既存の内容を保ち、視覚構造の変更を許容する	`redesign`	copy、情報アーキテクチャ、ブランドの意図を保つ
screenshotまたはURLがある	`study`	構造、フォントの組み合わせ、color anchorを抽出する

作業途中のUIでは、どれを選べばよいですか？ 何が問題かまだ分からなければ、まずauditを行います。punch listの内容がspacing、type hierarchy、不完全なstatesだけなら、部分的に修正します。構造のリズム自体が成立しておらず、大きなdiffを受け入れられる場合に限ってredesignへ進みます。

たとえば、side-projectのlanding pageにフォームとanalyticsがすでに組み込まれている場合、いきなりredesignすると、動いているinteractionまで影響を受ける可能性があります。先にauditを行い、「文字の階層が不明瞭」と「情報アーキテクチャ全体を並べ替える必要がある」を分けるほうが、「全部高級にして」と頼むより安全です。

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

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

実際の内容を用意する：少なくとも実際の見出し、主なCTA、機能上の制限、エラーメッセージを入れます。
参考素材を選ぶ：気に入った点が情報密度、レイアウトのリズム、色のどれなのかを明記します。「この感じにして」だけでは不十分です。
studyを実行する：デザインのDNAを抽出します。ピクセル単位のコピーを避け、許諾のない素材も使いません。
briefを確定する：維持すべきroutes、components、copy intent、brand、information architectureを確認します。
buildを実行する：既知の境界内でagentにページを生成させ、ファイルごとにdiffを確認します。
auditを実行する：結果をpunch listにまとめ、人が各修正を一つずつ承認します。

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

anti-slopを新しいテンプレートにしない

共通の悪い癖を避けようとすると、別の共通パターンが生まれがちです。今日、全員が紫のgradientを避けても、明日には同じeditorial type、oversized heading、ずらしたgridを使い始めるかもしれません。Hallmarkのtheme catalogは出発点になりますが、あなたのブランドが存在する理由までは理解していません。

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

type scaleと許容するfont weight
spacing tokensとコンテンツの最大幅
color anchors、コントラスト、禁止色
component ownershipと8つのinteraction states
ブランド文言のトーン、実際のデータ長、禁止するpattern

Hallmarkはこのプロジェクト言語に従うべきで、上書きするものではありません。単発のキャンペーンページなら、外部のガードレールだけでも十分に役立ちます。数年間保守する製品では、独自のtokens、components、statesこそが積み上げられる資産です。

Hallmark、Anthropic prompt、taste-skill、独自のDESIGN.mdをどう選ぶか

方法	適した状況	主なトレードオフ
Hallmark	4つのverbsで新規作成、audit、redesign、studyを管理したい	ルールは包括的だが、既存ルールとの優先順位を整理する必要がある
Anthropic cookbook	skillをインストールせず、1回のpromptだけを改善したい	軽量だが、完全なaudit workflowではない
taste-skill	landing page、portfolio、redesign	公式scopeではdashboard、data table、多段階UIを明示的に対象外としている
独自のDESIGN.md / design system	長期運用するブランド製品やチームでの共同作業	初期の整理には時間がかかるが、その後の一貫性を管理しやすい

これは品質ランキングではありません。同一briefによる独立したA/B testがないためです。今夜中に1ページのキャンペーンサイトを作るだけなら、cookbookかHallmarkを試せます。製品に完全なcomponent libraryがすでにあるなら、まず独自ドキュメントを補い、Hallmarkはauditの助言者として扱うのがよいでしょう。

57 gatesは使いやすさを意味しない：2層の受け入れテストを作る

公式READMEには現在、57個のslop-test gatesがあると書かれています。この数字が示すのはHallmark独自ルールのカバー範囲であり、accessibility、conversion、task completion、満足度ではありません。きれいなheroは評価材料として特に弱いものです。実際の製品で最も見栄えが悪くなりやすい場面を避けているからです。

テスト層	必ずテストする項目	合格基準
Hallmarkルール層	anti-pattern、tokens、構造、self-check	auditのpunch listを人が処理済み
コンテンツ状態	実際のcopy、長い文字列、empty、error、loading	重要情報が切れず、状態を理解できる
Viewport	320、375、414、768 pxとdesktop	横スクロールがなく、中核操作が見える
Interaction	keyboard、focus、disabled、reduced motion	マウスなしでもフローを完了できる
ユーザータスク	実際の中核タスクを1つ完了する	成功でき、復旧でき、エラー時に次の手段がある

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

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

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

成熟したdesign systemと厳格なブランド規定がある
dashboard、data table、情報密度の高い管理画面
多段階の決済、申請、医療、金融フロー
法規、アクセシビリティ、監査要件が厳しい製品
routes、component ownership、データ状態を自由に変更できない

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

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

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

最後に3列で記録します。採用した提案、却下した提案、DESIGN.mdに残すべきルールです。この記録は「デザインされた感じが増した」という感想より役立ちます。次回のagentが、どの選択がその製品らしいのかを理解できるからです。

単発のlanding pageを作っているなら、小さなbranchでHallmarkを試し、適切なverbを選んで素早く方向性を絞り込みます。成熟した製品を保守しているなら、design systemを守り、auditのpunch listは外部意見としてのみ使います。ツールは今後も変わりますが、どのルールを拒否すべきか判断できるようになったとき、自分のセンスが形になり始めます。