キー番号と調号の決定に関するメモ

音楽 数学

MIDIのノート番号は音のピッチ（音高）を表現している。ノート番号0はC-1の音を表していて、番号が1増えると、音高は半音上がる。

このような、ピッチを使った音の表記は、しかし、キーを表現することができないという問題がある。ノート番号はピッチを表現しているため、異名同音のD♯、E♭、F𝄫を区別することはできない。

そこで、ここではピッチではなく、キーに対して番号を振る方法を考えてみる。五度圏を考えると、キーは次のように並んでいる：

... A𝄫 E𝄫 B𝄫 F♭ C♭ G♭ D♭ A♭ E♭ B♭ F C G D A E B F♯ C♯ G♯ D♯ A♯ E♯ B♯ F𝄪 C𝄪 G𝄪 ...

そこで、五度圏に並んだ順で、音名Cのキー番号を0とし、そこから完全5度上昇するごとに番号を1ずつ増やしたものを、キー番号とする。

ノート番号とキー番号の関係

オクターブの差や異名同音を無視して考えると、キー番号が1増えれば、音高は完全五度上昇、すなわち、7半音上昇する。逆に、音高が半音上昇すれば、キー番号は7増える。そして、ノート番号もキー番号も、12増えた場合は同音になる。

C-1 のノート番号・キー番号がそれぞれ0となるように定めたので、ある音のノート番号nとキー番号kの間には

k \equiv 7n \pmod{12}

n \equiv 7k \pmod{12}

の関係があることになる。

調号の決定

五度圏を使ってキー番号を定義したことからも分かるが、キー番号は調号と直接的に対応している。長調においては、主音のキー番号が、そのまま調号におけるシャープ記号の数となる。（負数の場合は、フラット記号を付ける。）また、Aのキー番号が3であることから、短調では主音のキー番号から3を引けばシャープ記号の数になることがわかる。

調号の変化記号（シャープ記号またはフラット記号）の数は最大で7個なので、長調においては主音のキー番号kを-7 \le k \le 7となるように定める必要がある。同様に、短調においては主音のキー番号を-4 \le k \le 10の範囲で定める必要がある。従って、-7 \le k \le -5の場合（主音がC♭, G♭, D♭の場合）は長調に対して同主短調が記法上存在せず、8 \le k \le 10の場合（主音がG♯, D♯, A♯の場合）は短調に対して同主長調が記法上存在しない。

このことから、同主調を必要とするならば、キー番号は-4 \le k \le 7の範囲にある12個（A♭, E♭, B♭, F, C, G, D, A, E, B, F♯, C♯）に決めるべきだとわかる。C♭ major, G♭ major, D♭ majorはそれぞれB major, F♯ major, C♯ majorが同主短調の存在する異名同音調となる。また、G♯ minor, D♯ minor, A♯ minorはそれぞれE♭ minor, B♭ minor, F minorが同主長調の存在する異名同音調となる。

調の主音のノート番号がnとして、

k = \left ( \left (7n + 4 \right ) \bmod 12 \right ) - 4

と定めることで、調のキー番号kを-4 \le k \le 7の範囲で決定できる。

2種類の悉曇文字ryaとUnicodeに関するメモ

文字

悉曇文字のデータ化に関する諸問題 —大蔵経テキストデータベース化に伴う悉曇文字作成をめぐって—によれば、悉曇文字のryaは、大蔵経中に2種類の字体が使われている。一つは、raの切継上半体にyaを継いだもの、もう一つはraの切継上半体にyaの切継下半体を継いだものだ。しかし、Unicodeの規格上、ryaの字体をどのように実装するかということは明記されていない。これは、Unicodeの悉曇文字フォントを実装する上で問題になる。

このryaの字体の曖昧性は、悉曇文字だけの問題ではなく、デーヴァナーガリーやベンガル文字、カンナダ文字といった他のインド系文字にも存在しており、The Unicode Standard にも Alternative Forms of Cluster-Initial RA という題で言及されている。

