App Intentフレームワークの新機能

こんにちは Moeです App Intentチームのエンジニアです。 2027年リリースの App Intentの新機能を 紹介します。 App Intentはアプリのアクションや コンテンツをシステムに伝える フレームワークです 自然に深く統合された形で 機能します。 Siriやショートカットアプリから Spotlightやウィジェットまで App Intentは Appleプラットフォームで 優れた体験を支えてきました。 今やApple Intelligenceの 重要な柱となっています。 2027年リリースでは 皆さんのご要望に応えて より多くの制御と 柔軟性を提供し デベロッパ体験を 大幅に向上させます。 今日は3つの分野を紹介します。 まずエンティティについてです。 アプリ間での共有方法や 関連性の通知方法と 大規模な処理方法を説明します。 次にネイティブ型の 新しいサポートを紹介します ユニオン値とショートカットの 完全な統合も含めて。 最後にインテントをより長く 実行する方法 キャンセルの適切な処理と 実行プロセスの指定方法を紹介します。 今日は新機能に絞ります。 App Intentが初めての方や 基本を確認したい方は WWDC25の「Get to know App Intents」をご覧ください。 あのビデオではLandmarks Travel Trackingアプリを紹介しています。 今日紹介するAPIを使って そのアプリを拡張します。 サンプルコードをダウンロードして 一緒に試してみてください。 新機能を見ていきましょう。 エンティティはランドマークや プレイリストなど アプリのコンテンツです。 でもユーザはアプリに 留まりません。 常にアプリを切り替えています。 メールとマップと Travel Trackingアプリの例を見ます。 友達と旅行アイデアを 共有するショートカットを作りました。 近くのランドマークを見つけて メッセージと一緒に送ります。 エンティティはCoreTransferableの Transferableに準拠しています。 ショートカットがメールで使える 形式で共有できます。 これはうまく機能します。 でも友達に送る代わりに そのランドマークへの 道順を取得したい場合は？ これはうまくいきません。 マップには座標やアドレスなど 構造化された情報が必要です ナビできる情報が必要です。 でもそのようなデータには 対応するデータ形式がありません ファイルやデータとして 保存できる形式が 既存のファイルと データの表現は PDFや画像など既知の形式には 適しています でも形式のない 構造化型には使えません。

そこでValueRepresentationの 出番です。 システムが既に理解している 構造化型を共有できる 新しい表現型です。 LandmarkEntityはTravel Tracking アプリの場所を表します。 Transferableに準拠しているので ValueRepresentationを追加するだけです 既存の表現に並べて追加します。 ValueRepresentationの中で ランドマークの座標と名前を GeoToolboxフレームワークの PlaceDescriptorとしてエクスポートします。 PlaceDescriptorは座標と メタデータを持ち マップのナビに必要な情報です。 エンティティにPlaceDescriptorの @Propertyが既にある場合 クロージャを省略して キーパスを使えます。 結果は同じでコードが 少なくなります。

ショートカットに戻って 実行をタップすると ランドマークがPlaceDescriptorとして マップに渡され マップがランドマークへの 道順で開きます。

エンティティはアプリ間を より多くの方法で移動できます。

次にシステムへの関連性の 提案方法を説明します。 CosmoTunesのような 音楽アプリを作っているとします このビデオのサンプルアプリです 「Explore advanced App Intents features for Siri and Apple Intelligence」の ランニングに最適な 新しいハイテンポのプレイリストが アプリにあります。 FitnessアプリでRunningワークアウトを 設定するとき おすすめプレイリストの 一覧が表示されます。 自分のプレイリストを その候補に入れるには？

コンテンツをシステムに 提供する方法は今日2つあります。 1つ目はSpotlightで コンテンツをインデックスする方法です。 Spotlight UIでコンテンツを 検索できるようになります セマンティック検索も含めて SiriがコンテンツをRetrieveする 主な方法でもあります。 2つ目は インタラクションドネーションです。 ユーザがアプリで操作すると IntentDonationManager APIで インタラクションをシステムに ドネーションします。 システムはパターンを学習して 将来同様のアクションを 提案できます。 Siriもこれらのインタラクションを使って よりパーソナライズされた体験を提供します。 でも新しいプレイリストは？ 誰もそれを知らないので Spotlightで検索していません。 再生もされていないので ドネーションするインタラクションもありません。 このプレイリストが関連性があると システムに伝える方法が必要です 適切なタイミングで 表示されるように RelevantEntitiesを紹介します。 RelevantEntitiesを使うと エンティティをシステムに提案して いつ、なぜ関連性があるかの コンテキストを提供できます。 仕組みを見てみましょう。 まず関連するエンティティを 特定します 今回はランニング用プレイリストです。 次にコンテキストを作成して システムに伝えます ランが開始されたときにこれらの プレイリストが関連することを そしてupdateEntitiesを呼び出して 登録します。 システムは適切なコンテキストで これらのプレイリストを候補として表示します 一度も再生されていなくても。 エンティティは削除するまで 登録されたままです。 特定のコンテキストの 全エンティティを削除したり コンテキストから特定の エンティティを削除したり 全コンテキストのエンティティを すべてクリアできます。

コンテンツの発見を助ける 選択肢が増えました。 どれを選べばいいでしょうか？ コンテンツをSiriで検索・取得できる ようにしたい場合はSpotlightを使います。 インタラクションドネーションを使って SiriとシステムにアプリUI操作を教え ユーザの使い方を学習させ パターンを識別できるようにします 繰り返したいアクションを 提案できるようになります。 RelevantEntitiesを使って システムにヒントを与えます 特定の状況で関連する コンテンツを示して 適切なタイミングで 提案できるようにします。 詳細はSpotlightと インタラクションドネーションの 新しいドキュメントをご覧ください。 エンティティを共有でき システムが関連性を把握します。 次に効率を上げましょう。

Travel Trackingアプリに戻ります。 アプリにはランドマークの 写真があります 旅行写真も保存できるよう にしたかったのです。 そこでフォトアルバムビューを 追加しました 写真をシステムで 利用可能にするために 写真のapp schemaで PhotoEntityを定義しました。 システムがSiriを通じて 写真を扱うのに必要な コンテキストを提供します ショートカットとSpotlightでも

キーワードで写真を タグ付けするインテントも作りました 整理して検索しやすくなります。 フォトライブラリが増えるにつれて 気づきました。 大量の写真を一度に タグ付けするのが予想より遅い コードを見て理由を 確認しましょう。

インテントはシンプルで 写真にキーワードを追加するだけです。 @ParameterとしてPhotoEntityの リストとタグを取ります。 performメソッドは 各写真にタグを適用します。 では実際に何が 問題だったのでしょうか？

App Intentがパラメータを 解決する方法に関係しています。 インテントが実行される前に システムはすべてのエンティティを解決します。 エンティティクエリを呼び出して すべてのプロパティを設定します インテントが必要な情報を すべて持てるように。 ほとんどのインテントでは それが望ましいことです。 でも私の場合は数百から 数千のPhotoEntityを解決することになります コードではデータモデルの更新に エンティティIDしか必要ないのに。 どう修正すればいいでしょうか？ EntityCollectionが解決策です。 エンティティ識別子の配列を 保存する新しい型で 完全に解決されたエンティティの 代わりに使います。 EntityCollectionを パラメータ型として使うと システムはインテントの performメソッドに識別子だけを渡します エンティティを完全に 解決せずに。 更新したコードです。 @ParameterをEntityCollectionに 変更して タグ付けメソッドに 識別子を直接渡します。 これだけで十分です。

修正を確認するために 1000枚の写真を検索して タグ付けするショートカットを作りました。 まず通常のPhotoEntityの 配列で試します

次にEntityCollectionでは ほぼ瞬時に完了しました。 コードの変更は小さいですが パフォーマンスの差は 大きいです。

同じエンティティを複数の デバイスで使う場合はどうでしょうか？

2027年リリースではSiriが デバイスをまたいで会話を継続でき エンティティも その会話に参加できます。

アプリが複数のデバイスで 動作する場合 あるデバイスでSiriと 会話を始めて 別のデバイスで継続することがあります。 しかし課題があります。 iPhoneのSiriに 写真をアルバムに追加するよう頼んで 別のデバイスに切り替えてSiriに その写真のタグを付けるよう頼むと Siriがその写真を 見つけられないかもしれません。 理由を理解するために エンティティの識別方法を考えましょう。 すべてのエンティティにはIDが必要で システムがそれで見つけます。 エンティティIDは各デバイスで ローカルに生成されるかもしれません。 ローカルIDは作成された デバイスでは問題なく動作します。 しかし各デバイスが独自の ローカルIDを生成します。 同じエンティティがデバイスごとに 異なるIDを持つことになります。 Siriがデバイスをまたいで エンティティを参照するには どこでも同じstableIDが 必要です。 サーバーやCloudKitの レコードIDから取得できます。 エンティティIDが安定していると システムに伝える方法も必要です。 それがSyncableEntityの役割です エンティティIDが安定していて デバイスをまたいで使えると システムに宣言します。 採用方法を見てみましょう。 まずエンティティに SyncableEntityプロトコルを追加します。 次にstable IDを 提供する必要があります。 エンティティが全デバイスで 同じIDを使っている場合 サーバー割り当てのUUIDや CloudKitレコードIDなど 追加の変更は不要です。 CoreData行IDなど ローカル識別子を使う場合は両方必要です ローカルIDとstable IDの両方。 SyncableEntityIdentifierが 1つのIDにまとめます。 デバイス上では コードがローカルIDを使います。 デバイスをまたぐ場合は システムがstable IDを使います。

ここまではエンティティに 焦点を当ててきました。 次にそれらを使うインテントについて 説明します。 インテントはパラメータを取ります ユーザが提供する入力です 日付、名前、住所などです。 @Parameterを宣言すると システムがネイティブピッカーを Siriの理解とローカライズを 自動で提供します。

同じサポートをより多くの ネイティブ型に拡張します。 Durationのネイティブサポートを追加します カスタム時間ピッカーは不要になります。 PersonNameComponentsで 構造化された名前入力も 単なる文字列の代わりに 使えます。 さらにあります。

それぞれにネイティブピッカーがあり インテントが動く場所ならどこでも使えます Siri、ショートカット、ウィジェットも含めて。 これらは個別の型で @Parameterごとに1つの型です。 しかしパラメータが複数の型を 受け入れる必要がある場合があります。 ユニオン値はSwiftのenumで 各ケースが異なる型をラップします 単一のパラメータで複数の 選択肢を表現できます。 ランドマークと旅行写真の 両方がアプリにあるので フォトアルバムかランドマーク コレクションから 写真を表示するウィジェットが欲しかった。 @UnionValueで入力パラメータを サポートすると 1つのウィジェットで 両方に対応できます。 コードです。 ユニオン値を@UnionValueマクロで enumとして定義します。 各ケースが異なる エンティティ型をラップします ランドマークコレクション用と フォトアルバム用です。 マクロはシステムに必要な すべてを生成します 型情報、ケースのメタデータ ピッカーのサポートも含めて。

各オプションがピッカーで どう表示されるかも設定します。 typeDisplayRepresentationが 型全体のラベルで caseDisplayRepresentationsが各ケースの ピッカー表示名をマップします。 これはウィジェットだけではありません。 @UnionValueパラメータは インテントが動く場所ならどこでも使えます ショートカットアプリも含めて。

詳細はTravel Trackingの サンプルコードプロジェクトと 対応する記事をご覧ください。 ここまで紹介した内容で エンティティとパラメータの表現力と 効率が向上しました。 次に実行について説明します。 インテントがSiriやショートカットなど システムから実行されると 完了まで30秒しかありません。 ほとんどの日常的なアクションには 十分です。 でもすべてのインテントが それほど速くはありません。 アプリが写真のタグ付けと 整理をサポートするようになったので 旅行写真を共有できるよう にしたかった アプリを開かずに 共有アルバムにアップロードして。 そこでアップロードインテントを 作成して ウィジェットにボタンを追加して トリガしました。 でも大きな写真では アップロードに時間がかかります インテントは30秒以内に 完了できなかったため 繰り返し失敗しました。

LongRunningIntentが これを解決します。 インテントを30秒の制限を 超えて実行できるようにして アプリのバックグラウンドタスクの ライフサイクルを管理します。 インテントの実行中に進捗の更新が Live Activityとして自動表示されます。 コードを見てみましょう。

写真をアップロードするために 作成したインテントです。 LongRunningIntentに準拠します。 写真ファイルを入力として取ります。 作業をperformBackgroundTaskで ラップして 拡張実行のために使います。

LongRunningIntentは インテントの進捗報告が必要です システムが処理中で 停止していないと分かるように。 ProgressReportingIntentに 基づいているので 作業を追跡する組み込みの progressオブジェクトがあります。 ファイルのチャンク数を計算して 合計数を設定し 各チャンクをアップロードしながら 進捗を更新します。

インテントが実行されると こうなります。 より長く実行でき Live Activityに停止ボタンが表示されます いつでもキャンセルできます。 インテントが停止前に 通知を受けられると良いですね。

CancellableIntentでキャンセル時に インテントをきれいに終了できます ユーザがキャンセルをタップした場合 システムのタイムアウトや リソース回収時も含めて。 キャンセルサポートを 追加する方法です。

CancellableIntentを追加して onCancelハンドラを実装します。 キャンセルが発生すると ハンドラが理由を 教えてくれます それを使って部分的な アップロードのクリーンアップや 進行中のリクエストの キャンセルができます。 LongRunningIntentは対応デバイスで バックグラウンドGPUアクセスも 写真処理やオンデバイス推論などの タスクに使えます。 アプリのentitlementに GPUアクセスを追加してください。 バックグラウンドでタスクを 実行するメカニズムの詳細は WWDC25のこのビデオを ご覧ください。 ここまではインテントの 実行時間と 停止時の動作について 説明しました。 次に実行プロセスについて 説明します。

アプリが成長するにつれ 一部のインテントをWidget extensionや App Intents extensionに 移動するかもしれません。 アプリを起動せずにリクエストを 処理できる軽量な独立プロセスです。

共有Swiftパッケージを 作成することもあります インテントとエンティティを 配置するフレームワークです アプリとextensionに インポートして使います。 実はTravel Trackingアプリでも 同じことをしました すべてのインテントは 共有パッケージに入っています メインアプリとwidget extensionの 両方がインポートしています。 インテント、エンティティ、クエリが このような共有パッケージにある場合 アプリとextensionが リンクしていると システムが決定します リクエストが来たときにどのプロセスが インテントを実行するかを。 ヒューリスティックに基づいて ターゲットを選びます アプリがすでに実行中なら アプリを優先します。 そうでなければ extensionを起動します。 でもそれが適切でない 場合があります。 例えばウィジェットに お気に入りボタンを追加したかった ホーム画面から直接 写真をお気に入りにできるように。 ウィジェットはアプリとデータModelを 共有しています でも2つのプロセスが同じ データストアに書き込むと 競合が発生する可能性があります。 そこでウィジェットに読み取り専用アクセスを 与えメインアプリがすべての書き込みを処理します。 ボタンをタップすると インテントはメインアプリで実行される必要があります。 ExecutionTargetsを使うと システムに伝えられます どのプロセスがインテントを 実行するかを正確に。 方法を見てみましょう。

メインアプリを

appIntentsExtensionを widgetKitExtensionを またはその組み合わせを ターゲットにできます。 ExecutionTargetsでシステムの ヒューリスティックを上書きして インテントを処理するプロセスを 正確に制御できます。 紹介したかった 新機能は以上です。

次のステップとして エンティティにValueRepresentationを追加して 構造化データをアプリ間で 運べるようにしてください。 関連コンテンツをシステムに 登録して 適切なタイミングで 表示されるようにしましょう。 EntityCollectionを採用して インテントを高速化しましょう 大量のエンティティを扱う 場合に有効です。 30秒以上かかるインテントには LongRunningIntentを追加しましょう。 アプリのSiri体験を ステップバイステップで構築するには 「Code-along: Make your app available to Siri」を 新しいAppIntentsTestingフレームワークで インテントをテストするには 「Validate your App Intents adoption with AppIntentsTesting」を 皆さんの成果を楽しみにしています ご視聴ありがとうございました！