2022年9月19日月曜日

ナウイ・ミクトランを名前から考察

1年ほど前にコヤンスカヤの名前について考察してみました。
見事に外したわけですが、今回は次の異聞帯、「ナウイ・ミクトラン」について考察してみます。
前回は「コヤンスカヤという名前の起源」でしたが、今回は「ナウイ・ミクトランの意味」「ナウイ・ミクトランが指すもの」を軸にしたいと思います。

1. ナウイ・ミクトランの意味

「・」で分けられているので、それぞれ見ていきます。

1.1. ミクトラン

順番が逆ですが、こちらは調べるとすぐ出てきます。
アステカの冥府・冥界のことです。
アステカの宇宙観では、天空が9層、地下も同じく9層に分かれていて、ミクトランは地下世界の9層目=一番下にあるといいます。

1.2. ナウイ

こちらについてはアステカ神話における世界の創造が参考になります。
アステカ神話では、アステカ王国が存在する世界は5番目の太陽が照らす5番目の世界であるとされます。
第1~第4の太陽が照らす第1~第4の世界は滅んでしまいました。
それぞれの太陽と時代の名前は以下のとおりです。
  • 第1の太陽:ナウイ・オセロトル(Nahui Ocelotl)
  • 第2の太陽:ナウイ・エエカトル(Nahui Ehecatl)
  • 第3の太陽:ナウイ・キアウィトル(Nahui Quiahuitl)
  • 第4の太陽:ナウイ・アトル(Nahui Atl)
  • 第5の太陽:ナウイ・オリン(Nahui Ollin)
では「ナウイ」とは「太陽」という意味かというと、そうではありません。
太陽の名前には定番の訳があり、第1から順に「4の虎(または4のジャガー)」「4の風」「4の雨」「4の水」「4の動き」と呼ばれます。

1.3. ナウイ・ミクトラン

それぞれの語の意味から、「ナウイ・ミクトラン」は「4の冥界」と解釈できそうです。
ミクトランの概念を正確に日本語にすると長くなるので「4のミクトラン」としてもよいでしょう。

2. ナウイ・ミクトランが指すもの

語の意味としては「4の冥界」と考えてほぼ間違いないでしょうが、これがただの章タイトルではなく、何か特定の事柄を指す可能性はないでしょうか?
最初に書いたとおりに「ナウイ・ミクトランが指すもの」を考えてみます。

2.1. 太陽の名前

1.2.で挙げたとおり、第1~第5の太陽は「ナウイ・○○」という名前です。
であるならば、「ナウイ・ミクトラン」も太陽の名前であると考えられないでしょうか?
この場合はさらに2つの可能性が考えられます。

2.1.1. 第6の太陽

世界は創造と滅亡を繰り返す、というのはアステカに限らずメソアメリカの文明に見られる考え方です。
アステカの場合、第1~第4の太陽と世界は滅び、第5の太陽と世界もいずれは滅びると考えられていました。
そして第6の太陽について言及したアステカ王国時代のテキストは見当たりませんでした。
であるならば、ナウイ・ミクトランとは「4の動き」が滅んだ後の太陽と世界のことである、と考えることができそうです。

2.1.2. 第1~第5の太陽のいずれか

