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使えるし・・・。
ただベタデータは重い為変換して軽量化しないと描画が遅れる為、モダン開発環境を享受しつつユーザー体験を損なわない為には変換祭りをしなければない。

2026年1月11日日曜日

環境変数って何?一体どこで定義されているのか

 そもそも環境変数ってなに?

環境変数は超簡単に言えばただの「良く使うpath(パス)の集まり」です。
パスはエクスプローラーを開いた時に表示される「C:\Users\Username\Desktop\」みたいなPC上の階層の事です。
よく使うパスを登録した集合体の事を「環境変数」と呼んでいます。
PC内の処理で常にこういった長いパスを常に書き込んでいたらデータが長くなるので先に登録しておいて短い名称で呼び出そうという事です。

例えばよく使うアプリなどをデスクトップにショートカットを作ると思います。あれと同じです。ああいう感じのショートカットが1つに纏まってるという事です。

プログラミングなどのセットアップ時の環境変数

環境変数とだけ言うとつまりはただの省略パスの事なのでWindowsの特殊パス(マイドキュメントやデスクトップ)なども含まれますが一般的には「実行パス」の事を指します。
パスを通す」などともよく言われます。

実行パスを通すと登録したexeを名前だけで実行出来ます。
例えばWin+Rでファイル名を指定で実行読んでcmdやnotepadでアプリが呼び出せるのは環境変数が登録済みでパスが通っているからです。
逆にcmdやnotepadはOSに統合されたプログラムではなく単にcmd.exeやnotepad.exeが独立して作られておりそれを実行してるに過ぎません。

環境変数の確認の仕方

一般的なパスを確認するだけならWindowsの左下の検索バーで環境変数と入れれば簡単に確認できます。

※ただし、ここにはファイルを実行する系のパスは表示されません。

コマンドラインを開いて「path」を実行すればパスを表示できます。

ただこれだとちょっと見ずらいですよね。Powershellでも同様に表示し整形も出来ます。
まずは同じ事ができる「$env:Path」を実行してみましょう。

同じパスが表示されます。

次に整形して表示「$env:Path -split ";"」セミコロンで区切られるのでそこで改行させます

はい。分かりやすくなりましたね。

これらは一体どこに情報が書き込まれているのか?

次に情報の実体が一体どこにあるのかです。
答えから言うとレジストリにバイナリ形式で保存されています。
その為、メモ帳で開いてぱぱっと更新すると言ったことは出来ません。
バイナリエディタで開くにしてもチェックサムがある為「技術的には可能だが現実的ではない」です。

詰まる所、$envが何処にあるのかですよね。パワーシェルで「Get-PSDrive Env」を叩きます。

Environmentにある事がわかります。これがレジストリのどこにあるか。まずはレジストリエディタを開きましょう。
win+Rから指定実行で「regedit」

ルート名 役割(中身) ユーザーへの説明例
HKEY_CLASSES_ROOT (HKCR)ファイルの関連付けやプログラムの情報「拡張子(.txtなど)をどのアプリで開くか」を決める場所
HKEY_CURRENT_USER (HKCU)現在ログインしているユーザーの設定「壁紙」や「自分専用の環境変数」が入っている場所
HKEY_LOCAL_MACHINE (HKLM)PC全体(全ユーザー共通)の設定「システム環境変数」の本当の住所はここです
HKEY_USERS (HKU)PCに登録されている全ユーザーの個別情報「全社員の名簿とそれぞれの設定」を保管している大元の場所
HKEY_CURRENT_CONFIG (HKCC)現在のハードウェア構成の情報「今使っているモニターやプリンタ」の起動用設定

パスを通す場合は全体で呼べるようにするので「HKEY_LOCAL_MACHINE\」の中です。

コンピューター\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

最終的にはここに書き込まれています。

階層レベル フォルダ名 (キー) 具体的に何が入っているか
第1階層HKEY_LOCAL_MACHINE全ユーザー共通のハードウェア設定やOSの基本情報。
第2階層SYSTEMWindowsの起動や動作に絶対必要な「核」となるデータ。
第3階層CurrentControlSet今まさに正常に動いているドライバーやサービスの設定セット。
第4階層Controlタイムゾーン、マウス、キーボード、ファイルシステムなどの挙動設定。
第5階層Session ManagerOS起動時のプログラム実行順序や、メモリ管理などの「下準備」データ。
第6階層Environment【最終目的地】 Pathなどの「共通のショートカット集」の実体。

階層はこの様になっています。
環境変数と言った場合、基本的にはここに記述されているデータが本体といって差し支えないです。

更に奥にある実体パス

ただし、実体をここまで見に行くと今までみたcmdの「path」やPowershellの「$env:Path」とも違う記述があります。
例えば「%SystemRoot%」などさらに変数で指定されている事が分かります。じゃあ今度はこれらは一体どこに格納されているのか

コンピューター\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

この階層です。Windowsのより心臓部で定義されています。
ここで注目すべきなのはデータの種類(型)です。

実は先ほどのパスの種類は「REG_EXPAND_SZ」であり、今回の種類は「REG_SZ」です。
この違いが何かというと中の変数を展開できるかどうかです。

型の名前 正式名称 特徴・役割 環境変数での使われ方
REG_SZ String Value 固定された文字列。書かれた内容をそのまま読み取ります。 単純なパス(例: C:¥Tools¥App)
REG_EXPAND_SZ Expandable String 展開可能な文字列。中に % で囲まれた変数を含むことができる。 今回のキモ!%SystemRoot%等を翻訳するパス
REG_BINARY Binary Data バイナリ形式。人間には読めない形式。 特殊な構成情報の保存用など

つまり、今度こそ本当に環境変数という情報の末端という事です。
これで環境変数が一体なんなのかと、その実体が何処にあり参照されているか理解できたと思います。

2026年1月7日水曜日

n8nをセットアップしてみる

 前回はDockerDesktopを入れたので今回は何かコンテナに入れてみるっていうところです。

n8nとは

n8n(エヌエイトエヌ)とは、オープンソース(fair-codeライセンス)のワークフロー自動化ツールです。
ノーコードまたはローコードで、さまざまなアプリやサービスを連携させて繰り返しの業務を自動化できるプラットフォームで、ZapierやMakeのようなツールの代替として人気!

今回はZapierやMakeをなぜ使わないのかというとn8nはクラウドもありますがホスティングがセルフホストに出来るからです。つまり無料で使えます。
残り二つはクラウドのみです。

取り合えずインストール

Powershellを開いて
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n


パラメータ 役割 具体的になにをしているか
docker run 実行指示 新しいコンテナ(仮想的な箱)を作成して起動します。
-it 対話モード PowerShell画面にn8nの動作ログをリアルタイム表示し、キー操作を受け付けるようにします。
--rm 自動削除 コンテナを停止した際、PC内に不要なゴミ(一時ファイル)が残らないよう箱を自動で破棄します。
--name n8n 名前付け コンテナに「n8n」という名前を固定します。これがないとDockerが勝手に名前を付けてしまい、後で探しにくくなります。
-p 5678:5678 通信の道作り コンテナ内のn8nと、あなたのPCのブラウザをつなぎます。左がPC側、右がコンテナ側のポート番号です。
-v n8n_data:... データの保護 最重要。 コンテナを捨てても「作成したワークフロー」が消えないよう、PC側の保存領域(ボリューム)と紐付けます。
n8nio/n8n 設計図の指定 n8n公式が配布しているプログラム一式(イメージ)を指定してダウンロード・実行します。

「ポート番号?」という方の為に説明をすると

■0 ~ 1023(ウェルノウンポート):
Web閲覧用の 80 (HTTP) や 443 (HTTPS) など、世界的に用途が決まっている「一等地の番号」です。

■1024 ~ 49151(登録済みポート):
特定のアプリが「この番号を公式に使うよ」と予約している番号です。
n8nの 5678 もここに含まれます。

