Dyad を選ぶ前に読む: src/pro のライセンス境界とローカル実行の実際
Local, open-source AI app builder for power users ✨ v0 / Lovable / Replit / Bolt alternative 🌟 Star if you like it!
ひと目でわかる
- これは何？
- Dyad はローカルで動く AI アプリビルダーで、API キーを自分で持ち込む設計を取る。リポジトリの大半は Apache 2.0 だが src/pro だけは Functional Source License 1.1 であり、この境界が導入判断の中心になる。
- 誰に向いている？
- 自分で API キーを管理でき、生成されたコードを手元に置いたままにしたい個人開発者や小規模チームには向く。逆に、ホスティングまで含めた運用を外注したい場合や、src/pro のコードを自社サービスに組み込みたい場合は、まず LICENSE と src/pro/LICENSE の全文を読み、Functional Source License 1.1 が何を許し何を禁じるかを確認してから判断すべきだ。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
クラウド型ビルダーが残す3つの摩擦
Lovable、v0、Bolt といったクラウド型の AI アプリビルダーは、ブラウザを開けばすぐ使える代わりに、生成したコードが事業者の環境に置かれる。API 利用料は事業者の価格表に従い、使うモデルも事業者が決める。Dyad の README はこの3点を逆方向に振っている。ローカルで動くこと、AI の API キーを自分で持ち込むこと、Mac と Windows の両方で動くこと。README の表現を借りれば「no lock-in」で、生成物と鍵が自分の手元に残る。対象は、鍵の管理やローカル環境の面倒を見ることを厭わないパワーユーザーだ。README 自身がそう名乗っている。
BYO キーが意味するもの: モデル選択は自分の責任になる
トピック一覧には anthropic、openai、gemini、deepseek、qwen、ollama が並ぶ。つまり単一のモデル事業者に固定されておらず、ローカル推論の ollama も選択肢に入る。クラウド型ツールでは提供側がモデルを差し替え、価格も追随して変わる。Dyad ではその判断が利用者側に移る。どのモデルをどの作業に割り当てるか、トークン消費がいくらになるかは自分で決める。自由度と引き換えに、鍵の漏洩対策と費用の把握も自分の仕事になる。ここは README が利点として挙げる点だが、運用コストの移転でもある。
配布形態: 署名なしの即時利用を選ぶか、ソースからビルドするか
README の導線は「No sign-up required」で、dyad.sh のダウンロードページから各プラットフォーム向けのビルドを取得する形になっている。アカウント作成やクレジット購入の手順は README に書かれていない。ソースから動かしたい場合は CONTRIBUTING.md が入口として案内されている。プライマリ言語は TypeScript で、トピックに nextjs と react が含まれるため、Node.js 系のツールチェーンが前提になる。ただし README には具体的なビルドコマンドや必要な Node のバージョンは記載されていない。ここは実際に手を動かす前に CONTRIBUTING.md を開いて確認するしかない部分だ。
リポジトリを二分するライセンス境界
README のライセンス節は明快に線を引いている。src/pro の外側は Apache 2.0、src/pro の内側は Functional Source License 1.1 Apache 2.0 で、それぞれ LICENSE と src/pro/LICENSE に全文がある。リポジトリのメタデータ上は NOASSERTION と表示されるが、これは GitHub が単一の SPDX 識別子に落とせなかったという意味であって、ライセンスが不明という意味ではない。実務上の帰結はこうだ。src/pro のコードを自社プロダクトに取り込む、あるいは再販するといった使い方は、Apache 2.0 の部分とは別の条件に服する。FSL は一定期間後に Apache 2.0 へ移行する設計のライセンスとして知られるが、具体的な期間や許諾範囲は必ず原文で確認してほしい。ここで法的助言はできない。
向かないケース: 鍵を渡したくない、ビルドを任せたい
Dyad は AI プロバイダの API キーを自分で用意する前提のツールだ。組織のポリシーで個人が外部 API キーを発行できない場合、あるいはキーの管理を情報システム部門に集約している場合、この前提そのものが障害になる。また、デプロイやホスティングまで含めてワンストップで任せたい用途にも向かない。README が掲げるのはローカル実行と鍵の持ち込みであり、そこから先の運用は利用者の側にある。加えて README は Mac と Windows を挙げるのみで、Linux については記述がない。Linux デスクトップを主力にしているなら、対応状況を自分で確認する必要がある。
比較軸としての Cursor と Aider: 生成するか編集するか
同じくローカルで動き API キーを持ち込むツールに Cursor や Aider があるが、出発点が違う。Cursor は既存のコードベースを編集するエディタであり、Aider はターミナルから既存リポジトリに差分を当てる。Dyad はアプリを新規に組み立てる側から入る。README が比較対象に挙げるのは Lovable、v0、Replit、Bolt で、いずれもゼロからアプリを作る体験を売りにしている。つまり Dyad の位置は「クラウド型ビルダーのローカル版」であって「AI 対応エディタ」ではない。既存の大規模リポジトリに少しずつ手を入れたいなら、Dyad よりも編集特化のツールのほうが素直に収まる。
更新頻度とバージョンの読み方
直近のリリースは v1.14.0 で、その前に v1.14.0-beta.1 と beta.2 が続く。ベータを先に切ってから安定版を出す流れが定着していると読める。最終 push は 2026-09-09 で、安定版リリースと同じ日だ。更新は活発だが、その分だけ追従の手間も発生する。自分の鍵とローカル環境で動かす以上、破壊的変更があっても自動で巻き戻してくれる人はいない。どのバージョンに固定するかは自分で決めることになる。beta を試すか安定版だけを追うかも同じだ。
編集部の結論
自分で API キーを管理でき、生成されたコードを手元に置いたままにしたい個人開発者や小規模チームには向く。逆に、ホスティングまで含めた運用を外注したい場合や、src/pro のコードを自社サービスに組み込みたい場合は、まず LICENSE と src/pro/LICENSE の全文を読み、Functional Source License 1.1 が何を許し何を禁じるかを確認してから判断すべきだ。
コミュニティノート