国際線のない国際空港

昨日、関空のラウンジの話を書きましたが、同日の関西エアポート社の発表にこんなのもあった。

大阪国際(伊丹)空港の英語表記を「Osaka Itami Airport」に ~インバウンド旅客の利便性向上に向けて~ (pdf) (関西エアポート)


伊丹空港と呼ばれることが多いが、正式名称はずっと大阪国際空港である。

そもそも伊丹空港という呼び名も後で書く事情で違和感はあるのだが、

混乱をきたさない呼び方としてはこれが一番よいのが実情である。

で、大阪国際空港という名称の最大の問題はもはや国際線はないということである。

そう、国際線がなくなって30年経つのに「国際空港」なのである。


日本の人は事情を知っているからあまり問題はないけど、

国際線という観点では大阪の空港というのは関西しかないわけで、

Osaka(Kansai)と書いてあればよい方、単にOsakaと書いてあることも多い。

で、今までは英語表記で “Osaka International (Itami) Airport” とか書いてあったと。

一応はItamiと付記されることが多いが、Internationalとは付くこともあり混乱のもとだったという。

結局は一番見分けやすいのが空港コードだったのかもしれない。

関空行きのバス乗り場にはKIXと書き、伊丹行きのバス乗り場にはITMと書くようなことは行われている。


でも、なんで今に至るまで大阪国際空港って名前のままなんだろうと。

1つは周辺地域への配慮というのはあると思う。

周辺地域への騒音対策のために関空が作られ、国際線は移転したわけだけど、

結局は国内線の基幹空港として存続することになり、そこには地元の要望というのもあったわけである。

格下げされたわけではないというアピールは必要だったのかもしれない。

もっとも、国際空港とは言えないのに国が全額負担して管理するのはどうなのだという話があり、

2008年から2012年の新関西国際空港(株)への移管までの短期間、一部地元負担になっていたことはある。


伊丹空港と呼ばれることは多いけど、この呼び名も変な呼び名ではある。

というのも伊丹市にかかっていることは事実だが、基本的には空港の裏側だからである。

このあたりは市境・府県境が錯綜する複雑な地域ではあるのだが、

公式な所在地は「大阪府豊中市蛍池西町」となっている。そう、豊中市である。

なのになぜ伊丹空港と呼ばれているのかというと、その昔アメリカ軍が伊丹エアベースと呼んでいたからだという。

確かに滑走路の大部分が伊丹市にあること自体は事実であり、全く的外れな言い方でもないのだけど。

でも、普通は玄関のある大阪府・豊中市の空港であると見るべきであり、

「伊丹空港」と呼ばれることへの抵抗はあっても不思議ではない。


かといって大阪空港ではのっぺらぼうにすぎるし、なんとも難しい。

結果として外国語表記は”Osaka Itami Airport”、

あるいはそれに相当する表記ということで中国語だと「大阪伊丹机場」のようになるのだろう。

地元の抵抗もあるんじゃないかと書いたが今さらなのだろう。

関空と同じ会社が経営しており、国内線の基幹空港としての位置づけは明確で、

それが混乱の原因にならないようにという表記変更なので。

日本語表記では従来通り正式名称は「大阪国際空港」で通称「伊丹空港」というのは変わらない。


そういえば羽田空港もほぼ国内線のみの時代も含めてずっと「東京国際空港」でしたねと。

1978~2002年は台湾の航空会社のみが利用し、2002~2010年はチャーター便としてソウル(金浦)便などが運航され、

2010年以降、新国際線ターミナル(現:第3ターミナル)の開業により再国際化と言われるように。

でも、一応いろいろな事情があり国際線自体は途切れたことはない。

対になる成田国際空港(当初は新東京国際空港)がかなり離れているので、混乱は少なかったのかもしれない。

ちなみにさっき空港の地元負担の話を書いたけど、羽田空港は現在も全額が国費負担である。

他の全額国負担だった空港が会社化されてしまい、国直轄の空港では唯一になってしまった。

もっとも直近の羽田空港の拡張事業は地元からの融資や民間企業のPFI事業なども活用されているので、

会社経営の関西・中部・成田との実態としての差はあまり多くないのかもしれないけど。

関空のラウンジは1箇所になる

4月には大阪・夢洲での国際博覧会が開幕、

というわけでそれに向けて進めてきた関空の第1ターミナルリノベーションが一応の完成を迎えることとなる。

まだ残工事はあるんだけど、出発・到着の経路については一応の完成とのこと。

関西国際空港 T1リノベーション ~2025年春 グランドオープンに向けて~ (pdf) (関西エアポート)


で、けっこう衝撃的な話が書いてあるのだが、

なんと3月からは関空の国際線ラウンジは1箇所に集約されるという。

このラウンジというのは航空会社がビジネスクラス・ファーストクラス利用者や上級会員に提供するもので、

従来は航空会社別のラウンジが用意されていたところ、全て1つになる。

全て1つというと厳密ではなく「ビジネスラウンジ」と「プレミアムラウンジ」の2本立てではある。

とはいえ全社共用でターミナルビル3階中央にまとめて配置されるので、

1箇所といっても差し支えないのではないかと思う。


国内線は2022年の南ウイングへの移転時に全社共用のラウンジ「Lounge KANSAI」になっている。

元はJALのサクララウンジ、ANA LOUNGEがそれぞれ存在したのだが、

そもそも両社とも関空発着便が限られている中でなかなか見合わない状況だったのだろう。

そんな中で国際線エリア拡大のため国内線エリアを縮小・移転するということで、

ラウンジもコンパクトなもの1つに集約するというのは致し方ないことだと思っていた。


ただ、国際線までも1つに集約されるというのは驚きである。

現状、関空国際線の航空会社ラウンジは7つ存在する。

北ウイングにはKALラウンジ(大韓航空)、ラウンジパシフィック(キャセイパシフィック)、ANA LOUNGE、飛鳥ラウンジ、

南ウイングにはサクララウンジ、中央部にはKIXノースラウンジとKIXエアサイドラウンジがある。

