fcitx5の公式から見る2026年の設定事情

この記事の内容についてなるべく古いアプリなども考慮に入れた設定も提示したいですが(書くのも検証するのも)、面倒だと言うのもあり、きっと古いアプリにあわせた設定を書かずとも、他で新しく同等以上の機能を持ったアプリが出てるだろうと思うので((なかったらAIにでも聞いて下さい))、それを使用したらいいやんと、2026年2月現在のfcitx5公式wikiの内容に沿って記事を書いた次第です

Fcitx5

fcitx5は、Linuxで日本語を入力するためのもの、つまりはインプットメソッドフレームワークです。フレームワークなので、エンジンであるfcitx5-mozcをインストールすることで、Google日本語入力のオープンソース版を利用可能になります。従来のfcitx4から設計が刷新され、Wayland環境に標準対応しています。

GTKとQT

fcitx5-imグループをインストールすることで、fcitx5、fcitx5-gtk、fcitx5-qt、fcitx5-configtoolなどがインストールできます。基本的には全てインストールしておけば良いと思います。

GTK/QT環境に特化したいとか、最小構成にしたい時にはそれぞれ個別に必要なものをインストールすればよいかと思います。

インストールできるエンジンは、Mozc以外にも種類があり、fcitx5-skk、fcitx5-kkc、fcitx5-anthyなどがありますが、WindowsやMacと同じような感覚で入力するのであれば基本的にはMozc一択です。skkなどでは、独特な入力方式であり習得に時間がかかります。

GTKとはGIMP toolkitの略で元々はGIMPを作るために開発されたライブラリです。C言語で書かれており、Gnomeデスクトップの土台となっています。ライセンスが完全に自由なためオープンソースの世界で広く普及しました。代表的なアプリとしては、Firefox, LibreOffice, GIMP

QTとは読み方は「キュート」と読みますが、「キューティー」という人も多いと思います。C++で書かれており、KDE Plasmaデスクトップの土台となっています。非常に強力でLinuxだけではなくWindows、Mac、Android、iOS、更にはカーナビなどの組み込み機器まで、同じコードで動かせるマルチプラットフォーム性能が極めて高いのが特徴です。代表的なアプリとしては、VLC, OBS Studio, VirtualBox

GTKとQTの話になったのは、これらは見た目（ボタン、メニュー、ウィンドウなど）を作るためのGUIライブラリではありますが、fcitx5-gtkしか導入していない場合に、VLCで動画を見ようとした時に日本語入力ができなくなることがあるからです。

GUIライブラリGUIライブラリあるいはツールキットなどと呼ばれ、ボタン、スライダー、チェックボックス、テキストボックスなどの「部品（ウィジェット）」を提供し、それらを配置して画面を作るためのプログラム集です。フレームワークとしての側面もあり、単に「見た目の部品」だけでなく、イベント処理（ボタンが押された時の動作）や、今回のような「文字入力の受け渡し（インプットメソッドとの通信）」などの複雑な仕組みも一括して管理しています

WaylandはGTKやQTなどの特定のツールキットに依存しなくても共通のプロトコルで入力をやり取りするという理想があります。しかしWaylandがまだ発展途上でもあり、文字は入力できても表示されない((Windowsでもたまにフォーカスがおかしくなって別の小さなウィンドウが出る事ありますが同様のことが起こったり))といった挙動の乱れが起こることがあるわけです。モジュール(fcitx5-gtk/qt)を使用すると、各ツールキットがfcitx5と直接通信するため変換中の文字がアプリ内にきれいに収まるようになります。そのため、現在ではまだモジュール(fcitx5-gtk/qt)を使用する必要があるのです。なので最小構成ではなく全部入りで導入する事が、どんなアプリを使うかを気にせずに使えるという理由になります。

理想は「モジュールなし」 ですが、現実の快適さを取るなら 「モジュールを入れておく」 のが現時点での ベストプラクティス です。

Arch Linux系でpacmanを使用できる場合では、ターミナルから、

sudo pacman -S fcitx5-im fcitx5-mozc

でインストールできます。上記のGTKとQTを理解していれば、インストール時に何を選択したら良いかがわかるようになるのではないでしょうか？仮にPamacや他のディストリビューションでGUIなパッケージ操作ができたとしても、インストール時には選択肢が表示されると思います。それらで迷わないように。

