PS5のSpider-Man 2をクリアした。かなり面白かった。今回も良作。ただ総合的な満足感は前作の方が上という気がした。

PS4にあったゲームの続編で、ニューヨークを舞台にしたオープンワールドゲーム。今回の主なヴィランはKraven the hunterとヴェノム。Kraven the hunterっていうヴィラン初めて見たんだけど、ゲーム内でのデザインはよくできててかっこ良くはあるものの、「君ちょっと世界観違くない？」という気がする見た目だったのがすごく気になった。オープニングシーンとかちょっと笑っちゃった。

ゲームとしてはそんなに難しすぎないしやっていて楽しい。スパイダーマン的な動きが色々できたりアクションも派手。ゲームメカニズムとしては基本的には前作そのままでやることもそのままだが、色々追加要素（糸を渡したりとか）もあり、そこそこ複雑化していて楽しくはなっている。空飛ぶアクションは苦手だったのでそこはちょっとイマイチだったが。

ストーリーも複雑化していたが、でもきちんと繋がったストーリーになっていて感心した。特にLiのストーリーラインがなかなか良かった。ただ、ピーターとマイルズのダブル主人公制はそんなにすごく機能しているという感じではなかったかなと思う。あとMJ強すぎでは。というかMJの持ってる武器が強い。スパイダーマンたちもそれ装備しなよ！と少し思った。

総合的な満足度という点では、サブクエストがかなり少なかったように思う。前作ではスパイダーマンのマスクを被った猫を探すみたいな些細なサブクエストがたくさんあって楽しかったように記憶しているのだが（スパイダーキャットは本作でもちらっと再登場していて良かったけど）、そういうサブクエストが多くなかったかなと思った。序盤のサブクエストの一つはかなり良いものだったが、ああいうのがもう少し色々あると楽しかったかなぁ。一方で収集要素は増えていたけど、そっちはそこまで面白さを感じられず……。

サブクエストというかサブストーリーでいうとThe Flameのストーリーライン、あれで終了なの？　最後の一つをやり逃したのかと思ってしまった。続編を作る気満々だから、続編へのヒキも考えての展開だったのかな。

続編といえばエンディングからは続編作る気がビンビン伝わってきたが、アメコミ知識がなさすぎて最後に名前だけ出てくるキャラクターに「えっ誰？」となった。速攻で検索して把握しました。

というわけで、色々言いたいことはあったが総合的にはすごく楽しかった。続編も楽しみです。

数週間前くらいに会社で導入してもらって、github copilotを使ってみている。

今のところ、すごくいいっていう感じではない。copilotの動作、おおむね

• 関数などの名前だけ書いて空白にしておくと、関数全体の中身を勝手に埋めてくれる
• 細かい修正をしているときなどの補完入力的な挙動
• コメントなどの入力支援

と言ったところであるように思う。が、

• 最初のパターンはあんまり使ってない。出てきたものも微妙なものが多い気がする
• 細かい修正は便利なことは多い。特にGo言語はエラー処理などでboilerplateが多いので、そういうところでやってくれるのは本当に助かる
• ただ挙動として、プログラミング言語の意味的な情報（型とか）を利用しているわけではなく、周囲のコンテキストなどをプロンプトとして生成しているだけなので、結果として「雰囲気で補完している」ようなことがままある。ないフィールドを補完してしまったりとか。
• コメントの入力支援はなかなか便利。特に英語が母語ではない身としては割と助かる。ただそういうことではない、みたいなコメントも多い気がする。

というわけで、便利は便利なんだがなけりゃないで構わないな……という気持ちもある。個人的には、コメントの文章とかのこなれてない表現をいい感じに編集してくれたりしてくれた方が助かるのだが、copilotはそういう機能ではないなあ、という話ではある。

ただ、もっと最初のパターンを使いこなすようになってくるともっと生産性が上がるのかもしれない。まだ「上手い使い方」がわかっていない感じがある。関数の名前に加えてコメントを適切に書いたりと言った、一種のプロンプトエンジニアリングでもっといい感じにできるのかも。その辺を追求するべきなのかどうかは悩みどころ。