このラウンジは各航空会社が搭乗客に割りあてることになり、

航空会社ごとの系列に従ってラウンジが割りあてられる……とは単純に言えない。

搭乗口の近くのラウンジが割りあてられるからである。


もちろんJAL便ならできるだけサクララウンジが近い南ウイングを使うわけだけど、

そううまく割りあてられないケースも多く、特にリノベーション工事が始まってからは、

ゲートの一時閉鎖や国内線エリアの移設など変則的な割当が多くなっているそう。

KIXエアサイドラウンジ・KIXノースラウンジはその穴を埋める上で重要な役目を担っているようだ。

国際線エリアの各所に航空会社ラウンジを散らせるというのは案内面では難しい事情もあるようだ。


以前から中央部の3階に航空会社ラウンジを集約する絵は存在した。

ただ、それはサクララウンジ、ANA LOUNGE、KALラウンジ……のように各社のラウンジが並ぶものだと思っていた。

でも、それならもはやデカイのをドカンと1つ作ってみんなで使えばいいじゃないと。

従来の出国審査場・免税店エリアの中央部が全部ラウンジになるんだから、そりゃ広いですわな。

混雑も平準化され、利用者にとっては広々して使いやすくはなるのかなと思う。


ただ、悩み所は各社がラウンジサービスで差別化できなくなるということ。

最近は変則的な割当も多くなっていたようだけど、

自社でラウンジを設けるような航空会社はそれだけ気合いも入っていたはず。

それが関空ではできなくなってしまうのだから重い話である。

ビジネスクラスなど利用者や上級会員への体裁としては共用ラウンジを提供すればよいが、

それは関空発着便を使うどの航空会社でも変わらないわけだし。


あとは搭乗口との距離は遠くなってしまうだろうなと。

この搭乗口との位置関係をこだわると割当が難しいという問題はあったが。

上級会員の利用が多い便はできるだけ中央部に寄せるとかするのかもしれない。

羽田-伊丹便の両空港での搭乗口の割当が好立地なのはラウンジ利用者の便を考えてなんて話を聞いたこともある。

関空国際線だと何なのかはよくわからないけど。


これほどの規模の空港ではなかなかないことだと思うが、

これはこれで画期的な取り組みなのかもしれない。

今回のリノベーションは建物をそのまま使いながら、国際線の処理能力を激増させること。

国内線エリアの縮小、3階一般エリアの縮小という明確な変化はあるが、

多くは細かい配置の合理化でスペースを捻出しているというのが実情である。

ラウンジも各社細々と設けるとオーバーヘッドが生じるが、

まとめればより多くの利用者が広々利用できて、総面積としても削減できる。

こういう考えは確かにあるのだと思った。


南ウイングのサクララウンジを撤去すると38番ゲートも国際線で利用できる様になる。

スイングゲートかもしれない

今回の資料では明確にこの位置に「際内共用」というゲートがありますね。

北ウイングについてはラウンジ撤去による具体的な効果は定かではないが、

現状ラウンジが置かれているあたりは従来1機用だったスポットを、

小型機2機が同時に利用できるようにした搭乗口(1A., 3A)があるので、

このあたりの待合環境の改善という効果はあるのかもしれない。

クルドサックの使い方

Cities:Skylines2には「行き止まり」という道路パーツがある。

こんなの何に使うんだ? と思っていたのだが、必要なシチュエーションがあった。


この行き止まりというやつは クルドサックと呼ばれるものである。

フランス語でcul-de-sacで袋小路の意味である。

住宅団地などで通り抜けの出来ない道路の端をロータリー状にすることがあり、

通り抜けによる無用な交通を防ぎながら、必要な車両は転回して往来できるようにする目的がある。

ただし、日本ではあまり一般的ではない。

一部では採用されたのだが、緊急車両の通行に支障があるなどの問題があった。


というわけで、クルドサックを必要とする構造はあまり採用していなかったが、

これが必要だと感じたのはバスの運行経路の設定時である。

バスを転回させようとすると、細い街路の行き止まりまで走って苦しそうに転回する。

バス停のある道路(バス停は歩道のある道路にしか設定できない)で転回する方がよさそうだが、

経路選択アルゴリズムで転回できる場所にはあたらないようで……

で、この問題の打開策にクルドサックが使えることに気づいたと。

終点のバス停のある道路の先にクルドサックを置いておけば、そこでクルッと転回していく。

切り返しもなくスムーズである。(このゲームではうまく曲がれず切り返しする車がけっこういる)


ところでこのクルドサックだが、ゲーム上の扱いはラウンドアバウトとほぼ同じである。

道路の行き止まりのラウンドアバウトを付加することもできるし、

クルドサックに2本以上の道路を接続することもできる。

見た目が変わったりするみたいだけど、機能的な差はないみたい。

行き止まりではない道路でバスは折り返したい場合、クルドサックを置いて、

さらにその先に道路を延ばすというような使い方は効果的だが、

それはクルドサックというかラウンドアバウトでは? という話はあると思う。


日本でありがちなバス転回場を作るのってけっこう面倒なんですよね。

さっきも書いたけどこのゲームではバス停は歩道のある道路にしか置けない。

歩道のある道路ってのは一方通行でもなかなか太いですから。

バス停のある道路の先にクルドサックを置くのは容易な解決法である。

短い道路を分岐させて、クルドサックを置いてバスターミナルを作っている例もあった。

バスの乗降に時間がかかって道路をふさぐのを防ぐという目的もある。

行って帰ってきたところにバス停を置けば、乗降中のバスの後ろをさらに1台待てる。

それをたくさん並べると牛の乳みたいになってしまうけど。


人口にはあまり寄与しないけど低密度住宅も並べたいなと思い立って、

急勾配の山肌に沿うように道を張り巡らせて低密度住宅を並べて、

自宅に車庫はあるけど、そうはいっても通勤などは公共交通を使うわけで、

そうするとバスも走らせないとなと最寄り駅までバス路線を設定したが、

バスが折り返す地点にクルドサックを置くと収まりがよい。

