App Intents と MCP：ルーティングの問題

App Intents と MCP という2つのプロトコルは、どちらも外部のエージェントにアプリのドメインを操作させるためのものです。しかし、この2つが1つに統合されることはありません。問われるのは、どの機能をどちらに載せるのか、そしてなぜそれぞれのプロトコルが自分の呼び出し元にとって正しい答えなのか、という点です。

Apple が App Intents を投入したのは、Apple Intelligence がサードパーティ製アプリの UI に触れずにそれを操作できる、型付きで宣言的なサーフェスを与えるためでした。¹ Anthropic が Model Context Protocol を投入したのは、あらゆる LLM が任意のツールを UI に触れずに操作できる、型付きでサーバーを介したサーフェスを与えるためです。² 形は似ています。呼び出し元は似ていません。両者を1つのサーフェスとして扱えば、どちらの要求も満たさないアーキテクチャができあがります。

このクラスタの先行する2本の記事では、それぞれのプロトコルを単独で扱いました。App Intents はApp Intents はアプリへの Apple の新しい APIで、MCP は2つのエージェント・エコシステムと1つの買い物リストで取り上げています。今回のテーマはルーティングの問題です。ある機能はどんなときに AppIntent になり、どんなときに MCP ツールになり、どんなときに両方になるのか。そして、どこまでをアプリの内側だけに留めておくべきなのでしょうか。

TL;DR

• App Intents は、Apple Intelligence、Siri、Shortcuts、そしてシステムの提案スタックへ届く唯一の経路です。システムはインストール直後から、そしてアプリのアップデートを通じてこれらを利用可能にし、App Shortcuts のドネーションとインデックス化によって Spotlight や Siri の提案へと表面化させます。
• MCP ツールは、Apple 以外のあらゆる LLM（Claude、ChatGPT、Gemini、ローカルモデル）へ届く経路です。トランスポートは stdio または Streamable HTTP で、.mcpb はローカルの stdio サーバーを同梱することが多いパッケージング形式です。ホストはセッション開始時にツールを読み込みます。現行の仕様リビジョンは 2025-11-25 で、2026-07-28 のリリース候補ではプロトコルがステートレスなコアを軸に作り直されています⁶⁷。
• 両プロトコルは、型付きスキーマ、entity → action → result という形、そしてパラメータ解決という点で一致します。分かれるのは、アイデンティティ、永続性、レイテンシ、そしてレンダリングのサーフェスです。
• ルーティングの原則はこうです。ユーザーが Siri に頼んだり Spotlight から呼び出したりしそうな機能なら App Intents。開発者が Claude Code のセッションや外部エージェントの実行に組み込みそうな機能なら MCP。多くのアプリは、同じドメインに対して両方を必要とします。

2つのプロトコル、同じ形

どちらのプロトコルも、外部の呼び出し元とアプリのドメインとのあいだの操作契約を定義します。契約は3つの部分から成ります。スキーマ（呼び出し元が何を要求できるか）、リゾルバ（スキーマが名指しするエンティティをアプリがどう見つけるか）、そしてアクション（何が実行され、何が返るか）です。

App Intents はこの契約を Swift で表現します。プロトコルのサーフェスは AppIntent、AppEntity、AppEnum であり、@Parameter マクロがスキーマを駆動し、func perform() が結果を返します。³ スキーマはコンパイル時に生成され、インストール時にアプリへ同梱されます。Apple Intelligence、Siri、Shortcuts、Spotlight はいずれも同じスキーマを読み、型付きのリクエストを同じ perform() のエントリポイントへ流します。

MCP はこの契約を、stdio または Streamable HTTP 上の JSON-RPC で表現します。プロトコルのサーフェスは tools/list と tools/call というメソッドで、各ツールが名前、説明、inputSchema を宣言します（2025-06-18 の仕様では構造化された戻り値のために任意の outputSchema が追加され、2025-11-25 のリビジョンでは JSON Schema 2020-12 が既定のダイアレクトとして定められ、メタデータとしてのツールアイコンが加わり、Anthropic の枠を超えたガバナンスが明文化されました）。⁴⁶ MCP ホスト（Claude Desktop、Claude Code、Cursor、ChatGPT デスクトップアプリ）はセッション開始時にツールを発見し、JSON のペイロードを添えて名前で呼び出します。モデルを動かすのはホスト、ツールを動かすのはサーバーです。プロトコル自体も移行の途上にあります。2026-07-28 のリリース候補では、MCP は通常の HTTP インフラ上で動くステートレスなコアを軸に再構築され、長時間かかる処理は Tasks 拡張へ移り、MCP Apps によるサーバー側レンダリングの UI が加わりました⁷。以下のルーティングの議論はこの改訂を経てもそのまま成り立ちます。呼び出し元が誰かという点は、何も変わっていないからです。

形は同じです。スキーマ、リゾルバ、アクション。違うのは、それぞれの部分を誰が動かすのか、そして信頼境界がどこにあるのかです。App Intents はアプリのプロセス内、ユーザーのデバイス上で、アプリのエンタイトルメントのもとに動き、呼び出しのルーティングはシステムが仲介します。MCP サーバーは開発者が選んだ場所（ローカルの stdio、ホスティングされた HTTP、埋め込みバンドル）で動き、無数のツールにまたがる呼び出しのルーティングはホストの LLM が仲介します。

同じ形を持つ3つ目の呼び出し元にも触れておくと、全体像が完成します。Apple の Foundation Models フレームワークの背後にあるオンデバイスモデルは、Tool プロトコルを通じてアプリのコードを呼び出します。名前が付き、説明が付き、型が付いた機能という点で、他の2つと同じものです。よく設計されたドメイン層は、どれが呼んでいるのかを知らないまま、この3つのサーフェスすべてに同じものを供給できます。

2つのプロトコルが食い違うところ

表面的な形を越えて、ルーティングの判断に効く運用上の違いが4つあります。

アイデンティティと永続性。 App Intents は、システムが保存し、提示し、後から再解決できる AppEntity 型で語ります。Hey Siri、Water に 250ml を記録してと言って今日保存した水分の記録は、再起動をまたいで残り、ユーザーの iCloud 上のデバイス間で同期し、後から別のインテントから参照できます（昨日の水分記録を見せて）。システムはそれらの呼び出しすべてにわたってエンティティ ID を追跡し、³ iOS 27 ではその物語がハードウェアをまたいで広がります。SyncableEntity に準拠したエンティティは、ユーザーのデバイス間で一貫した識別子を持つため、Siri は同じオブジェクトについての会話を iPhone から Mac へ、Mac から Watch へと引き渡せます。⁸ MCP 自体もライフサイクル管理を備えたステートフルなプロトコルであり、Streamable HTTP は接続の継続性のためにセッション ID をサポートします。しかし、永続的なドメインのアイデンティティはサーバー側が持つ関心事であり、ホストのモデルがセッションをまたいで頼れるような、AppEntity の識別子に相当するプロトコルレベルの仕組みはありません。MCP は永続的な参照データのために resources を備え、2025-11-25 の仕様では永続的なリクエストを追跡する実験的な tasks が加わりましたが、ドメインオブジェクトのアイデンティティは依然としてサーバー側の責務であり、第一級のプロトコル契約ではありません。⁴⁶ 根っこにある規律は、アプリ自身のデータ層に当てはまるものと同じです。プロセスの寿命を越えて生き残る安定した識別子については、SwiftData の観点からスキーマの規律で扱っています。

レイテンシとバッテリー。 App Intent の perform() の本体は、デバイス上のアプリまたはアプリ拡張のコンテキストで実行されます。ネットワーク利用が発生するとすれば、それはアプリ自身のコードか、その周囲にある Apple Intelligence / Siri のレイヤーからであって、インテントの契約そのものからではありません。型付きのオンデバイスなアクションが型付きの結果を返す構図は、通常の場合は高速です。MCP ツールは、ローカルのものであっても stdio 上の JSON-RPC フレーミングを通り、別プロセスとの境界をまたぎます。リモートの MCP ツールなら HTTP のラウンドトリップが加わります。レイテンシの予算が違うのです。250ml を記録する App Intent は、Siri の発話のやり取りの間に収まります。リモートの MCP ツールは、Claude Code のセッションのボトルネックになりかねません。

レンダリングのサーフェス。 App Intents が返す結果は、Apple Intelligence がシステム UI へと描画します。ロック画面のバナー、Siri の応答、Shortcuts の出力、Spotlight の検索結果です。結果がどう提示されるかをアプリは制御できません。MCP ツールはコンテンツブロック（テキスト、画像、音声、埋め込みリソース、構造化コンテンツ）を返し、それを読んだホストのモデルが、どう見せるかを決めます。Claude Code のセッションであれば、結果をそのまま開発者に引用するかもしれませんし、要約するかもしれませんし、次の呼び出しへ流し込むかもしれません。レンダリングの判断はモデルの層にあります。

発見のされ方。 Apple Intelligence は、インストールされた時点から App Intents を利用可能にし、App Shortcuts のドネーションとインデックス化によって、ユーザーの行動に基づいてインテントを Spotlight 検索や Siri の提案へと表面化させます。アプリのアップデートや動的なエンティティによって、そのサーフェスは時間とともに変化します。ユーザーがツール名を打ち込むことはありません。MCP のホストはセッション開始時にツールを読み込み、モデルにどのツールを見せるかはユーザー（あるいはシステムプロンプト）が決めます。発見は、MCP 側では明示的な設定であり、App Intents 側では暗黙的なシステムの推測なのです。

2つのプロトコルは、アイデンティティ、レイテンシ、レンダリング、発見という4つの性質で食い違います。そしてこの4つは、1つの根本的な違いから導かれます。App Intents が相手にするのは、ユーザーが設定した覚えのないシステムレベルのエージェントです。MCP が相手にするのは、開発者が設定したセッションレベルのエージェントです。呼び出し元が違えば、負うべき義務も違います。

ルーティングの原則

両方のプロトコルを備えるアプリの機能マップは、次のようになります。

                    ┌──────────────────────────────────────────┐
                    │           App's domain capabilities       │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Both (AppIntent +   │    │  MCP tools   │
       │   only      │    │  MCP tool wrapper)  │    │    only      │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Cross-protocol           Claude Code,
       Shortcuts              capabilities             external agents,
       Apple Intelligence     where both callers       LLM tooling,
       proactive surfaces     should reach the         dev workflows
                              same domain

ルーティングの原則は、順に問う3つの質問です。

その機能は、ユーザーが Siri に頼んだり Shortcuts から呼び出したりするものか。 そうであれば、その機能には App Intent が必要です。水を 250ml 記録して、瞑想を始めて、リストにバナナを追加して、昨日の体重は——これらがインテントなのは、ユーザーが声に出して言い、Spotlight に打ち込み、Shortcuts でつなぐかもしれないからです。そうした機能にとって App Intent は任意ではありません。Apple Intelligence というファーストパーティのエージェント・サーフェスへ到達する手段は、他にないのです。

その機能は、外部のエージェントが動かせるべきものか。 そうであれば、その機能には MCP ツールが必要です。Claude Code のセッションから買い物リストに項目を追加する、Get Bananas の状態を Cursor のエージェントのコンテキストへ読み込む、リモートのツール利用型 LLM からワークフローを起動する——これらが MCP ツールなのは、呼び出し元が Apple Intelligence ではないからです。呼び出し元は、開発者がつないだ任意の LLM です。MCP ツールは App Intent が呼ぶのと同じドメイン層の Swift 関数をラップできますが、プロトコルのサーフェスは開発者が選んだトランスポート上の JSON-RPC です。

その機能は、システムが知る安定したアイデンティティを持って、単一のセッションより長く生き残る必要があるか。 そうであれば App Intent の経路が自然に噛み合います。システムが AppEntity のアイデンティティ、クエリのサポート、永続性のセマンティクスをただで与えてくれるからです。そうでなければ、MCP ツールはコンテンツブロックを返し、永続的なアイデンティティはサーバーの裁量に委ね、エンティティをモデリングするコストを省けます。

自明でないアプリの機能の多くは、両方の列に入ります。Water の水分記録の機能には AppIntent があり（Siri が口述筆記を受け取れるように）、MCP ツールもあります（Claude Code のセッションがエクスポート済みのログから過去分を埋められるように）。この2つの経路は1つの Swift 関数を共有し、その関数はどちらの呼び出し元が起動したのかを知りません。⁵

コードにすると、1つのドメインメソッドと、それを呼ぶ2つのアダプタというラッパーの形になります。

// Domain layer (Swift, no protocol assumptions)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter 1: App Intent (Apple Intelligence / Siri / Shortcuts)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>

    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)
    }
}

// Adapter 2: MCP tool (Claude Desktop / Code / external agent)
// Tool name "log_water" with inputSchema {amount_ml: number}
// Handler:
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

2つのアダプタが違って見えるのは、呼び出し元が違うからです。呼んでいる関数は同じものです。

アプリの内側に留めるもの

数は少ないものの重要な機能の一群は、アプリの中に閉じたままにしておくべきです。それらをどちらかのプロトコルへ回すのは誤りです。

UI の状態に関わる機能。 「3番目のタブを開く」「一番下までスクロールする」「この行をハイライトする」はドメインの操作ではありません。インタラクションのプリミティブです。App Intents は OpensIntent や Shortcuts を通じてある程度これを支援しますが、ジャンルとしての相性はよくありません。ユーザーが求めているのはたいてい結果であって、画面遷移ではないのです。MCP の UI ナビゲーション対応はさらに分が悪くなります。モデルが動かしているのは画面ではなく、ツールだからです。

人間の身体をループに要する機能。 写真の撮影、生体認証、機微な個人情報の入力、そしてユーザーが画面を見てタップする必要のあるあらゆるフローです。カメラのフローのために Apple の CameraCaptureIntent は存在しますが、その設計意図はフォアグラウンドの撮影アクティビティを起動することであって、エージェントにバックグラウンドのカメラアクセスを与えることではありません。両プロトコルに共通する正直な原則はこうです。カメラ、生体認証、機微な入力のフローは、無言のインテント呼び出しやツール呼び出しではなく、ユーザーの明示的な確認を伴うフォアグラウンドの UI として動かすべきです。これらの機能はアプリの UI の内側に置いたまま、エージェントにはユーザーを画面へ導かせるのであって、画面を通り抜けさせるのではありません。

長時間かかるバックグラウンド処理。 ここでは両プロトコルとも実用的なプリミティブを備えるに至り、判断は「決してやらない」から「プロトコルの仕組みを使って、意識的にやる」へと動きました。Apple 側では、iOS 27 の LongRunningIntent により、進捗を報告することを条件に、システムの30秒というバックグラウンド制限を越えてインテントを動かせます（このプロトコルは ProgressReportingIntent を精緻化したものです）。その進捗は Live Activities が描画します⁸。MCP 側では、2025-11-25 の仕様がポーリングと遅延した結果の取得を伴う永続的なリクエストのための実験的な tasks を加え、2026-07-28 のリリース候補では Tasks 拡張へと昇格しました⁶⁷。いまの正直な線引きはこうです。呼び出し元が自ら処理を始め、それを見守ることを期待しているなら、プリミティブを使いましょう。消費側が必要とする「進捗」がパーセンテージより豊かなものである場合や、ホストのモデルが待つあいだに推論の連鎖をタイムアウトさせてしまう場合には、その処理をアプリ自身の UI の内側に留めておきましょう。終わりの見えない処理に対しては、リクエストはキューに入りました。こちらがステータス画面ですが、いまも正しい戻り値です。

他のユーザーのデータに触れるもの。 どちらのプロトコルでも、信頼境界は呼び出しているエージェントです。Apple Intelligence はユーザーの iCloud アカウントのもとで動きます。MCP は開発者がつないだ資格情報のもとで動きます。ユーザーをまたぐ操作（共有、複数アカウントへのアクセス、管理者操作）は、呼び出し元のアイデンティティが正しいアイデンティティではないため、どちらのプロトコルを通しても安全ではありません。

自分ならこう作り直す

上のルーティングの原則を踏まえると、Swift アプリのドメイン層は、いまサービスの境界で API を設計するときと同じやり方で設計することになります。ドメインのメソッドは型付きの入力を受け取り、型付きの出力を返し、プロトコルの前提は一切焼き込みません。App Intents は @Parameter のスキーマと perform() のつなぎで、ドメインのメソッドを薄くラップします。MCP ツールは JSON スキーマと stdio のフレーミングで、同じドメインのメソッドを薄くラップします。どちらのプロトコルも薄いアダプタであり、仕事はドメインの側にあるのです。

ここから2つの帰結が導かれます。

呼び出し元のアイデンティティはドメインの関心事であって、プロトコルの関心事ではありません。 App Intent の本体は、システムが解決したパラメータを受け取り、ユーザーがシステムのインテント起動フローを通ってきたコンテキストで実行されます。MCP ツールの本体は、ホストが用意した資格情報を受け取ります。どちらも明示的な caller 引数としてドメインのメソッドへ受け渡されます。認可、確認プロンプト、その他のドメイン不変条件を強制するのはドメインのメソッドです。呼び出し元がユーザーであるかのように振る舞う権限は、どちらのプロトコルにも与えません。

2つのアダプタは同じアフォーダンスの集合を差し出します。 どの機能をどの呼び出し元に見せるかという判断は、あちこちに散らばったプロトコルのコードではなく、2つのマニフェストに記述されます。機能を1つ追加するとは、ドメインのメソッドが1つ、アダプタのラッパーが2つ、マニフェストのエントリが2つということです。機能の削除も対称的です。先ほどのマトリクスが、実在するファイルになるわけです。

これから数年の Apple プラットフォームのフロンティアは、どちらか一方のプロトコルを選ぶことではありません。フロンティアは、両者を同じドメイン層で合成される直交した契約として扱うことにあります。Apple Intelligence のエージェントは、ユーザーに対して一組の義務を負います（オンデバイスで動き、Siri として話し、システムを通じて描画する）。外部の LLM エージェントは、開発者に対して別の一組の義務を負います（どこででも動き、JSON-RPC で話し、開発者が選んだモデルを通じて描画する）。どちらも、あなたのアプリへの型付きのサーフェスを与えられるに値します。そして、どちらも唯一のサーフェスであるに値しません。

両方を作るべきでないとき

この議論は両方向に切れます。片方のプロトコルだけが必要で、もう片方は要らないアプリもあります。

開発者向けのサーフェスを持たない純粋な消費者向けユーティリティ。 懐中電灯アプリ。鳥の鳴き声の識別アプリ。AR の巻き尺。ユーザーは Siri から呼び出したいと思うかもしれませんが（App Intents は役に立ちます）、それを LLM のワークフローに組み込む開発者はいません（MCP は見せかけにしかなりません）。

エンドユーザー向けのサーフェスを持たない純粋な開発者向けツール。 コードフォーマッタの MCP サーバー。リポジトリ検索のツール。パッケージのバージョンを調べるツール。ここでのユーザーは Claude Code のセッションにいる開発者であり、Siri や Apple Intelligence の出番はありません。

どちらのエージェント層にもうまく応えられないアプリ。 操作性が高いゲーム、リアルタイムのマルチプレイヤーアプリ、アプリの中にいて画面を見ていることに価値があるアプリ。どちらのプロトコルも噛み合いません。正解は、すばらしいアプリを作り、エージェントとの契約は持たないことです。

判断すべきは既定で片方か両方かではありません。判断すべきはこのアプリは何のためのもので、他に誰がそのドメインを操作したがるかです。答えは、どちらも要らない、片方だけ、両方、のいずれにもなり得ます。ドメイン層がよく設計されていれば、片方を作るコストは小さくて済みます。そのドメイン層の上に両方を作るコストも、やはり小さくて済みます。大きいのは、ユースケースが求めているのに片方を作らないコストです。その場合、その機能はそのエージェント・サーフェスから完全に姿を消します。

このパターンが iOS 26 以降の Apple スタックに意味すること

持ち帰るべき点は2つです。

1. App Intents と MCP は、競合するプロトコルではなく、同じドメインに対する直交した契約として扱いましょう。 Apple Intelligence、Siri、Shortcuts、Spotlight は、システムレベルの義務を伴う1つの呼び出し元の層です。Claude、Cursor、ChatGPT などは、セッションレベルの義務を伴う2つ目の呼び出し元の層です。どちらも型付きのアクセスを与えられるに値します。その下にあるドメイン層は変わりません。

2. ルーティングの原則は誰が呼ぶかであって、何が動くかではありません。 App Intent と MCP ツールは、同じ Swift 関数を呼べます。違うのは、呼び出し元が負う義務、返ってくるレンダリング、そして期待される永続性です。関数を正しく作り、プロトコルの層は薄いままにしておきましょう。

Apple Ecosystem クラスタの全体像はこうです。Apple Intelligence のための型付き App Intents、LLM をまたぐエージェントのための MCP サーバー、ロック画面の状態機械のための Live Activities、視覚的な層のための Liquid Glass のパターン、そしてデバイスをまたいで届けるためのマルチプラットフォーム展開。ハブは Apple Ecosystem シリーズにあります。iOS と AI エージェントというより広い文脈については、iOS エージェント開発ガイドをご覧ください。

よくある質問

同じ機能について、App Intent と MCP ツールのどちらを作るべきですか

その機能を Apple Intelligence、Siri、Shortcuts、Spotlight へ届けたいなら App Intent を作りましょう。外部の LLM（Claude、ChatGPT、Claude Code や Cursor 上のエージェント）へ届けたいなら MCP ツールを作りましょう。両方の呼び出し元の層に応えるべきドメイン機能なら、共有された Swift のドメインメソッドの上に、薄いアダプタとして両方を作ります。

App Intents と MCP サーバーは互いに競合しますか

いいえ。App Intents は Apple のファーストパーティのエージェント・スタックへの経路であり、MCP はそれ以外のすべての LLM への経路です。Apple Intelligence が MCP ツールを呼ぶことはなく、外部の LLM エージェントが App Intents を直接起動することもできません（システムを経由します）。2つのプロトコルは、異なる信頼モデル、異なるレイテンシ予算、異なるレンダリングのサーフェスを持つ、異なる呼び出し元の層に応えるものです。

1つのアプリが両方のプロトコルでドメインを公開できますか

できますし、エージェントへの到達範囲を広く取りたい自明でないアプリの多くは、そうすべきです。Get Bananas（MCP サーバーの記事で扱いました）と Water（App Intents の記事で扱いました）が初期の例です。パターンは、下にドメイン層を置き、その上に App Intent のアダプタと MCP ツールのアダプタを並べるというものです。どちらのアダプタも同じ Swift 関数を呼びます。

Apple Intelligence が追跡していて MCP が追跡しないものは何ですか

Apple Intelligence は AppEntity のアイデンティティを、呼び出しをまたぎ、セッションをまたぎ、再起動をまたいで追跡します。iOS 27 の SyncableEntity を使えば、ユーザーのデバイスをまたいでも追跡できます⁸。エンティティのモデルは、ユーザーがインテントをまたいでつなげる永続的な参照をシステムに与えます。MCP 自体もライフサイクル管理を備えたステートフルなプロトコルであり、Streamable HTTP にはセッション ID もありますが、永続的なドメインのアイデンティティは第一級のプロトコル契約ではなくサーバー側の責務です。ホストのモデルは、プロトコルのサーフェスから AppEntity に相当する識別子を受け取りません。MCP の resources という概念と 2025-11-25 の仕様の実験的な tasks は、永続的な参照データと永続的なリクエストを支えますが、どちらもサーバーが持つ同じ層で動くものです⁶。

どちらのプロトコルでも公開すべきでない機能はありますか

あります。UI の状態に関わる機能（このタブを開く、ここまでスクロールする）、人間の身体をループに要する機能（写真の撮影、生体認証、機微な入力）、そして複数ユーザーのデータにまたがる操作は、アプリの UI の内側に留めるべきです。どちらのプロトコルも、ユーザーをまたいで安全に操作するために必要な信頼のシグナルを運んでいません。長時間かかるバックグラウンド処理は、線引きが動いた例外です。iOS 27 の LongRunningIntent と MCP の tasks 拡張がいまや実用的なプリミティブを与えているので、その仕組みを通じて意識的に公開し、終わりが見えず進捗バーより豊かな情報を要する処理だけを自分の UI の内側に残しましょう。

参考文献