y の増加量は x の増加量の何倍

まとめ

記事がとても長くなったので、最初にまとめを示しておく。

中学校の数学で、

  • 1次関数の「変化の割合」の学習の箇所に、「y の増加量は x の増加量の何倍」なる表現は必要か否か

利点よりも誤解を生む弊害のほうが大きいので不要、むしろないほうが望ましいというのが私の考え。

  • 「単位を外に付ければ x や y は「値」のみなので無次元」的な概念の是非

1点めを掘り下げているうちに明らかになった、中学数学全体に及ぶような大きな問題。そのためここで述べてもどうにもならないような気もするが、生徒たちは先(高校や大学、実社会)にも横(他教科、特に理科)にも進んでいかなければならないことを思えば、どちらにもつながらないこのような局所的な概念はないほうがいいというのが私の考え。

入試問題

きっかけは、中学3年生向けのワークブック(学校で全員が買わされるやつ)をたまたま見たことだった(私がそれを見てこの記事を書いているのは2023年11月)。そこに掲載されていた問題の出典は、京都府の高校入試問題(平成31年度 京都府公立高等学校入学者選抜 中期選抜学力検査 検査3「数学」の大問4)であることがわかった。

【4】 自転車に乗っている人がブレーキをかけるとき、ブレーキがきき始めてから自転車が止まるまでに走った距離を制動距離といい、この制動距離は速さの2乗に比例することが知られている。太郎さんの乗った自転車が秒速 2 m で走るときの制動距離は 0.5 m であった。
(1) 太郎さんの乗った自転車が秒速 x m で走るときの制動距離を y m とする。y を x の式で表せ。また、x が5から7まで変化するとき、y の増加量は x の増加量の何倍か求めよ。

解答欄は2つの枠があり、1つめには「y =    」が印刷されていてその後の空欄を埋めるようになっており、2つめには「    倍」が印刷されていてその前の空欄を埋めるようになっている。

何がおかしいか

私がおかしいと感じるのは問題文後半の「◯倍」を答えさせる部分だ。

y の増加量は長さの次元を持つ。x の増加量は速さの次元を持つ。問題文では「x が5から7まで変化するとき」と、あたかも無次元量のような表記になっているが、問題文前半から x、y がそれぞれ速さ、長さの次元であることは明らかである。そもそも次元の異なる2つの物理量の倍率を問うこと自体がナンセンスである。たとえるならば「5 kg は 1 m の何倍か」という表現と同等であり、意味をなしていない。

出題者は「x の増加量に対する y の増加量はいくらか」と問うべきところを、単なる日本語の間違いで「y の増加量は x の増加量の何倍か」と書いてしまったのだろうか。それを指摘することは揚げ足取りに過ぎないのだろうか。

出題者の意図

その旨を問い合わせたところ、京都府教育庁指導部高校教育課より回答があった。

本問については、まず自転車の速さをx(m/秒)、制動距離をy(m)として、xとyの関係を式で表現させています。そのxとyの関係式について、xの増加量とyの増加量を比較させる問題です。

この、xの増加量とyの増加量を比べることについて、単位の異なる2つの物理量を比較させているというご指摘ですが、x、yのそれぞれの増加量を比べているものであって、単位の異なる2つの物理量を比べているものではありません。

(京都府教育庁指導部高校教育課)

回答の内容は、私には意味不明としか言いようがない。

「物理量」「次元」という言葉がわかりにくいのであれば、「ある単位で表される値」とでも読み換えてもらっていい。それでも私の指摘するところは変わらない。

x が [m/s] で表される値ならば、「x の増加量」もまた [m/s] で表される値である。同様に、「y の増加量」も [m] で表される値である。単位の異なる2つの値を「◯倍」と表現することは、日本語ではあり得ない。

もし問題文が「x の増加量に対する y の増加量はいくらか。」または「変化の割合はいくらか。」であれば、変化の割合は有次元でもかまわないので「3/2」と解答できるが、問いが「何倍か」で解答用紙の欄に「倍」と印刷されて限定されているのであれば、答えるべき数値は無次元量でなければならず、この問題の場合は解答不能である。

問題文では「x が5から7まで」と、この箇所にはあえて単位を書かずあたかも無次元であるかのような表現になっている。しかし、問題の前段で求める係数 1/8 は、x や y がその次元(単位)だからこそその値になる。x の単位を [m/s] としたときのものであって、単位が異なれば値は変わる。試しに速さを [km/h] にして係数を求め直してみれば明らかだ。x や y の値は単位と切り離されておらず、式に現れる係数もまた同様である。したがって正答例 3/2 は、明らかに [m] と [m/s] の比であって無次元ではなく、「倍」と言うことができない。

この回答を見ると出題者は単に言葉「倍」の使い方を間違えたのではなく、実は確信的に、「xの増加量」を本当に無次元量だと思いこんで、「倍」を使ったのかもしれない。

私立高校入試問題

ここで補足的に、別の高校の対応について記しておく。

京都府に問い合わせて回答を待つ間にこちらでいろいろ調べているうちに、本件とほぼ同じ問題が2021年度にある私立高校入試で出題されていたことを発見した。(ここまでそっくりの問題を出題することの是非は、私は第三者であり当事者間の許諾などを関知していないため、ここでは触れない。)

その高校にも同様の問い合わせをしたところ数日後に回答があり、曰く、「出題ミス」と判断し過去問題を掲載していた箇所にその旨を掲示する、とのことであった。

教科書の記述