地区内の就業者数が案外多くてなにごとかと思ったら、

小学校の就業者数がかなり多かったらしい。その小学校への通勤(通学?)の人がバスを多く使っているようだが、

住宅を発着するバス利用もそれなりにあるみたいですね。

女同士で浮気って言う必要あるの?

先日発売された2つの小説が話題になっていて……

人妻教師が教え子の女子高生にドはまりする話2 (KADOKAWA)

彼女のカノジョと不純な初恋 (KADOKAWA)

同じ出版社で発売日が同じ、そして女同士の恋愛と浮気である。

同じ出版社といってもライトノベルのガリバーであるKADOKAWAだから普通……

と思いきやどっちも電撃文庫ということでレーベルまで同じでしたか。


「人妻教師が教え子の女子高生にドはまりする話」というのはタイトルがひどすぎるが、

以前もカクヨムネクストの話で話題にしてますね。

小説投稿サイトのプロ部門

上下巻構成で終わると思っていたら、収まりきらなかったようで3巻構成になりそうと。

既婚の高校教師、苺原樹が教え子の女子生徒に誘われるがままに手を出してしまうという内容である。

そんなことあるか? という感じはあるが、そこは小説ということで。うまく書いている。

2巻の紹介が「こんにちは! 私淫行教師の苺原樹! 十歳年下の教え子と関係を結んで平気な顔で教壇に立っているどうしようもないやつだよ!」とあって、

これは実際に小説の中で出てくる文言なのだが、ここにこの話の特色が現れている気がする。


「淫行教師」という部分は全く言い訳が立たないのですが……

高校生相手に女同士だから問題ないとは言えないでしょう。

一方で夫がいる中で女同士で付き合うことを「不倫」と重く考える必要があるのかというのは意見が分かれるところはあるかもしれない。

表に見える部分だけ集めれば、教師と生徒が公使ともに親しくしているぐらいの話で、

そこには教え子のプライベートな事情もあるということで。

2巻の結末はまさにそんな話だった。(ネタバレになるから書かないけど)

表向きはそんなにおかしな話ではないが、「不倫」と考えれば危ないというやつ。


逆に「彼女のカノジョと不純な初恋」は、紹介文に「恋愛感情がなければ浮気じゃない」なんて書いてあるけど、

これは浮気ではないかと言われる中で、友人関係の範疇であると言い張る話である。

そもそも背景として 碧海つかさ と 狭山玲羅 はよく知られた「カノジョ」同士ということがある。

女同士で付き合っていると考えられている。(実はここに疑義があるのでは? と書かれていたが)

で、この2人、元々は同居していたのだが、つかさが家を飛び出してきたところ、

事情があり、高校生でありながら1人暮らししている 拝島雪 の家に転がり込んできたと。

で、女同士で付き合っているとされる人と同居して親しくするのは浮気ではないかという指摘があり、

実際そういう見方もできる……というか際どいところはあるというか、言い訳できない部分もあるが、

先ほど書いたように表向き「恋愛感情がなければ浮気じゃない」としているところである。


で、この浮気ではないかと言っているのが、雪の友達である久留米弓莉なのだが、

口絵のキャラクタ紹介に「ユキに強い感情を向けている」とあるように、

この指摘は表向きは友人からの忠告に過ぎないのだが、おそらく別の思惑もあって……

転がり込んできた女に友人を取られることへの危機感なんでしょうよ。

「最近友人づきあいが悪いじゃないか」というような話なら一般的な友人関係にもありそうだが、

それを越えて独占したい人間関係ってもはや……ということなんですね。

玲羅-つかさ、つかさ-雪、雪-弓莉 の関係それぞれに着目してみると、

表向き恋人同士、友人同士、その実態は両思い、片思いの恋愛関係というのが交錯して大変煩雑である。

あとがきに「なぜかとても湿度が高い作品になっていました」とあった通り。


「夫がいる中で女同士で付き合うことを『不倫』と重く考える必要があるのか」と書いたが、

これは意見はいろいろあると思うが、男女間の関係と男同士・女同士は別という考えは一定ありそうである。

実際、男同士だからそれは別という考えを聞いたことはあるような気がする。

それで当事者同士が納得してしまえばそれで全部済んでしまうと。

もっとも「淫行教師」という部分は教員としての倫理とか、

現代的な言い方では「不同意性交等罪」への該当性とか問題はありますけど。

(かつての強姦罪だが、2023年以降、この名前になってからは女同士でも適用される余地が生じた)


そもそも浮気はいけないという考えはどこから出てきたのかという話もある。

さっき弓莉が浮気ではないかと忠告するのは「友人を取られることへの危機感」か?

なんて書いたけど、わりとそういう素朴なところが起点なのかもしれない。

ただ、男女間、特に婚姻関係となれば、より大きな問題がある。

まず重婚が禁止されているので、2つ以上の婚姻関係が同時に存在することはできない。

重婚があると絶対に困るなと思うのは嫡出推定である。

生まれてきた子の母親に2人以上夫がいたら嫡出推定なんて成り立ちませんよね。

(世界的には一夫多妻制が制度化されている地域はあるが、その逆がおおっぴらに行われている話は聞かない)

夫婦間には強い扶養義務がありますが、配偶者が2人以上いた場合には実現性にかなり問題がありそうで、

一夫多妻制が認められている地域でも扶養義務を確実に履行できることが要件にあったりする。

不貞行為が糾弾されるのも、親子関係や扶養関係というところへの憂慮が大きいんだと思いますけどね。

あとは税制や年金で優遇のある配偶者が2人以上いては不公平というのもあるでしょうしね。


で、この上に書いたようなことの起点がどこにあるのか考えると、

夫婦間に子供が生まれる可能性があるというところにあるんじゃないかと。

だから、結婚は嫡出推定や親権などの親子関係に影響を与えるし、

出産・育児などで仕事から(一時的かもしれないが)離れるのも珍しくない中で、

強い扶養義務、所得税・住民税の控除、社会保険料の軽減であったり、

