Toothpick: AIの味を取り除き、長持ちするインターフェースを届ける

このガイドについて

ここには「常にこのフォントを使え」「その色は絶対に使うな」といったルールはありません。どんな色、書体、レイアウトも使用できます。

このガイドが行うことは2つです：

AIの味を認識できるようにする：どの選択がAIの無意識のデフォルトであり、なぜ人々がそれを即座に見抜くのか。
よくある欠陥を回避できるようにする：インターフェースを粗雑で安っぽく、プロフェッショナルでなく見せる間違い。

テストはただ一つ：この選択はこのプロダクトのために行われたのか、それともどんなプロダクトでも行っただろうか？ 後者がAIの味です。

ユーザーの明示的なスタイル、ブランドガイドライン、既存のコードスタイルは常に優先されます。たとえユーザーが求めるものが以下に挙げる「AIの味」の一つであっても同様です。

AIの味とは何か

すべてのデザイン決定において、AIは最も一般的なオプションに引き寄せられます。これには2つの層があります。

第一層、古い決まり文句：紫から青へのグラデーション、絵文字をアイコンとして使用、同一の角丸カードとグレーの影、「中央揃えの見出し＋3つのフィーチャーカード」のランディングページ、「無限の可能性を解き放て」のようなコピー。多くの人がすでにこれらを認識しています。

第二層、センスがあるふりをする：「AIが生成したように見せないで」と言われると、AIは別の、同様に固定された装いに切り替わります：

クリーム色の紙の背景、大きなセリフ見出し、テラコッタまたは深紅のアクセント、「温かみとセンスがある」風
ほぼ黒の背景、一つのネオングリーン、アンバー、またはバーミリオンのアクセント、すべてにモノスペース、「ハッカー」風
新聞のような黒の細線、ゼロのボーダー半径、密集したカラム、「スイス風でプロフェッショナル」風
すべての見出しの上に大文字のラベル、「A · B · C」のような中点で区切られた文字列、すべてのリンクの後に「→」、すべての小さなデータラベルにモノスペース、シーケンスではないコンテンツに「01 / 02 / 03」
巨大な装飾数字、自己目的の非対称性、装飾として使われるターミナルの「$」プロンプトや「●」ステータスドット

第二層は「デザインされた」ように見えるため、気づきにくいです。しかし、第一層と同じ問題を抱えています：スタイルが後から付け加えられたものであり、プロダクトから自然に生まれたものではないのです。

各項目がなぜAI的に読まれるのか、そして実際に問題がないのはどのような場合かの完全なリストは、references/ai-tells.md にあります。

良いインターフェースとはどのようなものか

references/benchmarks.md には、Vercel、GitHub、ChatGPT、Google、Linear、そして中国のプロダクトであるDingTalk、Juejin、WeChat Read、sspai からの測定値があります。また、中国のインターフェースがどのように異なるか（より太い見出し、より高い行の高さ、より小さいサイズ）も記載されています。英語のリファレンスに共通する点：

非常に少ない色：ほとんどが黒、白、グレー、そして一つの機能色
一つのフォントファミリー。見出しは大きいが、太くはない
軽い分離：空白、薄い輪郭、非常に薄い影。黒い罫線や重い影ではない
プロダクト自体がヒーローであり、装飾はほぼゼロ
画面ごとに一つの焦点

これらはリファレンスであり、テンプレートではありません。コーヒーショップがVercelのように見えるべきではありませんが、同様に抑制が効いて正確であり、コンテンツが前面に出ているべきです。

リファレンス自体が新しいデフォルトになる可能性があります。名前を隠したあなたの最近のプロジェクトが、すべて白色、ニュートラルグレー、ピル型ボタン、細い枠線のパネルになってしまった場合、リファレンスがテンプレートに変わっています。リファレンスを使って技量を校正しましょう：線がどれだけ細いか、影がどれだけ柔らかいか、見出しがどれだけ細いか。色、素材、ヒーローはステップ2のリストから選びます。

ワークフロー

0. まず、変更の規模を判断する

