HTTP、正規表現、SQL。
この3つは、フレームワークが何度入れ替わっても残り続けます。
だから学習の投資対効果が、他とは比較にならないほど高い。
共通点があります。どれも半世紀前後を生き延びています。
| 技術 | 成立 | 現在 |
|---|---|---|
| 正規表現 | 1950年代に理論、1968年に実装 | ほぼそのまま使われている |
| SQL | 1974年に IBM で考案 | ほぼそのまま使われている |
| HTTP | 1991年 | 版は上がったが、考え方は同じ |
この間に、無数のフレームワークが登場して消えました。第2部から第4部で扱った Next.js も、いずれ別のものに置き換わります。第3部で見たとおり、Gemini CLI は2026年に個人向け提供を終えました。
一方で grep は半世紀前の設計のまま動いています。SELECT も同じです。
Next.js を学ぶ時間は、Next.js が使われている間だけ回収できます。この3つを学ぶ時間は、おそらく生涯回収し続けられます。
しかも3つとも、覚える量が驚くほど少ない。実務で必要なのは、それぞれ1時間程度の内容です。
| 技術 | いま効く場面 |
|---|---|
| HTTP | MCP サーバーの自作。API の疎通確認。エラーの切り分け |
| 正規表現 | シェル、エディタの一括置換、コード、CSV の整形。すべてで同じ記法が使える |
| SQL | Drizzle が生成するクエリの検証。遅い原因の特定。Supabase の RLS |
リクエストを送り、レスポンスが返る。ただそれだけの取り決めです。
HTTP には重要な性質があります。ステートレス ── サーバーは前回のやりとりを覚えていません。
第5部で見た「モデルはリクエスト間で何も記憶していないため、毎回コンテキスト全体を送り直している」と、まったく同じ構造です。覚えていない相手と話すには、毎回すべてを持参するしかありません。
ログイン状態が保たれているように見えるのは、ブラウザが毎回トークンを送り直しているからです。サーバーが覚えているのではありません。
返ってくる側も同じ形です。
| メソッド | 意味 | 2回送ったら |
|---|---|---|
GET | 取得する。何も変えない | 同じ結果 |
POST | 新しく作る | 2つできる |
PUT | 丸ごと置き換える | 同じ結果 |
PATCH | 一部だけ更新する | 場合による |
DELETE | 削除する | 同じ結果 |
右の列が実務的に重要です。何度送っても結果が変わらない性質を冪等（べきとう）と呼びます。
通信が途中で切れたとき、再送してよいかどうかがこれで決まります。GET は安心して再送できます。POST は再送すると二重登録になります。「送信ボタンを2回押さないでください」という注意書きの正体です。
API キーやトークンは Authorization ヘッダに入れます。URL に含めてはいけません。
URL はあらゆる場所に残ります。サーバーのアクセスログ、ブラウザの履歴、プロキシの記録、他サイトへ飛ぶときのリファラ。ヘッダはこれらに残りません。
第4部の "use client" の話と同じ系統の注意です。秘密情報を、残る場所に置かない。
3桁の数字の、最初の1桁だけで用が足ります。
| コード | 意味 | 実際の原因 |
|---|---|---|
401 | 誰だか分からない | トークンが無い、期限切れ、形式が違う |
403 | 誰だか分かるが、許可がない | 権限設定の問題。Supabase なら RLS |
404 | その場所に無い | URL の誤り。または「見せたくないので無いことにした」 |
429 | 送りすぎ | レート制限。時間をおいて再送する |
500 | サーバー内部でエラー | 相手側のコードが落ちている |
この2つを混同すると、原因の切り分けで遠回りします。
401 は「名乗っていない、または名乗り方が間違っている」。認証情報を見直します。403 は「名乗れているが、それを見る資格がない」。権限設定を見直します。
Supabase で 403 が返るなら、認証は通っていて RLS に弾かれている可能性が高い。この判断が1秒でできるかどうかで、調査時間がまるで変わります。
MCP サーバーを自作されている場合、curl で直接叩けると切り分けが速くなります。アプリ側が悪いのか、サーバー側が悪いのかを、1コマンドで分けられるからです。
個別の文字列ではなく、パターンを指定する記法です。
名前の由来は「regular expression（正規な表現）」で、1950年代の数学理論に始まり、1968年に Ken Thompson がテキストエディタへ実装しました。grep という名前も、当時のエディタのコマンド g/re/p から来ています。
| 記号 | 意味 | 例 |
|---|---|---|
. | 任意の1文字 | a.c → abc, a1c |
* | 直前を0回以上 | ab* → a, ab, abb |
+ | 直前を1回以上 | ab+ → ab, abb |
? | 直前を0回か1回 | ab? → a, ab |
[ ] | この中のどれか1文字 | [0-9] → 数字1文字 |
\d | 数字1文字 | [0-9] と同じ |
^ | 行の先頭 | ^社員 → 行頭が「社員」 |
$ | 行の末尾 | 円$ → 行末が「円」 |
{n} | ちょうど n 回 | \d{4} → 数字4桁 |
( ) | まとめる・取り出す | 後述 |
| | または | 営業|管理 |
VS Code の検索欄でも、右端の .* ボタンを押せば同じ記法が使えます。一括置換のときに効きます。
丸括弧で囲んだ部分は、あとから取り出せます。置換では $1 や \1 で参照します。
数百行の CSV の書式を揃える、といった作業がこれで数秒になります。
2つだけ知っておけば、大きな事故は避けられます。
* と + は、可能な限り長く取ろうとします。これが直感に反します。
*? や +? のように ? を後ろに付けると、最短一致に変わります。「思ったより多く取れてしまう」ときは、まずこれを疑ってください。
| 対象 | 理由 | 代わりに |
|---|---|---|
| HTML の解析 | 入れ子構造は正規表現では原理的に扱えない | 専用のパーサ |
| 複雑な CSV | 引用符の中のカンマや改行を判別できない | CSV ライブラリ |
| メールアドレスの厳密な検証 | 正式な規格が複雑すぎる | 大雑把に見て、実際に送って確かめる |
| 公的番号の検証 | 桁数は見られるが、検査用数字は計算が要る | 形の確認は正規表現、妥当性は別途 |
^\d{12}$ は「12桁の数字である」ことしか確認しません。マイナンバーには検査用数字が含まれているため、形が合っていても有効な番号とは限りません。
正規表現は形の確認まで、と割り切るのが安全です。妥当性の判定は、その分野の規則に従った別の処理になります。この線引きは、AI が生成したコードでも曖昧にされがちな箇所です。
正規表現は、頭の中で正しさを確認しにくい記法です。必ず実データで試してから使ってください。
とくに一括置換の前は、まず grep で「何件当たるか」を確認します。想定より多ければ、パターンが広すぎます。
Drizzle は SQL を生成します。生成物を読めないと、検算できません。
第3部でシェルで書いた処理と、まったく同じことをしています。
| シェル | SQL |
|---|---|
cat / tail | FROM |
awk '$5 >= 20' | WHERE |
sort -k4 -nr | ORDER BY ... DESC |
head -10 | LIMIT 10 |
cut -f3 | SELECT の列指定 |
ここが最初につまずく箇所です。SELECT を先頭に書きますが、実際には5番目に実行されます。
この順序が分かると、次の挙動が説明できます。
| 現象 | 理由 |
|---|---|
WHERE で SELECT の別名が使えない | WHERE のほうが先に動くため、別名がまだ存在しない |
ORDER BY では別名が使える | SELECT の後だから |
WHERE で集計関数が使えない | 集計は GROUP BY 以降。WHERE はその前 |
集計後に絞るには HAVING | GROUP BY の後に動く条件指定だから |
| 種類 | 結果 | 使う場面 |
|---|---|---|
INNER JOIN | 両方に存在する行だけ | 給与のある従業員だけを見たい |
LEFT JOIN | 左は全部、右は無ければ空欄 | 給与登録漏れを見つけたい |
右列の違いが実務では大きい。INNER JOIN だと、給与が登録されていない従業員が結果から静かに消えます。「人数が合わない」の典型的な原因です。
インデックスの欠落か、N+1 か。この2つで大半が説明できます。
インデックスは索引です。本の巻末索引と同じ役割で、「この語はこのページ」という対応表を別に持っておく仕組みです。
索引が無ければ、目的の語を探すのに1ページ目から全部めくることになります。データベースでも同じで、これを全件走査と呼びます。1万件なら気づきませんが、100万件になると止まります。
EXPLAIN の結果に Seq Scan（全件走査）と出ていれば索引が効いていません。Index Scan なら効いています。この2語だけ見分けられれば十分です。
索引は書き込みを遅くします。行を1つ追加するたびに、索引も更新する必要があるからです。
付けるのは WHERE、JOIN、ORDER BY で実際に使っている列だけにしてください。「念のため全列に」は逆効果です。
ORM を使うと必ず出会う罠です。従業員100人の一覧に給与を並べるだけで、101回の問い合わせが飛びます。
N+1 は、AI が生成したコードでも普通に発生します。ループの中にデータベースへの問い合わせがあれば、それが該当します。
開発中はデータが少ないので気づきません。顧問先のデータを入れた本番で初めて表面化します。第2部に書いた「出てきたものを疑う力」が、最も具体的に効く場面のひとつです。
確認は簡単で、ループの中にデータベース呼び出しがないかを見るだけです。
行単位のアクセス制御（RLS）は、SQL の条件式として記述します。
USING の中身が、WHERE と同じ条件式です。これが読めないと、自分が何を許可したのかを確認できません。
顧問先のデータを扱う以上、ここは AI に任せきりにせず、自分の目で読める状態にしておく価値があります。
同じ性質を持っているから、まとめて1つの資料にしました。
| 性質 | 内容 |
|---|---|
| 寿命が長い | 半世紀近く生き残り、当面消える気配がない |
| 移植できる | 言語・フレームワーク・OS を問わず同じ知識が通用する |
| 量が少ない | 実務に必要な範囲は、それぞれ1時間程度 |
| 検算に使える | AI が生成したものを疑うための道具になる |
最後の行が、この資料の趣旨です。
第2部の冒頭で、AI が強いのは真ん中（実装）で、人間に残るのは両端 ── 何を作るかの指定と、出てきたものの検証 ── だと書きました。
この3つは、後者のための道具です。
| 技術 | 検算できるようになること |
|---|---|
| HTTP | エラーが自分側か相手側か。認証情報を安全な場所に置いているか |
| 正規表現 | そのパターンが広すぎないか。形の確認と妥当性判定を混同していないか |
| SQL | クエリが N+1 になっていないか。RLS が意図どおりか |
正規表現 → SQL → HTTP を勧めます。
正規表現は今日から使えて、効果が即座に出ます。SQL は Supabase を使っている以上、避けて通れません。HTTP は MCP サーバーの自作で詰まったときに読めば足ります。
いずれも、通読してから使うものではありません。手を動かして、詰まったら引くという使い方が向いています。
第1部でシェルの原則、第2部で層の全体像、第3部で実例、第4部で Node と Next.js の内側、第5部で費用構造、そして第6部で寿命の長い技能を扱いました。
第1部に書いた1969年の設計思想が、この3つにもそのまま流れています。一つのことをうまくやり、テキストを共通語にし、組み合わせて使う。
道具は入れ替わります。原則は残ります。