さて、京都府教育庁指導部高校教育課からの回答には続きがあって、

実際に、当時の教科書においても、次のような記載があります(東京書籍『新編新しい数学2』P58)。

「1次関数の値の変化についてで「電気ポットでお湯を沸かすとき、熱し始めてからx分後の水の温度をy℃とすると、y=5x+20となることがわかりました。
  xの値が4から6まで増加したとき
  xの増加量は 6−4=2  yの増加量は (5×6+20)−(5×4+20)=10
 yの増加量はxの増加量の5倍になっている。
すなわち (yの増加量)/(xの増加量)=5
xの増加量に対するyの増加量の割合を変化の割合という。」

以上のことから、解答不能とは考えておらず、出題ミスとも考えておりません。

(京都府教育庁指導部高校教育課)
当時の教科書(平成27年検定済「新編 新しい数学2」東京書籍)

と書かれていた。

入試問題では明らかに「速さ毎秒 x m、距離 y m」と記しているので「y の増加量は x の増加量の何倍」という表現は誤りである。それに対して教科書では、ページの上段の「Q」と下段の「例1」のつながりをどの程度と見るかで判断は分かれるだろう。「例1」と区切っていることから、ここは具体的事象から切り離して数学的記述のみと見ることもできる。そう見れば、「y の増加量は x の増加量の5倍」という表現も一概に誤りとは言えない。

しかし、上段にある式をそのまま使っているこのページの構成からして、大半の読者は、上段の具体的事象について述べていると理解するのではないか。実際、入試問題作成者までがこの表現に影響されて、「速さ毎秒 x m、距離 y m」のように具体的な単位で表される値にまで「何倍」を用いてしまったではないか。

新版の教科書

令和2年検定済「新しい数学2」東京書籍

ちなみに2023年時点の現行の教科書(令和2年検定済「新しい数学2」東京書籍)では、具体的事象が消え、数学的な記述のみに変更になっている。確かにこのページだけ見れば「y の増加量は x の増加量の◯倍」という表現も誤りとは言えない。

しかし、このページ内での矛盾はなくなり旧版よりましになったとは言え、前後には具体的事象の例題・練習問題が多くある。また、1次関数は特に日常的事象や他教科(特に理科)の内容とも密接に関わる。x や y が具体的な単位で表される値になれば意味をなさない「y の増加量は x の増加量の◯倍」という表現は避けるべきであろう。

「変化の割合」に誘導するステップとして、「y の増加量は x の増加量の◯倍」の表現を置くことが生徒にとって助けになるとの判断があったのかもしれない。しかし、検定済7点の教科書を見比べてみると、これを抜きにしても変化の割合を丁寧に教えているものも存在する。

生徒だけでなく教師や入試問題作成者にすら上述のような誤解を与える弊害があることを考慮すると、この節に「y の増加量は x の増加量の◯倍」という表現は用いないほうが望ましい。

教科書出版社の回答

そこで東京書籍に問い合わせてみたところ、次のような回答があった。

数学の世界で関数を考察しておりますので、「y の増加量は x の増加量の◯倍」の表現は問題ないと存じます。

また、数学の世界に落とし込むときに混乱が生じないよう、文字のおき方も次元を持たない表現にしています。例えば、平成27年検定版の58ページのQでは
  「x分後の水の温度をy℃とすると,」
と表現してあります。次元を含んだものを計算することはできないため、無次元になるように定義しております。

(東京書籍 担当部門)

私の知る「無次元」は上述のとおりなのでやや面食らったが、どうやら中学数学ではこのように解釈するらしい。どうにか意図を読み取ると、文字とは別に単位を書いておけば x や y は無次元ということか。

この理屈でいくと、「x分後の水の温度をy℃とする。x+y はいくらか。」といった設問も可能ということになってしまう。ここまで露骨なものは実際にはないだろうが、極端な例を挙げている。

平成27年検定版58ページは、はじめに具体的事象が例示された後に式が示されその後に「何倍」とあるから、多少複雑になっているとは言え、ここに挙げた極端な設問と構造的には同じだ。やはり実感としてはおかしいと言わざるを得ない。

私のような者は「x分後の水の温度をy℃とすると,」を「x とは時間を分で測った量であり、y とは温度を摂氏で測った量であると定義する」という意味に理解する。むしろ無次元とはまったく逆である。私も当然、中学校の数学を通過した者だが、いつから現在のような感覚になったかは自覚していない。いずれにしろ、学校数学は世間一般の感覚からずれているように思う。

抽象化と具象化

「倍」という表現からいったん離れて、もう少し低学年で学習するであろうところに話を移してみる。

小学校低学年あたりの算数では「抽象化」の理解に力を注いでいるだろう。たとえば

(a) りんご5個とりんご2個、合わせていくつ。
(b) トラック5台とバス2台、合わせていくつ。
...

から、抽象化した 5 + 2 = 7 を理解させるような。ここまでできたら、「6 + 3 = 9 からお話を作ってみましょう。」が理解度を測る一つの方法だろう。

