『劇場版 カードキャプターさくら 封印されたカード』を考察してみた。

1/26(金)で『劇場版 カードキャプターさくら 封印されたカード』のリバイバル上映が終了した。

ちなみに、シネ・リーブル池袋で最後の上映回を見てきたんだけど、この回は満席・売切れになってた。

ホントに愛されてる作品なんだなぁ、と。

結局、5回しか見にいくことが出来なかったんだけど、十分堪能できたのでよかった。
そのついでで、この作品に対する自分の考察をちょっと語ってみたいと思う。

※以下、ネタバレを含むので、注意。
まぁ、20年前の作品だから、今更ネタバレもないんだけど（＾＾；

前回見に行ったときの感想は、以下から：

あらすじ

一応、あらすじも。

小狼が香港に帰ってしまって、さくらも小学6年生になっていた。
そんな夏休みの日、友枝町全体で開かれる「なでしこ祭」を前にして、小狼と苺鈴が友枝町にやってくる。
さくらは小狼に「好きだ」と言ってもらえた返事をしようとするが、なかなか上手くいかない。

そんな中、街の中で郵便ポストや橋が消えるという事件が起き、さくらカードも次々と消えていってしまう。
それは、エリオルの屋敷の下に封印されていたカード、「無」によるものだった。
「無」もさくらカードにすれば事件は解決するが、そのためには「一番大事な想い」を失わなければならないという・・・

解決策を見いだせないまま、「なでしこ祭」ではさくら達のクラスによる劇『悲しい恋』が演じられていた。
そこに「無」のカードの襲撃が。
大切な人たちが次々と消されていく。
クラスの友達や家族に始まり、知世、苺鈴、そして、ケロちゃんにユエまで・・・

封印を決意するさくらは、「無」との最終決戦に臨む。
しかし、そこにいた「無」は、ただ「友達」を取り戻したいだけという、いたいけな少女でしかなかった。
そんなさくらと「無」との間を、さくらカードたちが繋ぐ。
さくらカードたちも、「無」と「友達」になりたかったのだ。

いよいよ「無」のカードを封印し、「一番大事な想い」を失ってしまうというそのとき、小狼が現れる。
「無」のカードは、さくらではなく小狼を選んだ。
小狼の方が、残っていた魔力が多かったからだ。
「一番大事な想い」を失う小狼・・・
そして、「無」のカードは封印され、さくらカードに。
しかし、さくらの手に収まったのは「無」のカードではなく、さくらの「名前のないカード」と組み合わさった「希望」のカードだった。

「一番大事な想い」を失ってしまった小狼。
そんな小狼を前に、さくらは自分の想いを伝える。

「小狼くんが私のこと、何とも思ってなくてもいい。
　私は小狼くんが好き。
　私の一番は、小狼くんだよ？」

が、その想いは小狼には届かない・・・
かと思われた。
しかし、小狼はさくらに答える。

「俺もだ・・・さくら」

想いは届いたのだ。

＊＊＊

さて、最後の部分、ホントに「さくらちゃん、よかったね・・・」となるんだけど、よくよく考えると、かなりご都合主義に感じる部分も。
「そのとき、不思議なことが起こった」（by 仮面ライダーブラックRX）くらいの荒技で、ハッピーエンドにしているので。
まぁ、そんなご都合主義とか、もうどうでもよくなるくらいに感動的なので、映画見てるとあまり気にならないんだけどね。
ただ、ある程度は筋の通った解釈を示すことが出来ると思っているので、これについてはあとで。

劇中劇の妙

何はともあれ、この作品を語る上でまず語っておかないといけないのが、コレ。
劇中劇の妙。
これがホントに素晴らしすぎる。

この作品でキーとなっているジレンマは、

• 「無」のカードをさくらカードにしなければ、みんなが消えてしまう
• しかし、そうすると、「一番大事な想い」が消えてしまう

というもの。
簡単に言えば、「世界」をとるか、「個人」をとるか、という二択。

さくらちゃんはいい子なので、「世界なんてどうでもいい」とはならないし、かといって、「小狼への想いを失ってもいい」ともならないので、その間で苦悶することになる。

そして、劇はどんな内容なのかと言えば、「魔法の石」という強大な力を持った石をめぐって争う二つの国の、王子と姫の物語で、本番で王子を演じるのが小狼、姫を演じるのがさくらという配役。
二人は仮面舞踏会でお互いの正体を知らずに出会い、互いに好き合うが、その正体を知ることで、その恋が禁じられた恋であったことに気がつく。
王子は自分の想いを姫に伝えるが、姫はその想いには答えることが出来ないと言い、やがて、王子は姫を守って死んでしまう。
そして、姫は後悔するのだった。
「こうなるのなら、自分の想いを伝えていればよかった」と。

まるで、この作品（封印されたカード）のアナザーエンドを描いでいるかのような劇で、ここでも

• 自国の民のためには、魔法の石を手に入れなければならない
• しかし、そのためには、自分の想いは捨てなければならない

という、「公」をとるか、「私」をとるかという、似た構造が描かれている。

そして、それを小狼とさくらに演じさせるという、ね。

さくらが台本を読みながら

さくら
「・・・まるで心が自分のものではないかのようです。
　あの人を好きになってはいけないのに、私は私の心を止めることが出来ない。
　あの人の優しい笑顔が忘れられない。
　あの人に会いたい。
　会って、私の本当の想いを告げてしまいたい・・・」

（『劇場版 カードキャプターさくら 封印されたカード』より）

さくらが劇の練習で

さくら
「・・・なぜこんなことに。
　私を守るために死んでしまうなんて。
　あなたがいなければ、私に幸せなどないというのに。
　あなたに私のこの想いを伝えればよかった・・・
　本当の想いを・・・」

（『劇場版 カードキャプターさくら 封印されたカード』より）

劇本番で

さくら
「あなたが、我が国と争っている、隣の国の王子だったなんて・・・」

小狼
「姫、どうか泣かないで・・・
　誰よりも笑顔が似合うあなたを、悲しませてしまう私を許してください。
　けれど、この気持ちを止めることは出来ない」

小狼
「私は・・・
　私は、あなたが好きです」

さくら
「っ！」

さくら
「私は・・・
　私は、あなたの気持ちに答えることは出来ません」

小狼
「私を、お嫌いですか？」

さくら
「違いますっ！
　違い・・ます・・・」

二人
（・・・）

さくら
「私は・・・私は・・・
　いいえ、言えません。
　私のこの想いは、あなたにもーーいえ、あなたには」

さくら
「どうか、お願い。
　私のことなど、忘れてしまってください。
　心から、なくしてしまってください・・・」

（『劇場版 カードキャプターさくら 封印されたカード』より）

もうホントね、何なの、これ。
毎回、涙腺が崩壊する。

さくらは小狼のことが好きだし、好きだということをすごく伝えたいと思ってる。
そのさくらをして、「あなたの気持ちに答えることは出来ない」「私の想いを伝えることは出来ない」、さらには、「私のことなど忘れてしまってください」などと言わせるとか、ホントに・・・

劇中劇を使うことで、作品の構造を作品内に表せしめ、そして、さくらに本心とは真逆のことを言わさせるとか、なんて見事な手法なんだと言わざるを得ない。
こんな巧みな作品は、そうそうないと思う。

さらに、その劇中劇を悲劇で終わらせることで、この作品も悲劇で終わってしまうんじゃないかという不安を観客に引き起こさせる。
同時に、さくらの不安も引き起こし、葛藤を強調させる。
だって、想いを伝えられない苦しみを、さくら自身が、劇で自分で体験するのだから。

もうホント、この劇中劇、どんだけ仕事してるんだと。
素晴らしすぎて、脱帽の一言。

おまけで書いておくと、冒頭のバトルも作品の導入としてよく出来てるなぁ、と思う。
まぁ、こちらは作品に一気にのめり込ませるために、冒頭にひと盛り上がり用意するという、よくある手法なわけだけど。
ガルパン劇場版の冒頭のエキシビションマッチや、ユーフォニアム劇場版2作目の冒頭のプロヴァンスの風とかは、まさにこれ。

小狼の決心

ところで、この作品を見たときに気になってたのが、さくらに「無」のカードのことを相談されたときの、小狼の態度。

小狼は、「そうしなければ、街や人がなくなってしまうのなら、仕方ない」とさくらに答えるわけだけど、それはあまりに冷たすぎないかな、と。
まださくらから返事はもらえてないとはいえ、さくらの気持ちはある程度知っているわけで、そんなさくらに対して、「仕方ない」と言うのは、さすがにどうなのかと。
確かに仕方ない部分はあるけど、だからといって、そんな簡単に、好きになった相手の気持ちがなくなってしまったっていいと言えるものなのかと。

当然、これにはさくらもショックを受け、雨の中、傘もささずに駆け出していってしまうわけで。
この小狼の態度は、あまりに酷い。

ただ、今回リバイバル上映を観ている中で、実はそうじゃないんじゃないかと気がついた。

最後、さくらが「無」のカードを封印するとき、そこに現れた小狼は、こう言った：

