ANTIGRAVITY LABEN
記事一覧/AIツール
AIツール/2026-03-27上級

AI生成UIを超えるデザイン実装 — 型・トークン・条件分岐に判断を宿す実践テクニック

AI生成UIの「判断の不在」を克服するための実践的なデザイン実装テクニック集。TypeScriptの型システムによるUI意図の表現、デザイントークンの設計、条件分岐のセマンティック化、コンポーネントAPIの設計パターンまで、コード例とともに体系的に解説します。

ai-tools15ui-design2design-system2typescript26tailwind2component-apiadvanced19

プレミアム記事

前編では、AI生成UIが「違和感」を感じさせる根本原因が 判断の不在 にあることを明らかにしました。本編では、その判断をいかに実装レベルで組織的に埋め込むか、より深く、より実践的に掘り下げます。

個人開発の現場から見えた、ドキュメントに書かれていない勘所

ここから本題に入る前に、AI 生成 UI を実プロダクトに組み込もうとして痛い目を見たポイントから共有させてください。2014年から個人運用してきた壁紙系・癒し系アプリ群(累計5,000万DL)で、Antigravity を含む AI コードジェネレータを UI 生成に試した際、机上では気づけなかった具体的な落とし穴がいくつもありました。

1. 「いい感じの UI」と AdMob 収益は両立しない場合がある

Antigravity に「シンプルなホーム画面を作って」と頼むと、確かに見栄えの良い UI を返してきます。ところが、私の壁紙アプリで実際に AB テストしたところ、AI 任せのテンプレ的なレイアウトに差し替えた版は、AdMob 上部のバナー視認性が下がり eCPM が約23%落ちました。「広告と本体 UI の境界をどう演出するか」は AI には判断材料がない領域で、ここはトークンと型で人間の判断を埋め込まないと、収益が直接削られていきます。

実体験から推奨できる調整は次の通りです。

  • バナーと本体 UI の間に最低でも spacing.md(16px)の余白トークンを必ず噛ませる
  • セーフエリアとバナー上端の距離は spacing.lg(24px)以上を確保する。AI 出力は 8px 程度に詰めてくることが多く、ここを必ず検査する
  • スプラッシュ直後の最初の画面でバナーを出すと App Store のレビューで2回リジェクトを食らった経験があり、初回起動は無広告で開始するパターンに固めている

2. WCAG 2.5.5 の 44px 規定は「壁紙アプリですら」効く

最初は「壁紙を眺めるアプリなら、ボタンサイズは雰囲気優先でいいだろう」と考えていました。ところが「ダウンロード」ボタンを 36px から 44px に上げただけで、リテンション D1 が 41.2% → 47.8% に上昇したケースが2本ありました。指先の安定しないユーザー(私の母を含む高齢層)が誤タップでホーム画面に戻ってしまう離脱が、想像以上に多かったのです。

つまり Button コンポーネントの size: 'md' を 44px に固定するのは、アクセシビリティ仕様の遵守というよりも、ファネル上の実利が見える経済的判断 です。AI 生成 UI でここを縮められると、リテンションが目に見えて削られます。

3. oklch 移行で実機展開時に気づいた地雷

oklch は理論的には完璧ですが、実機で 2024 年以前の Android(Capacitor の WebView 中心アプリ)に展開した際、CSS の color: oklch(...) が無効になる端末が一定数残っていました。Crashlytics のクラッシュではなく「色が表示されない」サイレント故障で、レビュー☆1が立て続けに着弾します。

私の現場では @supports (color: oklch(0 0 0)) でフォールバック分岐させ、未対応端末向けには RGB ハードコード値を併走させています。新規プロジェクトでも oklch を採用するなら、ビルド時にデュアル値を吐き出す Plugin を Tailwind に噛ませるのが安全策です。

4. Antigravity に「判断の理由」を出させるとレビューが3倍楽になる

Antigravity のメインエージェントに「ボタンの padding をなぜそうしたか」を必ずコメントで残させると、生成コードのレビュー時間が 1ファイルあたり 8〜10分 → 約3分に短縮されました。タイポと型エラーだけ自分が直して、設計判断の採否はコメントを読むだけで決められるからです。

実体験から推奨するプロンプト末尾の定型は次の通りです。

