• AI
  • ツール
  • How-to

Core AI Frameworkことはじめ——QwenとSAM3をSwiftアプリに組み込むまで

WWDC 2026で発表されたCore AI Frameworkは、生成AI時代のオンデバイス推論を担う新しい実行・配布・最適化スタック。.aimodel形式への変換、Swift API、Background Assetsによるオンデマンド取得、AOTコンパイルまで、開発フローを一通り眺める。

カテゴリー: AI · ツール · How-to | 公開: 2026年6月9日

📑 目次

ふむふむ。「Core MLの後継って噂だけど、何がどう変わるんだろう？」——チカちゃん的には、今回 WWDC 2026 で発表された Core AI Framework を見て、最初にそう思いました。

結論から書くと、Core AI Framework は、Core ML を単純に消すものというより、生成AI時代のオンデバイス推論を担う新しい実行・配布・最適化スタックです。「Hugging Face に置いてあるオープンなモデルを、Apple silicon 向けに最適化して、Swift から数行で呼べる」 という開発体験が、一気に整った感じがします。

今回は、Core AI Framework の全体像と、WWDC 326セッションのサンプル実装を辿りながら、「自分の Swift アプリに Qwen や SAM3 を組み込む」 までの一連の手順を整理してみます。

Core AI Framework とは何か

WWDC 2026 のキーノートで、Apple は Core AI Framework を発表しました。これは 生成AI時代のオンデバイス推論を担う新しいフレームワーク で、Core ML と補完しあいながら、LLMやマルチモーダル生成の本流 を引き受けるものです。

位置づけを整理すると：

項目Core ML（従来の主力）Core AI（WWDC 2026で追加）
主たる対象古典的 ML（分類・検出・回帰）生成 AI（LLM・画像生成・マルチモーダル）
対応モデル形式.mlmodel / .mlpackage.aimodel
変換の流れPyTorch → coremltools → .mlpackageexport スクリプト → .aimodel
トークン生成Core ML単体では、LLMセッション・履歴・構造化出力・モデル配信・AOT特殊化までを一体化した開発体験は薄かったasync/await ネイティブ対応
構造化出力–@Generable で型付き
状態管理–セッション・履歴・ツール呼出し

Core ML がすぐ消えるわけではありません。ただ、WWDC26 の開発者向け導線を見る限り、新しいオンデバイス生成AIの実装では Core AI が前面に出ている と見てよさそうです。

なお、coreai-models の利用には Xcode 27.0+ と iOS/macOS 27.0+ が前提になります。また、モデルによっては tokenizer や追加リソースを含む resource folder として export されるため、.aimodel 単体で完結しないケースがあります。

ℹ️ WWDC 2026 直後の Developer Beta 情報をもとにしているため、API名・コマンド・対応モデル・配信手順は正式リリースまでに変わる可能性があります。

全体の流れ——モデルの発見から統合まで

WWDC 326 セッションでは、「カメラで撮ったものを語彙カードにする iOS アプリ」 の構築を通して、Core AI の使い方を紹介しています。チカちゃん的に大事なステップを抜き出すと：

  1. アプリの要件から必要なモデルを選ぶ
  2. coreai-models リポジトリから取得（または自作）
  3. Xcode で .aimodel ファイルを検証
  4. Swift コードから読み込んで実行
  5. Instruments でプロファイリング
  6. Background Assets で配信戦略を設計
  7. AOT コンパイルで初回体験を高速化

ひとつずつ見ていきます。

ステップ1: モデルの選定

サンプルアプリでは、2つの異なるモデル を組み合わせています。

  • SAM3 — テキストプロンプトで画像中のオブジェクトをセグメント化する
  • Qwen 0.6B — 119言語対応の軽量言語モデル（語彙カードのテキスト生成用）

「画像の中の “花” だけを切り抜いて、その名前と例文を生成する」 というタスクを、「視覚（SAM3） + 言語（Qwen）」 の二段構成で解く構成です。

チカちゃん的には、この 「複数の小さいモデルを組み合わせる」 という設計が、Core AI の思想の本丸だと感じています。「1つの巨大モデルで全部やる」 のではなく、「タスクごとに適切なサイズのモデルを選んで組み合わせる」 のが、新しいローカル LLM の使い方です。

ステップ2: coreai-models リポジトリから取得

Apple は coreai-models という公開 GitHub リポジトリで、人気のオープンソースモデルの export recipe を配布しています。

A curated collection of popular open-source models — including Qwen, Mistral, SAM3, and more — optimized for Apple silicon using the new Core AI Framework.

