iOS 27全体に広がるオンデバイスAI:SpotlightとMedia

iOS 26では、オンデバイスの大規模言語モデルはアプリの内部に存在していました。LanguageModelSessionを開いてツールを接続し、渡したコンテキストをモデルが推論する、という形です¹。iOS 27では、その同じモデルが一段上のレイヤーへと移ります。AppleはこのモデルをCore Spotlightに組み込み、アプリの既存の検索インデックスがモデルの根拠（グラウンディング）ソースになるようにしました²。さらにAVFoundationにも組み込み、再生中にデバイスが字幕を文字起こしし翻訳します。アプリ側は推論コードを一行も書く必要がありません³。この変化こそが見出しです。オンデバイスモデルは、アプリ内のAPIにとどまらず、システムサービスへと変わりつつあるのです。コードから直接呼び出すのと同じインテリジェンスが、検索の裏側でも、メディアの裏側でも動いており、すでに使い慣れたフレームワークを通じて手に届きます。

この記事では、それらシステム面のうち2つを、WWDC26のセッションから取り上げます。Core Spotlightを通じたLLM検索(セッション246)と、画面上でスタイルをプレビューできるApple AI生成字幕(セッション256)です。前者を支えるフレームワークの基礎にまだ触れていない場合は、Foundation ModelsオンデバイスLLMの解説とiOS 27のツール呼び出しの記事が下地になります。

TL;DR

• SpotlightSearchToolはFoundation ModelsのToolプロトコルを採用しており、言語モデルがアプリのCore Spotlightインデックスを直接検索して、文脈に応じた応答を生成できます。AppleはこれをiOS、iPadOS、macOS、visionOSで提供します²。
• ツールの設定はおおよそ一行で済みます。LanguageModelSessionに接続すると、モデル自身がクエリを生成し、インデックスに対して実行し、その結果を推論します²。
• 新しいインデックスデリゲートのメソッドsearchableItems(forIdentifiers:)により、完全なCSSearchableItemを復元できます。コンパクトな検索インデックスでは返せないメタデータを、モデルが参照できるようになります²。
• ガイダンスプロファイルは、より小さなモデル向けにツールの検索能力の範囲を絞り込みます。カスタムのパイプラインステージを使えば、インデックス側でモデルに代わって計算(件数、平均、独自のスコアなど)を実行できます²。
• Apple AI生成字幕は、再生中にライブかつローカルで動作し、アプリ側のコードは不要です。音声からの文字起こしと、既存字幕からの言語翻訳という2つの経路をカバーします³。
• AVPlayerViewControllerは生成字幕と新しいプレーヤー内スタイルプレビューを無償で得られます。AVPlayerLayerとAVCaptionRendererは、カスタムプレーヤーUI向けにスタイルプレビューAPIを公開します³。

システムに移ったもの

iOS 26のストーリーは、1つのモデルをプロセス内に置き、それを拡張するためのToolプロトコルを提供するものでした¹。iOS 27はそのモデルを維持しつつ、システムがあなたに代わってモデルを呼び出す場所を2つ追加します。Core Spotlightはモデルが問い合わせできる検索面となり、すでに提供している検索インデックスが根拠付きの文脈に変わります。AVFoundationは文字起こしと翻訳の面となり、元のメディアには同梱されていなかった言語の字幕が得られます。

この2つの機能は、共通のパターンに気づくまでは無関係に見えます。どちらも、Appleがモデルと重い処理を担い、アプリはコンテンツと表示面を担います。あなたは検索可能なアイテムを提供し、モデルがクエリを書きます。あなたは動画を再生し、デバイスが字幕を生成します。インテリジェンスは共有のシステム能力であり、あなたの仕事はそれを実装することから、適切なコンテンツを与え、結果をうまく提示することへと移ります。

Core Spotlightを通じたLLM検索

Appleが示す題材は、すでに州立公園やトレイルを閲覧でき、ハイキングのたびにユーザーが個人的なメモを書けるハイキングトレイルアプリです。開発者は、それらのハイキングについてモデルに自由に質問させたいと考えています。素のLanguageModelSessionはモデル自身が持つ世界知識から答えてしまいますが、それは間違ったソースです。答えは、アプリが実際に把握しているハイキングから得られるべきです。このアプリはすでにすべてのトレイルをCore Spotlightの検索インデックスにインデックス化しているので、解決策は、ツール呼び出しを通じてモデルにそのインデックスへアクセスさせることです²。

それを行うのがSpotlightSearchToolです。Appleはこれを、Toolプロトコルを採用したツールとして紹介しています。言語モデルが文脈に応じた応答生成のために、アプリのCore Spotlight内のコンテンツを直接検索できるようにするもので、iOS、iPadOS、macOS、visionOSで利用できます²。前提となるのは、すでに済ませているはずの作業、つまりCore Spotlightで検索可能なコンテンツを提供しておくことです。これはAppleの過去のセッション「Supporting semantic search with Core Spotlight」の主題でした²⁴。アイテムを提供したら、CoreSpotlightとFoundationModelsをインポートします。Appleによれば、このツールは一行のコードでインデックスを検索できる状態になります。モデルはSystemLanguageModelを使うか、新しいModel Provider APIから提供されるものを選び、SpotlightSearchToolのインスタンスをセッションに追加します²。

import CoreSpotlight
import FoundationModels

// Apple: "in one line of code, the tool is ready to search
// your app's Core Spotlight index."
let session = LanguageModelSession(tools: [SpotlightSearchTool()])

let response = try await session.respond(to: "What hikes have I gone on?")

クエリではなく、軌跡

注目に値する細部は、検索を書くのが誰かという点です。それはあなたではありません。Appleは「What hikes have I gone on?」のような質問の軌跡を、次のように説明します。モデルがSpotlightSearchToolが必要だと判断し、自分でクエリを生成し、Spotlightがそのクエリを実行して結果セットの説明を返し、モデルがその出力を推論して最終的な応答を生成する、という流れです²。セッションの締めくくりの一文は、この変化をはっきりと述べています。開発者はもう検索クエリを書きません。コンテンツを提供し、あとはインテリジェンスに任せるのです²。

ある制約が早い段階で現れますが、Appleはそれについて率直です。テキストコンテンツやHTMLといったSpotlightインデックス内の一部のメタデータは、検索はできても、言語モデルが読める形で復元できない、きわめてコンパクトな表現で保存されています²。モデルは正しいアイテムを見つけられますが、それらに提供されたすべてを読めるわけではありません。解決策は、再インデックス要求を処理するためにすでに実装しているインデックスデリゲートにあります。Appleは、一意な識別子から完全なCSSearchableItemを復元するメソッドを追加しました。これにより、モデルはすべてを読み込むことなく、潜在的には数百万件に及ぶ結果に対して応答を扱えます²。

// On your CSSearchableIndex delegate.
func searchableItems(
    forIdentifiers identifiers: [String]
) async -> [CSSearchableItem] {
    // Return the complete item for each id. The callback is also the
    // place to attach metadata you would not donate for search but
    // want the model to reason over.
    identifiers.compactMap { fullItem(for: $0) }
}

Appleは2つ目の点を明確に述べています。検索のために提供する意味はないがモデルの推論には役立つメタデータをアプリが持っている場合、このデリゲートのコールバックこそ、その追加属性をアイテムに設定してモデルに見せる場所です²。

結果の表示

Appleは2つの表示モードの間に明快な線を引きます。セッションの応答は結果セットに対する簡潔な説明であり、アシスタント風のインターフェースが見せたいのはこれです。リスト形式の表示には、結果そのものがSpotlightSearchToolから直接得られます。Appleはこれを、結果セットが大きいときに検索可能なアイテムへアクセスする最良の方法と呼んでいます²。検索の応答は非同期シーケンスとして届き、ツール呼び出しが完了するまで、それぞれが結果のバッチを伴う可能性があります。モデルは最終的な答えに至るまでにツールを複数回呼び出すことがあるため、Appleは各応答のqueryTokenを使って、UIをいつ更新すべきか判断するよう勧めています²。

選んだモデルに合わせたカスタマイズ

SpotlightSearchToolは、テキストに対するセマンティック検索から、日付・人物・場所に対する構造化検索まで、幅広い能力を備えています²。Appleはその能力面を、実行するモデルに合わせるための3つのレバーを示します。1つ目はガイダンスプロファイルです。小さなモデルにツールの能力すべてを渡すと、持っていない文脈を浪費してしまうため、GuidanceProfileはガイダンスをアプリが必要とするものだけに絞り込みます。モデルが考慮すべきメタデータ属性の正確なリストにまで絞り込め、ツール作成時に動的なガイドレベルを設定できます²。より制限された文脈サイズを持つオンデバイスモデルに対するAppleの助言は、よりシンプルな検索能力に向けた焦点を絞ったガイダンスです²。

2つ目のレバーは参照解決です。アプリが人物間の関係を提供しており、ユーザーがトレイル上の他の人々について尋ねた場合、モデルは「その人」が誰を指すのかを知る必要があります。Appleの答えは、ユーザーの身元に関連する連絡先情報を返すコンタクトリゾルバーで、ツールはそれをインデックス内のメタデータと照合します²。

3つ目のレバーは、検索を計算へと変えるものです。「今年は何本のトレイルを歩いたか、そして月ごとに平均で何マイルか?」のような複雑な要求に対して、Appleによれば、モデルは単純なクエリを見送り、インデックスへのクエリと結果セットに対する計算をまとめたパイプライン検索を選ぶことがあります²。モデルは質問をステージに分解します。完了したハイキングを探す検索、月ごとのテーブルを構築する集計ステージ、そして件数に対して平均を計算するステージです²。パイプラインステージはGenerableなので、モデルはプロンプトから必要に応じてステージを生成し、アプリは独自のカスタムステージを登録できます²。Appleの例は、各アイテムのメモから計算される幸福度スコアで、感情分析や5段階評価によって求められるかもしれません。Guideプロパティが、どの結果を優先すべきかをモデルに伝えます²。

// Apple's example: a Generable pipeline stage that scores items so the
// model reasons over the top-scoring results, not the raw set.
@Generable
struct HappinessScoredTrail {
    let item: CSSearchableItem
    @Guide(description: "Prefer higher scores; 5-star hikes rank highest.")
    let happinessScore: Double
}
// Register the stage on the tool's configuration.

Appleはこの節を、実装ではなく検証で締めくくり、Evaluationsフレームワークを指し示します。モデルがどれだけ的確にツールを呼び出し、その応答がどれだけ有意義かを測るもので、ハイキングアプリの例では結果のカバレッジを指標としています²。その評価ループはそれ自体が1つの主題であり、AppleのEvaluationsフレームワークの記事で扱っています。

オンデバイスで生成される字幕

メディア面は、同じ原則を別の角度から示します。Apple AI生成字幕は、メディアの再生中に、デバイス上でライブかつローカルに作成されます³。セッション256での位置づけはアクセシビリティを第一とするものです。字幕は、耳が聞こえない人や聞こえにくい人にとって、話されている台詞を追う人にとって、そしてその場で音声を聞けない誰にとっても重要です。コンテンツが、視聴者の理解できる言語を欠いた状態で配信されたとき、デバイスがその隙間を埋められます³。

Appleは2つの経路を説明します。1つ目は音声文字起こしです。元の音声がオンデバイスの音声テキスト変換モデルに入り、字幕が出てきます³。2つ目は言語翻訳です。既存の字幕(Appleの例では英語)がオンデバイスの翻訳モデルに入り、イタリア語など別の言語の字幕を生成します³。コンテンツ制作者が手作業で書いた制作済み字幕は、優先され変更されないままです。生成字幕が追加するのは言語だけです³。この同じオンデバイス翻訳能力は、Translationフレームワークを通じて開発者に直接提供されます。

導入にとって重要なのは、これを有効にするために何も実装しないという点です。Appleは、生成字幕が動画再生中に自動的に利用できると述べています³。これはライブTVチャンネルを含むHTTPライブストリーミング、ビデオオンデマンド、スポーツのようなライブイベント、そしてアプリ同梱やダウンロード済みメディアといったファイルベースのコンテンツをカバーします³。プロのコンテンツも、利用者が作成したコンテンツ(iPhoneのカメラ撮影、ソーシャル動画)も、どちらも対象です³。

ローンチ時のマトリクスは限定的で、正確に読む価値があります。iOSとmacOS 27から、英語音声から英語字幕を生成でき、これはtvOSとvisionOS 27でも対応します³。それに加えて、iOSとmacOSでは英語字幕から複数の字幕言語を生成できます³。つまり、文字起こしはまず4つのプラットフォームで英語から英語へ、翻訳は最も大きな2つで英語から広がります。

あなたの作業が実際にあるところ

生成字幕は有効化のコストがかからないので、あなたの労力は選択UIに向かいます。Appleの指針は明快です。再生中に字幕選択UIを提供してください³。Appleがどれだけ用意してくれるかの多い順に、3つの選択肢があります。

• iOSのAVPlayerViewController(およびmacOSのAVPlayerView)は、字幕選択とプレーヤーコントロールを完全に実装します。追加で何もする必要はありません³。
• AVLegibleMediaOptionsMenuControllerは、プレーヤーコントロールなしで選択用のコントロールと挙動を提供します。すでにプレーヤーUIがあり、メニューだけが必要な場合に適しています³。
• メディア選択用のカスタムコントロールは、メニューをアプリの他の部分に合わせたいときに使います³。

Appleのデモでは、生成されたオプションにきらめきのシンボルと「Translated」という語が付き、ユーザーが制作済みトラックと見分けられるようになっています³。

スタイルプレビュー

このセッションの2つ目の機能は提示です。設定アプリでは何年も前から字幕スタイルを選んだり作成したりできましたが、Appleの主張は、動画の途中でライブプレビュー付きにスタイルを変更できるほうが、再生を離れて設定を探し回るよりも簡単で、かつアクセシブルだということです³。ユーザーが設定で定義したのと同じスタイルが、カスタムのものも含めて、プレビュー付きでプレーヤーのスタイルメニューに表示されます³。

AVPlayerViewControllerは、スタイルプレビューとプレーヤーコントロールをそのまま実装します³。カスタムプレーヤー向けには、AVPlayerLayerがスタイルプレビューAPIを公開し、レンダリングを自分で引き受けるならAVCaptionRendererがプレビューを提供できます³。AppleのAVPlayerLayerのフローはこうです。各システムスタイルはプロファイルIDを持つので、プロファイルIDですべてのスタイルを取得し、その名前でUIを満たし、ユーザーが1つを選んだときにプレビュー関数を呼びます。選んだスタイルで新しい字幕が表示され、その間、既存の字幕は干渉しないように自動で隠れます。テキストパラメータにnilを渡すとローカライズされたシステムテキストが表示され、位置パラメータはコントロールを避けるようにプレビューをずらします。新しいスタイルごとにこの関数を呼び直し、選択が終わったらプレビューを停止し(これでアクティブな字幕が復元されます)、選ばれたスタイルをシステム上のすべての字幕に設定します³。

導入の仕方

Spotlight検索の場合:

1. まずコンテンツをCore Spotlightに提供します。ツールはインデックスを検索するので、提供がなければ検索するものがありません²⁴。
2. SpotlightSearchTool()をLanguageModelSessionに接続し、モデルを選びます。SystemLanguageModelか、Model Provider APIのものです²。
3. インデックスデリゲートにsearchableItems(forIdentifiers:)を実装して、完全なアイテムを返し、コンパクトなインデックスでは復元できないモデル専用のメタデータを付与します²。
4. アシスタントビューにはセッションの応答を表示し、リストビューにはツールからCSSearchableItemの結果を読み取り、各応答のqueryTokenで更新します²。
5. オンデバイスモデルを実行するなら、GuidanceProfileで能力の範囲を絞り、要求が大きな集合に対する集計やスコアリングを必要とするときにだけパイプラインステージに手を伸ばします²。

生成字幕の場合:

1. この機能を有効にするものは何もありません。再生中に自動で動作します³。
2. プレーヤーがAVPlayerViewController、AVLegibleMediaOptionsMenuController、または独自のコントロールを通じて字幕選択UIを公開していることを確認します³。
3. AVPlayerViewControllerでスタイルプレビューを無償で追加するか、AVPlayerLayerのプレビューAPIをカスタムプレーヤーに組み込みます³。
4. 言語を約束する前に対応マトリクスを読んでください。4つのプラットフォームでの英語から英語への文字起こし、iOSとmacOSでの英語ソースの翻訳です³。

FAQ

iOS 27のSpotlightSearchToolとは何ですか?

これはFoundation Modelsのツールで、Toolプロトコルを採用しており、言語モデルがアプリのCore Spotlightインデックスを直接検索し、その結果を応答生成に使えるようにします。AppleはこれをiOS、iPadOS、macOS、visionOSで提供します。SpotlightSearchToolのインスタンスをLanguageModelSessionに接続すると、あなたが書くのではなくモデル自身が検索クエリを生成します²。

検索クエリは自分で書く必要がありますか?

いいえ。Appleの位置づけでは、開発者はもう検索クエリを書きません。コンテンツを提供し、あとはモデルに任せます。モデルがツールが必要だと判断し、クエリを生成し、Spotlightがそれを実行して結果セットの説明を返し、モデルがその出力を推論して答えを導きます²。

なぜモデルは提供したメタデータをすべて見られないのですか?

テキストコンテンツやHTMLといった一部のSpotlightメタデータは、検索はできても読める形では復元できない、きわめてコンパクトな形で保存されています。モデルに全体像を与えるには、インデックスデリゲートにsearchableItems(forIdentifiers:)を実装して完全なCSSearchableItemを返し、そのコールバックを使ってモデル専用の追加属性を付与します²。

生成字幕を得るために何か実装する必要がありますか?

いいえ。Appleは、生成字幕が動画再生中に自動で利用でき、デバイス上でライブかつローカルに作成されると述べています。あなたの作業は選択UIと、任意でプレーヤー内のスタイルプレビューであり、推論ではありません³。

ローンチ時に生成字幕はどの言語に対応しますか?

iOSとmacOS 27から、英語音声から英語字幕を生成でき、これはtvOSとvisionOS 27でも対応します。これとは別に、iOSとmacOSでは英語字幕から複数の字幕言語を生成できます。つまり、文字起こしは4つのプラットフォームで英語から英語へ、翻訳はiOSとmacOSで英語から広がります³。

生成字幕とSpotlight検索はプライベートですか?

どちらもデバイス上で動作します。生成字幕はメディアの再生中にライブかつローカルで作成され³、SpotlightSearchToolはオンデバイスモデルを通じてアプリのローカルなCore Spotlightインデックスを問い合わせます¹²。Appleがシステム実装を供給することで変わるのは、誰がそれを保守するかであり、どこで動くかではありません。

Apple Ecosystemクラスタの全体像です。SpotlightSearchToolが採用するToolプロトコルとFoundation ModelsオンデバイスLLM、このようなツールをモデルがどれだけ積極的に呼び出すかを制御するiOS 27のツール呼び出し制御、バックグラウンド実行・同期・Spotlightのための並行するiOS 27のApp Intents面、そしてシステムモデルの下層を担うCore AI:Apple Siliconでモデルを動かすです。ハブはApple Ecosystemシリーズにあります。AIエージェントを伴うiOSのより広い文脈については、iOSエージェント開発ガイドをご覧ください。