Apple Foundation Models第3世代は20Bオンデバイス疎モデルとGoogle Cloud上のPCCに分かれた

Appleが2026年6月8日、Apple Foundation Models（AFM）の第3世代を公開した。
今回は「オンデバイスの小型モデルを少し良くした」だけではなく、20Bパラメータのオンデバイス疎モデル、Private Cloud Compute上の画像モデル、Google Cloud上のNVIDIA GPUまで含む構成になっている。

名前も少しややこしい。
AFM 3 Core、AFM 3 Core Advanced、AFM 3 Cloud、ADM 3 Cloud（Image）、AFM 3 Cloud Proの5種類があり、同じApple Intelligenceでも処理先と用途が違う。

五つのモデルが処理先で分かれる

Appleの説明では、AFM 3はGoogleとの協業で作られたモデルファミリーだ。
Apple Security Research側の記事では、GoogleのGemini familyの背後にある技術を使い、次世代のApple Foundation Modelsを構築した、と書いている。

公開された内訳はこうなる。

モデル	実行場所	役割
AFM 3 Core	端末上	次世代の3B denseモデル
AFM 3 Core Advanced	端末上	20B sparseモデル。音声、書き起こし、マルチモーダル寄り
AFM 3 Cloud	PCC	サーバー側の標準モデル
ADM 3 Cloud (Image)	PCC	画像生成、画像編集、Genmoji、Image Playground
AFM 3 Cloud Pro	Google Cloud上のPCC	agentic tool use、複雑な推論

Core、Core Advanced、Cloud、ADM 3 Cloud (Image) はApple silicon向けに最適化される。
Cloud ProだけはNVIDIA GPU向けで、Google Cloud上にPrivate Cloud Computeを拡張して動かす。

Appleの一次情報で確認できる2026年世代の公開名は、AFM 3 Core、AFM 3 Core Advanced、AFM 3 Cloud、ADM 3 Cloud (Image)、AFM 3 Cloud Proの5つ。
「Server」は2025年世代との比較やサーバー側モデルという役割の説明として出てくるが、2026年世代の名前としてはCloudが使われている。
また、AFM 3 Safetyという独立した公開モデル名は、記事時点の公開資料では確認できない。安全性はResponsible AI、safety taxonomy、言語別ガードレールモデル、人間によるレッドチーミングの話として説明されている。

全体の処理先を図にすると、こう分けて見たほうが誤解が少ない。

flowchart TD
    U["ユーザーの要求"] --> R{"OS / APIのルーティング"}
    R --> D["端末上<br/>AFM 3 Core / Core Advanced"]
    R --> A["PCC: Apple silicon<br/>AFM 3 Cloud / ADM 3 Cloud (Image)"]
    R --> G["PCC on Google Cloud<br/>AFM 3 Cloud Pro"]
    D --> D1["3B dense または<br/>20B sparseから1B-4Bを活性化"]
    A --> A1["標準サーバー推論<br/>画像生成・編集"]
    G --> G1["NVIDIA GPU<br/>agentic tool use / complex reasoning"]
    A -.-> P["PCCの約束<br/>stateless / no privileged runtime access<br/>verifiable transparency"]
    G -.-> P

去年までのApple Intelligenceは、オンデバイス処理とApple siliconサーバーのPCCが中心だった。
今回の発表で、Google CloudもPCCの処理先に入った。
ただしAppleは、ソフトウェアの制御、暗号署名、バイナリ公開、研究者向け検証の枠組みを残すとしている。

20Bオンデバイス疎モデルがGoogle Cloudへ置かれたわけではない。
AFM 3 Core Advancedは端末側のモデルで、フルの重みをNANDに置き、リクエストに応じた一部をDRAMへ載せる設計。
一方、Google Cloud上のNVIDIA GPUはAFM 3 Cloud Proの実行基盤として出てくる。
つまり「端末に20Bを載せられないのでGoogle Cloudへ逃がす」という構図ではなく、オンデバイスの上限を引き上げる話と、最も重いサーバー推論をPCCとして拡張する話が両方出ている。

20Bを全部DRAMに置かない

AFM 3 Core Advancedの特徴的なところは、20Bパラメータというサイズを端末上で扱うために、全部をDRAMへ常駐させない設計にしている点だ。

通常のdense LLMなら、推論時に全重みをメモリへ載せる。
MoEでも、トークンごとに選ばれるエキスパートが変わるため、参照する重みを高速な場所へ置いておく。
Appleの設計では、モデル全体はNANDフラッシュに置き、プロンプト処理の段階で固定のエキスパート集合を選んでDRAMへ読み込む。
生成中にも定期的に選び直すが、トークンごとにNANDから重みを入れ替える設計ではない。

