Foundation Models On-Device LLM：Tool プロトコル

ジャンル： frontier-essay。本記事では、Apple が WWDC 2025 で公開したオンデバイス LLM の契約を取り上げ、ルーティングの問いを掘り下げます。LanguageModelSession が適切なのはいつか、AppIntent が適切なのはいつか、MCP が適切なのはいつか、そしていずれでもないのはいつか。

iOS 26 では、Apple Intelligence 対応のすべてのデバイスに 30 億パラメータの言語モデルが搭載されます。¹ Apple はこのフレームワークを Foundation Models と呼んでいます。フレームワークはローカルで動作します。推論は Apple silicon 向けに最適化され、オンデバイスで実行されます。ネットワークは呼び出しパスには含まれません。モデルは SystemLanguageModel.default に存在し、アプリは LanguageModelSession を取得します。そして、そのセッションに有用な処理を実行させるための型付き表面が Tool プロトコルです。

Tool プロトコルは、アプリ開発者にとって最も重要な部分です。これがなければ、オンデバイス LLM は単なるチャット補完エンドポイントにすぎず、アプリのデータ、ユーザーのデータ、システムの他の部分と接続されることはありません。Tool があれば、モデルは型付きの Swift 関数を呼び出し、型付きの結果を受け取り、次のターンでその回答について推論できます。ツールで拡張されたオンデバイス生成こそが、このフレームワークの本来の能力です。チャット表面はデモにすぎません。

TL;DR

• Foundation Models は、Apple Intelligence 対応のすべてのデバイスに SystemLanguageModel.default で 30 億パラメータの LLM を提供します。モデルはローカルで動作し、推論は Apple silicon 向けに最適化され、オンデバイスで実行されます。ネットワークは呼び出しパスの外にあります。
• Tool プロトコルは、モデルとアプリの間の契約です。ツールは型付きの Arguments を宣言し、型付きの Output を返し、構築時に LanguageModelSession にバインドされます。
• Generable と Guide のアノテーションにより、モデルは文字列ではなく、型付きの Swift 値を直接生成できます。デコーダーはフレームワークの一部であり、開発者のコードではありません。
• Foundation Models、App Intents、MCP の間のルーティング規則は、誰がモデルを実行し、どこで実行するか です。Foundation Models = アプリがオンデバイスでモデルを実行。App Intents = Apple Intelligence がオンデバイスでモデルを実行し、アプリにルーティング。MCP = 外部のホストが任意の場所でモデルを実行し、ツールサーバーを介してアプリに到達。

フレームワークが実際に提供するもの

このフレームワークを支えるのは 3 つのプリミティブです。モデル、セッション、そしてツールです。²

SystemLanguageModel。 オンデバイスの基盤モデルへの参照です。デフォルトインスタンスはユーザーのデバイスにバインドされ、Apple Intelligence 対応ハードウェアで利用可能で、モデルが利用可能かどうかを判断するためにアプリが実行時に読み取る能力チェックを公開します。フレームワークは SystemLanguageModel(useCase:guardrails:)、カスタムアダプター、GenerationOptions による設定をサポートしますが、OpenAI や Anthropic に対するように任意のクラウドモデル ID を選ぶことはできません。Apple は OS リリースごとにオンデバイスモデルを出荷・更新し、フレームワークは現在インストールされているバージョンを渡します。

LanguageModelSession。 呼び出し間で会話状態を保持するステートフルなオブジェクトです。セッションは構築時にシステムプロンプトを受け取り、時間の経過とともにユーザー/アシスタントのターンを蓄積し、応答生成のための async メソッドを公開します。セッションは作成が軽量で、使い捨て可能です。アプリごとに 1 つではなく、タスクごとに 1 つ作成します。瞑想タイマーは「過去 7 日間の練習を要約して」というセッションを作成し、レシピアプリは「これを 4 人分ではなく 2 人分に変換して」という別のセッションを作成します。

Tool（プロトコル）。 Arguments 型、Output 型、async な call(arguments:) 関数を宣言する Swift プロトコルです。ツールは構築時にセッションにバインドされます（LanguageModelSession(tools: [...], instructions: ...)）。モデルがツールを必要と判断すると、構造化された呼び出しを発行します。フレームワークは引数をデコードし、ツールを実行し、結果をエンコードして、次のターンのためにセッションに戻します。モデルは Swift を見ません。マーシャリングはフレームワークが行います。

Tool プロトコルの形を凝縮すると、以下のようになります。

import FoundationModels

struct WaterEntryLookup: Tool {
    let name = "lookup_water_entries"
    let description = "Look up water intake entries for a given date range."

    @Generable
    struct Arguments {
        @Guide(description: "Start date in ISO-8601 format")
        let startDate: String

        @Guide(description: "End date in ISO-8601 format")
        let endDate: String
    }

    func call(arguments: Arguments) async throws -> ToolOutput {
        let entries = try store.entries(
            from: ISO8601DateFormatter().date(from: arguments.startDate) ?? .now,
            to: ISO8601DateFormatter().date(from: arguments.endDate) ?? .now
        )
        return ToolOutput(GeneratedContent(properties: [
            "count": entries.count,
            "total_ml": entries.reduce(0) { $0 + $1.amountMl }
        ]))
    }
}

モデルが見るのはツールの説明と JSON 形式の引数スキーマです。Swift コードが見るのは型付きの入力と型付きの出力です。デコード/エンコードの境界が、Apple が所有する部分となります。

Generable と Guide：パーサー不要の型付き出力

ツール引数を型付きにするのと同じアノテーションシステムにより、モデルは型付きの Swift 値を直接生成することもできます。³ @Generable 構造体はその形を宣言し、フレームワークはモデルの出力をそれに合うように制約します。

@Generable
struct PracticeSummary {
    @Guide(description: "Single-sentence headline summarizing the user's week")
    let headline: String

    @Guide(description: "Total practice duration this week in minutes")
    let totalMinutes: Int

    @Guide(description: "Three short observations as bullet points")
    let observations: [String]
}

let session = LanguageModelSession(instructions: "You are a meditation coach.")
let summary = try await session.respond(
    to: "Summarize this week of practice given the entries.",
    generating: PracticeSummary.self
)

モデルは PracticeSummary 値を返します。コード内に JSON パースは不要、「headline:」の文字列マッチングも不要、モデルが不正な形式のオブジェクトを返した場合のフォールバックも不要です。フレームワークは制約付きデコードを使用して、モデルのトークンごとの出力をスキーマに構造的に整合させ続けるため、構造的に無効な出力が境界をすり抜けることはありません。

Swift で型付けされた表面こそが、このフレームワークをクラウド LLM SDK から際立たせる点です。クラウド SDK（OpenAI Structured Outputs、Anthropic tool use など）も制約付きデコードをサポートしますが、開発者が受け取る型付き値はスキーマに対して検証された JSON オブジェクトであり、別ステップとして Codable Swift 型にデコードされます。Foundation Models はそれらのステップを統合します。@Generable マクロとフレームワークのデコーダーが、直接の戻り値として型付きの Swift 値を生成し、フィールドごとの @Guide アノテーションが意図を生成制約に持ち込みます。出力が型付きであるのは、開発者が Swift で再構築した JSON 仕様ではなく、Swift スキーマに対して生成自体が型付きで行われたからです。

@Guide アノテーションは、プロンプトに書き込むことなく、フィールドごとの意図をモデルに伝える方法です。生成された説明は生成制約の一部となります。フィールドレベルのガイドにより、プロンプトはクリーンに保たれ、スキーマはデータに近づきます。

ルーティングの問い、3 つの方法

Apple は今や、アプリが自身のドメインを言語モデルに公開するための 3 つのプロトコル表面を提供しています。それぞれ異なるランナーにルーティングされます。

Foundation Models（LanguageModelSession）。 アプリがオンデバイスモデルをロードし、推論を実行します。セッションが呼び出せるツールは、アプリのコードが定義したツールです。モデルがデバイスを離れることはありません。ユーザーが Siri 経由でこれを呼び出すことはなく、アプリのコードが呼び出します。ユースケースはアプリ 内部 にあります。週の練習を要約するために LLM を使う瞑想アプリ、より少ない人数分にレシピを調整するレシピアプリ、「ランチで 1 杯飲んだ」を構造化されたエントリに変換する水分摂取トラッカーなどです。

App Intents。 Apple Intelligence がユーザーに代わって LLM（Apple のファーストパーティエージェント）を実行し、能力呼び出しをアプリの AppIntent 型にルーティングします。アプリはモデルを実行しません。App Intents フレームワークを通じて型付きアクションを宣言し、Apple のシステムスタックが、ユーザーリクエスト、Spotlight クエリ、Siri 入力、または Shortcuts オーケストレーションに基づいていつそれらを呼び出すかを決定します。詳細は App Intents は Apple がアプリに用意した新しい API で扱っています。⁴

MCP。 外部のホスト（Claude Desktop、Claude Code、Cursor、ChatGPT）が、開発者が選んだモデルを実行します。アプリは、ホストのモデルが呼び出せるサーバーを公開します。モデルはホストが実行する場所で動作し、ツール呼び出しは JSON-RPC トランスポートを越えます。詳細は 2 つのエージェントエコシステム、1 つの買い物リスト と、ルーティングの問いの統合を扱う App Intents vs MCP で扱っています。⁵

ルーティングの判断は、突き詰めると 誰がエージェントなのか に集約されます。

                  ┌──────────────────────────────────┐
                  │  Who is the language model?       │
                  └────┬─────────────┬─────────────┬──┘
                       │             │             │
              ┌────────┴────┐ ┌──────┴──────┐ ┌────┴──────┐
              │ Your app's  │ │   Apple     │ │  External │
              │ own use of  │ │ Intelligence│ │   host's  │
              │   LLM       │ │   agent     │ │   agent   │
              └──────┬──────┘ └──────┬──────┘ └────┬──────┘
                     │               │             │
                     ▼               ▼             ▼
              Foundation Models  App Intents     MCP
              + Tool protocol   + AppEntity    + tools/list
              (on-device, your  (system runs   (host runs
               app runs model)   the model)     the model)

ユーザーの週を要約する瞑想アプリは Foundation Models を使います。アプリ自身がモデルを呼び出し、結果をアプリ内に提示したいからです。同じアプリの「5 分のセッションを記録する」機能は、Siri から呼び出せるように App Intents を使います。Claude Code セッションが使う「最後の瞑想ログエントリを見せて」機能は MCP を使います。3 つの異なるランナー、3 つの異なる責務、その下にある 1 つの共通ドメインレイヤー。

推論バジェット：フレームワークが要求するもの

LLM をオンデバイスで実行するのは無料ではありません。Apple silicon が推論を処理しますが、モデルにはコンテキストウィンドウ、トークンバジェット、デバイスに依存するウォールクロックレイテンシがあります。フレームワークでの設計を形作るのは、3 つの制約です。⁶

可用性はデバイス単位です。 すべての iOS 26 デバイスが Apple Intelligence を持つわけではありません。古い iPhone、ロックダウンされたデバイス、ユーザーが Apple Intelligence を無効にしたデバイスは、SystemLanguageModel.default.availability から非利用可能の状態を返します。可用性をチェックせずに LanguageModelSession を呼び出すコードは、実行時に生成エラーを引き起こします。正しいパターンは、事前に可用性の状態に基づいて UI を分岐させ、状態が利用不可の場合は LLM なしのパスを提示することです。モデルは保証ではなく、フィーチャーフラグとして扱いましょう。

レイテンシは無視できません。 iPhone 16 Pro での最初のトークンレイテンシはアプリ内インタラクションには使えますが、より長い生成やツール呼び出しの連鎖は瞬時ではありません。クラウド LLM のストリーミングで機能する UI パターンはここでも機能します。メインスレッドをブロックせず、プログレッシブな出力を表示し、ユーザーが生成中に画面遷移するケースを設計に含めてください。

コンテキストウィンドウはクラウドより小さいです。 オンデバイスモデルは、GPT-4 クラスのクラウドモデルよりも小さなコンテキストウィンドウを持ちます。長いドキュメントには要約またはチャンク化が必要です。長い会話履歴にはトリミングが必要です。大きな構造化ペイロードを返すツール出力は、ペイロード全体をインラインで返すのではなく、次のターンが必要に応じて再取得できる参照（ID やキー）を返すべきです。

制約のセットは、フロンティアのクラウドモデル向けではなく、ローエンドのエッジランタイム向けの設計に近いものです。フレームワークのアフォーダンスはより快適にしてくれますが、根本的な物理的制限は動きません。

Foundation Models を選ぶべきとき

このフレームワークが最も力を発揮するのは、オンデバイスで摩擦の少ない生成自体がプロダクトとなる場面です。

書式変更とリライト。 ユーザーの自由形式のメモを構造化されたエントリに変換する、下書きメッセージを磨き上げる、キャプチャされたトランスクリプトを要約するなど。レイテンシの許容度は中程度、データの機密性は高く、クラウド推論ではオーバースペックです。

プライベートデータに対するローカルな統合。 ユーザーのワークアウト履歴を「今週」のサマリーに変換するワークアウトアプリ。ユーザーの支出パターンを説明するファイナンスアプリ。四半期分のエントリ全体からテーマを浮かび上がらせるジャーナルアプリ。データはデバイスから出てはいけない、回答はアプリ内に表示されるべき、プロンプトは有限である、という条件です。

アプリ内自動化のための軽量なツール呼び出し。 ユーザーが「火曜日の瞑想ログを見せて」と言えば、ツールが基盤レコードを取得し、回答を整形するアプリ。エージェントはアプリ自身、ツールはアプリ自身のデータレイヤー、モデルはローカルです。

型に準拠した生成。 アプリが手書きの JSON パーサーや文字列テンプレートを書くことになる場面ならどこでも、@Generable と @Guide の組み合わせのほうが、より持続可能な表面となります。

Foundation Models を選ぶべきでないとき

このフレームワークが間違った答えとなる、いくつかの典型的なケースがあります。

ユーザーが Siri に尋ねる可能性のあること。 「水を 250ml 記録して」、「5 分の瞑想を始めて」、「リストにバナナを追加して」 は App Intents です。ランナーは Apple Intelligence、行き先はアプリです。Foundation Models はアプリ内生成のためのものであり、Siri 経由のアクションのためのものではありません。同じ機能を二重に実装した場合（App Intent + ツール付きの LanguageModelSession）、ユーザーは Siri を呼び出してアプリ内画面を呼び出すわけではないので、App Intent が勝ちます。

外部の LLM エージェントが駆動すべきもの。 Claude Code セッションがアプリのドメインに到達する場合、MCP 経由が適切です。アプリは LLM を実行せず、ホストが実行し、モデルはホストが配置した場所に存在します。Foundation Models は外部エージェントには応えられません。

大きなドキュメントに対する重い推論。 オンデバイスモデルは小さいです。200 ページの契約書、長いコードベースのコンテキスト、多数の写真にまたがるマルチイメージ推論は、コンテキストウィンドウとパラメータ数がワークロードに見合うクラウド推論（自社またはベンダーの）に属します。フレームワークの範囲を超えるタスクは、コンテキストウィンドウ超過、ガードレール違反、サポートされないロケールといった具体的なエラーを生じさせます。モデルが範囲外の処理を扱うことに依存するフローを設計するのではなく、それらのエラーを意図的に表面化させましょう。

クロスデバイス・クロスユーザーのワークフロー。 オンデバイスモデルは、アプリがセッションに渡したものにしかアクセスできません。クロスデバイス同期（Watch から iPhone へのタイマー状態）、クロスユーザー協業（共有リスト、共有ドキュメント）、サーバー側調整から恩恵を受けるあらゆるフローには、サーバーが必要です。モデルはネットワークプリミティブではありません。

自分のスタックなら何を変えて作るか

このフレームワークは、最初のパスで誤りやすい特定のアーキテクチャ選択に報いてくれます。ユーザーが アプリ UI を通じて呼び出す機能と、LLM が ツール として消費する機能は、重複した自由文パスとしてではなく、ツールとして実装すべきです。

瞑想アプリが LLM で要約された「週次レビュー」ペインを追加するとします。素朴な実装は単一のプロンプトです。「ユーザーの今週のエントリはこれです、段落を書いてください」。より良い実装は、モデルが週に何があったかを知る必要があるときに呼び出せる WeeklyEntries ツールを定義し、@Generable を介した構造化された WeeklySummary 出力を加えます。最初の実装は脆弱で（モデルは呼び出しごとに長いエントリリストを取り込む必要がある）、トークンが高価で、構造化されていない散文を生成します。2 番目は持続可能で（ツール呼び出しが「何が起こったか」と「それについてどう語るか」を分離する）、安価で（モデルは必要なものだけを取得する）、構造化されています（結果は型付きの Swift 値）。

このパターンは App Intents と MCP にもクリーンに合成できます。同じ WeeklyEntries クエリは、AppIntent パラメータリゾルバの本体でもあり、MCP ツールハンドラの本体でもあります。1 つの Swift 関数、3 つの表面。モデルはユーザーが呼び出すのと同じ関数を呼び出します。

もう 1 つのアーキテクチャ判断。ツールの説明はプロンプトの一部です。モデルは Tool.description を読み、いつ呼び出すかを判断します。説明文は、将来のコントリビューターが実際に読むことを期待する docstring のように扱いましょう。モデルがその将来のコントリビューターです。

このパターンが iOS 26+ の Apple スタックに意味するもの

3 つのテイクアウェイがあります。

1. オンデバイス LLM はバックエンドではなくランタイム機能です。 リモートサービスではなく、コンテキストウィンドウとオンデバイス推論バジェットを持つシステムフレームワークとして扱いましょう。アーキテクチャの判断対象は、可用性、レイテンシ、コンテキストウィンドウの規律、構造化出力です。

2. Tool プロトコルが表面です。 ツールがなければ、モデルはドメインに接続されていないチャット補完エンドポイントです。ツールがあれば、モデルはアプリのデータに対する構造化されたクエリ層となります。

3. Foundation Models、App Intents、MCP の間のルーティング規則は「誰がモデルを実行するか」です。 アプリ内生成は Foundation Models へ。Apple Intelligence ルーティングの機能は App Intents へ。外部エージェント機能は MCP へ。同じ Swift ドメイン関数を、3 つの表面すべてから呼び出せます。

Apple Ecosystem クラスタの全体像。Apple Intelligence のための型付き App Intents、クロス LLM エージェントのための MCP サーバー、両者間の ルーティングの問い、ロック画面のステートマシンのための Live Activities、ビジュアル層のための Liquid Glass パターン、クロスデバイスリーチのための マルチプラットフォーム出荷。ハブは Apple Ecosystem Series にあります。AI エージェントを伴う iOS のより広い文脈については、iOS Agent Development guide を参照してください。

FAQ

iOS 26 の Foundation Models フレームワークとは何ですか？

Foundation Models は、iOS 26（および iPadOS 26、macOS 26、visionOS 26）の Apple Intelligence 対応デバイスに搭載されるオンデバイス言語モデルにアクセスするための、Apple のフレームワークです。フレームワークは SystemLanguageModel、LanguageModelSession、Tool プロトコルを公開し、アプリがネットワークアクセスなしに型付きのオンデバイス LLM 呼び出しを実行できるようにします。

Tool プロトコルはどのように機能しますか？

Tool は、Arguments 構造体（@Generable と @Guide でアノテートされる）、async な call(arguments:) メソッド、モデルがいつ呼び出すかを判断するために使う名前と説明を宣言する Swift 型です。ツールは構築時に LanguageModelSession にバインドされます。モデルがツールを必要と判断すると、フレームワークは引数をデコードし、呼び出しを実行し、型付きの出力をセッションに戻します。

Foundation Models、App Intents、MCP の違いは何ですか？

Foundation Models は、アプリがオンデバイスで LLM を実行してアプリ内生成を行うためのものです。App Intents は、Apple Intelligence（システムエージェント）がアプリの型付き機能を呼び出すためのものです。MCP は、外部の LLM ホスト（Claude、ChatGPT など）が JSON-RPC トランスポートを越えてアプリの型付きツールを呼び出すためのものです。3 つのプロトコルは 誰がモデルを実行するか で異なります。同じ Swift ドメイン関数が 3 つすべてに対応できます。

Foundation Models は MCP ツールを呼び出せますか？

いいえ。LanguageModelSession.tools は Apple の Tool プロトコルへの準拠者を受け入れるのであり、MCP ツールサーバーを受け入れるわけではありません。両者をブリッジするには、call メソッドが MCP クライアントを呼び出す Foundation Models の Tool を書くことになります。Apple は組み込みのアダプターを出荷していないため、ブリッジはアプリ側のコードとなります。

オンデバイスモデルは本番運用に十分な性能ですか？

このフレームワークが想定するユースケース（書式変更、要約、ローカルデータに対する構造化生成、軽量なツール呼び出し）に対しては、十分です。大きなコンテキストにわたるフロンティアの推論、規模を伴うマルチモーダル理解、クロスドキュメント推論には、不十分です。オンデバイスモデルはクラウド LLM より小さなコンテキストウィンドウを持つ 30 億パラメータのモデルです。範囲に合うワークロードを選びましょう。

参考文献