REST API は一度公開すると変更しにくいため、設計段階での判断が重要です。後悔しないための設計原則をまとめます。
\n\nURL はアクションではなくリソース（名詞）を表します。
\n# 悪い例: 動詞を使っている\nGET /getUsers\nPOST /createUser\nPOST /deleteUser?id=123\n\n# 良い例: リソース + HTTP メソッドで表現\nGET /users # 一覧取得\nPOST /users # 作成\nGET /users/123 # 1件取得\nPUT /users/123 # 全体更新\nPATCH /users/123 # 部分更新\nDELETE /users/123 # 削除\n階層関係は URL で表現します。
\nGET /users/123/orders # ユーザー123の注文一覧\nGET /users/123/orders/456 # 特定の注文\n| コード | \n意味 | \n使いどころ | \n
|---|---|---|
| 200 | \nOK | \n取得・更新成功 | \n
| 201 | \nCreated | \nリソース作成成功 | \n
| 204 | \nNo Content | \n削除成功（ボディなし） | \n
| 400 | \nBad Request | \nバリデーションエラー | \n
| 401 | \nUnauthorized | \n未認証 | \n
| 403 | \nForbidden | \n認可エラー（ログイン済みだが権限なし） | \n
| 404 | \nNot Found | \nリソースが存在しない | \n
| 409 | \nConflict | \n重複など競合 | \n
| 422 | \nUnprocessable Entity | \n意味的に不正なリクエスト | \n
| 500 | \nInternal Server Error | \nサーバー側の予期しないエラー | \n
200 をすべてに使ってエラーをボディで返すのはやめましょう。
エラー時のレスポンス形式を統一しておくと、クライアント側の実装が楽になります。
\n{\n "error": {\n "code": "VALIDATION_ERROR",\n "message": "入力値が不正です",\n "details": [\n { "field": "email", "message": "有効なメールアドレスを入力してください" },\n { "field": "age", "message": "18歳以上である必要があります" }\n ]\n }\n}\ncode にはマシンリーダブルな文字列を入れると、クライアントがプログラムで判定できます。
API を公開した後に破壊的変更をする場合はバージョンを切ります。
\n# URL パスにバージョンを含める（最も一般的）\n/v1/users\n/v2/users\n\n# ヘッダーでバージョン指定（URL をきれいに保ちたい場合）\nAccept: application/vnd.myapp.v2+json\n大量データの取得にはページネーションを必ず実装します。
\n# カーソルベース（SNS のような無限スクロールに向く）\nGET /posts?cursor=eyJpZCI6MTAwfQ&limit=20\n\n# オフセットベース（ページ番号指定に向く）\nGET /products?page=3&per_page=20\nレスポンスには次のページの情報を含めます。
\n{\n "data": [...],\n "pagination": {\n "next_cursor": "eyJpZCI6MTIwfQ",\n "has_more": true\n }\n}\n設計に迷ったときは「クライアントを実装する人が直感的に使えるか」を基準にすると判断しやすいです。
\n","date_published":"Sun, 29 Mar 2026 00:00:00 GMT"},{"id":"https://mejiro877.github.io/lume-blog/posts/sql-performance/","url":"https://mejiro877.github.io/lume-blog/posts/sql-performance/","title":"SQL クエリのパフォーマンス改善","content_html":"アプリケーションが遅い原因の多くはデータベースにあります。インデックスの使い方から、よくあるアンチパターンまで、クエリ改善の基本を整理します。
\n\nEXPLAIN で実行計画を確認するチューニングの前に、データベースがどのようにクエリを実行しているか確認します。
\nEXPLAIN ANALYZE\nSELECT * FROM orders\nWHERE user_id = 123 AND status = 'pending';\n注目するポイント:
\nSeq Scan → テーブル全体を走査（遅い）Index Scan → インデックスを使用（速い）rows の見積もりと実際の差が大きい → 統計情報が古い複合インデックスは左端のカラムから順に効きます。
\n-- このインデックスは (user_id, status) の順\nCREATE INDEX idx_orders_user_status ON orders(user_id, status);\n\n-- 有効: user_id が先頭にある\nSELECT * FROM orders WHERE user_id = 123 AND status = 'pending';\nSELECT * FROM orders WHERE user_id = 123;\n\n-- 無効: user_id を含まない\nSELECT * FROM orders WHERE status = 'pending';\nカーディナリティ（値の種類数）が高いカラムを先頭に置くのが基本です。
\n-- 関数をかけるとインデックスが効かない\nWHERE UPPER(email) = 'USER@EXAMPLE.COM' -- NG\nWHERE email = 'user@example.com' -- OK\n\n-- 型が違うと暗黙変換でインデックスが効かないことがある\nWHERE user_id = '123' -- user_id が INTEGER の場合は注意\n\n-- LIKE の前方一致はOK、後方一致はNG\nWHERE name LIKE 'John%' -- OK\nWHERE name LIKE '%John' -- NG（インデックス非効率）\nループの中でクエリを発行するのは最も頻繁に見るパフォーマンス問題です。
\n-- N+1: ユーザーごとに注文数を取得 (1 + N 回のクエリ)\nSELECT * FROM users;\n-- ↓ ループ内で N 回実行\nSELECT COUNT(*) FROM orders WHERE user_id = ?;\n\n-- 改善: JOIN で1回にまとめる\nSELECT u.id, u.name, COUNT(o.id) AS order_count\nFROM users u\nLEFT JOIN orders o ON o.user_id = u.id\nGROUP BY u.id, u.name;\n-- SELECT * は避ける\nSELECT * FROM products; -- NG\n\n-- 必要なカラムだけ取得\nSELECT id, name, price FROM products; -- OK\n\n-- LIMIT を忘れない\nSELECT id, name FROM products\nORDER BY created_at DESC\nLIMIT 20;\n相関サブクエリは行ごとに実行されるため遅くなりがちです。
\n-- 遅い: 相関サブクエリ\nSELECT name,\n (SELECT COUNT(*) FROM orders WHERE user_id = u.id) AS cnt\nFROM users u;\n\n-- 速い: JOIN で書き換え\nSELECT u.name, COUNT(o.id) AS cnt\nFROM users u\nLEFT JOIN orders o ON o.user_id = u.id\nGROUP BY u.id, u.name;\nEXPLAIN ANALYZE で問題のあるクエリを特定するSELECT * をやめ、必要なカラムだけ取得するまずスロークエリログを有効にして、実際に遅いクエリを特定するところから始めましょう。
\n","date_published":"Sun, 22 Mar 2026 00:00:00 GMT"},{"id":"https://mejiro877.github.io/lume-blog/posts/typescript-tips/","url":"https://mejiro877.github.io/lume-blog/posts/typescript-tips/","title":"TypeScript 型安全テクニック","content_html":"TypeScript は「型を書けばいい」だけではなく、型システムをうまく使うことでバグを設計レベルで防げます。日常的に使えるテクニックをまとめます。
\n\nunknown を any の代わりに使うany は型チェックを完全に無効にしますが、unknown は「何か分からない値」として扱い、使う前に型チェックを強制します。
// 危険: any はどこでも使えてしまう\nfunction parseData(input: any) {\n return input.name.toUpperCase(); // 実行時エラーの可能性\n}\n\n// 安全: unknown は型ガードが必要\nfunction parseData(input: unknown) {\n if (typeof input === "object" && input !== null && "name" in input) {\n return (input as { name: string }).name.toUpperCase();\n }\n throw new Error("Invalid input");\n}\n外部 API のレスポンスや JSON パースの結果には unknown を使いましょう。
フラグのような boolean の組み合わせより、Union 型で状態を明示するほうが安全です。
// 問題: isLoading と error が同時に true になれる\ntype State = {\n isLoading: boolean;\n data: User | null;\n error: string | null;\n};\n\n// 改善: 状態が排他的になる\ntype State =\n | { status: "idle" }\n | { status: "loading" }\n | { status: "success"; data: User }\n | { status: "error"; error: string };\n\nfunction render(state: State) {\n switch (state.status) {\n case "success":\n return state.data.name; // data が確実に存在する\n case "error":\n return state.error; // error が確実に存在する\n }\n}\nsatisfies 演算子で型チェックしながら型推論を保つTypeScript 4.9 で追加された satisfies は、型の整合性を確認しつつ推論された型を保持します。
type Config = {\n port: number;\n host: string;\n};\n\n// as を使うと推論が失われる\nconst config = { port: 3000, host: "localhost" } as Config;\nconfig.port; // number\n\n// satisfies なら具体的な型が残る\nconst config = { port: 3000, host: "localhost" } satisfies Config;\nconfig.port; // 3000 (リテラル型)\n設定オブジェクトの定義によく使います。
\n同じ型チェックを複数箇所に書くなら、型ガード関数にまとめます。
\ntype ApiResponse<T> =\n | { success: true; data: T }\n | { success: false; error: string };\n\nfunction isSuccess<T>(res: ApiResponse<T>): res is { success: true; data: T } {\n return res.success === true;\n}\n\nconst response = await fetchUser();\nif (isSuccess(response)) {\n console.log(response.data); // T 型として使える\n}\nReadonly と as const でミュータブルなバグを防ぐ意図せず変更されては困るオブジェクトは読み取り専用にします。
\n// 定数オブジェクト\nconst ROLES = ["admin", "editor", "viewer"] as const;\ntype Role = typeof ROLES[number]; // "admin" | "editor" | "viewer"\n\n// 関数の引数を変更不可にする\nfunction process(config: Readonly<Config>) {\n // config.port = 8080; // エラー\n}\nany より unknown — 型安全を保ちつつ柔軟にsatisfies — 型チェックと型推論を両立as const / Readonly — 不変性をコンパイル時に保証型を「注釈」ではなく「設計ツール」として使うと、TypeScript の本領が発揮されます。
\n","date_published":"Sun, 15 Mar 2026 00:00:00 GMT"},{"id":"https://mejiro877.github.io/lume-blog/posts/git-workflow/","url":"https://mejiro877.github.io/lume-blog/posts/git-workflow/","title":"Git ブランチ戦略まとめ","content_html":"個人開発では main ブランチだけで事足りますが、チームで開発するとブランチ管理が重要になります。代表的な戦略と、それぞれの使いどころを整理します。
最もシンプルな戦略です。ブランチは main と feature/* の2種類だけ。
main\n └── feature/add-login\n └── feature/fix-typo\n手順:
\nmain から feature/xxx を切るmain へマージ向いている場面: 継続的デプロイができるプロダクト、スタートアップ、小〜中規模チーム。
\ngit switch main\ngit pull origin main\ngit switch -c feature/add-login\n\n# 実装...\n\ngit push origin feature/add-login\n# → GitHub で PR を作成\nバージョン管理が必要なアプリ（モバイルアプリ、パッケージなど）向けです。
\nmain ← 本番リリース済みコード\ndevelop ← 開発統合ブランチ\n └── feature/xxx\n └── release/1.2.0\n └── hotfix/crash-fix\nブランチの役割:
\n| ブランチ | \n役割 | \n
|---|---|
main | \nリリース済みコード | \n
develop | \n次のリリースへの統合 | \n
feature/* | \n機能開発 | \n
release/* | \nリリース前の最終調整 | \n
hotfix/* | \n本番の緊急修正 | \n
複雑な分、厳密なリリース管理が可能です。
\nどの戦略を採用しても、コミットメッセージのルールを決めておくと git log が読みやすくなります。
feat: ログイン機能を追加\nfix: パスワードリセット時のエラーを修正\ndocs: README にセットアップ手順を追記\nrefactor: 認証ロジックをサービス層へ移動\nchore: 依存ライブラリを更新\nConventional Commits に従うと、CHANGELOGの自動生成もできます。
\nブランチ戦略と同じくらい重要なのが PR のサイズです。
\n大きな機能はフラグで隠しながら小さく分割してマージするのが現実的です。
\nツールよりもチームの合意が大切です。
\n","date_published":"Sun, 08 Mar 2026 00:00:00 GMT"},{"id":"https://mejiro877.github.io/lume-blog/posts/docker-basics/","url":"https://mejiro877.github.io/lume-blog/posts/docker-basics/","title":"Docker 入門 — イメージとコンテナの基礎","content_html":"Docker を使い始めたとき、「イメージ」と「コンテナ」の違いで混乱した経験はないでしょうか。この記事ではその概念を整理し、日常的な開発で使う基本コマンドをまとめます。
\n\nイメージはコンテナを起動するための設計図（テンプレート）です。読み取り専用で、Dockerfile から作られます。
コンテナはイメージを実際に起動したものです。書き込み可能な実行環境で、何度でも起動・停止できます。
\nDockerfile → (build) → イメージ → (run) → コンテナ\nクラスとインスタンスの関係に近いイメージです。
\n# イメージを取得\ndocker pull node:22\n\n# コンテナを起動（起動後すぐ削除）\ndocker run --rm node:22 node --version\n\n# バックグラウンドで起動\ndocker run -d -p 3000:3000 --name my-app my-image\n\n# 起動中のコンテナ一覧\ndocker ps\n\n# コンテナの中に入る\ndocker exec -it my-app bash\n\n# コンテナを停止・削除\ndocker stop my-app && docker rm my-app\nFROM node:22-alpine\n\nWORKDIR /app\n\nCOPY package*.json ./\nRUN npm ci\n\nCOPY . .\n\nEXPOSE 3000\nCMD ["node", "server.js"]\nCOPY と RUN はキャッシュが効くので、変更頻度の低いものを上に書くのがポイントです。package.json を先にコピーして npm ci することで、ソースコードを変えても依存関係の再インストールが走りません。
複数コンテナを管理するときは docker compose が便利です。
services:\n app:\n build: .\n ports:\n - "3000:3000"\n depends_on:\n - db\n db:\n image: postgres:16\n environment:\n POSTGRES_PASSWORD: password\ndocker compose up -d # 起動\ndocker compose down # 停止\ndocker compose logs -f # ログ確認\nDocker の基本は「イメージを作って、コンテナとして動かす」この一点です。最初は docker run と docker compose up だけ覚えておけば十分です。慣れてきたら Dockerfile の最適化（マルチステージビルドなど）に進みましょう。