sudo apt install fcitx5 fcitx5-frontend-gtk3 fcitx5-frontend-qt5 fcitx5-configtool fcitx5-mozc

sudo dnf install fcitx5 fcitx5-gtk fcitx5-qt fcitx5-configtool fcitx5-mozc

sudo zypper install fcitx5 fcitx5-gtk3 fcitx5-qt5 fcitx5-configtool fcitx5-mozc

IBusなどが使用できる場合、それを使用しても日本語入力は可能ですが、どのディストリビューションでも一貫して同じやり方でアプリ設定などができるfcitx5を使用するのが良いのではないかと思います。以下の記事の中にも書いていますが、IBusと強く統合されているデスクトップ環境の場合に、fcitx5を使用するということは工夫が必要な場合もあります。しかしながらX11からWaylandに移行しつつある現在では、なるべくならWaylandに対応した環境で設定を覚えるのが良いのではないかとこの記事を書いています。

ibus-typerというものが開発中で、IBusをよりモダンなRust言語で書き直そうとする動きや、新しい入力プロトコルへの模索がありますが、fcitx5のシェアを脅かすほどの完成度に至った後継プロジェクトはまだありません。それぐらいfcitx5は2026年2月現在、頭一つ抜けているのです。

Fcitx5公式ではどう書いてあるのか

公式wiki: https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland

2026年は多くのディストリビューションがWaylandに対応しつつあり、現在の主流では環境変数を最小限にし、Waylandプロトコルに任せるという方向に進化しています。

これまでX11の場合は、

# skip-copy
# システム全体に適用する場合: /etc/environmentに、
# あるいはユーザーディレクトリの場合: ~/.xprofile等に

XMODIFIERS=@im=fcitx
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx

このような記述が必要でした。以前のように「とりあえず/etc/environmentに3行書く」というやり方は、Wayland環境ではむしろ推奨されないケースが増えています。

text-input プロトコルの活用

Wayland環境では、アプリとIMEの通信に text-input-v3 などのプロトコルが使われます。これにより、環境変数を設定しなくても日本語が打てるアプリが増えています。

ここから、環境変数を設定せず、アプリが直接Wayland経由で使用できると言うのが理想ですが、まだ完全にwaylandに移行しているわけではないので、不完全なアプリ(古いGTK2や特定のElectronアプリ)のために、補助的な設定が必要になっています。

上記のように「環境変数を書かない」のが基本になりつつあります。 設定しなくても動くなら、それが最も安定します。

Qt6.7以降では、フォールバックを記述して、

QT_IM_MODULES="wayland;fcitx"

このような記述をするのが増えています。Qt6.7以降で導入された環境変数で、Waylandネイティブ入力を優先して、フォールバックとしてfcitx5(やIBus)を指定するもので、公式では上記例のように書かれています。これはセミコロン(;)区切りのリストを正しく扱うためです。

Ibusもフォールバックする場合は、

QT_IM_MODULES="wayland;fcitx;ibus"

という事です。

主に非KDEではこのように書いて、KDEでは書かないのがベストとされています。またfcitx5ではなくfcitxである所も注意です。

