Foundation Lab を採用する前に読む: Apple Foundation Models の実行環境を1画面に集約する Swift 製ワークベンチ

Foundation Lab が埋めようとしている穴

Foundation Models を触るとき、最初に困るのはモデルそのものではなく周辺の散らかり方だ。プロンプトをどこに置いたか、temperature をいくつにしたか、どのツールを有効にしたか、そのとき何が返ってきたか。Xcode のプレイグラウンドで試すと、この4つが別々の場所に落ちる。Foundation Lab はここを1つのアプリにまとめる。README は「prompt, configuration, tools, transcript, and run evidence in one place」と表現していて、狙いは実験の再現性をアプリ側で持つことにある。対象読者は Foundation Models を使うアプリを書いている開発者で、API の形を確かめながら自分のプロンプトを育てたい層だ。フレームワークの入門記事ではなく、動くレシピを出発点に1か所だけ変えて即実行する、という反復を前提にしている。

Library、Playground、Runs という3つの行き先

アプリの構造は3つの目的地で説明されている。Library は18個の編集可能なレシピ、14個のガイド付きラボ、3つのワークショップ、保存済み実験、1つのワークスペースを並べる場所だ。Playground はプロンプトと instructions を編集し、モデルとツールを設定し、応答をストリーム表示し、音声入力を使い、実験を保存し、Swift をエクスポートする。Runs は永続化された実行の状態、設定、トランスクリプトのイベント、ツール呼び出し、タイミング、トークン使用量を検査する。Library の項目は開き方が4種類に分かれていて、Recipe は Playground で開いて編集と保存ができ、Guided Lab は特定の API 専用の画面を持ち、Workshop はスキーマ、言語、Xcode 27 の例をまとめるがトップレベルの行き先は増やさない。Workspace は Adapter Comparison のような専用ツールを開く。この分類は、汎用のチャット画面に何でも詰め込むのを避けるための設計判断だと読める。

実行の流れと FoundationLabCore の切り分け

リポジトリはサーフェスごとに分かれている。Foundation Lab ディレクトリがネイティブの Library、Playground、Runs、ガイド付きラボ、ワークスペースを持ち、FoundationLabCore が UI に依存しないリクエスト、結果、ユースケース、プロバイダ、実験モデルを担う。つまりモデル呼び出しの組み立てと画面が分離されていて、実験の設定や実行結果の型は UI 側から独立して扱える。トランスクリプト、コンテキスト、履歴、システムツールは外部パッケージの rryam/FoundationModelsKit に置かれ、ツールレシピは共有の FoundationModelsTools パッケージを使う。9種類のツールレシピが用意されていて、Open-Meteo 経由の天気、キー不要の Search1 検索、連絡先、カレンダー、リマインダー、位置と場所検索、許可済みの HealthKit データ、Apple Music、Web メタデータが並ぶ。ユーザーデータを変更しうるツールはアプリ側のワークフローで確認を要求する。

動かすまでの手順と、実機が要るという事実

取得は clone して Xcode プロジェクトを開くところから始まる。git clone のあと cd して open FoundationLab.xcodeproj を実行する。コマンドラインからのビルドは xcodebuild に -project FoundationLab.xcodeproj、-scheme 'Foundation Lab'、-destination 'generic/platform=macOS'、CODE_SIGNING_ALLOWED=NO を渡す形で、iOS 側は destination を 'generic/platform=iOS Simulator' に変える。要件は iOS 26.0+ または macOS 26.0+、オンデバイス実行には Apple Silicon、ライブのモデル実行には Apple Intelligence が有効であること、そして Xcode 26.6 か Xcode 27 だ。README は「Live model execution requires a compatible physical device」と明記していて、シミュレータのビルドはコンパイルとインターフェース確認までと割り切られている。ここは見落とすと詰まる。手元に Apple Silicon の実機がなければ、このアプリの中心的な価値である実行記録はほぼ空のままになる。

Xcode 26.6 と 27 で見えるラボが変わる

プロジェクトは Xcode 26.6 と Xcode 27 の両方でビルドできる。OS 27 SDK で導入された API はコンパイラと availability の両方でゲートされているため、コアのアプリは Xcode 26 でも使える。Xcode 27 でビルドしたときだけ追加で見えるラボには、PrivateCloudComputeLanguageModel、共有 LanguageModel の実行、画像添付と参照、明示的なツール呼び出しモード、動的プロファイルと reasoning 制御、トランスクリプト検査と履歴変換、コンテキスト予算の可視化、動画を扱うプロバイダブリッジを含むカスタムモデルエグゼキュータがある。Tools/ImageInputProbe の画像入力プローブは、その時点の SDK が実用上どこまでデコード済みバッファを扱えるかの境界を測るために置かれている。つまり Xcode のバージョンは単なるビルド手段ではなく、試せる API 集合を直接決める。チームで使うなら、どの Xcode を基準にするかを先に決めておかないと、ラボの有無について話が噛み合わなくなる。

