App IntentsはAppleが提供する、あなたのアプリへの新しいAPIです

2026年2月8日の朝、キッチンのシンクで両手がふさがった状態のまま、Apple WatchからSiriに「水を8オンス記録して」と頼みました。水は記録され、ウォッチのダイアログには「残り32オンス」と表示されました。画面には一度も触れていません。¹

その11週間前、私はWater（iOS向けの水分摂取トラッキングアプリ）にSwiftファイルを1つだけ追加していました。LogWaterIntent.swift、80行のAppIntentに加えて、3つのSiriフレーズのバリエーションを宣言するAppShortcutsProviderです。今やそのファイルは、私が所有するなかで最もホットなAPIサーフェスとなっています。²

ここから先は、自分のなかに腹落ちさせるのに時間のかかった部分です。App IntentsはSiriの機能ではありません。 App Intentsとは、サードパーティ製アプリがApple Intelligence（AppleがiOS 18から展開を始め、iOS 26まで構築を継続してきたシステムAIサーフェス）と取り交わす契約なのです。³ iOSアプリをリリースしている人がApp Intentsを「あれば便利」な音声機能として扱っているなら、それはAppleが築き上げてきたものを読み違えていることになります。App Intentsとは、AppleのAIがユーザーに代わって「あなたのアプリそのものとして」振る舞うことを可能にするAPIです。それ以外のもの（Siri、Spotlight、Shortcuts、Apple Intelligenceの要約、Apple WatchやVision Proの各サーフェス）は、すべてこの契約の下流に位置しています。iOS 26で出荷された端末内LLMであるFoundation Modelsは、アプリ内ツール呼び出しのために独立したToolプロトコルを公開しており、App Intentsを経由するのではなく並列で動作する設計になっています。

TL;DR

• App Intentsは、AppleのAIから直接呼び出せる型付きで構造化された形式で、アプリができることを宣言します。サードパーティ製アプリ向けの、Apple版ツール利用APIです。
• 実プロダクションの一例として、WaterのLogWaterIntentがあります。80行で、SwiftDataへの完全な書き込み、HealthKitへの同期、ロケールに応じた単位変換、構造化されたSiriダイアログのレスポンスをすべて備えています。
• iOS 26ではAppleの端末内LLMであるFoundation Modelsが追加されました。Foundation Modelsはアプリ内ツール利用のために独自のToolプロトコルを公開しています。一方でApp Intentsは、Siri / Spotlight / Apple Intelligenceがアプリ間をまたいで呼び出す正規のサーフェスとして残っています。同じ方向、2つの並列契約です。
• 2026年時点でApp Intentsを持たないアプリは、Apple Intelligenceからは見えない存在となります。AIファブリックは、宣言されたインテント経由でルーティングするか、もしくはあなたのアプリを迂回して競合へとルーティングするかのいずれかです。
• Appleはこの方向性を3年にわたって示し続けてきました。命名（App Intents、App Shortcuts、Apple Intelligence）は意図的なものです。WWDCのたびに、契約はスタックを1段ずつ上に上がっていきます。

App Intentsフレームワークのリファレンス画像。出典：Apple Developerドキュメント。⁵

App Intentとは実際のところ何なのか

2026年2月8日のコミットe398c58でリリースされたLogWaterIntentの全ソースコードです。²

import AppIntents
import SwiftData

struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    static var description: IntentDescription = "Log a glass of water to your daily intake"

    @Parameter(title: "Amount", default: 8)
    var amount: Int

    static var parameterSummary: some ParameterSummary {
        Summary("Log \(\.$amount) oz of water")
    }

    func perform() async throws -> some IntentResult & ProvidesDialog {
        let container = try ModelContainer(for: WaterEntry.self, DailyLog.self, UserSettings.self)
        let context = ModelContext(container)

        let settingsDescriptor = FetchDescriptor<UserSettings>(
            predicate: #Predicate { $0.id == "user-settings" }
        )
        let settings = try context.fetch(settingsDescriptor).first ?? UserSettings()

        let amountMl: Double
        if settings.unitSystem == .imperial {
            amountMl = Double(amount) * 29.5735
        } else {
            amountMl = Double(amount)
        }

        let todayKey = DailyLog.todayKey()
        let logDescriptor = FetchDescriptor<DailyLog>(
            predicate: #Predicate { $0.dateKey == todayKey }
        )
        let log: DailyLog
        if let existing = try context.fetch(logDescriptor).first {
            log = existing
        } else {
            log = DailyLog(date: .now, goalAmount: settings.dailyGoal)
            context.insert(log)
        }

        let entry = WaterEntry(amount: amountMl)
        log.entries.append(entry)
        try context.save()

        if settings.healthKitEnabled {
            try? await HealthKitService.shared.logWater(amount: amountMl, date: entry.timestamp)
        }

        let unit = settings.unitSystem == .imperial ? "oz" : "mL"
        let totalDisplay = settings.formatAmount(log.totalAmount)
        return .result(dialog: "Logged \(amount) \(unit). Today's total: \(totalDisplay)")
    }
}

struct WaterShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: LogWaterIntent(),
            phrases: [
                "Log water in \(.applicationName)",
                "Add water in \(.applicationName)",
                "Drink water in \(.applicationName)",
            ],
            shortTitle: "Log Water",
            systemImageName: "drop.fill"
        )
    }
}

（Waterの現行プロダクションバージョンでは、目標達成・残量に応じた条件分岐を加えてダイアログをさらに作り込んでいます。上記2月8日リリース時のコードは、私がキッチンのシンクで実際に検証したそのものです。）

ここで取り上げる価値のあるポイントは3つあります。たいていの「App Intentsチュートリアル」では軽く流されている部分です。

@Parameterがスキーマです。 AppleのAIには、デフォルト値8のamount: Intが見えています。Siriが「水を12オンス記録して」と解釈すると、LogWaterIntent(amount: 12)を生成してperform()を呼び出します。私の側で文字列パースは一切不要です。型システムこそがスキーマなのです。⁵

parameterSummaryはパラメーターを自然言語で映し出したものです。 AppleはこれをShortcuts UIでのアクション表示、ダイアログ表示、そしてApple Intelligenceの確認パネル（ますます重要性を増しています）に利用します。サマリーはユーザーに対して読み上げられます。これを誤ると、ユーザーには不格好な文章が聞こえてしまいますが、うまく仕上げればサーフェスはネイティブのように感じられるものとなります。⁶

perform()はIntentResult & ProvidesDialogを返します。 これが構造化された戻り値の正体です。AIサーフェスには、成功・失敗だけでなく、ユーザーに読み上げられるダイアログ文字列まで返ります。AppleはProvidesDialog、ProvidesView、ReturnsValueの利用をますます期待するようになっており、結果がSiri、Spotlight、Apple Watch、そしてiOS 26ではApple Intelligenceの応答チェーンへと組み込まれていく形になっています。⁷

末尾のAppShortcutsProviderブロックが、Siriのフレーズを登録する部分です。\(.applicationName)トークンには、Siriが「Water」を自動的に挿入してくれます。同じインテントに対して3種類のフレーズバリエーションを用意しておくと、フレーズ辞書を自分でメンテナンスせずとも、AppleのNLパーサーがユーザーの言い回しに柔軟にマッチできるようになります。systemImageNameは実在するSF Symbolsの名前であり、これがSpotlight、Shortcuts、Apple Intelligenceでアクションのアイコンとして描画されるしくみです。

Apple Intelligenceは、ユーザーのリクエストをApp Intents経由でルーティングし、端末内AI機能を提供します。出典：apple.com/apple-intelligence。

なぜこれがSwiftUI以来、最も重要なiOSのAPIなのか

iOSのAPIには2つの形があります。アプリ自身の描画方法に関するもの（UIKit、SwiftUI、Metal）と、システムへの統合方法に関するもの（URLスキーム、Universal Links、Widgets）です。App Intentsはこのどちらでもない、第3の形です。AppleのAIがあなたのアプリをどう利用するかを定めるAPIなのです。

その変遷をたどってみる価値があります。