ここで、クォート(")で囲むか囲まないかの違いがでてきます。例えば、Hyprlandで環境変数を書く場合は、

env = QT_IM_MODULES,wayland;fcitx

このように書きます。この場合は、クォート(")では囲みません。

一方、（~/.bashrc, ~/.profileなど）では、

export QT_IM_MODULES="wayland;fcitx"

このようにクォート(")が必須になります。bash/zshではセミコロンがコマンド区切りとして解釈されるため、クォートなしだとエラーになります。

システム全体に適用される/etc/environmentでは、

QT_IM_MODULES=wayland;fcitx

のようにクォートを書きません。systemd/pam_envの仕様でクォートは不要です（むしろ剥がされる）。

これらのように設定場所に応じて使い分ける必要がある ということです。こういった所がややこしいわけです。

デスクトップ環境ごとの事情

GNOME(Wayland)

GnomeはIBusとの統合が非常に強力なため、fcitx5を使用する場合は少し工夫が必要です。

• 環境変数は基本的に不要
• 必須な事項として、gnome-shell-extension-kimpanelをインストール。
  • これがないと入力候補ウィンドウが変な場所に表示されたり、表示されなかったりします。公式WikiではGNOME特有の追加ポイントとして「Fcitx5のIBus frontendが必要」（GNOMEがIBus DBusプロトコルを使っているため）と明記されています
• /etc/xdg/autostart/にあるorg.fcitx.Fcitx5.desktopが機能していればOK
  • org.fcitx.Fcitx5.desktopはfcitx5をインストールすると自動で作成される
  • 存在していれば基本的には問題ないが、IBusが優先されてfcitx5をブロックし、fcitx5が起動しない場合もあるようです。
    • この場合はGnome TweaksのStartup Applicationsでfcitx5を手動追加
    • あるいは~/.config/autostart/にorg.fcitx.Fcitx5.desktopを/etc/xdg/autostart/からコピー

Linuxディストリビューションでよく見るXDGとはX Desktop Groupの略で、現在はfreedesktop.orgと言う組織が管理しています。GNOME、KDE、XFCE、LXDEなど様々なデスクトップ環境が共通のルールで動作するようにするための仕様（specification）をたくさん作っています。「X」はクロスと言う意味で、「どのデスクトップ環境を使っていても、同じように動くようにしよう」という目的の規格群です。このため、Linuxの各ディストリビューションのユーザーディレクトリ等の構造は似通っており、上記の自動起動にしても同じ規格で動作するようになっています。違うものは例えばHyprlandがexec-onceであったり、KDE PlasmaではXDGに準拠していますが、~/.config/autostart-scripts/という独自規格をサポートしています。

gnome-shell-extension-kimpanelについて

これのインストールの流れですが、

• Gnomeのアプリ一覧(あるいはアプリ一覧画面で「extension」検索｜Windows/⌘ キー + A)から見つかる「拡張機能」アプリを開く
  • これはGnomeの拡張機能自体を、extensions.gnome.orgから探し、webから導入。

このようにするのが従来かつ現行の拡張機能の導入方法ですが、拡張機能の導入だけをするのに毎回それだと結構手間でもあるので、

1. FlatpakにあるExtension Managerを導入
2. Extension Managerから該当の拡張機能を導入する

という手順の方が今後拡張機能を探すのも何かと便利になります。

上記画像のような感じで導入できるExtension Managerのインストール方法は、

1. Flatpakでインストール(初めて導入する場合、既に導入済みなら不要)

   flatpak install flathub com.mattjakeman.ExtensionManager

   • Ubuntu/Fedoraなどではgnome-shell-extension-managerパッケージもあるが、Flatpak版の方が最新で安定しやすい
   • 「ソフトウェアの追加と削除」アプリからでも可能。Gnome純正の同アプリでExtension Managerを検索したらインストールはFlatpakになっていますのでGUIで導入できます

2. Extension Managerを起動 → Browse(検索)タブで「kimpanel((おそらく KDE Input Method Panelだろうかと))」または「Input Method Panel」を検索(上記最初の画像)

3. インストール → 有効化(上記最後の画像)

4. Gnomeのログアウト → ログイン

• Flatpak版Fcitx5を使っている場合、IME自体をFlatpakで入れているとIMモジュールがホストに届かないので、fcitx5はネイティブインストール((パッケージマネージャーあるいはそれらGUI版から導入する事))推奨。Kimpanelはシェル拡張なので影響なし

これらの方法は古いバージョンのGnomeだとエラーが出る可能性があります。何度か拡張機能の刷新があったと思いますがGnome45.3で拡張機能が機能しなくなったというのを覚えています。Gnome46(2024年4月ぐらい)からは現行と同様になったはずなので46以降なら問題ないかと。それ以前は問題がある可能性があります。2026年2月現行版のGnomeだと問題ありません(実証済み。画像参考)。

Gnomeのまとめ

インストールの方法なども書いたので煩雑(はんざつ)になってしまいましたが、簡単にまとめると、

• 設定不要（XWaylandアプリで稀に必要になる場合を除き、グローバルに設定しないのが公式推奨）
• 拡張機能で、kimpanelを探して入れる
• (ほぼ大丈夫だが、自動起動が効いているか念のため確認）

と言うだけのことです。実質、fcitx5をインストールして、拡張機能でkimpanelを入れれば良いと言う話です。他は必要に迫ったらという感じです。

KDE Plasma(6.0以降)

KDEはfcitx5と最も相性が良い環境です。Wayland-onlyの宣言もしており、X11は廃止していくことが現実味を帯びてきていますが、X11のアプリが動かなくなるということはなく、XWaylandという互換レイヤーがバックグラウンドで動作し、古いアプリの描画をWayland上で肩代わりします。

• システム設定の「仮想キーボード」項目から「Fcitx5」を選択するだけ

これだけでKWin(コンポジタ)が適切にfcitx5をハンドリングして、環境変数を手動で書かなくてもほぼすべてのアプリで動作するようになります。

デフォルトデスクトップ環境にKDE Plasmaが多く採用されているのはこういう所にあるのかも知れません。

Hyprland / Sway

• ~/.config/hypr/hyprland.confなどでexec-once = fcitx5 -dを記述する。ログインしたらfcitx5が実行されるようにする設定
  • 「などで」という意味としては、自動起動するものだけ別でまとめて書いてある場合があるからです
• 同様に、環境変数でenv = XMODIFIERS, @im=fcitxは書いておくと無難です。無くても問題ないですが古いアプリでfcitx5が動作しないなどがあった場合に。他の変数は特定のアプリ(VSCodeなど)で文字入力ができない場合にのみ追加します

そもそもシステムファイルである/etc/environmentを書き換えることができないと言う人もいたかも知れません。そういう人にこれまでは必要なことだからと書き換えを強要していたわけです。結果、設定できずに「どうしたらいいんだ？！」となって、そらLinux嫌いになっても仕方ありません。むしろそういうちょっとした事で躓(つまづ)いた人が未(いま)だに悪口を言っているのです。

Waylandでは、これまでのX11のようにシステムファイルの環境変数を書き換えたり、ユーザーファイルに追記する等の方法よりは、ずっと簡単になっているので、Wayland対応のデスクトップ環境を利用するのが得策です。Hyprland、Niriの設定はユーザーディレクトリ以下にあるので管理者権限も不要で、設定したら即反映になっています。KDEは選択するだけ、GNOMEは拡張機能入れるだけというお手頃な状態まで来ました。

しかし、一部のアプリではまだ問題点もあり、特定のアプリでは追加設定が必要になることがあります。

特定のアプリへの対策

• Chromium / Chrome / Electron (VSCode, Discord等)をWaylandで動かす場合、フラグが必要なことがあります。

  --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime

  ※ 最近のバージョンでは --wayland-text-input-version=3 を指定するとより安定します。

• Flatpak アプリでは、ホストのIME設定が見えないことがあるため、Flatseal などのツールで環境変数を個別に許可する必要があります。ただしこれも基本と同様に、必要に迫ったらと言う感じです。

フラグの設定方法

Chromium / Electronアプリのフラグの設定方法は、起動コマンドに引数(フラグ)を追加するのが基本ですが、手動で毎回打つのは現実的ではありません。Arch Linuxなどの一部のディストロでは~/.config/ディレクトリ以下にフラグ用のファイルを置くだけでランチャーからの起動時にも自動適用される仕組みがあります。

• VSCode(OSS版)の場合~/.config/electron-flags.confあるいは、electron-バージョン番号-flags.confがあれば、そのファイルの中身を

  --enable-features=UseOzonePlatform
  --ozone-platform=wayland
  --enable-wayland-ime

  と記入します。

もし、メニューやドックからアイコンをクリックして起動する場合は、システムのショートカットファイルを自分の設定で上書きするという方法もあります。

1. /usr/share/applications/discord.desktopなどを~/.local/share/applications/にコピーします。これで使用しているユーザーの環境でだけ設定変更することができます
2. コピーしたファイルをテキストエディターなどで開き、Exec=の行を書き換えます
   • 修正前は、Exec=/usr/bin/discord
   • 修正後は、Exec=/usr/bin/discord --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime

• Hyprlandなどでは、

  キーバインドの設定(~/.config/hypr/以下のbind.conf)で、

  # ターミナルからVSCodeを起動する場合のバインド例
  bind = $mainMod, C, exec, code --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime

  のように書けば同じ事になります。

  $mainModは大抵の場合SUPER(Windowsキー/Macでは⌘キー)で、続くCは任意のキーの組み合わせです。つまり上記の例で言うと、SUPER(Windowsキー/⌘キー) + Cのキーの組み合わせでcodeが起動する際、codeに続くフラグがオプションとして起動します。

上記のような方法があります。優先順位としては、KDEユーザーであれば何もしなくても大抵は大丈夫で、Hyprlandなどではキーバインドや~/.config/以下に設定ファイルを書いたりして、それらでどうしようもない場合は、.desktopファイルのExec行を書き換える。というような優先順序だろうと思います。

まとめ

ほとんどのLinuxディストリビューションは、英語が主言語として配布されているため、非ラテン言語系の地域の人は大抵それぞれの母国語が入力できる環境が必要になります。

特に日本人は英語で書かれている簡単な単語は読めるものの、本意が掴めない場合が多いので違った解釈をしてしまい、結果、正しく修正できなかったり自分の環境には合わない内容を適用してしまったりがあります。近頃のディストリビューションは、ローカライズしてあることが多く日本語は読めるので一応使えるけれども、ほとんどのアプリで入力することが多いので日本語が打てないことだけが不便なわけです。しかし英語圏の人々からしたらすでに英語での入力はできるので、その他の言語でどうかというのは報告がない限り気にもしないところだろうと思います。

IBusが強力に統合されているディストリビューション（特にGNOMEを採用しているUbuntu、Fedora、RHEL系）では、fcitx5を導入するかどうかはとても悩ましい問題です。今回はfcitx5での説明を書きましたが、「IBusが簡単に使えるのであれば」、「それで問題がないのであれば」fcitx5を使用しなくてもいいんじゃないかとも思います。

ただし、それら(Gnome)以外の環境ではIBusの方が設定が煩雑になることもあり、fcitx5を勧めているのは「どのディストリビューションでも」、「操作も」、「アプリ設定も」、同じとも言えるので一貫した方法で様々な環境に対応できると考えるとメリットはあると思います。

今はまだX11もWaylandも混在しているような環境でもある上に、色んなデスクトップ環境がありすぎてどれが正解かを模索している状況でもあると感じています。

つい最近ですが、

• Linuxゲーム開発者が協力してゲームエコシステム全体を改善する「Open Gaming Collective」を結成 - GIGAZINE
• OpenGamingCollective - Github

というニュースがありました。

これはゲームの話だろ？と思われるかも知れませんが、ゲームというのは動作して当然の商品です。キャラクターが動くだけではなく、ローカライズされた言語での表示、チャットがあるタイトルなら日本語が入力できなければなりません。

こういう事から、現在はバラバラで設定も多少難しくもあるLinux環境ですが、たとえゲームであれども軸ができるとそれに合わせて作ることができるようになるため、将来的にはIMEのアプリを入れるだけでバックグラウンドで設定は全てしてくれて、何も考えずに日本語入力ができる、あるいは変換精度や入力方法だけがより洗練されたものを選択できるような世界になるのではないかと予想されます。

特にゲームでは日本語入力がLinuxの弱点であるということが表面化します。それらがゲームから日本語の簡単設定・入力の方法が一般化しないといけません。Windowsで言えばDirectX(Direct Input、 XInput、 Text Services Frameworkなど)のようなものが必要になるということです。Google日本語入力、Microsoft IMEが入っていれば入力はできますよね。細かな設定は必要でしょうが、インストールするだけで入力できる。こういうことが必要になると思うのです。

Linuxに限らず、プレイステーションとセガサターンが出たことでスーファミが消えていったように、XBOXが出たと思ったらWiiだSwitchだと色んなものが台頭し消えていくのです。何が覇権をとるのか、三国志のように関係ない国が統一してしまうことだってありえます。Linuxの現在も似たようなものです。ただし、Windowsに一本化するというのはいけません。WindowsもMacもLinuxもあっても良いが、基本になる規格は統一すべきだという話です。あれがいい、これがいいと色々と素晴らしいアイデアや技術を出し合って形にし、基本はこうしようと「規格を統一する」これが大事です。それらをそれぞれが使用できるようにする。できた商品で儲ければいいじゃないと。規格を乱立させるのはいかんよと。USBだライトニングだとそれぞれが主張するのは全然ダメと言うことです。

作った人が「自分ところのが勝っている」と言いたいのはわからなくもないですけども。

これまでのLinuxでは、Gtk、Qt、Electron、X11がといろんな環境が受け口になっていました。今、LinuxはWaylandに移行する過渡期です。これがWaylandに集約していき、それらをうまく使う仕組みの制定がなされれば、それを基準にアプリが作られたりアップデートされて今以上に便利になるはずです。

それまでは今しばらく耐えて下さい。ずっと耐え続けないといけないかも知れません。きっと良い方向に向かう未来があると希望して。

Raindrop.ioへはこちらから