(a') バナナ6本とバナナ3本。合わせていくつ。
(b') コミック6冊と絵本3冊。合わせていくつ。

もし中途半端な理解であれば、

(x) 重さ 6 kg と長さ 3 m。合わせていくつ。

という誤ったお話(「具象例」)を作ってしまうかもしれない。

いろいろ検索して回っているうちに次のような論文を見つけた。

現行の算数科では概念の把握には助数詞または単位をつけた数 (名数) を考えるが,これを式で表現するときには無名数を用いることがほとんど」で、「計算の段階では単位・助数詞を考えず,計算結果が出たところでそれに対して単位助数詞を与えるというような操作が一般的」と述べ、「中学校以上になると始めから単位を表わさない量の表現もあ」り、そこでは「単位のついた形で量としてその概念を会得したのち,さらにその抽象化として捉える必要がある。」としている。

これらを「教育の段階として計算の過程だけを取り上げて教えることは当然のことだとは考える」としながらも、「が,その結果,たとえば
例: 3 m と 10 cm を加えて 13      5 m^2 と 3 m を加えて 8 m
になってしまうようなことに違和感を感じないのは大きな問題である。
」と述べ、「現象を抽象的に見て数値として表現するという,数概念の根幹が分かっていない」と断じている。

最後に「出来るだけ無名数を使わない方が良いのではないか。」「数学の基本的な道具立てを改めて認識し直すことが大切なのではないか」と結論づけている。

最初に取り上げた入試問題、それを誘発したこの教科書の記述はまさに「違和感を感じないのは大きな問題」であり、「数概念の根幹が分かっていない」と言えるのではないだろうか。

「◯倍」は必要か

東京書籍からの回答に戻る。

xの増加量やyの増加量のように、2つの数量の変化に着目する見方ができる生徒でも、2つの数量を対応させる見方に難しさを覚えることは多くあります。そこで、対応の見方を養うために「y の増加量は x の増加量の◯倍」といった文章を入れております。

(東京書籍 担当部門)

代替表現がないのであればまだしも、

  • x が 2倍,3倍,4倍,…になると y はどうなるか (ここでの「倍」は x どうしなので用法に問題はない)
  • x がいくつ増えると y はいくつ増えるか
  • x が1ずつ増えると y はいくつずつ増えるか

等の表現で、「2つの数量を対応させる見方」を養えるのではないか。

「y の増加量は x の増加量の◯倍」でしか表現できない何かがあるのだろうか。この表現による効果がゼロとは言わない。いくらかはあるだろう。しかしこの表現による副作用が

しかしながら、ご指摘のように異なる物理量について「倍」という表現を用いているように捉える先生がいらっしゃるかと存じます。

(東京書籍 担当部門)

であれば、しかもそれが入試問題になってしまい、さらには学校指定購入のワークブックに収載されてしまっているとなれば、もはや利点を大きく上回って有害とすら言えるのではないか。教師が誤解するほどであれば生徒はなおさらである。

たとえば、これは中学生の投稿する掲示板に見られる例である。

「変化の割合」を正しく理解しているにもかかわらず「何倍」に惑わされて混乱している様子が伺える。私に言わせればこの質問者らの感覚のほうがまともだ。

上に挙げた代替表現は、日常の具体的事象と結びつけても何ら困らない。「時間 x が 2倍,3倍,4倍,…になると 温度 y は」「時間 x がいくつ増えると 温度 y は」のように。ところが「温度 y の増加量は 時間 x の増加量の◯倍」は日本語として破綻している。数学的表現の限りでは問題ないことは私も理解するが、日常の具体的事象と結びつけたとたんに破綻する表現をあえて持ち込むことは特に利点がない以上、不要と考える。

結論

東京書籍からの回答を、先ほどと重複して引用する。

しかしながら、ご指摘のように異なる物理量について「倍」という表現を用いているように捉える先生がいらっしゃるかと存じます。

次回、教師用指導書等を編集する際に、上記のことを検討したいと存じます。

(東京書籍 担当部門)

「京都の入試問題は不適切」と単刀直入には言っていないまでも、先生(問題作成者)の誤読があると言っているように読めるが、どうだろうか。

教師用指導書等で解説されるとしたら、それはそれでいいことには違いない。ないよりははるかにましである。しかし、教科書の読者の圧倒的多数は生徒であり、生徒が教師用指導書を見ることはほぼない。生徒が、教科書だけでは誤解してしまう可能性のある記述のみを与えられ、その注釈を与えられないのは不当だろう。(とは言え、その注釈までも教科書に載せるのは現実的でないことは理解する。)

いくらかの利点があるとしてもそれを上回る弊害があるのであれば、むしろこの表現「y の増加量は x の増加量の何倍」は避けるべきだと考える。

余録

ここまでに引用したものの他にいくつかの回答を得たので、それをここに記しておく。

ひとつは、冒頭に示したワークブックの出版社。

確かに「制動距離は秒速の何倍か」のような出題だと明らかに誤りになりますが,問題文中に「秒速xmで走るときの制動距離をymとする」とありますので,xとyは数として解釈して計算しております。

このような表記と考え方(単位をxやyの外につけて,xとyの値にのみ着目する考え)は,中学数学の教科書では慣例的に使われており,出題として問題ないと判断して掲載いたしました。

(正進社 中学編集部数学担当)

もうひとつは、別の教科書出版社。こちらの教科書の当該箇所の記述は平成27検定版と令和2検定版のどちらも、東京書籍令和2検定版とほぼ同じで、具体的事象の例示はなく数学的記述のみで説明が進み、その中に「y の増加量は x の増加量の何倍」の表現がある(数学的記述のみの限りでは問題ないことは私も理解する)。そのためか、問い合わせの真意を汲み取ってもらえなかったところがある。

関数の学習では,身のまわりの数量をxやyで表すことがよくあります。xやyで表した時点で単位についての情報はなくなり,xやyは「値」を表していると考えております。

中学校でも関数を扱う際には,「x時間」「ycm」などとして,量を表す単位は文字には含めておらず,xの増加量,yの増加量はその単位で定められた変数がとる「値」であると考えております。

(啓林館 数学編集部)

こうして並べてみると、中学数学の世界には「単位を外に付ければ x や y は「値」のみなので無次元」的なことが共通認識としてあることがわかった。はじめに挙げた京都府からの回答も私には意味不明だったが、なるほどこういうことか。これはたいへんな驚きである。

さらにもうひとつは、東京書籍からの2通め。

単位や次元について強く意識されるのは、高等学校の物理で次元やSI単位系について学習する段階だと思われます。

中学校数学においては、数を対象として学習を行っておりますが、中学校理科や高等学校物理と考えが異なる点もございますので、次回改訂の際には、ご指摘いただいた点に意を払って議論を行いたく存じます。

(東京書籍 担当部門)

中学数学を教える側は一生そこに留まっていて困らないのかもしれないが、生徒たちはどんどん先にも横にも進まなければならない。ここでの認識にとらわれていたら、次元解析無次元化などまるで理解できなくなるのではないか。理解するためには中学で教わったことを捨てて発想を転換しなければならない。なぜ生徒たちがそんなことを強いられなければならないのか。中学数学のほうが「単位を外に付ければ x や y は無次元」のような、世間一般では通用しない珍妙な概念を捨てればいいのでないだろうか。

ウェブ会議でホワイトボード/PDF に手書き/Debian で使うタブレット

しばらく前(2023年に入ったころ)から、いわゆるウェブ会議を使って、リモートで家庭教師のようなこと(本当は違うのだが少しフェイクを入れるのでここではそういうことにしておく)をやっている。

こちらの環境は Debian で、そもそもプロプライエタリな道具はほぼ存在しないので、いろいろと探し回ることになった。

必要な道具は、まずウェブ会議の仕組みにホワイトボード機能となる。はじめは Jitsi を使っていたのだが、そのホワイトボード機能にバグのようなもの(数十分ほど書いたり消したりしているとハングアップしたようにそれ以上の書いたり消したりができなくなる)が出現して、Whereby を使うようになった。この切り替えはもう3か月ほど前なので、現在(2023年9月末)ではもう解決しているかもしれない。

Whereby は2人(1対1)で使う分には時間無制限なので、ここでの目的では困らない。Whereby ではホワイトボードとして外部サービスの Miro の画面を共有するようになっており、この使い方では Miro にアカウントを作る必要もない。

また、ホワイトボードに PDF を背景画像のように表示させてその上に書き込むように表示させる(家庭教師的に言えば、練習問題のプリントを表示させておいて解説を書き込む)ような使い方は、Jitsi のホワイトボードではできず、バグの有無に関わらず Whereby (Miro) のほうが優れている。

やや話はずれるが、ウェブ会議とは無関係に、既存のPDFに手書きで書き込むようなアプリケーションを探してみたら、Xournal++ というものが見つかった。これはこれでたいへん優れた道具だ。

さて、そのように手書きで書き込む際、マウス(と言っても自分はトラックボールだが)ではなかなか上手く書くことができないので、ペンタブレットを用意することにした。価格が手頃で Linux での実績がありそうな XPPen の Deco Fun XS を購入。お絵描きには小さすぎるかもしれないが、ここでの目的にはちょうどいい。

表面は思いの外ツルツルで、ペンが滑りすぎると感じるので、紙(たとえば便箋)をタブレットの作業エリアに貼り付けた。これで書き味がまさに紙に書いている感じになり、すこぶるよくなった。

XPPen には Linux 用のドライバが用意されている。これがなくても機器を接続するだけで十分使えるのだが、これによってさらに便利に使うことができる。たとえば、タブレットでの作業エリアを画面上の一部領域に設定できたり、ペンのボタンに機能を割り当てたりできるようになる。

ここでは「180度回転」と設定し、タブレットそのものを上下逆さまに置くことにした。このタブレットには作業エリア以外に幅 2cm ほどの部分があり、それを手前に持ってきてちょうどパームレスト(文字を書くので実際には小指の脇か)のように使うことで、より安定して字を書けるようになった。

【以下は、2023年9月末現在の自分の環境(Debian testing)での問題である。】

ところが、ここでは Debian の testing バージョン(安定バージョンではなく、ソフトウェア(パッケージ)が少しずつ新しいものに置き換わっていく)を使用しているため、ある時の Debian の更新以降この XP-Pen 提供のドライバ(この時点で XPPen-pentablet-3.2.3.230215-1.x86_64.deb)が動かなくなってしまった。提供されているドライバは当然にも 対応は Debian 安定版としか謳っていないので文句をいう筋合いではない。

XP-Pen 提供のドライバは実際には /usr/lib/pentablet/pentablet.sh というシェルスクリプト

#!/bin/sh
appname=`basename $0 | sed s,\.sh$,,`
dirname=`dirname $0`
tmp="${dirname#?}"
if [ "${dirname%$tmp}" != "/" ]; then
dirname=$PWD/$dirname
fi
LD_LIBRARY_PATH=$dirname/lib
export LD_LIBRARY_PATH
$dirname/$appname "$@"

を通じて、同じディレクトリの lib/ 以下のライブラリを使いつつ、同じディレクトリの pentablet というバイナリが起動されている。OSバージョンで困らないようにわざわざ同梱されている lib/ 以下のライブラリのどれかが逆に悪さして、このドライバが動かなくなっていた。このシェルスクリプトを飛ばして(LD_LIBRARY_PATHを設定しないようにして)直接 /usr/lib/pentablet/pentablet を起動すると、問題なく使えるようになった。

$ ldd /usr/lib/pentablet/pentablet

	linux-vdso.so.1 (0x00007fff87dc2000)
	libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f4e0b29d000)
	libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f4e0b15b000)
	libXtst.so.6 => /lib/x86_64-linux-gnu/libXtst.so.6 (0x00007f4e0b153000)
	libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007f4e0b13f000)
	libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f4e0b132000)
	libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f4e0b12b000)
	libQt5X11Extras.so.5 => /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 (0x00007f4e0b124000)
	libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f4e0aa00000)
	libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007f4e0a200000)
	libQt5Xml.so.5 => /lib/x86_64-linux-gnu/libQt5Xml.so.5 (0x00007f4e0b0e0000)
	libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 (0x00007f4e0a055000)
	libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f4e09a00000)
	libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f4e0a979000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4e0b0d9000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4e09600000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4e09f76000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4e0b0b5000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4e0941e000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f4e0a947000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4e0b2d2000)
	libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f4e0a91d000)
	libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f4e0a908000)
	libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f4e0a8fb000)
	libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f4e099ca000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4e099ab000)
	libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f4e09884000)
	libmd4c.so.0 => /lib/x86_64-linux-gnu/libmd4c.so.0 (0x00007f4e0a8e9000)
	libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f4e093cb000)
	libdouble-conversion.so.3 => /lib/x86_64-linux-gnu/libdouble-conversion.so.3 (0x00007f4e0986f000)
	libicui18n.so.72 => /lib/x86_64-linux-gnu/libicui18n.so.72 (0x00007f4e09000000)
	libicuuc.so.72 => /lib/x86_64-linux-gnu/libicuuc.so.72 (0x00007f4e08e02000)
	libpcre2-16.so.0 => /lib/x86_64-linux-gnu/libpcre2-16.so.0 (0x00007f4e0933d000)
	libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f4e08d41000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f4e08bfb000)
	libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f4e08b42000)
	libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f4e08b0e000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f4e09f6a000)
	libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f4e0b0a8000)
	libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f4e08800000)
	libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f4e08a42000)
	libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f4e08a16000)
	libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f4e08724000)
	libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f4e086f7000)
	libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f4e09869000)
	libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f4e0985b000)
	libicudata.so.72 => /lib/x86_64-linux-gnu/libicudata.so.72 (0x00007f4e06800000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f4e0865c000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f4e08647000)
	libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f4e0932a000)
	libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f4e08a09000)
	libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f4e08640000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f4e0862f000)
	libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007f4e08620000)
	libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f4e085fd000)

段落の最初の行頭の字下げ

WordPress.org の日本語フォーラムでの「日本語字下げをいつまで無視し続けるのか」という投稿に答えるなかで改めて調べてみて、いくつかを知ることになったのでここに記しておく。

多くの言語で使われることが想定される WordPress に、日本語の一つのスタイルである「全角アキ」を実装するよう求めるのは現実的ではない。利用者(サイト運営者)が style.css なりカスタマイズの「追加CSS」で対応するしかないだろうと思う。もっとも英語使用者にも似たような要望を持つ人はいるようで、たとえば英語のフォーラムにも Indent first line of most paragraphs, not all のトピックがあるし、そこからたどってみると #37462 の要望も出されている。

まず、英語をはじめとする多くの欧文で、段落整形は

  • 段落間は大きくあけず、段落の最初の行頭を字下げする
  • 字下げせず、段落間の行間をあける

のどちらかである。それぞれ「インデントスタイル」「ブロックスタイル」のように呼ばれるようだ。どうやら前者は伝統的なスタイルで、後者はウェブページなど電子テキストに多く見られる。

日本語の横書きもこれに準じる。ただし欧文の場合に字下げ幅が3–5文字であるのに対し、日本語の場合は全角アキである。

スタイルシート

私自身も、まとまった文章では伝統的な「インデントスタイル」が望ましいと考えているので、このサイトではスタイルシートで次のように設定している。

.entry-content p {
  margin-bottom:.25em;
  text-indent:1em
}

つまり、段落ブロックの下のアキは少しだけにして、最初の行頭の字下げ幅は 1em にしている。

見出し直後の段落

「インデントスタイル」の場合でも、最初の段落(見出し直後の段落)のみは字下げしない、という流儀もある。たとえば CSS のプロパティ text-indent の解説にもこのことが書かれている。まさにそこにあるように書くことで実現できる。

このサイトではこの流儀は採用していない。

日本語組版処理の要件

日本語については「日本語組版処理の要件」が重要な参考資料となる。「段落整形」の章でこの件について書かれている。

そこに、これまでどうしようか迷って自分でも揺らいでいた部分についての言及があった。

改行にして始めかぎ括弧[「] (LEFT CORNER BRACKET)及び終わりかぎ括弧[」] (RIGHT CORNER BRACKET)でくくった会話などを“といった……”などと受けて続く場合は,文節が連続していると考え,段落の先頭行の字下げは行わないで天付きとする(Figure 151).横組の別行にした数式を受けて,改行で“となるので……”などと受ける場合も,同様に段落の先頭行の字下げは行わない.ただし,小説などでは,すべて段落の先頭行の字下げは行うという処理方法も行われている(Figure 152).

「日本語組版処理の要件」3.5.1 段落先頭行の字下げ