リポジトリのカタログから、使いたいモデルを選び、export スクリプトを実行 すると、Apple silicon 最適化済みの .aimodel ファイル が得られます。coreai-models は、各モデルごとに export recipe を提供していて、利用したいモデルの README に従って export すると、.aimodel または tokenizer 等を含む resource folder が生成されます。

git clone https://github.com/apple/coreai-models
cd coreai-models

# 利用可能なモデルを確認
uv run coreai.model.registry --list-models

# 実際の export 手順は、models/ 以下の各モデル README に従う

出力された .aimodel ファイルを、ドラッグ&ドロップで Xcode プロジェクトに追加します。

ステップ3: .aimodel を Xcode で確認

Xcode に .aimodel を追加すると、GUI で以下が確認できます。

  • ファイルサイズ
  • 対応プラットフォーム（iOS / macOS / etc.）
  • 関数シグネチャ
  • テンソルの形状

そして、CoreAILM（言語モデル用）と CoreAISegmentation（セグメンテーション用）といった必要なライブラリだけを選んで、アプリの依存関係に追加します。

「全部入りライブラリ」じゃなくて、モデル種別ごとに別 SPM プロダクトになっている のは、ビルド時間とバイナリサイズに効く設計です。

ステップ4: Swift コードから呼び出す

ここからが、Core AI の真骨頂です。「数行で書ける」 を地でいってます。

SAM3 で画像セグメンテーション

import CoreAIImageSegmenter

let segmenter = try await ImageSegmenter(resourcesAt: sam3ModelURL)
let response = try await segmenter.segment(image: inputImage, prompt: "flower")
let mask = response.segments.first?.mask

「ImageSegmenter(resourcesAt:) で初期化して、segment(image:prompt:) で叩く」、以上。このデモに限って言えば、Core ML 時代に手書きしがちだった pre/post-processing の多くが、専用API側に寄せられています。

Qwen で語彙カード生成

import FoundationModels
import CoreAILanguageModels

let model = try await CoreAILanguageModel(resourcesAt: qwen3ModelURL)
let session = LanguageModelSession(model: model)
let response = try await session.respond(to: "Create a vocab card for flower")

LanguageModelSession は Foundation Models フレームワークの API で、既存の Foundation Models アプリとの互換性 を保ったまま、Core AI 経由のモデルを差し込める という設計です。

構造化出力：@Generable

@Generable
struct VocabCard {
    let chineseWord: String
    let englishMeaning: String
    let exampleSentence: String
}

let response = try await session.respond(
    to: "Create a vocab card for flower",
    generating: VocabCard.self
)
let card: VocabCard = response.content

@Generable マクロを付けた struct を generating: に渡すだけで、LLM の出力を Swift の型として受け取れます。これは Foundation Models フレームワークの LanguageModelSession が提供する型付き生成機能で、Core AI で読み込んだ言語モデルにもそのまま適用できます。JSON 文字列を手でパースする手間は大きく減りますが、生成内容の妥当性チェックやアプリ側の制約検証は引き続き必要です。

チカちゃん的には、この**「生成結果を型として受け取る」**体験が、Core AI の中でいちばん気持ちいいところだなと感じます。JSON 文字列を手でパースして事故る、という生成 AI アプリあるあるは大きく減ります。

ステップ5: Instruments で初回レイテンシを診断

セッションでは、Core AI Instruments テンプレート を使った診断も紹介されています。

よくあるボトルネックは、「モデル特殊化（model specialization）」 という処理で、特定デバイスのためにモデルをコンパイルする ステップ。これが初回起動時に走ると、ユーザーは「アプリ重い」と感じてしまう。

Instruments で「どこで時間がかかったか」を可視化 して、特殊化に時間がかかっているのか、ロードに時間がかかっているのか、を区別する。これは運用側でできる対策の基本です。

ステップ6: 配信戦略——Background Assets

チカちゃん的に、これは Core AI の隠れた目玉 だと思っています。

セッションで繰り返されるテーマは、「アプリバンドルにモデルを含めない」 です。

Don’t include models in the app bundle → Avoid bloating update size for all users.

代わりに、Background Assets という iOS の API を使い、モデルをダウンロードするタイミングをオンデマンドで決める。

  • ユーザーが機能を初めて使う直前
  • Wi-Fi 接続中のみ
  • バッテリー残量が十分

オンデバイス LLM の**「モデルサイズが大きすぎてアプリに入らない」問題を、「必要な時に、必要な人だけダウンロード」**で解決する設計です。

ユーザーがオプトインした場合のみダウンロード実行。

この**「勝手にダウンロードしない」**設計、プライバシー重視の Apple らしい ところです。

ステップ7: AOT コンパイルで初回体験を高速化

そしてもうひとつの目玉が AOT（Ahead-of-Time）コンパイル。

$ xcrun coreai-build compile MyModel.aimodel --platform iOS

開発マシン上でこのコマンドを走らせると、ターゲットデバイスのアーキテクチャ向けに事前コンパイルされたモデルアセットが生成されます。

  • 初回起動時の「モデル特殊化」時間を劇的に削減
  • ユーザー体験を「重い」→「速い」に切り替えられる

WWDC 326 のライブデモでは、iPhone で起動 → かなり短い待ち時間で語彙カード生成まで到達していました。

macOS との同一コード——マルチプラットフォームの威力

セッションの最後、「同じ Swift コードが macOS でも変更なしで動く」 ことが強調されます。

The same Swift code runs on macOS with no changes.

macOS デモでは、写真フォルダのバッチ処理を追加し、Qwen3 8B に切り替えて、より長いコンテキストでロードトリップ写真から完全なレッスンプランを生成する様子が紹介されました。

ImageSegmenter(resourcesAt:) 1個で iOS と macOS の両方がカバーされる。コードを書き直さずに「Mac アプリでも動く」が成立するのは、Apple silicon の統合プラットフォームとしての強みが、生成 AI 時代にも生きている感じがします。

Core AI の嬉しさを整理する

チカちゃん的に、Core AI Framework が**「Core ML から何が変わるか」** を整理すると：

観点Core ML 時代Core AI 時代
モデル変換coremltools で独自フォーマットにexport recipe で .aimodel を取得
トークン生成Core ML単体では、LLMセッション・履歴・構造化出力・モデル配信・AOT特殊化までを一体化した開発体験は薄かったasync/await で自然に書ける
構造化出力手動パース@Generable で型安全
配信アプリに同梱 or 自前 CDNBackground Assets 標準
プロファイリング標準 Instruments専用テンプレート
マルチプラットフォームOS 別 API単一 Swift コード

とくに**「coremltools で変換する儀式」からの解放は大きいです。「Hugging Face に置いてあるあのモデル、Apple silicon で動かしたいんだけど」** というのが、export スクリプト一発で済む。

チカちゃん的に気になる点——「何が変わって何が変わらないか」

もちろん、チカちゃん的には注意点も見ておきたい。

  • Core ML はすぐには消えない — Apple は非推奨化のサイクルを長くとる。.mlpackage を読み込む互換レイヤーは当面動く
  • .aimodel のサイズは依然として大きい — Background Assets があるから配信は問題ないが、「アプリ起動時に必ず使える状態」にはできない
  • Apple Intelligence のオンデバイスモデルと同じ API である一方、Qwen や Mistral の動作は Apple silicon 専用 — Android への展開は別途考える必要がある
  • NPU 性能差が効く — Core AI は CPU / GPU / Neural Engine を使い分けるが、A17 Pro と A19 Pro では速度が段違い になるはず

これらは、Core AI 採用時の「設計で決めておくこと」です。とくに**「モデルをどう配信するか」**は、Background Assets の設計と絡めて早めに固めるのが良さそうです。

まとめ——「Hugging Face のモデルが Swift アプリになる」未来

Core AI Framework の話を一言でまとめると、「Hugging Face に置いてあるオープンな生成 AI モデルを、Apple silicon 上で数行の Swift で動かせる」 開発体験の、ようやく来た完成形 だと感じます。

モデル変換で泣かなくていい。
トークン生成を手書きしなくていい。
JSON パースで事故らなくていい。
配信は Background Assets に任せればいい。

「生成 AI を自分のアプリに入れる」 ことの心理的・技術的なコストが、Core AI で一段下がった気がします。

ただし、「何ができるか」 が広がると、「何を作るべきか」 の問いが重くなる。技術的可能性と自分の作ろうとしているもののあいだで、チカちゃん的には、もうちょっと遊んでみたいところです。

答えを急がなくても大丈夫。
「自分のアプリに LLM を入れる」 ことが、スイスイできるようになった今、「それを何のために使うか」 の問いは、きっともっと面白くなる。

🔗 NAND-DRAM時代シリーズ（全4本）

参考URL

  • インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃（サプライチェーン攻撃）が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
  • AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。