Private Cloud Compute上のFoundation Models

オンデバイスのFoundation Modelに、兄弟分が生まれました。iOS 27はフレームワークに、Private Cloud Compute上で動作するサーバー規模のモデルをもたらします。32Kのコンテキストウィンドウと推論を備え、コードを1行変えるだけで利用できるのです¹。LanguageModelSessionもGenerableもToolプロトコルも、すべて同じまま⁴。より大きな変化はその下にあります。Appleは公開プロトコルを通じてほぼあらゆるLLMにフレームワークを開放しました。これにより、オンデバイスモデルも、クラウドモデルも、自分でバンドルするローカルモデルも、Hugging Faceのオープンソースモデルも、そして間もなく登場するClaudeやGeminiも、すべて同じSwift APIで応答するようになります²。あるモデルに対してコードを書くのではなく、付け替え可能なスロットに対してコードを書くようになるのです。

この記事は、フレームワークのリファレンスの上に重なる「クラウドとプロバイダー」のレイヤーを扱います。LanguageModelSession、Toolプロトコル、ガイド付き生成にまだ触れたことがなければ、まずFoundation Modelsフレームワーク解説とiOS 27のツール呼び出しの記事から読み始めて、それからここに戻ってきてください。

TL;DR

• Private Cloud Computeは、より大きなサーバーモデルをFoundation Modelsフレームワークに持ち込み、オンデバイスモデルから1行変えるだけで切り替えられます。オンデバイスの4Kに対して32Kのコンテキストウィンドウを提供し、3段階の推論をサポートし、iOS、macOS、visionOS、watchOSから動作します¹²。
• プライバシーの姿勢はシステムモデルと同等です。AppleはPCCを、ユーザーデータが一切保存されずリクエストにのみ使われるよう設計し、その設計は研究者によって独立に検証されています。APIキーも、アカウント設定も、開発者へのトークン課金もありません¹。
• 各ユーザーには、iCloudアカウントに紐づく1日あたりのリクエスト上限が割り当てられ、iCloud+でアップグレードできます。UIではこの上限を、モデルのクォータ状態を確認したうえで、アラートではなく永続的で操作可能なコントロールを表示して処理しましょう。アクセスは開発者向けWebサイトで申請でき、ダウンロード数200万未満のアプリで利用できます¹。
• 新しいLanguageModelプロトコルは、あらゆるモデルを差し込み可能にします。System、PCC、ANE上でローカルモデルを動かすCore AI、Hugging FaceコミュニティのためのMLX、そして今後登場するAnthropicとGoogleのプロバイダーパッケージです²。
• DynamicProfileを使えば、1つのセッションが会話の途中でこれらのモデルを行き来できます。ブレインストーミングの番では高い温度設定でPCCを使い、レビューの番ではオンデバイスモデルに切り替えてサーバー呼び出しを節約する、といった具合です³。

より大きなモデル、変わらない3行

昨年の売り文句は、オンデバイスモデルへのプロンプトはわずか3行で済むというものでした。セッションを作り、respondを呼び、答えを読む¹。今年はその売り文句がクラウドにまで広がります。どのモデルと話すかにかかわらず、フレームワークは統一されたSwift APIを提供するため、オンデバイスのSystemモデルからPCCモデルへ切り替えても、変わるのは構築するモデルだけで、ほかは何も変わりません¹。Generableによる構造化出力もツール呼び出しも、両者でまったく同じように振る舞います¹。

セッション319のLouis：オンデバイスモデルへのプロンプトは3行で済み、PCCサーバーモデルへの切り替えは、より大きなコンテキストと推論を備えたはるかに大規模なモデルへの1行の変更にすぎません。

差し替えの形を、フレームワーク自身の言葉で表すとこうなります。

import FoundationModels

// On-device: the System model.
let onDevice = LanguageModelSession(model: SystemLanguageModel.default)

// Cloud: swap the model. Same session API, same prompts, same tools.
let cloud = LanguageModelSession(model: PrivateCloudComputeLanguageModel.default)

let summary = try await cloud.respond(to: "Summarize this 30-page contract.")

