コンピュータサイエンス

https://anond.hatelabo.jp/20221129085814

なかなか面白いテーマだと思った。実際のところ、平常の仕事で必要かどうかでいうと全然必要ないんだよね。知っておく必要は特にない。もちろんフレームワークを作ったりプログラミング言語を作ったり、いろいろ必要な局面がありうるとは思うけど、たいていのソフトウェア技術者のたいていの仕事には必要な局面はごく稀。それは別にbigtechの従業員でも同じと思う。

そういえば圏論についてこんなことを書いたことがあった。これは今でも間違っていないと思う。https://qr.ae/pr7ITC

なのでまあ必要に応じて学んでいけばいいし、永遠に必要にならないこともたくさんある。そもそも学部レベルで学ぶような内容は(大学にもよるでしょうが)そこまで広い範囲でもなくカバーしていない分野も多いし、一方ですごく深く理解できるようになるかというとそこまででもないという気もする。

けど実際のところ体系的に学んでいないと必要に応じて学ぶというアクションを取ることができないというか、そのような選択肢に思い至らなくていろいろおかしくなってしまうということがあるんじゃないかなぁ。という気がする。

そういえば昔こんなことがあった。Google日本語入力チームで働いていたとき、軽く雑談しましょうとのちのPFNの人たち(当時PFI?設立前?どっちだったか)と話したことがあった。その雑談の中で、こんなふうに辞書データを圧縮していてこういうデータ構造を使ってるんですよね、まあこれが最適かどうかはわからないんですけど……みたいな話をちょっと話したところ、岡野原さんがさっと立ち上がって、軽く計算してみましょうか、とホワイトボードにざっくりとした概算を計算しはじめ、理論的な下限がこのくらいだからかなりいいんじゃないですか、みたいなことをパッと言ったのだった。

CSの学位があればこういうことができるかというとそれだけではないわけだけど(こちらもCS系の学位を持っている人はたくさんいた)、ないとできないようなタイプの議論とか考え方というものはあるのだと思った。

君はNorman Y. Mineta Highwayを知っているか

何ヶ月か前のことなんだけど、Highway 85を走っていたら “Norman Y. Mineta Highway” って書いてある標識を見かけた。

ハイウェイは通常、数字で呼ばれるけれど、たまに名前がついていることもある。大体の人は名前の存在を知らないけれど、そういうことはある。なので、おっそんな名前ついたんだ、と思ったのだった。

ノーマン・Y・ミネタの日本における知名度は高くないと思うけど、地元ではとても有名な政治家で、かなり出世した人だ。名前はかなり知られている。サンノゼ空港が正式には Norman Y. Mineta San Jose International Airport であったりするようなこともある。

つい最近(2022年5月)に亡くなられたのもあって、それでついた標識なのかなぁと思ったのだった。

それでふと、これいつからある標識なんだろ?と思ったのだった。Googleのストリートビューは定期的に撮影しなおされていて、過去の画像も見えたりする。で、色々みてみるとなんと2008年の12月にはもうあるのだった。

Wikipediaを見てみたら2008年9月にこの名前がついたという情報が書いてあった。どういうきっかけなのかはよくわからないけれど。

それにしても2008年て。私がこの辺に引っ越してくるより随分前だ。2008年くらいにはもう出張で頻繁に訪れて、この通りを通った回数なんて数えきれないぐらいなのに、マジで今年になるまでこの標識のことに気づいていなかった。

やーびっくりしました、という話でした。人間の認知なんてあてにならんもんです(それは主語が大きいという話かもしれないが)

mastodonについて

ElonがTwitterを買ったことは自分にとって思った以上にショックだった。彼のやろうとしていることがうまくいくか、それがいいことなのかどうか、というのはまあ興味深い話ではあるが、それはそれとして個人的に私はElonを支持しないので、彼の支配下のTwitterの利用を段階的にやめてみることにした。このブログは自動連携でtwitterに出てくるようになると思うし、アカウントを止めるわけではないが、基本的には投稿はしないし見るのも減らしている。

と言っても、まあ完全に止められるかはわからないし、数ヶ月後に何事もなかったかのように利用を再開することもあるかもしれない、と予防線ははっておきます。自分はsocial addictなので……。

さてそういうわけでどうするかということで、ひとまず個人的なこととかはFacebookに書いてみたり、5年前にアカウントを作ったっきり放置していたMastodonのアカウントを復活させて少し投稿してみたり、しているが、これが持続可能なのかどうかはよくわからない。

twitterがもしダメだったとして、しかし今後どうなるだろうか? Mastodonとfediverse(というらしい)がそのニッチに収まるかというと非常に怪しいなという印象しかない。Mastodonは(色々トラブルはあるものの)比較的牧歌的な状態であるが、それはユーザ数が少なくて理想論的なユーザが多いからだろう。ユーザ数がふえればtwitterと同じような問題、スパムやボット、問題発言、偽アカウントなどの問題が頻発するようになるはずだ。そして分散的なネットワークであるMastodon / fediverseでは誰かを追い出したり禁止したりということを現実的にenforceすることが非常に難しくなるだろう、ということは容易に想像される。

公式アカウントの認定のような機能はMastodon / fediverse には存在しないし、ありえないとも考えられる。ただ自分のドメインで運用することで公式性を与えるということになるだろう。それでも「紛らわしい微妙な名前のドメイン名」を使ってくる人々とか、そういう多数の問題が生じることも容易に想像される。映画が公式サイトにドメインを取得して公開後に第三者が勝手にドメインを獲得できてしまうように、時限的なアカウントの乗っ取りのようなことも起こりえる。それに結局、ドメイン名の維持に必要なのは少々の登録料な訳で、金銭で認証バッヂを買える新しいtwitterとどれぐらい違いがあるのかはまあわからない。

fediverseというのはどうもblogosphereみたいなのと似たような語感に思う。そうやって「誰もが使うサービス」はなくなり、それぞれがそれぞれに分かれて棲み分けるようになるという未来像は考えられなくもない。とはいえ便利だからみんな使うようになるわけで、twitterでないにせよ、それがなくなるという未来もあんまり考えづらい……。

とかまあ考えてみるとMastodon / fediverseではない別の何かになるのかなという気がする。それはdiscordのような非公開の場かもしれないし、redditなのかもしれないし、これからできる新しい何かなのかもしれない。正直よくわからんけど、まあ新しくできた何かなんじゃないか、という気がする。


話のついでにactivitypubも把握しておいた方がいいだろうなと思って仕様もざっくりと眺めてみた。20年くらい前にRDF / RSS / Atom とかを勉強してたのを思い出すね。なんか自分でactivitypubなマイクロブログを作ってみると楽しいのかなぁ。どう考えても持続可能ではないけれど。

それにしても仕様としてはまあまあシンプルなので、このままではとてもスケールしなさそうだなという気がする。例えば、

  • いろんなドメインのオーナーが自分のMastodonインスタンスなりなんなりを立てるのは大変すぎるので、マルチホストで独自ドメインに対応したホスティングサービスは不可欠になる。今のwordpress.comみたいな感じ。Automatticとか今頃そういうのを頑張ったりとかしてるのかな
  • スパム対策。メールと同じでスパムメッセージには対策が必須になる。Akismetみたいなサービスが必須みたいなことになると思う
  • 投稿数に応じてHTTPリクエストが爆発的に増えるとやってられないので、中継・一括化のようなものが必要になりそう

とか、色々やることがあるのかもね。

yamlについて思うこと

yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。

しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。

例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない(複数の経路から同じノードに到達できる)ということがある。本質的にはグラフになっている。

一方、kubernetesなどを見てもそんなことは全く考えられていない。全てのキーは単に文字列しか考えられていないし、エイリアスがレスポンスに出てくることはあり得ない。入力にエイリアスがあった場合の処理は自分はやったことがないのでわからないけど可能なら単にコピーしていたりするだけで、循環はスキーマに合致せずにエラーを返して終わりだろう。実際のところ、kubernetesのAPIサーバはyamlもjsonも返せるようになっているので、jsonで表現できないデータ表現はkubernetesにはあり得ない。

要するにyamlである必然性は全くない。単純に、jsonみたいだがもう少し「簡単に」かけてコメントのある何かというのが望まれていて、標準的だったのがyamlだったというのが本当のところだろうと思う。

ただ本当にこれが望まれているものだったのか、というのは謎でもある。yamlは文字列も数字もクオートなしで書けるのでちょっとした変更でデータ型が意図せず変わってスキーマに一致しなくなったりとか、インデントに意味があるのでうっかりミスでおかしくなったりとか、全体的に非常にerror proneなところが大きい。やりたいことは「なんか少しだけオシャレなJSON」なのにオーバースペックすぎる。なんというか、vscodeの設定ファイルみたいな、JSONにコメントを書けるようにすると言った拡張だけするのが望まれていたんじゃないか、という気もする。

kubernetesを出すときか、別のタイミングがあり得たのか知らないけれど、何か別のフォーマット、jsonnetとかcueとかdhallとかHCLとか……なんかそういうものを作ってそれを使えるようにしておけばよかったんじゃないか、という気がしないでもない。社内のborgは独自の設定ファイルだったからyamlにする必要はなかっただろうにね。

もっとも、新しくオープンソースプロジェクトを立ち上げるにあたって設定言語を独自に策定、というのはやりたくなかったのだろうね。yamlがここまで使われているのには「それが標準規格のものだから」というのはある気がする。コメント付きのJSONを処理するためのパーサというのはどのプログラミング言語にもあるわけではないけど、標準規格のフォーマットは大体パーサライブラリがあるので。

ただいかにもstatus quoであってこれをなんとか打開することがあったりしないんだろうか……といつも思っている。そう思ってる人がいるから、結構いろんな設定言語が色々あるんだろうけども。

(Helmについても色々思うところがあるが今回はオフトピックなので次回に持ち越します)

clear aligner続き

clear alignerを始めた

のその後です。1ヶ月くらい経って3個目のアライナーに移行しました。

  • 装着していると数日で慣れる。慣れると割とどうということもない
  • ただ新しいアライナーになるとまた最初は結構力がかかっているのを感じるようになる。毎回そうなるっぽい
  • 歯間フロスの感触が結構変わってきているから、実際に歯は動き始めてるってことなんだろうなあ。面白い
  • 飲食のたびに外すのはまあまあ面倒だが、そこまででもないといえばそこまででもない。飲食後に洗ったり口をすすいだりするのは結構雑になってきた気がする。食べかすが残ってて虫歯になったりするとシャレにならんけど
    • ただ仕事中にお茶を飲む量は減って水ばっかりになっている気がする
    • コーヒーはおおむね昼食後に一杯しか飲まない習慣だったので、昼食時とコーヒー飲用を一回のセッション(?)で行えていて、これまでと同じくらい飲めている
    • 熱で変形するのが問題なのでさませばそのまま茶を飲んでもいいはずなので、そういう方向性を考えてみたい
  • アライナー、わりとすぐ汚れるので歯ブラシで洗っているけど、これが面倒

まあそんな感じで慣れてきました。最後にどれぐらい変わりますかね。

clear alignerを始めた

ここのところ歯医者でずっと勧められていたのでclear alignerを始めてみた。いわゆる歯列矯正というやつなのだけど、ワイヤーなどを使って矯正するのではなく、透明なマウスピースのようなものをずっと嵌めて生活するというスタイルの矯正だ。アメリカでは比較的一般的みたい。invisalign(インビザライン)というのも聞いたことがあるが、これは特定商品の名前であって私がつけているのはそれではなく別の会社の製品。一般名詞はclear alignersというらしい。

治療に入る前に一旦計測器で歯の形状や配列を調べてデータをメーカーに送ると、メーカーがそのデータからシミュレーションをして歯の形状と動きに合わせたマウスピースを作ってくれる。マウスピースは自分の場合、2週間に1回新しい形状のものに取り替える仕組み。とりあえず3個まで(6週間分)のマウスピースをもらってきた。6週間ごとに歯医者を訪問して続きのやつをもらいつつ進捗を確認するといった状況のようだ。

マウスピースは着脱可能で、食事とかの際には外す。食事が終わったら歯磨きなどをして嵌め直す。1日だいたい22時間以上つけていてくれ、と言われている。飲み物とか噛まない食べ物(例えばアイスクリームとか)なら大丈夫らしい。でも後で口をすすいでほしいとのこと。間に入り込むと虫歯の原因になるからだろう。コーヒーなども制限があるという話だったが、聞いてみたところどちらかといえば高熱で変形するのが問題なようで、冷めていればいいらしい。でもまぁ外した状態で飲んで、後で水で口をすすぐ方がいいのかも。それ以外には特に制限はなく、要するにずっとつけているだけ。