配偶者の死後においては最低でも1/2の法定相続分、1/4の遺留分があり、

それに伴って相続税も軽減されることとなる。

制度面の話ばかり書いたけど、それ以外の慣例を生んでいる背景の多くはそこだと思いますよ。


じゃあ、男同士・女同士には成り立たないねという考えもあると思うんですよ。

男同士・女同士の恋愛関係があってもよいけど、

そこに男女間の関係にあるルールを当てはめてもうまくいかない可能性は大いにあるんじゃないか。

それでだいぶ前から同性婚に関する議論がとても危ういなと思っているんだよね。


というのも同性婚が制度化されたら、専ら相続時の優遇を目的に使う人が出てくるんじゃないかと。

もちろん男同士・女同士であっても相続が安定的にできることは、

同性婚を切望するひとにとって切実な課題の1つであるとは理解している。

でも、果たして節税同性婚なんてのが問題になったときに、世論は納得するのか? と聞かれると、

僕はそうもいかないんじゃないかなと思うんですよね。


本当に不公平かというと必ずしもそうとは言えないんだけど。

というのも男女間の結婚であってももっぱら節税目的で行われる可能性は存在する。

さっき結婚についての制度や慣例の多くは夫婦間に子供が生まれる可能性から来ているのではと書いたが、

夫婦間に子供がいるとは限らないし、おおよそ子供が生まれるとは思えない結婚でも成立するし、

親子関係に関わるものは関係ないにせよ、それ以外の効力は同様である

同性婚だってそれと同じことだから問題ないし、

重婚の禁止などの規定も適用されるだろう特段不公平とは言えない。


でも、なんやかんや言っても男女間だといろいろな慣例があって、

制度上可能だとしても踏みとどまるようなケースが多いと思うんですよね。

ところが男同士・女同士は別とすっ飛んで「節税同性婚」が容易に成立する可能性はかなりあるんじゃないかと思うんですよ。

で、そこに世論が納得しない場合、何らかの制限が必要になるかもしれないが、

男女間の結婚と同性婚に大きな差が生じるような制度は作れないでしょう。

子供がいることに着目するのか、婚姻期間に着目するのか、いろいろ考えはあると思うけど、

従来は全く問題なかったはずの男女間の結婚に問題が生じることになる。


ところで「節税養子」という言葉もありますが、

相続時の優遇を目的として成人同士の養子縁組が行われることは日本ではよくある。

というか日本の養子縁組のほとんどが配偶者の子に対するものと成人同士のものなんじゃないかね。

(養子縁組には家庭裁判所の許可が必要だが、この2つのケースは家庭裁判所の許可が不要である)

成人同士の養子縁組は子供の福祉に全く寄与しないので本来の趣旨から逸脱しているのだが、

日本では後継者を養子にして継承するということが伝統的に行われてきた。

現在もこの考え方は日本社会においては広く受け入れられているので、

節税養子というのも一定の制約のもとに公然と認められている。


そういう背景のない節税同性婚はおそらく社会的に受け入れられないんじゃないですかね。

そこをつぶす制度変更をするかどうかというのは政治的な判断だが、

そこをつぶすと男女間の結婚関係の慣例を多少なりとも破壊しかねないので、

そこが受け入れられるかというのは難しい問題ではないかと思う。

夫婦間に子供がいるような典型的なケースは従来通りカバーできる制度にすると思うが、

そこからこぼれる夫婦は不適格なのかという人は絶対に出てくるわけで、

そこに納得しない人が同性婚を制度化させるように仕向けたひとを批判するのは目に見えている。


話は長くなってしまったが、いろいろ突き詰めると難しい問題がある。

小説の話に戻ると――

「人妻教師が教え子の女子高生にドはまりする話」の特徴というのは、

男女間でやれば「不倫」ということを女同士でやって、これは不倫だと自らを責め立てるところにあると思っていて、

でも「後悔自体は一切ない」とあるように、そういう選択は普通にあるなというところが妙である。

「彼女のカノジョと不純な初恋」というのは、

友人関係と主張できる女同士の関係だとか、浮気をすれば糾弾されるような女同士の関係だとか、

なんとでも言えてしまうという要素がいろいろなところに現れている。

そんな中で関係を深めていくというところが面白いのではないかと思う。

どっちも大爆発エンドという可能性もありそうな作品ですけど、

何らかポジティブな結果には終わるんじゃないかと期待しているところである。

「彼女のカノジョと不純な初恋」の方は続刊出るか知らんけど。

リアルタイムOSのスタックの使い方

スタック消費量の計算をしないといけないということで、

コンパイラの設定をいじくってスタック消費量を出せるようにしていた。

思ったよりめんどくさい……というかある事情により超めんどくさいことになっている。


最初はスタック消費量なんてどんぶり勘定でいけると思っていた。

どんぶりサイズのスタックを用意しておいて、消費量の見積もりが湯飲み一杯分なので、

割り込みなどで見積もりに入っていないスタック消費があっても余裕余裕と。

ただ、思っていたより消費量が多い処理もあって、真面目に考えないといけないかもと。

果たして、割り込みなどで消費するスタック量はなんぼほどなのか。


そんなわけで使っているリアルタイムOSの資料を見ていたら、

なるほどこんな風にレジスタの退避をしているのかと。

OSでレジスタ退避が必要となるシチュエーションは大きく3つ、

自発的なディスパッチ、割り込み、割り込み後の非自発的なディスパッチである。

その上でレジスタは呼び出し先の関数で壊してよいスクラッチレジスタと、それ以外に大別される。

Cでレジスタを使ってやらかしてる

自発的なディスパッチ処理というのは、システムコールをきっかけに発生するディスパッチで、

tslp_tsk(SLEEP_TIME);
foo();

と、SLEEP_TIMEだけタスクの実行を休むシステムコールを実行して、

復帰後にはfoo(); という処理をする場合、この間にスクラッチレジスタが吹き飛ぶことを前提としてコンパイルが行われる。

なので、他のタスクに切り替える前に保存するのはスクラッチレジスタ以外だけでよいと。


