Pythonから使うFoundation Models：fm CLI

1年間、Appleのオンデバイス大規模言語モデルは壁の向こうに閉じ込められていました。アクセスできるのはSwiftからだけ、しかもXcodeで自分が作ったアプリの中からだけです¹。macOS 27はその壁を取り払います。Appleは現在、fmというコマンドラインツールをOSにプリインストールして提供し、さらにpipでインストールできるPython向けのFoundation Models SDKも用意しました¹。かつてはプロジェクト、ビルド、そしてコンパイル済みSwift内のLanguageModelSessionを必要としたモデルが、いまでは1行のシェルコマンドに応答し、Jupyterノートブックの中で動くのです。Foundation Models FrameworkチームのエンジニアであるEric Gourlaouen氏は、WWDC26のセッション334でこの変化を端的にこう表現しました。「これまで、これらのモデルはSwiftコードからしか利用できませんでした」¹。変わったのは新しいモデルではありません。変わったのは、同じオンデバイスモデルが突如としてアプリの外側からスクリプト化、自動化、評価できるようになり、しかもAPIキーもクラウドコストも不要だという点です¹。

TL;DR

• macOS 27にはオンデバイスのApple Foundation Model向けにプリインストールされたコマンドラインツールfmが付属します。そのサブコマンドにはrespond（プロンプトを一度だけstdoutへ）、chat（対話セッション）、schema（構造化出力の定義）があります¹。
• fm respondにはモデル用のオプション（Private Cloud Computeへの切り替え）、画像入力、構造化出力用のスキーマといったオプションがあり、残りは--helpで一覧できます¹。
• Python SDKは同じオンデバイスモデルにPythonからアクセスでき、Python 3.10以降、Xcodeのインストール、Apple Silicon搭載Macを必要とし、pipなどのパッケージマネージャーでインストールします¹。
• このSDKはSwiftフレームワークを反映しています。respondを呼び出すLanguageModelSession、ツール呼び出し、そしてfm.respondに生成用引数として渡すfm.generableデコレーターによるガイド付き生成です¹。
• どちらの手段も既定では常に利用可能なオンデバイスモデルを使い、より高性能ながら利用上限のある大きなPrivate Cloud Computeモデルへ切り替えることもできます¹。
• 得られる成果はプロトタイピングと自動化です。意味に基づいてファイルを仕分けるシェルスクリプトや、Pandasとmatplotlibでプロンプトの各バリアントを採点するPython評価パイプラインが実現します¹。

fmコマンドラインツール

macOS 27でTerminalを開いてfmと入力すると、ツールがサポートするコマンドを表示します¹。Appleはそのうち3つを取り上げています。fm respondはモデルにプロンプトを送り、応答を返します。fm chatは対話的な会話を始めます。fm schemaは構造化出力用のスキーマを作成します¹。最もシンプルな使い方は、Eric氏が最初に実演したものです。fm respondと入力し、プロンプトを入力してEnterを押すと、しばらくしてモデルの答えがターミナルに表示されます¹。

2つのトップレベルコマンドは、きれいな線で役割が分かれています。探索かスクリプティングかです。fm chatはモデルの感触をまず掴むためのものです。質問し、追加で質問しても会話は保持され、独自のスラッシュコマンドを備えています。/modelは会話をPrivate Cloud Computeモデルに切り替え、/saveは会話を保存して後で再開できるようにします¹。スクリプト内などで、キャプチャできるインライン応答が欲しいときは、代わりにfm respondを使います。これはモデルの出力をstdoutに書き出します¹。

オプションが集まっているのはfm respondです。Eric氏は3つを明示的に挙げました。モデルオプションは、既定のオンデバイスではなくPrivate Cloud Computeモデルにプロンプトを送ります。画像オプションはプロンプトに画像を含めます。そしてスキーマオプションはfm schema objectと組み合わせ、自分が定義した構造に出力を制約します¹。彼はほかにもオプションがあると述べ、それらをすべて一覧表示するためにヘルプオプションを指し示しました¹。トランスクリプトでは各オプションを正確なフラグの表記ではなく役割で呼んでいる（画面上に文字どおり示された唯一の形式はfm schema objectです）ため、以下でオプションを説明する箇所では、文書化された動作を述べているのであって、フラグ文字列を勝手に作っているわけではありません。

