6月に、WWDC26で発表されたAppleのFoundation ModelsフレームワークがShikishaの守備範囲にかなり食い込んできたこと、そしていずれ自分でも触ってみて、Shikishaがその上にどう乗るべきか見極めたいと書いた。それを今回やった。FoundationModelsChatModel は新しいオンデバイスのバックエンドで、SystemLanguageModel を裏側で使う。APIキーもbase URLも要らず、ネットワーク通信も一切発生しない。OpenAI、Anthropic、Googleの各バックエンドと同じ ChatModel プロトコルに準拠しているので、既存のチェーンでそれらのどれかをこれに差し替えても、他のコードは一行も変える必要がない。システムメッセージはセッションのinstructionsになり、最新のターンとそれ以前の履歴がプロンプトになる。ストリーミングは、Apple側の累積レスポンスのスナップショットを、Shikishaの他のバックエンドが期待するのと同じ差分(delta)に変換している。
モデル呼び出し自体より、ゲーティングの方に気を遣った。Shikishaのパッケージの対応OSは macOS 14 / iOS 17 が下限で、この一つのバックエンドのためにそれを引き上げたくはなかった。Appleのフレームワークは macOS 26 / iOS 26 専用なので、この型は #if canImport(FoundationModels) と @available(macOS 26, iOS 26, *) の後ろに置いてある。古いツールチェーンではそもそもコンパイル対象から外れ、新しいツールチェーンではコンパイルはされるが実行時にゲートがかかる。FoundationModelsはパッケージの依存関係ではなく弱リンクのシステムフレームワークなので、追加コストもゼロだ。ツール呼び出しは今回のv1では対象外にした。READMEとDocCのガイドも見直して、「手元にAPIキーがない」ときの選択肢としてOllamaの隣にこのバックエンドを並べておいた。まさにそういう場面でこそ効いてくるものだから。
今回のポイントは、オンデバイスのモデルがちゃんと答えを返すこと自体ではない。四つ目のプロバイダーを足すのに、Shikishaの他の部分を一切変えずに済んだことの方だ。共通の ChatModel の語彙をわざわざ作ったのは、そもそもそのためだった。