バックエンド開発者が毎日遭遇する英語の50単語
バックエンド開発に携わっているなら、毎日少なくとも一つのドキュメント・議論・コードレビューに現れる約50の単語があります。全部見たことがあるでしょう。ほとんどは知っているかもしれません。でも一部 — 10〜15語のあいまいに知っているもの — は、ドキュメント読解・アーキテクチャ議論・コードの正確性に実際の問題を引き起こします。
これがそのリストです。
各エントリには正確な定義、最もよく現れるドメイン、コンテキストの中で意味を定着させる使用例を含みます。
ネットワーク & 分散システム
1. throughput（スループット）
システムが単位時間に処理できる作業量。APIでは: リクエスト毎秒。データパイプラインでは: レコード毎分。
「現在のスケールでパイプラインのスループットは毎分50,000イベントです。」
2. latency（レイテンシー）
リクエストを送信してからレスポンスを受信するまでの経過時間。通常ミリ秒(ms)またはマイクロ秒(µs)で測定。
「デプロイ後にP99レイテンシーが800msに急上昇 — 原因を突き止める必要があります。」
3. idempotent / idempotency（冪等性）
何度呼び出しても一度呼び出したときと同じ結果を生成する操作を冪等という。リトライが一般的な決済APIや分散システムで重要。
「Idempotency-Keyヘッダーを受け付けることでchargeエンドポイントを冪等にしてください。」
4. circuit breaker（サーキットブレーカー）
ダウンストリームサービスの障害を検出し、一時的にリクエスト送信を停止して障害の連鎖を防ぐデザインパターン。電気安全装置にちなむ。
「インベントリサービスのサーキットブレーカーが5回連続タイムアウト後にトリップしました。」
5. backoff（バックオフ / 指数バックオフ）
苦しんでいるサービスへの負荷を軽減するため、リトライ間隔を指数関数的に増加させるリトライ戦略（例: 1秒、2秒、4秒、8秒）。
「サンダリングハードを防ぐため、ジッターを使った指数バックオフを実装してください。」
6. rate limiting（レート制限）
特定の時間ウィンドウ内でクライアントが行えるリクエスト数を制限すること。超過するとHTTP 429を返す。
「APIキーごとに毎分1,000リクエストのレート制限を適用しています。」
7. throttling（スロットリング）
レート制限に似ているが、リクエストを拒否するのではなく遅くすることを意味する。サービスがエラーを返すのではなくグレースフルに劣化する。
「高負荷時に検索サービスはリクエストをドロップするのではなくレスポンスをスロットリングします。」
8. graceful degradation（グレースフルデグラデーション）
一部のコンポーネントが失敗したときに完全に失敗するのではなく、部分的な機能を維持するシステムの能力。
「レコメンデーションサービスがダウンしていても、製品ページはグレースフルデグラデーションでロードされるべきです。」
9. failover（フェイルオーバー）
プライマリが失敗したとき、自動的にバックアップシステムまたはコンポーネントに切り替えること。
「データベースのリードレプリカへのフェイルオーバーが10秒以内に完了しました。」
10. load balancing（ロードバランシング）
受信リクエストを複数のサーバーに分散して、特定のサーバーが過負荷になることを防ぐこと。
「ピークトラフィックに対応するため、ロードバランサーの後ろに3番目のインスタンスを追加しました。」
データ & 一貫性
11. reconciliation（照合）
二つのデータレコードセットが一致することを確認するプロセス。金融システムでよく使われる: トランザクションログと銀行レコードの照合。
「毎日の照合ジョブで台帳とStripeの支払いレポートに$3の差異が見つかりました。」
12. eventual consistency（結果整合性）
分散データベースで使われるモデル。データ更新が非同期に伝播する。すべてのノードは最終的に同じデータを持つが、即時ではない。
「結果整合性を使っているため、一部のユーザーは最大30秒間古い在庫数を見る可能性があります。」
13. atomicity（原子性）
トランザクションのすべての操作が一緒に成功するか全て失敗するかという特性 — 部分的な状態なし。
「原子性を保証するため、デビットとクレジットを単一のトランザクションでラップしてください。」
14. schema（スキーマ）
データモデルの定義された構造: フィールド名、データ型、関係、バリデーションルール。
「usersテーブルに必須の'timezone'フィールドを追加するため、古いスキーマを移行中です。」
15. serialization / deserialization（シリアライズ / デシリアライズ）
データ構造を保存または転送の形式に変換すること(シリアライズ)とその逆(デシリアライズ)。
「サービスは処理前にKafkaからイベントペイロードをデシリアライズします。」
16. normalization（正規化）
データの冗長性を減らすためにデータベースを整理すること。「正規化」スキーマは各情報を一度だけ保存し、「非正規化」スキーマはクエリパフォーマンスのためにデータを複製する。
「高い正規化はストレージと更新異常を減らすが、JOINの複雑性を増加させる。」
17. sharding（シャーディング）
キーに基づいてデータを複数のデータベースインスタンス（シャード）に分割することで、データベースを水平パーティショニングすること。
「読み書き負荷を分散させるため、ordersテーブルをuser_idでシャードしています。」
18. replication（レプリケーション）
信頼性と読み取りスケーリングのために、一つのデータベースノード（プライマリ）から一つ以上の他のノード（レプリカ）にデータをコピーすること。
「プライマリからレポートクエリをオフロードするため、3つの読み取りレプリカがあります。」
API設計
19. endpoint（エンドポイント）
APIオペレーションを定義するURL+HTTPメソッドの特定の組み合わせ。
「POST /ordersが新しい注文を作成し、GET /orders/:idがそれを取得します。」
20. webhook（ウェブフック）
サーバー間コールバック: 特定のイベントが発生したときに設定されたURLにHTTP POSTを送信する。
「注文ステータスが'発送済み'に変わったとき、パートナーシステムにウェブフックを送信します。」
21. pagination（ページネーション）
大きな結果セットを順次返される個別のページに分割すること。一般的なパターン: オフセットベース、カーソルベース。
「大きなOFFSET値のパフォーマンス問題を避けるため、カーソルベースのページネーションを実装してください。」
22. deprecation（非推奨）
API機能またはエンドポイントを廃止予定としてマークすること。まだ機能するが将来のバージョンで削除される。
「v1/usersエンドポイントは非推奨になり、2027年3月以降に削除されます。v2/usersに移行してください。」
23. breaking change（破壊的変更）
既存の呼び出し側がコードを更新する必要があるAPIの変更。フィールドの削除、パラメータの名前変更、ステータスコードの変更はすべて破壊的変更。
「'email'フィールドを必須にすることは破壊的変更です — 既存の統合がそれを送信していない可能性があります。」
24. backward compatibility（後方互換性）
既存のクライアントが変更なしに使用できるAPIの更新。新しいオプションフィールドは通常後方互換性があり、フィールドの削除はない。
「新しいオプションフィールドを追加することでv1クライアントとの後方互換性を維持します。」
25. idempotency key（冪等性キー）
サーバーが重複リクエストを安全に検出・処理できるようにするために、リクエストヘッダーに含まれるクライアント生成の一意識別子。
「chargeの前にUUIDをIdempotency-Keyとして生成してください — リクエストが失敗した場合、同じキーでリトライします。」
26. polling（ポーリング）
リソースの状態が変化したかどうかを確認するため、固定間隔でAPIエンドポイントを繰り返し呼び出すこと。
「ジョブステータスエンドポイントを毎秒ポーリングしないでください — ウェブフックを使用するか指数バックオフポーリングを実装してください。」
27. payload（ペイロード）
ヘッダーを除いたHTTPリクエストまたはレスポンスのデータ本体。
「チェックアウト完了イベントのペイロードには注文ID、合計金額、注文明細が含まれています。」
認証 & セキュリティ
28. authentication（認証）
身元の確認 — 誰であるかを証明すること。通常、認証情報（ユーザー名/パスワード）、トークン（JWT）、または証明書を通じて。
「APIはAuthorizationヘッダーのBearerトークンによる認証を要求します。」
29. authorization（認可）
権限の確認 — 何をすることが許可されているかを証明すること。認証後に行われる。
「ユーザーは認証されているが、注文を削除する認可がない — 'viewer'ロールしか持っていない。」
30. JWT（JSON Web Token）
エンコードされたクレーム（ユーザーID、ロール、有効期限）を自己完結して含むコンパクトでURLセーフなトークン形式。署名キーを使用してデータベース検索なしで検証可能。
「JWTには'roles'クレームが含まれています — 管理者アクセスを許可する前にサーバーサイドで検証してください。」
31. OAuth 2.0
パスワードを公開せずにユーザーの代わりにアプリケーションがユーザーリソースにアクセスできるようにする認可フレームワーク。
「OAuth 2.0を使用してユーザーがアプリにGoogle Calendarへの読み取りアクセスを許可できるようにします。」
32. scope（スコープ）
OAuthでは: アクセストークンが許可する特定の権限。トークンは必要最小限のスコープを持つべき。
「'calendar.readonly'スコープのみをリクエストしてください — 必要のない書き込みアクセスを要求しないこと。」
33. refresh token（リフレッシュトークン）
ユーザーに再認証を求めることなく、新しい短期アクセストークンを取得するために使用される長期有効な認証情報。
「リフレッシュトークンを安全に保管してください — パスワードと同じくらい機密性が高い。」
34. HMAC
ハッシュベースのメッセージ認証コード。メッセージとシークレットキーから計算される暗号署名。データの整合性と真正性を検証するために使用。
「イベントを処理する前にHMAC-SHA256を使用してStripeのウェブフック署名を検証してください。」
パフォーマンス
35. caching（キャッシュ）
コストのかかる操作の結果を保存して、将来のリクエストをより速く提供できるようにすること。レベル: インメモリ（Redis）、CDN、ブラウザ。
「データベース負荷を減らすため、ユーザーのプロファイルデータを5分のTTLでRedisにキャッシュします。」
36. TTL（Time-To-Live）
キャッシュされたアイテムが古くなって更新が必要になるまでの有効期間。
「在庫数に60秒のTTLを設定してください — チェックアウト以外のページなら許容できる古さです。」
37. cache invalidation（キャッシュ無効化）
基になるデータが変更されたときに古くなったキャッシュエントリを削除または更新するプロセス。
「整合性を保つため、アイテムの追加/削除のたびにカートキャッシュを更新してください — TTLだけに依存しないこと。」
38. N+1 query（N+1クエリ）
パフォーマンスアンチパターン: N件のレコードのリストを取得し、次に関連データを取得するためにレコードごとに追加クエリを1回実行し、合計N+1のデータベースクエリ。
「ordersエンドポイントにN+1クエリがありました — 単一クエリでline itemsをJOINするためにeager loadingを使用してください。」
39. index（インデックス）
追加のストレージと書き込み時間を犠牲にしてクエリルックアップ速度を向上させるデータ構造。
「注文ルックアップを高速化するため、(user_id, created_at DESC)に複合インデックスを追加してください。」
40. connection pooling（コネクションプーリング）
リクエストごとに新しい接続を作成するオーバーヘッドを避けるため、再利用可能なデータベース接続のセットを維持すること。
「予想されるピーク時の並行クエリ数に合わせてコネクションプールサイズを設定してください。」
信頼性 & オブザーバビリティ
41. SLA（サービスレベルアグリーメント）
特定のサービスレベルへの契約上のコミットメント。通常アップタイムで表現（例: 99.9% = 年間約8.7時間のダウンタイム）。
「SLAは99.9%のアップタイムを保証しています — 計画外の停止はすべてそのバジェットから消費されます。」
42. SLO（サービスレベル目標）
サービス信頼性の内部目標。SLOは目標; SLAは契約。
「P99レイテンシーのSLOは300msです — 7日間の平均が超えたときにアラートを出します。」
43. observability（オブザーバビリティ）
メトリクス・ログ・トレースなどの外部出力からシステムの内部状態を推測できる程度。
「マイクロサービスの境界を越えたオブザーバビリティを向上させるため、分散トレーシングを追加してください。」
44. distributed tracing（分散トレーシング）
単一のリクエストが複数のマイクロサービスを通過する際に追跡し、サービス間のログを相関させるためにトレースIDを付与する。
「すべてのダウンストリームサービス呼び出しにトレースを伝播させるためにX-Trace-IDヘッダーを使用してください。」
45. idempotent consumer（冪等コンシューマー）
副作用なしに同じメッセージを何度でも安全に処理するように設計されたメッセージキューコンシューマー。at-least-once配信システムで必須。
「payment consumerを冪等にしてください — Kafkaからの重複メッセージは時々届きます。」
コード & プロセス
46. refactoring（リファクタリング）
外部の振る舞いを変えずに内部品質 — 可読性、保守性、パフォーマンス — を改善するために既存のコードを再構造化すること。
「リトライロジックを共有ユーティリティに抽出するためにpaymentモジュールをリファクタリングしました。」
47. regression（リグレッション）
以前機能していた機能を壊す変更によって導入されたバグ。
「デプロイがチェックアウトフローにリグレッションを引き起こしました — 前のビルドに戻しています。」
48. dependency（依存関係）
コードが依存するライブラリ、サービス、またはコンポーネント。依存関係の管理はビルドシステムの中核的な関心事。
「アップストリームの変更による予期しない破壊を防ぐため、ロックファイルで依存関係のバージョンを固定してください。」
49. race condition（競合状態）
システムの正確性が並行操作のタイミングに依存する場合に発生するバグ。
「データベースロックなしで、2つの同時チェックアウトリクエストが在庫をゼロ以下に減らせます — これが競合状態です。」
50. dead letter queue（デッドレターキュー / DLQ）
リトライ制限を超えた後に処理に失敗したメッセージが送られるキュー。手動の調査と再生のため。
「失敗したpaymentイベントをDLQにルーティングし、再生前に調査するためにオンコールにアラートを送ってください。」
座学なしでこの50語を習得する
このリストの各単語は、次の2週間の通常の開発作業で再び目にするものです。「曖昧に知っている」から「確実に知っている」への移行に最も効率的な方法は語彙コースではありません — あなたの脳が利用可能な瞬間に届けられるスペースドリピティションです。
Wordropではカスタム単語リストをインポートでき、MacのメニューバーでCIビルド中・ミーティングの合間・昼休みに自動的にレビューセッションを届けます。上の50語はすぐに使える出発点です。