Core AI: Apple Silicon でモデルを実行する

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

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

この位置づけが重要なのは、Core AI が、ほとんどのアプリが使うべき抽象化の 下 にあるからです。Apple の説明によれば、Core AI は 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 バンドルから読み込みます。フレームワーク周辺のツールチェーンも、いまではドキュメント化されています。coreai-torch という Python パッケージが PyTorch モデルを変換し、coreai-build CLI が .aimodel をアーキテクチャごとの .aimodelc アセットへ事前コンパイルします。検査とプロファイリングは、Core AI Debugger アプリに加えて Xcode のデバッグゲージと Instruments のテンプレートがカバーします。¹⁷ 特殊化とスケジューリングを明示的に制御する必要があるときは Core AI を、そうでなければ Core ML か Foundation Models を選んでください。²¹

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

Core AI がまず理解を求めてくるのは、ディスク上のモデルと推論を実行するモデルは別のオブジェクトであり、前者を後者へ特殊化する処理は高コストだという点です。フレームワークはそれぞれに型を与えています。

AIModelAsset は「an unspecialized source model asset」（特殊化されていないソースモデルアセット）です。² ディスク上の .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 で、「a specialized model for running inference on a device」（デバイス上で推論を実行するための特殊化されたモデル）です。³ AIModel は、現在のデバイスのハードウェア向けに最適化された特殊化済みの .aimodel アセットを表し、ディスクからアセットを読み込むことで生成します。³ アセットが答えるのは これはどんなモデルか? であり、モデルが答えるのは ここで、いま実行する です。この2つのコスト差こそ、API がどちらを求めているのかを明示させる理由です。候補となるモデルを100個検査して1つ選ぶ作業は、アセットだけを作るなら安価に済みます。検査のたびに特殊化していたら、破滅的なコストになるでしょう。

特殊化はデバイス固有の成果物を生み、その成果物には置き場所があります。それが AIModelCache、すなわち「a cache that stores the specialized model artifacts for inference」（推論用に特殊化されたモデル成果物を保存するキャッシュ）です。⁶ このキャッシュは、モデルが推論関数を実行するために読み込む、最適化済みでデバイス固有の成果物を保持します。Apple は、各キャッシュエントリが特定の .aimodel または .aimodelc と特殊化の組み合わせから形成される特殊化済みアセットを含む、と説明しています。⁶ 実務的に読み解けば、特殊化は起動のたびに繰り返したい処理ではない、ということです。高コストな工程を一度だけにし、以降は安価な工程（キャッシュ済み成果物の読み込み）で済ませる ― そのための仕組みがキャッシュなのです。

アセット操作が失敗したとき（バンドルが見つからない、.aimodel が壊れている、ファイルが読めない）、Core AI は AssetError、「an error that occurs during model asset operations」（モデルアセット操作中に発生するエラー）を返します。⁴ 扱い方は、あらゆる I/O 境界と同じです。アセットはディスク上にあり、ディスク操作は失敗するもので、型システムが catch を置くべき場所を正確に教えてくれます。

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

推論は数値を入れて数値を出す処理であり、その数値を収める Core AI のコンテナが NDArray、「a multidimensional array of scalar values used for model inference」（モデル推論に使われるスカラー値の多次元配列）です。⁵ NumPy の ndarray、MLX の配列、あるいは MLMultiArray を扱った経験があれば、発想の形はおなじみでしょう。レイアウトが定義された n 次元のスカラーの塊です。NDArray は、形状とその他の記述的プロパティによって定義されたレイアウトでデータを保持します。⁵

対になる型が NDArrayDescriptor、「a description of an array’s shape, scalar type, and memory layout expectations」（配列の形状・スカラー型・メモリレイアウトへの期待の記述）です。⁷ ディスクリプタは契約です。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、「a description of an image’s dimensions and pixel format」（画像の寸法とピクセルフォーマットの記述）も定義しており、ビジョンモデルのピクセル入力にも同じディスクリプタ優先の扱いが適用されます。¹¹

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

Apple silicon には計算できる場所が3つあります。CPU、GPU、Neural Engine です。Core ML だけでなく Core AI が存在する理由は、フレームワークがどれを対象にするのかを推測に任せず、自分で指定できるからです。

ComputeUnitKind は「a type of hardware compute unit available for model inference」（モデル推論に利用できるハードウェア計算ユニットの種類）です。⁸ コンピュートユニットの種類は特殊化オプションと組み合わせて使い、モデルを特殊化する際にフレームワークがどのハードウェアを対象にするかを制御します。デフォルトでは、特殊化はデバイス上の利用可能なすべてのコンピュートユニットを使います。⁸ 大半の用途ではこのデフォルトが正解であり、そこが要点です。上書きするのは理由があるときだけ ― レイテンシに敏感な経路を Neural Engine に固定したいとき、デバッグのために CPU に強制したいとき、他の GPU 処理と協調させたい GPU 中心のパイプラインがあるとき、といった場合です。

