Core AI：Apple silicon上でモデルを実行する

AppleのオンデバイスAIスタックには、これまで欠けていた一段がありました。Foundation Modelsは、密閉された無料のシステムLLMを提供します。Core MLは、変換済みの固定モデルを実行し、ハードウェアに関する判断はコンバーターが代わりに行ってくれます。MLXは、アプリに組み込む配列フレームワークと、自分で選ぶモデルを提供します。iOS 27は、これら3つすべての下に一段を追加しました。それがCore AIです。その1行で言い表せる概要は「Apple silicon上で、アプリ内のAIモデルを実行する」というものです。¹ これはモデル実行のための面であり、上位レイヤーのデフォルトに従う代わりに、特殊化（specialization）・キャッシュ・推論スケジューリングを自分で制御したいときに手を伸ばす場所です。

セッション324でAppleは、Core AIをオンデバイスのApple Intelligenceを支えるのと同じ推論フレームワークとして位置づけ、それを自分のアプリのインテリジェンスのために開放したと説明しています。¹⁵

この位置づけが重要なのは、Core AIが、ほとんどのアプリが使うべき抽象化の下に位置するからです。Appleはこれを、Apple siliconを念頭に置いて設計されたフレームワークだと説明しています。CPU・GPU・Neural Engineをまたいで最新のモデルアーキテクチャと推論技術をアプリで使えるようにし、一般的なタスクをシンプルにこなせるSwift APIを備えつつ、必要に応じてモデルの特殊化・キャッシュ・推論パフォーマンスをより細かく制御できるようにします。¹ この記事の主張はこうです。実行したいモデルがあり、それがどこでどのように実行されるかを明示的に制御したいときにCore AIへ手を伸ばし、そうでないときはCore MLやFoundation Modelsにとどまる、ということです。このフレームワークは、デフォルトの好みではなく、特定のニーズに応えるものです。

TL;DR / 要点

• Core AIは、未特殊化のAIModelAsset（モデルの構造やメタデータを安価に調べる）と、特殊化済みのAIModel（デバイス上で推論を実行する）を分離しており、AIModelCacheがデバイス固有のアーティファクトを保持し、AssetErrorがアセット操作の失敗を表します。²³⁶⁴
• 推論データはNDArrayを通って流れます。これはスカラー値の多次元配列であり、形状・スカラー型・メモリレイアウトの期待値を定めるNDArrayDescriptorによって記述されます。⁵⁷
• ハードウェアは、SpecializationOptionsを介してComputeUnitKind（CPU、GPU、またはNeural Engine）で指定し、非同期処理はComputeStreamにスケジュールします。⁸⁹¹⁰
• InferenceFunctionは重みとバッファを所有し、推論を実行します。InferenceFunctionDescriptorを使えば、その入力・出力・状態のシグネチャを先に調べられます。この関数はSendableなので、並行して実行できます。¹⁴¹³
• モデルはディスク上の.aimodelバンドルから読み込まれ、Core AIはフレームワークとあわせて準備・変換・デバッグ用のツールを提供します。特殊化とスケジューリングを明示的に制御する必要があるときはCore AIへ、そうでなければCore MLやFoundation Modelsにとどまりましょう。²¹

設計全体を貫く2つの言葉：アセットとモデル

Core AIがまず腑に落としてほしいと求めるのは、ディスク上のモデルと、推論を実行するモデルは別のオブジェクトであり、一方を他方へ特殊化するのはコストが高い、ということです。フレームワークはそれぞれに型を与えています。

AIModelAssetとは「未特殊化のソースモデルアセット」です。² ディスク上の.aimodelバンドルのURLから生成し、特殊化のコストを払わずにモデルを調べるために使います。Appleはこの分離が存在する理由を明確に述べています。モデルアセットを使えば、コストの高い処理である特殊化を行わずに、モデルの情報を照会できるのです。アセットからは、関数のシグネチャ、入力・出力の記述、計算型と格納型、そして作者が付与したメタデータを読み取れます。できないのは推論の実行です。アセットはあくまで調査専用です。²

// Call shape is illustrative; confirm the exact initializer against Apple's docs.
let asset = try AIModelAsset(url: bundleURL)   // an .aimodel bundle on disk
// Inspect signatures, input/output descriptions, compute and storage types,
// and author-provided metadata — without specializing.

