10月23日に発売されるiPhone Duoに向けて、AIを使う小さなアプリを作り、AppleのDuoシミュレータで試しました。原文を左、端末内AIの要約を右に並べるだけのアプリですが、画面の折り目、開け閉め、AIの出力の3か所で、作る前には気づかなかった落とし穴がありました。
先に結論
1. 画面を左右に等分すると、文字が折り目にかかる。折り目の位置はAPIで取れる
2. 閉じると画面の幅が変わる。AIの答えは、表示の切り替えで消えない場所に持つ
3. 端末内AIは、引用を正確に返しながら要点で数字を読み違えることがある。原文を隣に出す設計が要る
この記事の結果は、すべて Xcode 27.1 RC の iPhone Duo シミュレータ(iOS 27.1)で得たものです。実機では試していません。AIの速さはMac(M1 Max)で動かした値で、Duo実機の速さではありません。情報確認日は2026年10月7日です。

検証の環境と作ったアプリ
| 項目 | 内容 |
|---|---|
| 開発ツール | Xcode 27.1 Release Candidate(27A9275)。Apple Developerサイトから無料で入手 |
| シミュレータ | iPhone Duo、iOS 27.1(24A94232)。iOS 27.0ではDuoを作れなかった |
| Mac | MacBook Pro(M1 Max、メモリ32GB)、macOS 27.0、Apple Intelligenceはオン |
| アプリ | SwiftUI製。架空の提案書を左に出し、端末内AI(Foundation Models)に「見落としやすい条件を3つ、根拠の引用付きで」と頼んで右に出す |
Xcode 27では、シミュレータが「Device Hub」というアプリに変わりました。画面下のボタンで、閉じる・半分折る・全開を切り替えられます。比較のため、よくある作り方の「悪い版」と、問題を直した版を同じアプリに入れ、起動時の設定で切り替えられるようにしました。記事中のコードは、要点だけを残して簡略化しています。
分かったこと1:画面サイズは公式資料に頼らず実測する
Appleの仕様ページには画素数はありますが、アプリが使える大きさ(ポイント)は見当たりませんでした。そこでアプリの中で測りました。
| 状態 | 使える大きさ | 横のサイズクラス |
|---|---|---|
| 閉じた状態(外側の画面) | 382×644pt | compact |
| 半分折った状態 | 867×635pt | regular |
| 全開 | 867×635pt(画面全体は951×669pt) | regular |
| Split Viewで半分を使う | 385×635pt | compact |
全開でも横幅が951ptではなく867ptなのは、右端の約84ptを時計や電波の表示とカメラが使うためです。半分折った状態でも大きさとサイズクラスは全開と同じで、アプリから見ると区別がつきませんでした。
最初の失敗は、広い画面と狭い画面の切り替えにSwiftUIのViewThatFitsを使ったことです。867ptあるのに、狭い画面用のタブ表示が選ばれました。ViewThatFitsは長文を「改行しない場合の幅」で測るため、2列は入らないと判断したのです。Appleも、画面の向きや機種名ではなくサイズクラスで判断するよう勧めています。サイズクラスで切り替えたら、意図どおりになりました。

分かったこと2:画面の真ん中と折り目はずれる
右端の帯があるので、アプリから見た画面の中央は433ptです。一方、折り目の領域はx=455〜495ptの幅40ptでした。左右に等分すると、右側の文字の書き出しが折り目にかかります。半分折って本のように持つと、ちょうど読みにくい場所です。

折り目の位置は、iOS 27.1で追加されたreservedRegionsで取れます。今回は有効・無効を問わず取得し、その左右に並べました。
GeometryReader { proxy in
// 折り目(division)の領域。全開では「無効」扱いなので includeInactive を付ける
let fold = proxy.reservedRegions(kind: .division, options: .includeInactive).first?.frame
HStack(spacing: 0) {
SourcePane().frame(width: fold?.minX ?? proxy.size.width / 2)
Color.clear.frame(width: fold?.width ?? 0)
SummaryColumn(model: model)
}
}
ただし、まず検討すべきは自前の計算ではありません。AppleはNavigationSplitViewや新しいArrangementViewなどの標準部品が折り目に合わせて自動で調整されると説明しています(今回は未検証)。自前の2列レイアウトを持つアプリで、この方法が役立ちます。
分かったこと3:閉じても答えを消さない
AIが答えを作っている途中で閉じる実験をしました。全開で「要約する」を押し、約4秒後に閉じます。

悪い例では、原文の列を390ptに固定していました。閉じた画面は382ptなので、答えの欄の幅がゼロになりました。さらに、要約の状態を広い画面用と狭い画面用のそれぞれの表示部品に持たせていたため、開き直すと答えが消え、最初から作り直しになりました。
直した例では、答えを持つBriefModelを一番外側に置き、表示の切り替えに巻き込まれないようにしました。閉じている間も生成は続き、開き直しても答えは残りました。シミュレータでは、開閉でアプリが作り直されることはなく、画面サイズが変わる「リサイズ」として扱われました。
struct AdaptiveRootView: View {
@Environment(\.horizontalSizeClass) private var hClass
@State private var model = BriefModel() // 答えはレイアウトの外側に持つ
var body: some View {
if hClass == .regular {
TwoColumnLayout(model: model) // 原文とAIを左右に
} else {
TabbedLayout(model: model) // 原文とAIをタブで切り替え
}
}
}
分かったこと4:開閉の通知は、レイアウトではなく演出に使う
開き具合はonHingeChangeで受け取れます。シミュレータで記録すると、角度と状態は次のように変わりました。
| 動き | 切り替わり |
|---|---|
| 全開から閉じる | 約75〜83°で partiallyOpen から closed へ |
| 閉じた状態から開く | 約15〜21°で closed から partiallyOpen へ |
| 全開になる | 180°ちょうどで fullyOpen。175°ではまだ partiallyOpen |
開くときと閉じるときで切り替わる角度が違い、途中の大きさも50ミリ秒ほどの間に466×562pt、951×553ptと移り変わりました。Appleも、開き具合の値は動きや演出に使い、配置には領域のAPIを使うよう説明しています。
気になった点もあります。Appleの解説動画は「全開では折り目の領域は無効で、幅はゼロ」と説明しています。ところがシミュレータでは、全開でも幅40ptの領域が返り、「有効」への切り替わりも角度の通知より遅れて届くことがありました。この点は実機で確かめるまで、角度の値で自前の判定をしないのが安全です。
.onHingeChange { _, new in
guard let hinge = new.hinge else { return } // ヒンジのない端末では nil
// hinge.status は .closed / .partiallyOpen / .fullyOpen
print(hinge.status, hinge.angle.degrees)
}
分かったこと5:端末内AIは、引用は正確でも要点を読み違える
端末内AIのFoundation Modelsは、Duoシミュレータでも動きました。Appleの開発者フォーラムでは、Mac側でApple Intelligenceがオンであることが条件と案内されています。日本語にも対応していると判定されました。
switch SystemLanguageModel.default.availability {
case .available:
let ja = SystemLanguageModel.default.supportsLocale(Locale(identifier: "ja_JP"))
// ja が false なら日本語で頼まない
case .unavailable(let reason):
// .deviceNotEligible / .appleIntelligenceNotEnabled / .modelNotReady
// AIなしでも原文は読める画面にしておく
}
同じ依頼を10回続けて実行し、出力を原文と1件ずつ照合しました。
| 見たこと | 結果 |
|---|---|
| 根拠として示した引用が原文と一字一句同じ | 10回中10回 |
| 要点に、原文から言えないことや矛盾が混ざった | 10回中4回 |
| 「POSレジ改修と会員データ移行は対象外」に触れた | 10回中0回 |
| 最初の文字が出るまで(2回目以降) | 約1.1〜1.3秒 |
| 答えが完成するまで | 約4.8〜7.0秒 |
矛盾の例は「追加料金が明確でない」(実際は11万円と明記)や、「最低契約期間が6か月なので、長期契約ほど割高」(理屈が逆)です。さらに、この10回とは別の実行で2度、デザイン確認の回数を読み違えました。

引用が正確なので、ぱっと見では信用してしまいます。しかも10回とも、読み手が一番見落としやすい「対象外」の条件を拾いませんでした。だからこそ、Duoの広い画面では原文を隣に出し続け、AIの要点から原文へすぐ戻れる作りにする意味があります。使う側の視点はiPhone DuoをAIでどう使い倒すかの記事にまとめています。
細かい点では、端末内AIはMarkdownの太字で返すことが多く、文字列をそのままTextに渡すと記号の「**」が見えてしまいました。AttributedString(markdown:)を通すと解決します。
Split Viewで2つのアプリを並べたとき
ホーム画面でアイコンを長押しすると「Split Viewで開く」が出て、もう片方のアプリを選ぶと左右に並びました。片側の幅は385ptで、横のサイズクラスはcompactです。つまり、全開のDuoでもSplit Viewの中では閉じた画面に近い表示になります。

Split Viewのまま閉じると外側の画面には片方のアプリだけが出て、開き直すと並びは戻りました。ただし、Apple純正の設定アプリでも、左の列が空白のまま表示されました。RC版のシミュレータ固有の現象かもしれませんが、自分のアプリも「Split Viewで閉じて開く」を必ず試す価値があります。
発売前にやっておきたいチェックリスト
- 閉じた状態(382pt前後)で、固定幅の部品がはみ出さないか
- 半分折った状態で、文字やボタンが折り目にかからないか
- AIの生成中に閉じて開いても、答えと入力が残るか
- Split Viewの片側(385pt前後)でも入力欄と送信ボタンが見えるか
- 端末内AIが使えないときも、原文は読めて操作できるか
- AIの要点から原文の該当箇所へ戻れるか
実機でしか分からないこともあります。端末内AIの本当の速さ、折り目付近の触り心地、長く持ったときの読みやすさです。発売後に実機で確かめ、この記事に追記する予定です。
よくある質問
実機がなくてもDuo向けの開発はできますか?
画面の配置と開閉の動きは、Xcode 27.1のシミュレータで大部分を確かめられました。Apple Developerサイトへの登録は無料で、有料の開発者プログラムに入らなくても試せます。リリースノートには、Duoシミュレータでは多くのアプリ拡張機能を実行・デバッグできないなどの既知の制限が書かれています。
何もしない既存アプリはどうなりますか?
Appleの説明では、iOS 27.1のSDKでビルドすると画面の端まで表示が広がり、古いSDKのままなら時計やカメラの部分を避けて表示されます。どちらの場合も、開閉で画面の大きさは変わるので、固定幅のレイアウトは確認が必要です。
端末内AIは日本語で使えますか?
今回のシミュレータでは、日本語対応と判定され、日本語で答えを返しました。ただし、上限は約4,096トークンで、日本語はほぼ1文字が1トークンと案内されています。長い資料は分割して渡す必要があります。
参考資料
- Apple Developer「Designing for iPhone Duo」(折り目の領域、サイズクラス)
- Apple Developer「iPhone Duoに向けたアプリの準備」
- Tech Talk「Strike a pose with adaptive layouts on iPhone Duo」(reservedRegions)
- Tech Talk「Leverage multiple displays and scenes on iPhone Duo」(onHingeChange、Split View)
- Xcode 27.1 RC Release Notes(シミュレータの既知の制限)
- Foundation Models:言語とロケールの対応
- Apple Developer Forums:シミュレータでのFoundation Models
- Apple Newsroom「iPhone Duoを発表」
関連記事:iPhone DuoをAIでどう使い倒す?/MacBook Air M5 AI開発レビュー/iPhoneからMacのターミナルを遠隔操作する
最終確認:2026年10月7日。シミュレータでの結果であり、実機の動作を保証するものではありません。