Figma to Qtは、Qtの開発元であるThe Qt Companyが提供するFigmaプラグインで、Figmaで作った画面をQMLのプロジェクトとして書き出します。正式版1.0は2026年4月29日に公開され、2026年10月5日には1.1が出ました。1.1では、プレビュー画面でボタンやスライダーを実際に操作できるようになり、Qt 6.12 LTSとマイコン向けのQt for MCUsも書き出し先に加わっています。この記事では、FigmaのレイヤーがどのQML型に変換されるか、書き出す前に決めておくコード設定(翻訳・開始画面など)、書き出したプロジェクトをQt Creatorへどう組み込むか、旧製品のQt Bridge for Figmaとどこが違うかを、Qtの公式ドキュメントとリリース記事に沿って説明します。
まとめ:Figma to Qtの要点(2026年11月時点)
- 2026年11月時点の最新版は1.1(2026年10月5日公開)。Figma Communityから無料で入手でき、Figmaの無料プランでも使えます。
- 書き出しはQMLのみです。
.qmlproject付きのZIPで出力され、Qt Creator、VS Code(Qt拡張)、Qt Design Studioで開けます。 - 書き出したコードはQt 6.10以降が対象で、1.1でQt 6.12 LTSとQt for MCUs 2.12 LTSが加わりました。プラグインは無料ですが、書き出したプロジェクトで開発・出荷するにはQtのオープンソースまたは商用ライセンスが必要です(Qt for MCUsは商用ライセンスのみ)。
- Figmaの効果(影など)、多角形、星形はQMLに置き換えられず、画像になります。画像が増えると端末側の負荷が上がるため、Issuesタブの指摘を設計段階で潰すことが前提の道具です。
- 旧製品のQt Bridge for Figmaはレガシー扱いです。新規案件はFigma to Qtを使います。既存案件のサポートは2030年10月まで続きます(日本語FAQには旧記載の「2028年末」が残っています)。
- 多言語の製品なら、書き出す前に[Settings]→[Code]で翻訳マクロ(
qsTr()など)を選んでおくと、画面上の文字列がQtの翻訳ツールで扱える形で出力されます。 - 効果が出るのは標準的な画面と部品です。UXDiversの検証では、該当部分の工数が118時間から36時間に減りましたが、地図やグラフなど手作りの部品が多い案件では、プロジェクト全体で約20%の削減にとどまりました。
Figma to Qtの提供状況と利用条件
出力先のQMLは、Qtで画面を組むための宣言型の言語です。Rectangle { width: 100; color: "red" }のように、部品とプロパティを入れ子で書きます。Figma to Qtは、組み込み機器のGUIやHMI(人と機械の操作画面)をFigmaで設計し、その設計をそのまま端末に載せることを目的としたプラグインです。2025年9月に最初の公開ベータが出ました。2025年12月のベータ更新では、複数画面の同時プレビューやローカル変数のデザイントークン化が入り、その後1.0、1.1と続いています。
| 版 | 公開日 | 主な追加点 |
|---|---|---|
| ベータ(初回公開) | 2025年9月 | 公開ベータの開始 |
| ベータ更新 | 2025年12月17日 | Button・Switch・CheckBox、ローカル変数のトークン化 |
| 1.0 | 2026年4月29日 | Slider・TextField追加、共有ライブラリ対応 |
| 1.1 | 2026年10月5日 | 操作できるプレビュー、Qt 6.12 LTS、Qt for MCUs |
公式FAQによると、プラグインは無料で、Figmaのライセンスの種類も問いません。一方、Qt Framework向けの出力はQt 6.10以降が対象で、開発・配布には利用するQtのオープンソースまたは商用ライセンスの条件が適用されます。Qt for MCUsは商用ライセンスで提供され、期間限定の評価ライセンスではデバイスを配布できません。Qt Design Studioは必須ではありません。QML以外の言語での書き出しは正式リリース後の検討事項とされ、2026年11月時点では提供されていません。
1.1の新機能:操作できるLive PreviewとQt 6.12 LTS・Qt for MCUs
1.0からの変更点は大きく4つです。いずれも2026年10月5日のFigma to Qt 1.1の公式発表によるものです。
- プレビューで部品を操作できる:Inspectモードをオフにすると、ボタンのクリック、スライダーのドラッグ、スイッチの切り替えをブラウザ上のプレビューで試せます。
- QMLコードビューの編集:これまで読み取り専用だったコード表示で、色やサイズの値を書き換え、その結果をプレビューに反映できます。編集はそのセッション限りで、Figmaファイルには書き戻されません。Figmaと同期すると上書きされ、コードの編集にはQtアカウントへのログインが必要です。
- 書き出し先の拡大:Qt 6.10に加えてQt 6.12 LTSを選べるようになり、マイコン向けのQt for MCUs(2.12 LTS以降)にも対応しました。Qtは6.12を、EUのサイバーレジリエンス法(CRA)の既知の要件を満たす版と位置づけており、Figma to QtがCRA対応版を書き出し先に選べるのは1.1からです。MCU向けは[Settings]→[Code]の「Use Qt for MCUs compatible types」で切り替えます。ただし、MCU向けの変換問題を自動修正するとFigma側の機能が削られる場合があります。通常のQt向けも必要なら、元のデザインを複製してから修正してください。
- QMLネイティブで変換できる範囲の拡大:Figmaの制約(constraints)がQMLのアンカーになり、楕円と円弧は画像ではなくQMLの型で出力されます。アセットはPNG・JPGに加えてSVGでも書き出せます。
Qtのバージョン選択は、変換結果に直接効きます。プラグインの既定は最新のQtで、新しい版ほどQMLの型が増えるため、画像にされるレイヤーが減ります。たとえば楕円は、Qt 6.12以降を選ぶとQMLのEllipseShapeになりますが、6.10を選ぶと画像になります。開発チームが6.10で固定しているのに6.12で書き出すと、受け取った側で型やプロパティを差し替える作業が発生します。Qtバージョンは、デザイナーではなく開発側の採用版に合わせて選んでください。
FigmaのレイヤーがどのQML型になるか:変換対応表
公式の変換仕様を表にまとめました。レイヤーはQMLのコンポーネントに、コンポーネントとインスタンスはQMLのコンポーネントとインスタンスに、レイヤーのプロパティはQMLのプロパティになる、というのが基本です。
| Figmaのレイヤー | 変換後のQML |
|---|---|
| フレーム・長方形 | Rectangle/RectangleShape(MCUはRectangle) |
| 楕円 | EllipseShape(Qt 6.12以降)、6.10は画像 |
| 線 | ShapePathを持つShape |
| グループ | Item |
| テキスト | Text/MCUのStaticTextは最適化設定時 |
| バリアント付きコンポーネント | statesを持つコンポーネント |
| Qt Quick Controls対応部品 | Button/CheckBox/Slider/Switch/TextField |
| 縦横のオートレイアウト | FlexboxLayout(グリッドは非対応) |
| バリアブル | DesignTokensモジュール |
| セクション | 変換しない(子要素はページ直下扱い) |
画像として書き出されるレイヤーの条件
QMLに対応するプロパティを持たないレイヤーは、アセット(画像ファイル)として書き出され、QMLのImageで配置されます。公式ドキュメントが挙げる条件は、目に見える効果(影・ぼかし)がある、多角形か星形である、Qt 6.12未満で楕円を使っている、矢印などの線端装飾や中央以外のストローク位置を持つ線である、などです。コンポーネント内のあるレイヤーが画像に変換されると、各インスタンスやバリアント内にある同じレイヤーも画像になります。ImageにはRectangleのような色や枠線のプロパティがなく、低解像度のラスター画像は高DPI画面で粗くなることがあるため、アイコン、ロゴ、背景のような静的な要素だけを画像にし、それ以外はIssuesタブの指摘に従ってプロパティを外すのが基本方針です。
オートレイアウトとFlexboxLayoutの制約
Figmaの縦横オートレイアウトは、QMLのFlexboxLayoutに変換されます。ただしこれは既定ではなく、[Settings]→[Code]で「Use FlexboxLayout for auto layout」をオンにしたときだけ有効です。FlexboxLayoutはQt 6.10で入った型で、Qtのドキュメント上はまだ技術プレビュー(今後変わりうるAPI)の扱いです。制約も多く、方向ごとに1軸しか正しく動かない、効果・回転・反転や高度なオートレイアウト設定とは相性が悪い、Qt for MCUsでは使えない、とされています。オートレイアウトをオフにした場合や対象外のレイヤーでは、1.1から制約がアンカーと余白に変換されます(「Position with anchors」設定)。
バリアブルからDesignTokensへの変換と共有ライブラリの扱い
FigmaのバリアブルはDesignTokensというQMLモジュールになります。コレクションごとにシングルトンが作られ、コレクションのモードはテーマオブジェクトになり、activeThemeプロパティで切り替えます。1.0のリリース記事は「共有Figmaライブラリに対応」とうたっていますが、ドキュメントを読むと仕組みは自動参照ではありません。Figmaはプラグインが別ファイルのバリアブルを自動で読むことを許可していないため、ライブラリを持つファイルでプラグインからJSONに書き出し、使う側のファイルで読み込む手順になります。ライブラリを更新するたびにJSONを書き出し直して配る必要があり、複数のライブラリを読み込む場合はコレクション名を重複させない必要があります。REST APIでバリアブルを取得する方法もありますが、Enterprise組織のFullシートが必要で、ゲストは利用できません(Figma APIの使い方|APIキー発行・レート制限の実数・Variables REST APIの条件【2026年10月】)。
Qt Quick Controlsへの対応付けと制限
ボタンやスライダーを単なる四角形の集まりではなく、動くQt Quick Controlsとして書き出すには、プラグインの[Qt Quick Controls]ページで部品を登録します。登録方法は2つあります。1つはテンプレートから新規作成する方法で、既定のプロパティが設定済みの部品がキャンバスに作られます。もう1つは、自前のバリアント付きコンポーネント(コンポーネントセット)を選び、部品の種類に対応付ける方法です。
| 部品 | 対応付けで指定する要素 | Qt for MCUs |
|---|---|---|
| Button | 状態ごとの見た目 | 対応 |
| CheckBox | オン/オフの見た目、インジケーター | 非対応 |
| Switch | オン/オフの見た目、インジケーター | 非対応 |
| Slider | ハンドル、溝(背景)、縦横 | 非対応 |
| TextField | 入力文字のフォントと色、余白 | 非対応 |
どの部品にも、Default・Hovered・Pressed・Disabledの4状態があらかじめ定義されています。部品の見た目は変えられますが、動作そのものは変えられません。また、レイヤー名を変えたりレイヤーを消したりすると、Qt Quick Controlsとしては認識されず、普通のQMLコンポーネントとして書き出されます。インスタンス側で状態を上書きしても、状態はバインディングで制御されているため、プレビューではDefaultで表示されます。
実務で問題になりやすいのは、チェックボックスの中間状態です。後述のUXDiversの検証では、「すべて選択」用の3状態チェックボックス(オン・オフ・一部選択)を対応付けで扱えず、手で実装し直しています。オートレイアウトで組んだデザインシステムがある場合は、組み込みのテンプレートではなく自前のコンポーネントを対応付けるほうが、構造を崩さずに済みます(組み込み部品は固定フレームと手動配置で作られているため)。
インストールからQMLプロジェクトの書き出しまでの手順
インストールとLive Previewでの確認
Figmaでファイルを開き、[Plugins]→[Manage plugins]で「Figma to Qt」を検索して保存すると、[Plugins]→[Figma to Qt]から起動できます。まず試すなら、Qtが公開している医療用輸液ポンプの画面を題材にしたPlayground(練習用)ファイルが手早い入口です。変換したいレイヤーを選んで[Preview]を押すと、変換されたQMLがWebアプリのLive Previewにアップロードされ、ブラウザでQtの画面として描画されます。複数画面の同時表示、端末解像度の枠の重ね表示、要素を選んで対応するQMLを強調表示するInspect、書き出されるファイル構成を見る[Files]タブがあります。
フォントはGoogle Fontsなら自動でアップロードされます。それ以外のフォントは、.ttf・.otf・.woffをプレビューへアップロードします。アップロードしたフォントはブラウザのキャッシュを消すまで保持され、Qtアカウントに保存すれば恒久的に使えます。UXDiversは、Live PreviewがブラウザのFigmaでしか動かず、デスクトップ版を使っていたため気づくまで時間がかかったと述べています。
Live PreviewはQtが運営するWebアプリで、プラグインとはWebRTCでつながります。読み込みが終わらない、画面が白い、「Cannot connect to Figma」と出る場合、公式の接続トラブル対処が挙げる原因は、VPN、ファイアウォール、WebRTCの漏えい防止を有効にしたブラウザ拡張、広告ブロッカーです。推奨ブラウザはSafari、Chrome、Edge、Firefoxで、拡張機能の干渉を切り分けるにはシークレットウィンドウで開き直すのが早道です。社内ネットワークで試す場合は、情報システム部門にWebRTCの通信が許可されているかを先に確認してください。
Issuesタブによる変換エラーの修正
[Issues]には、QMLに対応物がないプロパティがエラーや警告として並びます。メッセージ内のボタンで修正を当てると、多くの場合はFigma側のレイヤーが書き換わり、より適切なQMLに変換できる状態になります。複数件をまとめて直す「Fix selected」、問題のレイヤーへ移動する「Locate」、意図して残す項目を隠す「Ignore」があり、修正はFigmaの取り消し(Ctrl+Z/Cmd+Z)で戻せます。隠した項目は[Settings]→[General]の「Restore issues」で再表示できます。
書き出す前に決めるコード設定:翻訳マクロ・注釈コメント・開始画面
変換対応表に載らない出力の違いは、プラグインの設定で決まります。開発側に渡してから直すと手戻りになる5項目です。
| 設定 | 場所 | 既定の動作 |
|---|---|---|
| 翻訳マクロ | Settings→Code | 文字列をそのまま出力 |
| 開発メモ | Figmaの注釈(Development) | QMLのコメントになる |
| 開始画面 | Home→Flow settings | 一番上のレイヤー |
| マスク | Settings→Code | 適用して画像化 |
| スキップ | ページ・レイヤー単位 | セクションは常に変換しない |
翻訳マクロは、[Text translation macro]でqsTr()、qsTranslate()、qsTrId()のどれかを選ぶと、画面上の文字列がその関数で包まれます。たとえばtext: "Hello"はtext: qsTr("Hello")になり、QtのlupdateとQt Linguistで翻訳ファイルを作れます。既定で対象になるのはテキストレイヤーだけで、文字列のバリアブルも含めるには「Mark variables for translation」をオンにします。Qt for MCUsはqsTranslate()に対応していないため、MCUに切り替えるとプラグインがqsTr()へ置き換えます。多言語で出荷する製品なら、最初の書き出しの前にどの方式を使うか開発側と決めておくのが確実です。後から変えると、翻訳ファイルの文脈やIDがずれます。
Figmaの注釈でカテゴリを「Development」にしたメモは、そのレイヤーから生成されたQMLの直上にコメントとして入ります。「読み込み中だけ表示」のような仕様メモを、仕様書ではなくコードの横に残せます。開始画面は、アプリを端末で起動したときに最初に出る画面で、選べるのはトップレベルのフレームかコンポーネントだけです。Qt for MCUsでCMakeのqul_add_targetにGENERATE_ENTRYPOINTを付けてエントリーポイントを生成する場合、開始画面が未設定だとビルドが失敗します。
Figma to Qtでは、既定でFigmaのマスクを適用したうえで、対象のレイヤーを画像として書き出します。Qt QuickにはMultiEffectによるマスク表現もありますが、このプラグインの標準変換とは別です。「Enable masks」をオフにすると、Figmaのデザインにはマスクを残したまま、コードには適用しません。製品に含めない検討用の画面やページは、スキップ指定で変換対象から外せます。スキップしたレイヤーの子も変換対象から外れます。ただし、変換対象として残るインスタンスが参照するコンポーネントは、スキップ指定しても除外されません。セクションは整理用の枠なので常にQMLにならず、中のレイヤーはセクションが無い場合と同じように変換されます。
ZIPでの書き出しと書き出し時の注意
[Download]を押すと、QMLファイル、アセット、使用中のカスタムフォントが.qmlproject付きのZIPにまとめられ、PCのダウンロードフォルダに保存されます。書き出し時はデザイン全体(スキップ指定したページとレイヤーを除く)を解析し直すため、個別レイヤーのプレビューで見たコードとは多少異なるコードになる点に注意してください。書き出しの準備中、プラグインは一時的にデザインを変更し、完了後に元に戻します。Qt for MCUs向けでは、テキストをStaticTextにする「Optimize text rendering」と、アラビア語・タイ語などの複雑な文字体系に対応するSparkフォントエンジンの設定が別にあります。
書き出したQMLをQt Creatorと既存のCMakeプロジェクトへ組み込む方法
書き出されるのはUI用の.qmlprojectであり、そのままではアプリケーションになりません。C++のコード、リソース、端末への配備設定は開発側で足します。Qt Creatorのドキュメントには、UIプロジェクトをそのまま開く、アプリケーションに変換する、既存のQt Quickアプリに中身を追加する、新しいQt Quickアプリを作って取り込む、の4通りが示されています。
CMakeでビルドしている場合は、プラグインの[Settings]→[Code]で「Generate CMakeLists.txt」をオンにして書き出します。これで、DesignTokensなどプラグインが作るQMLモジュールごとに、qt_add_qml_module()を含むCMakeLists.txtが生成されます。ただしトップレベルのCMakeLists.txtは生成されないため、どのモジュールにも属さないQMLファイル(画面本体など)は、プロジェクト側のCMakeLists.txtに手で追加します。次は公式例を基にしたモジュール取り込み部分の抜粋です。別途main.cpp、生成済みのDesignTokensフォルダ、画面QMLのリソース登録が必要で、この断片だけではアプリケーションは完成しません。
cmake_minimum_required(VERSION 3.16)
project(MyApp LANGUAGES CXX)
find_package(Qt6 REQUIRED COMPONENTS Quick)
# Figma to Qt が書き出したモジュール(例:DesignTokens)を取り込む
add_subdirectory(DesignTokens)
qt_add_executable(MyApp main.cpp)
target_link_libraries(MyApp PRIVATE DesignTokens)
公式ドキュメントの同じ例は1行目がmake_minimum_requiredと誤記されているため、そのまま写すとCMakeが未知のコマンドとして止まります。Qt Creator 20.0以降で作ったQt Quickアプリにはimportedcontentフォルダがあり、ZIPの中身と専用のCMakeLists.txtをそこへ置くと自動で取り込まれます。Qt CreatorのDesignモードで編集したい場合は、プラグイン側で.ui.qmlの生成を有効にし、Qt Creator側でQt Quick Designer拡張を有効にします。
UXDiversの二重実装に見る効果と、Figmaファイル側で必要な作法
UXDiversへの公式インタビューによると、Qtのパートナーであるデザインスタジオ、UXDiversは、実案件の画面を手書きQMLとFigma to Qtの両方で実装し、工数を比べました。対象は農業向けの霜害リスク監視ダッシュボードの3画面(概要、グラフ・ゲージ・地図を含む詳細画面、設定画面)です。端末はToradexのVerdin iMX8M PlusにDahliaキャリアボードを組み合わせ、10.1インチのタッチ画面とTorizon OSを載せた構成です。
工数の実測:該当部分は70%減、全体では約20%減
標準的な画面と部品の実装は、手作業の118時間に対しFigma to Qtでは36時間で、約70%減(約3.3倍速)でした。一方、プロジェクト全体の削減は約20%にとどまります。地図、時間別リスクのグラフ、ゲージの3つだけで全工数の48%を占め、これらはどちらの方法でも手作業だったためです。プラグインが効く標準画面と標準部品は、この案件では全体の28%しかありませんでした。設定画面、フォーム、カード、一覧が中心のUIでは、自動変換の対象範囲が広がるとUXDiversは見込んでいます。ただし、他案件でも70%減になると実測されたわけではありません。逆に、独自の可視化部品が工数の半分を占めるような案件では、プラグインだけで大きな短縮は見込めません。導入前に、画面の部品を標準とカスタムに仕分けて比率を見積もってください。Figmaのデザインシステムを変換しやすい形に整えるところから外部に頼む場合は、UI/UXデザインの支援のように、設計段階から命名規則やコンポーネント構成を決められる体制を選ぶと、後述の手直しを減らせます。
変換前にFigmaファイルで直した4点
UXDiversが変換のためにFigmaファイルの組み方を変えたのは、次の4点です。いずれも見た目ではなく、データ構造の変更です。
- レイヤー名:レイヤー名がQMLの識別子になり、QMLはハイフンを受け付けないため、kebab-caseからsnake_caseへ変えた。
- テキストの縦位置:オートレイアウト内のテキストが上に寄るため、全テキストレイヤーで縦方向の揃えを明示した。
- 枠線:QMLの
borderは全辺同じ太さの単色しか表せないため、辺ごとに太さや不透明度が違う枠線を統一した。 - 影:影を持つレイヤーは画像化されるため、解像度に依存しない状態を保つ目的でコンテナのドロップシャドウを外した。
この4点は、デザインシステムを作る段階で命名規則とスタイルの禁止事項として決めておくのが安上がりです。完成済みのFigmaファイルに後から当てはめると、修正量が大きくなります。
実機で起きたことと、再生成を前提にした分離
開発はQt 6.10.2で進め、Torizon向けのVS Code拡張の既定テンプレートはQt 6.8.2でした。実機に載せた際の修正はAPIの差分だけで、それも手書き部分に限られ、生成されたQMLは無修正で動いたと報告されています。UXDiversが運用上の課題に挙げたのは、デザインの変更に合わせて画面を再生成するときの扱いです。生成されたUIと手書きのコードをファイル単位で分け、生成物には手を入れない運用にしておけば、プラグインを何度でも再実行できます。
Qt Bridge for Figma・生成AI型ツールとの違い
| 観点 | Figma to Qt | Qt Bridge for Figma | 生成AI型の変換 |
|---|---|---|---|
| 出力 | QMLプロジェクトを直接 | Qt Design Studio経由 | HTML・React等が中心 |
| プレビュー | Figma作業中にブラウザで | Design Studio取り込み後 | ツールにより異なる |
| 同じ入力の出力 | 同一(版・設定が同じ場合) | 同一(版・設定が同じ場合) | 変動しうる |
| 位置づけ | 現行(無料) | レガシー、2030年10月まで保守 | 各社製品 |
Qt Bridge for Figmaは、デザインをQt Design Studio用のメタデータ(.qtbridge)に書き出し、Qt Design Studioで取り込んでからQMLにする方式でした。Qt Wikiによると、.qtbridgeの取り込みにはQt Design StudioのEnterpriseライセンスが必要です。Photoshop、Sketch、Adobe XD向けにも兄弟製品があったのに対し、Figma to QtはFigma専用に作られており、Qtは生成コードがより整理されていると説明しています。2つは別のプラグインなので、Qt Bridgeを使っていても自動では置き換わりません。新しくFigma CommunityからFigma to Qtを入れる必要があります。
生成AIでFigmaからコードを作るツールとの違いは、出力が決定的かどうかです。Figma to Qtは、Figmaのプロパティを決まったルールでQMLに写すため、デザイン、プラグインの版、対象Qt版、変換設定が同じなら同じコードが出ます。変換ルールに基づく出力はレビューの再現性を確保する助けになるため、医療機器や車載のように「何を出荷したか」を説明する必要がある分野で選ばれる理由になります。Web向けのReactやHTMLが目的なら、生成AI型のほうが選択肢が多く(FigmaをReactに変換する4つの方法、Kombai)、Qtを使わない案件でFigma to Qtを選ぶ理由はありません。
よくある質問
Figma to Qtは無料で使えますか?
プラグインは無料で、Figmaの無料プランでも使えます。ただし、書き出したQMLプロジェクトを開発・出荷に使うには、Qtのオープンソースまたは商用の開発者ライセンスが必要です(公式FAQ)。マイコン向けのQt for MCUsにはオープンソース版がなく、商用ライセンスか期間限定の評価ライセンスのどちらかです。有料契約が一律に必須というわけではなく、どちらを使えるかは製品の配布形態とQtの各ライセンス条件で決まります。
Qt Bridge for Figmaとの違いは何ですか?
Qt Bridge for FigmaはQt Design Studioを経由してQMLにする旧方式で、Figma to QtはQMLプロジェクトを直接書き出し、Figma作業中にブラウザでプレビューできます。Qt Bridgeはレガシー扱いです。既存案件のサポート期限は、英語版の公式FAQと1.0の発表記事では2030年10月です。日本語版のFAQページには、ベータ期の記載とみられる「2028年末まで」が2026年11月時点でも残っているため、保守計画を立てるときは英語版を基準にしてください。
Qt Design Studioは必要ですか?
必須ではありません。書き出したプロジェクトはQt Creator、VS Code(Qt拡張)など任意のIDEで開けます。Qt Design Studioで開くこともできます。
どのQtのバージョンに対応していますか?
書き出したコードの対象はQt 6.10以降で、1.1でQt 6.12 LTSとQt for MCUs 2.12 LTSが加わりました。プラグインの[Settings]→[Code]で、開発側が使う版を選びます。
QML以外の言語で書き出せますか?
2026年11月時点ではQMLのみです。Qtは、他の言語への対応を正式リリース後の検討事項としています。