Nextcloudデスクトップクライアントを再ビルドしたらWindowsで「No Qt platform plugin」になる原因と直し方

NextcloudデスクトップクライアントをWindows向けに自前ビルドし、ロゴなどの軽微なブランディング変更だけのはずなのに、起動直後に「No Qt platform plugin could be initialized」で落ちる——この手のトラブルは“ビルド成功”と“配布物として起動できる”が別物であることが原因になりがちです。特に「AWS上のWindows VMでは動くのに、手元のノートPCだと動かない」という差分は、Qtのプラグイン探索パスや依存DLL、環境変数の影響が濃厚です。 Nextcloud community

Nextcloudデスクトップクライアントを再ビルドしたらWindowsで「No Qt platform plugin」になる原因と直し方

症状の正体：Qtの「platforms」プラグインが見つからない・読めない

このエラーは多くの場合、QtのQPA（Qt Platform Abstraction）プラグインである qwindows.dll（Windows用）が、

そもそも配置されていない
配置はあるが依存DLL不足などでロードに失敗している
アプリが見に行く“プラグインの場所”がズレている
のいずれかで発生します。原因の切り分けは、Qtが用意しているデバッグ出力が最短ルートです。 doc.qt.io+1

まずやるべき切り分け：QT_DEBUG_PLUGINSで「真犯人」を出す

起動時にQtがどのプラグインをどこから探し、なぜ失敗したかを出力させます。

PowerShell

powershell

$env:QT_DEBUG_PLUGINS="1"
.\nextcloud.exe

cmd

bat

set QT_DEBUG_PLUGINS=1
nextcloud.exe

ここで、

「qwindows.dllが見つからない」なら“配置ミス”
「見つかったがロードできない」なら“依存DLL不足・ビルド種別不一致・VC++ランタイム不足”
と判断できます。 doc.qt.io+1

原因1：windeployqt未実施、または“違うQt”でdeployしている

WindowsのQtアプリは、exe単体では動きません。QtのDLL・plugins・必要に応じてQMLや翻訳などを、配布フォルダに正しく集める必要があります。Qt公式の windeployqt はその自動化ツールです。 doc.qt.io

鉄板の直し方（配布フォルダを作り直す）

nextcloud.exe を空のフォルダへコピー
そのexeをビルドしたのと同じQt環境の windeployqt.exe を使って実行

bat

windeployqt path\to\nextcloud.exe

ポイントは「PATHに入っている別のQtのwindeployqtを踏まない」こと。ローカルPCは開発ツールが多く、Qtが複数入っているほど事故ります。AWSのVMが“クリーン”で動くのは、この差が出やすいからです。

原因2：platforms\qwindows.dllはあるのにロードできない（依存DLL不足）

platforms\qwindows.dll が存在しても、内部でさらに必要なDLL（MSVCランタイム等）が足りないとロードに失敗し、同じエラーになります。依存関係を洗うときは「プラグイン自体の依存DLL」も対象にしてください（Dependency Walker系の確認が典型）。 Stack Overflow

また、Debug/Releaseの不一致も定番です。MSVC環境では、DebugビルドのアプリがReleaseプラグインを（またはその逆を）ロードできないケースがあります。Qt側もビルド種別の整合性を注意点として挙げています。 doc.qt.io

原因3：qt.confやプラグイン探索パスの“ズレ”

配布物に qt.conf が紛れ込むと、Qtの探索パスが上書きされ、正しいpluginsフォルダが見えなくなることがあります。qt.conf はパス上書きに使える一方、設定が少しでもズレると「platformsが見つからない」一直線です。 doc.qt.io+1

対処の考え方

まず qt.conf を一度外して起動確認
使うなら、配布フォルダ構造（plugins\platforms なのか platforms 直下なのか）と一致させる
“ローカルだけ失敗”の場合、環境変数や別Qtの設定が混ざっていないかも確認

「AWSで動くのにローカルで動かない」時に疑う順番

再現性の高い順に並べると、だいたい次の優先度で刺さります。

別のQtがPATHにいて、プラグイン探索が汚染（ローカル開発PCあるある）
VC++ランタイム等がローカルに不足（VM側にたまたま入っていた）
Debug/Release混在（ビルドとdeployの組み合わせ違い）
セキュリティ製品がDLLロードを妨害（例外設定で改善することがある）

QT_DEBUG_PLUGINSのログが出れば、1〜3はほぼ決着します。

失敗しない配布の最小要件チェックリスト

nextcloud.exe と同階層にQtの主要DLLが揃っている
platforms\qwindows.dll が存在する（フォルダ名が正確）
windeployqt は“ビルドに使ったQt”で実行した
qt.conf を置くなら、pluginsの位置と整合している
Debug/Releaseが混ざっていない
依存DLL（MSVCランタイム等）が満たされている

このチェックを通してもなお解決しない場合は、QT_DEBUG_PLUGINSの出力に「どのDLLがロードできないか」がほぼ必ず出るので、そのDLLを起点に潰すのが最短です。

まとめ

「No Qt platform plugin」は、アプリ本体の不具合というより“配布物の組み立て不良”で起きる代表例です。windeployqtで正しい依存物を集める→QT_DEBUG_PLUGINSで差分をログから確定する、この2段で、AWSとローカルの挙動差も含めて一気に解けます。
なお、ブランディング変更がロゴだけでも、ビルド成果物の配置やインストーラ生成工程でpluginsが落ちると同じ症状になります。まずは「platformsが入っているか」「正しいQtでdeployしているか」を最優先で確認してください。 doc.qt.io+1