Private Cloud Compute 上の新しい Apple Foundation Model で構築する

ハイライト

Apple は Private Cloud Compute（PCC）上で動作するサーバー側大規模モデルをサードパーティ App に開放します。開発者は PrivateCloudComputeLanguageModel() を渡す 1 行の変更だけで、デバイス上 LLM 呼び出しを 32K コンテキストのクラウドモデルへシームレスに切り替えられます。API Key も認証設定も Token 費用も不要ですが、ユーザーごとの日次クォータ制限への対応は必要です。

主要内容

デバイス上モデルの上限

昨年 Apple は Foundation Models フレームワークを発表し、開発者は 3 行のコードでデバイス上 LLM を呼び出せるようになりました。しかし 4K のコンテキストウィンドウと限られた計算能力では、少し複雑な場面でもすぐに窮屈になります。長文書を分析するアシスタントや、何度も tool を呼び出して大量の出力を生成する機能を作ろうとすると、デバイス上モデルにはそもそも入りません。(00:16)

開発者がこの制限を超えようとすると、通常はサードパーティのクラウド API を接続する必要がありました。つまり API Key を管理し、認証を処理し、Token 費用を負担し、データプライバシーについてユーザーへ説明する必要があります。独立開発者や小規模チームにとっては、かなり大きなコストと認知負荷です。

1 行のコードでクラウド計算能力を得る

Apple の今年の答えは、自社のシステム機能でも使っている Private Cloud Compute（PCC）をサードパーティ App に開放することです。PCC 上のサーバーモデルは 32K のコンテキストウィンドウを提供し、より複雑な推論に対応し、呼び出し方法はデバイス上モデルと完全に統一されています。(00:39)

最も分かりやすい利点は、コード上の移行コストがほぼゼロであることです。すでに Foundation Models フレームワークを使っているなら、LanguageModelSession の初期化引数を 1 行変えるだけです。

let session = LanguageModelSession(
    model: PrivateCloudComputeLanguageModel()
)

構造化出力（@Generable）と tool calling（Tool）のコードはまったく変える必要がありません。同じ respond(to:) メソッド、同じ generating: パラメータで、デバイス上とクラウドの動作が一致します。(03:02)

API Key は不要だが、クォータ対応は必要

PCC は iCloud と深く統合されています。ユーザーは新しいアカウント登録が不要で、開発者も API Key を設定する必要がありません。ユーザーのデバイスが Apple Intelligence に対応していれば、そのまま利用できます。(02:02)

ただし無料の昼食はありません。PCC の呼び出しはユーザーの iCloud アカウントに紐づき、各ユーザーには日次クォータ上限があります。ユーザーは iCloud+ へアップグレードすることでより高い上限を得られますが、開発者は App 内でクォータ枯渇を丁寧に扱う必要があります。ユーザーがその日の上限を使い切ると、リクエストは直接エラーを投げます。このとき「エラーが発生しました」という Alert を出すだけでは体験として不十分です。(07:14)

Apple が勧める方法は、UI 内でクォータ状態をリアルタイムに検出し、上限に近づいたら穏やかに通知し、使い切ったらリクエストボタンを無効化してアップグレードへ誘導することです。すべての状態情報は PrivateCloudComputeLanguageModel の quotaUsage プロパティから公開され、数行のコードで実装できます。(08:07)

詳細

デバイス上 vs クラウド: モデルをどう選ぶか

(04:06)

2 つのモデルにはそれぞれ向いた場面があります。

観点	デバイス上モデル	PCC クラウドモデル
ネットワーク依存	オフライン利用可能	ネットワーク接続が必要
リクエスト制限	無制限	日次クォータ
コンテキストサイズ	旧デバイスは 4K / 新デバイスは 8K	32K
推論能力	非対応	Light / Moderate / Deep の 3 段階
プライバシー	データはデバイス外へ出ない	エンドツーエンド暗号化、保存なし

コードでは contextSize プロパティを使い、現在のモデルのコンテキストサイズを動的に取得できます。

SystemLanguageModel().contextSize        // 4096 (旧デバイス) または 8192 (新デバイス)
PrivateCloudComputeLanguageModel().contextSize  // 32768

