採用の根拠

既定の言語は少数（TypeScript・Go・Ruby）に絞り、それ以外（Rust、Kotlin、Elixir、C#、Python）は条件を満たしたときだけ使う（§2-9、§2-10）

根拠知識とコード資産を案件間で再利用でき、レビューの質も上がる。一方で、既定で無理をせず、負荷や制約に合った言語を明文化した条件で選べる

標準規格を優先する（SQL／PostgreSQL、OpenAPI、OpenTelemetry、OCIコンテナ）

根拠特定ベンダーに閉じ込められない。クラウドや監視サービスを後から乗り換えられる

マネージドサービスを優先する

根拠OSやミドルウェアのパッチ適用、冗長化、バックアップを提供者に任せられる。運用の人件費と事故リスクを下げられる

インフラをコード化し、CIで検査する

根拠環境をいつでも再現でき、変更履歴がレビューを経て残る。属人化しない

設計判断をADRで記録する

根拠「なぜこうなっているか」が後から追える。引き継ぎ資料を別途作る必要がない

TypeScript

採用の根拠GitHubのOctoverse 2025（https://octoverse.github.com/）で、2025年8月に月間コントリビューター数でPythonとJavaScriptを抜き最も使われる言語になった。Next.jsやAstroなど主要フレームワークが既定でTypeScriptのプロジェクトを生成する。型によって多くの不具合をリリース前に検出でき、AIによるコード生成の誤りも型チェックで拾いやすい。フロントとバックエンドを1言語で書ける

よくある懸念と回答「JavaScriptより難しいのでは」→ 型は段階的に導入でき、エディタ補完が効くぶん学習もしやすい

Go

採用の根拠単一バイナリで配布でき、実行時の依存がない。メモリ使用量が小さく、同時接続に強い。Go 1互換性の約束により、長期間コードが壊れにくい。Docker、Kubernetes、TerraformなどインフラOSSの多くがGoで書かれている

よくある懸念と回答「人材が少ないのでは」→ 言語仕様が小さく、他言語経験者なら短期間で読み書きできる

Rails

採用の根拠CRUD中心のアプリで開発速度が非常に高い。近年のRailsはSolid Queue／Solid Cache／Solid Cableでジョブ・キャッシュ・WebSocketをDBだけで動かせるため、Redisなどの追加ミドルウェアが不要。GitHubやShopifyが大規模に運用している実績がある。Kamalで特定のPaaSに依存せずデプロイできる

よくある懸念と回答「Rubyは下火では」→ 採用企業は安定して存在し、フレームワークは毎年活発に更新されている

PostgreSQL

採用の根拠OSSでライセンス費用がかからない。AWS、GCP、Azureを含む主要クラウドがすべてマネージド版を提供している。拡張機能（pgvector、pg_bigm）でベクトル検索や日本語全文検索までこなせるため、専用DBを増やさずに済む

よくある懸念と回答「MySQLの方が一般的では」→ 機能・標準SQLへの準拠・拡張性で優位。移行ツールも揃っている

Rust

採用の根拠GCがなく、C/C++並みの性能とメモリ効率を出しながら、メモリ安全性をコンパイル時に保証できる。WebAssemblyやネイティブ拡張として他の環境に組み込みやすい。近年の高速な開発ツール（Biome、Ruff、uvなど）の多くがRust製で、実用性が証明されている

よくある懸念と回答「開発が遅くなるのでは」→ 性能・安全性が効く箇所に限定して使い、その他はGo・TypeScriptで書く（§2-10）

Kotlin

採用の根拠JVMの成熟したトランザクション・バッチ・ストリーム処理の基盤をそのまま使え、Javaより簡潔で安全に書ける。既存のJava資産と直接連携できる

よくある懸念と回答「重いのでは」→ 起動時間が問題になる用途（サーバーレス）以外では、常駐サーバーとして十分な性能が出る

Elixir

採用の根拠軽量プロセスと監督ツリーにより、大量の常時接続と障害時の自動復旧を少ないコードで実現できる。Discordなどが大規模なリアルタイム基盤で採用している

よくある懸念と回答「人材が少ない」→ 採用は常時接続が中核のサービスに限る。書ける人材の確保を採用の前提条件にする

C#

採用の根拠Unityとサーバーでコードを共有でき、ASP.NET Coreは性能も高い。Microsoft環境との親和性が高い

よくある懸念と回答「Windows専用では」→ .NETはLinux・コンテナで普通に動く

Python（AI・データ処理用途のみ）

採用の根拠機械学習・LLM関連のライブラリがPythonに集中しており、代替が事実上ない

よくある懸念と回答「なぜ全部Pythonにしないのか」→ Webアプリ本体はTypeScript・Go・Railsの方が型安全性や開発効率で有利

コンテナ＋Terraform

採用の根拠開発・検証・本番で同じイメージを使えるため、環境差による不具合が起きにくい。クラウド移行時もコードから再構築できる

よくある懸念と回答「学習コストが高い」→ テンプレート化しており、案件ごとの差分は小さい

Cloudflare

採用の根拠DNS、CDN、WAF、DDoS対策、アクセス集中時の入場制御（Waiting Room）を1か所で管理できる

よくある懸念と回答「障害時に全部止まるのでは」→ オリジンへの直接経路と切り戻し手順をランブックに用意する

Stripe／KOMOJU

採用の根拠カード情報を自社システムで扱わずに済み、PCI DSSの対応範囲を最小にできる。国内の決済手段（コンビニ払い等）はKOMOJUで補える

よくある懸念と回答「手数料が高い」→ 自前でカード情報を扱う場合のセキュリティ対策・監査コストと比べて判断する

マネージド認証（Clerk、Cognito等）

採用の根拠認証はセキュリティ事故の影響が最も大きい領域。パスキーや多要素認証を自前実装せずに済む

よくある懸念と回答「ロックインでは」→ 標準のOIDCで連携するため、IdPの差し替えは可能

Sentry＋OpenTelemetry

採用の根拠障害の検知と原因特定の時間を短縮できる。計装をOpenTelemetryにしておけば、監視サービスを後から変更できる

よくある懸念と回答「費用がかかる」→ 無料枠・サンプリングで調整できる。障害の長期化による損失の方が大きい

将来、保守を他の人に引き継げなくなるのでは？

回答TypeScriptとGoは利用者が多く、担い手は増え続けている。README、ADR、IaC、CIを整備しているため、第三者でも環境を再現して引き継げる。独自技術は使っていない

月額費用が高くならないか？

回答マネージドサービスは月額が見える一方、サーバー保守・パッチ適用・障害対応の人件費が減る。総額で比較する。コンテンツ中心のサイトは静的配信にすることで、むしろ安くなることが多い。PaaSには支出上限を設定する

WordPressなら非エンジニアでも更新できるのに？

回答ヘッドレスCMS（microCMSなど）で同等以上の更新体験を用意できる。プラグインの更新作業や改ざん対応が不要になる

実績のある技術なのか？

回答RailsはGitHubやShopify、GoはDockerやKubernetesなど、大規模な利用実績がある。PostgreSQLは主要クラウドすべてが公式に提供している

クラウドやSaaSの障害時はどうなるのか？

回答冗長構成、外形監視、障害対応手順（ランブック）を用意する。1つのサービスが止まっても全体が止まらないよう、依存先は §20 と §22 の基準で選んでいる

使っている技術が数年後に廃れないか？

回答利用者の多さと標準規格への準拠を選定基準にしている。本ガイドは定期的に見直し、廃れた技術は §20「採用しないもの」に移して置き換える