「間に合ってよかった。
　俺の魔力の方が、まだ残っていたみたいだな」

間に合ってよかった、ということは、最初から小狼は封印の場に居合わせようと考えていたことになる。
つまり、さくらのかわりに自身の「一番大事な想い」を失うことを、小狼は考えていたわけだ。
では、いつから・・・？
最後の決戦の途中で思いついたという可能性も考えられる。
というか、最初はそうだと自分は思ってた。
けど、よくよく考えてみると、違うことに気がつく。

決戦前、さくらが「早くさくらカードに変えて、みんなを取り戻さなきゃ」と言ったとき、小狼は間髪入れずに「俺も行く」と言っている。
さらに、知世がさくらにコスチュームを渡したあと、知世は小狼に近づいて、ささやくようにこう言っている：

「一人だけ帰ってこないなんて、いけませんわ」

この言葉に、小狼は目を見開いている。

つまり、小狼はこの時点で、さくらの代わりに自身の「一番大事な想い」を失うつもりで、決戦に臨んでいたと考えられる。
そして、そんな自己犠牲にしようとしていた小狼に知世は気づき、さくらには聞こえないように、この言葉を小狼に贈ったと考えられる。

さらに考えを進めると、じゃあ、小狼は実はもっと前から自己を犠牲にすることを考えていたんじゃないか、というところに行きつく。
それこそ、さくらから相談を受けた、その瞬間から・・・

実のところ、さくらが小狼に相談しているシーンを見返してみると、実はさくらは「誰の」一番大事な想いが失われるのかということは、小狼には話していない。
（さくらはエリオルから「一番魔力が残っていた人」の想いが失われると聞いてる）
なので、ここで小狼が自己犠牲を決心するには、情報が足りていなかったりする。

けど、おそらく小狼は、なんとなく気がついていたんじゃないかな、と。
というのも、小狼が「仕方ない」とさくらに告げるまでには若干の時間があり（このときのバスが通過する音が、妙に生々しい・・・）、さくらに「仕方ない」と告げたときも、悲痛に歪んだ顔というわけではなく、遠くを見つめるような、決意のこもった眼差しになっているから。
この短い間に小狼は考えを巡らせ、そして、さくらではなく、自分の想いを犠牲にする決心を行ったんじゃないのかな、と。

そう考えると、この小狼の態度も、「さくら」より「みんな」をとったという冷たいものというわけではなく、「自身」より「さくら」と「みんな」をとったという、さくらへの想いに溢れたものだったんだろうなぁ、と。

もちろん、そのような自己犠牲がいいかどうかは、別として。
劇中劇の最後でも「あなたがいなければ、私に幸せなどないというのに」というセリフが紡がれているし、知世も「一人だけ帰ってこないなんていけない」と告げている。
実際、さくらを悲しませてしまったわけだし。
この辺りは難しいところ。

さくらの選択

あと、ちょっと触れておきたいのが、さくらの選択について。

前述した通り、この作品でのジレンマは、「世界」をとるか、「個人」をとるか、というもの。
これに対して、さくらの出した回答は、なんだったのか。

結果だけ見れば、「世界」も「個人」もとれてるので、いずれの選択もしなかった（あるいは、どちらも選択した）かのようにも見える。
ただ、それはある種の「奇跡」が起こったからで、実際にはその「奇跡」を起こすに至った第三の選択を、さくらはしているんじゃないかな、と。
それは、アウフヘーベンに至るジンテーゼと呼ぶには、ちょっと弱いものだけど。

その選択というのは、「『無』のカードと『なかよし』になるために、『無』のカードを封印する」という選択。

最終決戦の前、さくらは「みんなを取り戻す」ために、「無」のカードを封印すると言っている。
つまり、この時点では、「個人」よりも「世界」をとるという選択を行なっている。
これは、街の惨状や、大切な人たちがいなくなってしまった現実に触れ、もはや「個人」をとるなんて言ってられない状況になってしまったから。
「無」のカードと対峙したときも、その想いが強く吐き出されている。

けど、これが「無」と話す中で、全く氷解してしまう。
さくらの頭の中からは消えてしまっている。
というのも、「無」のカードは、ただ「友達」であるはずのカードたちと一緒に居たかっただけだということが分かったから。

そして、カードたちの導きもあり、さくらはこの「無」のカードと「なかよし」になりたいと願うようになったんだと思う。
そのために、「無」のカードを封印する、と。

これらの選択は、いずれも「無」のカードを封印するということに違いはないのだけど、「無」のカードに対する態度が180度変わってしまっていることに気づいて欲しい。
最初は、「無」のカードはみんなや街を消してしまう「敵」で、封印することで「敵」を倒し、そしてみんなを取り戻す、という構図だった。
それが、「無」のカードと話すことで、「無」のカードは「敵」ではなくなってしまっている。
一緒に居たいと願う、「友達」の一人に変わっている。
この心の変化が、最後の奇跡へと繋がっていったんじゃないかな、と。

これは、「最後の審判」でのユエとさくらの会話を思い出させる。

ユエ
「・・・なにが『審判者』だ。
　結局、最初から次のクロウカードの持ち主は決まってたんじゃないか」

（中略）

さくら
「ユエさん・・・
　きっと、すっごくクロウさんのこと、好きだったんだね」

さくら
「わたしなんかまだまだ子どもだし、魔力もぜんぜんだし・・・
　寝坊ばっかだし、算数も嫌いだし、なんにもできないけど・・・
　カードのこともケロちゃんのことも大好き。
　きっとユエさんのことも好きになれる。
　ううん、もう好きだよ！」

さくら
「『主』とかじゃなくて、『仲よし』になってほしいな」

ユエ
「・・・目を閉じろ。
　審判終了。
　我『審判者・ユエ』、さくらを新しい主と認む」

（『カードキャプターさくら』より引用　※月はユエと表記）

「なかよしになりたい」というさくらの想いが、ユエの心を溶かしたように、この劇場版においても、「なかよしになりたい」というさくらの想いが、最後の奇跡に繋がったんじゃないかな、と。

なぜ小狼は大丈夫だったのか

では、なぜ小狼は大丈夫だったのか。
それについて、考察していってみたい。

なぜ「一番大事な想い」が失われないといけなかったのか

そもそもの話として、なぜ「無」のカードを封印するのに、「一番大事な想い」が失われないといけなかったのか。
ストーリーの都合上、と言ってしまえばそれまでだけど、それだけじゃないと自分は思ってる。
まずはそこから話していきたいと思う。

ここで一つ、明確にさせておきたいこと。
それは、「一番大事な想い」が失われないといけなかったのは、「無」のカードを封印するからじゃなくて、「無」のカードをさくらカードにするからだということ。
封印するのとさくらカードにするのは、ほぼ同時なので、この2つを区別することに、何の意味があるんだろうと思うかもしれない。
けど、この区別がけっこう重要だったりする。

思い出して欲しいんだけど、クロウカードをさくらカードに変換するとき、さくらは必ず変換したカードを即座に使用してきた。
それがまるで、クロウカードをさくらカードに変換するための条件であるかのように。

エリオルによれば、クロウカードをさくらカードに変換するのは、かなり危険らしい。
そのために、（事件を起こしたりして）さくらカードを使わざるを得ない状況にさくらを追い込み、そして、さくらカードに変換させてきた、と。
なので、おそらく、「さくらカードを使わなきゃ」という強い意志がさくらカードの変換には必要で、当然、その意志は嘘偽りのものでは「足りない」ので、変換後にその意志の実行（つまり変換されたさくらカードの使用）が、必然的に必要だったんだろうなぁ、と。

もちろん、ただ使えばいいというだけなら、なんか適当なものを消せばいいだけなので、何も「一番大事な想い」でなくたっていいだろうとは思うんだけど。
まぁ、「無」のカードは強大な魔力を持ってるから、その変換にはさらに強大な魔力が必要で、その強大な魔力を以って実現する必要のあることとなると、「一番大事な想い」をなくすとかになってしまう、とかなんだろうなぁ、と。

ちなみに、想いを失うーー忘れてしまうということ自体は、必ずしも悪いこととは限らない。
後述する話とも関係してくるんだけど、「忘れることが出来る」ことの凄さを、そういえばCLAMPは書いてたなと思い出したので、引用：

店長
「パソコンだから出来ることと、パソコンだから出来ないことがあります。
　それは、人間だから出来ることと出来ないことがあるのと同じです。
　いや、パソコンであることのほうが悲しいこともありますよ」

（中略）

店長
「僕らは少しずつ時間の力を借りて昔の痛みを乗り越えていけるけど、
　パソコンは持ち主が消してやらなければ、どんなに辛いこともずっと覚えています」

（『ちょびっツ』より引用）

閑話休題。

