LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

大画面・折りたたみ対応とは何か

モバイルアプリの大画面・折りたたみ対応とは、スマートフォン向けに設計されたUIを、タブレット・フォルダブル端末（折りたたみスマートフォン）・ChromeOSなど多様な画面サイズで適切に表示・操作できる状態に最適化する開発作業を指します。

Androidでは2022年以降、GoogleがフォルダブルとタブレットをあわせてAndroid大画面エコシステムとして積極的に整備を進めています。Jetpack Compose（ジェットパック・コンポーズ、Android公式のUIツールキット）とMaterial3アダプティブライブラリを組み合わせることで、画面サイズに応じたレイアウト自動切り替えが実現できます。

iPadOS側ではSplit View（分割表示）・Slide Over（スライドオーバー）・Stage Manager（ステージマネージャ、iPadOS 16以降のウィンドウ管理機能）に対応するため、Size Class（regular/compact）に基づくAdaptive Design（適応型設計）が求められます。これらの対応を社内エンジニアだけで完結させるには、プラットフォームごとの公式仕様の習熟と実機テスト環境が不可欠です。外注を検討する企業は、仕様の理解不足による手戻りリスクを低減するために専門パートナーに委ねる選択をしています。

Android：WindowSizeClass・Foldable Posturesの仕様

WindowSizeClass（ウィンドウサイズクラス）でレイアウトを切り替える

Androidの公式ドキュメントでは、画面サイズに応じたレイアウト設計の基準としてWindowSizeClass（ウィンドウサイズクラス）の使用を推奨しています^*1。WindowSizeClassはデバイスの物理的なサイズではなく、アプリが実際に利用できるウィンドウ領域（dp単位）を基準に分類します。

幅方向の主な区分は次のとおりです。Compact（600dp未満：縦向きスマートフォン向け）、Medium（600dp以上840dp未満：縦向きタブレットや大型フォルダブル）、Expanded（840dp以上：横向きタブレット）の3段階が標準的に使われます^*1。

重要なのは、この値がマルチウィンドウや折りたたみ・展開によって動的に変化する点です。たとえばフォルダブル端末をアンフォールド（展開）した瞬間に、アプリが受け取るウィンドウサイズはCompactからExpandedへ切り替わります。このときにレイアウトが適切に追従しない場合、UIが崩れたり操作不能になる不具合に直結します。

Foldable Posturesの2状態とヒンジ方向

フォルダブル端末固有の概念としてFoldable Posture（フォルダブル姿勢）があります^*2。AndroidのJetpack WindowManagerライブラリが提供するFoldingFeature（折りたたみ機能）APIでは、端末の折りたたみ状態を次の2値で管理します。

• FLAT：端末が完全に展開された状態（180度）。フル大画面として扱います。
• HALF_OPENED：端末が半開きの状態。画面が2つの表示領域に分割され、ヒンジ（折りたたみ部）を境に上下または左右に分かれます。

HALF_OPENED状態はさらにヒンジの向きによって2つの姿勢に分類されます。

• Tabletop Posture（卓上姿勢）：水平方向のヒンジ。端末を机に置いて上半分に映像・下半分にコントロールを配置するUIが想定されます。
• Book Posture（書籍姿勢）：垂直方向のヒンジ。書籍を開くように左右に画面が並び、電子書籍や2ペインコンテンツに適しています。

これらの姿勢はFoldingFeature.StateとFoldingFeature.Orientationの組み合わせで検出します^*2。HALF_OPENED状態では`isSeparating`が常にtrueになるため、UI要素をヒンジ付近に配置しないよう設計することが求められます。

NavigationSuiteScaffoldによるナビゲーション自動切り替え

Material3アダプティブライブラリが提供するNavigationSuiteScaffold（ナビゲーションスイートスカフォルド）は、WindowSizeClassに基づいてナビゲーションUIを自動的に切り替えます^*3。

Compact幅（スマートフォン）では画面下部のNavigationBar（ナビゲーションバー）、Medium/Expanded幅（タブレット・フォルダブル展開時）では画面側部のNavigationRail（ナビゲーションレール）に自動で変わります。この切り替えをゼロから実装すると複数のActivity/Fragment間で状態管理が複雑になります。専門ライブラリを正しく活用できる経験が、外注先評価の指標の1つです。

App Continuity（継続性）：折りたたみ時の状態保持

フォルダブル対応で見落とされやすいのがApp Continuity（アプリ継続性）です^*2。ユーザーが端末を折りたたむ・展開するたびにアプリが再起動し、入力中のテキストやスクロール位置、メディア再生状態がリセットされると、ユーザー体験を大きく損ないます。