矯正にかかる時間は人それぞれで事前には数ヶ月と聞いていたけど、製造されたアライナー(マウスピース)を渡されてみればナンバリングが1/26なので52週間つまり自分は1年間はやることになるようだ。

そのほかの雑感。

  • つけていると違和感はある。なんとなく慣れる気がするが一旦外すとまた付け直した瞬間には違和感がある。慣れるかなあ
  • メーカーによるのかもしれないが、自分のものは歯に着脱用の突起みたいなものを接着してアライナーをフィットさせる方式だった。この突起もまだ自分的には慣れてない
  • 目立たないということでいいのだが、喋り方とか滑舌とかちょっと変わる気もするがどうなんだろう?
  • 食事のたびにマウスピースを外したり、食後すぐに歯磨きをする生活がこれまでの生活習慣と異なるので、家族込みでの生活習慣の確立をしないといけない。例えばうちに小さな子供がいるので、子の前でマウスピースを外すといったあらぬ好奇心を掻き立てるようなことをしないようにしないといけない

とまあそんな感じ。始めたばっかりでよくわからないからそんな書くことがないな……。ただ1年と長丁場なので、記憶がフレッシュなうちに記録にとどめておくのがいいかもしれないかなと思って書いておいた。

費用。相場というものが全くわからないしこれもまた人それぞれであろうという気がするが、自分の場合はだいたい定価が$6,000くらいと言われた(60万円……ではなく今の円相場だと80万円強ぐらいか)。ここから保険が降りて、なぜか分割払いか一括払いかの選択で一括払いを選ぶと少し安くなるので、自己負担額は$3,300くらい。このうち一部はFSAを使って払ったので感覚的にはもう少し割り引かれた感じ。高いのか安いのかよくわからんけど適当にウェブで検索してみたところ日本でもこれが馬鹿たかいというほどではない気がする。

以上ですが、さてどうなるでしょうかね。

constructorを日本語でなんというか?

http://lise-sophia.net/kktm/Essay/xx-shi.htm

このエッセイが面白かった。動詞に-erや-orをつけるような名詞は「◯◯子」「◯◯機」「◯◯器」などといった接尾辞がつけられる。特に抽象的な概念などの場合には「子」がつけられがち。例えばoperatorを「演算子」と呼んだりidentifierを「識別子」と呼んだりするように、と。

プログラミングの世界ではまさにそういう「抽象的な概念」であるが-erや-orがついた名詞というのはたくさんあるような気がする。どうなっているだろう?

