callstackincubator/ai とは何ですか？

React Native アプリ内で LLM を動かすためのプリミティブ集。Apple のシステムモデル、llama.rn、MLC LLM という性質の異なる3つの実行経路を、Vercel AI SDK のインターフェースで包んでいる。採用判断の分かれ目はモデル品質ではなく、iOS バージョン要件とメモリ制約にある。

callstackincubator/ai は商用利用できますか？

できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

callstackincubator/ai は今もメンテナンスされていますか？

されています。最後のコミットは 71 日前です。

callstackincubator/ai はどのプログラミング言語で書かれていますか？

主に TypeScript です（GitHub の言語統計による）。

react-native-ai レビュー: プロバイダ選定と AI SDK v6 互換性の注意点

ひと目でわかる

これは何？: React Native アプリ内で LLM を動かすためのプリミティブ集。Apple のシステムモデル、llama.rn、MLC LLM という性質の異なる3つの実行経路を、Vercel AI SDK のインターフェースで包んでいる。採用判断の分かれ目はモデル品質ではなく、iOS バージョン要件とメモリ制約にある。
誰に向いている？: 採用すべきなのは、iOS 26 以降と Apple Intelligence 対応端末を対象に絞れるアプリ、あるいは GGUF モデルを自前で選定して llama.rn 経由で動かしたいチームです。サーバ側の推論基盤をすでに持ち、モデル品質を最優先するなら、このライブラリを選ぶ理由は薄いです。
商用利用できる？: できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 71 日前です。
何の言語で書かれている？: 主に TypeScript です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · callstackincubator/ai

サーバ推論を捨てる判断と、その代償

このライブラリが解く問題は、推論リクエストをサーバに送らないことです。README は「Run AI models directly on users' devices for privacy-preserving, low-latency inference without server costs」と述べており、プライバシー、レイテンシ、サーバ費用の3つを動機として挙げています。入力テキストが端末外に出ないため、機密性の高い入力を扱うアプリではデータ処理契約の設計が変わります。ネットワーク往復が消えるので、応答の初速もネットワーク状況に左右されません。

ただしこれは無料の改善ではありません。モデルの重みは端末のメモリに載り、推論は端末の CPU か NPU を占有します。サーバ側のように GPU を積み増して品質を上げる逃げ道がありません。したがってこのライブラリが向くのは、モデル品質の上限よりも、データの所在とオフライン動作を優先するアプリです。チャットボットの品質を競う用途ではなく、端末内で完結させたい処理を書くための道具だと捉えたほうが正確です。

3つのプロバイダは同じものではない

README の表は Apple、Llama、MLC の3つを並べていますが、この3つは実行基盤も配布形態も別物です。

Apple は iOS のシステムモデルをそのまま呼びます。built-in と明記されており、モデルのダウンロードが不要で、npm install @react-native-ai/apple の後に追加のリンク作業も要りません。テキスト生成、埋め込み、文字起こし、音声合成の4機能をカバーします。代わりに iOS バージョンの要件が機能ごとに異なり、テキスト生成と文字起こしは iOS 26 以降かつ Apple Intelligence 対応端末、埋め込みは iOS 17 以降、音声合成は iOS 13 以降（Personal Voice は iOS 17 以降）という区分になっています。

Llama は llama.rn をランタイムとして GGUF モデルを動かします。モデルは HuggingFace からダウンロードするため、初回起動時にネットワークとストレージが必要です。モデル ID は owner/repo/filename.gguf 形式で、README は ggml-org/SmolLM3-3B-GGUF/SmolLM3-Q4_K_M.gguf などを例に挙げています。

MLC は MLC LLM のランタイムを使い、こちらもモデルの事前ダウンロードが前提です。README が明示しているのは、Xcode で Increased Memory Limit ケーパビリティが必要という点です。この一文は重要で、MLC 経由のモデルが既定のメモリ上限に収まらないことを示唆しています。

Vercel AI SDK の上に載るという設計

このライブラリの中心的な設計判断は、独自 API を定義せず Vercel AI SDK のモデルインターフェースに合わせたことです。README のコード例では ai パッケージから generateText、embed、experimental_transcribe、experimental_generateSpeech をインポートし、model 引数に apple() や apple.textEmbeddingModel() を渡しています。呼び出し側のコードは、モデルを OpenAI や Anthropic のものから差し替えても形が変わりません。

ここで見落とせないのが互換表です。0.11 以下は AI SDK v5、0.12 以上は v6 に対応します。つまり 0.12 系へ上げる作業は AI SDK 本体のメジャー更新と不可分です。experimental_transcribe と experimental_generateSpeech という名前からも分かるとおり、文字起こしと音声合成は AI SDK 側でも実験的な位置づけで、API が安定している前提は置けません。

Llama プロバイダのモデルライフサイクルも AI SDK の抽象には収まっていません。llama.languageModel() でインスタンスを作り、model.download() で進捗コールバックを受け取り、model.prepare() でメモリにロードし、最後に model.unload() を呼ぶ。この4段階はアプリ側が明示的に管理する必要があります。generateText を呼ぶだけで済む Apple とは、運用の手間がまったく違います。

セットアップで実際に打つコマンド

プロバイダごとにインストールするパッケージが異なります。

Apple の場合:

npm install @react-native-ai/apple

追加のリンク作業は不要で、iOS 実機でそのまま動くと README は説明しています。

Llama の場合:

npm install @react-native-ai/llama llama.rn react-native-blob-util

llama.rn と react-native-blob-util が同梱されない点に注意してください。モデルのダウンロード処理は react-native-blob-util に依存していると読めます。

MLC の場合:

npm install @react-native-ai/mlc

加えて Xcode 側で Increased Memory Limit を有効にする必要があります。

開発時のプロファイリングには別パッケージを使います。

npm install @react-native-ai/dev-tools

これは Vercel AI SDK のリクエストから OpenTelemetry スパンを取得し、Rozenite DevTools 上に表示するプラグインです。前提として Rozenite がアプリにインストールされ有効になっている必要があります。README は、パネルは見えるのにチャット送信後も空のままという症状への対処として、React Native DevTools のウィンドウを閉じて開き直す手順を挙げています。古いデバッガセッションがパネルをマウントしたままテレメトリを受け取れなくなる、という説明です。

iOS 26 という要件が実質的な足切りになる

このライブラリの最も現実的な制約は、Apple プロバイダのテキスト生成が iOS 26 以降の Apple Intelligence 対応端末に限られることです。README の可用性表がそう明記しています。埋め込みだけなら iOS 17 以降で使えるので、意味検索や類似度計算を目的にするなら対象端末は広がります。しかしチャット用途を想定しているなら、対応端末を持たない利用者は最初から切り捨てることになります。

Llama と MLC はこの制約を回避できますが、別のコストに置き換わります。モデルファイルのダウンロード、端末ストレージの消費、ロード時間、そしてメモリ上限との戦いです。MLC について Increased Memory Limit が必要と書かれているのは、この戦いが現実に起きることを示しています。

もうひとつの失敗モードはバージョンの取り違えです。0.12 系は AI SDK v6、0.11 以下は v5 です。依存関係を更新する際にこの対応を誤ると、型エラーか実行時エラーのどちらかになります。experimental_ 接頭辞のついた API を使っている以上、マイナー更新でも壊れる可能性は残ります。

サーバ推論やネイティブ実装との比較

対抗馬として最も素直なのは、サーバ側でホスト型モデルを呼ぶ構成です。違いは能力ではなく、品質の上限とデータの所在です。サーバ推論ならパラメータ数の大きいモデルを使え、端末のメモリ制約も iOS バージョン要件も関係ありません。一方で、入力はネットワークを経由して事業者のサーバに到達し、レイテンシは回線品質に依存し、トークン単位の課金が発生します。react-native-ai はこの3つをまとめて捨てる代わりに、モデル品質の天井を受け入れます。どちらが優れているかではなく、どちらを諦めるかの選択です。

もうひとつの比較対象は、llama.rn や MLC のネイティブバインディングを直接使う構成です。react-native-ai の Llama プロバイダは llama.rn の上に乗っているので、下位ライブラリを直接叩けば AI SDK の抽象を挟まずに済みます。代わりに、generateText や embed といった共通インターフェース、ストリーミングやメッセージ配列の扱い、プロバイダを差し替えるときの書き換えコストを自分で負うことになります。複数プロバイダを併用する予定があるなら AI SDK 層を挟む価値はありますが、llama.rn 一本で固定するなら間接層が増えるだけです。

ライセンスと更新コストの見取り図

リポジトリのライセンスは MIT です。MIT は著作権表示とライセンス表示を残すことを条件に、改変と再配布を許す寛容なライセンスで、商用アプリへの組み込みを妨げる条項は含まれていません。ただし、これはこのリポジトリのコードに対する条件です。同梱あるいは別途インストールする llama.rn、MLC LLM、react-native-blob-util、そして各 GGUF モデルの重みにはそれぞれ別のライセンスが適用されます。モデルの配布元が商用利用を許しているかは、モデルごとに確認する必要があります。ここは法務判断の領域なので、ライセンス条項の解釈は専門家に確認してください。

更新コストの観点では、追従すべき依存が3層あります。react-native-ai 本体、Vercel AI SDK 本体、そしてランタイム側の llama.rn または MLC LLM です。0.12 系で AI SDK が v5 から v6 に上がったことが、この多層構造のコストを具体的に示しています。experimental_ 接頭辞の API を使う機能は、更新のたびに差分を読む前提で組んだほうが安全です。リリース履歴を見る限り 0.10 から 0.12 まで約4か月で到達しており、更新の間隔は短めです。

編集部の結論

採用すべきなのは、iOS 26 以降と Apple Intelligence 対応端末を対象に絞れるアプリ、あるいは GGUF モデルを自前で選定して llama.rn 経由で動かしたいチームです。サーバ側の推論基盤をすでに持ち、モデル品質を最優先するなら、このライブラリを選ぶ理由は薄いです。最初に確認するのは3点です。対象端末の iOS バージョン分布、MLC を使う場合の Xcode の Increased Memory Limit 設定、そして AI SDK のバージョンが 0.12 系の v6 と一致しているかどうか。ここが噛み合わないと、コードを1行も書かないうちに採用が破綻します。

公式情報源

コミュニティノート