対策として、テキスト入力・スクロール位置・キーボード状態・メディア再生の状態をActivityの`onSaveInstanceState`やViewModel層に正しく保存・復元する設計が必要です。この実装を怠ると、折りたたみ・展開のたびに状態が消えるという致命的な品質問題が生じます。

iPadOS：Size Class・マルチタスク・Stage Managerの仕様

Size Classによるレイアウト判定

iPadOSアプリのレイアウト制御には、Appleが提供するSize Class（サイズクラス）を使用します^*4。UIUserInterfaceSizeClassは`compact`と`regular`の2値を持ち、ビューコントローラはトレイトコレクション（traitCollection）からhorizontalSizeClassとverticalSizeClassを取得してレイアウトを切り替えます。

注意が必要なのは、Split ViewやSlide Overを使用した際のSize Classの変化です^*4。iPad miniでSlide Over利用中のアプリはhorizontalSizeClass=`compact`になり、iPad Pro(横向き)のSplit View 50/50では両方のアプリがhorizontalSizeClass=`regular`になります。デバイス固有の判定でレイアウトを切り替えると、これらのシナリオで誤動作を起こします。

Split View・Slide Over・Stage Manager

iPadOSのマルチタスクには、Split View（2アプリを画面左右に並べて表示）とSlide Over（浮遊するウィンドウで別アプリを重ねて表示）があり^*4、さらにiPadOS 16以降ではStage Manager（フリーウィンドウ管理）が加わりました。

Appleの公式ガイドラインでは、すべてのiPadアプリについてSplit ViewとSlide Overをサポートするよう推奨しています^*4。対応するためにはInfo.plistで4方向のインターフェイス向きをすべて宣言し、LaunchScreen.storyboardを使用することが前提条件です。

Stage Managerでは、ユーザーが任意のウィンドウサイズに変更できます。これはWindowSizeClassと同様に、アプリが「どのデバイスか」ではなく「今どのくらいの幅・高さか」を起点にレイアウトを決定する設計の重要性を示しています。

Auto Layout・Safe Areaによる実装

SwiftUIまたはUIKitのAuto Layoutを使用し、Safe Area（セーフエリア、ノッチやホームインジケータ等を除いた有効表示領域）内にコンテンツを収めます。とくにSplit ViewやSlide Overで画面幅が動的に変化するとき、固定幅のUIは表示が崩れる原因になります。

マルチタスク遷移時の状態保持についても、AndroidのApp Continuityと同様の設計が必要です。divider（仕切り）移動時にアプリがオフスクリーン状態になるため、`applicationWillResignActive`タイミングでデータ・スクロール位置・ナビゲーション状態を保存します^*4。

内製と外注の比較：必要スキルと工数

内製でAndroid大画面・フォルダブル対応を完結させるには、Jetpack Compose・Material3 Adaptive・Jetpack WindowManagerの3ライブラリと、WindowSizeClass・FoldingFeature・NavigationSuiteScaffoldの設計知識が求められます。iPadOS側ではSwiftUI/UIKitに加えてSize Class・Auto Layout・マルチタスク状態管理の実装経験が必要です。

これらを自社で新たに習得する場合、設計・実装に先立って学習期間が発生します。フォルダブル実機の購入・管理コストも加算されます。Android 16（APIレベル36）以降ではresizeableActivityの強制適用やアスペクト比制限の無視など仕様変更も続いており^*3、公式ドキュメントの継続的な追跡が前提となります。

外注フローの5ステップ

ステップ1：対象OS・端末・姿勢パターンの要件定義

外注前に、対応する端末とOSのスコープを明確にします。AndroidのみかiOSも含めるか、フォルダブル端末を対象とするか、タブレットのみかを決定します。

フォルダブルを対象とする場合は、FLAT/HALF_OPENEDの両状態と、Tabletop・Book各姿勢のUI仕様をスコープに含めます。State保持（App Continuity）の対応範囲も要件定義書に明記します。これを曖昧にしたまま発注すると、テスト工程でスコープ外と判明して追加費用・期間が発生します。

ステップ2：RFP（提案依頼書）の作成

RFP（Request for Proposal、提案依頼書）には次の情報を含めます。現状アプリの技術スタック（Compose/XML/SwiftUI/UIKit）、対応必要なWindowSizeClass区分、フォルダブル姿勢対応の有無、テスト対象の実機種別、納期・予算の上限です。

技術スタックを明示することで、パートナーは既存コードのリファクタリング規模を見積もれます。特にXMLレイアウトベースの古いAndroidアプリをCompose・Material3 Adaptiveに移行する場合、設計フェーズの工数が増加するため事前の共有が重要です。

ステップ3：外注先の選定と評価

RFPをもとに複数社から提案を取得し、次節の3ポイントで評価します。大画面・アダプティブUI対応の実装実績、折りたたみ実機テスト環境の有無、既存コードへの影響最小化の設計方針が中心的な評価軸です。

ステップ4：設計フェーズでの仕様確定

外注先が決まったら、まず設計フェーズでUIワイヤーフレームとレイアウト切り替え仕様を確定します。Compact/Medium/Expanded各サイズ、Tabletop/Book各姿勢での画面レイアウト、マルチタスク時のウィンドウサイズ変化への対応方針をここで合意します。

設計フェーズで合意せずに実装を開始すると、テスト工程でレイアウト崩れが多発して手戻りが発生します。設計フェーズへの時間投資がプロジェクト全体の品質を左右します。

ステップ5：実機テスト・継続性検証・リリース

実装完了後は、Compact/Medium/Expandedの各WindowSizeClass区分で画面表示を確認します。フォルダブル端末はFLAT→HALF_OPENED→FLAT遷移時の状態保持（テキスト入力・スクロール位置・メディア再生）を実機で検証します。

iPadOSはSplit View・Slide Over・Stage Managerの各形態でSize Classの切り替わりとレイアウト崩れがないことを確認します。テスト完了後、Google Play・App Storeのストア申請と段階的公開（ロールアウト）を経てリリースします。

外注先選定で確認すべき3つのポイント

ポイント1：アダプティブUI・大画面対応の実装実績

Jetpack ComposeのNavigationSuiteScaffold・ListDetailPaneScaffold（リストと詳細を2ペインで表示するカノニカルレイアウトコンポーネント）・SupportingPaneScaffoldを実際に使った実装経験があるかを確認します^*3。

提案段階で「WindowSizeClassに基づいたレイアウト切り替えを実装した案件がある」と具体的に説明できないパートナーは、フォルダブル対応の習熟度が低い可能性があります。実績をポートフォリオや案件概要で示してもらうと判断しやすくなります。

ポイント2：折りたたみ実機テスト環境の有無

フォルダブル端末のFLAT/HALF_OPENED遷移とTabletop/Book姿勢は、Androidエミュレータでも一定程度確認できますが、ヒンジの物理的な動作特性や実際の操作感は実機でしか検証できません。

「フォルダブル実機を保有しているか」「テスト端末の種類と台数」を確認します。Samsung Galaxy Z Fold・Pixel Fold等の主要機種を保有しているかが目安になります。実機テスト環境がないパートナーに依頼した場合、リリース後にユーザーから姿勢遷移時の不具合報告が相次ぐリスクがあります。

ポイント3：既存コードへの影響を最小化する移行設計

既存のAndroidアプリがXMLベースのView/Fragment構成の場合、Compose全面移行は工数が大きくなります。パートナーが「既存コードとComposeのInteroperability（相互運用性）を活用した段階的移行」を提案できるかどうかも評価点です。

既存のiOSアプリについても、UIKitとSwiftUIの混在構成でSize Class対応を追加する場合の設計方針を問います。既存アプリへの影響を最小化しながら大画面対応を追加する設計経験が、品質リスクと開発コストを抑える判断軸になります。

まとめ：大画面・折りたたみ外注の3つの判断軸

本稿では、モバイルアプリの大画面・折りたたみ対応を外注する際に押さえるべき仕様と手順を整理しました。要点を3つに集約すると次のとおりです。

第一に、AndroidはWindowSizeClass（Compact/Medium/Expanded）とFoldingFeature（FLAT/HALF_OPENED・Tabletop/Book姿勢）が大画面対応の技術的な核心であり、Material3 Adaptiveライブラリを活用した実装経験の有無が外注先評価の基準になります。

第二に、iPadOSはSplit View・Slide Over・Stage Managerの3形態でSize Classが動的に切り替わるため、デバイス固有の判定に頼らずSize Classを起点にレイアウトを設計する必要があります。マルチタスク遷移時の状態保持もiOSとAndroidで共通する重要課題です。

第三に、外注フローは「要件定義（スコープ明確化）→RFP作成→外注先選定（実機テスト環境確認）→設計フェーズ確定→実機テスト・リリース」の5ステップで進め、設計フェーズでの仕様合意を怠るとテスト工程の手戻りが増大します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Window size classes — Android Developers」（2026年確認）
2. *2　出典：Google「Make your app fold aware — Android Developers」（2026年確認）
3. *3　出典：Google「Adaptive do’s and don’ts — Android Developers」（2026年確認）
4. *4　出典：Apple「Adopting Multitasking Enhancements on iPad — Apple Developer」（2026年確認）

Tweet