Anthropic Claudeデザイン・クリエイティブ⭐ リポ 299品質スコア 94/100

axiom-hig-ref

Name: axiom-hig-ref
Author: majiayu000

Apple Human Interface Guidelines リファレンス — 色（セマンティックカラー、カスタムカラー、パターン）、背景（マテリアル階層、ダイナミック背景）、タイポグラフィ（標準スタイル、カスタムフォント、Dynamic Type）、SF Symbols（レンダリングモード、色、多言語対応）、ダークモード、アクセシビリティ、プラットフォーム固有の考慮事項を網羅したガイドラインです。

description の原文を見る

Reference — Comprehensive Apple Human Interface Guidelines covering colors (semantic, custom, patterns), backgrounds (material hierarchy, dynamic), typography (built-in styles, custom fonts, Dynamic Type), SF Symbols (rendering modes, color, axiom-localization), Dark Mode, accessibility, and platform-specific considerations

SKILL.md 本文

Apple Human Interface Guidelines — 包括的リファレンス

概要

Human Interface Guidelines（HIG）は Apple の設計哲学を定義し、すべての Apple デバイス全体で直感的でアクセシブルで、プラットフォームに適切な体験を作成するための具体的なガイダンスを提供します。

3 つのコア原則

すべての設計決定は、これらの原則をサポートする必要があります。

1. 明確性（Clarity） コンテンツが最も重要です。インターフェース要素はコンテンツに対して二次的な役割を果たすべきであり、競合すべきではありません。すべての要素には目的があり、不要な複雑さは排除され、ユーザーは広範な説明なしに何ができるかを即座に理解する必要があります。

2. 一貫性（Consistency） アプリは標準的な UI 要素と親しみのあるパターンを使用します。ナビゲーションはプラットフォーム規約に従い、ジェスチャーは期待通りに動作し、コンポーネントは予期された場所に表示されます。この親しみやすさは認知負荷を軽減します。

3. 謙虚さ（Deference） UI は重要なコンテンツを邪魔すべきではありません。微妙な背景、不要な時は後退するナビゲーション、抑制されたブランディングを使用し、コンテンツが主役になるようにします。

Apple HIG より: 「Deference はコンテンツが際立つ一方で周囲の視覚要素がそれと競合しないようにすることで、アプリを美しくします。」

設計システムの哲学

WWDC25 より: 「体系的なアプローチとは、すべてのレベルで意図を持って設計することを意味し、最小のコントロールから最大の表面まで、すべての要素が全体との関連で考慮されることを保証します。」

カラーシステム

セマンティックカラーの説明

ハードコードされたカラー値を使用する代わりに、色の外観ではなく目的を説明するセマンティックカラーを使用します。セマンティックカラーはライト/ダークモードとアクセシビリティ設定に自動的に適応します。

WWDC19 からの重要な洞察: 「ダークモードは、すべてが反転されるのではなく、照明が暗くなると考えてください。」色は単に反転されません。テーブル行の背景は両方のモードで明るくなります。

ラベルカラー（フォアグラウンドコンテンツ）

テキストとシンボルにはラベルカラーを使用します：

// プライマリコンテンツ（最も目立つ）
Text("Title")
    .foregroundStyle(.primary)
// `label` カラーを使用 - ライトモードでは黒、ダークモードでは白

// セカンダリコンテンツ（サブタイトル、目立たない）
Text("Subtitle")
    .foregroundStyle(.secondary)
// `secondaryLabel` を使用 - グレートーン

// ターシャリコンテンツ（プレースホルダーテキスト）
Text("Placeholder")
    .foregroundStyle(.tertiary)
// `tertiaryLabel` を使用 - より明るいグレー

// クォータナリコンテンツ（無効なテキスト）
Text("Disabled")
    .foregroundStyle(.quaternary)
// `quaternaryLabel` を使用 - 非常に明るいグレー

階層: label → secondaryLabel → tertiaryLabel → quaternaryLabel

背景カラー（プライマリ→ターシャリ）

背景カラーには 2 つのセット「グループ化されていない」と「グループ化」があります。

グループ化されていない背景

標準的なリストとビュー用：

// プライマリ背景（メイン背景）
Color(.systemBackground)
// ライトモードでは純白、ダークモードでは純黒

// セカンダリ背景（情報構造）
Color(.secondarySystemBackground)
// ライトモードでは薄いグレー、ダークモードではダークグレー

// ターシャリ背景（さらなるレイヤリング）
Color(.tertiarySystemBackground)
// セカンダリよりも軽く、ダークモードではより暗い

グループ化された背景

グループ化されたテーブルビュー用（iOS 設定スタイル）：

// プライマリグループ化背景
Color(.systemGroupedBackground)

// セカンダリグループ化背景
Color(.secondarySystemGroupedBackground)

// ターシャリグループ化背景
Color(.tertiarySystemGroupedBackground)

使用方法:

// 標準リスト
List {
    Text("Item")
}
.background(Color(.systemBackground))

// グループ化されたリスト（設定スタイル）
List {
    Section("Section 1") {
        Text("Item")
    }
}
.listStyle(.grouped)

ベースと昇格した背景

インターフェースをレイヤー化するために、実際には背景カラーの2 つのセットがあります：