Alternative Forms of Cluster-Initial RA. In addition to reph (rule R2) and eyelash (rule R5a), a cluster-initial RA may also take its nominal form while the following consonant takes a reduced form. This behavior is required by languages that make a morphological distinction between “reph on YA” and “RA with reduced YA”, such as Braj Bhasha. To trigger this behavior, a ZWJ is placed immediately before the virama to request a reduced form of the following consonant, while preventing the formation of reph, as shown in the third example below.

Similar, special rendering behavior of cluster-initial RA is noted in other scripts of India. See, for example, “Interaction of Repha and Ya-phalaa” in Section 12.2, Bengali (Bangla), “Reph” in Section 12.7, Telugu, and “Consonant Clusters Involving RA” in Section 12.8, Kannada.

https://www.unicode.org/versions/Unicode14.0.0/ch12.pdf#page=19&zoom=auto,-40,350

悉曇文字にも他のインド系文字の規則を応用すれば、raの切継上半体にyaを継いだもの（“reph on YA” に相当する）は ra + virama + ZWJ + ya、raの切継上半体にyaの切継下半体を継いだものは（“RA with reduced YA” に相当する）は ra + ZWJ + virama + ya として表現されるべきものであるように思われるが、悉曇文字に関しては、そのような挙動は明示的に記述されていないし、それを実装しているフォントもなさそうだ。

また、ZWJを使わない ra + virama + ya をどちらで表示するかという問題もある。

  • ra + virama + ZWJ + ya <U+115A8 U+115BF U+200D U+115A7> 𑖨𑖿‍𑖧
  • ra + ZWJ + virama + ya <U+115A8 U+200D U+115BF U+115A7> 𑖨‍𑖿𑖧
  • ra + virama + ya <U+115A8 U+115BF U+115A7> 𑖨𑖿𑖧

TypeScriptでESNextを使う場合のSequelizeの書き方

TypeScriptでSequelizeを使おうとして、マニュアル（Manual | Sequelize）にある通りに、null assertionを使ってモデルのフィールドを定義してやると、うまく動かなかった。

import { DATEONLY, INTEGER, STRING, Model, Sequelize } from "sequelize";

export const sequelize = new Sequelize("sqlite::memory:");

export class User extends Model {
    id!: number;
    name!: string;
    birth!: string;
}

User.init({
    id: {
        type: INTEGER,
        primaryKey: true,
        autoIncrement: true,
    },
    name: {
        type: STRING,
        allowNull: false,
    },
    birth: {
        type: DATEONLY,
        allowNull: false,
    }
},
    { sequelize }
);

export async function main() {
    await sequelize.sync({ force: true });
    const user = await User.create({
        name: "Albert Einstein",
        birth: "1879-03-14"
    });
    console.log(user.name, user.birth);
}

main();

コンパイラオプションのターゲットがESNextに設定されている場合、上のコードを実行すると undefined undefined と出力される。これは、最新版のTypeScriptが TC39 Stage 3 提案のクラスフィールド に対応しており、ターゲットがESNextになっている場合は、useDefineForClassFieldsコンパイラオプションが有効になって、現行の意味論である「定義」意味論が使われるからだ。（「定義」意味論については、Babelプラグインの順序とallowDeclareFieldsの妙を参照してほしい。）

この問題は、以下のいずれかで解決する:

  • useDefineForClassFieldsオプションをfalseに設定する。
  • null assertion の代わりに declare プロパティ修飾子を使う。
export class User extends Model {
    declare id: number;
    declare name: string;
    declare birth: string;
}

新規のコードを書くときは declare 修飾子を使うようにした方がいいだろう。

参考文献

IDSデータベースリスト

macOS Big Sur では梵字が表示できる

support.apple.com

macOS Big Sur に組み込まれているフォント一覧を見ると、Noto Sans Siddhamがあることが分かる。これは悉曇文字、つまり寺院などで目にする梵字を収録したフォントだ。Font Bookやアプリのフォント一覧には表示されず、フォントフォールバック機能を介して使うことが前提になっているみたいだ。

フォントが入っていない人は https://github.com/googlefonts/noto-fonts/tree/main/hinted/ttf/NotoSansSiddham からフォントを入手できる。（NotoフォントはSIL Open Font Licenseの条件下で公開されている）

