2026/06/02(火)超かぐや姫!を観てきた2

超かぐや姫!を観てきたに続き、去る5/2に超かぐや姫!をまた観てきたので、その感想を残す。

鑑賞から一ヶ月以上経っていることもあり、当時感じたことの多くが記憶から抜け落ちてしまったが、残っている記憶の限りで書き出しておく。

この記事のIDが0671、最新は0695なので、下書きを起こしてからおよそ一ヶ月放置していたらしい…。

四回目の鑑賞で思ったこと

ヤチヨのモチーフはセーラームーン?

ヤチヨのモチーフはセーラームーン?月見ヤチヨと月野うさぎはどことなく名前が似てるし、髪型もオマージュに見えなくもない。

( ◠ ᗜ ◠ )みたいな表情もあの世代のアニメによくあった表現手法な気がするので、どことなく親近感を感じた。

物語は最初からタイムリープに組み込まれている?

序盤のどこかでヤチヨが8000歳という情報が出てきたと思うが、これは8000年掛けて月から地球に戻ってきたヤチヨに一致する。

つまり初めて月に飛来する赤子のヤチヨと、歌声を聴いて戻ってきたヤチヨが交差する時間軸がここにあるのではないか?と思った。

ツクヨミとクガネの類似性

FF14にはクガネという和風のマップがあるが、雰囲気的には似ているような気がした。いや、3Dの和風マップなんてどれも似たり寄ったりだろと言われたらそんな気もするが、桟橋のような場所や海と、連なる高層建築とか、そういう雰囲気が似ているなと思った。

もう届いちゃったから

いろはが「ヤチヨのデビュー曲ってもう歌わないの?」と言い、ヤチヨが「もう届いちゃったから」と返すシーンがあるが、これはいろはとヤチヨが出会えたことにより、もう届いたという意味ではないかと思った。

ライブやダンスなど、アクションパートがすべて2D表現

昨今アクションパートのキャラクター描写は3Dで描かれがちだが、本作では2Dが基本だ。これは工数がかかりコスト増につながるため、そういった表現を取れるというのは凄いことだと感じた。

いろはがかぐやを遊びに誘うシーン

今までかぐやに対してそっけない態度だったツンデレいろはが遂にデレてかぐやを遊びに誘うシーンのエモさは筆舌に尽くしがたいものがあった。あのシーンには思わずグッときた…。

特に脱力的な「あそぼ~~~~」というセリフが最高にエモかった…。

母との和解

蛇蝎のごとく嫌っていた母と意を決して話し合うシーンで、これまでの思いを告げ、認められるシーンは、これはすごくいいと思った。

毒親を嫌うのは同情を得やすいと思うが、その先で和解まで描くのは美しいと思った。似たシーンはガルクラにもあったので、一つの潮流かもしれない。

フシ、ふじゅ~

恐らくこれらはかぐややヤチヨが不死であることを暗喩しているのではないだろうか?

異例の鑑賞地

まず現状本作は神戸市内で上映があったのに、市内で一度も鑑賞しなかった作品になっており、これは歴代の鑑賞歴の中では異例だ。

理由は割と単純で、まず初回鑑賞時では神戸の映画館はすべて埋まっていて姫路で観るしかなかったことが一つ、本作は2時間半と尺が長いのと観る時間を取りづらいこと、そして大箱向きの作品であり、市内にある狭い箱で観る気が余り起きなかったことがある。

ぶっちゃけ神戸市内で音とスクリーンがいいのはシネ・リーブル神戸とキノシネマ神戸国際くらいで、OSシネマズ二館は微妙だと思ってる。そして上映があるのはOSシネマズだけだったので、必然的に観なくなるというわけだ。

姫路で三度も見ているのは一回観たらもう一回観たくなり、そうしたら終電を逸してしまい、仕方なく姫路に泊まったら、ついでに翌朝もう一回観たくなったためである。

アースシネマズは箱がデカく、今回上映のあった箱はウシオプレミアムシアターと雷舞で、何となく気分が上がるのもいい。

その次は高知で観ているが、これはこれまでにあった特典全配布があったのと、特別上映があるということ、前々から高知に興味があったことの三点がうまく合致し、高知鑑賞が決定した。

高知県立県民文化ホールには広いオレンジホールと狭いグリーンホールがあり、上映があったのは狭いグリーンホールだったが十分な広さがあり、音響も非常によかった。恐らくだが民間はROIに依存した設備にせざるを得ないところ、公営なので何かしら一定品質の要求があり、それを満たせる高品質な設備を整えられ、日々のメンテナンスも無駄にしっかりしてるからとか、そんなことが背景にあったりするところによるのではないかと思った。

高知の旅行記もまた後日書いていきたいと思う。

その他、鑑賞以外のこと

公式サイトのスペシャルコンテンツの充実が凄い。凄すぎる。

二次創作ガイドラインについて

まず目についたのは二次創作ガイドラインだ。

本作はその作品特性からだろうか、次の様に非常に寛大なガイドラインを示してくれている。

★二次創作は是非楽しんでください。
★個人あるいは特定少数のグループで楽しむことを主たる目的としてください。
★作品ならびにファンを傷つける行為はご遠慮ください。
★ファンのみなさま同士で二次創作をもとに批判することはおやめください。
★本編設定と異なる場合は、誤解を生まないよう事前に注意書きをするなど留意してください。
★公序良俗に反する内容はお控えください。
★二次創作は創造性・オリジナル性が認められるものに限ります。また、公式の発表物・販売物と誤認されないようにしてください。

つまるところ、良識の範囲で二次創作が自由なのだ。

作中に「ツクヨミは皆が表現者」という言葉もあるように、『超かぐや姫!』としては今後も二次創作を楽しんでいただきたいと考えております。

という一文も見逃せない。

二次創作物の販売・頒布という項目もあり、こちらでも期間を定めたうえでの直接頒布の制限、その期間外での委託頒布の許可、在庫に限り委託も可能といった、とても柔軟で現実的な内容を書かれている。ここまで寛大な公式は中々ないのではないだろうか?

更に驚くのが一次創作物の使用だ。

一次創作物については、『超かぐや姫!』公式X(旧Twitter)、YouTube、TikTok、Instagramで公開した画像や映像の一部または全部について、営利目的でない目的で、WebブログやSNS等に掲載(外部プラットフォームの埋め込み等)していただいても問題ないとのことで、これは相当寛大な措置である。ネット文化では当然のように無許可利用が見られミーム化されているが、それを公式で認めてしまうというのは凄いことだと思う。超かぐや姫!ならではと言える。

このため、本記事中でも公式YouTubeで公開された画像を引用して使っている。

その他諸々についても細かく、しかし非常に寛大な規定があり、更にはこのガイドラインの発効以前のことについては基本的に許容する方向の旨まで書かれており、あまりにも寛大で、もはや何回この記事中で寛大と書いたかわからないほどだ。

更には次のようにコミュニティに対する助言まであり、非常に配慮が行き届いた内容になっているのは驚きである。

本ガイドラインの内容を他の方へ指摘する行為はお控えください。

総じて超かぐや姫!の制作はネット文化や、そこからリアルワールドのオタク・同人文化に深く精通し、それらを言語化したうえで、ファンダムに対し公開できるというところで、大変すごいと思う。

また国際的に公開されている関係からか、以下の一文があるのも驚きだ。たぶん他の作品にはここまで中々ないのではなかろうか?

本ガイドラインは日本語によって発表いたします。
本ガイドラインのその他言語への翻訳は参照のためのものに過ぎず、日本語版と翻訳との間に齟齬がある場合には日本語版を優先とします。

特別上映の多さ

発声可能上映は勿論のこと、SNSへのポスト可能上映といった珍しいものや、今回私が赴いた、未上映県での頒布物全部付き、物販ありの特別上映など、とても充実した上映があったほか、舞台あいさつについても人口に膾炙しきったタイミングで最後のファンサだ!”卒業記念舞台挨拶という、素敵なタイトルで実施されるというのがとてもいい。

更にセカンド上映も全国各地で行われていたり、本日6/2からはライブ音響上映も始まるということで、非常にこういった上映が多く面白いと感じる。

応援コンテンツの豊富さ

配信カウントダウンイラストでは主要スタッフからのカウントダウンイラストが多数あり、劇場特典 スタッフイラスト集 掲載イラストにも同スタッフによる多数のイラストが掲示されているうえ、ライナーノーツ【本編オリジナル曲】でもすべての曲のノートが書かれている。

更には超豪華応援イラスト&コメントでは岸本斉史先生や藤本タツキ先生をはじめとした名だたる人物からの応援イラストやメッセージが届いており、これも凄いことだ。

本作は作品自体もかなり厚いが、制作側の熱意も凄く、本当にすごいと感じる。

素材配布

「私は、わたしの事が好き。」素材ではBoothやピアプロといった第三者のオタククリエイティブプラットフォームを使った公式動画やロゴなどの素材配布があったり、壁紙ではLive2D画像を使ったスマホ壁紙の配布もあった。

お決まりのSNSアイコンとかは見られないが、配布コンテンツの内容が他にない独創性を持っていて、これはいいなと思った。

2026/06/02(火)LLMに対する最近の思いとか過去の考えとかの整理

投稿日:

これまでいろいろ書いてきたが、それらの総括的なものを吐露していく。

金銭面での問題

LLMは金が掛かる。特にAnthropicをBANされてPoeから叩いている私はなおのこと金が掛かる。

レートリミットがないので無限に使えるのを強みと言いたいが、そんなのはすっぱい葡萄の話でしかない。

またクラウドの登場からずっと言われていることだが、デジタル赤字の根源の一つにもなっている。

LLMを使えば使うほどAnthropicやOpenAI、Googleなどに富が流れ出ててしまうので、これは国としてみた場合に深刻だ。最近はデジタル小作人とかとも言われている。

とはいえ、正直これは仕方がない面もあり、ぶっちゃけITシステムはコモディティ化しやすく、局所的なところに集中せざるを得ないと思っている。例外的に中国だけは国内で回せているが、最前線とまでは言えないにせよ自前で実用水準を回せているが、これは中国の地政学的な問題が大きく影響していると考えている。

何故なら中国はその体制的に、アメリカのIT資産にアクセスできなかったり、仮にできてもある日突然禁じられるリスクがある。それなら中国の国家運営にフィットし、あわよくば普及させることで他国を操作しうる国産モデルの開発を好み、そのためなら予算を惜しまないだろう。だからこそ、一定のLLM開発が成立していると言える。

何故なら、もしアメリカを超えるモデルを作って普及させられれば、アメリカがやっているように「使わせない」ことで圧力をかけたり、制裁の脅しに使えるからだ。当然、そこから情報を抜き取って中国に有利な形で活用することもできるだろう。実際、中国が怪しい振る舞いをしているのは、Huaweiの問題や、宇通のバスに仕込まれていたバックドアからも明らかだ。

一方、日本にこれはできない。ドイツやイタリアをはじめとした欧州諸国だってそうだろう。アメリカ以外の国の大半には自国でフロンティアモデルレベルのLLMを作るだけの技術もリソースも恐らくない。何故なら現状フロンティアモデルは中国ですら到達できていないからだ。中国はフロンティアモデルを使ってLLMをトレーニングしていることが知られており、AnthropicもDetecting and preventing distillation attacksでそのことを公表している。要するに、中国でさえ自力でまともなモデルを作るだけのリソースを持っておらず、他人の成果物を横取りすることしか出来ない訳だ。

だが本質はそこではない。仮に世界各国が作り合ったとしても、同じようなものが万国に散らばっていても意味がない。すべての国が中米のように敵対しているわけでもない以上、いずれどこかに収束するのは自明であり、結局やる意味がないと言える。

開発時の認知負荷の重さ

AIを使った開発に取り組み始めてみた雑感で軽く触れ、Value-DomainのDNSを操作するユーティリティを更新したで実感したことだが、LLMを書いたコードをレビューするのは大変だ。

何せ一気に大量のコードを書いてくるし、もっともらしいコードを書いてくるので非常に疲れる。これが人間の書いたコードなら荒探しをしたい気持ちなどが湧いてきて徹底的に見たりするような気がするのだが、LLMは人間ではないのでそんな気も起きない。だって、間違いを指摘しても学んだり成長しないから、意味がない。

AIコーディングのレビュー負荷に関することは色んな企業のテックブログでも言われていると思うが、正直大量に書かせてしまうとレビューはほぼ無理だと思う。

先日読んだテストコードの意味がないという記事もまさにそれに近い話だろう。とはいえ、なかなか難しい話だとは思う。

個人的には実装からテストコードを書かせるのであっても、正常ケースと異常ケースを網羅的に書かせることができれば、以後の修正でテストが落ちれば、それは問題ないと感じる。但し初回作成時に実装コードを破壊して、意図したとおりにテストが落ちることの確認はしておいたほうが良いだろう。とはいえ、LLMに書かせているとそれすらおっくうになってくるのが個人的には困りものだ。

やるとしたらモジュラモノリスのような小さなモジュールを集めた構造にし、それを書かせれば多少はマシになると思う。でもそれって人間書いてもいいですよねってなるわけで、何ともな感じもある。

他にもLLMが書くと人間が正しく認知しないとか、人間が手で書いていればハマった部分や苦労した部分などで記憶に残り、バグが出たときに「あそこかも!」という当たりが付いたりするが、LLMに書かせていると、まず無理だろう。

当然LLMでも特定はできるだろうが、LLMは金が掛かるし、ソースを精査する時間も長い。チューニングで何とかなるといっても誰がチューニングするんだという話になってくる。

思考力の低下

よく昔はできたが今はできないということが語られると思う。例えば元開発者のマネージャーが、手を動かさなくなった結果、開発方法を忘れたとか、そんなことを話したりする。やっていなかったことができなることは自然なことだ。日々やり続けることによってのみ筋力が維持されるのと同じことである。

同様にLLMを使っていれば、LLMを使う力は養われるだろうが、LLMに文章を書かせていれば文章力が、LLMにコーディングさせていれば設計力や実装力が失われていくのは自明のことだろう。

果たしてこれはいいことなのかどうかというのはとても思う。たぶんLLMに漬かりすぎていると早期にボケるのではなかろうか?

登山中に電波が届かない環境や、会議のファシリテートなどで「LLMを使わないとわからない」なんてことは言いたくないものである。山の中は電波が届かないし、悠長にやっていてはバッテリーがなくなり、日が暮れる。ファシリテーターが一々LLMに聞いていては会議が進まない。

またLLMの技術を使ったブラウザ操作や、ECサイトでの買い物なども出てきており、この辺りでは意思決定の一部さえLLMに委ねており、人としてそれでいいのかとも思ってしまう。何も考えられなくなりそうだし、人としての意思とかは残るんだろうとか。

2024年12月20日には兵庫丼に次のことを書いていたが、まぁこんなのは今となってはもうどこでも起きていそうである。

「AIが提案したので実装しました。なんで動くのかは知りません」
「AIの提案なら大丈夫でしょう!レビュー通過です」
みたいなやり取りは全国でどのくらい起きてるのだろう

2024年12月17日にも兵庫丼に次のことを書いていた

人類そのうちAIに質問して出てきた返事のとおりにしか行動できなくなるのではないかみたいな心配をしてしまいがち

LLMプロバイダに生殺与奪の権利を握られる

AnthropicなどのLLMプロバイダは規約違反した人物をBANすることで有名だ。実際に私もAnthropicをBANされている

BANされると使えなくなるのでBANされないように忖度が始まるが、使わなければこんなことは気にしなくても済む。まぁ忖度したところで企業レベルでBANされてる話も聞くし、そもそも夜職に関わる開発など、BANされるような産業だとどうしようもなさそうだが…。

他にもおむつメーカーがパッケージを見せたところ児童ポルノ判定されたという話もみたことがあるので、何とも難しいことだと思う。LLMはなんにでも使えるわけではないのだ。

LLMは本当のことを言えない

これは何が本当のことか?という話になってくるのだが、LLMは本当のことを言えない。それに対して人間ならそれを言えるという話だ。

では何が本当のことか?だが、人間は生きている間ずっと、連続して何かを経験している。そして経験したことを、自分の言葉として言える。一方LLMは、膨大なテキストを流し込まれているだけだ。知識カットオフ以降のことやRAGで与えられた情報も語れるが、それらも結局は外から与えられたものにすぎない。つまりLLMが発することは、全て他人の又聞きでしかない。要するにLLMの言葉は「隣の田中さんがそう言っていた」と言う噂話を膨大に集めて確率的に確かにした話ということになる。

私は本当のこととは実体験に基づく、その人物だけが言えることだと考えている。「私はこれを見た」「私はこう感じた」、そういった実体験に基づく知識は人間にしかない。例えば昔事故を引き起こした振る舞いを知っていれば、それを止めることができる。いわゆる筋の悪さを語れるという話だ。しかし、LLMにはこの経験そのものが存在しない。だからLLMは、世界についての情報をいくら正確に語れても、「私が経験した」という意味での本当のことを、ただの一つも言えない。

もちろん、その経験が実際に役立つとは限らない。人間の側の知識が間違っていたり、古すぎたり、今回のケースとは違ったりして、役に立たないこともあるだろう。それ故にLLMのほうが正確な情報を出すことも少なくない。

しかし、LLMの情報がどれほど正確でも、LLMの言葉は誰のものでもない又聞きのままだ。そして人間の言葉には、たとえ間違っていても、その人が実際に経験したという、唯一無二の価値があると考える。

そう考えると人間はLLMの又聞きを聞いて頷いているだけではなく、独自の知見を求めるのがより大切なのかもしれない。他の誰も知りえない、そんな自分だけの体験を得ることができれば、何かになるのかもしれない。

LLMは日々成長しない

人間は基本日々成長したり劣化したりするけど、AIにはそれがない気がする。AIは学習したことをミックスして吐き出すことしかできないので思いつきや閃きと言ったイノベーションは起こせないと思う。

いやまぁ遺伝的アルゴリズムみたいなことすればできなくはないと思うけど、AIは人間に比べると個体数が少ないし多様性にも限度があると思うし、どうしてもどこかに収束していきそうだ。

ということを2023年12月12日に兵庫丼に書いていたので、こちらにも転記しておく。

LLMと話してると疲れる

壁打ちなどでLLMを使うことはよくあると思うし、だる絡みだっていくらでもできるが、割と虚無な話になって時間だけが経ち、無意味な会話になっていて可処分時間がつぶれて疲れただけというのは経験として割とよくあった。

回答に対しても一貫性がなく、生成するごとに違う回答をしてくるので疲れるみたいなところもある。

また基本的にスレッドを分けると過去の記憶は残らないので、以前の話はなかったものとして進むとかもあり、なんと言うか友人とかと思って接していると疲れる気がしている。

これはSNS疲れによく似たLLM疲れについてで幾らか書いているほか、個人的に思うLLMの活用方法についてにもある程度通じることを書いている。

LLMは理想を完全には作ってくれない

自分が作りたいものを100%形作ることにはLLMにはできない。人によっては気に食わず直すこともよくあるだろう。

これは単純な話で、部下にこれを作れと命じたところで微妙に違うものが出てくるのと同じことである。本当に解像度100%で自分が欲しいものを作りたい、こだわりや矜持を持ちたいなら、それは自分で作るしかなく、LLMに作らせる時点でそこに妥協が生まれるのだ。

あとがき

LLMそのものは便利だが、人間の手に余りすぎるし、金はかかるし、人の思考を奪ってくる割に、熟練の人間の思考より早く動くわけでもないので、常に使えるわけでもない。それに頼りすぎると人間性が失われそうでもある。そして何よりもそこに拘りは残らない。

Value-DomainのDNSを操作するユーティリティを更新した記事のあとがきにも次のように書いたが、きっとLLMに頼りすぎず、自分で何かを成し遂げていけたらいいのだとは思う。問題は今の時代にそれがどれほど実際に可能か、みたいな話ではあると思うのだが、このままではLLMの言いなりになって、LLMの単一思考によるコモディティ化と先細りしかないようにも思うし、デジタル赤字とかも問題だと思うので…。

ボケ防止のためにはAIに頼らず、自分の手を動かすのも大切なことだと思う。こういう話では、よくそろばん論を持ち出して、そろばんを使わなくなったが人類は劣化していない、電卓があるみたいなことを言う人がいるが、実際問題珠算ができる人は非常に速い速度で暗算ができ、頭の回転も速いとされているので、電卓があるから優位と言われれば、それは違うと思う。例えば電卓を取り出す時間で計算が終わっていたり、物事を予測しやすかったりするわけだ。

なんと言うかLLMを主とせず、あくまで補助的な役割で使っていければ、人の判断や軸が残るので、良いのではないだろうか?とかは少し思った。

2026/06/01(月)フレッツ光クロスでフルポート使えるIPv4が取れるか調べた

フレッツ光クロスとフレッツ光ネクスト隼のコスト比較をしてみたの続きのような記事。

結論から言うと、現実的は難しい。金があれば取れる。

フレッツ光クロス x OCNでの対応状況

取り敢えず私はOCNユーザーなので、まずはOCNの対応状況から調べてみることにした。

OCN IPv6インターネット接続|光回線 | OCNお客さまサポートによると次のようにあり、使えないことが分かった。

(OCN 光 with フレッツ クロス / OCN インターネット 10ギガはPPPoE接続できません。)

またOCNサポートに問い合わせたところ、OCNインターネット10ギガはIPoEのみ対応で、方式はMAP-E、OCNバーチャルコネクトとのことだった。そしてPPPoEは使えず、方式上フルポート使えるIPv4の提供はないと言う話だった。

兵庫県下におけるフレッツ光クロスで従来型IPv4の提供があるISPについて

フレッツ光 対応プロバイダー検索|NTT西日本公式に一覧があるが、対応しているのはIIJのみ。

IIJ IPv6 FiberAccess/F サービス タイプIPoEであればIPv4アドレスの固定割り当てが取れるそうだが、月額14,000円~ということで、到底支払える値段ではない。

IIJのフレッツ光ネクストはIPv6 IPoE、動的IPv4アドレスの場合は2,200円とのことなので、恐らくフレッツ光クロスにするとIPv4が高くなるのだと思う。

あとがき

今回の調査では、前段に外部のリバースプロキシやそれに類するものを置かず自宅サーバーを運用する場合にIPv4を切る必要が出てくることが判明した。

前回の調査ではフレッツ光クロスにすると年3万円コスト増になることが分かっているため、これと合わせるとクロスに移行する場合、年3万の負担増とIPv4でのサーバーサービスを終了しないとならないことが分かった。

中々悩ましい結果だが、回線が逼迫しているわけではないので、OpenWrtのメトリクスなどをもっとちゃんととって、必要が出たあたりで移行できたらいいなとは思う。今でも偶に不審な速度になることはあるので、それの裏が取れたら移行してもいいだろうとは思った。

2026/06/01(月)自鯖を別OSにマイグレーションするかどうか問題

投稿日:

最近自鯖を別環境に移行するかどうかについて少し考えている。

現在はUbuntuで運用しており、記憶が確かならUbuntu 16.04 LTSから24.04 LTSまで使ってきているが、幾つかの問題を感じている。別にクリティカルでも何でもないので、やる必要性も薄い。

移行方法についてもやや難しく、UbuntuはNVMe SSD上で動いているため、本来なら別にNVMe SSDを買ってきてそこに試験的に移行先を作り、移行が環境した時点でUbuntuのNVMe SSDと物理的にすり替えたいところだが、SSDが高騰している関係でこの手が使えず、やるとしたら空いているSATA SSDに環境を入れて、運用が軌道に乗りそうならUbuntuを消し飛ばすしかなくなる。つまり戻せないか、戻す場合はUbuntuの入っているNVMe SSDをddでどっかにバックアップしてやる必要がある。凄いめんどい。

ひとまず、以下に移行したくなった好ましくない理由と、移行先について書いていく。

Ubuntuの好ましくないところ

ここに書いていることはほとんど運用面では関係ない吝嗇である。端的に言えばCanonicalの姿勢が嫌いなのである。

Ubuntuの商業主義が気に食わない

自鯖はLinuxのDesktop環境の検証も兼ねているのでUbuntu Desktopを導入しているが、何かあるとCanoninalの製品に誘導されたり、過去にはMSアカウントとの連携をお勧めしてくる画面とも出会った記憶がある。こういうところがどうも好きになれない。

私はCanonicalに金を払う気がないし、LinuxをMSアカウントや、その他何かしらのアカウントと連携させたいとも思っていない。スタンドアロンこそが正義だ。

いやまぁ、Edgeのアカウントは連携するけどさ。

Snapが気に食わない

Snapに対する私の理解としてはSnapdというデーモンの上で動くアプリケーションという感じだ。

コンテナ化されたアプリケーションがDocker見たいなやつの上で動いている。なんかリソース食いそうだしキモイ。ネイティブアプリケーションはバイナリでそのまま動いてほしい。

噂ではFirefoxはaptでインストールしてもSnapdの上で動くらしい。これはWikipediaにも載ってるほど有名な話だ。何故snapdを使ってないのにそうなるのか?キモすぎる。

私は仮想化に対しては余り良いイメージがない。何故なら仮想環境分のオーバーヘッドを含み、無駄にストレージやメモリを食うこと、ホスト環境とゲスト環境の差異により問題が発生した時の特定が困難なことがある。

明示的に触れるDockerやVMならまだしもSnapdは一般向けで普通カスタマイズしない気もするし、そもそもカスタマイズが必要になるとしたらバカバカしい。なんでFirefox動かすのにそんな設定しないといけないのか?

動作が不安定

インストール直後にapt upgradeを叩くとリポジトリが死んでることがある。これは非常に嫌だ。

なんで公式でキッティングされてるリポジトリが死んでるのか?本当に営利企業がやってるのか?と思う。

他にもノートPCに入れてると蓋を閉じて開きなおしたときにキーボード入力が効かなくなり、一切何も操作できなくなることもあった。これは大分困る。

基本的にUbuntuのDesktop環境は不安定で、よくフリーズやクラッシュすると思う。それでもUbuntu 8.04 LTS辺りのころよりは安定したとは思うが…。

26でのinit.d切り捨て発表

init.dを捨てろという話なのだが、移行がだるい。

Ubuntuの好ましいところ

一方で、Ubuntuにもいいところはある。

広く普及しておりノウハウが豊富

人気のディストリのため、情報が多いのは強みかもしれない。

パッケージリポジトリも多く、基本的にUbuntu対応は多いと思う。

メジャーアップデートが容易

コマンド一個叩けばアップデートできるのは便利だ。設定の移行も手伝ってくれる。

特に何もしなくても大抵のハードウェアが動く

5種類くらいのデバイスに突っ込んだり、NICを増設したり、色々してきたが、今のところドライバを入れるとか何か対応したことはない。楽である。

現在検討している移行先

取り敢えずそんなこんなで移行先を探すことにした。

Debian

人生で最も最初に触ったディストリ。保守的で質実剛健という話を聞くやつ。

得られそうな利点
  • Canonicalの商業主義から解放される
  • Ubuntuより安定している可能性がある
    • Debianは徹底的なテストを経てリリースされているそうなので
懸念点
通信速度が異常に遅かった

懸念点としては何故か通信速度が異常に遅かった点だ。Live installerでiperf3で計測したところ、なんか異常に遅かった。これでは使い物にならない。原因は調べていないがNICは10000Mbpsでリンクアップしていたので、NICより手前で何かが起きていた可能性がある。

以下はDebian 13.5.0のLive installer上で計測した値だ。

Windows -> Debian

Interval Transfer Bitrate Retr Cwnd
0.00-1.00 sec 39.0 MBytes 327 Mbits/sec 1 247 KBytes
1.00-2.00 sec 40.9 MBytes 343 Mbits/sec 3 214 KBytes
2.00-3.00 sec 38.2 MBytes 321 Mbits/sec 4 187 KBytes
3.00-4.00 sec 41.0 MBytes 344 Mbits/sec 3 199 KBytes
4.00-5.00 sec 38.9 MBytes 326 Mbits/sec 3 160 KBytes
5.00-6.00 sec 40.1 MBytes 337 Mbits/sec 0 298 KBytes
6.00-7.00 sec 39.9 MBytes 334 Mbits/sec 0 386 KBytes
7.00-8.00 sec 41.1 MBytes 345 Mbits/sec 2 358 KBytes
8.00-8.81 sec 32.0 MBytes 331 Mbits/sec 0 423 KBytes

Debian -> Windows

Interval Transfer Bitrate
0.00-1.00 sec 37.8 MBytes 315 Mbits/sec
1.00-2.01 sec 41.2 MBytes 342 Mbits/sec
2.01-3.01 sec 38.1 MBytes 321 Mbits/sec
3.01-4.00 sec 40.6 MBytes 344 Mbits/sec
4.00-5.01 sec 39.4 MBytes 327 Mbits/sec
5.01-6.01 sec 40.1 MBytes 339 Mbits/sec
6.01-7.00 sec 39.2 MBytes 330 Mbits/sec
7.00-8.01 sec 41.1 MBytes 342 Mbits/sec
7.00-8.01 sec 41.1 MBytes 342 Mbits/sec
移行しても旨味があまりなさそう

手間がかかるだけでCanonicalの開放以外のメリットがなさそう。

移行の手間としても全ての手順をマニュアルに書き出すかAnsibleのような構成管理ツールでやる必要があり、非常に面倒そうである。

Proxmox

仮想環境をたくさん作ってその中でアプリケーションを運用するやつ。コンテナ単位でのバックアップも取れるなど便利そうだ。

この環境に移行する場合、移行が楽というのが最大のメリットだ。一度適当な環境に仮構築しモジュールごとに移行し、移行完了したらLXCのバックアップを取り、Ubuntu環境を潰し、Proxmoxに入れ替え、バックアップを復旧して移行すればリスクも手間も最低限で済む。

またDebianで発生したNICの極端な通信速度劣化についてもProxmoxでは確認できなかった。但しUbuntuよりは遅く見えた。

懸念点
スペック的に運用できるか怪しい

例えばコンテナ単位でのリソース管理はその一つだ。例えばコンテナごとにCPUやメモリ、ストレージを割り当てるとすると、特定のコンテナが跳ねたときにリミットにかかって動作が劣化するが、ネイティブで動かしていればCPUやメモリ、ストレージは共有なので、なんかいい感じにしてくれる。限界突破しない限りOOMは起きないし、私のサーバースペックであれば普通起きない。

しかしコンテナ化して1コンテナCPU2コア、メモリ2GBとかしていればしょぼいVPSみたいになって動作が劣化しそうだし、そんな立派なスペックでもなく、現状CPU6コアのメモリ32GBなので、この割り当てだとすぐに枯渇するのは自明である。ブレードサーバーを持ったホームラボ、k8sを使った運用のようにクラスタ化された環境なら、これはうまくいきそうだが、しょっぱいスペックのマシン一台で成り立つかどうかは怪しい。

Opus 4.8は成り立つというが、この分野ではLLMの言うことを真に受けたくはない。そもそもLLMの出力なんか何言ってるかわからないけど動くからいいか!で採用するものでしかないと思っている。

運用がだるそう

例えば10個くらいLXCを上げているとして、コンテナのイメージをアップデートしますとかなると全部上げていかないといけないだろうから、これは面倒そうだ。

他にもLXC1とLXC2, LXC4に対して作業する場合、それぞれのLXCにSSHDと鍵を入れる必要があり、無駄なオーバーヘッドが出る。つまりLXCを増やし、そこの中に入る場合は台数分のSSHDが多重起動し、その数分の鍵が必要だ。まぁこれについては最悪一個にしてもいいが…。切り替えについてもnginxでリバプロしてハブを作れば上手くいくかもしれないが、そもそもそれが出来るかよくわかっていない。軽くググった感じはできるらしいが、そもそもスイッチする時どうなるのか見当もつかない。/lxc1/path/toみたいな形式になるのだろうか?

そう考えるだけで運用がだるそうである。

pct setを使えばうまくいく可能性が示唆されているが、どうやらこの方法は前述のように根本にパスを追加して、そこから分けていく考えのようだ。ユーザーやグループとかどうなるんだこれ…?Proxmox側でID揃えてくれるのかな?

あとホストのアップデートもだるそうな気がしている。

監視がだるそう

動作パフォーマンスを取ろうにもホストとゲストのどっちのCPUやメモリの使用率を取るかは悩みである。ホストには空きがあるが、ゲストには空きがなければ広げた方がいいかもしれないし、この辺りについては考えがまとまっていない。

通信速度の比較

Ubuntu 24.04.4 LTS

Windows -> Ubuntu

Interval Transfer Bitrate
0.00-1.00 sec 1.11 GBytes 9.50 Gbits/sec
1.00-2.01 sec 1.11 GBytes 9.47 Gbits/sec
2.01-3.01 sec 1.10 GBytes 9.49 Gbits/sec
3.01-4.01 sec 1.10 GBytes 9.49 Gbits/sec
4.01-5.01 sec 1.11 GBytes 9.48 Gbits/sec
5.01-6.01 sec 1.10 GBytes 9.47 Gbits/sec
6.01-6.57 sec 628 MBytes 9.50 Gbits/sec

Ubuntu -> Windows

Interval Transfer Bitrate
0.00-1.01 sec 1.11 GBytes 9.40 Gbits/sec
1.01-2.00 sec 1.09 GBytes 9.42 Gbits/sec
2.00-3.01 sec 1.10 GBytes 9.40 Gbits/sec
3.01-4.01 sec 1.10 GBytes 9.39 Gbits/sec
3.01-4.01 sec 1.10 GBytes 9.39 Gbits/sec

Debian 13.5.0のLive installer上での計測

以下の計測値は全てクライアント側で取得したもの。Windows側にCwndが出ているので表が逆かもしれない(Proxmoxではクライアント側にCwndが出ていたため)

Windows -> Debian

Interval Transfer Bitrate Retr Cwnd
0.00-1.00 sec 39.0 MBytes 327 Mbits/sec 1 247 KBytes
1.00-2.00 sec 40.9 MBytes 343 Mbits/sec 3 214 KBytes
2.00-3.00 sec 38.2 MBytes 321 Mbits/sec 4 187 KBytes
3.00-4.00 sec 41.0 MBytes 344 Mbits/sec 3 199 KBytes
4.00-5.00 sec 38.9 MBytes 326 Mbits/sec 3 160 KBytes
5.00-6.00 sec 40.1 MBytes 337 Mbits/sec 0 298 KBytes
6.00-7.00 sec 39.9 MBytes 334 Mbits/sec 0 386 KBytes
7.00-8.00 sec 41.1 MBytes 345 Mbits/sec 2 358 KBytes
8.00-8.81 sec 32.0 MBytes 331 Mbits/sec 0 423 KBytes

Debian -> Windows

Interval Transfer Bitrate
0.00-1.00 sec 37.8 MBytes 315 Mbits/sec
1.00-2.01 sec 41.2 MBytes 342 Mbits/sec
2.01-3.01 sec 38.1 MBytes 321 Mbits/sec
3.01-4.00 sec 40.6 MBytes 344 Mbits/sec
4.00-5.01 sec 39.4 MBytes 327 Mbits/sec
5.01-6.01 sec 40.1 MBytes 339 Mbits/sec
6.01-7.00 sec 39.2 MBytes 330 Mbits/sec
7.00-8.01 sec 41.1 MBytes 342 Mbits/sec
7.00-8.01 sec 41.1 MBytes 342 Mbits/sec

Proxmox VE 9.2-1

以下の計測値は全てWindows上で取得したもので、Proxmox->Windows側はProxmox側のログの値ではない(転記が面倒だったためWindows側の値を取っている)

Windows -> Proxmox

Interval Transfer Bitrate
0.00-1.01 sec 1.07 GBytes 9.13 Gbits/sec
1.01-2.01 sec 1.07 GBytes 9.26 Gbits/sec
2.01-3.01 sec 1.07 GBytes 9.25 Gbits/sec
3.01-4.01 sec 1.09 GBytes 9.28 Gbits/sec
4.01-5.01 sec 1.06 GBytes 9.16 Gbits/sec
5.01-6.00 sec 1.02 GBytes 8.78 Gbits/sec
6.00-7.00 sec 1.07 GBytes 9.23 Gbits/sec
7.00-7.88 sec 948 MBytes 9.03 Gbits/sec

Proxmox -> Windows

Proxmox側(クライアント)にはCwndが出ていたが、Windows側(サーバー)の値を取っているため、その情報が欠落している。

Interval Transfer Bitrate
0.00-1.00 sec 1.08 GBytes 9.26 Gbits/sec
1.00-2.01 sec 1.09 GBytes 9.27 Gbits/sec
2.01-3.01 sec 1.08 GBytes 9.28 Gbits/sec
3.01-4.00 sec 1.08 GBytes 9.29 Gbits/sec
4.00-5.00 sec 1.08 GBytes 9.29 Gbits/sec
5.00-6.00 sec 1.08 GBytes 9.28 Gbits/sec
6.00-7.00 sec 1.08 GBytes 9.27 Gbits/sec
7.00-8.01 sec 1.09 GBytes 9.29 Gbits/sec
8.01-9.00 sec 1.07 GBytes 9.28 Gbits/sec
9.00-10.00 sec 1.08 GBytes 9.29 Gbits/sec

あとがき

Proxmoxで運用の支障がなければ環境分離の観点から移行できるとよさそうだが、メンテナンスのだるさを考えた時にどうかというのでぐるぐるしている。

かといって今のUbuntuを拡張すればするほど移行が手間になってくるので、悩ましい。しかし単一ホストで全部運用するのは間違いなく楽だしなぁ…。

取り敢えずDebianに移行する旨味は余りなさそうだし、これはしなくていいかと思った。

Proxmoxはやってみないとわからない部分もあるのでUbuntu環境のバックアップを入念に取ったうえでやるかもしれないが、問題はUbuntuをバックアップするストレージをどうするか…。

そもそも現時点でやる意義も怪しいので、今はやらない方に倒し、必要が出たときにやるのも一つではある。やりたくなった時にはそれはもう地獄が待っているかもしれないが、それ以前に私はやりたいことが無数にあるのだ。

今回は検証ができたという意味では一つ成果だと思うし、一旦ここで留めておこう。