OpenStreetMapを編集する

OpenStreetMapを編集する

あと1週間ほどで、 Backseat co-Driver アプリを Google Play で正式リリースできる見込みです。このアプリはドライビングアシストを主な目的としており、走行速度や進行方向を読み上げるほか、 OpenStreetMap に登録されている制限速度、道路標識、信号機のない横断歩道などの情報も音声でドライバーに知らせます。 OpenStreetMap を採用した大きな理由は、オープンデータとして利用できることです。ただし、日本では道路そのものの情報はかなり充実している一方、地域によっては制限速度、横断歩道、道路標識などの細かな情報が十分に登録されていません。こうした情報が少ない道路では、 Backseat co-Driver も十分なドライビングアシストを行うことができません。

OpenStreetMap は、利用者自身が情報を追加・修正することで、地図をより充実させることができます。まずは自分が普段走っている道路や、自宅、職場の周辺など、実際の状況をよく知っている場所から情報を登録してみるのがおすすめです。逆に、一度も通ったことのない道路や、現地の状況を確認できない場所を無理に編集する必要はありません。また、 Google Maps や Google Street View など、利用規約上 OpenStreetMap への転記が認められていない資料を見て、その内容を登録してはいけません。自分で現地確認した情報や、 OpenStreetMap への利用が認められている資料を使うのが基本です。普段よく使う道路であれば、見落とされがちな標識や制限速度、幅員や高さ制限など、自分が知っている有用な情報を追加できます。

この記事では OpenStreetMap の編集方法を簡単に紹介します。私自身の備忘録も兼ねています。 OpenStreetMap を編集する方法はいくつかありますが、今回はブラウザだけで利用でき、基本的な編集をわかりやすく行えるオンラインエディタの iD を使用します。

OpenStreetMapを編集する 1
https://www.openstreetmap.org/ をブラウザで開きます。右上の「ログイン」をクリックします。アカウントを持っていない場合は「利用者登録」を行います。

OpenStreetMapを編集する 2
すでにOpenStreetMapのアカウントを持っている場合は、アカウント情報を入力してログインします。新しくアカウントを作成する場合は、地球の絵の左にある「利用者登録」タブをクリックします。今回は利用者登録の手順については割愛します。

OpenStreetMapを編集する 3
左上付近にある「編集」をクリックします。編集方法の候補が表示された場合は「iD(ブラウザー内エディタ)で編集」を選択します。

OpenStreetMapを編集する 4
編集画面が開くと、背景に航空写真が表示されます。編集したい地域まで地図を移動し、十分に拡大します。建物や道路などのデータが多い地域を広範囲に表示すると、ブラウザの動作が重くなることがあります。そのため、まず編集したい場所まで移動してから、必要な範囲だけを拡大表示するようにすると操作しやすくなります。

OpenStreetMapを編集する 5
横断歩道の例です。道路上の横断歩道を示す基本的なタグは highway=crossing です。必要に応じて横断歩道の種類や路面標示なども設定します。日本で一般的な縞模様の横断歩道であれば「ゼブラ」を選択します。この画像は信号機のある交差点の横断歩道なので、信号で制御されていることを示す crossing=traffic_signals を設定します。ナビゲーションやドライビングアシストでは、横断歩道が信号機で制御されているかどうかが重要な情報になります。 Backseat co-Driver で特に注意を促したいのは、信号機のない横断歩道です。日本では信号機のない横断歩道の手前には、原則として横断歩道があることを知らせるひし形の道路標示が設けられています。ただし、道路状況によっては信号機のある場所にも設置されることがあるため、ひし形だけで判断するのではなく、実際の状況を確認して登録します。

OpenStreetMapを編集する 6
信号機の例です。信号機の基本的なタグは highway=traffic_signals です。交差点全体を1つの信号機ノードとして登録する方法もありますが、大きな交差点などでは、進行方向ごとに信号機を個別に登録することもできます。この画像では個別に信号機を登録しています。西から東へ進む車両に対して有効な信号なので、その信号が適用される方向を設定します。この道路では OpenStreetMap 上の道路の向きと対象車両の進行方向が同じなので「順方向」を選択します。これは traffic_signals:direction=forward に相当します。
ここで注意したいのは、編集画面に表示される道路の矢印が、一方通行や車の進行方向を意味するものではないことです。OpenStreetMap では、道路を表す線(way)には必ず始点から終点へ向かう方向があります。双方向に通行できる道路であっても、データ上はどちらか一方の向きに線が描かれています。「順方向」や「逆方向」は、このwayの向きを基準に指定します。方向指定を削除したい場合はゴミ箱のアイコンをクリックするか、全てのタグから traffic_signals:direction=forward 、 traffic_signals:direction=backward 、 traffic_signals:direction=both などの該当するタグを削除します。