Appleはこの仕組みをInstruction-Following Pruning（IFP）に基づく疎活性化アーキテクチャとして説明している。
Core Advancedは20B全体を持つが、リクエストに応じて1Bから4Bパラメータだけを活性化する。
常時稼働の共有エキスパートと、入力依存で選ばれるルーテッドエキスパートを組み合わせ、DRAMに載る部分を抑える。

手元のMacで巨大モデルを動かす話だと、以前 LFM2.5 1.2B JPをM1 Max 64GBで試したときは、モデルサイズが小さくてメモリでは詰まらなかった。
AFM 3 Core Advancedは逆で、端末上に20B級を置くために、重みの置き場所と読み込み方を設計している。
ローカルLLMでよく見る「量子化して全部メモリに載せる」とはかなり違う。

graph TD
    A["ユーザー入力"] --> B["軽量denseブロック"]
    B --> C["プロンプト単位で<br/>エキスパート選択"]
    C --> D["NAND上の20B重み"]
    D --> E["選ばれた重みを<br/>DRAMへ読み込み"]
    E --> F["共有エキスパートと結合"]
    F --> G["1Bから4B相当で推論"]
    G --> H["生成中に必要なら<br/>エキスパート再選択"]

この方式は、スマホやMacのストレージ帯域を推論資源として使う方向に近い。
ただしAppleは、NAND帯域がトークン単位の入れ替えには遅すぎると明記している。
プロンプト単位で選んで、生成中の入れ替え頻度を抑えるところでレイテンシを削っている。

Cloud ProだけGoogle CloudとNVIDIA GPUに出る

AFM 3 Cloud Proは、agentic tool useと複雑な推論向けの最上位サーバーモデルとして出ている。
ここだけApple siliconではなく、Google Cloud上のNVIDIA GPUで動く。

Apple Security Researchの記事では、PCC on Google Cloudの実装要素として、NVIDIA Confidential Computing、Intel TDX、Google Titan chipを挙げている。
PCCの要求も列挙している。ステートレスな処理、強制可能な保証、特権ランタイムアクセスの排除、個別標的化の不可（non-targetability）、検証可能な透明性の5つだ。

Appleは「Google Cloudを使う」だけではなく、PCCの検証可能性をGoogle Cloud側へ持ち込もうとしている。
PCC fleetに入るGoogle Cloudハードウェアは暗号的に検証できる追記専用台帳（append-only ledger）で管理する、とAppleは説明する。
ユーザー端末はAppleが暗号的に承認したPCCソフトウェアだけを信頼する構成だ。
バイナリ公開、研究者向けツール、Security Bounty Program経由の研究モードノードも予定に入った。

一方で、AppleはPCC on Google Cloudがまだ完全実装ではなく、夏のプレビュー期間中に保護を段階的に足すとも書いている。
Cloud Proの推論品質とPCCの検証手段、どちらもプレビュー期間中の公開待ちになる。

Googleという名前が三つの文脈で出る

今回の発表はGoogleの名前が何度も出るので、同じ話に見えやすい。
しかし一次情報を読む限り、少なくとも三つの文脈に分けたほうがよい。

文脈	何がGoogleか	記事時点で言えること
AFM 3の開発協業	Gemini familyの背後にある技術	AppleはAFM 3をGoogleと共同で作ったと説明している。ただしユーザーの推論先がGeminiそのものだとは書いていない。
PCCの実行基盤	Google Cloud上のNVIDIA GPU	AFM 3 Cloud Proのために、PCCをGoogle Cloudへ拡張する。AppleはPCCソフトウェアの制御と端末側の暗号的な承認を維持すると説明している。
開発者向けAPI	Firebase Apple SDK経由のGemini	Foundation Models frameworkのLanguageModel protocolに、GoogleがGeminiを接続する。これはApple Foundation Modelsとは別のクラウドモデル提供経路。

この三つを混ぜると、「Apple Intelligence全体がGeminiを呼ぶ」「20BモデルがGoogle Cloudで動く」「PCCならすべてApple silicon」というような読み違いになる。
少なくとも公開情報では、Cloud ProのGoogle Cloud実行、Core Advancedのオンデバイス実行、Geminiの開発者向け接続は別の話だ。

画像モデルはAFMではなくADM 3 Cloud

画像生成と編集はAFM 3 Cloudではなく、ADM 3 Cloud (Image) という別名で出ている。
Image Playground、Genmoji、PhotosのSpatial Reframing、タッチ操作による編集、パーソナライズに使われる。

Appleの説明では、ADM 3 Cloud (Image) は画像生成、編集、Genmojiをネイティブに扱い、下流の編集体験には専用アダプタを使う。
アスペクト比や解像度の違いにも対応する。
2025年のImage Playgroundは用途が限られていたが、今回の説明では写真編集や実用的な生成が中心になっている。

Google側でも、Apple開発者向けにGeminiをFoundation Models frameworkから呼べるようにする発表が出ている。
最近の Gemma 4 12B Unifiedの記事では、Googleが小型・統合型のマルチモーダル設計を進めている話を書いた。
Apple側のADM 3 Cloud (Image) はローカル配布モデルではなく、OS標準の画像生成APIを使うと、裏側の画像モデルが何かは開発者のコードからは分からない。

Foundation Models frameworkが単一APIに近づく

WWDC26のDeveloper Guideでは、Foundation Models frameworkがApple Foundation Modelsだけでなく、Claude、Gemini、その他のLanguageModel protocol準拠プロバイダも扱えると説明されている。
オンデバイスのAppleモデル、Private Cloud Compute上のAppleモデル、クラウドの外部モデルを同じAPI面に寄せる形だ。

Googleの発表では、iOS 27、macOS 27、iPadOS 27、visionOS 27、watchOS 27から、Firebase Apple SDK経由でGeminiをFoundation Models frameworkに接続できる。
Firebase AI LogicとFirebase App Checkを使い、アプリ側で専用バックエンドを持たずにGeminiを呼ぶ構成も用意される。

Apple Developer Guideには、App Store Small Business Programに入っていて、アプリの初回ダウンロードが累計200万未満なら、PCC上の次世代Apple Foundation ModelsをクラウドAPIコストなしで使える、とある。
この条件がそのまま本番運用にどこまで残るかは未確定だが、小規模アプリがサーバー費用なしでAppleのPCCモデルを試せるなら、サーバーAPI利用の初期費用が下がる。

AppleのPCCドキュメントでは、開発者が使う型は PrivateCloudComputeLanguageModel として説明されている。
オンデバイスの SystemLanguageModel はオフラインで動き、コンテキストは4K。
PCC側はネットワーク必須で日次利用上限があり、コンテキストは32K、reasoning levelはlight、moderate、deepの三段階。
APIとしては「AFM 3 Cloud Proを直接選ぶ」というより、PCCモデルを選び、必要ならreasoning levelを上げる説明になっている。
Cloud、Cloud Pro、ADM 3 Cloud (Image) の内部ルーティングや、どの機能でCloud Proへ上がるかは、記事時点の公開ドキュメントだけでは読み切れない。

App Intents側も同時に広がっている。
Siri AI、Spotlightのセマンティックインデックス、画面上の要素を参照するView Annotations APIも同じAPI群で扱う。
モデルそのものよりも、アプリのデータと操作をどれだけSiriやApple Intelligenceへ渡せるかが実装量を決める。

Safetyはモデル名より運用の話

安全性について、公開資料では独立したAFM 3 Safetyモデルは出てこない。
モデルファミリー全体にかかる分類、アラインメント、ガードレールとして構成されている。
AppleはResponsible AIの説明で、safety taxonomy、multilingual post-training alignment、言語別ガードレールモデル、対応ロケールのネイティブスピーカーを交えたレッドチーミングを挙げている。

Foundation Models framework側でも、生成失敗やガードレール違反をアプリがどう扱うかは実装上の論点になる。
特にPCCを使う場合は、ネットワーク失敗、日次上限、端末非対応、Apple Intelligence無効化といった通常のAPIエラーも重なる。
モデル性能だけでなく、「ガードレールで止まったときにアプリがどう戻るか」まで実装に含まれる。

まだ技術レポート待ちの部分

Appleは、2026年夏の後半に技術レポートと更新された評価を出すとしている。
現時点で公開されている評価は、Appleの内部人間評価が中心だ。

AFM 3 Coreは2025年のCoreモデルに対し、一般テキストで45.6%対23.3%の選好率を出した。
AFM 3 Cloudは2025年のServerモデルに対し、64.7%対8.7%の選好率としている。
Cloud ProはCloudより、overall response satisfactionでテキスト約10%、画像理解約14%の相対改善。
TTSではCore Advancedが既存production TTSのMOS 3.87に対して4.15、会話調では3.82に対して4.24だった。

ただ、外部ベンチ、モデルカード相当の詳細、モデル別のコンテキスト長、API制約、端末ごとの対応範囲はまだ薄い。
特にCore Advancedは「最も高性能なApple siliconシステムで解放される」と書かれているだけで、どのiPhone、iPad、Macで使えるかは記事時点では読み切れない。
開発者側の差分は、モデル名よりも、どの実行先にルーティングされ、どのAPIで呼べて、どのデータが端末外へ出るかになる。