---

さて、そんなことを思っていたらcopilot workspaceの話題を見かけた。

すごい。すごいけど、このcopilotの現状からしてどこまでできるようになるものなんだろうか。

これまでの自分の体験としては、確かにすごいけどそこまでのことができるようには思えないようにも思える。ただ、それなりにきちんとした実装方針を提示すると実際のコードや修正をそれなりの形に持っていける、というのは全く不可能ではないような気はする。この実装方針のブレークダウンが肝で、そこをうまく作るためにはそれなりにプロンプトエンジニアリングが必要な気がするし、現在の実装に基づいて具体的にissueを設定しないといけないんじゃないか、という気がする。まあただの想像ですけど。

ただ、そのようにしてなされた実装はどちらかというと設計が汚くなったり重複したりとなってしまいがちなんじゃないか、という気もする。同じようなコードを何度も書くことはAIにとってはそれほど苦ではないような気がするので。そしてこれを継続していくとコードは複雑化し、読めなくなっていき、メンテナンスができなくなっていったりするんじゃないだろうか。そこで適切なリファクタリングを導入する必要がある。もちろんそれにもcopilotを使って……となっていったりするのかな。

ところで、複雑なソフトウェアにおいては、問題をどのレイヤでどのように解決するかが自明でないことがよくある。copilot workspaceはそういう問題を解決するものではないだろう、と思う。例えば、ChromeOSのウィンドウマネージャを作っていたとき、「なぜかこのタイミングでフォーカスがあるはずなのにない」「フォーカスがないはずなのにある」みたいなことがある。その問題を解決するのに一番単純な方法は、問題が報告された場所にif文を一個足すことだったりする。しかしそうやっていくと管理するべき状態はどんどん複雑化し、また別な予測不能な問題を引き起こすこともある。でもそこでイベントの流れをよく追ってみると、正しい修正は別なコードの分岐のところに適切な処理を入れることだった、みたいなこともあったりする（そしてそこまでわかってみると修正は非常に単純であり、1行で済んでしまったりする）。

ソフトウェア開発ではそういうことがよくあるわけだけど、この種はAIは（まだ？）そこまではやってくれるようにはならないだろう。issueでもdiscussionの流れを見て……とか言ってたし、そういう分析や発見をissueにどんどん足していってもらうのが前提で、そういう全てを見て実装方針を決定したりするのだろうが、そのためには人間がそういうことをコメントに足していく必要がある。これまあ、悲観的に言えば「AIがソフトウェアを書くようになり、残された人間の仕事はデバッグだけ」ってことな気もするが、別な言い方をすると人間の仕事っていうのは「何が正しい動作なのかを考えて決める」「問題に対してどのような修正を行うべきなのかを決める」といったところとも言えるかもしれない。

子が3歳になった。誕生日会をやったり、プレゼントをあげたり、まあまあいろんなイベントをこなした。

それと別に保育園でもお祝いをしてもらったようで、アプリ経由で写真が送られてきた。Happy Birthdayと書かれた壁紙の前に撮って記念写真を撮ってもらったもののようだ。Vサインのような手を作っているが、よくみると手の指は3本立てている。

それで思い出したが数ヶ月前のこと。どこかに買い物をしに行った時だったかと思うが、適当に子供の写真を撮ったりしていると、子もポーズを取って撮影されてくれたりする。その中でVサインをしていることがあった。そして、自分はtwo歳なのでこうしているが（子は日本語と英語が混ぜこぜになっている）three歳になったらこうするのだ、といった趣旨のことを述べて指を3本立てて親に見せたのだった。

そのことを覚えていて初志貫徹して、3歳になったから指を3本だろと思ってそうしたのだろうか。それともそれと無関係に保育園の先生から何か言われたので3本指にしたのだろうか。

