ベストプラクティス集 ― 迷ったらこの鉄板に寄せる ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「付録」カテゴリ第2弾として、ベストプラクティス集を解説する記事です。

アンチパターン集が「踏んではいけない地雷」の逆引きだったのに対し、本記事は迷ったらまずこれの正引きカタログ。各分野で退屈だが裏切らない標準構成を1分野1枚に凝縮しています。新規プロジェクトの骨組み決定・レビュー前の最終確認・他チームへの説明資料の下敷きにご利用ください。

flowchart TB
    NEW([新規プロジェクト<br/>= 迷ったら標準に寄せる])
    A[アーキ全般<br/>YAGNI/モジュラーモノリス]
    I[インフラ<br/>マネージド/IaC/単一クラウド]
    D[データ<br/>PostgreSQL/正規化3NF]
    APP[アプリ<br/>SOLID/小さなクラス]
    F[フロント<br/>TypeScript+Next.js+Tailwind]
    S[セキュリティ<br/>IDaaS/Passkey/Secrets Manager]
    O[監視・運用<br/>SLO/Datadog/オンコール]
    P[プロセス<br/>GitHub Flow/Squash/PR小]
    AI[AI時代<br/>標準FW/型安全/学習データ豊富]
    NEW --> A
    NEW --> I
    NEW --> D
    NEW --> APP
    NEW --> F
    NEW --> S
    NEW --> O
    NEW --> P
    NEW --> AI
    classDef new fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    classDef good fill:#dcfce7,stroke:#16a34a;
    class NEW new;
    class A,I,D,APP,F,S,O,P,AI good;

このカテゴリの他の記事

アーキテクチャ全般の鉄板

個別の技術選定より前に、設計に向かう姿勢として業界で広く効く原則です。どれも地味ですが、これを守っているだけで「炎上プロジェクト」のリストからは外れます。

プラクティス	内容	根拠
YAGNI（今必要な分だけ）	使うか不明な層・抽象は作らない	未使用コードが技術的負債の主犯
Choose Boring Technology	実績2〜3年以上の選択肢を優先	情報量・採用事例がハルシネーションを抑える
ADRで判断理由を残す	なぜその選択をしたかを1ページで記録	3年後の自分と後任が最大の読者
標準ライブラリ／SaaS優先	車輪の再発明を避ける	独自実装は脆弱性とメンテコストの温床
必ず計測してから選ぶ	「速い気がする」は根拠にならない	体感と実測は3割ズレるのが普通

判断理由が文書化された技術的妥協は、無文書の技術的正解より長期運用では強い。

インフラ・デプロイの鉄板

クラウド・実行環境の定番はスタートアップも中堅もまずはこれで9割外しません。K8s やマルチクラウドへの背伸びが必要になるのは、売上やチーム規模が相当大きくなってからです。

プラクティス	内容	適用フェーズ
単一クラウドに寄せる	AWS か GCP か Azure の1択	全フェーズ（売上100億円規模まで）
ECS Fargate／Cloud Run	コンテナ運用の標準	MVP〜中規模まで K8s より先に試す
Terraform／CDKで全リソース管理	手動構築を一切禁止	開発1人目から導入
RDSはプライベートサブネット	DBを公開ネットワークに置かない	例外なし
AZ 2本・RTO 1時間／RPO 15分	可用性の最低ライン	業務システムの最低目標

段階別の実務テーブルとして、MVP は ECS Fargate 1AZ・RDS t4g.small で月数千円。成長期（DAU 10万〜）は 2AZ + Auto Scaling + CloudFront。エンタープライズ（社内業務・規制あり）は Multi-AZ + VPC エンドポイント + AWS Control Tower。

本命は単一クラウド + マネージドサービス。分散や自前は、9割のチームには早すぎます。

データの鉄板

データアーキテクチャはアプリと違って作り直せないため、最初の選択が5年後まで効きます。RDB + 厳密なスキーマ定義を中核に据えるのが現時点の業界相場で、AI 活用の前提でもここは変わりません。