変更	例	どのステップを使うか
小	色、スペーシング、またはコピーの変更。一つのコンポーネントの修正。ボタンの追加	関連するコードとスタイル変数を読み、既存のスタイルで変更し、`references/ai-tells.md` の関連するエントリをいくつか確認し、1～2文で納品する（プレースホルダーがある場合のみそのリストを添付）
中	既存のプロダクト内の新しいページまたは新機能の画面	ステップ1（3～4行の計画）、次にステップ5～7。プロダクトの既存のスタイルを維持。インベントリと議論はスキップ
大	新製品、ウェブサイト、ランディングページ、リデザイン	全7ステップ

迷ったら小さい方を選びます。ユーザーは必要に応じて追加を依頼します。一つのボタンにデザインプランを書かないでください。

1. これが何であるかを理解する：まずプロジェクトを読み、次に訪問者を理解する

既存のプロジェクトでは、何かに触れる前にそれを読む。 計画やコードの前に、以下を調査する：
- プロジェクトが実際にどの機能を持っているか（README、ルート、ページ、APIを読む。ページタイトルから推測しない）
- 既存のコンポーネント、スタイル変数、アイコンセット、フォント。新しいUIはそれらを使用する。並行システムを始めない
- データモデルとAPIが返す実際のフィールド。それらのフィールドに基づいてUIを構築する
- コピー内の既存の語彙。同じものを同じ名前で呼び続ける
「プロジェクトが持っているもの」を数行で書き留め、それに基づいて計画を立てる。読めないものがあれば（例えばバックエンドがリポジトリにない）、ユーザーに尋ねるか、仮定を明確に述べる。
プロダクトやコンテンツは何か？誰のためのものか？不明な場合は、具体的な仮定を立てて一文で述べ、繰り返し質問する代わりに先に進む。
このページのモードを決定する（プロダクトではなくページを判断する：開発者ツールのホームページは「説得」、そのダッシュボードは「操作」）：

モード	訪問者にとっての成功とは	例	デザインの努力の方向性
説得	決定し行動する	ホームページ、ランディングページ、キャンペーン、価格設定	視点とインパクト。実際の画像で説得する
操作	タスクを完了する	管理画面、ダッシュボード、エディター、設定、ツール	スキャン可能、一貫性、効率性。個性は細部に宿る
読み物	コンテンツを理解する	ドキュメント、記事、ヘルプセンター、チェンジログ	明確な構造、快適な読書体験
ショーケース	作品に没入する	ポートフォリオ、ギャラリー、ケーススタディ	作品が主導し、インターフェースは後退する

一致するリファレンス：説得とショーケースは references/web.md、操作は references/app-desktop.md、モバイルはさらに references/mobile.md を使用。プロジェクトのREADMEやその中のマインドマップ・図は references/readme.md を使用。

改良かリデザインか？ 改良は既存のスタイル、コピー、振る舞いを維持し、スコープ内のものだけを変更する。リデザインは全体的な外観を置き換えるが、プロダクトの事実、コンテンツ、機能は保持する。中途半端に新しいスタイルを古いものにパッチしない。

2. この主題にのみ属するものをインベントリする

このクライアントに属し、競合他社には属さない具体的なものを8～12個書き出す：名前とその意味、通りと都市、ドア番号とショップサイン、素材と色、その数字（席数、標高、営業年数）、制約（月に1バッチ、冬季休業）、儀式（5時にオーブンが点火される）、その世界の印刷物（レシート、ラベル、時刻表）。

デザインのアイデアはこのリストから生まれ、「この業界のウェブサイトは通常どのようなものか」からは生まれません。参考にしたオープンソーススキルでは、ブラインドテストで勝ったページはこのリストのアイテムを使用しており、負けたページは業界の一般的なアイデアに基づいた良い構成を持っていました。

3. セクションを選ぶ前に「論証」を書く

マーケティングページのすべてのセクションは、主張とその証拠であるべきで、それぞれ一行で：

ヒーロー：今週3つのロースト、金曜日発送 → 証拠：3つのバッグ、焙煎日
豆：それぞれに明確な産地と風味がある → 証拠：実際の産地、標高、カッピングノート
...

主張のないセクションは削除する。これにより、ありきたりな「ヒーロー、ロゴウォール、3つの機能、お客様の声、価格設定、FAQ」という構造から脱却できます。