正直なところその辺のことはよくわからないし、そもそも「2歳だから」と言う理由でVサインをするという発想自体も、保育園の先生か同級生から仕入れた発想だったのか、自分で考えたものだったか、その辺も不明ではある。

それはさておき、こういうことは書いておくことで覚えておきたいなと思っていたので書いておくことにする。

---

ものすごくどうでもいい余談であるが、この文章を書くにあたって一応Vサインの情報をwikipediaで読んでいたところ、日本における事例が妙に詳しく書かれていて興味深かった。そんなわざわざ特記するほどのことなのかはよくわからないけど。

なんか最近になって、VS codeを起動しているとファンが回るようになってしまった。topで調べると関連するプロセスがCPUを100%利用しているので、これが原因だろうとは思う。ただプロセス名が全部codeなので、どんな処理をしている奴がどんな理由でCPUを使っているのか、いまいちよくわからない。仕方ないのでVS codeを再起動するとまあ直ったりするのでそういうふうに使っていた。

今日もそういうことがあったが……いい加減うんざりしたので、調べてみることにした。

VS codeにはprocess explorerが同梱するようになっていたようだ。Ctrl-Shift-Pでコマンドパレットを起動して process explorer を調べて起動すると別ウィンドウが開いて教えてくれる。この機能は正直なところ完成度があまりにも低く、例えばCPUやメモリ使用量でソートしたりできないし、私の使っているLinux版ではCPU利用率が全く取れていないようで全部0%になっていたりするが、必要最低限の機能はある。自分の場合、そこまでプロセス数が多くないのでひとまずこれで乗り切れた。

さて、VS codeのウィンドウからはCPU利用率がわからないのでtopで問題のプロセスのPIDを特定し、それとVS codeのウィンドウにあるPIDの表示を突き合わせたところ、どうもgoplsを起動・管理するユーティリティプロセスが暴走していたということがわかった（ところでChromeでは、メインのブラウザプロセスやblinkを動かすレンダラプロセスの他に、外部コマンドやプラグインを別プロセスで安全に動作させるユーティリティプロセスというものもある。こういうjargonがelectron経由でこういうところにも見られるんだなーとちょっとした感慨がある）。しかも管理対象のはずのgoplsはdefunctしている。何らかの理由でgoplsがクラッシュするか動作を終了したけど、それを管理するユーティリティプロセスの側がその状態をうまく扱えておらずおかしくなっているという問題のようだ。なんかビジーループしているんじゃないだろうか。他のgoplsプロセスは普通に動いているのでVS code全体としての動作には問題が起きていない。要するにCPUの無駄遣いであった。

VS codeのprocess explorerから右クリックで個別プロセスをkillできるので、問題のあるユーティリティプロセスをkillして問題解決。問題の把握方法と単純な解決策を理解できたのは良かった。

まあしかし今後また起きると面倒なので、goplsの問題というべきかVS code側の問題かわからないけど、直ってくれるといいな。あとタスクマネージャ、流石にCPU利用率ぐらい取れるようにしてください……。

最近ふと気づいたネタです。

Googleのmanaged Kubernetes環境であるGKEで、新しく作るkubernetesクラスタには名前をつけます。まあGKEでなくても大抵はそうですが。利用者の識別のために何らかの名前をつけるわけです。識別のための名前なので、名前は重複しないように選ばないといけません。ではどのレベルでの重複が問題なんでしょうか？

例えばs3のbucketの名前とかは世界全体で重複しちゃダメですね。GCPのプロジェクトIDも同様です。一方、GKEのようなリソースの名前では、当然ながらプロジェクトIDが異なれば同じ名前のものを使えます。利用者側としても自分が指定したものがわかればいいので（ユニークなIDは内部的には付番されているはずですがこれを使うことはありません）。つまり自分用に気軽にmyclusterみたいな名前のクラスタを作ってもよい。当たり前のことですね。複数のプロジェクトが同じ組織に属している場合などで考えると当たり前とは言い難いかもしれませんが、まあそれでも大丈夫ということになっています。単にややこしくなるだけのことです。

さらにいうとGKEのクラスタの名前はもっと細かい範囲でも識別可能なら同じ名前でも大丈夫なようになっています。例えばリージョンが異なれば大丈夫。例えばus-central1にmyclusterを作ったら、もうus-central1にはmyclusterという名前の別なクラスタは作れないけれど、違うリージョンであるus-west2には作っても問題ありません。

さらにややこしいことに、GKEのクラスタはリージョン全体にまたがるregionalなクラスタと、単独のゾーン（availability zone）だけに存在できるzonalなクラスタがあります。そしてzonalなクラスタであれば、同じリージョン内でも違うゾーンなら同じ名前でも良いようです。つまり同じus-central1内でもus-central1-aのmyclusterと、us-central1-bのmyclusterが別個に存在しても良いのですね。

さらにさらに。regionalなクラスタとzonalなクラスタも共存できます。というか疑問に思ったのでやってみたらできました。つまり、us-central1-aのmyclusterとus-central1-bのmyclusterがあり、同時にus-central1に存在するmyclusterが存在しても良いわけです。この時、regionalなクラスタのノードはzonalなクラスタのノードと同じゾーン内に共存しています。していてもまぁ問題ないわけです。

まぁだからどうかというと、現実的にはこんなややこしいことをする利点は一切ないのであんまりやられていないと思いますが、やろうと思えばできるんだなあということでした。

そういえば、最近『バンオウ』という漫画が結構好き。将棋ものだけど、主人公は吸血鬼というとっぴな設定で、主人公は将棋の才能はそれほどでもないがとにかく好きなので数百年の経験がある凡才で、この主人公がとあるきっかけでプロたちと竜王戦に挑むというあらすじ。

飛び道具みたいな設定であるが、「悠久の時を生きられる凡才」という主人公の設定が物語にうまく組み込まれていて楽しい。途中で出てくるバンパイアハンターはちょっとまだ存在意義がよくわからないけど、楽しんで読んでいる。もうすぐ4巻が出るのも楽しみです。

https://amzn.to/46vioXJ

Clear alignerが終わる
終わるとどうなる？
知らんのか
retainerが始まる

1年ほど前にclear alignerという透明なプラスチックのマウスピースで歯列矯正をする処置を始めたというのを書いたのだが、無事終わった。

clear alignerを始めた

特に処置が早まるということもなく、進みが遅いということもなく、粛々と予定通りに終わった。

処置が始まってからもしばらく知らなかった（気にしていなかった？）のだが、alignerの処置は終わった後もretainerというものを口にはめて矯正後の歯を固定させるもののようだ。終わったかと思ったらretainerを渡された。

事前に友達から聞いていた話では、retainerというのは概ね夜寝てる時だけつけるものだということだったが、自分に知らされた指示は少し違っていた（この辺はalignerのメーカーや歯医者のポリシーなどによるんじゃないかなと思うが）：

• retainerは4組もらった。1年たつと新しいのに替える。つまり4年はretainer生活が続く
• 最初の1年のretainerは1日あたり10-16時間はつけるほうが良いとされている
  • さらに半年ぐらいはより長く、できたら1日あたり20時間以上つけたほうが良いと言われた。そのほうがよりよく固定されるらしい

というわけでもう半年ほどは、これまでとさほど変わらない生活が続くようです。

追記：

そういえば、これまでのaligner全26組があって、なんとなく全部捨てずにとっていた。しかし冷静に考えてみれば、というか考えるまでもなく邪魔なだけの代物だし、場合によってはちょっと汚かったりもするだろうし、ということで捨てることに。しかしいきなり全部捨てるのも忍びないのでいちおう全部写真に収めてから捨てた。まあ写真に撮っても今後見返す可能性は限りなくゼロというか、まあゼロではないか、という気がするけど。