• iOS 10（2016年） ではSiriKit Intents（INIntent）が導入され、サードパーティ製アプリが音声で呼び出される最初のしくみが生まれました。サーフェスは限定的で、固定ドメインのリスト（メッセージング、決済、配車）に厳格なスキーマが定められていました。⁸
• iOS 12（2018年） ではSiri Shortcutsによってサーフェスが拡張され、どのアプリでもNSUserActivityやINIntentをdonateして、Siriの提案対象になることを期待できるようになりました。
• iOS 13（2019年） では、アプリ内インテントハンドリングが追加され、ショートカット起動時にシステムのSiri UIへバックグラウンド遷移せず応答できるようになりました。
• iOS 16（2022年） ではApp Intentsフレームワークが導入され、@ParameterとAppShortcutsProviderを備えた型付き・宣言型の形になりました。新規開発において、前身のINIntentは事実上置き換えられました。⁹
• iOS 18（2024年） ではApple Intelligenceが登場し、可能な限りSiriリクエストをApp Intents経由でルーティングし始めました。Apple Intelligenceの「パーソナルコンテキスト」機能は、App Entities（App Intentsのデータ版）から情報を読み取ります。¹⁰
• iOS 26（2025年） では、Appleの端末内LLMである Foundation Models フレームワークが導入されました。Foundation Modelsは、アプリ内のツール呼び出し用に独立したToolプロトコルを公開しています。App Intentsは引き続き、Apple Intelligenceにとってアプリをまたいだ正規のサーフェスであり、Toolは直接的なLLM呼び出しのためのアプリ内サーフェスです。2つの契約は並列に動作しています。⁴

契約はリリースごとに、スタックの上方へと拡張されてきました。当初、App Intentの利用者はShortcutsアプリをタップする人間でした。次に音声のSiri、続いてSpotlight、そしてApple Intelligenceの要約。今や、Apple IntelligenceのLLMに支えられたシステムサーフェスがApp Intentsを利用して、ユーザーリクエストへのアクションを実行しています。2026年にあなたがリリースするApp Intentサーフェスこそ、iOS 27、28、29でApple Intelligenceが呼び出していくサーフェスなのです。

App IntentsがSiriの機能ではないと述べたのは、こうした流れのことです。App Intentsは、Apple AIファブリック全体に対する構造化ツール利用のためのAPIです。SwiftUIが最重要のUIAPIとなったのは、visionOS、watchOS 10以降、iOS 17以降でアプリを書く唯一の手段になったからでした。App IntentsはAI側で同じ軌跡をたどっており、Appleがすべての賭け金を投じているサーフェスなのです。

Foundation Modelsのリリースで何が変わるのか

Foundation Modelsは、Apple Intelligence対応のすべてのデバイスにバンドルされるフレームワークです。ハードウェアの対象はApple Intelligenceと同じリストです。iPhone 15 Proおよび15 Pro Max（A17 Pro）、iPhone 16ライン、iPhone 17ライン、iPhone Air、iPhone 17e、M1以降搭載のiPad Pro、M1以降搭載のiPad Air、A17 Pro搭載のiPad mini、M2以降搭載のVision Pro、そしてM1以降搭載のMacです。注目すべき点として、ベースモデルのiPhone 15 / 15 Plusは含まれていません。⁴¹²

ここから言えることはこうです。Appleのシステムサーフェス（Siri、Spotlight、Apple Intelligence）があなたのアプリを呼び出すとすれば、その経路はApp IntentsとApp Entitiesに限られます。システムAIファブリックには、サードパーティ向けのsetSystemPrompt(...)APIは存在しません。あるのはインテントレジストリだけです。Foundation Modelsは、開発者が自前の端末内LLM機能を構築したいときのために、並列となるアプリ内Toolサーフェスを追加するものです。アプリをまたいだ契約（Apple IntelligenceやSiriがアプリを発見するために使うもの）は、引き続きApp Intents経由で動いています。

アプリ開発者にとって具体的な帰結は3つあります。

