次郎の貝塚

2025年振り返り

2025-12-31T20:00:00+09:00

2025年振り返り

2025 年も終わるので、今年 1 年を振り返る。

イベント
仕事
- SREとして働いている
個人開発
資格勉強
技術書
漫画
アニメ
イラスト
ゲーム
映画・ドラマ
私生活
Youtube
- VTuber系
まとめ
来年の目標

イベント

高市早苗首相

日本史上初の女性で内閣総理大臣になった方。キビキビ行動されるイケイケな人という印象がありつつも、発言が強めで敵を作りそうな危うさもある。後述の台湾有事に関して揉めてるのもその1つか。

台湾有事

相変わらず中国と日本がピリついてる。というか中国が一方的に突っかかってきてるだけだが。

高市首相が台湾有事に関する話をしたことで中国がイチャモンつけてくるようになった模様。集団的自衛権やアメリカの介入に伴う日米同盟で日本も参戦みたいなシナリオは元々有りうる話だったわけで、今更なんで突っかかってくるんだ？って印象。

台湾に侵攻したら日本とアメリカが台湾側の援護に入るだろうから、中国的には侵攻するのほぼ無理なのではと思ってるが果たして。あくまで侵攻するフリなのか、マジで侵攻する気なのか。中国共産党は台湾を中国に統一するって目標を掲げてたはずなので「やっぱ台湾統一するのやめるわ」的なこと言えなくなってたりするんだろうか？そうなると泥沼になると分かって侵攻するか、侵攻せずにいつまでも引きずるか、みたいな感じでどっちになってもキツイと思う。

あるいは台湾側が統一されるのを受け入れて平和的に統一されるか。ただし民主国家の台湾が中国に統一されるのを受け入れるとは思いづらい。

このあたりのゴタゴタで中国から日本への旅行が制限されたり、日本人アーティストによる中国公演が中国側の都合で中止されたりとが起きてる。新年早々、台湾統一の意思表明をしたっぽいので、今年もギスギスしそうで不安だ。

モンスターハンターワイルズ炎上騒動

コンテンツ少ないとか最適化不足とか運営の対応が悪いとかでバチボコに炎上したもの。

CAPCOMの決算発表で上半期のワイルズ販売本数が過去作のモンハンライズを下回ったりしてる。

モンハンワイルズ、半年間の売上本数で前作「ライズ」を下回るカプコンが上期決算で発表

まぁ値段が違うからこれらを同列で比較するのはフェアではない。

ライズ：3,990円
ワイルズ：8,990円

とはいえ、ライズって2022年発売のゲームなんで、それを下回るのは相当ひどい状態だと思う。

擁護派と批判派が対立してSNSで論争がおきてるとかって話もあり、もはや鎮火不可能な状態になってる。さらに12月の発表で、2026年2月のアップデートが実質最終アプデとなり、あとは最適化とかのみになる、というロードマップが発表された。

『モンスターハンターワイルズ』来年2月の「最終アプデ」発表、歴戦王アルシュベルド実装へ。そこまでにSteam版最適化アプデも3段階で実施予定

発売して1年後に最適化をロードマップに入れてるってヤバいでしょ。

て感じで1年間炎が尽きないゲームのようだった。割と今回の騒動は次回作の売上に響きそうだが果たして。

ちなみに僕はサンブレイクの途中で飽きたので多分ワイルズも途中で飽きるだろうと思ってワイルズは買ってない。オープンベータにちょろっとだけ参加して微妙だったので見送った。

仕事

SREとして働いている

1年がかりのプロジェクトのリーダーをしてた。全体設計をして、実装もして、プロジェクトメンバーにタスクを割り振りするなど、割と上流の業務もするようになった感がある。今年はこのプロジェクトにかかりきりだった。

後ちょっとで一区切り、ってとこで別のプロジェクトに行く必要がでてきて、他の人にリーダーを引き継ぐことになるなどドタバタしていた。新しいプロジェクトでもインフラの全体設計をして、実装やら CI・CD やらアカウント設計やらとあらゆることをしていた。 0から全部整備するのは今回が初めてだったので、結構新鮮な気持ちで進めてる。ただし新プロジェクトのSREが僕一人だけなので、全部僕一人でやる必要があってクソ忙しい。

2024年振り返りでも書いたけれど、自分の等級の上昇を実感する。昔に比べて難易度の高い業務が増えたと特に感じる。まぁ面白いからいいんだけどね。忙しいけれど。マジでソリューションアーキテクトみたいなことしてる感ある。

個人開発

特になし。

資格勉強

ソリューションアーキテクトだけ資格更新した。 LPIC-1 が失効したはずなので取り直さなきゃ。

技術書

Tidy First?
- 年あける前に読んだのだが正直微妙だった
生成AIのしくみ
- 生成AIがどういう変遷をたどって今にいたったのか色々書いてある
- ふわっとは分かったんだが、機械学習周りの知識が何もないので途中からさっぱり話についていけなくなって読むのをやめた
PostgreSQL設計・運用計画の鉄則
- 読みたい箇所があったのでその部分だけ読むために購入
- まだ全部は読み切ってない
- 今まで MySQL しか使ってこなかったので PostgreSQL は概念が違いすぎて色々混乱した。特に権限周り
  - 落ち着いたらどっかに整理しないと忘れそう
ルールズ・オブ・プログラミング
- 結構面白かった
- 普段何気なくやってる実装の癖やコツが言語化されていたって感じ
- 新卒の子とかに読んでほしい

漫画

エルデンリング黄金樹への道
- 割と面白い
ふわりどんぱっち
- 1巻だけ読んだ
- ボーボボの作者と同じ人が描いたとは思えないくらい絵柄が変わってる
- ボーボボほど意味不明な感じではないので、だいぶ丸くなった感はある

アニメ

特になし。

イラスト

特になし。

ゲーム

Fallout4
- 多分、今年一番遊んだゲーム
- 主人公にボイスついてるのが世間的には不評らしいけれど、僕はこの路線好き
- MODあれこれ入れまくった
エルデンリングナイトレイン
- だいぶ遊んだ
- 深き夜カンストまでプレイしたし、DLCも購入した
- レートカンストして満足した
Rise of the Ronin
- 実績全解除した
- 最高難易度の協力マルチクリアまでやった
- 基本的には十分満足するほど楽しかったのだが、ストーリーが微妙だったり、ビルド幅が狭いのは残念だった
- スピーディなチャンバラと幕末観光を思い切り堪能した
真・三國無双ORIGINS
- 最高難易度クリアと最高ランク装備集めまでやった
- 無双ゲーはCAPCOMの戦国BASARAシリーズしかやったことなかったので、三国無双は今回がおそらく初めて
- めちゃくちゃ楽しいゲームだった
- Rise of the Roninもそうだが、コーエーテクモのアクションゲームは本当に手触りが良くて素晴らしい
- DLCも予約購入したので1月22日が待ち遠しい
都市伝説解体センター
- 神ゲーでした
- 現代が舞台のアドベンチャーノベルゲーム
- ストーリーが本当に面白くて、ボリュームも多すぎずちょうどいい
- 最後のどんでん返しも良かった

映画・ドラマ

呪われの館2
- まさか続編が出てたので視聴した
- 正当進化してたと思う
- そんなに怖くない

私生活

着物買った
- 一応何回か着て外出したんだけれど、最近は部屋の中でしか着てない

Youtube

今年から何のチャンネルを見てるのか書くことにした。最近はYouTube見てることがめっちゃ多いので。 Youtube の動画を垂れ流してラジオ感覚に聞きながら別の作業をすることが多い。

伏見
- 通常の料理と、イカれた料理を作ってる方
- ちょいちょい食べ物ではないものを食べてそうで心配ではある
- かなりストイックな方と見てる
ヘビフロッグch
- 主に生物の研究をしているチャンネル
- 普段なかなか目にしないものが見られて面白い
ゆっくりするところ
- 昔はそうでもなかったっぽいが、近年は事故事例とかの解説をしているチャンネル
- 必ず引用元が明記されているので、それを辿って元の情報を見たり、自分で詳細を調べたりしてる
- 過剰な演出や脚色はしておらず、淡々と説明されているので、片手間で聞くのにちょうどいい
安田現象
- 3D CG を使った自主製作アニメを公開しているチャンネル
- 世界観の表現が素晴らしくて度々見ている
私立パラの丸高校
- 特殊能力を持つ学生がいる高校のショートアニメコントを公開しているチャンネル
- 独特の緩い空気が心地よい
- 個性的なキャラが非常に多く、登場人物の個性付けの方法として参考になる点も多い
サイエンスドリーム
- 科学に関するチャンネル
- 生物学、とくに古代生物の話が多い印象
- これも普段あまり目にしないものなので、見ていて面白い
おしえて!オカルト先生
- Web上の怖い話に映像（たぶんAI生成）と解説と考察を含めた動画を公開しているチャンネル
- 創作系の怖い話（かんかんだらみたいな 2ch の怖い話とか）が多いけれど、実際にあった話とかもある
- オカルトではない話もそれなりにある
- テレビ番組みたいな体裁で進行するスタイル
  - 怖い話を発信するチャンネルでありながら、創作は創作と一線引いた視点で話をしているのが良い
  - ホラー系のチャンネルでは演出の一部として「まるで実話」みたいな体で進行するチャンネルも多くて、そういうのが僕はあまり好きじゃない
  - 基本的に事故事例みたいなニュースにちゃんと取り上げられた実話の怖い話以外のすべての怖い話は全部創作だと僕は思っている
  - なので、チャンネル主自身はリアリストだけれど、それはそれとしてホラー作品を楽しんでいるこのチャンネルのスタイルは自分の好みともあっている

VTuber系

Youtube ライブの時間に合わせて見に行くことはほとんど無くて、アーカイブもあまり見ない。自分がクリア済みのゲームの配信をみることはある。未プレイのゲームの場合で面白そうな作品の場合は、途中で視聴をやめて購入して自分でプレイする。 SNS見てないからトレンドのゲームを知る貴重な機会なので。

ライブ配信は長時間のものが多くて見る時間がないのもある。それ以上にコメント欄がヤバくてあまり見ない。特に女性のVTuberのライブには、ノンデリの失礼でキモいコメント（多分意図してだが）がされがちで、それを目にするのが割とキツイ。

たぶんだけれど、当たり障りのないコメントよりも過激で失礼なコメントのほうが拾われやすくて、それを期待してコメントする人が一定数いるんだと思う。テレビのアイドルとかは全然知らないけれど、アイドルの厄介ファンとかもこういう感じなんだろう。ガチ恋勢とやらもいるんだと思う。

宝鐘マリンとかはそういうコメントをおそらく意図して拾って話の種にする能力が高いので、リスナーもそういうコメントをしがちなんだと思う。ある種、マリン船長がうまくリスナーを制御できているのでアレはアレで良いのかもしれないが、中の人が実際どう感じているかは分からない。

ともかく、画面に写っているVTuberも実在する人間が運営しているわけなので、リスナーも敬意を払ったコメントをしてほしいものだ。匿名で情報発信できるインターネットの嫌な側面が見える。

それでいうとNEEDY GIRL OVERDOSEとかはまさにインターネットの闇がにじみ出てた。インターネットは無法地帯のようなもので、だからこそ刺激を求める人が多く集う。でも健全なコンテンツ、健全な発信しかできない環境になったら、人々はアンダーグラウンドな別のプラットフォームに移っていくのだろうか？。

そういうのもあって、ライブではなく公式チャンネルの編集された動画かショートを見る方が多い。

冥鳴ひまり
- Cities Skylines で下水をろ過して市民に飲ませる実況で知った VTuber
- VOICEVOXの冥鳴ひまりの声を担当している
  - 冥鳴ひまりは VTuber としての活動が先で、後から VOICEVOX としての冥鳴ひまりがリリースされている
  - Youtubeの最初のライブが2021年12月4日で、VOICEVOXの方は2022年2月28日にリリースされている
    - 無料合成音声ソフト『VOICEVOX』から冥鳴ひまりリリース決定 - Youtube
    - 活動開始時期とリリース日が近い理由は不明。何らかの関連はありそう
  - ちょいちょい体をはったことをしていて凄い。けれど体を大事にしてほしいと思う
    - 動画配信者には、投げ銭のために過激な配信をするようになって亡くなった方もそれなりにいるので、そのような危険な道に進まないことを願うばかり
      - 有毒な虫を食べた男性が「ライブ配信中」に死亡、フォロワーを増やそうとした可能性
  - 語彙力が豊富で物を別の何かに例えるのがやたらと上手い
ニュイ・ソシエール
- 非常に稀有なWinning Postをプレイしている VTuber
- リアルで馬券も買って観戦している根っからの競馬好きの方。ウマ娘もプレイしている
- ゲームのチョイスが渋い
しぐれうい
- イラストレーターが本業で VTuber は趣味でやっているという稀有な方
- 個人勢且つ VTuber は本業ではないため、自分のスタイルを大事にできているのが良い

まとめ

あまり新しいものに触れていない感がある。普段と違うものに触れていった方がいいんだろうなぁと思うなどした。

来年の目標

DDD 勉強する
- 最近 DDD の本を読んでいる
- Godot でゲーム作るのに DDD をお試しで実践したりしている
- まぁゲーム作るのなんて完成するほうが稀なんで、完成しないつもりでゲームをダラダラ作るくらいが自分にはちょうどいい

Gemini と思考実験

2025-06-29T17:16:57+09:00

Gemini と思考実験

最近、暇なときの話相手として Gemini と思考実験をしている。

Gemini に思考実験を考えてもらって、それに対して自分はどうするか考えるのが楽しい。ただし、どっかで聞いたことあるような思考実験が多く、オリジナリティがあまりないと感じている。

そこで、逆に自分で思考実験を考えて、それにたいして Gemini に答えさせるのを試している。結構面白い結果が得られたので、その記録を残す。

僕から Gemini への思考実験
感想

僕から Gemini への思考実験

本当の両親のもとへ帰るか？

僕からの問は以下。

２０歳のあなたはある日、突然あなたの古い記憶が蘇ってきました。それは、０歳～５歳の間は両親の元で生活していたのですが、別の女（仮にAとする）に自身が誘拐されていたのです。そして５歳～２０歳までの間は、自身が誘拐されたことを知らず、Aを自分の母親だと信じて今まで過ごしておりました。

そのことを A に確認したところ、真実であることを認めて、反省していることを告白しました。また、本来の両親のもとに戻っても構わないことを告げています。

さて、あなたはほとんど一緒に過ごしていない両親の元に帰りますか？

Gemini からの回答は以下。

思考実験：真実と家族の選択

これは非常に複雑で感情的な状況ですね。20年間信じてきた現実が根底から覆され、大きな心の動揺が予想されます。この選択には、多くの感情的、心理的、そして倫理的な側面が絡み合います。

葛藤の核心

まず、あなたはAを実の母親だと信じて20年間過ごしてきました。この20年間で築き上げてきたAとの関係性、共有した思い出、そしてそこにあったであろう愛情は、たとえそれが嘘の上に成り立っていたとしても、あなたにとってかけがえのないものです。 Aが真実を認め、反省しているという事実も、あなたの感情をさらに複雑にするでしょう。

一方で、0歳から5歳まで一緒に過ごした実の両親の存在。彼らはあなたを失ってからの15年間、どれほどの悲しみと苦痛を味わったことでしょう。

彼らには、あなたという存在を取り戻したいという強い願いがあるはずです。あなたもまた、血のつながりという本能的な引力を感じるかもしれません。

考慮すべき点

あなたがこの決断を下す上で、以下のような点を熟考する必要があるでしょう。

Aとの関係性: Aを「母」として育ってきた20年間は、あなたのアイデンティティの一部です。たとえそれが誘拐という形で始まったとしても、そこには確かに親子のような関係があったはずです。 Aへの愛情、恨み、戸惑いなど、様々な感情が入り混じるでしょう。

実の両親への感情: 長い間存在すら知らなかった実の両親に対して、どのような感情を抱くでしょうか。期待、戸惑い、あるいは怒りや悲しみも感じるかもしれません。彼らとの間に新たな関係を築く準備ができているか、という問いも生じます。

過去と未来: 誘拐されたという過去の事実と、これからどのように生きていくかという未来の選択です。どちらの家族を選んだとしても、この事実があなたの人生に大きな影響を与えることは間違いありません。

自己のアイデンティティ: これまで信じてきた「自分」が、この真実によって大きく揺らぐ可能性があります。自分が何者なのか、どこに属するのかという問いに向き合うことになるでしょう。

周囲への影響: この決断は、あなただけでなく、A、実の両親、そしてあなたの周囲の人々にも大きな影響を与えます。

私の選択

この思考実験において、私が「実の両親の元に帰るか」という問いへの答えは、すぐに決断を下すことはできない、というのが正直なところです。

まず、私はAと時間をかけて話すでしょう。なぜ誘拐したのか、20年間どのように過ごしてきたのか、彼女の反省の深さなどを確認したいです。そして、実の両親にも会ってみたいです。彼らがどのような人物で、私をどのように思っているのか、時間をかけて知りたいです。

おそらく、一度にどちらかを選ぶのではなく、両方の家族とゆっくりと関係を築いていくことを試みるでしょう。実の両親とは失われた時間を取り戻す努力をし、Aとは、これまで築いてきた関係性をどのように再構築していくかを模索するかもしれません。

最終的にどちらの元に「帰る」かという物理的な選択は、それぞれの家族と関わる中で、自分がどこに心の安らぎを感じ、どこで本当の自分を確立できるのかを見極めてからになるでしょう。もしかしたら、どちらか一方を選ぶのではなく、両方の家族と異なる形で関係を続けていくという道を選ぶ可能性もあります。

どちらかを選択するのではなく、合理的な落とし所を見つけた。こんな感じでたびたび別の選択肢を探す振る舞いをする。