constructorについては、「構成子」という訳語があるかな、と思ったが、「構築子」という用語もあるようだ。どちらも現存するらしい(前者は例えばJIS規格のFortran、後者はJIS規格のC#で使われている)。さてFortranのことは全く詳しくないが、C#くらいモダンな言語にはこの種の「◯◯子」がたくさんありそうだ。そこでJISX 3015をネットで検索して適当に見かけたものを探してみた。

なかなか面白い。みなさんも色々考えてみてほしい。

まずconstructorに対応するものとしてdestructorだけど、C#の仕様にはdestructorがない。あったけど紛らわしいのでfinalizerという名前になったようだ。JISX 3015にはその経緯も記載されて(翻訳されて)おり、destructorの方は「解体子」、finalizerは「終了化子」と訳されている。「化」は必要なのかなあ、でもないとちょっとおかしいのかなあ。うーん。

finalizerに対応するものといえばinitializerだろう。これは当然「初期化子」ということになる。これはまあ見覚えある気がするな。

次にiterator。これはどうなるだろうか、考えてみてほしい、がそれほど意外性はなさそうだ。「反復子」という言葉が入っている。

iteratorといえばgeneratorというものもあることがある。ただC#にはないので訳語はあるのかどうかわからない。自分なら「生成子」とでも名付けるだろうか。constructorと紛らわしいかなあ。難しいですね。

他にも色々な-erや-orがありそうだ。ありそうだと言いつつ、考えてみると意外と思い付かないものだけど。

逆にJISX 3015を眺めていて「おっ」と思った日本語の単語の方を二つ挙げておく。

「添字子」。これはindexerといったところだろうか。

「アクセス子」。えーと、accessorといったものだろうか、しかしもうちょっといい訳語はなかったものだろうか。さらにアクセス子の中には「イベントアクセス子」というのもあるようだが、もうそれなら全部カタカナ語にしちゃえよ感があって味わい深い。

アレキサンドラ・アンドリューズ『匿名作家は二人もいらない』

だらだら読んでたんですが結論としてはとても面白かったです。

作家を志して編集者になったもののあまりうまくいかず仕事もクビになった主人公が、デビュー作で一世を風靡した匿名作家のアシスタントに抜擢される。ところが……という話。

序盤のあまりうまくいっていない編集者生活とそれが破綻するまでの部分は(これはこれで面白いものの)ちょっとかったるいなと思っていたのだが、中盤あたりでおきるとある事件で物語は急展開をみせる。そしてそこからの展開が無茶苦茶で素晴らしい。とても良かった。

https://amzn.to/3ynRwdU

アメリカから日本に入国した

大したことはない体験記だけど、ないよりはいいかと思うので書いておきます。

はじめに:2022年3月の話です。国際線の出発地はロサンゼルス国際空港(LAX)でした。新型コロナウィルスのパンデミックによる入国制限の状況は刻々と変化しているので、この体験談がどれぐらい持続性のある情報になるかは分かりません。

私が入国した時に必要だったものは、航空機の出発時刻から72時間以内で新型コロナウィルスが陰性である証明書と、質問表の回答、後ブースターショットまで含めたワクチン証明書でした。誓約書は必要かと思って記入して持ち込んだのですが、結果としては必要ではありませんでした(待機が必要ではないため、またファストトラック(後述)によってハンドルされているからかも知れません)。ワクチン証明書はCDCの紙のカードも持ってきていますが、今の所Google Payに保存したQRコードのものしか使っていません。

陰性証明は、LAX内にあるClarity Mobile Labというところのサービスを利用しました。基本的にはこのブログの記事を参考にしてそのまま行いました。Clarityが発行する証明書は日本政府が発行する書式とは異なりますが、問題なく入国できました。一人$125の「24時間以内」コースを使いました(私の場合、結果は6時間ほどで通知されました)。1歳の子を連れていたのですが、子にも検査は実施して泣かれました。幼児に対しては検査自体が不可能なこともあるのでなくても大丈夫だという説も見かけたのですが、念のためということで。なお、「鼻腔ぬぐい液」という鼻の穴の奥まで突っ込まずに手前のみを擦って検体を取る手法も許可されたようなのですが、Clarity側でこうしたオプションが用意されておらず、鼻の奥までガッと突っ込む「鼻咽頭」になりました。検査結果がでた翌日、証明結果のPDFを印刷しておいたのですが、結果的にはこれは必要とされませんでした。

航空機は深夜(0:50)発のものでした。いろいろあって空港には8時頃にはもう到着していたのですが、チェックインは3時間前(9:50)からしか行なっておらず、時間潰しに苦労しました。空港内のお店は結構しまっていました。元々夜には閉まるからなのか、これもパンデミックの影響なのかは分かりません。ともあれ頑張って時間を潰してチェックインしました。チェックインの際には陰性証明書のチェックと質問表への登録の要請がなされます。トラブルはありませんでしたが時間は多少かかりました。そこからの荷物検査等はパンデミック以前と変わらないと思うので省略します。

荷物検査が終わってひと段落したところでファストトラックへの登録をしました。MySOSアプリとコンタクトトレーシングアプリは旅程の前の週などに事前にインストールしてあったので、アプリのインストール等はなく、航空機の座席情報や滞在先などの情報に答える質問票の登録と、ワクチン証明書のアップロード、検査結果のアップロードなどを行います。ここではワクチン証明書はQRコード付きの画面のスクリーンショットをアップロードしました。登録等が全て完了してしばらくすると確認が終わった旨の通知が来ました。

それから飛行機に乗り込みました。航空機はまだ空いていることを期待していましたが、かなり混雑していました。3列シートだと中央席は空いているところも目立つが窓席と通路席は空いているところがない程度、7割くらいは埋まってたんじゃないでしょうか。ただ、空港に到着してみたら多くの人が他国への乗り継ぎ便ということで降りていきました。日本が目的地だった人は少数派だったんじゃないかと思います。乗客の3割くらい?だったんじゃないかというぐらい。機内はそれほど変化は感じられず(もちろんずっとマスクをしているが)、特に書くべきことはなかったかなと。というか乳幼児を連れての長距離フライトとかしたことなかったのでそちらの方が新体験でした。

着陸後、まず席で待機するよう指示され、まず乗り継ぎ客から先に降ろされました。多分書類などの検査のフローが違うからだと思います。それがひと段落してから日本が目的地の人たちが降りるという流れでした。それで出る前になんとなく機内を眺めたところ、残っている人がかなり少なかったので、かなりの部分が乗り継ぎだったんだなと思いました。

降りてからは空港内をいろいろ歩き回って書類のチェックをされました。基本的にはファストトラックでチェックは済んでいるはずですが、確認というか、内容に誤りがないことを何度か確認するといった趣きでした。チェック自体は支障なくすぐ終わりましたが、何度も似たようなことを聞かれるのでファストトラックによる効率化がどこまで進んでいるかはわかりませんでした。大体これが降りてから30分-1時間くらいかかってた気がします。

そして唾液による検査を行いました。ただし乳幼児は唾液をこんなには出せないので、子に対しては再び鼻咽頭に突っ込まれて検体を採取されていました。この検査結果待ちがそれなりに時間がかかり、30分ほど席に座って待っていました。

ただ全般的に、着陸が早朝であり他の便がおそらくなかったために全体的な流れは非常にスムーズで、待ち行列のようなものもなく、待っている間の空間もかなり余裕があり、他の人と物理的に距離を取るのが容易な状態だったのでよかったです。

さて唾液検査の結果が陰性と出たので完了で、預け入れ荷物を受け取って、税関を抜けてそのまま出口を出ました。アメリカからの入国者でワクチン証明があるもの(及び同行する乳幼児)は強制隔離もなく、公共交通機関も使えるので、そのまま公共交通機関を使って移動しました。

というわけで、多分1ヶ月前とかと比べると随分と簡単に入国できるようになったのだと思います。空港内はいろいろ歩かされるし、同じようなチェックが多い気がするのはあんまり効率的に思えないけれど、事前に聞いていたよりはずっとスムーズだったし、特にトラブルもなく入国できたし、よしとしたいところです。

真・女神転生Vをクリアした

ちまちまプレイしていたけどようやくクリアした。カオスルート。シヴァ討伐などいくつかやり残しがあるけど、自分はヌルプレイヤーなのでもういいかな。楽しみました。クリアレベルは88だったかな。いっつもラスボスで辛い気持ちになったりしていたけど、今回はそういうことがなくラスボスはまあまあ対策すれば割と楽に倒せたところも個人的には良かった。ストーリーも、結構捻りがありつつナンバリングシリーズらしい展開で良かった。

ゲームシステム的には、今回は主人公も含めて誰も装備品というものがなく、マッカの使い道が消費アイテムぐらいしかないと思いきや、悪魔全書からの召喚に使うというシステムなのは思い切りが良くて良かったかな。あとハマ・ムド系が即死だけじゃなくてダメージも与えられるシステムだったのは使いやすくて良かった。

難点はなんだろう、いつもながら東京が舞台で現実の土地の名前がばんばん出てくるんだけど、どこがどこでどうつながってるかとかが全く把握できなかったところはちょっとした難点。あと3Dでオープンワールドっぽいところは本当に必要だったかなあ。もっと普通のJRPGの体裁を通しても良かったような気がするけど。

ストーリーといえば、今回はマジに女神が転生していてタイトル回収……!となったところは評価したい。いや過去作もこれが女神で転生ということなのか、とよく考えたら想像できるようなものもあった気もするけれど、ここまではっきりしたものはなかったのでは。第一作『デジタル・デビル物語 女神転生』(未プレイだけど)以来のタイトル回収なんではないか。だからどうなのかといえばどうということもないんだけど、そこは感心しました。