システムアーキテクチャ
システムアーキテクチャとは、ソフトウェアやハードウェア要素をどのように分割し、どのような責務と関係性で結合させるかを定義する設計上の骨格である。要素間のインターフェース、データの流れ、配備形態、非機能要求（性能・可用性・保守性・セキュリティなど）を総合的に扱い、変更容易性と運用性を両立させるための指針となる。適切なアーキテクチャは機能拡張のコストを抑え、障害時の影響を局所化し、継続的な改善を支える基盤となる。
基本概念
アーキテクチャは「構成要素（コンポーネント）」「接続（インターフェース）」「制約（技術・組織・法規）」「ビュー（論理・開発・運用・配備）」で捉えると理解しやすい。機能分割はドメインの境界に沿って行い、依存関係は一方向に揃える。同期/非同期、状態の所在、データ一貫性の扱いを早期に決めることが、将来の保守性と拡張性を左右する。
レイヤードアーキテクチャ
典型的には表示層・アプリケーション層・ドメイン層・インフラ層に分ける。層間依存を上から下へ単純化することで見通しを確保できる一方、跨層機能が増えると冗長化しやすい。ドメイン規模が中小で、変更が比較的予測可能な場合に適する。
- 利点：関心分離、テスト容易、教育コスト低
- 欠点：跨層変更時の重複、層越え依存の誘惑、性能劣化の懸念
クライアント/サーバと三層
2層（クライアント/DB直結）は実装が簡易であるがスケールに限界がある。3層（Web/アプリ/DB）は横方向のスケールアウトに向く。クライアントは可能な限りステートレスに保ち、セッションはサーバ側の分散ストアやトークンで扱うと拡張しやすい。
マイクロサービス
システムアーキテクチャが大規模化し変更頻度が高い場合、機能を小さな独立サービスに分割するマイクロサービスが有効である。各サービスは独自のデータを持ち、APIを介して疎結合に連携する。サービスディスカバリ、観測性（ログ・メトリクス・トレース）、CI/CD、自動復旧の整備が前提となる。
データ一貫性と取引設計
分散下ではACIDの厳密さを緩め、最終的整合性を許容する選択肢が増える。Sagaパターンやアウトボックス、冪等性キーにより、失敗時の巻き戻しや再実行を安全にする。強整合が不可欠な箇所は境界を狭く定義し、他は非同期で連携する。
イベント駆動アーキテクチャ
発生事象をイベントとして発行し、購読側が処理する非同期モデルである。疎結合・拡張容易・リアルタイム性に強い一方、因果関係の追跡やデバッグが難しくなる。少なくとも「少なくとも1回」配信を前提に、冪等処理と重複排除を徹底する。
ストリーム処理
ログ構造のストリーム（例：イベントブローカー）上でウィンドウ集計やパターン検知を行う。遅延・順序・再送が常態であるため、タイムスタンプの扱い、バックプレッシャー制御、オフセット管理を設計段階で確立する。
アーキテクチャ選定の判断軸
- ドメインの複雑性と変更頻度（DDDの適用度合い）
- チーム構造とコミュニケーション（Conwayの法則）
- 非機能目標：SLA/SLO、レイテンシ、スループット
- 法規・監査・データ所在要件（個人情報・業法）
- 運用成熟度：自動化・監視・Incident対応力
非機能要求と品質特性
性能・可用性・信頼性・保守性・セキュリティは相互にトレードオフとなる。CAP定理が示すように、分散環境では一部の特性を優先せざるを得ない。またACIDとBASEの選択は機能境界ごとに最適化する。キャッシュ、レプリケーション、シャーディング等を組み合わせて目標を満たす。
スケーリング戦略
垂直スケールは即効性があるが限界がある。水平スケールはステートレス化、セッション外だし、アイドル分離、バックエンドの読み取り分散（リードレプリカ）などの設計支援が必要になる。スロットリングやキューで負荷平準化を行い、優先度制御で全体の健全性を守る。
設計手法と表記
説明可能性のためにUMLではなくC4モデルのような抽象度の異なる図を用い、関心層ごとに示すと伝わりやすい。重要な意思決定はADRで記録し、背景・選択肢・根拠・採否を残す。図と文章は常に同期させ、レビューで逸脱を検知する。
クラウドとインフラ
IaaS/PaaS/Serverlessの選択は開発速度と運用責務の配分を左右する。コンテナとオーケストレーション（例：Kubernetes）で実行環境を標準化し、IaCで再現性を担保する。ゼロトラストの考え方でネットワーク境界に頼らず、ID・デバイス・コンテキストに基づく認可を行う。コストはFinOpsで継続的に最適化する。
可観測性と回復性
ログ・メトリクス・トレースを統合し、SLIを定義してSLOを監視する。カナリアリリースやサーキットブレーカー、レートリミット、ヘルスチェック、自動フェイルオーバーを組み合わせ、部分的な故障を全体障害に拡大させない。
移行とモダナイゼーション
既存システムの置換は段階的に行う。Strangler Figパターンで新旧機能を並行稼働させ、トラフィックを段階移行する。データ移行は二重書き込みやイベント再生で整合性を確保し、カットオーバーを最小リスクにする。運用面では観測とロールバック戦略を予め準備する。
実務での勘所
システムアーキテクチャは唯一解ではなく、制約の中での最適化問題である。要件は変化する前提で、疎結合・自動化・観測性・冪等性といった普遍原則を優先し、複雑さは必要最小限に留める。アーキテクトは図を描くだけでなく、計測による事実と検証に基づき、実行可能な設計に落とし込むことが重要である。