Apple Foundation Models：オンデバイスLLMフレームワーク徹底解説

Foundation Modelsフレームワークを使うと、Apple Intelligenceを支えているのと同じオンデバイス大規模言語モデルに、アプリから直接、無料かつオフラインでアクセスできます¹。APIキーも、トークン単位の請求も、ネットワーク往復も、端末外へのデータ送信も一切ありません。かつてはクラウドLLMとプライバシー審査を意味していた種類の機能が、いまやコストほぼゼロで実現できるのです。引き換えになるのは能力です。オンデバイスモデルは小さく、コンテキストウィンドウは有限で、フレームワーク自身が「やること」と「やらないこと」の間に明確な線を引いています。その線を知ることが、すべてと言っていいでしょう。

本稿はフレームワークそのものの参照資料です。実際に呼び出す型、このフレームワークを使う価値を生んでいる唯一の機能、そして手を止めてもっと大きなものに手を伸ばすべき地点を扱います。

要点

• LanguageModelSessionが入り口です。生成してrespond(to:)を呼べば、テキストが返ってきます。複数ターンの文脈はセッションが保持するため、単発の処理では毎回新しいセッションを作ります²。
• ガイド付き生成こそ、このフレームワークを使う理由です。 Swiftの型に@Generableを付ければ、パース対象の文字列ではなく、値が埋まって型検査済みのその型そのものが返ってきます³。
• Toolプロトコルにより、モデルは生成の途中で自分のコードを呼び出してデータを取得したり処理を実行したりし、その結果を回答に織り込めます⁴。
• 何をするにも、まずSystemLanguageModel.default.availabilityを確認してください。非対応端末、Apple Intelligenceがオフの状態、モデルのダウンロード中には、モデルは存在しません⁵。
• コンテキストウィンドウは実在し、しかも小さいものです。SystemLanguageModel.default.contextSizeが、プロンプトと応答で共有されるトークン予算を返します⁶。オンデバイスでの予算は4Kトークン、Private Cloud Computeのモデルなら32Kまで広がります¹⁴。想定して設計しないと、セッションが例外を投げます。
• iOS 26とApple Intelligence対応端末が必要です。それを下回る環境では、フレームワークそのものが存在しません。iOS 27のベータでは、同じAPIに画像入力、リクエスト単位のツール呼び出し制御、Private Cloud Compute上のサーバーモデルが加わります¹²¹³¹⁴。

このフレームワークの正体と、そうでないもの

Foundation Modelsはクラウドエンドポイントのラッパーではありません。モデルは端末上に存在し、OSと一緒に配布され、Neural Engine上で動作します。この一点が、APIの設計判断すべてと、それを使うあなたの判断すべてを規定します。

得られるもの：テキスト生成、要約、分類、抽出、短文のリライト、構造化出力。いずれもオンデバイスで、いずれも無料です。得られないもの：フロンティアモデル。Appleがオンデバイスモデルを作ったのは、アプリ内で完結する焦点の定まった言語処理のためであって、自由度の高い推論でも、長文書の分析でも、クイズに答えられるような世界知識でもありません。Apple自身がそう明言していますし、この位置づけは重要です。APIそのものは放っておけば逸脱を許してしまうので、期待値を定めているのはこの言葉のほうだからです¹。

トラブルを避けるための思考モデルはこうです。オンデバイスモデルは、速くてプライベートで無料のインターンだと考えてください。文章を整えるのは抜群にうまいけれど、事実を知っているかというとまるでダメです。素材と明確な指示を渡しましょう。答えようのない質問はしないことです。

LanguageModelSession：入り口

すべてのやり取りはセッションから始まります。

import FoundationModels

let session = LanguageModelSession()
let response = try await session.respond(to: "Summarize this review in one sentence: \(reviewText)")
print(response.content)

セッションは会話の状態を保持します。respond(to:)を呼ぶたびに進行中のトランスクリプトへ追記されるので、使い回しているセッションは以前のやり取りを覚えています。チャット機能ならそれが望みどおりの挙動でしょう。一方、独立した単発処理（これを要約する、あれを分類する）では、呼び出しごとに新しいセッションを作ります。古い文脈が紛れ込んでトークン予算を食い潰さないようにするためです²。

respond(to:)はasync throwsです。モデルの処理中は中断し、リクエストがコンテキストウィンドウを超えたとき、モデルが利用できないとき、ガードレールが内容を拒否したときには例外を投げます。そのいずれもが、無視してよい例外ケースではなく、あなたが実際に処理すべき分岐です。

