iPhone や Mac のアプリに AI を組み込むとき、Apple の端末内モデルは速くて無料でオフラインでも動くけど、込み入った仕事には力不足。そこを、同じコードのまま引数ひとつ差し替えるだけで Claude に切り替えられるようになった。Anthropic が出した「Claude for Foundation Models」という Swift パッケージの話。Apple の Foundation Models フレームワーク経由で Claude を呼べる。iOS 開発をやっている人には、AI 機能の設計図がひとつ増える内容なので、何ができるのかを整理する。
- Appleの同じAPIで、端末モデルとClaudeを切り替える
- 型付きの構造データをそのままClaudeに流せる
- 端末モデルとClaude、使い分けの線引き
- サーバーツールも効く、できることとできないこと
- ベータの注意点、APIキーは本番に載せない
Appleの同じAPIで、端末モデルとClaudeを切り替える
まず仕組みから。Apple の Foundation Models は、iPhone や Mac の中で動く AI モデルを、アプリから呼ぶための仕組み。今回 Anthropic が出したのは、その同じ枠組みの中で、Claude を「サーバーサイドの言語モデル」として使えるようにする Swift パッケージ。
ポイントは、Claude を Apple のフレームワークの LanguageModel という共通の型に合わせ込んでいること。だから、端末内モデルを動かすときとまったく同じ LanguageModelSession という API で Claude も動かせる。respond(to:) で応答を得る、ストリーミングで受け取る、構造化出力、ツール呼び出し。全部、端末モデルと同じ書き方で通る。
// 端末モデルでもClaudeでも、変わるのは model: の中身だけ let model = ClaudeLanguageModel(name: .opus4_8, auth: auth) let session = LanguageModelSession(model: model) let response = try await session.respond(to: "ブエノスアイレス4日間の旅程を組んで")
つまり、軽い処理は端末モデル、重い処理は Claude、とセッションごとに model: を差し替えるだけで使い分けられる。アプリ全体の作りを変えずに、必要な場面だけ Claude に格上げできる。ここが今回いちばん効く設計だと思う。
それと、知っておきたい大事な点が一つ。リクエストはアプリから Claude API へ直接飛び、Apple は経路に入らない。Apple はプロンプトも応答も見ない。課金は自分の Anthropic アカウントに、通常の API 料金でかかる。Apple を介さず、自分と Anthropic の間で完結する関係。
型付きの構造データをそのままClaudeに流せる
Anthropic がこの連携で推しているのが、型付きデータの受け渡し。Apple の Foundation Models には @Generable という仕組みがあって、Swift の型に印を付けておくと、モデルがその型に沿った値を返してくれる。
@Generable struct Trip { @Guide(description: "目的地の都市") var destination: String @Guide(description: "日数") var days: Int } let response = try await session.respond(to: "東京旅行を計画して", generating: Trip.self) print(response.content.destination) // ちゃんと String 型で取れる
これの何が嬉しいか。発表でも触れられているけど、Apple の枠組みで型付けした構造データを、そのまま Claude のリクエストに流し込める。ユーザーが打った生のテキストをそのまま投げるのではなく、アプリ側で型に整えたデータを送る形になる。そして応答は、同じ SwiftUI のビューにそのままストリームで返ってくる。アプリの中で「入力を型に固める → Claude に渡す → 型で受け取る → 画面に流す」が、一本のレールでつながる。生テキストのやり取りにありがちな、パースの手間や崩れたフォーマットの後始末が減る、という実利がある。
端末モデルとClaude、使い分けの線引き
この連携の肝は使い分けなので、線引きを整理しておく。
Apple の端末内モデルは、速くて、プライベートで(データが端末から出ない)、オフラインでも動く。ただし軽量なタスク向けに作られている。短い要約や分類、ちょっとした言い換えなら十分。一方、Claude に格上げすべきなのは、長いコンテキストを扱いたいとき、最前線の推論力が要るとき、あるいは Web 検索やコード実行みたいなサーバー側のツールを使いたいとき。両者が同じ LanguageModelSession で動くから、この判断をアプリのロジックの中で動的に切り替えられる。
実装の定石として案内されているのが、Claude がレート制限(.rateLimited)に当たったら、その回だけ端末モデルに切り替えるフォールバック。重い処理は基本 Claude に任せつつ、混雑時は端末モデルで凌ぐ、という二段構え。前に Fable 5 のフォールバックを取り上げたとき「能力の高いモデルほど、答えてくれなかったときの優雅な二番手への渡し方が体験を分ける」と書いたけど、ここでも同じ発想が効く。端末モデルという無料の二番手を、すぐ後ろに控えさせておける。
サーバーツールも効く、できることとできないこと
機能面も見ておく。クライアント側のツール(端末上で実行する自前の処理)は、Apple の tools: の仕組みがそのまま使える。加えて、Web 検索・Web 取得・コード実行といったサーバー側のツールも、serverTools: で設定すれば Anthropic 側のインフラで動く。effort(どれだけ頭を使わせるか)も fixedEffort: で固定でき、xhigh や max はこの指定経由でしか使えない(Apple 側の推論ヒントは high 止まりのため)。画像入力にも、対応モデルなら対応する。
一方で、Messages API のすべてが使えるわけではない。Apple のフレームワークの枠に収まらない機能は、この経由では使えない。具体的には、プロンプトキャッシュの細かい制御(自動適用はされるが、TTL や区切りの位置は調整不可)、stop sequences、バッチ処理、Files API、トークンカウント、beta ヘッダ。このあたりを使い込んでいる人は、できないことを先に把握しておかないと、後で詰まる。これは「汎用の Messages API クライアントではない」という割り切りの裏返しで、別言語で API を直接叩きたいなら従来の SDK を使え、という住み分けになっている。
ベータの注意点、APIキーは本番に載せない
最後に、手を出す前の現実的な注意。まず、これはベータ。対象は OS 27 系のベータ(iOS 27 / macOS 27 / visionOS 27 / watchOS 27)と Xcode 27 ベータで、サーバーサイド言語モデルに対応した最新 OS が前提。正式版までに API が変わる可能性があると明記されている。今すぐ本番投入というより、来る正式版に備えて触っておくフェーズ。
セキュリティ面の落とし穴も大きい。開発中は .apiKey で API キーを直接渡せるけど、アプリに埋め込んだキーは出荷後のバイナリから抜き出せる。抜かれれば、自分のアカウントに課金される要求を他人に投げられてしまう。ドキュメントも「.apiKey は開発専用、リリース前にプロキシへ切り替えろ」と警告している。本番では .proxied を使い、自前のバックエンド経由で Claude の認証情報をサーバー側で付与して、アプリにはキーを載せない構成にする。ここは妥協できないポイント。
総じて、Apple の端末モデルと Claude を同じ作法で混ぜられるのは、iOS/macOS の AI アプリ設計に効く一手だと思う。まず試すなら、OS 27 ベータ環境で、軽い処理は端末モデル、重い処理だけ Claude、という二段構成を model: の差し替えで組んでみたい。そのとき認証は最初からプロキシ前提で設計して、後から本番化で慌てないようにしておく。端末の速さとプライバシー、クラウドの賢さ、その両取りをアプリ側で握れるようになったのが今回の本質で、どこで線を引くかの腕の見せどころが、また一つ増えた。