要は、カギカッコの会話文や独立行の数式を挟んで文が続いているとき、それらの会話文や数式の後の段落は字下げしない。ここまで明確に書いてある説明をこれまで見ていなかった。

この記事でいうと、上のほうにある箇条書きに続く「のどちらかである。」のところは字下げしない、ということになる。これまでどうしたものかと思いっていたことの答がはっきりと示されていて、すっきりした。

内容に依存するため、さすがに一律に設定はできない。ここだけは字下げしないという場合にその CSS を適用する。WordPress のブロックエディターなら、右のほうのメニューの「ブロック」→「高度な設定」→「追加CSSクラス」で、前もって style.css か「追加CSS」に用意しておいた .noindent {text-indent: 0em} を指定するようにする。

Markdown でビジネス文書を作成する

まとめ

  • Pandoc’s Markdown という一方言には::: という汎用Divに対応する記法がある。
  • {markdown, latex} → html は pandoc のみでできる。別途 css を用意するといい。
  • {html, latex} → markdown は pandoc のみでできる。
  • {html, markdown} → latex はフィルタが必要。別途 sty を用意するといい。

ビジネス文書

しばらく前に「公文書を Markdown で」という話題があった。図入りの面倒くさいものや白書のような普通の書籍ほどの長大なものや法律の条文のような特殊なものは別として、圧倒的に多いであろう1枚ペラ程度の通達の類の文書には、 Markdown はとても向いていると思う。簡単なものほど Word のような高機能文書作成ソフトを使わずに Markdown で済ませたい。

この様式[1]は、役所が作成する公文書[2]から会社、さらには小学校や PTA、町内会までよく浸透している。

しかし Markdown では、この類の文書の様式に欠かせない右寄せ(右揃え)ができないのが最大のネックだ。意味見た目の分離という観点から言えば右寄せ(右揃え)は見た目なのだが、ここではもうそう呼ぶ ことにする。

Markdown

機能を絞り込んで簡潔であることが Markdown の特長なのだから、あれもこれも盛り込んでいけば最初から HTML を使えばいいとなって元も子もない。とは言え不満はなんとかしたい。Markdown で書きながらも最終的には HTML にすることを想定して直接 HTMLタグ (<div style="text-align:right">)を書いてしまうという手段もあるのだが、せっかくの Markdown なのだし他の形式への変換も考えるとなるべくそういうことはやりたくない。

ここは Markdown 記法に HTML の汎用タグ <div><span> を表せるものがあれば万能なのになあ……と思っていたら、Pandoc’s Markdown という一方言にはこれが存在していることに今さらながら気がついた。

Pandoc の Markdown 拡張

Pandoc’s Markdown という一方言には::: という汎用の Div に対応する記法がある。ここでは触れないが、汎用の Span に対応する []{} 記法もある。

この記法は Pandoc で考案されたようだ[3]。他の方言ではあまりサポートされていないようだ。HackMD (CodiMD, HedgeDoc) では ::: はやや違った意味にされ、記法も違い限定された語だけしか使えないようだ。

汎用タグを使いすぎれば意味見た目の分離が台なしになることは解っているのだが、最終手段として便利であることは間違いない。

たとえばファイル名 input.md に、Pandoc’s Markdown で書く。

::: {.myaddress}
○△□町会\
会長 ▼▲ ■◆
:::

Markdown から HTML へ

pandoc の標準機能で、特に何もしなくてもいい。コマンドラインで

pandoc --from markdown input.md -to html -o output.html

これにより作成される output.html は次のようになる。

<div class="myaddress">
<p>○△□町会<br />
会長 ▼▲ ■◆</p>
</div>

つまり、Markdown で書いた {.myaddress} がクラス名になる。このクラス名に対応する CSS は別途用意しておく。たとえばファイル名 myaddress.css に

.myaddress {
        text-align: right;
        text-indent: 0pt;
}

と書いておき、コマンドラインで

pandoc --from markdown input.md --to html --output output.html --css myaddress.css --standalone

として利用する。スタイルシートへのリンクがドキュメントヘッダに含まれるため、–standalone オプションも同時に付ける必要がある。

Markdown から LaTeX へ

出力形式を LaTeX とすると、::: は除去されてしまう。つまりコマンドラインで

pandoc --from markdown input.md --to latex --output output.tex

とすると、作成されるファイル output.tex は次のようになる。

○△□町会\\
会長 ▼▲ ■◆

pandoc の作者によるフィルタの例 latexdivs.py を使う[4]と、出力を

\begin{myaddress}

○△□町会\\
会長 ▼▲ ■◆

\end{myaddress}

のようにできる。これを実際に LaTeX で処理するには、 myaddress 環境を別途定義しておく必要がある。たとえば myaddress.sty に

% myaddress
\newenvironment{myaddress}
{\begin{flushright}}
  {\end{flushright}}

と書いておき、コマンドラインで --include-in-header で読み込ませる。

pandoc --from markdown input.md --to latex --output output.tex --include-in-header myaddress.sty --standalone

これにより作成される出力ファイルの内容は

\documentclass (略)
  (略)
% myaddress
\newenvironment{myaddress}
{\begin{flushright}}
  {\end{flushright}}
  (略)
\begin{document}

\begin{myaddress}

○△□町会\\
会長 ▼▲ ■◆

\end{myaddress}

\end{document}

のようになる。

形式の相互変換

