VULKがひとつの会話から8つのプラットフォームを扱う仕組み

2026年7月18日更新 — プレビューステータスを現在のマルチランタイムの現実(PHP + Python microVMは2026年7月からライブ)に修正し、プラットフォームデータを刷新。

VULKはひとつの会話から8プラットフォーム向けにどう生成する?

完全な答え:プロンプトがAIモデルに届く前に、VULKの検出システムがプラットフォーム固有のシグナルをスキャンし — キーワードだけでなく、文脈、共起する用語、意図のパターンを重み付けして — 8つの専用生成パイプラインのいずれかにルーティングします:React + Vite、Flutter、React Native + Expo、Shopify Liquidテーマ、Shopifyアプリ(Remix + App Bridge)、Shopify Hydrogen、PHP/Laravel、Three.jsゲーム。各パイプラインは独自のシステムプロンプト、ファイル構造ロジック、プレビュー戦略、デプロイ経路を持ちます。ドロップダウンから選ぶことは決してなく、欲しいものを記述すれば正しいモードが起動します。

需要は測定可能なほどマルチプラットフォームです:11,355の生成プロジェクトにわたり、累計プロンプト需要にはFlutter 381件、Nodeバックエンド310件、Python 246件、React Native/Expo 213件、PHP 174件が含まれます — React多数派と並んで(VULKプラットフォームデータ、2026年7月)。開発者の世界はReactよりはるかに広く、VULKはそのすべてのために作られました。

なぜ誰もこれを解決しようとしなかったのか?

VULKを作り始めたとき、市場のすべてのAIコードビルダーは同じものを生成していました:Tailwind CSS付きのReactアプリです。Bolt、v0、Lovable、Replit — 全部。モバイルアプリ、Shopifyテーマ、Laravelバックエンド、ブラウザゲームが欲しければ、運がなかったのです。カテゴリ全体が「AIがアプリを作る」=「AIがReactアプリを作る」と決めつけていました。

それは私には決して腑に落ちませんでした。カスタムテーマを必要とする170万のShopifyマーチャントがいます。Flutterにはネイティブモバイルアプリを作る100万人超のアクティブ開発者がいます。PHPは今もウェブのサーバーサイドの大部分を動かしています。Three.jsはブラウザベース3Dの標準です。これらは巨大なコミュニティなのに、完全に無視されていました。

だから私はVULKをそのすべてのために作りました。ひとつの会話、8つのプラットフォーム:

1. React + Vite — Tailwind CSS付きウェブアプリ
2. Flutter — Clean Architectureのネイティブモバイルアプリ
3. React Native + Expo — NativeWindのクロスプラットフォームモバイル
4. Shopify Liquidテーマ — Online Store 2.0
5. Shopifyアプリ — Remix + App Bridge + Polaris
6. Shopify Hydrogen — ヘッドレスコマースのストアフロント
7. PHP / Laravel — サーバーサイドアプリケーション
8. Three.js — 物理エンジン付きブラウザゲーム

検出は実際、内部でどう動いている?

ここが一番よく聞かれる部分です。ドロップダウンからプラットフォームを選ぶことはありません。欲しいものを記述するだけで、VULKがどの生成モードを起動するかを判断します。

プロンプトがAIモデルに届く前に、検出システムがプラットフォーム固有のシグナルをスキャンします。単純なキーワードマッチではなく、文脈、共起する用語、意図のパターンを重み付けします。たとえば「スクリーンとボトムナビゲーションバーのあるアプリを作って」はウェブではなくモバイルのシグナル。「商品バリエーションとコレクションのあるストアを作って」は汎用ECではなくShopifyのシグナルです。

検出は厳格な優先順位に従い、それには理由があります:Shopify App > Shopify Hydrogen > Shopify Liquid > Flutter > React Native > Three.js > PHP/Laravel > React(デフォルト)。

なぜこの順序か?具体性が勝つべきだからです。誰かが「Shopifyアプリ」と言えば、それは非常に精密な意図 — App BridgeとPolarisを持つRemixベースのマーチャントアプリが欲しいのであって、Shopifyと連携するだけの汎用ウェブアプリではありません。プラットフォームが専門的であるほど優先度は高い。Reactが最下位なのはキャッチオールだからです。他に何もマッチしなければ、おそらくウェブアプリが欲しいのであり、React + Viteがその最良のデフォルトです。

各モードのトリガーはこれです:

• Flutter — 「モバイルアプリ」「Flutter」「iOSとAndroid」「ネイティブアプリ」「APK」「スクリーン」(「ページ」でなく)
• React Native — 「React Native」「Expo」「クロスプラットフォームモバイル」
• Shopify Liquid — 「Shopifyテーマ」「オンラインストア」「Shopifyストア」
• Shopifyアプリ — 「Shopifyアプリ」「マーチャント向けアプリ」「Shopifyプラグイン」
• Shopify Hydrogen — 「Hydrogen」「ヘッドレスShopify」「Storefront API」
• PHP/Laravel — 「PHP」「Laravel」「WordPress」「サーバーサイド」
• Three.js — 「ゲーム」「3D」「Three.js」「ブラウザゲーム」
• React — それ以外すべて

検出を上書きしたければ明示するだけです。「これをFlutterで作って」「これにはReactを使って」が常に勝ちます。

各モードを実際に異なるものにしているのは何か?

これは単なるテンプレートの差し替えではありません。各プラットフォームは4つの独立したレイヤーを持つ独自の生成パイプラインを持ち、それぞれを正しく作るのに数か月のエンジニアリングを要しました。

プロンプトエンジニアリング — 各プラットフォームには、そのスタックの慣習、パターン、ベストプラクティスをAIモデルに教える専用のシステムプロンプトがあります。Shopifyのプロンプトだけで2,100行超。Liquid構文、セクションスキーマ、Dawn互換性、メタフィールドのパターン、そして動作するテーマとShopifyのテーマエディタで壊れるテーマを分ける数十の癖をカバーします。FlutterのプロンプトはClean Architectureを強制します。Three.jsのプロンプトはゲームループ、衝突検出、物理統合を扱います。モデルに「Shopifyコードを書いて」と言うだけで良い出力は期待できません。深いプラットフォーム固有のプロンプトエンジニアリングが必要です。

ファイル構造 — Reactはsrc/components/とsrc/pages/を生成。Flutterはlib/models/、lib/screens/、lib/services/。Shopifyはsections/、templates/、assets/。Laravelはapp/Http/Controllers/、resources/views/、database/migrations/。各フレームワークにはコードの置き場所への期待があり、それに背く出力は経験ある開発者には使い物になりません。

プレビュー戦略 — ここがエンジニアリングの本当に難しいところで、何がライブで動き何が動かないかについて私は正直さにこだわります。React + Vite(とThree.js)はFirecracker microVM — ウォームプールから起動する、ホットリロード付きの分離された仮想マシン — で動きます。Flutterはbuild-then-serveパイプライン:専用ビルドサービス上でflutter build webによりコンパイルされ、ビルドごとに約20〜60秒で配信されます。2026年7月からはPHPとPythonもライブのmicroVMランタイムとして動作 — Laravel/WordPress系アプリにはphp-fpm 8.3 + nginx、Pythonには自動検出されるuvicorn/Flask/Django/Streamlitサーバー。React Nativeと3つのShopifyモードにはライブプレビューがありません — RNはMetroバンドル(エディタ内プレビューは開発中)、ShopifyコードはShopify自身のランタイムを必要とするため、エディタは偽のレンダリングの代わりに正直なセットアップ手順を表示します。

デプロイ — Reactはワンクリックで Cloudflare Pagesへ。Flutterはストア提出の足場付きで本物のAPK/AABファイルをエクスポート。ShopifyテーマはShopify CLIでプッシュ。LaravelとPythonのプロジェクトは、あらゆるホストに対応した完全なプロジェクトディレクトリとしてエクスポートされます。

各プラットフォームは今どこにいる?

この表が「8プラットフォーム」の正直版です。生成は普遍的、ライブプレビューはウェブで実行可能なスタックをカバーし、デプロイ経路は各エコシステムが実際に要求するものに一致します。

他のAIビルダーとVULKはどう比較される?

競争環境について率直に言います。開発者は透明性に値すると信じているからです:

これは漸進的ではなく、カテゴリ的な差です。この差が存在するのは、マルチプラットフォーム生成が本当に作るのが難しいからです。新しいプラットフォームごとにエンジニアリング作業は倍増します:新しいプロンプトエンジニアリング、新しいファイル構造ロジック、新しいプレビューインフラ、新しいデプロイパイプライン、新しいテスト面。そして各プラットフォームは、そのエコシステムの経験ある開発者が受け入れられる出力を生まねばなりません。Flutter開発者は構造の悪いDartプロジェクトを即座に見抜きます。Shopify開発者はLiquidテンプレートがOnline Store 2.0のパターンに従っていなければ気づきます。

なぜ他の誰もこれをやらないのか?

これについてはよく考えましたが、答えは単純だと思います:経済性が一見魅力的に見えないのです。

AIコードビルダーを作っていて、ユーザーの80%がReactアプリを望むなら、明白なビジネス判断はReact生成を極めて良くし、他をすべて無視すること。Flutterサポートの追加はユーザーベースの少数派のための数か月のエンジニアリングです。プラットフォームごとのROIは下がります。

しかしその分析が見落としているのは:それら小さなコミュニティにはほぼゼロの代替肢しかないことです。React開発者は5、6のAIビルダーから選べます。AIでカスタムテーマを生成したいShopify開発者の選択肢はひとつ。プロンプトからAPKまで行きたいFlutter開発者の選択肢もひとつ。それらのカテゴリでの競争の堀は、誰も投資したがらないからこそ巨大なのです。そして上の需要テーブル — Flutter 381、Python 246、RN 213、PHP 174プロンプト、増加中 — は、それらの「ニッチ」がビルダーの実際の要望のかなりの割合を占めることを示しています。