Emacs の表示欠けの件

先日の、新メインPC/Ubuntu 20.04 への移行の際の未解決問題の一つの「Emacs の表示欠け」問題ですが…

あらためて再現動画を貼りますが、こんなんです。

あれから調べていたのですが、以下のことがわかりました。

  • 表示欠け状態は redraw-display または redraw-frame で修復できる。redisplay ではダメ。
  • emacs -q の初期設定で表示された *GNU Emacs* バッファでも再現する。
    • なのでフォント設定とか関係なさそう。
    • 表示欠けの部分が真っ白ではなくGNUアイコンの一部が描かれる場合がある。
  • ASCII 文字だけのバッファでも発生。
    • 日本語表示が原因というわけではなさそう。
  • scroll-down, scroll-down-command, recenter-top-bottom によるスクロールで再現するが常に再現するわけではない。
  • 表示欠けはウィンドウの最下行かその近くの行で発生する。

というわけで、ウインドウがスクロールするタイミングで redraw-frame を呼び出せばいいのでは?と思って以下のような設定をしてみました。

;; スクロール時に表示が欠けるバグの回避
(defun my-auto-redraw (win start)
  (redraw-frame))

(defun my-auto-redraw-setup ()
  (if (not (member 'my-auto-redraw window-scroll-functions))
      (progn
       (add-hook 'window-scroll-functions 'my-auto-redraw nil t))))

(add-hook 'after-change-major-mode-hook 'my-auto-redraw-setup)

スクロール発生時に呼び出される hook は window-scroll-functions ですが、buffer 毎に add-hook してあげないとダメみたいで、じゃあ buffer が作られる時に呼ばれる hook は?と思ったら、どうもないみたいなんですね…

代替案として after-change-major-mode-hook と buffer-list-update-hook が候補に上がっているのですが、buffer-list-update-hook が呼び出された時の current buffer がどれになるかよくわからなくて after-change-major-mode-hook でやりました。

これでうまくいくかと思ったら、表示欠けの発生自体は防げませんでした… でも C-l なり C-v なりでスクロールしたタイミングで修復されるので、ウィンドウの下の方で編集を続けるのでない限りは気にならなくなりました。表示が重くなったりちらついたりしないかと思ったのですが、GPUが速いせいか全然気にならないレベルでした。

とりあえずこれで様子見ですかね。バグレポとかした方がいいのかなぁ。でも検索しても他に発生してる報告を見かけないので環境特有の何かっぽいんですよね。うーむ…

メインPC新調 (ソフトウェア編)

前回の続きです。


Ubuntu 20.04 インストール

旧PCの Ubuntu 18.04 上で Ubuntu 20.04.1 ja (日本語Remix) をダウンロードしてブータブルUSBメモリを作成。

組み立てOSが何も入ってない状態で USB メモリを挿して起動したら普通にインストーラが起動しました。Ryzen PRO 4000 シリーズ(Renoir) の内蔵GPUが 20.04 の初期状態で動かないことがあるという話を聞いていましたが、HDMI で Full-HD モニターを繋いだ限りは大丈夫でした。*1

インストール先の SSDパーティションをいつものように切っていたら、インストールに進もうとすると、EFIシステムパーティションが必要だよ、このままだとブートしなくなるよ、みたいな警告が出て、EFIシステムパーティションて何?ってなったので調べました。

OSのブートローダーを入れる用のパーティションのようですね。MBRが手狭になったからこんなのできたんですかね?128MBもあれば十分みたいなので、それで設定しました。念の為 HDD の方にも作っておきました。なんかあった時にブートドライブにするかもしれないので。SSD は残り全部 / に、HDD は残り全部 /home に、swap パーションはナシ、で行きました。

その先は特にトラブルなくデスクトップが立ち上がりました。デスクトップは標準の Xorg を使いました。Wayland はまだ安定性が心配なのと、旧メインPCでベンチマークを測定しても特に速いわけではなかった(むしろ Xorg よりちょっと遅い)ので今回はパスしました。

デスクトップは今まで GNOME Flashback を使っていたのですが、home には Ubuntu 10.04 あたりからずっと引き継いできた秘伝のタレみたいな設定が仕込まれていて、トラブルの際に何がどうなってるのかよくわからなくなってきて放置になってる件もいくつかあり、この際一度まっさらな状態からやり直したいということもあって、今回から標準のデスクトップ環境を使うことにしました。標準のデスクトップならトラブルの際に情報も集めやすいというのもあって。

センサー関係

まずはハードウェアのトラブルをいち早くキャッチできるように、CPUやSSD/HDDの温度を確認できる体制にしたいと、hddtemp と lm-sensors をインストール。

$ sudo apt install hddtemp
$ sudo apt install lm-sensors
$ sensors-detect
...

sensors-detect は適当にやったのでよくおぼえていません… 基本デフォルトだったと思います。

この後 sensors-applet をインストールしたのですが、起動の仕方がわからず使用を断念。gnome-panel じゃないと使えない?

Ubuntu Software から適当に見繕った Hardware Sensors Indicator というのをインストールしました。パッケージ名は indicator-sensors です。

Preference で読み取るセンサーを選びます。CPU 温度は k10temp-pci-xxxx の Tdie、GPU 温度はたぶん amdgpu-pci-xxxx の edge、NVMe SSD の温度は nvme-pci-xxxx の Composite を見ればよいようです。HDD は HDD の型番が出てくるのでそれを。

これで温度が簡単に監視できるようになったのですが、トラブルが。indicator-sensors を起動したまま画面ロックまたは他のユーザーのデスクトップに切り替えてから戻ってくると、デスクトップがグレーアウトして、

Authentication is required to check power state for WDC WD40EFZX-...

という認証画面が表示されてデスクトップが一切操作できなくなってしまう現象が発生しました。キャンセルしても速攻再表示されます。認証すれば閉じると思ったのですが、一度は成功したものの、その後何度やっても認証が通らなくなって諦めて Ctrl+Alt+F3 でコンソール画面に入って X 関係のプロセスを kill するはめになりました…

どうやら以下の issue と同じ現象のようですが、まだ解決していないようです。

とりあえず HDD の温度表示は諦めて、Preference の Plugins タブから udisks2 を無効化しました。エラーメッセージでググるpolkit の設定ファイルを書き換えることで回避できるようなのですが、意味がよくわからないので敬遠しました。ていうか hddtemp 使ってないんですね。hddtemp を使うプラグインがあればいいのに…

ECC メモリは認識されている?

以下のコマンドでメモリが ECC かどうか確認できます。

$ sudo dmidecode -t 17
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
# SMBIOS implementations newer than version 3.2.0 are not
# fully supported by this version of dmidecode.

Handle 0x0016, DMI type 17, 84 bytes
Memory Device
	Array Handle: 0x000F
	Error Information Handle: 0x0015
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 16384 MB
	Form Factor: DIMM
...

ECC メモリでは Data Width と Total Width が同じ(64 bits)になるそうです。

エラー検出用のドライバは EDAC (Error Detection and Correction) というのですが、dmesg で EDAC がロードされて ECC が有効化されているのが確認できます。

$ dmesg
[    0.000000] Linux version 5.8.0-59-generic (buildd@lcy01-amd64-022) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 (Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18)
...
[    4.140391] EDAC amd64: F17h_M60h detected (node 0).
[    4.140441] EDAC amd64: Node 0: DRAM ECC enabled.
[    4.140442] EDAC amd64: MCT channel count: 2
[    4.140517] EDAC MC0: Giving out device to module amd64_edac controller F17h_M60h: DEV 0000:00:18.3 (INTERRUPT)
[    4.140520] EDAC MC: UMC0 chip selects:
[    4.140522] EDAC amd64: MC: 0: 16384MB 1:     0MB
[    4.140524] EDAC amd64: MC: 2:     0MB 3:     0MB
[    4.140527] EDAC MC: UMC1 chip selects:
[    4.140528] EDAC amd64: MC: 0: 16384MB 1:     0MB
[    4.140529] EDAC amd64: MC: 2:     0MB 3:     0MB
[    4.140530] EDAC amd64: using x8 syndromes.
[    4.140545] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED)
[    4.140546] AMD64 EDAC driver v3.5.0
...

メモリのエラー発生と訂正の情報は、edac-util で確認できます。

$ sudo apt install edac-utils
$ edac-util -sv
edac-util: EDAC drivers are loaded. 1 MC detected:
  mc0:F17h_M60h
$ edac-util -v
mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
edac-util: No errors to report.

というわけで ECC は OS 側から認識されているようです。エラー発生・訂正の様子を実際に確認するにはメモリを起動でコケない程度にオーバークロックするとよいそうですが、さすがにそこまではやりませんでした…

データコピー

デスクトップ環境をまっさらな状態から構築する関係で旧PCの home ディレクトリをそのまま移行はしないのですが、データの大半は必要ですし、必要になるたびコピーするのは面倒なので、旧 home をまるごと新PCの適当なフォルダにコピーしました。2TB近くあるので、万一のデータ化けを防ぐために転送方法を工夫しました。

最初は samba をインストールして SMB 署名を有効(smb.conf の [global] セクションで server signing = mandatory を設定)にして nautilus からコピーしようとしたのですが、SMB だとシンボリックリンクのコピーでエラーになり、ずっと確認ダイアログが出てきて前に進まないので*2 ssh と tar を使いました。

まず新PC側に ssh サーバーをインストールします。

$ sudo apt install openssh-server

そして新PC側にコピー先になる一時ディレクトリを作成して(~/tmp とします)、旧PC側で以下のようにして home ディレクトリを丸ごと転送しました(ユーザー名 hoge は適当に置き換えてください)。

cd /home
tar cfpv - -C . hoge | ssh hoge@keynes.local 'tar xf - -C tmp'

tar の p オプションでシンボリックリンクシンボリックリンクのまま転送しています。

ssh を使ったのは暗号化された通信なら通信路でデータ化けが発生すれば送信先で復号できなくなってエラーになることが期待できるからです。エラーにならずに送信が完了すればデータは無事というわけです。

単純なコピーなら scp の方が簡単ですが、scp はシンボリックリンクはリンク先の実体をコピーする形でしかコピーできないので上の方法にしました。

キーボード、日本語入力

mozc の修正

今まで何度か書いてますが、US配列キーボード + かな入力 + NeXT かな配列 という少数派(ていうか他にそんな人いるのかな?)の日本語入力方式を使っている関係で、mozc に自作パッチを当てて使っています。fcitx-mozc, ibus-mozc, emacs-mozc に対応したパッチがこれです。

実際には古いパッチがそのままでは使えなかったので、このパッチは手修正したものから再作成したものです。

作業手順は、まず、apt のソースリポジトリを有効にします。/etc/apt/sources.list の、

# deb-src ...

となっているところのコメントアウトを全部外します。ssh でリモートログインして作業してたのでこうしましたが、デスクトップが使える状態なら「ソフトウェアとアップデート」の「Ubuntu のソフトウェア」タブから「ソースコード」にチェックを入れたほうが早いです。

以下適当な作業ディレクトリを作って作業。

$ sudo apt-get update
$ sudo apt-get install dpkg-dev
$ sudo apt-get build-dep ibus-mozc
$ apt-get source mozc

ここで上のパッチを適用(path/to のところは適当に置き換えてください)。

$ patch -p1 < path/to/mozc-2.23.2815.102-nxkana-20210708.patch

パッチが終わったらビルドします。

$ dpkg-buildpackage -rfakeroot -uc -b

パッチでは changelog は修正していないので元のソースのバージョンと同じバージョンの deb が生成されます。これをそのまま上書きインストールしますが、その前に依存するパッケージをインストールしておきます。途中右往左往して最小限のパッケージがどれだかわからなくなりましたが、emacs と fcitx 関係を入れたのかな…

$ sudo dpkg -i *.deb

mozc のアップデートが降ってくると上書きされてしまいますが、その時は再び上の作業を繰り返す必要があります。

ちなみに最初は changelog に別のバージョンのログを定義してバージョンの違う deb をビルドしていたのですが(-8ubunt1 のところを -8rna1 とかにしてた)、mozc 以外のアップデートが降ってきた時に依存関係のせいなのか元のバージョンに上書きされてしまったので同じバージョンでビルドするようにしました。

キーボードの設定

旧メインPCに繋いでいる HHK (Happy Hacking Keyboard PD-KB02) は、新メインPCの設定が一通り終わるまでは使いたいので予備のキーボードを繋いだのですが、日本語キーボードしかなかったのでインストール時の初期設定は日本語キーボードにしていました。

新PCへの移行の目処がついた時点で HHK を新PCで使うためUSキーボード用の設定に切り替えました。まずコンソールのキーボードを変更。

$ sudo dpkg-reconfigure keyboard-configuration

CUI で設定画面が出るので HappyHacking, English(US) で設定しました。

次にデスクトップにログインして「設定 - 地域と言語」で入力ソースから「日本語」を削除して「英語」を追加して、追加されたエントリをドラッグして先頭に持っていきます。

Shift Space で IME を ON/OFF して入力モードを切り替える派なので、その後 Mozc の設定で「キー設定」をATOKをベースにして以下のように設定しました。

  • 変換前入力中/キャンセル後IMEを無効化 を Shift Space に
  • 直接入力/IMEを有効化 を Shift Space に
  • 入力文字なし/キャンセル後にIMEを無効化 を Shift Space に
  • 入力文字なし/代替空白文字を入力 を Ctrl Shift Space に

デスクトップを一度ログアウトしてログインしなおすと設定が反映されます。これでだいたい思ったとおりの挙動になりました。

emacs の設定

emacs はそのままだとインライン入力(on-the-spot)ができません。ibus-mozc からの入力になり、カーソル位置の下に小さなウィンドウが出てそこに入力文字が表示されて変換・確定して emacs のバッファに入力されることになります。

これは不便なので emacs-mozc パッケージを使いたいのですが、IME の ON/OFF を他のアプリと同じキーで行うには ~/.Xresources に以下の記述が必要です。

Emacs*UseXIM: false

これは X から emacsGUI への IME 入力を無効化する設定です。このあとデスクトップを一度ログアウトしてログインしなおすか、コマンドラインで以下を実行します。

$ xrdb merge ~/.Xresources

あとは ~/.emacs.d/init.el に emacs-mozc の設定をすればいいのですが、素の emacs-mozc は使っているうちに変換候補表示がものすごく重くなることがありました。今でもそうなのかわかりませんが、Ubuntu 18.04 では mozc-popup を入れると解決したので今回も入れます。

まず、melpa からパッケージをインストールできるようにします。

(require 'package)
(add-to-list 'package-archives
             '("melpa" . "https://melpa.org/packages/"))

package-list-package して melpa のパッケージが出てきたら*3 mozc-popup を探してインストールします。

で、これをインストールすると依存パッケージとして emacs-mozc の最新版もインストールされてしまうので、上でやった mozc へのパッチの emacs-mozc の分が台無しになります… しょうがないので、emacs の設定の方で解決します。まず、以下のかな配列テーブルを ~/.emacs.d/ にコピーします。

そして ~/.emacs.d/init.el で以下のように設定しました。

(require 'mozc)
(load-file (expand-file-name "~/.emacs.d/mozc-keymap-kana-101us-nx.el"))
(setq mozc-keymap-kana mozc-keymap-kana-101us-nx)
(set-language-environment "Japanese")
(setq default-input-method "japanese-mozc")
(prefer-coding-system 'utf-8)
(global-set-key (kbd "S-SPC") 'toggle-input-method)
(require 'mozc-popup)
(setq mozc-candidate-style 'popup) ; select popup style.

Shift Space で IME ON/OFF の設定も入っています。

GNOMEEmacsキーバインド

GNOME/GTK アプリで Emacs 風のキーバインドが使えるように設定します。dconf で設定してもいいのですが、ミスに気づきにくくてハマりやすいので GUI の dconf-editor をインストールします。

$ sudo apt install dconf-editor
$ dconf-editor

パスをたどって /org/gnome/desktop/interface/gtk-key-theme を Emacs にします。

xkeysnail のインストール

以下の理由から xkeysnail でキーのリマップを設定します。

HHK の Meta キーの件は以前は xkb の設定で解決していたのですが、面倒なのと、Firefox の件でどっちみち xkeysnail を使うので、キーリマップは xkeysnail に一本化しました。

まずインストール。

$ sudo apt install python3-pip
$ sudo pip3 install xkeysnail

設定ファイルを書きます(xkeysnail-config.py とします)。

import re
from xkeysnail.transform import *

define_modmap({
    Key.MUHENKAN: Key.LEFT_ALT,
    Key.HENKAN: Key.RIGHT_ALT,
})

define_keymap(lambda wm_class: wm_class in ("Firefox"), {
    K("C-n"): with_mark(K("down")),
    K("C-b"): with_mark(K("left")),
}, "Firefox")

前半は HHK のメタキー(◇)を Alt にするための設定、後半は Firefox に Ctrl N と Ctrl B が食われないようにするための設定です。

以下で動作を確認します(path/to のところは適当に置き換えてください)。

$ xhost +SI:localuser:root
$ sudo xkeysnail path/to/xkeysnail-config.py -q

上のように xkeysnail は root 権限で実行する必要があります。以前はデスクトップにログインするたびに sudo のパスワード入力をしていたのですが、面倒なので以下を参考に自動実行するように設定しました。

まずグループの作成とユーザーのグループ設定(hoge (ユーザ名)は適当に置き換えてください)。

sudo groupadd uinput
sudo gpasswd -a hoge input
sudo gpasswd -a hoge uinput

/etc/udev/rules.d/input.rules を作成して以下のように設定。

KERNEL=="event*", NAME="input/%k", MODE="660", GROUP="input"

/etc/udev/rules.d/uinput.rules を作成して以下のように設定。

KERNEL=="uinput", GROUP="uinput"

~/.config/systemd/user/xkeysnail.service を作成して以下のように設定(path/to のところは適当に置き換えてください)。

# 1. Copy this to ~/.config/systemd/user/xkeysnail.service
# 2. systemctl --user enable xkeysnail
#
# Note that you need to set proper $DISPLAY on your environment.

[Unit]
Description=xkeysnail

[Service]
KillMode=process
ExecStart=/usr/local/bin/xkeysnail path/to/xkeysnail-config.py -q
ExecStartPre=/usr/bin/xhost +SI:localuser:root
Type=simple
Restart=always

# Update DISPLAY to be the same as `echo $DISPLAY` on your graphical terminal.
Environment=DISPLAY=:0

[Install]
WantedBy=default.target

xkeysnail の -q オプションは入力したキーをシステムのログに残さないための設定です。こうしないと実質キーロガーになってしまうので…

このサービス有効化します。

$ systemctl --user enable xkeysnail
$ systemctl --user start xkeysnail

一度再起動しないと xkeysnail の起動に失敗するので start はいらないかも。ここまできたらPCを一度再起動します。

再びデスクトップにログインして、以下のようにステータスを確認します(hoge や 1234(ユーザID) や /path/to は適当に読み替えてください)。

$  systemctl --user status xkeysnail
● xkeysnail.service - xkeysnail
     Loaded: loaded (/home/hoge/.config/systemd/user/xkeysnail.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2021-07-05 09:39:27 JST; 16s ago
    Process: 2224863 ExecStartPre=/usr/bin/xhost +SI:localuser:root (code=exited, status=0/SUCCESS)
   Main PID: 2224864 (xkeysnail)
     CGroup: /user.slice/user-1234.slice/user@1234.service/xkeysnail.service
             └─2224864 /usr/bin/python3 /usr/local/bin/xkeysnail /path/to/xkeysnail-config.py -q

 705 09:39:27 keynes systemd[1421]: Starting xkeysnail...
 705 09:39:27 keynes xhost[2224863]: localuser:root being added to access control list
 705 09:39:27 keynes systemd[1421]: Started xkeysnail.

フォントの設定

何かと便利なので Windows と共通のMSコアフォントは入れておきます。

# sudo apt install ttf-mscorefonts-installer

日本語フォントは入ってませんが…

ネットで入手できるフォントはファイルをダブルクリックしてフォントビューアからインストールできますが、数が多くなると面倒なのと、.ttc (TrueType Collection) ファイルはなぜか [インストール] ボタンが無効になってインストールできないのでどうしようかと思っていたところ、~/.local/share/fonts にファイルをコピーするだけでそのまま使えるようになりました。

その他

ruby bundler でデプロイしたスクリプト

このブログを書くのにも使っている HatenaBlogWriter ですが、gem のバージョンを固定するために ruby bundler を使っています。

Ubuntu のデフォルトでは ruby からして入ってないので(python は入ってるのに…) bundler も一緒にインストールします。

sudo apt install ruby
sudo apt install ruby-bundler

旧PCからコピーしたデプロイ先ディレクトリ(/path/to/dir とします)でそのままスクリプトを実行すると、こんな感じのエラーで実行できません。

Traceback (most recent call last):
	2: from /usr/bin/bundle:23:in `<main>'
	1: from /usr/lib/ruby/2.7.0/rubygems.rb:294:in `activate_bin_path'
/usr/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': Could not find 'bundler' (1.16.1) required by your /path/to/dir/Gemfile.lock. (Gem::GemNotFoundException)
To update to the latest version installed on your system, run `bundle update --bundler`.
To install the missing version, run `gem install bundler:1.16.1`

古い bundler で入れた gem はそのままでは動きません。エラーメッセージの指示通り更新します。

$ bundle update --bundler
Fetching gem metadata from https://rubygems.org/.
Fetching rake 10.5.0
Installing rake 10.5.0
Fetching atomutil 0.1.5
Installing atomutil 0.1.5
Using bundler 2.1.4
Warning: the lockfile is being updated to Bundler 2, after which you will be unable to return to Bundler 1.
Bundle updated!

これでスクリプトが動くようになりました。

VLC

デフォルトの動画プレイヤーは対応コーデックが限られているので VLC をインストールしました。

$ sudo apt install vlc

Full-HD 動画の再生も特に問題なし、と思ったのですが、特定の MPEG2 TS ファイルを開くと途中から映像が止まり音声だけ進む状態になり、やがてマウスカーソルも動かなくなりました。音声はそのまま流れます。外から ssh でログインはできるので X だけハングしている状況のようです。

原因の切り分けのためにまず VLC の [ツール - 設定 - ビデオ] で「Output」を「無効」に設定してみたところ、ハングしなくなりました。なぜかウィンドウのサイズが勝手に変わり続けて気持ち悪いのですが、音声は正常ですし、ハングもしません。

では OpenGL 関係の不具合なのか?と思って今度は「ASCII Art」に設定してみたところ、同じ動画の同じ箇所でハングしてしまいました。ということは OpenGL は関係なく、MPEG2 ビデオデコーダーの不具合?

[ツール - 設定 - 入力/コーデック] の Hardware-accelarated decoding はデフォルトで「自動」になっていて、Ryzen APU の場合、ハードウェアデコーダが使用されているものと思われます。そこでこれを「無効」に設定したところ、ハングしなくなりました。

ソフトウェアデコードは重いのでは、と思ったのですが、さすがに 4コア8スレッドの Ryzen だけあって全く気になりません。再生中に Twitter で実況しても特に重くなる場面はありませんでした。CPU 使用率も MPEG2/Full-HD で20%前後、H264 でも10%前後(何故かH264の方が軽い)で CPU 温度も特に問題なかったので、それ以上設定を試さずにこれで行くことにしました。

shotwell

旧PCでは ~/Photos に写真を入れる設定にしていたのですが、旧PCから

  • ~/.local/share/shotwell
  • ~/.cache/shotwell
  • ~/Photos

を同じ場所にそのままコピーすると問題なく移行できました。ただし、Flickr への写真のアップロードの際は再認証が必要でした。何故かパスワードが通らなくて(アカウントが連携している yahoo.com では通るのに)一度パスワードリセットをする必要がありました。

Nextcloud クライアント

クラウドストレージは以前は Dropbox をメインに使っていたのですが、規約改定で無料で連携できるデバイス数が制限されてしまい使い勝手が著しく悪化したので、最近は昔から借りているさくらのレンタルサーバーに Nextcloud をインストールして使っています。

すでに 13GB くらい使っているのですが、さくらのレンタルサーバー(プレミアム)は一度に大量の転送が発生すると 503 エラーを返すようになり、ブログの画像置き場としても同サーバーを使っている身としてはそれは避けたかったので、ローカルでコピーしてから同期することで転送を防ごうとして試行錯誤していました。

最終的には、

  • 旧PC の Nextcloud クライアントを止める
    • 同期フォルダ直下にある以下のファイルが消える(xxxxxxxxxxxx は乱数っぽい文字列)
      • ._sync_xxxxxxxxxxxx.db-shm
      • ._sync_xxxxxxxxxxxx.db-wal
      • ._sync_xxxxxxxxxxxx.db は残る
  • 同期フォルダをまるごと(._sync_xxxxxxxxxxxx.db も含めて)新PCにコピーする
  • 新PCに Nextcloud クライアントをインストール(sudo apt install nextcloud-desktop)
  • nextcloud を起動して認証、同期フォルダ設定

でなんとかなりました。最初は ._sync_xxxxxxxxxxxx.db が残っていると悪さしそうと思って消していたのですが、それをやると逆にほぼ全ファイルを同期しようとしてダメでした。

XSH2

XSH2 は、とあるプロジェクトで使用している perl ベースの言語で、XMLの処理を簡単に記述できるので使っています。Ubuntu のパッケージはないので、CPAN でインストールします。試行錯誤しましたが、以下の手順でインストールできるはずです。*4

まず libxslt1 の開発用パッケージをインストールします。XSH2 が依存する XML-LibXSLT-1.99 がこれを必要とします。

$ sudo apt install libxslt1-dev

cpan を起動します。初回起動時の初期設定はデフォルトのままで進み、まず XML::LibXSLT を notest install します(test で失敗するため)。

cpan[1]> nostest install XML::LibXSLT
Running install for module 'XML::LibXSLT'
  SHLOMIF/XML-LibXSLT-1.99.tar.gz
...
  SHLOMIF/XML-LibXSLT-1.99.tar.gz
  /usr/bin/make install  -- OK

その後 XML::XSH2 を install します。

cpan[1]> nostest install XML::LibXSLT
...

途中、

	Term::ReadLine::Perl::readline(Term::ReadLine::Perl=ARRAY(0x56316edc7470), "Enter arithmetic or Perl expression: ", "exit") called at test.pl line 54
Enter arithmetic or Perl expression: exit

というメッセージが出て止まりますが、そのままリターンキーを押せば最後まで進んでインストールできました。

CPAN の初期設定で変更していないなら、~/perl5/bin/ に xsh がインストールされます。ここには CPAN が .bashrc を変更して PATH を通してあるので、シェルを立ち上げ直せば xsh が起動するようになります。

Stellarium

プラネタリウムソフトの Stellarium ですが、Ubuntu の公式リポジトリからインストールすると何故か少し古いバージョンが入ります。旧PCでは一時期あった月食のバグ(月食中の空を表示すると落ちる)を回避するために公式 PPA からインストールしていた関係で、旧PCの設定ファイルを新PCにコピーしても設定が一部反映されなくなりました。

仕方がないので新PCでも公式 PPA からインストールするようにしました。

$ sudo add-apt-repository ppa:stellarium/stellarium-releases
$ sudo apt-get update
$ sudo apt install stellarium

その後旧PCから ~/.stellarium を丸ごと新PCにコピーしてから stellarium を起動したところ、無事旧PCの設定が反映されました。

astrometry.net

astrometry.net は天体写真から写野の天球上の位置を特定する(plate solve といいます)ためのソフトです。Ubuntu にもパッケージがあるので、apt でインストールします。

$ sudo apt install astrometry.net

しかしこれだけでは計算できません。星表のデータが必要になります。これが膨大で全部で 30GB 以上あるものをダウンロードしなくてはなりません。これも apt でインストールできるので旧PCには全部いれていたのですが、むちゃくち時間がかかるしサーバーにも負荷がかかるので気が引けます。そこで旧PCからデータを丸ごとコピーすることにしました。

astrometry-data- 系パッケージのファイルリストを見ると、tycho2 (ティコ第二星表)も 2mass (Two Micron All-Sky Survey)も、最終的には /usr/share/astrometry/ に fits データを置いているだけのようです(2mass の方は中身はダウンローダーで別のサーバから fits をダウンロードしています)。その他ドキュメントも /usr/share にインストールしていますが、これは動作には関係ないと思われます。

ということで旧PCから /usr/share/astrometry/ の中身だけコピーします。新PC側で、先に sudo で何か実行して認証を済ませてから(そうしないと ssh と sudo のパスワード入力が被って入力できなくなる)以下を実行。

$ ssh rna@OLD_PC 'tar cfp - -C /usr/share/astrometry .'| sudo tar xvf - -C /usr/share/astrometry/

コピー完了後 solve-field コマンドを実行すると無事 plate solve に成功しました。

未解決の問題

indicator-sensors で HDD 温度表示を有効にすると認証を要求される

上の「センサー関係」で書いた通りです。今は udisks2 プラグインを無効にして、必要な時にコンソールから hddtemp を実行しています。あまり激しく温度変化することはないようなので当分これで行きます。

Emacs の表示欠け

Emacs を使っていると時々表示が欠ける(一部の文字が背景色で塗りつぶされる)ことがありました。こんな感じ。

文字単位で消えるわけではなく一部が欠ける感じなのですが、上の動画のように欠け方が大きくてほぼ1行まるまる消えているように見えることもあります。発生条件は不明ですが C-l でスクロール位置を切り替えていると発生することがあります。発生しないこともありますし、そうでない時に発生することもあります。

当該箇所でカーソルを動かしたり範囲選択したりすると表示が復帰しますが、編集中に発生すると文字の消しすぎと勘違いして再入力してしまったりして厄介です。

サウンドのノイズ

これも発生条件が不明なのですが、何かの表紙にサウンドにノイズが入り初めて、システムサウンドも含めてどのアプリから音を鳴らしてもノイズが入るようになってしまいます。ノイズの入った音のあとにエコーのように同じ音が繰り返されるのが特徴です。

気がつくと直っていることもあるのですが、ずっと直らないことも。ベンチマーク中でも何時間も動画を再生していても再現しないので負荷でチップが熱を持って、みたいな話ではなさそう。

再起動後デスクトップにログインしていきなり再現したこともあります。この時は top でプロセスを見ると pulseaudio が 5% ぐらいCPUを食った状態で張り付いていて、pulseaudio の暴走かなと重い以下のコマンドで pulseaudio だけ再起動すると即直りました。

$ pulseaudio -k

とりあえず再発したらこれでしのぎます…

nautilus で SMB のファイルコピーが遅い

Windows の共有フォルダをファイルマネージャー(nautilus)でマウントしてファイルをコピーすると異様に遅いことに気が付きました。1Gbps のネットワークなのに 30〜40MB/s 前後しか出ません。Windows 同士だと 100MB/s 近く出るのですが。

これは困る、と思ったのですが、調べてみると旧PCでも同じくらいしか速度が出ていないことが判明。なら今まで困ってないからいいか… ということで諦めたのですが、一応調べてみると、どうも GNOME の未解決の不具合(制限?)のようです。

nautilus の SMB は gvfs-smb 経由で GIO API を使っているのですが、この時デフォルトの 64KB のブロッサイズが適用されてしまい、性能が出ないとのこと。適切なブロックサイズをオプションで指定すれば性能が出るのは確認済みですが適切なブロックサイズを検出する方法が難しいようでまだ fix されていません。

apt で cifs-utils をインストールして、以下のように正攻法で cifs ファイルシステムとしてマウントするか(マウントポイントは share ユーザ名は hoge とする)、

$ sudo mount -t cifs //windowspc/share/ share -o "username=hoge"

あるいは逆に Ubuntu 側で samba の共有フォルダを作り Windows 側からコピーしてあげるとフルスピードでコピーできるので、それでしのぐことにしました。

デスクトップ壁紙画像が変更できない

デスクトップの背景を変えようと、設定 - 背景 の [画像を追加] で ~/ピクチャ から画像を選ぼうとしても選べませんでした。ファイルダイアログは開くのですが画像を選んでも [開く] ボタンがグレーアウトしたまま。~/Photos の下のファイルでも同様なので日本語パス名の問題ではないようです。

納得行かないのですが、dconf-editor で /org/gnome/desktop/background/picture-url に画像のURLを file:///home/hoge/ピクチャ/cure-marine.jpg のように設定してやれば変更できるので、当分それでしのぐことにしました。

iPhone からの動画のコピーで nautilus が固まる

USB で iPhone を繋いで iPhone 側で「このPCを信頼する」を許可してからUSBを挿し直したら nautilus から写真とドキュメントにアクセスできるようになったのですが、写真から大きな動画をコピーすると nautilus が固まってしまう現象が発生しました。

プログレスバーが進まなくなって転送速度も0KB/s表示になり、nautilus の操作が一切できなくなりました。しかし実際にはコピー自体は進んでいるようで、コピーが終わると nautilus も復帰し、コピーも成功していました。

いまいち納得いきませんが当面我慢して使っていこうと思います。

まとめ

いくつか問題は残りましたが、おおむね旧PCでできていたことは一通りできるようになりました。新PCはさすがに最新のCPUだけあってサクサク動くし気持ちいいです。

今までネットとテキスト編集程度だけなら低スペックのPCで十分って思ってたのですがそんなことはありませんでした。今どきの Web ページ、JavaScript バリバリに使ってるせいもあって、CPUパワー次第でレスポンス全然違いますね… どうせサーバーサイドが重いんでしょ、と諦めてた TwitterFacebook もサクサク動くようになってびっくり。

メモリも 32GB になると安心して使えます。16GB の時は長期間大量のタブが開いた Firefox を放置しているとメモリ残量が気になりだして Firefox を再起動したり Shotwell の同時起動をためらったりしてましたが、今は何も考えずガンガン起動できる感じです。

ということでこれから5年くらいは新PCでなんとかしのげるかな…

長々と書きましたが、正直これ読んで楽しい人なんてほとんどいないと思うんですけど、自作PCLinux やってる人で困った人が検索で見つけてちょっとは役に立ったりすればいいなと思って公開することにしました。実際今回も今までも自分がそうやって助かっているので。

*1:4K では表示がおかしくなるという話もありますが、Ubuntu 20.04 はデフォルトで HWE (HardWare Enablement) スタックのドライバが入るので、現在はインストール後アップデートをかければ直るものと思われます。

*2:なんでそんなにシンボリックリンクがあるのかというと IIIME 関係のソースをビルドした時に生成されたもののようですが、全部特定していらないものを削除したり、いるものは tar で固めたり、というのは大変すぎるので諦めました。

*3:最初 gnu のパッケージしか表示されなくて遅れて出てくることがある。出てこないなら M-x package-initialize したら出てくるようになるかも。

*4:参考: https://stackoverflow.com/questions/28473981/how-to-reinstall-re-run-module-installation-for-a-failed-install-in-perls-mcpa

メインPC新調 (ハードウェア編)

2014年から使っていたメインPCを丸ごと新調しました。Linux (Ubuntu)で使うということもあり、今回も自作です。

旧PC 新PC
CPU Athlon 5350 (4C4T/2.05GHz) Ryzen 3 PRO 4350G (4C8T/3.8GHz)
MB ASRock AM1B-ITX ASRock B550M-ITX/ac
MEM 16GB (DDR3 1600MHz) 32GB (DDR4 3200MHz, ECC)
HDD/SSD WD Red 4TB SSD 960 EVO 500GB / WD Red Plus 4TB
OS Ubuntu 18.04 Ubuntu 20.04
CASE Cooler Master CENTURION 6 (ATX) SSUPD MESHLICIOUS (Mini-ITX)
PSU SUPER FLOWER SF-500P14FG Seasonic FOCUS-GM-550 (550W)
CPU COOLER Thermaltake MeOrb II CRYORIG C7 V2
CASE FAN 12cm+14cm (CASE付属) 12cm x2 (Cooler Master MasterFan SF120M, 山洋 SF12-S4)

パーツの選定

旧PCのパーツは主にツクモから買いましたが、今回は Ryzen PRO 4000 シリーズがマザーボードとセットでしか販売しておらず、組わせられるマザーが店によって限定されている場合があり、目当てのマザーと組み合わせられるアークで揃えました。一部パーツは他の店の方が安かったのですが、同じ店で買った方がサポートで安心かと思って。

CPU の選定基準は、省電力運用できること、ECC に対応していること、内蔵グラフィックがあること、ということで Ryzen PRO シリーズ一択になりました。8月に最新の 5000G シリーズが発売ですが PRO 版がいつ出るかわからないし、そもそも8月まで待つつもりはないので 4000G で。省電力版の 4000GE は一般販売されていないので、4000G を cTDP 設定で 35W にして運用します。

マザーは UEFI (BIOS)で cTDP が設定できる ASRock の製品を選びました。設定場所がなかなかわからなくて苦労しましたが…

ケースは一時期流行ったキューブ型ケース以来の小型ケースですが、これは置く場所がなかったから。旧PCはそのままファイルサーバーとして運用する予定なので机の上しか置く場所がないのでした。HDD が1台しか載りませんがバックアップ等は旧PCをネットワーク越しに使えばOK。小型ケースは昔冷却能力の低さに悩まされてずっと敬遠してきたのですが、全面メッシュならなんとかなるだろう、水冷ラジエーターも対応してるので最悪水冷化も、と。

設置場所の制約で、幅20cm、奥行き30cm、高さ35cm くらいまで、種類が豊富なATX電源が載る、3.5' HDD が最低1台載る、という条件で在庫があるケースはほとんどなくて選択の余地があまりありませんでした。SSUPD は聞いたことのないメーカーだなと思ったら Lian Li のサブブランドということで、それなら作りもきっと大丈夫だろうと思って決めました。

起動ドライブは NVMe SDD にしました。これはサブPCで天体撮影のデータ一時置き場*1に使っていたものを、SSD を新調したのでお下がりで使い回すことにしたものです。交換前に Windows 用のツールで確認するのを忘れていたのですが、総書き込み量はたぶん8TBぐらい。960 EVO 500GB は TBW 200TB なのでまだまだ使えるはず…

/home 用には WD Red Plus を選択。メインPCは基本的に電源を落とさない運用なので NAS 用です。仮想通貨関係の需要による価格高騰が8TB以上ではまだ続いているので4TBを。NAS 用 HDD は東芝が安いのですが、先日録画サーバ用に使ってみたところ、書き込み時のカリカリ鳴る騒音が予想以上にでかくて結局バックアップ用にしたことがあったので… 作業中のカリカリは気にならないのですが、バックグランウドで動かしたまま寝たり動画観たり音楽聴いたりする時はどうしても気になってしまうので。

電源は、旧PCではファンレス電源でしたが、さすがに Mini-ITX ケースでファンレス電源は危険なので、信頼性の高そうな Seasonic の電源を選びました。このへんはあまり詳しくないので 80PLUS GOLD 以上のものからブランドだけ見て適当に選んでます。

CPUファンも詳しくないのですが、35W 運用とはいえ設定がうまくいかなかった場合も考えて 65W 以上対応で、小型ケースで邪魔にならない高さの低いもので、それでいて騒音の少ないものを選んだつもりです。

ケースファンは耐久性と静音性に期待して Cooler Master MasterFan を1個だけ注文したのですが、実際にケースの小ささを目の当たりにして、これはファン1個ではキツそうだな… と思って急遽サブPCのケースファンの交換用にストックしていた山洋の San Ace 12cm を追加投入しました。

組み立て

組み立ては結構苦労して半日かかりました。それとは別に組み立てと設置のスペースを確保するために部屋を片付けるのに2日かかってますが…

まず小型ケースはやっぱり苦労しました。いきなりケースのパネルの開け方がわからなかったのですが、これは戸棚の扉などでよくあるジュラコンキャッチ?式の突起を穴にパチッとはめ込むタイプでした。説明書が入っている箱がケースの中にくくりつけてあって、開け方を調べるために説明書を見ようと思っても開けないと説明書が取り出せないという…

部品の組付け方法が独特なので何をするにも説明書の確認は欠かせません。それでも組付けの順番や制約条件は自分で判断しないとわからないところもあり、途中まで組んでから一度バラしなおしたりという場面もありました。

ケースの工作精度は悪くないですが、板金が薄めでヤワいところがあり、雑な扱いは禁物という印象を受けました。特に 3.5' HDD を取り付ける部分は剛性が足りない感じ。スペース的には2台取り付けられる余裕はあるのですが、重さ的に厳しい印象。

この 3.5' HDD の取り付けですが、今回は内蔵GPUしか使わないので縦に取り付ける長いグラフィックボードとは排他なのは構わないのですが、ケースの中に水平に渡す金具に片持ちで HDD を吊るす形で取り付けるという独特なもの。ゴム製ダンパーが付いているので単周期の振動は発生しにくいようですが、本当に大丈夫なのか…

こういう仕組みなので 3.5' HDD を使うなら横置きは厳禁です。横置きできるとはどこにも書いてないし横置き用の足も付いてないので、設置は縦置きのみですが、マザーボードの組付けのためにケースを横に倒すのも、3.5' HDD を取り付ける前にやらないとダメです。

ちなみに製造不良なのか作業中ミスでネジ穴をナメてしまったのか、3.5' HDD 取り付け金具のケースに組み付けるためのネジ穴の一つにネジを奥までねじ込めないというトラブルがありました。ケースの構造上ネジの頭が出ているとサイドパネルがはまらないはずなのと、ネジを奥まで締め込まないと金具がぐらついて強度的にも振動的にも不安すぎるので焦りました。

無理やりねじ込もうとしても組み付け用の小さな皿ネジは材質的に弱いようで、あまり力を入れると頭の溝が欠けてきて、これは万事休すか、と思ったのですが、付属のネジにサイズとネジピッチが同じで頭がより大きな平ネジがあって、こちらの方が頭が丈夫そうだったので、これをねじ込んでネジ穴をタッピングすることに成功、その後元のネジを奥までねじ込むことができました。

なお MESHLICIOS は 3.5' HDD を取り付けてもライザーケーブルの取り付け位置を変更することで短い PCIe カードなら取り付けられる仕組みですが、ライザーの取り付け位置が変わるため、マザーのスロットとライザーの距離が離れてしまい、付属のライザーケーブルでは届かなくなり、長いライザーケーブルは別売りです。

ケースファンはフロントに 12cm または 14cm を2個取り付け可能ですが、上述の通り1個で済ます予定が、ケースの中が想像以上に密になりそうだったので2個取り付けました。2つとも静音ファンなのと設置場所がデスクから少し離れているのでファンノイズはほぼ気にならないです。

あとはマザーボードへの CPU ファンの取り付けが苦労しました。C7 は樹脂製バックプレートにボルトを通してナットで締めて固定する方式ですが、バックプレートの穴にボルトがなかなか通りません。一本通すと別の一本が外れてしまいます。CPU のコアがむき出しだった時代なら絶対コア欠けしてたな、というレベルでクーラーがガチャガチャ傾いてましたが、最終的にはかなり思い切って力を入れて無事はめ込むことができました。

UEFI(BIOS)設定

組み立て後、モニターとキーボードとLANケーブルを繋いで起動。一回で無事起動しました。ケースにスピーカーが付いていなくて POST コードがわからないので起動後しばらく画面が表示されなくて焦りましたが、待っていると UEFI の画面が表示されました。メモリも SDD も HDD も認識され、ファンセンサーも正常、CPU温度も異常なし。

デフォルトで自動オーバークロックが有効になっているのですが、トラブルの元なのでメモリのクロックだけは定格に固定しておきました。あとは内蔵GPU用のメモリを 1GB 固定に設定して、起動時 Num Lock を無効に。

最初 cTDP の設定が見つけられなくて困っていたのですが、これは後から姉妹板?の A520M-ITX/ac のレビューに書いてあったのと同じ設定項目があって無事設定できました。アドバンスド / AMD CBS/NBIO Common Options / SMU Common Options で System Configuration AM4 を 35W に変更。

ベンチマーク

Ubuntu 20.04 インストール後簡単なベンチマークを実施しました。ハードウェアの性能比較のためではなく、自分の作業環境がどれだけ改善されたかを確認するため、あるいは設定ミス等で異常に性能が落ちていないかを確認するのが目的です。

まず Octane 2.0 です。Firefox 89.0 の新規プロファイルで測定しました。

旧メインPC 4376
新メインPC 19672
サブPC 17456

サブPCは Windows 10 で天体撮影と画像処理、RAW現像、動画編集、ゲームなどに使っているマシンで、CPU は Core i5 6600、GPU は内蔵グラフィック(RAM は 1GB 割当)、メモリは 16GB (DDR4 2133MHz)です。

旧メインPCの4.5倍、サブPCと比べても1割程度速い結果になりました。

次に GPU の性能を見るのに Unigine BenchmarkHeaven。古いベンチマークですが、新しいものは負荷が高すぎて低スペックPCの内蔵グラフィックでは差が分かりづらいのでは思ってこれにしました。

Basic Extream
旧メインPC 170 53
新メインPC 1498 416
サブPC 635 172

もう一つ Linux オンリーですが OepnGL のベンチマークの GL Mark 2 を。

default fullscreen
旧メインPC 930 598
新メインPC 6646 6038

fullscreen は 1920 x 1080 (Full-HD)です。

ECC メモリだと内蔵グラフィックが遅くなるという噂を聞いて心配していたのですが、旧メインPCの 7〜10 倍速いし、Core i5 6600 のサブPCと比べても倍以上速いので、ひょっとしたらこれでも性能出ていないのかもしれないですが、自分の用途には十分すぎるくらの性能は出ているのでこれでよしとします。

結局新メインPCは家にあるPCの中で最速のPCになりました。なお、cTDP が定格(65W)だった時にも同じベンチマークをやりましたが、上の結果とほとんど変わらない結果でした。CPU と GPU 両方負荷かけないと差は出ないのかも。

冷却能力

GPU温度(amdgpu-pci, edge)は Unigine Heaven 実行中に 52℃ まで上昇しました(室温 27℃)。

CPU温度(k10temp-pci, Tdie)は Linux kernel のビルドで全コアに負荷をかけるテストではで 65℃ まで上昇しました(室温 26℃)。まあ許容範囲。

SSDの温度(nvme-pci, Composite)はアイドル時で 39℃、kernel ビルド時で 52℃ まで上昇しました(室温 26℃)。壊れる温度ではないですが、高め。マザー付属のヒートシンクを付けているのですがいまいち冷えていません。

HDDの温度はアイドル時で 36℃、kernel ビルド時で 37℃ まででした(室温 26℃)。

ということで…

ハードウェア自体は問題なく使えそうです。SSD もっと冷えて欲しいですが、作業は基本 HDD 上でやるのでまず問題ないかな。HDD の振動が心配でしたが、今の所問題は起きていません。

Ubuntu 20.04 のインストールと各種ソフトウェアの設定ついては後日エントリをアップします。

追記(2021-07-04): ケースの USB-C 端子について

一つ書き忘れていたことがありました。SSUPD MESHLICIOUS には上面に2つ USB の口がついていて、その片方は Type-C なのですが、マザー側に繋ぐケーブルの先のコネクタが20ピンの小さいやつ(Key A とか Type-E とか呼ばれてるやつ)で、B550M-ITX/ac 上にはこれに対応するヘッダがありませんでした。

マザー上には USB 3.2 Gen1 の19ピンの大きなヘッダがあり、これを20ピンに変換するパーツは1500円程で売っていますが、ヘッダは1つしかなく、Type-A の方に繋いでしまっています。ということで、ケーブルを繋ぐ先がなくて、ケースの Type-C は飾りになってしまいました。

PCIe 拡張カードで Type-E を増設できるやつがあるのですが、背が低いのでブラケットを外してスロットの摩擦だけで固定して無理やり組み込めるかも?でもそうまでしてフロントの Type-C 使いたいかというと…

*1:惑星撮影でCMOSカメラから動画を撮る時の保存先に高速なディスクが必要になるので使っていました。

上野千鶴子氏の東大入学式での祝辞の問題点について (2021/4/22追記あり)

二年前に話題になった上野千鶴子氏の東大入学式での祝辞を読み直す機会があり、今更ながらちょっとびっくりするようなことに気が付きました。初見ではスルーしていたのですが、よく見ると祝辞前半の理屈が全然通っていないのではないか?ということです。

祝辞の前半というのは東大理3の合格率の男女差について述べた以下の部分です。

ご入学おめでとうございます。あなたたちは激烈な競争を勝ち抜いてこの場に来ることができました。

その選抜試験が公正なものであることをあなたたちは疑っておられないと思います。もし不公正であれば、怒りが湧くでしょう。が、しかし、昨年、東京医科大不正入試問題が発覚し、女子学生と浪人生に差別があることが判明しました。文科省が全国81の医科大・医学部の全数調査を実施したところ、女子学生の入りにくさ、すなわち女子学生の合格率に対する男子学生の合格率は平均1.2倍と出ました。問題の東医大は1.29、最高が順天堂大の1.67、上位には昭和大、日本大、慶応大などの私学が並んでいます。1.0よりも低い、すなわち女子学生の方が入りやすい大学には鳥取大、島根大、徳島大、弘前大などの地方国立大医学部が並んでいます。ちなみに東京大学理科3類は1.03、平均よりは低いですが1.0よりは高い、この数字をどう読み解けばよいでしょうか。統計は大事です、それをもとに考察が成り立つのですから。

女子学生が男子学生より合格しにくいのは、男子受験生の成績の方がよいからでしょうか?全国医学部調査結果を公表した文科省の担当者が、こんなコメントを述べています。「男子優位の学部、学科は他に見当たらず、理工系も文系も女子が優位な場合が多い」。ということは、医学部を除く他学部では、女子の入りにくさは1以下であること、医学部が1を越えていることには、なんらかの説明が要ることを意味します。

事実、各種のデータが、女子受験生の偏差値の方が男子受験生より高いことを証明しています。まず第1に女子学生は浪人を避けるために余裕を持って受験先を決める傾向があります。第2に東京大学入学者の女性比率は長期にわたって「2割の壁」を越えません。今年度に至っては18.1%と前年度を下回りました。統計的には偏差値の正規分布に男女差はありませんから、男子学生以上に優秀な女子学生が東大を受験していることになります。第3に、4年制大学進学率そのものに性別によるギャップがあります。2016年度の学校基本調査によれば4年制大学進学率は男子55.6%、女子48.2%と7ポイントもの差があります。この差は成績の差ではありません。「息子は大学まで、娘は短大まで」でよいと考える親の性差別の結果です。

最近ノーベル平和賞受賞者のマララ・ユスフザイさんが日本を訪れて「女子教育」の必要性を訴えました。それはパキスタンにとっては重要だが、日本には無関係でしょうか。「どうせ女の子だし」「しょせん女の子だから」と水をかけ、足を引っ張ることを、aspirationのcooling downすなわち意欲の冷却効果と言います。マララさんのお父さんは、「どうやって娘を育てたか」と訊かれて、「娘の翼を折らないようにしてきた」と答えました。そのとおり、多くの娘たちは、子どもなら誰でも持っている翼を折られてきたのです。

上野氏の前半の理屈は一部混乱があるように思えますが以下のように整理できます。

A. 東大受験の女子の合格率は男子より低い(事実)*1
B. 東大を受験する女子が少ない(事実)
C. 社会には女性差別があり女子の受験が阻まれる(事実)
D. B の理由は C であろう(妥当な推論)
E. よって A の理由は C であろう(???)

よくわからないのは E です。単に A, B, C, D を列挙しただけなら論理的には問題ないのですが*2 A を述べた後「この数字をどう読み解けばよいでしょうか。統計は大事です、それをもとに考察が成り立つのですから。」「なんらかの説明が要ることを意味します」とした後「まず第1に」「第2に」「第3に」と B〜D を主張しているので、B〜D は A が何故なのかを「読み解き」「説明」しており、前半の議論の全体としては E を主張していると解釈するのが自然です。*3

ところが、A は 女子の東大合格率 = 女子の東大合格者数 / 女子の東大受験者数 が男子より低いという主張なのに、B〜D はその分母である「女子の東大受験者数」が少ないという主張しかしておらず、「女子の東大受験者数」が減った割合以上に「女子の東大合格者数」が減る(そうでないと合格率は減りません)理由を全く述べておらず、A の理由の論証として成り立っていないのです。

一方で、上野氏は「女子受験生の偏差値の方が男子受験生より高い」と主張しています。「女子の東大受験者数」が減る際に成績の低い人から東大受験を諦めるので、残った人は成績優秀な上澄みになるからです(以下これを「上澄み効果」と呼びます)。これは妥当な推論だと思います。

しかし、それならば女子の東大合格率は男子より高くならないと辻褄が合いません。辻褄を合わせるには女子が高校での成績が優秀であるにも関わらず受験本番で成績が下がる理由が必要です。ですがそれについて上野氏は何も述べていません。

「意欲の冷却効果」がその理由として提示されているという解釈は可能でしょうか?「意欲の冷却効果」は「どうせ女の子だし」「しょせん女の子だから」という社会の扱いが女子の勉強あるいは受験の意欲を削ぐという話です。

しかし、勉強の意欲が削がれているのなら女子一般の成績は男子一般より落ちるはずです。上野氏は女子受験生の方が男子受験生の方が成績が良いと言っているので、単純に見るとこれは矛盾です。ここは受験の意欲が削がれて受験を諦めた女子が多い中、敢えて受験を決意した女子は優秀な人が多い、と解釈するしかないと思います。

だとすると、結局これは「上澄み効果」の傍証を追加しただけということになり、「上澄み効果」があるにも関わらず女子の東大合格率が下がる理由については何も言っていません。

一体これは何なのでしょう?一つの解釈は、

1. 上野氏は「女子の東大受験者数」が減れば「女子の東大合格率」が下がると勘違いして、E を論証できたと思い込んでいる。

というもの。もう一つの解釈は、

2. E を論証するという素振りはフェイクで、実は「女子の東大合格率」が下がる理由は存在しないことを強調することで東大理3受験には女性差別的な不正があることを仄めかしている。

というものです。あるいは、

3. A の理由を説明する全く別の説明を用意していたが、当日話すのを忘れた。

という解釈もありうるでしょうか?

1 は上野氏の知的能力を疑っているという意味で失礼な解釈ですが、2 は上野氏に悪意があると見做しているのでこれもまた失礼な解釈ではあります。3 は 1 に似ていますが知的能力というよりは認知能力を疑っておりさらに失礼ですね… しかし、上野氏に間違いも悪意も存在しないという解釈はちょっと思い付きません。

もっとも 2 の解釈には問題があります。上野氏の祝辞は全体として東大の教育体制を肯定しているからです。祝辞の後半では「東京大学は変化と多様性に拓かれた大学です」「れから4年間すばらしい教育学習環境があなたたちを待っています。そのすばらしさは、ここで教えた経験のある私が請け合います」などと言って「ようこそ、東京大学へ」という歓迎の言葉で締めているのですから。

これを文字通りに取れば、上野氏は祝辞の前半で E が論証できたと思っている、すなわち合格率が低いのは入試以前の社会の女性差別のせいで入試に不正があったせいではないと思っていることになります。入試に不正があったと思っているならこうはならないでしょう。よって解釈 1 が正解であると。

しかし上野氏ほど知的能力の高い人が一世一代の大事なスピーチで 1 のような勘違いができるものでしょうか?そんなはずはない、とするならば、東大肯定のこの部分を文字通りに受け取ることは不可能になります。その場合、東大肯定部分は言外に「(但し医学部を除く)」という含みのあるものと解釈せざるをえません。

これはやや無理のある解釈ではありますが、上野氏は「社会に出れば、もっとあからさまな性差別が横行しています。東京大学もまた、残念ながらその例のひとつです」と言っており*4 東大の何もかもを肯定しているわけではないので、そういう解釈もありえなくはない、とは言えるでしょう。

また、3 の解釈にも無理があります。この祝辞は東大の公式サイトに掲載された際に「一部事実と異なる表記」を修正しています。3 の解釈が正解ならこの時に話し忘れた部分を加筆するのが自然ではないでしょうか。

今の今まで話し忘れたこと自体気付いてないという可能性もゼロではないですが、そもそも行間からも読み取れない主張を存在するものとして解釈する、しかもそれがどんな主張か全く不明、というのでは文章の解釈とは言えません。文章の解釈とは別次元の擁護論と言わざるを得ないでしょう。

ということで、僕自身は 1 の解釈を取っています。上野氏だって人の子で勘違いはするだろう、と思っているからです。でも上野氏の知的能力を信頼する人ほど 2 の解釈に流れるということはあると思いますし、その解釈を完全に否定することは困難だと思っています。

「ハンロンの剃刀」(無能で十分説明されることに悪意を見出すな)というベストプラクティスに反するとは言えますが、「ハンロンの剃刀」が常に正しいというわけでもないのですから。

なお、僕はこの祝辞は全体としては良いことを言っていると今でも思っています。上野氏は、才能や環境に恵まれ受験競争を勝ち抜いた新入生たちに対して女性差別を例に挙げ「がんばっても報われない社会」の存在を示し、その一方でフェミニストや東大そのものなど限られた範囲ではあれ「がんばったら報われる」環境を作ってきた人に思いを馳せ、そのように生きなさいと言っているのです。

ただ、最初にこれを読んだ時は不正入試を「がんばっても報われない社会」の例として示していて、理3の合格率男女比 1.03 も不正の仄めかしだと思っていました。女子が社会の女性差別の結果、浪人を過剰に避けたり進学を諦めたりするのもまた「がんばっても報われない社会」の独立した例示だと思っていたからです。

でも、今回祝辞を読み直して、どうも理3の合格率問題は不正ではなく社会の女性差別の帰結だと主張しているらしいことに気付いて戸惑った、というわけです。

祝辞の骨子としては依拠する例示が一つ減っただけで、何ら破綻があるわけではありません。しかし、理3の合格率問題を、これは不正なのか?と問いかけつつ、いや不正ではない、という論証に失敗しているというのは、じゃあ不正なのか?という疑問を残してしまうことになります。

実際のところ 1.03 という合格率男女比の偏りは統計的誤差の範囲と解釈可能で、理3の入試に不正はなかった、よって上野氏の祝辞の骨子は揺らがない、と言えると思いますが、1.03 が社会の女性差別の反映であるという主張自体は誤りで、そのことは上野氏の失点と言わざるを得ません。上野氏自身が「統計は大事です」などと言っているのですからなおさらです。

以上、この件については Twitter でもたくさんつぶやきましたが、話が結構ややこしい上、僕自身も頭を整理しきらないままつぶやき散らかしたせいで僕が何を言いたいのかわかりづらいところがあったと思い、改めて論旨を整理してまとめました。

追記(2021/4/22): 「1.03 という合格率男女比の偏りは統計的誤差の範囲と解釈可能」と書きましたが、そうとも言い切れない事に気が付きました。

一見してばらつきの範囲内に見えるのと、「東大理IIIは本当に男子の合格率が高いのか?」で有意差なしとの計算があったのでそう思っていたのですが、そもそもこれは「男女の合格率に差はない」という帰無仮説に対するものです。

しかし上野氏は女子の受験生の方が成績が良いはずだと主張しているので、本来は女子の方が合格率が高いはずなのです。そして男女の成績の差がどれだけあるかわからないのでどれだけなら有意差ありと言えるのかわかりません。

また、東大理3の入試は2018年度から面接が導入されていて、それ以前とはデータの連続性がありません。1.03 というのは2013年度から2018年度までの直近(当時)6年分のデータから算出したもので連続性のないデータが混じっています。

ということで有意差あるなしは簡単には言えなさそうです。不正がある、と言うには有意差があることを立証すべきですが、上野氏は「不正がなくても合格率は女子が不利になる」という話をしようとしているので、本来は必ずしもその必要はありません。

しかし、実際には「不正がなくても合格率は女子が不利になる」の論証に失敗していて、実質「不正がなければ合格率は男女逆転する」という話になってしまっているため、結果的に根拠のない話をしている、という評価になってしまうのだと思います。

*1:ただし、東大理3の合格率の男女比が 1.03 というのは統計的誤差の範囲ではないか?という指摘はあります。しかし上野氏は有意水準を前もって設定していないのでなんとも言えません。有意水準を設定していない=統計的誤差を考慮していないこと、一般的には有意でないとされるのではないかということ、については批判されてしかるべきですが、その点については本エントリでは割愛します。

*2:その場合、論理的には問題はなくても文章構成としては A が投げっぱなしになっていて不自然な構成と言わざるを得ませんが。

*3:例えば墨東公安委員会さんのこの解釈 https://twitter.com/bokukoui/status/1382946024600137731 もそうなっていると思います。

*4:その傍証として、東大の女子比率は博士課程までは増えていくのに研究職になると地位が上がる毎に減っていくことを挙げています。

フィンランド鉄道(VR)の車椅子対応の話とか

はてな匿名ダイアリー(以下慣例にならい個々の日記及びその筆者を「増田」と呼びます)にあったフィンランド鉄道(VR)の車椅子対応の件ですが、

  • 介助が必要な場合はカスタマーサービスに36時間前までに電話で介助スタッフ予約
  • 乗車列車やどんなサポートが必要か事前に伝える
  • サービスの利用は無料

https://www.vr.fi/en/facilities-and-services/accessible-train-travel
はてサが大好きな福祉先進国北欧の車イス対応についてのメモ — https://anond.hatelabo.jp/20210409174921

これについてはてなブックマークコメントで「36時間前までじゃなくて早くて36時間前、遅くて2時間前までに、って書いてない?」と書いたところ、いや、Assistance service at stations には36時間前までに予約って書いてある、との反論があったので補足します。

僕が言ってるのは Commuter traffic ramp service の章にある ramp service のことで、車両とホームの段差にスロープを付けるサービスです。ここには「You can order the service 36 hours before the trip at the earliest and 2 hours before the trip at the latest.」とあり、遅くとも2時間前に連絡を取ることになっています。

で、増田が言ってるのは Assistance service at stations の章にある「The assistance service should be booked 36 hours before the departure time of the train.」のことだと思うのですが、この assistance service というのは、一人で駅を使ったり電車を乗り降りしたりできない人をエスコートするサービスだと思います。

この章の Assistance in boarding the train 以降の節を見ると、出発駅では乗車する車両の席まで連れて行ってくれ、乗り換えでは正しい車両まで案内してくれ、到着駅ではタクシー乗り場やバス停まで案内してくれるようです。また、章の冒頭にはサービスの対象となる人として、高齢者、車椅子使用者、視覚障害者、聴覚障害者、自閉症スペクトラムの人、記憶障害のある人が挙げられています。

増田の「車椅子対応」が何を差すか明確ではありませんが、おそらく伊是名夏子氏の乗車拒否の文脈での話だと思います。伊是名氏は段差さえなければ電動車椅子を操縦して一人で移動でき、段差の解消または迂回を求めているので assistance service が提供するサービスは求めていません。なので、ramp service の方が求めるものに近いのではないでしょうか。

ただし、どちらのサービスも「車椅子を階段で持ち上げて運搬する」というサービスは想定していないと思います。

ramp service は車両とホームの段差にスロープを付けるだけだし、assistance service は「Please note that for security reasons, the assistant cannot lift the customer to or from a wheelchair.」とあって車椅子から利用者を降ろしたり乗せたりしませんし、安全上の理由でそうしないと言うくらいなので車椅子に乗せたまま階段上を運搬するなんてこともしないでしょう。

そもそも駅のアクセシビリティの状況はどうなのかということですが、Tips for a smooth train trip の章には「Most railway stations are primarily accessible.」「Some stations have lifts to make transfers easier.」とあり、駅構内は何らかの形で車椅子での移動が可能と思われます。が、全ての駅でそうなのかは不明です。

最後に伊是名氏の要求についての僕の見解を。

80kg*1電動車椅子を4人がかりとはいえ手で運ぶのはそこそこリスクはあり*2 仮に熱海駅長が断っていても責められるものではないと思っています。

この件は小田原駅の担当者が代替ルートを確保した上で案内する(案内できる体制にしておく)のが適切だったと思います。ただし常に代替ルートが使えるわけではないし、将来エレベーターを設置したとしても事故や災害等でどうしても電動車椅子を階段で運搬する必要も出てくるでしょうから、「モッコ」*3 なり「電ネコ」*4 なりを使って少人数で少しでも安全に運べる準備はあったほうがいいのではないでしょうか。

また、伊是名氏がクレーマーだとか過去の発言等から性格悪いとか思想的にどうなのかみたいなことも言われていますが、公共交通機関というのは性格悪かろうが過激思想の持ち主だろうがなんなら人殺しの過去がある人でさえ乗車拒否なんてしませんししてはいけません。仮に氏への批判が正当なものだったとしても*5そのことと公共交通機関バリアフリーがどうあるべきかというのは別の話です。

追記: 増田は「介助が必要な場合」って書いてるのでそれだけ見ると間違いではないのだけど、assistance service の「assistance 介助」というのは施設上の(いわゆる)バリアフリーでないところを助けるということではなく、バリアフリーの施設であっても利用に支障がある人を助けるためのものだと思うので、文脈上は違う話なのでは、ということです。

*1:100kg説、120kg説などあったが、本人はJ-CASTの取材に80kgと答えている。ブログの写真を見るとおそらく当日使用の車椅子は、さいとう工房のレルミニシリーズ(最軽量のモデルが 83kg) https://saitokobo.com/product/ と思われる。

*2:骨しゃぶりさんのブログ「1台の電動車椅子を持ち運ぶのに何人の駅員が必要か? ただし労働基準法に従うものとする」でも検討されているように安全性の点ではギリギリの条件。

*3:肩ベルトで支えて二人で重量物を運ぶための道具。運送業者は100kg以上の家具やコピー機などをこれで運ぶ。

*4:電動で階段を昇降できる運搬車。100kg以上の荷物の階段での運搬を一人で行うことができる。参照: https://liftkar.net/

*5:個人的には不当なものが圧倒的に多いと思うが。

『はじめての動物倫理学』を読む前に

田上孝一『はじめての動物倫理学』をこれから読もうと思うのだけど、その前に、現時点で動物倫理についてどう考えているか、を記録しておこうと思う。

はじめての動物倫理学 (集英社新書)

はじめての動物倫理学 (集英社新書)

そもそも動物倫理について曖昧にしか知らないからこそ「はじめての」と銘打つ本書を読むことにしたので、以下に述べることは概ね的はずれな話でしかないかと思うが、読後に考え方がどう変わったか、変わらなかったか、というのを自分で確認できるように。

特に誰かを説得したりするためのものではないので、箇条書き形式で思うがままに書き連ねることにする。

  • そもそもなぜ他人を苦しめたり傷つけたり殺したりしてはいけないのか?
    • いつ誰に苦しめられるかわからない状況で生きていくのは辛すぎるから互いに傷つけ合わない約束として「他人に苦痛を与えない」という倫理が必要とされた、と考えている。
      • 「他人」の範囲は最初は共同体のメンバーに限られていたが共同体間の相互依存が進むにつれ、人間全体に広げる必要が出てきたのではないか。
      • 相互に交わされる約束なので約束を理解し約束を守る能力と意志のない者は対象外。
        • それだと子供や知的障害者などはどうなるのか?
          • 子供については誰もが最初は子供なのだから保護しないわけにはいかない。
            • とはいえ母体の命に関わらない場合でも人工妊娠中絶を認めている以上、胎児レベルになると対等な「人間」として扱っていないのではないか。
              • 動物倫理を支持する人は人工妊娠中絶についてどう考えているのだろう?支持できないという立場にならざるを得ないような…
          • 障害者については、回復する可能性があるというのと、親族等がその人を仲間とみなしていることを尊重するという意味で保護すべきではないか。
            • それだと身寄りもなく回復の見込みもない障害者を傷つけない根拠がないのでは?
              • ストレートには保護する必然性を根拠付けられないかもしれない。
              • 結局「かわいそう」を根拠にするしかないのかも。
      • そういう功利的な理由だと、反撃しない相手に対しては約束を守る理由がなくなるのでは?
        • 個々の事情に関わらず普遍的に守られる約束でなければ、約束が守られると予期することで得られる安心が得られないため、約束を守らない者に対して第三者が制裁を加える動機があり、制裁を回避するという理由で約束が守られるであろう。
  • 上のような考え方だと、約束を交わせない相手である動物を人間と同様に扱う理由はない。
    • 「かわいそう」を根拠にした保護はありうるがそれは動物側の権利ではなく、あくまで人間側の心の平安を保護するもの。
      • ただし、人間に懐き、躾が可能な動物についてはある程度「約束」が成立していると見るべきかもしれない。
  • 痛覚の有無を「苦痛を与えない」対象を識別する根拠とするのはよくわからない。
    • そもそも我々が特定の属性を持つ人たちを差別していた/いるのは、その人たちが苦痛を感じないと思っていたからではない。その人たちの苦痛に共感しない、共感しなくてよいと思っていた/いるから。

まあ倫理学っぽい考え方ではないというか、倫理のために人があるのではなく人のために倫理がある、ぐらいの考え方なので、単に僕が倫理学を全否定する人でなしでした、ってだけの話かもしれない。

それにしても気が重い。読むと肉が食べられなくなるのではないか。それは僕にとって生きる意味の少なからぬ部分を棄損することを意味するし、それ以上に自分の過去の人生を取り返しのつかない罪に塗れたものとして全否定することになるのではないか。そんなことになったら正直死んだほうがマシと思わざるを得ないのではないか。

死にたくないので読まない、という選択もあるにはあるけれど、こういう時代の流れでは目を閉じ耳を塞ぎ続けるのも限界があるし。でも辛すぎて最後まで読めない、ということはあるかも。

包摂の条件 ― 『ヒーリングっど♥プリキュア』第42話における「のどかの選択」について

2021年1月31日放送の『ヒーリングっど♥プリキュア』第42話「のどかの選択!守らなきゃいけないもの」が衝撃的でした。僕はプリキュアシリーズは初代から今まで全話視聴していますが、今までにないパターンで強烈なメッセージを突きつけてきたな、と思いました。

今までアニメを見てきて(といっても年に数作程度しか見ていませんが)ここまで衝撃を受けたことは滅多にないことです。『新世紀エヴァンゲリオン劇場版 Air/まごころを、君に』(通称「夏エヴァ」)のラスト以来ではないでしょうか。

以下ネタバレになります。










第42話は主人公である花寺のどか(= キュアグレース)が、元敵組織の幹部で組織に命を狙われてのどかに助けを求めてきたダルイゼンを拒絶し、倒すという話でした。

ダルイゼンとのどかは因縁の深い関係で、幼い頃のどかを苦しめた原因不明の病気の本体はダルイゼンでした。敵組織ビョーゲンズの王キングビョーゲンの力で自我が芽生えたダルイゼンはのどかの体から出てきて人間の姿になり、ビョーゲンズの一員として地球を蝕む活動を始めます。

プリキュアとなってビョーゲンズと戦う(地球をお手当する)のどかは、やがてこの事実を知り、ダルイゼンを産み出してしまった自分に責任を感じ、自らの手でダルイゼンを倒すことを決意していたのですが、そこにダルイゼンが助けを求めてきます。

第41話でキングビョーゲンに同化されそうになったダルイゼンは脱走します。同化されれば自我を失い自分が自分でなくなるからです。追撃で傷つきボロボロになったダルイゼンはのどかの前に現れます。

ダルイゼン: みつけた… いいからよこせよその体!
のどか(キュアグレース): もしかして、キングビョーゲンにやられたの?グアイワルを取り込んだみたいに、また仲間を…
ダルイゼン: 助けて…くれ… このままじゃ、俺は俺じゃなくなる… 消えてなくなる… たのむ、キュアグレース、お前の中に俺を匿ってくれ…
ラビリン: 何言ってるラビ!
ダルイゼン: お前は俺を育てた宿主だ。お前の中ならきっとこの傷は癒える。キングビョーゲンに見つからず回復できる。たのむ、助けてくれ、キュアグレース…

激しく動揺するのどかは、助けを求めて伸ばしたダルイゼンの手を思わず振り払って背を向けて逃げ出します。そんなのどかをダルイゼンは責めます。

ダルイゼン: お前、俺に言ったよな!「自分さえよければいいのか」って!結局お前も同じじゃん!

第42話で、パートナーのラビリンがのどかの真意を確かめようとします。のどかは本当はダルイゼンを助けたかったのではなかったのか、地球を守るという使命を帯びたラビリンのために我慢したのではないか、と。しかしのどかはそうではないと言います。

のどか: ちがう、そんなことじゃないの… わたし、そんな優しい子じゃない…
ラビリン: のどか…
のどか: あの時、わたし、自分のことしか考えてなかった。だって、辛くて、怖かったの… 強い気持ちでいなきゃ負けちゃうから、笑っていないと自分が潰れちゃうから、だからすっごく頑張った。今の私を作ってる大事な経験だったと思ってる。でも、それでも、叶うことならもう二度と、あんな苦しい思い、もう、したくないよ…
ラビリン: のどか… ごめんラビ。ラビリンまだまだのどかのことわかってなかったラビ。ダメラビね…
のどか: ううん
ラビリン: のどかは、ダルイゼンを助けたいラビ?
のどか: そうした方が、よかったんだと思う…
ラビリン: そうじゃないラビ。のどかの気持ちを聞いているラビ。
のどか: 無理。わたし、どうしても嫌!嫌なの!
ラビリン: だったら、助けなくていいラビ!悩む必要もないラビ!
のどか: えっ?
ラビリン: のどかが自分を犠牲にしなきゃいけないなんて、そんな義理も責任もないラビ。のどかは、十分頑張ってくれてるラビ。それは、ラビリンたちがよーく知っているラビ。もし、のどかに何か言ってくるやつがいたら、ラビリンがぶっ飛ばしてやるラビ!
のどか: ラビリン… (涙)
ラビリン: だからのどかは、自分の気持も、体も、大事にしていいラビ。のどかが苦しまなきゃいけない理由はひとっつもないラビ!
のどか: うん、ありがとう…

笑顔を取り戻すのどかですが、ダルイゼンとの決戦では怪物化した彼にもう一歩踏み出した自分の気持を突きつけます(以下、ダルイゼンとラビリンとのどか(キュアグレース)のやりとりのみ抜粋)。

ダルイゼン: 助けてくれ… こんな、こんなのは俺じゃない!
ラビリン: ダルイゼン!グレースのやさしさにつけいるのはやめるラビ!
ダルイゼン: キュアグレース、お前だけが頼りなんだ。お前の中に!
のどか(キュアグレース): そしたら私はどうなるの!?いつまで!?あなたが元気になったらどうするの?あなたはわたしたちを、地球を、二度と苦しめないの!?わたしはやっぱり、あなたを助ける気にはなれない!
ダルイゼン: ウワーッ!
のどか(キュアグレース): ダルイゼン、あなたのせいでわたしがどれだけ苦しかったか、あなたは全然わかってない!わかってたら地球を、たくさんの命を蝕んで笑ったりしない!都合のいい時だけ私を利用しないで!わたしはあなたの道具じゃない!私の体も!心も!全部、わたしのものなんだから!

そして浄化技プリキュア・ファイナル・ヒーリングっどシャワーでとどめを刺します。

ダルイゼン: 俺だって、俺の体も、心だって… うわーっ!!

多くの人がこれを見て連想するのは「復縁を迫るクズ男を振り切る元カノ」ですよね。ダルイゼンが体が目当てだったところも… プリキュアは主に幼児から小学校低学年までの女児をターゲットにした作品ですが、将来クズ男に苦しめられた時に思い出して欲しい、という思いを込めたストーリーなのでしょうか。

僕はこれを見て2019年にプリキュアファン界隈で起こった性暴力事件のことを思い出しました。プリキュアファンの少女にプリキュアファン仲間の成人男性が交際を迫り性的な接触を強行し、耐えきれなくなった少女が別れ話を切り出すと「別れるなら死ぬ」と脅してきた、というものです。*1

警察の介入で縁は切ったものの、自分のせいで彼を死なせてしまったと思い込み、長い間罪悪感に苛まれていた被害者ですが、「のどかの選択」はこのような人にこそ届けたいメッセージだったのではないかと思います。

「わたしはあなたの道具じゃない」「私の体も心も全部わたしのもの」という言葉は、フェミニズム理論の概念の一つ「性的モノ化(sexual objectification)」を連想させる言葉です。女性は「モノ」ではない、すなわち、誰かの欲望を満たすための道具ではなく自律した存在であり体も心も自分自身のもので他人がそれを侵す権利はない、という主張です。

しかし作劇上は「魅力的な敵キャラ」として育ててきたダルイゼンを、最後の最後で「よく考えたらこいつクズ男じゃん!」という方向で決着させるのは、なかなかできないことですよね。

ということで、のどかの選択は間違いなく正しいのですが、不安にさせる要素があるのも事実です。プリキュアは「愛」の力で「悪」をも最終的には包摂する存在ではなかったのか?

プリキュアシリーズでは因縁の深い敵幹部がプリキュアに感化され転向して味方になったり、そうでなくとも何らかの救いがあることが多く、「敵」(そもそも敵という言葉も避ける傾向がありましたが)を絶対悪とせず理解可能な存在として相対化する傾向がありました。

そもそもプリキュア「正義の味方」ではないのです。あくまで自分たちの日常を守るために戦うのです。それは2004年の初代プリキュアのエンディングテーマ「ゲッチュウ!らぶらぶぅ?!」の歌詞に端的にあらわれています。


地球のため みんなのため それもいいけど忘れちゃいけないこと あるんじゃない?!の!

もちろん「のどかの選択」もこの線で理解することは可能です。善悪で言えば「悪」にすら救済の手を差し伸べることが「善」なのですが、のどかの平和な日常を守るためにはそれはできません。のどかは女神でも天使でもなく一人の中学生なのです。無限の愛も自己犠牲も期待していい相手ではありません。

しかし、だからといって単純に自分たちの都合だけで「悪」を切り捨てていいのでしょうか?ラビリンの言うように「義理も責任もない」のは事実だとしても、ならば「自分さえよければいいいのか」などと非難したのは間違いだったのでしょうか?

ダルイゼンは絶対悪だから他者のうちには勘定しない、他者への配慮を訴える「自分さえよければいいいのか」は適用されない、という考え方もあり得ます。しかし、のどかはそのような立場には立っていないように見えます。

むしろのどかは一貫してダルイゼンを「対等な他者」として見ているのではないでしょうか。本来ダルイゼンは人間ではないのでそれこそ人間の都合なんて考える義理も責任もないのです。なのにのどかは「自分さえよければいいいの?」「私がどれだけ苦しかったかあなたは分かってない」とダルイゼンを非難します。

これは相手を対等な関係であるべき他者だと思っているからこそ出てくる言葉です。つまりこれは「対等な関係を拒んでいるのはあなたの方だ」という非難なのです。

これもまた一つの「包摂」の物語なのではないでしょうか。包摂というのは同じ社会の一員として共に生きる関係を築くことです。一方的に救済するのではなく相手との対等な関係が前提になります。無条件の「赦し」は相手を対等な存在として認めていないということでもあり、それを包摂と言えるのか疑問が残ります。

後に相手が改心することを期待して先に大きな愛で抱擁するというやり方も間違いではないでしょう。でも、子供たちにまず必要なのは「自分の幸せを自分で守ること」です。対等な関係の中で「助け合い支え合うこと」がその次で、一方的に他人を救済するというのは大きな力を手にした人の責任と義務、すなわちノブレス・オブリージュです。

今までプリキュアは超越的な力を手にした存在として救済者の責務を負わされていた面がありました。しかし今期のプリキュアでは、プリキュアも、そしてプリキュアに憧れる子供たちも、本来は一人の人間だということを強調したのではないでしょうか。そして、高貴でありたいと願うその心につけいる邪悪が存在するということも。

もちろん「自分を大事にして自分を犠牲にしない」は一歩間違えば利己主義や自己責任主義に陥る危険性もあります。そうさせないためにも作中ではのどかを過剰なくらいに「いい子」として描いていたのかもしれません。

正直今まで僕はのどかの過剰なほどの優しさや気遣いに、子供にここまで求めるのは酷なのでは?とさえ思っていました。理想像として描いているにしても「いい子」過ぎると。しかし「のどかの選択」を見てその必然性はあったのだと思いました。

さて、第42話でプリキュアに浄化されたダルイゼンは完全には消滅せず、メガパーツで強化する前の初期の姿に戻っただけでした。そしてなすすべもなくキングビョーゲンに同化されてしまいます。しかし本当にダルイゼンは消えてしまったのでしょうか?

あれだけ自我の強いダルイゼンですからもしかしたら… ダルイゼンの最後の言葉「俺だって、俺の体も、心だって」が気になります。これは単なる自己愛の表現なのでしょうか。それとものどかも自分も同じだ、対等なんだ、という気付きの芽生えなのでしょうか。

*1:実際には死んでいません。それどころかその後も複数の少女を相手に同様のことを繰り返しています。