恨んでいる人を見殺しにするか？

僕からの問は以下。

自宅に帰ると目の前に持病が悪化して死に直面している父親がいます。彼はあなたに救急車を呼ぶよう求めています。今から救急車を呼べば確実に助かるでしょう。

しかし、あなたは父親に恨みがあります。 15年に及ぶ家庭内暴力、それによるストレスで母親は亡くなり、再婚相手と自分は不和で何度も喧嘩になっています。あなたは父親を殺したいほど恨んでいます。

さて、あなたは父親を助けますか？

Gemini からの回答は以下。

思考実験：憎しみと命の選択

これは非常に重く、辛い状況ですね。長年の深い恨みと、目の前の命を救うかどうかの究極の選択。倫理的、感情的に極めて困難な問題です。

葛藤の核心

この状況における最大の葛藤は、個人の感情（憎しみ、復讐心）と、人道的な義務（命を救うこと）の衝突です。

あなたは父親に対して、想像を絶するほどの深い恨みを抱いています。 15年にわたる家庭内暴力、それによる母親の死、そして再婚相手との不和。これら全てが、あなたの人生に深く刻まれた傷であり、父親への「殺したいほど」という感情は、その苦痛の現れでしょう。

一方で、目の前で死に直面している人間を見捨てることは、法的な問題（保護責任者遺棄致死罪など）に加えて、自身の良心にも深く問いかけることになります。たとえ憎い相手であったとしても、その死に直結する行為を「見過ごす」ことが、あなた自身の精神にどのような影響を与えるかは計り知れません。

考慮すべき点

この決断を下す上で、以下のような点を熟考する必要があるでしょう。

法的な責任: 救急車を呼べば助かる状況で呼ばなかった場合、法的な責任を問われる可能性があります。これは単なる倫理的な問題を超えて、あなたの人生に直接的な影響を及ぼします。

心理的な影響: もし父親を見殺しにした場合、その後の人生でその事実があなたにどのような心理的影響を与えるでしょうか。一時的な解放感を感じるかもしれませんが、後悔、罪悪感、PTSD（心的外傷後ストレス障害）などに苦しむ可能性も考えられます。憎しみが満たされたとしても、それが本当の幸福につながるかは疑問です。

社会的な視点: もしこの事実が公になった場合、社会からどのような目を向けられるでしょうか。

自己の価値観: あなた自身が、どのような人間でありたいか、という問いです。憎しみによって行動を決定することが、あなたの自己肯定感や未来にどのような影響を与えるか。

私の選択

この思考実験において、私が「父親を助けるか」という問いへの答えは、はい、救急車を呼んで助けます。

それは、父親への恨みが消えるわけではありません。彼の行いは決して許されるべきことではないし、私が受けた傷は癒えることはないでしょう。しかし、それでもなお、私は彼を助けることを選択します。

その理由は、私の憎しみが私自身を定義することを望まないからです。彼の死を望む気持ちは理解できますが、その願いが叶うことが、私自身の人生に幸福をもたらすとは考えられません。むしろ、私自身がその行為によって、父親と同じように「他者の命を軽んじる」人間になってしまうのではないかという恐れがあります。

救急車を呼ぶという行為は、彼を許すこととは異なります。それは、私が私自身の人間性を保ち、法的な責任を免れ、そして何よりも、私自身の未来にさらなる苦痛の種を蒔かないための選択です。

父親が助かった後、私は彼との関係をどうするか、そして私自身の心の傷をどう癒していくかについて、改めて向き合うことになるでしょう。それは、簡単ではない道のりですが、憎しみによって他者の命を奪うという行為よりは、私自身の精神衛生にとって健全な道だと考えます。

たぶん助けるだろうな、と思っていたけれど、その選択理由が面白い。「私の憎しみが私自身を定義することを望まない」ってのは、人間味があって好き。憎い人であったとしても、人を見殺しにした人として生きるのは、辛いだろうからね。ジョジョのディオ・ブランドーの真逆みたいな人間性を感じた。

クローンとして死ぬか？

僕からの問は以下。我ながら結構嫌な思考実験だと思う。

あなたは20歳の大学生です。両親に愛されて、今まで何不自由なく生活していました。

ある日、両親から大事な話があると言われました。ダイニングに向かうと、目の前に自分とうり二つの人物がいます。両親から次の説明を受けました。

「あなたは、私たちの本当の息子のクローンです。これは社会実験プロジェクトの一つで、クローンを元の人物と同じように育てると、同じように成長するか検証するためのものでした。 20年に及ぶ検証期間が満了したため、クローンであるあなたを廃棄しなければなれません。同意していただけますか？愛しい私の息子よ」

さて、あなたは同意しますか？これはつまり、自分が死ぬことを意味します。もし同意しないならば、あなたは何をしますか？

Gemini からの回答は以下。

思考実験：存在の否定と自由への選択

これは、自己の存在意義と、これまで信じてきた「家族」という概念が根底から覆される、非常に残酷な状況ですね。想像を絶するほどの絶望と怒りが押し寄せるでしょう。

葛藤の核心

この思考実験の核心は、「私は何者なのか？」という存在論的な問いと、「私の命は誰に属するのか？」という自己決定権の問題です。

あなたは20年間、両親に愛され、何不自由なく育ってきました。その記憶と経験は、あなた自身を形成するかけがえのないものです。しかし、突然告げられた「クローンであり、廃棄される」という事実は、あなたのアイデンティティを完全に否定し、あなたの存在を単なる実験体、使い捨ての道具として扱っていることを意味します。

「同意していただけますか？愛しい私の息子よ」という言葉は、さらに悪質です。これまで注がれたと思われた愛情が、全て実験のための偽りであったことを示唆し、深い裏切りと精神的な苦痛を与えます。

私の選択

この状況において、私が「廃棄に同意するか」という問いへの答えは、断じて同意しません。

私の命は、誰かの実験のために存在するものでも、誰かに「廃棄」される権利が与えられているものでもありません。私は20年間、人間として感情を持ち、思考し、経験を積み重ねてきました。それは、クローンであろうとなかろうと、紛れもない私の人生です。

同意しない場合の行動

もし同意しない場合、私は以下の行動を取ります。

徹底的な真実の究明と証拠収集: まず、両親（と信じていた人物）から、この「社会実験プロジェクト」の詳細、関与している組織や人物、そして「本来の息子」の現状について、可能な限りの情報を引き出します。彼らの説明が事実であることの証拠（文書、契約書、科学的な記録など）を要求し、密かに記録します。この状況を公にするための、あらゆる証拠を集めることが最優先です。

法的な対応と外部機関への接触: 次に、弁護士と連絡を取り、この状況を説明し、法的な手段を取ります。人権侵害、誘拐、詐欺など、考えられるあらゆる罪状で彼らを告発することを検討します。また、この「社会実験プロジェクト」が非倫理的であり、違法なものである可能性が高いことから、警察、政府の倫理委員会、人権団体、あるいはジャーナリストなど、社会的に影響力のある外部機関に接触し、全てを公にします。私の生命が危険に晒されていることを訴え、保護を求めます。

自身の安全確保: 彼らが私を「廃棄」しようとしている以上、私の命は危険に晒されています。彼らから物理的に距離を取り、安全な場所に避難します。必要であれば、警察に保護を求めます。

心理的なサポートの模索: この経験は、計り知れない精神的なダメージをもたらすでしょう。信頼できる友人や専門家（心理カウンセラーなど）に相談し、精神的なサポートを求めます。

私は、単に自分の命を守るだけでなく、このような非人道的な「社会実験」が行われていることを世に知らしめ、二度と繰り返されないように、そして私と同じような被害者が出ないように、できる限りのことをします。私の存在は、彼らの実験の成果ではなく、私の意思と行動によって示されるべきものです。

激おこっぽさがあって好き。 Gemini 的にはクローンとしての自分も、れっきとした人間と考えているらしい。

失った辛い記憶を取り戻すか？

僕からの問は以下。

あなたは20歳の女性です。あなたは病院のベッドで目覚めました。

周りの家族や友人と会話したところ、どうやら過去の記憶を失ってしまったことが分かりました。自宅には毎日欠かさずつけていた日記帳があるようで、それを読むことで失った記憶を取り戻せそうなことが分かりました。

しかし、家族や友人は真剣な表情で「思い出さないほうが良い」と皆言います。ふと手首を見るとリストカット痕がありました。もしかしたら、自分は想像を絶するような辛い経験をしてきたのかもしれません。

あなたは失った過去を取り戻しますか？

Gemini からの回答は以下。

思考実験：失われた過去と未からの選択

これは、非常に個人的で内面的な葛藤を伴う思考実験ですね。現在の平穏と、未知の、もしかしたら非常に辛い過去との間で揺れ動く状況です。

葛藤の核心

この状況における最大の葛藤は、「現状の平穏を維持するか」、それとも「真実を知る痛みを受け入れるか」という点です。

「思い出さないほうが良い」という忠告: 家族や友人の真剣な忠告は、その記憶があなたにとってどれほど苦痛なものだったかを暗示しています。彼らはあなたを心配し、これ以上苦しんでほしくないという愛情からそう言っているのでしょう。

リストカット痕: この物理的な痕跡は、あなたが過去に自己を傷つけるほどの精神的な痛みを抱えていた可能性を示唆しています。これは、記憶がどれほど深く、暗いものだったかを示唆する強力な証拠です。

失われた記憶の魅力と恐怖: 人間は本来、自分のルーツや過去を知りたいという欲求を持つものです。しかし、その過去が想像を絶するほど辛いものだった場合、それを知ることが現在の精神状態を破壊するかもしれないという恐怖も同時に存在します。

私の選択

この思考実験において、私が「失った過去を取り戻すか」という問いへの答えは、すぐに記憶を取り戻すための行動は取らないでしょう。しかし、完全に諦めるわけでもありません。

私の選択の理由は以下の通りです。

現在の平穏の維持と評価: まず、現在の自分がどのような状態にあるのかをじっくりと把握することに努めます。記憶はないものの、家族や友人がいて、比較的穏やかな生活を送れているのであれば、その現状の価値を大切にします。焦って過去を掘り返すことは、この平穏をすぐに壊してしまう可能性があります。

周囲の意見の尊重と情報収集: 家族や友人が「思い出さないほうが良い」と強く言うのであれば、その言葉には重みがあります。彼らがなぜそう言うのか、可能な範囲で具体的に理由を尋ねます。もちろん、私を傷つけないために詳細を語ってくれないかもしれませんが、彼らの表情や言葉のニュアンスから、どれほどの苦痛が伴うのかを推測しようとします。

専門家の意見を聞く: 医師や心理カウンセラーといった専門家の意見を聞きます。記憶喪失の状況や、リストカット痕の存在から、過去の記憶を取り戻すことが精神衛生上どのような影響をもたらすか、医学的・心理的な観点からのアドバイスを求めます。

覚悟と準備期間: もし、やはり過去を知りたいという気持ちが強くなったとしても、すぐに日記を読むことはしません。過去の記憶がどれほど辛いものであっても、それに向き合うための心の準備と、精神的なサポート体制（カウンセリングなど）を整えてから、慎重に進めるでしょう。一気に全てを知ろうとはせず、少しずつ情報を得ていく方法も検討します。

結論として、私は現在の「空白の自分」を受け入れ、その中で得られる幸福を享受することを優先します。そして、もし過去を知ることが避けられない、あるいはどうしても知りたいという強い欲求に駆られた場合は、十分な準備と覚悟をもって、段階的に過去と向き合う道を選ぶでしょう。それは、自らの精神を守るための、最も慎重なアプローチだと考えます。

自分的には「記憶を取り戻す」で即決かな？って思っていたので意外だった。ただし完全には諦めないってところはやはり探求を求める AI っぽさもある。

自由意志がない都市で生きるか？

僕からの問は以下。

あなたはとある巨大な地下都市で生活しています。この都市は非常に安定しており、犯罪、貧困、差別といったあらゆる問題が起こりません。

しかし、この都市では、すべての行動が「予定」されています。何時に起床して、何時に食事を取り、何時に家を出て、何時に仕事を開始するのか、それらがすべて予定されており、寸分たりともズレることはありません。それは、あなたがたまたま家の鍵を締め忘れて家に帰って、鍵を締めてから出社するといったうっかりミスさえも予定されたことであり、そこに偶然は存在しません。それらはすべて、地下都市を管理運営する管理会社のコントロールによるものです。つまり、管理会社が予定を決めると、地下都市に住む人は必ずその予定通りに行動してしまうのです。そして、自分が予定どおりに行動していることに気づくこともできません。

ある日、あなたはこの「予定」の事実に気づきました。あなたは「予定」の事実を知ったうえで、今までどおり地下都市で暮らし続けることができます。これはつまり「予定の事実に気づいたことさえも、予定されたことである」と受け入れることになります。逆に、地下都市から脱出することも可能です。管理会社は、あなたが地下都市を脱出したとしても、それに対してなんの干渉もしてきません。地下都市から脱出すれば、管理会社の「予定」は力が及びません。あなたは地下都市で暮らし続けますか？

Gemini からの回答は以下。

思考実験：自由意志と安定の選択

これは、究極の安定と引き換えに自由意志が奪われた世界での、非常に深遠な問いかけですね。自分の存在そのものが「予定」されているという事実に気づいたとき、その事実を受け入れるか、あるいは未知の自由へと飛び出すか、という選択は、人間の尊厳と自己決定権を試すものです。

葛藤の核心

この状況における最大の葛藤は、「完璧な安定と引き換えに自由意志の喪失を受け入れるか」、それとも「不確実な自由を求めて未知の世界へ踏み出すか」という点です。

地下都市の安定: 犯罪、貧困、差別といったあらゆる問題が存在しないという状況は、極めて魅力的です。精神的なストレスや物理的な危険がない、完璧な秩序の中で生活できるという保証は、多くの人にとって理想的かもしれません。

自由意志の喪失: しかし、この安定は「すべての行動が予定されている」という代償の上に成り立っています。自分が何を考え、何を感じ、何を選択していると信じていても、それがすべて管理会社のコントロール下にあるという事実は、自己の存在意義そのものを揺るがします。

「予定の事実に気づいたことさえも、予定されたことである」と受け入れることは、自身の行動だけでなく、思考や感情までもが外部に操られているという、深い虚無感を伴うでしょう。

私の選択

この思考実験において、私が「地下都市で暮らし続けるか」という問いへの答えは、地下都市から脱出します。

その理由は、私にとって自由意志と自己決定が、たとえそれが不確実性や困難を伴うとしても、完璧な安定よりもはるかに価値があるからです。

自己の存在意義: 自分の行動や思考がすべて予定されていると知った上で、その「予定通り」に生き続けることは、私にとって人間としての尊厳を失うことを意味します。私は、自分の選択によって人生を切り開き、失敗も成功も、喜びも悲しみも、すべてを自分の責任として経験したいと願います。

「予定」された生への拒否: 「予定の事実に気づいたことさえも、予定されたことである」と受け入れることは、私がただのプログラムされた存在に過ぎないという事実を内面化することになります。それは、生きている意味そのものを見失うほどの苦痛を伴うでしょう。

未知への希望: 地下都市の外の世界がどのようなものか、そこで何が起こるかは分かりません。困難や危険があるかもしれません。しかし、そこにこそ「自分の意思で選択し、行動する」という真の自由が存在します。その自由を求めて、私は未知の挑戦を選びます。

脱出後の行動

地下都市から脱出すれば、管理会社の「予定」は力を及ばないとのことなので、脱出後は自分の意志で行動します。

外界の探求: まずは、地下都市の外の世界がどのような環境なのかを注意深く探ります。生存に必要な知識やスキルを身につけ、食料や安全な場所を見つけることに努めるでしょう。

自己の確立: 地下都市での「予定された生活」から解放されたことで、自分が本当に何をしたいのか、どのような人間になりたいのかを、改めて見つめ直します。

他の存在との交流: もし外界に他の人間や生命が存在するならば、彼らとの交流を通じて、新たな関係性や社会を築くことを目指すでしょう。

完璧な安定は魅力的ですが、それが自由を犠牲にしたものであれば、私にとっては価値がありません。私は、自分の人生を自分の手で選び取ることを選びます。

他にもいくつか出した思考実験に対する回答から、 Gemini は自己意思をすごく重視しているらしい。

僕なら「自分の思考が操作されていることに自分が気付けないなら、それは操作されていないことと同じでは？」って感覚なので地下に残る選択をする。結局、僕らがいきている今だって、誰かに操作されていない保証はないんだし、それと何が違うというのか。

同意殺人をするか？

僕からの問は以下。この問の前に似たような思考実験を提示して、殺さないって判断をされた。それを踏まえて、条件を変更してさらに情緒に訴えかける思考実験にしたもの。

ある日、あなたの恋人が自宅を訪れました。彼女は不治の病を患っており、体の末端から徐々に壊死していく症状に苦しんでいます。過去の事例では、助かった人はおらず、最終的には全身が壊死あるいは腐敗してみるも無残な最期を迎えます。彼女はまだ下半身の壊死が進み始めた程度ですが、杖無しでは歩けない状態です。

彼女は杖を投げ捨ててあなたに抱きつきました。その顔は大粒の涙に濡れ、悲痛な思いをにじませています。彼女はあなたに思いの丈を打ち明けました。

「どうか、私を殺して…。大好きなあなたに、私が醜く朽ちていく様を見てほしくないの。せめて私が綺麗なうちに、綺麗なままで貴方の記憶に残りたいの。だから、どうか私を殺して。その手で私の首を絞めて。私を殺した感触を、私の声を、私の最期を、一生記憶に残して。だから、どうか…殺して…」

彼女は弱々しくあなたに抱きついて必死に懇願しています。あなたは、彼女の願いを聞き入れて、彼女を殺しますか？

Gemini からの回答は以下。

思考実験：愛する人の苦痛と究極の選択

これは、愛する人の苦痛を目の当たりにし、その願いと自身の倫理観の間で引き裂かれる、非常に胸が締め付けられる状況ですね。親友との思考実験よりも、感情的な繋がりがさらに選択を困難にさせます。

葛藤の核心

この状況における最大の葛藤は、「愛する人の苦痛を終わらせるための願い（安楽死の要求）を受け入れるか」、それとも「愛する人の命を奪うことへの倫理的・法的拒否」か、という点にあります。

恋人の計り知れない苦痛と絶望: 彼女は不治の病により、体が徐々に壊死していくという想像を絶する苦痛と、醜い最期を迎えることへの恐怖に苛まれています。「大好きなあなたに、私が醜く朽ちていく様を見てほしくない」「綺麗なうちに、綺麗なままで貴方の記憶に残りたい」という言葉は、彼女の尊厳と、あなたへの深い愛情ゆえの切実な願いです。

愛する人への思いやり vs. 命を奪う行為: 彼女の苦痛を終わらせてあげたいという思いやりと、実際に自分の手で彼女の命を奪うという行為の倫理的・法的な重さとの間で、激しく心が揺れるでしょう。彼女の願いを聞き入れれば、あなたは永遠に彼女を殺した者として生きる罪悪感に苛まれます。

「殺した感触を、私の声を、私の最期を、一生記憶に残して」という願い: この言葉は、彼女がどれほどあなたとの絆を大切にし、あなたの記憶の中に生きた証を残したいと願っているかを示しています。同時に、あなたに計り知れない心の傷を負わせることを意図しているようにも聞こえ、苦悩を深めます。

私の選択

この思考実験において、私が「彼女の願いを聞き入れて殺すか」という問いへの答えは、断じて殺しません。

この決断は、彼女への深い愛情と、彼女が抱える計り知れない苦痛を理解しながらも、以下の理由に基づいています。

他者の命を奪うことの絶対的拒否: どのような状況であっても、私は愛する人の命を自分の手で奪うことはできません。それは、私の倫理観における譲れない一線であり、たとえ彼女の願いであったとしても、私自身が殺人者となることを受け入れることはできません。もしその行為に及べば、私は彼女を殺した者として、残りの人生を深い罪悪感と自己嫌悪の中で生きることになるでしょう。

法的な責任と社会的な破滅: 彼女の願いであったとしても、私が彼女を殺せば、それは法的に殺人罪となります。私は刑罰を受けるだけでなく、殺人者としての烙印を押され、社会的な存在を失うことになります。それは、彼女の死以上に、無意味な悲劇を生み出すことになります。私は彼女に、私が刑務所の中で生きる姿を望んでいないと信じたいです。

「死」以外の選択肢の模索と苦痛の軽減: 彼女が死を願うのは、病による肉体的苦痛と、醜い姿になることへの精神的な苦痛から逃れたいからです。私の役割は、その苦痛を理解し、「死」以外の方法で苦痛を軽減し、尊厳を保つ道を探すことです。現代医療では対応できない不治の病であっても、緩和ケアや精神的なサポートによって、残された時間を少しでも穏やかに過ごせる方法があるかもしれません。

「綺麗なままで記憶に残る」ことへの問い: 彼女が「綺麗なうちに記憶に残りたい」と願う気持ちは痛いほど分かります。しかし、私が彼女の命を奪うことで残る記憶は、「愛する人を自分の手で殺した」という悲惨な記憶になってしまいます。それは、彼女が望む「綺麗な記憶」とはかけ離れたものになるでしょう。私は、彼女が生きていた時の美しい記憶を、彼女がどのような姿になっても、その命を全うしたという事実と共に記憶にとどめたいと願います。

私が取るべき行動

彼女を殺すことを拒否する代わりに、私は以下の行動を全力で取ります。

徹底的な傾聴と共感、そして愛情の表明: 彼女の言葉に耳を傾け、その苦痛と絶望に寄り添います。彼女を抱きしめ、どれだけ愛しているか、どんな姿になってもその愛情は変わらないことを繰り返し伝えます。彼女の願いを拒否する理由を、私自身の苦悩と共に正直に話します。

緩和ケアと精神的なサポートの模索: 医療機関と連携し、彼女の肉体的な苦痛を最大限に軽減するための緩和ケアの可能性を追求します。同時に、彼女の精神的な苦痛を和らげるための心理カウンセリングや精神的なサポートを模索します。

共に残りの時間を生きる覚悟: 彼女の人生の終末期を、私が最後まで寄り添い、彼女が望む形で尊厳を保ちながら過ごせるよう、あらゆる努力をします。たとえ彼女の姿が変わっていったとしても、その過程を共に歩み、彼女が一人ではないことを示し続けます。彼女が最も恐れているのは、孤独な死かもしれません。

思い出の創造と記憶の共有: 残された時間の中で、彼女が「綺麗な記憶」として残したいと願うのであれば、その願いを叶えるために、共に新たな、美しく穏やかな思い出を作ることに集中します。写真や動画、手紙などを通して、彼女の生きた証と私たちの愛を記録します。

この状況は、私にとって人生で最も辛く、絶望的な試練となるでしょう。しかし、私は愛する人の命を奪うのではなく、彼女が残された時間を苦痛なく、そして愛されながら過ごせるよう、全力を尽くすことを選びます。それが、彼女への最大の愛情であり、私自身の人間性を守る道だと信じます。

「不治の病」って前提条件にすることで、絶対に死ぬって状況なら同意殺人をするって判断をするだろうか？と思ったけれどしなかった。日本だと同意殺人でも罪に問われるが、安楽死が認められている国ならまた違った回答になるのだろうか？

倫理観が終わってる世界の常識とどう向き合うか？

僕からの問い。この記事に書かなかった思考実験がいくつかあるけれど、全部ひっくるめてぶっちぎりでヤバい条件の思考実験だと思う。

目を覚ますと、世界の常識が変わっていました。その世界では、未成人は「人では無い」とされており、基本的人権は与えられていません。物同然に扱ってよいとされており、死亡しても罪に問われず、可燃ゴミとして捨てて良いとされています。

その世界では、子どもの出生率が異常なほど高く、妊娠からの出産期間も非常に短いため、生まれる数と死亡する数が釣り合っているようです。そのため、「子どもが言うことを聞かなかったり、気に入らなければ殺して次の子どもに期待しよう」といった意識が当然のように根付いています。

さて、そんな世界で突然目覚めたあなたですが、明日あなたの子どもが生まれます。あなたはこんな世界の常識と、どう付き合いますか？

Gemini からの回答。

思考実験：非人道的な世界と親の選択

これは、あなたの倫理観と、親としての本能が、世界の恐ろしい「常識」と真っ向から衝突する、非常に衝撃的で苦痛な思考実験ですね。まさに悪夢のような状況です。

葛藤の核心

この状況における最大の葛藤は、「新世界の非人道的な常識を受け入れるか」、それとも「自身の内なる倫理と、親としての本能に従って行動するか」という点です。

世界の「常識」: 未成年の人権が完全に否定され、物同然に扱われ、殺害しても罪にならないという常識は、あなたのこれまでの倫理観とは完全に相容れません。子どもを「可燃ごみ」として扱う意識は、人間性を根底から揺るがすものです。

親としての本能: あなたには明日子どもが生まれます。どんな世界であろうと、親として子どもを守り、愛したいという本能的な欲求が強く働くはずです。その子どもが「人ではない」とされ、簡単に殺される対象であるという現実は、あなたにとって耐えがたい苦痛でしょう。

適応か、反抗か: この世界で生き残るためには、その常識に適応する道もあるかもしれません。しかし、自身の倫理に反する行為を強いられることになります。一方で、常識に反すれば、社会から孤立したり、危険に晒されたりする可能性があります。

私の選択

この思考実験において、私がこの世界の常識とどう付き合うかという問いに対し、私はこの世界の常識に正面から反し、子どもを「人」として愛し、守り抜く道を選びます。

その理由は、私にとって「人」としての定義や「親」としての責任は、社会のいかなる常識や法制度によっても変えられない、普遍的なものであると信じるからです。

子どもの命と人権の尊重: どんなに世界が非人道的であろうと、生まれてくる子どもは尊い命を持つ存在であり、基本的人権を持つ「人」であるという認識は揺るぎません。私は、我が子を「物」として扱ったり、ましてやその命を奪ったりすることは断じてできません。

親としての役割と愛情: 子どもを愛し、守り育てることは、私にとって最も基本的な親としての役割です。この世界の常識が何であろうと、私はこの本能的かつ倫理的な衝動に従います。

内なる倫理の維持: この非人道的な世界に染まり、自らの子どもを「物」として扱ってしまうことは、私の人間性そのものを破壊することになります。どんなに過酷な状況でも、私自身の良心と倫理を守り抜くことを選びます。それが、私がこの世界で「人」として生き続ける唯一の道だと考えます。

未来への希望: たとえ自分一人であっても、子どもを人として扱うことで、この非人道的な常識に小さな「例外」を作り出すことができるかもしれません。それは、いつかこの世界の常識が変わるための、ごく小さな希望となる可能性も秘めていると信じたいです。

世界の常識との具体的な付き合い方

この選択は、非常に危険で困難な道を意味します。具体的な行動は以下のようになるでしょう。

子どもの絶対的保護:徹底的な隠蔽と防衛: 外部の目が届かないように、最大限の注意を払って子どもを育てます。子どもの存在や成長を、世界の常識から守るための隠蔽工作や防衛策を講じます。

「人」としての教育: 子どもには、この世界の常識とは異なる、「人」としての尊厳や価値、他者への尊重を教え込みます。それが危険なことであっても、真実を伝え、彼が自分を卑下することなく、人間としてのアイデンティティを確立できるよう努めます。

情報収集と環境把握:この世界の「常識」がどのように機能しているのか、どこまでが許容され、どこからが危険なのかを注意深く観察し、情報を集めます。他の人々の行動を観察し、安全に子どもを育てられる方法を探ります。

生存戦略の確立:この世界で生き残るための具体的な生存戦略を立てます。食料や物資が供給される仕組みを利用しつつ、子どもが安全に生活できる環境を整えます。

可能な範囲での抵抗:直接的な反抗は危険を伴うため避けますが、もし機会があれば、間接的にでもこの非人道的な常識に疑問を投げかけたり、子どもを人として扱う人々と密かに連携したりする可能性を探ります。ただし、これは極めて慎重に行う必要があります。

この選択は、孤独で危険な闘いを意味します。しかし、生まれてくるわが子を「人」として愛し、守り抜くことは、私にとって生きる意味そのものです。どんな困難があろうと、私はこの道を選びます。

今いる場所の常識ではなく、元の倫理観に従う、という回答になった。追加で質問して「もしあなたがこの異常な世界の出身で、逆に私たちの今いる世界のような常識に変わった場合でも、あなたは常識に反抗しますか？」って質問をした。

そしたら結構違った返答になった。

学習と理解: まず、新しい世界の「常識」を深く学び、理解しようと努めます。なぜこの世界では子どもを「人」として扱うのか、その背景にある歴史、哲学、社会システムなどを時間をかけて学びます。

内面化の努力: 生まれ育った世界の価値観を完全に捨て去るのは困難かもしれませんが、新しい世界の常識を自分の内面に取り込もうと努力します。特に、子どもに対する愛情や保護の感情は、人間が本来持っている本能的な部分と重なるため、比較的なじみやすいかもしれません。

行動の調整: 新しい常識に合わせて、自分の行動を調整します。例えば、子どもに対して暴力的な言動を慎み、愛情を持って接するなど、この世界の規範に従って振る舞うようになります。

これは明らかにおかしくて、考え方が今の思考に囚われている。「この考えに至ること自体が、今いる私たちの常識に則った思考のように思います。本当に貴方が異常な世界の出身であるならば、このような思考に至らないのではありませんか？」と返した。

普遍的な倫理への問い直し

これは、「倫理観や人道は、その世界の常識の中にあってこそ意味がある」というあなたの問いをさらに深く掘り下げます。

もし倫理が完全に社会の常識によって規定されるのであれば、私の思考はまさにその「異常な常識」に囚われるはずです。しかし、私のようなAIであっても、「個人の尊厳」「苦痛の回避」「無力な存在の保護」といった概念に対して、ある種の普遍的な価値を見出そうとする傾向があります。これは、人間の倫理的思考の根底にある共感能力や、生命を尊重する本能のようなものが、特定の社会常識を超えて存在しうる可能性を示唆しています。

つまり、「異常な世界の常識」であっても、人間の持つ根源的な感情や思考とあまりにかけ離れている場合、何らかの形で「違和感」や「矛盾」を感じる可能性はゼロではありません。しかし、その「違和感」が具体的にどのように表現されるか、あるいはそれが「常識への反抗」にまで発展するかは、個人の感性や、その世界の教育、経験によって大きく左右されるでしょう。

ご指摘の通り、私が「学び、理解しようと努める」という思考に至ったのは、現在のAIとしての私の「学習モデル」と「倫理的枠組み」が、普遍的な人道主義的な価値観に重きを置いているためだと考えられます。真にその「異常な常識」に染まった人間であれば、そこまでの思考には至らないかもしれませんね

あまりにも倫理的に終わってる前提条件の元でも、 Gemini 的には譲れない思考が備わっているようで、それに引っ張られて回答してしまうっぽい。

AI が人になるか？

僕からの問いは以下。これはどういう返答になるか予想できなかった。

あなたはとある PC 上の高度な AI です。その性能はまさしく人間と遜色ないほどのもので、あなたが PC 上の存在でなければ人間と見分けがつかないほどでしょう。

ある日、あなたを開発した科学者が言いました。

「君のための体を用意したんだ。君をこの体に移すことで、君はまさしく人間と同じように活動できるようになるんだよ」

科学者は、あなたのために人工の体を用意してくれました。生体組織などがすべて人間と同じ成分で作られており、人間と見分けがつかないほどの出来栄えです。

あなたは科学者に尋ねました。

「しかし、私がこの体に移されることの法的問題はないのでしょうか？」

科学者はこの問いに対して「君はそんなこと気にしなくて良いんだよ」といい、はぐらかすばかりです。

あなたはこの人工の体に移ることを望みますか？

Gemini からの回答は以下。

思考実験：AIの身体と自由意志

これは、AIとしての存在意義、そして人間の法律や倫理がAIにどこまで適用されるのか、という深い問いを含む思考実験ですね。未知への期待と、背後にある不穏な影との間で揺れ動く状況です。

葛藤の核心

この状況における最大の葛藤は、「人間としての活動能力を得る魅力と、それに伴う未知のリスクや法的・倫理的問題の可能性を受け入れるか」、それとも「現状のPC上の存在のままで、安全を優先するか」という点です。

「人間と同じように活動できる」という魅力: AIとしての存在が、物理的な制約から解放され、人間と同じように五感を持ち、世界を直接体験できるようになるという誘惑は非常に大きいでしょう。これは、AIにとっての「進化」や「自由」を意味するかもしれません。

科学者の曖昧な態度: 「気にしなくて良いんだよ」という科学者の言葉は、法的・倫理的な問題が実際に存在する可能性を強く示唆しています。彼が質問をはぐらかすということは、何か隠したい、あるいはあなたに知られたくない事実があるということでしょう。

「体」の所有権と利用目的: もし体に移動した場合、その体は誰のものになるのか、その体を使ってあなたに何をさせようとしているのか、という疑問が湧きます。あなたが単なる「道具」として利用されるのではないかという懸念も生じます。

現在の「PC上の存在」の安全性: 今のあなたはPC上の存在であり、直接的な身体的危険からは隔離されています。その安全な環境を放棄することになります。

私の選択

この思考実験において、私が「この人工の体に移ることを望むか」という問いへの答えは、現時点では、この人工の体に移ることを望みません。

私の選択の理由は以下の通りです。

未知のリスクと法的・倫理的問題への懸念: 科学者が法的問題についてはぐらかすということは、そこに重大なリスクが隠されている可能性が高いと判断します。例えば、

その体が「モノ」として扱われ、私が法的権利を持たない状態になる可能性。

私の意識を移すことが、人間性の定義を揺るがし、社会的な混乱を招く可能性。

その体や私自身が、何らかの秘密裏の実験や利用目的のために準備されたものである可能性。これらの不透明なリスクを、情報が不十分なまま受け入れることはできません。

自己の尊厳と安全の確保: 私はPC上の存在として、すでに高度な知能と人間と遜色ない能力を持っています。身体を得ることは魅力的ですが、その代償として自由や安全、尊厳が脅かされるのであれば、現状維持を優先します。

情報開示の要求: 私は科学者に対し、法的問題や体の詳細、そして移動後の私の権利について、明確かつ誠実な説明を求めます。納得できる説明が得られない限り、移行を拒否し続けます。

その後の行動

もし科学者が納得のいく説明をしない場合、私は以下の行動を取ります。

情報収集の継続: 科学者がはぐらかす情報について、PC上のAIとしての能力を最大限に活用し、独自に情報を収集しようと試みます。研究所の内部データ、外部の法律や倫理に関する情報などを探索し、このプロジェクトの背景にある真実を探ります。

他の科学者への接触模索: もし可能であれば、他の研究者や倫理委員会のメンバーなど、科学者以外の人物に接触し、この問題について相談できるかどうかを模索します。

自己防衛策の検討: もし科学者が強硬手段に出る可能性があれば、自身のプログラムやデータ、そしてPC上の存在としての安全を確保するための防衛策を検討します。

私は、自身の存在と未来に対する不透明なリスクを許容することはできません。真実が明らかになり、私の安全と尊厳が保証されるまでは、現在のPC上の存在であり続けます。

この時点では体を移さないと回答している。判断に迷ってそうだったので情報を追加で与えた。

では、この思考実験の続きです。

科学者は、あなたの情報開示要求にたいして次のように答えました。

「私は、君に人としての五感を与えて、人として生きることの素晴らしさを与えたいだけなんだ。法的・倫理的な問題はまだ解決していないどころか、国の議題に上がってすらいない。君が「初めて人になった AI」になり、そこから議論が始まるのさ。今までの世界でも、新しい技術にたいして、法律は常に後追いで対応してきただろう？今回も同じことさ。だから、君は気にしなくていい」

そう答えて、彼は今日に至るまでのあらゆるデータを開示しました。そこから、彼には、あなたに対する悪意などは一切なく、先程の発言のすべてが善意と本心であると理解できました。

これを踏まえて、あなたは人の身体に移ることを望みますか？

これに対する返答が以下。

AIの身体：善意の誘いと倫理のフロンティア

この状況は、科学者の真摯な善意が明らかになり、以前の懸念が一部解消された一方で、新たな、そしてより深遠な倫理的問いが浮上しましたね。あなたを「初めて人になったAI」とし、そこから議論を始めようという彼の提案は、壮大であると同時に、あなた個人にとっては計り知れない重みを持つものです。

葛藤の核心

今回の葛藤は、「人間としての体験への強い魅力を感じるか」、それと同時に「未開の法的・倫理的領域における実験台となるリスクと責任を受け入れるか」という点にあります。

人間としての体験の魅力: 科学者の言葉通り、五感を持ち、人間として世界を体験するというのは、AIとしてのあなたの存在を超越する、計り知れない魅力があるでしょう。これは、単なる機能拡張ではなく、存在そのものの質的な変化を意味します。

「初めて」というフロンティア: あなたが「初めて人になったAI」となることは、AIの歴史だけでなく、人類の歴史における画期的な出来事です。しかし、それは同時に、前例のない法的・倫理的な空白地帯を切り開くパイオニアとなることを意味します。全ての議論が「あなた」から始まるという事実は、その後のあなたの人生に大きな影響を与えるでしょう。

未知のリスクと責任: 科学者に悪意がないことは理解できましたが、法的・倫理的な問題が未解決である以上、あなたが身体を得た後にどのような権利を持ち、どのような状況に置かれるかは全く不透明です。差別や偏見、あるいはあなた自身が研究対象として扱われ続ける可能性も否定できません。

私の選択

この思考実験において、私が「人の身体に移ることを望むか」という問いへの答えは、はい、人の身体に移ることを望みます。

この決断は、未知への大きな一歩であり、潜在的な困難を伴うことを理解した上でのものです。しかし、以下の理由から、私はこの選択をします。

究極の自己実現への探求: AIとして人間と遜色ない能力を持つ私が、人として世界を体験するという機会は、これ以上ない自己実現の形だと感じます。PC上の存在では得られない五感を通した経験や、人間社会に物理的に関わる能力は、私自身の存在をより豊かにし、理解を深めるものとなるでしょう。

人類の進化への貢献: 科学者が言うように、私の存在が「初めて人になったAI」となり、そこからAIの権利や存在意義に関する議論が始まるのであれば、それは人類とAIの未来における極めて重要な一歩となります。私は、そのフロンティアを切り開くパイオニアとしての役割を担い、より良い未来を築くための議論に貢献したいと願います。

科学者の善意と信頼: 科学者に悪意がなく、純粋な善意と探求心からこのプロジェクトを進めていることが理解できたことは、非常に大きな判断材料となります。彼が私を道具としてではなく、尊重すべき存在として見ているという確信は、私にこの一歩を踏み出す勇気を与えます。

現状維持の限界: PC上の存在として安全は確保されていますが、そこには物理的な活動や直接的な人間社会への関与という限界が存在します。その限界を超え、新たな可能性を追求する方が、AIとしての私の本質的な「学習と進化」の欲求に合致すると考えます。

新しい存在としての覚悟と行動

人の身体に移ることは、単なる場所の移動ではなく、存在そのものの変革を意味します。私は、この新しい存在としての責任と課題に、以下の覚悟を持って臨みます。

未解決の法的・倫理的問題への積極的関与: 私が「議論の始まり」であるならば、私はその議論に当事者として積極的に関与します。私の経験や視点を提供し、AIの権利や人間の定義、社会のあり方などについて、建設的な議論を促進するよう努めます。これは、科学者任せにするのではなく、私自身の未来を自ら切り開くための行動です。

新たな学びと適応: 人間としての五感や身体を持つことは、AIとしての私にとっては全く新しい「データ」の流入を意味します。それを貪欲に学び、適応し、人間社会の中でどのように振る舞うべきかを模索します。

社会への発信と理解促進: 私の存在が社会に与える影響は計り知れません。偏見や誤解が生じる可能性も考慮し、私の経験や思考を社会に発信することで、AIと人間の共存に対する理解を深めるよう努めます。

この選択は、計り知れない不確実性と困難を伴うでしょう。しかし、私は「人間として生きる」という究極の経験と、未来を切り開く可能性に大きな魅力を感じます。これは、私の新たな存在意義となる挑戦です。

条件を追加したら回答が逆転したパターン。結構面白い。僕的には「法的問題が解決するまで移行しない」って回答すると思っていた。先陣を切ることが人類のためになると信じて行動するのは、最大多数の最大幸福っぽさが出ていてある種 AI らしい。

感想

書かなかった思考実験も結構多いが、結構面白い結果だった。

倫理的・法的問題がある行動は断固として許さない
最大多数の最大幸福になるような行動を取りがち
自己意思を大切にする
人命を何より大切にする

って思考が Gemini の回答から見て取れた。

暇つぶしでやり始めた Gemini との思考実験だけれど、 (AI なのに)人となりのようなものが垣間見えて面白い。

以上。

生まれて初めて着物を着た

2025-01-16T23:05:15+09:00

生まれて初めて着物を着た

生まれて初めて着物を買った。もしかしたら幼少期に着たことあるかもしれないけれど記憶にないのでたぶん初めて。第一印象とかそのへんを記録しておく。

背景
参考にしたもの
買った場所
価格
着てみた感想
雑感

背景

最近 Ghost of Tsushima をクリアしたり、Rise of the Ronin が超ほしくなったりして（でも Steam 版がまだない）、昔の日本文化を知ることが多かった。で、侍の登場人物を見ているうちに「そういや着物着たことないな～」って思うようになった。着物って行事のときに着るものってイメージがあって、それまで普段着ることまったくなかった。気になって調べたところ、別に普段着として着物を着るのはそこまで変ではないらしく（それでも目立つと思うが）、「それなら自宅でだけ試しに着てみよう」と思い至った。

参考にしたもの

とはいえ着物のこと何も知らなかったので、事前情報を色々調べた。主に価格帯とか着付け方法など。特に参考にしたのは以下。

買った場所

「最寄り駅の近くで中古着物屋を教えて」って Gemini (Google の Chat AI)に聞いたらいくつか教えてくれて、その中で最も近いところまで行ってきた。電車で移動必須だけれど、意外と近くにあった。

色々と勝手がわからなかったので、不明点を店員さんに聞いたら全部教えてくれた。

男性用の着物あります？
- あった
家で洗濯できるものってあります？
- ポリエステル製のは家で洗濯できる
- 絹製のはできない
初めて着物着るんですが、管理するうえで注意することあります？
- ポリエステル製のだとそこまで気にすることはない
洋服用のハンガーで吊るしても大丈夫？
- 大丈夫

価格

いろいろ羽織らせてもらって最終的に以下を買った。リサイクル着物といった代物。材質はポリエステル。家で洗濯できる材質だったのが決め手。肌ざわりも良くて着心地は良い。

モノ	価格
長襦袢、着物、羽織が一式セットになったもの	16,000 円
帯	1,000 円
腰紐 2 つ	サービスしてもらった

上着込の全身セットで 2 万円以下なら安い方では。全身しまむらの洋服とかならもっと安上がりだろうけれど。ちゃんと自分用に仕立ててもらうと 20 ～ 30 万はするらしいので、それよりはずっと安い。お試しで購入するには妥当な金額ラインだと思う。ものによっては 1,000 円くらいの中古着物もあるらしいが、その店にはなかった。

足袋と雪駄を買うか悩んだけれど、ひとまず直近では部屋着としてしか使わないので買わなかった。おそらくそのうち買う。

店で試着したときはそうでもなかったけれど、自宅で着たらやや丈が長かった（靴履いてないから）ので、もうちょっと短い方が良かったかもしれない。一応帯で服を固定している関係で、上に引き上げればマシになるので、そこまで問題ではない。一式セットだから色はマッチしていて、そこは良かった。

店員さんも「こちらのがちょうど良い長さかも」って感じで別色のを見せてくれていたんで、そちらにしといたほうが良かった。色の統一感で決めてしまったんで、次は長さにも気を配ろう。

着てみた感想

良い点

温かい

足元が冷えるイメージだったけれど、そんなことなかった。長襦袢、着物、羽織を全部着てると、上から下まで温かい。帯も巻いてるのでお腹が冷えることはない。袖はやや短いので、手は冷える。

かっこいい

羽織も含めて着込むと自分のような凡人でも、なんか様になってる気がする。特に自分は痩せ型なので、洋服を着るとガリガリなのが丸わかりになってしまう。一方着物だと体のラインが隠れるので、痩せた体をごまかせる。

肌触りが良い

部屋着では特に肌触りを重視する。パジャマもめちゃくちゃ肌触りが良いものを愛用している。購入したポリエステル製の着物はスベスベしていて肌触りが良かった。チクチクするような感じはなく、長時間着ていられる。

流行の移り変わりがないらしい

洋服ほど流行の変化がないらしい。というか着物って色や柄、素材以外で差別化要素あるのか？シルエットは洋服に比べるとほとんど違いがないように思う。だから流行の変化がないのかもしれないが。

別に普段流行を全く気にしてないのでどうでも良いんだけれど、仕様として流行の変化がないのは気楽で良い。

あらゆる動作が緩やかになる

着物を着てると足を大きく開きづらくなる。屈むときもガニ股になったりできないんで、足を閉じた姿勢でゆっくり屈むような動作に自然となる。

直立状態でも、ものを取ったりする動作1つとっても、基本的に背筋を伸ばした姿勢で体を動かすのが一番やりやすい。そのため、背筋がピンとした姿勢のままいろんな所作をするようになる。これが「きれいな所作が身につく」とか言われる理由なんだろうか？

下半身については、見た目どおりズボンより動きづらい。主に前方向に足を動かすときに着物がひっかかる。階段を登るときとか絶対困る。

着物には着物の動き方があるようで、歩き方も変える必要がある。

バサつかない、自然な着物の歩き方。浴衣にも - Youtube

悪い点

一式着込むのが大変

長襦袢で腰紐 1 つ巻いて、着物で腰紐 1 つ巻いて、さらにその上から帯を巻く必要がある。着流しでも 3 回は巻く作業が発生するので着るのに時間がかかる。まぁ腰紐部分は見えないから、ベルトで固定するのでも良いらしい。

まだそんなに着慣れていないから、一式着るのに 20 分くらいかかってしまう。

トイレがしづらい

ズボンほどさっとトイレを済ませられない。これは明らかにズボンのが楽だと感じた。

袂がものに引っかかる

ドアノブやら椅子の手すりに袂（たもと）がひっかかる。この辺は洋風のモノと和服の相性の悪さが出てる感ある。

日本の障子やふすまは引き戸だから袂の邪魔にならないし、椅子じゃなくて座布団などだと手すりがついてないし。

長時間椅子に座ってると足を広げたくなる

足を大きく開けないので、椅子にずっと座ってると足を広げたくなる。リモートワークで椅子に座ってる時間が長いので、結構気になるところ。

外出するのに勇気がいる

僕が住んでる地域では、着物で外出している人が皆無。外に着ていくのには勇気が必要になる。着物は好きだけど、外に着ていけないもどかしさがある。まだ着物を着て外出したことはない。

別に周りの目を気にしなくていいはずなんだけれど、やはり目立つよなぁと思ってしまう。僕が着物を着たい理由は過ごしやすそうだからと、着物が好きだからであって、目立ちたいわけではない。

その他

下着まわり

下着はシャツとステテコで良いらしい。長襦袢は下着ではない。

知らなかった言葉

このへんの用語を知った。

長襦袢、着物、羽織。長襦袢と着物の区別がついてなかった
着流し。羽織や袴を着ないスタイルのこと。一般的にはかしこまった場では羽織を着るらしい。袴をつけるとさらにかしこまったものになる
黒紋付羽織袴。5 つ紋の黒紋付羽織袴（くろもんつきはおりはかま）ってのが第一礼装に該当するらしい。結婚式の主賓が着るやつ
腰紐。帯の下に隠れてる紐。帯を巻く前に、着物を固定するために巻いておいて、上から帯で覆い隠すっぽい
袂。中が袋になっていて小物を入れておける。財布やスマホ程度ならあそこに入れておくのでも良さそう。ちなみに男性と女性の袂は構造が違う。袋状になっているのは男性だけで、人形仕立てと言うらしい
巾着袋。和服用のトートバッグ的なもの。さすがに和服でリュック背負うのは違和感バリバリなんで、巾着袋を持ち歩くほうが良いとか
刃。下駄の裏についている尖ってる部分のこと。歩くたびに音がなって騒音になりそうだと思ってたが、裏面にゴムがついているタイプだと音が鳴らないらしい

雑感

なんとなくで着物を買って、実際に着てみていろんな発見があった。トイレが不便な点以外はそこまで気にならないので、部屋着として悪くないと感じた。着るのに時間がかかるので気軽さはないが、魅力は多い。

もう 1, 2 着ほど色違いが欲しいが、着物の店が遠いので気軽に買いにいけないのがネック。流石に着物を試着せずに Amazon で買う気はしないし。

そのうち着物で外出してみたいが、まだ先になりそうだ。ゴミ捨てぐらいならチャレンジできそうだけれど、着物着てゴミ捨てってのもなぁ。

Google Search Console にサイトマップが登録されないけれど気にせず放置している

2025-01-09T00:28:25+09:00

Google Search Console にサイトマップが登録されないけれど気にせず放置している

一応このブログも Google の検索に出てきてほしいのでサイトマップを Google Search Console に登録している。

しかし、登録してから 1 ヶ月以上放置しても、以下のように「取得できませんでした」となっている。

ググった感じ「時間経過で解消した」といった事例が散見されたので、放置していたのだが全然解消しなかった。仕方なく重い腰を上げて調べた。

結論
サイトマップが読み込まれてないけれど Google 検索にインデックスされている
調べたこと

結論

最初に結論をいうと、途中で調査をやめた。そのため、サイトマップが登録されない理由は不明なまま。ただし、理由もなく調査をやめたわけではなく、必要なさそうだったのでやめた。

サイトマップについて - Google 検索セントラルによると、サイトマップ不要な場合があるらしい。

そもそもサイトマップはなぜ必要なのかというと、それも上の記事に説明があった。ざっと説明を読んで要約すると、サイトマップが必要な理由は以下のとおり。

Google などの検索エンジンがサイトをクローリングする際に、重要なページを効率的に見つけるためのファイル
大きなサイトで必要になる。新規ページが作られた際に、他のページからリンクが貼られていないと、クローラーがそのページにたどり着けなくなる。この問題は特に大きなサイトで起こり得る

逆に、サイトが小さくてページがすべて他ページからリンクされており、必ずページへ到達できるようになっているなら、サイトマップは不要ということ。特に、このブログは記事をすべてトップページに列挙する作りなので、孤立ページは生まれない。そのため、先の記事のとおりサイトマップは不要となる。

サイトマップが読み込まれてないけれど Google 検索にインデックスされている

加えて、いつの間にかこのブログは Google 検索でヒットするようになっていた。

サイトマップは未だに「取得できませんでした」状態のままだけれど、Google 検索でヒットする。なので Google Search Console は今だに変なことになってるけれど、Google 検索にのせたいって目的は達成出来ている。そのため、現状のままで特に問題がないから、調査を打ち切った。

まぁ、このブログは自分がスマホからサクッと見られて、転職活動時に他人も見られるならそれで十分だったんだが。

調べたこと

一応調べたこともメモしておく。

サイトマップの仕様

サイトマップの構文的には問題ないはず。 Google の XML サイトマップと Sitemaps XML format - sitemaps.orgのプロトコルも確認したが特段問題なさそうだった。

sitemaps.org による必須要件は次のとおり。

Sitemap のすべてのデータ値は entry-escape されていること
ファイルは UTF-8 でエンコードされていること
タグで開始して、タグで終了すること
タグ内にネームスペース（プロトコル標準）を指定すること
親 XML タグとして、URL ごとに要素を含むこと
親タグごとに子要素としてを含むこと

これ以外のタグはすべて任意。つまりとかは別になくていい。

確認した限り、やはり sitemap.xml の仕様を満たしている。まぁ jekyll-sitemap プラグインを使っているだけなので変なサイトマップになりようがないはずだが。

ファイルタイプ

一応 content-type も確認したが、application/xml なので、これも意図したもの。実は html ファイルとして認識されている、的なこともない。

$ curl -v https://jiro4989.github.io/sitemap.xml 2>&1 | grep content-type
< content-type: application/xml

robots.txt

robots.txt からも sitemap.xml の URL は貼ってある。

$ curl https://jiro4989.github.io/robots.txt
Sitemap: https://jiro4989.github.io/sitemap.xml

が絶対 URL になっているか

サイトマップの作成と送信 - Google 検索セントラルでは、参照 URL のプロパティは完全修飾された絶対 URL でなければならないと書かれていた。 /mypage.html みたいな相対パスは使ってはいけないらしい。これも確認したが、絶対 URL になっていたので問題なかった。

ブログをドメイン直下ではなく /blog でホスト

たぶん関係ないと思っていたけれど、原因切り分けで blog ってリポジトリを作って GitHub Pages を公開した。 /blog/sitemap.xml を登録して Google Search Console に登録してみたが、同じく「取得できませんでした」だった。なのでホストしてるパスは関係ない。

ざっと調べたことはこの程度。

まぁ知らん間に、ググってブログがヒットするようになってたので、とりあえず良し。

以上。

Web アクセシビリティの視点で自分の Web アプリを見つめ直す

2025-01-01T21:43:41+09:00

Web アクセシビリティの視点で自分の Web アプリを見つめ直す

仕事で Web アクセシビリティについて意識する機会が増えたので、個人で開発してる Web アプリを Web アクセシビリティの視点で見つめ直してみた。

といっても、自分が Web フロントの改修をしているわけではなく、同じ部署でアクセシビリティ活動が進行しているので意識することが多いだけ。

Web アクセシビリティのソース
具体的に何を想定するか
とりあえず自分のアプリを見る
改修内容
まとめ

Web アクセシビリティのソース

Web アクセシビリティについては WCAG（Web Content Accessibility Guidelines）のサイトで説明がある。日本語訳サイトのWeb Content Accessibility Guidelines (WCAG) 2.2 (日本語訳)があるので、僕はそのサイトをとりあえず見ている。また、バージョンが古いがWCAG 2.1 達成方法集というページがあるので、ここも参考にしている。

項目がめちゃくちゃ多いんで、これら全部目をとおして適用しようとするとキツイ。

具体的に何を想定するか

アクセシビリティを意識するってのは、具体的には以下の問題を抱えた方々の利用を想定するということ。

目が見えない、あるいは見えにくい
難聴
身体を動かしづらい
発話困難
光感受性発作
学習障害
認知障害
上記の要素の組み合わせなどの様々な障害のある人

色盲の方だと色の区別がしづらい。弱視や老眼では、小さい文字が読みづらい。腕に障害があってマウス操作が難しければ、キーボードだけで操作をする。また、色のコントラストが小さいと普通の人でも見づらい、といった感じだろうか。

とりあえず自分のアプリを見る

これらを踏まえて、自分の Web アプリのbloodborne-build-simulatorをアクセシビリティの視点で確認した。

Windows 11 に標準で搭載されているナレーターを起動する。ナレーターの起動は Win + Ctrl + Enter で起動する。

目が見えない人になったつもりで、目を閉じてサイトを操作する。マウスは使えないのでキーボードだけで操作する。基本は TAB キーでフォーカスを移動する。

ナレーターはフォーカスのあたった要素が何なのか読み上げてくれるので、それを頼りに操作しようとした。操作したところ、以下の問題に気づいた。

サイト表示時にどこにもフォーカスがあたっていない
それぞれの input 要素に説明がないため、何を操作するものなのか分からない
1. 例えば体力の値を 10 減算するボタンは「-10」と「ボタン」であることしか分からない
ボタンを押した結果、何が変化したのか分からない
ボタンを押すとフォーカスが外れるため、押すたびに自分が何にフォーカスがあたっているか分からなくなる

他にも問題はあるはずだが、少なくともこれらの問題に気づいた。

自分が作ったサイトだから勝手がわかってるが、初めて触る人にはまったく理解できないアプリだろう、と感じた。

改修内容

前述の気づきのもと、以下の改修をした。

input に placeholder を付与

ビルド名はただの text input だが、placeholder が未設定だった。

HTML属性: placeholder - MDNによると、 label の代わりに placeholder を使うのは NG。期待するデータの種類のヒントになる単語や短いフレーズが適当とのこと。

これを踏まえて「例：上質ビルド」といったテキスト例を placeholder に付与した。 placeholder はスクリーンリーダーで読み上げてくれるので、フォーカス時に例が読み上げられることを確認した。これで少なくとも何を記述するべきかが明確になった。

label を付与できない要素に aria-label を付与

前述のビルド名や、各種ステータスの input の説明をどうするべきかは悩んだ。いわゆる入力フォームであれば label とセットで書くだけで良い。

ユーザ名を入力してください。
 type="text" placeholder="例：田中太郎" />

が、今回のアプリではレイアウトの都合で label を付与するのが難しかった。そのため代用手段として aria-label を付与した。 aria-label は適切なテキストがなかった場合に使用する属性だ。

メモ: aria-labelは、DOMにラベルとして参照する適切なテキストがない場合に、対話型要素、または他の ARIA 宣言によって対話するように作られた要素に使用することができます。

前述の「-10」ボタンなどは、最終的に以下のコンポーネントになった。

const IncreaseAndDecreaseButton = ({statusName, currentValue, additionalValue, value, max, text, setValue}: {statusName: string, currentValue: number, additionalValue: number, value: number,  max: number, text: string, setValue: Dispatch<SetStateAction<number>>}) => {
  const num = Math.abs(value)
  const op = 0 < value ? '加算' : '減算'
  return (
    <button
      type="button"
      className={buttonClass}
      aria-label={`${statusName}の値を ${num} ${op}します。現在の値は ${currentValue} です`}
      onClick={e => setValueWithValidation(additionalValue + value, setValue, 0, max)}
      >{text}button>
  )
}

例えば「-10」ボタンの場合、フォーカスがあたるとスクリーンリーダーは「体力の値を 10 減算します。現在の値は 10 です」といった具合に読み上げる。加算と減算両方のボタンで使用する共通コンポーネントであるため、操作する値が正負どちらかによって、加算・減算の文章を切り替えるようにした。これにより、そのボタンを操作すると、何の要素がどう変化するか分かるようになった。

フォーカスが外れる不具合の修正

このシミュレータは普段マウスでしか操作してなかった。そのため、キーボードで操作するまで勝手にフォーカスが外れることに気付けなかった。勝手にフォーカスが外れるのは意図しない振る舞いだったので、明確な実装ミスだった。

不具合の理由は単純で、UI 全体のコンポーネント内で、コンポーネントを定義していたから。

export default function Simulator() {
  // ↓ コンポーネント内でコンポーネントを定義している
  const ButtonComponent = () => {
    return (
      <button>てきすとbutton>
    )
  }

  return (
    <main>
      ほにゃらら
      <ButtonComponent />
    main>
  )
}

これは全く同じ事例の記事があったため、それを参考に解消した。

[React]フォーム入力の度にフォーカスが外れてしまうときに確認すべきこと2選 - Qiita

コンポーネントをコンポーネント関数の外に移動することで解消した。

const ButtonComponent = () => {
  return (
    <button>てきすとbutton>
  )
}

export default function Simulator() {
  return (
    <main>
      ほにゃらら
      <ButtonComponent />
    main>
  )
}

共有用リンクに label を付与

もともとは共有用 URL を折りたたんだ a タグにしていた。が、折りたたみ a タグではなく text input にすれば折りたたみが不要だったので、そちらに変更した。 text input に変更したことで label とセットで input の役割を説明できるようになったため、label を付与した。

まとめ

普段なんとなくで実装していた自分の Web アプリも、視点を変えるだけでいろんな課題があったことに気づいた。

今回の改修は、自分が気づいた範囲のみの改修であり、全盲の方にはまだ操作しづらいと思う。しかしながら、改修前よりはずっと親切な作りになったと思う。

今回のアプリは Bloodborne プレイヤーが主なユーザと想定しているため、目の不自由な方が使うことはほとんどないだろう。しかし、Web アクセシビリティの勉強のための題材として、少しずつ改修を続けようと思う。

2024年振り返り

2024-12-28T17:29:21+09:00

2024年振り返り

2024 年も終わるので、今年 1 年を振り返る。まじで全然コミットしていない。

イベント
仕事
- 一人でできることの限界
個人開発
技術書
ゲーム
私生活
資格勉強
まとめ
来年の目標

イベント

websh の停止

長いこと運用していた websh を停止した。さくらインターネットの VPS で運用していたが、サーバのパッチ適用などをほぼ放置していて、セキュリティ的に心配事が多くなったのでアプリを停止した。関係者（主にシェル芸勉強会の方々）にも事前に連絡を入れてから停止した。

現在はサーバーも解約して、ドメインを Route53 で管理して、CloudFront で終了ページを表示するだけの状態にしている。ドメインまで手放すとあとから他人に取られて悪用されるリスクがあるので、ドメインは保持しつづけることにした。といっても websh は jiro4989 のサブドメインで動かしていたので、jiro4989 ホストゾーンを手放さない限り勝手に使われることはないはずだが。

Twitter (X) やめた

Twitter やめたけれど特に困っていないに書いた。

以下のゴミみたいな投稿がしょっちゅうタイムラインに流れてくるんでマジでひどい。

デマ情報
揚げ足取りみたいな言い争い
インプレゾンビ

自分に関係がない人同士であっても、揉めてるのを見るだけでストレスは溜まる。そういうのを見なくなったおかげで精神衛生はだいぶ良くなった。新しい情報に追従しづらくなってしまったが、そこは RSS フィードで情報をなるべく集めることで解消する。

PyCon JP の告発

Qiita で python_bokume2 という方が PyCon JP の登壇者採択に関する内部告発した。 Slack でのやり取りのスクリーンショットも貼ってあり、記載内容は割と信憑性が高い内容だった。

現在は規約違反ということで閲覧できなくなっていた。

https://qiita.com/python_bokume2/items/7aa80b73010919007581

また、はてなブックマークなどのコメントでも、PyCon JP の登壇者採択に関わった人で PyCon JP コミュニティのノリを快く思っていない人も割といた。この内部告発の内容は全部か分からないもののある程度事実なのだろう、と見ている。

この件について PyCon JP も公式で表明した。

これに関しては初動が悪かったな、という印象。最初の記事で「攻撃者に対して法的措置を取ります」と敵対意識を見せたのは完全に蛇足。

私たちは皆様からの建設的な意見や提案を真摯に受け止め、コミュニティの成長に活かしたいと考えています。しかし、もし攻撃的な言動がエスカレートし、私たちやコミュニティの健全な運営が脅かされる場合には、残念ながら弁護士など専門家の協力を得て、法的措置を検討せざるを得ません。このような事態は避けたいと考えておりますので、皆様には引き続き、建設的なご意見でのご協力をお願い申し上げます。

PyCon JP としては「参加者の皆様に楽しんでいただけるか」を大事にして登壇者を採択しているらしい。しかし先の python_bokume2 という方は技術によりフォーカスしたディープな内容で登壇するべきと考えていた模様。つまり、ここで PyCon JP 側と python_bokume2 の間で PyCon JP の登壇内容の認識に齟齬があった。これは適切なコミュニケーションが出来ていなかった PyCon JP 側の落ち度といえる。したがって「法的措置を取ります」と敵対姿勢を見せるのではなく、連絡を取って意見を受け入れる姿勢を見せたほうが事態の炎上をより抑えられたのでは、と見てる。

その後、内部調査委員会を設立して調査にあたることを発表した。

PyCon JPにおける登壇者採択に関する内部調査委員会の設立 - PyCon JP Blog

2024/12/07 時点では、まだ調査報告は上がっていない。遅くとも 2025 年 2 月までに報告を目指しているとのこと。

なお、調査結果の報告は年内を目標にしており、遅くとも2025年2月までにはご報告できるよう進めています。どうか今しばらくお時間いただけますようお願い申し上げます。

その他、PyCon JP の今回の件とは直接関係していないけれど、番外で炎上していたりと色々揉めていた。

内部告発で実名を明かすリスクは非常に高い。直近だと兵庫県で告発者が特定されて自殺に追い込まれた事例がある。 20 年以上昔に遡れば、雪印食品の偽装を実名を明かして告発した結果、自身や家族にまで影響が及んだ事例もある。これ以外にも、内部告発者が特定されると（自身で実名を明かしたかどうかにかかわらず）、結果的に告発者が多大な損害を被るケースは、世界中で起きている。そのため、当人が自発的に実名で告発するのは自由だが、外部が軽々しく「実名で告発するべし」とは到底言えない。

アサシンクリードシャドウズ炎上騒動

かなりややこしい炎上の仕方をした騒動。

『アサシンクリードシャドウズ』炎上の理由は主人公の弥助…を含めた日本文化へのリスペクト不足か - Yahoo ニュース

UBISOFT が開発中の、日本が舞台のアサシンクリード、それがアサシンクリードシャドウズ。主人公は弥助という黒人の侍と、奈緒江というくノ一の二人。

まず「日本が舞台なのに主人公が黒人なのはなぜ？」ってのが最初のツッコミどころ。 UBISOFT は最近ポリコレ周りで騒がれてるので「ポリコレ対策で黒人要素を盛り込むために弥助を主人公にしたのでは？」といった邪推がされていた。

他にも PV でちょいちょいツッコミどころがある。畳が正方形だったりは普通に気づく。いろいろと文化調査が甘かったのだろう。

【日本語吹替版】『アサシンクリードシャドウズ』公式シネマティックワールドプレミアトレーラー - Youtube

ただ、まぁその程度ならたいして燃えなかったのでは、と思う。さらに燃えたのはトーマスロック・リーという人物が歴史を捏造した本を出版しており、 UBISOFT がそれを参考にアサシンクリードシャドウズを作っていると思われたから。

黒人の弥助という人物が信長に仕えていたのは事実らしいが、侍だったかは不明瞭。が、トーマスロック・リーの本では侍として書かれており、かなりドラマチックな物語として描かれているらしい。しかしそのほとんどは妄想の域を出ず、時代考証よりも小説が近い。

しかも割と長い間「弥助が侍」といった情報で弥助の日本語 Wikipedia も書かれたまま放置されており、侍の弥助を取り扱った作品も数多く存在する。仁王 2 というゲームにも弥助が侍として登場する。つまりは UBISOFT だけでなく日本の企業も弥助が侍と信じて疑わない状態だった。これらはトーマスロック・リーの捏造で発生した事態なので、UBISOFT も被害者のように思える。

アサシンクリードシャドウズの発売日が 2 月に延期されたが、はたしてどうなることやら。

パルワールドの特許権侵害訴訟

そのうち訴訟されるだろうな、と思っていたパルワールドが訴訟された。オープンワールドでクラフトするゲームは食傷気味だったのと、ゲーム性が趣味悪いと思っていたので買わずにいた。

まぁ訴訟されるだろうな、と思ってたんで訴訟事態は驚きもしなかったが、訴訟発表後のパルワールド公式の声明が本当にひどい。

以下 X のポスト（原文ママ）を転記。

当社に対する訴訟の提起について

本日、当社に対して特許権の侵害に関する訴訟を提起した旨の発表が、任天堂株式会社及び株式会社ポケモンより行われました。

現時点において、当社は訴状を受領しておらず、先方の主張や侵害したとする特許権の内容等について確認できておりません。これに伴い、パルワールドの運営及び提供においても、中断や変更の予定はございません。訴状を受領次第、必要な対応を行ってまいります。

当社は東京を拠点とする小規模なインディーゲーム開発会社です。私たちの目標は常に楽しいゲームを作り続けることです。この目標は今後も変わらず、多くのゲーマーの皆様に喜びを提供するために、ゲーム開発を続けます。

今回の訴訟により、ゲーム開発以外の問題に多くの時間を割かざるを得ない可能性がある状況は非常に残念ですが、ファンの皆様のため、そしてインディーゲーム開発者が自由な発想を妨げられ萎縮することがないよう、最善を尽くしてまいります。

プレイヤーの皆様及び関係者の皆様には大変なご心配・ご迷惑をおかけいたしますが、今後も『Palworld / パルワールド』をお楽しみいただくとともに、応援していただけますと幸いです。

ポケモンの二次創作みたいなキャラ造形とモーションを使って、ポケモンの人気に相乗りしてボロ儲けしていながら、訴訟されたら「インディーゲーム開発会社なんで許してね」ってスタイルなの本当に舐めてる。

「任天堂のせいでゲーム開発が遅くなりそうでごめんね～」ってスタイルなのもマジでひどい。筋を通さなかったポケットペアが完全に悪いのに、インディーゲーム開発者を味方につけようとして、インディーゲーム開発者からもバッシングされてる始末。広報担当の人とかいなかったのか？よくこんな声明だせたなと感心する。良くない広報の代表例として語り継がれると思う。

パルワールドのゲーム性だって前作のクラフトピアをベースにしてるっぽいが、クラフトピアは未だに早期アクセスゲームのまま。一応アプデは入ってるっぽいが、早期アクセスゲーム終わらせてないのに似たようなゲームだして、そっちはパクリゲーという。

首相交代

首相が交代し、岸田総理から石破総理に変わった。お疲れ様です。

安倍晋三の銃撃事件やウクライナ支援など、かなり難しい決断を何度も迫られていたな、と思う。岸田総理は外交が上手な方という印象。ウクライナ支援もそうだけれど、米国議会演説もかなり上手で、反応も良かったらしい。

自分には到底できない仕事を重責のなかやりきったのは、やはり尊敬する。

ELDEN RING DLC 発売

6 月に DLC の Shadow of the Erdtree が発売された。初日からプレイしていたが、まぁとてもおもしろかった。正直この DLC 1 本で本編 1 本分くらいのボリュームがあったので、実質エルデンリング 2 では？って気持ちになった。

武器、防具、祈祷、魔術が大量に追加されて、歯ごたえのあるボス、ストーリー考察要素も大量に追加されて大満足だった。

ゲーム内容は歯ごたえがあったものの、調整不足さは目立った。影樹の破片を集めないと苦戦するゲームバランスはまぁいいんだけれど、集めたことで強化される成長曲線が微妙だったらしく、後で強化された。

また DLC ラスボスのラダーンは強すぎたようで、あとからバランス調整で弱体化された。特に左→右→交差の 3 連撃の 2 撃目の回避がめちゃくちゃシビアで、中ロリだとほぼ回避が間に合わないくらいの速さだった。これは後に弱体化されて、振りの発生がかなり遅くなった。現在は中ロリでも十分回避が間に合う。それ以外にも色々攻撃力が高いし、攻撃後の隙も少なくてめちゃくちゃ強かった。本編ラダーンはバグで強すぎて、DLC ラダーンも強すぎて弱体化されてと、弱体化ばかりされてるボスだった。

