仕組みから学ぶ Web

仕組みから学ぶ Web 言語やフレームワークの使い方ではなく、Web の仕組みと設計判断に特化した学習サイト。動く図解と、設計判断を問う演習で学びます。 https://shikumikara.dev/ 2026-09-17T00:00:00+09:00 ページネーション — 数えて飛ばすか、続きから取るか https://shikumikara.dev/topics/api/pagination 2026-09-17T00:00:00+09:00 2026-09-17T00:00:00+09:00

offset は「ページ番号」という画面の都合から来ている。件数が増えると遅くなり、データが動くと境界がずれる。カーソル方式が何を解いて、何を捨てるのか。

ブラウザのストレージ — 読めるか、と、送られるかは別の話 https://shikumikara.dev/topics/browser/client-storage 2026-09-17T00:00:00+09:00 2026-09-17T00:00:00+09:00

Cookie / localStorage / sessionStorage / IndexedDB を容量ではなく「誰が読めて、いつ送られるか」で分ける。認証情報の置き場所を決めるための判断軸。

Core Web Vitals — 数字を上げるのではなく、何が遅いかを特定する https://shikumikara.dev/topics/browser/web-vitals 2026-09-17T00:00:00+09:00 2026-09-17T00:00:00+09:00

LCP・INP・CLS は原因ではなく症状の分類。3つが何の代理指標なのかを知ると、直す場所が工程の中で決まる。

マイグレーション — 流した瞬間に、書き込みが全部待つ https://shikumikara.dev/topics/data/migration 2026-09-17T00:00:00+09:00 2026-09-17T00:00:00+09:00

列を1つ足すだけの変更が、本番で11分サイトを止める。行数ではなく、同時に走っているトランザクションの長さが効く。

RDB と NoSQL — 問い合わせの形を、いつ決めるか https://shikumikara.dev/topics/data/rdb-vs-nosql 2026-09-17T00:00:00+09:00 2026-09-17T00:00:00+09:00

性能の比較ではなく「アクセスパターンがもう固まっているか、まだ動くか」で選ぶ。後から取り方を増やしたくなったとき、何が起きるかの違い。

インシデント対応 — 直すのが先か、分かるのが先か https://shikumikara.dev/topics/ops/incident-response 2026-09-17T00:00:00+09:00 2026-09-17T00:00:00+09:00

原因が分からないまま戻すのは怖い。その感覚が復旧を遅らせる。止血と原因究明の順序、記録の残し方、そして再発防止に「気をつける」と書かないこと。

金曜のリリースを、切り戻せなかった夜 https://shikumikara.dev/cases/friday-deploy-rollback 2026-09-16T00:00:00+09:00 2026-09-16T00:00:00+09:00

リリース後に決済が通らなくなった。切り戻せば直るはずだった。5つの判断点で、あなたは何を選びますか。

エラー設計 — 呼び出し側が正しく振る舞える情報を返す https://shikumikara.dev/topics/api/error-design 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

エラーは失敗の通知ではなく、次に何をすべきかの指示。リトライしてよいか、直せば通るかを伝える。

冪等性 — 同じリクエストが2回届く前提で設計する https://shikumikara.dev/topics/api/idempotency 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

ネットワークがある限り、再送は異常ではなく正常系。2回実行されても壊れない形をどう作るか。

リソース設計 — 一度公開したら変えられない契約 https://shikumikara.dev/topics/api/resource-design 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

URL は動詞ではなく名詞で切る、の理由。そして「きれいな REST」に収まらない操作をどう扱うか。

REST と GraphQL — 何を楽にして、何を難しくするか https://shikumikara.dev/topics/api/rest-vs-graphql 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

過不足のない取得という利点の裏で、キャッシュ・認可・負荷制御がクライアント任せから自分の責任に移る。

CORS — 壁に穴を開けるのは「読まれる側」 https://shikumikara.dev/topics/browser/cors 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

プリフライトはなぜ飛ぶのか。ワイルドカードと Cookie が同時に使えないのはなぜか。エラーメッセージから原因を逆算する。

イベントループ — 1本のスレッドで待たずに捌く https://shikumikara.dev/topics/browser/event-loop 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

JavaScript が1スレッドなのに、なぜ複数の処理を同時に進められるのか。そして、なぜ「重い処理」が画面ごと止めるのか。

レンダリングパイプライン — どのCSSが重いかは工程で決まる https://shikumikara.dev/topics/browser/rendering 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

ブラウザが HTML を受け取ってから画面を描くまでの工程。どのプロパティを触ると、どの工程からやり直しになるのか。

同一オリジンポリシー — ブラウザが最初から持っている壁 https://shikumikara.dev/topics/browser/same-origin 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

なぜ他のサイトの JavaScript から自分のページのデータを読めないのか。この制約がなければ Web はどうなっていたか。

実行計画 — DB が何をしようとしているかを読む https://shikumikara.dev/topics/data/execution-plan 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

推測でチューニングしない。EXPLAIN の読み方と、見積もりと実測のズレが何を意味するか。

インデックス — 読む行を減らすための索引 https://shikumikara.dev/topics/data/index 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

B-tree が何をしているかと、複合インデックスの列順がなぜ効くのか。張れば速くなるものではない。

N+1 問題 — 1回で済むはずの問い合わせが100回になる https://shikumikara.dev/topics/data/n-plus-one 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

ORM の便利さが隠してしまう問い合わせ回数。発見の仕方と、対処の選択肢を使い分ける。

正規化 — 同じ事実を2か所に書かない https://shikumikara.dev/topics/data/normalization 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

正規化は理論ではなく「更新時に矛盾が起きない形」を作る作業。どこまで正規化し、どこで意図的に崩すか。

トランザクションと分離レベル — 同時に動く処理が互いをどこまで見てよいか https://shikumikara.dev/topics/data/transaction-isolation 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

在庫が二重に引かれる、残高がずれる。同時実行の事故は、分離レベルの選択と設計の両方で決まる。

凝集度と結合度 — 変更したとき何ファイル触るか https://shikumikara.dev/topics/design/cohesion-coupling 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

良い設計は「動くか」では測れない。測れるのは、仕様変更が来たときの影響範囲。それを制御する2つの語彙。

ドメインモデリング — 業務の言葉をコードの形にする https://shikumikara.dev/topics/design/domain-modeling 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

テーブル設計から始めると、業務ルールの置き場所がなくなる。何が概念で、何が制約かを見つける作業。

レイヤードアーキテクチャ — 依存の向きを一方向に揃える https://shikumikara.dev/topics/design/layered-architecture 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

層に分けること自体に価値はない。価値があるのは、依存が一方向であることと、業務ロジックが技術から独立すること。

SOLID — 5つの原則が守ろうとしている1つのこと https://shikumikara.dev/topics/design/solid 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

暗記する対象ではなく、判断の道具として使う。それぞれが「どういう変更に備えているか」から理解する。

キャッシュ戦略 — いつ捨てるかを設計する https://shikumikara.dev/topics/network/caching 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

キャッシュを置くのは簡単で、正しく捨てるのが難しい。max-age・ETag・stale-while-revalidate の使い分けを判断軸から組み立てる。

CDN — 利用者の近くに置いて、オリジンを守る https://shikumikara.dev/topics/network/cdn 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

配信を速くする仕組みであると同時に、オリジンへのアクセスを減らす仕組みでもある。キャッシュキーの設計を誤ると、どちらも機能しない。

DNS — 名前からIPアドレスにたどり着くまで https://shikumikara.dev/topics/network/dns 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

ブラウザが example.com を数字の住所に変換する経路と、その途中に置かれたキャッシュがなぜ事故の原因になるのか。

HTTP/1.1 → 2 → 3 — 何が遅くて、何を直したのか https://shikumikara.dev/topics/network/http-versions 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

バージョンが上がるたびに解かれてきたのは「待ち」の問題。どの待ちがどこで消えたかを知らないと、HTTP/2 にしても速くならない。

TCP/IP — データが相手に届くまでの4層 https://shikumikara.dev/topics/network/tcp-ip 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

アプリが送った1行の文字列が、どう包まれて、どう運ばれ、どう元に戻るのか。障害の切り分けはこの層の把握から始まる。

TLS — 盗聴・改ざん・なりすましを同時に防ぐ https://shikumikara.dev/topics/network/tls 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

HTTPS の鍵マークが保証しているのは3つ。何を保証していて、何を保証していないのかを分けて理解する。

CI/CD — 壊れていることに、人間より先に気づく https://shikumikara.dev/topics/ops/ci-cd 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

自動化そのものが目的ではない。「壊れた変更が本番に届かない」ことと「いつでも戻せる」ことを仕組みで保証する。

コンテナ — 「手元では動く」を構造的に潰す https://shikumikara.dev/topics/ops/container 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

仮想マシンとの違いはどこか。イメージが層でできていることが、ビルド時間とデプロイの両方を決める。

ログと監視 — 誰より先に、壊れていることに気づく https://shikumikara.dev/topics/ops/logging-monitoring 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

ログは調査のため、メトリクスは検知のため、トレースは特定のため。3つの役割を分けて設計する。

テスト戦略 — どこに何枚の網を張るか https://shikumikara.dev/topics/ops/testing-strategy 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

テストは多いほど良いわけではない。壊れやすさ・実行時間・書く手間のバランスをどこで取るか。

Cookie とセッション — 状態を持たない HTTP に記憶を持たせる https://shikumikara.dev/topics/security/cookie-session 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

サーバーが覚えるか、利用者に持たせるか。この選択が、ログアウトの実装可能性とスケール特性をすべて決める。

JWT — 取り消せない代わりに、問い合わせが要らない https://shikumikara.dev/topics/security/jwt 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

署名付きトークンが解いた問題と、その代償。「ステートレスだからスケールする」の裏で何を諦めているのか。

OAuth 2.0 と OIDC — 「代理で使わせる」と「誰かを証明する」は別物 https://shikumikara.dev/topics/security/oauth-oidc 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

認可と認証を混同すると穴が開く。認可コードフローがなぜ遠回りに見える手順を踏むのか、一歩ずつ理由がある。

XSS・CSRF・SQLi — データとコードの境界が壊れる https://shikumikara.dev/topics/security/web-vulnerabilities 2026-09-15T00:00:00+09:00 2026-09-15T00:00:00+09:00

3つの代表的な脆弱性は、どれも「データとして扱うべきものが命令として解釈される」という同じ形をしている。