UIの応答性を保つなら、待たずにストリーミングしましょう。streamResponse(to:)はモデルが生成した端から部分出力を渡してくれるので、3秒の沈黙が「形になりながら現れるテキスト」に変わります⁷。

ガイド付き生成：フレームワークの価値を決める機能

ここが入場料に見合う部分です。たいていのLLM統合は、コードの3分の1をモデルから妥当なJSONを引き出すことに費やし、残る3分の2をそれでも失敗する場面への防御に費やします。Foundation Modelsは、その仕事ごと消し去ります。

Swiftの型に@Generableを付け、セッションにその型の生成を頼めば、値が埋まった型安全なインスタンスが返ってきます³。

@Generable
struct Recipe {
    @Guide(description: "The dish name")
    let title: String

    @Guide(description: "Ingredients, each as 'quantity item'")
    let ingredients: [String]

    @Guide(description: "Total minutes, start to finish", .range(5...240))
    let minutes: Int
}

let session = LanguageModelSession()
let response = try await session.respond(
    to: "A weeknight pasta for two.",
    generating: Recipe.self
)
let recipe = response.content   // a Recipe, not a String

パース処理なし。JSONDecoderなし。壊れた出力に備えたリトライループもなし。@Guideマクロは個々のフィールドに制約をかけます。モデルが指示として読む説明文と、数値範囲や出力が一致すべき正規表現といった任意の制限です⁸。フレームワークは「5から240の間の数字をください」とモデルにお願いしているのではありません。デコードそのものを制約し、それ以外の値では返せないようにしているのです。

そして本当の価値は、これが強いる規律のほうにあります。まず出力の型をSwiftで設計し、コンパイラに検査させます。モデルは、あなたが逆解析する散文を返すのではなく、あなたが定義した契約を満たします。抽出、フォーム入力、そして言語をデータに変えるあらゆる機能において、ガイド付き生成はデモと出荷可能なコードを分ける境目です。

知っておく価値のある制御がひとつ。respond(to:generating:)はincludeSchemaInPromptが既定でtrueになっており、型の構造をプロンプトへ注入してモデルをその形に寄せます。学習時点やセッションの以前のターンからモデルがすでに形式を知っている場合を除き、有効のままにしておきましょう。モデルが見たことのない形式なのに、トークン節約のためこれを切るのは、ゴミが返ってくる典型的なパターンです⁹。

ツール呼び出し：モデルの手を自分のコードに届かせる

ガイド付き生成は、出てくるものを形づくります。ツール呼び出しは、入っていくものを変えます。ツールとは、モデルが生成の途中で呼び出せるあなたのコードのことで、持っていない情報を取ってきたり処理を実行したりし、その結果を使って回答を続けます⁴。

ツールはToolプロトコルに準拠します。name、モデルがいつ呼ぶべきか判断するために読むdescription、@GenerableなArguments型、そして実処理を行うcall(arguments:)メソッドです⁴。

struct FindContacts: Tool {
    let name = "findContacts"
    let description = "Find a specific number of contacts from the address book"

    @Generable
    struct Arguments {
        @Guide(description: "How many contacts to return", .range(1...10))
        let count: Int
    }

    func call(arguments: Arguments) async throws -> [String] {
        // Fetch contacts, return formatted names.
    }
}

let session = LanguageModelSession(tools: [FindContacts()])
let response = try await session.respond(to: "Draft a dinner invite to three of my contacts.")

流れはこうです。モデルは連絡先が必要だと判断し、検証済みのcountを添えてツールを呼びます。あなたがデータを返すと、モデルは実在の名前を使って招待文を書きます。引数は同じガイド付き生成の仕組みを通って型検査済みで届くので、自由記述からモデルの意図を読み解く必要はありません。モデルがそのツールに手を伸ばすタイミングを左右できる唯一のレバーが説明文なので、他の文脈を一切持たない別のエンジニアが読んで正しく使えるような関数ドキュメントのつもりで書いてください。

ここはまた、Foundation Modelsがエージェントの物語の残りと接する継ぎ目でもあります。オンデバイスモデルが呼ぶツールと、Apple Intelligenceが呼ぶApp Intent¹¹は、面こそ違えど形は同じです。名前があり、説明があり、型のついた能力。能力を一度設計すれば、両方から公開できます。

利用可否の判定：省略できない確認

モデルは常にそこにあるとは限りません。Apple Intelligence非対応の端末では存在せず、ユーザーがオフにしていれば存在せず、OSがモデルアセットをダウンロードしている間も存在しません。モデルがある前提のコードを出荷すれば、あなたが一度もテストしていない層のユーザーに対して、クラッシュするか、黙って劣化するか、固まるかのいずれかが起こります。

SystemLanguageModel.default.availabilityを確認し、理由ごとに分岐しましょう⁵。

switch SystemLanguageModel.default.availability {
case .available:
    // Show the intelligence feature.
case .unavailable(.deviceNotEligible):
    // Hide it. This device will never have the model.
case .unavailable(.appleIntelligenceNotEnabled):
    // Prompt the user to turn on Apple Intelligence.
case .unavailable(.modelNotReady):
    // Downloading or otherwise not ready yet. Try again later.
case .unavailable(let other):
    // Unknown reason. Fail closed.
}

3つの理由は3つの異なるプロダクト上の応答を要求します。これらを一緒くたにすることが、こうした機能が「壊れている」と感じられる最大の原因です。deviceNotEligibleは恒久的なので、機能は隠します。しつこく促してはいけません。appleIntelligenceNotEnabledはユーザーが握っている設定なので、一度きりの案内なら妥当でしょう。modelNotReadyは一時的なので、再試行します。エラーは見せません。利用不可の経路も、正常系と同じ丁寧さで作り込んでください。相当数の端末にとっては、それが唯一の経路なのですから。

モデルが利用可能で、リクエストが来ると分かっているなら、セッションのprewarm()がモデルを温めておき、最初の応答が速く返るようになります¹⁰。ユーザーがまさに操作しようとしている画面では価値がありますが、当てずっぽうで呼ぶなら無駄です。

実践：1ファイルで完結する機能

ここまでの部品を組み合わせると、多くのネットワーク層がエンドポイント1本に費やすより少ないコードで、実用的な機能ができあがります。以下は、自由形式の会議メモを構造化されたアクションアイテムに変える、コンパイル可能な完全なSwiftUI画面です。利用可否の確認、@Generableな出力型、ガイド付き生成の呼び出し1回、そして利用不可の3分岐の処理まで含まれています。登場するシンボルはすべて、上で解説したフレームワークのAPIに由来します²³⁵⁸。

import SwiftUI
import FoundationModels

@Generable
struct ActionItems {
    @Guide(description: "One-sentence summary of the meeting")
    let summary: String

    @Guide(description: "Concrete follow-up tasks, each starting with a verb")
    let tasks: [String]

    @Guide(description: "How urgent the follow-ups are overall", .anyOf(["low", "medium", "high"]))
    let urgency: String
}

struct MeetingNotesView: View {
    @State private var notes = ""
    @State private var result: ActionItems?
    @State private var errorMessage: String?

    var body: some View {
        Form {
            TextField("Paste meeting notes", text: $notes, axis: .vertical)
                .lineLimit(6...12)

            Button("Extract action items") {
                Task { await extract() }
            }
            .disabled(notes.isEmpty)

            if let result {
                Section(result.summary) {
                    ForEach(result.tasks, id: \.self) { Text($0) }
                    Text("Urgency: \(result.urgency)")
                }
            }

            if let errorMessage {
                Text(errorMessage).foregroundStyle(.secondary)
            }
        }
    }

    private func extract() async {
        switch SystemLanguageModel.default.availability {
        case .available:
            do {
                let session = LanguageModelSession()
                let response = try await session.respond(
                    to: "Extract the action items from these notes: \(notes)",
                    generating: ActionItems.self
                )
                result = response.content
            } catch {
                errorMessage = "The model could not process these notes."
            }
        case .unavailable(.appleIntelligenceNotEnabled):
            errorMessage = "Turn on Apple Intelligence in Settings to use this feature."
        case .unavailable(.modelNotReady):
            errorMessage = "The model is still downloading. Try again shortly."
        case .unavailable:
            errorMessage = "This feature needs an Apple Intelligence-capable device."
        }
    }
}

これだけ小さなサンプルでも、注目すべき点が3つあります。第一に、出力型こそがAPIだということ。ActionItemsはこの機能が生み出すものを正確に定義しており、urgencyに付いた@Guide制約のおかげで、この文字列が許可された3つの値以外で返ってくることはありません⁸。第二に、抽出はそれぞれ独立しているのでセッションを呼び出しごとに作っていること。保持し続けたセッションは、以前のメモをトークン予算に引きずり込んでしまいます²。第三に、利用不可の分岐が汎用エラー1種ではなく3種類の異なる体験を生んでいること。これが、誠実に劣化する機能と、壊れて見える機能の差です。このファイルをiOS 26のプロジェクトに貼り付け、Apple Intelligence対応端末で実行すれば、そのまま動きます。

コンテキストウィンドウと、それが足りなくなる地点

SystemLanguageModel.default.contextSizeは、モデルが動作するトークン予算を返します。この予算は共有されており、プロンプトと応答が合わせて収まらなければなりません⁶。クラウドモデルと比べれば小さな数字で、現実の入力を相手にするとすぐに実感するはずです。長い文書、丸ごとのチャット履歴、肥大したツールの戻り値。どれもが予算を吹き飛ばし、respondが例外を投げる原因になります。

そこから2つの失敗パターンが生まれ、どちらもあなたが防ぐべきものです。ひとつは、じわじわ効いてくるほう。複数ターンのセッションがトランスクリプトを溜め込み、あるターンでついに溢れます。無関係な処理には新しいセッションを立て、1ターンあたりの入力を絞ることで管理しましょう。もうひとつは、単発の巨大リクエスト。20ページのPDFは入りません。以上です。分割して、断片ごとに要約し、その要約群に対して推論する（LLMのエンジニアにはおなじみのmap-reduceです）か、あるいはそもそもオンデバイスモデルに合わない形の仕事だと認めるかです。

コンテキストウィンドウは、このフレームワークで本当に重要な判断——端末上にとどまるか、外へ出るか——を示す、最も明快なシグナルです。数字はすでに公開されています。オンデバイスモデルは4Kトークンの予算で動作し、Private Cloud Computeのサーバーモデルはそれを32Kに引き上げます¹⁴。以下の分割にまつわる話は、いずれもこの数字を前提として読んでください。

iOS 27のベータで加わるもの

ここまではiOS 26で出荷された時点のフレームワークの説明であり、その内容は今も有効です。iOS 27のベータは同じ表面を4つの方向へ拡張しますが、そのどれもiOS 26の思考モデルを壊しません¹²。

プロンプトが画像を受け取ります。 オンデバイスモデルがVisionの能力を獲得しました。テキストと並べてプロンプトに画像の添付を差し込むと、モデルは両方を踏まえて答えます。新しい型はAttachment、ImageAttachmentContent、ImageReferenceで、添付はUIImage、NSImage、CGImage、Core Imageの各型、CoreVideoのピクセルバッファ、ファイルURLを受け付けます¹²¹³。画像はどんなサイズ・アスペクト比でも扱えますが、テキストと同じトークン予算から消費するため、4Kのオンデバイスウィンドウがたちまち設計上の制約になります¹³。詳しい手順はiOS 27のFoundation Modelsにおける画像入力で解説しています。

ツール呼び出しを絞れるようになります。 GenerationOptionsにリクエスト単位で指定するtoolCallingModeが加わり、アタッチしたツールとモデルがどう関わるかを制御できます。さらにVisionフレームワークが既製のOCRToolとBarcodeReaderToolの実装を提供するので、自前で認識コードを書く代わりにセッションへアタッチすれば済みます¹⁵。挙動の詳細はiOS 27のツール呼び出し制御にまとめています。

より大きなモデルが、たった1行の先に。 PrivateCloudComputeLanguageModelは、同じAPIをApple製サーバーモデルに対してPrivate Cloud Compute上で実行します。エンタイトルメントが必要ですが、32Kのコンテキストウィンドウと、オンデバイスモデルにはない推論能力が手に入ります¹²¹⁴。ガイド付き生成もツールもそのまま動き、モデルの切り替えはセッションのmodel引数だけです。

セッションまわりの制御手段が増えます。 ベータではContextOptions、TranscriptErrorHandlingPolicy、動的プロファイル（DynamicInstructions、LanguageModelSession.DynamicProfile）、そしてシステムのモデルではなく、あなたが用意したモデルをセッションが動かせるようにするカスタム言語モデルプロバイダのプロトコル（LanguageModel、LanguageModelExecutor）が追加されました¹²。対応プラットフォームには27.0でwatchOSも加わっています¹²。

押さえておきたい位置づけはこうです。iOS 26のコードはiOS 27でもそのままコンパイルされ、同じように振る舞います。ベータが広げたのは、プロンプトが運べるものと、モデルが動ける場所です。フレームワークの本質そのものは変わっていません。

Foundation Modelsを使うべきでないとき

無料で、プライベートで、オフラインで動く。だからこそ、どこにでも使いたくなります。そこは我慢しましょう。次の場合は、その先に手を伸ばしてください。

• 本格的な推論や、幅広い世界知識が要るとき。 オンデバイスモデルは設計上小さいものです。自由度の高い推論、コード生成、深い分析は、クラウドのフロンティアモデルの領分です。オンデバイスモデルに求めれば、自信満々で間違った答えが返ってきます。
• 入力がコンテキストウィンドウに収まらず、分割すると意味が壊れてしまうとき。全体を一度に見なければ成立しない仕事もあります。
• 自分で管理できるモデルが要るとき。 特定のチェックポイント、ファインチューニング、独自の重み、OS更新をまたいだ決定的なバージョン管理。Appleがモデルを出荷し更新するのは、Appleの都合であって、あなたの都合ではありません。
• iOS 26未満、あるいは非対応端末のとき。 フレームワークはそもそも存在せず、利用可否の確認が実行のたびにそう教えてくれます。

フレームワークがカバーしないオンデバイスの用途（独自モデル、自前の重み、端末上での学習）については、その下の層があります。変換済みの固定モデルならCore ML、オープンウェイトのモデルや自分で持つファインチューニングならMLX、特化とスケジューリングを明示的に制御したいならiOS 27のCore AIです。本当に規模が要る場合は、Private Cloud Computeか、プライバシー境界の向こうに置いたクラウドLLMが依然として誠実な答えでしょう。Foundation Modelsは、そのどれの代替でもありません。すでに手元にあるテキストに対する、焦点の定まった言語処理には最初に手を伸ばすべきものであり、それ以外のすべてには間違った選択です。

このフレームワークが報いてくれる技術は、プロンプトの職人芸ではありません。スコープに対する審美眼です。得意な仕事をモデルに渡すこと。必要なものを過不足なく捉える@Generable型を設計すること。そして、仕事が端末の器を超えた瞬間を見抜くこと。その勘所を持って作れば、オンデバイスモデルは驚くほど多くの実務を無料でこなします。無視すれば、入力がトークン1つ分だけ長かったユーザー全員に対して壊れる機能を出荷することになります。

よくある質問

AppleのFoundation Modelsフレームワークは無料で使えますか？

はい。このフレームワークにより、アプリからApple Intelligenceを支えるのと同じオンデバイスモデルへ、直接・無料・オフラインでアクセスできます。APIキーも、トークン単位の請求も、ネットワーク往復もありません¹。

Foundation Modelsにはどの端末とiOSバージョンが必要ですか？

iOS 26とApple Intelligence対応端末が必要です。それを下回る環境ではフレームワーク自体が存在しませんし、対応OS上であっても、非対応端末、Apple Intelligenceがオフの状態、モデルのダウンロード中にはモデルは使えません。使う前に必ずSystemLanguageModel.default.availabilityを確認してください⁵。

文字列ではなく、構造化された型安全な出力を得るには？

Swiftの型に@Generableを付ければ、パースが必要な文字列ではなく、値が埋まって型検査済みのその型が返ってきます。このガイド付き生成こそ、このフレームワークを使う価値を生んでいる唯一の機能です³。

Appleのオンデバイスモデルのコンテキストウィンドウはどのくらいですか？

SystemLanguageModel.default.contextSizeがトークン予算を返します。この予算はプロンプトと生成された応答で共有されます⁶。オンデバイスモデルは4Kトークン、Private Cloud Computeのモデルは32Kを提供します¹⁴。長い文書や長い複数ターンの履歴はオンデバイスの予算を超えるので、上限を織り込んで設計しないとセッションが例外を投げます。

Foundation Modelsはオフラインで動きますか？データはAppleへ送られますか？

完全に端末上でNeural Engineを使って動作します。データが端末外へ出ることはなく、ネットワーク往復も不要です。だからこそ、かつてはクラウドLLMとプライバシー審査を必要とした機能に向いているのです¹。

オンデバイスモデルは生成の途中で自分のコードを呼び出せますか？

はい。Toolプロトコルにより、モデルは生成中にあなたのコードを呼び出してデータを取得したり処理を実行したりし、その結果を回答に織り込めます⁴。

Foundation Modelsを使うべきでないのはどんなときですか？

フロンティアモデルが必要なとき、つまり自由度の高い推論、コード生成、長文書の分析、世界知識が要るときは、その先へ手を伸ばしてください。Appleがオンデバイスモデルを作ったのはアプリ内で完結する焦点の定まった言語処理のためなので、汎用的な知性を求めれば自信満々で間違った答えが返ってきます¹。

iOS 27ではFoundation Modelsに何が加わりますか？

iOS 27のベータでは、画像入力（UIImage、CGImage、ピクセルバッファなどから作るプロンプトへの添付）、GenerationOptionsによるリクエスト単位のツール呼び出し制御、既製のVisionツールであるOCRToolとBarcodeReaderTool、そしてApple製の32Kコンテキストのサーバーモデルに同じAPIで接続するPrivateCloudComputeLanguageModelが加わります^12131415。iOS 26のコードはそのまま動きます。