試しに、この記事にもいくつか梵字を載せておこう。（他にも 种子字 - 维基百科，自由的百科全书 にたくさん載っている。）

𑖭𑖾 saḥ

この字は東スポで記事になってた。（馬というか、勢至菩薩の種字で、午年の守り本尊なんだってさ） www.tokyo-sports.co.jp

𑖂 i

𑗘 i

𑗙 i

𑖮𑖳𑖽 hūṃ

𑖮𑗝𑖽 hūṃ

𑖏 kha

𑖭𑖿𑖝𑖿𑖪𑖽 stvaṃ

𑖮𑖿𑖨𑖱𑖾 hrīḥ

𑖮𑖿𑖮𑖳𑖼 hhūṃ

𑖮𑖿𑖦𑖿𑖦𑖯𑖼 hmmāṃ

梵字をよく知らないので、残念ながら書体のクオリティについてはコメントできない。

電子発行された生命保険料控除証明書を読む

皆さんは確定申告は済みましたか？ 私はまだです。2月中旬にやろうとしたけど、年末の携帯電話料金の引き落としの決済が完了していなかったんですよね……それで今日着手したんですけど、生命保険料控除証明書が必要になりました。10月ごろに郵送されて届いているらしい？ けど覚えていません。でも、電子発行も可能なみたいで、大丈夫そうでした。

で、電子発行したんですけど、ファイルの形式がXML。会計ソフトに金額を入力しなきゃいけないから読みたいと思ったんですけど、テキストエディタで開いて中をみてもタグ名がWCE00370みたいな識別子で、さっぱり項目が分かりません。

じゃあ、どうすれば読めるのか。方法を2つ見つけました。

方法その1 ＱＲコード付証明書等作成システムを使う

www.e-tax.nta.go.jp

ＱＲコード付証明書等作成システムに、生命保険料控除証明書のXMLファイルをアップロードすれば、PDFに変換されて、人間が読めるようになります。専門知識が要らないので、これが楽です。自分の環境はMacでFirefoxの推奨環境外ですけど、ふつうに使えました。

ただ、使うのはあまり難しくないにしても、リモートのサービスに依存しないと書類が読めないというのはちょっと不満があります。システムをオープンソースにしてほしい。

方法その2 XMLをウェブブラウザーで開く

XMLの基幹的な技術のひとつに、スタイルシートというものがあります。これは、XMLファイルを、人間が読める形に変換してくれる技術です。スタイルシートとしてはCSSが有名ですが、XMLのスタイルシートとしてはXSLというものが使われることが多いです。いまどきのWeb界隈はXMLを扱わないんでしょうが、ウェブブラウザーはXSLにもちゃんと対応しているので、開けるはずです。早速ブラウザーで開いてみましょう。

f:id:mandel59:20210301103913p:plain
XMLファイルを開いた結果

……ひどいですね。これはFirefoxで表示されたエラー画面ですけど、Google Chromeではエラーさえ表示されず、真っ白な画面が表示されます。開発ツールのウェブコンソールを確認すると、セキュリティ関係のエラーが出ています。（ローカルに保存したXMLファイルが、リモートにあるスタイルシートを参照しているので、エラーになっています。）

このエラーを回避する手順は:

  1. http://xml.e-tax.nta.go.jp/xsl/1.0/CMTEG800-001.xsl からスタイルシートをダウンロードする。
  2. XMLファイル中のスタイルシートのパスを、ダウンロードしてきたスタイルシートを指すように書き換える。
  3. 開発用ウェブサーバーを立ち上げ、XMLとスタイルシートをサーバーで提供する。
  4. ウェブブラウザーから開発用ウェブサーバーにアクセスしてXMLファイルを開く。

たいへんですね。専門知識がないとできません。こんなハックじみた方法じゃないと開けないのでは、スタイルシートの意義がないんじゃないでしょうか。 ウェブを取り巻く環境が変わって、セキュリティの仕組みがウェブブラウザーに入ってきたことに、対応できていないんですね。

むすび

いかがでしたか？ この記事で皆さんもXMLに興味が湧いてきたんじゃないでしょうか。

ここには書いてない読み方として、XMLスキーマをダウンロードしてきて自力で解読するという方法も思いつきましたが、試そうとしたところ国税庁ホームページがメンテナンスに入ってしまったんで試せませんでした。あとで誰か試してみてください。

個人的には、そもそもスタイルシートがなくても読めるようにしておくべきなのでは？という点が不満に感じました。人間に読めることを考えないんだったらJSONでいいじゃんって思うし、だからみんなJSONを使うようになっちゃったんでしょうね。どうあるのが理想なんでしょうか。

小ネタ

f:id:mandel59:20210301110012p:plain
XSLで変換された後のDOM

oncontextmenu="return false" はやめてください

■

mandel59.hateblo.jp

異体字セレクタを使うと「禰󠄀」の字を出せるよって話を前に書いたけど、アニメ公式の人物情報では「煉󠄁獄杏寿郎」の「煉󠄁」の字、「鬼舞辻󠄀無惨」の「辻󠄀」の字では異体字セレクタを使っていることがわかった。なんで禰󠄀の字だけフォントの変更で対応していたのかな？

MIDIデータを可視化するやつを作った

Midivis screenshot

音楽でどういう音が鳴っているのかを知りたいと思ったので、MIDIデータを可視化するやつ、Midivisを作りました。

https://midivis.ryusei.dev/

Web MIDI APIが動くブラウザー（Google ChromeかMicrosoft Edge）で使うことができます。Mozilla FirefoxはWeb MIDI APIをサポートしていないので動きません。（プラグインを使えば動かせるかもしれませんが、確認していません。）

ノートは、横方向は半音、縦方向は完全4度の音程で並んでいます。ノートは横に12列並んでいるので、これだと同じ音が重複して表示されることになりますが、このように表示することで、コードのパターンが分かりやすくなります。たとえば、次の動画ではカノン進行 D-A-Bm-F♯m-G-D-G-A を演奏していますが、D→AやBm→F♯m、G→Dのような4度下行のパターンは下に、D→Gのような4度上行は上に、A→BmやF♯m→G、G→Aといった2度の上行は右に動いて感じるかと思います。そうすると、カノン進行全体ではパターンはどんどん右に動いていきますが、循環コードなので最後には元の配置に戻ります。こういう表現ができるのは音を重複して表示させているからで、これを横幅5列にして重複をなくしてしまうと、パターンが途切れてうまくアニメーションしなくなってしまいます。

www.youtube.com

（動画ではF♯はG♭と表示されていますが、Midivis最新版では音名の表示にシャープを使うよう切り替えることができます。）

おまけですが、コードネームを表示する機能もつけています。よく使われるコードは表示できると思いますが、対応していないコードは代替表示になります1。異名同音も無視されるので、あくまでおまけ機能です。

  1. たとえばC, D♭, G, Bから構成されるコードがC{1,m2,5,M7}のような表示になります。↩

「不愉快の峠」仮説

マイノリティとマジョリティの間には、不愉快の峠があるのではないかと思う。

マイノリティ文化がマジョリティ文化に認知される過程を考えると、情報の少ない接触初期段階では、どうしても表現が歪み、不正確になってしまう。理解の深い人間の目には、この不正確で偏見混じりの描写はいかにも不愉快なものに映る。偏見をなくせ、正しく理解しろと憤る。

しかし、マイノリティ文化を最初から正確に描写することはできない。マイノリティ文化は異文化で、まず、正確に表現するための語彙さえ、マジョリティ文化には存在していない。マジョリティ文化の人間にマイノリティのことを正確に説明しようとすればするだけ、迂遠な表現で浅薄な解釈を回避することになるし、正確だが無味な描写は、結局はマジョリティ文化においては無視されることになる。偏見を許さない態度を強めれば強めるだけ、マイノリティ文化への理解が進展しなくなってしまう。そうであるとすれば、マイノリティがマジョリティに認知され、受容されるためには、少なくとも当分は、不愉快を飲んで相手の好奇心を刺激する描写に甘んじるしかないのではないか。

このような法則が、マイノリティの種別を問わず、普遍的にあるのではなかろうか。これは仮説でしかないのだけれども、明らかに不条理な仮説だ、と思う。マイノリティが無視される社会と、マイノリティが偏見にさらされる社会は、どちらも苦しい。マジョリティからの能動的な攻撃に晒されないだけ、無視されていた方がマシだ、という考えもあるだろう。しかし、無視されている状態からは、理解は進むはずがない。異文化間の不和を解消するには、不愉快の峠を乗り越え、その先へ進むしかないはずだ。

では、偏見を受け入れるべきなのか。部分的にはそうだ。しかし、極力無害な偏見を選ぶことは、できるかもしれない。致命的でない、許容できる不愉快さの偏見の峠を見つければ、不愉快さを耐えた先で、より深い相互理解を得られた未来に至ることができるかもしれない。

漢字処理に使うデータベース・関連サイトまとめ

漢字 技術 プログラミング

Unicode Character Database www.unicode.org

Ideographic Variation Database unicode.org

Adobe-Japan1 github.com

MJ文字情報一覧表 mojikiban.ipa.go.jp

漢字データベース kanji-database.sourceforge.net

GlyphWiki glyphwiki.org

萌典 www.moedict.tw

キーボード・ノートの対応

音楽

コンピューターのキーボードで音符を入力するとき、よくある方式だと

キー ノート
Z C3
S C♯3
X D3
D D♯3
C E3
V F3
G F♯3
B G3
H G♯3
N A3
J A♯3
M B3
K B♯3
, C4

のように対応させていて、要はピアノの鍵盤と対応させているけど、ふつうに横は半音階で並べて

キー ノート
Z C3
X C♯3
C D3
V D♯3
B E3
A F3
S F♯3
D G3
F G♯3
G A3
H A♯3
J B3
K B♯3
E C4

と割り当ててもいいのではないか。C4がEキーに当てられているのは、ベースの弦と同様に1段上が完全4度（5半音）になるように配置した結果で、実際にはQ, WキーにもB3, B♯3を重複して割り当てる。 こういうふうに、縦に完全4度、横に半音間隔で配列すると、左下のZキーから右上の0キーまでの音程は、3×5+9=24半音、ちょうど2オクターブになるので、割り当てに重複があっても、音域としては十分ではないかと思う。

竈門禰豆子の禰の字について

フォント 書体 漢字

f:id:mandel59:20201029182505p:plain
アニメ公式での竈門禰豆子の表記。禰を表示するのに中国語繁体字の字形を使っている。

どうやら、竈門禰豆子の禰の字について、しめすへんは正式には「ネ」の形という指定が存在しているようで、公式サイトでもわざわざフォントを変えて1、禰のしめすへんを「ネ」に変えています。中国語のフォントでは、しめすへんは常用漢字かどうかに関わらず、いつでも「ネ」の形をしているからですね。2

日本語フォント 禰

中国語フォント 禰

この、フォントを変える手法での字形変更は昔から行われていますが、中国語のフォントを使うわけなので、日本語のフォントのしめすへんとは形が少し違う問題があります。

他の方法としては、異体字セレクタと呼ばれる仕組みを使うと禰󠄁（しめすへんが「示」）と禰󠄀（しめすへんが「ネ」）は区別して出せます。この方法で変えられる字形は、日本語フォントの中で用意されている、他の字になじんだ字形を使うことができるメリットがありますし、異体字がUnicodeで表現されているので、コピー&ペーストしても、意図通りの異体字を出すことができます。3一方で、テキストに異体字セレクタという特殊な文字が含まれることになるので、それを考慮しないソフトウェアが誤った処理をする可能性もあります。

まあ、異体字セレクタまで使って字形に拘るのは個人的にはちょっとこだわりすぎに感じてしまいますが、常用漢字外の難字であればなおさら、細かい字形の差が混乱を引き起こすということもあるかもしれず、まあ難しいですね……

（ここまで書き上げたあとでスラドの WebサイトやWebサービスで異体字セレクタは使われているか | スラド IT で取り上げられていることに気づきましたが、はてなブログで異体字セレクタを使って表示する例として載せることにします。）

  1. 具体的には日本語のNoto Serif JPから繁体字中国語のNoto Serif TCに変更しています。↩

  2. 新字形や国字標準字体の場合。↩

  3. 表示に使うフォントが使う異体字セレクタに対応している必要があります。↩

メッセージとコンテキスト

note.com

安倍総理は、星野源さんのコンテンツの趣旨に敬意を払わずに、コンテクストと星野源さんが与えたルールを無視しました。

安倍総理の動画はただくつろいでいるだけで、歌っても踊ってもいない。コンテンツの趣旨、コンテキストを無視しているように見えるし、それが憤りに繋がっている。

しかし、いったいそんなコンテキストが本当にあったのだろうか。

星野源さんのインスタグラムには、バナナマンと大泉洋さんの動画も投稿されている。

www.instagram.com www.instagram.com

これらの動画は、何を伝えているだろうか。参加の形態は、必ずしも楽器の伴奏やコーラスやダンスに限らない、ということではないのか。俳優やお笑い芸人であり、音楽として関わることができなくとも、連帯してほしいということではないのか。これらの動画はニュースショーでも取り上げられていたし、これを見て、音楽でなくても大丈夫、というふうに思った人がいてもおかしくはない。

もちろん、個性的な大泉さんや、お笑い芸人のバナナマンだから、コンテキストを逸脱することが許されるのかもしれないし、星野源自身が投稿した動画であるから、彼らの動画が炎上するはずもない。一方で、一国の総理大臣が（追記：現状あまり職務を全うしていないと見なされている状況で）、彼らのように歌でも踊りでもない逸脱的メッセージを発することは、やはり問題があったのだとは思う。端的に言えば、安倍総理の動画はスベっていて、ムーブメントに水を差す結果になってしまった。

インターネットの時代、私たちは皆が皆異なるものを見ていて、コンテキストはほぼ共有されていない。この世界では、コンテキストを置き去りにして、メッセージだけが転送されてゆく。メッセージは原理的にコンテキストから乖離していく。この時代、正気でコミュニケーションをとろうとするのであれば、異文化への原理的無理解を理解し、ディスリスペクトという現象をリスペクトするべきだ。不快感に正直でありつつ、自分と異なる存在を理性的に認めるべきだ。そうでなければ、排外主義に堕してしまう。文化摩擦は、絶望というよりもチャンスであり、そういう時こそ感性を研ぎ澄まし、失われたコンテキストを集め、現象を見極めようとするべきだ。創造的な、あるいは破壊的な他者へのリスペクトが行われなければ、私たちは永遠にリスペクトされないだろう。

ウイルス感染シミュレーターを作ったので、オーバーシュートを完全に理解した

新型コロナウイルスの問題で、専門家が使う「オーバーシュート」という言葉の意味が問題になっていた。

togetter.com

興味を持ったので、自分でも感染症の数理モデルを作り（グラフは参考にしたが、計算するための具体的な数式は見ていない。集団免疫率の定義を見たぐらいだ。）、シミュレーションを行ってみたところ、同様のグラフを得ることができた。ここに、簡単に説明をしておこうと思う。

留意点として、私は疫学の専門家ではないので、以下で使われている用語は疫学で使っているものと異なっているかもしれない。

docs.google.com

f:id:mandel59:20200325093514p:plain
再生産数=2のときのシミュレーション

再生産数は感染者1人がウイルスを伝染させうる人数のこと。ウイルスの性質で決まる、本来的な再生産数を基本再生産数といい、コロナウイルスではだいたい2～3ぐらいであると考えられているらしい。

1度感染した人間は免疫を獲得するとすれば、ワクチンが開発されていない限り、延べ感染者数=免疫獲得者数となる。免疫を獲得した人間にはもうウイルスが感染しないことから、次のような漸化式を立てて、感染者数の変化を考えることができる。（直接、感染者数や延べ感染者数=免疫獲得者数を扱うのは面倒があるので、それぞれ人口で割って、感染者率・延べ感染者数率=免疫獲得者率とする。）

感染者率' = 感染者率 \times 基本再生産数 \times (1 - 免疫獲得者率)

免疫獲得者率' = 免疫獲得者率 + 感染者率'

この式を眺めれば分かるが、感染者率は基本再生産数 \times (1 - 免疫獲得者率)が1を超えていればどんどん増えるし、1を下回ればどんどん減っていく。その境界となる免疫獲得者率の値を、集団免疫率という。

基本再生産数 \times (1 - 集団免疫率) = 1

式変形すれば

集団免疫率 = 1 - \frac{1}{基本再生産数}

これらの式から、免疫獲得者率=延べ感染者率が集団免疫率を下回っている間は、感染者は増え続け、延べ感染者率が集団免疫率を上回ったところで、ようやく感染者数が減少に転じるということがわかる。（わからなければ、シミュレーション結果のグラフを見て確認してほしい。上掲のグラフは基本再生産数が2の場合のシミュレーションで、集団免疫率は50%だ。免疫獲得率が50%のところで、感染者数が減少に転じている。）何もしなければ、社会の人口のうち集団免疫率の分の人間がウイルスに感染するまで、ウイルスの勢力は強まり続けるという、避けがたい運命が示されている。ウイルスの封じ込めができなくなった以上、どんな政策を行おうと、いずれ延べ感染者数は、人口の50%～66%に至るのだ。たとえ、新型コロナウイルスの致死率が数%程度だったとしても、大量の人間が死ぬことになる。

もはや、延べ感染者数の人口比が集団免疫率に至ることが避けられないのであれば、私たちは速やかに集団免疫率を目指して、感染するようにすべきなのだろうか？いや、違う。何もしなければ、集団免疫率を大幅に超えて感染者が発生してしまうことになるのだ。

集団が集団免疫を獲得した時点、すなわち、延べ感染者率が集団免疫率に達し、感染者数が減少に転じた時点で、自然と流行に終息に向かうというのは正しい。しかし、流行が終息に向かうというのは、直ちに終息するわけではなく、感染者数が0になるまでは、あらたな感染者が出続ける。シミュレーションでは延べ感染者率は約87%に至っており、集団免疫率とは大きな差が生じている。これこそが、「オーバーシュート」と呼ぶべき現象だ。

しかし、オーバーシュートを回避する方法はある。実効再生産数（感染者が実際に感染を広げる人数）を下げれば良い。つまり、衛生管理を徹底する、外出を避ける等の施策によって、人為的に実効再生産数を下げることができれば、延べ感染者率はより低い値に収束し、その時点で感染者数がほぼ0になる。延べ感染者率が集団免疫率に至った時、感染者がほぼ0である状況であれば、ここから元の生活に戻り、実効再生産数が上昇したとしても、免疫獲得者の割合が多く実効再生産数は1を下回るのでウイルスの流行はもはや拡大しない。（延べ感染者率が集団免疫率を下回った状態ではいけない。延べ感染者率が集団免疫率より少ない状況で、実効再生産数が基本再生産数に戻れば延べ感染者率が集団免疫率より少ない状況では、実効再生産数が1以上に戻りうるので、そこからまた流行が拡大することになる。）

実効再生産数を下げれば、感染者数の最大値も下がる。医療のキャパシティが有限である以上、このことも施策上重要な要素ではあるのだが、感染者数が医療のキャパシティを超えることをオーバーシュートと呼ぶわけではない。オーバーシュートは、延べ感染者数の割合が集団免疫率を超えて増えすぎてしまうことを指すのだ。延べ感染者数×死亡率=総死者数なのだから、延べ感染者数を最小化することは非常に重要だ。

以上が、是非とも実効再生産数を下げる政策を積極的に行わなければならない理屈だ。しかし、このような理屈をまともに書いている記事はほとんどない。医療従事者さえ、この理屈を正しく理解できていないから、オーバーシュートを誤用しているのだろうと思う。これは問題だ。自分でシミュレーションをやってみれば、上の理屈は容易に理解できるはずだ。

ウイルス感染シミュレーターといっても、Google Sheetsで簡単な数式を並べてグラフを作成するだけの、やり方を知っていれば誰でも作れるものだ。実際に自分でも、シミュレーションをして、パラメーターを変えて感染状況の変化を確認してみてほしい。

追記:

追記2 (2020-03-27): 上の記述で、「実効再生産数」が適切に使われていなかったので、訂正し、より正確な表現にした。

オープンソース概念の無意識な風化への抵抗

このツイートが目に触れた。これは問題だ。

リプライにぶら下がっているリンクから、＜利用ガイドライン＞に飛ぶことができた。

本日より放送開始30周年となる2028年7月6日までの間において、以下の「利用ガイドライン」と「利用規約」の両方に同意いただくことを条件に、日本国内に居住されている個人の方に限り、アニメーション作品「serial experiments lain」（以下「本作品」といいます）の二次創作の利用を商用・非商用にかかわらず無償で許諾します。監修を受ける必要もありません。

また、個人の集合体となるファン・コミュニティによるOpen Source Projectであれば法人格を有しない限り、同様に許諾します。

www.nbcuni.co.jp

Open Source という言葉は、1998年に生まれた。パーソナル・コンピュータが大衆化し、人々の相互接続性が次第に高まっていく、そういう時代だ。奇しくも、あるいは必然か、serial experiments lainが発生した年でもある。（私はそれが存在することを知っているが、触れたことはない。）

Open Source は、概念だ。概念はとらえどころのない存在だが、言葉で定義されることで、社会全体に客観的に理解できる、確固としたものとなる。Open Sourceは、Open Source Initiative によって定義されていて、次のページで定義を見ることができる。

opensource.org

日本語で読みたい人は、次の八田真行訳を読んでもいい。

opensource.jp

第5条には、こういう定義がある。

  1. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons.

  2. 個人やグループに対する差別の禁止 ライセンスは特定の個人やグループを差別してはなりません。

ライセンスに「法人格を有しない」という条件を課すことは、当然、差別にあたる。これは、私には（おそらく、他のオープンソースソフトウェア・コミュニティーの人間にとっても）明らかにOpen Sourceとは認められない。

オープンソースとは、個人の集合体という意味ではない。個人であろうと、法人であろうと、差別されず参加できる、そういう仕組みを実現するための言葉なのだ。

だいたい、「法人格を有しない」という条件があるのであれば、法人格を有するいちから株式会社の運営するバーチャル配信者グループ「にじさんじ」に所属する、月ノ美兎は、どうなるのだ。月ノ美兎は、個人なのか、法人なのか？

考えれば、法人という概念自体が、組織をバーチャルな人間とみた概念とも言えるだろう。とらえどころのない組織に対してインターフェースとして与えられた、法的にバーチャルな人間、それが法人だ。月ノ美兎自体は、いちからではなく、いちからの運営するにじさんじに所属するバーチャルライバーではあるし、月ノ美兎は、個人であるように見える。しかし、月ノ美兎の活動は © Ichikara Inc. の付く、いちからの知的財産でもあり、月ノ美兎の、月ノ美兎としての活動は、いちからの活動ということにもなるはずだ。

いったい、この状況で、月ノ美兎は岩倉玲音の凸を受けることができるだろうか？ いや、そもそも、Open Source の考えは、そんなことで悩ませたりせず、自由な参加を促すためのものだったんじゃないのか？（これはただの私見だし、私は悩むのが好きだけれども）

Open Source 文化は、日本の同人文化やネット文化と似た面もあるが、本質的に異文化だ。おそらく、日本の同人文化が個人と法人の区別による黙認で二次創作を正当化してきた一方、Open Source 文化は明示的なライセンスによる許諾で二次創作を正当化してきたという文化的背景が、利用ガイドラインに無意識に反映されてしまっているのだろう。しかし、自分が Open Source だと言葉にするなら、Open Source 文化を正しく理解するとまでは言わずとも、少しはOpen Source 文化に触れてみてほしい。社会では色々な属性の人間やグループが、それぞれの意思と目的をもって活動しているが、それにも関わらず、Open Source文化では協同することができる。たとえ競合関係にある企業同士でさえ、その経済的原理から Open Source License のもとで協同することができる。（わたしはこういう、ドライで感情を伴わない状態から、原理に従って協力構造が生まれるという構図が、とても好きだ。）Open Source は、そうしてできあがった営みを指している。

lain は真に Open Source となることを願うだろうか。