皆さんは、Figmaで作り込んだ完璧なデザインデータが、実装時にエンジニアから「OSの制約でそれは無理ですね」と言われて悔しい思いをした経験はありませんか？
あるいは、「自分自身でアプリを作ってみたい（個人開発したい）けれど、技術がありすぎて何から勉強すればいいか分からない」というモヤモヤを抱えていませんか？

2026年のアプリ開発において、フレームワーク（実装技術）の選択は、UIの再現性とユーザー体験にいかに直結するのでしょうか。
今回は、UIデザイナーの視点から「そもそもクロスプラットフォームかネイティブか」という根本的な比較から、「個人開発で学ぶならどっちが良いか」まで、私たちのデザインの可能性を広げる技術トレンドとの向き合い方についてお話しします。

1. 根本的な比較：クロスプラットフォーム vs ネイティブ

プロジェクトが立ち上がった際、まず議論になるのが「クロスプラットフォームで作るか、ネイティブで作るか」という選択です。UIデザイナーとしても、この違いを理解しておくことは非常に重要です。

ネイティブフレームワーク（SwiftUI / Jetpack Compose）

AppleやGoogleが公式に提供する言語・ツールを使って、iOSとAndroidそれぞれ別々にアプリを開発するアプローチです。

• メリット：OSの最新機能をいち早く取り入れられます。また、デバイスの性能を極限まで引き出せるため、アニメーションの滑らかさなどパフォーマンス面で妥協がありません。
• デメリット：iOS用とAndroid用で2つのコードベースを保守する必要があるため、開発コストと期間が単純に2倍近くかかります。両OSで「全く同じ見た目・動き」を維持するためのデザイン管理コストも跳ね上がります。

クロスプラットフォームフレームワーク

1つのコードベース（共通の言語）でコードを書き、それをiOSとAndroid両方のアプリとして出力するアプローチです。

• メリット: 1つのコードで両OSに対応できるため、開発スピードが圧倒的に早く、コストも抑えられます。デザインシステムを1つのコードベースで管理できるため、iOSとAndroidで統一されたブランド体験（見た目）を提供しやすいのが最大の特徴です。
• デメリット: デバイス固有の極めて高度な機能や、超低遅延が求められるグラフィック処理には不向きな場合があります。

2. デザイナー視点で考える「ケース別」最適な選択

では、実際のプロジェクトにおいて私たちはどちらの技術を選択すべきなのでしょうか。
UI/UXの観点から、それぞれの強みが活きるケースを整理してみましょう。

ネイティブを選ぶべきケース：OSに深く根ざした「極限の心地よさ」を追求するとき

UIデザイナーがこだわる極限まで入力遅延（Input Latency）の少ない操作応答性や、触覚フィードバックを伴う複雑なマイクロインタラクションを実装する際には、ネイティブの力が遺憾なく発揮されます。
また、iOSなら「HIG」、Androidなら「Material Design」を厳格に踏襲することも強力な選択肢になります。各OSのユーザーが最も使い慣れている標準的なUIやナビゲーションを提供したい場合、ネイティブフレームワークを採用することで自然で学習コストの低い体験を構築しやすくなります。

クロスプラットフォームを選ぶべきケース：ブランド体験の統一と高速なイテレーション

一方で、ニュースアプリ、SNS、SaaSのモバイル版など、情報設計や一貫したブランド体験が重視されるアプリでは、クロスプラットフォームが圧倒的に有利です。
iOSとAndroidで「ブランドとして同一のルック＆フィール」を提供したい場合、最適解となります。また、新規事業のMVP（Minimum Viable Product）としていち早く市場にプロダクトを出し、ユーザーのフィードバックを得ながら高速で改善を回していくアジャイルな現場にも非常に適しています。

3. クロスプラットフォームならどっち？FlutterとReact Nativeの徹底比較

現在の二大巨頭であるFlutterとReact Native。エンジニアから「どっちが良いと思う？」と意見を求められた際、デザイン視点での違いを理解しておくことが重要です。

Flutter（Google提供）の特徴

独自の描画エンジン（Impeller等）を持っており、キャンバスに直接絵を描くようにUIをレンダリングします。

• メリット：OSのネイティブコンポーネントに依存しないため、Figmaで組んだデザインが「完全にピクセルパーフェクト」に近い形で再現されます。デザインレビュー時の「実装ズレ」の手戻りが劇的に短縮されます。
• デフォルトはMaterial Designベース：Google製であるため、標準コンポーネントはMaterial Designの思想が色濃く反映されています。1つのコードベースの強みを活かすため、「Materialベースで両OSを共通化する」か「完全に独自のブランドUIを作る」かのどちらかを前提にデザインを組むのが実務ではスムーズです。

React Native（Meta提供）の特徴

Web開発で広く使われているReactの仕組みを用いて、アプリのUIをOSのネイティブコンポーネントに変換して表示します（最新のNew Architectureによりパフォーマンスも劇的に向上しています）。

• メリット：Webフロントエンドの組織では学習コストが極めて低く、Web向けに構築されたデザイントークンなどをアプリ開発にもスムーズに展開しやすいという大きな強みがあります。
• デメリット：最終的にOS標準のコンポーネントに変換されるため、ボタンの余白やフォントのベースラインにおいて、iOSとAndroid間で微細な「見た目のズレ」が生じやすくなります。

UIデザイナーが「個人開発」で勉強するならどっち？

実務のUIデザイナーが「自分でもアプリを作ってみたい！」と勉強を始める場合、個人的なおすすめはFlutterです。
FlutterはUIを「Widget（ウィジェット）」というブロックの組み合わせで構築するため、Figmaのオートレイアウトやコンポーネントの概念と非常に似ており、デザイナーにとって直感的に理解しやすいのが特徴です。また、後述するFlutterFlowを使えば、ノーコードから自然とDart言語の学習へとステップアップしていくことができます。
一方、過去にHTML/CSS/JavaScriptを少し触ったことがある方や、Webフロントエンドにも興味がある方の場合は、React Nativeから入るのも非常に有力な選択肢となります。

4. フレームワーク別：開発連携に向けたFigmaデータ作りのポイント

実装ズレを防ぐため、UIデザイナーはそれぞれの特性に合わせた「Figmaデータの作り方（ハンドオフの準備）」を意識する必要があります。

ネイティブ開発（SwiftUI / Jetpack Compose）の場合

• OSごとのUI出し分けとすり合わせ：iOSの「HIG」やAndroidの「Material Design」に基づき、どこまで共通化し、どこからOS専用のUIを作るか、Figma上で明確に切り分けてエンジニアと合意をとります。
• ダイナミックタイプ（文字サイズ可変）の考慮：ユーザーが端末設定で文字サイズを大きくした場合でもレイアウトが破綻しないよう、オートレイアウトの「折り返し（Wrap）」などを活用します。

Flutterの場合

• 状態（State）の徹底的な定義：OS標準の動きに頼れないため、ボタンのHover/Pressed/Disabled状態から、タップ時の波紋まで、コンポーネントのあらゆる状態をFigmaのバリアンツ（Variants）で漏れなく定義しきる必要があります。
• Widget構造を意識したオートレイアウト：Figmaのオートレイアウト（Frameの階層）をそのまま実装のネスト構造としてエンジニアが見るため、不要なFrameを排除して整理します。

React Nativeの場合

• Web版デザインシステムとの共通化：デザイントークン（色や余白の命名規則）をWeb版のFigmaデータと完全に一致させ、エンジニアがReactの資産を流用しやすい状態を作ります。
• ピクセルパーフェクトからの脱却：最終的にOS標準のUIへ変換されるため、「1pxのズレも許さない」のではなく、OS間の微細な差異を許容する柔軟なデザインルールを敷くことが重要です。

5. AIネイティブ時代における高度な実装連携とローコードの波

「AIがFigmaからコードを全自動生成する時代に、UIデザイナーの仕事は奪われるのでは？」と不安に思う方もいるかもしれません。しかし現実は逆です。

日々の実装連携において、AIの高度な活用が進んでいます。最近の実務では、Figmaと最新のLLMを連携させ、「エンジニアへ引き渡す前に、ボタンの無効化状態やエラー表示の考慮漏れがないかをAIに自動チェックさせる」といった使い方が広まっています。
これによりヒューマンエラーが減少し、デザイナーとエンジニアがより建設的な「体験の質」の議論に時間を使えるようになりました。

また、Flutterのコードを出力できる「FlutterFlow」等の進化により、個人開発やMVPであればデザイナー自身が数日で「実際に動くアプリ」を作って検証できるようになっています。だからこそ、AIに的確な指示を出し、出力されたコードの構造を理解するためにも、UIデザイナー自身がフレームワークの特性を深く知ることが武器になるのです。

終わりに

最後までお読みいただき、ありがとうございます！

UIデザイナーにとって、開発言語やフレームワークは「エンジニアの領域」と一歩引いてしまいがちなテーマかもしれません。しかし、技術を知ることは決してデザインを妥協するためではなく、「デザインの可能性を最大限に引き出すための力」になります。

要件定義の段階で「このUIの動きならFlutterのほうが実装工数が下がるから、余った工数で機能をリッチにしよう」といった提案ができたり、個人開発で自分のアイデアを形にできたりと、技術を知ることでデザイナーとしてのキャリアは確実に広がります。

これからも、技術の進化を味方につけながら、日々のデザインの探求を一緒に楽しんでいきましょう。
それでは、良いデザインライフを！

The post デザイナーが知っておきたい！2026年モバイルアプリ開発フレームワークの現在地と選び方 first appeared on デザペディア.

日々のUI制作で画面に向き合っていると、「なんとなく良さそうな青色を選んでみた」「いまっぽい角丸の数値にしてみた」と、自分の直感や感覚だけに頼って決めてしまう場面はないでしょうか。
デザインの意図をチームやエンジニアに説明する際、「なぜここはこの余白なのか」「なぜこの色なのか」という根拠が曖昧だと、レビューでの合意形成に時間がかかったり、手戻りが発生する原因になりがちです。

そんな「デザイン決定の根拠」をロジカルに整理する上で大きな助けになるのが、Googleが策定・公開しているオープンソースのデザインシステム「Material Design 3（M3）」です。
M3は単なるコンポーネントのカタログではなく、人間の知覚に基づいた配色ロジックや、アクセシビリティを仕組みで担保するトークン設計など、実務で今すぐ活かせる実践知見が体系化されています。

今回は、Material Design 3の基本思想から、配色迷子をなくす「HCT理論」、実務で破綻しないカラートークンの階層設計、そしてFigmaでの具体的な活用フローまでを分かりやすく整理しました。

1. Material Design 3（M3）とは？通常ルールとの決定的な違い

Material Design 3 – Google's Open Source Design System

Googleが提供するオープンソースデザインシステム。個人の嗜好に適応するダイナミックカラーやHCTカラースペース、最新のUIコンポーネント仕様を網羅。

Material Design（マテリアルデザイン）は、GoogleがAndroidやWeb向けに展開してきたデザインシステムです。
従来のMaterial Design（M2）は、「紙とインク」の物理法則を画面上に模倣し、影（Elevation / Drop Shadow）の高さによって要素の階層関係を伝えるアプローチが中心でした。

それに対して最新のM3では、「ユーザー個人の好みや利用環境に合わせて、デザイン側が柔軟に変化する」という思想へと大きく舵を切っています。
均一で固定された1枚のデザインカンプを作るのではなく、ユーザーごとに心地よい形へと適応させる「システムの柔軟性」を設計するスタンスが根本にあります。

Form follows feeling（形態は感情に従う）

近代デザインの有名な原則に「形態は機能に従う（Form follows function）」がありますが、M3が掲げるテーマは「形態は感情に従う（Form follows feeling）」です。
使いやすさや機能性は大前提とした上で、使う人が愛着を感じられるパーソナルな体験を重視しています。

その代表例が「ダイナミックカラー（Dynamic Color）」です。
ユーザーがスマートフォンの壁紙を変更すると、壁紙から抽出されたキーカラーをもとに、OSやアプリ全体の配色パレットが自動生成され、調和のとれた色合いへとシームレスに変化します。

