## このドキュメントの使い方

各カテゴリで **既定（迷ったらこれ）** を1つに絞り、**代替** には「どんな条件なら乗り換えるか」を書いている。案件ごとに調べ直すのではなく、既定を採用し、条件に当てはまるときだけ代替に乗り換える運用を想定している。

バージョン番号は陳腐化が早いため記載していない。採用時は各ツールの最新安定版を使う。

選定の根拠と、よくある疑問への回答は §22 にまとめている。

### 選定の進め方

作るものが決まったら、次の順に見ていく（Web版では「作る」ページで1〜2をまとめて確認できる）。

1. **言語を決める**：§2-9（作成物ごと）と §2-10（バックエンドの負荷の性質）で決める。
2. **構成を決める**：§19 から近いケースを選び、構成図と表で全体像を確認する。
3. **規模を確かめる**：§23 の目安の数値で、想定規模に対して構成が過剰・不足でないかを確認する。
4. **出口を確かめる**：§24 の移行パスで、成長したときの次の一手と、今のうちにやっておく備えを確認する。
5. **費用の膨らみ方を確かめる**：§25 で、採用するサービスの課金の仕組みと注意点を確認する。
6. **習熟度を確かめる**：§27 で未経験のツールが含まれていないかを確認し、含まれていれば検証期間を見積もりに入れる。
7. **作り始める**：§26 のコマンドで雛形を作り、§21 のチェックリストを埋める。

### 選定の原則

1. **1カテゴリ1ツール**：同じ役割のツールを混在させない（例：ESLintとBiomeを併用しない）。
2. **マネージド優先**：自前運用は、コスト・データ所在・オンプレ要件のいずれかで必要になったときだけ選ぶ。
3. **PostgreSQLを軸にする**：キュー、全文検索、ベクトル検索も、まずPostgresで足りるかを検討する。
4. **標準に寄せる**：OpenTelemetry、OpenAPI、OCIイメージなど、ベンダーに依存しない規格を優先する。
5. **根拠を説明できること**：利用者が多く、ドキュメントが厚く、採用理由を第三者に説明できるツールを選ぶ（§22）。