ということで、さくらカードへの変換にはさくらカードの使用が必須なんだと考えると、「一番大事な想い」を失うという効果は、実際に発現していたんだろうなぁ、と。
そういう意味で、「名前のないカード」と一緒になって「希望」のカードに変わることで、「一番大事な想い」を失うという効果はキャンセルされたんだ、という説は、ちょっと説得力が弱いかなと思う。
それに、それだとまさに「そのとき、不思議なことが起こった」レベルで、ただ奇跡が起こっただけ（＝さくらと小狼の運がただよかっただけ）という話になってしまうので。

ツイッターで見かけた考察

一つ、ツイッターで見かけた面白い考察は、「名前のないカード」が小狼の身代わりになったんじゃないか、という説。
「名前のないカード」はさくらの想いが作り出したカードで、さくらの一番大事な想いと魔力が詰まってる。
なので、「無」のカードは、小狼の「一番大事な想い」の代わりに、その場で一番魔力の残っていた「名前のないカード」の、そこに込められていた「一番大事な想い」を失わさせて、さくらカードに変わったんじゃないか、と。

これは、効果が奇跡でキャンセルされたという説に比べると、だいぶ説得力がある。
けど、まだ気になるところがある。

まず気になるのは、じゃあなぜ「無」のカードはさくらカードになったとき、「希望」と名前が変わったのか。
「名前のないカード」と合わさったのだから名前も変わるだろう、と素直に捉えてもいいけど、そうだとしても、その名前が「希望」である理由は、ちょっと分からない。

それと、「無」のカードは明らかに小狼をターゲットにしていた。
「名前のないカード」はそこに割り込んだわけだけど、割り込むくらいで代わりになれるものなのか、という疑問が残る。
もし、割り込んで代わりになれるくらいに魔力が高かったのであれば、「無」のカードは最初から小狼ではなく「名前のないカード」をターゲットとして選んでいただろうし。

クロウカードの枚数

さて、ここからは自分の考え。

まず注目したいのが、クロウカードの枚数。

アニメ版で、クロウカードの枚数は、52枚となっている。
これは、ケロちゃんも劇中で「クロウカードは全部で52枚やろ」と言っている通り。
ところで、この枚数、何か覚えのある数字じゃないだろうか・・・
そう、これは、トランプの枚数と同じ。

おそらく、アニメ版でクロウカードの枚数が52枚になったのは、グッズとしてトランプが売れるよね、とか、1年が52週だからちょうどいいよね、とか、そういった軽い理由だったと思うんだけど、あえてこの枚数に注目してみたい。
後付けでこの枚数の設定が利用された可能性は考えられるし。

ちなみに、興味深いこととして、劇中劇でさくらの侍女役を演じた4人のドレスのモチーフは、それぞれトランプのマークになってる。
奈緒子ちゃんがスペード、千春ちゃんがハート、利佳ちゃんがダイヤ、そして、苺鈴がクラブ。
4人だったからトランプのマークをモチーフにしたのか、それとも・・・

何はともあれ、クロウカードをトランプと対応させると、面白いことが見えてくる。
それは、さくらの「名前のないカード」の立ち位置。
52枚のいずれでもない、53枚目のそのカードは、すなわち「ジョーカー」になっている。
「ジョーカー」というのは、「何者でもないが、それゆえ、何者にでもなれる」カード。
これがまずポイントになる。

さくらの無敵の呪文

それを踏まえた上で、「名前のないカード」の生まれたシーンを思い出して欲しい。

原作では、知世からの電話で、急がないと間に合わないことを告げられたとき、知世から「さくらちゃんには無敵の呪文がありますもの！」と背中を押され、さくらは「・・・絶対、だいじょうぶだよ」と、答えている。
一方、アニメ版では、知世のセリフはカットされ、代わりに、さくらのこぼした涙から魔法陣が展開し、「名前のないカード」が生まれている。
つまり、「名前のないカード」は、「絶対だいじょうぶだよ」というさくらの無敵の呪文の具現として表現されていると見ることも出来る。
もちろん、純粋に小狼への気持ちの具現としてみる解釈も可能だけど。

ここで重要なのが、「絶対だいじょうぶだよ」の呪文自体は、具体的に何かを生み出したりはしないということ。
もちろん、気持ちの変化を与えたり、次の行動を引き起こしたりして、その結果として、何かを生み出すことに繋がってはいくんだけど。
けど、そこで生み出されたものは、あくまで呪文によって引き起こされた行動の結果であって、呪文自体は何も生み出していないことに注意しないといけない。
そして、それがゆえに、呪文によって引き起こされる行動は多彩なものになり、結果として、生み出されるものも多彩になる。
つまり「絶対だいじょうぶだよ」の呪文は、「何も生み出さないが、それゆえ、何でも生み出すことが出来る」呪文となっている。
ある意味、創造の極点というか。
そして、これはまさに、先に述べた「ジョーカー」の立ち位置になっている。

「創造」の条件

さて、そんな「何者でもないが、それゆえ、何者にでもなれる」「何も生み出さないが、それゆえ、何でも生み出せる」「創造の極点」とも呼べる「名前のないカード」だけど、実は、その力を最大に発揮するには、一つ、条件が必要なことに気がつくだろうか。
それは、「余白」の存在。
「何者でもない」がゆえに何者にでもなれる、というのであれば、すでに何者かであったのならば、そこからなれる者の範囲というのは、自然と限られてきてしまう。
同様に、「何も生み出さない」がゆえに何でも生み出せる、というが、すでに何かが生み出されていたならば、そこに加えて生み出せるものは、自然と限られてきてしまう。

何か別の姿になるには、今の姿を捨てなければならない。
何かを生み出すには、今あるものを失くさなければならない。
「破壊」と「創造」ーー
そう、「創造」の前には、先立って「破壊」がなければならない。

「希望」を生み出すもの

ここまでくれば、自分が何を言いたいのかは、大体分かってきたんじゃないかと思う。

そう、「名前のないカード」が「創造の極点」とも呼べるカードなら、逆に、「無」のカードは、「破壊の極点」とも呼べるカード。
それは、今あるものを、何もかも無くしてしまうカード。
劇中でケロちゃんも言ってた通り、なんとも物騒なカードである。

けど、これが「創造の極点」たる「名前のないカード」と組み合わさることで、その「破壊」の意味は、大きく変容させられることになる。
その「破壊」は、「創造」を生み出すための「破壊」ーー

「無」のカード単体では、現状を破壊することしか出来ない。
破壊した後には、何も残らない。

一方、「名前のないカード」単体では、現状を変えることは出来ない。
何もかも生み出すことは出来るかもしれないけど、今すでにあるものは、変わらずそのまま残り続ける。

しかし、この2つが組み合わさればーー
そう、何もかもを変え、何もかもを創っていくことが出来るようになる。
今ある枠を壊し、飛び越え、何者にだってなることが出来る。
それこそが、「希望」。

何もかもを無くす「無」のカードと、何もかもを生み出す「名前のないカード」が組み合わさることで、それは「希望」のカードとなった。
「希望」のカードは、何もかもを無くし、それがゆえに、何もかもを創っていくことが出来るカードだと言える。

思い返してみれば、さくらカードへの変換も、破壊と創造によって成り立っていた。
さくらの呪文を思い出して欲しい。

「クロウの創りしカードよ、古き姿を捨て、生まれ変われ。
　新たな主、さくらの名の下に！」

このように、クロウカードはクロウカードでなくなることで、さくらカードとして生まれ変わることが出来ている。
「希望」のカードは、そんなさくらカードの象徴なのかもしれない。

小狼の「一番大事な想い」

こうして「希望」のカードがどういったカードなのかを掴むと、小狼がなぜ大丈夫だったのかが見えてくる。

そう、小狼は、「一番大事な想い」を失わなかったわけではない。
「希望」のカードによって、小狼は確かに一度、「一番大事な想い」を失っている。
そしてまた、さくらに新しく恋をした。

古き恋心はなくなり、そして、新たな恋心として生まれ変わった。
それゆえ、小狼は大丈夫だった、と。

劇中でも、小狼は言っている。

「この気持ちがなくなっても、俺、またさくらのこと・・・」

そう、何度だって、何度だって、さくらがさくらである限り、小狼はさくらに恋をする。
何度だって、さくらに新しく恋することが出来る。
だから、さくらと小狼がいれば、二人は「絶対、だいじょうぶ」なのだ。

実のところ、この考えに至ったのはけっこう最近で、『宇宙パトロールルル子』を観たのが大きい。
（余談だけど、『宇宙パトロールルル子』も非常に面白い作品だったので、オススメ）

ルル子
「宇宙とか虚無とか、中学生の私には全然意味分からない。
　でも、これだけは分かる。
　これは、私がノヴァくんを好きっていう気持ち。
　何度奪われても、この想いはもう、絶対に消えることはないの。
　ねぇ、ノヴァくん、覚えてる？
　あたしね、嬉しかったんだ。
　二人で頑張ろうって、あなたは言ってくれた。
　その、たった一言で私の中に生まれた、光を超えて無限に広がり続けるこの想いが、
　まだ13歳の普通の中学生だった私の世界を変えたの！」

（『宇宙パトロールルル子』より引用）

何度恋心を失っても、何度だって恋してやる、この恋心が消えることは、決してない、という、ルル子の強い想いが、とても印象的。

さくらカードと陰陽のバランス

ところで、「無」のカードがさくらカードになったあと、陰陽のバランスの問題はなくなったのだろうか。

「無」のカードが「無」のカードのままさくらカードになっていれば、この陰陽のバランスは、何も問題がなかった。
52枚のカードが陽を受け持ち、「無」のカードが陰を受け持てばいいだけだから。

けど、実際には「無」のカードは「無」のカードではなくなり、「希望」のカードになってしまった。
はてさて、それでバランスに問題は生じないのだろうか・・・？

これに関しては、そもそもさくらカードでは、陰陽について考える必要がないんだろうなぁ、というのが、自分の考え。
それは、あくまで持論だけど、クロウの「闇の力」とさくらの「星の力」では、性質に差があると思っているから。

電力と磁力

以下は自分の考えだけど、クロウの「闇の力」は、電力に近いんだと思っている。
一方、さくらの「星の力」は、磁力に近いんだと思っている。

電気というのは、プラスとマイナスがあるわけだけど、実体として存在するのは「電子」（＝マイナス）だけで、その偏り具合が見かけ上のプラスとマイナスを生み出している。
そして、マイナスの少ない側（＝プラス）に向かってマイナスの多い側（＝マイナス）から電子が流れることで、電気は仕事をする。
このとき、電力が発生する代わりに、電子の偏り具合はどんどん減っていってしまう。
だから、化学反応を使ったり（電池）、運動エネルギーを使ったり（発電機）して、電子の偏り具合を保ち続ける必要がある。

一方、磁気というのは、「電子」が動いたときに、その周りに発生する。
電磁石とかだと、その電子の流れは電力によって生み出されるわけだけど、永久磁石とかだと、（厳密にはスピンとか出てきてよく分からないんだけど、イメージとしては）電子が原子核の周りを回っていることで生み出される。
なので、永久磁石は、外部から電力を供給することなく、ずっと磁力を保ち続けることが出来る。

「闇の力」というのはまさに電気のようなもので、そこに偏りを発生させることで、魔法という効力を生み出しているんだと思っている。
52枚分のカードにはプラスを、「無」のカードにはマイナスを与え、プラスの力を持ったカードは、そのプラスの力を放出することで、魔法を発現する。
ただ、そうするとカードに込められたプラスの力はどんどん減っていってしまうから、術者が定期的にプラスの力を補充していってやらないといけない。
あと、当然プラスの力をマイナスの力にぶつけても、相殺されて0になってしまうので、プラスの力はマイナスの力には一切通用しない。

一方、「星の力」というのはまさに永久磁石のようなもので、カードに込められた魔力がその中で動き続けることで、魔法という効力を生み出しているんだと思っている。
ここでは、何かを陰陽に分ける必要すら存在しないーーというか、厳密にいうと、陰陽に分けることがそもそも出来ない。
だって、そこに陰陽の偏りはないわけだから。
（これは、N極だけの磁石やS極だけの磁石を作れないようなもの）

ちなみに、なぜ自分がこのように考えているのかというと、クロウ、それにエリオルが、次のように言っているから：

クロウ
「その杖には、新しい力が宿っています。
　太陽でも月でもない、あなただけの『星』の力が。
　たとえ今は小さな光でも、
　自分で光りつづける星の力が・・・」

（『カードキャプターさくら』より引用）

エリオル
「しばらくは、わたしがカードに残した闇の力で
　カード達は活動できますが、
　ずっとそのままではやがて魔力を失い、
　クロウカード達はただのカードに戻ってしまう」

（『カードキャプターさくら』より引用）

つまり、闇の力は自然と失われていってしまうのに対し、星の力はずっと残り続けることが出来る、と。
これはまさに、電池と磁石の関係。
さらに、今回の映画で陰陽の話が出てくると、それはまさに電気のプラスとマイナスの話になっている。

原作のクロウカード

ちなみに、アニメ版、そして「封印されたカード」では、52枚のクロウカードと「無」のカード1枚で陰陽のバランスをとっていると言っていたわけだけど、原作の方はどうなのかな、という話。

これもあくまで自分の考えで、公式にそういう設定があるわけではないんだけど、実は、原作は原作で、うまいこと陰陽のバランスをとってるんじゃないかな、と。

そう思うきっかけになったのは、これまたクロウカードの枚数。

原作のクロウカードの枚数は19枚で、すごく中途半端な枚数になっている。
タロットカードを意識するなら、大アルカナの22枚とかになりそうなもの。
それに、19というのは素数。
太陽と月、というように、陰陽を感じさせる要素があるわけだから、偶数にして、太陽所属の陽のカードと、月所属の陰のカードにキレイに分かれるようになっているのが普通だと思うんだけど。
実際、「光」と「闇」はそれぞれケルベロスとユエの第一配下のカードと言及されてるし、「火」と「地」はケルベロスの属性、「風」や「樹」はユエの属性と言及がされている。

と、ここで、ある特殊なカードの存在に気付くだろうか。
それは、「鏡」。
さくらの対の存在とも言える、「鏡」のカード。
なら、逆に考えれば、さくらもカード達の中に入れてしまえば・・・
さらにいうと、守護者であるケルベロスとユエも加えれば、数は22になり、大アルカナに揃うことになる。

そして、以下のような感じで、陰陽のバランスがとられていたんじゃないかな、と：

	陽	陰
主	さくら	鏡
守護者	ケルベロス	ユエ
第一配下	光	闇
四大元素	火、地	水、風
その他	剣、灯、雷、花、跳、迷	盾、影、消、樹、翔、幻

なお、その他についてはそれっぽいのに分けてるだけだけど、意外と対応が取れてたり。
（剣と盾、花と樹、など）
CLAMP（というか大川さん）がここまで考えてたかどうかは分からないけど、考えててもおかしくはなさそう。

---

以上で、考察は終わり。
めっちゃ長文になったけど、語りたいことは語りつくせたかな。

今日はここまで！

劇場版 カードキャプターさくら 封印されたカード [DVD]

カードキャプターさくら(1) (KCデラックス)

ちょびっツ（１） (ヤングマガジンコミックス)

宇宙パトロールルル子 (初回生産限定盤) [Blu-ray]

Karabiner-Elementsで英数/かなの切り替えをトグルにしてみた。

Macを使っててちょっと困るのが、英数/かなの切り替えがトグルでないこと。

まぁ、トグルでなくて明示的に指定した方が分かりやすい、という人もいるけど、仕事では（残念ながら）Windowsを使っているので、MacとWindowsで操作が違うのは、けっこう面倒。
あと、自分の場合、（絵を描くわけでもないけど）マウスの代わりにペンタブを使っているので、ペンを持った状態のままキーを叩こうとすると、右手の親指を動かすことが出来ず、「かな」キーを押しづらいというのもある。

そんなわけで、以前はKarabinerを使ってトグル切り替え出来るようにしてたんだけど、困ったことに、MacがSierraになったときに、Karabinerは使えなくなってしまった。
これに困った人はたくさんいて、代替ソフトがいろいろ出てたんだけど、どれも微妙な感じ。

なので、ずっと我慢して、かなに切り替える場合、右手を下に引いて右手の人差し指で「かな」キーを押すとかいう無茶をやってたんだけど、久々に調べたら、Karabinerの後継であるKarabiner-Elementsで英数/かなのトグル切り替えが出来るようになったとのこと。
そこで、Karabiner-Elementsを使って英数/かなのトグル切り替えを出来るようにしてみた。

ダウンロード＆インストール

ダウンロードは、以下のサイトから：

Karabiner - Software for macOS

ダウンロードしたら、dmgファイルを開いて、その中に入っているpkgファイルをダブルクリックすれば、インストーラが起動する。
あとは、インストーラの指示に従ってインストールすればOK。

インストールが終われば、アプリケーションフォルダにKarabiner-Elements.appとKarabiner-EventViewer.appがインストールされる。

設定

ここで行う設定は、以下の2つ：

• 「英数」キーを押したとき、英数/かなをトグルする
• 'ろ'のキー（右Shiftの左側のキー）を押したときに、バックスラッシュ（\）を入力し、Shift+'ろ'を押したときに、アンダースコア（_）を入力する

後者の設定もWindowsのキーマップに似せるためのもので、何も設定してないとバックスラッシュではなくアンダースコアが入力されるので、を使うときに地味に不便だったりする。

何はともあれ、まずはKarabiner-Elementsを起動。
アプリケーションフォルダを開き、Karabiner-Elements.appを開く。

起動すると、おそらく次のような設定ダイアログが表示されるはず。

表示されない場合、メニューバーにあるKarabiner-Elementsのアイコンをクリックし、そこから"Preferences..."を選択すればいい。

この設定ダイアログにはいくつかのページがあり、上の画像のページ（"Simple Modifications"）では、あるキーを別のキーに置き換えるということが出来る。
ただ、今回はそんなシンプルな話ではないので、ここは使わない（使えない）。

