フロントエンド座学ノート

大地図 ― なぜ「全部いっしょに襲ってくる」のか

最初に、いちばん大事な安心を渡します。あなたが並べた50個の横文字は、バラバラの敵ではありません。全部、たった1つの仕事——「文字と絵を、人のブラウザの画面に出す」——のための道具です。役割で並べれば、1本の道の上にきれいに整列します。

答え：フロントエンドとは「人が実際に見て触る画面がわ」のこと。あなたの理解で合っています。ではなぜ全部襲ってくるか。理由は1つだけ。「素のHTML/CSS/JSだけで作ると、規模が大きくなったとき手に負えなくなる」から。その"手に負えなくなる場所"を1つずつ楽にするために、道具が1個ずつ増えていった。だから道具は問題ごとに1個あり、種類が多い＝解決したい悩みが多い、というだけの話です。

道具を「1本の道」に並べる

あなたのコードが、書かれてから客の画面に映るまで。全部品はこの道のどこかの駅にいます。

あなたが挙げた横文字を、この駅に振り分けたのが下の表です。「多すぎる」の正体は、1つの駅にライバル商品が何個も並んでいるだけ——どれか1つ選べば、その駅は片付きます。

「正解は1つじゃない」という大原則

あなたは何度も「どれが正解なの！？ 何を選べば怒られないの！？」と叫びました。ここが一番の誤解です。フロントエンドに"唯一の正解"はありません。料理に唯一の正解がないのと同じです。あるのは「この場面ならこれが無難」という相場だけ。だから——

• 怒られません。どれを選んでも動きます。「間違い」ではなく「向き・不向き」があるだけ。
• 各駅には「迷ったらこれ」の無難な第一候補が実在します（この本の最後に早見表を付けます）。
• あなたはもうAstro＋Cloudflareという、静的サイトでは"最も無難で強い"組み合わせを選び終えています。つまり選定はすでに正解済み。

まず、これを声に出して言わせてください。あなたの直感は、1000%正しい。それが本当に土台で、25年前から今日まで一度も変わっていません。ReactもNextもTailwindも、全部この3つの上に乗っている"追加の便利道具"にすぎない。土台がぐらついているのではなく、土台の上に人が勝手に増築しただけです。

では、なぜこの3つだけじゃ足りなくなったのか

1ページの小さなサイトなら、本当にこの3つだけで完成します（あなたの座学ノートのHTMLがまさにそれ）。問題が起きるのはページが増え、動きが増え、同じ部品を何十回も使い回すようになったときです。素のJavaScriptで大きなアプリを作ると、こういう地獄が始まります。

• 「カートの数字」を、ヘッダー・商品欄・会計欄の3か所で手作業で書き換える。1か所忘れて表示がズレる。
• 同じ「ボタン」のデザインを、40ページにコピペ。1つ直すのに40回触る（あなたの旧・屋号サイトのナビがこれ）。
• どこで誰が画面を書き換えたか追えなくなる。

この「大きくなると手に負えない」を解決するために生まれたのが、次の部のReact/Vue/Svelteです。つまり——フレームワークは「素のJSの続き」であって、別物ではありません。あなたの出発点はそのまま正しく、その延長線上に全部が乗っています。

DOM ― この本で一番大事な4文字

後の章で何度も出るので、ここで一度だけ。DOM（ドム）＝いまブラウザが表示している画面の、部品の一覧表です。あなたがHTMLを書くと、ブラウザはそれを読んで「見出しが1個、画像が1個、ボタンが1個…」という一覧を頭の中に作ります。これがDOM。

JavaScriptで「動き」をつけるとは、このDOMを書き換えることです。「ボタンを押したらメニューを開く」＝JSがDOMの中のメニューを"表示"に書き換える。これだけ分かっていれば、後で出てくる「仮想DOM」「Shadow DOM」も、全部このDOMという一覧表の話だと見抜けます。

4つとも、やろうとしていることはまったく同じです。名前が4つあるだけで、発明は1個。その発明とは——「状態（データ）を書き換えたら、画面が自動でついてくる」という仕組みです。

素のJSの地獄 → その1個の解決

第1部の「カートの数字を3か所で手書き換え」を思い出してください。素のJSではデータと画面を人間が手でつなぐ。ここが全バグの巣でした。フレームワークはこれを逆さにします。

つまりフレームワークとの約束は1つだけ。「あなたはデータだけ書き換える。画面はこっちが合わせる」。React も Vue も Svelte も Solid も、この約束を実現する道具です。違うのは書き方の好みと、内部のやり方だけ。

答え：JSXは「JavaScriptの中に、HTMLそっくりの見た目を直接書ける」書き方です。正体はJavaScript。でも見た目はHTML。だから「どっち？」は正しい疑問で、答えは「JavaScriptだけど、HTMLの顔をしている」。名前もそのまま——JS + XML（HTMLの親戚）＝JSX。

なぜHTMLとJSを混ぜたのか

