Discover machine learning & AI frameworks on Apple platforms

ハイライト

Jaimin Upadhyay 氏が、Apple ML/AI スタックを高層から低層へと5層構造で整理：Platform Intelligence、ML-powered APIs、ドメイン固有フレームワーク、Core ML、MLX。新しく追加された Foundation Models フレームワークにより、わずか3行の Swift でオンデバイス言語モデルを呼び出せるように。

主要内容

iOS 18 以降、アプリに AI 機能を組み込む際、一般的な手法は OpenAI や Gemini のクラウド API を利用することです：API キーの管理、リクエストごとのコスト、ユーザーデータのデバイス外への送信、ネットワーク依存などが課題となります。行程の要約、スマート検索の候補、ゲーム内対話生成など、多くの「軽量・ローカル」な機能にとって、このクラウドアプローチは過剰な存在です。

Jaimin Upadhyay 氏がこの session で提示する回答は：Apple ML/AI スタック全体を「高層から低層へ」5層に分け、必要に応じて使い分けることです。最上層はシステムに組み込まれた Writing Tools、Genmoji、Image Playground で、標準 UI コントロールが自動的にサポートし、ほとんどコードを書く必要がありません（02:03）。その下に iOS 26 で新しく追加された Foundation Models フレームワークがあり、3行の Swift でオンデバイス言語モデルを呼び出せます。完全にオフライン、コストゼロ、プライバシーはデバイスから漏れません（05:05）。さらに下には Vision、Speech、Natural Language などのドメイン固有フレームワークがあり、それぞれがタスク専用の最適化モデルを内蔵。最下層は Core ML で任意のカスタムモデルをデプロイする層、そして MLX のような研究最前線向けのオープンソース配列計算フレームワークです。各層は Apple Silicon 向けに最適化され、CPU / GPU / Neural Engine を適切にスケジューリングします。

詳細

第一層：Platform Intelligence（01:16）

Writing Tools と Genmoji は標準テキストコントロールに組み込まれており、ほぼゼロコードで統合できます。Image Playground フレームワークは SwiftUI 拡張 imagePlaygroundSheet を通じて画像生成パネルをポップアップします。

第二層：ML-powered APIs（02:45）

iOS 18.4 で導入された ImageCreator により、システムパネルを介さずに、テキストプロンプトから直接画像を生成できます（03:08）：

let creator = ImageCreator()
let images = try await creator.images(
    for: [.text("a corgi surfing at sunset")],
    style: .illustration,
    limit: 1
)
// images を取得した後、表示方法を自分で決定

重要な点：

• ImageCreator() を直接インスタンス化でき、entitlement の申請は不要。
• 最初のパラメータは ImagePlaygroundConcept の配列。.text(...) はテキストプロンプト使用を意味；開始画像を concept として渡すことも可能。
• style でスタイルを選択（.illustration / .animation / .sketch）、limit で返される枚数を制御。
• 戻り値は非同期シーケンス/配列。images 取得後の表示方法はアプリ側で決定し、システム UI は一切表示されない。

Smart Reply API（03:29）は、会話コンテキストをキーボードに「提供」し、システムが候補エリアにスマートリプライを生成する仕組みです：

// メッセージング场景の入力ビューで
let context = UIMessageConversationContext(messages: recentMessages)
textView.conversationContext = context

// メール场景では delegate を実装して自分でリプライを生成
func insertInputSuggestion(_ suggestion: UIInputSuggestion) {
    let reply = await generateLongerReply(from: suggestion)
    textView.insertText(reply)
}

重要な点：

• UIMessageConversationContext / UIMailConversationContext が会話履歴を保持し、キーボードが表示される前に entry view に設定する必要がある。
• インスタントメッセージ场景では、ユーザーが選択したリプライがそのままドキュメントに挿入され、アプリ側での処理は不要。
• メール场景ではシステムが insertInputSuggestion をコールバックし、アプリ側で suggestion に基づいて長い本文を生成する。
• すべての推論はオンデバイスで完了し、Apple foundation model を使用。

Foundation Models フレームワーク（04:24）は iOS 26 で新しく追加されたオンデバイス言語モデル API で、わずか3行のコードで動作します：

import FoundationModels

let session = LanguageModelSession()
let response = try await session.respond(to: "Summarize this trip in 3 bullets: ...")

重要な点：