該当カテゴリーで関連するApp Intentを持たないアプリは、Siriの音声コマンドからは到達できません。 Apple Intelligenceは「Hey Siri、水を記録して」のようなフレーズを、対応するインテントを先に宣言したアプリへとルーティングします。私はWaterのインテントを2026年2月にリリースしました。私のフレームワーク方向性に関する読みはこうです。2027年にインテントをリリースする水分摂取アプリは、ルーティングの重みがすでに先行プレイヤーへと積み上がった市場に参入することになります。同じ理屈は、買い物リスト、ワークアウト記録、カレンダー入力、写真検索にも当てはまります。インテント宣言における先行者利益は、複利で効いていく と私は見ています。HealthKitカテゴリー、Spotlightリッチ結果、Live Activitiesトークンといった、Apple既存のプラットフォーム賭け金APIがそうであったのと同じ構図です。

Apple Intelligenceのパーソナライズは、インテントだけでなくApp Entitiesからも情報を読み取ります。 AppEntityは「このアプリはこの形のデータを持っています」と宣言するものです。ユーザーが「最後に読書リストに追加した本は？」と尋ねると、Apple Intelligenceはインストールされている全アプリのAppEntityのうちBookにマッチするものをすべて検索します。読書リストを持つアプリでBookEntityを宣言していなければ、あなたのデータはAppleのAIサーフェスから見えません。Apple Intelligenceは、あなたのデータを取得することも参照することもできないのです。¹¹

IntentResult & ProvidesDialogという戻り値の形がますます重要になります。 Apple IntelligenceはSiri、Spotlight、Apple Watchを横断して、インテントの結果をより長い応答へと組み立てるようになっています。構造化されたダイアログを返さず単に成功だけを返すperform()は、システムから一貫した応答へと組み込みづらくなります。ProvidesDialogやProvidesViewは単なる礼儀の問題ではなく、自分のアクションをユーザーのAIサーフェスにおける引用源にするための手段なのです。

もう一度作り直すとしたらどう変えるか

Waterの本番運用ログ11週間ぶんから、もっと早くやっておくべきだったと感じることが3つあります。

思っているよりも多めにインテントをリリースすべきです。 私は1つしかリリースしませんでした。本当は4つリリースすべきだったのです。LogWaterIntent、CheckTodaysProgressIntent、AdjustGoalIntent、ShowHistoryIntentの4つです。それぞれが、ユーザーが実際に試すSiriフレーズに対応しています（「今日は水をどれくらい飲んだ？」は、私のアプリのデータではなくAppleの汎用AIへとルーティングされてしまいました）。リリースし損ねたインテントの一つひとつが、Apple Intelligenceが私のアプリを迂回するクエリとなるのです。

ダイアログ文字列は、メールの本文ではありません。 当初からProvidesDialogは備えていましたが、私の初期のダイアログは散文調でした。CarPlayやAirPodsを通じて聞くユーザーには、短く、具体的で、事実起点で構造化されたものが必要なのです。「8オンス記録しました。残り32オンスです。」のように。とくにApple Watchのサーフェスは積極的に文を切り詰めます。会話調のダイアログは、自信のある事実伝達型のダイアログより体験を悪化させます。私は4週目に書き直しました。²

App Entitiesは私が思っていたより重要です。 SwiftDataのWaterEntryモデルは持っています。それに加えてWaterEntryEntity: AppEntityと、対応するWaterEntryQuery: EntityQueryを宣言することで、Apple Intelligenceが「昨日水を飲んだのはいつか教えて」に答えられるようにすべきです。最小限のブリッジコードはこうなります。¹¹

struct WaterEntryEntity: AppEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Water Entry"
    static var defaultQuery = WaterEntryQuery()
    var id: UUID
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(amount) oz at \(timestamp.formatted())")
    }
    @Property(title: "Amount") var amount: Int
    @Property(title: "Timestamp") var timestamp: Date
}

struct WaterEntryQuery: EntityQuery {
    func entities(for identifiers: [UUID]) async throws -> [WaterEntryEntity] {
        // Fetch matching entries from SwiftData
    }
    func suggestedEntities() async throws -> [WaterEntryEntity] {
        // Recent entries Apple Intelligence can suggest
    }
}

小さなSwift型2つに、SwiftDataのフェッチ用つなぎコードを足すだけです。Spotlightで個々のエントリーを検索可能にするには（「水」と検索したユーザーが正しいエントリーに辿り着けるように）、エンティティをIndexedEntityに準拠させ、書き込み時にインデックスの更新をdonateします。これがAppleのSpotlightパイプラインが、素のAppEntity公開を超えて期待していることなのです。