そして、改めて最初のやつと最後のやつを見比べると歯並びが全然違う。矯正意味あるんだなあ、当たり前だけど。さいきん人に会うと「痩せた？」とか訊かれることが増えてきたのだけど、これも歯並びが良くなって顔の下半分の形状が少し変わったからなんじゃないか、と妻には言われている。そうなのかな、それだけじゃない気もするけどな、とか思うけど、でもまあそうなのかもしれない。

ライトニングケーブルの話題のたびに「あれっ」と思って調べて、なるほどーと思ってまた忘れる、というのを何度か繰り返している気がするので、何度めかのTILだと思うが、lightningとlighteningは違う単語なのであった。lightningは雷、稲妻のこと。lighteningは「明るくする」ということ。前者はふつうの名詞。後者は動詞の現在進行形。

なんとなくlight + en で lighten から派生したように思って、ついlighteningが雷の意味の語の正しい綴りである、みたいに思いがちなんだよね。lightningは簡略的な綴り、みたいな。でもそうではない。

明るくするほうの lighten は14世紀初頭から使われはじめた用法で、light-enという現代英語と同じルールの単語。いっぽうlightningのほうは語源は古英語のlightnen(「明るくする」)かlihting(光)からきているらしい。

っていうことは、語源(の説のひとつ)のlightnenとlightenは同義っぽい気がする。が、単語として確立したのが古英語の時代からなので綴りとしてはこうなってる、ということなのかね。ちなみにGoogleの検索結果で教えてくれる語源では、中英語期の綴りはlighteningだったということが書いてあってよくわからないといえばよくわからない。

というわけで学びがありました。でもまたすぐ忘れると思います。そしてライトニングケーブルの話題を見ることはもうないので学ぶことはないかもしれない。

https://www.grammarly.com/blog/lightening-vs-lightning/

https://www.etymonline.com/word/lighten#etymonline_v_30828

https://www.etymonline.com/word/lightning#etymonline_v_9506

ちょっと前にblueskyで見かけた話題。もとは「GraphQLのスキーマではintが32ビットしかなくて、64ビット整数とかないのがイケてない」といった話だったかなと思う。直感的にはこれは「Javascriptではすべてが倍精度浮動小数点数だから64bit intがないから」ということになるが、よくよく調べてみるといろいろややこしい歴史的事情があるようだ。

たしかにJSにはもともとひとつのNumber型しかなく、いわゆるdouble型(倍精度浮動小数点)だけで数値を表現してきた。IEEE754の倍精度浮動小数点数は仮数部が52ビットあるので、実際には32ビット整数ていどであれば全て誤差なく表現できる。なので32ビット整数または倍精度浮動小数点数がどちらも使えるというふうに理解されてきた。

そうはいっても不便なので、現代のJSにはBigIntがある。ES2020で導入されたらしい。ただし普通の数値リテラルはすべてNumberであり、BigIntにするためにはnを後置する必要がある(0nみたいに。または明示的にコンストラクタを呼ぶ)。BigIntとNumberはimplicitには変換されず、明示的に変換する必要があり、取り扱いはちょっと面倒ではある……が、存在するのは有り難い。ともあれ、BigIntはあるので「すべてがdoubleなので64ビット整数は扱えない」というのは現代では厳密にいうと正しくない。

一方、ウェブのAPIというものはだいたいJSONをフォーマットとして利用している。元々の話題であるGraphQLでもそうで、レスポンスはたいていJSONだろう。そしてJSON自体はBigIntなどが導入されるよりはるか昔に制定された規格なので、BigIntであったり整数に後置する記号(nとか)のことなんか考えられていない。このためにBigIntを利用できない。というわけでJSONは仕様上ではdoubleしかない、というふうに理解・整理できそうではある。

……かと思いきや、実はJSONの仕様上では数値の桁数などに制限はない。あくまでも表記的なフォーマットの話だから、数値データでは数字をいくらでも連ねてもよい。つまりフォーマットとしては決してdoubleに縛られているわけではない。