• import FoundationModels でモジュールを導入し、追加の初期化は不要。
• LanguageModelSession() でセッションを一度作成すれば再利用可能で、コンテキストを自動的に管理。
• respond(to:) は非同期メソッドで、構造化された結果を返します。テキストは response.content に含まれます。
• 完全にオンデバイスで動作し、API キーは不要、ネットワークリクエストもなし、ユーザーと開発者にとってコストはゼロ。

Guided Generation（05:38）により、Swift の型をそのまま出力スキーマとして使用でき、JSON 解析の手間を省けます：

@Generable
struct Itinerary {
    @Guide("都市名") var city: String
    @Guide("3から7日のスケジュール") var days: [DayPlan]
}

@Generable
struct DayPlan {
    @Guide("その日のテーマ、例：美食、博物館") var theme: String
    @Guide("その日のアクティビティリスト") var activities: [String]
}

let itinerary = try await session.respond(
    to: "Plan a 5-day trip to Kyoto",
    generating: Itinerary.self
)

重要な点：

• @Generable で既存の Swift 型を生成可能としてマーク。ネストされた型もそれぞれマークする必要あり。
• @Guide("...") で各プロパティに自然言語の説明を記述し、モデルがフィールドの意味を理解できるようにする。
• respond(to:generating:) で出力型を指定。フレームワークがデコードループをカスタマイズし、スキーマに合わない構造の生成を阻止。
• 強く型付けされたインスタンスを取得でき、JSON schema の手書き、解析器の実装、LLM の不正 JSON に対するエラーハンドリングが不要。

Tool Calling（07:02）により、モデルが必要に応じてリアルタイム／個人データにアクセスし、実際のアクションを実行できます。データソースを引用する能力で、ユーザーは出力の事実確認ができ、学習データの時点制限を回避できます。

第三層：ドメイン専用フレームワーク（08:21）

Vision は今年、Document Recognition（「行単位の文字読み取り」の上で、見出し・段落・表グループを識別）と Lens Smudge Detection（09:13）を追加しました。Speech フレームワークは SpeechAnalyzer を導入し、古い SFSpeechRecognizer を置き換えます（09:56）。新しい音声モデルは lecture、meeting、conversation といった長音声や遠方録音に対して、著しく高速かつ高精度になりました。使用方法は、オーディオバッファを analyzer インスタンスに投入し、モデルにルーティングさせるだけです：

let analyzer = SpeechAnalyzer(modules: [transcriber])
try await analyzer.start(inputAudioFile: audioFile)

for try await result in transcriber.results {
    print(result.text)
}

重要な点：

• SpeechAnalyzer(modules:) はモジュール構造で異なる分析機能を組み合わせ、transcriber が音声認識を担当。
• start(inputAudioFile:) はファイル入力を受け付け。リアルタイム场景ではオーディオバッファを直接投入することも可能。
• transcriber.results は非同期シーケンスで、認識結果をストリーミング返却し、リアルタイム表示に適している。
• 完全にオンデバイスで動作し、長音声と遠方场景向けに最適化されている。

Natural Language、Translation、Sound Analysis はそれぞれ言語識別、テキスト翻訳、音声分類を担当します。Create ML（10:55）は独自データでシステムモデルを微調整できます—Vision 用画像分類器、Natural Language 用 word tagger、さらに Vision Pro で 6DOF トラッキング付きの特定物体認識も可能です。

第四層：Core ML と低層（11:16）

モデルのソースは二つ：developer.apple.com にはカテゴリ別整理・デバイス性能データ付きの Core ML モデルライブラリがあり、Hugging Face の Apple space では Core ML フォーマットと PyTorch ソース定義の両方が提供されています。Core ML Tools は PyTorch モデルを Core ML に変換し、演算子の融合・冗長性排除を自動で行い、プルーニング・量子化でトレードオフを調整可能です。Xcode 統合（13:09）では、接続された任意のデバイス上で予測レイテンシ、ロード時間、各演算子が CPU / GPU / ANE のどこに配置されるかを可視化。今年は完全なアーキテクチャ可視化が追加され、各演算子をドリルダウンできます。

より細粒度の制御には二つの層があります：MPS Graph + Metal は Core ML モデルをグラフィックスパイプラインに埋め込み、Accelerate の BNNS Graph API は CPU 上で厳密なレイテンシとメモリ制御を行うリアルタイム信号処理を担当します。BNNS Graph は Graph Builder を追加（14:36）し、演算子グラフを直接構築できるようになり、前／後処理や小規模 ML モデルを CPU 上でリアルタイム実行可能です。