プラクティス	内容	理由
PostgreSQLを第一候補	スキーマ・JSONB・pgvector・拡張性すべて備える	スキーマレスへの逃げを封じる
OLTPとOLAPを早期分離	業務DBと分析DBを混ぜない	本番DBでの分析クエリは鬼門
履歴テーブルorイベントソーシング	上書き更新せず履歴を残す	監査・AI学習・障害分析すべてで効く
dbt tests／Great Expectations	データ品質を自動検証	不整合は気づいた時には数万件
バックアップはリストア演習まで	復旧検証を四半期に1回	取れているだけでは意味なし

数値Gateの例として、テーブル1000万行以上はパーティション、10k RPS を超えたらストリーミング（Kafka／Kinesis）、DWH は Redshift／BigQuery／Snowflake から選定。

データアーキテクチャの失敗は、アプリケーションアーキテクチャの失敗より5倍重い。ここの妥協は5年先まで尾を引きます。

アプリケーションの鉄板

コード設計は「1ファイル300行・1メソッド50行・ネスト3段」の素朴な数値を守るだけで、大半の保守性問題は予防できます。DDD や Clean Architecture の派手な理論より、まず素朴な上限を決めるほうが効きます。

プラクティス	内容	閾値の目安
単一責任原則で分割	1クラス・1ファイル・1メソッドに1つの責任	1ファイル300行・1メソッド50行
ビジネスロジックはアプリ側	ストアドプロシージャに寄せない	DB移行可能性を確保
エラーは握りつぶさない	catchしたらログ + 再スロー	握りつぶしは障害発覚の致命傷
ドメイン用語で命名	data・manager・utilを避ける	コードの意図を読める命名
コンストラクタ注入	全staticを避ける	テスト可能性の土台
Optional／Result型	nullの代わりに型で表現	nullチェック漏れの撲滅

素朴な数値上限を守る地味なチームは、複雑な設計論を振りかざすチームより5年後の生産性が高いです。

フロントエンドの鉄板

フロントはメタフレームワーク + ユーティリティCSS + マネージド認証の3点セットが現時点の業界標準です。自作認証・独自 CSS 設計・生の React ルーティングは、工数に見合うリターンが出にくい選択です。

プラクティス	内容	代表例
メタフレームワーク採用	ルーティング・SSR・ビルドを自作しない	Next.js／Astro／Remix
JWTはHttpOnly Cookie + BFF	localStorage 保存は禁止	BFF 経由でトークンを隠す
認証はSaaSに委譲	Clerk／Auth.js／Auth0／Cognito	自前実装は脆弱性の温床
Tailwind + shadcn/ui	独自CSS設計システムを作らない	人材確保・学習コスト最適
画像はCDN変換 + WebP／AVIF	LCP 2.5秒以下を目標	Core Web Vitals対策
JSバンドルは170KB（gzip後）	コード分割で段階配信	3G端末でも初期描画3秒

SEO 重視なら SSG／ISR、ダッシュボード系なら CSR + API、コンテンツ + 対話なら SSR + RSC（React Server Components＝サーバー側で描画してクライアントに HTML と最小の JS を送る仕組み）で使い分けるのが現在の相場です。

「素のReactで自前ルーティング」は、現在の業界で筋が悪い選択。メタフレームワークに乗るのが鉄板です。

セキュリティの鉄板

セキュリティは最初に標準装備するのが最もコストが低く、後から足すと100倍高くつきます。自前実装を徹底的に避け、委譲・多層防御・最小権限で組むのが業界の定石です。

プラクティス	内容	必達レベル
認証はIDaaSに委譲	Auth0／Cognito／Clerk／Okta	新規サービスの初日から
MFA全ユーザー必須化	SMSより TOTP／Passkey	管理者は例外なし
Passkey対応を標準化	FIDO2 ベースのパスワードレス	現在、新規サービスでは標準
TLS 1.3必須・1.2最低	1.0／1.1を廃止	全通信で強制
秘密情報はVault／Secret Manager	Git への混入を pre-commit hook で検知	開発初日から
ゼロトラスト前提	VPN内を信頼しない	全リクエストで認証
ログのPIIマスキング	個人情報を生ログに出さない	個人情報保護法対応