シンボル名はセッションからそのまま来ています。AppleはクラウドモデルをPrivateCloudComputeLanguageModelとして公開し、セッションではSystemLanguageModelとPrivateCloudComputeLanguageModelの両方にあるcontextSizeプロパティからコンテキストサイズを読み取る様子が示されました¹。クラウドモデルは、ほかのすべてのモデルが準拠するのと同じLanguageModelプロトコルに準拠しているため、残りのコードはその違いに気づきません²。

オンデバイスモデルから引き継がれ、しっかり確認すべき制約が1つあります。PCCはApple Intelligenceをサポートするデバイスでのみ動作するのです。可用性APIを確認し、Apple Intelligenceが利用できないケースを、オンデバイスモデルですでにゲートしているのと同じように処理してください¹。

PCCで得られるもの、その対価

PCCは、オンデバイスモデルでは届かないユースケースに対するAppleの答えです。大量のユーザー入力にわたって推論するアシスタントや、大きな出力を伴う多数のツール呼び出しを発火させる機能などです¹。そのトレードオフは雰囲気任せではなく具体的で、セッションはそれを真っ向からの対比として示しています。

判断の大半は、2つの行が担っています。4Kから32Kへの跳躍こそが、「画像付きの長い文書を要約する」機能を、クラウドモデルでは実現可能にし、オンデバイスモデルでは窮屈にするものです¹。もう1つは推論です。素のレスポンスがプロンプトを読んで生成するのに対し、推論ありのレスポンスは答える前に、トランスクリプトの別セグメントで追加のテキストを生成します¹。3つの段階は、その思考の予算をスケールさせます。lightは少しだけ追加の文脈を集め、moderateはより深く推論し、deepでは答えそのものより長い推論セグメントを生成することもあります¹。段階はセッションでrespondを呼ぶときに設定します¹。

推論はタダではありません。推論セグメントはモデルが生成するテキストなので、トークンを消費し、32Kのコンテキスト予算を圧迫します¹。セッションは、そこで求められる規律についてはっきり述べています。オンデバイスとPCCのどちらを使うか、そして推論段階を、雰囲気ではなくデータから決めるのです¹。Appleはまさにそのために、Xcodeに新しいEvaluationsフレームワークを投入しました。オンデバイスモデルは多くのタスクで予想以上の性能を発揮し、それを知る唯一の方法は計測することだからです¹。

プライバシーの姿勢こそが見出し

ユーザーの私的な入力を扱うサーバーモデルは、たいていプライバシーの物語が崩れる場所です。PCCはそうならないように作られています。Appleはエンドツーエンドのプライバシーを念頭にPrivate Cloud Computeを設計し、ユーザーデータが一切保存されずリクエストにのみ使われることを保証しています。そしてその設計は研究者によって独立に検証されました¹。PCCはすでにApple Intelligence自身の複雑なタスクを支えており、フレームワークはその同じインフラをあなたのアプリに開放します¹。

開発者が肌で感じるのは、運用面での帰結です。PCCはiCloudと並んでOSに統合されているため、組み込むべき認証も、ローテートすべきAPIキーも、ユーザーに求めるアカウント設定もありません¹。ユーザーに必要なのはApple Intelligenceをサポートするデバイスだけで、それ以上は何もいりません。開発者であるあなたへのトークン課金はなく、各ユーザーには1日の上限が割り当てられ、ユーザーはiCloud+を通じてそれを引き上げられます¹。このモデルはダウンロード数200万未満のアプリで利用でき、開発者向けWebサイトで申請します¹。

プライバシー保証についてのセッション319：アカウント設定も、認証も、APIキーも、開発者へのトークン課金もなく、各ユーザーのリクエストはそのiCloudアカウントに対してカウントされます。

更新、2026年6月8日：PCCがApple siliconの外へ

WWDCが開幕したのと同じ週に、Appleはセキュリティ記事を公開し、PCCの動作場所を変えました。PCCは新しいApple Intelligenceワークロード向けに、NVIDIA GPU上のGoogle Cloudへと拡張され、「業界をリードするPCCのプライバシーへのコミットメントを、初めてサードパーティのデータセンターへと広げる」ものとなります⁵。あなたがターゲットとするフレームワークは変わりません。その下にあるインフラが変わるのです。