昔は「HTMLファイル」「JSファイル」を分けるのが正義でした。でも実際の部品——たとえば「ボタン」——は、見た目（HTML）と動き（JS）がセットで初めて意味を持つ。ファイルを分けると、1つのボタンが2か所に散らばって管理が面倒になる。そこでReactは「見た目と動きを1か所にまとめよう」と決めた。その"1か所"を書くための記法がJSXです。

{ } の中身だけがJavaScriptに戻る、という約束です。「HTMLの中に、波かっこで穴を開けてJSを流し込む」。これがJSXの9割です。

なぜ class じゃなく className なのか（似せきれなかった理由）

あなたの怒り「似せるならちゃんと似せてよ！」は完全に正論で、実は開発者たちも同じことをずっと言っています。理由はこうです。JSXの正体はJavaScript。ところがJavaScriptには、大昔から class という別の意味の予約語がすでに存在した（設計図を作る命令）。同じ部屋に同じ名前の人が2人いると混乱するので、HTMLの方の class を className に改名して衝突を避けた——それだけの、しょうもない歴史的事情です。

この叫び、実はめちゃくちゃ鋭い。答えは——「その通り、ほとんど全部がコンポーネントです」。コンポーネント＝名前をつけて使い回せるようにした、画面の部品。ボタンもカードもページも、大きさが違うだけで全部"部品"。これはあなたの全体像編で習ったAstroの「金型（1個作って着せ替える）」とまったく同じ話です。

「偉い」理由は1つ：直す場所が1か所になる

あなたは既にこの価値を体で知っています。旧・屋号サイトは「ナビが6ページにコピー」＝直すのに6回。bramleyは Nav.astro という部品1個＝直すのは1回。この「部品1個」がコンポーネントです。偉いのは賢いからではなく、「1回直せば全部に反映される」から人間が楽になる、ただそれだけ。

じゃあ「コンポーネントじゃないもの」は？

ちゃんと答えます。画面の部品でないもの——たとえば、

• ただの計算やデータ（「合計金額を出す関数」「客リストの配列」）。これは部品ではなく"中身・道具"。
• 設定ファイル（どのフォントを使うか等）。画面ではなく"取り決め"。
• スタイル（CSS）そのもの。部品に着せる"服"であって部品ではない。

つまり「目に見える四角い部品」＝コンポーネント、「その裏で働くデータ・計算・設定」＝コンポーネントじゃないもの。あなたの直感（ほぼ全部コンポーネント）は、見た目に関しては正しかったわけです。

まず言葉。state（ステート）＝状態＝「今この画面が覚えておくべき値」。たとえば「カートの数：2」「メニューは開いてる？：はい」。useState＝その"覚えておく値"を1個作る道具。第2部の「データを変えたら画面が自動で追う」の、その"データ"を作る係です。

なぜ2つセット（配列）で返るのか

useStateは、いつも「今の値」と「値を変えるボタン」の2点セットを渡してきます。これが配列に見える正体です。

なぜ「値を直接書き換える」じゃダメで、わざわざ変更係（setCount）を通すのか。ここが超重要です。Reactは「setCountが呼ばれた」という合図を見て、初めて画面を描き直すから。もし count = 3 と直接書き換えたら、値は変わってもReactは気づかず、画面が古いままになる。だから——

「値」と「変更を知らせるボタン」をセットで渡す＝Reactに"変えたよ"と報告する義務を作っている。この報告があるから、画面が自動で追いつく。

あなたの「値を変えたいだけなのに」という感覚は自然です。でもReactにとっては「値を変える」と「画面に反映する」はワンセット。だから変更は必ずボタン（setCount）経由、という決まりになっています。

レンダリング＝「今の値から、画面の設計図を1枚作る」作業。再レンダリング＝値が変わったので、設計図をもう1枚作り直すこと。答え：値が変わるたび、何回でも描き直します。それがフレームワークの仕事（第2部「画面は勝手に追いつく」）の正体です。

「何回描くの」→ 値が変わった回数だけ

カートの数が 0→1→2→3 と変われば、Reactは設計図を4回作り直します。これは無駄ではなく、"常に最新を映す"ための正しい動き。あなたが手で3か所書き換えていた地獄を、Reactが代わりに全部やり直してくれている、と考えてください。

「描きすぎると遅い」→ ここで仮想DOMが効く（大事）

ここで矛盾に気づきます。「毎回作り直したら、画面全体を毎回描き直して重いのでは？」——その通り。だからReactはズルをします。いきなり本物の画面を描き直さず、まず"下書き"を作って、前の下書きと見比べ、"変わった所だけ"本物に反映する。この下書きが次の項の仮想DOMです。

前項の通り、Reactは値が変わるたび全部を作り直します。ということは——関係ない重い計算まで毎回やり直してしまう。useMemo／useCallback は、その無駄を止める道具。「この計算結果、材料が変わってないなら前回のを使い回して」と頼むメモ書きです。memo＝メモ（記憶）、そのままの意味。

