AnyLanguageModel 1.0はAppleのFoundation Modelsに近いAPIで、端末内と外部モデルを選べます。ツール呼び出しや構造化生成の対応も拡充しました。 共通APIでもモデルごとの能力や送信先は異なります。端末とクラウドを切り替える条件、認証、出力の検証を設計することが焦点です。 端末内と外部モデルを共通のSwift APIへ Hugging Faceは10月20日、AnyLanguageModel 1.0を紹介しました。AppleのFoundation Modelsフレームワークに近いAPIを使い、アプリが利用するモデルや提供元を選べるライブラリーです。端末内の推論と外部の推論にはそれぞれ利点があり、共通APIで作業に合うモデルを選ぶ狙いです。同時にswift-huggingface 1.0とswift-xet 1.0も紹介しています。HubからSwiftアプリへモデルを取得する経路を支えます。今回の発表は開発者向けの統合であり、端末に含まれる標準モデルそのものを更新する発表ではありません。対応するOSやモデルの条件は機能ごとに異なります。 ツールと構造化生成を複数の提供元で扱う 原文は、すべての提供元でのツール呼び出しと構造化生成、画像入力への対応を説明しています。ローカルではllama.cpp、MLX、Core MLを使い、外部ではOpenAI、Anthropic、Gemini、Ollama、Hugging Face Inference Providersなどを案内しています。一部の機能はOS 27に対応します。対象はSwiftでAI機能を開発するチームです。モデルを切り替える際には、再利用できない推論内容を要求から外す処理もあります。APIキーは固定の文字列だけでなく、処理を通じて短期の認証情報を取得できるとしています。共通のセッションコードを使えることは、試作や提供元の比較を簡単にする可能性があります。ただし、生成品質やツールの判断はモデルによって異なります。共通形式で呼べることと、同じ業務を任せられることは分ける必要があります。 切り替えの条件とデータ経路を明示する 実務では、ローカルで完結する作業と外部へ送信する作業の境界を決めることが論点です。共通APIの背後で送信先が変わる場合、利用者が情報の扱いを理解できる表示や設定が必要と考えられます。ツール呼び出しや構造化生成も、形式が正しいだけでは内容の正しさを保証しません。対象モデルごとの試験を行い、失敗した場合の戻し先を決める方法があります。モデルのダウンロード量、端末のメモリー、外部APIの費用は、選択肢ごとに評価する対象です。認証情報をアプリへ埋め込む構成と、サーバー経由で取得する構成の違いも確認する必要があります。原文はLinuxでの利用も紹介しており、サーバーとのコード共有を検討できます。利用環境を増やす際は、共通化できる部分と個別に検証する部分を整理し、更新後も同じ評価を続けることが判断材料になります。