このアプローチは単なる思いつきではなく、数千人規模のユーザー調査と認知心理学の実験を経て導き出された設計です。
固定的なビジュアルを押し付けるのではなく、ユーザーのコンテキストに寄り添うUI設計の思想は、自社サービスをデザインする際にも大きな示唆を与えてくれます。

Apple HIG vs Google M3 の設計思想の対比

UIデザインの現場で双璧をなすのが、AppleのHIG（Human Interface Guidelines）とGoogleのM3です。
どちらが優れているかという話ではなく、両者が目指す哲学の違いを理解しておくと、プラットフォームごとの適切なUI判断が下しやすくなります。

両者の思想を把握しておくことで、iOSとAndroidのマルチプラットフォーム展開時にも、それぞれのユーザーのメンタルモデルに沿った自然なデザインの出し分けが可能になります。

2. 配色の迷子をなくす「HCTカラースペース」とコントラストの科学

UIデザイナーが最も多くの時間を費やし、かつ迷いやすいのが「配色」の決定です。
「綺麗に見えるけれど文字が読みにくい」「ダークモードにしたらコントラストが崩れてしまった」という問題は、従来のカラーモデルの仕組みそのものに原因がありました。

その課題を根本から解決するためにGoogleが開発したのが、M3の基盤となる「HCTカラースペース」です。

従来のRGBやHSLが抱えていた限界

Web制作で広く使われてきたRGBやHSLは、コンピュータの画面表示にとって都合の良い数値モデルです。
しかし、人間の目は色相（Hue）によって明るさの感じ方が大きく異なるという特性を持っています。

例えば、HSLで同じ明度（Lightness 50%）に設定した場合でも、人間には「黄色」が非常に明るく見え、「青色」は暗く見えます。
そのため、HSLの数値を揃えるだけではアクセシビリティ（WCAGのコントラスト比）を担保できず、デザイナーが画面を見ながら手作業で微調整を繰り返す必要がありました。

HCT（Hue / Chroma / Tone）の仕組み

HCTは、人間の知覚モデル（CAM16）を組み込むことで、この「見え方のズレ」を解消した新しい色空間です。

• Hue（色相 / 0〜360）: 色味そのもの（赤、青、緑など）
• Chroma（彩度 / 0〜無制限）: 色の鮮やかさ。0は無彩色（グレー）
• Tone（トーン / 0〜100）: 人間の目が知覚する明るさ（輝度）。0は純粋な黒、100は純粋な白

HCTの最大の特徴は、「色相が何色であっても、Toneの数値が同じなら人間が知覚する明るさが同一になる」という点です。
Tone 40の青も、Tone 40の黄色も、人間にとっては全く同じ明るさとして認識されます。

この仕組みのおかげで、「Toneの差がそのままコントラスト比になる」というシンプルな計算式が成立します。
例えば「背景がTone 90なら、文字にはTone 40以下の色を置く」というルールを守るだけで、どんな色相を選んでもWCAG 2.1のコントラスト基準（4.5:1以上）を自動的にクリアできます。

3. 実務で破綻しない「カラートークン（Roles）」の階層設計

HCT理論の優れた知見を日々のUI設計に落とし込むための仕組みが、M3の「カラートークン（Color Roles）」です。
M3では、生の色コード（#1E40AF など）をUIパーツに直接指定することを推奨していません。すべて「その色が果たす役割（Role）」として名前をつけて管理します。

主要カラートークンの役割と階層一覧

M3のカラーパレットは、UIの構成要素に合わせて明確なグループに分かれています。
実務で頻出する主要なトークンの役割は以下の通りです。

「Container」と「On-〜」の命名規則の読み解き方

M3の命名規則で最初に覚えるべき重要なパターンが、「Container」と「On-〜」の接頭辞・接尾辞です。

• 単体名（例: Primary）: 最もコントラストが高く目立つ塗り。メインボタンなどに使用。
• Container（例: Primary Container）: 明るい淡いトーン（ダークモードでは適度に沈んだトーン）の面。視覚的な圧迫感を抑えつつグルーピングしたい領域に使用。
• On-〜（例: On-Primary, On-Surface）: 「その面の上に載せる色（On top of）」を意味する。背景のトーンに応じた視認性の高い文字色やアイコン色を指す。

「Primaryの上にはOn-Primaryを載せる」「Surfaceの上にはOn-Surfaceを載せる」という組み合わせルールが名前自体に組み込まれているため、デザイナーもエンジニアも迷うことなくコントラストを担保できます。
この設計思想は、自社サービスで独自のデザイントークンを組む際にもそのまま流用できる強力なフレームワークです。

4. Figma実務でM3を取り入れる3つのステップ

M3の設計思想やトークン構造を、日々のFigma作業で効率的に活用するための3つの実践ステップを紹介します。
複雑な計算を手動で行う必要はなく、公式ツールを賢く組み合わせることで素早く高品質な基盤を整えられます。

Step 1: 公式プラグイン「Material Theme Builder」でトークンを一括生成

Google公式がFigma向けに無償提供しているプラグイン「Material Theme Builder」を使用します。
プラグインを開き、ブランドの核となるキーカラー（Primary Color）を1色指定するだけで、HCT理論に基づいて計算されたLightモードおよびDarkモードのフルカラーパレットが一瞬で生成されます。

SecondaryやTertiaryも自動で調和する補色が提案されますが、ブランドガイドラインに合わせて個別にキーカラーを上書き指定することも可能です。
コントラスト計算に頭を悩ませる作業をツールに任せ、デザイナーはUI全体の情報設計に集中できます。

Step 2: Figma Variablesにトークンをマッピングする

Material Theme Builderで生成されたカラートークンは、Figmaの標準機能である「Variables（変数）」としてそのままファイル内に登録されます。
コレクション内に「Light」列と「Dark」列が自動生成され、color/primary や color/surface といったセマンティックな変数名で管理されます。

フレームのFillやテキストのカラーに変数を割り当てておけば、親フレームのModeを「Dark」に切り替えるだけで、画面全体のカラーが適切なコントラストを保ったまま一瞬で反転表示されます。
ライト版とダーク版のカンプを2重管理する手間がなくなります。

Step 3: 公式「Material 3 Design Kit」からレイヤー構造をリバースエンジニアリングする

Figma Communityで公式配布されている「Material 3 Design Kit」は、公式チームの手によるコンポーネント構造の実践的なお手本です。
ボタン、カード、トップアプリバー、ダイアログなど、すべてのUIコンポーネントが最新のAuto LayoutとVariablesで精緻に組み上げられています。

Material 3 Design Kit – Figma Community

Google公式提供のMaterial Design 3 UIキット。最新のAuto Layout、カラートークン、コンポーネント構造をFigma上で直接複製・参照可能。

自分自身も、新しいUIパーツの余白設計やネスト階層で迷った際は、このM3 Design Kitを開いて「Googleのチームはここをどう組んでいるのか」を必ず確認するようにしています。
公式データのレイヤー階層を分解して観察するだけでも、プロの構造設計ルールが自然と身につきます。

5. 動き（Motion）に物理法則を取り入れるスプリングアニメーション

UIの触り心地や操作感を決定づけるのが「動き（Motion / Micro-interactions）」です。
ボタンを押したときや画面が遷移するとき、どこか機械的で味気なく感じてしまう原因の多くは、等速（Linear）で動いて急停止するなど、自然界の物理法則を無視している点にあります。

M3では、アニメーションに「スプリング（バネ力学）」の考え方を全面的に取り入れています。
「0.3秒で移動する」という時間（Duration）指定ではなく、物体の「重みや反発」という質感で動きを表現するアプローチです。

• Stiffness（剛性 / バネの硬さ）: 数値が高いほどキビキビと素早く反応し、低いほどゆったりと追従する。
• Damping（減衰 / 摩擦の強さ）: 数値が低いとボヨンとバウンドし、高いと揺れずにスーッと静かに収束する。

