ChatJS を採用する前に読む: 120 モデル対応チャット基盤の構成と依存の実態

ChatJS が埋めようとしている穴はどこにあるか

AI チャットの画面自体は、AI SDK のような道具を使えば短時間で動くものが作れる。難しいのはその先で、会話の永続化、ページ再読み込み後も続くストリーミング、会話の分岐、公開リンクでの共有、画像や PDF の添付、複数プロバイダの切り替えといった周辺を揃える作業になる。ChatJS はこの周辺部分を最初から入った状態で配ることを狙っている。README の冒頭は「Stop rebuilding the same AI chat infrastructure」と述べ、認証、120 以上のモデル、ストリーミング、ツールを備えた土台だと説明している。想定読者は、チャットそのものが製品ではなく、チャットを組み込んだ別の何かを作りたい開発者だ。UI コンポーネントの見た目を競う種類のプロジェクトではなく、アプリケーションの骨格を配る種類のプロジェクトだと考えると位置づけが掴みやすい。

モノレポの中身と、実行される単位

リポジトリは 4 つの単位に分かれている。apps/site がランディングページ、apps/chat が Next.js のチャットアプリ本体、apps/docs がドキュメント、packages/cli が対話式の雛形生成 CLI で、公開されている npm パッケージはこの CLI にあたる。つまり利用者が最初に触る成果物はアプリのソース一式であり、CLI はそれを手元に展開するための入口という関係になる。チャットアプリ側の技術選択は README のスタック一覧に明示されていて、Next.js の App Router と React Server Components、AI SDK、AI Gateway、Better Auth、Drizzle ORM、PostgreSQL、Redis、Vercel Blob、tRPC、Zod、Zustand、Pino、Langfuse といった面々が並ぶ。データの流れとしては、tRPC と Zod で型付けされた境界を通して会話データが PostgreSQL に入り、Redis がキャッシュと再開可能ストリームを担い、ファイルは Blob に置かれる、という分担が読み取れる。ここで注意したいのは、この分担が特定のホスティング事業者の製品名で書かれている点だ。PostgreSQL と Redis は自前で立てられるが、AI Gateway と Vercel Blob は README の記述からは代替実装の存在が分からない。

CLI が生成する設定と、選んだ機能が要求する環境変数

セットアップの入口は 1 行で、README には npx @chat-js/cli@latest create my-app とある。このコマンドは対話形式で、ゲートウェイ、機能、認証方式の選択を順に尋ね、回答に応じて chat.config.ts を生成し、その選択で必要になる環境変数の一覧を出力する、と説明されている。生成された設定ファイルが事実上の単一の情報源になる点は、後から機能を足すときの見通しに関わる。たとえば Web Search、画像生成、コード実行、MCP といった項目は README の機能一覧に並んでいるが、それぞれが追加の資格情報や外部サービスを要求する可能性がある。CLI が変数の一覧を出すという設計は、この種の雛形では珍しく実用的で、どの機能を選んだ結果どの鍵が必要になったのかを後から追える。開発時のポートは固定ではなく、.env.worktree.local に CHATJS_DEV_SLOT を設定してワークツリーごとに 10 ポートの範囲を予約する仕組みで、範囲内のオフセットは chat が 0、Electron が 1、site が 2 と .worktree-env.json で定義されている。README はポートを決め打ちせず bun dev:info を実行して確認するよう指示している。

ストリーミングと分岐を支える Redis の位置づけ

機能一覧で目を引くのは Resumable Streams と Branching の 2 つだ。前者はページを再読み込みしても生成が続くという挙動で、これを成立させるにはサーバー側に進行中のストリームを保持し、再接続時に途中から読み出せる場所が要る。README のスタック表では Redis の役割が「Caching & resumable streams」と明記されているので、この機能は Redis の可用性に直接ぶら下がっていると読める。Branching は会話を分岐させて別案を試す機能で、会話の木構造をデータベース側でどう表現するかという設計判断を含むが、その詳細は README には書かれていない。ここは導入前にソースを読むべき箇所だ。分岐の粒度、分岐元の参照方法、削除時の扱いといった点は、後から仕様を変えるとデータ移行が必要になりやすい。Redis を落とせない構成である以上、可用性の要件はチャット機能そのものと同じ水準になる。