この逆に割り込みで保存する必要があるのは割り込み復帰に必要なレジスタとスクラッチレジスタである。

なぜならば割り込みハンドラの中でスクラッチレジスタ以外を使う場合、

割り込みハンドラの責任で退避・復帰を行うからである。

一般的に割り込み時のレジスタ退避はそういう考えで行われるみたいですね。

で、割り込みハンドラを抜けて元の処理に戻る場合は、

スクラッチレジスタを復帰して、割り込み復帰に必要なレジスタを復元するわけだ。


ところがOSでは割り込みをきっかけにしてタスクの切替を行うことも多い。

タイマ割り込みをきっかけにして優先度の高いタスクが動き出す場合など。

このような場合はスクラッチレジスタ以外も退避する必要がある。

結果的には全レジスタを退避させることになるのだが、

スクラッチレジスタとそれ以外をグループ分けしてモジュール化することで、

多重割り込みなどにも効率的に対応できる仕組みになっている。


今のリアルタイムOSを使用する前に、他のOSのソースコードを見ていたことがあり、

こういう処理ってアセンブラで書くしかないこともあるんだけど、

なんでこういう処理にやっているのか理解しにくくて困った覚えがある。

現在使っているOSでは退避と復帰が一対一対応するようにアセンブラで書かれていて、

いろいろな構成やシチュエーションに対応できるようにモジュール化されていて、

解説も相まってかなり読みやすいなと思った。ありがたいですね。


で、退避させるレジスタのサイズを見たら、案外多いんだよね。

割り込み復帰に必要なレジスタ+スクラッチレジスタ+それ以外のレジスタとフルセットで退避させるとこんなに行くのかと。

冒頭に書いたようなどんぶり勘定が成り立つなら全く問題ないが、

真面目に考えないといけないものもあるかもなぁと。


あと、多重割り込みですよね。これがくせ者である。

割り込みがあるごとにレジスタ退避に割り込みハンドラ実行にスタックを使う。

1回1回が少量ならデフォルトのスタック確保で十分だが、

思っているより多い……となってしまった。

というか、これは設計思想が合ってない気がするな。

移植という性質もあり、今さらどうしょうもないんだけどさ。


で、これを書いているときに計算の設定ミスに気づいてしまった。

もうちょっと厳密に計算できるが、計算結果が増えるか減るかわからん。

車庫証明がないと渋滞が起こる?

Cities:Skylines2で最初に作った都市も人口42万人にも達し、

これ以上やるのも難しいかなと思いつつも、もう少しできることはあるんじゃないかと。

で、市内各所で渋滞が起きているのだが、ある時はここで渋滞が発生し、

ある時はここで渋滞が発生し、と渋滞が起こる場所が転々としていることに気づく。

で、いろいろ観察していたのだが、原因は駐車場を探す車による渋滞だったらしい。


中密度以上の住宅には駐車場が備わっていない。

この場合、車を持つことを希望する住民は車を路上か駐車場に停める。

このゲームはあまり気にせずに道路を引くと路上駐車が発生する。

日本の感覚では路上駐車が基本というのは変な感じがするけど、

アパートに駐車場がないというのもそれはそれで変な話である。


ただ、それ以上におかしいのは、駐車場を探し回って右往左往する車が多数発生することである。

駐車場のアテが付かない場合は車を持たないというロジックは存在するらしいが、

1台でも駐車スペースに空きがあれば、車を所有できると考えてしまうそうで、

駐車場のわずか数台の空きをめがけて何十台も押しかけるわけである。

当然、駐車できるわけはないので、大半の車が引き返して他の駐車スペースを探す。

大抵の場合は他の駐車スペースに空きが1台は空きが存在するので、そこをめがけて走り出す。

これが渋滞が起きる場所が転々としていた理由であり、転回が多数発生する原因でもある。


日本では車庫証明という制度があり、自動車を保有するには使用の本拠(通常は自宅)の近くに保管場所がなければならない。

「保管場所を使用できる権原を有すること」という要件があって、

自己所有なのか月極契約なのかはさておき、必要時には駐車できる必要があるので、

通常は保管場所から車を出すと、帰ってくるまで空きであるのが通常である。

ところがこのゲームは駐車場所の裏付けがなくても車は所有できるし、

駐車場所から車を出すと、駐車場所を他の車に奪われてしまうのは普通である。

結果として自宅近くの駐車場所には戻ってこられない可能性もある。

こうなるとどこでもいいから駐車場所を探して彷徨うことになる。


SimCityで高密度住宅から1000台とか車が出てきて、明らかにおかしいだろと思ったことはあるけど、

住宅には必ず駐車場を備えているというモデルであれば、

とりあえず自宅には車を停めることはできるので上記のような問題は起きない。

ところがCities:Skylinesシリーズでは自宅に駐車場があるとは限らないし、

外部に駐車する場合に日本で言うところの「保管場所」としての駐車スペースと、

目的地の駐車スペースを区別する仕組みが無いので、駐車スペースが見つかる保証がないのである。


この問題の打開策はいくつかある。

1つは自宅付近に十分な駐車スペースを用意するという方法。

低密度住宅であれば敷地内に駐車場があるので容易に実現できる。

「駐車場付き道路」という多くの車両が路上駐車できる道路もある。

ただ、これだけだと中密度住宅にも追いつかないのが実情だと思う。

入居時などに駐車したい車が殺到すると、駐車スペースを探して右往左往して渋滞が発生して、

これがなかなか引かないで公共サービスにも影響を来すということはあると思う。

低密度中心でなければ取り得ないアプローチかもしれない。


逆に全く駐車スペースを用意しないというアプローチもある。

駐車場を作らず、道路も路上駐車できないものばかり作るわけである。

3車線道路、街路、砂利道、高速道路などを選べば路上駐車できなくなる。

2車線道路などは街路樹・広い歩道・草地を付加することで路上駐車を封じることができる。

こうして徹底的に駐車スペースをなくしていくと、どこにも駐車できないという判定になり、

低密度住宅などで駐車場のアテのある車以外は存在しなくなるわけである。

大都市を目指すならこのアプローチが楽には違いない。


で、もう1つ代表的なアプローチとして、郊外に駐車場を設けるという方法がある。

郊外に車を停めて地下鉄などで移動するという形にするのである。

十分な数の駐車スペースがあれば、駐車場を求めて彷徨う車もいつかは駐車できる。

市街地に十分な駐車スペースを設けるのは難しい面もある。

例え十分なスペースがあっても右往左往する車で大渋滞となり様々支障がある。

後で書くような事情もあり、どうしても駐車場付近の渋滞は避けられないので、

渋滞対策の容易性や、公共サービスへの影響を考えれば郊外に駐車場を集めるのが理にかなっているわけである。


最初は2番目に書いた方法がよいかと思ったが、それはそれでリアリティがないので、

3番目に書いた郊外に駐車場を設けるアプローチでいくことに。

郊外の3つの駅前に立体駐車場をずらりと移設・新設していく。

高速道路に直結したところにある駅なので、車を集めるにも好都合である。

立体駐車場はアップグレードすると300台まで収容できる。

維持費が比較的高価らしいが、すさまじい黒字なので気にしない。

立体駐車場以外の既設の駐車場は削除、路上駐車できる道路はできるだけ差し替えていく。


そんなので市街地からは駐車場を求めて彷徨う車はほぼいなくなり、

駅前は駐車場を求める車であふれ、その渋滞は高速道路の本線まで伸びるものも。

駐車場までの道路を長くするなどの調整をして、他への影響を軽減しつつじっくり待つ。

車の動きを観察すると、人気の駐車場に殺到して、満車になって別の駐車場に並び直しをしたり、

列から抜ける車が何台もいると思ったら、路上駐車を潰せてなかった道路に向かっていたり……

数量として充足していてもなかなかスムーズに停めてくれないのが実情である。

どうしても渋滞が長引くことは避けられないので、郊外で処理した方がよい。


最終的に3つの駅前に計50棟の立体駐車場が並ぶこととなった。

42万人に対して15000台の公共駐車場を用意したという形である。

そこから自宅などには地下鉄(大半は高架だけど)・徒歩などで移動する。

で、おそらく通勤・買い物などの日常生活ではほぼ自家用車は使っていないはず。

なぜならば目的地にはほぼ駐車場がないからである。

一部には自家用車での通勤もあるが割合としては少なく、地下鉄・徒歩が主とみられる。

このため入庫する車(並び直し含む)は混むが、出庫する車で混むという光景はみられない。

市外への移動など、どうしても車が便利な移動では活用しているようだが、全体としてはわずかである。

冒頭で書いたように駐車場を探す車による渋滞が多くを占めていたことの証拠でもある。

まだしばらくはこの都市でやっていけそうだなと思った。


地下鉄がある現在ならこのアプローチは全く問題ないけど。

地下鉄・鉄道などができる以前の公共交通といえばバスだろうけど、

バスは利用者が多くなると乗降で混雑し、数珠つなぎになってしまう。

郊外の駐車場と結ぶためのバスを運行するとどれぐらい混むのかわからないけど、

あれもこれもバスで移動となるとけっこう大変ではないかと思う。

何もかも自家用車では道路の渋滞が大変だが、バスばかり使われてはバスの運行の妨げになる。

となるとある段階までは1番目に書いたような駐車スペースを分散させるアプローチがよいのかもしれない。

いずれにせよ駐車場を探す車による渋滞が延々続くのは避けたいのだから。

コードサイズが肥大化した原因

プログラムにある改造を施していたらビルドが通らなくなったと相談があり、

リンカでのエラーで、おそらくプログラムサイズの問題なんだろうなと、

調べてみたら異常にコードサイズが巨大な関数があって、

一体何が原因かと思ったらバイトオーダーを入れ換えるマクロのせいだった。


こんなやつね。

#define SWAP32(v) (((v) & 0xff000000u)>>24)|(((v) & 0xff0000u)>>8) | \
                   (((v) & 0xff00u)<<8)|(((v) & 0xffu)<<24))

こんな処理が愚直に展開されてしまっていたと。

これが何回も何回も出てくる関数がとんでもないサイズに肥大化していたと。

で、さすがにおかしいだろということで確認したところ、

最適化レベルをNoneにしていたらしく、それも相まってすごいサイズになってしまったらしい。


確かにマクロというのは使う場所に都度コードを展開するというものなので、

何度も何度も使うとコードサイズが肥大化する原因にはなりうる。

ただ、コンパイラの最適化が期待できる部分もあり、

上記のマクロにしても a=BSWAP(0x12345678); のような使い方だと、

定数演算はコンパイラで済ませて、a=0x78563412; に相当する処理になるなど、

マクロを使うことによる特有のメリットがあると言うこともまた1つの側面である。

そこの見極めが必要だったんじゃないのというのは1つありますが。


そもそも冒頭に書いたような処理は専用の命令を持ってるCPUが多いわけで……

#define BSWAP32(v) ({ unsigned int r; \
__asm__("rev %0, %1" :"=r" (r):"r" (v)); r; })

のような書き方の方がよかったという説はある。

コンパイラの最適化でこういう置換をしてくれることもあるが、

最適化レベルを下げていたのでそういうのも期待できなかったと。

この話にはさらに続きがあるんだけど、それは書けない話なので書かない。


コードサイズの肥大化という形で問題が顕在化したわけだけど、

よくよく考えてみるとコードサイズが大きい=実行時間が長くなるという構図である可能性も高く、

新規に挿入したマクロでコードサイズが激増したということは、それだけ実行時間が増えるんだろうなと。

コードサイズの増加だけの問題ならばマクロから関数呼び出しに変える方法もあり、

コードサイズへの影響はかなり軽減できることにはなる。

ただ、実行時間の増加という観点ではほぼ変わらないわけである。

そう考えると正直どうなのかなと思うところもある。


バイトオーダーの変換に限らず、いろいろな処理をマクロでやっていて、

ほぼコンパイラで静的に処理されるだろうと期待しているものも多いが、

中にはけっこうなコードサイズの処理になっているものもあるのかもしれない。

かなり衝撃的な話でしたね。

ラブラッドアプリがない人の献血

金曜に献血に行っていた。平日にしてはえらい混んでた気がする。

そこで掲出されていたのだけど、来年1月から献血カードの発行・更新をしなくなり、

ラブラッドアプリを使用しての受付が基本になるそう。


こうなると気になるのがアプリを使えない人への対応である。

アプリがないと献血できない? そんなわけはないでしょう。

何年も前に献血したことがあるような……という人が献血会場に来て、

じゃあ受付用紙に情報を書いてくれと言われて、それを元に検索して、

ありましたねと言われて献血している人はナンボでもいるわけである。

それは来年以降も変わるわけはない。献血久しぶりの人を拒むわけはないのだから。


今後、アプリがない人のワークアラウンドは明示されるかもしれないが、

おそらく都度、氏名・生年月日などで検索するということになるのだと。

取り違えが心配だが、最近は指静脈情報での認証を行っているのでおそらく問題はないだろう。

明確に変わるのは献血カードの発行・更新を行わなくなること。

あのリライタブルカードのシステムを維持するのをやめるということで、

次回献血可能日などをカードに記載して教えるということはやりませんよと。

代替手段として献血者コードを書いた紙切れを渡すようなことはあるかもしれない。

これでも献血時の本人確認としては一定の意義がある。

次回献血可能日は自分で計算するかラブラッドのWebサイトで見るか、それで勘弁してねと。


アプリへの一本化はどうかと思うところはあるけど、

ラブラッドアプリは便利であることは確かである。

1つはアプリからサクッと予約ができること。

昔は予約という概念がなく出たとこ勝負だったり、電話をかけて予約したり、

そんなのだったけど成分献血だと予約しないなんてあり得ないよね。

さすがにバスでの献血を予約する人はそうそういないだろうけど。

もう1つはやはり問診の事前入力である。これは本当に楽である。

15分前までに入れておかないと受付時に反映できないのが注意だが。


ラブラッドアプリを多くの人が利用するようになっていて、

リライタブルカードで献血カードを発行する意味が薄れていて、

ゆえに発行・更新を停止するというのは、理解できる話ではあるが、

全ての人がその恩恵にあずかれるというわけではないのも事実。

で、似たような話があったなと思ったんですよね。

それがETC専用のインターチェンジを暴力団員が利用できるかという話である。

高速6社「暴力団員もETC使わず走行可に」 憲法違反の訴えに反論 (朝日新聞デジタル)

暴力団員はクレジットカードを作ろうとしても拒まれる状況にあり、

ETCパーソナルカードというデポジット式のカードでさえ拒まれる状況。

一方で都市高速を中心に既存の料金所がETC専用化される流れもあり、

こうなるとヤクザは高速道路を使えないという状況にもなりかねない。

それっておかしいんじゃないのという話で、本当に道路が使えなければ確かに問題である。

しかし、高速道路各社の回答としてはサポートレーンに入って料金を後払いするという方法はあると。

この方法ならばETCがない人でもETC専用出入口が使えるという理屈である。

ETCで何らかトラブルがあり、Web・電話で申告してETCカードに請求してもらったり、後で料金所事務所で払ったり、

そういう手続きを行うことは普通にあるわけで、できない話ではないが、

それが正当な手段ですよと言われてしまうと、そうなの? とはなる。


ラブラッドアプリのない人の献血ってのも同じような話だと思いますね。

都度検索すればアプリがなくても献血することはできるが、

それが当然となる人がいていいのかという話は当然の指摘である。

でも、アプリがないひとを拒むことはないのはほぼ間違えない。

【令和8年1月5日(月)から】献血カード・献血手帳の新規発行および更新の終了について (日本赤十字社)

ここに「アプリやカードをお持ちでなくても献血の受付は可能ですが」って書いてあるよね。

所得税の申告で手入力は少なくなった

所得税の申告書類が揃っていることに気づいたのでe-Taxでサクッと申告した。

確定申告の期日前だが、そもそも還付申告なので関係ないし。


で、今回の提出書類の多くがXMLデータだった。

GMOクリック証券の年間取引報告書はXMLで受信にしていたし、

市町村・道府県への寄付金については、各プラットフォームがXMLを出している。

ふるさとチョイス、さとふる、au PAYふるさと納税、それぞれでダウンロードできた。

XMLデータを食わせていくと、これらの項目はほぼ自動入力である。

(譲渡所得は他の費用がないかなど手で入れる項目は多少あったが)


結果として他の入力項目は給与の源泉徴収票と、

それ以外の寄付金(日本赤十字社・国立文化財機構)だけだった。

給与の源泉徴収票は入力項目が多くて煩わしいのだが、

実は事前登録しておけば源泉徴収票のデータが自動入力される機能があるそう。

給与所得の確定申告がさらに簡単に!【利用者用ページ】 (国税庁)

よくわからん書き方だが、e-Taxの「本人確認/情報取得希望」を登録しておく必要がある。


ただ、現状はかなり穴があって、それは勤務先から税務署に源泉徴収票が電子的に送信されている必要があること。

源泉徴収票というのが問題で、給与の源泉徴収票は支払額500万円以下の場合は税務署に送信する必要はない。

ただ、その場合でもほぼ同じ内容を記載した給与支払報告書を市町村に提出する必要があり、

多くの場合はeLTAXという地方税ポータルサイトで電子的に提出されている。

これを元にして住民税の計算を行い、6月に住民税額が届くわけである。

ほぼ同じものをe-Tax(税務署)とeLTAX(市町村)に提出するのは無駄ということで、

eLTAXに提出すれば税務署への提出も兼ねるという制度変更がなされるようだし、

現状でもeLTAXへの送信データ作成時に500万円以下の分も含めてまとめてe-Taxのデータにして提出することはできる。

なのですでに解消されている場合もあるし、将来的にはほぼ解消する見込みである。