その意図は SpecializationOptions を通じて渡します。これは特殊化時に行われた選択を運ぶ構造体です。⁹ 特殊化は先ほど述べた高コストな工程であり、コンピュートユニットの指定をはじめとする特殊化の判断はこの SpecializationOptions に集約されます。キャッシュエントリは特定のアセットと特殊化の組み合わせをキーとするため、オプションを変えれば返ってくるキャッシュ成果物も変わります。こうして、ハードウェア指定とキャッシュがひと続きの輪になるのです。⁶

「どう実行するか」のもう一方の軸がスケジューリングで、Core AI はこれを ComputeStream、「a stream of work to be run asynchronously」（非同期に実行される処理のストリーム）としてモデル化しています。¹⁰ コンピュートストリームは、そこへ処理をエンコードするために渡すものです。同じストリームにエンコードされた複数の推論は、読み書きされる値に基づいて必要に応じて直列化される、と Apple は説明しています。¹⁰ ここから2つのことが導かれます。第一に、ストリームは順序付けのプリミティブです。依存関係のある推論を1つのストリームにエンコードすれば、Core AI がデータ依存に基づいて順序を決めてくれます。第二に、処理はデフォルトで非同期です。したがってストリームは、Neural Engine や GPU が働いている間、呼び出し側のスレッドを解放しておくための仕組みでもあります。

推論関数 ― 実際に走るもの

読み込まれた .aimodel は、1つの呼び出し可能な塊ではありません。モデルは名前付きの関数（エンコーダ、デコーダ、ビジョンタワー、prefill と decode のステップなど）を公開しており、Core AI における実行単位が InferenceFunction、「a function that performs inference on input values and produces output values」（入力値に対して推論を行い、出力値を生成する関数）です。¹⁴

呼び出す前に、まず検査します。InferenceFunctionDescriptor は「a description of an inference function’s signature」（推論関数のシグネチャの記述）であり、推論を実行する前に関数の入力・出力・状態の名前と型を調べるために使います。¹³ 立ち止まる価値があるのは状態です。状態を持つ関数は、ステートフルなモデル（たとえば Transformer のデコードループにおける KV キャッシュ）が呼び出しをまたいで情報を保持するための仕組みであり、ディスクリプタは、動かそうとする前にその関数が状態を持つことを教えてくれます。

InferenceFunction 自身は、モデルの重みや中間バッファを含む、推論に必要なリソースを所有します。関数はモデルから読み込み、run(inputs:states:outputViews:) を呼び出して推論を実行します。¹⁴ run のシグネチャは Apple 自身の解説の中で示されており、呼び出しに必要な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 のインスタンス、「a value that an inference function accepts as input or produces as output」（推論関数が入力として受け取り、あるいは出力として生成する値）です。¹² InferenceValue は NDArray かピクセルバッファのいずれかをラップし、推論後は value プロパティを使って結果を取り出します。¹² このラッパーがあるおかげで、1つの run シグネチャがテンソル入力と画像入力の両方を、オーバーロードを分けずに運べます。テキストモデルは NDArray に裏打ちされた値を渡し、ビジョンモデルはピクセルバッファに裏打ちされた値を渡す。そして関数は、どちらを期待しているのかをディスクリプタから読み取るのです。

Core AI に手を伸ばすべきとき

Core AI で最も難しいのは API ではありません。1つ上の層ではなく、そもそもここにいるべきだと判断することです。正直な判断樹を示します。

• 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 です。上位レイヤーのデフォルトこそが障害になっていて、どのデフォルトを上書きしたいのかを言葉にできるとき、ここへ来ることになります。

スタック全体を貫く筋道はこうです。1つ下の層へ降りるたびに、デフォルトを手放してハンドルを受け取る。Foundation Models はすべてを渡してくれて、何も要求しません。Core AI はレバーを渡し、どれを引くべきかを知っていることを求めます。必要な特殊化・キャッシュ・スケジューリングの制御を言葉にできないなら、まだ Core AI は必要ないということです。

WWDC 2026 のラボでの発言が、新規開発における Core AI と Core ML の線引きをより鮮明にしてくれます。WWDC 2026 の Coding Intelligence, Machine Learning & AI Group Lab をローカルで文字起こしした録音からの要約によれば、パネルに参加した Core AI のエンジニアは、ニューラルネットワークを扱うすべての人に今後は Core AI へ移行してほしいと述べ、Core ML は残るものの決定木のような従来型の機械学習に軸足を置き、新しいものはすべて Core AI へ向かう、と語っています。¹⁶ これは文書化された方針というより、フレームワークを作っている当事者からの進行方向のシグナルとして読むべきものです。新規プロジェクトでニューラルネットワークに手を伸ばすなら、ラボはその土台として Core AI を挙げていた、ということです。

モデルはどのように Core AI へ届くのか

このフレームワークは、より大きなワークフローのランタイム側の半分にあたります。そして6月のベータ以降、Apple はツール側の半分も余さず公開しました。¹⁷ パイプラインは次のように進みます。

変換する。 出発点は .aimodel ファイルです。coreai-torch パッケージ（Apple の Core AI PyTorch Extensions for Python）でソースモデルから変換するか、すでにこの形式で用意されたものを使います。¹⁷ .aimodel は他のリソースと同じように Xcode のターゲットに追加され、Compile Sources ビルドフェーズに現れ、Xcode ではパラメータ、ストレージサイズ、メタデータ、演算グラフを表示するモデルビューアが付きます。先に知っておくべきビルドシステム上の依存関係が1つあります。Core AI のモデル統合には Metal Toolchain が必要で、Xcode はこれをデフォルトではインストールしません。入っていないと、.aimodel ファイルを含むビルドは Metal コンパイラが見つからないというエラーで失敗します。¹⁷

必要なら事前コンパイルする。 特殊化は AIModel を作成した時点で自動的に行われ、大きなモデルでは初回ロードのコストが無視できません。coreai-build コマンドラインツールは、最も高コストな部分であるモデルのコンパイルをビルドマシン側へ移します。.aimodel をデバイスアーキテクチャごとに1つの .aimodelc アセットへ変換し（MyModel.aimodel をコンパイルすると MyModel.<arch>.aimodelc が生成されます）、実行時にはアプリが現在のデバイスに合うアセットを選ぶため、Core AI はコンパイル工程を省けます。¹⁷ 事前コンパイルが対象とするのは Apple Intelligence のハードウェア下限です。A17 Pro 以降を搭載した iPhone または iPad、M1 以降の Mac、そして M2 を搭載した Apple Vision Pro です。¹⁷

デバッグとプロファイリング。 可観測性を担うツールは3つあります。モデルの演算グラフを検査し、デバイス上で実行し、出力をリファレンス実行と比較できるスタンドアロンの macOS アプリ、Core AI Debugger。デバッグセッション中にロード・特殊化・推論の動きをライブで監視する Xcode の Core AI デバッグゲージ。そして CPU・GPU・Neural Engine をまたぐ実行タイミングをプロファイリングする Instruments テンプレート、Core AI instrument です。¹⁷

先に見たランタイムの姿は、このワークフローにそのまま収まります。準備されたモデルは検査のために AIModelAsset として読み込まれ、AIModel へ特殊化され、その InferenceFunction を通じて実行されます。そして AIModelCache が特殊化済みの成果物を保持するので、高コストな工程は一度きりで済みます。¹²³⁶¹⁴

よくある質問

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

Core AI は、Apple silicon 上で AI モデルを実行するための iOS 27 の低レベルフレームワークで、Apple 自身は「Run AI models in your app on Apple silicon」と要約しています。¹ CPU・GPU・Neural Engine にまたがってモデル推論を実行し、Swift API は一般的な処理を簡潔に書けるようにしつつ、必要なときにはモデルの特殊化・キャッシュ・推論パフォーマンスを制御させてくれます。¹ モデル実行の層として、Foundation Models と Core ML の下に位置します。

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

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

Core AI は CPU・GPU・Neural Engine をどう選ぶのですか?

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

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 へ手を伸ばしましょう。⁸⁹⁶¹⁰ 必要な制御を言葉にできないなら、1つ上の層にとどまるのが賢明です。

Apple Ecosystem クラスタの全体像はこちらです。自前のモデルと学習ループが欲しいときに組み込む配列フレームワークは MLX on Apple Silicon、CPU/GPU/Neural Engine の共有を成り立たせているハードウェア基盤は Apple Silicon の TBDR と統合メモリ、Core AI の1つ上にある固定モデルの層は Core ML によるオンデバイス推論、そしてスタック最上段にある Apple の封をされたシステム LLM は Foundation Models です。ハブは Apple Ecosystem シリーズ にあります。iOS と AI エージェントを組み合わせた広い文脈については、iOS Agent Development ガイド をご覧ください。

参考文献