自作するな、委譲しろがセキュリティの鉄則。独自実装が正当化される組織は国内に数社しかありません。

監視・運用の鉄板

「動いている」と「監視できている」は別物です。可視化の仕組みを最初から組み込み、人間の勘ではなく数値で運用を回すのが SRE 的な標準構成です。

プラクティス	内容	目標値
構造化ログ（JSON）標準化	検索・集計を前提にした形式	1日から導入
SLO／SLI／エラーバジェット	可用性を数値で議論	99.9%（月43分ダウンまで）
3本柱を揃える	メトリクス・ログ・トレースの統合	Datadog／New Relic／Grafana Stack
オンコール + PagerDuty	アラートを確実に人に届ける	夜間対応は必ず当番制
ランブック整備	主要障害の対応手順を文書化	新人が夜間対応できる粒度
ポストモーテム必須	障害後に原因と対策を記録	責任追及ではなく再発防止
CI/CD経由のみで本番変更	本番SSHを禁止	再現性・監査可能性の担保

可視化されていないものは存在しないのと同じ、が運用業界の共通認識です。

プロセス・組織の鉄板

技術選定が正しくても、プロセスで失敗するプロジェクトが実は最も多い領域です。意思決定の記録・段階移行・発注側の理解の3つが長期運用の成否を決めます。

プラクティス	内容	効果
ADRで決定記録を残す	「なぜ」を1ページで文書化	3年後に誰も答えられない問題を予防
Strangler Figで段階移行	ビッグバン刷新を避ける	数年・数億の炎上を回避
PoC → 本実装の順序	不確実性が高い技術は必ず先に検証	見積もり精度が2倍以上変わる
アーキテクトと実装者を混ぜる	孤立した理想論を避ける	現場と整合する設計を担保
Conway’s Lawを逆利用	組織構造からシステム境界を逆算	チーム境界とAPI境界を揃える
発注側もアーキテクチャを理解	ベンダー丸投げを避ける	運用引き継ぎを可能にする

「動かしている技術の中身を発注側が理解していない」状態は、いずれ必ず爆発します。これは業界の共通認識です。

AI時代の鉄板

AI 駆動開発が前提になると、AIが流暢に書けるか・読めるかが選定軸の中心に入ります。主流フレームワーク・型安全・宣言的・CLI操作の4つが AI との相性を決めます。

プラクティス	内容	AI時代の効き
主流フレームワークに寄せる	Next.js／Django／Rails／FastAPI	学習データ量が生産性を決める
型とスキーマを明示	TypeScript／Pydantic／dbtモデル	AIのハルシネーションを抑制
CLI／API／IaCで操作可能なツール	GUI専用ツールを避ける	AI に操作を任せられる
データカタログとメタデータ整備	説明文・タグ・関係性を記載	RAG・AIエージェントの精度が跳ねる
AI生成コードも通常レビュー	検査なしデプロイを禁止	脆弱性の本番流入を防ぐ
pgvector／Pinecone前提の設計	ベクトル検索を後付けしない	RAG機能の追加コストを下げる

現在の設計原則はAIが流暢に書ける・読めるという軸が中心。この軸で選ぶと、結果的に人間にも優しい設計になります。

「退屈な技術」で勝つ組み合わせ

Stack Overflowが .NET + SQL Server + Redis の保守的スタックで月間1億アクセスを9台のサーバーで捌いた話は、「退屈な技術」を選んだ勝者の典型として業界で語り継がれています。逆に Uber が2,200以上のマイクロサービスに分割した後、開発体験の悪化で DOMA（Domain-Oriented Microservice Architecture）への再統合を進めた事例は、「できる分割の最大値をやった結果の反省」として頻繁に引き合いに出されます。

現時点の外さない鉄板組み合わせは以下です。新規プロジェクトで迷ったら、まずこの構成から引いて、外す必要がある要素だけ差し替えるのが現実解です。

層	鉄板
クラウド	AWS（東京リージョン）
実行環境	ECS Fargate
DB	PostgreSQL + pgvector
バックエンド	Python（FastAPI／Django）or Go
フロントエンド	Next.js + Tailwind + shadcn/ui
認証	Clerk or Auth.js
監視	Datadog or Grafana Cloud
IaC	Terraform
CI/CD	GitHub Actions

退屈な構成を5年間まっすぐ動かせるチームが、結局のところ一番強いチームです。

筆者メモ — 「鉄板」を選ぶのは気恥ずかしさとの戦い

アーキテクトの仕事で意外と難しいのは、「最新」「かっこいい」「勉強になる」という3つの誘惑を振り切ることだと業界で繰り返し語られています。カンファレンスで紹介される最先端事例は、ほぼ例外なく「相当な規模・相当なチーム・相当な予算」が前提になっており、それを10人のチームが真似ると、本命の機能開発に手が回らなくなるケースが多いと示唆されています。

Shopify が Ruby on Rails をモノリスのまま巨大スケールまで運用し続けている話、Basecamp が HEY というメールサービスを意図的に「退屈な技術」で構築した話、Amazon ですら S3 の裏側で20年以上 C++ と内製 RPC を使い続けている話は、全て退屈さを受け入れる勇気が勝者の共通項だと示唆する典型例です。

気恥ずかしさを受け入れて標準に寄せたチームが、5年後に淡々と動かし続けている事例が多数報告されています。アーキテクトが誇れるべきは「使っている技術の新しさ」ではなく、「プロダクトが5年間止まらずに動いていること」──これを忘れないのが、長く現場を回せる人の共通項です。

自己診断チェックリスト

鉄板を押さえられているかを確認できます。3つ以上該当しないならレッドゾーンで、該当する分野を見直す価値があります。

• 本番環境はADRで意思決定記録を残している
• Terraform／CDKで全リソースを管理している（手動構築なし）
• RDS／DBは必ずプライベートサブネットに配置している
• 認証はIDaaS（Auth0／Cognito／Clerk等）に委譲している
• MFAを全ユーザー必須化している
• 構造化ログ（JSON）で出力している
• SLOを明示的に数値で定義している（99.9%など）
• 本番への変更は必ずCI/CD経由で行っている
• 主要障害のランブックが文書化されている
• バックアップからのリストア演習を定期的に行っている

最終的な判断の仕方

ベストプラクティスの本質は業界で最も多くの現場が生き残った組み合わせを初手で採用することです。個別に優れた選択肢は他にもありますが、情報量・人材・運用実績の3つが揃う選択は、特定時点では必ず1つか2つに絞られます。

AI 時代はこの傾向がさらに強まります。AI が流暢に書けるフレームワークは生産性を数倍押し上げ、ニッチな選択肢との差が広がります。地味だが定番を選ぶことは、人間にも AI にも優しい設計に直結します。

選定の優先順位

1. 標準・多数派 — 情報量と人材確保のしやすさが長期で効く
2. マネージド／SaaS — 自前実装より脆弱性・運用コストで圧勝
3. 型安全・宣言的 — AI時代の精度と保守性を底上げ
4. 段階移行可能 — ビッグバン刷新を避け、差し替え余地を残す

「鉄板を選べば、3年後に誰も責められない」奇を衒った選定は、成功しても属人化し、失敗すれば孤立します。

まとめ

本記事はベストプラクティス集について、全分野鉄板・退屈な技術・AI時代の標準構成・5年後も淡々と動かす設計姿勢まで含めて解説しました。如何だったでしょうか。

標準に寄せ、マネージドに委譲し、型で締め、段階で移す。これが2026年のベストプラクティスの現実解です。

次回は「重大インシデント事例集」について解説します。Knight Capital・Equifax・SolarWinds・CrowdStrike など、業界が払った数百億円規模の代償から学ぶ実践リファレンスを掘り下げる予定です。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。