付録B: 用語索引

本書で初出時に定義した主要語を章別にまとめる。詳細な使い方は各章の本文を参照する。

第1章研修の地図を持つ

研修の地図：個別の技術項目を、価値、実装、品質、運用、共有の流れへ置き直した見取り図。
現在地メモ：自分が分かっていること、分からないこと、次に確認することを短く残すメモ。
最終プロジェクト：研修の各章で練習した作業の型を、一つの小さなプロダクトに統合する課題。
証拠：説明を支えるログ、テスト結果、PR、文書、画面、デモなどの具体物。

第2章価値から機能を考える

ユーザー：機能を使って判断、作業、確認をする人。依頼者と同じとは限らない。
成果：機能が完成したことではなく、利用者の困りごとがどう良くなるか。
MVP：Minimum Viable Productの略。最初に価値を確かめるための最小構成。
Decision Memo：背景、選択肢、採用案、採用しない案、確認方法を残す意思決定メモ。

第3章 AIを使い、検証して進める

AI利用計画：AIへ依頼する前に、目的、渡す情報、禁止事項、検証方法を決める文書。
検証：AIの出力を、実行結果、公式資料、テスト、画面確認などで確かめる行為。
機密情報：社外やAI入力へ出してはいけない顧客情報、認証情報、未公開情報、内部資料。
AI利用ログ：AIの出力、採用判断、確認結果、残る不確実性を残す記録。

第4章チームに情報を渡す

技術相談文：状況、期待結果、実際の結果、確認したこと、判断してほしいことを渡す文書。
変更説明メモ：なぜ変えたか、何を変えたか、どう確認したかをレビュー前に整理する文書。
レビュー返信：指摘への対応内容、未対応理由、再確認方法を短く返す文章。
観察と推測：実際に見た事実と、そこから考えた原因候補を分けるための区別。

第5章手元で動かす作業場

プロジェクトルート：プロジェクト全体を見渡す基準のディレクトリ。READMEや設定ファイルが置かれることが多い。
ローカル：自分の手元のPC上で動く環境。ファイル、プロセス、ポート、環境変数の状態を含む。
CLI：Command Line Interfaceの略。文字でコマンドを入力して操作する入口。
パス：ファイルやディレクトリの場所を表す文字列。絶対パスと相対パスがある。
ランタイム：Node.jsやPythonなど、アプリを実行するための基盤。
依存関係：アプリが動くために追加で必要とするライブラリやパッケージ。
localhost：自分のPC自身を指す名前。ローカルで起動したサーバーへアクセスするときに使う。
ログ：アプリやサーバーが実行中に残す出来事の記録。
ポート：同じPCやサーバー上で通信先を区別する番号。
プロセス：PC上で実行中の仕事。開発サーバーは起動後も動き続けるプロセスである。
環境変数：コードの外から実行時の設定を渡す仕組み。接続先やsecretの指定に使われる。

第6章変更をレビューにつなげる

Git：ファイルの変更履歴を手元で管理する道具。
GitHub：Gitの履歴をチームで共有し、PRやレビューを行う場所。
working tree：いま編集しているファイル群の状態。commit前の変更がここに現れる。
staging area：次のcommitに含める変更を選んで置く場所。
diff：変更前と変更後の差分。追加、削除、変更された行を確認する材料。
staged diff：次のcommitに入る予定の差分。git diff --staged で確認する。
branch：本流から分けて変更を進める作業場所。
commit：後から読める単位で保存した変更履歴。
remote：GitHubなど、手元以外にある共有先repository。
push：手元のcommitをremoteへ送る操作。
merge：別branchの変更を現在のbranchへ取り込む操作。
Pull Request：変更をレビューしてもらい、本流へ取り込むための提案。
review comment：Pull Request上で、差分や設計、確認方法についてやり取りするコメント。
conflict：同じ場所に複数の変更が入り、Gitが自動で最終状態を決められない状態。
conflict marker：conflictした箇所を示す <<<<<<<、=======、>>>>>>> の印。

第7章 Webの通信を観察する

HTTP：HyperText Transfer Protocolの略。ブラウザとサーバーがWeb上で情報をやり取りするための約束ごと。
URL：Web上の対象を指す入口。scheme、host、path、queryなどに分けられる。
scheme：URLの先頭で通信方法を示す部分。例としてhttpやhttpsがある。
host：接続先の名前。localhostやexample.comなど。
port：同じhost上の通信入口を分ける番号。ローカル開発では3000番などをよく使う。
path：URLの中で、サーバー上の画面やAPIの場所を示す部分。
query：URLの ? 以降に置く条件。検索条件や絞り込み条件に使われることがある。
fragment：URLの # 以降に置くページ内位置などの情報。通常HTTP requestとしてサーバーへ送られない。
origin：scheme、host、portの組み合わせ。CORSの切り分けで重要になる。
DNS：Domain Name Systemの略。名前から接続先を探す仕組み。
HTTP request：ブラウザやcurlからサーバーへ送る依頼。
HTTP response：サーバーからクライアントへ返る結果。status、headers、bodyを含む。
method：GET、POST、PATCH、DELETEなど、requestで何をしたいかを示す言葉。
status code：responseの大まかな結果を数字で示す値。
headers：requestやresponseに付く追加情報。認証や形式、Cookieなどに関係する。
Content-Type：bodyの形式を示すheader。JSON、HTML、フォームなどを区別する手がかりになる。
body：requestやresponseの本体。HTML、JSON、送信データ、エラーメッセージなどが入る。
Cookie：ブラウザが保存し、条件に合うrequestへ添付する小さな情報。
Set-Cookie：サーバーがブラウザへCookie保存を指示するresponse header。
session：ログイン状態など、利用者に関する状態をサーバー側で扱う仕組み。
Authorization header：認証情報をrequestへ付けるheader。tokenなどを含むため提出物やAI入力では伏せる。
curl：ターミナルからHTTP通信を確認する道具。
Networkタブ：ブラウザの開発者ツールで、画面表示や操作に伴うHTTP通信を観察する場所。
CORS：Cross-Origin Resource Sharingの略。ブラウザが異なるoriginへの通信を安全上制御する仕組み。

第8章既存コードを小さく読む

再現：同じ手順で同じ不具合を起こし、修正前後を比べられる状態にすること。
再現手順：不具合を同じ状態で起こすための操作手順。修正後の確認にも使う。
期待結果：本来起きるべき結果。仕様、課題文、利用者の目的から決める。
実際の結果：実際に観察された結果。画面、Network、curl、ログなどで確認する。
観察した事実：実際に見た出力、通信、ログ、差分。推測と混ぜない。
仮説：観察した事実から考えた原因候補。外れる確認方法も必要になる。
入口：URL、API、画面表示、ログなどからコードを読み始める場所。
検索語：関連コードを探すために使うURL、API名、画面文言、field名、エラーメッセージなどの手がかり。
呼び出しの流れ：画面、API handler、ロジック、データ、テストがどの順でつながるか。
スタックトレース：エラーがどの呼び出しの流れで起きたかを示す一覧。
最小修正：原因に対応する範囲へ絞った変更。周辺の設計変更を混ぜない。
回帰確認：直した不具合が戻っていないことと、既存の正常系が壊れていないことを確かめる確認。
影響範囲：変更によって動きが変わる可能性がある画面、API、データ、テスト、利用者の範囲。
差分：変更前と変更後の違い。レビューでは修正内容と影響範囲を確認する材料になる。

第9章要件からドメインを整理する

ドメイン：その仕事で使う言葉、ルール、状態、例外のまとまり。
機能要求：利用者や関係者から出る、実現したい機能の要望。実装方法とは分けて読む。
ユースケース：誰が何のために何をするかを、一つの流れとして書いたもの。
用語集：チームが同じ言葉を同じ意味で使うための一覧。
状態：対象が今どういう段階にあるかを表す値。
イベント：状態を変えるきっかけになる出来事。誰が何をしたかとして表す。
ルール：いつ、誰が、何をしてよいか、何をしてはいけないかを決める条件。
境界：今回作る範囲、今回は作らない範囲、後で検討する範囲を分ける線。
MVP：最初に価値や前提を確認するための最小範囲。雑に作ることではない。
ドメインモデル：業務で出てくる主な概念と関係を表すたたき台。DB設計の前段階として使う。
受け入れ条件：実装が要求を満たしたと言える具体的な条件。
Given / When / Then：前提、操作、結果に分けて受け入れ条件を書く型。

第10章データを保存できる形にする

RDB：Relational Databaseの略。データをテーブルと関係として扱うデータベース。
テーブル：同じ種類の事実を行として保存する場所。
行：テーブルに保存される1件のデータ。
カラム：一つの行に保存する属性。型、NULL可否、制約とセットで考える。
制約：データが矛盾しないようにデータベース側で守るルール。
主キー：行を一意に識別する値。
外部キー：別のテーブルの行との関係を守る制約。
参照整合性：外部キーなどにより、存在しない相手を参照するデータを防ぐ性質。
NULL：値がない、または不明であることを表す特別な値。空文字、0、noneとは意味が違う。
NOT NULL：そのカラムにNULLを入れられないようにする制約。
UNIQUE：同じ値、または同じ値の組み合わせを重複させない制約。
CHECK制約：カラムに入れてよい値や条件をデータベース側で制限する制約。
DDL：Data Definition Languageの略。テーブルや制約など、DBの構造を定義するSQL。
DML：Data Manipulation Languageの略。データの追加、更新、削除、取得を行うSQL。
JOIN：関係するテーブル同士を条件でつないで読む操作。
LEFT JOIN：左側のテーブルの行を残しつつ、右側のテーブルに一致する行があれば結合する操作。
ON CONFLICT：主キーやUNIQUE制約にぶつかったときの扱いを指定するUPSERT系の構文。DBMSにより書き方が違う。
UPSERT：行がなければ追加し、既にあれば更新する操作を表す俗称。DBMSにより構文が違う。
正規化：同じ意味のデータを重複して持ち、不整合が起きることを減らす考え方。
インデックス：検索や結合を助けるためのデータベース上の仕組み。
トランザクション：複数の更新をひとまとまりとして成功または失敗させる仕組み。
マイグレーション：アプリの変更に合わせてDBスキーマを段階的に変更する作業。
バックフィル：既存データに対して、新しく追加したカラムやテーブルの値を埋める作業。

第11章 APIで画面と業務をつなぐ

API：画面や他のシステムがバックエンドへ依頼するための契約。
HTTP JSON API：HTTPで呼び出し、主にJSON形式で入力や出力をやり取りするAPI。
endpoint：APIの入口。methodとpathで操作の対象と種類を示す。
HTTP method：GET、POST、PATCHなど、requestで何をしたいかを示す種類。
CRUD：Create、Read、Update、Deleteの略。作成、取得、更新、削除の基本操作。
request：クライアントからAPIへ送る入力。
response：APIからクライアントへ返す出力。
path params：URLの一部として対象を指定する値。例: /learners/{learnerId}。
query params：URLの?以降で絞り込みや表示条件を指定する値。
headers：requestやresponseに付く追加情報。認証、形式、Cookieなどに使われる。
Authorization header：認証情報を送るためによく使われるHTTP header。
Bearer token：Authorization headerで使われることが多いtoken形式。実際の値はログや提出物に残さない。
Content-Type：requestやresponseのbody形式を示すheader。JSONなら application/json を使うことが多い。
body：requestやresponseの本文。JSONなどのデータ本体が入る。
HTTP status code：HTTP responseで処理結果の種類を数字で伝える合図。
safe method：通常はサーバー状態を変更しないHTTP method。代表例はGET。
idempotent：同じrequestを複数回送っても、結果の状態が同じになる性質。
認証：利用者が誰かを確認すること。
認可：その利用者がその対象を操作してよいかを確認すること。
入力検証：外から来た値の形式、必須、長さ、許容値を確認すること。
error response：失敗時に返すresponse。status code、code、message、fieldsなどを含める。
requestId：requestごとに付ける識別子。画面のエラー、サーバーログ、監視ログを結びつけるために使う。
handler：HTTP requestを受け、入力を読み、処理を呼び、responseへ変換する入口の関数。
use case：業務上の操作やルールを表す処理のまとまり。
repository：DBなどの保存先への読み書きを担当する部品。
curl：ターミナルからHTTP requestを送ってAPIを確認するコマンド。

第12章フロントエンドとアクセシビリティ

フロントエンド：利用者が触る画面と、その画面状態を扱う部分。
UI state：読み込み中、空、入力中、保存中、成功、失敗など画面の状態。
アクセシビリティ：多様な利用者や操作方法で使えるようにする品質。
セマンティックHTML：見た目ではなく意味に合うHTML要素を選ぶ考え方。
label：入力欄が何のためのものかを利用者や支援技術へ伝える要素。
form：入力と送信をひとまとまりの操作として扱うHTML要素。
button：利用者が実行する操作を表す要素。
フォーカス：キーボード操作で今どの要素が操作対象かを示す状態。
WCAG：Web Content Accessibility Guidelinesの略。Webアクセシビリティの国際的な基準。
ARIA：Accessible Rich Internet Applicationsの略。HTMLだけでは足りない意味や状態を補う属性群。ネイティブHTMLを置き換えるものではない。
アクセシブルネーム：支援技術が入力欄やbuttonなどの名前として扱うテキスト。
aria-describedby：入力欄などと、説明文やエラー文を関連づけるARIA属性。
aria-invalid：入力値が不正であることを示すARIA属性。
aria-live：画面上の変化を支援技術へ通知するためのARIA属性。
role=“status”：状態メッセージを支援技術へ伝えるために使われるARIA live regionの役割。
フォーカス順：Tabキーなどで操作対象が移動する順番。基本的にはHTMLのDOM順に従う。
tabindex：要素のフォーカス可否や順序に関係する属性。正の値で順番を作ると保守が難しくなりやすい。
コントラスト比：文字やUI部品と背景の明暗差を数値化したもの。
Network：ブラウザ開発者ツールでHTTP requestとresponseを確認する場所。
Console：ブラウザでJavaScriptエラーや警告を確認する場所。
Elements：ブラウザでHTML構造、属性、ラベルの関係を確認する場所。
コンポーネント：画面の一部を役割ごとに分けた部品。
レスポンシブ：画面幅が変わっても主要な情報と操作が崩れないようにする考え方。

第13章テストとコード品質

テスト戦略：何を守りたいか、どのリスクをどの種類のテストで確認するかの方針。
テスト観点：何を確認したいかを表す視点。まだ具体的な手順ではない。
テストケース：条件、操作、期待結果を持つ具体的な確認項目。
テストコード：テストケースを自動実行できる形で書いたコード。
手動確認：人が画面、ログ、ブラウザ開発者ツールなどを見て確認すること。
TDD：Test-Driven Developmentの略。失敗するテスト、最小実装、整理を短く回す進め方。
リファクタリング：外から見えるふるまいを変えず、内部構造を整理する変更。
テストピラミッド：速さ、範囲、信頼性の違うテストを組み合わせる考え方。
単体テスト：小さな関数やロジックを、外部要素からできるだけ切り離して確認するテスト。
統合テスト：複数の部品を組み合わせ、部品同士の接続や保存結果を確認するテスト。
APIテスト：HTTP request、response、必要なら保存結果を通じてAPI契約を確認するテスト。
E2E：End-to-Endの略。利用者に近い操作から複数の部品をまたいで確認するテスト。
カバレッジ：テスト実行時に、コードのどの行や分岐が通ったかを示す指標。
flaky test：同じコードでも通ったり落ちたりする不安定なテスト。
テスト分離：各テストが実行順序や他のテストの結果に依存しないようにすること。
回帰確認：変更によって、以前動いていたふるまいが壊れていないかを確認すること。
characterization test：既存コードの現在のふるまいを記録し、変更で壊していないかを見るためのテスト。
境界値：許される値と拒否される値の境目にある入力。
fixture：テストで使う前提データを再利用しやすく用意する仕組み。
factory：テストデータを必要な条件に合わせて作る仕組み。
テストダブル：本物の外部部品の代わりに使うテスト用の代替部品の総称。
mock：外部部品の呼び出しや期待された使われ方を確認するための代替部品。
stub：決まった応答を返す代替部品。
内部品質：利用者から直接は見えないが、読みやすさ、変更しやすさ、テストしやすさに関わる品質。
技術的負債：後で修正や整理が必要になる設計上、実装上の借り。

第14章セキュリティの基本

資産：守るべきデータ、機能、権限、可用性、信頼。
脅威：資産に対して起きてほしくない出来事や悪用の可能性。
攻撃者：意図的な攻撃者だけでなく、権限を越えた利用者や誤操作を含む主体。
信頼境界：信頼できる前提が変わる境目。browserからAPI、APIからDBなど。
OWASP Top Ten：Webアプリケーションでよく問題になるリスクを整理したOWASPの資料。
ASVS：Application Security Verification Standardの略。アプリケーションのセキュリティ確認項目を体系化した標準。
SSDF：Secure Software Development Frameworkの略。セキュアなソフトウェア開発の高水準プラクティスをまとめたNIST文書。
認証：利用者が誰かを確認すること。
認可：その利用者がその操作をしてよいかを確認すること。
IDOR：Insecure Direct Object Referenceの略。IDを書き換えることで、本来アクセスできない対象へ届く問題。
BOLA：Broken Object Level Authorizationの略。対象オブジェクトごとの認可が壊れている問題。
入力検証：外から来た値の形式、範囲、業務ルールを確認すること。
出力エンコード：値を表示する文脈に合わせて、コードとして解釈されない形にすること。
SQLインジェクション：信頼できない入力がSQLの構造を変えてしまう問題。
パラメータ化クエリ：SQLの構造と値を分け、入力をSQL命令として解釈させにくくする書き方。
ORM：Object-Relational Mappingの略。プログラム上のオブジェクトとDB操作を対応づける仕組み。
XSS：Cross-Site Scriptingの略。信頼できない入力がブラウザ上でコードとして実行される問題。
CSRF：Cross-Site Request Forgeryの略。ログイン中のブラウザから意図しない更新requestが送られる問題。
CSRF token：正規の画面やフォームから送られたrequestかを確認するためのtoken。
SameSite：Cookieが別サイト由来のrequestに送られる条件を制御するCookie属性。
HttpOnly：JavaScriptからCookieを読みにくくするCookie属性。
Secure属性：HTTPS通信時だけCookieを送るようにするCookie属性。
CSP：Content Security Policyの略。ブラウザで読み込めるscriptなどを制限し、XSS被害を減らすための仕組み。
secret：APIキー、パスワード、トークンなど外へ出してはいけない値。
rotation：secretを無効化または更新し、古い値を使えないようにすること。
依存関係：アプリが利用する外部ライブラリやパッケージ。
lock file：実際に使う依存関係のversionを固定するファイル。
直接依存：自分の依存関係ファイルに直接書いたpackage。
間接依存：直接依存しているpackageがさらに利用しているpackage。
ソフトウェアサプライチェーン：外部ライブラリ、registry、ビルド、配布など、ソフトウェアが作られ届くまでのつながり。
監査コマンド：依存関係などに既知の脆弱性がないかを確認するコマンド。
最小権限：必要な操作に必要な範囲だけの権限を与える考え方。
監査ログ：後から誰が何をしたかを確認するためのログ。

第15章コンテナと実行環境

image：コンテナを起動するための読み取り専用テンプレート。
container：imageから起動した実行中の単位。
layer：imageを構成する差分の積み重ね。Dockerfileの命令ごとに作られることがある。
Dockerfile：imageの作り方を記録するファイル。
Compose：アプリ、DBなど複数サービスの起動関係を記録する仕組み。
Compose Specification：Compose fileの構造やservicesなどを定義する仕様。
volume：コンテナの外側へデータを残すための保存場所。
named volume：Dockerが名前で管理するvolume。DBデータの永続化などに使う。
build context：imageを作るときDockerへ渡すファイルの範囲。
.dockerignore：build contextから除外するファイルやディレクトリを指定するファイル。
service：Composeで定義するapp、dbなどの実行単位。
network：container同士が通信するための仮想的な接続範囲。
service名：Compose内で他serviceへ接続するときに使える名前。例として db がある。
port mapping：host側のportとcontainer側のportを対応させる設定。
EXPOSE：Dockerfileでcontainerが待ち受けるportの意図を示す命令。host公開そのものではない。
environment variable：環境ごとに変わる設定値を外から渡す仕組み。
DATABASE_URL：DB接続情報をURL形式でまとめた環境変数名としてよく使われる名前。passwordを含む場合はsecretとして扱う。
.env：ローカルなどで環境変数の値を置くファイル。secretを含む場合はcommitしない。
.env.example：必要な環境変数名と安全な例を共有するための見本ファイル。
bind mount：host側のファイルやディレクトリをcontainer内へ見せる開発用の仕組み。
healthcheck：serviceが起動しただけでなく利用可能かを確認するための検査。
depends_on：Composeでservice間の起動順や依存関係を表す設定。利用可能状態の確認とは分けて考える。
非root実行：container内のprocessをrootではないuserで動かすこと。
base image：Dockerfileの FROM で指定する、image作成の出発点。
image tag：imageのversionやvariantを示す名前。例として node:20-alpine がある。
migration：アプリの変更に合わせてDB schemaを変更する作業。
seed：開発や初期起動のためにDBへ入れる初期データ。

第16章クラウドとCI/CD

クラウド：実行、保存、通信、権限、監視などをサービスとして組み合わせる環境。
CI：Continuous Integrationの略。変更を継続的に検証する流れ。
CD：Continuous DeliveryまたはDeploymentの略。検証済みの変更を環境へ届ける流れ。
AWS account：AWS resource、請求、権限の境界になる単位。
region：AWS resourceを配置する地理的な範囲。
IAM：Identity and Access Managementの略。誰が何をできるかを管理するAWSの仕組み。
OIDC：OpenID Connectの略。GitHub Actionsなどが短期認証情報を得るために使える認証連携方式。
ECR：Elastic Container Registryの略。container imageを保存するAWSのregistry。
App Runner：container imageやsourceからWebアプリを実行するAWSのmanaged service。
ECS Express Mode：container imageからWebアプリやAPIを簡易にdeployするAmazon ECSのモード。Fargate、load balancer、networking、monitoringなどを組み合わせて作る選択肢。
RDS：Relational Database Serviceの略。AWSが管理するリレーショナルデータベース。
VPC：Virtual Private Cloudの略。AWS内でnetwork境界を作る仕組み。
VPC connector：App RunnerなどからVPC内resourceへ通信するための接続設定。
security group：AWS resourceへ入る通信、出る通信を制御する仮想firewall。
Secrets Manager：secretを保存、参照、rotationしやすくするAWS service。
Parameter Store：Systems Managerの機能。設定値やsecret参照を管理する選択肢。
CloudWatch Logs：AWS上のアプリやserviceのログを集めて確認する場所。
CloudWatch log group：CloudWatch Logsでログをまとめる単位。
IAM policy：roleやuserに許可するAWS操作を定義する文書。
trust policy：どの主体がIAM roleを引き受けられるかを定義する文書。
workflow permissions：GitHub Actions workflowがGitHub上で使える権限設定。
GitHub Actions environment：stagingやproductionなどの環境単位でsecret、variables、承認を分ける仕組み。
required reviewers：GitHub Actions environmentでdeploy前に承認者を要求する設定。
staging：productionに近い条件でリリース前確認を行う環境。
production：実際の利用者に影響する本番環境。
health check：serviceが動いているかを確認する検査。
readiness check：serviceが外部からrequestを受けられる準備状態かを確認する検査。
smoke test：deploy後に最低限の主要動作を短く確認するテスト。
image tag：container imageの版を識別する名前。
image digest：container imageの内容に対応する識別子。tagより内容追跡に向いている。
tag immutability：同じimage tagの上書きを防ぐ設定や方針。
manual approval：自動処理の途中で人の承認を必要にする制御。
rollback：問題が起きたとき、前の正常な状態へ戻すこと。
roll forward：戻すのではなく、追加修正を出して前へ進める復旧方法。
feature off：feature flagや設定で問題の機能を止める対応。
runbook：運用時に実行する手順、確認、問題時対応をまとめた文書。
lifecycle policy：古いimageやlogなどをいつ削除するかを定める方針や設定。
ARN：Amazon Resource Nameの略。AWS resourceを識別する名前。
cleanup：検証後に不要なcloud resourceを削除し、費用やリスクを残さない作業。

第17章オブザーバビリティとSRE

オブザーバビリティ：外から得られる情報で、システム内部の状態を調べられる性質。
モニタリング：あらかじめ決めた指標や条件を継続的に見て、異常や傾向に気づく活動。
テレメトリ：システムが外へ出す観測用データ。ログ、メトリクス、トレースなどを含む。
ログ：出来事を時系列で残す記録。
構造化ログ：messageだけでなく、request_id、endpoint、status、duration_msなどのfieldを持つログ。
log level：info、warn、errorなど、ログの重要度や扱いを分ける分類。
メトリクス：数値として継続的に測る指標。
counter：増え続ける値を表すmetric type。request数やerror数などに使う。
gauge：上下する現在値を表すmetric type。CPU使用率、memory使用量、接続数などに使う。
histogram：値の分布を集計するmetric type。latencyのp95やp99などに使う。
metric label：metricをendpointやenvironmentなどの軸で分けるための属性。
cardinality：metric labelの組み合わせ数。増えすぎると費用、保管量、集計負荷が増える。
トレース：一つの処理が複数の場所を通る流れを追う記録。
span：トレースの中で、DB queryや外部API呼び出しなど一つの処理区間を表す単位。
instrumentation：アプリがlogs、metrics、tracesを出せるように計測処理を組み込むこと。
request_id：一つのrequestをログ上で追いやすくする識別子。
trace_id：複数のserviceやspanにまたがる処理全体を追う識別子。
latency：requestを受けてからresponseを返すまでの遅延時間。
error rate：request全体のうち、失敗したrequestの割合。
traffic：一定時間あたりのrequest数や処理量。
saturation：CPU、memory、DB connectionなど、resourceがどれだけ限界に近いかを示す状態。
p50 / p95 / p99：応答時間の分布を見る百分位。p95は95%のrequestがその値以下で終わることを示す。
SLI：Service Level Indicatorの略。利用者に関係するservice levelを測る定量指標。
SLO：Service Level Objectiveの略。利用者に対して守りたい信頼性の目標。
error budget：SLOを満たしながら許容できる失敗の余地。
アラート：人が確認または対応すべき状態を通知する仕組み。
period：CloudWatch alarmなどで、一つのdata pointを作る時間幅。
evaluation periods：alarm判定で直近いくつのdata pointを見るかを表す設定。
datapoints to alarm：評価対象のうち何個が条件を満たしたらalarm状態にするかを表す設定。
ダッシュボード：重要な指標と状態を、判断のためにまとめて見る画面。
インシデント：利用者影響、データ影響、運用対応などが必要になる望ましくない出来事。
mitigation：根本原因の完全解決前に、利用者影響を下げる暫定対応。
recovery：利用者に必要な機能や状態が復旧したこと。
ポストモーテム：インシデントの事実、影響、原因、対応、再発防止を責任追及ではなく学習としてまとめる文書。
CloudWatch Logs：AWS上のアプリやserviceのログを集め、検索、集計、確認する場所。
CloudWatch Logs Insights：CloudWatch Logsをqueryで検索、集計、可視化する機能。
CloudWatch Application Signals：アプリのlatency、error、requestなどを使い、service healthやSLO確認に使えるCloudWatchの機能。
X-Ray：AWSでrequestの流れやlatencyをtraceとして確認するためのservice。

第18章 LLMと生成AIの基礎

LLM：Large Language Modelの略。自然言語やコードの入力をもとに出力を生成するモデル。
生成AI：文章、コード、画像などの新しい出力を生成するAI。出力は下書きであり検証が必要である。
model：入力をもとに出力を作るAIの本体。得意なタスク、速度、費用、出力の癖が異なる。
prompt：AIへ渡す依頼文。目的、条件、出力形式を含める。
instruction：AIに守ってほしい作業指示。目的、役割、制約、禁止事項、評価条件などを含む。
context：AIへ渡す参考情報。仕様、コード、ログ、文書など。
output format：AIの出力形式。表、JSON、箇条書き、PR本文など、後で使う形を指定する。
temperature：出力の揺らぎやすさに関係する設定。高ければ創造的になりやすく、低ければ安定しやすい。
hallucination：もっともらしいが根拠がない、または誤った出力。
stale knowledge：モデルが持つ知識や参照情報が古く、現在の仕様や事実とずれること。
uncertainty：根拠不足、情報不足、矛盾などにより、断定できない状態。
RAG：Retrieval-Augmented Generationの略。検索して取り出した情報を生成に使う考え方。
retrieval：質問やタスクに関係する文書、ログ、コード、データを検索して取り出すこと。
grounding：AIの出力が、渡した根拠資料や観察された事実に基づいている状態。
citation：主張がどの情報源に基づくかを示す参照表示。リンクがあるだけで正しいとは限らない。
tool use：AIが検索、DB参照、ファイル読み取り、コード実行など外部の道具を使うこと。
function calling：決められたschemaに沿って、AIが外部関数やtoolの呼び出し入力を組み立てる仕組み。
schema：tool入力や出力形式を、項目名、型、必須項目などで定義した構造。
agent：目標に向けて手順を計画し、toolを使い、結果を見て次の行動を決める仕組み。
human-in-the-loop：重要な判断や影響の大きい操作の前に、人間が確認する設計。
rubric：AI出力を評価する採点表。事実性、根拠、安全性、形式などの評価軸を持つ。
test case：AI出力を試す具体的な場面や入力例。通常例だけでなく失敗しやすい例も含める。
評価：AI出力を採用してよいか、根拠、正確性、安全性、使いやすさで確認すること。
prompt injection：入力文によって、本来の指示や制約を無視させようとする攻撃や誤作動の要因。
sensitive information disclosure：秘密情報、個人情報、顧客情報、内部情報がAI入力や出力を通じて漏れること。
excessive agency：AIに過剰な自律性や権限を与え、意図しない操作や影響を起こすリスク。
overreliance：AI出力を批判的に確認せず、判断や作業を過度に依存すること。

第19章 AIコーディングの実務ワークフロー

AIコーディング：AIにコード生成だけでなく、調査、計画、編集、テスト、レビュー補助を担わせる管理された開発作業。
AI coding agent：codebaseを読み、file編集やcommand実行まで行えるAI支援ツール。
Claude Code：codebaseを読み、file編集、command実行、開発tool連携を行えるagentic coding tool。
Codex：ローカルCLIやcloud taskでコード調査、編集、実行、レビューを支援するOpenAIのAI coding agent。
feature brief：AIやチームへ渡す、機能、利用者、目的、範囲、品質条件、受け入れ条件の短い説明。
acceptance criteria：何ができれば完了とみなすかを、利用者行動や確認条件として書いた受け入れ条件。
context pack：AIに読ませるファイル、workspace状態、既存パターン、実行してよいコマンド、禁止情報のセット。
plan mode：実装前に調査、既存パターン、変更案、テスト案、リスクを出させる計画段階。
permission：AIがfile read、edit、command実行、git操作などをどこまで行えるかを管理する権限設定。
sandbox：AIやAIが起動したcommandが触れられるfile、network、system resourceを制限する境界。
approval：AIが強い操作を行う前に、人間が許可するか判断する確認点。
allow / ask / deny：AIのtool利用を、許可、確認後に許可、禁止に分けるpermissionの考え方。
settings：Claude Codeの権限、hooks、MCPなどをmanaged、user、project、localなどのscopeで管理する設定。
CLAUDE.md：プロジェクトの開発コマンド、設計方針、禁止事項、レビュー観点などをAIへ伝えるmemory file。強制境界やsecret置き場ではない。
hook：Claude Codeのlifecycleの特定時点で、format、lint、通知、blockなどの処理を動かす仕組み。
skill：繰り返し使う手順、チェックリスト、専門作業のinstructionsを再利用する仕組み。
session plan：AIとの作業を調査、実装、検証、レビューへ分け、permission、sandbox、approvalを明示する計画。
allowed scope：AIが触ってよいfile、area、command、変更種類の範囲。
stop condition：変更範囲拡大、secret要求、同じ失敗の反復など、AI作業を止めて人間が判断する条件。
small diff：意味のある小さな単位で作られ、戻しやすくレビューしやすい差分。
diff review：AIが編集した差分を、人がgit状態、目的、範囲、品質、依存変更、リスクで確認すること。
manual check：自動テストだけでは見えない画面操作、アクセシビリティ、文面、動線を人間が確認すること。
ai-work-log：AIへの依頼、使ったtool、採用した計画、採用しなかった提案、変更ファイル、検証結果、失敗と修正、残課題を残す記録。
AI-assisted PR description：AIを使った変更について、変更概要、確認結果、実行しなかった確認、人間がレビューした点、残課題をPRで説明する文書。

第20章テクニカルライティングと知識共有

テクニカルライティング：技術的な事実、手順、判断、制約を、読者が次に行動できる形へ整理して書くこと。
知識共有：個人の作業記憶を、チームと未来の自分が再利用できる文書や履歴へ変えること。
読者：文書を読んで次の行動を取る人。知識量と目的を明示する必要がある。
目的：読者が文書を読んだ後にできるようになる行動や判断。
読むタイミング：新規参加時、レビュー前、障害対応中、設計変更時など、その文書が必要になる場面。
事実・判断・推測・未決定：確認済みのこと、決めたこと、仮説、まだ決めていないことを分ける整理。
文書タイプ：読者の目的に応じて、README、設計メモ、ADR、runbook、インシデント報告などを選ぶ分類。
チュートリアル：初めて学ぶ人が、順に手を動かして成功体験を得るための文書。
ハウツー：すでに基本を知る人が、特定の作業や問題を解決するための文書。
リファレンス：仕様、API、コマンド、設定値などを正確に引くための文書。
説明：背景、理由、設計意図、選択肢の関係を理解するための文書。
README：使い始める人に、概要、起動方法、確認方法、注意点を渡す入口文書。
設計メモ：背景、課題、制約、根拠、選択肢、採用案、影響、残課題、未決定事項を残す文書。
ADR：Architecture Decision Recordの略。一つの重要な技術判断について、文脈、決定、状態、良い/悪い/中立の結果を残す文書。
PR説明：変更の背景、内容、確認方法、未実行確認、レビューしてほしい点をレビュアーへ渡す入口文書。
runbook：繰り返す運用作業や障害時対応を、前提、使ってよい条件、手順、確認、戻し方としてまとめる文書。
インシデント報告：問題の事実、影響、対応、原因候補、未確認事項、再発防止を学習可能にする文書。
Diátaxis：文書をチュートリアル、ハウツー、説明、リファレンスに分ける考え方。
判断理由：結論に至った背景、制約、比較、採用しなかった案を含む説明。
再現性：別の読者が同じ前提と手順で、同じ確認や作業をたどれる性質。
文書レビュー：誤字だけでなく、読者、目的、事実、再現性、判断理由、古さ、機密情報、AI推敲後の差分を確認する作業。
source of truth：文書の内容を確認するときに最終的に戻るべき正本。
更新担当：文書が古くなったとき、確認し直す責任を持つ役割や人。
last reviewed：文書が最後に実態と照合された日付。
superseded：古い判断が新しい判断に置き換えられた状態。古い文書を消さず、置き換え先を示すために使う。

第21章個人開発プロジェクト

個人開発プロジェクト：自由テーマを選び、小さなWebアプリとして企画、実装、確認、説明まで自分で進める課題。
自由テーマ：何を作るかを自分で選べる形式。ただし、ユーザー、課題、範囲、確認方法を説明できる必要がある。
Project Brief：個人開発の利用者、問題、成果、主な流れ、範囲、制約をまとめる企画メモ。
User：そのプロダクトで作業や判断が少し良くなる対象者。自分自身でもよいが、状況を具体化する。
Problem：ユーザーが今困っている具体的な状態。作りたい機能名とは分けて書く。
Outcome：プロダクトを使った後に、ユーザーの作業や判断がどう良くなるか。
Success Signal：MVPが価値を見せられたと言える、観察可能な操作や結果。
In Scope：今回作る範囲。最初の完成形に必要な機能、画面、データ、確認を含む。
Out of Scope：今回は作らない範囲。通知、課金、多人数共有、外部連携などを明示して範囲拡大を防ぐ。
Constraints：時間、技術、データ、安全性、研修条件など、設計判断に影響する制約。
Data Safety：扱うデータ、保存場所、公開範囲、削除方法、AI入力可否を確認する観点。
Data Lifecycle：データを保存するか、どう更新・削除するか、AIへ入力してよいかを確認する観点。
Riskiest Assumption：外れているとMVPの価値や実装計画が大きく崩れる、いちばん不確かな前提。
Evidence Needed：不確かな前提や成功のサインを確認するために必要な操作、ログ、画面、テスト結果。
MVP Scope：最初に届ける範囲と、今回やらない範囲を分ける文書。
MVP：Minimum Viable Productの略。最初に価値を確かめるための小さな完成形。
Must / Should / Could / Won’t：必須、できれば、余裕があれば、今回はやらない、に分けてMVP範囲を管理する考え方。
acceptance criteria：完了したと言える確認可能な条件。実装したではなく、どう確認できるかで書く。
First Demo Flow：最初のデモで見せる最短の操作順。価値と動作を説明できる流れにする。
vertical slice：一つのユーザー操作を、画面、APIまたは処理、データ保存、確認まで細く通す実装単位。
Delivery Plan：最初の縦切り、保存するデータ、タスク、AI委任、確認コマンド、進捗ログのルールをまとめる作業計画。
Human Checkpoints：実装前、AI出力後、共有前、レビュー依頼前に人間が確認する項目。
task：レビュー可能な小さな作業単位。完了条件と確認方法を持つ。
done when：そのtaskが終わったと言える具体的な状態。
verification log：実行したコマンド、画面操作、結果、補足を残す確認記録。
AI利用ログ：AIに何を頼み、何を採用し、何を採用せず、どう検証したかの記録。
self-review：メンターへ出す前に、価値、動作、確認、安全性、アクセシビリティ、既知の問題を自分で見る作業。
demo script：操作順だけでなく、各操作で何を示すかを残す発表用台本。
mentor review request：メンターへ見てほしい観点、起動方法、確認方法、既知の課題、質問を渡すレビュー依頼。
progress log：進捗、詰まり、判断、確認結果を継続的に残す記録。

第22章既存プロダクト改善

既存プロダクト改善：すでに動いている画面、データ、手順、利用者の期待を守りながら、小さな変更を入れる作業。
既存振る舞い：変更前に利用者が期待している画面、API、データ、操作結果。
現在の約束：README、画面動作、API response、保存済みデータ、確認手順など、利用者や開発者が頼りにしている既存の前提。
behavior inventory：変更前の主要操作、画面、API、データ、確認手順、守るべきふるまいを棚卸しする文書。
変更要求：改善として求められている内容。実装前に目的、範囲、非対象、受け入れ条件へ分解する。
影響範囲：変更が触る画面、API、DB、テスト、文書、運用手順。
change impact analysis：変更要求を、目的、範囲、受け入れ条件、影響領域、互換性リスク、不明点へ分ける文書。
status contract：statusなど新しい値の許可値、意味、表示名、default、既存データの扱い、validationをそろえる表。
validation rules：保存してよい値、拒否する値、未指定時の扱いを決めるルール。
互換性：既存の使い方、既存データ、既存API、既存手順が変更後も困らず使える性質。
回帰確認：変えていないはずの振る舞いが壊れていないかを見る確認。
regression test plan：既存動作と新しい動作を、自動テストと手動確認に分けて確認する計画。
characterization test：既存コードの現在のふるまいを記録し、変更で壊していないかを見るためのテスト。
safe change plan：テスト、リファクタリング、仕様変更、文書更新、データ変更を小さな順序に分ける変更計画。
refactoring boundary：ふるまいを変えない整理と、利用者に見える仕様変更を混ぜすぎないための境界。
互換性リスク：既存利用者、既存データ、既存手順が変更後に困る可能性。
migration：データ構造や既存データを新しい形へ移す作業。
migration note：データ変更、既存データの扱い、defaultやbackfill、確認方法、戻し方を説明する文書。
default：値が明示されていないときに使う初期値。既存データの扱いに関係する。
backfill：既存データへ新しいカラムや値をあとから埋める作業。
nullable：カラムやfieldが空の値を持てること。既存データを壊さず変更するときの選択肢になる。
read-time fallback：保存済みデータを書き換えず、読み取り時に足りない値を補って扱う方法。
revert：変更を取り消して以前の状態へ戻すこと。小さな変更ほど戻しやすい。
roll forward：前の状態へ戻すのではなく、追加修正を出して前へ進めながら直す対応。
Checks Not Run：実行していない確認、理由、リスク、フォローアップを明示する欄。
release note：利用者や運用者に、何が変わったか、既存データや互換性に何があるかを伝える短い文書。
improvement PR summary：改善PRの目的、変更内容、互換性、データ移行、確認結果、レビュー観点をまとめる文書。

第23章 Production Readiness Review

Production Readiness Review：本番または本番相当へ出す前に、出してよいか、止めるべきか、追跡課題つきで進めるかを判断する確認。
release candidate：リリース判断の対象になる、候補版の成果物。
PRR：Production Readiness Reviewの略。本番前に止める理由が残っていないか確認する作業。
release candidate summary：今回リリースする変更、含めないもの、主要ユーザーフロー、既知の問題、確認環境を固定する文書。
artifact/version：PR、commit、image tag、文書版など、どの成果物を確認したかを後から追うための情報。
evidence index：regression test、readiness確認、runbook、smoke testなど、判断に使う証拠の所在をまとめた一覧。
readiness checklist：出す前に確認すべきsecurity、accessibility、performance、observability、operations、documentationの一覧。
blocker：このまま出すと利用者、安全性、運用に大きな問題があるため、先に直すべき項目。
accepted risk：残っているが、影響と追跡方法を理解したうえで今回は受け入れるリスク。
skipped check：本来確認したいが今回は実行しなかった確認。理由、リスク、owner、期限、follow-upを明示する。
follow-up：リリース後または次の作業で追う課題。owner、期限、次の行動を持たせる。
owner / due：follow-upを誰がいつまでに追うかを示す担当と期限。
security readiness：入力検証、認可、secret、依存関係、ログ安全性など、危ない使い方を防ぐ確認。
accessibility readiness：キーボード操作、label、focus、error message、色だけに頼らない表示など、使える人を減らさない確認。
performance readiness：主要操作が現実的な速さで動き、データ量増加時の懸念を説明できるかの確認。
observability readiness：問題が起きたときに、ログ、metrics、events、deploy historyなどで追えるかの確認。
operations readiness：リリース、確認、戻し、片付けの手順が実行可能かを見る確認。
documentation readiness：README、release note、runbook、migration noteが実装と合っているかの確認。
smoke test：リリース直後に短時間で主要動線が生きているかを見る最小確認。
runbook：リリース前、リリース中、リリース後、問題時対応、rollback、cleanupをまとめた手順書。
rollback：問題発生時に、前の動作または安全な状態へ戻す対応。
cleanup：一時データ、debug log、研修用cloud resource、未整理のfollow-upを片付ける作業。
go：確認結果から、このまま進めてよいというリリース判断。
go with follow-up：出せるが、追跡すべき残課題を明示して進める判断。
no-go：blockerがあり、今は出さず先に直す判断。
decision matrix：blocker、smoke test、skipped check、accepted riskを並べ、判断への影響を見る表。
release decision：go、go with follow-up、no-goの判断と、証拠、受け入れるリスク、blocker、follow-upを残す文書。

第24章最終発表と次の学習計画

最終発表：成果物を見せるだけでなく、課題、判断、確認、学び、次の行動を証拠つきで説明する場。
evidence index：発表やレビューで使う証拠を、主要証拠と補助証拠に分けた一覧。
core evidence：発表の中心で実際に見せる根拠。企画、MVP、改善PR、PRR、release decisionなど。
supporting evidence：発表では詳しく見せないが、質問時に参照できる補助根拠。ログ、詳細メモ、テスト結果など。
missing evidence：説明したい主張に対して、まだ根拠が足りないもの。補うか、主張を弱める必要がある。
do not show：secret、実在の個人情報、本番データ、内部URLなど、発表に出してはいけないもの。
source of truth：迷ったときに正本として見る成果物や記録。発表スライドではなく、実装、README、テスト、PRR文書などが該当する。
safe to show：発表、提出物、AI入力に出してよいかを判断する観点。必要ならredactや代替証拠を使う。
presentation brief：発表の核となるメッセージ、読者、成果、判断、証拠をまとめる文書。
core message：発表全体で最も伝えたい一文。何を作り、何を確かめ、何を学んだかを短く表す。
audience：発表を聞き、評価し、フィードバックする人。メンター、講師、配属先の人など。
technical decision：なぜその設計や実装を選んだかを、理由、trade-off、証拠とともに説明する判断。
quality evidence：テスト、セキュリティ、アクセシビリティ、PRR、manual checkなど、品質を支える証拠。
PRR result：第23章のgo、go with follow-up、no-goの判断とその根拠。
demo script：操作の順番、見せる証拠、失敗時の説明をまとめる台本。
fallback evidence：デモが失敗したときに、同じ主張を支えるために見せるスクリーンショット、ログ、テスト結果、PRR文書。
learning reflection：うまくいったこと、難しかったこと、変えた判断、削った範囲、AI利用の学び、次に変える行動を証拠とともにまとめる文書。
scope cut：時間、品質、リスクを考えて今回は作らないと決めた範囲。理由と将来案を残す。
next 90 days plan：次の30日、60日、90日に伸ばす行動を決める学習計画。
focus area：次の90日で伸ばす領域。多くても三つに絞り、行動と成果物に接続する。
success signal：行動が進んだと言える小さな確認条件。成果物、説明可能性、レビュー通過などで表す。
weekly review：90日計画を週次で見直し、action、output、support neededを更新する習慣。
support needed：次の行動に必要なレビュー、相談相手、環境、資料、権限などの支援。
feedback wanted：発表で聞き手に見てほしい観点。技術判断、品質確認、AI利用、90日計画など。
feedback to incorporate：受けたフィードバックのうち、次の計画へ反映するもの。

第1章 研修の地図を持つ

第2章 価値から機能を考える

第3章 AIを使い、検証して進める

第4章 チームに情報を渡す

第5章 手元で動かす作業場

第6章 変更をレビューにつなげる

第7章 Webの通信を観察する

第8章 既存コードを小さく読む

第9章 要件からドメインを整理する

第10章 データを保存できる形にする

第11章 APIで画面と業務をつなぐ

第12章 フロントエンドとアクセシビリティ

第13章 テストとコード品質

第14章 セキュリティの基本

第15章 コンテナと実行環境

第16章 クラウドとCI/CD

第17章 オブザーバビリティとSRE

第18章 LLMと生成AIの基礎

第19章 AIコーディングの実務ワークフロー

第20章 テクニカルライティングと知識共有

第21章 個人開発プロジェクト

第22章 既存プロダクト改善

第23章 Production Readiness Review

第24章 最終発表と次の学習計画

第1章研修の地図を持つ

第2章価値から機能を考える

第4章チームに情報を渡す

第5章手元で動かす作業場

第6章変更をレビューにつなげる

第8章既存コードを小さく読む

第9章要件からドメインを整理する

第10章データを保存できる形にする

第12章フロントエンドとアクセシビリティ

第13章テストとコード品質

第14章セキュリティの基本

第15章コンテナと実行環境

第16章クラウドとCI/CD

第17章オブザーバビリティとSRE

第20章テクニカルライティングと知識共有

第21章個人開発プロジェクト

第22章既存プロダクト改善

第24章最終発表と次の学習計画