App IntentsはAppleがあなたのアプリに用意した新たなAPIです

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

その11週間前、私は水分摂取を記録するiOSアプリ「Water」に、たった1つのSwiftファイルを追加しました。LogWaterIntent.swift という、80行の AppIntent と、3種類のSiriフレーズを宣言する AppShortcutsProvider から成るファイルです。今では、このファイルが私の所有する中で最もホットなAPI面となっています。²

ここで腑に落ちるまで時間がかかった部分があります。App IntentsはSiriの機能ではありません。 これは、サードパーティアプリがApple Intelligence——AppleがiOS 18でロールアウトを始め、iOS 26にかけて構築を続けているシステムAI面——と交わす契約なのです。³ iOSアプリをリリースしているにもかかわらず、いまだApp Intentsを「あれば便利」な音声機能として扱っているなら、Appleが築いてきたものを読み違えています。App Intentsは、Apple Intelligenceがユーザーの代わりにあなたのアプリとして振る舞うことを可能にするAPIです。それ以外のすべて（Siri、Spotlight、Shortcuts、Apple Intelligenceの要約、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ファブリックは宣言された intent を経由するか、あなたのアプリを迂回して競合へとルーティングするかのどちらかです。
• Appleはこのことを3年間にわたり伝えてきました。命名（App Intents、App Shortcuts、Apple Intelligence）には意図があります。WWDCを迎えるたびに、契約はスタックの一段上へと進んでいます。

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が「log 12 oz of water」をパースすると、LogWaterIntent(amount: 12) を生成して perform() を呼び出します。私の側で文字列解析をする必要は一切ありません。型システムがそのままスキーマなのです。⁵

parameterSummary はパラメーターの自然言語による反映です。 AppleはこれをShortcuts UI、ダイアログ、そして増えつつあるApple Intelligenceの確認パネルでアクションをレンダリングするのに使います。サマリーはユーザーに対して読み上げられます。間違えればぎこちない文章を聞かせることになり、正しく書けば面はネイティブに感じられます。⁶

perform() は IntentResult & ProvidesDialog を返します。 これが構造化された戻り値です。AI面は成功/失敗だけでなく、ユーザーに聞こえるダイアログ文字列も受け取ります。Appleは ProvidesDialog、ProvidesView、ReturnsValue をますます期待するようになっており、その結果がSiri、Spotlight、Watch、そして（iOS 26では）Apple Intelligenceの応答チェーンへと組み込まれていきます。⁷

末尾の AppShortcutsProvider ブロックがSiriフレーズを登録する部分です。\(.applicationName) トークンには、Siriが自動的に「Water」を挿入します。同じ intent に対して3つのフレーズバリアントを用意することで、フレーズ辞書を自分で保守しなくても、AppleのNLパーサーがユーザーの言い回しに合致できる余地が広がります。systemImageName は実在するSF Symbolsの名称で、Spotlight、Shortcuts、Apple Intelligenceがアクションのアイコンをレンダリングする際に使われます。

SwiftUI以来、最も重要なiOSのAPIである理由

iOSのAPIには2つのかたちがあります。1つはアプリが自身をどう描画するかに関わるもの（UIKit、SwiftUI、Metal）。もう1つはアプリがシステムとどう統合するかに関わるもの（URLスキーム、Universal Links、ウィジェット）です。App Intentsは第3のかたち、つまりAppleのAIがあなたのアプリをどう使うか、というものです。

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

• iOS 10（2016年） はSiriKit Intents（INIntent）を導入しました。サードパーティアプリが音声で呼びかけられるようになった最初の機会です。面は狭く、固定されたドメイン（メッセージング、決済、配車予約）に厳格なスキーマでした。⁸
• iOS 12（2018年） はSiri Shortcutsで面を広げました。あらゆるアプリが NSUserActivity または INIntent をdonateし、Siriが提案してくれるよう期待できるようになりました。
• iOS 13（2019年） ではアプリ内 intent 処理が追加され、システムの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年） は Foundation Models フレームワーク——AppleのオンデバイスLLM——を導入しました。Foundation Modelsはアプリ内ツール呼び出しのために別個の Tool プロトコルを公開しています。App IntentsはApple Intelligence向けの正規のクロスアプリ面として残り、Tool は LLM 直接呼び出しのアプリ内面となります。両者の契約は並行して動きます。⁴

契約はリリースごとにスタックの上へと拡張されてきました。当初、App Intentの利用者はShortcutsをタップする人間でした。次にSiri音声、次にSpotlight、次にApple Intelligenceの要約。そして今、Apple IntelligenceのLLMに裏打ちされたシステム面が、ユーザーのリクエストに基づいて行動するために App Intents を使っています。2026年にあなたが出すApp Intent面は、iOS 27、28、29でApple Intelligenceが呼び出すことになるものなのです。

上記のパターンこそ、App IntentsがSiriの機能ではないと私が言うときの意味するところです。これは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とiPhone 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 など存在しません。あるのは intent レジストリです。Foundation Modelsは、独自のオンデバイスLLM機能を持ちたい開発者のために、並行するアプリ内 Tool 面を追加します。クロスアプリの契約（Apple IntelligenceとSiriがあなたのアプリを見つけるために使うもの）は、App Intents経由で動きます。

アプリ開発者にとって具体的な3つの帰結を挙げます。

カテゴリー内に該当するApp Intentがないアプリは、その分野のSiri音声コマンドから到達不可能です。 Apple Intelligenceは、「Hey Siri、水分摂取を記録して」のようなフレーズを、対応する intent を最初に宣言したアプリへルーティングします。私はWaterのintentを2026年2月にリリースしました。私のフレームワーク方向性の読みでは、2027年に intent をリリースする水分管理アプリは、ルーティングの重みづけが先行者へすでに蓄積された市場へ参入することになります。買い物リスト、ワークアウト記録、カレンダー登録、写真検索にも同じ論理が当てはまります。intent宣言における先行者優位は、複利的に積み上がっていくと予想します。これまでもAppleの他のプラットフォーム賭け金API（HealthKitカテゴリー、Spotlightリッチリザルト、Live Activitiesトークン）で起きてきた通りです。

Apple Intelligenceのパーソナライゼーションは、intentだけでなくApp Entitiesからも読み取ります。 AppEntity は「このアプリにはこの形のデータがある」と宣言します。ユーザーが「読書リストに最後に追加した本は何だった？」と尋ねると、Apple Intelligenceはインストール済みのすべてのアプリにわたって Book に該当するすべての AppEntity を検索します。読書リストを持つアプリで BookEntity が宣言されていなければ、そのデータはAppleのAI面からは見えません。Apple Intelligenceはあなたのデータを取得することも参照することもできません。¹¹

IntentResult & ProvidesDialog という戻り値の形は、ますます重要になります。 Apple IntelligenceはSiri、Spotlight、Watchをまたいで、より長い応答に intent の結果を組み込んでいます。構造化されたダイアログのない単純な成功を返すだけの perform() は、首尾一貫した返答にシステムが組み込みにくくなります。ProvidesDialog と ProvidesView は任意の心遣いではありません。あなたのアクションがユーザーのAI面において引用元となるための仕組みです。

もう一度作るなら何を変えるか

Waterで11週間にわたるプロダクションログを見ると、もっと早くやっておくべきだった3つのことが見えてきます。

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

ダイアログ文字列は、メールの本文ではありません。 当初から ProvidesDialog を持っていましたが、初期のダイアログは散文調でした。CarPlayやAirPodsを通じて聴くユーザーには、短く、具体的で、事実を先に伝える構造が必要です：「8 oz logged. 32 oz to go.（8オンス記録。残り32オンス）」。特にWatchの面は容赦なく切り詰めます。会話的なダイアログは、自信を持って事実を伝えるダイアログよりも体験が劣ります。私は4週目に書き直しました。²

App Entitiesは思っていた以上に重要です。 WaterEntry のSwiftDataモデルがあります。これに加えて 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())")
    }
    var amount: Int
    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に表示できるようにする（「water」を検索しているユーザーが、適切なエントリにたどり着けるようにする）には、entityを IndexedEntity に準拠させ、書き込み時にインデックス更新をdonateします。これがAppleのSpotlightパイプラインが、素の AppEntity 公開を超えて期待していることです。

私の他のアプリにも同じ形が当てはまります。買い物リストアプリのGet Bananasにはすでに @Attribute(.unique) var id: UUID、name、amount、section、isChecked、加えてiCloud Drive同期用の lastModified フィールドを持つSwiftDataの @Model ShoppingItem があります。¹³ これを ShoppingItemEntity: AppEntity としてラップし、いくつかの intent（AddShoppingItem、CheckOffItem、ShowList）をリリースすれば、Get Bananasがすでに .mcpb MCPサーバーを通じてClaude Desktopに公開しているのと同じ永続化レイヤーを、Apple Intelligenceにも公開できます。¹⁴ 2つのLLMエコシステム、2つの異なる契約、同じ買い物リスト。これが、1つのリリース済みアプリにおける並行契約テーゼの実例です。SwiftDataモデルがデータ、App IntentsがAppleの契約、MCPがAnthropicの契約、両方の面が同じ真実の源を操作するのです。

App Intentをリリースしない方が良いとき

選ばないこともデザインの一部です。

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

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

正しいルールはこうです：App Intentが価値を持つのは、アクションを引き起こすためにユーザーが自然に口にする文があるときです。「8オンスの水を記録して」はその文です。「レイヤー3にσ2.4のガウスぼかしを適用して」はそうではありません。アプリのアクションが後者のパターンに集中しているなら、intentはあなたのコンバージョンレバーではありません。

締めの一言

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の要約を通じて）、intentを宣言していないアプリは、ルーティンググラフの外側に置かれることになりそうです。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のメインのintentフレームワークとして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 がintent。WaterEntry をクエリ可能な型にしたものがentityです。Apple Intelligenceは両方を使います。intentはアクションを行うため、entityは応答内でデータを取得・参照するために使います。

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

Foundation Modelsは、直接的なアプリ内LLMツール呼び出しのために独自の Tool プロトコルを公開します。App IntentsはApple Intelligence、Siri、Spotlightが呼び出す正規のクロスアプリ面として残ります。同じ方向（型付きで宣言的なツール利用）の2つの並行する契約です。システム AI 面から到達されたいアプリはApp Intentsをリリースします。自前のオンデバイスLLMをカスタムツールで呼び出したいアプリは Tool 準拠をリリースします。多くのアプリは両方をリリースすることになるでしょう。

App Intentsは機能ではありません。契約なのです。先に intent をリリースしたアプリが面を獲得し、後からリリースしたアプリは、面がすでに別の場所へルーティングされていることに気づきます。11週間前、私はWaterに1つリリースしました。複利はすでに始まっています。

References