ベースセット: バックグラウンドアプリ/インターフェース用
昇格したセット: フォアグラウンドアプリ/インターフェース用

これが重要な理由:

ライトモードでは、シンプルなドロップシャドウが視覚的な分離を作成します。ダークモードではドロップシャドウが効果的でないため、システムは昇格したコンテンツにより明るい色を使用します。

例: iPad のマルチタスキング:

Mail アプリのみ → ベースカラーセット
Contacts がスライドオーバー内 → 昇格したカラー（より明るく、目立つ）
両方が横並び → 両方が昇格したカラーを使用してスプリッター周辺のコントラストを実現
メール作成シート → 昇格したカラーとオーバーレイ暗くする

重要: より暗いカラーの一部は昇格した状態でコントラストがよくないかもしれません。常に昇格した状態で設計をテストしてください。半透明フィルと区切りカラーは優雅に適応します。

ティントカラー（ダイナミック適応）

ティントカラーはダイナミックです。ライト/ダークモードのバリエーションがあります：

// ティントカラーは自動的に適応
Button("Primary Action") {
    // action
}
.tint(.blue)
// ダークモードではより明るく、ライトモードではより暗くなります

カスタムティントカラー: カスタムティントカラーを作成する場合は、両方のモードでうまく機能するカラーを選択します。コントラスト計算器を使用して、4.5:1 以上のコントラスト比を目指します。ライトモードで機能するカラーは、ダークモードで不十分なコントラストをもつかもしれません。

フィルカラー（半透明）

フィルカラーは半透明で、変動する背景に対してよくコントラストします：

// システムフィルカラー
Color(.systemFill)
Color(.secondarySystemFill)
Color(.tertiarySystemFill)
Color(.quaternarySystemFill)

使用時: 動的背景上に表示する必要があるコントロール、ボタン、対話的要素。

区切りカラー

// 標準区切り（半透明）
Color(.separator)

// 不透明区切り
Color(.opaqueSeparator)

不透明区切りは、透明度が望ましくない結果をもたらす場合に使用されます（たとえば、交差するグリッド線で、半透明カラーが重なることで光学的な幻覚を作成します）。

恒久的な暗い背景を使用する場合

Apple の明示的なガイダンス:

「まれなケースでは、インターフェースで暗い外観のみを使用することを検討します。たとえば、没入的なメディア視聴を可能にするアプリの場合、UI が後退し、ユーザーがメディアに焦点を当てるのに役立つ恒久的な暗い外観を使用するのが理にかなっています。」

Apple のアプリからの例:

アプリ	背景	根拠
Music	暗い	アルバムアートが視覚的焦点
Photos	暗い	画像がヒーローコンテンツ
Clock	暗い	夜間使用、楽器のような感触
Stocks	暗い	データビジュアライゼーション、チャート
Camera	暗い	撮影中の気が散るのを軽減

他のすべてのアプリの場合: システム背景経由でライトモードとダークモードの両方をサポートします。

カスタムカラーの作成

カスタムカラーが必要な場合：

Assets.xcassets を開く
カラーセットを追加
バリエーションを設定:
- ライトモードカラー
- ダークモードカラー
- High Contrast Light（オプション、推奨）
- High Contrast Dark（オプション、推奨）

// アセットカタログからカスタムカラーを使用
Color("BrandAccent")
// 正しいバリエーションを自動的に使用

タイポグラフィ

システムフォント

San Francisco (SF): システムサンセリフフォントファミリー。

SF Pro: 一般的な使用
SF Compact: watchOS とスペース制限されたレイアウト
SF Mono: コードとモノスペーステキスト
SF Rounded: より柔らかく、より親しみやすい感触
ウェイト: Ultralight, Thin, Light, Regular, Medium, Semibold, Bold, Heavy, Black

New York (NY): 編集コンテンツ用システムセリフフォントファミリー。

両方がバリアブルフォントとしてシームレスなウェイト遷移で利用可能です。

フォントウェイトの推奨事項

Apple HIG より: 「軽いフォントウェイトを避けます。Ultralight、Thin、Light の代わりに Regular、Medium、Semibold、または Bold を使用してください。」

理由: 軽いウェイトは特に小さいサイズ、明るい照明、または視覚障害のあるユーザーにおいて可読性の問題があります。

階層:

// ヘッダー - 目立たせるために Bold ウェイト
Text("Header")
    .font(.title.weight(.bold))

// サブヘッダー - Semibold
Text("Subheader")
    .font(.title2.weight(.semibold))

// ボディ - Regular または Medium
Text("Body text")
    .font(.body)

// キャプション - Regular（決して Light ではない）
Text("Caption")
    .font(.caption)

階層用テキストスタイル

自動階層と Dynamic Type サポートのために組み込みテキストスタイルを使用します：

.font(.largeTitle)    // 最大
.font(.title)         // ページタイトル
.font(.title2)        // セクションヘッダー
.font(.title3)        // サブセクションヘッダー
.font(.headline)      // 強調されたボディ
.font(.body)          // デフォルトボディテキスト
.font(.callout)       // わずかに強調
.font(.subheadline)   // あまり目立たない
.font(.footnote)      // 補助情報
.font(.caption)       // 最小限の強調
.font(.caption2)      // 最小

Dynamic Type サポート

要件: アプリは最低限200%（iOS、iPadOS）または140%（watchOS）のテキストスケーリングをサポートする必要があります。

実装:

// ✅ 正しい - 自動的にスケール
Text("Hello")
    .font(.body)

// ❌ 間違い - 固定サイズ、スケールしない
Text("Hello")
    .font(.system(size: 17))

レイアウトの考慮事項:

より大きいサイズで複数列レイアウトを減らす
テキスト切り詰めを最小化する
大きいサイズではスタックレイアウトを使用
サイズに関係なく一貫した情報階層を維持する

すべてのコンテンツが均等にスケールするわけではありません: ユーザーが実際に気にすることを優先します。タブタイトルなどの二次要素は主なコンテンツほど成長すべきではありません。

カスタムフォント

カスタムフォントを使用する場合：

さまざまな距離と状態での可読性を確保
Dynamic Type サポートを実装
Bold Text アクセシビリティ設定に応答
すべてのテキストサイズでテスト
アクセシビリティのためのシステムフォント動作に合わせる

カスタムフォントが細い場合: 大文字ラテンテキストと組み合わせるときは、サイズを約2ポイント増やします。

Leading（行間隔）

ルーズ leading: 幅広い列（次の行への追跡が簡単） タイト leading: 制限された高さ（3 行以上では避ける）

// 特定のレイアウト用に leading を調整
Text("Long content...")
    .lineSpacing(8) // 行間にスペースを追加

形状と幾何学

3 つの形状タイプ（iOS 26）

WWDC25 より: 「私たちの形状がどのように組み合わされるかには静かな幾何学があり、同心性によって駆動されます。半径とマージンを共有中心の周りに揃えることで、形状は互いに快適に入れ子にすることができます。」

1. 固定形状

サイズに関係なく一定のコーナー半径：

RoundedRectangle(cornerRadius: 12)

使用時: 特定の変わらないコーナー半径が必要な場合。

2. カプセル

半径はコンテナの高さの半分：

Capsule()

使用時: 形状をコンテンツに適応させ、丸い端を維持する場合。ボタン、ピル、コントロールに最適。

iOS 26 全体に見られます: スライダー、スイッチ、グループ化されたテーブルビュー、タブバー、ナビゲーションバー。

3. 同心形状

親の半径からパディングを減じて半径を計算：

.containerRelativeShape(.roundedRectangle)

使用時: コンテナ内に形状をネストして視覚的な調和を維持する場合。

同心性の原則

ハードウェア ↔ ソフトウェアの調和: Apple のハードウェアは一貫したベゼル曲率を備えています。同じ精度が現在 UI を導き、曲率、サイズ、比例が揃って、あなたが持つものとあなたが見るものの間に統一された律動を作成します。

同心性の例:

ウィンドウ（角が丸い）
  ├─ シート（ウィンドウに同心）
  │   ├─ カード（シートに同心）
  │   │   └─ ボタン（カードに同心）

プラットフォーム固有のガイダンス

iOS:

ボタン、スイッチ、グループ化されたリスト用カプセル
タッチに優しいレイアウトで階層と焦点を作成

macOS:

ミニ、小、中コントロール → 角丸矩形（密集したレイアウト、インスペクターパネル）
大、特大コントロール → カプセル（余裕のある領域、Liquid Glass 経由の強調）

光学センタリング

光学的バランスを保つために、ビューは：

意味のある場合は数学的に中心揃え
光学的重量がそれを要する場合は微妙にオフセット

例: 非対称アイコンは光学的センタリングのためにパディング調整が必要な場合があります。

マテリアルと奥行き

標準マテリアル

マテリアルは背景コンテンツが見えるようにし、視覚的な奥行きと階層を作成します。

4 つの厚さオプション

ウルトラシン — 最小限の分離、コンテンツが明確に見える
シン — より軽量のインタラクション
レギュラー — デフォルト、ほとんどの状況でうまく機能
シック — 背景からの最大分離

厚さ選択:

コンテンツがより多くのコントラストを必要とする → より厚いマテリアル
よりシンプルなコンテンツ → シン/ウルトラシンマテリアル

// マテリアルを適用
.background(.ultraThinMaterial)
.background(.thinMaterial)
.background(.regularMaterial)
.background(.thickMaterial)

ビブランシーを使用したマテリアル

キー原則: マテリアルの上で鮮やかなカラーを使用して可読性を確保します。ソリッドカラーは背景コンテキストによっては濁る可能性があります。ビブランシーは背景に関係なくコントラストを維持します。

// マテリアル上の鮮やかなテキスト
VStack {
    Text("Primary")
        .foregroundStyle(.primary) // 鮮やか
    Text("Secondary")
        .foregroundStyle(.secondary) // 鮮やか
}
.background(.regularMaterial)

Liquid Glass（iOS 26+）

目的: コントロールとナビゲーション用の異なる機能レイヤーを作成し、コンテンツ上に浮かんでいます。

2 つのバリアント:

レギュラー Liquid Glass
- デフォルト、ほぼ 95% のケースで使用
- 完全な視覚と適応効果
- コンテキストに関係なく可読性を提供
- あらゆる背景上で動作
クリア Liquid Glass
- 高度に半透明
- 適応動作なし
- 視覚的に豊かな背景（写真、ビデオ）上のコンポーネント用のみに使用
- 可読性のための暗くするレイヤーが必要

クロスリファレンス: 実装詳細については axiom-liquid-glass スキル、包括的な採用ガイドについては axiom-liquid-glass-ref を参照してください。

レイアウト原則

ビジュアルハイアラーキー

相対的な重要性を伝えるためにアイテムを配置:

重要なコンテンツ → トップと先頭側
セカンダリコンテンツ → 下または末尾
ターシャリコンテンツ → 別のビューまたは段階的な開示

Apple HIG より: 「十分なスペースを与え、非必須の詳細で隠さないことで、重要な情報を見つけやすくします。」

グループ化と整理

コンテンツを端まで拡張

「コンテンツを拡張してスクリーンまたはウィンドウを埋める」背景とアートワークが表示エッジに達する。

背景拡張ビュー: コンテンツが自然にフルウィンドウにまたがらない場合に使用。

// コンテンツを端まで拡張
VStack {
    FullWidthImage()
        .ignoresSafeArea() // スクリーン端まで拡張
}

セーフエリアとレイアウトガイド

セーフエリア: 以下で遮られない矩形領域：

ステータスバー
ナビゲーションバー
タブバー
ツールバー
デバイス機能（Dynamic Island、ノッチ、ホームインジケータ）

レイアウトガイド: 以下でコンテンツの配置とスペーシングを定義する矩形領域：

定義済みマージン
テキスト幅最適化
読み取り幅制約

キー原則: 「各プラットフォームのキー表示とシステム機能を尊重します。」

// セーフエリアを尊重
VStack {
    Text("Content")
}
.safeAreaInset(edge: .bottom) {
    BottomBar()
}

コンポーネントを揃える

「コンポーネントを相互に揃えてスキャンを簡単にします。」

グリッド揃え:

テキストベースラインが揃う
コントロールが共有グリッド上で揃う
スペーシングが一貫性があり、律動的

適応性要件

以下のレイアウトを設計：

「コンテキスト変更に優雅に適応しながら、認識可能に一貫した状態を保つ」
Dynamic Type テキストサイズ変更をサポート
複数のデバイス、向き、ローカライゼーション間で動作
さまざまなスクリーンサイズ、解像度、システム機能を考慮

アクセシビリティ

ビジョンアクセシビリティ

テキストと可読性

要件:

最低限200%（140% watchOS）のテキスト拡大をサポート
systemwide テキスト調整用に Dynamic Type を実装
Bold Text アクセシビリティ設定を強化するフォントウェイトを使用

カラーコントラスト

WCAG Level AA 標準:

通常テキスト（14pt 以上）: 4.5:1 最小
小さいテキスト（14pt 未満）: 7:1 推奨
大きいテキスト（18pt 以上 regular、14pt 以上 bold）: 3:1 受け入れ可能

実装:

// ✅ セマンティックカラーを使用（自動コントラスト）
Text("Label").foregroundStyle(.primary)

// ❌ カスタムカラーはコントラストが失敗する可能性
Text("Label").foregroundStyle(.gray) // 計算機で確認

High Contrast モード: 「Increase Contrast」アクセシビリティ設定が有効な場合、より高いコントラストカラースキームを提供します。

ライトモードとダークモード両方でテストしてください。

カラーの考慮事項

重大: 「色のみで情報を伝えない」色盲ユーザーをサポートするため。

ソリューション:

色と一緒に異なる形状またはアイコンを使用
テキストラベルを追加
システム定義カラーのアクセシブルバリエーションを使用
Color Blindness シミュレーターでテスト

例:

// ❌ 色のみがステータスを示す
Circle().fill(isActive ? .green : .red)

// ✅ 形状 + 色
HStack {
    Image(systemName: isActive ? "checkmark.circle.fill" : "xmark.circle.fill")
    Text(isActive ? "Active" : "Inactive")
}
.foregroundStyle(isActive ? .green : .red)

スクリーンリーダー

VoiceOver アクセシビリティ用にインターフェースとコンテンツを説明します：

Button {
    share()
} label: {
    Image(systemName: "square.and.arrow.up")
}
.accessibilityLabel("Share")

聴覚アクセシビリティ

メディア代替案

ビデオ/オーディオコンテンツの場合、提供：

対話用キャプション
字幕
ビジュアル情報専用の音声説明
より長い形式のメディア用トランスクリプト

オーディオキュー

オーディオ信号を次のものと組み合わせます：

ハプティックフィードバック
ビジュアルインジケータ

モビリティアクセシビリティ

タッチターゲット:

最小: 44x44 ポイント
スペーシング: コントロール周辺 12～24 ポイントパディング

ジェスチャー:

シンプルなジェスチャーを使用
代替案を提供（ジェスチャー横のボタン）
Voice Control をサポート
キーボードナビゲーションを有効にする

支援技術:

VoiceOver
Switch Control
Full Keyboard Access

認知アクセシビリティ

インタラクション設計

「アクションをシンプルで直感的に保つ」
時間ベースの自動消去ビューを避ける
オーディオ/ビデオの自動再生を防止

モーションと視覚効果

「Reduce Motion」を尊重:

アニメーションを最小化
過度なフラッシング光を避ける
「Dim Flashing Lights」をサポート
バウンス効果を軽減
z 軸の深さ変更を最小化

// Reduce Motion 設定をチェック
@Environment(\.accessibilityReduceMotion) var reduceMotion

var body: some View {
    content
        .animation(reduceMotion ? nil : .spring(), value: isExpanded)
}

ゲーム対応

調整可能な難易度レベルを提供します。

visionOS 固有

快適さを優先：

水平レイアウトを維持
アニメーション速度を削減
ヘッド固定コンテンツを避ける（支援技術使用を防止）

モーションとアニメーション

コア原則

目的あるアニメーション: 「目的を持ってモーションを追加し、体験をサポートしながらそれを圧倒しない。」

不要なアニメーションを避ける気を散らしたり、不快感を与える。モーションはドミナント化ではなく、強化すべきです。

アクセシビリティ最優先

モーションをオプション化します。 視覚的なフィードバックをハプティクスとオーディオで補足して重要な情報を伝え、すべてのユーザーがモーション設定に関係なくインターフェースを理解できることを確保します。

フィードバックのベストプラクティス

リアルなモーション

ユーザー期待とジェスチャーに合わせたアニメーションを設計。フィードバックは：

「簡潔で正確に」
軽量
気を散らさずに効果的に情報を伝える

頻度の考慮事項

頻繁な UI インタラクションをアニメーション化しない。 標準システム要素にはすでに微妙なアニメーションが含まれているため、カスタム要素は一般的な操作に不要なモーションを追加すべきではありません。

ユーザーコントロール

「ユーザーがモーションをキャンセルできるようにする」アニメーション完了を待つ強制なし、特に繰り返されるインタラクション。

// ✅ 即座のタップを許可、アニメーション上で機能を停止しない
Button("Next") {
    withAnimation(.easeOut(duration: 0.2)) {
        showNext = true
    }
}
// ユーザーは再度タップでき、アニメーション待機を強制されない

プラットフォーム固有のガイダンス

visionOS

周辺視界エッジでのモーションを避ける — 不快感を引き起こす
オブジェクト再配置時にはフェードを使用、目に見えるモーション以外
ステーショナリーフレームオブリファレンスを維持
持続的な振動を避ける（特に 0.2 Hz 周波数）
仮想世界回転を防止（安定性を乱す）

watchOS

SwiftUI はアニメーション機能を提供；WatchKit はレイアウトアニメーションと序列用に WKInterfaceImage を提供します。

アイコンとシンボル

SF Symbols

利点:

5,000+ シンボルシステムに含まれる（SF Symbols 5）
San Francisco フォント視覚特性に一致
テキスト内にタイプできる
埋め込まれたベースライン値で正確な垂直配置
小、中、大スケール変種
San Francisco フォントと一致する 9 つのウェイト
ベクトルベース — テキストサイズと Dynamic Type でスケール
Bold Text アクセシビリティ有効時により太字になる
自動ライト/ダーク適応

使用:

Label("Settings", systemImage: "gear")

Image(systemName: "star.fill")
    .font(.title) // テキストサイズでスケール

カスタムインターフェースアイコン

キー設計原則:

単純化と認識: 混同を避けるために「認識可能な、高度に単純化された設計」を作成します。アイコンはアクションまたはコンテンツに直接接続された親しみやすい視覚的なメタファーで最適に機能します。

視覚的一貫性: 統一を維持：

サイズ
詳細レベル
ストロークの厚さ
すべてのインターフェースアイコン間の透視図法

ウェイトマッチング: 意図的に 1 つの要素を強調しない限り、隣接するテキストとインターフェースアイコンウェイトを揃えます。

光学的配置: 非対称アイコンは光学的センタリング（幾何学的センタリングでなく）のためにパディング調整が必要な場合があります。特に視覚的重量が 1 つのエリアに集中する場合。

形式と実装

ベクター形式が必須: カスタムインターフェースアイコン用にPDF または SVGを使用し、表示解像度全体で自動スケーリングを可能にします。PNG は各アイコンに複数バージョンが必要です。

選択状態: システムコンポーネント（ツールバー、タブバー、ボタン）は選択された外観を自動的に処理します。カスタムバージョンは必要ありません。

アイコン対テキストを使用する時

WWDC25 より: 「ペンシルは注釈付けを提案でき、チェックマークは確認のように見えます。Select や Edit などのアクションは誤解しやすくなります。明確なショートハンドがない場合、テキストラベルは常により良い選択です。」

アイコンを使用:

シンボルが明確で普遍的な意味を持つ（共有、削除、設定）
スペースが制約
アイコンがクイックスキャンを援助

テキストを使用:

アクションに明確なシンボルがない
複数の類似アクション存在
明確さがスペースより重要

アクセシビリティ

常に代替テキストラベルを提供 VoiceOver 説明を有効にする：

Image(systemName: "star.fill")
    .accessibilityLabel("Favorite")

ジェスチャーと入力

コアジェスチャー設計原則

一貫性と親しみやすさ: 「ユーザーは現在のコンテキストに関係なく、ほとんどのジェスチャーが同じように機能することを予期します。」タップ、スワイプ、ドラッグなどの標準ジェスチャーはプラットフォーム全体で期待通りに実行されるべき。

応答性フィードバック: 「ジェスチャーにできるだけ応答性を持たせる」ジェスチャーパフォーマンス中にフィードバック提供してユーザーが結果を予測できる。

