このドキュメントの使い方
各カテゴリで 既定（迷ったらこれ） を1つに絞り、代替 には「どんな条件なら乗り換えるか」を書いている。案件ごとに調べ直すのではなく、既定を採用し、条件に当てはまるときだけ代替に乗り換える運用を想定している。
バージョン番号は陳腐化が早いため記載していない。採用時は各ツールの最新安定版を使う。
選定の根拠と、よくある疑問への回答は §22 にまとめている。
選定の進め方
作るものが決まったら、次の順に見ていく（Web版では「作る」ページで1〜2をまとめて確認できる）。
- 言語を決める：§2-9（作成物ごと）と §2-10（バックエンドの負荷の性質）で決める。
- 構成を決める：§19 から近いケースを選び、構成図と表で全体像を確認する。
- 規模を確かめる：§23 の目安の数値で、想定規模に対して構成が過剰・不足でないかを確認する。
- 出口を確かめる：§24 の移行パスで、成長したときの次の一手と、今のうちにやっておく備えを確認する。
- 費用の膨らみ方を確かめる：§25 で、採用するサービスの課金の仕組みと注意点を確認する。
- 習熟度を確かめる：§27 で未経験のツールが含まれていないかを確認し、含まれていれば検証期間を見積もりに入れる。
- 作り始める：§26 のコマンドで雛形を作り、§21 のチェックリストを埋める。
選定の原則
- 1カテゴリ1ツール：同じ役割のツールを混在させない（例：ESLintとBiomeを併用しない）。
- マネージド優先：自前運用は、コスト・データ所在・オンプレ要件のいずれかで必要になったときだけ選ぶ。
- PostgreSQLを軸にする：キュー、全文検索、ベクトル検索も、まずPostgresで足りるかを検討する。
- 標準に寄せる：OpenTelemetry、OpenAPI、OCIイメージなど、ベンダーに依存しない規格を優先する。
- 根拠を説明できること：利用者が多く、ドキュメントが厚く、採用理由を第三者に説明できるツールを選ぶ（§22）。