ちなみに、"Virtual Keyboard"ページでは、キーボードの種類が選べるので、適切なキーボードになっているか、確認しておいた方がいい。

今回行うような複雑な設定には、"Complex Modifications"ページを使う。
ただ、その前にJSONファイルを用意しておかないといけない。

まず、ターミナルなどを使って、以下のフォルダを開く：

$ open ~/.config/karabiner/assets/complex_modifications/

ここに、適当な名前のJSONファイル（例えば、my_option.json）を用意して、以下の内容を入力して保存：

{
  "title": "自分用の設定",
  "rules": [
    {
      "description": "英数キーで入力をトグルできるようにする",
      "manipulators": [
        {
          "type": "basic",
          "description": "入力ソースが英字の場合、ひらがなにする（入力ソースがひらがなの場合、上書きの必要なし）",
          "from": { "key_code": "japanese_eisuu" },
          "to": [ { "key_code": "japanese_kana" } ],
          "conditions": [
            {
              "type": "input_source_if",
              "input_sources": [ { "language": "en" } ]
            }
          ]
        }
      ]
    },
    {
      "description": "'ろ'にバックスラッシュ、Shift+'ろ'にアンダースコアを割り当てる",
      "manipulators": [
        {
          "type": "basic",
          "description": "'ろ'にバックスラッシュを割り当てる（Shift+'ろ'は、上書きの必要なし）",
          "from": { "key_code": "international1" },
          "to": [ { "key_code": "international3" } ]
        }
      ]
    }
  ]
}

この詳細については、後ほど。

ファイルが用意できたら、"Complex Modifications"ページを開き、"Add rule"をクリック。

以下のようなシートが表示されるはずなので、「自分用の設定」の"Enable All"をクリック。

すると、以下のようになるはず：

これで完成！

ちゃんと「英数」キーで英数/かなのトグルが出来るし、'ろ'でバックスラッシュ、Shift+'ろ'でアンダースコアが入力されるようになってるはず。

設定の詳細

ここからはオマケ。
上のJSONファイルでうまくいかなかったり、自分でKarabiner-Elementsの設定を行いたい人向け。

まず、Karabiner-Elementsの動作イメージを説明しておくと、Karabiner-Elementsが起動している場合、入力デバイス（キーボードやマウス）で起きたイベント（キーが押された、など）を、直接Macに渡すのではなく、Karabiner-Elementsを経由させてからMacに渡す、という感じになっている。
なので、JSONファイルでは、どのイベントをどのイベントに変換するか、というのを記述することになる。

詳細については、karabiner.json Reference Manual - Karabiner - Software for macOSを参照。

JSONファイルの構成

"Complex Modifications"のルールを記述するJSONファイルの全体構成は、以下のようになっている：

{
  "title": "(ルールセットのタイトル)",
  "rules": [
    {
      "description": "(ルール1の説明)",
      "manipulators": [
        {
          // 変換操作の内容1-1
        },
        ...
        {
          // 変換操作の内容1-n
        }
      ]
    },
    ...
    {
      "description": "(ルールmの説明)",
      "manipulators": [
        {
          // 変換操作の内容m-1
        },
        ...
        {
          // 変換操作の内容m-n
        }
      ]
    }
  ]
}

変換操作の記述

変換操作の記述は、以下のような感じ：

{
  "type": "basic",
  "description": "(変換操作の説明)",
  "from": {
    // 変換元のイベント
  },
  "to": [
    {
      // 変換後のイベント1
    },
    ...
    {
      // 変換後のイベントn
    }
  ],
  "conditions": [ // 変換操作を行う条件（オプション）
    {
      // 条件1
    },
    ...
    {
      // 条件m
    }
  ]
}

なお、toの他に、to_if_alone、to_if_held_down、to_after_key_up、to_delayed_actionなどもあるけど、省略。
基本的にはtoを使えばいいと思うので。

あと、conditionsはあってもなくてもいい。
指定した場合、条件が満たされたときだけ変換操作が行われるようになる。
今回の場合は、入力が英数のときだけ、「英数」キーを「かな」キーとして働かせることになるので、そのときに使っている。

fromに関して

変換元のイベントの記述は、以下のような感じ：

"from": {
  "key_code": "(入力されたキーのキーコード)",
  // 以下はオプション
  "modifiers": {
    "mandatory": [ // 必須なキー（組み合わせたときにだけ働く）
      "(必須なキーのキーコード)",
      ...
    ],
    "optional": [  // 一緒に押せるキー（組み合わせても働く）
      "(一緒に押せるキーのキーコード)",
      ...
    ]
  }
}

なお、key_codeの他に、consumer_key_code、pointing_button、anyというのもあり、そのいずれかを指定することになっている。
ただ、基本的にはkey_codeでOKのはず。

modifiersは、指定しなかった場合、他のキーと組み合わせたときには働かなくなる。
少しややこしいのだけど、以下のように考えればいいと思う：

やりたいこと	modifiersの指定
他のキーと一緒に押されたときは、変換操作をやりたくない	modifiersなし
特定のキーと一緒に押されたときだけ変換操作をやりたい	modifiersでmandatoryを指定する
特定のキーと一緒に押されたときにも変換操作をやりたい	modifiersでoptionalを指定する

例えば、今回だと、'ろ'のキー（"international1"）が押されたときにバックスラッシュのキー（"international3"）が押されたイベントを送るようにしてるんだけど、Shiftと一緒に押されたときにも変換処理が行われてしまうと、縦棒（|）が入力されてしまう。
なので、modifiersなしにすることで、Shiftと一緒に押されたときにはバックスラッシュのキーではなく'ろ'のキーがそのまま送られるようにしている。
（結果として、Shift+'ろ'でアンダースコアが入力される）

toに関して

変換後のイベントの記述は、以下のような感じ：

"to": [
  {
    "key_code": "(変換後のキーのキーコード)",
    // オプション
    "modifiers": [
      "(一緒に押されたとするキーのキーコード)",
      ...
    ],
    "lazy": false,
    "repeat": true
  },
  ...
]

なお、key_codeの他に、consumer_key_code、pointing_button、shell_command、select_input_source、set_variableというのもあり、そのいずれかを指定する。
基本的にはkey_codeのはず。

ちなみに、select_input_sourceを使うことで、入力ソースを切り替えるイベントを送ることも出来る。
最初はこれを試して、Safariとかでは問題なく動いたんだけど、ターミナルで入力ソースが切り替わらないという自分としてはかなり致命的な問題が生じたので、素直にキーコードを送るイベントを使うようにしている。

あと、lazyは他のキーが押されるまでイベント変換を遅延させるかどうかという設定、repeatは繰り返し変換を行うかどうかという設定。
まぁ、明示的に指定する必要があるケースはあまりなさそう。

conditionsに関して

変換操作を行うかどうかの条件にはいくつかタイプがある：

タイプ	説明
frontmost_application_if, frontmost_application_unless	アプリのバンドル名、ファイルパスの条件
device_if, device_unless	デバイスの条件
keyboard_type_if, keyboard_type_unless	キーボードの種類（ansiやjisなど）の条件
input_source_if, input_source_unless	入力ソースの条件
variable_if, variable_unless	変数の条件

それぞれのタイプで、指定する内容は異なってくる。

今回は、入力ソースが英字のときにだけ変換操作を行いたかったので、input_source_ifを使ってる。

input_source_ifは、以下のような感じ：

{
  "type": "input_source_if",
  "input_sources": [
    {
      "language": "(言語の正規表現)",
      "input_source_id": "(input source idの正規表現)",
      "input_mode_id": "(input modeの正規表現""
    },
    ...
  ]
}

なお、language、input_source_id、input_mode_idはそれぞれオプショナルなので、特に問題がなければlanguageを指定しておくだけで十分。
ちなみに、これらの値はKarabiner-EventViewer.appを起動して、"Variables"ページを見ると、確認できる。

キーコードの確認について

あと、キーコードの確認も、Karabiner-EventViewer.appを起動すると、出来る。
"Main"ページを開いて適当なキーを押すと、そのキーのキーコードがテーブルの"name"列に表示されるので、それを使えばいい。

なお、"japanese_kana"や"japanese_eisuu"はエイリアスで、本来の名前はそれぞれ"lang1"、"lang2"となっている。
どんなエイリアスが使えるのかは、コードを確認する必要がある。

以下のリポジトリで、src/share/types.hppを参照するといい：

今日はここまで！

pLucidをいじってみた。（その2）

前回はLucidの処理系であるpLucidについて紹介した。

今回はLucidについて触れていきたい。

Lucidとは？

Lucidというのは、前回も触れたとおり、データフロープログラミング言語の1つ。

データフロープログラミング - Wikipedia

Lucid (プログラミング言語) - Wikipedia

自分がこの言語に触れて一番変わってるなぁと思ったのは、変数が数列のように履歴を持つというところ。
なので、プログラミングが、漸化式を書くような感じになってたりする。
まぁ、これは実際の例を見てみないと分かりづらいと思うので、後で。

Hello, world!

とりあえず、新しいプログラミング言語に触れるなら、まずこれでしょ、ということで、Hello, world!から。