「最初から忘れないでよ」への正直な答え

あなたのツッコミは正しい。理想を言えば、Reactが自動で「これは変わってないから使い回そう」と判断してくれるべき。そして実際、それが起きつつあります。2024年以降のReactには「React Compiler」という自動化が入り始め、useMemo/useCallbackを人間が手で書く必要は、これから減っていきます。あなたの「最初から忘れないでよ」は、React開発チームの目標そのものです。今はまだ過渡期で、手で書く場面が残っている——それだけ。

第1部で「DOM＝ブラウザが持つ画面の部品リスト（本物）」を習いました。仮想DOM＝そのコピーを、Reactが自分の頭の中に持つ"下書き用のリスト"。偽物を作る理由はハッキリしています——本物のDOMの書き換えは"重い"から。

なぜ本物は重く、下書きは軽いのか

本物のDOMを書き換えると、ブラウザはそのたびに画面のレイアウトを計算し直して描画します（重い作業）。一方、下書き（仮想DOM）はただのメモなので、いくらいじっても軽い。そこでReactはこうします。

これで「値が変わるたび全部描き直す」ように見えて、実際に本物が書き換わるのは本当に変わった1か所だけ。前項の「描きすぎると遅い」を、Reactはこの仕組みで防いでいます。偽物を1枚はさむ方が、結果的に速い——これが仮想DOMの答えです。

この4つはまったく同じ1つの質問への、4通りの答えです。その質問とは、あなたが自分で言った——「いつ・どこで・誰がHTMLを作るのか」。これ以上でも以下でもありません。全体像編で習った「静的 vs 動的」を、4段階に細かくしただけです。

1枚の図で「誰が作るか」を掴む

第2部のReact/Vueは「部品を作る道具」でした。こちらはその1つ上の階層——部品を集めて"サイト全部"に組み立てる工場です。ルーティング（URLとページの対応）、上の4方式（SSG/SSRなど）の切り替え、画像の最適化などを丸ごと引き受ける。これを「メタフレームワーク（フレームワークのフレームワーク）」と呼びます。

なぜあなたはAstroなのか（ここが芯）

NextやNuxtは「動きまくるアプリ（SNS・管理画面・EC）」まで想定した重装備。多機能な代わりに、放っておくと客のスマホに大量のJavaScriptを送りつけて重くなる。一方Astroは思想が真逆で、「基本、JSを1バイトも送らない。動きが要る所にだけ足す」。だから——

• あなたが作る「見せるための美しいサイト」に最適（宿・店・作品サイト）。
• 速くて軽く、SSGと相性抜群＝Cloudflareでほぼ無料配信。
• 必要なら「この地図だけReactで」と部分的に動きを招ける（"アイランド"という考え方）。

これは今のフロントエンドで一番ややこしく、一番新しい話です。だから混乱して当然。結論を先に：これはNext.jsなど"最新の一部"だけの話で、あなたのAstroにも、世の中の大半のサイトにも関係ありません。安心した上で、正体だけ掴みましょう。

なぜサーバーが出てくるのか

きっかけは第3部の反省です。「全部を客のスマホ（クライアント）でJSで組み立てるCSR」は、最初の表示が遅く、スマホに負担が重い。そこで新しいReact/Nextはこう考えた——「動く必要のない部品は、サーバー側で先に作って、完成品だけ送ればいい。動く部品だけスマホで動かそう」。この「部品ごとに、作る場所を分ける」発想が Server Components です。

つまり "use client" は「この部品は客のブラウザで動かしてね」という付箋。書かなければ「サーバーで作る部品」。1つの画面が、サーバー製の部品とブラウザ製の部品の寄せ集めになる——だから「どっち？」の答えは「部品ごとに違う。両方が協力して1画面を作っている」です。

また同じ構造です。全部「CSSを書く」という1つの仕事の、書き方バリエーション。そして「普通のCSSでいいじゃん」は、小〜中規模では本当に正解。あなたの座学ノートも普通のCSSで書かれていて、何も問題ありません。流派が生まれた理由は、たった1つの持病を治すためです。

普通のCSSの唯一の持病：「名前がぶつかる」

CSSは、書いた飾りがページ全体に効いてしまう。だから大規模になると、Aさんが作った .title と、Bさんの .title がぶつかって、片方の見た目が壊れる。この事故を防ぐための工夫が、各流派の正体です。

その"呪文"、実は1個ずつはただのCSSの短縮形です。魔法でも新概念でもない。あなたが今まで書いてきたCSSに、あだ名をつけて直接HTMLに貼っているだけ。翻訳表を見れば一瞬で解けます。

「flex items-center justify-between gap-2 px-4 py-2」を翻訳すると——「横並び・縦中央・両端寄せ・隙間8px・左右余白16px・上下余白8px」。あなたが普段CSSでやっていることそのままです。呪文の正体はただの略語の連続でした。

「方針変えないでよ」への、正直な歴史の説明

あなたの怒りは100%正当です。実際に方針は変わりました。順を追うと：

1. 昔の教え：「見た目（CSS）と構造（HTML）は分けろ。HTMLにスタイルを書くな」。理由は"分けた方が整理される"という理想。
2. 現実に起きたこと：分けたら分けたで、CSSファイルが巨大になり、「このクラス、まだどこかで使われてる？消していい？」が誰にも分からなくなった。触るのが怖いCSSが積み上がった。
3. Tailwindの主張：「分けた理想より、見た目と構造が同じ場所にある方が、実際は直しやすい」。部品を見れば飾りも全部そこにある＝迷子にならない。

つまり「理想（分ける）」から「実利（一緒にある方が直せる）」へ、現場が方針転換したのです。どちらが絶対正解でもなく、今も両派は共存しています。あなたが「昔と違う」と感じたのは気のせいではなく、業界が実際に学習して考えを変えた記録です。

UIライブラリ＝「よく使う部品（ボタン・メニュー・カレンダー・モーダル）の、出来合いの詰め合わせ」。毎回ゼロから作らず、棚から出して使う。多いのは、その詰め合わせの「見た目の完成度」と「自由度」のバランス違いがあるからです。

「頭がないUI（ヘッドレス）」の正体

全体像編でmicroCMSを「ヘッドレスCMS＝見た目を持たず中身だけ渡す」と習いました。まったく同じ"ヘッドレス"です。ここでの「頭（head）」＝見た目。「頭がないUI」＝見た目ゼロで、中身の機能だけを持つ部品。

なぜ見た目を捨てるのが人気なのか。ボタンやメニューには、実は目に見えない難しさが詰まっています——キーボードだけで操作できるか、読み上げソフトで意味が伝わるか、モーダルを開くと背後がスクロールしないか（これがアクセシビリティ／第11部）。この"面倒で間違えやすい部分"だけを完璧に用意し、見た目は真っさらで渡す。すると開発者は、自分のデザインを1から当てつつ、難しい部分はタダで手に入る。だから「頭がない」ことが逆に価値になる。

これは新しくて紛らわしい発明なので、混乱は正常です。一言で言うと——shadcn/uiは「ライブラリ」ではなく「部品のコピー配布所」。あなたの直感の3択のうち、「部品取り」が一番近いです。

普通のライブラリとの決定的な違い

「インストールしたのに自分のコードになる」＝入れる操作が"ダウンロード"ではなく"あなたのフォルダへのコピー＆ペースト"だから。レシピ本を借りるのではなく、レシピを自分のノートに書き写して、あとは自由に改変する——これがshadcn/uiのモデルです。中身はさっきのRadix（頭なし）に、きれいな見た目を当てた状態でコピーされます。

「アップデートは？ 自分で面倒を見る？」への答え

その通りで、ここが唯一の代償です。自分の物になった＝作者の自動更新は届かない。だから改良版が出たらあなたが手で取り込む。ただし多くの場合これは利点です：勝手に更新されて見た目が突然変わる事故が起きない。あなたが「デザインを置き換えたら意図せず作り直されて外した」と過去に苦い思いをしたのと逆で、shadcnは"勝手に変わらない安心"を選んでいます。

第3部で「state＝画面が覚えておく値」を習いました。状態管理ライブラリ＝そのstateが、アプリ中に散らばって手に負えなくなったときの"整理棚"。5つあるのは、整理の流儀違いです。そして先に結論——これは"大きなアプリ"だけの悩みで、あなたには1つも要りません。

なぜ整理棚が要るのか（バケツリレー地獄）

stateは、それを作った部品の中だけで有効です。ところが「ログイン中のユーザー名」のようにアプリの隅々で使いたい値があると、部品から部品へ手渡しで延々とバケツリレーすることになる。10階層下の部品に届けるのに、間の9個の部品が全員バケツを持たされる。これが地獄。

この「みんなが見られる共有の棚」を提供するのが状態管理ライブラリ。5つの違いは、棚の作りの好みだけです。

Reduxが厳格すぎて疲れた人たちが、次々と「もっと楽な棚」を作った——それが5つに増えた歴史です。つまり多さは"Reduxへの不満の数"。今から選ぶなら軽いZustandが無難、とだけ知っておけば十分。

この部の道具は全部「裏方」で、あなたが直接触ることはまずありません（Astroが中で勝手に使う）。でも名前だけは襲ってくるので、正体を1枚で押さえます。まず大前提——あなたが書いたコードは、そのままではブラウザで動きません。だから「変換（ビルド）」という工程が挟まります。

変換の中身は主に3つ。この3つを担う道具の名前が、あなたを襲った横文字たちです。

• トランスパイル（翻訳）：最新JSやTypeScriptを、古いブラウザでも動く昔のJSに書き直す。担当＝Babel・SWC。
• バンドル（荷造り）：何百個に分かれたファイルを、配りやすいよう少数にまとめる。担当＝webpack・Rollup・esbuild・Rspack。
• この2つを束ねた総合窓口：担当＝Vite・Turbopack（開発中のプレビューも速くする）。

全部「さっきの変換をやる道具」で、違いは実質「新しいか、速いか」だけ。歴史は"同じことをもっと速く"の一本道です。名前の洪水は、その世代交代の記録にすぎません。

ポイントは1つ。「速い新型」は、たいてい古い定番をGoやRust（速い言語）で作り直したもの。webpack→Rspack、Babel→SWC、というように"中身は同じ仕事・エンジンだけ高速化"。だからあなたが機能を覚え直す必要はゼロ。速くなっただけです。

Babel（バベル）＝元祖の"翻訳屋"。最新JSを古いブラウザ向けに書き直す仕事を、長年ひとりで担ってきた功労者です。「もういらない」と言われるのは、前項のSWCやesbuildが、同じ仕事をもっと速くやるようになったから。世代交代で主役の座を譲りつつある——それが"いらない"の意味。

でも「設定に出てくる」のも本当。理由は2つ。①長年の資産：世界中の古いプロジェクトがBabel前提で作られていて、まだ現役。②細かい特殊技：SWCが未対応の特殊な変換を、今もBabelだけが担える場面がある。だから答えは——「新規で自分から選ぶ必要はない（いらない）。でも既存プロジェクトや一部機能では今も動いている（いる）」。両方本当、というのが正直な現状です。

パッケージマネージャ＝「他人が作った部品（パッケージ）を、ネットから取ってきて揃える"買い出し係"」。4つあるのは、買い出しの速さと省スペースの改良版が次々出たから。仕事は全部同じです。

「知らない人のコードが千個」＝ライブラリの連鎖（正しい恐怖）

この恐怖はまっとうな感覚です。仕組みはこう：あなたが部品Aを1つ入れると、Aも別の部品Bに頼っていて、Bも部品Cに頼っている…と連鎖する。結果、1個入れたつもりが数百〜千個の他人のコードが芋づる式に入る。それらが詰まる倉庫が node_modules（ノードモジュールズ）で、重いのはこの芋づるを全部保管しているから。

lockfile ― 「増やさないでよ！」の正体と、実は味方な話

lockfile（ロックファイル。package-lock.json 等）＝「今回入れた数百個の部品の、正確なバージョンを1個残らず記録した名簿」。増えるのは邪魔に見えて、実はあなたの命綱です。これが無いと、明日別のPCで買い出しした時に部品のバージョンが微妙にズレて"昨日動いたのに今日動かない"が起きる。lockfileは「全員がまったく同じ部品で揃う」ことを保証します。だから消さない・GitHubに一緒に保管するのが鉄則。名簿が各買い出し係で名前違い（package-lock.json／yarn.lock／pnpm-lock.yaml／bun.lockb）なので、「買い出し係は1プロジェクトで1つに統一」すればlockfileも1つで済み、あなたの「増やさないで」も守れます。

npm audit（オーディット＝監査）＝「集めた数百個の部品の中に、危険が見つかった物はない？」を自動チェックする健康診断。「怒られる」のは、その芋づるの奥の方の部品に既知の弱点（脆弱性）が見つかると警告が出るから。

厄介なのは、警告の多くが「あなたが直接選んだ部品」ではなく、その奥にある"部品の部品の部品"にあること。だから自分では直しようがなく、無理に自動修正（npm audit fix --force）をかけると他の部品との噛み合わせが狂って壊れる。あなたの「直したら壊れる」はこれです。冷静な対処はこう：

2つとも「別のファイルから部品を呼び出す書き方」で、やることは同じ。方言が2つあるだけです。あなたの「どっちでもいいじゃん」は本質を突いていて、実際どちらでも部品は呼べます。違いは"世代"。

なぜ仲が悪いか。ブラウザは昔から require を理解できず、Nodeは昔 import を理解できなかった。育った家が違うので方言が分かれ、混ぜると「この部品、どっちの言葉で呼べばいいの？」という噛み合わせ事故が起きる。今はESM（import）に世界が統一されつつあり、仲直りの最中です。あなたの「仲良くして」は、まさに今進行中。

「同じWebじゃないの」——気持ちは分かりますが、ここが現実の壁です。Webのルール（HTML/CSS/JSの仕様）は1つ。でも、それを"読んで実行するアプリ"＝ブラウザは、会社ごとに別々に作られている。Chrome（Google）、Safari（Apple）、Firefox（Mozilla）…。同じ楽譜でも演奏する楽団が違えば、微妙に音が変わる。それがブラウザ差です。

なぜ「iOS Safariだけ」壊れるのか

あなたのこの観察は鋭い。理由はAppleのルールにあります。iPhoneでは、たとえChromeアプリを入れても、中身は強制的にSafariのエンジンで動く（Appleがそう決めている）。だから「iPhoneのChromeでは動くのにiPhoneのSafariでは…」ではなく、iPhoneは全部Safari。しかもそのSafariが他ブラウザと挙動が違うので、「PC・Androidでは平気、iPhoneだけ崩れる」が起きる。よくある崩れどころ：

• 画面の高さ計算（100vh）が、アドレスバーの伸縮でズレる（iOS名物）。
• 最新CSS機能の対応が一歩遅く、Chromeで使えた飾りがSafariで無視される。
• 日付の扱いや、動画の自動再生のルールが厳しめ。

CORS（コルス）＝「あるサイトのページが、"別のサイト"のデータを勝手に取りにいくのを、ブラウザが止める安全装置」。エラーに見えて、正体はあなたを守るための警備員です。だから「悪いもの」ではなく、「初期設定が厳しめの、味方の門番」。

なぜ止めるのか（あなたを守る理屈）

もしこの門番がいなかったら——あなたが銀行サイトにログイン中に、たまたま開いた怪しいサイトのJavaScriptが、あなたの銀行データを裏でこっそり読み取れてしまう。それを防ぐため、ブラウザは「ページと、そのページが読みにいく先のサイトが"別のドメイン"だったら、まず止める」という規則を持っています。これがCORS。

「許していいの？」への、はっきりした答え

ダメならダメと言います。許可を出すのは、あなた（取りに行く側）ではなく、"取りに行かれる側のサーバー"の設定です。だから——

• あなたが自分で両方のサーバーを持っているなら：「このサイトからのアクセスはOK」と自分で許可設定を書けばよい（安全）。
• 他人のサービス（外部API）を使うなら：そのサービスが許可を出す仕組み（APIキー等）に従う。勝手には通れない（それが正しい）。
• やってはいけないこと：「全世界からのアクセスを無条件で許可（*）」を、ログインや個人情報が絡む所で使うこと。これは門番を撤去するのと同じで危険。

単語は強そうですが、全部たった1つの問題を解くための道具です。その問題とは——「ログインは一瞬。でもその後の全ページで"さっきの人と同じ人だ"とどう証明し続けるか」。Webは基本、1ページ見るごとに相手を忘れる仕組みなので、この"覚えておく手段"が必要になる。それが認証の全て。

関係を整理すると、こう積み上がっています。

「トークン」＝前項の合言葉／通行証のこと。これをブラウザのどこに保管するか、3つの候補にそれぞれ弱点があって板挟み——という、プロも悩む本物の難問です。だから混乱は当然。1枚で整理します。

答え：現在の推奨は「httpOnly属性を付けたCookie」。これは「JavaScriptからは中身を読めない」特殊なCookieで、たとえ悪意のJSが紛れ込んでも合言葉を盗み出せない。「Cookieも設定ミスると危ない」の"設定"とはこの httpOnly や Secure／SameSite のことで、正しく付ければ最も安全。逆にlocalStorageは手軽さゆえに初心者が使いがちだが、盗難リスクが高いので合言葉の保管には避けるのが定石です。

この2つはWeb攻撃の二大巨頭。名前は怖いですが、やられ方は1文で説明できます。正体を知れば、対策も1つずつはっきりします。

覚え方：XSS＝「悪いコードを、あなたのサイトに"入れられる"」／CSRF＝「あなたの権限を、別サイトから"勝手に使われる"」。方向が逆の攻撃です。

TypeScript（タイプスクリプト・略してTS）＝「JavaScriptに"型のメモ"を書き足せるようにしたもの」。型＝「この値は数字」「これは文字」「これは客データ」という、中身の種類の宣言。これを書いておくと、書いてる最中に間違いを赤線で教えてくれる。「文字と数字を足そうとしてるよ」と、動かす前に警告が出る。これがTSの全価値です。

なぜ「ビルド後に消える」のか（消えて正しい理由）

第7部を思い出してください。あなたのコードは、ブラウザ向けに変換（ビルド）されます。ところがブラウザは型を理解できません（ブラウザが読めるのは素のJavaScriptだけ）。だから変換の最後で、型のメモは役目を終えて削り落とされる。つまり——

型は「書いている最中を守る道具」であって、動いている時に働く物ではない。だから消えて正しい。あなたの「大事なら消えないで」は自然な感覚ですが、正確には「型は"作る時"に大事な物で、"動く時"には役目を終えている」。テスト前の勉強ノートのようなもので、本番（ブラウザ）には持ち込まなくていい。むしろ持ち込む（消さない）と、ブラウザが理解できずエラーになります。

両方とも「サイトが、サーバーからデータを取ってくる時の"注文の仕方"」。あなたの「RESTでいいじゃん」は、多くの場合その通り正解です。違いは注文の柔軟さだけ。

「RESTは取りすぎなの？」——半分正解。RESTはセットメニューなので、要らない付け合わせも一緒に来がち。でもそれが問題になるのは、通信量にシビアな大規模アプリの話。普通のサイトでは"取りすぎ"は誤差で、RESTの単純さの方が価値があります。GraphQLは「巨大アプリで、画面ごとに欲しいデータが細かく違って、通信を切り詰めたい」時に効く道具。多くの現場は今もRESTで、それで何も問題ありません。

テスト＝「コードを直すたび、壊れてないか"機械に自動で確認させる"仕組み」。手で全ページをポチポチ確認する代わりに、機械が一瞬でやる。まず種類（何をどこまで確認するか）と、道具（それをやるアプリ）は別の話なので、分けて整理します。

次に道具。どれが「単体用」か「E2E用」かで住み分けています。

モック／スタブ＝「テストの時だけ使う、本物そっくりの"替え玉（ニセモノ）"」。なぜ本物を使わないか。テストで毎回"本物のサーバー"に問い合わせると、こうなるから：

• 遅い：ネット越しに毎回問い合わせる＝テストが何十倍も時間がかかる。
• 不安定：サーバーが混んでいたり、通信が落ちたりすると、コードは正しいのにテストが失敗する。これでは「壊れた」のか「たまたま通信が悪かった」のか区別できない。
• 危険：「注文」のテストで本物を叩くと、本当に注文が入ってしまう。

だから「相手のサーバーは、いつも決まった答えを即返す替え玉」に差し替える。これがモック。するとテストは速く・毎回同じ結果・安全になり、「自分のコードだけ」を正確に確認できます。「本物が信用できない」のではなく、「テストでは"自分のコードの検査"に集中したいから、外部という不確定要素を一時的に外す」——という理屈です。（スタブとモックは細かくは別物ですが、あなたは「テスト用の替え玉」と一括りで大丈夫。）

まず、名前が似ている2つを役割で分けます。ここが混乱の元です。

「最初からBiomeでよくない？」への正直な答え

あなたの疑問はまっとうで、新規プロジェクトなら「Biome 1つ」で正解に近いです。速いし、2つ入れる手間もない。ではなぜ皆Biomeに一本化しないか——「ESLintのルール資産」がそれです。ESLintは長年かけて膨大な"検査ルールの蓄積"を持っていて（特殊な状況を検知する細かいルールが何千個もある）、Biomeはまだ全部には追いついていない。だから「複雑な既存プロジェクト＝ESLintの資産が要る」「新しく小さく始める＝Biome1つが楽」という住み分け。あなたの新規サイトならBiome、またはClaudeにお任せで何も問題ありません。

セミコロン・クォート戦争 ― 「どっちでもいい。決めて自動化するだけ」

ここが一番のガス抜きポイント。セミコロンが要るか、シングルクォート(')かダブル(")か、末尾にカンマを付けるか——技術的には、どれも正解です。コードの動作は1ミリも変わりません。ではなぜ揉めるか。「チーム全員がバラバラだと、diff（変更箇所の記録）が汚れて、誰が何を直したか分からなくなる」から。つまり中身の正しさではなく"揃っているか"だけが問題。だから解決は1つ——

「どれでもいいから1つに決めて、あとはPrettier/Biomeに自動で揃えさせる」。人間が手で気にするのをやめ、保存した瞬間に機械が統一する。これで宗教戦争は"起きなくなる"のではなく"どうでもよくなる"。

末尾カンマがなぜ大事か、だけ補足：行を1つ足した時、末尾カンマがあると「新しい行の追加」1行だけの変更に見えるが、無いと前の行にカンマを足す変更まで混ざって、diffが余計に汚れる。だから「常に末尾カンマを付ける」派が多い。これも"揃えると後で楽"という実利の話で、あなたが覚える必要はありません。

デプロイ＝「完成したサイトを、世界に公開する（サーバーに置いて配る）こと」。全体像編の「店舗（Cloudflare）」がこれです。7つの名前は"公開を代行してくれる会社"のライバル同士で、あなたはもうCloudflareを選び終えています。

あなたの観察、正確です。サーバーはあります。「サーバーレス」は"サーバーが無い"という意味ではなく、"あなたがサーバーを管理しなくていい"という意味。名前が誤解を生む、業界の悪いネーミングの典型です。正直に読むなら「サーバー管理レス（管理しなくていい）」。

だから「ログにサーバーっぽい物が出る」のは当然で、実際に裏でサーバーが動いている。ただそれをあなたが一切世話しなくていい。CloudflareのWorkers（前項）がまさにこれで、「呼ばれた時だけ、ほんの少し処理して、寝る」という、管理不要の小さなサーバーです。

環境変数＝「コードの中に直接書きたくない"設定値"を、外の小さなメモ帳に分けて置いたもの」。代表例がAPIキー（鍵）。鍵をコードに直接書くと、GitHubに上げた瞬間に世界に漏れる。だからコード本体とは別のファイル（.env）に隔離し、そのファイルはGitHubに上げない。全体像編でmicroCMSの鍵を「焼き込みの時だけ使い、公開HTMLに残さない」と習った、あれの正体です。

.env の種類 ― 「場面ごとの使い分け」だけ

末尾の違いは「どの場面用のメモ帳か」を表すだけです。

読まれる順は「より具体的なものが優先」（.env.local が .env より強い、など）ですが、これはあなたが暗記する必要はゼロ。Claudeとツールが正しく扱います。要点は1つ——「本物の鍵は .env.local に置き、GitHubには上げない。見本は .env.example で共有する」。

NEXT_PUBLIC_ ― 「名前でセキュリティを決めないで」の真相

あなたの怒りはほぼ正しく、しかし1点だけ理解を足すと腑に落ちます。これはNext.js（と類似ツール）のルールで——「変数名の頭に NEXT_PUBLIC_ と付いた物だけを、ブラウザに送り出す」という約束です。逆に言うと、付いていない環境変数は、ブラウザには絶対に出ない（サーバー側に留まる）。

つまり「名前でセキュリティが決まる」のではなく、「これは公開してよい」と開発者が意図的に宣言するための"目印"が、その名前。危険なのは、本物の秘密の鍵にうっかり NEXT_PUBLIC_ を付けてしまうこと——そうすると「公開してよい」と宣言したことになり、鍵がブラウザに漏れる。だから「NEXT_PUBLIC_ は"バレてもいい物にだけ"付ける」のが鉄則。名前は不親切ですが、仕組みとしては「公開/非公開を人間が明示する安全弁」です。

CI＝「あなたがGitHubに送るたび、"別のまっさらなPC"が自動で組み立て直して、壊れてないか確認する仕組み」。GitHub Actionsは、GitHubがその仕組みを提供するサービス名。目的は「あなたのPCではたまたま動くだけ、を防ぐ」ことです。

なぜ「ローカルで動いたのに落ちる」のか（理由は全部同じ1つ）

原因はいつも「あなたのPCと、CIのまっさらPCの、環境が違う」の一点です。あなたのPCには、長年かけて溜まった設定・ファイル・ツールがある。CIは毎回ゼロから作るので、あなたのPCにあって当然の物が無い。あなたが挙げた4つは、その"違い"の代表例です。

だから「ローカルで動いたら本番でも動いてよ」は正論で、CIはまさにその願いを叶えるための道具です。「あなたのPCの特殊事情に頼らず、まっさらな所でも動く」ことを保証する＝本番で動くことの事前確認。CIで落ちるのは、実は「本番で落ちる前に、安全な場所で先に落ちてくれた」ありがたい警告なのです。

キャッシュ（cache）＝「一度読み込んだ物を、次回速く出すために"手元に取っておく"仕組み」。ブラウザは、あなたのサイトの画像やCSSを毎回ダウンロードし直すと遅いので、1回目にコピーを保存して、2回目からはそれを即出す。これで表示が速くなる——普段はあなたの味方です。

問題は更新した時。あなたはサイトを新しくしたのに、ブラウザは「前に取っておいたコピー」を"まだ新しい"と思って出してしまう。だから「更新したのに古い画面」。あなたの怒りはこの一点で、「速くする仕組みが、更新の邪魔をする」という、キャッシュ本質のジレンマです。

直し方 ― プロは「名前を変える」で解決している

「効かないでよ」を実現する定番の技があります。ファイルの名前に"指紋"を付ける方法です。中身が変わったら、ファイル名を style.css → style.a1b2c3.css のように自動で変える。するとブラウザには"別の新しいファイル"に見えるので、古いコピーを使わず取り直す。この仕組みを、Astroやビルドツール（第7部）が自動でやってくれます。だから正しく作られたサイトは、更新すれば新しい画面が出ます。

名前で損してますが、闇でも何でもありません。第1部のDOM＝画面の部品リストを思い出してください。Shadow DOM＝「部品の中に、外から干渉されない"独立した小部屋"を作る仕組み」。shadow（影）は「表の一覧からは見えない、隠された内部」という意味で使われているだけ。「隠し部屋つきDOM」と読み替えると正確です。

何のためにあるのか ― 第5部の「CSSが漏れる持病」の最終解決

第5部で、CSSの持病は「飾りがページ全体に効いてしまって名前がぶつかる」ことだと習いました。Shadow DOMは、この持病を物理的に断つ仕組みです。部品を"隠し部屋"に閉じ込めると、その部屋の中のCSSは外に漏れず、外のCSSも中に入れない。完全に独立する。だから「他人が作った部品を自分のサイトに埋め込んでも、お互いのデザインを壊さない」を実現できます。

この本で一番使う1枚。あなたが何度も叫んだ「どれが正解なの！？」に、全部まとめて答えます。読み方は簡単——「迷ったら」列が世間の無難な第一候補、「あなた」列が静的サイト職人のあなたにとっての答え。緑のマスは「あなたが実際に使う／使っている物」、それ以外は「知っておくだけでよい＝選ばなくていい」です。