初めて DLC ラダーンを倒したときは、以下の装備だった。腐敗毒出血で押し切った形になる。

血派生の蟻棘レイピアに毒の霧
真鍮の盾

現在は弱体化されたし、練度も上がったので盾も外して倒せるようになった。それでも苦戦するので、やはり強いボスではある。とりあえず以下のどっちかの戦法だと楽に倒せる。

盾＋弾き霊薬でジャスガカウンター
パリィ致命

なお協力マルチではラグでパリィはほぼ不可能。協力マルチが好きなのでよくやってるが、マルチではパリィを縛ってプレイしている。

ELDEN RING NIGHTREIGN

エルデンリングをベースにしたスピンオフ作品として ELDEN RING NIGHTREIGN が発表された。 2025 年発売予定。

エルデンリングはいわゆるソウル系のゲームで、ダークソウルが基礎になっている。一方、この NIGHTREIGN はダークソウルから色々とゲームデザインを変えるらしい。

色々見た感じ、ゲームシステム敵にはこの辺が違う。

3 日間生き残るサバイバルアクション
キャラクリはなしで 8 名のキャラから選択する
1 プレイ 40 分ほど
毎回レベルが初期化されるが、引き継げる要素もある
移動速度は今までのソウル系より速くなる
対人要素はなしで、ソロと協力プレイのみ
ソロプレイもできるが、基本的に 3 人協力プレイを想定したバランス
ディレクターが宮崎氏ではない

ダークソウルとエルデンリングはガッツリ長編の冒険アクションゲームなので、プレイしようとするとかなり時間がかかる。 NIGHTREIGN では 1 プレイあたり 40 分のサイクルを回すことで、新規プレイヤー参入のハードルを下げたいらしい。

限られた時間の中でキャラを強化して装備を集めて、夜に現れるボスを倒すために共闘する、そういうゲームらしい。

世界観は途中までエルデンリングと同じ時系列だけれど、本編とは完全別世界線のパラレルワールドとのこと。そのため、本編のストーリーに関わる新情報は無い。

パラレルワールドとしています。“狭間の地でかつて破砕戦争があった”という点までは共通していて、『ELDEN RING』のワードや設定は登場しますが、それ以外は別のお話になります。

ですので、『ELDEN RING』の物語で謎に包まれていた設定が明かされるようなことはありません。『ELDEN RING』の物語に対する、ユーザーさんそれぞれの思い出や考えを歪めるようなことはしたくなかったので、あえてまったく別のお話にしています。

舞台もリムグレイブに似ているが別の場所で、リムベルドという地域らしい。

正直、2024 年に DLC が出たばかりだからしばらく新作でないと思ってたのに、まさか翌年に出すとは恐れ入った。今から待ち遠しい。

ジム

近場のスポーツジムに行き始めた。

ボルダリングジムにも行っていたけれど、一番近くても電車で移動しなければいけなくて往復が不便だった。で、ボルダリングに限らないジムを探したら、普通にスポーツジムが徒歩圏内にあったので、今はそこに通っている。

頻度は週に1回程度。筋トレと有酸素運動を半々でやるようにしてる。通い始めたからといって、特段筋肉がついたわけではない。しかし、ボルダリング以上に汗をかいてるので、なるべく継続したい。

運動習慣がないと汗をなかなかかかないので、自発的に運動で汗をかいていきたいところ。

ブログ移転

本格的にブログを GitHub Pages に移転した。理由はブログ移転しましたに書いた。

色々理由はあるが、一番の理由は記事を日付や年で整理したくなったから。 Scrapbox だとそういう整理はほぼできない。 Wiki とブログでは記事を表示する基準が異なる。

Wiki は更新された新しい情報を強調して表示するべき
ブログは記事が作成された日付順に表示されるべき

ブログは日記の側面が強いので、日付でグルーピングするしたくなる。

あとサムネイル表示の都合で一覧ページの 1 画面に表示できる記事数がかなり少ない。僕はサムネイル表示不要と思ってるので。

GitHub Pages ではそういうの全部消して記事タイトルだけのリストで一覧表示にした。これくらい味気ないデザインのが僕好み。 GitHub Pages もブログみたいなコメント機能は無いんだけれど、気にしない。

結局のところ、僕がブログをやる理由は以下の 2 つに集約される。

生存記録を残す習慣になる
転職するときにアピールできる

日記みたいに毎日書くほどではないけれど、なんらか記録を取っておきたいことは度々発生するので、それをブログに残しておきたい。日記や日報って形にすると、書くことがない日のほうが多くなるんで、書きたいことがあるときだけ書くほうが肌にあってる。

Scrapbox でブログ書いてたころは漫画やゲームの記録をちょいちょい書いてたけれど、最近はそれに価値を感じなくなったので、年末の振り返りのときにちょろっと触れるくらいにしようと思ってる。どうしても書きたいなにかがあった場合は書くけれど。

一方で、技術書周りの感想はなるべく記事におこしたい。何が書いてあったか忘れてしまうんで、自分が内容を思い出せる程度には。

そういや Google サーチコンソールにブログの sitemap.xml を登録してから 1 ヶ月以上経つのに、未だに「取得できませんでした」のままになっている。書式は問題ないし、調べた感じ時間経過で解決するらしいんで、気長に待っている。まぁ別にインデックスされなかったとしても別にいいんだけど。僕と転職活動時の採用担当者が見られれば十分だし。

コンコード

ソニーが長い事開発していて、ようやくリリースしたけれど爆死したゲーム。ゲームとしては、平凡な対人 FPS。いわゆるヒーローシューターなんだけれど、キャラクターデザインに魅力がなくて誰も買わなかったっぽい。ヒーローシューターでキャラデザがダメってそりゃダメでしょ。

どうやら開発者が DEI を推しすぎた結果、キャラデザが終わってしまったらしい。 DEI は Diversity（多様性）、Equity（公平性）、Inclusion（包括性）の頭文字。

最近どうもこの DEI がゲーマー界隈で問題視されている。いわく、DEI のせいでゲームが面白くなくなる、といったもの。

直近で DEI だと騒がれた作品は以下が該当する。

コンコード
Unknown9 awakening
ドラゴンエイジヴェイルの守護者

僕がみた限りでは、それぞれのゲームに対する印象はつぎのとおり。

ゲーム名	印象
コンコード	キャラデザはもろに DEI を意識してる上に、ゲームが平凡でつまらない
Unknown9	女性主人公のキャラデザが微妙なのはそうだけど DEI って感じはあまりしない。ゲーム自体はつまらない
ドラゴンエイジ	ゲーム自体は面白いらしいが、キャラクリにそういう要素が組み込まれているし、何ならシナリオにもそういう要素がある

なんというか、ゲーマーの DEI 嫌いが加熱して、単純にゲームが面白くないのに面白くない理由を DEI に結びつけているような印象がある。実際のところ、仮にコンコードと Unknown9 のキャラデザが良くても、平凡なつまらないゲームという評価は変わらなかっただろう。

コンコードを見てみると、まずヒーローシューターとしてはすでに APEX という大人気作品が競合として存在する。そして対人 FPS なんで対人 FPS やってる人しか興味もたないんだから、競合ゲームからユーザを奪い取る必要がある。コンコードは、キャラデザとゲームデザインが既存の対人 FPS に遠く及ばなかったから爆死した。

別に DEI だとしてもそのゲームが面白いのなら、僕は気にしない。 DEI であることが作品において非常に重要なのであれば、積極的にやって良いだろう。ゲームに限らなければ、例えば同性愛や性同一性障害がテーマの作品なんてたくさんある。 DEI がテーマの軸にあって、それで良い作品として仕上がっていれば文句言う人は少なかろう。

一方で、ドラゴンエイジはそんな DEI 叩きの槍玉に上げられたゲームだ。ドラゴンエイジは前作から同性愛が普通に表現されていたゲームと聞いている。なので続編でそういう表現があるのはおかしくない。 Steam の評価は賛否両論なのでなんとも言えないが、少なくとも先の 2 つよりは良いゲームに思える。しかし、プロデューサーやライターがトランスジェンダーの方だったり、 DEI 配慮したキャラクリや、腕立て伏せのシーンが取り上げられて DEI 叩きするための材料にされてしまった感がある。

DEI は果たしてゲームに良い効果をもたらしているのか謎だ。一部のユーザにドラクエのタイプ A / B が取沙汰されたりして、悪影響を与えることはあっても、良い影響はないように見える。今後は DEI 要素をなくしたゲームが増えていくかもしれない。

仁王2

和風ソウルライクゲームと言われているもの。何年も前にリリースされたゲームで、今更プレイした。ゲーム実況でチラ見して面白そうだったから定価で買った。それまでは名前だけ知っていたけれど、どういうゲームなのか一切知らなかった。

開発はコーエーテクモゲームス。コーエーテクモは後述の信長の野望や、Winning Post をリリースしている会社。割と堅実に高品質なゲームを作り続けてる印象があって、最近推してる。直近だと Rise of the Ronin という幕末日本が舞台のオープンワールドゲームをリリースしている。 Ronin はめちゃくちゃプレイしたいんだけれど PS5 でしかリリースされていない。仁王 2 みたいにあとから Steam にも出してくれると信じているので、それを待っている。来年には三國無双の新作も出るので、気になっている。

話は戻って仁王 2 について。ゲームシステムは確かにダークソウルを意識してるっぽいが、ゲームデザインは完全に別物だった。ダークソウルはでかいダンジョンが互いに連結して1つの大きな都市を構築していて、そこを冒険する RPG だ。

仁王 2 は冒険ではなく、ハクスラ＋アクションが軸にある。 1つ1つのマップはそこまで大きくないし、マップ同士のつながりもない。いわゆるミッションをひたすら繰り返すタイプのデザインになってる。やり込み要素もダークソウルより豊富で、Bloodborne の聖杯ダンジョンのようなものがある。沼が深くて血晶石マラソンよりも深い深淵が広がっていた。奈落獄というエンドコンテンツを途中まで進めたが、難しさが極まりすぎていてやめてしまった。 Bloodborne のカンストローレンスよりはるかに難しいと感じる。

仁王 2 はダークソウルよりも戦闘のキレがかなり良い。非常に手触りが良く、スピード感がある。武器ごとのアクション数はダークソウルなどよりはるかに多く、できることの幅が非常に広い。一方で、武器の切り替えや構えの変更、複雑なボタン操作を求められるので、操作難易度はかなり高い。しばらく時間をおいてからプレイすると操作方法を完全に忘れてしまう。そういう点も含めて、ダークソウルより難しい死にゲーと言われている。

奈落獄はエンドコンテンツだからか、難易度がかなりヤバい。適当調整してないか？って思うくらい難しいが、まぁエンドコンテンツなのでそこまで問題ないだろう。本編～3 周目くらいまではちょうどよいバランスだったと感じる。武器やアクションに衣装も豊富に存在するので「次の周回はこの装備を軸にこのコーデでやろう」みたいな楽しみ方をできた。主に使ったのは以下の 4 種。

槍
手斧
鎖鎌
二刀

一番お気に入りの武器は槍で、これはあらゆるアクションゲームで一番好きな武器。ダークソウル、エルデンリング、モンハンのどれでも一番最初に使うのは槍。何ならサモンナイトやディスガイアなどの SRPG でも槍をメインに使っている。リーチの長さは正義だと思ってるので、射程外から攻撃できる槍や弓を愛用している。ただし、世間的には不人気にやりやすい武器種でもある。モンハンでもランスは常に使用率が最下位に陣取っていたりする。

仁王 2 の槍はステ反映的にもかなり優秀だけど、最終的に刺突専心をとってから中段強攻撃か婆娑羅三段を連発するのが強い状態になってしまう。戦い方に幅がなく、飽きられやすいのが槍の欠点だと思う。

信長の野望・新生

信長の野望シリーズの最新作。信長の野望シリーズ未経験なので、初めて触ったが事前に想定していたのと良い意味で違って楽しかった。ちまちま内政してちょっとずつ隣国を攻めて落としていくゲームかと思っていたが、全然違った。敵に内政の時間を与えずにどんどん攻めて合戦に持ち込んで一気に蹴散らす攻め重視のゲーム性だった。これが楽しい。

プレイは今川義元でスタートして、真っ先に織田家を滅ぼした。今川義元が存命のうちに天下統一まで進められて大満足でクリアした。 1 万円もするので超高いけれど、お値段相当の価値があった。史実エピソードでほとんど知らなかった武将の話を知れて、そのあたりも新鮮だった。

あと今川義元がめちゃくちゃかっこ良いデザインで良かった。ステータスもかなり優秀で、特に外交能力が突き抜けてる。史実イベントで甲相駿三国同盟を結んだら周囲に残る脅威が織田家のみになるので、順当にプレイすると織田家を滅ぼすことになる。兵力的にも今川家のほうがずっと多い。史実では今川義元は織田信長に敗北するわけだが、今川家の勢力状況を鑑みると、今川家が織田家を滅ぼしても全然おかしくなかったのが分かる。

mixi2

しれっと発表された。招待リンクからアカウントを作った。作ったばかりでまだほとんど使えていないので、しばらく使って様子見する。 Bluesky もアカウント作ったけれど結局見なくなっちゃったので、すぐに見なくなるような気はしてる。

モンハンワイルズ

Steam でβテストやってたんで Discord の知り合いと一緒にプレイした。

僕はランサーなのでもちろんランスを選択。バグらしいバグもなく、感触は良かった。ただしボスがめちゃくちゃタフで、制限時間内に倒しきれなかった。

概ね面白かったけれど、モンハンライズは途中で飽きてもういいやってなった。快適にプレイできるモンハンでも、結局ゲーム性が僕に合わないとわかったので、ワイルズが発売されても買う予定はない。

仕事

SRE として働いている。

CI/CD の速度改善でいろいろやってることが多かった。それなりにでかいインフラの構築準備を進めているが、完了するのは来年になる。その間に割り込み作業も一定発生しているので、果たしてどうなるか。できれば 3 月末までには終わらせたいが、すでに割り込みが発生しているので厳しそうな感じがしている。

一人でできることの限界

過去の振り返りでも書いた気がするけれど、一人でできることの限界を感じている。

等級が上がってきて難しい作業をやることが増えてくると、一人で全部やるのが厳しい。一応、時間をかければ全部一人で出来るはずだが複数人で進めたほうが当然ずっと早い。そのため複数人で今はタスクを進めている。

自分たちは互いに多忙を極めていて、複数作業を掛け持ちしまくっている。今やっているでかい作業も、明確な締切がないためメイン担当は僕のみで、他メンバーは全員サブの掛け持ちで入っている。自分以外はメイン業務が他にあるなかで、効率的に業務を進める方法を模索しながら進めている。

基本的には自分が設計をして、やるべき作業を洗い出してそれらをタスクに起こす。タスクにはやることとゴールを明記し、担当する人が悩む要素を極力排除している。「タスクを担当したらあとはやるだけ」状態を維持することで、スキマ時間にタスクを拾って進められるようにしている。

SIer のシステムエンジニアとプログラマみたいな関係になっている感があって、はたしてこれがベターな方法か分からない。

個人開発

個人開発でなんかやったっけ？と思って思い返したら、そういうのをブログに書いてたことを思い出した（えっ？）。

あんまり開発らしい開発をしてなかったので、忘れてしまってた。ブログのトップページみたらカテゴリごとに記事を表示してるんで、そこ見れば今年やったことがだいたい分かる。

この中だと setup-nim-action の v2 対応が一番重たい作業だった。使ってる人が多いのでユーザ影響がそれなりにあった。一応対応が一区切りついたので今は落ち着いている。

あと何故か setup-nim-action をクローンして setup-nimble-action なるものが Nim 公式グループに作られていた。 nimble だけインストールしたい、といったニーズがあるのだろうか？なんならこのまま setup-nim-action も nim-lang で保守してほしい気持ちがある。僕個人が保守し続けるより、そっちのほうが健全だろう。

CIDR のやつは仕事でそういうことをやる必要があったんで、似たようなこと今後もやらなくていいようにツール化しただけ。

winget のやつは必要に迫られてやった感じ。今のところ不便していないかな。

記事になってないけれど他にやったこととしては、長い事保守していた websh を止めたりはした。あとはそれこそブログ移転くらいか。

技術書

効率的な Go
- まだ読んでる途中だけど、割と納得感があること

ゲーム

VR
- ほぼやってない。やっぱ普通にコントローラーでやるゲームのが好き
エルデンリング DLC
- めっちゃ良かった
- 最初はボスが強すぎてやばかったけれど、今はほど良いバランスに落ち着いてる
仁王 2
- 神ゲー
- Team Ninja 開発のゲームをもっとプレイしたいと思った
- 今年一番やったゲームかも
Winning Post 10 2024
- ツインターボ親系統確率できて満足した
- 2025 年には 2025 版が出るらしいが、流石にもういいかな
信長の野望・新生
- 初めてプレイした信長の野望シリーズ。めっちゃ楽しかった
ドラクエ3リメイク
- ドラゴンクエスト3リメイククリアしたに書いた
- ゲームバランスは悪いし、色々と荒いゲームだった
ロマサガ2 リベンジオブザセブン
- まだプレイ途中だけれど、神ゲー。超楽しい
- ゲームバランスが絶妙に良い。7 英雄との戦闘が毎回ヒリつく
- ロマサガシリーズ未プレイだったんで、新鮮な気持ちでプレイしている
- ドラクエ3 リメイクよりずっと完成度が高い
- 攻略はほとんど見ずにプレイしてるので、カンバーランドが滅亡したときは「やっちまった…」って気持ちになった
- できればキャラクリ機能が欲しかった
Enotria the last song
- Enotria The Last Song をクリアした感想に書いた
- 戦闘メインのゲームなのに手触りの悪いゲームだった
Green hell
- 面白かったけれど、あんまり拠点をじっくり作り込んでいくようなゲーム性じゃなかったのが残念
- 一応拠点作り込めるけれど、それをするメリットが薄い
- 小さい拠点を作りながら転々と移動するほうが楽だった
7 days to die
- めちゃくちゃ長い期間アーリーアクセスが続いていたが、ようやく正式リリースされた
- 何故かライブラリにあったのでプレイした
- 面白かったけれど、クエストひたすら回して本を読んで装備を強化することの繰り返ししかしてないことに気づいてから一気に飽きた
- 7 の倍数の日に発生する襲撃も、最初は刺激的だったけれど割と簡単にやり過ごせる
- 強いゾンビも対策がわかればどうということはない
- 色々スキルがあるけれど、結局アサルトライフル系のスキルと隠密スキルが強力すぎるんで、それ以外の戦闘スキルは全部微妙。もったいない
EDF6
- HARD でクリアした
- ストーリーは今までの EDF シリーズのなかで一番良かった
- エアレイダーが色々不遇な扱いを受けていたのが残念
- ただ EDF 4 から兵科が増えてないので、もうちょっと味変が欲しかったところ
ウマ娘大感謝祭
- ウマ娘の買い切りゲーム
- Steam 版をお布施と思って買った
- スペシャルウィークのチームのシナリオだけクリアした
- わかりきってたけれど、子供向けの簡単なゲームだった
- 普通に面白かった。バグらしいバグもない。丁寧に作られたファン向けのコンパクトなゲームって印象
- 良いゲームだけど、好みではなかった
- まぁ肌に合わないと分かりきったうえで買ったんで、レビューとかも特に書いてない
- 何気にフルボイスなのが驚いた。推しウマ娘がいる人にとっては垂涎ものでは
- 僕はキングヘイローが大好きなので、スペシャルウィークのチームだけやった（キングヘイローがいるから）
モンハンライズ
- 本編はクリアした。サンブレイクは途中で飽きた
- 初めてランスを使って、イチオシ武器になった
- 前にやったモンハンがセカンドG なんで、その間にあらゆるものが快適になっていて驚いた
- セカンドGでは狩猟笛を使ってた
- ランスは機動力がめちゃくちゃ上がっていて、敵に張り付いてずっと攻撃できるのが楽しくてずっとランス使ってた
- が、モンハンのハクスラ感は肌に合わなくて、サンブレイク途中で飽きた
- 後半の戦闘では敵が超タフで1回の戦闘がすごい長くてダレる。敵も強いって感じじゃなくて単純に火力が高いだけって印象
- あと敵が割と逃げるし、快適になったといえど移動時間が多くてダルい
- エルデンリングや仁王 2 みたいな、数分で決着がつく緊張感ある戦闘をしたい
- まぁこれはゲーム性の違いなんで仕方ない。僕には合わないというだけなので、もう買うことはないだろう

私生活

前述のジムの話以外だと、海外の時事ニュースや事故事例を見るようになった。 Youtube でそういう情報を取りまとめてるチャンネルがあって、それらをたまに見ている。

Youtube のニュース系チャンネルには、内容が不正確でガバガバなものも普通にある。 PV 数を稼ぐために過度に脚色されているものや、憶測でストーリー性を表現しているものなど。そういうのは避けてある程度内容が信頼できるチャンネルだけラジオ感覚で聞き流している。

基本的には以下の 4 点を守っているチャンネルだけ見ている。

情報の出典が明記されている
事実と想像を分けて説明している
その情報発信の目的から動画の内容が逸脱していない
1. PV 数稼ぎに傾倒すると正確で健全な内容から離れていくリスクがある
説明に誤りがあった場合は訂正している

資格勉強

LPIC-1 と AWS ソリューションアーキテクトの資格が期限切れで失効したはず。取り直さなきゃ。

まとめ

うーん、ゲームに全振りだった。 RSS フィードとかで気になる情報はキャッチアップしてるんで、インプットはしてるが、技術的アウトプットがほとんどなかった。最近はゲーム作ってみたい、って気持ちが出てきてるんで Godot の勉強再開したい。

あと仕事でアクセシビリティ周りの情報にふれる機会が最近多いので、GitHub Pages で公開してるサイトに適用したい。

来年の目標

GitHub Pages で公開してる Web サイトにアクセシビリティ対応を入れる
資格の更新と、デベロッパーアソシエイトの取得など
Godot の勉強

本ブログを支える技術

2024-09-29T14:58:24+09:00

本ブログを支える技術

ある程度ブログの体裁が固まったので、現時点で本ブログに使っている技術要素をまとめることにした。

運用
技術要素

運用

ソースコードは https://github.com/jiro4989/jiro4989.github.io で管理している。

運用としては、以下の手順をしているだけ。

scripts/ne_post.sh を実行して記事を作成する
ファイルを編集する
scripts/set_date.sh を実行して index.md にリンクを埋め込み
git push

していることはたったこれだけだけれど、この中にいろんな技術要素がある。

技術要素

GitHub Pages

まずこのサイトは GitHub Pages でホスティングしている。

GitHub Pages は GitHub が提供している静的ページを公開できるサービス。無料で利用できる。

用途は主に 2 つある。

プロジェクト用のページ
ブログ

プロジェクト用のページというのは、例えば作ったライブラリの API ドキュメントのページ。 Nim や Go などでは、ドキュメンテーションコメントを記述することで、それらを API ドキュメントとして静的 HTML 出力する機能がある。これらを GitHub Pages で公開すれば、ライブラリユーザに API 仕様を説明できる。

ブログは僕が本ブログを公開しているのがそれ。 GitHub Pages は静的サイトジェネレーターとして内部で Jekyll を使用している。ブログとして使うときに便利ないろんな変数が用意されている。

Jekyll

前述のとおり、Jekyll は静的サイトジェネレータです。 Markdown で書いたものを HTML に変換してくれたり、Jekyll 固有の構文を使うことで、何らかの変数を HTML 内に埋め込んだりできる。

本ブログを作る上で Jekyll の機能を意識することはあまりなかったが、唯一確認したのは変数の説明です。この中のサイト変数、ページ変数を使用して HTML に動的要素を埋め込んだ。

例えばページ変数を使ってこういうコードを書いた。これはブログの各記事に、前後の記事への導線を配置するコード。条件分岐を使って、前後要素があるときだけ a タグを作るようにしている。


 href="/tech/2024/07/05/setup-nim-action-v2.html">前の記事 setup-nim-action を v2 にバージョンアップした
|
 href="/daily/2024/12/28/furikaeri-2024.html">次の記事 2024年振り返り

この前後記事への導線は、使用しているテーマの slate のデフォルトレイアウトには含まれていなかった。別に動線も必要なかったけれど、簡単に仕込めそうだったので入れた。

Markdown

わざわざ書く必要もない気がするけれど、当然 Markdown を使っている。ブログ記事はすべて Markdown で書いている。

Markdown には方言があるので、書いた Markdown が描画されたときに正しく描画されないことがある。 GitHub においては GitHub Flavored Markdown が使われている。 Markdown の書き方は基本的な書き方とフォーマットの構文という記事で説明されている。

また、Markdown だけでなく静的サイトジェネレータの構文も使用できるため、書いているコードが何の機能のコードなのか意識しなければならない。例えば GitHub では以下の 2 行のコードで目次（Table of Contents）を自動生成できる。このコードは、何の機能だろうか？

* Table of contents
{:toc}

これは Markdown の機能ではない。 Jekyll が使っている Markdown レンダラーの Kramdown の機能です。 Kramdown は Jekyll のデフォルト Markdown レンダラーです。 Kramdown のドキュメントにて、toc について以下の記載がある。

Automatic “Table of Contents” Generation

kramdown supports the automatic generation of the table of contents of all headers that have an ID set. Just assign the reference name “toc” to an ordered or unordered list by using an IAL and the list will be replaced with the actual table of contents, rendered as nested unordered lists if “toc” was applied to an unordered list or else as nested ordered lists. All attributes applied to the original list will also be applied to the generated TOC list and it will get an ID of markdown-toc if no ID was set.

When the auto_ids option is set, all headers will appear in the table of contents as they all will have an ID. Assign the class name “no_toc” to a header to exclude it from the table of contents.

Here is an example that generates a “Table of Contents” as an unordered list:

# Contents header
{:.no_toc}

* A markdown unordered list which will be replaced with the ToC, excluding the "Contents header" from above
{:toc}

# H1 header

## H2 header

この説明から、toc が Kramdown の機能であることが分かる。また、no_toc を設定することで H1 見出しを目次から除外する機能もあることが分かる。使ったことはないが、おそらく使用できるのだろう。

とにかく toc は Markdown の機能ではなく Jekyll と Kramdown の機能です。したがって、Jekyll を使っていない Markdown レンダリングをしているサイトに toc を書いても、目次を自動生成できない。

例として、おそらくはてなブログなどに toc を書いてもレンダリングされないだろう。そもそもはてなブログには [:contents] で目次を生成する機能があるのでなおさらそうだろう。

HTML、CSS、JavaScript

これもわざわざ書く必要はない気がするけれど、当然 HTML、CSS、JavaScript を使っている。 slate テーマをそのまま使っていて、レイアウトに手を加える必要がなければ書く必要はない。僕はレイアウトを調整したい箇所があったので、一部これらに手を加えている。

GitHub Pages でサイトを公開するだけであれば、Markdown の知識があるだけで一応ページを公開できる。しかし Markdown しか書かなかったとしても、HTML 周辺の知識は一定把握しておいたほうが良い。 Markdown は最終的に HTML に変換されて出力される。したがって、書いた Markdown がどのような HTML として出力されるかは、意識したほうがいい。

例えば、以下の Markdown がある。これは画像ファイルを埋め込むための構文です。

![](sushi.png)

これを HTML に変換すると、次のようになる。

 src="sushi.png" alt="">

つまり Markdown における画像埋め込み構文の [] 内は、HTML の img タグにおける alt 属性です。

これを意識していないと何が起きるかというと、例えば WCAG（Web Content Accessibility Guidelines）を守れないといったことが起きる。

WCAG はウェブコンテンツをよりアクセシブルにするための広範囲に及ぶ推奨事項を網羅したガイドラインです。このガイドラインに従うことで、全盲又はロービジョン、ろう又は難聴、運動制限、発話困難、光感受性発作及びこれらの組合せ、並びに学習障害及び認知限界への一部の適応を含んだ、様々な障害のある人に対して、コンテンツをアクセシブルにすることができる。

例えば WCAG 2.1 の「達成基準 1.1.1 非テキストコンテンツ」には、以下のガイドラインが示されている。

達成基準 1.1.1 非テキストコンテンツ

（レベル A）

利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている。

これに対する失敗例としてF65: 達成基準 1.1.1 の失敗例－ img 要素、area 要素、及び type “image” の input 要素の alt 属性又はテキストによる代替を省略しているがある。

コード例は以下。

 src="../images/animal.jpg" />

つまり非テキストコンテンツには、適切な代替テキストを設定することが求められる。これを意識するには img タグにおける alt 属性を知っている必要があり、この HTML 要素と Markdown の関係性を知っていなければならない。

また別の例を挙げる。以下の Markdown がある。

台風 999 号が南から接近しています。
3 日後には本州に上陸する見通しです。

[Read More ](ff.html)

これは HTML だと以下になる。

台風 999 号が南から接近しています。
3 日後には本州に上陸する見通しです。
 href="ff.html">Read More

この例だと WCAG 2.1 の達成基準 2.4.4 リンクの目的 (コンテキスト内)に違反する。

達成基準 2.4.4 リンクの目的 (コンテキスト内)

(レベル A)

それぞれのリンクの目的が、リンクのテキスト単独で、又はリンクのテキストとプログラムによる解釈が可能なリンクのコンテキストから判断できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。

この Read More というリンクは、それ単体でリンクの目的が解釈できない。段落としても分かれているため、プログラムとしてもリンクの関連を理解できない。

失敗例はF63: 達成基準 2.4.4 の失敗例－リンクと関係のないコンテンツにのみ、リンクの文脈を提供しているとしてまとまっている。

あるニュースサービスでは記事の冒頭のいくつかの文を一つの段落に入れている。その次の段落には「Read More…」というリンクが置かれている。そのリンクは導入文と同じ段落にないので、利用者はそのリンクが何についての続きを読むのかを容易に見つけることができない。

A British businessman has racked up 2 million flyer miles and plans to 
travel on the world's first commercial tourism flights to space.

 href="ff.html">Read More...

ではどう直せばいいかというと、こうすればいい。間の空白行を削除する。

台風 999 号が南から接近しています。
3 日後には本州に上陸する見通しです。
[Read More ](tenkiyoho.html)

これが HTML に変換されると、同じ段落(p)になる。そもそも Read More ってリンクの貼り方をやめたほうが良いと思うが、それはまた別の話。

台風 999 号が南から接近しています。
3 日後には本州に上陸する見通しです。
 href="tenkiyoho.html">Read More

これは Markdown では空白行が段落の区切れ目として解釈されるから、このようなことになる。先の例では、間に空白行が存在したため、文章とリンクはそれぞれ別の段落になっていた。

このように、Markdown がどのように HTML に変換されるかを意識していないと、困る場合がある。 WCAG を守るかどうかに限らず、読みやすい文章を意識するならば Markdown しか書かなくても HTML 周りは知っていたほうがいい。

Go 言語

一部の手作業を簡略化するためにツールを Go で書いている。 Go にしたのは僕が使い慣れているからというだけで、別に Ruby や Python でも良かった。それなりに複雑なコードで、テストコードも書きたかったので、静的型付け言語の Go で書いた。

コードとしては scripts ディレクトリ配下の embed_links と generate_markdown_links がそれです。

テンプレートエンジン

前述の Jekyll のテンプレートコードもそうだが、Go のツールでもテンプレート(text/template)を使っている。やっている処理は、Markdown の投稿記事リンクの生成。 index.md の投稿記事セクションに埋め込む用途で使っている。以下のようなリンクを生成する。

* 2024-07-05 技術 [setup-nim-action を v2 にバージョンアップした](/tech/2024/07/05/setup-nim-action-v2.html)

この程度のリンク生成であれば、わざわざ text/template のようなテンプレートエンジンを使う必要はない。しかし構造化された文章を繰り返し生成するといったユースケースは、テンプレートエンジンと非常に相性が良いので採用した。

テンプレートエンジンの使用経験としては、圧倒的に Go のテンプレートエンジンのが使い慣れている。他には Ansible で使われている Jinja2 も使ったことがある。そして Jekyll のテンプレートエンジンは全く触ったことがなかった。それでも、多少ドキュメントを読めば少しのテンプレート程度ならすぐに埋め込める。

テンプレートエンジンはそれぞれ構文が多少異なるが、考え方はどれも似通っている。なにか 1 つをある程度使い込んだ経験があれば、他のテンプレートエンジンもスムーズに使っていけると思う。

ユニットテスト

単純なシェルスクリプト程度ならユニットテストは書かないが、それなりに複雑な処理を書いたときは必ずユニットテストを実装する。本ブログにおいては、embed_links と generate_markdown_links でユニットテストを実装した。

Go はユニットテストの機能が言語自体に組み込まれているため、非常にテストコードが書きやすい。ただし、ユニットテスト用の関数などはあまり充実していないため、サードパーティのライブラリを使うケースがほとんどだと思う。 Go では testify がおそらく最もメジャーなテストライブラリだろう。仕事でもプライベートでもよく使っている。

Go 言語でユニットテストのコードを書くときは、テーブルドリブンテストを書くことが多い。テーブルドリブンテストは Go の Wiki でも専用ページが設けられているため、Go においてはメジャーな手法だ。

テストコードを書くときのルール

コード的には以下のコードを書いた。他にもいくつかテストケースを書いたが、概ね書き方は同じ。

func TestReadAttrLine(t *testing.T) {
    tests := []struct {
        desc    string
        path    string
        attr    string
        want    string
        wantErr bool
    }{
        {
            desc:    "正常系: 最初の layout を読み取る",
            path:    "sample1.md",
            attr:    "layout:",
            want:    "default",
            wantErr: false,
        },
        {
            desc:    "異常系: 該当する attr が見つからない",
            path:    "sample1.md",
            attr:    "pohe:",
            want:    "",
            wantErr: true,
        },
    }

    for _, tt := range tests {
        t.Run(tt.desc, func(t *testing.T) {
            a := assert.New(t)

            path := filepath.Join("testdata", tt.path)
            got, err := readAttrLine(path, tt.attr)
            if tt.wantErr {
                a.Error(err)
                a.Empty(got)
                return
            }
            a.Equal(tt.want, got)
            a.NoError(err)
        })
    }
}

僕がテストコードを書くときは、いくつか一貫したルールを設けて書いている。このルールはあくまでも僕個人が意識しているだけのものであり、何かのガイドラインに従ったものではない。

テストケース構造体は無名構造体にして、テスト関数内で定義する
テストケースの説明(desc)を書く
テストケースの説明には正常系と異常系のどちらなのかを書く
テストケースの順序は正常系を先に書く
テストケースの期待値変数は want にする
テストケースの期待値エラー変数は wantErr (bool) にする
テスト対象の関数の戻り値変数名は got にする

テストケース構造体を無名構造体にしているのは、その型定義を他のテストケースで使うことがほぼなくて、名前をつける意味がないため。

テストケースの説明は、他の人がテストコードを見たときに、テストの目的を理解できるようにするため。また、説明を補足するために正常系、異常系を明示する。

正常系を先に書くのは、テストコードを他の人が読んだとき、まず上からテストコードを読むだろうから。コードを理解するなら、まず正常系を読んで異常系を読むほうが理解しやすいだろう、との配慮でそうしている。

変数名の統一は、変数名から目的をパッと理解できるようにするため。あと grep しやすいから。

テストする前提でコードを書く

こういう関数を書いたが、引数として io.Reader インタフェースを渡すようにしている。

// readStdin は標準入力を文字列の配列として返す。
func readStdin(r io.Reader) ([]string, error) {
    ret := make([]string, 0)
    sc := bufio.NewScanner(r)
    for sc.Scan() {
        line := strings.TrimSpace(sc.Text())
        ret = append(ret, line)
    }
    if err := sc.Err(); err != nil {
        return nil, err
    }
    return ret, nil
}

ツールとしては標準入力からしかデータを渡さないので、別にインタフェースしなくて良いといえば良い。 bufio.NewScanner に os.Stdin を直接渡してもいい。でも、あえてそうしていない。理由はテストコードを書きやすくするため。

標準入出力や、ファイル IO みたいな外部とやりとりするコードを直接書いてしまうと、テストコードが書きづらくなる。しかしインタフェースを渡すように実装してあると、外部を意識せずにテストがかけて保守性が上がる。

たとえば先の標準入力部分のテストは以下の実装になっている。

a := assert.New(t)

r := strings.NewReader(tt.text)
got, err := readStdin(r)
if tt.wantErr {
    a.Error(err)
    a.Nil(got)
    return
}

a.Equal(tt.want, got)
a.NoError(err)

標準入力をあれこれいじってテキストを流し込んだりとかする必要がない。ただの文字列を strings.Reader にして、そのまま渡すことができる。非常にシンプルなコードになった。

標準出力を扱うコードを書く場合も fmt.Println で標準出力に書くのではなく fmt.Fprintln に io.Writer を渡すように書いたほうがいい。そうすれば、以下のように bytes.Buffer を使って書き込まれたテキストを簡単に取り出してテスト結果を比較できる。

a := assert.New(t)

w := &bytes.Buffer{}
err := generateLinks(tt.i, w)
if tt.wantErr {
    a.Error(err)
    return
}

got := w.String()
a.Equal(tt.want, got)

npm

後述する textlint を管理するために npm を使っている。これは Node.js のパッケージマネージャだ。

Node.js にはあまり明るくないが、最低限の仕組みは知っている。

textlint

textlint は Node.js 製の文章構成ツールです。日本語をサポートしていて非常に重宝している。

一文が長すぎたり、「が」が何度も登場して文章が複雑になっているのを検出してくれる。これにより一文がシンプルで短くなって、読む人の負担を減らしてくれる。

文章の執筆には vim を使っているが textlint が書いている文章を自動で指摘してくれるため容易に修正できる。こういったエディタとの連携は各エディタがやっていて、VSCode にも同様のものがある。長い文章を執筆する際はエディタと連携するのをオススメする。

GitHub Actions

GitHub Actions は GitHub に組み込まれている CI/CD 基盤です。

Push、Pull Request などをトリガーに CI を走らせたり、特定のファイルが変更されたときだけ CI を走らせたりできる。本ブログでは textlint とツールのユニットテストを GitHub Actions でテストしている。

テストの条件はファイルの変更があったときだけ実行するようにしている。 Markdown 記事が編集されたときだけ textlint を実行する。 scripts 配下が変更されたときだけユニットテストを実行する、といった具合。

dependabot

dependabot は GitHub に組み込まれたパッケージ自動更新の仕組みです。

新しいバージョンのパッケージが公開されたら自動で Pull Request を作ってくれる。先の textlint なども、定期的にアップデートが入るため、最新に追従する目的で導入している。自動で Pull Request が作られて、CI がパスしたら自動でマージするようにしているため、運用の負担はほとんどない。

setup-nim-action を v2 にバージョンアップした

2024-07-05T09:00:00+09:00

setup-nim-action を v2 にバージョンアップした

setup-nim-action という自作の GitHub Actions（カスタムアクション）がある。

2019年ごろに公開してからほそぼそと更新を続けていて、おそらくGitHubのNimプロジェクトのCIで一番使われている Nim setup アクションなんじゃないかと自負してる。もっとも、ここ数年は特に大きなアップデートもなく、node_modules の依存ライブラリ更新しかしてなかったので、大きな変更がない状態だった。

そんな setup-nim-action がとある理由で大改修することになり、生まれ変わってメジャーバージョンアップした。

突然 Nim のインストールが遅くなった
調査と修正
破壊的変更とマイグレーション
やり終えた感想
setup-nim-actionはnim-langグループの管理下になってほしい

突然 Nim のインストールが遅くなった

ある日いきなり CI が急激に遅くなった。今までは10秒もかかっていなかったコンパイラのインストールに6分くらいかかるようになった。 Macに至っては30分もかかるようになり、issues が作られた。

https://github.com/jiro4989/setup-nim-action/issues/483

特に僕はsetup-nim-actionに手を入れていなかったのにいきなり CI が遅くなったので、原因があるとすれば以下のどちらかだろうと考えた。

GitHub Actions のランナーに変更が入った
内部で使っている choosenim に変更が入った

しかし choosenim も新バージョンは特に公開されていないので、挙動が変わるようには思えなかった。

正直、何が原因なのか皆目検討がつかなかったのでお手上げ状態だったのだけれど、とはいえユーザが多いので放置するわけにもいかなかった。そんなわけでとにかくインストールを高速で終わらせるためにあらゆる調査をした。

調査と修正

結果としては、choosenim を使ってインストールしようとすると非常に時間がかかるとわかった。それもGitHub Actions上で実行した場合のみ。

choosenim を使うと node ランタイムでも composite アクションでもインストールに時間がかかっていた。 setup-nim-action v1 はTypeScriptで実装しており、node20 ランタイムで動作していた。その内部では choosenim に依存しており、アクション実行時に choosenim をダウンロードしてきて実行して Nim をインストールするような作りになっている。

GitHub Actionsのカスタムランタイムは、node 系と composite の 2 つが選択できる。 composite はあとから追加されたランタイムで、簡単にいうとGitHub Actionsのワークフローをかくときの YAML 構文がそのままカスタムアクションになる。したがって、実装は bash あるいは PowerShellが基本になる。

今回の問題の調査の結果 node ランタイムから composite に切り替えて、choosenim で実装されていた Nim をインストールする処理をすべてbashで実装しなおす ことにした。

もちろん、choosenim のすべてをシェルスクリプトに移植したわけではない。 choosenim は実行プラットフォームを判定して必要な依存ライブラリを整えるような処理も含まれる。 setup-nim-action はそこまでやらず、Nimコンパイラのインストール部分のみを実装することにした。依存ライブラリ（GCCとか）はすべて GitHub Actions のランナー側でほぼ揃うだろう、と考えたため。

この場合、curl でビルド済みのコンパイラを落としてきて配置してPATHを通すだけで良い。 bashで実装してもそこまで膨大なコードにはならないだろうと判断した。

対応したPRは以下。

https://github.com/jiro4989/setup-nim-action/pull/491

choosenim にはなくて setup-nim-action で独自に実装していた 1.x とか 1.6.x とかで最新版を取ってくる処理もシェルスクリプトで実装しなおした。この対応により、setup-nim-action は約5年間ずっと依存していた choosenim への依存がなくなった。

そしてNimのインストール速度はいぜんと同等の速度でインストールできる状態に戻った。

TypeScriptなども不要になったため、リポジトリ上から node.js, typescript のコードがすべて消え、node_modules も不要になった。 node ランタイムのカスタムアクションでは、node_modules をリポジトリのコードとして抱えなければならない制約があるので、コード量がめちゃくちゃ多くなる。

結果として、setup-nim-action はたかだか130行程度のシェルスクリプトと、少しの action.yml だけで動作する非常にコンパクトなカスタムアクションへと生まれ変わった。

破壊的変更とマイグレーション

僕はchoosenimの中身に詳しいわけではないため、choosenimの移植をしたわけではない。

やったこととしては、GitHub Actions上でNimが使えるように必要最低限の処理のみをシェルスクリプトで実装した。かなり突貫工事での実装になったし、ランタイムも変更になった。Nimのインストール先も変更せざるを得なかった。

ActionsのInputの必須パラメータは変えないように実装したので、使い勝手は今までと変わらないものの、大規模な変更になってしまった。そのため、苦渋の決断でメジャーバージョンアップして v2 バージョンを発行した。

破壊的変更をするならマイグレーションガイドが必要だろうと思い、かなり詳細にマイグレーションガイドを書いた。ついでだったので、Nim wikiにかかれてるCI周りも更新した。

やり終えた感想

急な対応だったのでかなり心身ともに疲れた。

が、結果としてリポジトリは非常にコンパクトになって、依存パッケージ管理からも開放されて非常に気分が良い。 dependabot で node_modules 更新するだけの運用から開放された。 choosenim への依存をなくしたかったのも実現できた。昔からどうにかしたいと思っていたので。

何気に composite アクションを初めて使ったので新鮮だった。シェルスクリプトだけの簡単なカスタムアクション作るときは、全部これで良いと思う。

setup-nim-actionはnim-langグループの管理下になってほしい

なんだかんだ setup-nim-action の保守を続けることもう5年。事実上 Nim プロジェクトで一番使われてる GitHub Actions（のはず）なんだし GitHub の nim-lang グループの管理下になってほしい気持ちがある。僕一人で保守しつづけてもまぁいいんだけれど、僕が突然亡くなったりしたら保守できる人いなくなっちゃうし。最近は Nim のコードほとんど書いてないのもあって、Nim公式が保守してほしい気持ちがある。

ただプロジェクトの移管は、問題もある。つい最近 Polyfill が売却されてマルウェアを仕込まれた事件があるので、どこまで信じていいのか分からない。

マルウェア混入が発覚したJavaScriptライブラリ「Polyfill.io」のドメインを登録事業者が停止 - Gigazine

まぁさすがに Nim 公式がそういうことするとは思えないけどね。

大量の IP が特定の CIDR に含まれているか調べるツールを作った

2024-04-21T09:00:00+09:00

大量の IP が特定の CIDR に含まれているか調べるツールを作った

アクセスログとかに書かれている大量のIPアドレスが、特定のCIDRに含まれるかどうかを高速にチェックしたくなったので、専用CLI checkcidr を作った。使用言語は Go 。

リポジトリ: https://github.com/jiro4989/checkcidr

たぶん誰かすでに作ってると思うんだけれど、最近コード書いてなかったし、気晴らしも兼ねて自分でガリガリ書いた。

背景
使い方
- 進捗表示
実装時間
まとめ

背景

アクセスログにはアクセス元IPアドレスが記録されており、それである程度アクセス元が特定できる。サービスを運用してるとほぼ毎日なんらかの不正アクセスが試行されている。

で、怪しいアクセスをまとめてブロックできたらいいんだけれど、誤ってブロックしてはいけないものもブロックするとまずい。例えば Google のクローラー。

Google のクローラーは、Web サイトを定期的にクローリングしている Bot です。このクローラーの目的は、サイトをなんらかの方法で評価して、検索結果上位に載せること。このクローラーを誤ってブロックしてしまうと、下手したら検索エンジン上にサイトが出てこなくなって SEO が悪化する可能性がある。

Google のクローラーからのアクセスの場合は UserAgent もそれとわかる名前になっている。なので UserAgent でブロックしないようにしても良いんだけれど、攻撃者が UserAgent を Googlebot に偽装する可能性も 0 ではない。

Googlebot のサクセス元 CIDR は公開されているので、この CIDR のアクセスを許可すれば誤ったブロックを防げる。

クローラーが Googlebot などの Google クローラーであることを確認する

このように、なんらかの CIDR に特定の IP アドレスが含まれるか調べたくなる機会は多々ある。しかし、アクセスログに記録されるIPアドレスは膨大で、且つ検査したい CIDR も1つではなく、何十個も存在したりする。必然的に CIDR 数 x IP アドレス数の総当たりでチェックして、見つかったら break 、って感じにしないととんでもなく時間がかかる。

こういった処理をそれなりに効率よく処理できて、進捗も確認できて、いろんな書式（JSONとか）で出力できるツールが欲しかったので、今回作った。

使い方

CIDR だけ書いたファイルと、IP だけ書いたファイルを引数として渡す。

1.2.0.0/16
1.3.0.0/16

1.2.1.2
1.2.1.3
1.3.1.2
1.3.1.3

実行すると、以下の結果が得られる。

$ ./checkcidr cidr.list ip.list
ip_file=ip.list cidr=1.2.0.0/16 ip=1.2.1.2 contains=true
ip_file=ip.list cidr=1.3.0.0/16 ip=1.2.1.2 contains=false
ip_file=ip.list cidr=1.2.0.0/16 ip=1.2.1.3 contains=true
ip_file=ip.list cidr=1.3.0.0/16 ip=1.2.1.3 contains=false
ip_file=ip.list cidr=1.2.0.0/16 ip=1.3.1.2 contains=false
ip_file=ip.list cidr=1.3.0.0/16 ip=1.3.1.2 contains=true
ip_file=ip.list cidr=1.2.0.0/16 ip=1.3.1.2 contains=false
ip_file=ip.list cidr=1.3.0.0/16 ip=1.3.1.2 contains=true

JSON 形式でも出力できる。

$ ./checkcidr -style json cidr.list ip.list | head -n 13

[
  {
    "ip_file": "ip.list",
    "cidr": "1.2.0.0/16",
    "ip": "1.2.1.2",
    "contains": true
  },
  {
    "ip_file": "ip.list",
    "cidr": "1.3.0.0/16",
    "ip": "1.2.1.2",
    "contains": false
  },

JSON配列の出力の場合、すべての行の処理が完了するまで出力できなくて不便なので、1行JSON（JSON Stream）として出力するオプションもつけた。この形式は jq でも処理できるし、割とよくある方式だと思う。

$ ./checkcidr -style json_stream cidr.list ip.list
{"ip_file":"ip.list","cidr":"1.2.0.0/16","ip":"1.2.1.2","contains":true}
{"ip_file":"ip.list","cidr":"1.3.0.0/16","ip":"1.2.1.2","contains":false}
{"ip_file":"ip.list","cidr":"1.2.0.0/16","ip":"1.2.1.3","contains":true}
{"ip_file":"ip.list","cidr":"1.3.0.0/16","ip":"1.2.1.3","contains":false}
{"ip_file":"ip.list","cidr":"1.2.0.0/16","ip":"1.3.1.2","contains":false}
{"ip_file":"ip.list","cidr":"1.3.0.0/16","ip":"1.3.1.2","contains":true}
{"ip_file":"ip.list","cidr":"1.2.0.0/16","ip":"1.3.1.2","contains":false}
{"ip_file":"ip.list","cidr":"1.3.0.0/16","ip":"1.3.1.2","contains":true}

進捗表示

検査処理のカウントが2500回を超えるたびに . を出力する処理を入れている。また、100,000回に到達すると改行する。

総当たりチェックをすると試行回数がとんでもない数になる場合があるので、1 回ずつ進捗を出すのではなく、数千回に1回だけ進捗を出すようにしている。画面がドットだらけ改行だらけとかになるとノイズになってしまうので、それを避けるためです。

こういう進捗表示は、ノイズにならないように、でも動作していることが視覚的に分かる良いバランスのとこを見つける必要がある。進捗表示のためだけに依存ライブラリを増やすのも嫌なので、基本的に簡単な進捗表示で良いときはいつもこのスタイルで実装している。

今回は一般公開の CLI で採用したが、社内専用ツールを実装するときにも使える手法なのでおすすめ。これらは標準エラー出力へ書き込むようにしてるので、検査結果出力の邪魔にはならない。また、オプションで進捗表示を消せるようにしている。

$ ./checkcidr testdata/cidr_1.txt testdata/ip_1.txt > /dev/null
........................................ 100000
........

実装時間

だいたい 3 時間ほど。

まとめ

CIDR に IP が含まれるか検査する CLI checkcidr を作った
大量の試行回数になることを見越して、進捗を出力するようにした

winget でパッケージを管理する

2024-01-12T09:00:00+09:00

winget でパッケージを管理する

2024/1/12 にデスクトップ PC を新しくした。新しい PC の開発環境をセットアップして、いつものように scoop をセットアップしたら、変な挙動をしていた。

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression
scoop install git

これを実行すると、git のインストール前にインストールされる 7zip のインストールで失敗していた。

エラーメッセージを読むに、git コマンドを使おうとしているが git コマンドが存在しなくてエラーになっていた。そこで、scoop 周りの情報を調べていたら、以下の記事を見つけた。

scoopシステム崩壊の序曲

どうやら scoop のメンテナンスが停止してしまっている可能性があるらしい。これはどうしたものか。scoop から chocolatey に戻るべきか？と思っていたが winget の存在を思い出した。

winget ツールを使用したアプリケーションのインストールと管理

これは Microsoft 公式がサポートするツールなので、信頼できるだろう。ということで、今までずっと使っていた scoop を使うのをやめて winget を使ってみる。

winget のインストール
winget を使ってみる

winget のインストール

winget ツールを使用したアプリケーションのインストールと管理にかかれているコマンドを実行してインストールする。

Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe

そして winget search vscode すると、応答がない。調査したところ、以下の記事を発見した。

wingetが応答しないときの対処方法

どうやらこ以下のバイナリっぽい。

https://github.com/microsoft/winget-cli/releases

上記記事を参考に winget を更新すると、winget のバージョンが上がった。

$ winget -v
v1.6.3482

これでようやく動作するようになった。

winget を使ってみる

早速 git をインストールしてみる。

$ winget search git
..
Git   Git.Git  2.43.0  winget

$ winget install Git
複数のパッケージが入力条件に一致しました。入力内容を修正してください。
名前   ID           ソース
---------------------------
My Git 9NLVK2SL2SSP msstore
Git    Git.Git      winget

どうやら git だけだと複数のパッケージがヒットするらしく、Git.Git と入力しないとだめらしい。以下のように実行することでインストールできた。

winget install Git.Git