Apple Foundation Models 統合用 Claude

Anthropic は ClaudeForFoundationModels Swift パッケージを導入し、Claude を Apple の Foundation Models フレームワークに統合しました。この統合により、開発者は Claude をサーバーサイドの言語モデルとして使用でき、Apple のオンデバイスモデルで使用されている同じ LanguageModelSession API を利用できるため、ローカルとクラウドベースの推論間をシームレスに切り替えることができます。

ローカルとクラウド推論のための統一 API

この統合の主な利点は、Apple の LanguageModel プロトコルが提供する抽象化レイヤーです。Claude をこのプロトコルに適合させることで、開発者はプロンプトへの応答、ストリーミング、ガイド付き生成、ツール呼び出しなどに同じセッション API を使用してモデルを操作できます。

開発者はタスクの複雑さに応じて、Claude と Apple のオンデバイスモデルのどちらを使用するかを決定できます:

  • オンデバイスモデル: 速度、プライバシー、オフラインでの利用が最適化されており、軽量タスクに適しています。
  • Claude: より大きなコンテキストウィンドウ、先端的な推論、またはウェブ検索やコード実行といったサーバーサイドツールが必要なタスクに推奨されます。

両プロバイダーが同じ LanguageModelSession API を使用しているため、切り替えはセッション内の model: 引数を入れ替えるだけで済みます。

技術要件とインストール

このパッケージは現在ベータ版で、OS 27 ベータで導入されたサーバーサイド言語モデル API を対象としています。以下の要件を満たす必要があります。

  • オペレーティングシステム: iOS 27、macOS 27、visionOS 27、または watchOS 27（すべてベータ）。
  • 開発ツール: Xcode 27（ベータ）。
  • 認証: 開発用に Claude Console から取得した Claude API キー。

インストールするには、開発者は ClaudeForFoundationModels パッケージを Package.swift に追加するか、Xcode の「Add Package Dependencies」メニューから追加し、FoundationModels フレームワークと共にインポートします。

主な機能と実装の詳細

モデル選択と機能

モデル識別子は ClaudeModel 列挙型で管理されます。.opus4_8（claude-opus-4-8 にマッピング）などの定数は特定の機能を持ち、パッケージがモデルがサポートするリクエストフィールドのみを送信することを保証します。これにより、サポートされていないフィールドを API に送信した際のハードエラーを防止できます。

努力度レベル

開発者は fixedEffort: パラメータを使用して特定の努力度レベル（low、medium、high、xhigh、max）を固定できます。これはフレームワークの一般的な推論ヒントよりも優先されます。フレームワークの推論レベルは「high」で止まりますが、fixedEffort パラメータにより .xhigh と .max レベルにアクセスできます。

構造化出力とストリーミング

  • 構造化出力: 型に @Generable を付与することで、開発者は構造化出力を要求できます。選択したモデルがこの機能をサポートしていない場合、パッケージは LanguageModelError.unsupportedGenerationGuide エラーをスローします。
  • ストリーミング: streamResponse(to:) メソッドは増分応答を提供します。返される各要素は、差分ではなく応答の累積スナップショットです。

ツール使用: クライアント側 vs. サーバー側

  • クライアント側ツール: フレームワークの標準 tools: 配列が使用されます。Claude がツールを要求した際、フレームワークはデバイス上でこれらのツールを呼び出します。
  • サーバー側ツール: ウェブ検索やウェブ取得などのツールは Anthropic のインフラ上で実行されます。これらは ClaudeLanguageModel を通じて設定され、トランスクリプト上では ClaudeServerToolSegment カスタムセグメントとして表示されます。

認証とセキュリティ

API キーが出荷バイナリに露出するのを防ぐため、Anthropic は 2 つの認証モードを提供しています：

  1. API キー（開発）: 素早いプロトタイピングに使用されます。キーはバイナリから抽出可能なため、プロダクションでは推奨されません。
  2. プロキシ（本番）: リクエストは開発者自身のバックエンドを経由します。リレーがサーバー側で Claude API 資格情報を付加するため、アプリにキーが含まれません。プロキシが呼び出し元を認可するためにカスタムヘッダーを提供できます。

エラーハンドリングと制限事項

パッケージは Claude API のエラーを Apple の LanguageModelError ケースにマッピングします。たとえば、HTTP 429 は .rateLimited に、コンテキストウィンドウのオーバーフローは .contextSizeExceeded にマッピングされます。

一部の Messages API 機能は Apple のプロトコルに表現されていないため利用できません。具体的には、プロンプトキャッシュ制御（自動的にキャッシュは適用されます）、ストップシーケンス、バッチ処理、トークンカウント API などです。

コミュニティの洞察と見解

業界の観察者や開発者は、この動きが Apple にとって LLM を商品化しつつ、ユーザー体験とハードウェアエコシステムのコントロールを維持する戦略的転換であると指摘しています。

Apple が LLM を商品化しながら UX のコントロールを保っているということです。彼らはハードウェア企業であり、AI 用に最適なマシンを販売し続けるでしょう。

他の開発者は API キーの配布や、ユーザーに自分のキーを提供させるユーザー体験に懸念を示しています。一部は、この抽象化レイヤーが Apple の長期的な戦略であり、オンデバイス機能が向上するにつれて、開発者が他のクラウドモデルを統合しやすくするためのものだと指摘しています。

これは単に Apple がオンデバイスモデルの向上を計画しているだけだと思います… 開発者が外部 LLM を呼び出すすべてのコードでこれを使用すれば、Apple のモデルがより高性能になり、利用ケースが増えるにつれて、個々の呼び出し箇所で簡単に切り替えられるようになるでしょう。

Sources