2026年9月10日午前2時(日本時間)、Appleの新製品発表イベント「Surprise and shine.」が開催されました。目玉はAppleとして初となる折りたたみiPhone「iPhone Duo」です。
この記事は発表内容そのもののまとめではありません。それは各メディアがすでに詳しくやっています。ここでは受託でクライアントのWebサイトやアプリを預かっている立場から、「折りたたみiPhoneが市場に出ることで、自分たちのコードの何が影響を受けるのか」を整理します。
本記事は発表当日(2026年9月10日)時点の情報をもとに書いています。仕様・価格・日本での提供時期は今後変わる可能性があるため、実装判断の前にApple公式サイトの記載を確認してください。
1. 発表内容の要点
まず前提の共有として、今回発表されたものを短くまとめます。
今回いちばん押さえておきたいのは、個別のスペックよりもラインナップの構成が変わったことです。
標準モデルのiPhone 18は今秋には登場せず、2027年春に回るとされています。つまりこの秋のiPhoneは「Proと折りたたみだけ」という構成になりました。
| 製品 | ポイント |
|---|---|
| iPhone Duo | Apple初の折りたたみiPhone。7.6インチのインナーディスプレイと5.4インチのアウターディスプレイ、A20 Proチップ、C2モデム、48MP Dual Fusionカメラ、Touch ID、eSIM専用。開いた状態で厚さ5.2mm、重量254g。日本では364,800円から、予約は10月16日、発売は10月23日 |
| iPhone 18 Pro / Pro Max | A20 Proチップ、可変絞り対応のメインカメラ、小型化されたDynamic Island。米国価格は前世代比+100ドル |
| その他 | AirPods 5、Apple Watch Series 12、Apple Watch Ultra 4 |
なお今回は、9月1日にCEOへ就任したジョン・ターナス氏にとって初めての基調講演でもありました。
iPhone DuoはiPhone 18 Proより1か月ほど遅い発売です。Apple Pencil(USB-C)への対応も「年内」とされており、発売時点ではまだ使えません。
2. なぜ「折りたたみ」がWeb側の話になるのか
ネイティブアプリの話でしょ、と流したくなるところですが、実際にはWeb側のほうが影響を受けやすい面があります。まず、公式仕様に出ている数字を並べてみます。
| インナー(開いた状態) | アウター(閉じた状態) | |
|---|---|---|
| サイズ | 7.6インチ(実測7.58インチ) | 5.4インチ(実測5.36インチ) |
| 解像度 | 1,878 × 2,670ピクセル | 1,398 × 2,034ピクセル |
| 画素密度 | 430ppi | 460ppi |
| 本体の外形 | 幅164.6 × 高さ117.8mm | 幅84.1 × 高さ117.8mm |
ここで注目したいのは比率です。アウターは 1,398 : 2,034 で およそ 1 : 1.45。インナーは開くと横向きになるので 2,670 : 1,878 で およそ 1.42 : 1。つまり閉じても開いても、比率はほぼ同じ 1 : 1.42 前後です。Appleが両ディスプレイで比率を揃えてきた設計になっています。
問題は、この 1 : 1.42 が従来のiPhoneの 9 : 19.5(およそ 1 : 2.17)とまったく違うことです。閉じた状態ですら、既存のスマホ用CSSの想定からは外れています。 「開いたときだけ気にすればいい」という話ではありません。
CSSピクセル(pt)に換算すると、おおよそ次の値になります。
| 状態 | 論理解像度(概算) |
|---|---|
| アウター(縦) | 約 466 × 678pt |
| インナー(横) | 約 890 × 626pt |
Appleは論理解像度を公表していないため、上記は公称解像度を3で割った計算値です。Safariの実際のビューポートは、アドレスバーやツールバーの分だけこれより小さくなります。実機で window.innerWidth / innerHeight を確認するのが確実です。
この数字を踏まえると、影響は3点にまとまります。
1つ目は、幅466ptという中途半端なアウターの横幅。 従来のiPhoneの縦持ちは390〜440pt程度なので、それより広く、しかし高さは678ptしかありません。max-width: 480px あたりでスマホ判定をしている実装は、閉じた状態でぎりぎり引っかかるかどうかという位置に来ます。
2つ目は、インナーが横長890ptで来ること。 タブレット用のレイアウトが当たる幅ですが、高さは626ptしかありません。縦に長いヒーローエリアやフルスクリーンモーダルは、ここで窮屈になります。
3つ目は、開閉で同一セッション中にビューポートが変わること。 回転ではなく折りたたみでサイズが変わるため、初回描画時にJavaScriptで測った値を持ち回っている実装は、開いた瞬間に破綻します。加えて、ヒンジをまたぐ位置にボタンやフォームの入力欄が来ると、押しづらい・読みづらいというUX上の問題も出ます。
3. CSS Viewport Segments API の現在地
Webにはすでに、折りたたみ端末のために策定された仕様があります。CSS Viewport Segments です。ビューポートが物理的に分割されている場合に、その分割数と各領域の座標をCSSとJavaScriptから取得できます。
CSSではメディア特性と環境変数の組み合わせで書きます。
.layout {
display: flex;
flex-direction: column;
}
/* 横方向に2セグメント = 見開きで左右に分かれている状態 */
@media (horizontal-viewport-segments: 2) {
.layout {
flex-direction: row;
}
.list {
width: env(viewport-segment-width 0 0);
}
/* 折り目そのものの幅を確保して、コンテンツを跨がせない */
.hinge {
width: calc(env(viewport-segment-left 1 0) - env(viewport-segment-right 0 0));
}
.detail {
width: env(viewport-segment-width 1 0);
}
}
JavaScript側は window.viewport.segments から取得します。
const segments = window.viewport?.segments ?? [];
segments.forEach((segment, index) => {
console.log(`segment ${index}: ${segment.width}px x ${segment.height}px`);
});
折りたたまれていない端末や折りたたみに対応していない端末では、ビューポート全体を表す1要素の配列が返ります。分岐を書かずに済むように仕様側で揃えられています。
4. ここが本題:Safariは未対応
便利そうな仕様を紹介しておいて恐縮ですが、対応状況はこうなっています。
| ブラウザ | 対応 |
|---|---|
| Chrome / Chrome for Android | 138(2025年6月)以降 |
| Edge | 138以降 |
| Firefox | 未対応 |
| Safari / Safari on iOS | 未対応 |
つまり、折りたたみiPhoneが発売されても、Safariで Viewport Segments を前提にした実装は今のところ使えません。 折りたたみ端末向けの標準APIがChromiumにしかない状態で、Chromiumを積んでいない折りたたみ端末が市場に出る、という構図になります。
iOS 27世代のSafariで対応が入るかどうかは、リリース後のSafariリリースノートで確認するのが確実です。本記事執筆時点では未対応として扱っています。
ここから導かれる方針はシンプルで、セグメント情報に依存しない形で「どんな幅・どんなアスペクト比でも壊れない」状態にしておくことになります。地味ですが、これは折りたたみ端末に限らず効きます。
5. 今日からできる現実的な対策
5-1. 画面幅ではなくコンテナ幅で分岐する
メディアクエリは「ビューポートがいくつか」を見ますが、コンテナクエリは「この要素に与えられた幅がいくつか」を見ます。折りたたみのように想定外の幅が来る環境では、後者のほうが破綻しにくいです。
.card-area {
container-type: inline-size;
}
/* 親要素の幅で切り替わるので、画面全体の幅を気にしなくてよい */
@container (min-width: 640px) {
.card {
display: grid;
grid-template-columns: 200px 1fr;
gap: 16px;
}
}
5-2. 決め打ちのブレークポイントを棚卸しする
max-width: 767px のような、特定端末を想定した数値が残っていないか確認します。開いた状態の折りたたみ端末は、スマホ用とタブレット用のどちらのCSSが当たっても不自然になり得ます。幅の値そのものより、「その幅で何を切り替えているか」を見直すほうが効果があります。
5-3. 初回描画時の測定値を持ち回らない
window.innerWidth を初期化時に一度だけ読んで保持している実装は、開閉のたびにズレます。resize イベントか ResizeObserver で追従させます。
// 初期化時の値を保持したままにしない
let layoutMode = resolveLayoutMode(window.innerWidth);
window.addEventListener('resize', () => {
const next = resolveLayoutMode(window.innerWidth);
if (next !== layoutMode) {
layoutMode = next;
applyLayout(layoutMode);
}
});
5-4. 横向きレイアウトを確認する
iOS 27では、これまで縦向き中心だったシステムアプリに横向きレイアウトが戻ってきています。折りたたみの内側ディスプレイを見据えた動きと見られています。長らく縦向きだけ確認して済ませていたページがあれば、この機会に横向きも見ておくと安全です。
5-5. 実機がなくても検証する
発売直後に実機を用意するのは現実的ではないので、当面はエミュレーションで進めます。
- Chrome DevToolsのカスタムデバイスに、アウター(466 × 678)とインナー(890 × 626)を登録して切り替えながら確認する
- Viewport Segments のポリフィルで、セグメント分割時の挙動を手元で再現する
6. ネイティブ・ハイブリッド側の状況
iOS 27のフレームワークには、折りたたみ状態を示す foldState やヒンジの開閉角度を示す angleDegrees といった記述、および内蔵ディスプレイ数を取得する仕組みが含まれていることが、ベータ公開時点で開発者によって指摘されていました。iOS 26には存在しなかったものです。
またWWDC 2026のPlatform State of the Unionで、Appleは特定の画面サイズを前提にせず、幅広いサイズとアスペクト比に対応する設計を開発者に促していました。iPhoneアプリのウィンドウリサイズ対応が広がったのも同じ流れの中にあります。
WKWebViewを内包するハイブリッドアプリを持っている場合、この話はネイティブ側とWeb側の両方に効きます。ネイティブのコンテナが可変サイズになる以上、中のWebビューも可変前提で組む必要があります。
7. 受託開発での落としどころ
クライアント案件で「折りたたみiPhone対応」を今すぐ提案すべきかというと、そこは冷静に判断したいところです。折りたたみ端末の出荷台数はスマートフォン全体の数パーセント規模にとどまっており、iPhone Duoの初期供給も限定的と見られています。専用の分岐を作り込む投資対効果は、現時点では高くありません。
現実的な進め方としては次のあたりになります。
- 今やる:既存サイトを 466 × 678 と 890 × 626 で開き、明確に崩れる箇所だけ直す
- 次の改修で混ぜる:決め打ちブレークポイントをコンテナクエリへ寄せる
- 保留:Viewport Segments を使ったセグメント分割レイアウト。Safariの対応状況が変わってから
「折りたたみ対応」という項目を新設するより、レスポンシブ設計の健全性チェックとして扱うほうが、説明もしやすく無駄も出にくいと考えています。
8. まとめ
- iPhone Duoの2つのディスプレイは、閉じた状態も開いた状態も比率がおよそ 1 : 1.42。9 : 19.5 前提のCSSはどちらでも想定外になる
- 論理解像度はアウターが約466 × 678pt、インナーが約890 × 626pt(公称解像度からの計算値)
- 標準仕様のCSS Viewport SegmentsはChrome / Edgeのみの対応で、Safariでは現時点で使えない
- そのため当面は、セグメント情報に頼らず「どんな幅でも壊れない」状態を作るのが現実解
- コンテナクエリ、ブレークポイントの棚卸し、初期測定値の見直し、横向き確認の4点は、折りたたみ以外にも効く
新しいフォームファクタが出たときにいつも効いてくるのは、結局のところ普段のレスポンシブ設計の丁寧さでした。今回もそこは変わらなさそうです。
参考
- Apple「iPhone Duo - 仕様」
- Apple「iPhone 18 Pro」
- MDN「horizontal-viewport-segments」
- MDN「vertical-viewport-segments」
- MDN「Viewport: segments property」
- Chrome for Developers「Support foldable devices with the Viewport Segments API」
- web-features「Viewport segments」(対応状況の確認用)
- foldable-devices/viewportsegments-css-polyfill

