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

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

「がとらぼ」の中の人が常用しているPCのOSはLinuxでKDE neonというディストリビューションです。最新のKDE Plasmaデスクトップ環境が搭載されていること以外はほぼubuntuです。KDE PlasmaではX11からWaylandへの借り換えが進んでいて、まもなく2026年10月のKDE Plasma 6.8ではX11セッション廃止という話が現実となりそうです。

基本的にはX11からWaylandへの以降は順調で、一般的なユーザーにとって、特に英数字圏のユーザーには何が変わるということもなく気付いたら入れ替わっていたということになる筈ですが、日本語環境などインプッドメソッド(IM)が関わるととたんに英数字圏の人たちとは違った問題がでてきます。

今回はLinuxで日本語入力を行う人たちにとっては比較的メジャーなFcitx5をWalandで使う場合の備忘録です。

共通設定

Fcitxを使用使用可能にするにはFcitx関係のパッケージをインストールしてKDEシステム設定から「キーボード」「仮想キーボード」を開き、「Fcitx 5」または、「Fcitx 5 Wayland Launcher(Experimental)」を選択します。KDE neonの更新で異常があったときにはPlasma Keyboardを使用した時期もありましたが、正しく動作しない部分もあったため、「Fcitx 5」「Fcitx 5 Wayland Launcher(Experimental)」が良さそうです。UbuntuやKDE neonではFcitxを動かすための設定は基本的にはこれだけで終わりです。従来とはFcitxの起動方法が違うので、古いドキュメントなどに従って手動でまたは自動でFcitxを起動することは避けます。動作テストとしてFcitxを起動するのは自由です。

ただし、それだけでは使えないものもあるため、以前は./bashrcなどに以下の3行を書きました。

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

FcitxのWikiのドキュメントUsing Fcitx 5 on Waylandによると以下のようになっています。
GTK_IM_MODULEとQT_IM_MODULEの2行はKDE Plasma 6.7では推奨されなくなったので記載しません。
KDE Plasma 6.7では./bashrcではなく、/etc/environmentに以下の2行を書きます。

XMODIFIERS=@im=fcitx
QT_IM_MODULES=wayland;fcitx

従来のQT_IM_MODULEに"S"が付いたQT_IM_MODULESであることに注意が必要です。

ただし、UbuntuのKDE Plasmaデスクトップ環境のWaylandでは、ドキュメントどおりしても効果はなく、後述のfcitxの更新を行うと逆にShiftキーとCtrlキーが効かなくなる modifier/key-release 問題を発生させます。

解決方法は KDE Bug 520566 を参照します。(以下)
しかし、それだけではダメでfcitxの更新も必要でした。

Plasma Waylandセッション開始時から入力メソッド環境を設定するためにシステム全体設定として/etc/environmentに設定を作成します。

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

/etc/environmentでは、exportや二重引用符は使用しないということになっています。

なお、実際には上記の3行の環境変数を書かなくてもprintenvなどで確認すると設定していない筈のGTK_IM_MODULEやQT_IM_MODULEが設定されています。
どうやらUbuntu系のディストリビューションでFcitx関係のパッケージをインストールすると /etc/X11/Xsession.d/70im-config_launch というファイルが用意されるようです。この中で設定されます。

/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

この70im-config_launchはXsession経由でFcitxを使うことを前提としています。重複する設定にはなりますが、前述の/etc/environmentへの設定も行っておきます。/etc/X11/Xsession.d/70im-config_launch ファイルは残しておいて問題ないでしょう。
しかし、このファイルの元であるim-configは要りません。パッケージとして削除するのではなくim-configを無効化します。

$ im-config -n none
コマンドを実行すると ~/xinputrc に run_im none が書き込まれます。(無効化は設定ファイルで永続化されます)

システムを再起動して問題が解決したならこの時点で終わりでも構いませんが、私の環境ではこれだけでは全く効果がありませんでした。そこで、Fcitxを更新することにしました。

Fcitxを5.1.12に更新

Ubuntuでは標準でインストールされるFcitx 5.1.7より新しい5.1.11が用意されています。これはリポジトリを追加して簡単にインストール可能ですが、「zwp_input_method_v2 使用時に modifier key state と key release event が送られない」という問題に対応したとされているのは5.1.12です。それ以降のバージョンも存在します。
Ubuntu用にFcitx 5.1.12パッケージが存在するようですが、それはUbuntu 25.04用として作成されているため、Ubuntu 24.04で直接利用すると依存関係に大きな問題が起きる可能性があります。
そこで、今回は少しだけ面倒ですがビルドして5.1.12を導入することにしました。ソースパッケージは用意されているのでソースにパッチを当てる必要などはなく、大変というものではありませんでした。(以下)

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

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

  • fcitx5_5.1.12-2.dsc 3.8 KiB 0a249245ec6f6faa8b9d059ea54055a22f324e609bfe7ce138ae852c279fdb0f
  • fcitx5_5.1.12.orig.tar.xz 7.2 MiB 09d7e98a6498136839983caa4b8c1df752deb6933a984e6390557602cab357a0
  • fcitx5_5.1.12-2.debian.tar.xz 12.1 KiB d864eb6cd943aba7651303cf5ad3df9102303c70f0bea4070a45a26604df32c7
上記は2026年8月下旬時点のものです。

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.12-2.dsc, fcitx5_5.1.12.orig.tar.xz, fcitx5_5.1.12-2.debian.tar.xz)を ~/fcitx5-build にコピー/移動させます。

$ dpkg-source -x fcitx5_5.1.12-2.dsc
$ cd ~/fcitx5-build/fcitx5-5.1.12
$ 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.12-2\_all.deb'. 
        Renaming fcitx5-modules-dbgsym\_5.1.12-2\_amd64.deb to fcitx5-modules-dbgsym\_5.1.12-2\_amd
64.ddeb 
 **dpkg-genbuildinfo --build=binary -O../fcitx5\_5.1.12-2\_amd64.buildinfo** 
 **dpkg-genchanges --build=binary -O../fcitx5\_5.1.12-2\_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.12-2_amd64.deb \
  ./fcitx5-data_5.1.12-2_all.deb \
  ./fcitx5-modules_5.1.12-2_amd64.deb \
  ./fcitx5-frontend-all_5.1.12-2_all.deb \
  ./libfcitx5core7_5.1.12-2_amd64.deb \
  ./libfcitx5config6_5.1.12-2_amd64.deb \
  ./libfcitx5utils2_5.1.12-2_amd64.deb

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

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

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

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

$ sudo tee /etc/apt/preferences.d/fcitx5-local-5112.pref >/dev/null <<'EOF'
Package: fcitx5 fcitx5-data fcitx5-modules fcitx5-frontend-all libfcitx5core7 libfcitx5config6 libfcitx5utils2
Pin: version 5.1.12-2
Pin-Priority: 1300
EOF
インストールされているバージョンと候補のバージョンとプライオリティを確認します。
$ apt policy fcitx5 fcitx5-data fcitx5-modules libfcitx5core7
fcitx5:
  インストールされているバージョン: 5.1.12-2
  候補:               5.1.12-2
  バージョンテーブル:
 *** 5.1.12-2 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.12-2
  候補:               5.1.12-2
  バージョンテーブル:
 *** 5.1.12-2 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.12-2
  候補:               5.1.12-2
  バージョンテーブル:
 *** 5.1.12-2 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.12-2
  候補:               5.1.12-2
  バージョンテーブル:
 *** 5.1.12-2 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.12のビルドとインストールと確認が完了しました。
WaylandではFcitxを手動で起動させないことになっているのでシステムを再起動するなどしてから動作確認を行います。
一応、再起動後にFcitxのバージョンを確認しておきます。

$ fcitx5 --version

5.1.12になっている筈です。

Kate (KDEのエディタ)やKonsole(KDEのターミナル)アプリで日本語を入力したり[Shift]キーを押しながら英数字を入力して大文字や記号が表示されること、[Ctrl]+[A](全選択)、[Ctrl]+[C](コピー)、[Ctrl]+[V](ペースト)、[Ctrl]+[Insert](ペースト)が正しく機能することを確認します。

多くは以上で問題ない筈ですが一部アプリではこれだけでは日本語の入力が行えないことがあります。

Google Chromeブラウザ

Chrome系ブラウザをWaylandネイティブとして起動すると、キーボードからの入力が、KWin / Wayland → Chrome (Ozone Wayland) → Wayland text-input / input-method → Fcitx5に伝わりますが、Wayland + KWin + Fcitx間のmodifier処理の問題で異常動作になるようです。
この経路を KWin → XWayland → Chrome Ozone/X11、つまりX11/XWayland経由に変更することで対応します。

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

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

Android Studio

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

WaylandとFcitx5環境で日本語入力できないアプリの対処方法 4
今回は、「環境変数」に"GDK_BACKEND=x11"を入力します。右上の「保存」を押します。

X11ログインセッションが廃止されるPlasma 6.8 (今年10月予定?)以降もXwaylandサポートは残るということなので当分は問題ないでしょう。(たぶん)

令和に蘇る昭和のMacintosh II ケースのレトロブライト (前編)

令和に蘇る昭和のMacintosh II ケースのレトロブライト

「がとらぼ」の中の人はもともと、Apple製品にはほとんど興味がありませんでした。新製品が登場するたびに熱狂する熱心なユーザーたちを、少し離れたところから冷ややかに眺めていた側です。これまで自分で購入したApple製品も、ウェブサイトの表示互換性確認用のMacintosh Quadra 800の一台だけでした。

ところが、そのQuadra 800も私にとっては満足に使えるものではありませんでした。当時のMacintoshに搭載されていた「System 7」などの、いわゆるSystem xxと呼ばれるOSがどうしても好きになれず、最終的にはNetBSDをインストールして使用していました。そのため、Appleのコンピューターそのものに愛着を持つことはなく、Macintoshの文化や歴史にも積極的に関心を向けてきませんでした。

そんな私でも、Macintosh IIとMacintosh SEのデザインだけは別でした。Apple製品であるかどうかとは関係なく、純粋に工業製品として見たとき、その端正で無駄のない姿には強く感心していました。特にMacintosh IIの横置きケースと、Macintosh SEの一体型の造形には、ほかのコンピューターにはない完成度があります。使ってみたいというより、その姿を手元に置いて眺めていたいと思わせる魅力があり、興味のないApple製品の中で、この2機種だけは以前から密かな憧れの存在でした。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 0a
Macintosh II

今回入手したのは、1987年に登場したAppleのMacintosh II (実際には1988年発売のMacintosh IIx)です。発売からすでに40年近くが過ぎているため、現在では名前を聞いても、その姿を思い浮かべられない人のほうが多いかもしれません。しかしMacintosh IIは、性能面だけでなく、Appleの工業デザインを語るうえでも非常に重要な一台です。16MHzの68020プロセッサーと6基のNuBusスロットを備え、外付けディスプレイを使用する拡張型Macintoshとして登場しました。当時は一式揃えるのは車を買うのに匹敵するほど高価でした。

1980年代初頭のAppleは、製品ごとにばらばらだった外観を整理し、ひと目でApple製品だと分かる統一されたデザインを必要としていました。Steve Jobsは世界水準のデザイナーを求め、ドイツ出身の工業デザイナーHartmut Esslingerと、彼が率いるfrogdesignを採用します。そこで作られたのが、Apple IIcなどから展開された「Snow White」と呼ばれるデザイン言語です。細く均等に並ぶ水平スリット、控えめな角の丸み、明るいプラチナ色、機能部分を外観のリズムとして見せる処理によって、無機質になりがちなコンピューターに整然とした品格が与えられました。おもしろいことに、Snow Whiteデザインが全盛を迎えたのはSteve JobsがAppleを去った後のJohn Sculleyの時代です。

Macintosh IIのケースは、その考え方を横置きのデスクトップ型に落とし込んだ、完成度の高いデザインです。正面には必要な要素だけが静かに配置され、広い平面と水平線によって低く安定した姿に見えます。過度な曲線や装飾、時代性の強い色や素材に頼っていないため、現代の机に置いても古びた印象になりません。むしろ、現在販売されているシンプルなPCケースの中に混ざっていても、不思議ではないほどです

残念ながら「Show White」は1990年のMacintosh IIfxを最後に採用が終わり、以降の数年間はSnow Whiteの劣化版でただのベージュの箱のようなデザインが採用されました。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 0
ディスプレイ一体の箱型タイプの(デザインだけ)最高峰 Macintosh SEとMacintosh SE/30

MacintoshやMacには、その時代を象徴する個性的な製品が数多くあります。ただし、強い個性を前面に出したデザインは、最初の印象が鮮烈である一方、長く眺めているうちに飽きを感じることもあります。「Snow White」でデザインされたMacintosh IIやMacintosh SEはその反対です。目立つための形ではなく、機能を素直に整理した形なので、何年見ても落ち着きがあり、いつまでも手元に置いておきたくなります。約40年前の製品でありながら、現在でも十分に通用する、PCケースとして非常に秀逸なデザインです。

本来、基板や電源、ドライブまで揃った貴重なMacintosh IIであれば、内部を取り除いて現代のPCを組み込むのはためらわれます。しかし今回購入したものは、最初から中身のないケースだけです。歴史的な一台を壊してしまうわけではないため、修復方法や内部加工についても比較的気楽に考えられます。この美しい外観を生かし、最終的には現在のPCを収めるケースとして再利用する予定です。

もっとも、届いたケースは長い年月の影響で樹脂が大きく変色し、全体が非常に黄ばんでいました。表面の汚れも目立ち、このままでは本来の端正な姿を十分に楽しめません。そこで、まずはケースを分解して洗浄し、黄変した樹脂をできるだけ元の色調へ近づけるため、レトロブライトを行うことにしました。

今回は洗濯用の漂白剤ではなくクリームタイプの染毛剤で過酸化水素濃度が6%の製品を購入しました。クリーム状ということで乾きが遅いことを期待しましたが意外と乾くのが早かったので高頻度での重ね塗りを行うことになりました。臭いは予想よりキツくなくレトロブライトの作業用として良い品でした。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 1
今回は、ヤフオクでMacintosh IIのケースを入手しました。正確にはMacintosh IIxのケースです。樹脂はひどく黄変しており、汚れや傷も多く、正直なところ修復にはかなり手間がかかりそうです。しかし、内部の基板類がすでに取り除かれた状態なので、どのように活用しても罪悪感がありません。何より、落札価格が1,200円という安さだったのが最高です。なお、購入したのは5月です。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 2
実際に届いたMacintosh IIxです。本体のほかに、金属製のフレーム類がプチプチに包まれた状態で付属していました。今回はMacintosh IIxを本来の姿へ復元する予定ではないため、これらの部品は使用しません。鉄と思われる素材で作られているため、見た目以上に重量があります。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 3
本体正面です。フロッピーディスクドライブは、1台のみ使用できる構成のモデルだったようです。正面のAppleロゴには、虹を思わせる6色の横縞が使われています。これは、Appleがかつて公式に使用していた、初代ロゴです。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 4
本体側面です。上部には前面から背面へ向かって多数の水平スリットが並び、下部には縦方向のスリットが配置されています。向きの異なるスリットを組み合わせた、Macintosh IIらしい特徴的なデザインです。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 5
本体の上面です。側面と同じように、前面から背面へ向かう細いスリットが多数並んでいます。左半分の中央寄りには、内部の熱を逃がすための通気孔が設けられています。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 6
背面は、右側に拡張カード用スロットの蓋、左下にI/Oポート、左上に京町家の格子戸を思わせる通気孔が配置されています。基本的な構成は現在のデスクトップPCとほとんど変わりません。約40年前の製品であることを考えると、非常に先進的な設計だったことが分かります。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 7
上蓋を開けると、プチプチに包まれていた金属フレーム類とは別に、ベースプレート、フロッピーディスクドライブ、電源ユニットが本体内部に残されていました。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 8
当時のMacintoshには、SONY製の電源ユニットが採用されていました。この電源は経年劣化によって故障すると修理が難しいため、一般的なPC用電源を流用してMacintoshを再生する方法もよく用いられています。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 9
上蓋の内側です。右下に「13.8.89」と記されているため、1989年8月に製造された個体と思われます。Macintosh IIの外装は樹脂製ですが、内側にはほぼ全面にアルミ製のプレートが貼られており、電磁波対策が施されています。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 10
電源ユニットを取り外しました。電源ユニットに覆われていた部分だけは、アルミプレートが鏡面に近い状態を保っており、とてもきれいです。ただし、その周囲には大量の埃が詰まっていました。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 11
本体内部に残されていたフロッピーディスクドライブです。大量の埃に加え、金属板の錆もかなり進行しています。この状態からディスクドライブユニットを再生するのは、かなり難しそうに見えます。

Macintosh IIの外装は細い溝やスリットが多いため、刷毛と中性洗剤を使って徹底的に清掃します。洗剤をかけながら刷毛で溝の内部まで丁寧にこすり、長年蓄積した汚れや埃を取り除きます。

美容院などで使用される、過酸化水素を高濃度で配合したクリーム状の薬剤を刷毛で塗布します。ケース全面に日光がしっかり当たるよう、ときどき向きを変えます。時間が経つと表面の薬剤が乾いてくるため、乾燥する前に何度か刷毛で塗り重ねました。水分の蒸発を防ぐためにラップで包む方法もありますが、乾く前に再塗布を繰り返すほうが簡単だと思います。

以下はレトロブライトの施工前の写真が撮れていなかったため、漂白剤を塗り重ねてある程度白くなり始めた状態からの写真です。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 12
底面と正面です。「Macintosh IIx」と記されたモデル名の文字やAppleロゴは、漂白剤の影響を受ける可能性があります。本来の姿へ忠実に復元する場合は、ロゴの背面に穴を開けて押し出し、あらかじめ取り外しておく方法があります。また、印刷された文字が消えないよう、薬剤の濃度や処理時間にも注意が必要です。しかし、「がとらぼ」の中の人にとっては、モデル名もAppleロゴもそれほど重要ではないため、気にせず薬剤をたっぷり塗っていきます。今回はPC-9801FAのレトロブライトでの反省から高濃度過酸化水素の使用と短時間施工を行うため文字剥がれは発生しない可能性もあります。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 13
上蓋も同じ方法で処理します。全面に日光が均等に当たるよう、ときどき向きを変えながら、刷毛で薬剤を塗布します。表面が完全に乾く前に塗り重ねる作業を繰り返しました。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 14
本体側面は特に汚れがひどく、以前にテープのようなものが貼られていた跡も残っていました。薬剤を塗って処理したところ、表面に残っていた粘着剤もきれいに除去できました。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 15
レトロブライト1日目の処理を約3時間行った後の上蓋です。すでに中性洗剤と水で薬剤を徹底的に洗い流し、十分に乾燥させています。以前に処理したPC-9801FAと比べると、はるかに短い時間でかなり白くなりました。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 16
本体底面と背面です。上蓋と同様に、1日目のレトロブライトを約3時間行った後、中性洗剤と水で徹底的に洗浄し、乾燥させました。目立っていたひどい黄ばみは、ほとんど解消しています。ただし、まだわずかに黄変が残っています。

令和に蘇る昭和のMacintosh II ケースのレトロブライト 17
本体正面です。以前の所有者によって、表面に何らかの塗料が塗られていた形跡があります。刷毛で塗ったニスのようなものでしょうか。レトロブライトを行ったことで、表面に残っていた刷毛目がはっきりと浮かび上がりました。ほかの面と比べても、正面には黄変がやや強く残っています。

1回目のレトロブライトによって、正面以外の黄変は大部分が改善しました。しかし、正面だけはまだ黄ばみが強く残っています。印刷された文字が剥がれ落ちる覚悟があるなら、目の細かいサンドペーパーを取り付けたサンダーで研磨し、過去に塗られたと思われる塗膜を完全に除去したほうがよさそうです。最近、YouTubeでトナー転写を行う動画を見たため、PC-9801FAのときに採用したインクジェットプリンター用の転写シートではなく、今回はトナー転写による文字の再生を試してみたいと考えています。特にこのケースは、正面のモデル名付近に目立つ引っかき傷があるため、パテで傷を補修して塗装した後、トナー転写で文字を再現する予定です。Appleロゴについては、今回の短時間のレトロブライトでは、目立った色落ちは確認できませんでした。

関連記事:
Up