Xcode 27.2 の iPhone Duo アクセシビリティテストはどう確認する？2026

Device Hubの読み取り制限とアプリの不具合を分けます

Appleのリリースノートは、Device Hub内のVoiceOverやAccessibility Inspectorなどのアクセシビリティツールが、iPhone Duoの画面内容を伝えられない制限を記載しています。これはDevice Hub上で画面内容を読み取れないことを示すものであり、iPhone Duoに対するすべての検査が不可能、あるいはアプリに不具合があるという意味ではありません。Device Hubでシミュレーターと実機を管理する説明も参照し、利用中の環境と検査経路を記録してください。

最初に、問題がどの検査に影響しているかを特定します。視覚的な画面確認、アプリが提供するアクセシビリティ情報、VoiceOverなどによる操作確認は、目的も確認できる範囲も異なります。ひとつの失敗だけから、ほかの検査まで失敗したと判断しないでください。

• Device Hubが画面内容を伝えない：該当するツール検査は「未検証」として扱い、別の確認経路を探します。
• 画面の要素が重なる、欠ける、操作しづらい：アプリのレイアウト問題として、発生する画面状態と再現手順を確認します。
• ラベルやフォーカス順が期待と異なる：アプリ側のアクセシビリティ情報と、実行時の操作結果を分けて調べます。

画面状態ごとのレイアウト確認を先に行います

外側の画面と内側の画面、展開時と折りたたみ時、画面の向きが変わった状態では、同じ画面でも表示領域や要素配置が異なる場合があります。AppleのiPhone Duo向けデザインガイドを基準に、対象の状態ごとにレイアウトを見てください。特に、画面の端に沿う要素や左右対称でない安全領域を前提にした配置は、実際の表示で確認する必要があります。

各確認では、端末の姿勢、画面の向き、表示中の画面、再現操作、期待する表示、実際の表示を記録します。スクリーンショットは視覚的な差分を示す資料になりますが、読み上げ順やアクセシビリティ要素が正しく提供されている証拠にはなりません。

アプリ側の意味情報と実際の操作を別に検証します

画面上のボタンや入力欄について、アクセシビリティラベル、要素の種類、必要なヒント、フォーカス順序をアプリ側で確認します。AppleのVoiceOver対応に関する開発資料では、アプリがVoiceOver向けの情報を提供するための考え方を確認できます。これらの属性を確認できても、Device HubがiPhone Duoの画面を読み取れたことにはなりません。

検証記録では、次の観点を別々の項目として残します。

• アプリ側の属性：ラベル、要素の種類、ヒント、フォーカス順序。
• 実行時の挙動：読み上げ内容、フォーカス移動、主要な操作が完了できるか。
• ツールの状態：使用したツール、対象環境、画面情報を取得できたか。

Appleのアプリ向けアクセシビリティ監査の説明とアクセシビリティテストのガイドを参照し、属性確認と操作テストを混同しないようにします。監査で問題が検出されなかったことだけを、実機の全操作が問題なく完了する証明として扱うのも避けてください。

シミュレーターの確認結果だけで実機の挙動を確定しません

シミュレーターでは、画面状態の観察やアプリのビルド・実行、属性の確認を行えます。Appleのシミュレーターまたは実機でアプリをビルドして実行する手順に沿って環境を記録しても、実機でのVoiceOver操作やフォーカス移動をすべて確認できたことにはなりません。

対象の実機を使える場合は、チームが定めた重要なユーザー操作を選び、読み上げ、フォーカス移動、操作完了までを確認します。実機を用意できない項目は未検証として残し、代替検査の内容と限界を記録してください。シミュレーターで確認した項目、アプリ属性を調べた項目、実機で操作した項目を同じ「合格」ラベルにまとめないことが重要です。

FAQ：補完検証と判定の考え方

Device Hubで画面を読めない場合、アプリの不具合とどう区別しますか？
Xcodeのバージョン、対象環境、検査の種類を先に記録します。レイアウトの崩れやアプリ側の属性不備はそれぞれ別に確認し、Device Hubの読み取りだけができない場合は、アプリ不具合ではなく未検証として扱います。別経路で確認した結果も、Device Hubの検査結果とは分けて残してください。

VoiceOverやAccessibility Inspectorで確認できない項目は、どう補いますか？
ラベルや要素の種類などはアプリ側の属性検査やアクセシビリティ監査で確認し、VoiceOverの読み上げやフォーカス移動は可能な対象環境で操作して記録します。属性の確認だけで実際の読み上げを証明することはできません。検査方法ごとに「何が確認できたか」を区別してください。

シミュレーターでの確認を実機検査の代わりにできますか？
シミュレーターの確認は画面表示やアプリ側の情報を調べる材料になりますが、実機での操作挙動すべてを証明するものではありません。リリースで重要な操作は、実機での確認ができたか、未検証として残っているかを明示し、実施した環境も記録します。

Device Hubの結果をCIからのリリース判定に使えますか？
Device Hubで読み取りができない項目を、合格ともアプリ不具合とも決めつけないでください。チームの重要項目に対する補完証拠、未検証項目、リスクを受け入れる責任者を記録し、社内で決めた放行基準に沿って判断します。これはAppleが定めた一律の放行要件ではなく、チームの運用判断です。

CI記録では未検証とアプリ不具合を別の状態にします

CIの結果には、Xcodeのバージョン、テスト対象、シミュレーターまたは実機の別、検査の種類、失敗時の証拠を含めます。Device Hubが画面内容を伝えず実行できなかった項目は「未検証」または「代替確認が必要」とし、アプリのテスト合格にも不具合にも分類しないでください。

実行環境を確認する例です。

xcodebuild -version
xcrun simctl list devices booted

CI記録には、実際のコマンド出力と実行環境を添えて、検査結果を次のように分けます。

toolchain: <xcodebuild -version の実際の出力>
target: <実機またはSimulatorと対象名>
check: <layout / semantics / interaction>
status: <verified / not-verified / app-failure>
evidence: <ログまたは画面記録の保存先>

この形式は記録項目の例であり、特定のテストが成功したことを示すものではありません。QA担当、アクセシビリティ担当、リリース担当が、未確認項目と代替確認の結果を照合し、社内基準に照らして放行可否を判断します。Appleのツール対応や開発資料が更新された場合は、現行のXcodeと実際のチーム環境で再確認し、検査フローの変更可否を見直してください。

Mac CIの運用方法は検証頻度と担当範囲で選びます

次の条件分岐で、補完検証の置き場所を決めます。

• 画面レイアウトの差分確認が中心で、実機操作を証明する必要がない場合は、シミュレーターを使った検査をCIに組み込みます。実機の読み上げまで確認したものとしては扱いません。
• チームの重要な操作について実機での挙動を放行条件にしている場合は、実機検証の担当者と証拠の保存先を決めます。実機確認が終わるまでは該当項目を未検証として扱います。
• Device Hubで画面情報を取得できず、その検査を放行条件にしている場合は、別の検証経路を用意するか、責任者が未確認リスクを受容するまで放行を保留します。
• Xcode更新後にツールの挙動が変わった場合は、以前の記録をそのまま流用せず、対象環境で再確認してから手順を更新します。

現在のMacをCIと開発者の作業で共用すると、ジョブの競合や作業環境の違いが出やすく、購入したビルド用Macを増やすと調達・保守の負担も伴います。一方、レンタルは一時的な検証環境やCI用のMacを分けたい場合の選択肢ですが、継続的な高負荷運用や物理端末への直接アクセスが必要な組織では、自社管理の実機が適することもあります。

まずは対象アプリの重要な操作について、検査経路と証拠を整理し、現在のMac CIが必要なXcodeと手順を継続して実行できるか確認してください。短期の補完環境やチーム用のリモートMacが必要なら、NodeMiniのMac利用案内で利用方法を確認できます。購入とレンタルの条件を整理したい場合は、Mac miniの調達案内も比較材料になります。