同じ構造は、私の他のアプリにも当てはまります。買い物リストアプリのGet Bananasには、すでにSwiftDataの@Model ShoppingItemがあり、@Attribute(.unique) var id: UUID、name、amount、section、isChecked、それにiCloud Drive同期用のlastModifiedフィールドを備えています。¹³ これをShoppingItemEntity: AppEntityとしてラップし、いくつかのインテント（AddShoppingItem、CheckOffItem、ShowList）をリリースすれば、Get Bananasがすでに.mcpbMCPサーバー経由でClaude Desktopに公開しているのと同じ永続化レイヤーを、Apple Intelligenceにも公開できることになります。¹⁴ 2つのLLMエコシステム、2つの異なる契約、しかし同じ買い物リスト。これが「並列契約」というテーゼを、1本のリリース済みアプリで体現したかたち です。SwiftDataモデルがデータであり、App IntentsがAppleの契約、MCPがAnthropicの契約、両方のサーフェスが同じ唯一の信頼源を操作しているのです。

App Intentをリリースすべきでないとき

リリースしないという判断もまた設計の一部です。

アプリが純粋に消費型（ユーザーの写真を読む、ニュースを表示する、音声を再生する）で、ユーザーの可変な状態を持たないなら、App Intentsには公開すべきものが何もないかもしれません。AppleのフレームワークはOpenIntent（特定のコンテキストでアプリを開くだけ）をサポートしていますが、有用なアクションが「アプリを開く」だけであれば、インテントはオーバーヘッドにすぎません。「あるからリリースする」という理由でリリースしてはいけません。

UIアフォーダンスに依存していて抽象化が難しいアクション（多段階の複雑なキャンバスツール、3D編集アプリ）の場合、必須となるparameterSummaryは、誰も実際には言わない曖昧な疑似自然言語へと劣化します。「ぼかしツールを強さ7にして写真を編集して」というSiriフレーズは技術的には可能ですが、誰一人として口に出さないでしょう。インテントのサーフェスは、見返りのない税金になってしまいます。

正しい指針はこうです。App Intentが報われるのは、ユーザーが自然に発する一文がアクションを引き起こす場合です。「水を8オンス記録して」はその一文です。「レイヤー3にσ=2.4のガウシアンぼかしを適用して」はそうではありません。アプリのアクションが2つ目のパターンに集中しているなら、インテントはあなたのコンバージョン手段にはなりません。

結びの所感

3年にわたってAppleは、iOSのシステムAIファブリックがApp Intents経由で動くことを示し続けてきました。WWDC 2024ではApple Intelligenceからのルーティングが追加されました。WWDC 2025では、独立したアプリ内ツール呼び出しサーフェスとしてFoundation Modelsを並列追加し、App IntentsはSiri / Spotlight / Apple Intelligenceが使い続けるアプリ間契約として残されました。あらゆるシグナルが同じ方向を指しています。型付き・宣言型のApp Intentこそが、サードパーティ製アプリがシステムと交わすことになった契約なのです。

ほとんどのiOSアプリは、いまだApp IntentsをSiri Shortcutsとして扱っています。時間があればリリースすればいい機能、というふうに。私の見立てでは、その捉え方は早晩古びることになります。Apple Intelligenceのシステムサーフェスが拡張されていくなかで（今日すでにSiri、Spotlight、Shortcuts、Apple Intelligenceの要約に及んでいます）、インテントを宣言していないアプリは、ルーティンググラフの外側に置かれてしまう可能性が高いでしょう。先行サーフェスの利益は、Appleの他のプラットフォーム賭け金を見てきた経験から言えば、複利で積み上がっていくものです。

WaterはLogWaterIntentを11週間にわたってリリースし続けています。App Intentをリリースするためのコード量は、ファイル1つに収まるほど小さいものです。リリースしないことのコストは、Apple Intelligenceがリリースを重ねるごとに膨らんでいきます。

