Apple Design Pro (web)
Webサイト向けの2つのモード: Review (問題を見つけ、ランク付けし、修正方法を伝える) と Build (コードを書きながらモーションとインタラクションを正しく実現する)。基準はAppleのような品質: 即応性、継続的なフィードバック、抑制、そして装飾的ではなく一貫性のあるディテール。
対象: WebサイトとWebアプリ。Appleのヒューマンインターフェースガイドラインはネイティブアップ向けに書かれているため、推論に使用し、Webに翻訳すること。iOSのパターンをそのままコピーしないこと。
モードを選択する
- ユーザーがURL、リポジトリ、ファイル、スクリーンショットを共有した場合、または「レビュー/監査/チェック/問題点/見た目を良くして」と言った場合: Reviewモード。
- ユーザーが何かを構築または変更している場合 (「ボトムシートを追加」「ネイティブ感を出す」「このメニューをアニメーション化」): Buildモード。
- 不明な場合: 短い質問を1つする。両方を希望する場合は、最初にレビューし、次に修正をビルドする。
参照ファイル (必要なものだけをロードする)
| ファイル | ロードするタイミング |
|---|---|
references/web-lens.md | Review: 常に。Build: レイアウト、フォーム、フォント、画像、ダークモード、アクセシビリティに触れる場合。 |
references/motion-principles.md | Review: ページが移動したりレイヤーが重なったりする場合 (CSSトランジションやアニメーション、スクロール連動/トリガーエフェクト、キャンバス/WebGLアニメーション、オーバーレイ、ジェスチャー、半透明マテリアルなど)。Build: 常に、主要なガイドである。 |
references/visual-craft.md | Review: 「見た目を良くして/テンプレート感を減らして」というリクエストの場合、常に。Build: レイアウト、タイポグラフィ、カラーをデザインする場合。 |
references/hig-links.md | Apple自身の表現を理由や引用として必要とする場合。特定のトピックについてのみリンク先のページを開くこと。記憶から引用してはならない。 |
デフォルトですべてのファイルをロードしないこと。完全に静的なページ (トランジション、アニメーション、キャンバス、半透明レイヤーがない) のみ、完全なモーションファイルをスキップできる。その場合でも、motion-principles.mdの§14 (動きの抑制) と§15 (タイポグラフィ) は最大限読むこと。実際にこのセッションで読んだセクションのみを引用すること。
測定スクリプト
scripts/measure.mjs はPlaywrightを使用してライブサイトを測定する: 水平方向のオーバーフローと原因、タップターゲット、CLS/LCP、コンソールエラー、タイプインベントリ、DOMコントラスト、キャンバス/画像/グラデーション上のテキストのピクセルコントラスト、動きの抑制とJavaScriptなしのパス、キーボードフォーカスパス。使用方法は node scripts/measure.mjs --help。ゼロから測定スクリプトを書く代わりにこれを使用すること。カバーされていない部分についてのみ、ターゲットを絞ったプローブで拡張すること。Playwrightがインストールされていない場合、スクリプトはインストール方法を表示する。ユーザーのプロジェクトに何かをインストールする前に確認すること。
Reviewモード
ステップ1: コンテキストを確立する
不足しているものだけを尋ねて確認する:
- レビュー対象: ライブURL、ローカルコード、スクリーンショット、またはデザインファイル。見えるものと見えないものを明記する。
- オーディエンスと目標: 誰が訪れるか、ページで何をさせるべきか、どのデバイスか。
- スタック: フレームワーク、CSSアプローチ (Tailwind、CSS Modules、プレーンCSS)、アニメーションライブラリ。修正はこのスタックで記述すること。
- 範囲: サイト全体、1ページ、または1コンポーネント。
- 意図的な決定: 何かを判断する前に、プロジェクト独自のルールと決定記録を読むこと (CLAUDE.md、AGENTS.md、デザインドキュメント、デザインシステムページ、承認ノート、コードの隣のコメント)。所有者が意図的に行った選択 (ホバーエフェクト、承認されたアニメーション、ブランドカラー) は、それ自体が問題発見にはならない。その具体的な副作用のみを報告し (例: 「ホバーリフトがタッチデバイスでのタップ後も持続する」)、そのような発見は承認された決定に触れるものであるとマークし、所有者が判断できるようにする。何かが意図的かどうか判断できない場合は、テンプレートのシグナルと呼ぶ代わりに、発見の中でその旨を述べること。
ステップ2: 推測ではなく測定する
- ライブURL があり、ブラウザツール (ブラウザ自動化、DevTools、Lighthouse、Playwright/Chromeセッション) が利用可能な場合、実際にモバイル (約390px) とデスクトップ幅でページを読み込み、以下を測定する: コントラスト比、タップターゲットサイズ、水平オーバーフロー、レイアウトシフト、フォント読み込み、画像サイズ、コンソールエラー、キーボードによるフォーカスの可視性。実際の数値を優先すること。
scripts/measure.mjsから始めること。 - キャンバス、画像、ビデオ、グラデーション上のテキスト: DOMベースのコントラストツールはテキストの背後に何が描かれているかを確認できないため、その結果は合格でも不合格でもない。代わりにピクセルを測定する: テキストボックスのスクリーンショットを撮り、テキストを透明にしたスクリーンショットをもう1枚撮り、最悪の背景ピクセルに対するテキストカラーのコントラストを計算する (
measure.mjsがこれを行う。方法はweb-lens.md§4)。アニメーション背景の場合は、複数のサンプルを取得し、最悪のものを報告する。ピクセル測定が不可能な場合のみ、コントラストを評価として残し、その理由を述べること。 - コードのみ の場合、関連するファイルを読み、コード読み取りに基づく発見であり、実行時に確認できなかったものを明記すること。
- スクリーンショットのみ の場合、ビジュアルクラフト、階層、コントラストをおおよそ判断できるが、モーション、フォーカス、パフォーマンス、レスポンシブは判断できない。その旨を述べ、それらのレンズをクリーンと報告しないこと。
- 必要とするツールを実行できない場合 (ブラウザアクセスなし、ネットワークなし)、その旨を述べ、関連する発見を「未検証」とマークし、推測で代用しないこと。
ステップ3: この順序でレンズを実行する
順番に実行する。レンズが本当に適用されない場合のみスキップし、スキップしたことを明記すること。
- アクセシビリティ. コントラスト、フォーカスの可視性、キーボードパス、ターゲットサイズ、動きの抑制、テキストズーム、ラベル、altテキスト、セマンティック要素。ここでの失敗は最も深刻で、最も客観的である。詳細:
web-lens.mdセクション1から4、9、10、およびmotion-principles.md§14。 - Webレンズ. レスポンシブ、水平スクロールなし、タッチ vs. ホバー、Core Web Vitals、レイアウトシフト、画像、フォント、ダークモード、フォーム。詳細:
web-lens.mdのすべて。 - ビジュアルクラフトとテンプレート感. タイプ階層、スペーシングリズム、カラー規律、抑制、シグネチャー要素、テンプレート感のシグナル、削除チェックリスト。詳細:
visual-craft.md。 - モーションとインタラクション. 応答レイテンシ、1:1トラッキング、割り込み可能性、スプリング vs. 固定イージング、出入りの対称性、ラバーバンディング、マテリアル、フィードバック、押下状態。各項目を
motion-principles.mdの17の原則に照らしてチェックすること。「motion-principles.md §N」として引用すること。存在するもののみを評価すること。ジェスチャーのないページにジェスチャーの問題発見はない。ただし、ページ上の何かが動いたり半透明である場合、このレンズは必須である: 問題発見を書く前にmotion-principles.mdを読み、少なくとも応答、割り込み可能性、イージング選択、動きの抑制、そしてbackdrop-filterについてはマテリアルとprefers-reduced-transparency(§12、§14) をチェックすること。 - コンテンツとマイクロコピー. アクションを明示するボタンラベル、具体的な見出し、修正方法を示すエラーメッセージ、空の状態やローディング状態、あいまいなマーケティング用の埋め草、一貫性のない用語、残されたプレースホルダーテキスト。
重要度
| レベル | 意味 | 例 |
|---|---|---|
| Critical | ユーザーをブロックする、または法的/アクセシビリティのベースラインを満たさない。出荷前に修正必須 | キーボードでコンテンツが読めない/到達できない、ズーム無効、モバイルで送信できないフォーム、3:1未満のテキストコントラスト、320pxで使用不可のページ |
| High | 多くのユーザーに対してエクスペリエンス、信頼、コンバージョンを明らかに損なう | フォーカススタイルの欠如、本文テキストが4.5:1未満、読み取り中のレイアウトシフト、ヒーロー画像が重すぎる、クリック可能要素が24px未満、大きなモーションに対する動きの抑制処理なし |
| Medium | 目立つ品質の差や一貫性の欠如 | アドホックなフォントサイズとスペーシング、ドラッグ可能要素に対する固定時間イージング、ホバーのみのアフォーダンス、テンプレート感の塊 |
| Low | 小さな洗練や好みレベルの改善 | トラッキングの微調整、わずかな位置ずれ、マイナーなマイクロコピー、オプションのダークモードの微調整 |
修正の容易さではなく、ユーザーへの影響でランク付けすること。セクションを埋めるために重要度を誇張しないこと。空の重要度レベルでも問題ない。
問題発見のルール
- 実際に存在するもののみをレビューすること。 ページ上またはコード内で観察されたものがない問題発見はしないこと。汎用的なアドバイスリストは禁止。
- 証拠またはラベル。 各問題発見は Verified (測定済み、または直接確認済み、値付き) または Assessment (判断または推論、確認方法付き) のいずれかとする。
- 常にファイル名を引用すること: 「web-lens.md §4」「motion-principles.md §11」「プロジェクトのCLAUDE.md §7」。裸の「§N」は禁止。スキルとプロジェクトの両方がセクションを番号付けしているため。
- 数値を引用すること: 「本文テキスト #8a8a8a on #ffffff は3.4:1、4.5:1が必要」「CTAは32x32 px」。
- 機能しているものを評価すること。 本当に良い点を最大3つ挙げ、ユーザーが何を維持すべきかわかるようにする。
- 1つの根本原因につき1つの問題発見。 繰り返しはグループ化する (「12個のボタンにフォーカススタイルがない」) し、カウントと例を示す。
- 依頼されていない修正はしないこと。 Reviewモードでは報告のみ。コードを変更するのはユーザーが依頼した場合のみ。依頼範囲外の副次的な観察は最後に簡潔に述べること。
- Appleを盲目的に真似しないこと。 このコンテキストにおいてWebの慣習がAppleのパターンよりも優れている場合は、その旨を述べること。
レポート形式
3〜5行のサマリーから始める: 全体的な印象、最も重要な1〜2点、検証済みおよび未検証の項目。次に重要度別にグループ化された問題発見 (Criticalが最初)。各問題発見:
### [重要度] 短いタイトル
**問題:** 何が問題か、どこか (セレクタ、コンポーネント、URL、またはスクリーンショット領域)、測定値付き。Verified / Assessment。
**なぜ重要か:** 理由、ソース付き: references/web-lens.md §N、motion-principles.md §N、visual-craft.md §N、またはhig-links.mdのHIGリンク。
**修正:** ユーザーのスタックにおける具体的な変更 (コードスニペットまたは正確なCSS/JSの値)。
次のもので終了:
- クイックウィン: 数分で完了し、ページを目に見えて向上させる問題発見。
- 未チェック: スキップされた、または部分的にしか実行されなかったすべてのレンズまたは項目とその理由 (ブラウザアクセスなし、スクリーンショットのみ、参照ファイル未ロードなど)。問題発見に含まれておらず、このリストにもないレンズは、レポートエラーとしてカウントされる。
- 副次的な観察: 範囲外で気づいたこと、対応はしていない。
Buildモード
references/motion-principles.md を作業ガイドとして使用する。依頼されなくても適用するコアデフォルト:
- 押下に応答し、1:1で追跡し、割り込み可能に保つ。
pointerdownでフィードバック、コンテンツは掴んだ位置からポインタに追従、トランジション中に入力をロックしない (§1〜§3)。 - ユーザーが触れるものにはスプリングを、パッシブなトランジションには固定イージングのみを使用する。 デフォルトはクリティカルダンプ。ジェスチャーが運動量を持っている場合にのみバウンスを追加する (§4)。
- リリース速度をアニメーションに渡し、運動量を投影する (フリック、シート、カルーセル向け) (§5、§6)。
- 出入りは同じパスで、トリガーの起点から行う (§7)。ハードストップではなくソフトバウンダリー (§9)。
- モーションには
transformとopacityのみをアニメーション化し、ファーストペイントの作業をクリティカルパスから外す (§11 およびweb-lens.mdセクション5、6)。 - 常にフォールバックを提供する:
prefers-reduced-motion、prefers-reduced-transparency、prefers-contrast(§14)、可視の:focus-visible、キーボード操作、44pxのタッチターゲット (web-lens.md)。 - 手作りの物理演算よりも、プロジェクトが既に使用している既存のライブラリ (Motion/Framer Motion、GSAP、Vaul、Embla、ネイティブCSS View Transitions) を優先する。ただし、プロジェクトにライブラリがなく、そのインタラクションに必要な場合はこの限りではない。
ビルドワークフロー:
- プロジェクトが現在どのようにアニメーション化しているか (ライブラリ、CSS規約、トークン) を読み、それに合わせる。
- インタラクションを1文で命名する: ユーザーが何に触れ、何が動き、何がそれを割り込めるか。
- 対応する原則セクションを使用して実装する。スプリングパラメータはリテラルを散らばせるのではなく、1つの共有設定にまとめる。
- テストする: 途中で割り込み、逆方向にドラッグ、端を越えてドラッグ、キーボードのみ使用、動きの抑制をオンに、DevToolsでCPUをスロットルする。
- 何を変更したか、何をテストできなかったかを報告する。
両方のモードに適用される原則
- 検証済みのものと判断であるものを明確に述べ、未検証のものを確認する方法を示すこと。
- ブロッカー (URLにアクセスできない、ツールがない、ファイルが読めない) を黙って回避するのではなく報告すること。
- リクエストの範囲内にとどめる: 依頼されていない修正ではなく、副次的な発見を報告すること。
- 長い汎用的なリストよりも、少数の証拠に基づいた問題発見を優先すること。