(05:58)

利用可能性を確認する

PCC は Apple Intelligence に対応するデバイスでのみ利用できます。UI では isAvailable を先に確認し、関連機能を表示するかどうかを決めるべきです。

import FoundationModels

struct ArticleSummarizationView: View {
    private var model = PrivateCloudComputeLanguageModel()

    var body: some View {
        if model.isAvailable {
            // PCC 機能の UI を表示する
        } else {
            // デバイス上モデルまたは他の方法へフォールバックする
        }
    }
}

(03:51)

ポイント:

• isAvailable は View の body 内で直接使え、SwiftUI は状態変化に自動反応する
• Apple Intelligence に対応しないデバイス、たとえば A17 Pro / M 系列チップ以外のデバイスでは false を返す
• 利用可能性を仮定せず、常にフォールバックを用意する

構造化出力と tool calling は完全に再利用できる

デバイス上モデルの @Generable と Tool プロトコルは、PCC モデルでも同じように動作します。

import FoundationModels

@Generable
struct ArticleSummary {
    let oneLineSummary: String
    let keyPoints: [String]
}

struct FindRelatedArticlesTool: Tool {
    // Tool の実装...
}

let session = LanguageModelSession(
    model: PrivateCloudComputeLanguageModel(),
    tools: [FindRelatedArticlesTool.self]
)

let response = try await session.respond(
    to: "この記事を要約してください: \(article)",
    generating: ArticleSummary.self
)

(03:25)

ポイント:

• @Generable マクロで印付けした構造体定義は変わらない
• Tool プロトコルに準拠した tool 実装は変わらない
• respond(to:generating:) の呼び出し形式は変わらない
• モデル切り替えは LanguageModelSession の初期化引数を変えるだけ

推論レベルを設定する

PCC モデルは 3 段階の推論（Reasoning）をサポートし、最終回答を生成する前にモデルが「考える」ことを可能にします。

let response = try await session.respond(
    to: prompt,
    contextOptions: ContextOptions(reasoningLevel: .light)
)
// .light: モデルが少量の追加コンテキストを集める
// .moderate: 中程度の深さの推論
// .deep: 推論テキストが最終回答より長くなることもある

(05:26)

ポイント:

• 推論プロセスは追加のテキスト断片を生成し、session の transcript に保存される
• transcript を観察して推論進捗を表示できる。特に .deep モードで有用
• 推論テキストは Token を消費し、32K コンテキスト制限に含まれる
• 単純なタスクに .deep を使わない。クォータを無駄に消費する

クォータ制限を丁寧に扱う

クォータを使い切ったときは Alert を表示するのではなく、UI 状態を更新します。

struct ArticleSummarizationView: View {
    private var model = PrivateCloudComputeLanguageModel()

    var body: some View {
        VStack {
            Button("要約を生成") {
                // リクエストを開始する
            }
            .disabled(model.quotaUsage.isLimitReached)

            if case .belowLimit(let info) = model.quotaUsage.status,
               info.isApproachingLimit {
                Text("クォータがまもなく上限に達します")
                    .foregroundStyle(Color.orange)
            }

            if model.quotaUsage.isLimitReached {
                Text("本日のクォータを使い切りました")
                    .foregroundStyle(Color.red)
                if let suggestion = model.quotaUsage.limitIncreaseSuggestion {
                    Button("クォータを増やす") {
                        suggestion.show()
                    }
                }
            }
        }
    }
}

(09:41)

ポイント:

• quotaUsage.status は .belowLimit(info) またはクォータ枯渇状態を返す
• info.isApproachingLimit は上限に近づいていることを示し、穏やかな案内に適している
• isLimitReached が true のときはリクエストボタンを無効化する
• limitIncreaseSuggestion はユーザーをアップグレードへ導くボタンを提供し、show() を呼ぶだけでシステム UI を表示できる
• Alert は避け、永続的なインライン UI を使う

Xcode でクォータ状態をデバッグする

Xcode にはクォータ状態をシミュレートするデバッグオプションがあります。Scheme の Debug > Options で “Simulate Apple Foundation Models Availability” を選ぶと、実際のユーザーが上限に達するのを待たずに、クォータ枯渇（Quota Usage Limit Reached）や上限接近（Nearing Usage Limit）の状態をシミュレートできます。(09:12)

