Apple Foundation ModelsにClaudeを組み込む
(platform.claude.com)- AppleのFoundation ModelsフレームワークにClaudeをサーバーサイドモデルとして接続するSwiftパッケージで、開発者はAppleのオンデバイスモデルとまったく同じコードパスでClaudeを呼び出せる
- WWDC 2026でAppleが導入した**
LanguageModelプロトコルにより、オンデバイスモデルでプロトタイピングした後、複雑な作業だけをクラウドモデルに渡すハイブリッド構成**が単一の標準APIで可能になった - 核心はプロバイダーの差し替え可能性で、セッションロジックを触らずにSwift Packageの依存関係だけを変えればApple・Claude・Geminiの間を行き来できる点
- AnthropicがApache 2.0で公開したこのパッケージは、その「どんなバックエンドでも接続可能」という構想の実際に動作する最初の事例
- リクエストはアプリからClaude APIへ直接送られ、Appleは経路上に存在しないため、プロンプトや応答を見ることはできず、料金もAnthropicアカウントに直接請求される
なぜ重要か
- iOSアプリに言語モデルを組み込むには、これまで別途クラウドAPIへの登録、キー管理、トークン単位の課金、すべてのプロンプトをデバイス外へ送信する必要があったが、WWDC 2026でAppleがこの長年の不便を解消した
- Foundation Modelsフレームワークは、Apple Intelligenceのオンデバイスモデル、Private Cloud Compute、Claude・Geminiのようなサードパーティクラウドを1つのネイティブSwift APIですべて呼び出せる形へ拡張された
- Anthropicはこの新しいプロトコルを実装したSwiftパッケージを公開した。Appleのオンデバイスモデルから引き継いで、より複雑なワークフローを処理するためにClaudeを呼び出す用途を想定している
開発者にとって何が変わるか
-
コード変更なしのプロバイダー切り替え
- Appleのオンデバイスモデルでアプリをプロトタイピングした後、複雑なクエリをGoogle GeminiやAnthropic Claudeへルーティングしたり、その間で切り替えたりする作業を、Swift Package Managerの依存関係を更新するだけで、セッションロジックや残りのアプリコードを変更せずに行える
- オンデバイスモデルは要約・抽出のような高速でローカルな作業に使い、マルチステップ推論・コード生成・Web検索・コード実行が必要なときだけClaudeへハンドオフする
- どちらの場合も同じ
LanguageModelSessionAPIを使うため、model:引数を差し替えるだけで切り替えられる
-
型ベースのハンドオフ
- プロジェクトに追加してAnthropic APIキーでログインした後、Appleのオンデバイスモデルの型付き出力をClaudeへのリクエストとして渡すと、パッケージがストリーミング・ツール呼び出し・構造化応答を再びSwiftUIビューで処理する
- ガイド生成により、わずか3行のコードだけで型付きSwift値を返せるほど簡単に使える
プライバシーとコスト構造
- リクエストはアプリからClaude APIへ直接送信されるため、Appleはリクエスト経路上に存在せず、プロンプトや応答を見ることはできない
- 利用量は標準API価格でAnthropicアカウントに直接請求される
- アプリはセッションごとにClaudeを使うかAppleのオンデバイスモデルを使うかを自ら決定する
より大きな構図
- Appleは2025年に公開したオンデバイスモデル向けネイティブSwift APIであるFoundation Modelsフレームワークを今夏オープンソース化する予定で、新しいLanguageModelプロトコルにより、Apple独自モデルでもリモートプロバイダーでも、ほぼすべてのモデルが単一のSwift APIの背後でLanguageModelSessionを駆動する
- この「どんなバックエンドでも接続可能」の実例として、AnthropicのClaudeForFoundationModelsがアダプターパターンを具体化している
- AppleはDynamic Profilesシステムにより、アプリがセッションの途中でモデル・ツール・指示を切り替えられるようにし、これをマルチエージェントワークフローの基盤として位置づけている
- ただし、この統合はiOS・iPadOS・macOS・visionOS・watchOS 27およびXcode 27を必要とするベータ段階であり、正式リリース前にAPIが変更される可能性がある
1件のコメント
Hacker Newsの意見
Appleはユーザー体験を支配しながら、LLMをコモディティ化しつつある
ハードウェア企業らしく、AI利用に最適なマシンを売り続けるという戦略で、うまい選択に見える
インフラに何十億ドルも投資するが、価値はその上のレイヤーにいる別の会社が持っていく構造だ
適応しない企業は、人々が作ったAIベースのDIYウェブスクレイパーに叩きのめされ、最終的には屈するしかなくなる
LLMをコモディティ化するという表現は当てはまるだろうが、これはすでに何年も磨き込んできたユーザー向け機能だ
Apple's Foundation Models frameworkでClaudeをサーバー側言語モデルとして使えるようにするSwiftパッケージとは、逆方向を期待していた。Claude Codeの既存機能が somehow 自分のノートPCのNeural Engineでローカル実行されることを願っていたM2に8GB RAMでは夢物語だが、一瞬だけ希望を持てた
https://developer.apple.com/videos/play/wwdc2026/232/
https://www.youtube.com/watch?v=wykPErJ8M-8
だが実際には、どこでホスティングされているのかも分からないClaudeを受け取ることになる。xAIのデータセンターかもしれないし、Amazonのどこかかもしれないし、誰にも分からない
これはClaude専用ではない。開発者はGoogleのサーバー型Geminiモデルを呼び出すアプリも作れる
WWDCでAppleは、Foundation Models frameworkをサードパーティのクラウドモデル提供者に開放すると発表した。iOS 27、macOS 27、iPadOS 27、visionOS 27、watchOS 27から、モデル提供者は新しい公開
LanguageModelプロトコルを実装し、モデル推論のための共通インターフェースを提供できる。GoogleはFirebase Apple SDKを通じて、GeminiモデルをFoundation Models frameworkで使えるようにしたこれにより、完全にネイティブな開発体験が可能になる。クラウドホスティングされたGeminiモデルは同じAPIを通じてFoundation Models frameworkに直接接続でき、デバイス内のAppleモデルとクラウドホスティングされたGeminiモデルが共通のAPI表面の背後に置かれるため、用途に応じてローカル推論とクラウド推論を簡単に切り替えられる
https://blog.google/innovation-and-ai/technology/developers-...
language model protocolと呼び直した点であり、そのひどく長い表現に呪われる前に、みんな早くこちらに結集すべきだAppleがこのような抽象化を導入したのは歓迎だが、主な懸念はローカルモデルのほうだ
たとえばGemma4を使いたいとしても、ユーザー視点ではアプリ10個が同じモデルをそれぞれダウンロードしたら、スマホが無駄に肥大化してしまう
Appleが複数のアプリで同じデバイス内モデルを使えるようにする方法を提供しているのか、まだ理解できていない。厄介な名前空間や権限の裏技なしで可能であるべきだ
そうしたことを示唆する話は見ていない
デバイス内モデルが大きく遅れていた時期には間違っていたが、長期的にはなお正しいかもしれない
私の使う複数のアプリがGemma 4 E4Bを必要とするかもしれないが、使うアプリは数十あり、開発者は数百のモデルから選べる。共有キャッシュが重なる場合には容量を少し減らせるだろうが、核心の問題は残る。各アプリがモデルを選ぶと、ディスクとメモリのスワッピングが爆発する
デバイスメーカーがデフォルトを内蔵するほうが、より良い可能性が高い。他のモデルの利用を禁じようという話ではないが、1つの共有デフォルトがアプリの99%にとって、開発者体験とユーザー体験の両面で最善かもしれない
すでにメモリに載っている状態こそ最大の性能向上であり、デフォルトモデルは温かい状態に保たれる可能性がはるかに高い
「最高のモデル」はたいてい、RAMと計算量を踏まえた「このデバイスに最適なモデル」だ。開発者はあらゆるデバイスをテストできないが、Appleならできるし、そうするだろう
各モデルはハードウェアに合わせて最適化される必要がある。ANE、Metal、CPUのどこで何が動くかが重要で、デフォルトモデルは最適化される
カスタムモデルが必要なら、LoRAがおそらく最善だ。30MB程度で、上の利点をすべて享受できる
デフォルトを差し替え可能にすべきだとは言えるが、それはAppleというよりLinux的な理想に近く、実際に見られるかは疑問だ。しかも現実的な欠点もある。意図したかどうかにかかわらず、プロンプトは開発対象モデルに合わせて最適化されるため、デフォルトのシステムモデルを変えると、すべてのアプリの品質が低下しうる
https://developer.apple.com/videos/play/wwdc2026/339
Appleが開発者に、LLMを自社のAPI抽象化レイヤー経由で使うよう誘導しているのではないかと思う。後で自社LLMを出したときに、開発者がスムーズに切り替えられるようにするためかもしれない
Appleが学習に多額の資金を投じていて、Siriや現在のApple AIと何らかの形で関係しうるという話を聞いた気がする。あるいは単なる開発者向け利便機能なのか、別の意図があるのか気になる
プライバシーを重視するなら、Appleが中間に入ることには価値がある
このフレームワークの要点は、同じAPIでデバイス内蔵モデル、AppleホスティングのオンラインモデルであるPrivate Cloud Computer、または任意にホスティングされたオンラインモデルを呼び出す独自shimのすべてを対象にできることだ
そうすれば、「これはローカルモデルで使い、あれはClaudeで使いたい」といった独自の抽象化レイヤーを作ったり、Anthropic/OpenAI API統合を直接つないだりせずに、システムAPIで呼び出しを別のモデル/プロバイダ種別へ動的にルーティングできる
ツール呼び出しのようなものを一か所で抽象化したり、セッション中にプロバイダやモデルを動的に切り替えても同じ
transcriptを引き継いだりと、便利な点や特徴がいろいろあるこのAPIはAppleデバイスでしか使えないので、iOSでまともに動作させるには、開発者が同じシステムを使えないよう市場を分断し、ユーザーをさらに強く囲い込む効果もある
Appleは自社のオンデバイスモデルが今後さらに良くなることを見越しているように見えるし、Geminiにアクセスできるようになったことを考えると筋が通る。
開発者が外部LLM呼び出しのコードをすべてこれで書くなら、Appleのモデルがより有能になり、より多くのユースケースをカバーするようになったとき、個々の呼び出し箇所で簡単に切り替えられる。そうなればアプリのユーザー体験は良くなり、Appleが手数料を取れない開発者の請求コストも下がる
Appleは企業であり、企業が何を気にするかは皆わかっているので、スマホ上でローカルモデルが動くユートピアになる可能性は低そうだ
MicrosoftとNvidiaが組んでいるのも理由があってのことだ
これをユーザー向けに配布するソフトウェアで実際にどう使うのか気になる。ユーザーに直接APIキーを作らせて入力させるのは、良いユーザー体験としてはハードルが高すぎる
「質問1つにいくらかかるかわからない金を払い、欲しい答えが得られないこともあり、もっと使うならさらに金を払う」という仕組みは、ギャンブラーでない大半の人には魅力的ではない。長い会話の最後の「ありがとう」が文脈のせいで高くつくことを説明するのは、平均的なユーザーにはなおさら受け入れにくい。
トークン費用がヨーヨーのように上下するのも助けにならない。一般ユーザーには固定費が必要で、AI界隈の動向を追い続けることにエネルギーを使いたくはない。「先月は自分のサブスクでもっと長く使えたのに」といった問題も良い方向ではない。
多くの場合、ローカルLLMが未来だというAppleの判断は正しいと思う
Anthropicの規約もまだ完全には理解できていない。
setup-token Set up a long-lived authentication token (requires Claude subscription)のようなものを入力することはできるが、罠のように見える。誰がこれを使うのかわからないし、どこで使っても即座に規約違反になるのではないかと思う。今のallihat.comでは、Claudeキーを使いたくない場合はローカルのAppleモデルを使えるようにしていて、有料ユーザーへの転換率が3倍ほど上がった。だが当然、Claudeの代替ではない。AppleがClaudeプロキシを代行してくれる何らかの仕組みを作ってくれたらと思っていた。自分のサーバーでClaude API使用量を管理するためにプロキシする必要もなくなるし
.proxiedでリクエストを自前のバックエンド経由にルーティングするよう書かれている。Appleはダウンロード数200万未満の開発者に対し、自社サーバー経由の無料AIモデルを提供している https://techcrunch.com/2026/06/08/apple-bets-cheaper-ai-will...
「リクエストはアプリからClaude APIへ直接送られ、Appleはリクエスト経路上におらず、プロンプトや応答を見ることもない」という文言は、開発者視点だというのはわかる。
だが消費者の立場からすると、ただただ滑稽だ
MicrosoftはまずCopilotの規約に「Copilotは娯楽目的でのみ提供される」と入れ、さらにExcel向けCopilotにも「正確性や再現性が必要な作業、法的・規制・コンプライアンス上の影響がある作業にはCOPILOTの使用を避けよ」という警告を入れることで、このゲームを壊した。
続いてAppleは、競合LLMを作るために数十億〜数千億ドルを投じず、静かに参加を拒否している。もちろん、世間知らずの人々のためにClaudeを再販したりGeminiを活用したりはしているが、Appleは状況を理解している。
https://www.microsoft.com/en-us/microsoft-copilot/for-indivi...
https://support.microsoft.com/en-US/Excel/copilot-function
コーディングエージェント自体がすでに無理やり載せられたレイヤーなのに、今度はさらにもう1層追加するのかという感じだ。コーディングエージェントはしばしば90年代の人材派遣会社のベンダーマネージャーのようだ。
顧客にこの世のあらゆることを約束し、哀れな契約社員をせき立てて納品させるようなものだ。コーディングエージェントは、人材派遣会社が顧客に請求した額と契約社員に払った額の差額のように、トークンを10倍余計に食う。簡単なテストとして、コーディングエージェント経由だとモデルがコンテキスト長を超える同じ作業でも、直接プロンプトすれば問題なく動く。
レイヤーは贅沢であり、制御と透明性を失わせる