LucidでHello, world!を書くと、次のようになる：

`Hello, world!'

ちょっと注意が必要な点としては、最初のはクォートはバッククォートで、最後のはシングルクォートだということ。

これをpLucidで実行するには、まず適当なファイルに保存して（ここではhelloというファイルとする）、以下のようにコンパイル：

$ lucomp hello

ただし、これはlucompから呼び出されるpass1、pass2、pass3、pass4、pass5が、PATHの通った適当な場所に置かれているのが前提。
もしこれらがPATHの通った場所に置かれていない場合、以下のようにして、パイプで処理をする：
（ここではpass1〜pass5がカレントにあると仮定）

$ ./pass1 hello | ./pass2 | ./pass3 | ./pass4 | ./pass5 hello

すると、hello.iという中間のバイナリファイルが生成される。

中間のバイナリファイルが生成されたら、次のように実行：

$ luval hello.i

さて、実行したらどうなるのかというと、こうなる：

$ luval hello.i
Evaluation begins .........

output(  0) : `Hello, world!' 
output(  1) : `Hello, world!' 
output(  2) : `Hello, world!' 
output(  3) : `Hello, world!' 
output(  4) : `Hello, world!' 
...（省略）...
output(995) : `Hello, world!' 
output(996) : `Hello, world!' 
output(997) : `Hello, world!' 
output(998) : `Hello, world!' 
output(999) : `Hello, world!'

$

なんじゃこりゃ！？、ってなるよねw

ただ、これがつまり、変数が数列のように履歴を持つということを意味している。

Lucidでは、一番外側にある式が評価され、その値が出力となる。
このHello, world!では、`Hello, world!'という文字列が式になっていて、その値が評価される。

だったら、`Hello, world!'が一回表示されて終わりなのでは？となりそうだけど、そうはならない。
というのも、これは、Lucid的には次のような意味になるから：

そう、outputという変数は、単一の変数ではなくて、数列のように、0番目の値、1番目の値、2番目の値、・・・と、複数の値を含んでいるようになってる。
なので、pLucidはその値を順番に出力していった、と。
（実装的に上限が1000で固定になってるので、999番目の値で出力は止まってる）

うん、変な言語w

Hello, world!（真）

じゃあ、一回だけHello, world!を出力して終わりにしたかったら、どうするか。

数学的に考えれば、次のように場合分けすればいいことになる：

なお、eodは、データの終わりということ。

これをLucidで書くと、次のようになる：

`Hello, world!' fby eod

さっきと同じようにコンパイルして実行すると、以下のような出力になる：

$ ./luval hello.i 
Evaluation begins .........

output(  0) : `Hello, world!' 

Statistical Information about the evaluation
# of memory buckets created    =          0
# of space/time/place tags created   =          3

このとおり、1回だけ出力され、終了する。
（それ以外の出力もなんかいろいろ出てるけど・・・）

ここでポイントとなっているのは、fbyという演算子。
これは"followed by"の略で、1回目は左項が評価され、2回目以降は右項が評価されるようになっている。
なので、output(0)は左項が評価されて`Hello, world!'になり、output(1)以降は右項が評価されてeodとなるので、データの終了ということでそこで出力が停止する、と。

ちなみに、fbyは右結合なので、次のように書くと、2つ出力して終わる感じになる：

`Hello, world!' fby `Good bye!' fby eod

実行例は、以下：

$ ./luval hello.i 
Evaluation begins .........

output(  0) : `Hello, world!' 
output(  1) : `Good bye!' 

Statistical Information about the evaluation
# of memory buckets created    =          0
# of space/time/place tags created   =          4

理屈としては分からなくもないけど、なんとも分かりにくい（＾＾；
アイディアは面白いと思うんだけど、もうちょっと分かりやすい記法はなかったものか・・・

---

なお、今自分がいじっているGitHubのリポジトリは、luvalを実行するとセグメンテーションフォールトが発生するので、ここでの実行例は、おそらくGCCでオリジナルのコードをそのままビルドして作られたバイナリを使ってる。
自分のいじってる方も、そのうちちゃんと動くようにしたい。

今日はここまで！

pLucidをいじってみた。（その1）

最近、pLucidをいじってるので、それについて少しずつ書いていこうと思う。

pLucidとは？

pLucidというのは、Lucidというデータフロープログラミング言語の処理系の1つ。

データフロープログラミング - Wikipedia

Lucid (プログラミング言語) - Wikipedia

新年の挨拶と今年やっていきたいこと。（2018年） - いものやま。で書いた通り、最近データフロー指向というのに興味を持っている。
そこで、どんなデータフロープログラミング言語があるのかなとwikipediaを見てみたんだけど、いくつか言語がリストアップされているものの、HDL（ハードウェア記述言語）でなく、（LabVIEWのような）ビジュアルプログラミング言語でもないものとなると、かなり少ない。
Lucidはそんな条件を満たす言語の1つで、しかもある程度情報があり、pLucidという処理系も一応ある。
ということで、このpLucidをちょっといじっていこうかな、と。

Lucidは、wikipediaによれば1976年に登場した言語で、けっこう古い言語といえる。
C言語が登場したのが1972年とかで、標準化されたのは1990年（ANSI C）。
そして、pLucidはC言語で書かれてるんだけど、そんなわけで、標準化される前のK&Rの文法だったりする。

そんなpLucid、Google Codeにコードがアップされていたんだけど、Google Codeが閉鎖されたので、今はGitHubにコードは移っている。

plucid - Google Code

ただ、Google CodeからGitHubへリポジトリをエクスポートしている人は何人かいて、どれが本流なのかがよく分からない・・・
まぁ、どれもオリジナルからほとんど変更していないようだけど。

ということで、とりあえず適当な人のリポジトリからフォークして、自分のリポジトリを作ってみた。

ちなみに、K&R時代のC言語で書かれてたこともあって、かなりハチャメチャなコード。
グローバル変数だらけだし、型もかなり適当。
マクロでけっこう無茶なことやってたり、もう何が何やら・・・

そもそも、Clangだと普通にビルドエラーが起きてビルドが通らなかったり（＾＾；

なので、とりあえずコードのフォーマットと明らかにおかしいところを修正して、とりあえずビルドエラーと警告を全部消した。
これだけで約33klocの差分w
ほぼすべて書き直しw

これで一応ビルドは出来るようになって、ソースを中間のバイナリファイルに変換するところまでは動くようになった。
けど、このバイナリファイルを解釈させて実際に動作させるプログラムを動かすと、セグメンテーションフォールトになる（＾＾；
標準のmalloc使えばいいのに、なんか自前で独自のメモリ管理やってるし、グローバル変数だらけで初期化の順番も怪しかったりするんで、たぶんその辺りが原因。
この辺りも、あとで解決していかないとなぁ・・・

さて、肝心のLucidについては、次回で。

今日はここまで！

2017年に初めて遊んだゲーム、ベスト3。

2016年に引き続き、2017年に初めて遊んだゲームで、特に気に入ったものを選んでみた。

2016年、2015年のは、以下から：

なお、2017年は8月くらいからあまりゲームを遊べなかった。
なので、ホントは5つ取り上げたいんだけど、4位と5位が難しかったので、上位3つだけ。
この3つは、とりあえず順位はつけたけど、どれも甲乙つけがたいレベルで好き。

第3位「ボブジテン」

2017年のゲームマーケット春で発表された、TUKAPONさんのゲーム。

ルールは簡単で、お題のカタカナ語を、カタカナ語を使わないで説明しよう、というもの。
ホントこれだけのルールなのに、めっちゃ面白いw

「ほら、えっと、あれだよ、あれ！」みたいに、言いたい言葉がなかなか出てこないw
普段、どれだけカタカナ語に頼りきってるのかを実感するw

例えば、お題で『エンターキー』とか出てくると、「パソコンのキーボードで入力を確定させるときに押すキー」と言いたいんだけど、「パソコン」も「キーボード」もアウトw
じゃあ、パソコンってカタカナ語を使わないでどう説明するよ、って、ほら、電脳的な箱とか、そんなパワーワードが出てくるw
お題を出す方は、ああでもない、こうでもないと頭を捻るし、回答する側も、まさに忖度を働かせて答えを探っていくのが面白い。

そんな、ただでさえ面白いゲームに、さらに華を添えるのが、トニーの存在。
お題を決めるときにトニーが出てくると、出題者はカタカナ語に加え、助詞も使ってはいけないという縛りが追加される。
なので、「えー、球、二人、棒、叩く、んー、あっ、松岡修造！」みたいな片言にw
そして、トニーが出てるわけでもないのに、なぜか不思議とみんな片言になっていくというねw

これは面白いので、オススメ。
ちなみに、拡張で「ボブジテン2」や「わたしのボブジテン」というのも出てたりする。

第2位「アノウ」

Trick Taking Partyゲーム賞2017に応募された、与左衛門さん作のトランプを使ったトリックテイキングゲーム。
ちなみに、大賞受賞作。

（今気づいたけど、2017ってことは、今年もやるのかな？w）