OpenStreetMapを編集する 7
道路を選択した状態です。道路には国道や都道府県道、一般道、自動車専用道路、住宅地の道路、農道、林道、歩道など、さまざまな種類があります。主要な道路については道路そのものや名称がすでに登録されていることが多い一方、制限速度などの細かな情報が登録されていない区間もあります。制限速度は maxspeed タグで登録します。 OpenStreetMap では、見た目には1本の道路でも、データ上はいくつもの区間に分割されていることがあります。制限速度などの情報は、それぞれの区間ごとに設定されるため注意が必要です。橋、交差点、道路属性の変化する場所などでwayが分割されていることもあるので、途中の区間だけ情報が抜けないよう、同じ道路をたどりながら確認していきます。

OpenStreetMapを編集する 8
一時停止の例です。一時停止を示す基本的なタグは highway=stop です。一時停止は、どちらの方向から走ってくる車両に適用されるのかを指定する必要がある場合が殆どです。この画像では道路は片側1車線の双方向ですが、OpenStreetMap 上では1本のwayとして登録されています。wayには便宜上の向きがあるため、その向きを基準に一時停止が適用される方向を設定します。この画像では「順方向」 direction=forward ですが、道路の描かれ方によっては「逆方向」になる場合もあります。編集画面に表示される扇形の方向ガイドを確認し、実際に一時停止しなければならない車両の進行方向と一致するように設定します。この例では、左(西)から右(東)へ走行する車両に対して一時停止が適用されます。

OpenStreetMapを編集する 9
信号機のない横断歩道の例です。前述した信号機付きの横断歩道と同じく highway=crossing を設定し、信号機で制御されていない横断歩道であることを示す crossing=uncontrolled を設定します。画像を見ると、横断歩道の手前にひし形の道路標示も確認できます。信号機のない横断歩道では、横断しようとする歩行者がいる場合、車両には横断歩道の手前で一時停止する義務があります。そのため、Backseat co-Driver のようなドライビングアシストアプリにとって、信号機のない横断歩道の位置は特に重要な情報です。こうした横断歩道を OpenStreetMap に正しく登録しておけば、アプリからドライバーへ事前に注意を促せるようになります。

OpenStreetMapを編集する 10
変更内容はまとめてアップロードできますが、私の環境では数百件ほどの変更をためた状態になるとブラウザの動作が重くなり、安定性も下がることがありました。そのため、ある程度編集したところで画面右上の「保存(アップロード)」ボタンをクリックして保存するようにしています。左上のコメント欄には、どのような変更を行ったのかを簡潔に記入します。その後「アップロード」ボタンをクリックすれば、変更内容が OpenStreetMap に登録されます。

編集画面ではデフォルトで航空写真が表示されますが、航空写真上の道路と OpenStreetMap の道路の線がずれて見えることがあります。この場合、安易に航空写真へ合わせて道路の位置を変更しないようにしてください。航空写真そのものに位置のずれが含まれていることがあり、 OpenStreetMap の道路データのほうが正しい場合もあります。位置を修正するときは、利用可能な複数の情報を確認して慎重に判断する必要があります。一方で、道路名、交差点名、制限速度、道路標識などの情報が未登録だったり、実際の状況と異なっていたりすることもあります。自分で現地の状況を確認できる場所であれば、ぜひ積極的に追加・修正してみてください。
地図の情報が充実すれば、それを利用するサービスも便利になり、利用者が増えることでさらに地図が充実していく好循環も期待できます。 Backseat co-Driver の利用者が OpenStreetMap の情報を少しずつ充実させてくれることを願っています。

関連記事:

WaylandとFcitx5環境で日本語入力できない/Shift,Ctrlキーが効かない不便な症状の対処方法

WaylandとFcitx5環境で日本語入力できない/Shift,Ctrlキーが効かない不便な症状の対処方法
キーボードが正常に使えないツラさを体で表現しています

「がとらぼ」の中の人が常用しているPCのOSはLinuxで、 KDE neon というディストリビューションです。 KDE neon は Ubuntu LTS をベースに、最新世代の KDE Plasma や KDE アプリケーションを利用できるようにした環境です。 KDE Plasma では X11 から Wayland への移行が進んでおり、2026年10月にリリース予定の KDE Plasma 6.8 では Plasma の X11 セッションが廃止され、ログイン時に選択できる Plasma セッションは Wayland のみになります。ただし、 X11 アプリケーションそのものが動作しなくなるわけではなく、多くの X11 アプリケーションは XWayland という互換レイヤーを介して引き続き利用できます。

