iPhone Duo発売、Web制作の対応は？

グレープフルーツ編集部です。

きのう10月23日、折りたたみのiPhone「iPhone Duo」が発売されました。開くと7.6インチ、閉じると5.4インチ。iPhoneなのに画面が2枚あります。

新しい形のiPhoneが出ると、「自社のサイトも何か対応しないといけないのか」が気になるのではないでしょうか。発売と同じ日に、Safariの開発元であるWebKitが、開いたとき・閉じたときの画面寸法を公表しています。

先に答えると、機種別の対応はいりません。

iPhone Duo用のブレークポイントを足す必要はなく、幅に合わせて伸び縮みするレスポンシブ設計で足ります。WebKit自身がそう書いています。ただ、弊社サイトを同じ寸法で眺めてみたら、幅ではなく「縦の短さ」で1か所引っかかりました。その話はあとで。

iPhone Duoの何がWeb制作に関わるのか

画面は2枚です。内側が7.6インチで1,878×2,670ピクセル、外側が5.4インチで1,398×2,034ピクセル（Appleの仕様ページ）。本体は開くと幅164.6mm、閉じると幅84.1mmで、閉じたときの厚さは11.3mm。価格は364,800円（税込）からです。

発表は現地の9月9日、日本時間では9月10日の未明でした。予約開始が10月16日、発売がきのうの10月23日。日本は第1弾の70以上の国と地域に入っています。

ここまでは、ニュースで見た話ですよね。

Web制作の目で見ると、関係するのは3つあります。画面が2枚あること。閉じた状態の画面が普通のiPhoneより横に広く縦に短いこと。そして横に開くとiPadに近い幅になることです。ひとつの端末の中で、Webページが表示される領域の幅が倍以上変わる。ここが新しいところです。

ブラウザは変わっていません。

Duoに載っているのはiOS 27.1で、Safariも27.1です。このiOS 27.1はiPhone Duoだけに配信されていて、ほかのiPhoneは10月23日時点でiOS 27.0.1のままです（Appleのセキュリティリリース一覧）。

WebKitの記事は「Today iPhone Duo arrives, and with it, Safari 27.1.」と始まりますが、エンジンはほかのiPhoneと同じWebKitです。Duo専用の描画エンジンが載ったという話は出ていません。

無視できる台数かというと、そうでもなさそうです。StatCounterの2026年9月の数字では、日本のモバイルOSはiOSが約6割、Androidが約4割（Webアクセスの比率）。

一方でMMD研究所の2026年8月の調査では、スマートフォン利用者のうちiPhoneは45.6%、Androidが54.1%です。測り方で順位が入れ替わるので「日本はiPhoneが多い」とは言い切れませんが、どちらで見ても半数前後。iPhoneの新しい形が出たとき、Webサイト側が気にする理由は十分にあると思います。

WebKitが出した姿勢別の数字

幅は382から951、高さは368から902。WebKitの記事「WebKit Features for Safari 27.1」（Jen Simmons、10月23日）が、Safari 27.1でWebページが表示される領域をCSSピクセルでこう公表しました。

使い方ごとに分けた表が同じ記事に載っています。

SVHはタブバーが出ている状態の高さ、LVHはスクロールしてタブバーが縮んだ状態の高さです。ほかのiPhoneと同じく、Duoでもスクロール中にタブバーが縮むので、高さが2段階あります。

外側ディスプレイでは初期設定でタブバーが下にあり、これも普通のiPhoneと同じ。内側ディスプレイではタブバーが上に移って、iPadやMacに近い見え方になります。内側を横向きにすると2つのウィンドウを左右に並べられて、そのときの各ウィンドウは幅385の細長い縦向きです。

幅が5通り。同じ端末で、です。

382、385、594、669、951。この数字を見て「Duoのブレークポイントは何pxにすればいいのか」と考え始めると、答えが出ません。1台の中で幅が切り替わるのだから、機種を1つの幅で代表させる発想がそもそも成り立たないのです。

もうひとつ、この範囲はまったく新しい幅帯でしょうか。従来のiPhoneの幅はおおむね375から440、951はiPadの幅の範囲内です。既にiPhoneとiPadの両方で崩れていないサイトなら、見たことのない幅はほぼ生まれない計算になります。

幅は崩れず、縦で見出しが消えた

実機のiPhone Duoは手元にありません。そこで、WebKitの表の寸法どおりにヘッドレスのChromiumで弊社サイト（grafru.jp）のトップページを開き、5通りの寸法でスクリーンショットを撮りました。UAはiPhoneのSafari 27.1相当にしていますが、動いているのはChromiumで、Safariでも実機でもありません。

「寸法を再現して眺めてみた」以上のことは言えない前提で読んでください。

幅で崩れたものは1つもありませんでした。

外側・縦の382pxは普段のスマホ表示とまったく同じでした。見出し3行、リード文、イラスト、NEWSの帯まで普通に収まります。2ウィンドウの片側にあたる385pxも同じ。内側・縦の669pxは、スマホ用のレイアウトのまま幅が広がった状態で、ロゴが中央、見出しは左寄せ、リード文は中央寄りの段になります。読めますが、余白が大きくてタブレット寄りの見え方です。

幅は余裕。で、横向きにしてみると……。

外側・横の594×368では、ファーストビューの見出し3行が画面に出てきません。固定ヘッダーのすぐ下がリード文から始まっていて、キャッチコピーが見えませんでした。縦368pxは、普通のiPhoneの横向きと同じくらいか、それより短い高さです。内側・横の951×585でも、見出しの最後の1行「サポートする。」だけが固定ヘッダーの縁からのぞき、上の2行は隠れていました。幅は十分なのに、縦で詰まった。

正直、幅のほうを心配していたので意外でした！

原因は、画面の高さを基準に位置を決めているファーストビューが、短いviewportに収まらなかったところまでしか分かっていません。CSSのどこが効いているかはこれから追います。ただ、これはDuo固有の話というより「縦が短い横向き」全般の問題です。WebKitが高さを368から902までと幅広く示した意味が、ここで体感できました。

ブレークポイントを足すより先にやること

WebKitの答えは「数字を気にしなくていい」です。原文はこうなっています。

However, you don’t need to worry about all these numbers. Instead, lean into the wisdom of Responsive Web Design techniques. Create layouts for your websites and web apps that simply work on every sized screen from the extremely large to the very tiny.

ただし、これらの数字をすべて気にする必要はない。レスポンシブWebデザインの知恵に寄りかかって、極端に大きい画面から極端に小さい画面まで、どのサイズでもそのまま動くレイアウトを作ってほしい。そういう趣旨です。

同じ記事に「Avoid UA sniffing to detect devices, and use feature detection instead.」ともあります。端末の判定にUAスニッフィングを使わず、機能検出を使うこと。

具体的には、幅を固定せず流体で組むこと。これで幅のブレークポイントを増やす場面はかなり減ります。

.container {
  width: min(100%, 40rem);
}
h1 {
  font-size: clamp(1.5rem, 1rem + 2vw, 2.5rem);
}

min()で「親の幅か上限のどちらか小さいほう」を取り、clamp()で文字サイズに下限と上限を付けて間を幅に連動させる。この2つを使っていれば、382でも951でもブレークポイントを増やさずに済むことがほとんどです。例外は改行できない長い英数字や幅を固定した画像で、そこは別に見ます。文字まわりの実測は日本語Webフォントを軽くした記事にも書いています。

幅よりも見直したいのは縦です。

機種別のブレークポイントを足すより、縦の短い画面でファーストビューを見直すほうが先です。

弊社サイトで起きたことも、おそらくこの典型例だと思います。ファーストビューの高さを100vhのように画面いっぱいで取り、見出しを高さ基準で中央に置いていると、縦368pxでは固定ヘッダーに潜ります。高さはsvhで取り、固定ヘッダー分の余白を上に足す。見出しの位置を高さに連動させない。この3つをセットで確認してください。

.hero {
  box-sizing: border-box;
  min-height: 100svh;
  padding-top: var(--header-height);
}

box-sizing: border-boxを付けているのは、余白を足しても全体の高さが100svhを超えないようにするためです。svhはタブバーが出ている状態の高さを基準にするので、スクロール前でも収まる高さになります。ただしsvhはブラウザのUIを引いた高さで、ページ側の固定ヘッダー分までは引いてくれません。だから余白をセットで足します。スクロールに合わせて高さを追従させたいところはdvhです。

もうひとつ、固定要素の重ね過ぎ。縦368pxのviewportに固定ヘッダーと固定フッターとCookieバナーを重ねたら、本文に残る高さはいくらでしょうか。固定フッターは便利ですが、縦の短い画面で何を優先して見せるかを決めてから使ったほうがいいかもしれません。

フッターを画面下に固定するCSSの記事

【CSS】フッターを画面下部に固定する方法を解説！ Webサイトのフッター、中途半端な位置に浮いていませんか？Webサイトを制作していると、特にコンテンツ（情報量）が少ないページで「フッターが浮いてしまい、画面の下…

やらないほうがいいのは、JavaScriptで「iPhone Duoだったらこのレイアウト」と端末名で分けることです。幅が5通りに切り替わる端末なので、端末名で判定しても当たりません。幅や高さそのもの、つまりメディアクエリやコンテナクエリで判定すれば、Duoの次の端末が出ても同じコードで動きます。

固定幅でPC専用のまま残っているサイトは、Duo以前にスマホで既に困っているはずです。そういうサイトは、Duo対応ではなくレスポンシブ化そのものが先です。

古いホームページの見直しの記事

古いホームページ、使っていませんか？デザイン改善で集客に差をつける秘訣 「うちのホームページ、なんだか古くてダサいかも…」 そう感じている中小企業の経営者やウェブ担当者の方、多いのではないでしょうか。せっかく時間とお金をかけて作っ…

折り目のAPIは今どこまで使えるのか

Safari 27.1には、半分に折った状態を検出する「Device Posture API」と、画面の分かれ目の位置を取る「Viewport Segments API」が入っています。ただし、機能フラグの裏です。「設定」の「アプリ」から「Safari」「詳細」「機能フラグ」と進んで両方をオンにした人のSafariでだけ動く、開発者プレビューの扱いです。

Device Posture APIは@media (device-posture: folded)で、半分折った状態に当てるCSSを書けます。値はfoldedとcontinuousの2つで、continuousは平らに開いた状態と完全に閉じた状態の両方を含みます。

JavaScriptからはnavigator.devicePosture.typeで読めて、変化はchangeイベントで取れます。

Viewport Segments APIは@media (horizontal-viewport-segments: 2)で「画面が左右2つに分かれている」ことを判定し、env()のviewport-segment-widthなど6つの変数で各区画の位置と大きさを取ります。JavaScriptはwindow.viewport.segmentsで、DOMRectの配列です。

面白そうですよね。でも、iPhone向けに本番サイトで使う段階にはありません。

Chromeでは出荷済みです。Device Posture APIがChrome 132（2025年1月）、Viewport Segments APIがChrome 138（2025年6月）で入りました。

Chrome 125から128にかけては試験運用のOrigin Trialだったので、「Chrome 125で使える」と書いてある情報は古いか不正確です。

一方でFirefoxは未実装、macOSのSafariも未実装。MDNは両方のAPIを「実験的」「利用可能性は限定的」と位置づけています。

WebKitも、フラグの裏にある間は仕様が変わる余地があるとして、フィードバックを募っている段階です。Androidの折りたたみ端末を主な対象にするなら使う選択はありますが、iPhone向けには「使えるようになったら、の話」と線を引いておくのが今は正確だと思います。

もう1点、外側ディスプレイの話を補足します。外側は普通のiPhoneより横に広く縦に短いので、iOSは操作系を横に寄せて置いています。Safari 27.1はその操作系の裏までWebコンテンツを広げず、ページの背景色を延長して埋めます。

WebKitはviewport-fit=coverで広げる案も検討していますが、四辺のインセットを正しく処理しているサイトが少ないため、より確実な別の手段を調べているところだそうです。Duoの外側ディスプレイ対策として制作者が先回りしてviewport-fit=coverを足すのは、WebKitが心配している方向そのものなので、私は勧めません。Safari側の課題として待つのが正解でした。

実機がなくても確認はできる

「You don’t need iPhone Duo in hand to test your website or web app.」と、WebKit公式は案内しています。Webサイトの確認に実機のiPhone Duoは要らない、と。

公式の手段はXcode 27.1です。Xcode 27.1以降のDevice HubでiPhone Duoのシミュレーターを作れて、全部の姿勢と向きで確認できます（Apple Developerのお知らせ）。Macがあれば、端末を買うより確実に安いですよね。

Macが無い、もっと手早く見たい。そういうときはChrome DevToolsです。

DevToolsのデバイスモードにiPhone Duoのプリセットは今のところありません。寸法のリストから「Edit」を開き、「Add custom device」で名前と幅と高さを入れて追加します。

登録する数値はWebKitの表にあるSafariのviewport値で、画面の物理ピクセルを倍率で割った値ではありません。レイアウトの確認が目的なら、DPRの欄は空のままで構いません。Appleの仕様ページには論理解像度や倍率の記載がないので、埋めようとしても埋まりません。

高さはタブバーが出ている状態（SVH）の値にしています。短いほうで収まっていれば、タブバーが縮んだ状態でも収まるからです。DevToolsには二画面のエミュレーションと姿勢の切り替えもありますが、こちらはSurface DuoやZenbook Foldを例にしたもので、iPhone Duoの折り目を再現するものとは別です。

私なら順番はこうします。まずDevToolsで382×580と594×368を開く。縦の短い594×368で、ファーストビューと固定要素がどう見えるかを確認する。それで気になるところがあれば、Xcodeのシミュレーターで姿勢を変えながら見る。実機を買うのは、その先でいいと思います。

きのう出た端末の話を発売翌日に書いているので、Safari側の挙動はこれから変わるところがあるはずです。弊社サイトの、横向きで見出しが隠れる件も近いうちに直します。

自社サイトがDuoでどう見えるか気になったら、まずDevToolsで2つの寸法を開いてみてください。そこで崩れていなければ、たぶん何もしなくて大丈夫です。

参考・出典