アダプタ比較は macOS 側のワークスペースに隔離されている

Adapter Comparison は macOS でのみ、.fmadapter パッケージを読み込んで同じプロンプトを素のベースモデルとアダプタ適用済みセッションの両方に流し、2つのストリームと time-to-first-token および総所要時間の診断値を並べる。学習とエクスポートはアプリの中では完結せず、同梱の fmas CLI 側に残っている。手順は python3.11 で venv を作り、Tools/AdapterStudio を editable でインストールし、fmas init、fmas setup、fmas train-adapter --help、fmas export --help と進む。アプリが推論の比較を担い、CLI が学習と書き出しを担う分担だ。ここは評価と生成を1つのツールに押し込まなかった判断として妥当だが、Python 3.11 の仮想環境とモデル学習の計算資源が別途必要になる。アダプタを作る気がないなら、このワークスペースは使わない。

afm CLI は別リポジトリに切り出されている

コマンドラインから Foundation Models を扱う afm は、このリポジトリには含まれていない。README によれば standalone の rudrankriyam/Foundation-Models-Framework-CLI リポジトリから提供され、公開の FoundationModelsKit パッケージを使い、CLI のリリースをアプリのリリースから独立させている。導入は brew tap rudrankriyam/tap のあと brew install afm。ソース、ドキュメント、リリース自動化、サーバーモードの実装は CLI 側のリポジトリを見ることになる。この分離は、アプリと CLI の更新頻度が違うことを認めた構成だ。Foundation Lab を評価するとき、CLI の機能まで含めて判断しようとすると、実際には別プロジェクトを2つ読むことになる。アプリ側の README には CLI の詳細はない。

向かない場面と、代わりに何を使うか

最大の制約は実行環境だ。ライブのモデル実行には対応する実機が必要で、シミュレータはコンパイルと画面確認までしか担わない。CI でモデル出力を検証したい、Linux 上でバッチ処理を回したい、といった用途はこのアプリの守備範囲外になる。その場合は afm CLI のサーバーモードやスクリプタブルなワークフローを別リポジトリで確認するほうが筋が良い。もう1つの制約は対象 OS だ。iOS 26.0+ と macOS 26.0+ が要件で、Apple Intelligence が有効でなければならない。古い OS を切れないプロダクトや、Intel Mac しかない環境では、このアプリで学んだ設定をそのまま自分のアプリに持ち込めない。加えて、API の形そのものを最速で把握したいだけなら、Xcode のドキュメントと自分の最小プロジェクトで足りる。Foundation Lab の価値は、18個のレシピ、14個のラボ、3つのワークショップという既製の出発点と、実行記録が残ることにあり、そこに価値を感じないなら依存を増やす意味は薄い。

ライセンスとメンテナンスの見え方

ライセンスは MIT で、リポジトリはアーカイブされていない。1.0.0 が 2026-06-20、1.1.0 が 2026-06-22、1.2.0 が 2026-06-23 と短期間に並び、最終 push は 2026-08-25 なので、少なくともこの期間は動いている。MIT なのでアプリ内のレシピや構成を自社コードに取り込むことは可能だが、同梱の外部パッケージ、FoundationModelsKit、FoundationModelsTools、AdapterStudio の Python 側、afm CLI はそれぞれ別の配布物として扱う必要がある。MIT の表示義務がどこまで及ぶかは個別に確認が要る話で、ここで断定はしない。追跡コストの面では、Xcode 27 のラボが OS 27 SDK の API に依存してゲートされている以上、SDK の更新に追随してビルド可否が変わる可能性がある。採用を決める前に、自分の基準 Xcode で xcodebuild の macOS と iOS Simulator の2コマンドが通るか、そして実機で1つレシピを走らせて Runs に記録が残るかを確認しておくとよい。

編集部の結論

Foundation Models の API を触り始めた iOS/macOS 開発者、とくにプロンプトと設定と実行記録を散らかしたくない人には向いている。逆に、シミュレータだけでモデル出力を確認したい人、Linux や CI 上でモデルを走らせたい人には向かない。最初に確認すべきは、手元に Apple Intelligence を有効にした Apple Silicon 実機があるかどうか、そして Xcode 26.6 と Xcode 27 のどちらで開くかだ。Xcode 27 のラボ群は OS 27 SDK の API に依存してコンパイラ側でゲートされているため、26.6 で開いた時点で見えるラボの数は変わる。

公式情報源

1. Issues
2. License: MIT
3. README
4. Releases
5. rudrankriyam/Foundation-Models-Framework-Lab on GitHub