がしかし、その数値データをどのようにデコードするかというロジックはデコーダ側の実装にゆだねられている。JavascriptではJSON.parseによってデコードするのが普通だが、ECMAscriptの仕様で定義されるJSON.parseの挙動によればJSONの数値はすべてNumberになることを定めているので、どれだけ大きな桁数の数値であってもけっきょくはdoubleの精度までしか扱えないし、BigIntにはできない、ということになる。

つまるところ、「JSONは昔のJSの仕様がもとになっているのでBigIntのことなんて知らんし」「JSにおけるJSONの扱いにおいてはBigIntのことはなかったことになっている」ということになっている。お互いがそれぞれ新しい状況に対応できていない感じ。

どうにかならないもんだろうか。ちょっと考えてみる。

案1：ECMAscriptのJSON.parseの仕様を改めdoubleで表現しうる以上の整数はBigIntにデコードするように変更する。ただこれをしてしまうと、値の大きさによってBigIntかNumberか型が変わってしまうので、デコード結果を扱うのが面倒になる。先述したようにJSではBigIntとNumberはimplicitには変換しない方針なのも大きい。小さな値のBigIntを含むオブジェクトをJSON.stringifyしたものをJSON.parseすると違うデータになる(Numberになっちゃうから)という問題もある。

案2：JSONの仕様を変更してnのような後置を認める。これはJSの利用者からすると有り難いが、世界中に無数にあるいろんなプログラミング言語のJSONライブラリとの互換性が崩れるという難しい問題がある。互換性の問題が発生してしまう。新しい仕様への対応を済ませてサーバ側が新しいフォーマットを返すようにしたら古いクライアントで動作しなくなるといったことも起こる。

というわけでなかなか簡単な解決策はないのであった。sigh。

JSON5みたいな類似フォーマットで対応できてないのかな、と思ってみたが、JSON5も不可であった。BigInt登場以前からあるからかな。

YAMLの場合にはBigIntに対応できている。そしてYAMLはJSONの厳密な拡張である(つまり、正当なJSONは正当なYAMLである)。なのでJSON.parseのかわりにYAML.parseすることでBigIntにできる可能性はある。npmのyamlパッケージだと intAsBigInt というオプションがあって、これで全部BigIntにできるようだ。ただし、あまりにもトリッキーなので実用することはなさそうな気がする。

もちろん全く他のシリアライゼーションフォーマットを採用するという手もある。たとえばBSONにも64bit整数はあるし、messagepackにもある。毛色は違うがprotocol buffersにもある。ちなみに、protobufにはJSONデコーダ/エンコーダもあるが、protobuf/jsonは64ビット整数を文字列にエンコードしている。スキーマがあるので、どの文字列を64ビット整数としてデコードしてほしいかがわかっているので、こういうことができる。ただ、調べたかぎりでは任意長のいわゆるBigIntをサポートするフォーマットはなさそうだ。言語によってはBigIntが外部ライブラリになってしまったりするからね、C++とか……。

けっきょくいちばん現実的なのは「64ビット整数やBigIntはネイティブにはサポートせず文字列にする。適宜文字列からBigIntなどに変換するロジックを持つ」という一種のstatus quoなのだな。変換は場合によってはわりと面倒なのでフレームワークが適切に対応してくれないと厳しいが、そのためには「どの文字列はBigIntであるべきか」という情報、つまりスキーマ定義が必要になってしまうので自動化しづらい。TypeScriptの型情報とかをうまく使ったりできたら面白いんですけどね。できるのか知らないけど。

それでいうと、元の話題にもどるとGraphQLではスキーマがあるのだからint64を持っていてBigIntで取り扱うということはできそうではある。ただそうするとエンコーダ・デコーダに専用のライブラリが必要になってしまうのが痛いという判断なのかもしれない。

---

ところで、JavascriptのJSON.stringifyはBigIntをエンコードできない、というのはこの記事を書くために手元で試すまで知らなかった。BigInt……めんどうくさい……。

アイスランドを象徴するような動物はいくつかありそうだが、その筆頭になるものがあるとすればパフィンだと思う。

ペンギンを思わせる黒と白のカラーリングに派手な嘴の小さな海鳥だ。産卵のためアイスランドに夏にやってくる(らしい)。パフィンはアイスランドのいたるところでキャラ化しており、土産の意匠としても一番メインというかんじ(もうひとつの主役はヴァイキングたち)。ぬいぐるみ、フィギュア、キーホルダー、ステッカー、衣類、ほんとになんでもある。わたしはTシャツと靴下を買った。

さてそんなパフィンだがもちろん観察ツアーもある。パフィンがいるのは夏だけで、ツアーはだいたい8月下旬には終わるようだった。わたしが行った時期はほぼ終わりかけだったけどなんとか期間内ということでツアーに参加できた。

なお、アイスランド最大のパフィンコロニーは島の南のほうだそうで、そちらにいくともっとたくさん見られるようだったが、そちらに行くのはすこし面倒そうだったので、レイキャビクから行けるツアーを選んだ。市内の港から船で出て15分ほどで行けるコロニーを見るというような1時間ほどのツアーだ。

終わりかけの時期だし、首都から近い場所だし、どうかなーと思ったけど、パフィンはあっさり見られた。けっこう小さな鳥だし船ではそこまで近寄れないし、さすがに最盛期よりは少ないだろうし、持ってるのは携帯電話だけだし子供は抱っこせにゃならんし、というわけですごくいい写真は撮れなかったのだけど、たくさん見られて良かった。ツアーは2箇所ぐらい巡ったが、どちらにもたくさんいた。

パフィンツアーはとても楽しかった。もっとたくさんいる時期には街にも迷い込んだ小鳥がいたりするらしい。最大のコロニーのある場所だとさらにもっといっぱいいるとか。またアイスランドではパフィンを食べるという話もあるようだが、パフィン料理は都合がつかず食べられなかった。

---

話はかわってブルーラグーン。

ブルーラグーンはアイスランドでもかなり大きな観光施設である。そこそこ大きな湖というか池みたいなものが丸ごと温泉になっているという話。実際にはここにジオサーマル発電施設があり、その関係で副産物的に出来た温泉であるらしい。

こちらもなかなか楽しいのだけど、アイスランド旅行としては異質という気がした。非常に完成度の高い観光施設というか温泉施設というか、そういうものになっており、火山が噴火したので溶岩見学ツアーするぜ！みたいなのとは対局にある感じがするため。でもいい場所ではあった。空港にほど近く、レイキャビクからはけっこう離れている。わたしは到着したその日にそのまま行った。入場するなら予約はしておいたほうがいい。レイキャビクからはツアーバスがあるのでそれを利用するという手もある。

---

というわけで、アイスランド旅行で書こうかなと思ってたことはこれぐらいかなと思う。パフィンはかわいかったし自然はすごかった。レイキャビク市内も楽しい。あーあとそういえば緯度が高いのでまったく陽が沈まなかった。夏至あたりでは白夜になることもあるようだ。わたしが行ったときはだいたい夜10時ぐらいが日没とのことで、夜11時になれば真っ暗なのだが、夜9時ぐらいに散歩したときにはこれぐらいの明るさ。

逆に冬となればまったく陽が登らない極夜にもなるらしい。冬も冬でオーロラツアーとかあるみたいだけど、ハイシーズンはやっぱり夏かなぁという気がする。こういう緯度が高い場所は気候が極端になりがち。

そういえばアイスランドは経度としてはレイキャビクあたりで西経20度ほどにもなるようだが、イギリスと同じタイムゾーンを採用しているらしい。しかもサマータイムがないので、時刻は常にUTC。なんか知らんけど便利そうだ。でもまぁこのズレは日没時間とかに微妙なズレを与えているはず。

というわけでアイスランドでした。サンフランシスコからは直行便がないのでそうそう気軽に行けるような場所ではないけど、また行きたいなあ。とくに子がもう少し大きくなって移動の自由度が増したらまた行きたいね。