title: 用語集 icon: 📖 card_desc: 本書で出た言葉を読み仮名（英字の読み方）付きでさっと引ける辞書 slug: 14-glossary

14 用語集 — 読み方が分からない言葉を引く辞書

専門用語は「読み方」も含めて最初の壁です。「クロンだと思ってたらクーロンだった」みたいな罠がたくさんあります。本書で使った用語をまとめた辞書です。

この辞書の使い方

読み仮名は英字綴りの語にだけ付けています（CI＝シーアイ、YAML＝ヤムル等）。カタカナ語・漢字語は自力で読めるので読み仮名なし。

複数読みがある英字語は通称を併記（例: Cron は「クロン」に見えますが、現場では「クーロン」が通説）。

読み仮名のあいうえお順 で並んでいます。英字略語（CI・API など）も「シーアイ」「エーピーアイ」の読みで行に並ぶので、似た略語を見比べられます。

〔第○章〕 は、その用語を詳しく解説した本編の章への道しるべです。

🔖 筆者の実例 の枠（コラム）がある用語は、汎用解説に加えて自作プロジェクトでの使われ方を補足しています。

あ行

あ

ACID（アシッド）— トランザクションが満たすべき4つの整合性の性質（原子性・一貫性・隔離性・耐久性）。お金等の絶対に狂ってはいけないデータは ACID の強い RDB が基本。〔第7章〕

💡 使い方: 決済など「絶対に途中で止まってはいけない」処理は ACID を満たす RDB で。「全て成功」か「全てなかったこと」のどちらかが保証される。

API（エーピーアイ／Application Programming Interface）— プログラム同士が通信するための「約束事」。〔第3章〕

💡 使い方: 天気アプリが「気象庁の API を叩いて明日の天気を取得」する等。人間が画面を操作するのでなく、プログラム同士の窓口。LINE Bot も LINE の API 経由でメッセージを送受信。

IDOR（アイディーオーアール／Insecure Direct Object Reference）— URL の ID を書き換えるだけで他人データにアクセスできる脆弱性。認可チェック忘れの代表例。〔第5章〕

💡 使い方: URL の ?id=123 を ?id=124 に書き換えただけで他人の予約が見えた＝IDOR。「ログインは通った」だけでなく「この人はこのデータを見てよいか」の認可チェックが漏れていた。

アラート（alert）— 監視で異常を検知した時に人に知らせる通知。閾値（限界値）を超えた等の条件で発火。多用しすぎると「アラート疲労」に。〔第8章〕

💡 使い方: 「CPU使用率90%超でアラート発報→Slackに通知」等。ただし毎日鳴るアラートは次第に無視される（アラート疲労）ので、本当に人間が見るべき時だけ鳴らす設計が要る。

RDB（アールディービー／Relational Database／リレーショナルデータベース）— データを**表（テーブル）**で管理する方式。SQL で操作し、データの整合性が強い。〔第7章〕

💡 使い方: 顧客管理・注文管理等、「表で整理できて整合性が要る」データは RDB。SQL で「先月売上上位10件」等の集計が柔軟にできる（→ NoSQL は不向きな場合が多い）。

RBAC（アールビーエーシー／役割ベースアクセス制御）— 「管理者・一般」等の役割で権限を管理する認可の方式。〔第5章〕

💡 使い方: 「管理者ロール」「一般ロール」等の役割で権限を分ける。新しい人には役割を割り当てるだけで権限が設定済（人ごとに個別設定しない）。

🔖 筆者の実例: 自作の予約管理システム（reserve-optimizer）では、予約の取得・作成・取消を行う REST API を設計し、フロントと GAS（Google Apps Script）の間を HTTP で結んでいます。

い

委譲（delegation／「任せる」）— 自分の代わりに限られたことだけを外部に許可する仕組み（OAuth の核心）。〔第5章〕

💡 使い方: 「パスワードを渡さずにアプリに権限を貸す」＝委譲。全部でなく「限られたことだけ任せる」を安全に実現するのが OAuth。

dependency hell（依存地獄／dependency hell）— 依存ライブラリの版の矛盾で身動きが取れなくなる状態。SemVer・ロックファイル・棚卸しで防ぐ。〔第10章〕

💡 使い方: 「ライブラリ A は B v2 必要、C は B v3 必要」で矛盾して動かない状態。ロックファイルで版を固定し、定期的な棚卸しが予防策。

イメージ（image）— コンテナの設計図（読み取り専用のテンプレート）。イメージを起動するとコンテナ（実体）が動き出す。1イメージからコンテナを複数起動できる。〔第6章〕

💡 使い方: 「イメージ＝設計図、コンテナ＝実体」。同じイメージから開発・本番で同じ環境のコンテナを何個でも作れる（環境差の言い訳が消える）。