4. 短い計画を書く

色：4～6つの値、それぞれの使用場所
タイプ：どの書体と、それぞれの役割
レイアウト：アイデアを一文で、必要なら簡単なASCIIワイヤーフレーム、そして配置
ヒーロー：このページで最も説得力のあるもの、そして実際に所有しているアセット（存在しない画像を前提にデザインしない）
強度：抑制（操作と読み物のデフォルト）、一つのヒーロー（説得のデフォルト：インベントリから1つの大胆な画像、他はすべて控えめ）、またはフルコンセプト（以下の「強力なコンセプトにコミットするタイミング」を参照）

5. 計画をチェック：デフォルトか選択か？

同じようなブリーフが与えられたら、ほぼ同じ計画にたどり着くだろうか？そうであれば、その部分はデフォルトです。ステップ2のリストに戻ってアイデアを探す。
references/ai-tells.md の何かに当てはまるか？そうであれば、変更するか、なぜこのプロダクトに必要なのか説明できるようにする。
コンテンツよりも装飾が多いか？

返信で、何を変更したか、その理由を簡潔に述べる。

6. 構築する

色とスペーシングはCSS変数で管理する。セレクターの詳細度に注意して、クラスが互いにオーバーライドしないようにする（特にセクションのパディング）。
サンプルコンテンツは現実的で具体的であり、数字は整合している。
ページがプロダクトのインターフェースを表示する場合（例えばSaaSホームページのスクリーンショットスロット）、それをそのプロダクトの実際の断片として構築する：実際のデータ、整合する数字、一つの明確な発見。グレーのブロックや偽の数字ではない。
クラフトの詳細は references/craft-details.md にあります。

7. 結果を見て、バッチで修正し、最後に一つ削除する

実際のサイズで見る：デスクトップ、電話（約375px）、ダークモード（もし作ったなら）。一度見て、すべてを一緒に修正する。微調整のたびにスクリーンショットを撮らない。
checklist.md をチェックする。
家を出る前に鏡をチェックするように、アクセサリーを一つ外す。
結果を見ることができない場合（モデルが画像を読めない、ブラウザがない）：見たふりをしない。代わりにコードをレビューする：各ブレークポイントで最も長いテキストがカラムに収まるか、色の値から計算されるコントラスト比はどうか、すべてのインタラクション状態が記述されているか？納品時にはブラウザで確認していないことを伝え、再度のパスのためにデスクトップと電話のスクリーンショットを一枚ずつユーザーに依頼する。

抑制は空虚ではない

装飾を取り除くことは仕事の半分に過ぎません。ラベル、罫線、カードを失い、その代わりに何も得られなかったページは薄っぺらく読まれ、まだAIの味が残っている豊かなページに負ける可能性があります。残りの半分は実質です：より大胆なタイプスケール、全体的な色のフィールド、この主題の世界の実際の写真、すべてのセクションに完全なコンテンツが詰め込まれていること。

強力なコンセプトにコミットするタイミング

抑制がデフォルトであり、上限ではありません。全ページにわたるビジュアルコンセプト（漫画、新聞、設計図、チケット）は、以下のすべてが満たされた場合に適切です：

ソースがある：ユーザーから依頼されたか、主題自身の世界がこの言葉を話している（建築家の図面、印刷所の校正刷り、鉄道の時刻表）、そしてステップ2のリストで見つけることができる
すべてのデバイスがコンテンツにマッピングされる：マッピングを書き留める（例：「スピード線：積み重なるリクエスト」、「スクリーントーン密度：ロックの重さ」）。マッピングできないデバイスは削除する
それでも正確に読める：コード、数字、表、ボタンはエラーなく読み、操作できる。コンセプトはコンテンツに奉仕し、人々に誤読させない
事実は変わらない：新しいスタイルは、すべてのプロダクトの事実、機能、数字、プレースホルダーリストを保持する
どこで止めるかを知っている：メインラインでは完全に使用し、細部では抑制を保つ。すべての隅にテーマ要素を配置しない

これらのいずれかを満たさない場合は、一つのヒーローにフォールバックする：その言語をヒーローまたは一つのセクションでのみ使用する。スタイルのコスチュームとの違い：コスチュームはどんなプロダクトにもフィットします（クリームとセリフ、ほぼ黒とネオン、新聞の細線）。強力なコンセプトはこのプロダクトにのみ意味を持ちます。

納品するときは、デザインのアイデアを1～2文で説明し、ユーザーが簡単に方向転換できるようにし、プレースホルダーリストを添付します（「何も偽らず、開発者を騙さない」を参照）。

ユーザーが変更を要求した場合

ユーザーの発言	意味
より大胆に	より大きなスケールのコントラスト、全体的な色のフィールド、より大きなヒーロー。装飾を増やすのではない
より静かに / ごちゃごちゃしている	色と動きを減らし、タイプサイズを減らし、二次的な要素を削除する
シンプルに	主張のないセクションや要素を削除する。コアを維持する
もっと磨きを	クラフト：配置、スペーシング、半径、影、状態、ブラウザネイティブ部分
出荷準備はできているか？	エラー、空の状態、非常に長いコンテンツ、他の言語、エッジケース

何も偽らず、開発者を騙さない

ユーザーと開発者の両方が、何が本物で何がまだ完了していないかを区別できるべきです。

エンドユーザーに対しては偽物は禁止

でっち上げのロゴ、顧客ロゴの壁、パートナーバッジは禁止。「$」、「▲」、「●」などの記号から組み立てられた偽ロゴは禁止。ロゴがない場合は、プロダクト名をプレーンテキストで十分。
でっち上げのユーザー数、満足度、成長率、お客様の声、プレス掲載は禁止。
専門的な事実をチェックする（技術詳細、標準、規制、医療、財務、統計）。AIはこれらを流暢に書き、その間違いも同様に流暢に見える：
- ページ上の専門的な主張をリストアップする。ドキュメントや標準で確認できるものは調べ、コードコメントに出典を記載する
- 確認できないものは、省略するか、プレースホルダーリストの「未確認」にリストする
- ページ上の数字は互いに整合していなければならない（1秒間に70リクエストを41秒間で2,870リクエスト）

開発者を騙すものは禁止

でっち上げの機能は禁止：インターフェースに表示されるすべての機能は、プロジェクトに存在するか、明示的に要求されたものでなければならない。ページを良く見せるために「スマートレコメンデーション」や「ワンクリックエクスポート」を追加しない。
モックデータが実際のデータを装わない：可能な場合は実際のAPIに接続する。できない場合は、モックデータを一箇所にまとめ（例：mock/）、実際のAPIと同じフィールドを持たせ、コード内でモックであることを明示する。魅力的な数字をコンポーネントにハードコードしてページが「完成した」ように見せかけない。
偽のインタラクションは禁止：配線されていないボタン、フォーム、リンクには、動作しているふりをするクリックアニメーションをつけてはならない。無効にして「未接続」とラベルするか、納品ノートにリストする。
ゼロから構築されたデモやコンセプトは、架空のブランドとデータを使用してもよいが、ページはそれが例であることを明示しなければならない。

プレースホルダーリストを添付する

あらゆる大規模または中規模の変更に、テキストファイル PLACEHOLDERS.md を添付する。インベントリ（ステップ2）から、まだ適用していない現実世界の要素、まだ設定していない変数、まだ調べていない専門的な事実をリストする。それぞれに「未確認」のラベルを付ける。
このリストは、開発者がページを完全なものにするために何をする必要があるかを正確に知ることができるようにするためのものです。それはTODOリストであり、謝罪ではありません。

作業を超えて：設計判断の説明

実際の作業が終わった後でも、開発者とユーザーはデザインの理由を知る必要があります：

コード内：「このコンポーネントはページの大部分を占めているため、フォーム全体が上部の空きスペースに手を伸ばせるようになっています」

納品時：「ヒーロー画像で製品を強調し、明るい青色がCTAに注意を向けさせています」

設計判断を説明するときは、動作を説明するだけでなく、プロダクトの事実がなぜその特定の外観につながったのかを述べてください。これは、開発者がデザインを維持し、一貫性を保つのに役立ちます。

toothpick

toothpick とは？

お気に入りのAIに質問する

ドキュメント