第五層：MLX（15:33）

Apple ML 研究チームが設計した完全オープンソースの配列計算フレームワーク。コマンドライン一行で Mistral といった LLM 推論が実行可能（デモでは quicksort コードを生成、max token = 1024）。Hugging Face の MLX コミュニティには数百の最先端モデルがあり、一行のコードでロードできます。Apple Silicon の統一メモリ（16:30）を活用し、MLX では配列はデバイスに紐付かず、操作がデバイスに紐付きます。これにより、同一バッファ上で CPU/GPU が異なる操作を並列実行できます。Python / Swift / C++ / C の多言語バインディングを提供し、一行コードでの微調整と分散学習拡張をサポート。PyTorch や JAX を利用している場合、Apple は Metal バックエンドを提供しており、フレームワークを切り替えずに Apple Silicon で最先端を探索可能です。

重要ポイント

• 何をするか：アプリに Foundation Models 駆動の「スマート要約／スマート分類」機能を追加する。

  • なぜ価値があるか：完全オンデバイス動作、API コストゼロ、オフライン可用、ユーザーデータはデバイスから流出しない—クラウド LLM 接続よりもコンプライアンスとコストの両面で有利。
  • どう始めるか：import FoundationModels、LanguageModelSession 作成、プロンプト送信。まずは3行コードで最小版を動作させ、その後ドメインデータをプロンプトに詰めて品質を検証。

• 何をするか：@Generable + Guided Generation で既存の「LLM + JSON 解析」パイプラインを置き換える。

  • なぜ価値があるか：カスタムデコードループが構造的エラーを阻止し、schema 手書き、パーサ実装、LLM の不正 JSON 処理が不要に。Swift 型が即座にスキーマとなり、データ構造更新がそのままプロンプト出力更新になる。
  • どう始めるか：既存の Codable 構造体に @Generable を追加、フィールドに @Guide("...") 記述を付与。必要に応じて .range、.count 等の制約を追加。

• 何をするか：古い SFSpeechRecognizer の長録音／会議機能を SpeechAnalyzer に移行する。

  • なぜ価値があるか：新しい API とセットの新モデルは長音声と遠方（lecture、meeting、conversation）に対して著しく高速かつ高精度。古い API は短文口述向け設計で、長録音体験が劣悪。
  • どう始めるか：SpeechAnalyzer インスタンスを作成し、transcriber モジュールを設定、オーディオバッファをストリーミング投入、results シーケンスからテキストを取得。

• 何をするか：Tool Calling で「すべてのコンテキストをプロンプトに詰め込む」手法を置き換える。

  • なぜ価値があるか：オンデバイスモデルの知識には時点制限があり、プロンプトで全データを供給すると遅く、コンテキストウィンドウ超過の恐れ。tool calling によりモデルは必要に応じて天気、カレンダー、アプリデータをクエリし、ソースを引用し、実際のアクションを実行可能。
  • どう始めるか：Tool を定義（記述、パラメータスキーマ、実行クロージャ付き）、tools 配列を session に渡す。プロンプトでタスクを記述し、モデルにどの tool をいつ呼び出すか決定させる。

• 何をするか：リリース前に Xcode の Core ML 性能／アーキテクチャ可視化でモデル健康診断を行う。

  • なぜ価値があるか：各演算子が CPU / GPU / ANE のどこに配置されているか、各デバイスでの予測レイテンシとロード時間が可視化され、リリース後に特定演算子が ANE 非対応で全体レイテンシを低下させる問題を回避可能。
  • どう始めるか：.mlpackage を Xcode にドラッグし、Performance タブを開いて実機接続でベンチマーク実行。今年追加されたアーキテクチャビューで疑わしい演算子をドリルダウン。

関連セッション

• Meet the Foundation Models framework — Foundation Models 入門、session、guided generation、tool calling、streaming を詳説
• Explore prompt design and safety for on-device Foundation models — プロンプト設計、AI 安全性、品質と安全性の評価テストの実践ガイド
• Bring advanced speech-to-text to your app with SpeechAnalyzer — SpeechAnalyzer API + 新音声モデル、長音声と遠方専用
• Explore large language models on Apple silicon with MLX — MLX で Apple Silicon 上で DeepSeek-R1 等の大モデルを実行
• What’s new in BNNS Graph — BNNS Graph Builder で CPU 上にリアルタイム ML / 信号処理パイプラインを構築