LASSIC Media らしくメディア
アプリのダークモード・ダイナミックタイプ対応を外注する進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ダークモード・ダイナミックタイプ対応はセマンティックカラーとフォントの可変設計が核で、実装漏れはApp Store審査で指摘されることがあります。
- iOS・Android双方で対応方法が異なるため、外注前に仕様と現状ハードコードの棚卸しをしておくと発注範囲が明確になります。
- 費用・工期は既存ハードコードの量と対象画面数によって変わります。外注先選定では両プラットフォームの実装実績と審査対応経験を確認することが大切です。
目次
ダークモード・ダイナミックタイプとは
ダークモードとは、アプリの配色をユーザーのシステム設定に連動して明暗2テーマで自動切替する機能を指します。目への負担軽減や有機ELパネルでの省電力に加え、アクセシビリティ向上の観点でも評価が高まっています。
ダイナミックタイプ（Dynamic Type）とは、iOSのシステム設定で変更した文字サイズにアプリ内のテキストを自動的に追随させる機能です。対応アプリのみで機能します。高齢者や視覚に配慮が必要なユーザーがシステム設定を大きくしても、アプリ側が正しく追随することがアクセシビリティの前提条件のひとつです。
Appleは2024年以降、App Storeのプロダクトページにアクセシビリティ栄養成分表示（Accessibility Nutrition Labels）を導入しました。VoiceOver・音声コントロール・Dynamic Type・ダークモード・コントラスト調整などの対応状況を申告ベースで表示する仕組みです。申告内容と実際の実装に乖離がある場合、審査プロセスで指摘される可能性があります。
この流れを受け、ダークモード・ダイナミックタイプ対応はグラフィックの「見栄え」ではなく、公開前に完了しておくべきアクセシビリティ基盤として位置づける必要があります。
iOS・Android別の実装要点
ダークモードとダイナミックタイプの実装方法は、iOSとAndroidで異なります。外注先へ仕様を伝える際は、プラットフォームごとの要件を整理してから発注することで認識齟齬を防げます。
共通して押さえるべきポイントは3点です。第一に、セマンティックカラー（意味ベースのカラーシステム）で全画面の配色を一元管理すること。第二に、固定pxによるフォント指定を排除してシステムフォントスケールに追随させること。第三に、WCAG 2（Web Content Accessibility Guidelines 2）のコントラスト比基準（通常テキスト4.5:1以上、大きなテキスト3:1以上）を満たすことです。
| 項目 | iOS（Swift/SwiftUI） | Android（Kotlin/Compose） |
|---|---|---|
| カラー管理の仕組み | Dynamic Color（UIColor/Color）をカラーアセット（.xcassets）で Light/Dark ペアとして定義し、システムテーマ変更時に自動適用される。 | DayNightテーマ（Theme.AppCompat.DayNight または Material3 Dynamic Color）でres/values/colors.xmlとres/values-night/colors.xmlをペア管理する。 |
| フォント可変対応 | UIFont.preferredFont(forTextStyle:) またはSwiftUIのdynamic type modifierを使用。固定サイズ指定（UIFont(name:size:)のみ）は対応外になる。 | sp単位でフォントサイズを指定する。dp単位や固定px指定はシステムスケールに追随しない。 |
| 画像・アイコン対応 | カラーアセットにLight/Dark両バリアントを登録。SF Symbolsはシステムカラーに自動追随する。 | drawableフォルダをdrawable-night/に分け、ダーク用アセットを配置する。VectorDrawableはtintで制御可能。 |
| コントラスト比の確認 | XcodeのAccessibility Inspectorまたはシミュレータで確認。WCAG 2：通常テキスト4.5:1以上・大きなテキスト3:1以上が目安。 | Android StudioのLayout Inspectorまたは外部ツール（例：TPGi Colour Contrast Analyser）で確認する。 |
| 主な実装リスク | カラーアセットを使わず固定HEXを直書きしているコードが残ると、ダークモード切替時に文字や背景が同色になるケースがある。 | カスタムViewでハードコードしたカラーがDayNightテーマに追随しないケースがある。 独自テーマ継承の場合は親テーマの見直しも必要になる。 |
画像やSVGアイコンは、ライトテーマとダークテーマの双方でコントラストを維持できるバリアントが必要です。PNG画像はテーマごとに別ファイルを用意し、SVGはシステムカラーのtintで制御できる場合はその方法を選ぶと管理コストを抑えられます。
対応を進める4つのフェーズ
既存アプリへの後付け対応は、新規開発とは異なる難しさがあります。ハードコードされた色やフォントが画面全体に散在しているケースでは、対応漏れがあるとダークモード切替時に文字や背景が見えなくなるなど、ユーザー体験を著しく損ないます。
フェーズ1：既存ハードコードの洗い出し
最初に行うべきは、コードベース全体のカラーとフォントサイズを棚卸しすることです。固定HEXカラーの直書き、UIFont(name:size:)による固定サイズ指定、dp/sp以外の固定px指定などをリストアップします。
画面数が多いアプリでは、この洗い出しだけで相応の工数が発生します。外注前に大まかな画面数と技術スタックを把握しておくと、見積もりの精度が上がります。
フェーズ2：セマンティックカラーと文字スタイルの設計
洗い出したカラーを「背景色」「主テキスト色」「サブテキスト色」「ボーダー色」「アクセントカラー」のように意味（セマンティック）ごとに整理し、ライト・ダークの両バリアントをカラーアセットに登録します。この設計フェーズを省略すると、後工程で色の定義が複数の箇所に分散し修正コストが増大します。
文字スタイルも同様に、Body・Caption・Headlineなどのスタイル定義をシステムテキストスタイルに対応させます。このタイミングでWCAG 2のコントラスト比を満たしているかも確認します。
フェーズ3：実装と置換
設計したカラーアセット・テーマ定義をコードに適用します。iOSではハードコードのUIColorをDynamic Colorに、AndroidではHEXカラーをDayNightテーマのカラーリソースに置き換えます。フォントサイズは固定指定からシステムスタイルに変更します。
この工程は対象画面数に比例して工数が増えます。画面あたりの修正密度はコード品質によって異なるため、外注先には画面ごとの修正見積もりを依頼すると比較しやすくなります。
フェーズ4：テストと審査対応
実装後は実機およびエミュレータ・シミュレータでテーマ切替を行い、全画面の表示崩れ・コントラスト不足・ダイナミックタイプの折り返し崩れを確認します。App Storeに申告するアクセシビリティ栄養成分表示と実装内容が整合しているかも、公開前にチェックが必要です。
外注で進めるための手順
外注でダークモード・ダイナミックタイプ対応を進める場合、発注前の準備が品質と納期の安定につながります。以下の手順で進めると認識齟齬を防ぎやすくなります。
- 対象プラットフォーム（iOS・Android・両対応）と対象画面・バージョンを確定する
- 現行コードの技術スタック（Swift/SwiftUI・Kotlin/Compose/Flutter等）と大まかなファイル構成を伝える
- ハードコードの有無・量の把握（難しい場合は外注先に調査フェーズを含めた提案を求める）
- デザインシステムの有無を確認し、カラーアセット設計をデザイナーと外注先どちらが担うかを決める
- テスト工程の分担（実機テストを外注先に含めるか、自社QAと分担するか）を明確にする
- App Store再申請・審査対応の窓口を決める
デザインデータ（Figma等）がある場合は、ライト・ダーク両テーマのトークン定義と合わせて外注先に共有すると設計フェーズを短縮できます。デザインデータがない場合は、カラー設計から含めた提案を受けることになるため、スコープに入れて発注することをお勧めします。
費用が変わる要素と依頼前の確認ポイント
ダークモード・ダイナミックタイプ対応の外注費用は、プロジェクトの条件によって幅があります。市場参考値（一次資料ではありません）として、既存アプリへの後付け対応は小〜中規模で数十万円〜、大規模・多画面では数百万円規模になるケースがあります。以下の要素が費用に影響します。
費用に影響する主な要素
- 対象画面数と既存ハードコードの密度：画面数が多いほど、またハードコードが多いほど置換工数が増えます。
- プラットフォームの数：iOS・Androidの両対応は片方のみと比べ工数が増えます。Flutterなどクロスプラットフォームの場合は別途確認が必要です。
- カラー設計の有無：デザインシステムやカラートークンがない場合は、設計工程も含めた費用が発生します。
- テスト範囲：実機テスト・自動テスト整備を含めるかどうかで費用が変わります。
- App Store再申請対応：審査対応・アクセシビリティ栄養成分表示の申告を外注先に含めるかどうかも確認します。
依頼前に準備しておくと見積もり精度が上がる情報
- 画面一覧（スクリーン数・サブ画面含む）
- 技術スタック・フレームワーク（Swift/SwiftUI/Kotlin/Compose/Flutter/React Native等）
- 現行デザインデータの有無（Figma・Sketchのトークン定義）
- テスト端末・OSバージョンの要件
- 納期・リリース予定のApp Storeレビュー期間の考慮
これらが未整理の場合でも、先に調査・設計フェーズだけを発注して実態を把握してから本実装を発注する進め方が費用対効果の観点で有効です。
外注先の選び方
ダークモード・ダイナミックタイプ対応の外注先を選ぶ際は、iOS・Android双方のネイティブ開発実績とアクセシビリティ対応の知見を持つかどうかが分岐点になります。
確認すべき実績・経験
- ダークモード対応の実装実績：既存アプリへの後付け対応と新規開発では要件が異なります。後付け対応の具体的な案件経験を確認します。
- WCAG 2コントラスト比の検証経験：コントラスト比の基準を理解し、設計段階から意識した実績があるかを確認します。
- App Store審査対応の経験：アクセシビリティ栄養成分表示の申告・審査指摘への対応経験があると心強いです。
- デザイン工程の対応可否：カラーアセット設計・デザイントークンの整備を含めて依頼できるかどうかを確認します。
発注形態の選択
スポット対応（1プロジェクト完結型）と継続保守を組み合わせた契約の2通りがあります。ダークモード・ダイナミックタイプ対応は、OSバージョンアップに伴い再対応が発生するケースがあります。対応後の保守体制も含めて確認しておくと、中長期コストの見通しが立てやすくなります。
内製でこの対応を進める場合、iOS・Androidそれぞれのアクセシビリティ仕様、カラーシステム設計、WCAG 2の実装知識、テスト工程の知識が必要です。これらを社内で習得しながら対応するには相応のリードタイムが発生します。外部パートナーを活用することで、対応漏れリスクを抑えながら計画的にリリースできます。
まとめ：外注成功に向けた3つの判断軸
本稿では、ダークモード・ダイナミックタイプ対応の技術要件から外注の進め方・費用・パートナー選定までを整理しました。要点を3つに集約すると次のとおりです。
第一に、セマンティックカラーとフォントの可変設計が実装の核です。iOS・Androidともにカラーアセットとシステムテキストスタイルへの置換が基本であり、ハードコードの棚卸しが対応範囲の見積もり精度を左右します。
第二に、App Storeのアクセシビリティ栄養成分表示との整合が審査上の留意点です。申告内容と実装に乖離があると審査プロセスで指摘される可能性があるため、公開前に申告内容と実装の整合確認が必要です。
第三に、外注先選定ではiOS・Android双方の後付け対応実績とWCAG 2の知見を確認することが大切です。対応後のOSバージョンアップへの保守体制も含めて確認すると、中長期のリスク管理につながります。
よくある質問
ダークモード対応とダイナミックタイプ対応は同時に発注できますか？
はい、同時に発注できます。両対応ともカラーアセットやフォントスタイルの一元管理が基本となるため、設計フェーズをまとめて進めると工数を抑えられます。別々に発注すると二度手間になるケースがあるため、まとめてスコープに含めることをお勧めします。
FlutterやReact Nativeのアプリでも対応できますか？
対応できます。Flutterはシステムテーマに連動するThemeData/ColorSchemeの切替、React NativeはAppearanceモジュールやuseColorSchemeフックを使う方法があります。ただし、ネイティブブリッジを使っているコンポーネントは個別対応が必要なケースがあるため、外注先にクロスプラットフォームの実績があるか確認することをお勧めします。
ダークモード対応後にApp Storeの審査が通らないケースはありますか？
アクセシビリティ栄養成分表示に申告した機能が実際に動作しない場合は、審査プロセスで指摘される可能性があります。申告するDynamic TypeやダークモードがすべてのOSバージョン・端末で機能するかを実機テストで確認し、申告内容と実装を整合させてから申請することが大切です。
対応工数の目安を教えていただけますか？
対応工数はコードのハードコード密度と画面数によって大きく異なります。カラーアセット設計から全画面の置換・テストまでを含めると、画面数が20〜30程度でも数週間規模の工数が発生するケースがあります（市場参考値・一次資料ではありません）。外注先に調査フェーズを含めた提案を依頼すると、実態に即した工数見積もりが得られます。
対応後もOSアップデートのたびに修正が必要になりますか？
iOSやAndroidのメジャーバージョンアップでUIコンポーネントの仕様が変わると、再確認・修正が必要になるケースがあります。カラーアセットやテーマを一元管理する設計にしておくと、修正範囲を最小限に抑えやすくなります。外注先と継続保守契約を結んでおくと、OSアップデートへの対応を計画的に進められます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Inc.「Human Interface Guidelines – Accessibility」（Apple Developer Documentation、参照2026年）
- *2 出典：Apple Inc.「Scaling Fonts Automatically (Dynamic Type)」（Apple Developer Documentation、参照2026年）
- *3 出典：W3C「Web Content Accessibility Guidelines (WCAG) 2.1」（W3C勧告、2018年）
- *4 出典：Android Developers「Support dark theme – Android Developers」（Google、参照2026年）
