アクセシビリティをプラットフォームへ：Personal Voice、Live Speech、Eye Tracking、Music Haptics

Personal Voice（iOS 17）、Live Speech（iOS 17）、Eye Tracking（iOS 18）、Music Haptics（iOS 18）、Vocal Shortcuts（iOS 18）。Appleが近年リリースしてきたアクセシビリティ機能の流れには一貫性があります。かつてはサードパーティアプリ、専用ハードウェア、特殊な統合を必要としていた機能が、OSが処理するプラットフォーム機能へと変わってきているのです。その結果、ユーザーがインストールすべきアプリは減り、開発者の関わり方も変わりました。機能を自分で作り込むのではなく、システム側のサーフェスに対してオプトインする（Personal Voiceの認可）か、すべてのアプリがすでに満たすべき標準に従う（Eye Trackingに対応する適切なアクセシビリティラベルやヒットターゲット）かのどちらかです。

本記事では、各機能における開発者向けサーフェスを順に見ていきます。視点は「この機能をどう実装するか」ではなく、「自分のアプリがこの機能に参加するために何をすべきか」です。機能はAppleがすでに作っており、問われているのはアプリ側の準備が整っているかどうかなのです。

TL;DR

• Personal Voice（iOS 17以降）は、ユーザーが15分間音声を録音することで、AACや支援的コミュニケーションアプリ向けのオンデバイス合成音声を作成できる機能です。アプリはAVSpeechSynthesizer.requestPersonalVoiceAuthorization()で統合し、voiceTraitsの.isPersonalVoiceを確認します¹。
• Live Speech（iOS 17以降）はシステム機能です。ユーザーがテキストを入力し、デバイスがそれを（任意でPersonal Voiceを使って）読み上げます。アプリがLive Speechを直接統合することはありません。この機能は通話、FaceTime、対面コミュニケーションを横断してOSレベルで動作します。
• Eye Tracking（iOS 18以降）は、フロントカメラを通じた視線とDwell Controlでデバイスを操作します。アプリが対応するには、アクセシビリティ標準（適切なアクセシビリティラベル、ヒットターゲットのサイズ、フォーカス順序）に従います。多くのアプリでは専用のAPIは不要です²。
• Music Haptics（iOS 18以降）は、MediaAccessibility.framework内のMAMusicHapticsManager APIを介して、音楽再生をオーディオに同期したTaptic Engineの振動に変換します。Info.plistにMusicHapticsSupportedを設定し、アクティブなNow Playingアプリとなり、ISRCを提供すれば、どんな音楽アプリでも統合できます³。
• Vocal Shortcuts（iOS 18以降）は、ユーザーがカスタムフレーズを割り当ててSiri Shortcutsをトリガーできる機能で、サードパーティのAppIntentアクションも対象になります。この機能はApp Intentsの採用と相乗効果を発揮します（App IntentsはAppleが提供するアプリへの新しいAPIで扱っています）。

Personal Voice：認可パターン

Personal Voiceは、開発者向けサーフェスが最も明確なアクセシビリティ機能です¹。ユーザーは「設定 > アクセシビリティ > Personal Voice」からオプトインし、ランダム化されたプロンプトを読み上げる15分程度の音声を録音します。すると、デバイスがオンデバイス機械学習を使ってローカルに合成音声を生成します。この音声はユーザー個人のもので、ユーザーが明示的にiCloudペアリング済みデバイスへ共有しない限り、デバイスから外には出ません。

アプリがAVSpeechSynthesizerでユーザーのPersonal Voiceを利用するには、次の手順が必要です。

1. AVSpeechSynthesizer.requestPersonalVoiceAuthorization(completionHandler:)で認可をリクエストする。
2. ユーザーがシステムプロンプトで許可するのを待つ。
3. 許可されたら、AVSpeechSynthesisVoice.speechVoices()をクエリし、voiceTraitsに.isPersonalVoiceを含む音声をフィルタリングする。
4. 取得したAVSpeechSynthesisVoiceを、他の音声と同様にAVSpeechUtteranceで使用する。

import AVFoundation

AVSpeechSynthesizer.requestPersonalVoiceAuthorization { status in
    guard status == .authorized else { return }

    let personalVoices = AVSpeechSynthesisVoice.speechVoices().filter { voice in
        voice.voiceTraits.contains(.isPersonalVoice)
    }

    if let voice = personalVoices.first {
        let utterance = AVSpeechUtterance(string: "Hello.")
        utterance.voice = voice
        synthesizer.speak(utterance)
    }
}

この認可は繊細です。Appleのガイダンスでは、Personal Voiceは主に拡張・代替コミュニケーション（AAC）アプリや類似の支援的な文脈に使われるべきとされています。汎用的な読み上げアプリがPersonal Voiceの認可をリクエストしても、ユーザーに拒否される可能性が高く、App Store審査でも問題視されるかもしれません。

ここではオンデバイスファーストのアーキテクチャが重要になります。ユーザーの音声トレーニングデータと、生成された音声モデルは、ユーザーが明示的にiCloud共有をオプトインしない限り、デバイスのセキュアエンクレイブ領域から決して外に出ません。Personal Voiceを使うアプリのApp Storeプライバシー栄養ラベルでは、データ収集はゼロと表示されるべきです。合成はローカルで行われ、音声出力はネットワークではなくスピーカーへ流れるからです。

Live Speech：統合不要のシステム機能

Live SpeechはPersonal Voiceに対応するコンシューマー向け機能です⁴。ユーザーがテキストを入力し、デバイスがそれを読み上げます。任意でPersonal Voiceを使うこともできます。Live Speechは通話、FaceTime、Mac SharePlay、そしてデバイススピーカーを通じた対面の会話で動作します。

アプリがLive Speechを直接統合することはありません。この機能はOSレベルで動作し、システムのLive Speech UIから入力されたテキストを取り込んでオーディオスタックにルーティングします。アプリの視点から見るとLive Speechは透明です。通話に流れる音声ストリーム（または対面利用時にデバイススピーカーから流れる音声）はユーザー本人のように聞こえますが、アプリ側のコードは一切関与しません。

アプリ開発者にとっての示唆は次の通りです。アプリが音声を扱う場合（通話アプリ、ビデオチャットアプリ、アクセシビリティ補助アプリ）、アプリのオーディオパイプラインはシステムのオーディオルーティングを尊重する必要があります。そうしないとLive Speechが同じチャネルから出力できません。システムレベルの重ね合わせ音を考慮せず、オーディオセッションに対して排他的制御を主張するアプリは、Live Speechを壊してしまいます。

Eye Tracking：標準準拠で動く機能

Eye TrackingはiOS 18で導入された機能で、視線方向とDwell Controlを使ってiPhoneやiPadを操作できます²。ユーザーは数秒でフロントカメラをキャリブレーションし、その後は要素を見るだけでUIをナビゲートします。要素に対して設定したDwellタイムアウトの間視線を保持すると、その要素がアクティブになります（タップ、スワイプなど他のジェスチャーをSwitch Controlで設定可能）。

実装はオンデバイスで行われます。フロントカメラがオンデバイス機械学習で視線データを処理し、データはデバイスから外に出ません。追加のハードウェアも必要ありません。

ほとんどのアプリでは、Eye Trackingに対応するために専用コードを書く必要はありません。標準のアクセシビリティ慣習に従うUIであれば、機能はそのまま動作します。

• 適切なヒットターゲット。 Apple Human Interface Guidelinesでは、タップ可能な要素のヒットターゲットは最小44pt × 44ptと規定されています。Eye Trackingはこの基準に従います。最小サイズより小さいボタンは、Dwellで正確にターゲットしづらくなります。
• アクセシビリティラベル。 すべてのインタラクティブな要素に、有用なaccessibilityLabel（SwiftUI）またはaccessibilityLabelプロパティ（UIKit）を設定すべきです。Eye Trackingは、ユーザーが要素の近くで視線を留めると、ラベルをツールチップ相当として表示します。
• 論理的なフォーカス順序。 MacのTabキーやtvOSのフォーカスエンジンが利用するフォーカス順序は、Eye Trackingが要素間を移動するときと同じものです。SwiftUIの標準レイアウトプリミティブを使うアプリでは自動的に整います。フォーカス挙動をオーバーライドするアプリでは検証が必要です。
• Dwellに優しいモーダルパターン。 モーダル外のタップで自動的に消えるモーダルは、Dwellポイントが一瞬モーダル領域から外れることがあるEye Trackingユーザーを困らせます。モーダルUIを持つアプリは、明示的な閉じるボタンを用意すべきです。

特定のビュー（機密コンテンツ、複雑なジェスチャー操作のゲームなど）でEye Trackingをオプトアウトしたい場合、Eye Tracking専用のドキュメント化されたオプトアウトAPIは存在しません。この機能は表示されているあらゆるコンテンツで動作し、アプリの責任は標準のアクセシビリティサーフェスを正しく整えることです。

iOSアプリの3つのサーフェスに関する記事では、より広いパターンを扱っています。可視UIが1つ目のサーフェス、App Intentsが2つ目、アクセシビリティが3つ目です。Eye Trackingは可視UIサーフェスに参加します。このサーフェスを正しく整えることが、Eye Tracking、Switch Control、VoiceOver、Voice Controlを同時に有効化することにつながるのです。

Music Haptics：オーディオとハプティックの架け橋

Music Hapticsは、音楽再生をオーディオに同期したTaptic Engineの振動に変換します³。この機能はユーザーごとにオプトイン（設定 > アクセシビリティ > Music Haptics）で、Apple Musicに限らず、APIを正しく統合したあらゆる音楽アプリで動作します。

開発者向けサーフェスはMediaAccessibility.frameworkのMAMusicHapticsManager（iOS 18以降）にあります。音楽アプリは次の3ステップでMusic Hapticsを統合します。

1. Info.plistでサポートを宣言する。 MusicHapticsSupportedキーに値YESを追加します。これによりシステムはアプリがMusic Hapticsレンダリングに参加するかを判別します。
2. アクティブなNow Playingアプリになる。 アプリはMPNowPlayingInfoCenter.default().nowPlayingInfoを通じて再生メタデータを公開し、Now Playingオーディオセッションを所有する必要があります。システムはハプティック合成を駆動するために、明確にアクティブなNow Playingソースを必要とします。
3. 再生中のトラックのISRCを提供する。 MPNowPlayingInfoPropertyInternationalStandardRecordingCodeキー（International Standard Recording Code）により、システムはオーディオに対応するハプティックトラックを検索できます。AppleはISRCをキーとしたハプティックアセットライブラリを管理しており、ISRCのないトラックではハプティックは得られませんが、それ以外のNow Playing統合は引き続き機能します。

import MediaPlayer
import MediaAccessibility

// Info.plist: MusicHapticsSupported = YES (boolean)

let info: [String: Any] = [
    MPMediaItemPropertyTitle: track.title,
    MPMediaItemPropertyArtist: track.artist,
    MPNowPlayingInfoPropertyInternationalStandardRecordingCode: track.isrc,
    // ... other now-playing properties
]
MPNowPlayingInfoCenter.default().nowPlayingInfo = info

この統合はあらゆる音楽アプリに適用されます。AVAudioEngine上に構築されたストリーミングクライアント、カスタムデコーダーを持つDJアプリ、サンプル再生を行う音楽学習アプリなどが該当します。制約はISRCとアクティブなNow Playing役割であり、基盤となるオーディオAPIではありません。ISRCを持たないアプリ（メタデータのないユーザーアップロード音楽、生成音楽など）は単にハプティックを得られないだけで、それ以外の再生統合には影響しません。

隣接領域のアプリ（リズムゲーム、音楽ビジュアライゼーション、効果音エンジンなど）にとって、Music Hapticsはそもそも対象外です。これらのアプリは、自身のオーディオソースに同期した手作業のハプティックパターンとともにCHHapticEngineを直接使うのが適切です。

Vocal Shortcuts：アクセシビリティとApp Intentsの交差点

Vocal Shortcutsは、ユーザーがカスタム音声フレーズをSiri Shortcutsに割り当てられる機能で、サードパーティのAppIntent型に紐づいたものも含みます⁵。ユーザーは、ToDoアプリが登録したAddTodoIntentをトリガーする「マーカー」というフレーズを設定できます。Siriのウェイクフレーズを呼び出さずに「マーカー」と言うだけで、どこにいてもインテントが起動するのです。

統合には、本クラスタで詳しく扱ってきたApp Intentsフレームワークを使います。ただし見落としやすい構造的なポイントが1つあります。アプリは明示的なphrasesを持つAppShortcutエントリを公開するAppShortcutsProviderを宣言する必要があります。素のAppIntentはシステム上には存在しますが、Shortcutsエディタでユーザーが手動でショートカットを組み立てたときにしか起動できません。AppShortcutsProviderは、ユーザーがVocal Shortcut、アクションボタン、Siri、Spotlightにすぐ割り当てられる、システムから可視のショートカットを登録します。

struct TodoShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: AddTodoIntent(),
            phrases: [
                "Add a todo in \(.applicationName)",
                "\(.applicationName) marker"
            ],
            shortTitle: "Add Todo",
            systemImageName: "checkmark.circle"
        )
    }
}