核心アイデア

1. 「知的ドキュメントアシスタント」を作る

デバイス上モデルの 4K コンテキストでは数ページの文書しか扱えません。PCC の 32K なら一冊の本を取り込めます。@Generable で構造化出力を定義し、長文書から重要情報を抽出し、要約を生成し、具体的な質問に答えさせます。

• 何を作るか: PDF/Word/Markdown に対応した知的読書アシスタント
• なぜ価値があるか: PCC の 32K コンテキストにより、デバイス上 App が初めて本当に長い文書を扱えるようになり、データは Apple のプライバシーアーキテクチャ内に留まる
• どう始めるか: PrivateCloudComputeLanguageModel() で session を作成し、出力形式を表す @Generable 構造体を定義し、respond(to:generating:) で構造化結果を取得する

2. 多段階推論による段階的 AI 機能

すべてのタスクに .deep 推論が必要なわけではありません。単純な質問にはデバイス上モデル、複雑な質問には PCC の .light、深い分析には .moderate、研究級のタスクには .deep を使います。

• 何を作るか: タスクの複雑さに応じてモデルと推論レベルを自動選択する知的ルーティング層
• なぜ価値があるか: ユーザーのクォータを節約し、応答速度を高め、デバイス上モデルによりオフラインでも動作できる
• どう始めるか: まずデバイス上モデルを試し、信頼度が低い、またはコンテキストが足りない場合に PCC へ切り替える。contextSize プロパティで動的に判断する

3. Tool calling 付きの個人ナレッジベース

PCC は Tool プロトコルをサポートするため、モデルに自作 tool を呼び出させられます。32K コンテキストと組み合わせることで、ローカルノートを検索し、カレンダーを照会し、連絡先を取得できる個人アシスタントを構築できます。

• 何を作るか: App 内の複数データソースを呼び出せる個人 AI アシスタント
• なぜ価値があるか: デバイス上 + PCC のハイブリッドアーキテクチャにより、プライバシーと性能を両立できる
• どう始めるか: 検索や照会などの tool を Tool プロトコルで実装し、LanguageModelSession 初期化時に tools 引数で渡す

4. クォータを意識した段階的フォールバック

ユーザーのクォータが尽きたとき、単にエラーを出してはいけません。単純なタスクは自動的にデバイス上モデルへフォールバックしつつ、UI 内で iCloud+ へのアップグレードを案内できます。

• 何を作るか: クォータ枯渇時にモデルを自動切り替えする知的フォールバックシステム
• なぜ価値があるか: クォータ問題で App が使えなくなるのではなく、コア機能を常に利用可能にできる
• どう始めるか: quotaUsage.isLimitReached を監視し、true なら model 引数を渡さずに LanguageModelSession() を作成し、既定のデバイス上モデルで単純なリクエストを処理する

5. watchOS 上の AI 機能

PCC は watchOS からも呼び出せます。Apple Watch の計算能力は非常に限られていますが、PCC によりクラウド側大規模モデルの能力を得られます。

• 何を作るか: Apple Watch 上で音声要約や健康データ分析などの AI 機能を実装する
• なぜ価値があるか: watchOS が初めてサーバー級 LLM 能力を得られ、さらにペアリングされた iPhone を通じるため Watch 単体の独立ネットワーク接続は不要
• どう始めるか: watchOS App で FoundationModels を直接 import し、iOS とまったく同じ API を使う

関連 Session

• Foundation Models フレームワークの新機能 - Foundation Models フレームワークの全体像。画像入力や改善された tool calling など、デバイス上モデルの新機能も含む
• Foundation Models でエージェント App 体験を構築する - デバイス上モデルと PCC モデルが協調する Agent アーキテクチャ
• Evaluations フレームワークに出会う - データを使って、デバイス上モデルと PCC モデルそれぞれの能力境界を判断する
• Instruments でエージェント App 体験をデバッグしプロファイルする - 実行時のモデル呼び出し、Token 消費、推論時間を追跡する
• Swift の新機能 - Foundation Models フレームワークが依存する Swift 6 の新機能