インデックス（index／「索引」）— 本の巻末の索引のように、特定の列から高速にデータを見つける仕組み。ただし作成・更新コストもかかり、貼りすぎると書き込みが遅くなる。〔第7章〕

💡 使い方: 「メールアドレスで素早く検索したい」列にインデックスを張る。ただし書き込み時に索引更新のコストがかかるので、何でもかんでも張らない。

え

SQL（エスキューエル／Structured Query Language／「シークェル」とも）— RDB を操作するための共通言語。「このデータを取得/更新して」をほぼ共通の文法で書ける。〔第7章〕

💡 使い方: 「先月売上上位10件を取得」を SELECT ... WHERE ... ORDER BY ... LIMIT 10 のような共通文法で書ける。RDB なら方言があっても基本は同じ。

SQLite（エスキューライト）— データベース全体がファイル1つに収まる軽量な RDB。サーバー不要で導入が簡単だが、同時書き込みに弱い。〔第7章〕

💡 使い方: 小規模アプリやスマホ組み込みで「サーバー不要・ファイル1つ」の手軽さが活きる。ただし同時書き込みが多い処理には不向き（サーバー型 RDB へ）。

HTTP（エイチティーティーピー／HyperText Transfer Protocol）— Web の通信で事実上の標準になっている「リクエストとレスポンス」の約束事。〔第3章〕

💡 使い方: ブラウザが「このページ見せて」とリクエストし、サーバーが HTML を返す＝HTTP の基本形。ステータスコード（200 OK／404 等）で結果を伝える。

HTTPS（エイチティーティーピーエス）— HTTP を暗号化したもの（TLS/SSL で通信を守る）。パスワード等の送受信に必須。現場では「エッチティーティーピーエス」とも。〔第3章〕

💡 使い方: パスワード入力フォーム等は必ず HTTPS（鍵マーク）。裸の HTTP だと通信が途中で覗き見・改ざんされる危険。

エンドポイント（endpoint）— API の「窓口（住所）」。URL のパス部分で機能を識別する。〔第3章〕

💡 使い方: GET /api/users や POST /api/reserve 等、URL のパスで「どの機能か」を識別。窓口ごとに役割を分けて設計する。

MRE（エムアールイー／Minimal Reproducible Example／最小再現例）— バグを再現する不要部分を削ぎ落とした最小の手順・コード。作る過程で原因が際立つ。〔第11章〕

💡 使い方: 「バグります」と言うより、不要部分を削った最小コードを添えると原因が浮かびやすい。バグ報告・質問の基本作法。

MFA（エムエフエー／多要素認証）— 知識・所有・生体など異なる性質の要素を組み合わせる認証。パスワード1つへの依存を減らす。〔第5章〕

💡 使い方: パスワード（知識）＋スマホのコード（所有）の組み合わせ。パスワードが漏れても片方で止まるので、重要アカウントは必ず MFA 有効化。

npm（エヌピーエム／npm）— JavaScript（Node.js）のパッケージマネージャ（荷物の管理係）。〔第10章〕

💡 使い方: npm install パッケージ名 で外部ライブラリを取り込み、npm install 単体で package.json 通りに環境を再現。JS 開発の荷物管理係。

お

OAuth（オース／通称「オーオース」も／OAuth 2.0）— 委譲: 限られた権限を外部サービスに貸す仕組み。「Googleでログイン」の基盤。〔第5章〕

💡 使い方: 「Google でログイン」「このアプリに Twitter 投稿を許可」等。パスワードを渡さずに限られた権限だけ貸すのが OAuth の核心。

OIDC（オーアイディーシー／OpenID Connect）— OAuth の上に乗った認証仕様。外部アカウント（Google等）で「この人は誰か」を保証してもらう。〔第5章〕

💡 使い方: 「Google でログイン」で「この人は Google アカウント持ち主の〇〇さん」と本人性を保証してもらう層。OAuth（権限貸し）の上に認証を乗せた仕様。

ORM（オーアールエム／Object-Relational Mapping／オブジェクト関係マッピング）— プログラムのコードとデータベースの間を橋渡しし、SQL を直接書かずにデータ操作できる仕組み。〔第7章〕

💡 使い方: SQL を直接書かず User.objects.filter(name="山田") のようにコードでデータ検索。SQL 文字列の組み立てミスを減らせる（複雑処理は生 SQL も）。

オーケストレーション（orchestration／「楽団の指揮」由来）— 複数のコンテナを本番で大量に運用・自動管理する仕組み。Kubernetes（K8s）が代表。〔第6章〕

💡 使い方: コンテナが数十〜数百に増えた本番で「どのサーバーで・何個動かす・故障時の再起動」を自動管理。Kubernetes（K8s）が代表格。

か行

か

回帰（regression／リグレッション）— コードを直した時に前まで動いていたものが壊れること。テストで自動検知する主目的の1つ。〔第12章〕

💡 使い方: 「直したら別の場所が壊れた」＝回帰。テストを毎回自動で回す（CI）のは、この回帰を即座に捕まえるため。

型チェック（type check／タイプチェック／型検査）— データの「種類（型）」の矛盾を、コードを実行せずに（静的に）見つける検査。型の矛盾による実行時エラーを構造的に防ぐ。〔第12章〕

💡 使い方: 実行前に「文字列を数値として足そうとしている」等の型矛盾を指摘。実行時エラーを未然に防ぐ。

カバレッジ（coverage）— テストがコードをどれくらい網羅しているかの割合（％）。高いほど「未テスト箇所が少ない」が、100％＝バグなしではない（逆に低くても、必ずバグがあるわけではない）。〔第1章〕

💡 使い方: 「テストがコードの何割を通ったか」の目安。100％でも「指定した機能を網羅した」だけでバグがない保証ではない（確認し忘れた機能は計測外）。

環境変数（environment variable）— プログラムの外側から差し込む設定値。コードを書き換えずに開発と本番を切り替えられる。〔第4章〕

💡 使い方: APIキーやDB接続先等をコード外から差し込む。開発・本番で同じコード・設定値だけ切替（.env ファイルで管理）。

関心の分離（SoC／エスオーシー／separation of concerns）— 異なる関心事（UI・DB・業務ロジック等）を分離して別の部品に。混ざると1箇所の変更が全体に波及する。〔第13章〕

💡 使い方: UI・DB・業務ロジックを別部品に分ける。「表示だけ直したい」変更がDB処理を壊さない構造になる。

🔖 筆者の実例: 自作の LLM 中継プロキシ（glm-rate-proxy）では、APIキー等の秘匿値をすべて ~/.secrets.env という環境変数ファイルに一元化し、コードには「キー名」しか書かない運用で漏洩を防いでいます。

cargo（カルゴ／cargo）— Rust のパッケージマネージャ。〔第10章〕

💡 使い方: Rust の荷物管理係。cargo build（ビルド）／cargo add パッケージ名（依存ライブラリ導入）で版管理する。

き

キャッシュ（cache）— 一度取得・計算した結果を使い回して速くする仕組み。古さ（一貫性）の管理が難問。〔第9章〕

💡 使い方: 「何度も同じ検索結果を取得」等の無駄を、結果を使い回して高速化。ただし古くなる（一貫性）問題と付き合う。

キャッシュ雪崩（スタンピード／cache stampede）— TTL一斉切れで全キャッシュミス→本来のデータ源に殺到してダウンさせる事故。〔第9章〕

💡 使い方: TTL が一斉に切れると全リクエストが本来の DB 等に殺到→ダウン。TTL に揺らぎ（ジッター）を持たせて一斉切れを予防。

キュー（queue／「列」）— 非同期処理で依頼を順に並べておく場所。ワーカーが取り出して処理する。〔第9章〕

💡 使い方: 「依頼を順に並べて、ワーカーが順に処理」。時間のかかる処理（メール送信等）を後回しにして素早くレスポンスを返す。

git bisect（ギット・バイセクション／git bisect）— 良い版と悪い版を指定し、原因のコミットを二分探索で特定するGit機能。〔第11章〕

💡 使い方: 「この版では動く・あの版では壊れる」を指定すると、Git が二分探索で原因コミットを特定してくれる（手動探索より圧倒的に速い）。

技術的負債（technical debt）— 「後で直す」と先送りされた問題が、雪だるま式に膨らんで開発を重くする現象。借金のメタファー。〔第1章〕

💡 使い方: 「後で直す」と先送りした箇所が積もって開発速度を下げる。借金と同じで計画的に返済（リファクタリング）しないと金利（修正コスト）が膨らむ。

凝集度（cohesion／コヒージョン）— 1つのモジュール（部品）内の機能のまとまり。高い（強い）ほど良い。1モジュール＝1責務に集中すると凝集が強くなる（→ 結合度）。〔第13章〕

💡 使い方: 1部品内の「機能のまとまり」。強い（高い）ほど良い＝1部品＝1責務に集中させる（同時に結合度は下げる）。

く

GraphQL（グラフキューエル／通称「グラフキュー」も）— 「欲しいフィールドだけ」を1リクエストで指定できる API 設計スタイル。REST の代替候補。〔第3章〕

💡 使い方: 「名前と電話番号だけ欲しい」等、必要フィールドを1リクエストで指定。REST の過不足（不要データも取る／足りず複数回）を解消。

クライアント（client）— サービスにリクエストを送る側（ブラウザ・アプリ等）。〔第3章〕

💡 使い方: リクエストを送る側（ブラウザ・スマホアプリ等）。サーバー（応える側）と対になる。

クローン（clone）— リモート（GitHub 等）のリポジトリをまるごと手元にコピーする最初の1回の操作。〔第2章〕

