Apple Foundation ModelsがClaude・Geminiを同じSwift APIで呼べる
WWDC 2026を伝えるニュースの見出しは、ほとんどが「iPhoneでClaudeが使えるようになる」だった。けれど現役でアプリにLLMを組み込んでいる側から見ると、効いてくるのはそこではない。Appleは、オンデバイスモデル用に2025年に出したFoundation Modelsフレームワークを、プロバイダ非依存の抽象レイヤーへと作り替えてきた。アプリは1本のSwift APIに対してコードを書き、その裏側でApple自前のモデル、Private Cloud Compute(PCC)上のクラウドモデル、ClaudeやGeminiのようなフロンティアモデルを差し替える。データベースにおけるJDBCやORMに相当するものが、ようやくLLM層に降りてきた、という捉え方が一番しっくりくる。
🔌 設計の核は「Language Model protocol」
Appleのニュースルームは、開発者が「ClaudeやGemini、あるいは新しいlanguage modelプロトコルを実装した任意のプロバイダ」のモデルを選べる、と明記している。Foundation Models自体は、画像入力・サーバーモデル・カスタムスキルに対応した単一のネイティブSwift APIとして位置づけ直された。
a single native Swift API that supports more powerful on-device models with image input, support for server models, and the ability to build custom skills
ポイントは固有のモデル名ではなく、このプロトコルだ。どのプロバイダであれプロトコルに準拠さえすれば、同じセッションロジックの裏側に挿さる。アプリ側のコードは「モデルに問い合わせる」ところで止まり、どのバックエンドが応答するかは設定とルーティングの問題になる。モデル層がコモディティ化し、選択は実行時の関心事に移る、という方向性そのものだ。
具体的なSwiftの呼び出しシグネチャは、Appleのセッション動画 What's new in the Foundation Models framework(Session 241) に集約されている。プロトコルのメソッド名まで含めて正確に確認したい人はそちらを見るのが早い。
ルーティング先で何が変わるか
「同じAPIで呼べる」は便利だが、抽象化は必ず漏れる。1リクエストごとにオンデバイス/PCC/フロンティアを切り替えるということは、レイテンシ・コスト・コンテキスト長・到達できる能力が大きく違う相手を、同じ呼び出し口の向こうに並べるということでもある。ここは表で整理しておく価値がある(数値はモデルやプランで変動するため、性質の比較にとどめる)。
| ルーティング先 | データの経路 | コスト負担 | 主な使いどころ |
|---|---|---|---|
| オンデバイスモデル | 端末内で完結 | なし | 低レイテンシ・オフライン・機微なデータ |
| PCC上のAppleモデル | Apple管理のプライベートクラウド | 小規模開発者は無料枠あり | 端末で重い処理を秘匿性を保ったまま |
| Claude / Gemini 等 | 各社のクラウドへ | 各プロバイダの課金 | 長文・難しい推論・最新の能力 |
同じsessionの裏でこれだけ性質が変われば、プロンプトの移植性はタダでは手に入らない。Apple自前モデル向けに詰めた指示が、そのままClaudeやGeminiで最適に動く保証はない。抽象レイヤーが隠してくれるのは「呼び出しの形」であって、「モデルごとの癖」ではない。ここを混同すると、ルーティングを増やすほどプロンプトの分岐が増える、という地味な保守コストに後から気づくことになる。
🧩 Dynamic Profiles と、別物の Core AI
差し替えは静的なビルド時設定にとどまらない。Dynamic Profiles は、継続中のセッションの中でモデル・ツール・instructionsを動的に入れ替える仕組みだとされている。マルチエージェント的に、簡単な問いはオンデバイスで捌き、複雑になった瞬間にフロンティアモデルへ昇格させる、といった制御が同一セッション内で書ける。
混同しやすいが、Core AI はこれとは別の新フレームワークだ。Appleは「デバイス上でモデルを動かす最良の方法」と説明し、Apple Siliconのユニファイドメモリと Neural Engine に最適化したアーキテクチャで、フルスケールのLLMをローカルに展開できるとしている。Foundation Modelsが「どのモデルを呼ぶか」のレイヤーなら、Core AIは「自前のモデルをデバイスでどう走らせるか」のレイヤー、と役割を分けて読むのが正しい。
加えて、モデルからVisionフレームワークのツール(OCRやバーコード読み取り)を直接呼べる点と、AI機能の挙動を検証する Evaluations フレームワークが用意された点も、実務寄りの更新として地味に大きい。ユニットテストでは捉えにくい「動的な条件下での振る舞い」を確かめる手段が標準で来たのは素直にありがたい。
Gemini側はFirebase経由で入る
Googleも同じ日に受け側の対応を出している。iOS 27世代以降、Foundation ModelsフレームワークからクラウドのGeminiを呼べるようになり、その実装は Firebase Apple SDK(Firebase AI Logic)を介して提供される。個人開発者は Google AI Studio で取得したGemini APIキーをそのまま使え、エンタープライズは Gemini Enterprise Agent Platform 経由で専用クォータやデータプライバシー制御を得る、という二段構えだ。さらにApple自身のオンデバイスモデルが「Googleとの協業でカスタムビルドされた」と明言されている点も見落とせない。プラットフォーマー同士が、足元のモデルとSDKの両方で組んでいる。
💰 無料PCC枠は「開かれた囲い込み」
地味だが効くのが課金まわりだ。App Store Small Business Program のメンバーで、累計の初回ダウンロードが200万未満のアプリは、次世代のApple Foundation Models を Private Cloud Compute 上でクラウドAPIコストなしに使える。端末では重すぎる推論を、秘匿性を保ったまま無料で回せる枠が、小規模開発者に向けて開く。
これは強烈な配布レバーだと思う。プライバシー保護をうたうクラウド推論を無料で配れば、初期コストに敏感な個人・小規模チームほど引き寄せられる。同時に、これはApple製プラットフォームへのロックインを「開放」の言葉でくるんだ施策でもある。プロトコルを公開して他社モデルを受け入れる開放性と、無料枠で自社クラウドに留まらせる引力が、同じ発表の中に同居している。どちらか一方だけを見て評価すると判断を誤る。
総じて、今回の本質は「iPhoneにClaudeが来た」ことではなく、Appleがモデル選択をOS/SDKレベルの抽象に押し込んだことだ。モデルを差し替え可能な部品として扱う設計に賛成だが、差し替えられるのは接続の形であって、プロンプトと評価まで自動で移植されるわけではない。実装する側の仕事は、APIが1本に減ったぶんだけ、ルーティング方針とモデルごとの挙動検証へと移っていく。