Siriがアプリを呼び出せるなら、最初にどの機能を公開する?
Appleの11月の開発者向けプレビューでは、Siri AIとApp Intentsを連携できます。配送照会を例に、文脈、確認、結果が明確な操作の設計を考えます。
荷物が遅れています。顧客は退社前に会社へ届くかを知りたいのですが、答えを見つけるにはログイン画面、注文一覧、配送追跡ページを順に開く必要があります。アプリが該当する荷物の照会方法を明確に定義していれば、自然な言葉で尋ねるだけでこの手順を短縮できます。
Appleは11月3日、iOS 27.3などのベータ版で、App Intents向けのSiri AI開発者プレビューを開始しました。開発者は、個人の文脈や画面上の情報、関連する操作を使うリクエストにアプリを接続できます。Appleは後日この連携を利用者に提供する予定で、App Storeへの提出は春に始まる見通しです。利用者が頼る前に、一つ一つの操作の振る舞いを詰める機会です。

2014年のSiri。撮影 Kārlis Dambrāns。切り抜きとサイズ変更あり、CC BY 2.0。画像の出典 · ライセンス。
結果がひと目でわかる作業を一つ任せる
App Intentの照会。Telli.sh制作。
App Intentは、アプリが実行できる操作を表します。配送状況を照会できるアプリを考えてみます。入力にはアプリが特定できる配送エンティティを使い、出力には該当の荷物、最新の状況、更新時刻を含められます。データを管理し、ログイン中のアカウントに何を見せるかを決めるのはアプリです。
この設計なら、短いやり取りで答えを出せます。一つのアカウントで三件の配送が進行中なら、アシスタントにはそれらを区別する情報が必要です。追跡番号、短い名称、本人がわかる届け先があれば、候補が具体的になります。「私の荷物」のように複数の項目に当てはまる依頼には、確認の質問を返します。
| リクエスト | アプリに必要な情報 | 利用者に返す内容 |
|---|---|---|
| 注文した品は今どこ? | アカウントと配送の識別情報 | 状況、更新時刻、詳細へのリンク |
| 明日の予約はある? | アカウント、日付、関連するタイムゾーン | 予約時刻、場所、現在の状態 |
| 予約を午後7時に変更して | 予約、希望の変更内容、空き状況 | わかりやすい確認手順と最終結果 |
| 同じものをもう一度注文して | 商品、価格、住所、アカウント権限 | 確定前に確認できる条件付きの注文概要 |
最初の二つは取り組みやすい例です。通常は取引を発生させずに役立つ答えを返せます。予約変更には別の条件があります。希望の時刻に空きがない、会場が手数料を請求する、タイムゾーンの変換で日付が変わるといったケースです。こうした条件は、アプリの操作と応答に反映します。
実行する時点でアプリが権限を確かめる
App Intentの変更。Telli.sh制作。
アシスタントは依頼を解釈し、実行候補の操作を特定できます。誰が依頼したか、どの項目にアクセスできるか、その操作を進めてよいかは、引き続きアプリが検証します。既存画面で使っている確認を、この操作経路にも適用します。利用者が別のアカウントを使っているとき、端末がロックされているとき、セッションが切れたあとでも、自然な言葉での依頼は届き得ます。
支払いを伴うなら、最終的な金額と請求先を表示します。配送先を変えるなら、確認の前に届け先を見せます。バックエンドが処理の成功を判断できない場合は、同じ依頼の再送を促すより、利用者が確認して解決できる状態を返します。決済画面を作ったことがあるなら、見慣れた原則です。音声やチャットでは、その明確さをより短い表現に収める必要があります。
コーヒーを一袋、再注文する例を考えます。前回は期間限定の割引だったかもしれず、届け先は古いかもしれません。商品には複数の容量がある場合もあります。注文を出す前に現在の商品、容量、価格、住所を伝えれば、安心して確認できます。処理後に購入記録を見つけやすくすることもできます。
利用者の文脈があれば、適切な項目から始められます。そのうち何を実際に参照したかは明確にしておきます。注文が一件しか表示されていなければ、「画面に表示されている注文」という確認でも伝わります。複数の項目があれば、どれを選んだかを言い直します。実行する前に、解釈の誤りを訂正する機会を設けます。
複数の操作をつなぐなら最終状態を正確に伝える
Appleは、複数の操作を組み合わせるスキルと、Spotlightのセマンティックインデックスでのエンティティ対応も説明しています。組み合わせれば、依頼から結果までに開く画面を減らせます。一つの操作の出力が次の入力になるため、途中の小さな誤りも無視できません。
近く予定されている予約を探し、時間を変える依頼を想像してください。照会には成功し、変更には失敗することがあります。その場合は両方の状態を伝えます。予約は見つかったが元の時刻のままだとわかれば、利用者は次にすることを判断できます。一律の成功表示では変更の失敗が隠れ、一律のエラー表示では照会の成功が隠れます。
実用的な操作の流れでは、複数の種類の結果が必要になります。ある段階では候補を返し、次に選択や確認を求め、最後に処理結果や保留状態を返せます。操作を組み合わせるときは、途中で利用者が考えを変えた場合と、ネットワーク処理が会話中に待てる時間を超えた場合を試します。
内部では安定したレコード識別子を使います。自然言語の表示名は変わり、似た名称を持つ項目もあります。安定したIDがあれば、アプリは意図した項目を扱ったと判断でき、利用者には読みやすい説明を返せます。文脈を確認したい人が適切な画面を開けるよう、元レコードへのリンクを残します。
手作業で結果を照合できる操作からプレビューを試す
- Appleの開発者向け発表で、対応するベータOS、端末、言語を確認します。テスト用アカウントとデータを使います。Appleは対応言語に韓国語を挙げ、端末と地域による制限を説明しています。
- 利用者が普段から繰り返す照会を一つ選びます。通常の画面遷移と、操作が成功したときに返すべき答えを具体的に書き出します。
- AppleのApp Intentsの資料を使って、操作と対象エンティティをモデル化します。該当レコードが0件、1件、複数件のときの振る舞いを決めます。
- 通常の依頼と曖昧な依頼を実行します。アカウントがない、セッションが切れている、同名項目がある、ネットワークが使えないケースを含め、各結果をアプリの画面と照合します。
- 後から変更操作を追加する場合は、対象、条件、結果がそれぞれどこに表示されるかを記録します。タイムアウトのあと同じ依頼を繰り返し、アプリが正しく扱えるかを確認するテストも加えます。
- 利用者向けの提供日と開発者プレビューを別の節目として扱います。App Storeへの公開を計画するときに、Appleの最新の提出要件とポリシーを再確認します。
ここでは言い回しの違いも試せます。配送アプリなら、問い合わせ窓口に実際に届く表現を使えます。日付を入れる人、店舗名を言う人、届け先で荷物を説明する人がいます。情報が足りない依頼に対して、アプリが何を尋ねるかを確かめます。よい確認の質問は、利用者を答えに一歩近づけます。
結果に合った表示方法を選ぶ
Appleは、Spotlightに表示するアプリのエンティティ、アプリ固有の操作、スニペット、複数の操作をまとめるスキルを区別しています。配送アプリなら、具体的な質問一つに合う方法を選べます。検索結果のエンティティは注文を見分ける助けになります。操作は現在のアカウントで依頼を解決でき、カードは結果をひと目で読み取れるようにします。注文を見つけることが最初の段階にすぎないなら、複数の操作をつなぐ価値があります。
配送状況のカードには、届け先の市区町村、現在の状況、配送業者が最後に更新した時刻を出せます。適切な情報量は、カードが表示される場所や端末のロック状態によって違います。画面を確認するときは、利用者が音声で説明を聞いた前提にしません。音声を試すときも、重大な警告を画面が補うことを前提にしません。同じ元データが両方で意味を伝える必要があります。
Appleのプレビューガイドは、アシスタントがアプリを特定する方法も説明しています。アプリがバックグラウンドにある場合、以下の文脈を除き、カスタム操作にはアプリ名が必要です。フォアグラウンドのアプリ、実行中のLive Activity、すでにアプリ名を出した会話が文脈になります。まずアプリ名を明示して、操作自体が動くことを確認します。それからホーム画面、別アプリを開いた状態、継続中の会話で同じ依頼を試します。どの文脈でどの結果になったかを残します。
配布経路は操作とは別に試す
プレビューガイドには、開発署名したビルドを端末で試す方法と、内部TestFlightを使う方法が載っています。外部TestFlightとApp Storeの配布ビルドでは、これらのプレビュー連携を試せないと説明しています。プロダクト担当者が顧客向けの試行を求めるときに重要な違いです。開発ビルドで正常に実演できても、ストアのビルドで同じ機能を顧客が有効にできるとは限りません。
Appleは、Apple Intelligenceに対応したハードウェアと韓国語を含む6言語を挙げています。地域、年齢、サーバー側の制限もあります。Siri AIにはiOS、iPadOS、macOS、watchOS、visionOSの27.3ベータを挙げる一方、初期のサードパーティー向けプレビューにはiOS、iPadOS、macOS、visionOSを挙げています。テスターを割り当てる際は対象範囲を分けます。前提を明記した記録は、次の開発者が原因を操作、テスト経路、端末のどこに求めるか判断する助けになります。
内部テストでは、依頼、端末、言語、配布経路、結果を一行ずつ記録します。正常とわかっている一行から始めます。韓国語で配送状況を尋ねるなら、短い口語表現と、販売店や追跡日を含む依頼を比べます。どちらも同じレコードに行き着けば、実際にあり得る表現の違いに対応できています。他人の注文が表示されたら、テストを止めて権限確認の経路から直します。
最終確認では、利用者が自分で対応を引き継ぐ流れを試します。予約を見つけても変更できないなら、空いている時間を示し、正しい画面を開きます。変更できるなら、完了結果を示し、後からアプリで処理記録を見つけられるようにします。どちらでも、次にできることを具体的に伝えます。
一つ一つの操作が明確ならショートカットは信頼される
Siri AI連携の魅力は、アプリの役に立つ機能を必要とする人の近くに置けることです。対象が狭く、結果を確認できる操作が一つあれば、多数の連携を用意しなくても価値を提供できます。正しい配送状況を表示できる事業者には、それがよい出発点になります。
操作を追加する際は、すべてに同じ基準を使います。何を見つけ、何の許可を求め、その後何が起きたかを、利用者が理解できることが大切です。複数のサービスにまたがる依頼や、利用者が元のアプリを一度も開かない場面では、特に明確さが求められます。
出典
- Apple Developerによる11月3日のSiri AIプレビュー発表
- AppleのApp Intentsドキュメント
- Appleの開発者プレビュー設定とテストのガイド
- AppleのSpotlightとApp Intentsのドキュメント
仕事の背景となる会話や判断を検索できる記録にするには、Telli.shのアカウントを作成してください。