基本的には X11 から Wayland への移行は順調で、一般的なユーザー、特に日本語入力のようなインプットメソッド(IM)を必要としないユーザーにとっては、気付かないうちに Wayland へ置き換わっていた、という程度の変化で済むことも多いでしょう。しかし、日本語、中国語、韓国語などの入力にインプットメソッドを使用する環境では事情が異なります。 Wayland では X11 とは入力処理の仕組みが異なり、アプリケーション、 GUI ツールキット、 Wayland コンポジター、インプットメソッドの間で使用するプロトコルも関係するため、英数字だけを入力する環境では表面化しない問題が発生することがあります。

今回は、Linuxで日本語入力を行う人にとって比較的メジャーなインプットメソッドフレームワークであるFcitx 5をWaylandで使用する場合の備忘録です。

基本設定

Fcitx 5 を使用可能にするには、 Fcitx 5 本体や Mozc など必要なパッケージをインストールしたうえで、 KDE システム設定から「キーボード」「仮想キーボード」を開き、通常は「 Fcitx 5 」を選択します。「 Fcitx 5 Wayland Launcher (Experimental) 」が表示される環境もありますが、現在の Fcitx 公式ドキュメントで推奨されているのは「 Fcitx 5 」です。 KDE neon の更新に伴う不具合の回避策として「 Plasma Keyboard 」や「 Fcitx 5 Wayland Launcher (Experimental) 」を試した時期もありましたが、正しく動作しない部分があったため、通常は「 Fcitx 5 」を使用するのが適切です。 KDE Plasma の Wayland 環境では、この方法で KWin から Fcitx 5 を起動することが重要です。従来の X11 環境とは起動方法が異なるため、古いドキュメントなどに従って Fcitx 5 を別途自動起動する設定を追加することは避けます。また、この方法で起動した Fcitx 5 は KWin から Wayland 入力メソッド用の接続情報を受け取っているため、システムトレイのメニューから Fcitx 5 だけを再起動する操作も避けた方が安全です。なお、原因調査のためにターミナルから一時的に起動して動作を確認すること自体は問題ありません。

Waylandへの移行以前はアプリケーション側から Fcitx 5 を利用できるようにするため、 ~/.bashrc などへ以下の3行を記述する方法がよく使われていました。

export XMODIFIERS='@im=fcitx5'
export GTK_IM_MODULE="fcitx5"
export QT_IM_MODULE="fcitx5"

Fcitx の Wiki のドキュメント Using Fcitx 5 on Wayland によると、現在の KDE Plasma Wayland 環境では考え方が変わっています。基本構成では XWayland 上で動作するアプリケーションのために XMODIFIERS を設定しますが、 GTK_IM_MODULE と QT_IM_MODULE はシステム全体には設定せず、 GTK や Qt の Wayland ネイティブな入力経路を使用することが推奨されています。なお、 Qt 6.7 では複数の入力メソッドを優先順位付きで指定できる QT_IM_MODULES という環境変数が追加されました。これは KDE Plasma 6.7 の機能ではなく Qt 6.7 以降の機能で、互換性に問題のある Qt アプリケーションなどでフォールバックを用意する場合に利用できます。 GUI から起動するアプリケーションにも確実に環境変数を渡したい場合は、 ~/.bashrc ではなく /etc/environment など、ログインセッション全体へ適用される設定を使用します。

XMODIFIERS=@im=fcitx
QT_IM_MODULES=wayland;fcitx

従来の QT_IM_MODULE ではなく、末尾に"S"が付いた QT_IM_MODULES であることに注意が必要です。 QT_IM_MODULES は複数の入力メソッドをセミコロンで並べ、利用可能なものを順番に試すための変数です。なお、この QT_IM_MODULES はKDE PlasmaでFcitx 5を使うために必須というわけではなく、Qtアプリケーションの互換性を補うための設定として考えた方がよいでしょう。

ただし、 Ubuntu 24.04 LTS をベースとする KDE neonでPlasma 6.7 を使用する環境では、Fcitx公式ドキュメントどおりに GTK_IM_MODULE と QT_IM_MODULE を設定しない構成にすると、Ubuntu側で提供されているFcitx 5のバージョンやWaylandとの組み合わせによって、 Shift や Caps Lock などの修飾キーが正常に処理されない問題が発生する場合があります。これは KDE Bug 520566 でも報告されている問題で、環境変数を設定したことによって発生する問題ではなく、逆に Ubuntu/KDE neon 側の Fcitx 5 と Wayland 入力メソッドとの組み合わせで発生する互換性問題です。この環境ではCtrlキーについても正常に扱われない症状が確認できました。

解決方法は KDE Bug 520566 を参照します。(以下)
Bug 520566 ではG TK_IM_MODULE、QT_IM_MODULE、XMODIFIERS を明示的に設定することで修飾キーの問題を回避できたと報告されています。しかし、「がとらぼ」の人の環境ではそれだけでは完全には解決せず、後述する Fcitx 5 本体の更新も必要でした。(全員に必ず必要ということではない可能性があります)

そこで、 Ubuntu/KDE neon 固有の問題を回避するため、 Plasma Wayland セッションの開始時から Fcitx 5 の入力メソッドモジュールを明示的に使用するよう、システム全体の環境変数を /etc/environment に設定します。これはFcitx公式が KDE Plasma 向けに示している標準構成とは異なり、 Ubuntu/KDE neon 環境で発生する互換性問題に対する回避策であることに注意してください。

/etc/environment (ファイルが存在しない場合は新規作成)
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx

/etc/environment ではシェルスクリプトのように export を付けるのではなく、「変数名=値」の形式で記述します。上記の値には空白が含まれていないため、二重引用符で囲む必要もありません。設定を変更した後は、すでに起動しているアプリケーションだけを再起動するのではなく、いったんログアウトして Wayland セッションへログインし直すか、OSを再起動して環境変数を反映させます。

なお、実際には上記の3行を /etc/environment へ記述していなくても、 printenv などで確認すると、設定した覚えのない GTK_IM_MODULE や QT_IM_MODULE が設定されている場合があります。 Ubuntu 系のディストリビューションでは Fcitx 5 関連パッケージのインストールに伴って im-config が導入されることがあり、この im-config が入力メソッド用の環境変数を設定するためです。 im-config には X11 セッション用の /etc/X11/Xsession.d/70im-config_launch が含まれていますが、 Wayland セッションでは主に /etc/profile.d/im-config_wayland.sh などの仕組みが使用され、 ~/.xinputrc またはシステム側の設定を読み込みます。そのため、Wayland環境で環境変数が設定されている原因を調べる場合は、 /etc/X11/Xsession.d/70im-config_launch だけを見るのではなく、 im-config -m の結果や ~/.xinputrc の内容も確認する必要があります。 KDE Plasma 側に Fcitx 5 の起動を任せ、 im-config から入力メソッドを有効化したくない場合は、 im-config -n none によって「 im-config では入力メソッドを有効化せず、デスクトップ環境の設定を使用する」状態にできます。

/etc/X11/Xsession.d/70im-config_launch後半
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# If already tweaked, keep hands off :-)
# If im-config is removed but not purged, keep hands off :-)
if [ -z "$XMODIFIERS" ] && \
   [ -z "$GTK_IM_MODULE" ] && \
   [ -z "$QT_IM_MODULE" ] && \
   [ -z "$CLUTTER_IM_MODULE" ] && \
   [ -z "$SDL_IM_MODULE" ] && \
   [ -r /usr/share/im-config/xinputrc.common ]; then
    IM_CONFIG_PHASE=1
    export IM_CONFIG_PHASE
    # initialize all im-config common functions and parameters
    . /usr/share/im-config/xinputrc.common
    unset TEXTDOMAIN
    unset TEXTDOMAINDIR
    # source the first found configuration file
    if [ -r "$IM_CONFIG_XINPUTRC_USR" ]; then
        . $IM_CONFIG_XINPUTRC_USR
    elif [ -r "$IM_CONFIG_XINPUTRC_SYS" ]; then
        . $IM_CONFIG_XINPUTRC_SYS
    fi
    # always export variables even for manual configuration.
    export XMODIFIERS
    export GTK_IM_MODULE
    export QT_IM_MODULE
    export CLUTTER_IM_MODULE
    export SDL_IM_MODULE
fi

前述のとおり、 /etc/X11/Xsession.d/70im-config_launch は X11 の Xsession で im-config を利用するためのスクリプトで、 Wayland セッションでは /etc/profile.d/im-config_wayland.sh など別の仕組みも使用されます。そのため、 70im-config_launch そのものを削除する必要はありません。ここでは KDE Plasma 側に Fcitx 5 の起動を任せるため、 im-config による入力メソッドの設定を無効化し、必要な環境変数は前述の /etc/environment から明示的に設定する構成にします。 im-config パッケージそのものは他のパッケージとの依存関係もあるため削除せず、次のコマンドでユーザー単位の設定を「none」に変更します。

$ im-config -n none

コマンドを実行すると ~/.xinputrc に run_im none が書き込まれます。この設定はファイルに保存されるため、一度設定すれば再起動後も有効です。これにより im-config は Fcitx 5 などの入力メソッドを自動的に選択・起動しなくなりますが、 /etc/X11/Xsession.d/70im-config_launch など im-config がインストールしたファイル自体を削除する必要はありません。

システムを再起動して問題が解決したのであれば、この時点で作業を終えても構いません。しかし、私の環境ではここまでの設定だけでは Shift キーや Ctrl キーの問題はまったく改善しませんでした。そこで、 Ubuntu 24.04 の標準リポジトリに含まれている Fcitx 5 が比較的古いことに着目し、 Fcitx 5 本体を更新することにしました。

Fcitxを5.1.14-1に更新

初稿では5.1.12-2でしたが、このバージョンは完全に修正されたものではありませんでした。5.1.13で追加された Wayland input-method v1 の modifier 転送に関する修正こそが核心であり、この修正後のソースパッケージで近いバージョンは5.1.14-1になります。そこで改めて5.1.14-1に更新しました。ただし、Chrome/Chromiumブラウザを使用していない方にとっては5.1.13以降のバージョンへの更新は必須ではないかもしれません。

Ubuntu 24.04 LTS(Noble) の標準リポジトリで提供されている Fcitx 5 は 5.1.7 ですが、追加のリポジトリを利用すれば、それより新しい 5.1.11 をパッケージとして導入することもできます。しかし、今回問題になっている Wayland の zwp_input_method_v2 使用時の修飾キーの状態 (modifier key state) やキーを離したイベント (key release event) が正しく送られない問題に関係する修正が明記されているのは Fcitx 5.1.12 です。 Fcitx 5.1.12 では、 zwp_input_method_v2 使用時の仮想キーボードの処理が改良されており、今回の Shift キーや Ctrl キーの異常と関係する可能性が高い変更が含まれています。
ただし、Chrome/Chromium ブラウザで使用されるのは Wayland input_method v1 のようであり、5.1.12 では Chrome ブラウザの使用で問題が残ります。そして、Wayland input-method v1 の modifier 転送に関する修正が加えられたのが 5.1.13 です。したがって 5.1.13 以降のバージョンに更新する必要があります。

Ubuntu 用には Fcitx 5.1.14 パッケージ自体は存在し、 Ubuntu 25.04(Plucky) 向けには 5.1.14-1 が提供されていました。しかし、 Ubuntu 25.04 向けにビルドされたバイナリパッケージを Ubuntu 24.04 へそのままインストールするのは避けるべきです。パッケージは各 Ubuntu リリースのライブラリ構成を前提としてビルドされており、実際に Fcitx 5.1.14-1 も libstdc++6 など Ubuntu 25.04 側のバージョンを前提とした依存関係を持っています。無理に導入すると多数のシステムライブラリの更新を要求されたり、依存関係を壊したりする可能性があります。
そこで今回は少しだけ手間がかかりますが、 Ubuntu 24.04 の環境上で Fcitx 5.1.14 のソースパッケージをビルドし、その環境に適合した Debian パッケージを作成してインストールすることにしました。 Fcitx 5.1.14 のソースコードと Debian 用のパッケージングデータはすでに用意されているため、自分でソースコードへ修正パッチを作成する必要はありません。手順はいくつかありますが、プログラムそのものを一からビルドするほど大変な作業ではありませんでした。(以下)

$ sudo apt install build-essential devscripts dpkg-dev  #ビルド用パッケージのインストール
$ sudo apt build-dep fcitx5   #Fcitx 5用のビルド依存関係パッケージのインストール

Debian/Ubuntu 用に Fcitx 5.1.14 のソースパッケージが用意されているので3つのファイルをダウンロードします。

  • fcitx5_5.1.14-1.dsc 4.1 KiB c9b065a618baea6bee13b2a68c8c0b583844d205cf7f6eb41a24a1dacc639042
  • fcitx5_5.1.14.orig.tar.xz 7.3 MiB 601ed5c17a477a6cd46be5b8382685b5d2e1e1c092a8e4455d03dea760908fad
  • fcitx5_5.1.14-1.debian.tar.xz 12.1 KiB ed98548dbe4c1c0975edb2b36c7730da312eeef6d863714c2030d3c2daa1457c
上記は2026年9月下旬時点のものです。(初稿は8月中旬の5.1.12-2用でした)

Ubuntu 24.04(Noble) のソースパッケージ情報を有効にします。
/etc/apt/sources.list.d/ubuntu.sourcesファイルの Type: deb を Type: deb-src に書き換えます。

$ sudo sed -i 's/^Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/ubuntu.sources

以下のようになります。

/etc/apt/sources.list.d/ubuntu.sources (修正後)
Types: deb deb-src
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb deb-src
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

以下を実行します。

$ sudo apt update
$ sudo apt build-dep fcitx5

$ mkdir -p ~/fcitx5-build
$ cd ~/fcitx5-build

先に取得した3つのソースパッケージファイル( fcitx5_5.1.14-1.dsc, fcitx5_5.1.14.orig.tar.xz, fcitx5_5.1.14-1.debian.tar.xz )を ~/fcitx5-build にコピー/移動させます。

$ dpkg-source -x fcitx5_5.1.14-1.dsc
$ cd ~/fcitx5-build/fcitx5-5.1.14
$ dpkg-checkbuilddeps     #依存するパッケージを調査
ここで不足するパッケージがあると
dpkg-checkbuilddeps: error: Unmet build dependencies: dh-exec
のように表示されます。この例では dh-exec が不足していると指摘されています。

$ sudo apt install dh-exec  #dh-execパッケージをインストール
$ dpkg-checkbuilddeps     #依存するパッケージを再調査

他に不足するパッケージが指摘されたら同様にインストールし、何も指摘されなければパッケージの依存関係は満たされています。

ビルドの実行
$ dpkg-buildpackage -b -uc -us

ビルドが始まり画面にはズラズラと表示されます。しばらく待ってエラーで停止しなければ完了です。
最後が以下のように表示されていればビルドは成功です。

**dpkg-deb:** building package 'fcitx5-frontend-all' in '../fcitx5-frontend-all\_5.1.14-1\_all.deb'. 
        Renaming fcitx5-modules-dbgsym\_5.1.14-1\_amd64.deb to fcitx5-modules-dbgsym\_5.1.14-1\_amd
64.ddeb 
 **dpkg-genbuildinfo --build=binary -O../fcitx5\_5.1.14-1\_amd64.buildinfo** 
 **dpkg-genchanges --build=binary -O../fcitx5\_5.1.14-1\_amd64.changes** 
**dpkg-genchanges:** info: binary-only upload (no source code included) 
 **dpkg-source --after-build .** 
**dpkg-buildpackage:** info: binary-only upload (no source included)

生成されたパッケージを確認します。

$ cd ~/fcitx5-build
$ ls -1 *.deb
パッケージインストールのシミュレーションを行います。(実際にはインストールされません)
$ sudo apt -s install \
  ./fcitx5_5.1.14-1_amd64.deb \
  ./fcitx5-data_5.1.14-1_all.deb \
  ./fcitx5-modules_5.1.14-1_amd64.deb \
  ./fcitx5-frontend-all_5.1.14-1_all.deb \
  ./libfcitx5core7_5.1.14-1_amd64.deb \
  ./libfcitx5config6_5.1.14-1_amd64.deb \
  ./libfcitx5utils2_5.1.14-1_amd64.deb

実行結果で削除件数が0であれば問題ないでしょう。

今度はパッケージインストール本番です。(オプションの -s を外して実行します)

$ sudo apt install \
  ./fcitx5_5.1.14-1_amd64.deb \
  ./fcitx5-data_5.1.14-1_all.deb \
  ./fcitx5-modules_5.1.14-1_amd64.deb \
  ./fcitx5-frontend-all_5.1.14-1_all.deb \
  ./libfcitx5core7_5.1.14-1_amd64.deb \
  ./libfcitx5config6_5.1.14-1_amd64.deb \
  ./libfcitx5utils2_5.1.14-1_amd64.deb

今回インストールしたパッケージが今後の ubuntu のパッケージ更新によって上書きされないようピンを追加します。 sudo から EOF まで一気にコピペして実行します。

$ sudo tee /etc/apt/preferences.d/fcitx5-local-51141.pref >/dev/null <<'EOF'
Package: fcitx5 fcitx5-data fcitx5-modules fcitx5-frontend-all libfcitx5core7 libfcitx5config6 libfcitx5utils2
Pin: version 5.1.14-1
Pin-Priority: 1300
EOF
インストールされているバージョンと候補のバージョンとプライオリティを確認します。
$ apt policy fcitx5 fcitx5-data fcitx5-modules libfcitx5core7
fcitx5:
  インストールされているバージョン: 5.1.14-1
  候補:               5.1.14-1
  バージョンテーブル:
 *** 5.1.14-1 1300
        100 /var/lib/dpkg/status
     5.1.11-2ubuntu1~noble1 500
        500 https://ppa.launchpadcontent.net/ikuya-fruitsbasket/fcitx5/ubuntu noble/main amd64 Packages
     5.1.7-1build3 1100
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages
fcitx5-data:
  インストールされているバージョン: 5.1.14-1
  候補:               5.1.14-1
  バージョンテーブル:
 *** 5.1.14-1 1300
        100 /var/lib/dpkg/status
     5.1.11-2ubuntu1~noble1 500
        500 https://ppa.launchpadcontent.net/ikuya-fruitsbasket/fcitx5/ubuntu noble/main amd64 Packages
        500 https://ppa.launchpadcontent.net/ikuya-fruitsbasket/fcitx5/ubuntu noble/main i386 Packages
     5.1.7-1build3 1100
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages
        500 http://archive.ubuntu.com/ubuntu noble/universe i386 Packages
fcitx5-modules:
  インストールされているバージョン: 5.1.14-1
  候補:               5.1.14-1
  バージョンテーブル:
 *** 5.1.14-1 1300
        100 /var/lib/dpkg/status
     5.1.11-2ubuntu1~noble1 500
        500 https://ppa.launchpadcontent.net/ikuya-fruitsbasket/fcitx5/ubuntu noble/main amd64 Packages
     5.1.7-1build3 1100
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages
libfcitx5core7:
  インストールされているバージョン: 5.1.14-1
  候補:               5.1.14-1
  バージョンテーブル:
 *** 5.1.14-1 1300
        100 /var/lib/dpkg/status
     5.1.11-2ubuntu1~noble1 500
        500 https://ppa.launchpadcontent.net/ikuya-fruitsbasket/fcitx5/ubuntu noble/main amd64 Packages
     5.1.7-1build3 1100
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages

これで Fcitx 5.1.14 のビルド、インストール、インストール結果の確認まで完了しました。
KDE Plasma の Wayland 環境では、 Fcitx 5 を通常のアプリケーションのように手動で自動起動するのではなく、 KDE システム設定の「仮想キーボード」で Fcitx 5 を選択し、 KWin から起動させるのが基本です。そのため、いったんログアウトして Wayland セッションへログインし直すか、システムを再起動してから動作確認を行います。
念のため、再起動後に実際に使用されている Fcitx 5 のバージョンも確認しておきます。

$ fcitx5 --version

5.1.14 になっていれば、今回ビルドしてインストールした Fcitx 5 へ正常に更新されています。

続いて、 Kate (KDE のテキストエディタ)や Konsole (KDE のターミナル) で日本語を入力できることと、 [Shift] キーを押しながら英数字キーを押したときに大文字や記号を正しく入力できることを確認します。また、修飾キーが正常に動作していることも確認します。 Kate では [Ctrl]+[A] (全選択) 、 [Ctrl]+[C] (コピー)、 [Ctrl]+[V] (ペースト) などを試します。 Konsole では [Ctrl]+[C] は実行中の処理を中断するためのキーとして使われ、 [Ctrl]+[A] にもシェル側の機能が割り当てられているため、コピーとペーストの確認には [Ctrl]+[Shift]+[C] と [Ctrl]+[Shift]+[V] を使用します。また、多くのLinuxアプリケーションでは [Ctrl]+[Insert] がコピー、 [Shift]+[Insert] がペーストとして機能するため、これらについても確認できます。

多くのアプリケーションでは以上の設定で問題なく利用できるはずですが、一部のアプリケーションでは、それでも日本語を入力できなかったり、 Shift キーや Ctrl キーなどの修飾キーが正常に機能しなかったりすることがあります。これはアプリケーションごとに Wayland への対応方法や、 Fcitx 5 との間で使用する入力メソッドの経路が異なるためです。

Google Chromeブラウザ

この Chrome ブラウザの対応は Ubuntu 系の標準パッケージで導入した Fcitx 5.1.13 未満のバージョン(実際には 5.1.7 など)をそのまま使用する場合に必要な対応です。この記事の前述の Fcitx 5 を 5.1.13 以降のバージョンに更新した場合には全く行う必要はなく、むしろ、X11 互換の経路に変更することは、Chrome ブラウザの文字入力以外の動作を不安定にさせるため行うべきではありません。ポインタの表示位置、ブラウザのウィンドウサイズの変更やウィンドウの移動、ブラウザ内での動画の再生など様々な問題が発生します。
また、Fcitx 5 を更新しない場合に以下の対応を行うと文字の入力の殆どで問題がなくなりますが、Chromeブラウザの文字入力以外の動作を不安定にさせます。ポインタの位置、ブラウザのウィンドウサイズの変更やウィンドウの移動、ブラウザ内での動画の再生など様々な問題が発生することにご留意ください。Chromeブラウザで文字入力を殆ど正しく行えることを重視するか、ブラウザの安定動作を重視するかの問題となります。

Chrome/Chromium 系ブラウザを Wayland ネイティブの Ozone Wayland バックエンドで起動した場合、通常のキーボードイベントは KWin から Chrome へ渡され、日本語入力については Chrome と KWin の間で Wayland の text-input プロトコル、 KWin と Fcitx 5 の間で input-method プロトコルなどを使用して処理されます。今回の環境では、この Wayland ネイティブの入力経路を使用すると修飾キーの状態やキーを離したイベントの処理に問題が発生し、 Shift キーや Ctrl キーが正常に機能しないことがありました。そこで Chrome を --ozone-platform=x11 で起動し、 KWin → XWayland → Chrome(Ozone/X11)という X11 互換の経路へ変更します。これにより、問題が発生していた Wayland ネイティブの text-input/input-method 経路を回避できます。

WaylandとFcitx5環境で日本語入力できないアプリの対処方法 1
アプリケーションランチャーから Google Chrome ブラウザのアイコンを右クリックし、表示されたメニューから「アプリケーションを編集」を選択します。

WaylandとFcitx5環境で日本語入力できないアプリの対処方法 2
「全般」タブの「コマンドライン引数」の欄に、 "--ozone-platform=x11 " を追加します。元々存在していた "%u" の前に挿入します。右上の「保存」を押します。(2重引用符は入力しません)

Android Studio

以下の対応はFcitx 5.1.12以下のバージョンを使用している場合に必要です。Fcitx 5.1.13以降のバージョンに更新した場合は以下の対応は不要になります。

Android Studio についても、 Wayland ネイティブ動作時に同様の問題が発生する場合は、フォールバックとしてAndroid Studio を確実に X11/XWayland 経由で動作させることができます。 Android Studio 2026.1 系を含む最近の IntelliJ Platform ベースの IDE では LinuxのWayland バックエンドが利用されますが、 Android Studio そのものを実行している Java 仮想マシンのカスタム VM オプションを指定することで、 AWT を従来の X11 用 XToolkit へ切り替えられます。

AWTは Abstract Window Toolkit の略で、 Java で GUI アプリケーションを画面に表示し、 OS のウィンドウシステムやキーボード・マウス入力を扱うための基盤です。
Android Studio の画面そのものは Java 系の GUI 技術で作られており、その下の層で AWT が Linux のデスクトップ環境とやり取りします。大まかには、
Android Studio → Swing / IntelliJ UI → AWT → Linuxの画面システム (Wayland または X11)
という関係です。
ここで重要なのが、 AWT には Linux の画面システムへ接続するための実装が複数あることです。

  • WLToolkit:Wayland へ直接接続する新しい AWT バックエンド
  • XToolkit:従来の X11 へ接続する AWT バックエンド

XToolkit を指定することで、この AWT の表示・入力処理を Wayland ネイティブではなく X11/XWayland 経由へ切り替えることができます。

WaylandとFcitx5環境で日本語入力できないアプリの対処方法 3
Android Studio を起動し、上部のメニューバーから「ヘルプ」ドロップダウンから「カスタム VM オプションの編集」を選択します。

WaylandとFcitx5環境で日本語入力できないアプリの対処方法 4
「カスタム VM オプションの編集」の実体は studio64.vmoptions というファイルで、 Linux では ~/.config/Google/AndroidStudio2026.1.3/ などのAndroid Studioの設定ディレクトリにあります。正確なディレクトリ名は使用している Android Studio のバージョンや Stable/Beta/Canary などのリリース種別によって異なるため、「Help」 → 「Edit Custom VM Options...」から開くのが確実です。 Android Studio を新しい世代へ更新すると、対応する新しい設定ディレクトリが作成されることがあります。メモリ割り当てなどをすでにカスタマイズしている場合は、 -Xmx3072m のような VM オプションがこのファイルに記載されていることもあります。

-Dawt.toolkit.name=XToolkit

という1行を追加します。このオプションは、 Android Studio の Java GUI で使用するAWTツールキットを Wayland 用の WLToolkit ではなく、 X11 用の XToolkit へ切り替えるためのものです。 Wayland セッション上で XToolkit を使用した Android Studio は XWayland を介して表示されます。 Android Studio では編集した設定ファイルは通常自動的に保存されますが、この VM オプションが読み込まれるのは次回起動時なので、入力後はいったん Android Studio を完全に終了して再起動します。今回の環境では、これによって日本語入力が正常に行えるようになり、 Shift キーと Ctrl キーも正常に機能するようになりました。

2026年10月にリリース予定の Plasma 6.8 では Plasma の X11 ログインセッションが廃止され、 Wayland セッションのみになります。ただし、これは X11 アプリケーションを動作させるための XWayland まで廃止するという意味ではありません。 KDE は Plasma 6.8 以降も X11 アプリケーションの互換性を XWayland によって提供する方針を示しているため、 Chrome を Ozone/X11 で動かしたり、 Android Studio を XToolkit で動かしたりする今回の回避策は、 Plasma 6.8 以降も当面は利用できると考えられます。ただし、これらはあくまで Wayland ネイティブ動作で問題が発生するアプリケーション向けのフォールバックであり、将来的に KWin、Fcitx 5、Chromium、JetBrains Runtime 側の問題が解消された場合は、 Wayland ネイティブへ戻す方が望ましいでしょう。

Up