Dyad

クラウドIDEではなくElectronデスクトップアプリとして動かし、projectと実行環境を手元に置く

公式READMEはDyadを「local, open-source AI app builder」と位置づけ、fast・private・no lock-inを主要価値として挙げています。MacとWindows向けに配布され、サインアップなしで利用開始できます。アプリ本体はElectron/Viteで構成され、terminal・Monaco editor・Git操作・local SQLiteなどを組み込み、生成中のcodeと実行結果をdesktop上で扱います。

最新安定版v1.15.0はmacOS arm64/x64、Windows installer、Linux向けdeb/rpm/AppImageなどのrelease assetを公開しており、単なるweb serviceのfrontendではなくローカルにinstallするapplicationとして配布されています。

出典：[2][3][6]

BYOKで複数LLM providerを切り替え、Ollama / LM Studioなら推論までローカル化できる

READMEはBring Your Own Keysを明示しており、code上でもOpenAI・Anthropic・Google/Vertex・OpenRouterなど複数providerを扱います。特定vendorのsubscriptionへ固定せず、projectごとにmodelとcost/qualityの組み合わせを変えられる構成です。

OllamaとLM Studioはlocal providerとして実装され、LM StudioにはOpenAI-compatible APIとして接続します。このため「Dyad自体をlocalに動かす」だけでなく、対応modelを用意すればpromptやcode contextを外部LLM APIへ送らない構成も選べます。

出典：[2][4][3]

生成アプリはVite + React + TypeScriptを基盤にし、UI部品まで含む実コードとして手元に残す

repositoryのscaffoldはVite、React、TypeScript、React Router、TanStack Query、Radix UI系component、Tailwind CSSを組み合わせたapp templateです。AIが生成する成果物をDyad専用の閉じたruntimeだけで動かすのではなく、一般的なfrontend toolchainでbuildできるsource projectとして扱えます。

scaffoldには通常のdev・build・preview scriptがあり、Dyadの外でもVite projectとして操作できます。AI builderから離れた後もcodeを編集・version管理しやすいことが、hosted builderとの重要な違いです。

出典：[5][3]

MCPやSupabase・Neon・Vercel系SDKを組み込み、生成だけでなく開発workflowへ接続する

Dyad本体はModel Context Protocol SDKとAI SDKを採用し、Supabase management API、Neon API、Vercel SDK、Git操作やterminal機能も依存関係として持っています。promptから画面を作るだけのprototype generatorより、database・deployment・tool連携を含む開発環境へ広げる設計です。

ただし各service integrationは外部accountやcredential、provider側の仕様変更に依存します。local-firstなdesktop applicationであっても、利用するbackendやdeployment先まで自動的にlocal/self-hostedになるわけではありません。

出典：[3]

Lovable / v0系の高速な生成体験は欲しいが、code・provider・実行環境の主導権を手元に残したい人に

AIでReact applicationを素早く立ち上げつつ、生成codeを自分のfilesystemとGitで管理したい個人開発者やpower userに向きます。BYOKでmodel費用を自分で管理したい場合や、Ollama / LM Studioを使って機密codeを外部LLMへ送らない構成を試したい場合にも比較価値があります。

「local」はアプリの実行場所を指す。cloud modelを選べばpromptやcode contextは外部APIへ送信される

Dyadのdesktop applicationとproject filesがlocalにあることと、LLM inferenceがlocalであることは別です。OpenAI・Anthropic・Google・OpenRouterなどを選べば、それぞれのprovider APIへrequestを送ります。完全なlocal processingを要件にする場合は、Ollama / LM Studioなどlocal providerを明示的に選び、利用model・telemetry・外部integrationも含めてdata flowを確認する必要があります。

またlocal modelはGPU/RAM、context window、coding能力に依存するため、hosted frontier modelと同じ生成品質・速度を前提にはできません。

出典：[2][4]

repositoryは完全なApache-2.0ではない。`src/pro`はFSL-1.1-ALv2で競合利用を制限する

top-level LICENSEとREADMEは、src/pro以外をApache License 2.0、src/proをFunctional Source License 1.1 Apache 2.0 Future Licenseで配布すると明記しています。FSL部分ではDyadや同等機能を代替するcommercial product/serviceとして提供するCompeting Useが許可されません。

FSL-1.1-ALv2は各versionの公開から2年後にApache-2.0へ移行するfuture licenseを持ちますが、それまではOSI型のopen-source licenseと同一ではありません。fork、再配布、商用サービス化を検討する場合はdirectory単位のlicense境界を確認する必要があります。

出典：[7][8][2]

stable releaseとmainのbetaを分けて評価し、生成stackの前提もversionごとに確認する

2026年9月15日時点の最新stable GitHub Releaseはv1.15.0ですが、mainのpackage versionは1.16.0-beta.1です。新機能を追うためにmainへ直接追従すると、stable buildより先のmigrationやprovider変更を取り込むことになります。

現在のdefault scaffoldはVite + React + TypeScript中心です。Dyadを「任意frameworkを自由に生成する汎用agent」とみなすより、生成template・supported integration・releaseごとのmigrationを確認して、自分のstackと合うか判断する方が安全です。

出典：[6][3][5]