Desktop App と Electron が加える配布の負担

README は Electron で macOS、Windows、Linux のネイティブアプリとしてパッケージできると述べており、リリースの節では @chat-js/electron のインストーラが GitHub Releases に公開されると説明されている。これは Web 版とデスクトップ版を同じコードベースから出せる利点がある一方、配布物としての管理が増えることを意味する。コード署名、更新の配信、プラットフォームごとのビルドといった作業は Web アプリだけなら発生しない。さらに開発時のポート割り当てで Electron に専用のオフセット 1 が与えられている点は、デスクトップ版が Web 版と並行して動く前提でワークフローが組まれていることの表れだ。Web だけで完結する用途なら、この層は使わない選択ができる。逆にデスクトップ配布を要件に含めるなら、Changesets によるリリース運用と GitHub Releases への公開経路まで面倒を見る必要がある。

リリース運用と Apache-2.0 が意味する範囲

リリースはリポジトリ全体で Changesets によって駆動される。変更した公開対象パッケージごとに changeset を追加し、生成されたバージョン PR をマージする流れで、@chat-js/cli のような公開パッケージは npm に、@chat-js/electron のインストーラは GitHub Releases に公開される。CLI のバージョンは 0.8.0、0.7.0、0.6.5 と続いており、0 系のままである点は利用者にとって無視できない。0 系ではマイナー更新に破壊的変更が入り得るのが通例で、生成される chat.config.ts の形が変われば既存プロジェクトの追随作業が発生する。ライセンスは Apache-2.0 で、これは寛容なライセンスとして知られるが、特許条項や帰属表示の扱いなど条件の解釈は用途によって変わる。ここで法的な助言はできないので、配布形態が組み込み製品なのか社内ツールなのかによって、何を残す必要があるかを自組織の基準で確認してほしい。

同じ目的に対する別の取り方

似た目的の出発点として、AI SDK の公式テンプレート群がある。あちらは Next.js のチャット UI とストリーミングの接続を示す最小構成に近く、認証、添付、分岐、共有、コード実行、MCP といった周辺は自分で足す前提だ。ChatJS との違いは抽象度の方向にある。AI SDK のテンプレートは土台を薄く保ち、足すものを利用者が選ぶ。ChatJS は逆に、周辺を最初から詰め込んだ状態を配り、不要なものを外す。どちらが良いかは、外す作業と足す作業のどちらが自分のチームに向いているかで決まる。ChatJS の場合、外す作業はスタック一覧に名前の挙がっているサービス、とくに AI Gateway と Vercel Blob との結び付きをほどく作業を含み得る。この結び付きの強さは README からは判断できないので、実際に生成されるコードを見るまでは、AI SDK テンプレートからの出発のほうが可搬性は高いと見ておくのが無難だ。

編集部の結論

自前のチャット UI と認証、ストリーミング、添付、分岐をゼロから組むコストを避けたい Next.js チームには向く。逆に、Vercel の AI Gateway や Blob を使わない構成を前提にしている場合、PostgreSQL と Redis を自前で運用したくない場合、あるいは Electron のデスクトップ配布まで面倒を見たくない場合は、この構成をそのまま採る意味が薄い。採用前に確認すべきは、CLI が生成する chat.config.ts の中身と、選択した機能に対応する環境変数の一覧が自分のインフラで満たせるかどうか。とくに AI Gateway と Vercel Blob の 2 つは差し替え前提の抽象化が README からは読み取れないため、ここが契約上の制約になるかどうかを最初に確かめる。

公式情報源

1. FranciscoMoretti/chat-js on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases