本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリの入口として、ハードウェア・ソフトウェア・ネットワークを包括した骨組み全体を俯瞰する記事です。この領域で何を決めるのか、なぜ最初に決める必要があるのか、AI駆動開発前提の選定軸まで整理します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』・『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
この記事の結論
- システムアーキテクチャは最も後戻りできない領域。プロジェクト1週目に骨子を決める
- アプリ形態→デプロイ→ベンダー→実行環境と、上流から順に決める
- 個人〜中規模SaaSは単一クラウド+マネージド+IaCが鉄板
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもシステムアーキテクチャとは何か
家の基礎工事を想像してください。基礎を打ち終えてから「やっぱり地下室がほしい」と言っても、基礎をやり直すコストは家を建て直すのとほぼ同じです。間取りや壁紙は後から変えられますが、基礎と構造材は最初に正しく決めるしかありません。
システムアーキテクチャは、ハードウェア・ソフトウェア・ネットワークを包括したシステム全体の骨組みを決める領域です。クラウドか自社DC（データセンター）か、OS・DB・コンテナ基盤・ネットワーク設計をここで決めます。現場では「インフラアーキテクチャ」とほぼ同じ意味で使われることも多く、呼び方はどうであれ「骨組みをまとめて扱う層」と押さえておけば十分です。他のアーキテクチャ層（ソフトウェア・データ・セキュリティ等）は、この骨組みの上に建てる内装にあたり、骨組みの制約を全面的に受けます。
なぜ最初に決めるのか
この領域は One-way Door（Amazonのベゾス流に言う「後戻り困難な決定」）の集合地帯だからです。クラウドベンダーを途中で変えるのは実質「作り直し」、オンプレとクラウドの切り替えも大工事、OS・DB製品の変更は広範囲に波及します。
そして「MVPだから適当でいい」という姿勢は、あとで最もコストの高い選択になります。コードと運用が骨組みに癒着してから剥がす作業になるため、先送りは小規模プロジェクトほど致命傷です。骨子はプロジェクト1週目に決めます。
何を決めるのか ― 3つのグループ
この領域で決める項目は3グループに分かれ、上流のグループの決定が下流の選択肢を制約します。
グループ1（基盤の選定）は、アプリ形態 → デプロイモデル → クラウドベンダー → 実行環境 → OS → データ永続化の順に決めます。上流で決めた内容が下流の選択肢を絞るため、この順序を逆にすると必ず手戻りが発生します。たとえばDBを先に決めてからクラウドベンダーを選ぶと、選定の幅が不自然に狭まります。配下の記事01〜06で順に扱います。
グループ2（ネットワーク・セキュリティ・監視）は、基盤の上でデータをどこに置き、どう繋げ、どう守り、どう見張るかを設計します。この3つは後付けが極めて困難な領域なので、基盤選定と同時期に着手するのが鉄則です。配下の記事07〜09で扱います。
グループ3（BCP・コスト・自動化）は、構成が固まった後に「壊れたらどう復旧するか」「費用をどう管理するか」を設計します。BCP計画書を作っただけで訓練しないのは典型的な失敗パターンです。配下の記事10〜11で扱います。なおCI/CD・IaC・構成管理などの開発プロセス系は、別カテゴリ「開発・運用アーキテクチャ」に集約しています。
規模・フェーズ別のシステム構成
システムアーキテクチャは組織規模で最適解が変わります。先に結論だけ言うと、個人〜中規模SaaSまでは単一クラウド＋マネージド＋IaCが鉄板で、ハイブリッドやマルチクラウドは大企業以上に限定するのが2026年時点の健全解です。
| フェーズ | 推奨構成 | 専任インフラ人員 |
|---|---|---|
| MVP・個人 | 単一クラウド・1リージョン・マネージド | 0人 |
| 初期スタートアップ | 単一クラウド・マルチAZ・IaC必須 | 0.5人 |
| 中規模SaaS | 単一クラウド+DR用2リージョン | 1〜3人 |
| 大企業 | ハイブリッド+専用線+Organizations | 5人〜 |
| 金融・医療・公共 | プライベートクラウド・コンプライアンス認定 | 10人〜 |
マルチクラウド・ハイブリッドの実質下限は専任インフラ人員3人以上です。これ未満で選ぶと運用だけで現場が溶けます。スタートアップが大企業の構成を真似るのはよく見る失敗パターンで、数カ月で疲弊して縮退移行に追い込まれます。規模に見合わない構成は負債にしかなりません。
AI判断軸 ― コードで表現できるか
規模に加えて、AI駆動開発前提の時代には「コードで表現できるか」という判断軸が全ての選定に重なります。
IaC化されたインフラはAIにとって「読めるコード」になる
TerraformやCDKで定義されたインフラは、AIにとって通常のソースコードと同じ扱いになります。VPCの構成・セキュリティグループのルール・IAMポリシーがすべてテキストファイルとして存在するため、AIが構成を理解し、変更提案をPRとして出せます。一方、マネジメントコンソールのGUI操作で構築されたインフラはAIから一切見えません。構成情報がAPI経由でしか取れず、変更履歴も追えないため、AIによるレビューや自動修正の対象外になります。
単一クラウドがAI活用で有利な構造的背景
AWSの情報量はAzure・GCPの数倍あり、AIの学習データもそれに比例します。AWSのIAMポリシーやCloudFormationの書き方は膨大な公開サンプルが存在するため、AIは正確なコードを生成できます。マルチクラウド構成にすると、各ベンダーのIaC・IAM・ネットワーク設計をすべて二重管理する必要があり、AIのコンテキスト負荷も倍増します。マルチクラウドが正当化されるのは、法規制・M&A・特定サービスの独占的優位性（BigQuery等）がある場合に限られます。
ベンダーロックインの論点も変わりました。単なる移行コストではなく、「AIがそのベンダーを詳しく知っているか」が新しいロックインリスクです。標準プロトコル（OIDC・OpenTelemetry等）への準拠も、同じ理由でAI時代の必須条件になっています。
やってはいけないこと
各論記事で詳しく触れる禁じ手の中から、全体設計レベルで押さえるべき核心を6つに絞ります。
| 禁じ手 | なぜダメか |
|---|---|
| 下流から決めて上流に逆算 | アプリ形態→クラウド→実行環境の順序を崩すと必ず手戻りが出る |
| マルチクラウドを人員不足で採用 | IAM・監視・IaCの二重化で運用コストが倍増する |
| IaCなし・GUI手動構築 | 環境差分が生まれ再現不能になり、AI時代に負債化する |
| セキュリティ・監視を後から追加 | 認証・暗号化・監査ログは設計時の組み込みが前提。後付けは大事故のもと |
| BCP計画書を作って訓練なし | 2017年のGitLab事件のように、いざという時バックアップが機能しない |
| 大手の構成をそのまま真似る | 規模の前提が違い、オーバーエンジニアリングで保守不能になる |
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰しました。如何だったでしょうか。
システムアーキテクチャは最も戻せない領域です。規模・上流順・IaC化・セキュリティ標準装備の4点を最初に決めることが、その後の数年〜10年の運用コストとAI時代対応力を決定づけます。
次回からはこの領域の各論に入り、まずアプリケーション形態（Native / Web / Hybrid）の選び方から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS Well-Architected フレームワーク も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（11/95）