AIModelはもう一方の半分であり、「デバイス上で推論を実行するための特殊化済みモデル」です。³ AIModelは、現在のデバイスのハードウェア向けに最適化された特殊化済みの.aimodelアセットを表し、アセットをディスクから読み込むことで生成します。³ アセットはこのモデルは何か？に答え、モデルはここで、今すぐ実行せよに答えます。両者のあいだのコストの非対称性こそが、APIがどちらを求めているのかを明示させる理由です。候補となるモデルを100個調べて1つを選ぶのは、アセットだけを作るなら安価ですが、調べるたびに特殊化していたら破滅的なコストになるでしょう。

特殊化はデバイス固有のアーティファクトを生み出し、そのアーティファクトには住み処があります。それがAIModelCache、すなわち「推論用に特殊化済みモデルアーティファクトを格納するキャッシュ」です。⁶ このキャッシュは、モデルが推論関数を実行するために読み込む、最適化されたデバイス固有のアーティファクトを保持します。Appleは、各キャッシュエントリが特定の.aimodelまたは.aimodelcと特殊化の組み合わせから形成された特殊化済みアセットを含む、と述べています。⁶ 実用的に読み解けば、特殊化は起動のたびに繰り返したいものではない、ということです。キャッシュは、コストの高いステップを一度だけ実行し、その後は安価なステップ（キャッシュ済みアーティファクトの読み込み）で済ませるための仕組みなのです。

アセット操作がうまくいかないとき（バンドルが見つからない、.aimodelが壊れている、ファイルが読めないなど）、Core AIはAssetError、すなわち「モデルアセット操作中に発生するエラー」を返します。⁴ 任意のI/O境界と同じように扱いましょう。アセットはディスク上に存在し、ディスク操作は失敗し、型システムがcatchをどこに置けばよいかをきっちり教えてくれます。

テンソル：NDArrayとそのディスクリプター

推論は数値を入れて数値を出します。Core AIにおけるその数値のコンテナがNDArray、すなわち「モデル推論に使われるスカラー値の多次元配列」です。⁵ NumPyのndarray、MLXの配列、MLMultiArrayを扱ったことがあれば、この発想の形にはなじみがあるはずです。定義されたレイアウトを持つn次元のスカラーのブロックです。NDArrayは、自身の形状とその他の記述的なプロパティによって定義されるレイアウトでデータを格納します。⁵

対になる型がNDArrayDescriptor、すなわち「配列の形状・スカラー型・メモリレイアウトの期待値の記述」です。⁷ ディスクリプターは契約です。Appleの説明は率直です。ディスクリプターは、推論関数に渡す配列値に対する期待値を含み、その多くは厳密です。ディスクリプターがスカラー型.float32を指定するなら、渡す配列は.float32を使わなければなりません。⁷ 関数が求める形状や型を推測するのではなく、その関数のディスクリプターに尋ね、それに従うのです。

// Call shape is illustrative; confirm exact property/method names against Apple's docs.
let inputDescriptor = function.descriptor.inputs.first!   // an NDArrayDescriptor
// The descriptor fixes shape, scalar type, and layout; the array you build
// must satisfy those expectations (e.g. .float32 means .float32).

ここでの設計上の教訓は、アセットとモデルの分離と同じ形をしています。Core AIは一貫して、コストの高い値オブジェクトの前に、安価な記述オブジェクトを置きます。先に割り当てて推論時に不一致に気づくのではなく、ディスクリプターを読んで契約を学び、それを満たすNDArrayを割り当てるのです。画像入力に特化して、Core AIはImageDescriptor、すなわち「画像の寸法とピクセルフォーマットの記述」も定義しており、ビジョンモデルのピクセル入力も同じく「ディスクリプター優先」の扱いを受けます。¹¹

推論をどこで実行するかを選ぶ

Apple siliconには計算を行える場所が3つあります。CPU、GPU、そしてNeural Engineです。Core MLだけでなくCore AIが存在する理由は、Core AIではそのうちどれをフレームワークの対象にするかを、推測させるのではなく明示的に指定できるからです。

ComputeUnitKindとは「モデル推論に利用できるハードウェアコンピュートユニットの種類」です。⁸ コンピュートユニットの種類を特殊化オプションとあわせて使い、モデルを特殊化する際にフレームワークがどのハードウェアを対象とするかを制御します。デフォルトでは、特殊化はデバイス上で利用可能なすべてのコンピュートユニットを使います。⁸ このデフォルトはほとんどの作業で正しい答えであり、それが要点です。デフォルトを上書きするのは、理由があるとき（レイテンシに敏感な経路をNeural Engineに固定したい、デバッグのパスをCPUに強制したい、他のGPU処理と調整しているGPU負荷の高いパイプラインがある、といったとき）だけです。

その意図はSpecializationOptionsを通じて渡します。これは特殊化時に行われた選択を運ぶ構造体です。⁹ 特殊化は先ほどのコストの高いステップであり、SpecializationOptionsはコンピュートユニットの指定やその他の特殊化に関する判断が置かれる場所です。キャッシュエントリは特定のアセットと特殊化の組み合わせをキーとするため、オプションを変えると返ってくるキャッシュ済みアーティファクトも変わり、これが指定とキャッシュの間のループを閉じます。⁶

スケジューリングは「どう実行するか」のもう一つの軸であり、Core AIはこれをComputeStream、すなわち「非同期に実行される処理のストリーム」としてモデル化します。¹⁰ コンピュートストリームは、処理をストリームにエンコードするために渡すものであり、Appleは、同じストリームにエンコードされた複数の推論は、読み書きされる値に基づいて必要に応じて直列化される、と述べています。¹⁰ ここから2つの含意が得られます。第一に、ストリームは順序付けのプリミティブです。依存し合う推論を1つのストリームにエンコードすれば、Core AIがデータ依存に基づいて順序を整えます。第二に、処理はデフォルトで非同期なので、Neural EngineやGPUが処理を行っている間、ストリームは呼び出しスレッドを解放しておくための手段でもあります。

推論関数：実際に実行されるもの

読み込んだ.aimodelは、単一の呼び出し可能な対象ではありません。モデルは名前付きの関数（エンコーダー、デコーダー、ビジョンタワー、prefillとdecodeのステップなど）を公開しており、Core AIにおける実行の単位がInferenceFunction、すなわち「入力値に対して推論を実行し、出力値を生成する関数」です。¹⁴

呼び出す前に、まず調べます。InferenceFunctionDescriptorは「推論関数のシグネチャの記述」であり、推論を実行する前に、関数の入力・出力・状態の名前と型を調べるためにディスクリプターを使います。¹³ 立ち止まって注目すべき詳細が状態（state）です。状態を持つ関数は、状態を持つモデル（たとえばtransformerのdecodeループにおけるKVキャッシュ）が呼び出しの間で情報を保持する仕組みであり、ディスクリプターは、その関数を駆動しようとする前に、状態を持つかどうかを教えてくれます。

InferenceFunctionそのものは、モデルの重みや中間バッファを含め、推論に必要なリソースを所有します。モデルから関数を読み込み、run(inputs:states:outputViews:)を呼び出して推論を実行します。¹⁴ runのシグネチャはApple自身の説明の中で名指しされているため、1回の呼び出しに必要な3つの要素は明示されています。入力値、状態値、そして書き込んでほしい出力ビューです。

// run(inputs:states:outputViews:) is named in Apple's docs; surrounding
// loading/value-construction shapes are illustrative — confirm against Apple's docs.
let function: InferenceFunction = /* load from an AIModel */
let outputs = try function.run(
    inputs: inputValues,        // InferenceValue per input
    states: stateValues,        // any stateful values the function declares
    outputViews: outputViews
)

この関数を負荷下でも扱いやすくする2つの性質があります。Sendableなので複数のタスクから並行して実行でき、Appleは、その並行性をサポートするために必要に応じて追加の中間バッファを自動的に割り当てる、と述べています。¹⁴ 共有のスクラッチ領域を保護するためにロックの後ろで呼び出しを直列化する必要はありません。関数は並行する呼び出し元ごとに自前のバッファを管理します。これは、単一の推論ハンドルが事実上シングルスレッドになるようなAPIとの、意味のある違いです。