以上、markdown → {html, latex} の例を示した。

自分のよく使う markdown, html, latex の相互変換についてまとめると、

  • {markdown, latex} → html は pandoc のみでできる。別途 css を用意するといい。
  • {html, latex} → markdown は pandoc のみでできる。
  • {html, markdown} → latex はフィルタが必要。別途 sty を用意するといい。

となる。

具体的な例

変換された html で利用する CSS ファイル
business.css
latex 出力のための pandoc フィルタ
business_md.py
latex 出力が利用する sty ファイル
business.sty
入力ファイル (markdown)
business-sample.md
pandoc --from markdown --to html --css business.css --standalone --output business-sample.html business-sample.md での出力ファイル (html)
business-sample.html
pandoc --from markdown --to latex --filter=./business_md.py --include-in-header business.sty --standalone --output business-sample.tex business-sample.md[5]での出力ファイル (latex)
business-sample.tex
pandoc --from markdown --to pdf --filter=./business_md.py --include-in-header=./business.sty --output business-sample.pdf business-sample.md[6]での出力ファイル (pdf)
business-sample.pdf
  1. 英文レターの形式を調べると、アメリカ式「フル・ブロック・スタイル」とイギリス式「フル・インデント・スタイル」が見つかる。日本のいわゆるビジネス文書はこのイギリス式「フル・インデント・ス タイル」にとてもよく似ている。特に電磁的文書ならアメリカ式がとても楽だし合理的だと思うのだが、なんと言っても理屈ではない習慣だからそう簡単に廃れることはないだろう。
  2. 検索すると多くの自治体の規程が見つかる。たとえば墨田区佐伯市など。
  3. Syntax for divs
  4. サンプルのフィルタ latexdivs.py をそのまま使うには、入力ファイルのクラス名を書くところに .latex を加えておく必要がある。つまり input.md は ::: {.latex .myaddress} のように書く。
  5. PDF に変換させるには、オプションはこれだけでは実は足りず、ここの例では --pdf-engine=lualatex -V documentclass=bxjsarticle -V classoption=pandoc -V classoption=jafont=auto -V indent=1zw -V pagestyle=empty を加えている。
  6. 前註に同じ。

CSS で見出し(h1, h2, …)に連番を付ける

検索すると似たようなタイトルでたくさんの記事が見つかります。今さら……な話題ですが、それらを参考に試行錯誤して、次のような CSS になりました。

よく見かける例だと、それぞれの見出しでひとつ下の階層のカウンターだけをリセットしているのが多いのですが、それだと h2 の次に(h3 がなくて) h4 が来るような場合にうまくいきません。そういう文書が悪いとも言えますが。

Chrome と Firefox で異なる結果になったりして、結局こうなりました。counter-set を紹介している記事はほとんど見かけません。見つけたのはこの質問と回答くらいで、回答者が仕様を説明してくれているのはとても参考になりました。仕様の EXAMPLE 22 は Firefox では正しく再現されません。

【2022年4月18日追記】現時点での Safari や iOS 上のブラウザー(Webkit)では counter-set が実装されていないため、下記ではうまくいかないようです。【追記終わり】【2023年12月12日追記】Safari や iOS 上のブラウザー(Webkit)に counter-set が実装されたようです。現時点でまだ実際に動作を確認していませんが。【追記終わり】

padding で字下げをしています。番号の書式は「公用文作成の考え方」を参考にしました。\a0 (non-breaking space)をいくつか入れているのは、連番をカタカナとしたので、見出しそのものの内容がカタカナで始まっている場合にある程度あいだが開いていないと混乱するからです。

body {
    counter-reset: chapter section subsection subsubsection paragraph subparagraph;
}

h1 {
    counter-set: section subsection subsubsection paragraph subparagraph;
}
h2 {
    counter-set: subsection subsubsection paragraph subparagraph;
    padding-left:1em;
}
h3 {
    counter-set: subsubsection paragraph subparagraph;
    padding-left:2em;
}
h4 {
    counter-set: paragraph subparagraph;
    padding-left:4em;
}
h5 {
    counter-set: subparagraph;
}

h1::before {
    counter-increment: chapter;
    content: counter(chapter, upper-roman) "\a0\a0\a0\a0";
}
h2::before {
    counter-increment: section;
    content: counter(section, decimal) "\a0\a0\a0\a0";
}
h3::before {
    counter-increment: subsection;
    content: "(" counter(subsection, decimal) ")\a0\a0\a0";
}
h4::before {
    counter-increment: subsubsection;
    content: counter(subsubsection, katakana) "\a0\a0\a0\a0";
}
h5::before {
    counter-increment: paragraph;
    content: "(" counter(paragraph, katakana) ")\a0\a0\a0";
}
h6::before {
    counter-increment: subparagraph;
    content: counter(subparagraph, upper-alpha) "\a0\a0\a0\a0";
}

きっかけは Markdown でした。最近、Firefox なら拡張機能 Markdown Viewer Webext 、Chrome なら拡張機能 Markdown Preview Plus などを使って、手元で Markdown で書いたものをブラウザーで眺めることがしばしばあります。その際に、この文書は見出しに連番がほしいよなあなどと思ったのです。

ここに挙げた2つの拡張機能は CSS を追加できるので、そこにこれを書いてもいいですが、そうすると Markdown なら全て連番付き見出しになってしまいます。拡張機能 Stylus で、好きなときに入れたり切ったりすることにしました。もちろん Markdown のプレビューだけではなく、あらゆるサイトを見る際に適用できます。

