2026年2月2日月曜日

CRYMACHINA:クライマキナで原始疑似完全数の式を学んだ話

原始疑似完全数の式のお話

クライマキナというゲームには5桁のアドレスを入力することで入れるエリアがある。
メインストーリーとは関係ないため、クリア後に行う事になった。

入力アドレスはそれぞれ規則性があり総当たりする必要はない。
今回はそのうちの一つの条件にあった原始疑似完全数のお話です。

ちなみに今から書くことはアドレス解析ページ(クライマキナ完全アドレス一覧)で既に書いたことなので目新しい内容は無いです。

約数とは?

約数とは? ある整数を割り切ることができる(割った余りが0になる)整数のことです。 例えば「6」なら, 1, 2, 3, 6 で割り切れるので, これらが約数です。

完全数とは?

完全数は「その数自身を除く約数をすべて足すと、元の数と等しくなる数」です。

完全数6の場合
「6÷1、6÷2、6÷3、6÷6」これら全て余りが0。つまりこれらが約数。
約数=「1, 2, 3, 6」正し自身の数を含めないので利用数約数は「1, 2, 3」です。
この出てきた数を全て足すと「1+2+3=6」となります。
この様に数値の約数を全て足すと元の数字になるものを完全数と言います。

約数 結果
6 1, 2, 3 1 + 2 + 3 = 6 完全数
28 1, 2, 4, 7, 14 1 + 2 + 4 + 7 + 14 = 28 完全数
496 1, 2, 4, 8, 16, 31, 62, 124, 248 1 + 2 + 4 + 8 + 16 + 31 + 62 + 124 + 248 = 496 完全数

疑似完全数とは?

次に、疑似完全数についてです。 完全数の条件を少しだけ「ゆるく」したのがこれです。

完全数は、自分以外の約数を「全部」足さなければなりませんでした。対して疑似完全数は、「自分以外の約数の中から、いくつか(一部でも全部でも可)を選んで足したとき、元の数と等しくなる数」を指します。

12
12の約数:1, 2, 3, 4, 6, 12

自分以外を全部足すと 1+2+3+4+6 = 16 となり、12を超えてしまいます。

しかし、ここから 2, 4, 6 だけを選んで足すと、合計は 12 になります。
このように「約数から好きな数字を選んで足し算して元の数が再現できる」のが疑似完全数です。

原始疑似完全数とは?

本題前の本題です(混乱)。
疑似完全数の中には、少し「ズルい」やつがいます。例えば「6」が完全数(=疑似完全数)だと分かれば、その倍数の「12」や「18」も、約数の中に「6を作るセット」を自動的に持ってしまうため、当然のように疑似完全数になります。

これでは面白くない、ということで定義されたのが原始疑似完全数です。

原始疑似完全数とは、「疑似完全数であり、かつ、その約数の中に疑似完全数を一つも持たない数」のことです。
つまり、「他の疑似完全数の力を借りずに、自力で初めて疑似完全数になった最小単位の数」と言い換えられます。

  • 6 は原始疑似完全数です(約数 1, 2, 3 の中に疑似完全数がないから)。
  • 20 も原始疑似完全数です(約数 1, 2, 4, 5, 10 の中に、一部を足して自分になる数は 20 以外にありません)。
  • 12 は疑似完全数ですが、原始ではありません。なぜなら、約数の中に 6(疑似完全数)が含まれているからです。

n∈PPS⇔n pseudoperfect ∧∀d|n (1<d<n⇒d∉PP)

さて、完全な本題である原始疑似完全数の数式です。これが既に読める人はここで解散してください。今回はこれを説明するために記事を作っただけです。
まぁ一般人がゲームやる為にこんな記号見せられても分かるはずもないだろうというのが正直なところだと思います。順番に行きましょう。

n∈PPS⇔

・「n」は指定した数字
・「∈」は同じって事です。正確にはそれに含まれるという意味。
・「PPS」は原始疑似完全数

つまりnが原始疑似完全数に含まれる。という説明です。まぁ言葉で読む分には「n=原始疑似完全数」こういう事です。

・「⇔」これの左右が同じ事を表します。
つまり「n=原始疑似完全数」⇔(原始疑似完全数の条件)
nが原始疑似完全数になる条件は=「n pseudoperfect ∧∀d|n (1<d<n⇒d∉PP)」
こういう事です。という事は「⇔」の右側が読み解ければ原始疑似完全数が何なのかわかるって事です。

n∈PPS⇔n pseudoperfect∧

・「n pseudoperfect」はnとして使う値は疑似完全数
つまり「原始疑似完全数=疑似完全数」

これは事前に説明してる通り、疑似完全数というカテゴリの中に原始疑似完全数が存在する為です。

・「∧」はandです。なおかつって事ですね。
原始疑似完全数=nが疑似完全数かつ(原始疑似完全数の条件)
これによって確認すべき条件がより右にスライドしました。

∀d|n (1<d<n⇒d∉PP)

やっと事実上の条件の肝となる部分に到達しました。
・「∀」はforAll、全てのという意味
・「d|n」はdでnを割り切る=「n÷dの余りが0」
・「∀d|n」
こうなった場合はnに総当たりで1~nの間で割り算するって事ですね。条件が割り切る=余りが0になる=約数が取得出来るという事です。
nを割り切れた値が全て=約数群d

d = [a for a in range(1, n + 1) if n % a == 0]

約数一覧がGET出来たので約数が何だったら原始疑似完全数なのかという話になります。という事は
原始疑似完全数=nが疑似完全数かつnの約数が…(原始疑似完全数の条件)
ここまで来ました。

∀d|n (1<d<n

この先の条件はただの不等号です。
・「1<d<n」dが1より大きく、nより小さい
「1<d」なのは約数1はどの数値であっても割り切れるため条件から除外される。
「d<n」は自分より小さいものだけを対象とする

これを全てのdに対して行うで

d = [a for a in range(2, n) if n % a == 0]

1を除外し、自身も含めない。

(1<d<n⇒d∉PP)

・「⇒」もしそうだったら
・「d∉PP」d∉PP. dが疑似完全数ではない。
つまり「約数群全てが過去に出た疑似完全数を含むことがない」って事ですね

n∈PPS⇔n pseudoperfect ∧∀d|n (1<d<n⇒d∉PP)

最後に全部を通しで見てみましょう
「原始疑似完全数はnが疑似完全数かつnの約数全てが自身より小さい疑似完全数を含まない」

これでやっと式の内容が全て解読できましたね。お疲れ様でしたー。

追記「1<」は無くていい。
n PP∧∀d|n (d<n⇒d∉PP)
後から見たらそもそもnは疑似完全数という前提なんだから1が含まれていない。 つまり、1より大きいと書く必要はなくて単純に約数dがnより小さければOKですね。

2026年1月28日水曜日

Webデザインの歴史をまとめてみる

今回はウェブデザインを纏めてみるお話。phpやリアクトなど動的な技術的は一旦置いておいて原始的なタグの推移のお話。

ウェブページデザインの歴史(主なタグ・技術の変遷)

時期 主なレイアウト/デザイン手法 使われていた主なタグ・技術 特徴・問題点・背景 代表的な見た目例
1991〜1995年 ほぼ純粋な文書構造 <h1>〜<h6>, <p>, <br>, <hr>, <a>, <ul>, <pre> デザインという概念がほぼ存在しない。ブラウザのデフォルト表示に頼る 白背景+黒文字、青いリンク、文字ばかり
1993〜1998年頃 画像+テーブルレイアウトの夜明け <img>, <table>, <tr>, <td>, bgcolor, background, <font> Netscapeの<center>, <font color>, sizeなどが乱発。テーブルで無理やりレイアウト 派手な背景GIF、Under Constructionアイコン、カウンター
1998〜2004年頃 テーブルレイアウト全盛期 <table>, <tr>, <td>, 入れ子テーブル、spacer.gif 最も汚いHTMLが量産された時代。メンテナンス性最悪。CSS1は存在するが普及せず 3Dボタン、ドロップシャドウGIF、フレームサイト
2004〜2010年頃 CSSレイアウト移行期(table → float) <div>, float:left/right, margin, padding, position CSS Zen Gardenで一気に認知。tableレイアウトは「悪」とされるようになる Web 2.0(丸角、グラデーション、ドロップシャドウ)
2007〜2012年頃 スキューモーフィズム+擬似CSS3 CSS3(border-radius, box-shadow, gradient, text-shadow) iPhone登場後、リアル質感が流行。Flash衰退の始まり リアルなレザー、ステッチ、金属質感、グラデボタン
2010〜2015年頃 レスポンシブデザインの確立 @media クエリ, max-width, flexible images, fluid grid Ethan Marcotteの「Responsive Web Design」論文(2010)が決定打 スマホ対応で崩れないレイアウトが必須に
2013〜2018年頃 フラットデザイン全盛期 flexbox (display:flex), フラット色、アイコンSVG iOS7でスキューモーフィズム終了宣言。ミニマリズム+大胆な色 ドロップシャドウほぼ消滅、フラット2.0(微妙な影)
2014〜現在 グリッドレイアウトの本格普及 display: grid, grid-template-columns, gap 2017年頃から主要ブラウザが一斉対応。float卒業の最終兵器 複雑なカード配置、マガジン風レイアウトが容易に
2017〜現在 CSS変数、カスタムプロパティ、コンテナクエリ --変数名, calc(), @container テーマ切り替え、ダークモードが劇的に楽に。設計思想が大きく変わる デザインシステム対応が容易に
2020〜現在 ニューモーフィズム / Glassmorphism / 3D風 backdrop-filter: blur(), filter: drop-shadow(), 3D変形 ミニマリズムの飽き+立体感回帰。GPUアクセラレーション前提 フロストガラス、ソフトUI、微妙な奥行き表現
2022〜2026現在 変数・論理演算・scroll-driven animation @property, color-mix(), animation-timeline: scroll() ほぼJavaScript無しで複雑なアニメ・配色・レイアウトが可能に スクロールで動く高度な演出、AI生成背景など

結局は「格子」へ回帰:ウェブデザインの螺旋進化

歴史は繰り返すとはよく言ったもので、ウェブの歴史を俯瞰すると画面を「情報の格子(グリッド)」として整理するのが、人間にとって最も直感的だという結論に、何度も戻ってきている。 初期の<table>乱用から始まり、floatの混沌、Flexboxの柔軟性、そしてCSS Gridの完成形へ——不自由を解消しながら、結局「2次元の骨組み」が最適解だったという皮肉な軌跡になっている。

1. 「脱テーブル」運動と、制御の難しいfloat時代

2000年代前半、<table>によるレイアウトは「構造を破壊する悪」とされ、CSS floatへの移行が強く推奨されました。
つまり、タグはそのタグ名の意味に合わせて正しく使おうというだけの話です。
tableはデータ一覧など表を作るものであってデザインに使うのは正しくないとシンプルな理由ですね。
次に注目されたのはfloatで、floatは自動折り返しが可能で理論上優れていましたが、現実は「浮遊」の名にふさわしく扱いが難しかった。

floatの致命的な落とし穴

要素を「浮かせる」性質上、後続コンテンツが下に潜り込みやすく、崩壊を防ぐためのclearfixハック(空divや::after偽要素)が必須に。1つ忘れただけでページ全体が崩れる——当時の開発者の悪夢だった。

2. スマホ革命と、Flex → Gridへのスムーズ移行

2007年のiPhone登場で「m.ドメイン」の二重管理が限界を迎え、2010年にレスポンシブデザインが提唱されます。
現代の人には分からないと思いますが「m.ドメイン」というのはガラケーなどのかなり小さな画面向けに1つのサイトに対してPC用と携帯用の実質2つサイト作っていたのです。
スマホが普及するにつれ、ある程度画面幅が確保された事で、1つのサイトが幅によって自動でコンテンツ表示を調整する方が良いという考えに至ったという事です。
この画面幅によって自動的に最適化しようというのがレスポンシブデザインです。

float自体はコンテンツを自動改行でき、レスポンシブとも相性が良かったのである程度続きますがデザイン方法が直感的ではないため苦しめられた人も多かったと思います。
Flexbox(2012年頃本格普及)はfloatの不安定さを解消し、方向性の並べ替えを簡単に実現できました。
ただ、Flexは1次元でのデザインとなるので少し機能面不足があり続けて作られたのがGridという概念です。
ただ、出始めは一部ブラウザが対応してないなどで利用が限られました。

いやまぁ、大抵のタグ問題はIEが最新のタグに対応出来ないという問題が多かったと思います。
そして、根幹的な最大の問題はWindowsのデフォルトブラウザだったせいで切り捨てるの難しかったという側面も大きい。

そして2017年以降、CSS Gridの主要ブラウザ完全対応により、2次元レイアウトが本格的に可能に。
floatやclearfixのような「回避策」はほぼ不要となり、2026年現在、レイアウト目的のfloatは絶滅危惧種と言えます。

3. 最大の皮肉:本物の表データでさえ<table>を避ける現代

Gridが成熟した今、面白い逆転が起きている。
かつて「脱テーブル」を叫んだ私たちが、今度は「本当に表形式のデータすら、<table>を使わずdiv+Gridで作りたがる」という矛盾を抱えている。
Tableタグは柔軟性が低くそのままではレスポンシブでもはみ出やすい。
例えば、幅を単に100%にすると幅に収まるが表が超縦長になる。
なので、Tableはdivで囲んでoverflowとセット、角を丸める等にしてもdivで囲んだ方良い。
ただ、それなら最初からdivで表にしようと思うのは自然な考えだと思います。

なんならリストだったり、ボタンも意味タグを使うよりも柔軟にできるdivを使う場合もあると思います。
こうなってしまうと全てがdivでclassを見なければ何を意味するのが構造が理解しにくい。
個人的には意味タグを優先して使うがWebツールなどの場合はどうしてもdivで代替する事はやはりある。

なぜdiv+Gridを選ぶのか

React/Vueなどのコンポーネント駆動開発では、<table>の厳格な親子構造よりdivの方が柔軟。レスポンシブで「列をカードに変形」「仮想スクロール」「ソート・フィルタUIのカスタム」が容易だからだ。TanStack Tableなどのライブラリも、内部でdivベース+ARIAを駆使している。

アクセシビリティの再来する代償

見た目は表でも、divの塊ではスクリーンリーダーに「行・列の関係」が伝わりにくい。かつてのtableレイアウトと同じく、意味の欠落が起きている。2026年現在、WCAGも「真の表データは<table>を推奨」と再確認しつつ、開発現場では「利便性>セマンティクス」のトレードオフが続いている。


デザインは歴史を繰り返しながら少しずつ上に

意味の違う「箱(table)」→扱いの難しい「浮遊(float)」→デバイス分断の時代を経て、ウェブは再び「進化した格子(Grid)」に戻ってきた。
 Flexboxでfloatは減り、Gridでfloatはほぼ消滅。過去の不便を解消しながら、「情報の2次元整理」という本質だけは変わらず残る。

2026年の今、Subgridやmasonryレイアウト、container queriesが加わり、Gridはさらに脳に優しいツールへ進化中。結局、人間は「視覚的な格子」を愛している——歴史は螺旋状に、しかし確実に上へ進んでいる。

2026年1月21日水曜日

クライマキナは戦闘以外は素晴らしい

クライマキナ

https://www.cs.furyu.jp/crymachina/

機械の少女が「本物の人間」になる為の物語。
PS4、PS5、switchで発売。

良い所

戦闘以外はとても良いゲームだと思います。
戦闘以外ははなまる

第八神機エノア

機械の少女。とても可愛い。
めちゃくちゃ褒めてくれる。超癒し。天使。すけこま神機

ストーリー

最初の目標から土台をひっくり返さえたりと話も面白い。
マテリアルの資料、人格データ回想録などを見るのも楽しい。

百合

エリア攻略パート以外にコミュニケーションとしてお茶会があってガールズトークが楽しめる。根本的にゲーム全体的がゆりゆりしていてとても良い。
登場人物は一部敵を除けば女性しかいない。

ビジュアル

キャラクターデザインも世界観などもとても良い
背景もとても広大で良かったです。
また、声優陣も豪華で良き。
キービジュアルなども良いし、3Dのキャラクターや背景も良くできています。

カメラモード

一般の人がどれくらい必要としてるか分からないけど個人的にはカメラモードがあるゲームが好き
先に述べた通り背景も良く出来ているのでぐりぐりと見渡せるのがとても良い。
アサクリオデッセイとかと同じくR3+L3(アナログスティック両押し)でカメラモードです。

音楽

全体的には透き通った曲が多くどれも良い。
マテリアルの音楽鑑賞で流れた曲が確認できる所もグッド!

戦闘のシステム基盤

戦闘が良くないと後で説明するものの面白くなる要素自体は持っていて
ダッシュ、ジャスト回避、パリィ、通常攻撃、打ち上げ攻撃、打ち上げた敵を空中で連続攻撃、空中からの叩きつけ攻撃、フィニッシュ攻撃。
戦闘支援→支援攻撃、回復、覚醒
武器、眷属のカスタマイズ性。キャラの強化にカスタマイズ性。
戦闘の基盤になるシステム自体は揃ってる気がする。素材は良いんですよ。

ロードが早い

PS4版ですがロード時間を感じる所が無かったです。
普段やってるアサクリシリーズとかだと十秒以上待つこともあるので。まぁ、比較対象が重いだけかもですが…。

格下にめっちゃ強い

良い点というか、このあと色々説明するものの相手よりLvが上がれば倒せるようになるから安心してねという話
特に寄り道のギミックを解いてエリア移動する敵は完全に無視して良いです。
・・・まぁ、メインイベント進行のエリアはLvキャップで同等Lvが限度なのでキツイ事には変わりないけどね…。
レベル差がこちらが上なら覚醒をして攻撃連打でほぼどの敵にも勝てます。

クリア後はLv差が絶対正義

サブネットワーク周りは全てクリア後推奨です。
レベル有利に格差が超強く出るのでクリア後Lvキャップが129になってからの方が楽です。
本編はキャップでかつかつの戦闘ですがクリア後は格下を蹂躙する事が可能。□連打だけでいいです。
ちなみに、トロフィー対象の第二神機は極が付いてない方で、なおかつ戦闘開始で取得となります。

極じゃない第二神機はLv129になれば覚醒して殴るだけで勝てます。
逆に極第二神機は遥か格上となる為戦闘システムがひどいのもあって勝つのが難しいです。

補足:E×PとLvについて

レベルは気にせず上げてください。

サイトの情報が古い所だとEXPが1になるのでレベルの低いキャラを確保しておく必要があると説明してる所がありますがそれらは古い情報です。
Ver1.0.8「https://www.cs.furyu.jp/crymachina/news/565/


自身でも検証して、Lv129とLv80で同じエリアを探索した時にLv129のEXPがだいたい4000前後で、Lv80はだいたい6000前後でした。
多少は差がありますが、先ほど説明した通りLv有利がかなり顕著にでます。
なので、適正で苦戦するよりもLvで蹂躙した方が時間効率が良くなります。

良くない所

正直良くない所は戦闘だけです。
それ以外は素晴らしいです。

戦闘システムが粗削りと言えば優しい方で作りが雑。
逆にあえて難易度を上げるためにユーザーを操作難にしてるんだったら難易度の上げ方が間違っていると思うのよね・・・。

「戦闘システムを構成する要素」自体は良さそうなのにどうしてこんなに酷い形に組みあがったのか逆に謎である。

ピーキーな戦闘

基本的には敵も味方も攻撃力が高めです。
とは言え圧倒的に不利なのはこちらで、2・3発で死亡。
下手したら一発で死ぬ時もある。
ボス敵のHPも削れやすいとはいえ、相手は数発で倒せるなんて事は無い。
しかも、ボスだけというわけではなく雑魚敵すらワンパンでこちらがやられる時がある。
面倒臭いのは雑魚敵に負けるとステージ最初のムービーから始まる所でスキップは出来るもののそれでもだいぶ面倒臭い。
雑魚は複数同時に出るため、単純にパリィやジャスト回避してても横やりで簡単に事故死する。
複数回スタート地点に戻されるとスキップポチポチにアイテムの拾いなおしも相まってかなり地獄。

どちらもアーマー状態

アーマー状態っていうのは攻撃を受けてる側が行動制限を受けないという事です。
つまりこちらが攻撃してる最中も敵は攻撃してきます。
そして先に述べた通り数発でこちらは蒸発します。

画面が汚い

戦闘中キャラの攻撃に眷属の攻撃、更に敵も通常の攻撃と眷属も使ってくる。
超派手な爆風、超派手な斬撃、更には敵が複数の場合はさらに画面がエフェクトで埋もれる。

プレイヤー以外にはすごくきれいで派手にみえるけどこれは画面が汚いって表現の方が正しい。
見辛いじゃない見えないんだ。本当になーんにも見えない
十字の攻撃予兆が見えてもタイミングは攻撃によって違うので敵の動きが見えてなければパリィもジャスト回避も出来ない。つまり不可能。


敵の攻撃開始である十字エフェクトも良く分からなくなる。
自キャラ位置も敵の位置も見えなくなる。なんだよこれ・・・。
味方側の攻撃のエフェクトなのか敵の攻撃のエフェクトかも分かり難いため本当になんも見えない。
先に説明した通り攻撃力馬鹿デカゲームなので本当にテストプレイしたのかと疑うほどエフェクトまみれになって気が付いたらこちらHPが0なんてこともざら。
何発も攻撃に耐えられるゲームならある程度視認難でも問題になり難いがこのゲームは数発で死ぬ、下手すれば一発即死のため視認性は死活問題。

敵の攻撃カラーと味方の攻撃カラーでエフェクト分けたりしてないので、そもそもどっちの攻撃が当たってるのかすら分からないという状態になる。

回避とパリィにキャンセル受付がない

画面がごちゃごちゃしてても見えるのも当然ある。
敵の攻撃十字エフェクトを見てから回避やパリィを押すと攻撃中のモーションはキャンセルできずそのまま普通に喰らう。ピーキーな戦闘なので容易にこちらだけが溶ける。

攻撃予兆は結局目押し

攻撃予兆で光った後はどの敵も同じタイミングで攻撃が来るわけでは無い。光ってすぐ攻撃がくるものもあれば少し溜めてくるのもあるしがっつり遅いジャストタイミングもある
つまり、敵のモーション別に目押しでジャストを狙わなければならない。
所が光った十字エフェクトの後に敵キャラのモーションを見なければならいがエフェクトだらけで正直見えない。
更にシステム的に終わってるのは敵の眷属はノーモーションで攻撃してくる。
どういうことかというと敵の攻撃にジャストを狙ってる最中にダメージを喰らうしジャスト後攻撃中にもダメージを喰らう。なんでだよ・・・
しかも敵の十字をみてジャストしようにも眷属の爆風とかで視界を奪われる。なんだこれどうしろって・・・

パリィを使う理由が皆無

パリィはパリィできない攻撃があるためそのままダメージを受けてしまう事がある。
逆にジャスト回避はどの攻撃でも敵の裏に回れるのでパリィを使う理由が存在しない。
この後の動画を見ればわかるが同じ攻撃の同じタイミングでもジャスト回避は可能。

フィニッシュアサルトを使う理由がほぼない

相手がぴよったら打ち上げ、叩き落してダウン、ダウンすると締めのフィニッシュアサルトが出来る。
最初ダメージが大きいかなとちゃんと狙っていたがさして減らない。しかもこちらの攻撃ターンが終わってしまう。
そのため、延々と通常攻撃を相手がダウン回復するまで殴り続けた方が削れる。
無敵が全くないのでいつでも回避に移れる通常攻撃でいい。

フィニッシュアサルト中くらいは発生から硬直終了まで無敵であってほしかったし、ダメージももっとあって欲しかった。
フィニッシュアサルトやってそのまま死ぬの悲しい。
発動硬直中も時は止まらず容赦なく連続でダメージを喰らうのでWAKEだからといって近寄ってはならない。死ぬ。

回避方向が正しくない

ロックの有無に関わらず近くの敵と相対的にみて入力キーを判定するガバガバ判定
正面に敵がいてキャラがほんの僅かでも左右側だとアナログスティックを後ろ+回避としれても敵の横を馬鹿みたいに移動する。
本来この入力なら画面手前に回避行動すべきなのに気が狂っている。このせいで本来回避できる攻撃すら回避出来ない。
戦闘がピーキーな感じでなければ許せるかもしれないがワンミスで即死するこのゲームでは致命的。
敵とキャラクターを相対に判定する意味が分からない。いまある画面とキャラに対して入力してる方向に移動しろよ・・・という。
あとニュートラル回避は画面関係なくキャラの向いている方向となっている。ダッシュの側面もある為だがそれは方向キーで入れるべき。
ニュートラルはバックにして欲しい。

鎮守NETの関所の横ボスが最低で狭い部屋に雑魚をずっと出し続ける。
何が起きるかというと回避行動が周りの雑魚の周回を回る様に移動するせいでメインボスの攻撃が回避が出来ない。仕様として終わってると言わざるを得ない。
何をどう考えたらロックすらしてない敵の周回を回避行動させようと思うのか全く理解出来ない。

カメラアングル

戦闘でのカメラアングルが正直終わっている。
ジャスト回避で敵の後ろに回って攻撃する瞬間まではちゃんと「カメラ→自キャラ→敵」の順番で画面に収まる様に移動するのに、なぜかそこからカメラが自キャラの正面に移動してくる。
なんでぇ??????意味不明。テストプレイしてないの???
カメラの影に敵キャラが隠れて見えなくなる敵キャラがカメラ外に移動するため敵の攻撃開始エフェクトも見えない。

挙動的にはおそらくカメラが操作画面外にいるのでカメラを内側に移動してるんだと思うけど、R3でカメラ始点補正をすれば普通に画面端でもカメラは外側で問題無いんだから技術的にできないんじゃなくてただただユーザーの視野を奪うという奇抜な難易度調整・・・いやテストプレイしてないだけだと思うけど。

戦闘エリアが狭い、回避が壁で止まる

広い戦闘エリアはごく一部で雑魚戦は勿論ボスエリアも基本的に狭い。敵の眷属と同時に攻撃されると回避しきれない時もある。
更に追い打ちをかけるのが回避移動が画面端に触れるとピタッと止まる。なんで・・・。
普通は壁際を沿うように移動出来るものだがそんな事はなく壁に張り付くため無防備になる。
他にもイカレカメラアングルのせいで攻撃してから回避しようと後ろに入れて回避行動をしようとしてる時にカメラがぐるっと勝手回り敵側に回避行動が実行される。終わっている・・・。
敵にも当たり判定があって敵の目の前で止まり無防備になる。なんでだよ・・・
画面が狭いのもあり敵が下がってもこちらがフィニッシュ攻撃をしても敵が壁際に行く。これによって回避行動が正常に機能しない。

支援システムの作りが良くない

十字キーの左右で支援項目を選んで下を押して始めて支援行動が始まる。
しかもこの支援項目は常に表示しているわけでは無い。十字キーを押し、画面に表示されてから下を押さないと支援が来ない。
そしてこの間、時は止まらない。
更にひどいのは時間が少し経つとこの支援項目が非表示に戻る。消えたら表示させないといけない。とっさに支援を出せない。

つまり、事前に左右で良く使うのに選択しておいて、選択項目を記憶させても下ボタン一発で出ない。どうなってんだよ・・・誰もテストプレイしてないのか?

ユーザーの操作難度を上げて難しくするのは良くない。
単純に十字キーのそれぞれに支援項目割り当てて一発で支援が発動出来ればいいのにどうして・・・。

帰還についてはそもそもメニュー入れる必要性が皆無。これがあるせいで対象コマンドの選択が無駄に1つ通る事になる。邪魔過ぎる。
もしどうしても選択系メニューをやりたいんだったら選択中は時間停止か時間の超スローとかにすればいい。
時間も絶対止めたくないというのであれば、コマンド選択中にコマンド名を喋るでもでもいい戦闘中敵を見ながら左上を見てられない選んでるコマンドが音声で分かれば辛うじて何とかなる
十字キーを操作という事は移動のアナログスティックが操作出来ない訳で戦闘中に操作しにくいなんて事は少しテストプレイすればわかるはずなのに・・・。

眷属を操作出来ないタイミングがある

射撃攻撃中は眷属が操作出来ない。ミコトがビームを出してる間とかに眷属を射出出来ない。
L2中R1がリロードで束縛されるのは分かるが、ビーム射出中は何処も押してない。
結果的にビームを溜めてる間とビームを撃ってるあいだ眷属の操作が全く出来ない

あらゆる行動に無敵が無いしフレーム不利

ジャスト回避・パリィ・フィニッシュなど戦闘システムとしてえらい行動がいくつかある。
だがこれらに無敵が無い。
フィニッシュ攻撃中に普通に横から攻撃されて蒸発する。
ジャスト回避とパリィは受けた攻撃に対してだけダメージがないがその後はダメージがある。
他にも敵が近いと後ろ回避を入れてるのに左右回避を強制されて距離を離せずダメージくらうのも馬鹿らしい。

ミコトはジャスト回避するとスローになり一方的に攻撃出来るが無敵はない。
攻撃判定が残ってるものに触れるとそのままダメージを喰らうしスタン攻撃とかが置いてあると突っ込めばスタンする。
アミは特にひどく大振りな上にジャストを取っても1発自動攻撃保証がある以外無敵はない。スローにもならない。
唯一の良心がレーベンでスローにならないものの数秒無敵になる。差別化なんだろうけどアミだけ何も得がない。

特にアミでの戦闘ひどい

例えば首無しミコト戦でジャスト回避をすれば一発だけ反撃出来るが、ミコトが連続斬りをしていた場合、二発目以降の攻撃は回避不能。
しかもフレーム不利となっていて、連続で回避を連打してもジャスト回避は出来ない。ひどすぎる。なんでだよぉ・・・。
えらい行動をしたはずなのにこちらがダメージを受ける。意味不明過ぎる。

リリー戦もそうで、ジャストを取ってるにも関わらず乱打と敵眷属でこちらが蒸発する。納得いかなすぎる。
ジャスト回避とパリィと向き合っても戦闘が安定しない。こんなのゲームじゃない。
本当にこんな運ゲーが面白いと思ってだしたのか?結局たまたま勝てるというサイをひたすら作業として振らせられ続ける。
こうなるとただの苦痛。

タイラー戦は敵が槍で超狭いエリアで戦わされる。悪意が高い。
ジャスト回避やパリィをしても連続突きの2発目以降は回避できないため死ぬ。
アミが大振りで隙だらけというのも拍車をかける。地獄。

敵がオーバーヒートしても攻撃出来ない時がある

敵がオーバーヒートすれば敵は眷属も使えず無防備になってチャンス!
と、いう訳でもなく、敵眷属の攻撃が残っている場合は本体がぴよっていても攻撃を受けてしまう。
また、設置系の攻撃は残留し続け、主にイカみたいなボスは床設置、空中誘導弾が遅延してヒットする。
先に言った通りどの行動にも無敵が基本ないのでチャンスをつかみに行くと一緒に現れる雑魚の攻撃で死んだりもする。
敵がオーバーヒート中じゃなければ敵本体がダウンなど動けない状態でも攻撃を喰らう。
敵がダウン硬直が戻る前に敵眷属が動きだし喰らう場合もある。
「受けるダメージ>>チャンスで与えられるダメージ」と割に合わない事が割と多い。下手するとそのまま死ぬ。

進行キャラが固定されるし、Lvもキャップされている

エリア進行で使えるキャラが固定され育成したキャラを選択出来ない。
しかもキャラが固定される事で平行強化が必要になりあらゆるポイントが分散されて育成が滞る。
更に、レベルもキャップされていて進行しないと解除されない。レベルを上げて物理で殴る事も出来ない。

寄り道の強い敵

簡単なギミックを解いて戦える強い敵がいる。ちょっと強いじゃなくてバカ強い。
チュートリアルで最初に寄り道してはと言われるが確実に瞬殺される。
2・3個のエリアで寄り道に行ったところで無理だなと悟りそれ以降ギミックエリア自体を無駄だと無視する様になる。

更に最悪なのは死ぬとスタート地点に戻される初回にいくエリアだとムービーとかも入る。スキップは出来るがストレスでしかない。
ある程度強くなって戻ってきても死ぬたびに当然のようにエリア入口に戻される。ピーキーな戦闘である為対等な強さでも簡単に死ぬ。
・・・テストプレイしてないんですか?またギミックエリアをやる事になり、数度死ぬと何やらされてるんだって気持ちになる。
鎮守NET関所の寄り道ボスとか足場の乗り継ぎが上手くいかなくて戻るだけでイライラが溜まってしまう。

あと、ただの1対1ならまだしも、この戦闘エリアにビーム系のトラップがある場所は最悪で、触れたらビームの場所なんて視界が消される
悪意しかない。まともに戦わせる気が全くない。全く見えない視界から斬撃で即死とかジャストも取れないし対処のしようがない。
敵が視認できて始めてなんとか戦えるのにそれすら出来ない。

ジャンプ猶予に余白がない

アクション要素のあるゲームは大抵ジャンプ猶予に余白があるんだけどこのゲームにはない。
そのため、ジャンプボタンを押してるのに落下する事が多々ある。
後半のギミック少し長めで足を踏み外すとだいぶ面倒臭い。しかもスタートに戻された後だとなおさら。

勝利しても戦闘に納得感がない

基本死にゲーとなるが、なんどもやってるとたまたま上手くかみ合って勝てる。
だが、戦闘システムとして何故勝てたのかも再現性もない。
となると戦闘が面白く感じない. 特に複数の敵がいた時に横やりで死ななかったのは単なる運でしかない。

どう頑張ってもこの戦闘システム爽快感もカタルシスも存在しない。皆無である。

支援システムやジャスト回避、パリィなどを詰めようとするほど操作性が…戦闘システムがダメすぎるという事しか分からない・・・どうしてこうなった・・・。

戦闘が難しくても敵の攻撃パターンとか理解してパリィとかすれば普通のゲームは論理的に勝てるシステムなんだけどこのゲームにそんなものはない。

眷属を変えたり、思想を変更したり、進行毎にキャップまでレベルを上げても戦闘が安定しない。パリィやジャスト回避してもこちらがダメージを受ける事も多くここまでやって安定しない事を考えると本当にテストプレイしてないとしか思えない。

戦闘以外は面白いので戦闘もどうにか楽しめないかと試行錯誤したが煮ても焼いても無理だった。仮にもっと深い読み合いがあるとしても、ユーザー側が「かなり頑張って楽しもうとしても無理」な時点でゲーム性としては厳しい。

数少ない安定率の高い戦闘は遠距離眷属で外周をひたすら回りながら打つとかだが戦闘エリアが狭いという・・・。
他には全方位シールド両翼装備で片方を少しずらして発動しながらヒット&アウェイ。簡単に剥がれるが安定度は出る。
シールドタイプ眷属の「オールレンジバリア」は固有思想のため消費されないので安心して付け外し可能です。
ただし思想の連鎖で別のシールドを付けると上書きされるので注意。
また、パリィで取れない攻撃もあるので「オートマティックパリィ」の方は微妙かも。

ギミックビームはバリアで防げない

オールレンジバリアが便利と言ったけれどギミックビームはバリアを貫通する。
フィールドの攻略でギミックビームがシールドで防げないのはまぁ良いんだけどボス戦に置くのは無理がある。
四か所から線ビームを出してるボスエリアが最悪で、入口と出口のちょっとした隙間でしかこちらは動けない。
その上、敵はその入口と出口のエリアには基本入ろうとしない。
フィニッシュアサルトの所でも説明したが、こちらはフィニッシュ攻撃含めどの行動にも無敵が無いため溜めモーション中に溶ける。
時間制限のある覚醒以外で近寄る事すら出来ず、敵のLvが上だと当然それだけでは倒しきる事も出来ない。

戦闘が安定するのがLv80くらい

レベルキャップがLv80くらいからある程度戦闘が安定してきます。
EVEチューニング、戦闘支援プログラム強化が積まれるのも大きいですが、Lvキャップ解放が先なのでメインクエストでやっと敵より先にLvが高くなります。
また、寄り道エリアにいるボスもLv80前後だから即死せずに戦えます。
・・・ちょっと遅い。メインイベントのかなり後半です。
Lv80解放は非ネットワーク領域の開始からなので
星界観測NET→大型工廠NET→人型工廠NET→文化集積NET→深層NET→鎮守NET→エデン神髄NET→非ネットワーク領域
領域的にもう最終領域なんですよ・・・。

こちらのLvが上回れるので最後のエリアが一番楽でカジュアルにしてるなら覚醒□ボタン連打だけで全部終わります。

サブネットワーク入力が面倒臭い

サーバーファームなど資料を入手してアドレスを入力するんだけどこれは固有値で予測でも入力可能。
なので、入力式なのは構わないと思う。
ただ、ゲーム内でアドレス資料を見つけたら対象アドレスを選択式にして欲しい。
ゲーム内で資料まで移動するのが面倒臭い。
もしくはアドレス入力画面で所持資料のアドレスの表示くらいして欲しい。
まぁでも戦闘システムに比べれば些細な事なので頼むからカメラワークと戦闘支援は直して・・・

色々書いたが戦闘以外は本当に面白いのでやってみて欲しい

この戦闘のシステムが全体の面白さを台無しにしてると取るか、このイカレタ戦闘システムを他の要素でどうにか良ゲーにしてると取るかは絶妙なラインな気がする。
いや本当に戦闘がどうにか面白くならないか?どうにか楽しめるようにならないかと試行錯誤したが私には無理だった。すまない
ジャスト回避を数十回成功させて頑張って削ったのに、こちらがどうしても回避出来ないタイミングの攻撃でHPが消し飛ぶとかざらでいや流石に・・・。
カジュアルに変更してもこちらのHPが溶けるのをみてカジュアルとは・・・?ともなって、カジュアル付けるくらいならいっそ戦闘スキップボタンでいいんじゃないかな。

おかしいな、もっとこう面白かったっていう要素を並べたかったのに・・・。
前作にクライスターというゲームがあってクライマキナが面白かったので買おうかと思ってるけど、クライマキナが前作よりは操作性がましという内容をネット見かけて戦々恐々になっている。

2026年1月20日火曜日

サイトデザインを更新するぞ

サイトデザイン更新

時間があるうちにサイトのデザインを更新する事にしました。
前の状態はこんな感じ。

■Twitterウィジェット

画面中央左の空きはTwitterのツイートウィジェットです。
仕様が変わった事で見てるブラウザでログインしてない限りは表示されなくなりました
逆に言えば、仕様が変わっても𝕏にログインさえしてればツイートがちゃんと表示されるんですがブラウザにログインセッションがないとガラ空きになってしまう。
スマホアクセス時はバッサリツイート表示を消してたのでまぁそもそも別にいらないかな。

■更新履歴

内部スクロールに詰めてたけど数個だけ表示してあとはmoreで履歴ページにまとめよう。

■リンク周り

一旦整理するのに大半を除外。

■ヘッダーとフッター

遥か昔に更新が面倒なのでもともとヘッダーとフッターはjavascriptで生成して埋め込んでいました。
ですが昔のクローラーはjavascriptを全く読まないのでサイトの奥へリンクを読みにいけないためSEO的にダメという事でhtml側に書くようにした経緯があります。
メニューを更新したくなかったからメインメニューを減らしたんですよ。

現在のサイトデザイン

まぁ暫定ですが一旦更新したのがこちら


モダンとは何かが良く分からないけどまぁ色々モダンに寄り添うようには頑張ったはず。

■サイトのトップ

最近の流行りというかなんというかサイトを開いたら「ヒーローイメージ」という画像をバァンと出して、キャッチコピーなどをドカンと入れるのが主流(たぶん)。
勿論サイトの種類に寄りますが折角絵を描いてるしそれに倣う事にしました。
とは言え最近絵を描いてなかったから幅2000~3000pxの絵があまりなくて、今回はオリキャラのロロさんじゃなくて、闇玉藻をバァンと配置しました。
超いにしえのサイトが中央に「入口」みたいなリンクがあるのを彷彿とさせるというのはデザインが一周回ったという可能性がある。

■サイトの横幅

前回の横幅サイズは1000pxにしていました。
今回の横幅は1280pxです。
2025年前後で現在PCディスプレイの解像度は1920px、1536pxの幅が多いです。
マックスサイズで開く事はあまりないのでそれより狭い幅が良いかと。
指標的なものは余りありませんがTailwind CSSのコンテナ幅で2xlが1536px、xlが1280pxという感じなので広げ過ぎても情報が横に伸びるため今回は1280pxにしました。

■基本メニュー

TOPは100vh-数十ピクセルで上下を黒線で映画画面な形にする事で引き締めてあります。
なので必ずスクロールが必要でヒーローイメージで1ページを占有させたので基本メニューはその下に全部あります。
機能面で言えば機能性が悪いです。
まぁでも自分のサイトの構成上メイントップよりサイト内サイト構成になってるのでそちらに直接アクセスする方が多いだろうから別にいいかなって割り切った。

■モダンって何だろうね・・・

grokにモダンっぽいを聞いたらメニューをガラス表現のトップ追従とかがモダンっぽいと言ってたんだけどエフェクトでわざわざ重くすることはないなと。
appleが良くやってます見栄えが良くなりますってメッチャ推してきたけど保留。
いやまぁモダン的な動きを付けるとどれも重くなるだけなんだけどさ。
個人的には情報を見る時に注視してる外で物が動くのが嫌なのでサイト内で動的な所は少ないです。
メニューが少し遅く表示されるのはReactの読み込みをラグを体感させないためにそうしています。遅れてぱっと出るとガク付きを感じますが、元を0%表示からゆっくり出す事でで読み込みラグがあってもメニューの表示がそういう演出に見える様にしました。

■ダークモード

現在サイトを見てる人の大半はダークモードで見てる割合が5割を超える
トグルで切り替え付けた方がベターだとは思ったけど面倒になったのでサイト全体を強制ダークベースにしました。

■ヘッダーとフッター

最近はベタhtmlの方が確実とはいえ生成コンテンツ部分も読むみたいなので今回はReact18でヘッダーとフッターを作る様に変更。
React19だとsrcでjsxが変換できないため18です。割とお試し実装なのでCDN経由。使えなくなりそう時はちゃんと実装します。
現在はバベル経由でwebで直ビルド。
一応jsが無効な時用に最低限のヘッダーはindexへのリンク、footerはコピーライトだけが残る様にベタcssで入れてあります。

■cssフレームワーク

今回はメインのcssはスカスカにしてあります。
こちらも結構お試しの感覚でCDNでTailwind を入れています。
今でもコード見るとやはりごちゃごちゃして汚く感じるものの確かにsrcのcssと往復しなくていいのはデザインいじりが捗ります。
まぁただ前回の記事でも話した通りTailwind の真価がでるのはReactなどのコンテンツに押し込んで使った時なのでベタhtmlに書いている今回の場合はそりゃあそう感じるのは仕方ない。

■レスポンシブの対応方法

TWのmdでちょこちょこメディアクエリを入れてる所はありますが基本的には最低と最大幅のコンテンツdivを作って自動折り返し。
今回は幅広めなので指定数で幅が狭くなったら1列にするという形ではなくて、幅があるだけ横にアイテムを詰めて、狭くなるだけアイテム列が減っていく形にしてあります。

2026年1月16日金曜日

js-mjs-jsx-ts-tsxの違い

js、mjs、jsx、ts、tsxって何なの?

さて今回はjavascriptの話です。

超簡単に言えば結局どれもjs=Javascriptであり、Javascriptに出来ない事は他のjs以外の拡張にでも処理出来ません。それに加え、末尾xがついてるものはjs+タグの構造です。
個々に説明しますね。

.js

一般的にバニラjsなどと呼ばれる無加工天然のjavascriptです。
全ての基盤であり、ブラウザが進化して例えば直接ts実行できるみたいな未来がない限り先ほど出した一覧のどの形式であってもこの純粋jsにトランスパイルする必要があります。

一般的なスクリプト体系と同様に変数の型が自動で判定されます。
また、変数や関数はグローバル領域「window.」に定義される為どこからでも参照もでき、定数やfreezeでなければどこからでも変更もできます。
つまり、スコープが超広い。

.mjs

端的に言えばモジュールJavascriptです。ES Modulesと言われます。
拡張子は区分けの為にmjsとする場合もありますが「.js」でも問題ありません。
呼ぶ時に<script type="module" src="script.js"></script>このtype部分で判定されます。
基本的にはほぼほぼバニラjavascriptで、トランスパイルなども不要です。
モジュールとなった事でスコープの範囲がそのmjs内でしか参照出来ません。
そうなると複数のmjsファイルの場合、他のファイルの変数や関数にアクセス出来ない…となりますが、mjs内でexportを指定した上で他のmjsはimportすれば参照出来る様になります。

スコープが排他された事でhtml側からのonclick等での関数実行も出来ません。
mjsを使う場合イベントリスナーが必要になります。
js側からhtml側をみてクリック等を見張るという形で実行します。

jsかmjsは読み込み方で変わるので以降のものもこのどちらかに属します。
つまり、mjs(jsx)みたいな事もあり得るわけです。

また、mjsは個々同士でexportとimport出来ますがpackage.jsonにまとめて管理する事が多いかと思います。

.jsx

簡単に言えば「HTML+javascript」の融合体です。
JavaScript XMLと言われます。

関心の分離はどうした?と初見ではかなり抵抗がありますがjs側で全てを管理するという事で現在は主流の仕組みです。
ブラウザ上で直接は利用出来ません。つまり必ずJavascriptに変換する必要があります。
一応CDNでバベルなどを経由すればjsxの直接リンクしてもリアルタイムでビルド出来ます。

.ts

雑に言えばjavascriptの強化版です。typeScriptと言われます。

Javascriptに型定義の概念を追加する事で開発の安定性を向上させる事に成功しました。
ブラウザ上で直接利用する事は出来ません。トランスパイルが必須です。

.tsx

typeScriptのJSX版です。typeScriptの型定義を使える上にhtmlタグも一緒にまとめて記述出来るという訳ですね。

当然ながらブラウザ上で直接は利用出来ません。トランスパイル必須です。

jsxの仕組みが主流という事はそうじてtsxも主流です。
どちらかと言えば強固であるtsxの方を主流というのが正しいかも。

現在のjavascriptフレームワークはReactが主流であり、大半はtsxなんじゃないかな。

その他

他にcjsやコーヒースクリプトなどもあるがもう古い技術として基本覚える必要はない。cjsは必要な時に調べれば十分。

2026年1月14日水曜日

React-TailwindでCDN経由で使ってみる

Reactを使ってみよう!

今回はいたって単純React使ってみようという話です。
CDN経由で使えるのでどんな感じかを直ぐに試せるのは本当に良い時代です。
一応順を追って説明しますね

CDN (Contents Delivery Network) とは

まずコンテンツ・デリバリー・ネットワークで使えるというのがどういうことかというと、通常ライブラリとかフレームワークはダウンロードしてきてサーバーアップロードして参照したりしないといけない。
正直面倒臭いし、ブログなどではそもそもサーバにファイルが置けない。
そんな時にCDNです。
CDNは超簡単に言えば直リンクです
JSとかcssとかに直リンクして必要な結果だけを貰う。
ただし、昨今のCDNはデータサイズが大きいので重いです。例えば、Tailwindcssとかはcssって名前ではあるものの実際にはjsを経由してcssのデータを貰う形です。
全乗せのcss情報が来るのでサイズが大き目でリンク時のコンソールにもCDNでの本番運用だと遅いから推奨しないって内容の文字が裏で表示されます
他にも少し問題がありますが一旦後で説明します。
取り合えず超簡単にまとめると「便利機能がリンクするだけで使える様になる」です。

Reactとは

さて、本題のリアクトとはjavascriptのフレームワークです。
jsxで記述する事でタグとjavascriptを一つにまとめる事が出来ます。
初見では相当気持ち悪さを感じますがみんながみんな慣れるというので慣れなんだと思います。
また、Tailwindとの相性がよくcssを別途使わなくても短い記述でstyleも含めて記述する事が出来ます。クラス名を考えなくて良いという事もあり開発速度が上がります。

CDNでReactで使う場合

先ほど「他にも少し問題が」って言いましたがCDN経由ビルドとなるのでmjsでは利用できません。
私は自作のDOMラッパーをインポートしたりするので最近はmjsが多かったのですが今回は使えません。
何故使えないのかというとまずjsxのアクセス方法が<script type="text/babel" src="jsx.js"></script>こんな感じですね。
babelに投げてビルドしてもらうという事ですね。投げたjsxはjavascriptとして返ってきて始めて動作するのですがbabel君は外部接続できないのでimport文が利用出来ません。
スクリプトのアクセス方法をmjsにするとそもそもbabelにデータが渡せません。

つまり変数がグローバル化してしまうという事です。
まぁ、それだけといえばそれだけです。

Reactのおおまかな流れ

①ReactDOMから必要な機能を取り出す

const { createRoot } = ReactDOM;

分割代入で取り出すのが一番楽かと思います。
一応、ReactDOMから取り出してるだけなので
const a=ReactDOM.createRootでも
const a=ReactDOM['createRoot']でもアクセスは可能です。

②コンポーネントを作る

例えば以下の様にfooterを作ってみます

const Footer = () => (
    <footer className="py-8 border-t border-[#1a1a1a] bg-[#050505]">
        <div className="max-w-[1280px] mx-auto px-5 text-center text-xs text-[#555]">
            <p>©black stray cat</p>
        </div>
    </footer>
);

定数にFooterを定義無名関数でそのまま内容を書きます。
ほぼほぼタグをそのまま記述可能ですがclassはバニラJavascriptで定義されているためJSXではclassNameにする必要があります。
ちなみに「ケースセンシティブ (case-sensitive)」なのでFooterの頭をFにする事でタグのfooterと別の判定になります。Reactは 「小文字で始まるものは通常のHTMLタグ」「大文字で始まるものはカスタムコンポーネント」 と自動で判別します。そのため、自作コンポーネントは必ず大文字で始める必要があります。

③レンダリングする

const footerEl = document.getElementById('footer-root');
if (footerEl) createRoot(footerEl).render(<Footer />);

処理的には先ずDOMを定義して次に存在確認存在したらレンダリング
先ほどReactDOMから取り出した機能を使います。
renderに指定する中身は定数に定義したコンポーネント名です。
今回で言えば「<Footer />」こうですね。

④html側

<div id="footer-root"></div>

こんな感じです
先ほどgetElementById指定した所に内容を生成します。
このdivの内側に予定と違う内容あれば全て書き換えます。

挙動だけを見るとinnerHTMLに近いものだと思ってもあまり問題ないです。
ただし内部的には仮想DOMで極力再利用する様に処理されます。
innerHTMLの場合は全て破棄された後に書き変わる処理である為Reactの方がメモリ効率が良いし高速です。

つまり、事前に使うhtmlを用意しておくと読み込みが早くなります。
基本的にはNext.jsを使う事になると思いますがhtmlが無くても生成はされますので試す分には問題ないです。

この様にしてcss-in-jsがコンポーネントとして分離サイト内でパーツとして利用できます。
新たにサイト等を作る時にも同様の機能が欲しい時全て込み込みで移植出来ます。

CDNでReactでモジュール

さて、React19では可能というか19以降はインポートでしか行けない。
しかもインラインでしかjsxをビルド出来ない。
パーツをインラインで書くなら意味がない。

さらに色々な問題が発生します。
相対パスが外のurlと相対になり参照が上手くいかないとか、CDNのTailwindが先に処理されてReact19内で使うstyleが用意されないといった問題が起きる。
一応TWの対応はできる
  <script>
    tailwind.config = {
      safelist: [
        'hidden',
        'md:block',
        'md:hidden',
        'block',
        'w-8',
        'h-8',
        'py-4',
        'bg-[#050505]',
        // 例えば事前に読み込む必要がでる
      ]
    }
  </script>
のように先に使うものを指定しておく・・・ただこれを手動でやるのはCDNの手軽さが損なわれる。TWの参照が前後するならもう普通のスタイルを埋め込んだ方が確実。

React19の一応使い方としてはまず呼び出しは
  <!-- importmap:React 19 -->
  <script type="importmap">
  {
    "imports": {
      "react": "https://esm.sh/react@19.2.0",
      "react-dom/client": "https://esm.sh/react-dom@19.2.0/client"
    }
  }
  </script>

  <!-- tsxでJSX変換 -->
  <script type="module" src="https://esm.sh/tsx"></script>
この様に変更します
コード呼びは
<script type="text/babel">ここにインラインで記述
そしてReact呼び出しは今回インポートに変わります
    import React, { useState } from "react";
    import { createRoot } from "react-dom/client";
JSXに基本的な記述変更ありません
CDNでReactをモジュールにするとかなり色々な相性が悪くなる
ただ、公式推奨はもう新しいReact19なんですよね・・・。

まとめ

cdnで使うという前提において
コードを外部参照できるのはReact18まで
この場合はTailwindもとても相性が良い

React19はコードを外置き出来ないインラインでしかjsxをビルド出来ない
コードを別ファイルで管理したい時の解決策は2つ
1.素直にReact18を使う(既にサポート終了ずみ余命のみ)
2.React19でjsxを記述せず純粋なjsモジュールとして使う

ただまぁReactをバニラjsのmjsで利用すると変化癖がつく可能性があるにはある
たぶん現在の一般的な使い方はjsxで記述するのが普通だろうし・・・。
やはりCDNは個人サイトとかで使う場合であってもお試しが限界かなぁ

2026年1月12日月曜日

Next.js-React-TailwindCSSなどたわいもない話

最近思ってる事を整理するために一旦書き出して整理してみるという話

今回は最近思ってる事を 整理するために一旦書き出して整理してみるという話。
昨今のWebページは基礎となるhtmlやcssやjsを素のままは書かない。 大半はフレームワークだよりになっている。 一応WebComponentsという選択肢もあるがこれもまたフレームワークの影響によるもの。

この世には「関心の分離」という言葉あって、Webページで言うなら画面のデザインと動的処理の分離をするべきだとずっと言われてきた。 だが最近の流れはそうではない。データをコンポーネント単位で「デザイン+処理」としてカプセル化して再利用しようというのが主流である。

まず、大半はフレームワークという話。

主に流行ってるのはReact.jsとVue.jsほぼ2強…いやたぶん割合的にReact(next.js)1強。
htmlタグをjs側に取り込んでしまおうというのがこれらのフレームワークである。 通常のhtmlはhtmlからjsとcssを呼び出してhtmlを主体にそれを装飾する形だった。 フレームワークは逆にjsを主体にhtmlを吐き出すという思想の元に出来ている。

そうすると空白のページにjsが動いて始めて生成される。 これにはちょっとした問題がありページが大きいほど描画が遅れる。 そこで更にサーバー側のフレームワークNext.jsである。 サーバ側で一旦描画処理をして静的htmlを生成し描画を先にする。

フロントフレームワークは「html+処理」だがこれらフレームワークは既にあるhtmlを生成せず差分のみを生成する様に出来ている。 今は「Svelte、Solid、Astro」みたいな軽量かつ強いものも育ってきてるが先に出来たものに対して「安定」を優先させると新規フレームワークを導入・選択肢にするのはまだ難しい気がする。

WebComponentsの話

Microsoftなどの大きいサイトの場合はページが大きすぎて使ってるフレームワークの分裂が起きている。 そして統合が難しいが同じメニューなどを付けたくなった時にフレームワークを統合するのではなくもっと原始的なWebComponentsでパーツを配る事にしたそうである。 つまり、WebComponents+各フレームワークを使って共存させる事で落ち着いている。

TailwindCSSの話

cssやめよう。極端に言えば思想はこれである。

webページでの関心の分離はデザインとhtmlの分離ではないし、分離しない方が良いという方向で作られている。
デザイン面においてはhtmlよりもcss主体の方が再利用性があるという考え。
前回、使用感を記事にしたがhtml上にstyleでごりごり書くような地獄のような可読性になる。

ただ、Tailwindの思想としては「html+Tailwind」ではなくあくまでもcss-in-jsのパーツとして出来ている。
そのため開発者もフレームワークを使わない=コンポーネントにしないTailwindCSS単品の運用はあまり本意でない様である。
複数回登場するようなパーツならなおさらコンポーネント化した方が良い。

また、クラス名を考えるのは時間の無駄でさっさとデザインを反映させた方が良いという考え方。
じゃあなぜstyleではなくTailwindを使うのかというとstyle記述では出来ないメディアクエリなどのcssstyleが複数あるため。
他にも、フレームワーク全般に言える事だが記述の統一性の向上がある。

フレームワークの食い合わせの話

Reactは仮想DOM、WebComponentsはシャドーDOMを使っている。 先に述べた通りWebComponentsは他のフレームワークと共存できるが、シャドーDOMはTailwindと食い合わせが悪い。
これはcssが内部に閉じてしまいTailwindが使えなくなってしまう。
(いくつか対応方法はあるが現状あまり美しい実装ではない感じ)
逆に言えばReactとTailwindは良い組合せと言える。

現状の組み合わせで良さそうなものは?

Next.js-React-Tailwind現状ではこの組み合わせがかなり良さそうに感じる。

ちなみに今はかなり下火に見えるphpも再考した時に悪くないと思っている。 phpが凄く下げられているが現行のシェアもphpは低いわけでは無く特にWordPressは根強いシェアがある(40%以上ある)。

■変換が多すぎ問題

上記をもう少し加えるならTailwind-in-Next.js(React(TypeScript))という構造だろうか。 TypeScriptは型なしjavascriptに変換する必要があり、Next.jsはhtmlを生成する必要がある。 リアクトはビルドする必要があり、Tailwindもビルドする必要がある。 こう考えると本当に変換しすぎていて正直面倒臭い。

先ほど再考にphpが上がったのは面倒臭いからhtmlなどを直接インクルードすればいいじゃんという考えである。
この変換祭りがなんで起きるのかというと開発環境の負債をユーザに渡さない為である。

正直面倒臭いからCDN (Contents Delivery Network) =リンクのみで済ませたい。 ReactとTailwindはCDN使えるし・・・。
ただベタデータは重い為変換して軽量化しないと描画が遅れる為、モダン開発環境を享受しつつユーザー体験を損なわない為には変換祭りをしなければない。