用語集

会議やレビューで、意味の分からない言葉が出てきた時に引いてください。その場で聞けるのが一番良いですが、聞きそびれた時のための場所です。

「握る」「温度感」のような日本の開発現場特有の言い回しも入れています。

162 件

開発プロセス

スプリントsprint / イテレーション: 1〜2週間の固定期間。この単位で計画し、作り、振り返る。期間は伸ばさないのが原則で、入りきらない場合は中身を減らす。詳しく読む
デイリー朝会 / スタンドアップ / daily scrum: 毎朝15分の短い会。進捗報告の場ではなく、困っていることを早く表に出すための場。詳しく読む
レトロretrospective / 振り返り / KPT: スプリント末に、やり方を改善するために行う振り返り。責めるのは人ではなくプロセス。KPT（Keep / Problem / Try）で整理することが多い。詳しく読む
DoDDefinition of Done / 完了の定義: チームが「終わった」と認める条件。実装・テスト・レビュー・ドキュメント・動作確認まで含むことが多い。「動いた」とは違う。詳しく読む
POプロダクトオーナー / Product Owner: 何を作るかの優先順位を決める人。「どう作るか」は開発チームが決める。詳しく読む
ストーリーポイントSP / ポイント / 見積もり: 作業量を時間ではなく相対的な難しさで表す数値。人によって作業時間が違うことと、時間で言うと約束に聞こえることを避けるため。詳しく読む
ベロシティvelocity: 1スプリントでチームが消化できるストーリーポイントの実績値。計画の目安に使う。個人の評価には使わない。
バックログbacklog: やることリスト。全体を並べたプロダクトバックログと、今スプリントでやるスプリントバックログがある。詳しく読む
受け入れ条件AC / Acceptance Criteria: そのチケットが「できた」と言える具体的な条件。書かれていなければ自分で書いて確認するとよい。詳しく読む
リファインメントグルーミング / backlog refinement: 着手前にバックログを「分かる状態」にしておく活動。分割・受け入れ条件・見積もりまでやる。スクラムガイド上はイベントではなく継続的な活動。詳しく読む
スプリントゴールsprint goal: そのスプリントで達成したいことを1つに絞ったもの。割り込みが来た時に「これはゴールに必要か」で判断できる。無いとタスクの寄せ集めになる。詳しく読む
スプリントレビューレビュー会: スプリントの終わりに、動くものを関係者に見せてフィードバックをもらう場。発表会ではなく実際に触ってもらう場で、成果物はバックログの更新。詳しく読む
KPTKeep Problem Try: レトロでよく使う型。続けたいこと・困ったこと・次に試すこと。Try は1〜2個に絞ってバックログに載せるまででワンセット。出して終わると誰も実行しない。詳しく読む

Git / レビュー

PRプルリク / Pull Request / MR / Merge Request: 変更をレビューしてもらい、取り込んでもらうための単位。小さく出すほど早くレビューされる。詳しく読む
LGTMLooks Good To Me: 「自分は良いと思う」= 承認。レビューを通した合図。詳しく読む
nitnitpick: 「細かいけど」という前置き。直さなくてもマージできることが多い、軽い指摘。詳しく読む
WIPWork In Progress: まだ作業中。レビュー前に方向性だけ見てほしい時に付ける。
rebaseリベース: コミットの土台を差し替えて履歴を書き換える操作。push 済みで他人が取り込んでいるブランチではやってはいけない。詳しく読む
squashスカッシュ: 複数のコミットを1つにまとめること。マージ時に squash してから取り込むチームも多い。
コンフリクトconflict / 衝突: 同じ場所を両方が別内容に変えたため、Git が自動で決められない状態。壊れているわけではなく、人間の判断待ち。詳しく読む
reflog: HEAD が動いた履歴。reset --hard で消したように見えるコミットもここから戻せる。やらかした時の命綱。詳しく読む
cherry-pick: 特定のコミットだけを別のブランチに取り込む操作。緊急修正の反映などに使う。
Draft PR下書き PR: レビューを依頼しない状態の PR。方針だけ早く確認してもらうために使う。1週間黙って作り込んでから出すのが新人の最大の失敗で、これはその対策。詳しく読む
Squashsquash and merge: PR の中の複数コミットを1つに潰してマージする方式。履歴が読みやすくなる代わりに、PR のタイトルがそのまま履歴に残るので、タイトルを丁寧に書く必要がある。詳しく読む
CODEOWNERS: 特定のファイルやディレクトリの担当者を割り当てる設定ファイル。自動でレビュー依頼が飛ぶ。承認を必須にするかはブランチ保護側の設定で決まる。詳しく読む
ブランチ保護branch protection / ruleset: main への直接 push を禁止し、レビューと CI の通過を必須にする設定。「main に push できません」と言われたら、正しく守られているということ。詳しく読む
Suggested changes提案: レビューで修正案を直接書ける GitHub の機能。受け取った側はボタン1つで取り込める。typo の指摘に使うと往復が1回減る。詳しく読む

コンピュータの基礎

UTF-8Unicode / 文字コード: 文字とバイト列の対応表のうち、現在の事実上の標準。1文字が1〜4バイトになるため、バイト数と文字数は一致しない。文字化けの大半は「保存した文字コードと読んだ文字コードが違う」ことで起きる。詳しく読む
改行コードCRLF / LF / \r\n: Windows は CRLF、macOS / Linux は LF。混在すると diff が全行変更に見える、シェルスクリプトが動かない等の事故になる。Git の core.autocrlf と .gitattributes で揃える。詳しく読む
BOMbyte order mark: ファイル先頭に付く見えない3バイト。Excel が UTF-8 CSV を読むために求める一方、シェルスクリプトや JSON では先頭に混ざって壊れる。「なぜか1行目だけおかしい」の典型的な原因。詳しく読む
浮動小数点float / double / IEEE 754: 小数を2進数の近似で持つ形式。0.1 + 0.2 !== 0.3 になる。金額の計算には使わず、整数（最小単位）か十進数型を使う。詳しく読む
タイムゾーンUTC / JST / ISO 8601: 保存は UTC、表示のときだけローカル時刻に変換するのが原則。日付だけを持つと、時差で1日ずれる。詳しく読む
計算量オーダー / O記法 / Big-O: 入力が増えたときに処理時間がどう伸びるかの目安。O(n²) は 1000 件で 100 万回。手元で速いコードが本番で落ちるのは、ほぼこれが原因。詳しく読む
プロセスとスレッドprocess / thread: プロセスはメモリ空間ごと独立した実行単位、スレッドはメモリを共有する実行単位。共有するからこそ速く、共有するからこそデータ競合が起きる。詳しく読む
メモリリークmemory leak / OOM: 使い終わったメモリが解放されず増え続ける状態。だんだん遅くなり、最後に OOM Killer に落とされる。再起動で直るように見えるのが厄介。詳しく読む
エンディアンbyte order / ビッグエンディアン / リトルエンディアン: 複数バイトの数値をどの順で並べるか。ネットワークはビッグエンディアン、x86 はリトルエンディアン。バイナリを自前で読む時だけ意識する。詳しく読む
名前空間namespace: プロセスから見える範囲を区切るカーネルの機能。コンテナの中で ps を打つと自分のプロセスしか見えないのはこれ。ファイルシステム・ネットワーク・ホスト名も別々に見せられる。詳しく読む
cgroupコントロールグループ: プロセスが使える CPU とメモリの上限を決めるカーネルの機能。コンテナに「メモリ 512Mi まで」と指定できるのはこれのおかげで、超えると OOMKilled になる。詳しく読む
FHSFilesystem Hierarchy Standard / ディレクトリ構成: Linux のどこに何を置くかの決まり。設定は /etc、ログは /var/log、コマンドは /usr/bin。知っていると「設定ファイルを探す」時間が消える。詳しく読む
inodeアイノード: ファイルやディレクトリの実体を管理する情報。ハードリンクされた複数の名前が同じ inode を指すこともある。個数に上限があるため、小さいファイルを大量に作ると容量が空いていても「No space left」になる。df -i で確認する。詳しく読む
umask: 新しく作るファイルの初期権限を決める設定。0022 がよく使われ、その場合は 644 のファイルと 755 のディレクトリができる（値は環境による）。「アプリが作ったファイルを別のプロセスが読めない」時に疑う。詳しく読む
シンボリックリンクsymlink / ソフトリンク: 別のファイルを指す「別名」。実体ではないので、リンク先が消えるとリンクだけが残って壊れる。ls -l で -> として表示される。詳しく読む

Web / ネットワーク

CORSオリジン間リソース共有: ブラウザが別オリジンへのリクエストを制限する仕組み。サーバー側が許可ヘッダを返す必要がある。実務で最も時間が溶けるエラーの1つ。
DNS: ドメイン名を IP アドレスに変換する仕組み。キャッシュ（TTL）があるため、切り替えてもすぐには反映されない。
TLSSSL / HTTPS: 通信を暗号化する仕組み。証明書の有効期限切れは典型的な障害原因。
gRPC: protobuf でスキーマを定義し、HTTP/2 の上で通信する RPC の仕組み。JSON より小さく速く、型が保証される。
protobufProtocol Buffers / proto: スキーマを先に定義するシリアライズ形式。フィールド番号を変えると後方互換性が壊れるので注意。
REST: リソースを URL で表し、HTTP メソッドで操作を表す設計スタイル。GET は取得、POST は作成など。
レイテンシlatency / 応答時間: リクエストしてから応答が返るまでの時間。平均値ではなく p95 / p99（遅い方から数えた値）で見るのが実務の作法。
p99パーセンタイル / p95: 遅い順に並べた時の上位1%の値。平均は速く見えても p99 が悪いと、一部のユーザーが強い不満を持つ。
CDN: 世界中に配置したサーバーから静的ファイルを配る仕組み。距離が縮まるので速くなる。
ペイロードpayload: リクエストやレスポンスの本体データ。
名前解決resolve / lookup: ドメイン名から IP アドレスを引く処理。「つながらない」の切り分けは、まずここが成功しているかを dig で確認するところから始める。詳しく読む
CIDRサブネット / 10.0.0.0/24: /24 のように、IP アドレスのうち何ビットがネットワーク部かを示す記法。/24 は 256 個、/16 は 65536 個。VPC やファイアウォールの設定で必ず出る。詳しく読む
TCP / UDPトランスポート層: TCP は順序と再送を保証する代わりに遅い。UDP は投げっぱなしで速い。動画や DNS は UDP、それ以外はたいてい TCP の上に載る。詳しく読む
ポート番号port: 同じ IP アドレス上でどのプログラムに届けるかの番号。80 は HTTP、443 は HTTPS、5432 は PostgreSQL。lsof -i で誰が使っているか分かる。詳しく読む
TTLtime to live: 有効期限。DNS では「このレコードを何秒キャッシュしてよいか」、キャッシュでは「何秒で捨てるか」。DNS を切り替える前日に TTL を短くしておくのが定石。詳しく読む
WebSocket: HTTP で接続を張った後、双方向に流しっぱなしにできる通信。チャットや通知など、サーバーから送りたい場合に使う。詳しく読む
RFCRequest for Comments: インターネットの仕様書。IETF が公開していて全部無料で読める。発行された本文は差し替えられず、誤記は Errata、内容の更新や廃止は別番号の RFC として出る。読む前に Obsoleted by と Updates を必ず確認する。詳しく読む
ISO 8601日時形式: 日付と時刻の書き方の国際規格。2026-08-14T09:30:00+09:00。API では、これを機械向けに絞った RFC 3339 に寄せるのが安全。タイムゾーンは必ず付ける。詳しく読む
デファクト標準de facto: 誰も正式に決めていないが、みんなが使うので事実上の標準になったもの。Kubernetes や Markdown が該当する。対義語は標準化団体が定めたデジュール標準。詳しく読む
MUST / SHOULDRFC 2119: 仕様書における定義済みの用語。MUST は絶対に守る、SHOULD は正当な理由があれば外れてよい、MAY は任意。「SHOULD だからやらない」には理由の説明が要る。詳しく読む

インフラ / デプロイ

コンテナDocker / container: アプリと必要な依存をまとめて、どこでも同じように動かす仕組み。中身は Linux なので macOS との差に注意。詳しく読む
Pod: Kubernetes でコンテナを動かす最小単位。通常は1 Pod に1コンテナ（＋補助コンテナ）。
Deployment: Pod を何個動かすかを宣言するリソース。更新すると順次入れ替えてくれる。
Service: Pod へのアクセス口。ラベルで対象の Pod を選ぶので、セレクタが合っていないと繋がらない（Endpoints が空になる）。
GKEGoogle Kubernetes Engine: GCP のマネージド Kubernetes。クラスタの管理を任せられる。
ステージングstaging / stg: 本番とほぼ同じ構成の確認環境。ここで確認せずに本番へ出さないのが基本。詳しく読む
カナリアリリースcanary: まず一部のユーザーにだけ新バージョンを出し、問題がなければ広げる方式。炭鉱のカナリアが語源。詳しく読む
ロールバックrollback / 切り戻し: 問題が出た時に前のバージョンへ戻すこと。「出せること」より「戻せること」の方が重要。詳しく読む
フィーチャーフラグfeature flag / フラグ: コードは出すが機能は設定でオフにしておき、後から有効化する仕組み。デプロイと公開を分離できる。
CI/CD: コードを push したら自動でテストし（CI）、自動でデプロイする（CD）仕組み。「CI が落ちた」はテストや lint の失敗を指すことが多い。
IaCInfrastructure as Code / Terraform: サーバーやネットワークの構成をコードで管理すること。手作業の変更は次の apply で消えるので注意。
リージョンとゾーンregion / availability zone / AZ: リージョンは地理的な大きな区分、ゾーンはその中の独立した障害単位。複数ゾーンに分散して初めて、片方のデータセンターが落ちても生き残れる。詳しく読む
マネージドサービスmanaged service: クラウド事業者が運用まで面倒を見るサービス。自前で立てるより高く見えるが、バックアップ・パッチ・冗長化の人件費を含めるとたいてい安い。詳しく読む
statetfstate / Terraform state: Terraform が「現実のインフラは今こうなっているはず」と記録しているファイル。手で直すと現実とずれる。共有ストレージに置き、ロックをかけて使う。詳しく読む
OCIOpen Container Initiative: コンテナのイメージと実行方式の標準規格。「Docker イメージ」の実体はこれで、containerd や Podman でも動く。Kubernetes が使っているのも Docker ではなく containerd であることが多い。詳しく読む
systemdsystemctl: Linux サーバーで常駐プログラムを管理する仕組み。systemctl status で状態、journalctl -u でログを見る。start は今動かすだけ、enable で再起動後も上がるようになる。詳しく読む
journalctl: systemd が集めたログを読むコマンド。-u <サービス名> で絞り、-f で追い続ける。サービスが起動しない時は systemctl status の次に見る。詳しく読む
Composedocker compose / compose.yaml: 複数のコンテナの起動を1つのファイルに宣言する仕組み。基本は1台のマシン向けで、restart ポリシーで再起動はできるが、複数台への配置・台数の増減・無停止の入れ替えは担わない（そこからが Kubernetes）。詳しく読む
Caskbrew cask: Homebrew で GUI アプリを入れる仕組み。brew install --cask google-chrome。brew bundle dump で Brewfile に書き出せば、マシンの中身をファイルで表現できる。詳しく読む

運用 / 監視

SLOSLI / SLA / サービスレベル: SLI が測る指標（成功率など）、SLO が目標値（99.9%）、SLA が顧客との契約。SLO を下回ると新機能を止めて改善に回す、という運用をすることがある。
オンコールon-call / 当番: 障害が起きた時に呼び出される当番。新人はしばらく免除されるか、必ず先輩とペアで入る。
ポストモーテムpostmortem / 振り返り / 障害報告: 障害の原因と再発防止をまとめる文書。個人を責めない（blameless）のが原則。仕組みの問題として書く。
可観測性Observability / オブザーバビリティ: ログ・メトリクス・トレースで、システムの中で何が起きているかを外から分かるようにすること。
分散トレーストレース / trace / スパン: 1つのリクエストが複数サービスをどう通ったかを追跡する仕組み。どこで時間がかかっているかが分かる。
構造化ログ: JSON などの機械が読める形式で出すログ。後から絞り込み・集計できる。文字列を繋げただけのログは検索しづらい。
相関IDtrace id / request id: 1つのリクエストに付ける一意の ID。サービスをまたいでログを繋げるために使う。
アラートalert / ページング: 異常時に人を呼び出す通知。鳴りすぎると無視されるようになる（アラート疲れ）ので、本当に対応が必要なものだけにする。
SLIservice level indicator: 実際に測る指標そのもの（成功率、レイテンシなど）。SLI を決めて測り、その目標値が SLO。詳しく読む
エラーバジェットerror budget: SLO を 99.9% と決めたときに許容される 0.1% の失敗枠。残っていれば新機能を出し、使い切ったら安定化を優先する、という判断の道具。詳しく読む
スロットリングthrottling / 流量制御: 処理量が限界を超えないよう、意図的に受付を絞ること。全部倒れるより、一部を断って生き残るほうが被害が小さい。詳しく読む
ブルーグリーンデプロイblue-green: 新旧2つの環境を用意し、切り替えで本番を入れ替える方式。戻すのも切り替えるだけで済む。詳しく読む
バックプレッシャーback pressure: 処理側が追いつかない時に、送り手に「待て」と伝える仕組み。無いとキューが無限に膨らんで、最後にメモリごと落ちる。詳しく読む

データベース

N+1問題N+1: 一覧を取得した後、各要素ごとに追加クエリを投げてしまい、100件なら101回クエリが飛ぶ状態。レビューで指摘される定番。
INDEXインデックス: 検索を速くする仕組み。付ければ何でも速くなるわけではなく、書き込みは遅くなる。
トランザクションtransaction: 複数の操作をまとめて「全部成功」か「全部なかったこと」にする仕組み。
SpannerCloud Spanner: GCP の分散データベース。連番の主キーを使うと書き込みが1ノードに集中する（ホットスポット）ため、主キー設計が普通の RDBMS と異なる。
ホットスポット: 分散データベースで、特定のノードに負荷が集中する状態。連番 ID やタイムスタンプ順の主キーで起きやすい。
マイグレーションmigration / スキーマ変更: DB のスキーマを変更する作業。カラム削除などの破壊的変更は、追加→両対応→削除の2段階に分けるのが安全。
レプリカreplica / リードレプリカ: 読み取り専用の複製。書き込みの反映が少し遅れる（レプリケーション遅延）ので、直後に読むと古い値が返ることがある。
ACID原子性 / 一貫性 / 独立性 / 永続性: トランザクションが満たすべき4性質。「途中まで実行された状態が残らない」ことを保証してくれるから、アプリ側が複雑な後始末を書かずに済む。詳しく読む
トランザクション分離レベルisolation level / READ COMMITTED / SERIALIZABLE: 同時に走るトランザクションをどこまで隔離するか。緩めると速いが、ファントムリードなどの異常が起きる。既定値はデータベースごとに違う。詳しく読む
デッドロックdeadlock: 2つの処理が互いの持つロックを待ち合って、永久に進まなくなる状態。ロックを取る順番をコード全体で統一すると大半は防げる。詳しく読む
正規化normalization / 第3正規形: 同じ事実を1箇所にしか持たせない設計。更新漏れによる矛盾を防ぐ。読み取り性能のために意図的に崩す（非正規化）こともある。詳しく読む
実行計画EXPLAIN / クエリプラン: データベースがそのクエリをどう実行するつもりかの説明。遅いクエリは、想像ではなく EXPLAIN を見て直す。詳しく読む
楽観ロック / 悲観ロックoptimistic lock / pessimistic lock / バージョン番号: 悲観は先にロックを取る、楽観はバージョン番号で「更新時に他人が変えていないか」を確認する。衝突が稀なら楽観のほうが速い。詳しく読む
コネクションプールconnection pool: DB 接続を使い回す仕組み。接続の確立は高価なため必須だが、上限を超えると待たされる。Pod 数 × プール数がDB の上限を超えないように設計する。詳しく読む

設計

冪等性べきとうせい / idempotency: 同じ操作を何回実行しても結果が変わらない性質。リトライする仕組みでは必須。決済で二重課金を防ぐのがこれ。
リトライretry: 失敗した通信をやり直すこと。全員が一斉にリトライすると障害を悪化させる（リトライストーム）ので、間隔を空ける（バックオフ）。
サーキットブレーカーcircuit breaker: 失敗が続く相手への呼び出しを一時的に止める仕組み。壊れた相手を叩き続けて共倒れになるのを防ぐ。
マイクロサービス: システムを小さなサービスに分けて、それぞれ独立してデプロイできるようにする構成。分割の代償としてネットワーク越しの失敗を常に考える必要がある。
モノリスmonolith / モノリシック: 1つの大きなアプリとして作る構成。単純で速いが、大きくなると変更が怖くなる。
BFFBackend for Frontend: フロントエンド専用のバックエンド層。複数サービスの結果をまとめて画面に必要な形で返す。
キャッシュ: 一度取得した結果を保存して再利用する仕組み。速くなるが、古いデータが返る問題（キャッシュの無効化）が常について回る。
結果整合性eventual consistency: 今この瞬間は食い違っていても、いずれ揃うという保証。分散システムでは強い整合性を諦める代わりに、可用性と速度を得る。「反映まで数秒かかる」を仕様として書く必要がある。詳しく読む
DI依存性の注入 / dependency injection: 依存する相手を自分で作らず、外から渡してもらう書き方。テスト時に差し替えられるのが最大の利点。詳しく読む
ADRarchitecture decision record / 設計決定記録: 「なぜこの設計にしたか」を1件1ファイルで残す記録。半年後の自分と、次に来る人のためのもの。却下した案とその理由まで書くと価値が出る。詳しく読む
境界づけられたコンテキストbounded context: 同じ言葉が別の意味を持つ範囲の区切り。「顧客」が営業と配送で違うものを指すなら、無理に1つのモデルにまとめない。詳しく読む
集約aggregate / アグリゲート: 一貫性を保つ単位。注文と注文明細のように、必ずセットで整合していなければならないものをまとめ、外からは代表（集約ルート）だけを触らせる。詳しく読む
ユビキタス言語ubiquitous language: 業務側とエンジニアが同じ言葉を同じ意味で使う状態。コードの変数名まで業務の言葉に揃えると、翻訳のコストと誤解が消える。詳しく読む
凝集度と結合度cohesion / coupling: 凝集度は「1箇所にまとまっているか」、結合度は「他とどれだけ絡んでいるか」。凝集度を高く、結合度を低くが設計の基本方針。詳しく読む
アクセシビリティa11y: 誰にとっても使える状態にすること。障害のある人だけのための特別対応ではない。正しい HTML（div ではなく button、label の紐づけ）が出発点で、そのうえでキーボード操作・フォーカス・コントラスト・動的更新の通知などを設計する。詳しく読む
WCAGウェブアクセシビリティ指針 / JIS X 8341-3: W3C が定めたアクセシビリティの指針。文字のコントラスト比 4.5:1 以上など、数値で判定できる基準を持つ。日本の JIS X 8341-3 はこれに対応している。詳しく読む
スケルトンskeleton screen: 読み込み中に、表示される予定の形を灰色の枠で見せる手法。スピナーより待ち時間が短く感じられる。1秒以上かかる場合に使う。詳しく読む
空の状態empty state: データが0件の時の画面。初めて使う人が最初に見る画面なので、「データがありません」で終わらせず、次に何をすればよいかを示す。詳しく読む

品質 / テスト

技術的負債負債 / technical debt: 後で直す前提で残した実装。放置すると利息のように開発速度を下げる。悪ではなく、意識的に借りて返すもの。
リファクタリング: 振る舞いを変えずに内部構造を整理すること。機能追加と同じ PR に混ぜるとレビューが困難になる。
カバレッジcoverage / テストカバレッジ: テストがコードのどれだけを通ったかの割合。高ければ品質が高いとは限らないが、極端に低いと危険。
AAAパターンArrange Act Assert: テストの書き方。準備（Arrange）・実行（Act）・検証（Assert）の3段に分けると読みやすい。
モックmock / スタブ: テストで外部依存を偽物に差し替えること。使いすぎると「テストは通るが本番で動かない」状態になる。
lintリンター / linter: コードの書き方の問題を機械的に指摘するツール。CI で落ちる原因の定番。
境界値boundary value / off-by-one: 0件・1件・最大件数・月末・うるう年など、境目の値。バグはほぼここに出るので、テストもここに集中させる。詳しく読む
フレーキーテストflaky test: 同じコードなのに、通ったり落ちたりするテスト。リトライで隠すと「たまに壊れる本番」を見逃すことになる。原因はたいてい時刻・順序・非同期待ち。詳しく読む

セキュリティ

