Siri対応は「声のUI追加」ではなく、アプリを索引化する改修になった
AppleのWWDC26セッション「Make your app available to Siri」は、Siri AI対応を派手な会話機能ではなく、既存アプリのデータ、操作、画面文脈をシステムへ渡すための改修として見せています。Calendarアプリのコード沿いに、App Schemas、IndexedEntity、Spotlight、onscreen awareness、OpenIntentを順に入れる構成です。Siriを使えるアプリにする作業は、音声コマンドを足すことではなく、アプリの中身をApple Intelligenceが辿れる形へ整えることに近づいています。
App Schemasは、Siriに「このアプリの中身」を説明するための型になる
このセッションでAppleが最初に置くのは、Siriの返答文ではありません。カレンダー、参加者、イベントといったアプリ内の対象をAppEntityとして表し、Calendar domainのApp Schemaへ当てはめる作業です。Appleは、App Schemasがentity、parameter、outputをSiriがすでに理解できる構造で記述すると説明しています。
重要なのは、ここで自然言語処理をアプリ側で作らないことです。セッションでは、schemaを採用すれば「custom natural language」なしでSiriがイベントを検索し、内容を答え、操作へつなげられると示しています。Siri AI対応は、会話の文言を増やすより先に、アプリのデータモデルを標準化された語彙へ写す作業になります。
Spotlightへのdonationが、会話より先に必要な下地になる
CalendarEntityやEventEntityでは、AppleはIndexedEntityへの準拠とSpotlightへのdonationを強調しています。カレンダーを作成、更新、削除したときにindexAppEntitiesやdeleteAppEntitiesで索引を保つ流れまでコード沿いに見せるのは、Siriの知能をアプリ内部の最新データへ接続するためです。
この設計では、Siriが賢く答えられるかどうかは、モデルの能力だけでは決まりません。イベント名、メモ、参加者、場所といったアプリ側の内容が、検索可能なentityとして正しく寄付されているかに依存します。AppleのAI導線は、チャット画面の上ではなくSpotlightとApp Intentsの層から立ち上がっています。
| 層 | 使う仕組み | ユーザー体験への効き方 |
|---|---|---|
| データ | AppEntity、App Schemas、IndexedEntity | SiriやSpotlightがアプリ内の対象を意味で見つけられる |
| 更新 | indexAppEntities、deleteAppEntities | 作成・変更・削除された内容をシステム側の索引へ反映する |
| 画面 | appEntityIdentifier、userActivity、OpenIntent | 『これ』の参照や検索結果から、正しい画面へ戻れる |
onscreen awarenessとOpenIntentで、Siriは画面上の対象へ戻れる
後半でAppleは、Siriが『このイベント』『3番目の予定』のような指示を解決できるよう、画面上の要素へEntityIdentifierを付ける流れを示します。リストにはappEntityIdentifier、詳細画面にはuserActivityを使い、いま見えている対象をSiriへ渡す。ここでも主役は会話ではなく、画面とデータの対応関係です。
さらにOpenIntentを加えると、SiriやSpotlightの結果をタップしたときに、アプリのトップではなく該当イベントの詳細画面へ戻せます。これは小さな実装に見えますが、Siri対応を『聞ける』だけで終わらせず、ユーザーを正しい作業位置へ戻すための接続です。Appleが今年求めているのは、アプリの情報を話せるようにすることではなく、情報、操作、画面遷移を一つの索引へつなぐことです。
このコード沿いセッションは、以前のApp Schemas概説を実装順に落としたものです。Siri AIを支える現実の作業は、音声UIの演出より、AppEntity、schema domain、Spotlight donation、onscreen context、OpenIntentを既存アプリの中へ入れていくことにあります。AppleがSiriを再設計するほど、開発者側の仕事は『話しかけられるアプリ』ではなく『システムが辿れるアプリ』を作る方向へ寄っていきます。