■49152 ~ 65535(ダイナミックポート):
一時的な通信のために自由に使える「空き部屋」です。

こんな感じに利用されています。
左側のPC側のポート番号は好きに変えても問題ないです。
変更した所でその番号でアクセスするのが右の5678となります。

右側の5678はコンテナ内の環境変数に入ってるデフォルト値で変更不要です。
コンテナの環境変数を変更すれば変更可能ですが何か調べる時に置き換えて考えるのは面倒だと思います。他のアプリとポートが被るなどよほどの理由がない限りは固定で良いです。

つまり左側は任意の番号、右はほぼ固定という事です。
そしてあえて別の番号にする必要性がないので左のポート番号であるPC側も同じ番号を指定する感じです。


実行するとインストール処理がずざーと流れます。
インストール途中でDockerがファイヤーウォールで止められたメッセージが出た時は許可してください。

最後に「Press "o" to open in Browser」と表示されたらインストールは完了。
「o」を押したらブラウザが開くという親切設計ですが私の環境ではo押しても開かなかったのでそういう場合は普通にブラウザに直接urlを入力します。
アクセス先はメッセージ「Editor is now accessible via: http://localhost:5678」とある通り「http://localhost:5678」にアクセスします。

Powershellはそのままにします(最小化でもしててください)。
✕で閉じてしまうと処理が終了してブラウザで上記URLにアクセス出来なくなります。


正しく手順が進んでいればこの画面(管理者登録画面)が表示されます。
ここで入力する情報は何処かに飛ばすデータではなくてPCの中(Dockerのボリューム)に保存するデータです。


起動時に表示されるのはアンケートです。
選択式なのでおおまか合ってるのを入力してください。

■What best describes your company?(会社の業種は?)
自分用なら Other や Education など何でもOK。

■Which role best describes you?(あなたの職種は?)
Personal use(個人利用)や Engineering など。

>What are you looking to automate?

・CI/CD: システム開発の自動テストや公開作業
・Cloud infrastructure orchestration: クラウドサーバーの自動管理
・Data syncing: データの同期(AのデータをBに移すなど)
・Incident response: 障害が起きた時の自動対応
・Monitoring and alerting: 異常がないか見守って通知する
・Reporting: レポートの自動作成
・Ticketing systems integrations: お問い合わせ管理ツールとの連携
・Other: その他

■Who will your automations mainly be for?(誰のための自動化?)
自分用なら Myself 。

■How big is your company?(会社の規模は?)
I'm not using n8n for work: 仕事では使いません(お試しならこれで)

■How did you hear about n8n?(どこでn8nを知った?)
GoogleでもTwitterでもなんでもOK

内容的にはこんな感じです。
選択はドロップダウンなので手入力は無いですがOtherの時は理由入力が出たりするのでstudyとかPersonal useとかで良いかと思います。


次にセルフホストユーザーには初回に基本表示されるらしいこちらは有償機能を無料で使えるライセンスキーを上げるよって内容です。
セルフホストの基本機能は別に制限は掛かっていませんので面倒なら左下のスキップでも構いませんが、メール登録するだけでforever(ずっと)なので登録しといた方が少しお得です。

(※Cloud版、Self-hosted版、Enterprise版があってEnterprise(法人向け)の機能が使える用になるライセンスキーです。)

・Advanced debugging: 失敗した自動化を簡単に直して再実行できる機能
・Execution search and tagging: 過去に動かした履歴を検索したり、タグを付けて整理したりできる機能
・Folders: 作った自動化をフォルダ分けして整理できる機能

この3つが使える様になるよって内容です。
「Send me a free license key(無料キーを送って)」で良いかと思います。

登録した場合の右下に出るポップ「Your license key is on the way!Check your email, 登録したメールアドレス, to find your license key. Then head over to usage and plan to activate your license.」は「ライセンスキーが届きました!メールでライセンスキーをご確認ください。その後、使用状況とプランのページにアクセスしてライセンスを有効化してください。」です。

これでセットアップが完了です。


下部にあるのはテンプレートで内容は以下通り。
テンプレート 内容(日本語訳) 何ができるの?
Secure web form to Odoo CRM... Webフォームから顧客管理ソフトへ連動 サイトのお問い合わせフォームに入力された情報を、自動で顧客リスト(Odoo)に登録します。
Automated LinkedIn posts with AI... AIによるLinkedInへの自動投稿 OpenAI(ChatGPT)を使って記事を自動生成し、LinkedInへ投稿する仕組みです。
Automated lead capture, scoring... 見込み客の自動獲得とランク付け 新しい顧客情報を取得し、その重要度を判定して、HubSpotやSlackに通知します。
Automated local event monitor... ローカルイベントの監視とAI分析 特定の地域のイベント情報を収集し、AIを使って内容を分析・整理します。
Automate restaurant customer... 飲食店向けのチャットボット対応 WhatsAppとAI(Llama)を使い、レストランの予約や質問に自動で答えます。
Ai voice & text note-taking... 音声とテキストによる自動メモ作成 LINEからのメッセージや音声をAIで要約し、データベースとGmailに保存します。

ただ、これらのテンプレートは外部サービス(LINEやChatGPTなど)のAPIキーが必要になるため、初心者がいきなり動かすには少しハードルが高いです。

まずは、一番上にある大きな四角 「Start from scratch(ゼロから作る)」 をクリックして、真っ白な画面から始めてみるのがおすすめ。


セットアップおまけ:ライセンスキーの有効化

上記で無料ライセンスキーを登録してる場合はメールが届ているのでメールの「Activate License Key」ボタンを押します。

Sign inのページに飛ぶのでメールとパスワード入れる。
これで終了です。Sign in時点でライセンスが有効化します。

Sign inするとこちらの画面に飛びます。
You’re on the Community Editionの隣に「Registered」が表示されていればライセンス登録済みです。


もしメールのボタン以外でSign inした場合は「Enter activation key」(アクティベーションキーを入力)から入力してアクティベートすればOKです。

なお、メールのボタンでSign inした場合は先ほど言った通りSign inした時点で登録済み「Registered」になるのでもう一度アクティベートしようとすると


もう登録済みって表示されます。

これで本当にセットアップ全部終了です。

2026年1月6日火曜日

svgファイルで保存できるドット絵作成webツールを作ってみた

 SVGドット絵Webエディタ

https://blackstraycat.nobody.jp/webtools/svg-pixel-art-maker/

作ったのはこちらです。
好きに使ってみてください。

そもそもSVGファイルってなーに?

画像ファイルの形式です。
ですがjpgやpngなどと違いバイナリデータではありません。
内部構造はテキストデータです。
つまり、「ファイル名.svg」という画像はメモ帳で開いて編集すら可能です。

何が便利かというと拡大縮小しても画像データが全く劣化しません
更に内部はテキストデータであるためWebPやjpgなどよりも軽量です。

要するに、複雑な画像でない限りは最強の画像形式という事です。

何で作ったの?

単純にサイトと作ってる時に軽量な画像が欲しかったからです。
簡単なアイコンを作る時に欲しいなって思って。

webでドット絵にする方法は実はcssで影を付けるという方法(box-shadow)もあるんですがsvgデータはcssにテキストで書き込む事も出来るし、ファイルとして保存すればキャッシュ出来るし、単独で管理できるので便利だろうなって。

ただまぁドット絵にすると座標の埋め込み列挙になるので本来最強の軽量形式ですが今回は利点が少し損なわれています。まぁ、それでも十分軽量ですけどね。

他の理由

今回は他にcssフレームワークのテイルウィンド(Tailwind)を使って見たかったという理由もあります。
Tailwindはオープンソースで利用に制限が無く、CDN (Content Delivery Network) 形式で簡単に実装出来るのでお試しです。
ちなみに、CDNを使った場合、consoleにも表示されますが「遅いから本番環境で使うのはやめておけ」みたいなメッセージが表示されます。
Tailwind君が何が言いたいのかというと、別に使うのは禁止しないけどデータ群が大きいのでテストサイト等には便利だが本番で使うにはページの表示が遅くなるよって事です。

(一応補足するとちゃんと使うならTailwindはビルドして必要なスタイルだけを適用するのでCDNを使わなければ遅いわけではないです。)

まぁ、今回作ったページの速度を見る限りはCDNでも問題なさそうに感じます。
むしろ触ってみた感じではコードが気持ち悪いという印象の方が強いです。

これはまぁリアクトのコード見た時みたいな拒否反応なのでなれの問題というのは分かっています。
でもやはり、タグで構成するWebデザインという構造上このスタイルはこの為に定義している(headerとかtop-menuなど)名称みたいな方が正しいような気がします。
後ですり替える際もhtmlを変更しないで良い訳ですし。

しかし、分離したcssで定義を書くならhtmlに書いても変わらないだという気持ちもわかります。
なおかつ記述はcssの通常記述よりも短いし、style名称を毎回考えなくても良いという利点もありますので。

でもhtml内の可読性が酷いような。
styleでゴリゴリに書いてるような感覚になる。しかもいっそstyleで全部書いた方がCDNを通さない分早い。
リアクトでも関心の分離的にえぐいと思ったけどあれは機能に対してデザイン込みで含めるものなのでまだ理解出来る。

今回は全体的に「その気持ちは分かる」と「でもそれは辛くない?」が交錯しながら作ってました。閑話休題。

使い方

話を戻して使い方ですが、スマホのタップでもPCのクリックでもポチポチ出ます。
フリーラインなのでドラッグとかでもそのまま描けます。
「消しゴムボタン」
押すと消しゴムに切り替わりもう一度押すか色変更で鉛筆に戻ります。

「全消去」を押すと全てを消します。
ピクセルカンバスサイズを変更しても同様に全て消えます。

「タグコピー」はテキストデータをそのままコピーします。
メモ帳を開いて「ファイル名.svg」で保存すればすぐ使えます。

「SVGでDL」はデータをsvgで直接保存できます。
まぁ元々がテキストデータなので拡張子を変更してるに過ぎません。

感想としてはそこそこいい感じに出来たので満足です(*´ω`*)

■余談
最初ドット絵メーカーにしてたけどエディタに名称変えた

2026年1月3日土曜日

DockerDesktopを入れてみる

Docker Desktopとは

まずはそもそもDocker Desktopが何なのかという所から。
「開発者向けの共同コンテナ化ソフトウェア」と説明されるけどつまりどういうこと?と思う人が多い気がしますのでもっと詳しく。

要するに「実行環境を隔離する技術」です。
確実に隔離するならVM(仮想PC)で良いですが、PC内でPCを起動させると起動までの動作などが遅い。
そこでDockerです。
実行環境ごとアプリを最低構成で1つまとめる」これがコンテナ化という事です。
全体をエミュレートするVMと違い軽量で高速に起動と実行が可能

このコンテナはLinuxカーネルで動作し、OSなどで環境変わってもこのコンテナ内で動作するので自身のPC→テスト環境(サーバ)→本番環境(サーバ)みたいな移行や他の人のPCで移しても最低限の設定でどこでも同じ様に動作するという事です。

物理的な貨物コンテナの様にコンテナ内に作った機能を簡単に移動できる事ですね。
先述した通りこのコンテナはLinuxカーネルで動作するのでWindowsやMacなどの場合は必ずLinuxが必要です。
ただし、LinuxOSをフルで入れる必要はなく、カーネル(プロセス処理など最低構成)だけあれば動作します。

イメージとしては「ユーザー操作→OS→小さなLinux→コンテナ(アプリ)」たったこれだけです。
アプリなどの機能自体はLinuxコンテナ上で動くようになっていて、動作が保証されています。
基本的なPC操作などはホストのOS側で制御し、それを小さなLinuxVMで操作を情報をパイプしてコンテナ内に伝える事でどこでも動作します。


DockerDesktopダウンロード

https://www.docker.com/ja-jp/get-started/

Mac、Windows、Linux各OS用が準備されています。
一般的なWindowsユーザーならAMD64です。

(※左下の「スタートボタン」を右クリック > 「システム」 を開く。「システムの種類」 という項目を見てください。「64 ビット オペレーティング システム、x64 ベース プロセッサ」 と書いてあれば ➡ Windows版のダウンロード - AMD64「ARM ベース プロセッサ」 と書いてあれば ➡ Windows版のダウンロード - ARM64 (最近のSurface Proの一部などがこれです))

DockerDesktopインストール

1. Use WSL 2 instead of Hyper-V (recommended)
「Hyper-Vの代わりに WSL 2 を使って動かします(推奨)」
 Windowsの中でLinuxの仕組みを効率よく動かすための最新技術(WSL 2)を使う設定です。昔の技術(Hyper-V)より圧倒的に動作が速く、PCへの負担も少ないため、必ずチェックを入れたままにします。

2. Allow Windows Containers to be used with this installation
「Windowsコンテナも使えるようにしますか?」
ここはチェックを外したままでOK。世の中のほとんどのDockerアプリは「Linux用」として作られています。これをオンにするとWindows専用の特殊なコンテナ用設定になります

3. Add shortcut to desktop
 「デスクトップにショートカットを作成する」
 お好みですが、管理画面をすぐ開けるようにチェックを入れておくと便利です。


■「Close and restart(閉じて再起動)」

押すと強制でPCが再起動します。
何か作業途中などの場合は保存などしてから押してください。

■規約確認

1. 「Accept(同意)」
個人利用や、学習目的、あるいは小さな会社での利用であれば、そのまま**「Accept」**を押して進めて問題ありません。

2. 無料で使える条件(Docker Personal)以下のいずれかに当てはまる場合は、無料で使い続けることができます。
個人利用(趣味や学習など)教育機関やオープンソースプロジェクトでの利用小規模企業(従業員250人未満、かつ年間売上高1,000万ドル=約15億円未満)

3. 有料になる条件上記の「小規模企業」の基準を超える大きな会社で業務利用する場合は、有料サブスクリプション(Pro, Team, Businessなど)の契約が必要になります

※2026年1月時点

■初回起動:WSLインストール
Powershellで「wsl --update」を入力してねと表示されます。
リンクにある通り「https://learn.microsoft.com/en-us/windows/wsl/install」で何のコマンドかちゃんとか確認してから入力してください。
(危険なコマンドなどでは無いですがユーザーにコマンドを入れさせるというのは普通はあまりないです。リンク先の内容はWindows 上で Linux を動かすための WSL (Windows Subsystem for Linux) をインストール・設定する方法が詳しく記載されています。)

最初に説明してる通りDockerDesktopはLinuxカーネルが必要なのでWSLインストールが必要です。

Windowsの検索バーに「Powershell」と入力すればこんな画面になるので一番上のPowershellをそのまま起動

(ちなみに、Windows PowerShell ISEのISE は「Integrated Scripting Environment(統合スクリプト環境)」の略です。長いプログラム(スクリプト)を書いて保存したり、間違いがないかチェック(デバッグ)したりするための「書き物用」のツールです。上半分がメモ帳のようなエディタ、下半分が実行画面になっています。今回ISEは選ばない)

Powershellが起動したら画面上で「wsl --update」を入力。
(コピペする場合はPowershell上で右クリックすると貼り付けされます)
エンターを押せばWSLのインストールが始まります。

WSLのインストールが終わったらDocker Desktopに戻って「WSL needs updating」のままなので、中央の 「Restart」 ボタンを押してください。

これでセットアップ終了です


■オマケ


VSCが入ってるならここら辺がVSC側から推奨されます。