Appleは契約をまったく同じに保ちます。5つの中核要件は以前のまま変わりません。「ステートレスな計算、強制可能な保証、特権的なランタイムアクセスの不在、非標的性、検証可能な透明性」です⁵。変わるのは実装で、Appleはそれを「NVIDIA GPUを用いたNVIDIA Confidential Computing、Intel TDX対応のIntel CPU、そしてGoogleのTitanチップ」と名指ししています⁵。Appleはその土台を、標準的なConfidential Computingの構成を超えて、開発者が留意すべき2つの方法で堅牢化しています。「PCCフリートの一部であるすべてのGoogle Cloudハードウェアの、暗号学的に検証可能な追記専用台帳」を維持すること、そしてユーザーデータを流出させうるコンポーネントについては「ソフトウェアのアテステーションが、独立したベンダー由来の少なくとも2つの別個の信頼の根に根ざしている」ことです⁵。

プライバシーの姿勢にとって最も重要な一文は、コントロールに関するものです。Appleは「AppleはPCCソフトウェアに対する完全なコントロールを保持し続ける。AppleデバイスはAppleが暗号学的に承認したPCCソフトウェアのみを信頼する」と述べています⁵。研究者向けの検証の物語も引き継がれます。Appleは、Apple Security Bountyプログラムを通じて、すべてのバイナリを公開検査のために公表し、研究モードで稼働中のPCCノードへのアクセスを提供すると述べています⁵。ロールアウトは段階的で、「サマープレビュー期間を通じて保護一式の完成へと近づいていく」ため、PCCに対してリリースした機能は、プレビュー中、最終版ではなく動き続ける保証一式を引き継ぐことになります⁵。

この記事のコードにとっての要点はこうです。上記のプライバシーに関する主張は、PCCモデルがApple siliconから応答してもGoogle Cloudから応答しても成り立ちます。Appleが同じ5つの要件と同じデバイス側の信頼ゲートを保つからです。PCCはまた、サードパーティのモデルが追従できない領域における、Appleのファーストパーティの答えでもあります。これは同じ週に出たAppleのプロンプトインジェクションへのファーストパーティの答えと対になります。

ラボメモ：PCCの保証はフレームワークの境界で止まる

WWDCのラボがはっきり述べていた点が、その拡張の隣で取り上げる価値があります。マーケティングが引かない一線を引くものだからです。PCCの保証、すなわちステートレスな計算、非標的性、一時的なストレージは、フレームワークの言語モデルプロトコルを通じて到達するGeminiやClaudeなどのサードパーティモデルには及びません。セッションがSystemモデルやPCCモデルではなくプロバイダーパッケージにルーティングされる場合、そのプロバイダーの規約を読み、結果として生じるデータフローを、App Storeのプライバシー栄養表示ラベルを含めて開示するのは、開発者の責任です⁶。プロトコルはモデルをまたいで1つのSwift APIを与えますが、モデルをまたいで1つのプライバシーの姿勢を与えはしません。その開示の作業は、Appleではなくあなたに課されます。

UIを壊さずに1日の上限を扱う

1日の上限は、クラウドモデルがUXに入り込む唯一の場所であり、セッションはその扱い方について明確な意見を持っています。リクエストはユーザーのiCloudアカウントに対してカウントされ、上限を超えたリクエストはエラーをスローします¹。その生のエラーをUIにそのまま出すのは間違った手です。そのエラーは操作可能ではないからです¹。

代わりに、モデルのクォータ状態を確認し、自前のコントロールを描画しましょう。セッションは、モデルのquotaUsageにあるisLimitReachedを確認し、上限を超えていたら、ユーザーが上限を管理またはアップグレードできるボタンを表示します¹。表示を律するルールは2つあります。アラートは使わないこと。上限状態は、いったん閉じられるのではなく、ずっと残るべきだからです。代わりにUIの状態を更新します。たとえばリクエストボタンを無効化し、その下に控えめなラベルとアップグレードのアクションを示すといった具合です¹。そして、上限が近づくケースも検知してください。モデルはbelowLimit状態を公開しているので、上限に近いユーザーに警告し、どのリクエストに使う価値があるかを本人に決めてもらえます¹。

// Sketch following the session's pattern.
let quota = PrivateCloudComputeLanguageModel.default.quotaUsage
if quota.isLimitReached {
    // Persistent label + upgrade button. No alert.
    showUpgradeAffordance()
} else if quota.belowLimit {
    // Optional: warn the user they are nearing the daily limit.
    showNearingLimitNotice()
}

Xcodeは、実際のクォータを消費せずにこれを作る手助けをしてくれます。スキームのDebug Optionsにある「Simulate Apple Foundation Models Availability」設定では、「Quota Usage Limit Reached」と「Nearing Usage Limit」が選べるので、両方のUI状態をシミュレーターで動かせます¹。

自分のLLMを持ち込む：プロバイダープロトコル

iOS 27のより深い変化は、Foundation Modelsが単一モデルのフレームワークであることをやめた点です。AppleはオンデバイスのSystemモデルを作り直し、さらに3つのファーストパーティの選択肢を追加し、それから他のすべての人にも扉を開きました。PCCは推論と32Kコンテキストを備えたサーバーモデルをもたらします。Core AIはApple Neural Engine上でローカルモデルを効率的に動かします。MLXは、Hugging FaceにあるMLXコミュニティの数千ものモデルを、モデルIDで利用可能にします²。そしてそのすべてが新しい公開プロトコルの上に乗っているため、フロンティアのプロバイダーは独自のSwiftパッケージを出荷できます。Appleは、同じフレームワークを通じてClaudeとGeminiをSwift開発者にもたらす存在として、AnthropicとGoogleの名を挙げました²。

セッション339のChristopher Webb：システムモデルに加えて、フレームワークはPCC、Core AI、MLXを追加し、公開プロトコルによってAnthropicやGoogleのようなプロバイダーが独自のSwiftパッケージでそれを拡張できます。

プロトコルには2つの部分があり、その分割こそが設計のすべてです。LanguageModelはモデルをフレームワークに対して記述します。能力を宣言し、構成を返します。LanguageModelExecutorは実際の処理が宿る場所で、その構成を受け取るイニシャライザ、最初のリクエストに先立って重みを読み込んだり接続を開いたりするprewarm、そして生成をセッションへストリーミングで返すrespondを持ちます²。構成は両者をつなぐリンクであり、ルックアップのキーでもあります。各セッションはエクゼキューターのストアを保持します。モデルがストアの見たことのない構成を生み出すと、フレームワークはエクゼキューターを構築してキャッシュします。セッションはこの構成をHashableとして記述するので、同じ構成を持つ2つ目のモデルは同じエクゼキューターに解決されます²。このキャッシュこそが、ステートフルな統合が、処理をやり直すのではなく、呼び出しをまたいでKVキャッシュや永続的な接続を保持できる理由です²。

モデルプロバイダーにとって、エクゼキューターの仕事は翻訳です。フレームワークはエクゼキューターに、型付きエントリの列であるトランスクリプトを渡し、エクゼキューターはそれらのエントリを、自前の推論エンジンが話すどんな役割にもマッピングします²。Appleは6種類のエントリタイプを定義しています。instructions、prompts、ツール呼び出し、ツール出力、レスポンス、そして推論です²。system、user、assistantの役割しか持たないモデルは、ツール呼び出しと推論をassistantにマッピングし、専用のツール役割を持つモデルはそちらにルーティングします²。各リクエストはまた、開発者の意図を2つのプロパティバッグで運びます。プロンプトに入るもの（推論段階やレスポンススキーマなど）を扱うContextOptionsと、デコーダーループ（サンプリング、温度、長さなど）を扱うGenerationOptionsです²。出力側では、エクゼキューターはチャンネル上でイベントをストリーミングし、テキストのデルタより先に、メタデータの更新（モデルIDとリクエストID）とusageの更新（プロンプトのトークン数）を先頭に置きます。これにより開発者は、ストリーム全体を待たずにリクエストのコストを知ることができます²。

エラーの物語は、プロバイダーを書くことが決してなくても、アプリ開発者にとって重要です。Foundation Modelsは、あらゆるモデルが遭遇するケースのためにLanguageModelErrorを出荷します。コンテキストウィンドウのオーバーフロー、レート制限、拒否などです²。プロバイダーは、当てはまる場合にはそのいずれかをスローすべきです。フレームワークのどのユーザーもすでにそれをキャッチする方法を知っているからです。そして、サブスクリプションのティアやアカウント状態のように、自分のサービス特有の障害にだけカスタムエラータイプを取っておくべきです²。プロバイダーはまた、カスタムのレスポンスメタデータ（毎秒トークン数、最初のトークンまでの時間）や、音声や動画といった新しいモダリティへとプロトコルを拡張するカスタムセグメントタイプを通じて差別化する余地も得ます。そのすべてが同じセッションを通って流れます²。クラウドプロバイダーには、資格情報に関する鋭いリマインダーが向けられます。APIキーをただの文字列として受け取らないこと。トークンプロバイダーやサインインフローを用意し、トークンはKeychainに永続化し、App Attestによるデバイスアテステーションと組み合わせるのです²。

エージェント的な含意：1つのセッション内でモデルをルーティングする

プロバイダープロトコルとPCCが報われるのは、アプリごとに1つのモデルという考えをやめ、タスクごとに1つのモデルという考えを始めたときです。それを可能にするのがDynamicProfileです。これにより、1つのLanguageModelSessionが会話の途中でモデルを切り替え、目の前のタスクに最適な構成を選べます³。

セッション242のErikとOliver：クラフトアプリがエージェントとして振る舞うプロファイルを宣言し、高い温度でPCC上でブレインストーミングし、深い推論で計画を立て、サーバー呼び出しを節約するためオンデバイスモデルでレビューします。

セッションの例は、3つのフェーズを持つクラフトアプリです。ブレインストーミングは広い知識と創造性を求めるため、そのプロファイルは温度を1に設定したPrivateCloudComputeLanguageModelを使います³。計画は深さを求めるため、PCCのままreasoningLevelをdeepに設定します³。レビューはユーザーが作業する間の日常的なガイダンスなので、SystemLanguageModelに切り替えて不要なサーバー呼び出しを省きます。これは、本当に必要な作業のためにユーザーの1日のPCCクォータを温存することにもなります³。DynamicProfileの本体はプロンプトごとに再評価されるため、アプリがモードを変えるとセッションがペルソナを変えます。帽子を取り替えるように、あるいはエージェントを取り替えるように³。

異なるコンテキストサイズのモデル間でルーティングすると、オンデバイス専用のフレームワークが決して要求しなかった規律が求められます。PCCの32Kからオンデバイスの4Kへ移ると、収まるようにエントリを切り詰める必要があるかもしれません。セッションはプライバシー上の用途も挙げています。より私的でないモデルへ移るときに、既存のエントリから私的な情報を伏せるのです³。フレームワークのhistoryTransformは、プロンプトを送る前にローカルで非破壊的な変換を適用するので、1つのモデルのために切り詰めても、次の番で必要になるかもしれない文脈を失いません³。変更には対価が伴います。トランスクリプトへの追記はKVキャッシュを保ち、最初のトークンまでの時間を最小化しますが、履歴を書き換えること（エントリの削除、ツールの変更、命令の更新）はたいていキャッシュを無効化し、レイテンシを増やします³。昨年のセッションAPIは、その最適化を保証するために追記専用でした。今年Appleは補助輪を外しました。そしてモデルのキャッシュ挙動を知る唯一の方法は、XcodeのFoundation Models Instrumentで計測することです³。

判断：オンデバイス、PCC、それとも自分のプロバイダーか

3つの選択肢ははしごではありません。それぞれが、異なる形の問題に対して適しています。

まずはオンデバイスのSystemモデルに手を伸ばしましょう。 無料で、オフラインで動作し、リクエスト上限がなく、iOS 27の作り直しによって命令追従が向上し、画像入力も加わりました²。4Kのコンテキストが本当の天井です¹。もっと必要だと決めつける前に評価してください。セッションは、その性能の良さに驚くだろうと警告しています¹。

タスクがオンデバイスモデルを超え、かつデータが機微なときは、Private Cloud Computeに手を伸ばしましょう。 32Kウィンドウを必要とする長い文書、複数ステップの推論、あるいは大きな出力を伴う多数のツール呼び出しです¹。PCCは、キーもアカウントもトークン課金もなしにAppleのプライバシーの姿勢を保つ唯一のクラウドの選択肢で、その対価はあなたが設計してまわるユーザーごとの1日の上限です¹。自前のサーバーモデルを立てて、プライバシー審査を恐れることになりそうなときに選びましょう。

プラットフォームが与えてくれない特定のモデルが必要なときは、自分のプロバイダーに手を伸ばしましょう。 バンドルしてANE上で動かすローカルモデルにはCore AI、IDで指定するオープンソースモデルにはMLX、フロンティアモデルにはプロバイダーパッケージ（Claude、Gemini）です²。あなたは資格情報の扱い、アテステーション、プライバシー開示を引き受け、その代わりに、アプリがすでに話している同じLanguageModelSessionの背後に、名前のついたモデルを得ます²。セッションは、オンデバイスモデルとクラウドモデルがまったく異なるプライバシー特性を持つこと、そしてどちらが応答しているのかをユーザーが知る権利があることを、はっきり述べています²。

フェーズが異なるときは、1つのセッション内で混ぜましょう。 それがDynamicProfileのケースです。重い創造や推論の番にはPCC、日常的な番にはオンデバイスモデルを使い、各プロファイルがそれぞれのモデル、温度、推論段階を携えます³。

FAQ

オンデバイスモデルからPrivate Cloud Computeへ切り替えるには？

LanguageModelSessionに渡すモデルを変えてください。フレームワークはモデルをまたいで統一されたSwift APIを提供するので、オンデバイスのSystemモデルからPrivateCloudComputeLanguageModelへの移行は1行の変更であり、プロンプトもGenerable出力もツールも同じように動きます¹。PCCはApple Intelligenceをサポートするデバイスでのみ動作するので、可用性チェックは残しておきましょう¹。

Private Cloud Computeはオンデバイスモデルと同じくらい私的ですか？

Appleは、ユーザーデータが一切保存されずリクエストにのみ使われるようPCCを設計し、その設計は研究者によって独立に検証されています¹。PCCはiCloudと並んでOSに統合されているため、管理すべきAPIキーも、アカウント設定も、認証もありません¹。オフライン動作と無制限のリクエストではオンデバイスが依然として勝り、コンテキストサイズと推論ではPCCが勝ります¹。

PCCのコストはいくらで、1日の上限はどれくらいですか？

開発者であるあなたへのトークン課金はありません¹。各ユーザーには、iCloudアカウントに対してカウントされる1日のリクエスト上限が割り当てられ、ユーザーはより高い上限をiCloud+を通じてアップグレードできます¹。UIではこの上限を、モデルのクォータ状態（isLimitReached、belowLimit）を確認し、アラートではなく永続的で操作可能なアップグレードコントロールを表示して処理しましょう¹。このモデルはダウンロード数200万未満のアプリで利用でき、開発者向けWebサイトで申請します¹。

「自分のLLMプロバイダーを持ち込む」とは実際どういう意味ですか？

Appleは公開のLanguageModelプロトコルを追加したので、あらゆるモデルがFoundation Modelsフレームワークに差し込め、Apple自身のモデルと同じAPIを通じて呼び出せます²。SystemモデルとPCCに加えて、フレームワークはANE上のローカルモデルにCore AIを、Hugging FaceコミュニティモデルにMLXを追加し、AppleはClaudeとGeminiのSwiftパッケージを出荷する存在としてAnthropicとGoogleの名を挙げました²。プロバイダーはLanguageModelに加えて、フレームワークのトランスクリプトを自前の形式に翻訳し、生成をストリーミングで返すLanguageModelExecutorを実装します²。

1つのセッションで2つ以上のモデルを使えますか？

はい。DynamicProfileを使えば、1つのLanguageModelSessionが会話の途中でモデルを切り替え、タスクごとに最適な構成を選べます³。プロファイルはそれぞれのモデル、命令、温度、推論段階を携え、プロファイル本体はプロンプトごとに再評価されるので、1つのセッションが同じ会話の中でPCCでブレインストーミングし、オンデバイスモデルでレビューできます³。そうするときは、モデル間のコンテキストサイズの差と、履歴を書き換える際のKVキャッシュのコストに注意してください³。

Apple Ecosystemクラスタの全体像はこうです。Foundation Modelsフレームワーク解説、iOS 27のツール呼び出し制御、エージェント的ワークフローの区別、そしてオンデバイスLLM。ハブはApple Ecosystem Seriesです。AIエージェントを伴うiOSのより広い文脈については、iOS Agent Development guideをご覧ください。