Expert Mouse を買った(14年ぶり2回め)

この前の記事「HHKBを買った」から9か月も何も書いていなかったのか。しかもその時とほとんど同じような内容とは……。

Expert Mouse トラックボール(EM7) を長いこと使っています。正確に記録を残していませんでしたが、今では高校生になっている、友人の子がその当時はよちよち歩きで、膝に乗せてこのボールを触らせてあやしたことを覚えているので、購入したのは14,5年前のことです。

今でも問題なく使えているのですが、この前の HHKB と同じく、ふと壊れる前に新しくしてみようという気になりました。これまた HHKB と同じく、すっかり体に馴染んでいるので別のものに変えようという気にはなりません。現在もデザインもまったく変更なく同じものが販売されています。ありがたいことです。

新品と比べてみてみれば、古いものは何らか劣化していることに気づくかなと思ったのですが、案外そのままでした。スイッチの感触もほとんど変わりありません。見た目は確かに指の触れるところの塗装が剥げているのと、スクロールリングのギザギザがすっかり摩耗してツルツルになっているくらいでした。

ときどき掃除してきれいに使っているつもりでしたが、支持球が汚れているのか操作球が摩耗しているのか、新品のほうがはるかに滑らかにボールが動きます。この製品のスクロールリングの出来はあまり評判がよくなくて、前のは一度分解してどこか磨いたりしたような記憶がありますが、今回の新品は最初からスムーズで心地よく回ります。

自分の使い方では、本体は20年はもちそうです。HHKB 同様、この先これを買い換えることはもうないかもしれません。

EM7 とペットボトルカバーによるパーム(リスト)レスト
付属のパームレストはとうの昔にひび割れてだめになったので、試行錯誤の末、今は100円ショップで買ってきたペットボトルカバー350mL用にタオルを詰め込んで使っています。詰物をおはじきか何かと工夫しようと考えていますがまだ実現できていません。かなり高めにして、パームと言うよりは手首の上のほうを置いています。

ボタン割り当て

EM7 と右手ボタンの割り当ては自由に設定できるため、各自が自分の好みにすればいいのですが、参考までに私の例を晒しておきます。

右利きで、キーボードの右側に置いて右手で使用しています。

  • 左下ボタンを左クリック相当(親指)
  • 右下ボタンを右クリック相当(小指)
  • 右上ボタンを中クリック相当(薬指)
  • スクロールリングは時計で言うと3時の位置を薬指で、時計回りで下スクロール、半時計回りで上スクロール

ボールはだいたい人差し指と中指の2本の指先で操作しています。

HHKBを買った (22年ぶり2回め)

初代 HHKB の裏面ラベル

一つ前の型 HHKB Professional2 Type-S (PD-KB400WS) が Amazon のタイムセールで 20% OFF になっていたので、思わず購入してしまいました。現時点の最新型 Hybrid ではなく、USB 有線のみのものです。

これまで使っていたのは初代の Happy Hacking Keyboard (PD-KB01) で、裏を見ると1997年7月のものでした。

アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。

いまやパソコンは消耗品であり、キーボードは大切な、生涯使えるインタフェースであることを忘れてはいけない。

の言葉のごとく、本体は何度も替わりましたがこのキーボードを22年も使い続けてきました。

まだ壊れてしまった訳ではありません。左シフトの反応が少しおかしい (キーをいったん外して紙片を入れて押し込みの深さを調整すれば大丈夫) のと、数年前に掃除した際にスペースバーの裏のバネを1本紛失してしまったのが不都合と言えるくらいです。

1990年代、私は Sun のワークステーション (SPARCclassic) を独占してデスクトップで使えるという環境にあったのですが、純正のキーボードは確か Type5 で、かなり大きくて邪魔なものでした。「CTC 省スペースキーボード」を入手して使ってみたのですが、これはノート PC のキーボードを持ってきたようなもので、キーストロークが非常に浅く、打鍵感がどうにも不快でしかたありませんでした。

そこに Happy Hacking Keyboard が登場してきたので購入したのです。ケーブルは Sun 用と PS/2 用 があって、はじめはもちろん Sun SPARCclassic で使っていたのですが、そのうち PC がどんどん高性能・低価格になり、Debian をインストールした PC がメインになり、PS/2 で接続して使うようになっていきました (SPARCclassic は画面なしキーボードなしで、リモートログインして使うサーバーとしてしばらく存在していましたが、6,7 年で退役しました)。

新旧 HHKB

それから本当に何台も本体は入れ替わっても、キーボードはずっと生き残り続けました。しかし接続口が Sun または PS/2 では、そろそろ「馬」に合わなくなってきたようです。

新旧の二つを並べてみると、この色の違い! 新品どうしならおそらくほぼ同じ色のはずです。煙草は吸わないのですがここまで黄ばんでいたとは。毎日目にしていると案外気がつかないまま、ここまで変色していました。

新旧 HHKB を横から見る

さっそく新しいのを使ってみていますが、やはりちょっと違和感があります。写真にうまく撮れませんでしたが、本体の厚さ(高さ)がほんの数 mm ですが高くなり、それに本体断面のカーブがゆるくなっています。それから、各キーの縁が微妙に指に痛い。前のは使い込みすぎて縁が丸くなっていたのでしょうか。もちろんこれらは慣れの問題で、すぐに気にならなくなるでしょう。

今回購入したものがこの後また20年ほどもつとしたら、次のキーボードを買うことはもうないかもしれません。