アノウというのは、石垣造りの技術者集団で穴太衆（あのうしゅう）というのがいて、そこからつけられた名前とのこと。
実際、トランプを石に見立てて、立派な石垣を作っていくのがこのゲームの目的になっている。

穴太衆 - Wikipedia

各トリックで、1位の人はプレイされたカードから1枚、2位の人は2枚を獲得し、自分の場に並べる。
このとき、自分の場には4つの列が用意されていて、各列には同じスートを並べていく。
ただし、列ごとに上限が決まっていて、左から、1枚、2枚、3枚、4枚となっている。
もし上限を超えてしまった場合、その列は1枚あたり-1点となってしまい、逆に、上限以下で抑えられれば、その列は1枚あたり+1点となる。
なので、場の状況と手札とで相談して、取ることが少なそうなスートは左側に、逆にたくさん取ることが出来そうなスートは右側に置いていくことになる。

これがホントによく出来たシステムで、ある程度はカードが欲しいけど、取りすぎたらマイナス点になってしまうので、ヒヤヒヤしながらカードを取っていくことに。
狙ったカードが欲しければトリックを取りにいくのがいいし、枚数が欲しければ2位を狙っていくことになる。
けど、終盤になってくると、自分の場ももう空きがなくなって、取りたくない状況になってくる。
そんなときに、うっかり2位にさせられてしまって、欲しくもないカードを押しつけられたり（＾＾；
そして、これはスートに対するビッドと見ることも出来たり。
取るトリック数に対するビッドはよくあるけど、スートに対するビッドは、かなり珍しいんじゃないかな？

それと、トリックをとって列を作っていくと、写真のような感じになっていって、まさに石垣を作っていってる感じになって、すごくいい。
そして、石を高く積みすぎると、崩落する、とw
トリテはあまりテーマを乗せづらいイメージがあるけど、このゲームはテーマとシステムが見事に一致していて、ホント大賞にふさわしい見事なゲームだと思った。

第1位「クイビット」

可愛い見た目、簡単なルール、対象年齢は7歳から。
そんなゆるふわな雰囲気からは程遠い、ガチゲーム。

ルールはホントに簡単で、手札からカードを1枚選んで一斉に公開し、カエルの駒を進めていく。
カエルの駒が、カエルと同じ色の葉っぱか蓮の花に止まれれば、出したカードは手札に戻り、そうでない場合、出したカードは捨てられることになる。
それを繰り返していって、手札がなくなったら、脱落。
そして、最後の1人だけになるか、誰かを1周遅れにさせたら、ゲーム終了。

これだけのルールなんだけど、読み合いがガチw
他の人がどのカードを出すのかがある程度読めるので、あの人はおそらくこのカードを出すはずで、となるとあの人はこのカードを出すはずだから、と、もうひたすら真剣に計算するw
脳汁出まくりw

大人はみんな、こういうゲームはガチよ、ガチw
大人気ない？ 大いに結構！
真剣に他人を蹴落とし蹴落とされするからこそ、面白いw

と、そんな感じで、可愛い見た目とは裏腹に、ガチで濃厚なバトルが楽しめるのが、このゲーム。

ちなみに、遊んだときに「このゲーム、対象年齢7歳からなんだって」と言ったら、「確かに7歳から遊べると思うけど、これ、子供泣いちゃうよ？」って言われたw
うん、自分もそう思うw
子供でも遊べるかもしれないけど、本当にこのゲームを楽しめるのは、汚い大人だけw
けど、そんな子供でも遊べるゲームを、大人がガチで真剣に遊ぶからこそ、面白い！

今日はここまで！

新年の挨拶と今年やっていきたいこと。（2018年）

あけましておめでとうございます！
今年もよろしくお願いします！

初日の出＠大洗 with 5LINKS and KhodaaBloom

ということで、今年やっていきたいことのリストアップ。

全般

もうちょっとね、更新頻度をね（＾＾；

今年はゲームとアニメに割く時間をちょっと減らそう・・・
代わりに、コードに触れる時間をもっと増やしていきたい。

技術

去年の振り返りでも触れたとおり、今、興味を持ってるのが、コンパイラと実行環境のところ。
それに関して、アウトプットを出していきたいな、と。

具体的には、以下のとおり：

• 『OS自作入門』の続き
• System Verilogやハードウェア周り
• データフロー指向

データフロー指向というのは、聞きなれない言葉だと思うんだけど、これが今自分が注目しているパラダイム。
System VerilogなどのHDL（ハードウェア記述言語）も、大枠としてはデータフロー指向に含まれたりする。

データフロープログラミング - Wikipedia

データフロー指向というのは、まぁ古いパラダイムで、関数型言語の親戚みたいなもの。
関数型言語が発展していく中で、（おそらく実用性、汎用性に難があって）忘れ去られてしまったんだと思うんだけど、これが見直されてくるんじゃないかな、と。

関数型言語が注目されている原因の一つは、並列処理をうまくかけるんじゃないか、という期待があるから。
コアの数が増えてくると、その能力をフル活用するには、処理を複数のタスクに分割し、並列処理をしていってやらないといけない。
けれど、これが普通の手続き型だと、並列処理を間違いなく書くというのは、かなり難しかったりする。
そこで、副作用を持たない関数を使ったり、その解決を遅延させるようにして、並列処理をうまいこと動くようにしよう、と。

ただ、関数型言語（Haskell）に触れてみて分かったのは、そんなにうまい話にはなってないな、ということ。
というのは、確かに、純粋関数の部分だけみれば、その実行の順番には依存がなく、ある関数が他の関数から必要とされたタイミングで処理が実行されるので、人間が処理の順番を考える必要がないようになっている。
けど、ここにモナドが関わってくると、厄介で。
モナドというのは、結局のところ、関数の合成をやっているので、その中の関数は必然的にシリアライズがかかってしまう。
（だから、状態を扱えるようにもなるんだけど）
そして、Haskellの場合、一番トップレベルの関数はmainというIOモナドなので、それだけだとうまく並列化はされない（はず）。
ちゃんと並列処理を行うには、それなりにいろいろやらないとダメらしく、それだけで本が一冊出てるくらい・・・（読んだことはない）

そこで注目したのが、VerilogなどのHDL。
HDLは、本質的に並列な処理を記述するので、データを処理する各モジュールを記述し、その繋がりを定義して、あとはデータを流すだけ、となっている。
実は、これはモナドの考えに近くて、モナドではある一つのデータ（状態だったりリストだったりIOだったり）に関する関数を並べていった1つの関数を定義して、最後にその関数に対象のデータをポンと流す、となっている。
データフロー指向というのはその考え（モナド）の拡張になっていて、モナドだと（暗に）流れていくデータは（そのモナドの中で）１つだけだったけど、どのデータも関数の繋がりの中を流れていくものだとして、各関数の処理と、その関数間のデータの流れを記述していくことになる。

まぁ、ホントにこれでちゃんと処理が進むのか、普通の処理が書けるのかは、だいぶ怪しいと思うので、そういったところも含めて、いろいろ試していかないとなんだけど。
それについては、またそのうち。

---

ここからはオマケ。

一昨年、去年に引き続き、今年も大洗で初日の出を見てきた。

これまではロードバイクで大洗まで自走してたんだけど、今年は体調も不安だったので、別の方法で。
そう、5LINKSが今年はあるからねw

出発〜水戸

12月31日の午前中に水戸のビジネスホテルを予約し、年越しそばを食べてからの出発。
最寄駅まで5LINKSで行った後は、輪行状態にして輪行。
柏駅で特急券を購入し、特急ときわに乗れば、あっという間に水戸に到着w

今回泊まったのは、コートホテル水戸というビジネスホテル。

ここがなかなかに優秀だった。
水戸駅から徒歩10分弱と近く、素泊まりで4,500円と安い。
1Fにはデニーズ、近所にはマクドナルド、それにセブンイレブンも。
部屋も清潔で、加湿機能付きの空気清浄機も置いてあり、ユニットバスではあるものの、アメニティもバッチリ。
さらには1Fには無料のコーヒーメーカーまであって、至れり尽くせり・・・
もちろん、折りたたんだ自転車も、嫌な顔されず、ちゃんと室内に持っていけた。
一昨年泊まったビジネスホテル六号に爪の垢を煎じて飲ませたい。。。

さて、そんなわけで21時にチェックインして、セブンイレブンで軽い朝食を確保し、ジルベスターを見ながら年を越して、4時まで仮眠・・・
だったんだけど、枕が合わなかったのか、全然眠れなかった（＾＾；

水戸〜大洗

軽い朝食を食べ、シャワーを浴びたら、チェックアウト。
輪行状態を解除し、ライトの電池が切れかかってたのでセブンイレブンで購入して、出発したのが5時20分頃。

ルートは簡単で、国道51号をひたすら走っていくだけ。
そして、途中で県道2号に入れば、大洗はすぐそこ。
距離にして、10km強といったところ。

途中、県道2号に入ったところから、渋滞がすごいことになってた。

みんな、大洗海岸を目指してるのね・・・
まぁ、自転車なんで、渋滞もなんのその、華麗にスルーしていくのだけど。

そんなこんなで、6時頃に大洗駅に到着。

駅にはラッピングバスも停まってた。

海岸近くのコンビニはトイレが行列になってるのが必至なので、ここでトイレを済ませ、いつもの海岸へ。

と、ここで思わぬ遭遇がw
鳥居下の交差点に行ったら、なんと、KhodaaBloomの白いFarnaに乗った人が！
おそらく、去年、潮騒の湯に行ったときに停めてあった人！

！！？
まさか自分以外にもコーダーブルーム乗りが大洗に… pic.twitter.com/faYlAG5dqK

— やまいも@技術書典7【え23C】(3階Cホール) (@yappy0625) 2016年12月31日

思わず声をかけ、写真を撮らせてもらってしまったw
そのあと、自分はそそくさと退散してしまったけど、今思えば、もうちょいいろいろと話しておけばよかったな（＾＾；

初日の出

さてさて、そんなことがありつつ、初日の出。

今年はけっこう雲がかかってたけど、無事見れたので一安心。

ちなみに、ガルパンの立て看は、今年もあったw

潮騒の湯

初日の出も見終わって、じゃあ初詣に行こうと思ったんだけど、ここで一つ困ったことが。
なんと、持ってきた自転車用の鍵が、壊れてしまっていて使えないという事態に。
ママチャリとかならいざ知らず、5LINKSの自転車は10万はするので、さすがにこれを鍵なしで停めておくのは怖すぎる・・・

ということで、一旦お茶を濁すべく、潮騒の湯へ。
潮騒の湯なら、最悪輪行状態にすればフロントで預かってもらえると思ったので。

この読みはドンピシャで、輪行状態にして、フロントで預かってもらえることになった。
ホント、助かった・・・

湯けむり作戦セットをチョイスして、まずはご飯。
お刺身とあんこう鍋のセット。

あんこう鍋は、最初食べたときに食べ方がよく分かってなくて、骨のある部分をガリっとやっちゃって失敗したんだけど、それで学んだので、今回は骨のある部分はちゃんと取り除いて。
そうやって食べると、ぷりぷりの白身がすごく美味しいね、これ。
お刺身も美味しくて、大満足。

鍵をゲットしに

ご飯を食べた後は、お風呂に入って、そのあと、ちょいと検索。
調べてみると、自転車屋はいくつかあるっぽかったけど、多分お休み・・・
と、ここで、100均にならもしかして売ってるんじゃないかと思いつき、検索。
すると、キャンドゥが大洗にあることが発覚！
さっそく向かってみた。

ちなみに、潮騒の湯を離脱するときにちょいと見てみたら、あの白いFarnaがやっぱり停まってたw

さて、まず自転車屋を見て回ったけど、どこも予想どおりでお休み。

なお、関係ないけど、寄せ木戦車専門店なんてのがあったw

クオリティすごっ！

で、肝心の100均・・・
ここで無事、鍵をゲット！
もし、鍵をゲットできなかったら、今回はいろいろ諦めて帰るしかないと思ってたので、これで一安心。

大洗シーサイドホテル

鍵も無事手に入ったことだし、磯前神社に初詣に行こうと思ったんだけど、ズラっと長い行列が・・・
これはちょっと待って、お昼時を狙ったほうがいいんじゃないかな、と大洗シーサイドホテルに行ってみた。

フロントでは、巨大ボコと新年のボードがお出迎え。

そして、レストランで戦車ケーキセットを注文。

このケーキセット、普通に美味しいんだよね。

そのあと、メニューにあったあんこう天丼が美味しそうだったので、食べきれるかどうか少し不安だったけど、注文。

いやー、これも美味しかった。
あんこうの身とあん肝も揚げられてたり。
そして、ボリュームたっぷりw

磯前神社

お腹もかなり膨れたので、磯前神社へ初詣。
ちなみに、行列は全然短くなってなかった（＾＾；

寝不足でかなり朦朧とした状態で列に並び、参拝するのに1時間くらいかかったw

散策〜帰路へ

初詣も済ませたので、あとは商店街をさらっと散策し、15時には大洗を出発。

秋山殿はもふもふ可愛いなぁ・・・

ちなみに、大洗〜水戸の車両が、ちょうどラッピングされたものだったw

今日はここまで！

ブログの今年一年を振り返ってみた。（2017年）

2017年も終わりなので、ブログの今年一年を振り返ってみた。

全体

まず、全体的なところから。

更新頻度

もうこれは酷いとしか言いようのない状態で・・・（＾＾；
特に、9月以降はよくて月1回、11月は投稿0という酷い有様。

これは原因はハッキリしていて、一つはアニメとゲーム。
ついついそっちに流れてしまって、全然勉強やブログに時間を割けていなかった。
FGOとか・・・

もう一つは、体調的な問題。
9月頭に筑波山まで自転車で行ったんだけど、その後から体調を崩してしまって、頭痛と37度前後の微熱が地味に続く状態が続いたり・・・
普段は寝れば大抵の頭痛は治ってたんだけど、なかなか治らないもんだから、念のために脳神経外科に行ってCTを撮ってみたり（結果は問題なし）、普段通ってる医者で薬を処方してもらったり。
なんやかんやで10月中頃には治ったけど、そんなだったから、あまり無茶をする気になれなくて、ゲーム会に行く頻度も落ちたし（これは別の要因も大きいんだけど）、自転車で長距離走るのも控えめに。
で、休日も体力回復のためにダラっとアニメ見たりゲームしたり寝てることが多かった（＾＾；

来年はもうちょっとアニメとゲームを控えて、体力ももう少し戻し、アウトプットを増やしていきたいところ。

内容

さて、そんなわけで、今年書いた記事はそもそも数が多くない・・・

だいたい、次のような内容：

• 技術
  • OS自作入門
  • LilyPond
• ゲーム
  • シャドウバース
  • デュエルエクスマキナ
• 自転車
• 昔のブログで書いた記事の紹介
  • 言語に関する考察

『OS自作入門』は読み途中なんだけど、コンパイラを導入するのにそれなりに気合が必要なので、ちょっと止まってる。
あと、Lilypondの勉強や音楽理論の研究も同様・・・
この辺りは、来年ちゃんと再開できればいいのだけど。

アクセス数

去年は更新頻度が下がってもアクセス数自体は伸びてたんだけど、今年はさすがに減った感じ。
強化学習の記事もアクセス頻度下がってる感じだし。

はてなカウンターがサービス終了してしまったので、今年はGoogle Analyticsのデータ。
なので、去年とは単純に比較できないけど、以下のような感じ：

月	ユーザー	セッション
1	10822	13079
2	9223	10995
3	9057	10827
4	8983	10862
5	9358	11563
6	7993	9721
7	7381	9044
8	7126	8585
9	7162	8559
10	7605	9246
11	7246	8685
12	6482	7791

（※12月は12/29まで）

う〜ん、やっぱりちゃんと更新しないとね（＾＾；

今年の目標の振り返り

さて、今年やっていきたいと挙げていたのは、以下のようなこと：

• 作曲、音楽理論
• 電子書籍作成

お、おぅ・・・
一応、LilyPondを入れはしたけど、全然達成できてない。。。

まぁ、これはやりたいことの優先度が自分の中で変わったというのもある。

今、自分が興味を持ってるのが、コンパイラやそれを動かすための実行環境という部分。
実のところ、『OS自作入門』を読み始めたのも、そのための勉強という部分が大きかったり。
他には、最近だと『ディジタル回路設計とコンピュータアーキテクチャ』というのを読んだり、『きつねさんでもわかるLLVM』を読んでいたりする。

30日でできる! OS自作入門

ディジタル回路設計とコンピュータアーキテクチャ 第2版

きつねさんでもわかるLLVM ~コンパイラを自作するためのガイドブック~

なんでこの辺りに注目してるのかを説明するのは、仕事の話も出てきて話せないことがちょこちょこあるので、ちょっと難しい・・・
すごく端的にいうと、ハードが拡張されていっている現状に合わせて、ソフトも新しいパラダイムを獲得していかないといけないと思っているのが、その理由。
もっとも、実際にはずっと昔に作られて、そして忘れ去られてたパラダイムなので、再発見されなければならない（そして、焼き直されなければならない）という感じなんだけれども。

まぁ、それについては、いずれまた。

人気の記事

さて、今年アクセスの多かった記事は、と紹介したいところなんだけど、確認してみると、上位に来てるのはどれも2016年や2015年の記事・・・
まぁ、今年はほとんど更新しなかったから、仕方ないのだけど。

とりあえず上位3つだけ挙げておくと、以下のとおり：

今年書いた記事で上位に入ってたのは、以下のようなところ：

ちなみに、『21世紀の貨幣論』はホントに面白かったので、オススメ。

２１世紀の貨幣論

---

といったところで、短めだけど、今年はおしまいかな。
来年こそは、ちゃんと更新していこう。

今日はここまで！
良いお年を！