phrases配列は、システムがSiriおよびVocal Shortcutsに公開する内容です。プロバイダーが用意されていれば、App Intentは音声起動の対象としてただちに有効になります。なければ、インテントは手動のShortcuts設定経由でしか動作せず、その経路は長く、多くのユーザーはそこまでたどり着きません。

このパターンはApp IntentsやApp Intents vs MCP Toolsと相乗します。ユーザーのApple Intelligenceサーフェスにふさわしい場所を勝ち取ったApp Intentが、ユーザーがどう起動するかを宣言するAppShortcutsProviderと組み合わさることで、Vocal Shortcutのターゲットとしてもふさわしい位置を獲得します。「App Intentsは『アプリができること』に対するシステム横断的な契約である」というクラスタの主張は、ここでも当てはまります。Vocal Shortcutsは、その同じ契約の別の消費者なのです。

横断するパターン：標準そのものが統合である

上述のアクセシビリティ機能には、構造的な共通点があります。それぞれが、アプリがすでに満たすべき標準の上に構築されており、アプリが明示的に協力しなければならないケース（Personal Voiceの認可、MPMusicPlayerControllerを介したMusic Haptics）に対しては小さなオプトインAPIサーフェスが用意されているという点です。

開発チームへの示唆はこうです。アクセシビリティ作業は、アプリ出荷後に行う独立したワークストリームではありません。アプリのアクセシビリティラベル、ヒットターゲット、フォーカス順序、標準のシステムAPI利用こそが、Eye Trackingを動作させ、Live Speechを正しくルーティングし、Music Hapticsを起動させ、Vocal Shortcutsに適切なインテントを露出させるのです。サイクルの最後にアクセシビリティをチェックボックスとして扱うアプリは、VoiceOverでは動くがEye Trackingでは動かない、あるいはLive Speechが追従できない方法でオーディオをルーティングする機能を出荷することになります。

クラスタの書かないと決めていることでは、書かないことをポジショニングの一手として論じました。アクセシビリティにおける「拒否」はその逆です。「これを追加することを拒否する」ではなく「すべてのiOSアプリが満たすべき標準を満たさないものを出荷することを拒否する」のです。

カスタムなアクセシビリティコードが必要になるケース

標準準拠のパターンですべてをカバーできない3つのケースがあります。

カスタム描画サーフェス。 描画アプリ、チャート、カスタムレンダリングのゲームUIは、SwiftUI/UIKitのアクセシビリティツリーをバイパスします。アプリはUIAccessibilityCustomAction、UIAccessibilityElement、および各意味のある要素に対する明示的なアクセシビリティプロパティを使って、独自のアクセシビリティツリーを構築する必要があります。Eye Tracking、VoiceOver、Switch Controlはいずれもアクセシビリティツリーが正しく構築されていることに依存します。

リアルタイムのジェスチャー操作。 連続的なジェスチャー入力（描画、ドラッグで照準合わせ）を持つゲームは、Dwellベースやスイッチベースの入力に自然にはマッピングできません。正しいアプローチは、アクセシビリティシステムと戦うのではなく、代替の操作スキーム（オプションとしてのボタンベース入力）を提供することです。

アクセシビリティ専用機能を持つアプリ。 AACアプリ、音声拡張アプリ、手話通訳アプリなどです。これらのアプリ自体がアクセシビリティ製品であり、システムフレームワーク（Personal Voice、Speechフレームワーク、手話検出のためのVisionフレームワーク）と深く統合します。統合作業は実質的かつ意図的なものです。

このパターンがiOS 26以降のアプリにとって意味するもの

要点は3つあります。

1. アクセシビリティへの参加は、ほとんどが標準準拠であり、機能の作り込みではない。 Appleはアクセシビリティをプラットフォーム層へと移してきました。やるべきは、Eye Tracking、Switch Control、VoiceOver、Voice Controlがすべて依存している標準（適切なラベル、ヒットターゲット、フォーカス順序、システムオーディオルーティング）にアプリが従っているか確認することです。

2. Personal Voice統合は繊細である。 アプリに本物のAACユースケース（支援的コミュニケーション、音声拡張、アクセシビリティツール）があれば、Personal Voice認可は適切な統合です。汎用アプリの場合、Personal Voice認可をリクエストすると、ユーザーを助けるよりも混乱させる可能性が高くなります。

3. App Intentsはアクセシビリティのインフラストラクチャである。 整理されたきれいなAppIntentは自動的にVocal Shortcutsの対象となり、Shortcuts経由でアクセシブルなUIサーフェスを得て、システムの音声駆動・スイッチ駆動の操作モードと統合されます。App Intents採用に関するクラスタの主張は、アクセシビリティにも当てはまります。

Apple Ecosystemクラスタの全記事：型付きApp Intents、MCPサーバー、ルーティングの問い、Foundation Models、ランタイム vs ツーリングLLMの違い、3つのサーフェス、単一の真実の源パターン、2つのMCPサーバー、Apple開発のためのフック、Live Activities、watchOSランタイム、SwiftUIの内部、RealityKitの空間メンタルモデル、SwiftDataスキーマの規律、Liquid Glassパターン、マルチプラットフォーム出荷、プラットフォームマトリクス、Visionフレームワーク、Symbol Effects、Core MLによる推論、Writing Tools API、Swift Testing、Privacy Manifest、書かないと決めていること。ハブはApple Ecosystemシリーズにあります。iOSとAIエージェントというより広い文脈については、iOS Agent Developmentガイドを参照してください。

FAQ

Eye Trackingに対応するためにコードを書く必要はありますか？

ほとんどのアプリでは不要です。Eye Trackingは、標準のアクセシビリティ慣習に従うあらゆるUIで自動的に動作します。適切なヒットターゲット（最小44pt）、有用なアクセシビリティラベル、論理的なフォーカス順序、標準のシステムコントロールがあれば十分です。独自にUIを描画するアプリ（カスタムビュー、ゲーム、チャート）は、UIAccessibilityElementやSwiftUIのアクセシビリティモディファイアを使ってアクセシビリティツリーを明示的に構築する必要があります。その作業はVoiceOverやSwitch Controlでアプリを動作させるためにも必要なものです。

汎用の読み上げアプリでPersonal Voiceを使えますか？

システムはAVSpeechSynthesizer.requestPersonalVoiceAuthorization()によってそれを許可しますが、Appleのガイダンスおよび App Store審査プロセスでは、Personal Voiceは支援的な文脈（AAC、拡張・代替コミュニケーション）に使うことを強調しています。Personal Voice認可をリクエストする汎用の読み上げアプリは、2つの困難に直面します。1つはユーザーが認可を与える可能性が低いこと、もう1つは審査が不適切な利用としてリクエストを差し戻す可能性があることです。本当に支援的なユースケースであれば統合は適切です。汎用的なナレーション用途であれば、システム音声が適切なツールです。

Live SpeechとPersonal Voiceの違いは？

Personal Voiceは、ユーザー本人のように聞こえるオンデバイス合成音声です。Live Speechは、ユーザーが入力したテキストを（システム音声またはPersonal Voiceで）デバイスに読み上げさせるシステム機能です。両者は補完関係にあります。Personal Voiceが声を提供し、Live Speechが入力から音声化までのUIを提供します。アプリはSpeech Synthesizer APIを介してPersonal Voiceを統合します。Live Speechはアプリからは見えず、OSレベルで動作します。

AVAudioEngineを使っている音楽アプリにMusic Hapticsを追加するには？

可能です。Music Hapticsは特定の再生APIに縛られていません。統合手順は次の通りです。Info.plistにMusicHapticsSupported = YESを追加し、MPNowPlayingInfoCenter.default().nowPlayingInfoを通じて再生中トラックのメタデータを公開（システムがアプリをアクティブなNow Playingソースとして認識するため）し、MPNowPlayingInfoPropertyInternationalStandardRecordingCodeにトラックのISRCを含めます。あとはシステムがハプティック合成を処理します。ISRCのないトラックではハプティックは得られませんが、それ以外のNow Playing統合は通常通り機能します。

Vocal Shortcutsで最良の体験を提供するApp Intent設計は？

4つの原則があります。第1に、アプリ向けにAppShortcutsProviderを宣言し、音声でアクセスさせたいインテント用にAppShortcutエントリを登録します。プロバイダーがなければ、インテントは手動でのShortcuts編集を経てしかVocal Shortcutsに到達しません。第2に、titleとshortTitleは説明文ではなく、短い動詞句（「Add Todo」「Start Timer」など）にすべきです。第3に、パラメータはオプションかデフォルト値を持たせ、ユーザーがすべてのフィールドを指定せずにインテントを起動できるようにします。第4に、descriptionはインテントの効果を説明する明確な1文にすべきです。これは、ユーザーが割り当てるフレーズを選ぶ際に文脈として表示されます。

References