WWDC 2026で発表されたCore AI（CoreAIとも表記される）は、AppleがCore MLとは別に用意した、生成AI・大規模ニューラルモデル向けのオンデバイス実行基盤である。報道ではCore MLの後継と呼ばれることも多いが、Apple公式の整理では、Core MLは従来型の機械学習モデル向けにそのまま残り、LLMや生成AIモデルを端末に持ち込む新しい主経路としてCore AIが置かれている。ツリー系モデルや回帰といった定型的な推論は引き続きCore MLが担い、Core AIはそこに生成AIの実行を足す関係にある。
ローカルLLMをめぐる話題は、これまでNVIDIA GPUやOllama・llama.cppといった経路に集まりがちだった。一方でApple Siliconの統合メモリは、VRAM容量とは別の解き方を持つ。Core AIはその実行を担う層にあたる。ここではCore AIが何で、Foundation Modelsフレームワークの中でどう位置づき、MLXやApple Neural Engine（ANE）とどう役割を分けるのかを、ローカルでモデルを動かす観点から整理する。
Core AIとは何か
Core AIは、Apple Silicon向けにAIモデルを変換・最適化し、端末の上で動かすための実行基盤である。Appleはこれを、サーバー依存もトークン課金もなく端末内でモデルを動かす、Apple Silicon専用に作られた一連の技術と位置づけている。特定のモデル種別に限定されず、モデルサイズに合わせて動かせる汎用的な基盤として案内されている点が、LLM専用ランタイムとは異なる。対応はiOS 27 / macOS 27 / visionOS 27世代にあたり、Apple公式のCore AIページでは実行対象としてiPhone・iPad・Mac・Apple Vision Proが挙げられている。AI & Machine Learning全体ではApple Watchを含むプラットフォーム向けの機械学習基盤が案内されているため、watchOSでの扱いはCore AI単体ではなく、利用するフレームワークやバックエンドごとに確認する必要がある。
では、LLMとして動かすための処理はどこが担うのか。自己回帰的なトークン生成、KVキャッシュの管理、生成トークンのストリーミング出力、初回の遅延を抑えるprewarmといった要素は、Core AI単体の機能というより、後述するFoundation ModelsフレームワークのLanguageModelの仕組みを通じてアプリ側から扱う形になる。Appleの開発者セッション「Bring an LLM provider to the Foundation Models framework」（WWDC26 セッション339）では、ローカルモデルを効率よく動かしANEを活用する経路としてCore AIが説明されている。Core AIがモデルを動かす土台を提供し、その上でLLMとしての振る舞いをFoundation Modelsが整える、という分担と捉えるとわかりやすい。推論はANE・GPU・CPUに振り分けられ、Apple Siliconの統合メモリを前提にする。
これらの要素は、ローカルLLMを動かしてきた人には馴染みのある仕組みである。LLMの生成は、直前までの出力を手がかりに次の一トークンを選ぶ処理の繰り返しで進む。このとき過去の計算結果を保持しておく仕組みがKVキャッシュで、これがなければ一トークンごとに最初から計算し直すことになる。生成したトークンを最後まで待たずに順次返すストリーミングも、チャット用途では応答の体感を左右する。こうした処理は従来アプリ側で個別に組み立てる場面も多かったが、Foundation ModelsのLanguageModelを使えば共通の作法で扱える。OllamaやllamaがGGUFモデルに対してすでに提供してきた振る舞いが、Apple純正の経路でも揃ったと捉えると位置づけが見えやすい。
名称の表記は媒体によって「Core AI」と「CoreAI」が混在するが、APIの型名はCoreAILanguageModelのように一語で書かれる。本稿では原則として「Core AI」を用いる。繰り返しになるが、Core MLとCore AIは役割の異なる別々のフレームワークとして並存し、従来型のモデルはCore ML、生成AIや大規模モデルはCore AI、という住み分けになる。
Foundation Modelsフレームワークの中での位置づけ
Core AIを理解するうえで欠かせないのが、Foundation Modelsフレームワークと、その中心にあるLanguageModelプロトコルである。セッション339では、モデルを差し替えても呼び出し側のコードを変えずに済む理由として、どのモデルも同じプロトコルに従う点が挙げられている。System Language Model、Private Cloud Compute、Core AI、MLX、そしてコミュニティが用意するモデルが、いずれも同じ約束事の上に並ぶ。
つまりCore AIは単独のエンジンというより、複数ある実行経路（バックエンド）のひとつとして設計されている。アプリ側は共通のLanguageModelSessionを通じて応答を受け取り、裏でどのバックエンドが動くかを差し替えられる。事前の重い準備——重みの読み込みや接続の確立——はprewarm()で先に済ませ、最初の応答が遅くならないようにする、という作法も示されている。
| バックエンド | 実行場所 | 主な役割 |
|---|---|---|
| System Language Model | 端末内蔵 | OS標準のオンデバイスモデル。指示追従と画像入力が改善 |
| Private Cloud Compute | Appleのサーバー | より長い文脈や推論を要する処理（32Kトークン文脈） |
| Core AI | 端末ローカル | 自前のモデルをANE・GPUで実行し、アプリにバンドル |
| MLX | 端末ローカル | Hugging FaceのMLX-communityにあるオープンモデルを実行 |
| コミュニティ | 提供元のクラウド経由 | ClaudeやGeminiなど（各社サーバー・規約に依存）。提供は順次予定 |
この並びで注意したいのは、フレームワークを使うこと自体が「すべて端末内で完結する」を意味しないことである。Private Cloud ComputeはAppleのサーバー側で動き、コミュニティ枠のClaudeやGeminiは各社のクラウドを経由しうる。端末内で閉じるのはSystem Language Model・Core AI・MLXの経路であり、どのバックエンドを選ぶかでデータの行き先は変わる。ローカル実行を目的にするなら、Core AIかMLXを明示的に選ぶことになる。
Core AIとMLXの役割分担
端末内で動く二つの経路、Core AIとMLXは、扱うモデルの出どころで住み分けている。セッション339の言い方を借りれば、自前のモデルを動かしたいならCore AIにリソースの場所を指す、最新のオープンソースモデルを試したいならモデルIDを渡してフレームワークに任せる、という分担になる。
Core AIは、変換・最適化した自前モデルをアプリに同梱して動かす経路にあたる。コードのうえではCoreAILanguageModel(resourcesAt:)のようにモデルの場所を指定する。ANEを使える点が特徴で、消費電力や常時性が問われるアプリ内蔵の用途と相性がよい。
MLXは、Hugging FaceのMLX-communityで配布されている多数のオープンモデルを、モデルIDの指定だけで呼び出す経路である。MLXLanguageModel(modelID:)の形でモデルを指す。OllamaやllamaなどでおなじみのオープンウェイトをApple Silicon向けに動かしたい場合は、この経路が窓口になる。実際にApple Silicon機でオープンモデルを動かした速度感は、MacBook Air M5でローカルLLMを21モデル比較した実測が参考になる。
MLX-communityには、主要なオープンモデルがApple Silicon向けに変換されて多数置かれている。OllamaがGGUFという量子化形式を中心に据えるのに対し、MLXはMLXフレームワーク向けの形式でモデルを配布する点が異なる。同じモデル名でも、動かす基盤に合わせて別々の形式が用意されていると考えるとよい。Core AIとMLXは対立するものではなく、自前モデルとオープンモデルという入り口の違いとして併存する。手元に変換済みの独自モデルがあるならCore AI、出回っているオープンモデルをそのまま試したいならMLX、という選び方になる。
性能の実際 — 公開ベンチが示すもの
Core AIがMLXに対してどれだけ速いのかは、Appleの公式数値ではなく、第三者による計測がいくつか出ている。ここではApple Silicon向けのローカルLLMベンチを公開しているjohn-rocky氏の計測（apple-silicon-llm-bench）を参照する。これは個人が再現可能な手順で測ったもので、Appleの保証値ではない点を前置きしておく。計測条件はデバイスや表ごとに異なり、M4 Mac（macOS 27β）とiPhone 17 Proでは前提が別になっている。いずれもgreedy設定でのデコード速度を中心に見たもので、正確なプロンプト長や生成長・試行回数・ウォーム／コールドの別は同リポジトリのmethodologyとraw logsに依存する。ここでは特定の条件を断定せず、同リポジトリの表に掲載された値をそのまま引用する。
| モデル | Core AI（デコード） | MLX（デコード） | 差 |
|---|---|---|---|
| Qwen3-0.6B | 484 tok/s | 432 tok/s | +12% |
| Gemma3-4B-it | 141.5 tok/s | 136.3 tok/s | +4% |
| Qwen3-8B | 94.1 tok/s | 90.0 tok/s | +5% |
この表から読み取れるのは、8Bクラスのように実用域のモデルサイズでは、Core AIとMLXの差は数パーセント程度に収まるということである。実務的に体感が大きく変わる差ではない。一方で0.6Bのような小型モデルでは差が開く。同リポジトリのiPhone 17 Pro（A19 Pro）の計測（Macとは別条件）では、Qwen3-0.6BのデコードでCore AIのGPUパイプライン経路が181 tok/s、MLXのGPU経路が112 tok/sと、より大きな開きが出ている。ANE経路（静的形状）は49 tok/sで、経路によって性質が異なる。
もうひとつ見落とせないのが初回の遅さである。同ベンチでは、Core AIのGPUパイプライン経路がiPhone 17 Proで初回71 tok/s、定常181 tok/sと記録されている。初回はカーネルのコンパイルと、3段のパイプラインを満たすまでの立ち上がりがあるためで、二度目以降は定常値に乗る。常駐しないアプリで毎回起動コストが乗る使い方では、この初回コストが効いてくる。前述のprewarm()は、この立ち上がりをユーザーに見せないための仕掛けと位置づけられる。
これらはあくまで「生成速度」という測られた一面である。同じモデルでも出力の品質や安定性は別の軸であり、速いことがそのまま良い体験を意味するわけではない。数値はバックエンド選択の一材料として扱うのが妥当だろう。
ANEとGPU、推論をどこで動かすか
Apple Siliconには、GPUとは別にApple Neural Engine（ANE）と呼ばれる専用の演算ユニットが載っている。こうしたAI処理専用ユニットの位置づけはNPUとCPU・GPUの違いで整理したとおりで、ANEもその一種にあたる。Core AIはGPUとANEの両方を使えるが、同じモデルでも経路によって速度と消費電力の性質が変わる。前掲のiPhone 17 Proの計測では、Qwen3-0.6BでGPUパイプライン経路が181 tok/s、ANE経路が49 tok/sと、生成速度の面ではGPUが上回っていた。
では速いGPUを常に選べばよいかというと、そう単純でもない。ANEは低い消費電力で動くことを得意とし、バッテリーや発熱が制約になる端末で、軽いモデルを常時動かすような用途に向く。一方GPUは、より大きなモデルや高い生成速度を求める場面で力を発揮する。ANE経路は静的な形状を前提にするなど、扱えるモデルや条件にも違いがある。Core AIが両方の経路を持つのは、用途に応じてこの性質を選び分けられるようにするためと見られる。
この使い分けは、デスクトップのNVIDIA GPUで動かす運用にはあまりない観点である。据え置きのGPUでローカルLLMを動かす場合、計算はほぼGPUに集約され、消費電力と速度のバランスをユニット単位で選ぶ発想は薄い。スマートフォンやタブレットまで含めて推論の動かし先を最適化する点は、モバイルとデスクトップを同じアーキテクチャで貫くApple Siliconの特徴である。AI処理をNPU・GPU・CPUのどれに振り分けるかという考え方そのものは、AMD Ryzen AIでの適材適所などWindows側のプロセッサにも共通する。
RTX・Ollama勢から見たApple Silicon
NVIDIA GPUとOllamaでローカルLLMを動かす環境から見ると、Core AIとMLXは直接の置き換えにはならない。設計の前提が異なるためである。最も大きな違いは、対応するハードウェアと可搬性にある。
| 観点 | Core AI / MLX | Ollama / llama.cpp |
|---|---|---|
| 対応プラットフォーム | Apple Silicon専用（Mac・iPhone・iPad） | Windows・Linux・macOSを横断、NVIDIA/AMD/Apple |
| 主な対象モデル | Core AI=変換した自前モデル／MLX=MLX-community | GGUF形式の量子化モデルを広くカバー |
| 配布と統合 | アプリにバンドル、OSのフレームワーク | CLIやローカルサーバー、モデルファイルを配置 |
| メモリの考え方 | 統合メモリをCPU・GPU・ANEで共有 | GPUのVRAMが中心（不足分はRAMへオフロード） |
| 可搬性 | Appleのエコシステム内 | クロスプラットフォーム |
統合メモリは、容量の面でApple Siliconに独特の強みを与える。NVIDIAのコンシューマーGPUでは、たとえば16GBのVRAMに載るかどうかがモデル選択の壁になりやすい。これに対しApple Siliconは、CPUとGPUとANEが同じメモリ領域を共有するため、搭載メモリの大きい機種ほど大型モデルを丸ごと載せやすい。VRAMという独立した枠を前提にしない点が、容量面での解き方の違いになる。
ただし、容量だけで速度が決まるわけではない。LLMの生成速度は、モデルの重みをメモリからどれだけ速く読み出せるか、つまりメモリ帯域に強く左右される。Apple Siliconの上位チップは広いメモリ帯域を持つことで知られ、これが大型モデルでも実用的な速度を保つ支えになっている。逆に、エントリー向けのチップでは帯域が抑えられ、大きなモデルを載せられても生成が重くなることがある。容量と帯域は別の壁であり、どちらか一方だけを見て機種を判断しない方がよい。この点はGPUのVRAM容量とメモリ帯域の関係と同じ構図で、ハードウェアが変わっても効いてくる。Apple Silicon機での容量と速度の実際は、M5 MacBook Airの総合レビューやM5 ProでのQwen実測比較に具体的な数字がある。
一方で、Core AIとMLXはApple Silicon専用であり、ここがOllamaやllama.cppとの決定的な分岐になる。Ollamaの強みは、WindowsでもLinuxでもMacでも、NVIDIAでもAMDでもAppleでも、同じモデルファイルを持ち運んで動かせる可搬性にある。Core AIはその可搬性を志向していない。Apple Siliconを使う前提が固まっているなら有力な実行基盤だが、複数の環境を横断したい用途では引き続きクロスプラットフォームのツールが向く。両者は競合というより、選んだハードウェアによって入り口が分かれる関係にある。
2026年6月時点での注意点
Core AIをめぐる情報は、まだ動きの速い段階にある。以下は2026年6月時点のβ前提の整理で、正式版で変わりうる項目として挙げる。
- β段階である。 上で挙げた速度は、macOS 27βで測られた公開ベンチの値である。正式版に向けて最適化が進めば数値は変わりうる。特定の数字を固定された性能として扱わない方がよい。
- 対応はiOS 27 / macOS 27世代から。 Core AIはこの世代のOSに乗り、実行対象はiPhone・iPad・Mac・Apple Vision Proとされている。なおFoundation Modelsフレームワーク自体はwatchOS 27にも対応し、Private Cloud Compute経由でのモデル利用が可能になっている（端末内で動かすCore AIとは経路が別）。前世代の環境では、まずCore MLの互換経路が現役という位置づけになる。
- コミュニティ枠は順次提供（2026年6月時点で時期未定）。 ClaudeやGeminiといった外部モデルをLanguageModelプロトコル経由で扱う枠組みは示されており、AnthropicやGoogleが各社のSwiftパッケージとして出す形が予告されている。これらは各社のクラウド経由となり、データの送信先は提供元の規約に依存する。
- 「ローカル＝外部に出ない」は経路次第。 Core AIとMLXの経路は端末内で動く。ただしFoundation Modelsフレームワークにはサーバー側のPrivate Cloud Computeやクラウド経由のコミュニティモデルも含まれる。データを端末内に留めたいなら、どのバックエンドを選ぶかを明示する必要がある。
まとめ
Core AIは、Core MLとは別に、LLMや生成AIモデルのオンデバイス実行を担う推論基盤である。単体のエンジンというより、Foundation Modelsフレームワークの中でLanguageModelプロトコルに従うバックエンドのひとつとして設計され、自前モデルはCore AI、オープンモデルはMLXという入り口の住み分けを持つ。公開ベンチの範囲では、8Bクラスでのデコード速度はMLXと数パーセント差にとどまり、差が目立つのは小型モデルやGPUパイプライン経路、そして初回の立ち上がりコストである。
Apple Siliconの統合メモリは容量面で独特の強みを持つ一方、Core AIとMLXはApple専用であり、Ollamaやllamaのようなクロスプラットフォームのツールとは別のレイヤーにある。どちらを使うかは、横断したい環境があるか、Apple Siliconに寄せるかという、ハードウェア選択の延長で決まる。Core AIはその選択肢が増えたことを意味する。
Core AIについてよくある疑問
Core MLは廃止になるのか
廃止の案内は出ていない。Apple公式の整理では、Core MLは画像分類やツリー系モデル、回帰といった従来型の機械学習タスク向けにそのまま残り、Core AIはLLMや生成AIといった大規模モデル向けの新しい経路として加わる。両者は役割の異なる別々のフレームワークとして並存する関係で、既存のCore ML資産がすぐに動かなくなるわけではない。新規に生成AIを組み込むならCore AI、従来型のモデルを使い続けるならCore ML、という選び分けになる。
GGUF形式のモデルはそのまま使えるのか
OllamaやllamaでおなじみのGGUF形式を、Core AIやMLXがそのまま読み込むわけではない。MLXはMLXフレームワーク向けの形式、Core AIは変換・最適化した自前モデルを前提にする。同じモデルでも、動かす基盤に合わせた形式を用意する必要がある。Hugging FaceのMLX-communityには主要なオープンモデルがApple Silicon向けに変換されて置かれているため、多くの場合はそこから取得する形になる。
Apple WatchやwatchOSで使えるのか
Core AIが実行対象として挙げているのはiPhone・iPad・Mac・Apple Vision Proで、Apple Watch単体での端末内実行は公式の対象に含まれていない。ただしFoundation Modelsフレームワーク自体はwatchOS 27に対応し、Private Cloud Compute経由でのモデル利用が可能になっている。「watchOSでまったく使えない」わけではなく、端末内で動かすCore AIの経路と、サーバー側のPrivate Cloud Computeの経路を区別して考える必要がある。
WindowsやAI PCのユーザーに関係あるのか
Core AIとMLXはApple Silicon専用で、WindowsやNVIDIA GPUの環境で直接動くものではない。クロスプラットフォームでモデルを動かしたいなら、引き続きOllamaやllama.cppが向く。一方で、AI処理をどの演算ユニットに振り分けるかという考え方は、プラットフォームをまたいで共通する。Windows側でもNPU搭載のAIノートPCやCopilot+ PC、Dell ProのAIノートがオンデバイスAIを進めており、Apple Silicon側の動向はローカルAI実行という同じ土俵の選択肢として押さえておく意味がある。
参考資料
- Apple Developer — Core AI
- Apple Developer — Meet Core AI（WWDC26 セッション324）
- Apple Developer — Integrate on-device AI models into your app using Core AI（WWDC26 セッション326）
- Apple Developer — Bring an LLM provider to the Foundation Models framework（WWDC26 セッション339）
- john-rocky / apple-silicon-llm-bench（Apple Silicon向けローカルLLMベンチマーク）