💡 使い方: GitHub のリポジトリを手元にまるごとコピーする最初の1回。その後の更新は git pull で取り込む。

CRUD（クラッド）— 作成(Create)・読取(Read)・更新(Update)・削除(Delete)の頭文字。データ操作の4基本。〔第3章〕

💡 使い方: 作成・読取・更新・削除。「この画面でできること」を4つで整理できる（「編集画面は CRUD のどれ？」と問うと抜けが分かる）。

Cookie（クッキー）— ブラウザに保存される小さなデータ。リクエストのたび自動でサーバーに送信される。セッション方式の中核。〔第5章〕

💡 使い方: ブラウザに保存されリクエストのたび自動送信される小さなデータ。「ログイン状態の保持」等の中核。

け

結合度（coupling／カプリング）— モジュール（部品）同士の依存の強さ。低い（ゆるい）ほど良い。片方を変えるともう片方も壊れる＝結合が強い（→ 凝集度）。〔第13章〕

💡 使い方: 部品同士の依存の強さ。ゆるい（低い）ほど良い＝片方を直してもう片方が壊れない（同時に凝集度は上げる）。

GET（ゲット）— HTTP メソッドの1つ。「取得したい（ページを見る）」という意味。〔第3章〕

💡 使い方: HTTP メソッドで「取得したい」。URL にパラメータを付けて「これ見せて」と要求。原則データを変えない（参照系）。

こ

コードレビュー（code review）— 他の人が書いたコードを確認し、改善点を伝え合う作業。Pull Request で実施するのが現代の定番。ミス探しでなく知見共有の場。〔第13章〕

💡 使い方: Pull Request で他の人がコードを確認し合う。ミス探し以上に「チームの知見・方針をすり合わせる」場。

コミット（commit）— 変更を「歴史の1ページ」としてローカルに保存すること。commit だけではまだ他の人に見えない（→ push）。〔第2章〕

💡 使い方: 変更を歴史の1ページとしてローカルに保存。commit だけでは他の人に見えない（→ push で共有）。

コンテナ（container）— アプリと実行環境を**「丸ごと1つの箱」**に詰め込む技術。イメージ（設計図）を起動した「動いている実体」でもある。Docker が代表実装。〔第6章〕

💡 使い方: アプリ＋実行環境を「丸ごと1箱」に。「自分の PC では動いた」を無くす（環境ごと持ち運ぶ）。Docker が代表。

コンフリクト（conflict／「衝突」）— 同じファイルの同じ行を別々に変更してしまい、Git が自動で統合できなくなった状態。人間が解決する。〔第2章〕

💡 使い方: 同じ行を別々に変更して Git が自動統合できない状態。人間が「どちらを正とするか」判断して解決する。

さ行

し

CI（シーアイ／Continuous Integration＝継続的インテグレーション）— push のたび機械が自動でビルド・テスト・品質チェックを回す仕組み。〔第1章〕

💡 使い方: 「CI回してますか？」＝「push ごとに自動テスト走らせてますか」。GitHub の Actions タブで緑 ✓ が並んでいる状態が「CI が通っている」。

🔖 筆者の実例: 自作の AI エージェント基盤 NexusCore では、Bandit（セキュリティスキャン）＋ pytest（テスト）＋ ruff（リンター）を GitHub Actions で毎 push 時に自動実行し、CI が緑（成功）の状態を維持しています。

CD（シーディー／Continuous Delivery / Deployment＝継続的デリバリー／デプロイ）— CI で検査を通ったコードを「いつでもリリースできる状態」に保つ、または本番まで自動で届ける仕組み。〔第1章〕

💡 使い方: 「CIで検査通過 → 自動で本番に反映」がCD。CIが「通る」、CDが「出る」。両輪で初めて「安心して更新できる」状態に届く。

シークレット（secret）— 環境変数の中でも他人に見られてはいけない値（APIキー・パスワード・トークン等）。基本原則: コードに書かない・Gitに入れない・本番は専用保管場所。〔第4章〕

💡 使い方: APIキーやパスワードを app.py に直書きしてGitHubにpush → 数時間で世界中から見られる事故が頻発。環境変数経由にして、リポジトリにはキー名だけを書く。

gRPC（ジーアールピーシー）— 「関数呼び出し」風の通信（RPC）を、現代風に高速・型付きにしたもの。マイクロサービス間等で使われる。〔第3章〕

💡 使い方: REST API（GET /users）は「URLと動詞で会話」、gRPCは「関数呼び出しで会話」と覚えるとイメージしやすい。サービス間で大量に通信する内部APIで速度・型安全が必要な時に選ぶ。

CSRF（シーエスアールエフ／Cross-Site Request Forgery／「偽造リクエスト」）— ログイン中の利用者に、悪意ある別サイトから勝手にリクエストを送らせる攻撃。Cookie方式で特に注意。〔第5章〕

💡 使い方: 「別のタブで開いた偽サイト経由で、自分の銀行口座から勝手に送金」されるイメージ。Cookieだけで本人判定しているのが原因で、CSRFトークン（1回だけ有効な乱数）で防ぐ。

CI/CD の「緑・赤」 — GitHub 上の CI 結果の色表示。🟢緑＝全job成功・🔴赤＝どこか失敗・🟡黄（in_progress）＝いま実行中。〔第1章〕

💡 使い方: 緑＝「直したコードが自動テストを全部通過」＝mainブランチにマージしてOKな印。赤＝「どこかが失敗」＝マージ前に直す。色は信号と覚える（緑＝進め、赤＝止まれ）。

す

ステージ（stage／別名 index）— コミット前に「この変更を記録する」とまとめておく待合室。ワークツリー→ステージ→リポジトリの中間。〔第2章〕

💡 使い方: git add ファイル名 で「この変更を次にcommitする分に入れる」と宣言する操作。選別して記録できる（全部まとめて1コミットでなく、「機能A」「機能B」と分けられる）。

ステータスコード（status code）— HTTP レスポンスに含まれる3桁の数字で「結果はどうだったか」を機械的に伝える。200=成功・401=認証無効・403=権限なし・404=見つからない・500=サーバー内部エラー・503=サービス停止中。〔第3章〕

💡 使い方: 「ページが出ない」とき、ブラウザのDevToolsのNetworkタブで 404（URL違い）か 500（サーバー側バグ）か 503（サーバーダウン中）かで見当を付ける。最初の数字のクラスで大別（2xx=成功、4xx=自分のリクエスト側ミス、5xx=サーバー側問題）。

ステップ（step）— GitHub Actions でジョブの中の個々の実行単位。ジョブ > ステップ の階層。〔第1章〕

💡 使い方: YAMLで「actions/checkout@v4でソース取得 → python3 -m pip installで依存導入 → pytestでテスト」のように並べる。各stepが失敗すると次のstepは走らない。

せ

静的解析（static analysis／スタティックアナリシス）— コードを実行せずに解析する手法。Lint・型チェックを含む上位概念。実行不要で速く、人間の見落としを補う。〔第12章〕

💡 使い方: 「プログラムを走らせずに問題を見つける」＝静的解析。エディタで書いているそばから波線で出る警告の大半がこれ（実行しなくても型・構文の問題は機械に分かる）。

セキュリティスキャン — 既知の脆弱性のあるライブラリを使っていないかを自動で調べる CI の検査。Bandit 等が代表例。〔第1章〕

💡 使い方: 「自分のコード」だけでなく「自分が使ってるライブラリの中にも脆弱性が埋まってる」ケースを検出。「古い版を使い続けるな」の自動取り締まりだと思えばいい。

セッション（session）— ログイン中の状態をサーバー側が記憶する仕組み。Cookieと組み合わせて使うブラウザ型の古典（ステートフル）。〔第5章〕

💡 使い方: ログイン中「あなたのIDは〇〇さん」をサーバーが覚えていて、以降のリクエストのたびに「同じ人か」確認する方式。サーバーが状態を持つ＝「ステートフル」。JWTなど「トークンに状態を載せる」方式との対比で使う言葉。

SemVer（セムヴァー／Semantic Versioning／セマンティックバージョニング）— バージョン番号 メジャー.マイナー.パッチ で後方互換性の有無を伝える約束。メジャー上がり＝壊れる変更。〔第10章〕

💡 使い方: 「^1.2.3 で入れたら 2.0.0 が出て壊れた」＝メジャー上がりで後方互換性が壊れた例。番号の桁で警戒度を変える（パッチ=安心・マイナー=ほぼ安心・メジャー=要確認）。

た行

た

単一責任（SRP／エスアールピー／単一責任原則／single responsibility）— 1つのモジュール・関数は1つの責務だけ持つという原則。複数の役目を持つと、一部を変えたい時にも全部に影響する。〔第13章〕

ダッシュボード（dashboard）— メトリクス（CPU・エラー率等）をグラフ等で可視化する画面。システム全体の状態を一目で把握する。〔第8章〕

デプロイ（deploy＝「リリース」「公開」とほぼ同義）— コードを本番環境（ユーザーが使う環境）に配置して動かすこと。〔第1章〕

🔖 筆者の実例: この教科書自身も、main ブランチに push すると GitHub Actions が自動でビルドし、GitHub Pages に自動デプロイ（CD）される仕組みで運用しています。

DELETE（デリート）— HTTP メソッドの1つ。「削除したい」。〔第3章〕

diff（ディフ／「差分」）— 変更前後の違い。PR で「何を変えたか」を確認する基本。〔第2章〕

2FA（ツーエフエー／二要素認証）— MFAの「2要素組み合わせ」版。現場では MFA とほぼ同義で使われる。〔第5章〕

て

テスト（test）— コードが期待通り動くかを確認する仕組み。単体テスト（unit）と統合テスト（integration）が代表的。CI の主役。〔第1章〕
トークン（token）— 入場券のような文字列。ログイン成功後に発行し、以降のリクエストに添えて身元を証明する（JWT 等）。〔第5章〕

と

トランザクション（transaction）— 複数の処理を1つのまとまりにし、「全て成功」か「全てなかったこと」のどちらかにする仕組み。RDB の強み（→ ACID）。〔第7章〕

な行

に

認証（authentication）— 「あなたは誰か」を確認すること。パスワード・生体等で身元を特定。〔第5章〕
認可（authorization）— 「何をしてよいか」を判断すること。認証とは別問題（IDOR等は認可の欠如）。〔第5章〕

の

NoSQL（ノーエスキューエル／「SQLでない」）— 表以外の形でデータを扱うデータベースの総称。柔軟・特定用途で高速だが、厳密な整合性は RDB ほどでないことが多い。〔第7章〕

は行

は

ハッシュ（hash／「すりつぶす」）— 元に戻せない一方向の変換。パスワード保存は必ずハッシュ化（bcrypt 等の専用アルゴリズム）。〔第5章〕
bundler（バンドラー／bundler）— Ruby のパッケージ管理ツール。〔第10章〕
パスキー（passkey）— パスワードの代わりにデバイスで認証する仕組み。フィッシング（偽サイト騙し）に強い（FIDO2/WebAuthn 基盤）。〔第5章〕

ひ

非同期（async／エイシンク）— 時間のかかる処理の完了を待たず先へ進む方式（後回し）。同期（sync／シンク＝待ってから次へ）の対。〔第9章〕
pip（ピップ／pip）— Python のパッケージマネージャ。〔第10章〕

ふ

feature flag（フィーチャー・フラグ／機能フラグ）— コードは配置したまま、設定で機能を ON/OFF できる仕組み。ロールバックの手段としても使う。〔第1章〕
fetch（フェッチ）— リモートの最新情報を取得だけする（手元のファイルは書き換えない）。確認用。〔第2章〕
flaky test（フレイキー・テスト／「フレーキー」とも）— 環境次第でたまに落ちる不安定なテスト。CI が緑でも信頼できない原因になる。〔第1章〕
fork（フォーク）— 他人のリポジトリを自分のアカウントにコピーする操作。OSS 貢献の入口。〔第2章〕
FIDO2（フィドウ・ツー）— パスワードレス・フィッシング耐性の認証技術。パスキーの基盤。〔第5章〕

び

ビルド（build）— コードがエラーなく組み立てられるか確認すること。CI の基本検査の1つ。〔第1章〕

ぷ

プッシュ（push）— 手元のコミットをリモート（GitHub）に送ること。push して初めて他の人に共有される（commit ≠ push）。〔第2章〕
プル（pull）— リモートの最新を取得して手元に取り込むこと（＝ fetch + merge）。〔第2章〕
Pull Request / PR（プルリクエスト／通称「プルリク」）— 「この変更を取り込んでください」とチームに依頼し、レビューを経て統合する仕組み。〔第2章〕

ぶ

ブランチ（branch）— 履歴を枝分かれさせて別々に進められる仕組み。「平行世界」。main（旧称 master）は中心の安定した歴史。〔第2章〕
ブルートフォース（brute force／「力技」）— パスワードを総当たりで試す攻撃。試行回数制限・アカウントロックで対策。〔第5章〕

ほ

PostgreSQL（ポストグレス・キューエル／通称「ポストグレス」）— サーバー型の本格的な RDB。同時書き込みに強く大規模向き。MySQL と並ぶ代表格。〔第7章〕
ボリューム（volume）— コンテナの**「外」にデータを保存**し、コンテナから参照させる仕組み。DBのデータ等、消してはいけないものはコンテナ内でなくボリュームに置く。〔第6章〕

ま行

ま

MySQL（マイエスキューエル）— サーバー型の本格的な RDB。同時書き込みに強く大規模向きだが、運用コストがかかる。〔第7章〕
マージ（merge／「統合」）— 別ブランチで進めた作業を main 等に合わせること。〔第2章〕
main（メイン／旧称 master）— リポジトリの中心となる安定した歴史を指すブランチ名。「main は常に動く・壊れない状態を保つ」のが現場の合意。〔第2章〕
main（メイン／旧称 master）— リポジトリの中心となる安定した歴史を指すブランチ名。「main は常に動く・壊れない状態を保つ」のが現場の合意。〔第2章〕
メトリクス（metrics／「指標」）— システムの状態を表す数値（CPU使用率・レスポンス時間・エラー率等）。モニタリングの中身。〔第8章〕
MongoDB（モンゴディービー）— JSON のような形が変わるデータを扱うドキュメント型 NoSQL。事前のスキーマ定義が不要で柔軟。〔第7章〕

や行

や

yarn（ヤーン／yarn）— JavaScript のパッケージマネージャ（npm の代替）。〔第10章〕
YAGNI（ヤグニ／You Aren't Gonna Need It／それはまだ要らない）— 今不要な機能・抽象を作らない原則。「将来使うかも」で作った複雑さは負債になりがち。〔第13章〕

ゆ

YAML（ヤムル／YAML Ain't Markup Language。「ヤメル」と読む人もいるが「ヤムル」が通称）— インデントで階層を表す設定ファイル記法。GitHub Actions のワークフロー定義等で使う。〔第1章〕
uv（ユーブイ／uv）— Python の高速なパッケージマネージャ（pip の代替候補）。〔第10章〕

ら行

ら

rubber duck debugging（ラバーダック・デバッグ／ゴムアヒル技法）— ゴムアヒル（または誰か）にコードを口頭で1行ずつ説明し、自分の勘違いに気づいて原因を見つけるデバッグ技法。〔第11章〕

り

リクエスト（request／「お願い」）— クライアントからサーバーへ送る「やってほしいこと」の依頼。〔第3章〕
レスポンス（response／「お返事」）— サーバーからクライアントへ返す結果。〔第3章〕
リモート（remote）— ネットワーク上（GitHub 等）にある離れたリポジトリ。ローカル（手元）の対義語。〔第2章〕
リポジトリ（repository／通称「レポ」「リポ」）— 変更が履歴として保存される場所（.git/ 配下）。〔第2章〕
リンター（linter）— コードがチームの規約を守っているか（読みやすさ・一貫性）を自動チェックする道具。ruff・ESLint 等が代表。〔第1章〕
Lint（リント）— コードを実行せずに（静的解析）、書き方の問題・バグの種を見つける検査そのもの。リンターが担当する。〔第12章〕
リバート（revert／「取り消す」）— 特定のコミットを打ち消す操作。壊れた変更を main から取り除く時に使う。〔第1章〕
REST（レスト／Representational State Transfer）— URL（名詞）と HTTP メソッド（動詞）で機能を表現する API 設計思想。最も普及しているスタイル。〔第3章〕
RPC（アールピーシー／Remote Procedure Call）— 「関数呼び出し」風の通信スタイル。これを現代風にしたのが gRPC。〔第3章〕

る

root cause（ルートコーズ／根本原因）— バグの表面でなく根っこの原因。ここまで直さないと同じバグが再発する。例:「クラッシュ直前にnullチェックを足す」は対症療法・「なぜnullが渡るか」を直すのが根本解決。〔第11章〕

れ

Redis（レディース）— 「鍵に対する値」を超高速で読み書きするキー・バリュー型のインメモリ NoSQL。電源切断で消えうるため一時データ（キャッシュ等）向け。〔第7章〕

ろ

lock file（ロックファイル／lock file）— 実際にインストールした版組み合わせを全件記録し再現性を担保するファイル（package-lock.json・Cargo.lock 等）。原則コミット。〔第10章〕
ログレベル（DEBUG/INFO/WARN/ERROR/FATAL）— ログの「重さ（深刻度）」の分類。本番では DEBUG を絞り、レベルで絞り込み・優先度判断する。〔第8章〕
ローカル（local）— 手元の環境（自分のPC）。リモート の対義語。〔第2章〕
ロールバック（rollback／「巻き戻し」）— 公開してみたら不具合が出た時、前のバージョンに戻すこと。「デプロイできる」と同じくらい「戻せる」ことが重要。〔第1章〕

わ行

わ

ワークフロー（workflow）— GitHub Actions で「どのタイミングで・何をするか」を定義したもの。.github/workflows/ に YAML で置く。〔第1章〕
WebHook（ウェブフック）— サーバーがクライアントに能動的に通知を送る仕組み。決済完了通知等で使う。公開エンドポイントになるため署名検証がほぼ必須。〔第3章〕
WebSocket（ウェブソケット）— 双方向・常時接続の通信スタイル。チャットやリアルタイム更新で使う。〔第3章〕
WebAuthn（ウェブオースン／Web Authentication）— Web で FIDO2/パスキーを実現する API 仕様。〔第5章〕

英字語・記号始まり

.env（ドット・イーエンヴイ／通称「ドット・エンブ」も）— ローカル開発で環境変数をまとめた設定ファイル。Git には入れない前提。〔第4章〕
.gitignore（ドット・ギットイグノア）— Git の追跡から除外するファイルを指定する設定ファイル。.env 等の秘匿ファイルを弾くのに使う。〔第4章〕
CDN（シーディーエヌ／Content Delivery Network）— 静的ファイル（画像・CSS等）を世界中のサーバーに配置し、ユーザーに近い所から配信する仕組み。静的配信のキャッシュ代表。〔第9章〕
DRY（ドライ／Don't Repeat Yourself／繰り返すな）— 同じコード・知識を重複させない原則。直す時に複数箇所触る重複は修正漏れの温床。〔第13章〕
Docker（ドッカー）— コンテナを作り・動かす最も普及したツール兼フォーマット。「環境を丸ごと箱詰め」して運ぶ。〔第6章〕
Dockerfile（ドッカーファイル）— イメージの作り方を書いた手順書。これをビルドするとイメージができる。〔第6章〕
ELK（イーエルケー／Elasticsearch+Logstash+Kibana）— 大量の構造化ログを集めて検索・可視化するログ集計スタックの代表例。〔第8章〕
Git（ギット）— コードの変更履歴を記録・管理するバージョン管理システム。〔第2章〕
GitHub（ギットハブ）— Git の履歴をインターネット上で共有・協働するプラットフォーム。「みんなで使う作業場」。〔第2章〕
GitHub Actions（ギットハブ・アクションズ）— GitHub が提供する CI/CD 実行環境。.github/workflows/ に YAML で定義する。〔第1章〕
issue（イシュー）— 「やるべきこと・問題・要望」を1件ずつ管理するチケット。〔第2章〕
job（ジョブ）— GitHub Actions でワークフロー内の実行単位。ワークフロー > ジョブ > ステップ の階層。〔第1章〕
JSON（ジェイソン／JavaScript Object Notation）— 「キーと値のペア」を {} で囲む、汎用のデータ交換形式。API で事実上標準。〔第3章〕
JWT（ジェイダブリューティー／通称「ジョット」／JSON Web Token）— 認証情報を安全に運ぶ署名付きトークン。API・モバイル向き（ステートレス・無効化は工夫が要る）。〔第5章〕
KISS（キス／Keep It Simple, Stupid／シンプルに）— 必要以上に複雑にしない原則。賢い書き方より分かる書き方。〔第13章〕
Kubernetes（クーバネティス／公式ギリシャ語発音。通称「K8s＝ケーエイツ」）— コンテナを本番で大量に運用・自動管理する基盤。〔第6章〕
left shift（レフトシフト／「左へずらす」）— 問題を工程の**手前（左）**で見つけるほど直すコストが安い、という思想。エディタ・pre-commit・CI など手前に検査を置く根拠。〔第12章〕
Observability（オブザーバビリティ／観測可能性）— システムの内部状態を外部から把握できる度合い。ログ・メトリクス等を整えて高める。〔第8章〕
origin（オリジン）— 自分が push/pull する相手（普通は fork した自分のリポジトリ）のデフォルトの呼び名。upstream（コピー元）の対。〔第2章〕
PATCH（パッチ）— HTTP メソッドの1つ。「一部だけ更新したい」。PUT（丸ごと更新）との違いは粒度。〔第3章〕
pre-commit（プレコミット）— コミットの直前に自動検査（Lint・テスト等）を走らせる仕組み。問題あるコードが履歴に入るのを未然に防ぐ。〔第12章〕
POST（ポスト）— HTTP メソッドの1つ。「新しく作成したい」。〔第3章〕
PUT（プット）— HTTP メソッドの1つ。「全体を更新したい（丸ごと置き換え）」。〔第3章〕
rebase（リベース）— ブランチの変更を main の最新の先に積み直す操作。履歴を一直線にできるが履歴書き換えなので要注意（push 済みの rebase は厳禁）。〔第2章〕
SLA/SLI/SLO（エスエルエー等／合意・指標・目標）— サービスの信頼性を**約束（SLA）・計測（SLI）・目標（SLO）**として数値管理する作法。「可用性99.9%」等。〔第8章〕
Stripe（ストライプ）— 決済 API の代表格。WebHook で決済完了通知を受け取る使い方が定番。〔第3章〕
TTL（ティーティーエル／Time To Live／「寿命」）— キャッシュの有効期限。過ぎると自動で捨てられ、新しさを期限で緩和する。〔第9章〕
upstream（アップストリーム）— コピー元の**「オリジナルのリポジトリ」**を指す呼び方（川の上流＝源流のイメージ）。origin の対。〔第2章〕
VM（ブイエム／Virtual Machine／仮想マシン）— OSごと丸ごと隔離する従来の仮想化方式。コンテナより重い・起動が遅いが、完全な隔離を持つ。〔第6章〕

まとめ

用語集は読み仮名のあいうえお順。読み方が分からない時は、見出しの（カタカナ読み）を頼りに引いてください
読み仮名は英字綴りの語のみ。カタカナ語・漢字語は自力で読めます
🔖 筆者の実例 の枠がある用語は、汎用解説に加えて自作プロジェクトでの使われ方を補足しています

💡 この辞書は生き物です: 本編（第5章以降）が増えるたび、新しい用語を追加していきます。「この言葉が載ってない！」があれば、それが次に追加すべき用語の目安です。