XSSクロスサイトスクリプティング: ユーザー入力をそのまま HTML に出したせいで、任意のスクリプトを実行されてしまう脆弱性。innerHTML ではなく textContent を使う。
SQLインジェクションSQLi: SQL を文字列結合で組み立てたせいで、任意のクエリを実行されてしまう脆弱性。必ずパラメータ化クエリを使う。
CSRF: ログイン中のユーザーに、意図しないリクエストを別サイトから送らせる攻撃。トークンで防ぐ。
認証と認可authn / authz / authentication / authorization: 認証は「誰であるか」を確かめること、認可は「何をしてよいか」を決めること。別のもの。
JWTジョット / JSON Web Token: 署名付きのトークン。中身は誰でも読めるので秘密情報を入れてはいけない。一度発行すると失効させにくい。
シークレット秘密情報 / credential: API キーやパスワード。コードに書かず環境変数などで渡す。コミットしてしまったら、まず鍵を無効化して報告する。詳しく読む
OAuth 2.0oauth: 認可の仕組み。「このアプリに、自分の代わりにこの範囲だけ操作させる」ための許可の受け渡し。ログイン（認証）そのものではない。詳しく読む
OIDCOpenID Connect: OAuth 2.0 の上に認証を載せた規格。「誰であるか」を ID トークンとして受け取る。「Google でログイン」の中身はこれ。詳しく読む
ハッシュとソルトhash / salt / bcrypt / Argon2: パスワードは暗号化ではなくハッシュで保存する（戻せないことが重要）。同じパスワードが同じ値にならないよう、利用者ごとの乱数（ソルト）を混ぜる。詳しく読む
公開鍵暗号非対称鍵 / RSA / 楕円曲線: 公開鍵で暗号化し、秘密鍵でしか復号できない方式。鍵を事前に共有せずに安全な通信を始められるのが利点。TLS も SSH も土台はこれ。詳しく読む
電子署名digital signature: 秘密鍵で署名し、公開鍵で検証する。中身を隠すのではなく、改ざんされていないことと、誰が作ったかを証明するもの。詳しく読む
SBOMsoftware bill of materials: そのソフトウェアが何のライブラリをどのバージョンで含むかの一覧。脆弱性が公表された時に「うちは影響あるか」を即答するために要る。詳しく読む
ReDoS正規表現DoS: 書き方の悪い正規表現に長い文字列を食わせると、指数的に時間がかかりCPUを食い尽くす攻撃。利用者の入力を正規表現に通す箇所は要注意。詳しく読む
レートリミットrate limit: 一定時間あたりの回数を制限すること。総当たり攻撃と、悪意のない暴走クライアントの両方に効く。詳しく読む
最小権限least privilege: 必要な権限だけを、必要な期間だけ与える原則。侵入された時の被害範囲がそのまま変わる。詳しく読む
脅威モデリングthreat modeling / STRIDE: 設計の段階で「どこを、誰が、どう攻撃しうるか」を洗い出す作業。作ってから直すより、圧倒的に安い。詳しく読む
プロンプトインジェクションprompt injection: LLM への入力に命令を混ぜ込み、本来の指示を上書きさせる攻撃。LLM は命令とデータを区別できないため、入力の検証ではなく出力側の権限で防ぐ。詳しく読む
sudo: 必要な時だけ管理者としてコマンドを実行する仕組み。常に root で作業しないのは、事故を減らし、誰が何をしたかを残し、乗っ取られた時の被害を抑えるため。詳しく読む
push protection: secret scanning が検出した秘密情報の push を、GitHub 側でブロックする機能。一度 push したものは消しても履歴に残るので、事前に止める価値が大きい。ただし予防策の1つであって、漏れた後は鍵の無効化と再発行が最優先。詳しく読む

社内でよく出る言い回し

握る: 関係者間で合意を取ること。「PdM と握っておいて」= 事前に合意を取っておいて、の意味。
巻き取る: 他の人の作業を引き受けること。「こっちで巻き取ります」= 自分がやります。
温度感: 緊急度や重要度の肌感覚。「温度感を教えてください」= どれくらい急ぐか知りたい、の意味。
よしなに: 「いい感じにやっておいて」。判断を任されているが、基準が不明なら必ず確認すること。
一次情報: 公式ドキュメントやソースコードなど、元の情報。ブログ記事は二次情報。迷ったら一次情報を見る。
積む: タスクをバックログに追加すること。「来週に積んでおきます」。
ペアプロペアプログラミング / モブプロ: 2人（複数人）で1つの画面を見ながら実装すること。新人が最短で慣れる方法なので、遠慮せずお願いしてよい。
ラバーダックrubber duck: 人に説明しようと状況を言葉にしている途中で、自分で答えに気づく現象。質問を書く効果の1つ。
30分ルール: 30分考えて進まなければ人に聞く、という目安。新人が最も評価を落とすのは技術力不足ではなく報告の遅れ。詳しく読む