runを流れる値はInferenceValueのインスタンス、すなわち「推論関数が入力として受け取る、あるいは出力として生成する値」です。¹² InferenceValueはNDArrayまたはピクセルバッファのいずれかをラップし、推論後にそのvalueプロパティを使って結果を取り出します。¹² このラッパーがあるからこそ、1つのrunシグネチャがオーバーロードを分けることなくテンソル入力と画像入力の両方を運べます。テキストモデルはNDArrayに裏打ちされた値を渡し、ビジョンモデルはピクセルバッファに裏打ちされた値を渡し、関数はどちらを期待しているかをディスクリプターを読んで判断します。

いつCore AIへ手を伸ばすか

Core AIで最も難しいのはAPIではありません。一段上のレイヤーではなく、そもそも自分がここにいるべきだと知ることです。正直な意思決定ツリーは次のとおりです。

• Foundation Models：Appleのシステムモデルがそのタスクをこなせる場合。要約、分類、抽出、書き換え、構造化出力はFoundation Modelsの領分であり、重みもメモリ予算も特殊化のステップも要しません。機能がそれに収まるなら、そこで止めましょう。システムモデルがすでにこなしていることをCore AIまで降りて再実装するのは、無駄な労力です。
• Core ML：変換済みの固定モデルがあり、ハードウェアと最適化の判断をコンバーターに任せたい場合。Core MLは、ロックダウンされた本番モデルに対して、厳しい電力とレイテンシの制約のもとでNeural Engineを対象とし、特殊化やスケジューリングについてあなたに何も求めません。コンピュートユニットの指定やコンピュートストリームについて考えたくないなら、それがCore MLにとどまるべき合図です。
• MLX：埋め込んで反復するための研究水準の配列フレームワークがほしい場合。自前のトレーニングループ、量子化されたオープンウェイトモデル、LoRAファインチューン、素早い実験などです。MLXは、重みとともに出荷するライブラリであり、システムのモデル実行面ではありません。柔軟性と反復速度で勝ります。
• Core AI：実行したいモデルがあり、フレームワークの明示的なハンドルがほしい場合。コミットする前に調べるAIModelAsset、コンピュートユニットを固定するSpecializationOptions、自分で管理するAIModelCache、スケジュールするComputeStream、そして並行して呼び出すInferenceFunctionです。上位レイヤーのデフォルトが邪魔になっていて、上書きすべきデフォルトを名指しできるとき、ここに手を伸ばします。

スタック全体を貫く一本の線はこうです。一段降りるごとに、デフォルトを手放してハンドルを得ます。Foundation Modelsはすべてを渡し、何も求めません。Core AIはレバーを渡し、どれを引くべきかを知ることを求めます。必要な特殊化・キャッシュ・スケジューリングの制御を名指しできないなら、まだCore AIは必要ありません。

新規の作業においてCore AIとCore MLの境界がどこにあるかを、WWDC 2026のラボでの発言が鮮明にしてくれます。WWDC 2026 Coding Intelligence, Machine Learning & AI Group Labのローカル文字起こし録音からの言い換えですが、パネルに参加したCore AIのエンジニアは、Appleはニューラルネットワークを扱うすべての人に今後Core AIへ移行することを求めており、Core MLは残るものの決定木のような従来型の機械学習に焦点を当て、新しいものはすべてCore AIへ向かう、と述べました。¹⁶ これは文書化された方針というより、フレームワークを作っている人々からの進行方向のシグナルとして読みましょう。新しいプロジェクトでニューラルネットワークに手を伸ばすなら、ラボはCore AIを土台にすべき面として位置づけました。

モデルはどうやってCore AIに届くのか

このフレームワークは、より大きなワークフローのうちランタイムにあたる半分です。Appleは、Core AIがフレームワークとあわせてモデルの準備・統合・デバッグ用の追加ツールを含むと述べています。Apple silicon向けにモデルを準備し、.aimodelフォーマットへ変換し、可視化と数値デバッグをサポートするコンパニオンアプリを使う、というものです。¹ ファクトシートにおけるこれらのツール名の記述は途中で切れているため、再構成を信じるのではなく、正確なツール名とその呼び出し方法はAppleのCore AIドキュメントで確認してください。¹ 検証できているのはパイプラインの形です。ソースモデルが準備され、.aimodelへ変換され、調査用にAIModelAssetとして読み込まれ、AIModelへ特殊化され、そのInferenceFunctionを通じて実行されます。そしてAIModelCacheが特殊化済みアーティファクトを保持し、コストの高いステップが一度だけ実行されるようにします。¹²³⁶¹⁴

FAQ

AppleのCore AIフレームワークとは何ですか？

Core AIは、Apple silicon上でAIモデルを実行するためのiOS 27の低レベルなフレームワークで、Appleは「Apple silicon上で、アプリ内のAIモデルを実行する」と要約しています。¹ CPU・GPU・Neural Engineをまたいでモデル推論を実行し、一般的なタスクをシンプルにこなせるSwift APIを備えつつ、必要に応じてモデルの特殊化・キャッシュ・推論パフォーマンスを制御できるようにします。¹ モデル実行の面として、Foundation ModelsとCore MLの下に位置します。

AIModelAssetとAIModelの違いは何ですか？

AIModelAssetは、ディスク上の.aimodelバンドルのURLから生成する未特殊化のソースアセットです。特殊化はコストが高く、アセットは推論を実行できないため、特殊化せずにモデルの関数シグネチャ、入力・出力の記述、計算型と格納型、メタデータを調べるために使います。² AIModelは、現在のデバイスのハードウェア向けに最適化され、実際に推論を実行する特殊化済みモデルで、アセットをディスクから読み込むことで生成します。³ この分離により、安価に調べ、コミットするときにだけ特殊化できます。

Core AIはどうやってCPU・GPU・Neural Engineを選びますか？

ハードウェアの指定はSpecializationOptionsを介してComputeUnitKindで制御します。コンピュートユニットの種類は推論に利用できるハードウェアコンピュートユニットの種類を表し、モデルを特殊化する際にフレームワークがどのハードウェアを対象とするかを制御するために使います。デフォルトでは、特殊化はデバイス上で利用可能なすべてのコンピュートユニットを使います。⁸⁹ デフォルトを上書きするのは、レイテンシに敏感な経路を1つのコンピュートユニットに固定するなど、特定の理由があるときだけです。

InferenceFunctionとは何で、どう実行しますか？

InferenceFunctionは、モデルの重みと中間バッファを所有しながら、入力値に対して推論を実行し、出力値を生成します。¹⁴ まずInferenceFunctionDescriptorを通じてそのシグネチャを調べます。これは関数の入力・出力・状態の名前と型を記述します。次にAIModelから関数を読み込み、run(inputs:states:outputViews:)を呼び出します。¹³¹⁴ この関数はSendableであり、並行性をサポートするために中間バッファを自動的に割り当てるため、複数のタスクが同時に実行できます。¹⁴

Core MLやFoundation Modelsの代わりにCore AIを使うべきですか？

システムモデルがそのタスクをこなせるときはFoundation Modelsを、変換済みの固定モデルがあり、ハードウェアと最適化の判断をコンバーターに任せたいときはCore MLを使いましょう。上位レイヤーが代わりに扱ってくれる特殊化（SpecializationOptions、ComputeUnitKind）、キャッシュ（AIModelCache）、スケジューリング（ComputeStream）を明示的に制御したいときに、Core AIへ手を伸ばします。⁸⁹⁶¹⁰ 必要な制御を名指しできないなら、一段上のレイヤーにとどまりましょう。

Apple Ecosystemクラスター全体は次のとおりです。自前のモデルとトレーニングループがほしいときに埋め込む配列フレームワークについてはApple Silicon上のMLXを、CPU/GPU/Neural Engineの共有を成り立たせるハードウェアの基盤についてはApple SiliconのTBDRとユニファイドメモリを、Core AIの上にある固定モデルのレイヤーについてはCore MLのオンデバイス推論を、そしてスタックの頂点にあるAppleの密閉されたシステムLLMについてはFoundation Modelsをご覧ください。ハブはApple Ecosystemシリーズにあります。AIエージェントを伴うiOSのより広い文脈については、iOS Agent Developmentガイドを参照してください。

参考文献