QMK と ZMK の違いは？自作キーボードで迷わないファームウェア選び

自作キーボードを使い始めて、VIA や Vial の次に firmware レベルまで触ってみたい人 向けの記事です。QMK と ZMK はどちらも有名ですが、向いている前提がかなり違います。

先に結論を言うと、有線中心で既存の対応キーボード資産を活かしやすいのが QMK、無線や宣言的な設定を重視しやすいのが ZMK です。読了後には、自分が最初にどちらを触るべきかを判断しやすくなります。

TL;DR

QMK は有線前提で使われることが多く、keymap.c を中心に細かく調整したい人に向いています。
ZMK は BLE を含む無線運用や、.keymap を中心にした宣言的な設定に向いています。
GUI で始めたい場合、QMK には QMK Configurator、ZMK には ZMK Studio があります。
迷ったら、今あるキーボードが QMK 前提なら QMK、これから無線込みで組むなら ZMK と考えると整理しやすいです。
優劣ではなく、運用したい形と手元の資産に合うか で選ぶのが失敗しにくいです。

まず結論: QMK と ZMK は「できること」より「前提」が違う

QMK と ZMK は、どちらもレイヤー、タップホールド、マクロのような高度なキーマップを扱える firmware です。
ただし、何を前提に設計されているか が違います。

QMK は公式ドキュメントでも keymap.c、config.h、rules.mk を中心にした構成が案内されており、コード寄りに育てる感覚 が強いです。

一方の ZMK は公式ドキュメントで .keymap と devicetree 構文を使う宣言的な方式を採っています。さらに ZMK Studio によって、対応構成なら実行中にキーマップを更新できます。

この違いが、そのまま「初心者が最初にどこで詰まりやすいか」に直結します。

QMK と ZMK の比較表

比較軸	QMK	ZMK
有線/無線	有線中心で考えやすい	BLE 対応を前提に考えやすい
学習コスト	`keymap.c`、`config.h`、`rules.mk` の役割分担を覚える必要がある	`.keymap` と devicetree、behavior の考え方に慣れる必要がある
既存キーボード資産	既に QMK 前提で紹介されているキーボードや手順を活かしやすい	新しく ZMK 前提で組むと整理しやすい
GUI運用	QMK Configurator が入口になる	ZMK Studio が強い。ただし対応構成が前提
詰まりやすい点	どのファイルに何を書くかで混乱しやすい	devicetree と behavior の考え方で止まりやすい

有線/無線

最初に見るべき軸はここです。
有線中心なら QMK、無線を重視するなら ZMK と考えると大きく外しません。

QMK は有線キーボードでの利用イメージを持ちやすく、既存のビルドやキーマップ管理もその前提で入っていきやすいです。
一方 ZMK は Bluetooth 機能が公式機能として整理されており、無線 split やモバイル併用を考えると強みが出ます。

「ノート PC、タブレット、スマホでも同じキーボードを使いたい」という発想が最初からあるなら、ZMK を先に見る価値があります。

学習コスト

初学者が苦しみやすいのは、「難しい機能」より「設定の置き場」です。

QMK は keymap 構造の公式説明の通り、最低限 keymap.c が必要で、必要に応じて config.h や rules.mk を触ります。
つまり、「この設定はどこに書くのか」を覚える段階があります。

ZMK は Keymaps & Behaviors にある通り、.keymap に寄せて考えやすい一方で、devicetree の書き方や behavior の理解が必要です。
そのため、C 由来の分割で迷いやすいのが QMK、devicetree の文法で迷いやすいのが ZMK です。

どちらが簡単かは一概に言えません。
ただし「設定を 1 ファイル寄りで追いたい」なら、最初の印象は ZMK のほうが入りやすい人が多いです。

既存キーボード資産

ここは初心者ほど重要です。
今持っているキーボードが何を前提にしているか で、最初の選択はかなり決まります。

すでに QMK 対応として売られていたり、QMK ベースの手順が多く見つかるキーボードなら、まずは QMK から入るほうが自然です。
無理に ZMK に寄せるより、既存の手順やサンプルをそのまま使えるほうが最初の成功率は上がります。

逆に、これからコントローラや無線運用を含めて新しく組むなら、最初から ZMK 前提で考えるほうが設計がすっきりします。

GUI運用

CLI を避けたいなら、ここも重要です。

QMK には QMK Configurator があります。これはオンライン GUI で .hex や .bin を生成できる公式ツールです。
ただし公式 docs にもある通り、別コントローラへの置き換えを含むようなケースは Configurator だけでは扱えません。

ZMK には ZMK Studio があります。対応済みの構成なら、キーボード使用中にキーマップ変更ができます。
さらに公式 docs では、USB だけでなく BLE 経由での変更にも触れられています。

ただし、ZMK Studio は「ZMK なら全部そのまま使える」わけではありません。
公式 docs にある通り、キーボード側の対応設定が必要 です。ここは期待しすぎないほうが安全です。

詰まりやすい点

比較記事で大事なのは、良い点より どこで止まりやすいか です。

QMK で詰まりやすい点

keymap.c、config.h、rules.mk の役割分担で迷いやすい
Configurator でできる範囲と、コード編集が必要な範囲の境目で迷いやすい
QMK CLI を使う段階で、ローカル環境構築が必要になる

ZMK で詰まりやすい点

devicetree の考え方に慣れるまで読みづらい
behavior の組み合わせが分かるまで、.keymap の見通しが急に悪くなることがある
無線前提の便利さに目が行きやすいが、最初は build や board 対応の理解も必要になる
ZMK Studio は便利だが、対応済みかどうかを先に確認する必要がある

初めて触る人向けのおすすめ判断

初心者向けにかなり単純化すると、次のように考えると決めやすいです。

QMK を先に触るとよい人

すでに手元のキーボードが QMK 前提で紹介されている
まずは有線で安定して使えればよい
設定をコードとして細かく管理したい
GUI から始めても、必要なら CLI に進むつもりがある

ZMK を先に触るとよい人

無線や BLE を含めて使いたい
新しくキーボード構成を組む予定がある
.keymap を中心に設定を見通しよく保ちたい
対応しているなら ZMK Studio を活かしたい

判断フロー

最後に、迷ったときの流れを文章でまとめます。

無線を使いたいか を最初に決める
- 使いたいなら ZMK を先に検討する
- 使わないなら次へ進む
今あるキーボードが何を前提にしているか を確認する
- QMK 前提なら QMK を優先する
- これから新しく組むなら次へ進む
設定をどう管理したいか を決める
- C ベースで細かく触りたいなら QMK
- .keymap で宣言的に整理したいなら ZMK
GUI をどこまで重視するか を確認する
- QMK Configurator で入口だけ作れればよいなら QMK
- 対応構成で runtime 変更を重視するなら ZMK

簡易診断

次の質問に当てはまるものが多いほうを選ぶと、最初の一歩で失敗しにくいです。

QMK 寄り

今あるキーボードを活かしたい
有線で困っていない
コードを読んで設定を詰めるのが苦ではない
まずは QMK Configurator から入りたい
将来的に CLI ベースの管理も受け入れられる

ZMK 寄り

無線を使いたい
split keyboard を無線込みで考えている
.keymap 中心で設定を把握したい
対応していれば ZMK Studio を使いたい
新規構成なので firmware の前提を自分で選べる

まとめ

QMK と ZMK は、どちらも優れた keyboard firmware です。
違いは「どちらが上か」ではなく、どの前提で始めると楽か にあります。

QMK は有線中心、既存資産を活かしやすく、コードで細かく育てたい人向けです。
ZMK は無線との相性がよく、宣言的な設定や ZMK Studio を活かしたい人向けです。
初めて firmware レベルまで触るなら、今あるキーボード資産と無線の要否 を最優先に決めるのが近道です。

迷ったら、まずは 手元のキーボードで成功しやすいほう を選ぶのがおすすめです。最初の 1 回で「書けた」「焼けた」「使えた」を経験できるほうが、その後も続けやすいです。