あと、僕は職場の年末調整で提出したけど、保険料控除の書類も手入力になりがちだが、

こちらも実はXMLでの受信が可能になっていることがあって、

全国生協連は昨年分からXMLでの発行が可能になったそう。

現状は職場での提出方法が紙での提出だから、郵送されてきたのを出しているけど、

職場でもXMLデータで提出に対応しているところはあるかもしれない。

そもそも所得税の申告をするのなら会社に紙で提出する必要が無いのはそうなのだけど。


その他の寄付金控除もXML形式で作成することはできるが、

ニーズがどの程度あるかという問題はあると思う。

あと、住民税の申告を兼ねるという点では条例指定か否かという情報も必要だが、

これはe-TAXでは自動判別できないので手入力になるはず。

圧倒的にニーズの多い市町村・道府県への寄付金は自動的に判別できるけどね。

(東京都と洲本市・都農町以外は全て対象なわけだし)

日本赤十字社の受領証はどうせPDFでダウンロードするのだし、

同じ情報をXMLでも用意してくれれば助かるのはあるんだけどね。


申告前のチェックで寄付金の条例指定状況の入力がミスしているのに気づき、

危ない危ないと思って修正した程度で、もう慣れたもんですね。

あと、振込先の入力もいらなくなったんですよね。

公金受取口座を使うとしたらそれで済むからである。

この公金受取口座というのも過去の所得税の還付に使った口座なわけで、

実態としては前回のデータを使うに近いのだが、こういうデータを行政機関で保持するようになったのは大きな変化ではある。

ゲーム内のラウンドアバウト

Cities:Skylines2ではラウンドアバウトがシステム的に取り込まれている。

貨物駅周辺の交通をさばくのに効果があるのではと導入してみたが、

それなりによくできたシステムだなと思った。


日本の法令では2014年に環状交差点の制度ができた。

環状交差点の入口に環状交差点標識をつけることにより、

左回り、環道優先、環道内徐行などの効果が得られることとなった。

従来は環道優先というのが明らかではなかったので、

ロータリー交差点の入口には止まれ標識を付けていたが、

環道優先が明らかになる制度ができたことで 止まれ標識を外すのが一般的になった。

すなわち他の車・歩行者がなければ停止せずに環状交差点を通過できると。


Cities:Skylines2では交差点を作ってから、ラウンドアバウトの中央島のパーツを重ねると、

その交差点がラウンドアバウトの交差点になるという仕組みを取っている。

てっきりラウンドアバウトの交差点を置いてから道路を接続すると思ったのだが、

そうではなく交差点の拡張としてラウンドアバウトが存在すると。

当然、単なる十字路に比べて大きいので、既設の交差点に重ねると周辺の建物に影響があるが。


さすがシステム上取り込まれていることもあり、環道優先は徹底されているようだった。

日本のラウンドアバウトは環道内は1車線しか想定されていないが、

ゲーム内では環道内に3車線ぐらいあるのも普通である。

ただ、それがうまくいっているのかというと微妙なところはあるが。

このゲームはとにかく右折が下手なのでラウンドアバウトはある程度マシだが、

やはり交通量が増えてくると苦しいのは現実のラウンドアバウトと同じ。


ただ、一番ダメだったのは環道から出られないという問題で、

これはラウンドアバウトというより接続道路の問題である。

環道優先が徹底されていることの裏返しだが、それで交差点全部潰れるのもひどい話。

それ以外の問題としては環道内の車の流れが途切れず、ある向きからは環道に入れないと言う問題。

これはもう立体交差以外の抜本的な解決はないでしょうね。

平面交差の限界を超えているということなのだし。

横断歩行者に妨害されて進めないというのは信号制御でなければどんな交差点でも起きる問題か。


現実世界だと信号制御が賢いのでそっちの方が処理能力が高いのが定説だが、

Cities:Skylinesの世界では信号制御が下手なので、ラウンドアバウトの方がマシという面はかなりある。

ただ、立体交差化には勝てないというのが実情ですかね。

このレベルの交差点で立体交差化しないとダメなのかと絶望するけど。

立体交差化したら、それはそれで車線変更が下手で困るけど。


で、このゲームはどうにも無駄な走り方をする車が多くて、

あるインターチェンジが改善を重ねても糞詰まりのところがあり、

なんでこっち方向に行く車がこんなに多いんだと調べてみると、

なんでもない片側1車線道路に向かって転回していたのである。

幹線道路はほとんどが一方通行道路というのもあるのかもしれないが、

このゲーム、中央分離帯がないところでは好き勝手に転回するのである。

どうも高速道路を走ってきて、インターチェンジに入り、接続道路に出たら、

片側1車線道路になった途端に転回してインターチェンジに戻るみたいな動きをしていたと。

高速道路の出口をラウンドアバウトで処理したところでもこれが発生して、

ラウンドアバウトを1周回る車が続出し、こうなると他の方向から環道に入れなくなってしまう。


普通はインターチェンジで来た向きに戻る経路は用意しないけれど、

そういうルートを用意しておかないと他への被害が甚大ということで、

わざとそういう穴を用意しておくというのが対策になる。

ただ、そうするとインターチェンジ内を意味不明な走り方をする車が出るし、

それもそれで考え物なんですけどね。


最近新しいパッチが出たようで、死亡率の適正化が行われたらしい。

死者数が多すぎると思っていたので減るのかと想ったらその逆で、

死者数が激増して火葬が間に合わない状態になってしまった。

健康度が低いわけではなさそうだし、一体どういう状況なのか。

人口32万人で火葬場が5つあっても全然回ってない状態で、どうすると。

(パッチ前は火葬場3つで回していた)

火葬が間に合わないことが幸福度に大きな影響を及ぼしてるようには見えないので、

のらりくらりとやっているが、なかなかひどい見た目である。


人口20万人を超えたあたりからいろいろシステムが崩壊している気がするが、

先のパッチで労働者人口が増えるというのもあり、

人手不足問題が解消、一転職場不足になるという状況もあり、

そうなるとそれなりに面白さが増した面もある。