モデルの選択は、最も重要な決定です。既定ではfmはmacOSに付属するオンデバイスモデルを使い、これは常に利用可能です¹。Private Cloud Compute上のApple Foundation Modelに切り替えることもでき、Eric氏はこれを「オンデバイスモデルよりずっと大きなモデルなので、複雑な問題でより良い性能を発揮する」と説明し、その代わりに利用上限があるとしました¹。既定こそが正しい出発点です。無料で、ローカルで、上限がありません。本当にその必要があるほど難しいタスクのときに、Private Cloud Computeへとグレードアップするのです。

自動化スクリプトを作る

ファイル仕分けのデモは、CLIが重要である理由を最も明快に示しています。Eric氏はドラフト版と最終版のアセットが入り混じったプロジェクトフォルダを持っており、最終版を残してバックアップし、ドラフトをアーカイブ用ディスクに移動する、繰り返し使えるスクリプトを求めていました¹。難しいのはファイルの移動ではありません。難しいのは、名前が雑然としているときに、どのファイルがドラフトなのかを判断することです。彼の言葉を借りれば、スクリプトから言語モデルを呼び出すことで、「名前が雑然としていて予測どおりに仕分けるのが難しい」場合でも「ドラフトと最終版のファイルを仕分ける」ことができるのです¹。

この形は、あらゆる「リストに対する判断」型の自動化に一般化できます。スクリプトは作業ディレクトリ内のファイルを読み込み、次にfm respondを通じてモデルに、そのリストを最終版ファイルとドラフトファイルの2つのグループに仕分けるようプロンプトを送ります¹。出力を使えるものにするため、スクリプトは事前にfm schema objectでスキーマを定義し、最終版のリストとドラフトのリストという2つのフィールドを記述して、そのスキーマをスキーマオプション経由でfm respondに渡します¹。モデルは答えをJSONとして返し、スクリプトはそれを読んで最終版をバックアップへコピーし、ドラフトをアーカイブへ移動します¹。

構造化出力のステップこそが要となる部分です。自由形式のテキストで答えが返ってくると、スクリプトは散文を解析せざるを得ず、それはLLMと対話するあらゆるシェルパイプラインで最も脆い部分です。fm schema objectでスキーマを宣言してJSONを受け取ることで、スクリプトは直接的に処理できる契約を手に入れます¹。このパターンは、Swift開発者がガイド付き生成として知っているものと同じで、ここではCLIのオプションとして公開されています¹。「モデルの判断をもとに何か決定的なことを行う」で終わるどんなタスクも、まさにこの形を求めています。プロンプト、スキーマ、JSON、実行、です。

Python SDK

2つ目の手段は、別の場面の別の人のためのものです。Eric氏はこう述べています。「もしあなたが機械学習エンジニアなら、SwiftよりPythonをよく使うかもしれません」。そしてSDKは「オンデバイスモデルをPythonコードで簡単に使えるようにします」¹。その売りはPythonのエコシステムにあります。「Pythonには機械学習とデータサイエンス向けのオープンソースパッケージの豊富なエコシステムがあります」。つまり評価パイプラインを書き、「それらのパッケージを活用して機能の品質を定量化できる」のです¹。

インストールには4つの要件があり、いずれもセッション内で述べられています。Python 3.10以降、Xcodeのインストール、Apple Silicon搭載Macが必要で、SDKはpipまたはお好みの任意のパッケージマネージャーでインストールします¹。Apple SiliconとXcodeという要件は、このパッケージがホスト型APIではなく、OSが動かすのと同じオンデバイスモデルへのバインディングであることを示すサインです。

このAPIは、Swiftフレームワークを使ったことのある人なら誰でも見覚えのある感触になるはずで²、それは意図的なものです。「APIと抽象化はすぐに馴染みあるものに感じられるでしょう」¹。LanguageModelSessionを作成し、必要に応じて指示を渡したうえで、プロンプトを添えてsession.respondを呼び出すことでプロンプトを送ります。その結果にはモデルの出力が含まれます¹。SDKはフレームワークの中核機能を引き継いでいます。テキストと画像の入力、ストリーミング応答、モデルがあなたのコードと対話できるツール呼び出し、そして構造化出力のためのガイド付き生成です¹。

これらの機能のうち2つが具体的に扱われました。ツール呼び出しについて、Eric氏はユーザーの直近の注文をいくつか取得するためにモデルが呼び出せるツールを定義し、「より個別化された情報を提供できるように」しました。これはSwiftフレームワークのToolプロトコルと同じパターンです¹。ガイド付き生成については、fm.generableデコレーターを使って望む出力構造であるItemsSuggestionオブジェクトを定義し、それを生成用引数としてfm.respondに渡しました¹。このデコレーターはSwiftの@GenerableマクロのPython版であり、生成用引数はモデルに返してほしい形を手渡す手段です。トランスクリプトはこれらを役割やオブジェクト名で示すだけでクラス本体全体を表示しないため、ItemsSuggestionは自分で定義する構造に対するこの例での名前だと捉えてください。

評価パイプライン：Pythonを使う本当の理由

このケーススタディは、Python SDKが単なる便利さであることをやめ、一つの手法になる場面です。Eric氏はユーザーが食料品カートに追加したいものを予測する機能を作っており、3種類の異なるプロンプト実装を持っていました。最小限のもの、より説明的なもの、そしてルールの完全なリストを書き出した詳細なものです¹。すべてのプロンプトエンジニアが直面する問いは、どれが実際に最良なのかであり、その正直な答えには好みではなく測定が必要です。

Appleは、Swift開発者にはここで独自の答えがあると明言しています。EvaluationsフレームワークはXcode 27に付属し、評価の作成と、イテレーションをまたいだ機能精度の追跡を容易にします¹。Python SDKは、ノートブックの中で生きるデータサイエンティストのための並行した道です。Eric氏は分析全体をJupyterから実行しました¹。

このパイプラインは、オンデバイスモデルに向けた標準的なML評価ループのように読めます。まず、大きなサーバーモデルを使って評価データを生成し、各入力と期待される出力を得ました¹。次に、すべての入力について、3つのプロンプト実装それぞれから出力を生成し、入力と出力をPandasのDataFrameの行として格納しました¹。続いて、サーバーモデルに支えられたジャッジ関数が、彼が選んだ基準に照らして各出力を採点し、それらの指標がDataFrameに戻されました¹。最後に、matplotlibが採点結果をグラフに変えました¹。

そのグラフは、プロンプトをいくらにらんでいても分からない物語を語りました。詳細なプロンプトは高い割合で生成エラーを起こし、Eric氏はこれをモデルの最大コンテキストウィンドウサイズへの到達に起因するとしました。詳細さの低い2つのプロンプトはカートに余計な品目を追加した一方で、詳細なものはより少なく追加しました。詳細なプロンプトは期待された品目をより多く取りこぼし、最小限のプロンプトは最も多くの品目をハルシネーションしました¹。どのプロンプトにもそれぞれ異なる失敗モードがあり、それを表面化させたのは測定だけでした。それこそがこのアプローチ全体を支持する論拠です。「Pythonなら、プロジェクト全体を作り直すことなく、ノートブックから直接そうしたイテレーションを素早く回せます」とEric氏は語りました¹。

どちらを選ぶべきか

これまでの契約から、いくつかのルールが導かれます。

シェルスクリプトに判断が必要なときはfm respondを選びましょう。 雑然としたファイル名の仕分け、入力された1行の分類、非構造化テキストからのフィールド抽出などです。fm schema objectとスキーマオプションと組み合わせれば、スクリプトは散文を解析する代わりにJSONを処理できます¹。

スクリプティングではなく探索しているときはfm chatを選びましょう。 モデルが自分のプロンプトをどう扱うかの最初の感触を得るのに最も速い方法で、/modelでPrivate Cloud Computeにエスカレートし、/saveでセッションを保持できます¹。

単に呼び出すだけでなく測定したいときは、Python SDKを選びましょう。 プロンプトが2つ以上あって、どちらが優れているかを知る必要が出た瞬間こそ、ノートブックとPandasとmatplotlibのループの出番です。オンデバイスモデルは無料でローカルなので、請求書なしで評価セット全体を実行できるからです¹。

既定はオンデバイスモデル、Private Cloud Computeへは意図的にグレードアップしましょう。 オンデバイスモデルは常に利用可能で利用上限がありません。Private Cloud Computeはより大きく、複雑な問題でより優れていますが利用上限を伴うので、それに値するタスクのために取っておきましょう¹。

ここでプロトタイプを作り、Swiftで出荷しましょう。 Eric氏自身の言い回しでは、これらのツールは「Xcodeプロジェクトと並行して、プロンプトをプロトタイプして評価する方法として」、あるいは「それ単独で、モデルを新しいやり方で使うために」利用できます¹。食料品アプリの例は「Swiftで実装する前に」Pythonでプロンプトをプロトタイプします¹。CLIとSDKはアイデアから証拠までのループを短縮しますが、機能が最終的に落ち着く先は依然としてアプリです。

FAQ

fmコマンドラインツールとは何ですか？

fmはmacOS 27にプリインストールされて付属するコマンドラインツールで、TerminalアプリからオンデバイスのApple Foundation Modelにアクセスします¹。そのサブコマンドには、モデルにプロンプトを送って応答を表示するrespond、対話的な会話を始めるchat、構造化出力を定義するschemaがあります。既定のモデルがオンデバイスで動くため、APIキーもクラウドコストもなしに実行できます¹。

fmから構造化されたJSONを得るにはどうすればよいですか？

fm schema objectでスキーマを定義し、そのスキーマをスキーマオプション経由でfm respondに渡します。モデルはそのスキーマに一致するJSONとして答えを返すので、スクリプトは自由テキストを解析する代わりに直接処理できます¹。この仕組みはフレームワークのガイド付き生成のCLI版です¹。

Foundation Models Python SDKには何が必要ですか？

Python 3.10以降、Xcodeのインストール、Apple Silicon搭載Macです¹。pipまたはお好みの別のパッケージマネージャーでインストールします。Apple SiliconとXcodeという要件は、SDKがホスト型APIを呼び出すのではなく、OSが動かすのと同じオンデバイスモデルにバインドすることを反映しています¹。

Python SDKはSwiftフレームワークとどう違いますか？

同じモデルであり、意図的に馴染みのあるAPIを別の言語で提供したものです。LanguageModelSessionを作成し、respondを呼び出し、ツールを公開し、生成用引数としてfm.respondに渡すfm.generableデコレーターを通じてガイド付き生成を使います¹。Pythonを選ぶ理由はそのエコシステムです。Pandas、matplotlib、Jupyter、そして評価パイプライン向けのデータサイエンススタックの残りは、Swiftほど直接的には届かないものです¹。

オンデバイスモデルの代わりにPrivate Cloud Computeをいつ使うべきですか？

fmもSDKも既定でオンデバイスモデルを使い、これは常に利用可能で利用上限がありません¹。問題がより大きなモデルを必要とするほど複雑なときは、fm respondのモデルオプションやfm chatの/modelコマンドからPrivate Cloud Computeに切り替えましょう。その場合、利用上限を伴うことは受け入れることになります¹。

Apple Ecosystemクラスター全体はこちらです。これらのツールが反映するSwiftの基盤についてはFoundation Modelsフレームワーク解説、モデルがツールをどう使うかについてはiOS 27のツール呼び出し制御、オンデバイス対より大きなモデルの選択についてはFoundation Modelsのエージェント型ワークフロー、そしてエージェント中心のワークフローのIDE内側についてはXcode 27のコーディングエージェントをご覧ください。ハブはApple Ecosystemシリーズにあります。エージェントを使ったiOS構築のより広い全体像については、iOSエージェント開発ガイドをご覧ください。