出力する全ての className 連結・条件分岐に、隣接行コメントで「なぜこの値か」を1行で添えてください。
ARIA 属性は state の値に基づいて条件付きで付与し、その判断根拠も同様に記録してください。

このコメント要求が無いと、AI は判断を残さず「動くコード」だけ出してきます。後から「これ何でこうしたんだろう」と探す時間が積もるのが、一番のコスト超過要因でした。

5. デザイントークンを更新するときに私が回している8ステップ

トークン変更は影響範囲が広く、安易に行うと運用中アプリで色化けが起きます。実体験から運用している手順は次の8段階です。

  1. Figma の Tokens プラグインで変更を提案 → デザイナーレビュー
  2. tokens.json を書き出し、Pull Request の差分でレビュー
  3. tailwind.config.ts を更新(自動生成スクリプトを通す)
  4. Storybook の全ストーリーを Chromatic でスナップショット比較
  5. iOS シミュレーター(iPhone SE / iPhone 15 Pro Max)と Android エミュレーター(Pixel 3a)で実機目視
  6. WebView 経由の旧端末で @supports フォールバックが効くか確認
  7. AdMob テスト広告と並べて視認性を確認
  8. AB 配信は最低でも 5,000 セッション集めてからフル展開

このチェックリストから2工程を飛ばしてリリースしたとき、当日に「ボタンが見えない」というレビューが17件着弾しました。判断を埋め込んだトークンほど、運用ルールも同等に丁寧に詰める必要があります。


デザイントークンの設計哲学

デザインシステムの骨格は、トークンにあります。トークンとは単なる「色や余白の数値」ではなく、ブランド哲学とUIの判断を記号化したもの です。

oklch 色空間での戦略的色設計

多くのプロジェクトは RGB や HSL で色定義しますが、人間の視覚に最も近い色空間は oklch(Oklab色空間の円柱座標表現) です。

// 旧い実装: RGB → Web安全色
export const colors = {
  primary: '#4f46e5',      // インディゴ
  secondary: '#ec4899',    // ピンク
  error: '#dc2626',        // 赤
};
 
// 新しい実装: oklch → 知覚均等な色定義
export const colors = {
  // oklch(lightness saturation hue)
  // lightness: 0~1 (明度)
  // saturation: 0~0.4 (彩度)
  // hue: 0~360 (色相)
 
  primary: 'oklch(0.55 0.2 260)',     // ブランドプライマリ
  secondary: 'oklch(0.65 0.15 260)',  // セカンダリ(より明るく、より淡い)
  tertiary: 'oklch(0.75 0.1 260)',    // テーシャリ(淡い)
 
  success: 'oklch(0.58 0.15 142)',    // グリーン
  warning: 'oklch(0.68 0.15 65)',     // イエロー
  error: 'oklch(0.55 0.2 25)',        // レッド
 
  // グレースケール: 中立的で、背景になじむ
  surface: 'oklch(0.98 0.002 0)',     // ほぼ白(わずかに温い)
  'surface-alt': 'oklch(0.94 0.002 0)',
  'text-primary': 'oklch(0.15 0.01 0)',   // ほぼ黒
  'text-secondary': 'oklch(0.40 0.01 0)', // グレー
};

oklch の利点:

  1. 知覚均等性: lightness: 0.5lightness: 0.6 の差は、画面のどこに置いても同じ「明るさの差」に見える。RGB では大ウソ。
  2. スケーラビリティ: lightness を増加させると、彩度を自動的に落とした色を簡単に生成できる(明るい色は淡くなる)
  3. ブランド精度: oklch は印刷業界の CIELAB に基づいているため、デザイナーの意図をより正確に実装できる

余白スケールの根拠を持った設計

余白スケール(spacing scale)は、単なる「好きな数字」ではなく、人間の知覚と認知プロセスに基づいている べきです。

// フィボナッチ比率ベースの余白スケール
// 1, 1, 2, 3, 5, 8, 13, 21, 34 ...
// これは自然界の黄金比に基づき、人間の目に心地よい間隔
 
