Shortcutsでは正常に見える機能でも、Entity QueryやSpotlight連携の回帰は利用者の操作で初めて発覚することがあります。本稿では、AppIntentsTestingをUI Testing Targetへ組み込み、固定データ、署名、継続的インテグレーション、再起動復旧までをシナリオ単位で受け入れる方法を説明します。
Shortcutsでは正常に見える機能でも、Entity QueryやSpotlight連携の回帰は利用者の操作で初めて発覚することがあります。本稿では、AppIntentsTestingをUI Testing Targetへ組み込み、固定データ、署名、継続的インテグレーション、再起動復旧までをシナリオ単位で受け入れる方法を説明します。
Shortcutsでは手動確認が正常でも、Entity Queryの回帰が利用者からの報告で初めて発覚するなら、重要なApp Intentsの経路をAppIntentsTesting 自動テストへ移すべきです。UI Testing Targetから実アプリのIntent、Entity、Query、Spotlight連携を検証し、継続実行にはツールチェーンを固定できるリモート Macを使います。
すでにApp Intentsを組み込んでおり、Siri、Shortcuts、Spotlightの静かな回帰を心配する独立開発者向けの記事です。毎回のコミットでIntentとEntity Queryを検証したい小規模チームや、常設のApple silicon Macを持たないWindows・Linux開発者にも適しています。
※最終更新：2026年9月1日。AppIntentsTestingのBeta状態、XcodeとiOSの公開バージョンは、Appleのリリース記録および Xcodeのシステム要件で確認しています。
AppIntentsTestingは、普通の単体テストでIntentのメソッドを直接呼び出したり、Mockオブジェクトだけで結果を作ったりする用途とは異なります。AppleのApp Intents Testing公式ドキュメントに沿って、UI Testing Targetからアプリの実プロセスを起動し、システムがIntentを解決して実行する経路を確認します。
設定で特に重要なのは、アプリのBundle Identifier、UI Testing Target、署名チームの対応関係です。テスト対象とアプリが異なるTeamで署名されていたり、対象のBundle IDが別のアプリを指していたりすると、Intentの実装以前にテスト発見で止まります。
最初は外部API、個人アカウント、既存のクラウドデータに依存しないIntentを一つ選びます。ここで記録する失敗は、次のように分けてください。
この分類を最初から分けると、CIの失敗通知を見た時点で、Xcodeプロジェクトを直すべきか、アプリの実装を直すべきか判断できます。
App Intentsの不具合は、Intent単体の成功だけでは見えません。Entityを文字列で検索できるか、識別子から同じEntityを再取得できるか、Shortcutsへ返す表示名や補足フィールドが正しいかを別々に確認します。
たとえばテスト専用の固定データを初期化し、名称検索、識別子解決、返却項目の一致を順に検証します。開発者個人のアカウントに存在するデータを使うと、削除、権限変更、同期遅延によって結果が変わるため、回帰テストの材料として不適切です。
次に、先行Intentが返したEntityまたは識別子を、後続Intentの引数へ渡します。前段が成功しても後段で型変換に失敗する場合があるため、Shortcuts上で二つの操作をつないだときと同じ受け渡しを作る必要があります。
AppleのWWDC26 AppIntentsTestingサンプルは、こうしたアプリのIntent実装をテスト対象として扱う考え方を確認する資料になります。ここでの合否は、単なる戻り値ではなく、ユーザーが次の操作へ進めるデータ契約まで含めて判定します。
既知のEntityがSpotlight検索に出ない場合、Queryのロジックだけを疑うのは危険です。インデックスがまだ生成されていない、保存済みデータが古い、検索対象の属性が公開されていないという別の原因があるためです。
まずテスト用Entityを登録し、インデックス生成後に既知の文字列で検索します。次に、更新したデータが古い表示のまま残らないか、削除したEntityが候補に残らないかを確認します。App EntitiesをSpotlightで利用可能にする公式説明と、Core Spotlightの仕様を突き合わせ、登録処理と検索処理を同じ合格条件にしないことがポイントです。
画面側では、テスト専用Intentで決められた画面へ移動し、View Annotationが意図したEntityを公開しているかを確認します。自動テストはシステム統合コードの検査には有効ですが、音声認識の聞き間違い、Siriの応答、Shortcutsの候補の分かりやすさまでは保証しません。Appleが示すApp Intentsのシステム体験テストも参照し、手動の最終確認を残します。
注意：テスト入口はデバッグビルドだけで発見できない状態にし、リリースビルドに初期化、画面遷移、削除用のIntentが混入していないかをアーカイブ前に確認します。
AppIntentsTestingの結果が実行ごとに変わるなら、コードの不具合だけでなく環境共有を疑います。前回のデータ、並行ジョブが作ったEntity、ログイン状態を共有すると、失敗すべきテストが偶然通ることがあります。
テスト専用Intentをデバッグビルドに限定し、次の処理を一つのシナリオとして完結させます。
Bundle ID、Team、テストアカウント、保存先パス、サンプルデータ名は、リポジトリに実値を置かずプレースホルダーで管理します。署名に使う証明書やProvisioning Profileも個人の開発環境からコピーするのではなく、CIで復元可能な手順にします。チームの署名証明書を共有するApple公式資料に照らし、秘密情報の保管方法を別途監査してください。
AppIntentsTestingを継続的インテグレーションで動かす場合、ジョブを普通の単体テスト、XCUITest、正式署名・配布タスクから分離します。単体テストの失敗はロジックの問題、UI自動化の失敗は画面導線の問題、AppIntentsTestingの失敗はIntentとOS機能の統合問題として扱うためです。
リモート Macでは、次の受け入れ順序を採用します。
2026年8月24日時点で、Appleの公開記録ではXcode 27の最新公開テスト版はBeta 6、iOS 27はBeta 7です。これらはAppleのリリース記録で確認できますが、BetaのAPI、既知の問題、必要なシステム条件は正式版やRCで変わる可能性があります。したがって、現在の合格結果を長期保証と解釈せず、Xcode 27正式版の公開時に再検証します。
App Intentsの利用が試験的な段階なら、最小のIntent実行とEntity Queryだけをローカルで確認し、Betaフレームワークにプロジェクト全体を依存させない方法が安全です。重要なショートカット経路が製品の中核になった段階では、コミットごとの統合テストへ昇格します。
常時稼働するリモート Macへ移すのは、再起動後の復旧、署名情報の復元、シミュレーター状態の初期化、成果物保存まで自動化できた後です。物理デバイス、手動の音声確認、長期の重いビルドを同じノードへ詰め込むと、失敗原因が混ざるため、役割を分けてください。
| 運用案 | 適する状態 | 検証範囲 | 評価 |
|---|---|---|---|
| ローカル試用 | App Intentsを試作中 | Intent実行と基本Query | 小さく始めやすい |
| コミットごとのCI | 回帰を早期検出したい | Entity、連続Intent、Spotlight | 独立開発者に有力 |
| 常設リモート Mac | 継続的に統合確認したい | 再起動復旧、署名、成果物保存まで | 運用設計が前提 |
現在のWindows・Linux環境だけでiOS連携を完結させようとすると、Xcode専用処理、Appleの署名、シミュレーター実行を別の場所へ逃がす必要があり、認証状態の管理、実行環境の再現、ログ回収という三つの負担が残ります。常設のApple silicon Macを購入する方法は安定しますが、検証期間が短い場合や複数環境を試す場合は資本負担が先に発生します。
そのため、まず本文の受け入れ項目を手元のApp Intentsテストへ置き換え、連続実行と再起動後の復旧を確認してください。常時稼働できるMacが必要になった時点で、VNCMacのMacレンタル構成を候補として比較すると、購入前に必要な運用条件を確かめやすくなります。サービスの入口はVNCMacの日本語案内から確認できます。
FAQでは、UI Testing Targetを使う理由、CIでの実行条件、Entity Queryとパラメータ受け渡し、コード署名、Siri・Shortcutsの手動確認を分けて扱います。自動化できる範囲と、最後まで人が確認すべき体験を混同しないことが重要です。
最小構成の合格条件は、Intent実行、Entity Query、連続Intent、Spotlight検索、再起動後の復旧です。どれか一つだけを通して導入完了とせず、xcresultとコンソールログから失敗原因を再現できることまで確認します。
現在の環境が単なるローカル試用なら、Betaの回帰リスクを抑えるために対象Intentを限定します。App Intentsを製品の主要導線として利用しているなら、リモート Mac上のCIへ移し、Xcode 27正式版の公開後にAPIとテスト結果を再確認してください。
WindowsやLinuxから一時的にiOS連携を検証する場合、既存環境にはXcode専用処理、Apple署名、シミュレーター状態の保持という制約があります。自前のMacを常時稼働させる方法は長期の安定運用に向きますが、短期検証や小規模チームでは、専用のリモート Macを周期利用する方が撤去しやすく、環境を分離しやすい場合があります。
物理デバイスを常時接続したい場合、長期にわたり重いビルドを固定実行する場合、またはローカルの周辺機器へ直接アクセスする場合は、レンタルが最適とは限りません。一方、手元のMacをCI専用にしたくない、複数の開発者が同じ環境を使いたいという条件なら、VNCMacのMacレンタルで専用テストノードを用意する方が、購入前の検証と運用分離を進めやすい選択です。