一方で「ナウイ・ミクトラン」がFGO2部7章、異聞帯、ありえたかもしれない全く別の人類史であることを考えると、第1~第5の太陽のいずれかがナウイ・ミクトランに置き換わったという可能性もあります。
この異聞帯を受け持つデイビッドが契約しているサーヴァントはテスカトリポカであるという説も囁かれていますが、これが正しいと仮定するともう少し推理を進めることができそうです。
第1~第5の太陽はそれぞれ神と紐付けられています。
テスカトリポカは「4のジャガー」であり、つまり太陽でした。
しかしケツァルコアトルに倒されて海に落ち、ジャガーに変身、さらにこの世界の人々を喰らい、「4のジャガー」は終焉を迎えます。
ケツァルコアトルは次の「4の風」となり、今度はテスカトリポカがケツァルコアトルを打ち倒して「4の風」は終焉を迎える・・・というのが本来の第1と第2の太陽の時代です。
では、「4のジャガー」の時代にテスカトリポカがケツァルコアトルに倒されなかったら?と考えてみます。
本来であれば太陽がジャガーへと変じて終焉を迎えるはずだった世界が終焉を迎えない、という点において、ここで汎人類史との分岐が発生します。
ケツァルコアトルがテスカトリポカを倒せなかった理由として考えられるのが、デイビッドの存在です。
ケツァルコアトルはアプリで実装済み、テスカトリポカは未実装ですが、異聞帯に登場するのであれば、バビロニアでのケツァルコアトルを考えるとどちらも神霊サーヴァントであることが予想されます。
どちらも神霊で、原典においてもライバルのような存在ですが、テスカトリポカだけがマスターと契約していると考えると、パワーバランスに影響を及ぼしかねないでしょう。
これによって本来起こるはずだった「4のジャガー」の滅亡が起こらなかった世界が「ナウイ・ミクトラン」ではないか?と考えることができます。
ですが、「4のジャガー」が続いているのならば「ナウイ・ミクトラン」ではなく「ナウイ・オセロトル」になるはずです。
ここでアステカの世界観について、「アステカ王国の生贄の祭祀」P49~50から引用します。
世界の中心と東西南北の四地域には、巨大な世界樹が地下世界に根を張ってそびえ立ち、その幹と枝で天空世界を支えている。天空の力と地下の力はこれらの世界樹の内部を、らせん運動をしながら、かたや下降、かたや上昇し、やがて地表へと到達し、合流する。
「4のジャガー」がずっと続いている世界で、この正常な循環が機能し続けているのでしょうか?
循環が滞ったり止まったりしたときにどうなるか、テキストにはないようですが、おそらく世界そのものの生命力とか、重大なレベルで支障をきたすでしょう。
正式な名前は「ナウイ・オセロトル」でも、まるで冥界が座しているかのような様相を呈していることから「ナウイ・ミクトラン」とも呼ばれる、という状態なのではないかと考えれば一応の説明にはなります。
それでも、デイビッドが「4のジャガー」の時代にどうやって到達したのか、など課題は山積しています。
最初に思いついたときは「こっちのほうが汎人類史との分岐点がはっきりする」と思ったのですが、それ以外はかなり拡大解釈や連想を重ねた感じです。

2.2. 日付の名前

アステカで使われた暦には、365日周期の太陽暦である「シウポワリ」と、260日周期の祭祀暦である「トナルポワリ」があります。
このうちトナルポワリは1~13の数字と、20種類のシンボルで日を表します。
20種類のシンボルは以下のとおりです。
最初はナワトル語の発音をカナにしたもの、()内は意味です。
  1. シパクトリ(ワニ)
  2. エエカトル(風)
  3. カリ(家)
  4. クエツパリン(トカゲ)
  5. コアトル(ヘビ)
  6. ミキストリ(死)
  7. マサトル(シカ)
  8. トチトリ(ウサギ)
  9. アトル(水)
  10. イツクイントリ(犬)
  11. オソマトリ(猿)
  12. マリナリ(草)
  13. アカトル(葦)
  14. オセロトル(ジャガー)
  15. クアウトリ(鷲)
  16. コスカクアウトリ(コンドル)
  17. オリン(動き)
  18. テクパトル(石刀)
  19. キアウィトル(雨)
  20. ショチトル(花)
カウント方法は最初が「1のワニ」、次の日が「2の風」、さらに「3の家」と続き、「13の葦」の次が「1のジャガー」、「2の鷲」と続いていきます。
13と20の最小公倍数が260なので、260日目が「13の花」になり、次の周期に移ります。
20のシンボルを見ると、比較的近いミキストリはありますが、ミクトランはありません。
シンボルにミクトランがあったとすると「4のミクトラン」が現れますので、この可能性はないでしょうか?
この場合も2.1.と同じように2つの可能性があります。

2.2.1. シンボルが21種類になっている

シンボルが21種類になったとしても、13と21の最小公倍数は2つの積である273なので、存在しない日は発生しません。
とはいえ、地球の公転周期に基づくわけでもないのに273日という中途半端な周期を持つ暦ってどうなのよ、という気がします。

2.2.2. いずれかのシンボルがミクトランに入れ替わっている

こちらだと260日周期を維持しながら「4のミクトラン」が現れます。もちろん存在しない日も発生しません。
入れ替わる候補としてはやはりミキストリでしょうか。
しかし、ミキストリを除くと可能性が高そうなのはオセロトルであると考えます。
トナルポワリは13日で1つの単位(グレゴリオ暦でいう週)とされ、それぞれに守護神がいます。この単位は現在トレセーナと呼ばれていますが、ナワトル語で何と呼ばれていたのかは歴史の中に消えたようです。
トレセーナはそれぞれ最初の日の名前で呼ばれます。
で、ケツァルコアトルは「1のジャガー」「1のシカ」の守護神です。(「1のジャガー」は単独、「1のシカ」は他の神々と兼任)
テスカトリポカは単独で守護するトレセーナはなく、「1の動き」「1の鷲」を他の神々と兼任で守護します。
ちなみにミクトランに最も関わる神であるミクトランテクトリは「1の石刀」を守護します。
これも「デイビッドがテスカトリポカと契約している」という前提ですが、ケツァルコアトルが単独で守護するトレセーナの代わりに、別の何かが入っている、という想定です。

3. 太陽の名前とトナルポワリの資料を合わせて考えてみる

太陽の名前がすべてトナルポワリの日の名前と合致します。
なので、それぞれがシンボルで何番目かを書き出して法則性がないか見てみると、以下になります。
ジャガー(14)
↓8個
風(2)
↓17個
雨(19)
↓10個
水(9)
↓8個
動き(17)
ということは第6の太陽は動きから数えて17個先のシンボルでは?と推測できます。
17番目から17個先は14番目(20種類なので一回りしてしまう)となり、再びジャガーになります。
第6の太陽は再び「4のジャガー」になり、すでに書かれている創世神話と同じことが繰り返される、ということなのかもしれません。
これをFGOの話に当てはめてみると、第6の太陽ひいては世界の名前が第1と同じになってしまうということで、何者か(デイビッドかもしれないし、他のクリプターかもしれないし、もっと別の何者かかもしれない)が別名をつけることを提案、そこで便宜上つけられた名前が「ナウイ・ミクトラン」であるという可能性が考えられます。

まとめ・感想

「ナウイ・ミクトラン」の意味は「4の冥界」または「4のミクトラン」と考えて良さそうですが、それが意味するものについてはこれだ!という説にたどり着けませんでした。
1つに絞って主張するのであれば、3.の第6の太陽の別名ではないか、と考えます。
今回については自分の知識の狭さを痛感しました。
どれか、かする程度でもいいから当たっててほしいなあ!


今日の1曲:

2022年4月26日火曜日

FAC製作記 その4 MVVMフレームワークをPrismからCommunityToolkit.Mvvmに移行する

2021年11月に.NET 6がリリースされました。
FACも.NET 6でビルドし直して、ついでにあれこれ手を加えて、3月19日に.NET 6版をリリースしました。
今回は「あれこれ手を加えて」の1つ、MVVMフレームワークの移行についてです。

なお、今回からコード類はQiitaに載せることにしました。

MVVMフレームワークの移行についてはその2でも少し書きました。
その2のときは.NET 5対応に伴って、MVVM Light ToolkitからPrismに移行しました。
今回はタイトルの通り、PrismからCommunityToolkit.Mvvmに移行しました。

【移行した理由】
前回はMVVM Light Toolkitが.NET 5に対応しないから、という理由でした。
今回は少し理由が違っていて、Prismと一緒に使っていたライブラリが開発を終了したためです。

FACではPrismを使うにあたり、Prism.Unityを使っていました。
で、これを構成するDIコンテナのUnity Containerが、2021年11月9日付けで開発とメンテナンスを終了しました。
今でもNuGetからインストールすることはできますが、非推奨となっています。

Unity ContainerはDIコンテナなので、別のDIコンテナに切り替えることも考えました。
例えば、Unityと並んでPrismと統合されているDryIocとかがあります。
ですが、仕事で調べ物をしている最中に、偶然「Microsoft.Toolkit.Mvvm」というものに遭遇しました。
せっかくなのでこれを調べてみて、「MVVM Light Toolkitみたいじゃねえか!」ということで移行を決意しました。

【Microsoft.Toolkit.MvvmとCommunityToolkit.Mvvm】
調べて出てきたのは「Microsoft.Toolkit.Mvvm」、俺がFACで使っているのは「CommunityToolkit.Mvvm」です。
NuGetで「mvvm toolkit」とかで検索すると、同じアイコンで2つ出てきます。
安定版の最新バージョンはどちらも同じで、CommunityToolkit.Mvvmは新しいメジャーバージョンのプレビュー版があったりします。
どうやら将来的にはCommunityToolkit.*に統一される予定らしいということで、CommunityToolkit.Mvvmを使うことにしました。

【移行する】
結構力技でやりました。
一応順を追って行きます。

1. 参考にするためにMVVM Light Toolkitを使うアプリとCommunityToolkit.Mvvmを使うアプリを作る
いきなり脱線します。
というのも、FACではPrism.Unityを使うためにApp.xaml/App.xaml.csを書き換えていました。
書き換える前のコードなんか覚えていないので、丸写しするためにテスト用のアプリを作ったわけです。

2. NuGetで必要なライブラリをインストール
CommunityToolkit.MvvmとMicrosoft.Extensions.DependencyInjectionをインストールします。
後者はDIコンテナです。
Unity Containerから脱却するためのMVVMフレームワーク移行なので、DIコンテナは使い続けます。

3. App.xaml/App.xaml.csを書き換える
1.で作ったCommunityToolkit.Mvvm版のコードを丸写しします。
名前空間が違うのでそこだけ書き換えます。

4. ロケーターを用意する
Prism.UnityではApp.xaml.csでDIの設定をしていましたが、ばっさり削除してしまったのでどこかで設定する必要があります。
そこでViewModelLocatorに相乗りさせることにしました。
通常はViewModelsフォルダーにViewModelLocatorというクラスを用意します。
MVVM Light Toolkitの場合はNuGetでインストールするだけで自動生成してくれるファイルですね。
これにDIも含めた役割を持たせるために、プロジェクト直下にLocatorというクラスを用意しました。
ここにCommunityToolkit.MvvmのViewModelLocatorと、Microsoft.Extensions.DependencyInjectionのDIの設定をまとめてしまいます。
最後にApp.xamlでアプリのリソースにLocatorクラスを登録すればOKです。

5. ViewとViewModelを修正する
MVVMフレームワークを移行するので、ViewModelへの影響は避けられません。
また、FACの場合はViewとViewModelの紐づけにPrismの機能を使っていたので、これを削除する必要があります。
紐づけはMVVM Light Toolkitのころと同じく、ViewのDataContextをXAMLで設定することで実現します。

Gitのログを見てみると、2.~5.で約2時間半という感じでした。

.NET 5対応に伴ってPrismに移行したときには、また移行することがあるとは思ってもいませんでした。
MVVMフレームワークはアプリ作りの根幹にかかわることだけに、そうそう移行をするものではないですが、これもまた経験と捉えましょう。
MVVM Light Toolkitは気に入っていたので、同じ感覚で使えるのは嬉しいポイントですね。

今回のコードはこちらに載せました。


今日の1曲: