App Intentでアプリのコア機能をユーザーに提供

こんにちは 「Bring your app’s core features to users with App Intents」へようこそ App Intentチームのエンジニア Christopher Nebelです

これは私のアプリです 同様のアプリは多数ありますが これは私が作りました 実はこれはサンプルコードで デベロッパサイトから入手できます このアプリはトレイルのカタログです 本ビデオを通じて詳しく見ていきます よろしくお願いいたします さて 私が作ったこのアプリは素晴らしい出来です ユーザーからはアプリを使っていると 本当に楽しいと言われます では アプリを開いていないときは？ ほとんど見ることもないホーム画面上の 四角にすぎないのでしょうか？ そうとは限りません 適切なコードがあれば アプリはただの四角ではなくなり 様々な機能を 便利に実行できるようになります Spotlightから直接操作するか Siriに話しかけることで デバイスの他の場所から アクションを指示できます

ウィジェットに情報を追加して ホーム画面に表示することもできますし

アクションやステータスを コントロールセンターに追加することもできます そうすれば アプリを開いていないときでも ユーザーに利便性を提供できます

これがApp Intentと それにより 実行可能になる機能の価値です 本ビデオではその価値を 実現する方法を説明します アプリの使用中のフローの向上と それを支援するシステム機能の ファミリーについてお話しします App Intentの概要 各機能との連携の仕組み アプリに組み込むApp Intentの 構築方法について説明します

楽しい体験を提供するうえで 重要になるのはフローです 心理学ではフローとは 思考と行動の融合を意味します やりたいと思ったらすぐ手軽にできる それがフローです デバイスでは 次に必要なものが常に手近にあり 簡単にアクセスできることを意味します フローの途中に集中を妨げる 余計なステップがある場合 それは摩擦と呼ばれます 比喩表現であり 物事の進行を妨げるものを意味します 同様の表現は他にもいろいろあります 摩擦が大きいことを 「粗雑だ」とも言います 「行き詰まる」とか 「本当に面倒だ」など 摩擦が小さい場合 流れが良いと表現します よく油がさされた機械のようなものです スムーズです 少々の摩擦は よい効果をもたらすこともありますが 摩擦がまったくない表面について話すと きりがないので控えます 一般的には摩擦は可能な限り 少ないほうがよいでしょう 摩擦は単一の大きな障害だとは 限りません 多くの場合 何度も繰り返し発生する小さな障害です デバイスの使用で言えば アプリの切り替えがその一例です

アプリは注意深く構築された 小さな世界であり 独自のボックスです アプリ内の世界ではすべてが 完璧に完結しています 問題は ユーザーは一つのアプリだけを使って 物事を行うわけではないことです 多数のアプリを使うのです では あるボックスから別のボックスへ 移動する必要がある場合はどうでしょうか？ それぞれのアプリは 独自のボックス内の世界です デフォルトでは 中を見たり何かを実行したりするには ボックス内に入るしかありません 1つのボックスに入れば 他のボックスの中は見られず 何もできません 現在のボックスを離れ別の ボックスに入る必要があります これがアプリの切り替えです

アプリの切り替えは難しくはありませんが 必ず代償が生じます ナビゲーション操作に 時間と労力が生じるのです それが摩擦となります では デバイスがボックスの中身と コア機能を把握していたらどうでしょうか？ そのようなデバイスは 各ボックスの外から全体を概観し 各ボックスへのより迅速かつ 簡単なアクセスを可能にします この考えに基づいた 一連のシステム機能を利用すれば デバイス使用時の体験はスムーズになります いくつかの例を見ていきますが これらはすべて後で構築方法を解説します これらは私のサンプルアプリの画面です 対象地域のトレイルのカタログと 様々な詳細を表示しています いくつかの機能は Spotlightでの検索のように アプリ内で目的の場所に 素早く移動するうえで役立ちます 例えば ホーム画面からピン留めした トレイルを見たいとします この場合 Spotlightを起動します 何も入力しなくても Spotlight検索候補は ユーザーがサンプルアプリを 使いたいのだと予測し 必要なアプリのショートカットを提示します この予測がされなかった場合 ユーザーは 「e、x、a」と入力しないといけません サンプルアプリを使いたいことが 明確になった段階で それがトップヒットとなり アプリのショートカットが より目立つ位置に表示されます

または デバイス内の場所に関わらず Siriに何が必要か 話しかけることもできます

アプリの切り替えを容易にするだけに 留まらない機能もあります アプリの切り替え自体を 不要にする機能も存在します 例えば お気に入りのトレイルの 現在の状況を常にチェックしたい場合

思い出した時に その都度アプリを開くのではなく その情報をウィジェットで ホーム画面に表示することができます こうすれば他のことをしながらでも 一目で確認できます 情報をロック画面に表示することもでき その場合 スマートフォンのロック解除を 行う必要すらありません

他のアプリの使用中にアクセスできる カスタムコントロールを コントロールセンターに 追加することもできます

このような機能は他にも多数あり 継続的に追加されています 昨年はアクションボタンを追加しました 今年はカメラキャプチャや Apple Pencil Proの スクイーズ機能などを追加しています これらによりアプリの機能を ボックス外で利用できるようになります そして それらがデバイス全体の体験を 構成することでユーザーが 「これをしたい」と思った瞬間から 実行されるまでの フローがスムーズになります これらの機能は 利用可能にするアクションを 誰が決めるのかに基づき区分されますが これは重要な点です

Spotlightのような機能では デベロッパであるみなさんが決めます デベロッパがアプリの 重要なアクションを指定すれば デバイスはそれらのアクションを 自動的に最適な場所に表示します デバイス上でどの画面を表示していても アプリでよく使用するアクションが 常に手近な場所にあるため ユーザーはスムーズなフローを体験できます

ウィジェットやコントロールなどの機能では アクションを決めるのはユーザーです デベロッパは柔軟なコンポーネントを提供し ユーザーは自分にとって 重要なアクションを選んで 自身に合ったワークフローを構築します 言い換えれば ユーザーは アプリの体験をパーソナライズして デバイスを自身の延長にしたり 自己表現したりできるのです これはユーザーにとっても アプリデベロッパである みなさんにとってもメリットです なぜなら ユーザーが アプリを自身や自分の生活に合わせて より高度にカスタマイズできるほど アプリが継続的に使われる 可能性が高まるからです ここで みなさんはこう思うでしょう 「メリットはわかるけど アプリのフローを 向上させるにはどうすればいい？」 そう その答えとなるのが App Intentの導入です でも なぜそれが答えなのでしょうか？ ここまでは Siriやコントロールセンターなどの 優れた機能について 話していたはずでしたよね 実は 話題は変わっていません 説明しましょう

App Intentは それ自体が機能ではありません では何かというと 機能を構築するための共通の基盤です ここまでお話ししてきた Siri Spotlight ショートカットなどには すべてに共通のテーマがあります これらの機能はアプリのコア機能や ユーザーにとって 重要なアクションやコンテンツを アプリの外に表示して 実行できるようにします そのためには システムが理解できる形で アプリのコア機能を指定する必要があります App Intentはそれを 実現するためのフレームワークです 大きく分けて 2つの処理が行われます 第一に アプリのコアアクションや コンテンツを定義して SiriやSpotlightなどのシステム機能が 何を表示すべきかを理解できるようにします 第二に 実際に表示するためには アプリと表示機能の間で 多くのやり取りが必要になります 例えば ユーザーが Siriに アプリ内のアクションを指示すると Siriはその指示をアプリに送信し アプリはそれを実行した旨と その結果を返します App Intentが そのやり取りを処理してくれるため デベロッパは機能の 実際の動作の実装に集中できます 機能の実装が完了し 1つのシステム 機能がサポートされるようになれば ほかのシステム機能でも 同じ処理を利用できます それらの処理はすべて App Intentに基づいているからです つまり 様々なシステム機能をまたいで コードを共有でき 複数の機能を まったく同じコードで サポートすることができます 記述が必要なもののうち 最も重要なものは3つあります 記述方法は次のセクションで説明します インテントはビューを開く ハイキングを 始めるなどのアクションを実行します インテントはアプリのコマンドであり いわば動詞です

エンティティはトレイルやコレクションなどの オブジェクトです いわば名詞です インテントを動詞 エンティティを名詞とみなすなら アプリショートカットはいわば文です アプリの重要な機能を記述するために 動詞と名詞 または名詞の箇所を埋める空白 そしてアプリを使うあらゆるユーザーが 行うであろう 重要な機能をまとめて説明するのに 必要な他のオプションです Spotlightや アクションボタンなどの機能は その文が記述する機能を提供し ユーザーがそれを迅速かつ 簡単に実行できるようにします

これら3つが一体となり デバイス全体で アプリがどう表示されるかを定義します 概要がわかったところで 実際にコードを記述してみましょう

アプリのフローがスムーズになるよう いくつかの機能を加えていきます 実際には次の5つです パラメータのない シンプルなショートカットアクション パラメータのある ショートカットアクション ホーム画面のウィジェット コントロールセンターのコントロール SpotlightとSiriの アプリショートカットです 追加する機能が多いと 感じられるかもしれませんが すべてApp Intentフレームワークに 基づいているため 複数の機能間で 多くのコードを簡単に共有できます では始めましょう

ショートカットアプリは ユーザーが アクションを検討 組み合わせ 再構成して 自身のカスタムショートカットを作成できる パワフルなツールです 例えば 私の同僚は娘と一緒に マウンテンバイクを楽しむのが趣味なので 私のアプリのアクションを使って 特定の地域のランダムなバイクトレイルを選ぶ カスタムショートカットを作成しました デベロッパとしては この機能の優先度は 低いかもしれません ニーズが限定的だからです ですが ショートカットアクションの形で 柔軟性が提供されるので ユーザーは自分でショートカットを作成し ニーズに応じて調整できます

私は最近 トレイルをリストの上部に ピン留めする機能を追加しました 旅行の計画を立てる際に その地域の詳細を素早く表示して 「どうやって行くか」や「友人が犬を連れて 行けるか」などの事項について調べられます 素晴らしい機能ですが アプリを開いていない時も ピン留めしたトレイルに 素早くアクセスできるようにしたいので アプリでピン留めしたトレイルの詳細を開く ショートカットアクションを作成しましょう 完成すると ショートカットアプリで このように表示されます

App Intentフレームワークでは ショートカットアクションとは インテントのことであり すべてのインテントはデフォルトで ショートカットアプリのアクションとして 表示されます

インテントはAppIntentプロトコルに 準拠する型です 必須の構成要素は2つあります アクションの名前として表示されるー ローカライズ可能なtitleと アクションを実行する performメソッドです インテントは常にアプリのユーザーにとって 重要なアクションである必要があります ここでは OpenPinnedTrailは 内部実装ではありません

performメソッドは 必ず結果を返しますが この例のように空であることもあります

このインテントでは アプリ内のビューを表示するので 実行時にアプリが 開かれるようにする必要があります App Intentに これを処理させるにはこのように openAppWhenRunを使って指定します

インテントには ジョブの実行に必要な情報として 追加パラメータを付与することもできます このインテントでは不要ですが 追加パラメータが必要なインテントも 後ほどお見せします

以上で新しいインテントが ショートカットアプリのライブラリに アクションとして表示されるようになりました

このアクションで ショートカットを作成すると ショートカットアプリで実行できます また さらに一歩進めて ホーム画面に追加することもできます

タップすると アクションが実行され 想定通りにアプリが起動して ピン留めしたトレイルの詳細が表示されます

これでも十分ですが 自分で選んだトレイルを開く アクションも作りたいので 特定のトレイルを開いたり 実行時に開きたい トレイルの入力を求めたりする ショートカットを作成します そのためには パラメータのある インテントを作成する必要があります これは 最初に説明したインテントに 非常によく似ています 実際 最初のインテントをクローンして 名前を変更することから始めます アプリ内でパラメータを開くインテントには OpenIntentという 特別なプロトコルがあるので このプロトコルを追加します

OpenIntentはopenAppWhenRunと 同じ意味なので 後者は削除できます

このプロトコルが定義する パラメータを追加する必要があります パラメータは@Parameterでマークされた 通常のプロパティで ローカライズ可能なtitleなどの 追加のメタデータを付加できます ここではTrailにします 私のアプリではTrailはコアとなる コンテンツの型なので TrailEntityという名前にします

ここで注意すべきことが2つあります 第一に エンティティはアプリのユーザーにとって 重要なものである必要があります つまり データベースの行や その他の実装内容ではなく Trailをエンティティにすべきです 第二に エンティティを参照するパラメータは エンティティを説明するデータではなく エンティティ自体であるべきです したがって これはトレイル名や UUIDではなく TrailEntityにします

performメソッドを更新して 対象のパラメータに移動します これで完了ですが TrailEntityを定義できていませんでした

幸い これは難しくありません エンティティはAppEntityプロトコルに 準拠する型です モデルの型を直接 準拠させることができます これがうまく機能するのは モデルが十分に小さいため すべてがメモリ内に収まり 必要なすべてのインスタンスが すでに揃っている場合です またはエンティティを 単に実装を参照するのみの 独自の型にすることもできます これは必要に応じて モデルインスタンスのみを作成する場合や インテントには不要な 高コストのプロパティが モデルインスタンスにある場合に有効です

この例では後者のアプローチを採用しており TrailEntityは基盤となる モデルの型であるTrailを参照します

ここでエンティティのプロパティを指定できます この例では Trail Nameです これはパラメータによく似ていますが コンテンツオブジェクト上のものであり コマンドではありません エンティティには3つの要素を 指定する必要があります デバイスのメニューへの表示などに必要となる DisplayRepresentationと 永続的なID そしてクエリです

では クエリとは何でしょうか

クエリが何であるかを説明する前に クエリの機能を説明します クエリはエンティティに対する質問を 実際のエンティティに変換します インテントパラメータの値を選択する際 次の2つの質問が行われます 1つ目は どのエンティティが存在するかです これは デバイスに選択肢のリストを 表示するための質問です 選択肢を1つ選ぶと そのエンティティのIDが保存されます その後 インテントの実行時に 保存されたIDが送信され そのクエリの第2の質問 すなわち このIDはどのエンティティのものかが 問われます その答えがインテントのパラメータとなり インテントコードが単なるIDではなく エンティティを取得するようになります そのコードはどのようなものでしょうか？

クエリはEntityQueryに準拠する型です エンティティの取得方法は複数あります 前述の2つの質問を使用する以外にも 文字列や述語などに基づく検索も可能です そのためEntityQueryには それぞれの質問に対応する サブプロトコルがいくつかあります どのエンティティが存在するかという質問は EnumerableEntityQueryで 処理できます この場合 ご覧の通り allEntitiesメソッドが定義されます これは概念的に 最もシンプルなクエリ形式です iOS 18 SDKを使用して ビルドする場合 App Intentはより複雑なクエリを 生成する場合があります もちろん 実際にすべてのエンティティを 一度に返せる場合のみ機能するため モデル全体が メモリに収まっている必要があります そうではない場合や クエリを自動生成するよりも 優れた方法がある場合は ほかのクエリプロトコルを 使用するべきでしょう とはいえ この例は十分にシンプルです

このIDはどのエンティティのものか という質問には entities(for)メソッドによって EntityQuery自身が回答します

これらが組み合わさり パラメータ設定に必要な すべての処理が行われます

これでインテントを実行する 準備ができました しかし 追加すべきものがもう1つあります parameterSummaryです

これがないとインテントは ショートカットアプリで ご覧のように表示されます これでも機能はしますが わかりにくい表示方法です なぜなら展開しないと 開こうとしている トレイルが見えないためです

parameterSummaryとは インテントの実行内容を 自然言語で説明する文のことです この文には重要なパラメータの値が すべて含まれます この例では 開きたいトレイルです これで このインテントの実行内容が わかりやすくなり パラメータの編集時に読みやすくなりました

実際の動作を見てみましょう トレイルのプレースホルダをタップすると トレイルを選択するシートが表示されます クエリによって選択肢が提供され 検索がサポートされます 1つ選択すると インラインでトレイルが表示され このアクションを実行すると 何が起こるかその時点で確認できます これが parameterSummaryの機能です

しかし 実はトレイルを 今選びたいのではなく 実行しながら選びたい場合もあります その場合 このパラメータを消去して ショートカットをホーム画面に保存します

これでショートカットをタップすると クエリによって 生成される類似のピッカーが 表示されるようになり ホーム画面やショートカットを トリガーできる あらゆる場所から実行可能になりました

ショートカットアクションはアプリの 柔軟性を高めるための最適な手段です ユーザーはみなさんが 想像もしなかったような ワークフローに ショートカットを組み込むでしょう 次に 一目で情報を確認できる より直接的な柔軟性強化の方法を 見てみましょう それはウィジェットです トレイルの詳細情報の大半は 頻繁に変わることはありません 地震などの特殊なケースを除いて 地理的位置が変わることもないでしょう

しかし トレイルの状況は 常に変化する可能性があるので モニタリングできると便利です

ウィジェットはこうした用途に最適です 一目で情報を確認できるよう デザインされているためです ピン留めしたトレイルの詳細を表示する ウィジェットを作成することもできますが 出かける際に最適な状況の トレイルを選べるように 複数のトレイルの状況を モニタリングできるようにしましょう そのためには ウィジェットの構成によって表示する トレイルを指定できるようにする 必要があります つまり Open Trailアクションと同様に ウィジェットに トレイルのパラメータを付加します

ウィジェットを作成する際は ウィジェットの定義が必要です これはWidgetKitのビデオではないため ビューやタイムラインプロバイダなどの 詳細は省略します それらの詳細については WidgetKitの ドキュメントを参照してください ウィジェットがAppIntentと どのように連携するかについては WWDC23のビデオ「Explore enhancements to App Intents」をご覧ください

ここで重要なのはbodyです 特にウィジェットの構成の インテントの型を指定する intentパラメータが重要です

構成のインテントは WidgetConfigurationIntentに 準拠するインテントです 面白い仕組みです

すべてのインテントと同様に titleが必要です このウィジェットでは構成により トレイルを指定できるようにしたいので パラメータを追加します 追加するのはTrailです 先ほどすでにOpenIntentに対して TrailEntityを定義しましたね 再利用できるでしょうか？ もちろん可能です

ウィジェットが ホーム画面に追加されたときに 空でもよいように このパラメータは任意にしていますが それ以外はOpen Trailインテントの パラメータと同じ型です これでトレイルの状況を示す ウィジェットにおいて 数の制限なく どのトレイルでも構成して 追加できるようになりました すでに記述したTrailEntityと そのクエリによって構成のための値の選択が 処理されるため 再度記述する必要はありませんでした 非常に簡単でしたので もう一つの機能も構築してみましょう iOS 18で新しいAPIが導入された コントロールセンターのコントロールです

ウィジェットと同様に コントロールでも構成により トレイルを指定できるようにします タップすると トレイルの詳細が アプリに表示されるようにします

ここではコントロールのApp Intentに 関連する部分だけを扱います コントロールの詳細については 「Extend your app’s controls across the system」をご覧ください それでは さっそく始めましょう

コントロールとは基本的に何かというと ControlWidgetという 特別なタイプのウィジェットです コントロールでは bodyにおいて その外観と機能を定義します ここで作成する構成による 機能の指定が可能な コントロールではApp Intentにより それを実現します ウィジェットと同様に構成可能にするために AppIntentControlConfigurationを 追加します

ボタンのように動作させたいので ControlWidgetButtonを追加します

これが構成可能なボタンコントロールの 基本的な形です ボタンの内容を構築するための 構成を保持するインテントの型と ボタンがタップされたときの処理を行う インテントのインスタンスも必要です 少し考えてみましょう 構成にトレイルのパラメータを 追加すると言いましたが これは先ほど作成した Open Trailインテントの場合と同様です 再利用できるでしょうか？ もちろんできます OpenTrailに関して 唯一変更する必要があるのは それがControlConfigurationIntentに 準拠していると宣言することです これはextensionであり 既にインテントにない要素は 不要なため bodyは空です 記述が完了したら 型を入力し その型の構成済みインスタンスを使用して ボタンの画像とテキストを作成できます

次の箇所が 本当に優れた部分なのですが 構成で指定されたトレイルを開く インテントインスタンスも アクションとして記述する必要があります これもまた OpenTrailと同様です しかし 新しいOpenTrailインスタンスの 作成は不要です すでにconfigurationの インテントがあるからです それをそのままアクションとして 渡すことができます なぜなら 必要なperformメソッドが そこにすでに含まれており 必要な形で構成されているからです 実際の動作を見てみましょう

これがコントロールセンターの 新しい構成モードです すでに左下に 新しいコントロールが追加され Monterey Bay Coastal Trailを 開くように構成されています 編集を停止すると コントロールは有効になります タップするとインテントが実行され 構成により指定したトレイルの 詳細がアプリで開かれます

さらにピン留めしたトレイルの詳細を 開くアプリのアクションを SpotlightとSiriで自動的に 利用できるようにしましょう そのためには アプリショートカットを 作成する必要があります アプリショートカットはデベロッパが アプリの重要な機能として 強調したいインテントに対して 作成するラッパーです

Spotlight アクションボタン Apple Pencil Proなど 様々な機能で アプリショートカットを実行できます その際 当該のアプリは 実行中である必要はなく 一度も実行されたことがなくても 機能が提供されます では コードを見てみましょう

アプリショートカットのリストである 静的メンバーを含む AppShortcutsProviderを1つ定義します アプリショートカットは インテントをラップします ここでは 先ほど作成した OpenPinnedTrailインテントです これはintentインスタンスであり 型ではありません つまり ここでパラメータの一部または 全部を事前に入力できるということです そのため 多くのパラメータを持つ 非常に一般的なインテントを アプリショートカットとしてラップし 特定の機能を提供できます ショートカットが実行されると 未入力の必須パラメータがあれば 入力が促されるので 提供したい体験に基づき どちらの方法も選択できます このインテントにはパラメータがないので 括弧の中は空です

アプリショートカットは Siriから利用できるため 発話するフレーズのリストを記述し 各フレーズに アプリ名を含める必要があります また Spotlightのように視覚的に表示する 機能のためにタイトルと画像が必要です

このコードには登録コードが ないことにお気づきでしょうか App Intentフレームワークは プロバイダを自動的に検出し 登録を処理してくれるので 作成したアプリショートカットは アプリがインストールされると すぐに利用可能になります

これで アプリショートカットが Spotlightに表示されるようになりました

Siriに話しかけて 実行することもできます SpotlightとSiriは両方とも 自動的に処理されるため デバイスのユーザーはアプリを インストールするだけでよいのです しかし デバイスをカスタマイズしたい場合 アプリショートカットは ほかの機能からも実行できます アクションボタンとApple Pencil Proです つまり 1つのコードで 4つの機能を実装できるのです 既存のアプリショートカットについては どうでしょうか 既存のアプリショートカットは 昨年 アクションボタンで自動的に 機能するようになりましたが 現在はApple Pencil Proでも同様です

素晴らしい改善点を紹介しましたが Siriとの連携にはまだ課題があります 第一に ビューで表示されるためデバイスを 見ていることが最低限必要になります 第二に アプリが開かれるため その時使用している別のアプリから 移動させられることになります そこで インテントを少し変更し 適切に情報を返してくれる インテントに置き換えましょう インテントを作成しますが これはピン留めしたトレイルを 開くものではありません トレイル情報をスニペットで表示し ユーザーが画面を見ていない場合や HomePodやAirPodsのように 画面がないデバイスでは 音声で伝えてくれます

まず stub performメソッドから始めます ステップ1は ピン留めしたトレイルの取得です しかし ステップ2が問題です どうすればアプリを使わずに情報を表示したり 発話したりできるでしょうか？ 答えはresultの使用です performメソッドのresultは 単なる値ではありません このresultはSiriが発話する ダイアログや 表示するビューのスニペットなどの 豊富な組み合わせです

resultがProvidesDialogおよび ShowsSnippetViewに準拠していれば ダイアログとビューを取得する resultを生成するための 異なるメソッドを使用できます それが妥当である場合 ダイアログかビューの一方のみ 提供することもできますが ここでは両方を提供します

Siriに発話させる文を記述します この文はスニペットのテキストとは 異なってもかまいません ここでは便宜上文字列補完を 使用していますが このパラメータは実際には Intent Dialogインスタンスであるため 必要に応じてダイアログ全文や 補足的なダイアログも別途記述できます

次にSwiftUIビューを記述します ビューの正確な詳細は省略し 別の関数を使用して取得します ViewBuilderの式を含む トレイリングクロージャを使用して インラインで記述することもできます どちらの場合も ビューは ウィジェットのようにアーカイブされるため Siriにリレーできます そのため ウィジェットがサポートする すべてのSwiftUI機能を使用できます

これで Siriに話しかけると ユーザーが画面を見ている場合は ピン留めしたトレイルの状況が スニペットで表示されるようになりました 表示を閉じると使用していた画面に戻るため 元の場所を探し直す必要はありません ユーザーが画面を見ていない場合 Siriがダイアログを読み上げてくれます ブーツを探していて 電話がポケットに入っている場合 部屋の向こうにあるHomePodに トレイルの状況を尋ねることもできるので 電話をポケットから出す必要すらありません 以上で アプリをより便利に利用できるようにする 機能を実にたくさん追加しましたが 記述したコードはそれほど多くありません これがApp Intentの力です コアとなるコンセプトを一度表現すれば 関連する多くの機能で再利用できます 内容をまとめましょう アプリ使用時のフローを向上させることで ユーザーがより迅速に目的を果たし より楽しさを感じられるようになるほか アプリの使い方を調整して 自身の生活に アプリを組み込めるようになります これを実現するために Siri ショートカット ウィジェットなどの機能を導入できます これらの機能によりユーザーは アプリを開いていないときでも アプリを使えるようになります これらの機能の導入に役立つのが それらすべての基盤として機能する App Intentです 共通の基盤であるため 習得が必要な各種APIの数が減り 機能間でコードを共有できるようになります さらに詳細を学びたいとお感じでしょう こちらのビデオもぜひご覧ください App Intentにまだ慣れていない方は App Intentの概要を解説する 「Designing App Intents」をご覧ください 未視聴であれば 熟練者の方にもおすすめです SiriとApp Intentの連携の 仕組みの詳細については 「Bring your app to Siri」を ご覧ください すでにApp Intentを利用していて 昨年からの更新事項を知りたい方は 「What’s new in App Intents」を ご覧ください

ご視聴いただきありがとうございました 皆さんがApp Intentを どのように活用するか楽しみです