## 22. 採用の根拠

確認：2026年9月

### 22-1. 全体方針の根拠

| 方針 | 根拠 |
|---|---|
| 既定の言語は少数（TypeScript・Go・Ruby）に絞り、それ以外（Rust、Kotlin、Elixir、C#、Python）は条件を満たしたときだけ使う（§2-9、§2-10） | 知識とコード資産を案件間で再利用でき、レビューの質も上がる。一方で、既定で無理をせず、負荷や制約に合った言語を明文化した条件で選べる |
| 標準規格を優先する（SQL／PostgreSQL、OpenAPI、OpenTelemetry、OCIコンテナ） | 特定ベンダーに閉じ込められない。クラウドや監視サービスを後から乗り換えられる |
| マネージドサービスを優先する | OSやミドルウェアのパッチ適用、冗長化、バックアップを提供者に任せられる。運用の人件費と事故リスクを下げられる |
| インフラをコード化し、CIで検査する | 環境をいつでも再現でき、変更履歴がレビューを経て残る。属人化しない |
| 設計判断をADRで記録する | 「なぜこうなっているか」が後から追える。引き継ぎ資料を別途作る必要がない |

### 22-2. 主要技術ごとの根拠

| 技術 | 採用の根拠 | よくある懸念と回答 |
|---|---|---|
| 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にしておけば、監視サービスを後から変更できる | 「費用がかかる」→ 無料枠・サンプリングで調整できる。障害の長期化による損失の方が大きい |

### 22-3. PHPを採用しない理由

- **品質に責任を持てる範囲に集中するため**：深い知見があり、品質を保証できる言語に絞っている。これが最大の理由であり、PHPという言語の優劣の問題ではない。
- **言語を統一できない**：フロントエンドは必ずTypeScriptになるため、バックエンドにPHPを入れると2言語の保守が必要になる。
- **エコシステムのばらつき**：近年のPHPは型や性能が大きく改善したが、周辺ライブラリやプラグインでは型の整備が不均一な資産がまだ多い。
- **セキュリティ運用の負担**：WordPressなどのCMSでは、脆弱性の多くがサードパーティのプラグインに起因しており、継続的な更新と監視が欠かせない。ヘッドレスCMS＋静的配信ならこの負担をほぼなくせる。

公平のため付記すると、PHPは人材の母数と安価なホスティングという点では依然として強い。その利点を捨ててでも、上記の理由で集中を選ぶという判断である。

### 22-4. よくある疑問と回答

| 質問 | 回答 |
|---|---|
| 将来、保守を他の人に引き継げなくなるのでは？ | TypeScriptとGoは利用者が多く、担い手は増え続けている。README、ADR、IaC、CIを整備しているため、第三者でも環境を再現して引き継げる。独自技術は使っていない |
| 月額費用が高くならないか？ | マネージドサービスは月額が見える一方、サーバー保守・パッチ適用・障害対応の人件費が減る。総額で比較する。コンテンツ中心のサイトは静的配信にすることで、むしろ安くなることが多い。PaaSには支出上限を設定する |
| WordPressなら非エンジニアでも更新できるのに？ | ヘッドレスCMS（microCMSなど）で同等以上の更新体験を用意できる。プラグインの更新作業や改ざん対応が不要になる |
| 実績のある技術なのか？ | RailsはGitHubやShopify、GoはDockerやKubernetesなど、大規模な利用実績がある。PostgreSQLは主要クラウドすべてが公式に提供している |
| クラウドやSaaSの障害時はどうなるのか？ | 冗長構成、外形監視、障害対応手順（ランブック）を用意する。1つのサービスが止まっても全体が止まらないよう、依存先は §20 と §22 の基準で選んでいる |
| 使っている技術が数年後に廃れないか？ | 利用者の多さと標準規格への準拠を選定基準にしている。本ガイドは定期的に見直し、廃れた技術は §20「採用しないもの」に移して置き換える |