C++のフレームワークを選ぶときは、最初に「どれが人気か」「どれが速いか」ではなく、何を作るのかを明確にすることが重要です。
C++は非常に用途の広い言語です。
デスクトップアプリ、Webサーバー、組み込み機器、ゲーム、画像処理、数値計算、CLIツール、ライブラリ開発など、使われる分野が幅広いため、すべての用途に対して万能なフレームワークはありません。
そのため、C++のフレームワーク選定では、まず次のような観点を整理する必要があります。
C++フレームワークを選ぶ前に整理すべきこと
作りたいものを明確にする
最初に決めるべきなのは、アプリケーションの種類です。
たとえば、以下のように用途によって選ぶべき候補は大きく変わります。
デスクトップGUIアプリを作るのか、Web APIを作るのか、組み込み機器向けのソフトウェアを作るのか、ゲームを作るのか、高性能なネットワークサーバーを作るのかによって、適したフレームワークは異なります。
同じC++でも、GUIアプリならQtやwxWidgets、Web APIならDrogonやCrow、低レイヤーのネットワーク処理ならBoost.AsioやBoost.Beast、ゲームならUnreal EngineやSDL、SFMLなどが候補になります。
動作環境を決める
次に、どの環境で動かすのかを確認します。
Windowsだけでよいのか、macOSやLinuxにも対応するのか、組み込みLinuxで動かすのか、マイコン上で動かすのかによって、選択肢は大きく変わります。
クロスプラットフォーム対応が必要な場合は、QtやwxWidgetsのような複数OS対応に強いフレームワークが候補になります。
一方で、特定環境に最適化したい場合は、OSやSDKに近いライブラリを選んだ方がよいこともあります。
重視する条件を決める
フレームワーク選びでは、何を優先するかも重要です。
開発速度を重視するのか、実行速度を重視するのか、メモリ使用量を抑えたいのか、長期保守を重視するのか、商用利用のしやすさを重視するのかによって、選ぶべきものは変わります。
特にC++では、パフォーマンスだけでなく、ビルドのしやすさ、依存関係の管理、チームメンバーの習熟度、ドキュメントの充実度も重要な判断材料になります。
ライセンスを確認する
商用開発では、ライセンス確認は非常に重要です。
MIT、BSD、Boost Software Licenseのように比較的扱いやすいライセンスもあれば、GPL、LGPL、商用ライセンスのように配布形態やリンク方式によって注意が必要なものもあります。
特にQtのような大規模フレームワークでは、オープンソース版と商用版で利用条件が異なるため、製品として配布する前に必ずライセンス条件を確認するべきです。
ただし、商用ソフトウェアだから必ず商用ライセンスが必要というわけではありません。
LGPLなどの条件を満たせる場合は、オープンソース版を使えるケースもあります。
重要なのは、配布形態やリンク方式、自社のソース公開方針に合っているかを確認することです。
デスクトップGUIアプリ向けのフレームワーク
Qt
本格的なデスクトップGUIアプリを作るなら、Qtは有力な候補です。
QtはWindows、macOS、Linuxなどに対応したクロスプラットフォームGUIフレームワークです。GUIだけでなく、ネットワーク、ファイル操作、スレッド、データベース、国際化、QMLによるUI開発など、多くの機能を備えています。
商用アプリや業務アプリ、長期保守を前提としたデスクトップアプリでは、Qtが第一候補になることが多いです。
Qtが向いているケース
Qtは、複雑なGUIを持つアプリケーションに向いています。
たとえば、業務用デスクトップアプリ、設定ツール、エディタ、管理ツール、組み込み機器のタッチパネルUI、複数OS対応の商用ソフトウェアなどに適しています。
Windows、macOS、Linuxに同じコードベースで対応したい場合にも、Qtは強力な選択肢になります。
Qtのメリット
Qtの大きなメリットは、機能が非常に豊富なことです。
GUI開発に必要な機能だけでなく、アプリケーション開発全体に必要な機能がまとまっています。
そのため、複数のライブラリを細かく組み合わせるよりも、Qtを中心に構成した方が開発しやすいケースがあります。
また、ドキュメントや事例が多く、商用サポートがある点も実務では大きな強みです。
Qtの注意点
Qtは便利ですが、学習コストは低くありません。
Qt独自の仕組みであるシグナル・スロット、QObject、メタオブジェクト、QMLなどに慣れる必要があります。また、小規模なツールに使うにはやや大きすぎる場合もあります。
商用利用では、ライセンスの確認も必須です。特に静的リンク、組み込み配布、アプリストア配布、クローズドソース製品としての配布では慎重に判断する必要があります。
wxWidgets
OSネイティブな見た目を重視したい場合は、wxWidgetsが候補になります。
wxWidgetsは、Windows、macOS、Linuxなどで動作するクロスプラットフォームGUIフレームワークです。
各OSのネイティブコントロールを使うため、アプリケーションがそのOSらしい見た目になりやすいという特徴があります。
wxWidgetsが向いているケース
wxWidgetsは、ネイティブUIの見た目を重視したいデスクトップアプリに向いています。
Qtほど大きなフレームワークは必要ないが、複数OSに対応したGUIアプリを作りたい場合に検討しやすい選択肢です。
伝統的なデスクトップアプリ、業務ツール、軽めのGUIアプリなどに向いています。
wxWidgetsの注意点
wxWidgetsはネイティブUIに強い一方で、モダンで自由度の高いUI表現ではQtやQMLに比べて弱く感じる場合があります。
また、複雑なアプリケーションになると、アーキテクチャ設計やイベント処理の設計が重要になります。
Dear ImGui
開発者向けツールやデバッグUIを作るなら、Dear ImGuiが非常に便利です。
Dear ImGuiは、即時モードGUIと呼ばれるスタイルのライブラリで、ゲームエンジン内のデバッグ画面、パラメータ調整ツール、リアルタイム可視化ツールなどによく使われます。
Dear ImGuiが向いているケース
Dear ImGuiは、エンドユーザー向けの一般的なGUIアプリよりも、開発者や制作者が使う内部ツールに向いています。
ゲーム開発、映像制作ツール、シミュレーション、デバッグパネル、リアルタイム調整画面などで特に力を発揮します。
Dear ImGuiの注意点
Dear ImGuiは非常に軽量で扱いやすい一方、OSネイティブな見た目やアクセシビリティ、一般ユーザー向けの完成度を重視するアプリには向きにくいです。
一般ユーザー向けの本格的なGUIアプリを作る場合は、QtやwxWidgetsの方が適していることが多いです。
Web API・Webサーバー向けのフレームワーク
C++でWebを作るべきかを先に考える
C++でWeb APIやWebサーバーを作ることは可能です。
ただし、まず考えるべきなのは、本当にC++でWebを作る必要があるかという点です。
一般的なWebアプリケーションや管理画面、CRUD中心のAPIであれば、Go、Java、TypeScript、Python、Ruby、PHPなどの方が開発効率や人材確保、エコシステムの面で有利なことが多いです。
一方で、既存のC++資産をWeb API化したい場合や、画像処理、音声処理、動画処理、数値計算などの重い処理をC++で直接扱いたい場合には、C++のWebフレームワークが有力な選択肢になります。
Drogon
C++でモダンなWeb APIを作るなら、Drogonは有力候補です。
DrogonはHTTPアプリケーションフレームワークで、非同期処理、高速性、ルーティング、WebSocket、ORMなどを備えています。
C++でREST APIや高性能なWebサーバーを作りたい場合に検討しやすいフレームワークです。
Drogonが向いているケース
Drogonは、高性能なREST API、C++ライブラリのWeb API化、非同期HTTPサーバー、WebSocketを使うアプリケーションなどに向いています。
既存のC++コードを活用しながら、HTTP経由で機能を提供したい場合にも適しています。
Drogonの注意点
DrogonはC++のWebフレームワークとして実用的ですが、Web開発全体のエコシステムで見ると、JavaScript、Go、Java、Pythonなどに比べて情報量や人材は少なめです。
Webだけが目的であれば、他言語のフレームワークも比較対象に入れるべきです。
Crow
Crowは、PythonのFlaskに似た雰囲気で書ける軽量なC++ Webフレームワークです。
シンプルなREST APIや小規模なWebサービス、学習用途、軽い管理APIなどに向いています。
Crowが向いているケース
Crowは、小規模から中規模のHTTP APIを素早く作りたい場合に向いています。
ルーティングがわかりやすく、C++でWeb APIの構造を学ぶ用途にも適しています。
Crowの注意点
Crowを大規模なプロダクション環境で使う場合は、認証、DB接続、ログ、監視、エラー処理、セキュリティ設計、運用体制まで含めて慎重に判断する必要があります。
小さく始めるには扱いやすいですが、大規模化する場合はDrogonやBoost.Beastなどとの比較も必要です。
Boost.Beast
Boost.Beastは、HTTPやWebSocketを扱うための低レイヤー寄りのライブラリです。
DrogonやCrowのようなWebフレームワークではなく、より細かくHTTP通信を制御したい場合に使われます。
Boost.Beastが向いているケース
Boost.Beastは、高性能なHTTPサーバーやWebSocketサーバーを自前で設計したい場合に向いています。
Boost.Asioと組み合わせて、非同期I/Oやネットワーク処理を細かく制御したい場合に有力です。
Boost.Beastの注意点
Boost.Beastは自由度が高い一方で、Webフレームワークとしての便利機能は少なめです。
ルーティング、認証、バリデーション、DB連携、エラーハンドリングなどは自分で設計する必要があります。
そのため、初心者がWeb APIを手早く作る用途にはあまり向いていません。
組み込み・IoT向けの選び方
組み込みでは制約条件が最優先
組み込み向けのC++開発では、一般的なアプリケーション開発とは違い、メモリ、CPU、ストレージ、リアルタイム性、起動時間、消費電力、ハードウェア依存性が非常に重要になります。
そのため、単に有名なフレームワークを選ぶのではなく、対象デバイスの制約に合っているかを確認する必要があります。
組み込みLinuxならQtが有力
組み込みLinux上でタッチパネルUIやHMIを作る場合、Qtは有力な候補です。
産業機器、医療機器、車載HMI、POS端末、制御パネルなど、見た目や操作性が重要な組み込みGUIでは、Qtが使われることがあります。
ただし、Qtは比較的大きなフレームワークなので、メモリやストレージに余裕があるか、GPUや描画環境が適切か、ライセンス条件に問題がないかを確認する必要があります。
軽量GUIならLVGLなども候補
より軽量な組み込みGUIが必要な場合は、QtだけでなくLVGLなどの軽量GUIライブラリも候補になります。
特にマイコンやリソース制約の厳しい環境では、大規模なフレームワークよりも軽量ライブラリや専用SDKを使う方が現実的です。
マイコンでは巨大フレームワークを避ける
マイコン向け開発では、巨大なC++フレームワークを使うより、RTOS、ベンダーSDK、HAL、軽量ライブラリを組み合わせる方が一般的です。
動的メモリ確保を避けるか、例外を使うか、RTTIを使うか、標準ライブラリがどこまで使えるかなど、C++の使い方そのものを慎重に設計する必要があります。
ゲーム・リアルタイム描画向けの選び方
本格3DゲームならUnreal Engine
本格的な3Dゲームや商用ゲームを作るなら、Unreal Engineが有力です。
Unreal EngineはC++をベースにした大規模なゲームエンジンで、高品質な3D描画、物理演算、アニメーション、ネットワーク、エディタ、Blueprintなどを備えています。
Unreal Engineが向いているケース
Unreal Engineは、3Dゲーム、VR、AR、映像制作、シミュレーション、リアルタイムビジュアライゼーションなどに向いています。
商用ゲームや大規模なリアルタイム3Dコンテンツを作る場合には、非常に強力な選択肢です。
Unreal Engineの注意点
Unreal Engineは高機能ですが、学習コストも高いです。
C++だけでなく、Blueprint、Unreal独自のオブジェクト管理、リフレクション、Actor、Componentなどの仕組みを理解する必要があります。
また、プロジェクト規模が大きくなりやすく、ビルド時間やエンジンバージョン管理も重要になります。
2Dゲームや学習用途ならSDL・SFML・raylib
小規模なゲーム、2Dゲーム、学習用途、プロトタイピングであれば、SDL、SFML、raylibなどが候補になります。
SDLは低レイヤー寄りで移植性が高く、ウィンドウ、入力、音声、描画の土台として使えます。
SFMLはC++らしく扱いやすく、2Dゲームや学習用途に向いています。
raylibはシンプルで学習しやすく、プロトタイピングや小規模なゲーム制作に向いています。
CLIツール・汎用ライブラリ開発向けの選び方
大きなフレームワークは不要なことが多い
C++でCLIツールや小規模なユーティリティを作る場合、巨大なフレームワークを導入する必要はないことが多いです。
むしろ、必要なライブラリを組み合わせた方が、軽量で保守しやすい構成になります。
CLIツールでよく使われるライブラリ
CLIツールでは、引数解析、ログ出力、設定ファイル、JSON処理、テスト、フォーマット処理などが必要になります。
このような用途では、CLI11、cxxopts、fmt、spdlog、nlohmann/json、yaml-cpp、toml++、Catch2、GoogleTestなどが候補になります。
フルスタックなフレームワークを使うより、用途ごとに軽量なライブラリを選ぶ方が実務的です。
Boost
Boostは、C++開発で長く使われてきた重要なライブラリ群です。
ネットワーク、ファイルシステム、日付時刻、正規表現、テスト、プログラムオプション、スマートポインタ、非同期処理など、非常に幅広い機能を提供しています。
Boostが向いているケース
Boostは、長期保守が必要なC++プロジェクトや、標準ライブラリだけでは足りない機能を補いたい場合に向いています。
特にBoost.Asio、Boost.Beast、Boost.Program_options、Boost.Testなどは、用途によっては今でも有力な選択肢です。
Boostの注意点
Boostは強力ですが、すべてのプロジェクトに必要なわけではありません。
現代C++では、std::filesystem、std::optional、std::variant、std::any、std::chronoなど、かつてBoostで補っていた機能の一部が標準ライブラリに取り込まれています。
また、fmt、spdlog、CLI11、Catch2などの軽量ライブラリで代替できる場面も多くあります。
そのため、Boostを丸ごと入れるのではなく、必要なライブラリだけを選んで使うのがよいです。
フレームワーク選定で見るべきポイント
メンテナンス状況
フレームワークを選ぶときは、現在もメンテナンスされているかを確認する必要があります。
最近リリースされているか、IssueやPull Requestが放置されていないか、ドキュメントが更新されているか、CIが動いているか、セキュリティ修正が出ているかを確認しましょう。
有名なライブラリでも、実はメンテナンスが停滞している場合があります。
対応C++標準
使用するフレームワークが、どのC++標準を要求するかも重要です。
C++11、C++14、C++17、C++20、C++23のどれに対応しているか、GCC、Clang、MSVCで問題なく使えるかを確認する必要があります。
新規開発であれば、C++17以上を前提にすると扱いやすいことが多いです。
ただし、組み込みや古い環境では、C++11やC++14に制限される場合もあります。
ビルドシステムとの相性
C++では、フレームワークの機能だけでなく、ビルドしやすいかどうかが非常に重要です。
CMakeに対応しているか、vcpkgやConanで導入できるか、Windows、macOS、Linuxで同じようにビルドできるか、CI環境で再現できるかを確認しましょう。
ローカルでは動くがCIで壊れる、Windowsだけリンクエラーが出る、依存バージョンの違いでビルドできない、といった問題はC++では珍しくありません。
パフォーマンス
C++だから必ず速い、フレームワークを使うから必ず遅い、というわけではありません。
実際には、起動時間、メモリ使用量、レイテンシ、スループット、CPU使用率、バイナリサイズ、コンパイル時間、リンク時間などを総合的に見る必要があります。
ベンチマークだけで選ぶのではなく、実際のユースケースに近い小さな検証を行うことが重要です。
学習コスト
C++フレームワークは、APIを覚えるだけでなく、そのフレームワークの設計思想を理解する必要があります。
QtにはQt独自のオブジェクトモデルがあります。Boost.Asioには非同期I/Oの考え方があります。
Unreal EngineにはActorやComponent、Blueprintとの連携があります。
チームがその思想を理解し、長期的に保守できるかを確認することが重要です。
ドキュメントと情報量
公式ドキュメントの質も重要です。
チュートリアルが最新か、APIリファレンスが整っているか、サンプルが実際に動くか、CMakeでの導入方法が説明されているか、エラー処理やスレッド安全性について説明があるかを確認しましょう。
C++はコンパイルエラーやリンクエラーで詰まりやすいため、情報量の少ないフレームワークは採用リスクが高くなります。
チームの習熟度
技術的に優れたフレームワークでも、チームが使いこなせなければ負債になります。
C++上級者が多いチームであれば、Boost.Asioや低レイヤー寄りの設計も可能です。
一方で、C++経験が浅いメンバーが多い場合は、ドキュメントが充実していて設計がわかりやすいものを選んだ方が安全です。
「最も高性能なもの」よりも、「チームが安全に開発・保守できるもの」を選ぶべきです。
用途別のおすすめ
本格的なデスクトップGUI
本格的なデスクトップGUIアプリを作るなら、Qtが有力です。
複雑な画面、複数OS対応、商用利用、長期保守を前提にするなら、Qtは非常に強い選択肢になります。
ネイティブUI重視のデスクトップアプリ
OS標準の見た目を重視したい場合は、wxWidgetsが候補になります。
Qtほど大きなフレームワークを使わずに、ネイティブ寄りのGUIアプリを作りたい場合に向いています。
開発者向けツール
デバッグUIやリアルタイム調整ツールを作るなら、Dear ImGuiが向いています。
ゲーム開発、シミュレーション、社内ツール、開発支援ツールなどで特に便利です。
C++ Web API
C++でWeb APIを作るなら、Drogonが有力です。
軽量なAPIや学習用途ならCrowも候補になります。
HTTPやWebSocketを細かく制御したい場合は、Boost.Beastを検討できます。
CLIツール
CLIツールでは、大きなフレームワークを使うより、CLI11、fmt、spdlog、nlohmann/json、Catch2などを組み合わせる方が実務的です。
軽量で依存が少なく、ビルドや配布もしやすくなります。
組み込みGUI
組み込みLinuxやHMIでは、Qtが有力です。
ただし、マイコンやリソース制約の厳しい環境では、LVGLなどの軽量GUIライブラリやベンダーSDKを使う方が適している場合があります。
ゲーム開発
本格的な3DゲームならUnreal Engineが有力です。
2Dゲーム、学習用途、小規模なゲーム制作では、SDL、SFML、raylibなどが候補になります。
よくある失敗パターン
ベンチマークだけで選ぶ
フレームワーク選びでよくある失敗は、ベンチマークだけを見て選ぶことです。
たしかに性能は重要ですが、実際のアプリケーションでは、DB、JSON処理、ログ、認証、外部API、メモリ管理、スレッド設計など、さまざまな要素がボトルネックになります。
最速のフレームワークよりも、保守しやすく、運用しやすい構成を選ぶ方が重要です。
小規模ツールに大規模フレームワークを使う
小さなCLIツールや簡単な社内ツールに、大規模なフレームワークを導入すると、ビルドや配布が重くなることがあります。
必要な機能が少ない場合は、軽量ライブラリを組み合わせる方がシンプルです。
ライセンス確認を後回しにする
商用開発でライセンス確認を後回しにするのは危険です。
静的リンク、動的リンク、組み込み配布、アプリストア配布、クローズドソース配布、SDKとしての再配布などによって、ライセンス上の条件が変わることがあります。
技術選定の初期段階で、ライセンスは必ず確認するべきです。
チームの習熟度を無視する
フレームワークの機能だけを見て選び、チームの習熟度を無視すると、保守できないコードになりやすいです。
C++は言語自体の難易度が高いため、フレームワークまで複雑すぎると開発速度が落ちます。
チームが理解しやすく、安全に扱えるものを選ぶことが大切です。
C++で作る必要がないものまでC++で作る
C++は強力な言語ですが、すべての用途に最適なわけではありません。
一般的なWebアプリや管理画面、CRUD中心のシステムでは、他の言語やフレームワークの方が開発効率が高いことも多いです。
C++を選ぶ理由が、性能、低レイヤー制御、既存資産、組み込み制約、リアルタイム性などにあるかを確認するべきです。
実務での選定フロー
まず用途を一文で定義する
最初に、作りたいものを一文で説明できるようにします。
たとえば、Windows、macOS、Linux対応の業務GUIアプリ、Linuxサーバー上で動く高性能REST API、既存C++ライブラリをHTTP経由で呼び出すWebサービス、産業機器向けのタッチパネルUIなどです。
この一文が曖昧だと、フレームワーク選定も曖昧になります。
絶対条件を決める
次に、絶対に外せない条件を決めます。
対応OS、商用利用、メモリ制限、起動時間、C++標準、ライセンス、静的リンクの可否、配布方法、長期保守の必要性などを整理します。
ここを決めると、候補はかなり絞れます。
候補を3つまでに絞る
最初から多くの候補を比較すると、判断が難しくなります。
GUIならQt、wxWidgets、Dear ImGui。WebならDrogon、Crow、Boost.Beast。CLIならCLI11、cxxopts、Boost.Program_optionsのように、用途ごとに最大3つ程度に絞ると比較しやすくなります。
小さな検証を行う
C++のフレームワーク選びでは、記事を読むだけでなく、小さく試すことが重要です。
Hello Worldだけでなく、実際に必要になる機能を試しましょう。
GUIなら日本語入力、高DPI対応、ファイル選択、ダークモード、配布方法などを確認します。
Webならルーティング、JSON入出力、エラー処理、ログ、DB接続、Docker化、CIでのビルドを確認します。
CLIなら引数解析、設定ファイル、ログ、テスト、クロスプラットフォームビルドを確認します。
まとめ
C++のフレームワーク選びでは、人気や性能だけで決めるのではなく、用途、動作環境、ライセンス、ビルド、保守性、チームの習熟度を総合的に判断する必要があります。
デスクトップGUIや組み込みGUIならQtが有力です。ネイティブUIを重視するならwxWidgets、開発者向けツールならDear ImGuiが向いています。
C++でWeb APIを作るならDrogonやCrowが候補になります。
HTTPやWebSocketを細かく制御したいならBoost.Beastも検討できます。
ただし、一般的なWeb開発ではC++以外の言語も比較すべきです。
CLIツールや小規模なユーティリティでは、大規模なフレームワークを使うより、CLI11、fmt、spdlog、nlohmann/json、Catch2などの軽量ライブラリを組み合わせる方が実務的です。
組み込み開発では、対象デバイスの制約が最優先です。
組み込みLinuxのGUIならQtが有力ですが、マイコンや軽量GUIではLVGLやベンダーSDKを中心に考えるべきです。
ゲーム開発では、本格3DならUnreal Engine、小規模2Dや学習用途ならSDL、SFML、raylibなどが候補になります。
最終的には、5年後も保守できるか、チームが理解できるか、ビルドと配布が安定するか、ライセンス上問題ないかを基準に選ぶのが安全です。
C++では、最も有名なフレームワークを選ぶより、プロジェクトの目的に合った構成を選ぶことが重要です。
以上、C++のフレームワークの選び方についてでした。
最後までお読みいただき、ありがとうございました。