標準ジェスチャー

すべてのプラットフォーム全体でサポートされる基本ジェスチャー（正確な動きはデバイスによって異なります）:

タップ
スワイプ
ドラッグ
ピンチ
回転（iOS/iPadOS）
Long press

タッチターゲット要件

最小タッチターゲットサイズ:

プラットフォーム	最小サイズ	スペーシング
iOS/iPadOS	44x44 ポイント	12～24pt パディング
macOS	コントロールによる	システムスペーシング
watchOS	システムコントロール	小スクリーン最適化
tvOS	大（フォーカスモデル）	60pt 以上スペーシング

// ✅ 適切なタッチターゲット
Button("Tap") { }
    .frame(minWidth: 44, minHeight: 44)

// ❌ 小さすぎる
Button("Tap") { }
    .frame(width: 20, height: 20) // アクセシビリティ失敗

カスタムジェスチャーガイドライン

カスタムジェスチャーは必要な場合のみ実装され、以下でなければならない：

発見可能 — ユーザーが見つけることができる
実行が簡単 — 実行が容易
他のジェスチャーと異なる — 競合なし
唯一の方法でない — 重要なアクション用の代替案を提供

警告: 標準ジェスチャーをカスタムで置き換えないこと。ショートカットは親しみやすいインタラクション、置き換え不可に補足すべきです。

アクセシビリティ

重大: 「アプリとインタラクトする複数の方法をユーザーに提供してください。」ユーザーが特定のジェスチャーを実行できることを前提としない。

代替案を提供:

Voice control
キーボードナビゲーション
ジェスチャーへのボタン代替案

// ✅ スワイプアクション + ボタン代替案
.swipeActions {
    Button("Delete", role: .destructive) {
        delete()
    }
}
.contextMenu {
    Button("Delete", role: .destructive) {
        delete()
    }
}

ローンチとオンボーディング

ローンチスクリーン

必須: iOS、iPadOS、tvOS 不要: macOS、axiom-visionOS、watchOS

設計原則: 「アプリまたはゲームの最初のスクリーンとほぼ同一のローンチスクリーンを設計する」視覚的な遷移の不快感を避ける。

ベストプラクティス

ブランディング最小化:

ロゴを避ける
スプラッシュスクリーンなし
芸術的なフラッシュなし
目的: 起動の知覚速度を向上、ブランド紹介ではない

テキストなし:

ローンチスクリーンコンテンツはローカライズできない
完全にテキストを避ける

外観に一致:

デバイス向きを尊重
ライト/ダークモードに適応

// ローンチスクリーンは最初のスクリーンに一致
// フラッシュなく滑らかに遷移

オンボーディング

オンボーディングはローンチフェーズの後の別の体験です。新規ユーザーに「アプリまたはゲームの高レベルビュー」を提供し、必要に応じてスプラッシュスクリーンを含めることができます。

使用時: 新規ユーザーに伝える有意な文脈がある場合のみ。

オンボーディングに含める:

ブランディングとスプラッシュスクリーン
教育コンテンツ
許可リクエスト
アカウント設定

タイムライン:

ローンチ — システムはローンチスクリーン表示、最初のスクリーンに遷移
オンボーディング（オプション） — ブランディングと教育を含める
継続使用 — 「アプリが再起動時に前の状態を復元して、ユーザーが前回のポイントから続行できるようにする」

プラットフォーム固有のガイダンス

iOS

デバイス特性:

中程度サイズの高解像度ディスプレイ
片手または両手インタラクション
ポートレート/ランドスケープ切り替え
視聴距離: 1～2 フィート

入力方法:

マルチタッチジェスチャー
仮想キーボード
Voice control
ジャイロスコープ/加速度計
空間インタラクション

設計パターン:

戻るナビゲーション用スワイプ
リストアクション中央または下部エリアに配置
複数同時アプリ
頻繁なアプリ切り替え

コンテンツ階層:

「画面上のコントロール数を制限しながら、最小限のインタラクションで二次詳細とアクションを発見可能にします」

システム統合:

ウィジェット
ホームスクリーンクイックアクション
Spotlight 検索
ショートカット
Activity views

iPadOS

iOS を拡張:

より大きいディスプレイ（同時により多くコンテンツ）
サイドバー適応レイアウト
Split view マルチタスキング
ポインタ/トラックパッドサポート
任意のウィンドウサイズ変更（iOS 26+）
メニューバー（トップからスワイプ）

設計考慮:

iOS レイアウトを単純にスケールしない
サイドバーをナビゲーション活用
Split view サポート
ポインタインタラクション最適化

macOS

特性:

大きく高解像度なディスプレイ
ポインター優先インタラクション
キーボード中心のワークフロー
複数ウィンドウ
メニューバーでコマンド

設計パターン:

密集したレイアウト受け入れ可能
より小さいコントロール（iOS 対）
ウィンドウクロムとコントロール
コンテキストメニュー期待
キーボードショートカット必須

コントロールサイズ:

ミニ、小、中 → 角丸矩形
大、特大 → カプセル（iOS 26+）

watchOS

制約:

非常に小さいディスプレイ
グランス可能なインターフェース
最小インタラクション時間
Always-on 考慮

設計原則:

フルブリードコンテンツ
最小パディング
Digital Crown インタラクション
ウォッチフェース用コンプリケーション

tvOS

特性:

大きいディスプレイ
10 フィート視聴距離
フォーカスベースナビゲーション
ジェスチャーリモコン

設計要件:

大きいタッチターゲット
フォーカス状態明確で目立つ
限定テキスト入力
空間ナビゲーション（上/下/左/右）

visionOS

ユニークな側面:

空間コンピューティング
グラスマテリアル
3D レイアウト
奥行きとレイヤリング

設計原則:

快適な視聴深度
ヘッド固定コンテンツ避ける
視野中心に重要コンテンツを中央配置
深さを意図的に大規模で重要な要素に使用

インクルーシブデザイン

言語とコミュニケーション

ようこそ言語要件:

平易で直接的で尊重のあるトーンを使用
教育レベルに基づいて排他性を示唆しない
「ユーザー」ではなく「あなた/あなたの」で直接対応
必要時に専門用語を定義
文化固有の表現を平易な代替案で置き換える

抑圧起源の句を避ける（例：「peanut gallery」）。

ユーモアで注意を行使 — 主観的で、文化全体でのローカライズが困難。

ビジュアル表現

人的多様性の描写:

人々を特徴づけ、人種背景、体型、年齢、身体能力の範囲を示す
職業と行動でのステレオタイプ表現を避ける

仮定を避ける:

狭い家族構造の定義を仮定しない
普遍的体験を仮定しない
文化固有のセキュリティ質問をより普遍的な体験で置き換える

ジェンダーアイデンティティと代名詞

ベストプラクティス:

コピーで不要なジェンダー参照を避ける
インクルーシブオプション提供：「nonbinary」、「self-identify」、「decline to state」
ジェンダー中立なイメージ使用
アバターとキャラクターのカスタマイズ許可

アクセシビリティと障害

認識:

障害はスペクトラムに存在
一時的/状況的障害はみんなに影響

含める:

障害者多様性表現
人を最優先のアプローチ採用（「disabled person」ではなく「person with disability」）

ローカライゼーションとグローバル考慮

以下用にソフトウェアを準備:

インターナショナライゼーション
複数言語への翻訳

文化的カラー認識:

カラーは文化固有の意味を運ぶ
白は一部の文化で死を、他では純潔を表す
赤は一部の文化で危険を示し、他では積極的な意味

平易言語を使用スムーズなローカライゼーション促進。

ブランディング

コア原則

声と声色: 書かれたコミュニケーションを通じて一貫したブランドパーソナリティを維持。

ビジュアル要素:

UI コンポーネントのアクセントカラー考慮
ブランドと強く関連する場合はカスタムフォント（ただしボディコピーにはシステムフォントがより良い可読性）

キー自制力ガイドライン

最も重大なガイダンス — 自制:

コンテンツに譲歩: 「ブランドアセットを表示するだけの要素にスクリーンスペースを使用することは、ユーザーが気にするコンテンツのスペースが少なくなることを意味できます。」

ロゴ最小化: 「アプリまたはゲーム全体でロゴ表示の誘惑に抵抗してください（コンテキスト提供が不可欠でない限り）。」

親しみやすいパターン: スタイル付き設計でさえ標準 UI の動作とコンポーネント配置を維持して、インターフェースをアプローチ可能に保つ。

ローンチスクリーン注意: ローンチスクリーンはすぐに消えるため、ブランディングに使用しないでください；代わりにオンボーディングスクリーンでブランド統合を検討。

適切なブランディング

する:

アプリティントカラーとしてブランドのアクセントカラーを使用
オンボーディング（ローンチスクリーンでない）にブランディングを含める
コピーにブランド声を使用
コンテンツでブランドを特徴づけ、クロムでない

しない:

ナビゲーションバーにロゴを表示
ブランドカラーでシステム背景をオーバーライド
スプラッシュスクリーン追加
ブランディングがコンテンツと競合

法的考慮

Apple トレードマークはアプリ名またはイメージに表示されません。Apple の公式トレードマークガイドラインを参照。

よくある HIG 問題のトラブルシューティング

カラーコントラスト失敗

症状: App Store アクセシビリティ違反拒否、またはカラーが WCAG 標準を満たさない。

診断:

Xcode Accessibility Inspector でテスト
オンラインコントラスト計算機を使用
ライト/ダークモード両方でチェック
Increase Contrast 有効でテスト

ソリューション:

// ❌ 問題：カスタムグレーはコントラスト失敗
Text("Label").foregroundStyle(.gray) // 4.5:1 要件失敗する可能性

// ✅ ソリューション 1：セマンティックカラーを使用（自動準拠）
Text("Label").foregroundStyle(.secondary)

// ✅ ソリューション 2：検証済みコントラストのより暗いカスタムカラーを使用
Text("Label").foregroundStyle(Color(red: 0.25, green: 0.25, blue: 0.25))
// 白背景で ~8:1 コントラスト達成（WCAG AAA）

タッチターゲットが小さすぎる

症状: ユーザーがタップ困難を報告、App Store アクセシビリティ拒否。

診断:

// ボタンサイズをチェック
Button("Tap") { }
    .frame(width: 30, height: 30) // ❌ 小さすぎる

ソリューション:

// ✅ タッチターゲットを最小 44x44 に拡張
Button("Tap") { }
    .frame(minWidth: 44, minHeight: 44)

// ✅ 代替案：パディング追加
Button("Tap") { }
    .padding() // システムが適切なパディングを追加

ダークモード問題

症状: ダークモードで色が間違って見える、不十分なコントラスト。

診断:

ハードコードされた両方の外観モードに適応しないカラー
暗いバリエーションのないカスタムカラー
両方の外観モードでテストしない

ソリューション:

// ❌ 問題：ハードコード白テキスト
Text("Label").foregroundStyle(.white)
// ライトモードでは見えない

// ✅ ソリューション：セマンティックカラー
Text("Label").foregroundStyle(.primary)
// ライトではブラック、ダークではホワイト

// ✅ 代替案：アセットカタログカラーのバリエーション
Text("Label").foregroundStyle(Color("BrandText"))
// Assets.xcassets でライト/ダークバリエーションを定義

軽いフォントウェイト可読性

症状: 特に小さいサイズまたは明るい照明でテキストが読みにくい。

診断:

Text("Headline")
    .font(.system(size: 17, weight: .ultralight)) // ❌ 軽すぎる

ソリューション:

// ✅ Regular 最小を使用
Text("Headline")
    .font(.system(size: 17, weight: .regular))

// ✅ より良い：システムテキストスタイルを使用
Text("Headline")
    .font(.headline) // 自動的に適切なウェイトを使用

Dynamic Type が動作しない

症状: ユーザーが設定でテキストサイズを増やしてもテキストがスケールしない。

診断:

// ❌ 固定サイズはスケールしない
Text("Label").font(.system(size: 17))

ソリューション:

// ✅ テキストスタイル使用で自動スケーリング
Text("Label").font(.body)

// ✅ カスタムフォントでスケーリング
Text("Label").font(.custom("CustomFont", size: 17, relativeTo: .body))

Reduce Motion が尊重されない

症状: モーション感度のあるユーザーが不快感を体験。

診断:

アニメーションは設定に関係なく常に再生
モーション感度のあるユーザーへの代替なし

ソリューション:

// ✅ Reduce Motion 設定をチェック
@Environment(\.accessibilityReduceMotion) var reduceMotion

var body: some View {
    content
        .animation(reduceMotion ? nil : .spring(), value: isExpanded)
}

// ✅ 代替案：シンプルなアニメーション
.animation(reduceMotion ? .linear(duration: 0.1) : .spring(), value: isExpanded)

VoiceOver ラベルがない

症状: VoiceOver がアクションではなく「Button」のような役に立たない情報を発表。

診断:

// ❌ ラベルなし画像ボタン
Button {
    share()
} label: {
    Image(systemName: "square.and.arrow.up")
}
// VoiceOver は言う：「Button」

ソリューション:

// ✅ アクセシビリティラベルを追加
Button {
    share()
} label: {
    Image(systemName:

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者: majiayu000
リポジトリ: majiayu000/claude-skill-registry
ライセンス: MIT
最終更新: 2026/5/4

GitHubで原本を見る →フィードバックを送る

Source: https://github.com/majiayu000/claude-skill-registry / ライセンス: MIT

SKILL.md 本文

Apple Human Interface Guidelines — 包括的リファレンス

概要

3 つのコア原則

設計システムの哲学

関連スキル

カラーシステム

セマンティックカラーの説明

ラベルカラー（フォアグラウンドコンテンツ）

背景カラー（プライマリ→ターシャリ）

グループ化されていない背景

グループ化された背景

ベースと昇格した背景

ティントカラー（ダイナミック適応）

フィルカラー（半透明）

区切りカラー

恒久的な暗い背景を使用する場合

カスタムカラーの作成

タイポグラフィ

システムフォント

フォントウェイトの推奨事項

階層用テキストスタイル

Dynamic Type サポート

カスタムフォント

Leading（行間隔）

形状と幾何学

3 つの形状タイプ（iOS 26）

1. 固定形状

2. カプセル

3. 同心形状

同心性の原則

プラットフォーム固有のガイダンス

光学センタリング

マテリアルと奥行き

標準マテリアル

4 つの厚さオプション

ビブランシーを使用したマテリアル

Liquid Glass（iOS 26+）

レイアウト原則

ビジュアルハイアラーキー

グループ化と整理

コンテンツを端まで拡張

セーフエリアとレイアウトガイド

コンポーネントを揃える

適応性要件

アクセシビリティ

ビジョンアクセシビリティ

テキストと可読性

カラーコントラスト

カラーの考慮事項

スクリーンリーダー

聴覚アクセシビリティ

メディア代替案

オーディオキュー

モビリティアクセシビリティ

認知アクセシビリティ

インタラクション設計

モーションと視覚効果

ゲーム対応

visionOS 固有

モーションとアニメーション

コア原則

アクセシビリティ最優先

フィードバックのベストプラクティス

リアルなモーション

頻度の考慮事項

ユーザーコントロール

プラットフォーム固有のガイダンス

visionOS

watchOS

アイコンとシンボル

SF Symbols

カスタムインターフェースアイコン

形式と実装

アイコン対テキストを使用する時

アクセシビリティ

ジェスチャーと入力

コアジェスチャー設計原則

標準ジェスチャー

タッチターゲット要件