本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリの入口として、ハードウェア・ソフトウェア・ネットワークを包括した骨組み全体を俯瞰する記事です。建物でいえば基礎工事と構造材にあたり、全アーキテクチャ層で最もやり直しが効かない領域です。
本記事ではこの領域で何を決めるのか、なぜ最初に決める必要があるのか、AI駆動開発前提の選定軸まで俯瞰します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』・『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
そもそもシステムアーキテクチャとは何か
家の基礎工事を想像してください。基礎を打ち終えてから「やっぱり地下室がほしい」と言っても、基礎をやり直すコストは家を建て直すのとほぼ同じです。間取りや壁紙は後から変えられますが、基礎と構造材は最初に正しく決めるしかありません。
システムアーキテクチャは、ハードウェア・ソフトウェア・ネットワークを包括したシステム全体の骨組みを決める領域です。クラウドか自社DC（データセンター）か、OS・DB・コンテナ基盤・ネットワーク設計──全アーキテクチャ層の中で最もやり直しが効きません。
もしシステムアーキテクチャを軽視すると、クラウドベンダーを途中で変える＝実質「作り直し」のような事態が起き、他の全ての設計判断が無に帰します。
最初にして、最も戻しにくい決定
システムアーキテクチャは、ハードウェア・ソフトウェア・ネットワークを含む全体の骨組みを決める層です。建物で言えば基礎工事と構造材にあたります。ここを後から変えようとすると、家を建て直すのとほぼ同じだけのコストがかかる。ここが他の領域との決定的な違いです。
「インフラアーキテクチャ」とほぼ同じ意味で使う現場が多く、両者を区別しない派閥もあります。呼び方はどうでもよくて、「骨組みをまとめて扱う層」と押さえておけば十分です。
他のアーキテクチャ層（ソフトウェア・データ・セキュリティ等）は、この層で決まった骨組みの上に建てる内装にあたり、骨組みの制約を全面的に受けます。各アーキテクチャの中で難易度が最も高い領域であり、他のアーキテクチャはここを詳細化したものだと思えば全体像が掴めます。
なぜ最初に決めるか
この領域は One-way Door（Amazon ベゾス流の「後戻り困難な決定」）の集合地帯です。下流の判断は、ここで決めたことに縛られます。一度決めた骨組みを後から変えるのは、以下のように重い作業になります。
- クラウドベンダーを途中で変えるのは実質「作り直し」
- オンプレとクラウドを後から切り替えるのも大工事
- OS・DB製品の変更は広範囲に波及
小規模プロジェクトでも、最初に大枠を決めておくのが鉄則です。「あとで考える」は小さなプロジェクトほど致命傷になりやすく、コードと運用が骨組みに癒着してから剥がす作業になります。
MVPだから適当でいい、という姿勢はあとで最もコストの高い選択になります。システムアーキテクチャはプロジェクト1週目に骨子を決めるべきで、先送りは小規模ほど致命傷です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
この領域で決めるべき項目を、3つのグループに分けて整理します。
基盤の選定
| 項目 | 選択肢の例 |
|---|---|
| アプリケーション形態 | ネイティブアプリ・WEBアプリ・ハイブリッドアプリ |
| デプロイモデル | オンプレ・クラウド・ハイブリッド |
| クラウドベンダー | AWS・GCP・Azure |
| 実行環境 | VM・コンテナ・サーバーレス |
| OS選定 | Linux・Windows・UNIX |
| データ永続化方法 | RDBMS・NoSQL・ファイルシステム |
この層は配下の記事 01〜06 で順に扱います。最初に決めるべき土台の部分で、ここを誤ると後段の選定全てが狂います。
ネットワーク・セキュリティ・運用
| 項目 | 選択肢の例 |
|---|---|
| DBベンダー | Oracle・PostgreSQL・DynamoDB |
| バッチ処理方式 | 常駐・スケジュール・イベント駆動 |
| ネットワーク | IPアドレス帯の設計・サブネット分割 |
| 通信プロトコル | HTTPS・gRPC・WebSocket |
| セキュリティ基盤 | WAF・IDS/IPS・ゼロトラスト（社内ネットワークも信頼せず毎回認証する考え方） |
| 監視・アラート設計 | CloudWatch・Datadog・PagerDuty |
ネットワーク・セキュリティ・監視は後付けが極めて難しい領域で、設計段階で組み込んでおく前提が必要です。配下の記事 07〜09 で扱います。
BCP・コスト・運用自動化
| 項目 | 選択肢の例 |
|---|---|
| ストレージ・バックアップ | S3・Blob・アーカイブ戦略 |
| 外部接続 | インターネットGW・NAT・VPN・専用線 |
| BCP対策 | マルチAZ（同一リージョン内の複数データセンターに分散）・マルチリージョン（地理的に離れた拠点に分散）・DRサイト |
| CI/CD基盤 | GitHub Actions・GitLab CI・CodePipeline |
| IaC | Terraform・CloudFormation・Pulumi |
事業継続・コスト管理は配下の記事 10〜11 で扱います。CI/CD・IaC・構成管理などの開発プロセス系は別カテゴリ「開発・運用アーキテクチャ」に集約しています。
このカテゴリの知識構造
このカテゴリは全12記事で構成されていますが、やみくもに読む必要はありません。記事は3つのグループに分かれ、上流のグループの決定が下流を制約する構造になっています。
**グループ1（基盤の選定）**は、アプリ形態 → デプロイ → ベンダー → 実行環境 → OSの順に決めます。上流で決めた内容が下流の選択肢を絞るため、この順序を逆にすると必ず手戻りが発生します。たとえばDBを先に決めてからクラウドベンダーを選ぶと、選定の幅が不自然に狭まります。
**グループ2（データとネットワーク）**は、基盤の上でデータをどこに置き、どう繋げ、どう守り、どう見張るかを設計します。ネットワークとセキュリティは後付けが極めて困難な領域なので、基盤選定と同時期に着手するのが鉄則です。
**グループ3（事業継続とコスト）**は、構成が固まった後に「壊れたらどう復旧するか」「費用をどう管理するか」を設計します。BCP計画書を作っただけで訓練しないのは典型的な失敗パターンです。
全体を通して、上流から順に決めるのがシステムアーキテクチャの鉄則です。
規模・フェーズ別のシステム構成
システムアーキテクチャは組織規模で最適解が変わります。先に結論だけ言うと、個人〜中規模SaaSまでは 単一クラウド＋マネージド＋IaC が鉄板で、ハイブリッドやマルチクラウドは大企業以上に限定するのが2026年時点の健全解です。
| フェーズ | 月額インフラ費 | 推奨構成 | BCP水準 | 専任インフラ人員 |
|---|---|---|---|---|
| MVP・個人 | 〜5,000円 | 単一クラウド・1リージョン・マネージド | 99% | 0人 |
| 初期スタートアップ | 5万〜50万円 | 単一クラウド・マルチAZ・IaC必須 | 99.9% | 0.5人 |
| 中規模 SaaS | 50万〜500万円 | 単一クラウド + DR用2リージョン | 99.95% | 1〜3人 |
| 大企業 | 500万円〜 | ハイブリッド + 専用線 + Organizations | 99.99% | 5人〜 |
| 金融・医療・公共 | 業種次第 | プライベートクラウド・コンプライアンス認定 | 業種要件 | 10人〜 |
マルチクラウド・ハイブリッドの実質下限は専任インフラ人員3人以上です。これ未満で選ぶと、運用だけで現場が溶けます。
「単一クラウドに寄せる勇気」が運用とAI生産性の両立に直結します。スタートアップが大企業の構成を真似るのは、よく見る典型的な失敗パターンで、数カ月で疲弊して縮退移行に追い込まれます。規模に見合わない構成は負債にしかなりません。
AI時代の判断軸 ― コードで表現できるか
規模に加えて、AI駆動開発（バイブコーディング）前提の時代には「コードで表現できるか」という判断軸が全ての選定に重なります。
| AI時代に有利 | AI時代に不利 |
|---|---|
| パブリッククラウド + IaC（Terraform） | オンプレ・GUI前提の運用 |
| コンテナ + 標準技術（k8s・OCI） | ベンダー独自ランタイム |
| OIDC・SSO等の標準認証 | 独自認証・長期キー運用 |
| OpenTelemetry（ログ/メトリクス/トレースをベンダー中立に収集する業界標準）等の標準可観測性 | ベンダー独自SDK |
ベンダーロックインの論点も変わりました。単なる移行コストではなく、「AIがそのベンダーを詳しく知っているか」が新しいロックインリスクです。情報量が世界一のAWSの優位は、ここからさらに広がる方向です。
全項目に共通する選定の優先順位をまとめると次の通りです。
- 上流から順に決める（アプリ形態 → デプロイ → ベンダー → 実行環境）
- IaC化可能性を全選定の必須チェック項目に
- 単一クラウドに寄せる（マルチクラウドは明確な理由がある時だけ）
- 標準プロトコル準拠（OIDC・OpenTelemetry等）を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など）がある場合に限られます。
やってはいけないこと
各論記事で触れた禁じ手と、非専門家が陥りやすい勘違いから、全体設計レベルで押さえるべき核心を整理します。
| 禁じ手 | なぜダメか |
|---|---|
| 下流から決めて上流に逆算 | アプリ形態・クラウド・実行環境の順序を崩すと必ず手戻り |
| マルチクラウドを人員不足で採用 | IAM・監視・IaC二重化で運用コスト倍増 |
| IaCなし・GUI手動構築 | 環境差分が生まれ再現不能、AI時代に負債化 |
| BCP計画書を作って訓練なし | GitLab 2017年のようにバックアップが機能せず |
| セキュリティを後から追加 | 認証・暗号化・監査ログは設計時組み込み必須 |
| FinOpsなしでクラウド利用 | 月100万円超の請求書で経営が揺らぐ |
| DB / Redis を Publicサブネット | 2017年 MongoDB ランサム事件のパターン |
| 単一AZ で本番運用 | AZ 障害で全停止、マルチAZ は最低ライン |
| 最新技術スタックを無条件に採用 | 情報量が薄くAI生成精度も低い。枯れた標準技術のほうが安全 |
| 大手の構成をそのまま真似る | 規模の前提が違い、オーバーエンジニアリングで保守不能に |
| 全部マネージドに寄せる | ロックインとコスト固定費化。適材適所で選定する |
| 自社DCの方が安全と思い込む | パッチ・監視・BCP・人材の自前負担がリスクを押し上げる |
ここで出てくるFinOpsはクラウドコスト運用の継続最適化を指します。詳細は配下の記事「コスト管理」で扱います。
システムアーキテクチャは最も戻せない領域です。規模・上流順・IaC化・セキュリティ標準装備、この4点を外さないことが死活的に重要です。
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰しました。如何だったでしょうか。
システムアーキテクチャは最も戻せない領域です。規模・上流順・IaC化・セキュリティ標準装備の4点を最初に決めることが、その後の数年〜10年の運用コストとAI時代対応力を決定づけます。
次回からはこの領域の各論に入り、まずアプリケーション形態（Native / Web / Hybrid）の選び方から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS Well-Architected フレームワーク も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（5/89）