2026年にiOSアプリをリリースしていながら、まだ1つもApp Intentを宣言していないなら、ロードマップに抜け落ちている項目があるということです。今すぐ追加してください。

FAQ

iOS開発におけるApp Intentとは何ですか？

App Intentとは、アプリのアクションの1つをAppleのシステムAIサーフェスに公開する、型付き・宣言型のSwift構造体です。@Parameterによるパラメーター宣言、parameterSummaryによる自然言語サマリー、そして処理を実行して構造化された結果を返す非同期のperform()本体を備えます。AppleのSiri、Spotlight、Shortcuts、Apple Intelligenceから呼び出すことができます。Foundation Models（Appleの端末内LLM）は、直接的なアプリ内ツール呼び出しのために別のToolプロトコルを使用します。

App Intentsは、以前のINIntentとどう違うのですか？

App Intents（iOS 16・2022年導入）は、Appleの主たるインテントフレームワークとしてINIntentを置き換えました。新しいフレームワークは完全にSwiftネイティブで、@Parameterのようなプロパティラッパーを使い、AppEntityによる型安全なエンティティクエリをサポートし、Siri、Spotlight、Shortcuts、Apple Intelligenceが呼び出すサーフェスとなっています。古いINIntentは引き続きサポートされていますが、新たな機能追加は行われていません。

App Intentをリリースするのに、iOS 26は必要ですか？

いいえ、必要ありません。App IntentsはiOS 16以降で利用可能です。iOS 26ではFoundation Modelsフレームワークが並列に追加されますが、App Intentの宣言自体はiOS 16以降で動作します。上記の例ではSwiftData（iOS 17以降）を使っているため、デプロイメントターゲットはperform()本体が何をimportするかに依存します。素のApp IntentsはiOS 16まで遡って動作し、SwiftDataベースのものはiOS 17が必要です。

App IntentとApp Entityの違いは何ですか？

App Intentはアクション（動詞）です。App Entityはアプリが知っているデータ（名詞）です。LogWaterIntentがインテント、WaterEntryがクエリ可能な型になったものがエンティティです。Apple Intelligenceは両者を活用します。インテントでアクションを実行し、エンティティで応答内のデータを取得・参照するのです。

App IntentsはFoundation Modelsのツール呼び出しとどう関係しますか？

Foundation Modelsは、直接的なアプリ内LLMツール呼び出しのために独自のToolプロトコルを公開しています。App Intentsは引き続き、Apple Intelligence、Siri、Spotlightが呼び出すアプリ間横断の正規サーフェスです。同じ方向（型付き・宣言型のツール利用）でありながら、2つの並列契約となっています。システム AIサーフェスから到達可能になりたいアプリはApp Intentsをリリースし、自前 の端末内LLMをカスタムツールで呼び出したいアプリはToolへの準拠をリリースします。多くのアプリは両方をリリースすることになるでしょう。

App Intentsは機能ではありません。契約です。先にインテントをリリースしたアプリがそのサーフェスを獲得し、後からリリースするアプリは、サーフェスがすでに別のところへルーティングされているのを目にすることになります。11週間前、私はWaterで1つリリースしました。複利はもう動き始めています。

Apple Ecosystemシリーズの他の記事

このエッセイは入り口です。残りの4本は、アーキテクチャスタックの他の部分をカバーしています。

• Two Agent Ecosystems, One Shopping List：Get BananasがiCloud Drive上の1つのJSONファイルを通じて、Apple Intelligence（App Intents）とClaude Desktop（MCP）に同じデータをどう公開しているか。
• Liquid Glass in SwiftUI: Three Patterns From Shipping Return：iOS 26ビジュアルレイヤーの本番運用パターン。
• Five Apple Platforms, Three Shared Files：マルチプラットフォーム展開戦略。コードを共有すべきとき、ターゲットを分岐すべきとき。
• HealthKit + SwiftUI on iOS 26：認可フロー、サンプルタイプ、そしてユーザーをアプリから締め出してしまう落とし穴に関するデータソース層。

または、ハブから一覧をご覧ください。Apple Ecosystem Series。AIエージェントを活用した広範なiOS開発の文脈については、iOS Agent Development guideを参照してください。

References