例えば、成功トースト通知や重要なバッジは少しバウンドさせて視線を集め、設定シートのスライド表示は減衰を高めて滑らかに定位置へ収める、といった調整を行います。
指先のタップ操作に対して自然な手応えを返す配慮が、プロダクトへの心地よさと信頼感を高めてくれます。

6. Material Design 3に関するよくある質問（FAQ）

M3の導入や学習を進める中で、現場のデザイナーからよく寄せられる疑問とその回答をまとめました。

• Q. WebサイトやiOSアプリのUI設計でもM3の考え方は活用できますか？
  十分に活用できます。ダイナミックカラー自体はAndroid OS独自の機能ですが、HCT理論によるアクセシブルな配色ルールや、Surface/Containerによるカラートークン構造、スプリング力学などは、プラットフォームを問わずWebやiOSのプロダクト設計にもそのまま応用できる普遍的な知見です。
• Q. ダイナミックカラーはすべてのプロダクトで導入すべきですか？
  いいえ、必須ではありません。強いコーポレートカラーやブランドの世界観を厳密に固定したいプロダクト（金融、BtoB SaaS、特定ブランドアプリなど）では、あえて壁紙連動のダイナミックカラーを採用せず、ブランド固定のPrimaryトークンを運用するのが実務上一般的です。
• Q. M3のトークン数が多すぎてチームで管理しきれない場合はどうすればいいですか？
  最初から全トークンを網羅する必要はありません。まずは「Primary」「Surface」「On-Surface」「Background」「Error」の主要5系統に絞ってスモールスタートし、運用しながら必要に応じてContainerやTertiaryを段階的に増やしていく運用をおすすめします。

次のステップ：あわせて深掘りしたい知見

M3のカラートークン設計をチームで破綻させずに運用するためには、FigmaのVariables機能とオートレイアウトの基礎を押さえておくことが不可欠です。

トークンの2層構造（PrimitiveとSemantic）やライブラリの非公開化など、実務で迷わない変数設計ルールは以下の記事で詳しく解説しています。

Figma Variables（変数）の使い方完全ガイド｜破綻しない命名規則とトークン設計【2026】

Variablesへの心理的ハードルを下げ、スモールスタートで運用を回すための2層トークン構造（PrimitiveとSemantic）とガバナンス設計ルールを徹底解説。

コンポーネント内の要素間余白やPaddingを崩さずに組むオートレイアウトのネスト設計手法については、こちらの解説記事を参考にしてください。

Figmaオートレイアウト完全ガイド！崩れないネストと余白設計

Figmaオートレイアウトの基本と崩れないネスト設計を解説。Padding・Gapの設定からHug・Fill・Fixedの使い分け、メディアカードの組み立て手順まで網羅。

設計したトークンや余白をエンジニアへ手戻りなく引き渡すためのDev Mode活用法については、以下の記事で体系的に整理しています。

Figma Dev Mode（開発モード）の使い方と料金体系｜できること・できないことと実装連携【2026】

Figma Dev Modeで何ができて何ができないのか、有料シートの料金体系やVS Code連携、差分比較（Diff）による手戻り防止フローを徹底解説。

まとめ：デザインの「感覚」を強固な「ロジック」に変える

Material Design 3は、単なるGoogle専用のデザインガイドラインではありません。
アクセシビリティを担保しながら、デザインの意思決定に確かな根拠を与えるための優れた設計思想です。

• HCTカラースペースを理解し、Toneの数値差によってアクセシビリティを自動担保する
• Hex値の直打ちをやめ、Primary / Surface / Containerなどの役割（Role）でトークンを管理する
• Material Theme Builderと公式Design Kitを活用し、Figma実務での設計精度を高める

まずは次の案件から、主要なカラーを「役割」で定義してみたり、公式のDesign Kitを覗いてみることから始めてみてください。
「なんとなく決めた色や余白」に論理的な説明がつくようになるだけで、チームとの合意形成がぐっとスムーズになります。

The post Material Design 3（M3）入門ガイド｜カラートークン設計とFigma実務活用【2026】 first appeared on デザペディア.