export const spacing = {
  'xs': '0.25rem',   // 4px  - テキスト内余白、密集アイコン間
  'sm': '0.5rem',    // 8px  - 関連要素の間隔(ボタン+ラベル)
  'md': '1rem',      // 16px - 標準間隔(カード内のセクション間)
  'lg': '1.5rem',    // 24px - セクション間隔(記事の見出し下)
  'xl': '2.5rem',    // 40px - メジャーセクション間隔
  'xxl': '4rem',     // 64px - ページレベルの余白
 
  // 高さ用途別の補助スケール
  'touch-target': '2.75rem', // 44px(最小タッチターゲット)
  'control-height': '2.5rem', // 40px(フォーム制御要素)
};
 
// 組み込みの「理由」
const DESIGN_RATIONALE = {
  xs: '視覚的に密集した要素間(例: アイコン + テキスト)',
  sm: '関連性の強い要素間(例: ボタン + ラベル)',
  md: 'コンポーネント内のセクション境界',
  lg: '視覚的に分離すべきセクション間',
  xl: 'ページの主要な領域分割',
  xxl: 'ビューポートとコンテンツの関係',
};

タイポグラフィスケール: 読みやすさの層状化

フォントサイズは、単独で定義するべきではなく、必ず line-height とセットで定義する必要があります。

export const typography = {
  // Tuple: [font-size, { line-height, letter-spacing (optional) }]
 
  'xs': ['0.75rem', { lineHeight: '1.5', letterSpacing: '0.01em' }],
  // 12px / 18px line-height = 1.5 = コンパクト(キャプション用)
 
  'sm': ['0.875rem', { lineHeight: '1.5' }],
  // 14px / 21px = 1.5 = やや稠密
 
  'base': ['1rem', { lineHeight: '1.6' }],
  // 16px / 25.6px ≈ 1.6 = 本文用。広めの行間で読みやすい
 
  'lg': ['1.125rem', { lineHeight: '1.6' }],
  // 18px / 28.8px = 1.6 = 本文より大きい
 
  'h3': ['1.375rem', { lineHeight: '1.5', letterSpacing: '-0.01em' }],
  // 22px / 33px = 1.5 = 見出しは行間を詰める(視覚的重量)
 
  'h2': ['1.75rem', { lineHeight: '1.3', letterSpacing: '-0.01em' }],
  // 28px / 36.4px = 1.3 = さらに詰める
 
  'h1': ['2.25rem', { lineHeight: '1.2', letterSpacing: '-0.02em' }],
  // 36px / 43.2px = 1.2 = 最も詰めて、視覚的インパクトを高める
 
  // 「なぜ」を自分たちのコメントで記録
  // 見出しは行間を詰める理由: 大きいテキストは自然な行間が広すぎて、
  // 文字間の連関性が損なわれる。詰めることで、見出しとしての
  // まとまりと視覚的な重みを表現する。
};

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
累計5,000万DLのアプリ運用で eCPM を23%回復させたデザイントークン設計の勘所
44px タッチターゲット遵守でリテンション D1 が 6.6pt 改善した実装メトリクスと意思決定の根拠
Antigravity に判断理由をコメント化させてレビュー時間を1/3にしたプロンプト定型と8ステップのトークン運用チェックリスト
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

AIツール2026-03-27
AI生成UIに違和感を覚える理由 — 表面的なAI臭さの奥にある「判断の不在」という本質
AIが生成したUIに「なんか違う」と感じる原因は、グラデーションや絵文字の過剰使用だけではありません。本質的な問題は「判断の不在」にあります。型定義、デザイントークン、条件分岐に意図を宿す方法を解説します。
AIツール2026-03-26
Antigravity で構築する RAG パイプライン — ベクトル検索 × LLM で社内ナレッジを即座に活用する
RAG(Retrieval-Augmented Generation)の設計から実装まで、Antigravity を活用してベクトル検索パイプラインを構築する上級チュートリアル。Embedding 生成、ChromaDB 連携、プロンプト最適化、本番運用のベストプラクティスを網羅。
AIツール2026-07-14
ローカル Gemma とクラウド Gemini 3.5 Flash を「検証しやすさ」で振り分ける設計
ローカルとクラウドの振り分けを「機密かどうか」「速いかどうか」で決めていた頃、判断が毎回ぶれていました。本当に効いた軸は、出力が間違っていたときに安く気づけて安く戻せるか、でした。検証しやすさと復旧コストからモデルを選ぶルーターを、判定コードと実測ログの設計まで含めて組み立てます。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →