Foundation Models オンデバイス LLM：Tool プロトコル

Apple が WWDC 2025 で発表したオンデバイス LLM の契約は、即座にルーティングの問題を提起します。すなわち、いつ LanguageModelSession が正解で、いつ AppIntent を使うべきか、いつ MCP なのか、そしていつそのいずれでもないのか、という問いです。

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

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

TL;DR

• Foundation Models は、Apple Intelligence 対応のすべてのデバイスに、SystemLanguageModel.default で利用可能な 3B パラメータの 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。 呼び出し間で会話状態を保持するステートフルなオブジェクトです。セッションは構築時にシステムプロンプトを受け取り、時間とともにユーザー／アシスタントのターンを蓄積し、レスポンスを生成するための非同期メソッドを公開します。セッションは生成コストが軽く使い捨てが可能なので、アプリごとに 1 つではなく、タスクごとに 1 つ作成します。瞑想タイマーアプリは「直近 7 日間の練習を要約して」のためにセッションを作成し、レシピアプリは「これを 4 人前から 2 人前に変換して」のために別のセッションを作成する、といった具合です。

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

このプロトコルが要求する完全な要件は次のとおりです。name: String、description: String、ConvertibleFromGeneratedContent に準拠する関連型 Arguments、PromptRepresentable に準拠する関連型 Output、そして非同期の call(arguments:) メソッド。Arguments 構造体に @Generable マクロを付けると ConvertibleFromGeneratedContent への準拠が無料で生成されます。Output については String と GeneratedContent がすでに準拠しています。Apple のドキュメント例では String または [String] を返しています。

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 -> String {
        let entries = try store.entries(
            from: ISO8601DateFormatter().date(from: arguments.startDate) ?? .now,
            to: ISO8601DateFormatter().date(from: arguments.endDate) ?? .now
        )
        let totalMl = entries.reduce(0) { $0 + $1.amountMl }
        return "Found \(entries.count) entries totalling \(totalMl)ml."
    }
}

モデルが見るのは、ツールの説明と生成スキーマの引数の形です。Swift コードが見るのは、型付きの入力と型付きの出力です。デコード／エンコードの境界は Apple が所有する部分です。ツールの出力は String または GeneratedContent オブジェクトのいずれかにできます。上記の例では、次のターンの推論を消費する側がモデルなので、String を返しています。

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
)

この呼び出しは Response<PracticeSummary> を返し、その content は型付きの PracticeSummary です。コードに JSON パースは不要、「headline:」を文字列マッチで探す処理も不要、不正な形式のオブジェクトが返ってきたときのフォールバックも不要です。フレームワークは制約付きサンプリングを使ってモデルのトークンごとの出力をスキーマと構造的に整合させ続けるため、構造的に不正な出力が境界をすり抜けることはありません。上記のセッションがツールを取らないのは、型付き出力とツール呼び出しが独立した機能だからです。セッションはレスポンスの形に @Generable を使うことも、グラウンディングにツールを使うことも、両方使うことも、どちらも使わないこともできます。

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 週間を要約する瞑想アプリ、サービング数を減らすためにレシピを変換するレシピアプリ、「お昼にコップ 1 杯飲んだよ」を構造化されたエントリに変える水分摂取トラッカーなどがそれにあたります。

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

MCP。 外部ホスト（Claude Desktop、Claude Code、Cursor、ChatGPT）が、開発者が選んだ任意のモデルを実行します。アプリは、ホストのモデルが呼び出せるサーバを公開します。モデルはホストが実行する場所であればどこでも動作し、ツール呼び出しは JSON-RPC トランスポートを介して行われます。詳しくは Two Agent Ecosystems, One Shopping List と、ルーティング問題を統合して論じた 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)

ユーザーの 1 週間を要約する瞑想アプリは、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 を使わないパスを提示することです。モデルは保証ではなく、フィーチャーフラグとして扱いましょう。

レイテンシは無視できません。 Return での検証では、iPhone 16 Pro ハードウェアでの初トークンレイテンシはアプリ内インタラクションに耐えうるものでした。長めの生成やツール呼び出しチェーンは即座には終わりません。クラウド LLM ストリーミングで機能する UI パターンはここでも有効です。メインスレッドをブロックしないこと、進行中の出力を表示すること、生成中にユーザーが画面を離れた場合に対応した設計をすること、です。

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

制約セットは、フロンティアのクラウドモデル向け設計というより、ローエンドのエッジランタイム向け設計に近いものとなります。フレームワークのアフォーダンスがそれを心地よくしますが、根底にある物理的限界は動きません。

いつ Foundation Models に手を伸ばすべきか

このフレームワークが最も力を発揮するのは、オンデバイスかつ低摩擦な生成がプロダクトそのものになる場面です。

書き換えと整形。 ユーザーの自由形式メモを構造化エントリに変える、ドラフトメッセージを磨く、キャプチャしたトランスクリプトを要約する、といったケースです。レイテンシ許容度は中程度、データ機密性は高く、クラウド推論はオーバーキルです。

プライベートデータ上のローカル合成。 ユーザーのワークアウト履歴を「今週の」サマリに変えるワークアウトアプリ。ユーザーの支出パターンを説明する金融アプリ。1 四半期分のエントリを横断してテーマを浮かび上がらせるジャーナルアプリ。データはデバイスを離れるべきではなく、答えはアプリ内に表示されるべきで、プロンプトは有界です。

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

型適合の生成。 アプリが本来であれば手書きで 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 で要約された「週次レビュー」のペインを追加するとしましょう。素朴な作りは、1 つのプロンプトで「ここに今週のユーザーのエントリがあります、段落で書いてください」というものです。よりよい作りは、モデルが週の内容を知る必要があるときに呼び出せる WeeklyEntries ツールと、@Generable を介した構造化された WeeklySummary 出力を定義します。最初の作りは脆く（モデルが呼び出しごとに長いエントリリストを取り込む必要がある）、トークン的に高価で、構造化されていない散文を生みます。2 番目は耐久性があり（ツール呼び出しが「何が起きたか」と「それをどう語るか」を分離する）、安く（モデルは必要なものだけを取得する）、構造化されています（結果は型付きの Swift 値）。

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

もうひとつのアーキテクチャ判断は次のとおりです。ツールの説明はプロンプトの一部です。モデルはいつ呼び出すかを判断するために 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 つのサーフェスすべてから呼び出せます。

Foundation Models フレームワークの内側をさらに深く掘り下げる兄弟記事が 3 本あります。Foundation Models のユースケース（ワークロード適合の判断について）、カスタムアダプタ（アプリデータでのオンデバイスモデルのファインチューニングについて）、そしてエージェント型ワークフロー（アプリ内 LLM とツール用 LLM の分割について）です。

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 は、@Generable と @Guide でアノテーションされた Arguments 構造体、非同期の 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 は、MCP ツールサーバではなく、Apple の Tool プロトコルへの準拠者を受け付けます。両者をブリッジするには、call メソッドが MCP クライアントを呼び出す Foundation Models の Tool を書くことになります。Apple は組み込みアダプタを出荷していないので、ブリッジはアプリ側のコードになります。

オンデバイスモデルはプロダクションに使える品質ですか？

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

References