本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリの入口として、ハードウェア・ソフトウェア・ネットワークを包括した骨組み全体を俯瞰する記事です。建物でいえば基礎工事と構造材にあたり、全アーキテクチャ層で最もやり直しが効かない領域です。
本記事ではこの領域で何を決めるのか、なぜ最初に決める必要があるのか、AI駆動開発前提の選定軸まで俯瞰します。
このカテゴリの他の記事
最初にして、最も戻しにくい決定
システムアーキテクチャは、ハードウェア・ソフトウェア・ネットワークを含む全体の骨組みを決める層です。建物で言えば基礎工事と構造材にあたります。ここを後から変えようとすると、家を建て直すのとほぼ同じだけのコストがかかる。ここが他の領域との決定的な違いです。
「インフラアーキテクチャ」とほぼ同じ意味で使う現場が多く、両者を区別しない派閥もあります。呼び方はどうでもよくて、「骨組みをまとめて扱う層」と押さえておけば十分です。
他のアーキテクチャ層（ソフトウェア・データ・セキュリティ等）は、この層で決まった骨組みの上に建てる内装にあたり、骨組みの制約を全面的に受けます。各アーキテクチャの中で難易度が最も高い領域であり、他のアーキテクチャはここを詳細化したものだと思えば全体像が掴めます。
なぜ最初に決めるか
この領域は One-way Door（Amazon ベゾス流の「後戻り困難な決定」）の集合地帯です。下流の判断は、ここで決めたことに縛られます。一度決めた骨組みを後から変えるのは、以下のように重い作業になります。
- クラウドベンダーを途中で変えるのは実質「作り直し」
- オンプレとクラウドを後から切り替えるのも大工事
- OS・DB製品の変更は広範囲に波及
小規模プロジェクトでも、最初に大枠を決めておくのが鉄則です。「あとで考える」は小さなプロジェクトほど致命傷になりやすく、コードと運用が骨組みに癒着してから剥がす作業になります。
MVPだから適当でいい、という姿勢はあとで最もコストの高い選択になります。システムアーキテクチャはプロジェクト1週目に骨子を決めるべきで、先送りは小規模ほど致命傷です。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
この領域で決めるべき項目を、3つのグループに分けて整理します。
flowchart TB
A[1. 基盤の選定<br/>アプリ形態 / デプロイ / クラウド / 実行環境 / OS]
B[2. データの置き場<br/>DB / ストレージ / NW構成]
C[3. 運用の仕組み<br/>監視 / BCP / コスト管理 / セキュリティ]
A -->|上流の決定が<br/>下流を縛る| B
B --> C
classDef base fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef data fill:#fef3c7,stroke:#d97706;
classDef ops fill:#fae8ff,stroke:#a21caf;
class A base;
class B data;
class C ops;基盤の選定
| 項目 | 選択肢の例 |
|---|---|
| アプリケーション形態 | ネイティブアプリ・WEBアプリ・ハイブリッドアプリ |
| デプロイモデル | オンプレ・クラウド・ハイブリッド |
| クラウドベンダー | AWS・GCP・Azure |
| 実行環境 | VM・コンテナ・サーバーレス |
| OS選定 | Linux・Windows・UNIX |
| データ永続化方法 | RDBMS・NoSQL・ファイルシステム |
この層は配下の記事 01〜06 で順に扱います。最初に決めるべき土台の部分で、ここを誤ると後段の選定全てが狂います。
ネットワーク・セキュリティ・運用
| 項目 | 選択肢の例 |
|---|---|
| DBベンダー | Oracle・PostgreSQL・DynamoDB |
| バッチ処理方式 | 常駐・スケジュール・イベント駆動 |
| ネットワーク | IPアドレス帯の設計・サブネット分割 |
| 通信プロトコル | HTTPS・gRPC・WebSocket |
| セキュリティ基盤 | WAF（Web Application Firewall、Webの攻撃防御装置）・IDS/IPS（侵入検知／防御システム）・ゼロトラスト（社内ネットワークも信頼せず毎回認証する考え方） |
| 監視・アラート設計 | CloudWatch・Datadog・PagerDuty |
ネットワーク・セキュリティ・監視は後付けが極めて難しい領域で、設計段階で組み込んでおく前提が必要です。配下の記事 07〜09 で扱います。
BCP・コスト・運用自動化
| 項目 | 選択肢の例 |
|---|---|
| ストレージ・バックアップ | S3・Blob・アーカイブ戦略 |
| 外部接続 | インターネットGW・NAT・VPN・専用線 |
| BCP対策 | マルチAZ（同一リージョン内の複数データセンターに分散）・マルチリージョン（地理的に離れた拠点に分散）・DRサイト（Disaster Recovery、災害時の待機系） |
| CI/CD基盤 | GitHub Actions・GitLab CI・CodePipeline |
| IaC（Infrastructure as Code、インフラ構成をコードで管理） | Terraform・CloudFormation・Pulumi |
事業継続・コスト管理は配下の記事 10〜11 で扱います。CI/CD・IaC・構成管理などの開発プロセス系は別カテゴリ「開発・運用アーキテクチャ」に集約しています。
検討の進め方
システムアーキテクチャの検討は、必ず上流から順に決めるのが鉄則です。下流から決めて上流に逆算するのは事故のもとで、必ず手戻りが発生します。
1. アプリケーション形態を決める ← 最上流（01_アプリケーション形態）
↓
2. デプロイモデルを決める ← オンプレ / クラウド（02_デプロイモデル）
↓
3. クラウドベンダーを選定 ← AWS / Azure / GCP（03_クラウドベンダー）
↓
4. 実行環境を決める ← VM / コンテナ / FaaS（04_実行環境）
↓
5. DB・ネットワーク・セキュリティ等の個別設計この順序に沿えば、下流の判断に必要な前提が自動的に揃っていきます。逆順で決めると、たとえば「DBを決めてからクラウドベンダーを選ぶ」という不自然な動きになり、選定の幅が人為的に狭まります。
上流から順に決める。下流から逆算するのは事故のもと。これは原則として外せません。
規模・フェーズ別のシステム構成
システムアーキテクチャは組織規模で最適解が変わります。先に結論だけ言うと、個人〜中規模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生産性の両立に直結します。スタートアップが大企業の構成を真似るのは、よく見る典型的な失敗パターンで、数カ月で疲弊して縮退移行に追い込まれます。規模に見合わない構成は負債にしかなりません。
システムアーキテクチャ全体の鬼門
各論記事で触れた禁じ手のうち、全体設計レベルで押さえるべき核心を整理します。
| 禁じ手 | なぜダメか |
|---|---|
| 下流から決めて上流に逆算 | アプリ形態・クラウド・実行環境の順序を崩すと必ず手戻り |
| マルチクラウドを人員不足で採用 | IAM・監視・IaC二重化で運用コスト倍増 |
| IaCなし・GUI手動構築 | 環境差分が生まれ再現不能、AI時代に負債化 |
| BCP計画書を作って訓練なし | GitLab 2017年のようにバックアップが機能せず |
| セキュリティを後から追加 | 認証・暗号化・監査ログは設計時組み込み必須 |
| FinOpsなしでクラウド利用 | 月100万円超の請求書で経営が揺らぐ |
| DB / Redis を Publicサブネット | 2017年 MongoDB ランサム事件のパターン |
| 単一AZ で本番運用 | AZ 障害で全停止、マルチAZ は最低ライン |
ここで出てくるFinOpsはクラウドコスト運用の継続最適化を指します。詳細は配下の記事「コスト管理」で扱います。
システムアーキテクチャは最も戻せない領域です。規模・上流順・IaC化・セキュリティ標準装備、この4点を外さないことが死活的に重要です。
AI時代のシステムアーキテクチャ
AI駆動開発（バイブコーディング）が入ってくると、システムアーキテクチャ全体に「コードで表現できるか」という新しい評価軸が重なります。
以前は「エンジニアの学習コスト・運用人員の確保しやすさ」が選定の中心軸でしたが、今はAIが流暢に書けるスタック・IaCで全て宣言できる構成・標準プロトコル準拠が決定的に効きます。
| AI時代に有利 | AI時代に不利 |
|---|---|
| パブリッククラウド + IaC（Terraform） | オンプレ・GUI前提の運用 |
| コンテナ + 標準技術（k8s（Kubernetes）・OCI（Open Container Initiative、コンテナ業界標準仕様）） | ベンダー独自ランタイム |
| OIDC（OpenID Connect、ログイン連携の標準）・SSO（Single Sign-On、シングルサインオン）等の標準認証 | 独自認証・長期キー運用 |
| OpenTelemetry（ログ/メトリクス/トレースをベンダー中立に収集する業界標準）等の標準可観測性 | ベンダー独自SDK |
結果としてベンダーロックインの論点も変質しました。単なる移行コストの話ではなく、「AIがそのベンダーを詳しく知っているか」これが新しいロックインリスクです。情報量が世界一のAWSの優位は、ここからさらに広がる方向です。
Terraform で書けば AWS と GCP を行き来できる、という楽観論はあるものの、実際には各ベンダーのサービス固有の癖をAIがどれだけ学習しているかで、開発速度が体感で2〜3倍変わります。全てをコードで宣言できる状態に持っていく。これがAI時代の基本姿勢です。
よくある勘違い
非専門家・若手エンジニアが陥りやすい誤解を整理します。どれも一見もっともらしく見えて、実務では手痛いしっぺ返しを食らいます。
- 最新技術が優れている → 本当はこう：最新技術は情報量が薄く、AIの学習データも十分に揃っていません。枯れた標準技術のほうが運用ノウハウもAI生成精度も一枚上。「最新」は罠になりやすいキーワードです
- 大手が使っているから正解 → 本当はこう：大手の選定理由は「数万人規模・数億ユーザー」という前提で成立しています。中小規模で同じ選定を真似るとオーバーエンジニアリングで、保守できない怪物が残ります。自社の規模と制約に合わせるのが大原則
- 全部マネージドにすれば楽 → 本当はこう：マネージドは運用負担を減らす代わりに、ロックインとコスト固定費化を引き込みます。適材適所で選ばないと、毎月の請求書が数百万円まで膨らみ、撤退できない状態で固まります
- 自社データセンターの方が安全 → 本当はこう：物理的に自社にある＝安全、という直感は誤りです。パッチ適用・監視・BCP・人材確保を全部自前で回す負担がセキュリティリスクを押し上げる。大手クラウドのほうが、専任セキュリティチームと監査体制で守られているケースが多い
「直感的に正しそう」な判断ほど疑う価値があります。必ず規模と前提を照らし合わせる習慣が、システムアーキテクトを1年で一段レベルアップさせます。
決めるべきこと — 優先度順チェックリスト（再掲＋追加）
冒頭の「決めるべきこと」を踏まえ、プロジェクト立ち上げ時にシステムアーキテクトが決めるべき項目を優先度順に並べ直したものが下記です。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- アプリケーション形態（Native / Web / Hybrid）
- デプロイモデル（クラウド／オンプレ／ハイブリッド）
- クラウドベンダー（AWS / GCP / Azure、または複数）
- 実行環境（VM / コンテナ / サーバーレス）
- データストア（RDB / NoSQL / 併用）
- ネットワーク設計（VPC / サブネット / 接続方式）
- 監視基盤（ツール選定・アラート方針）
- BCP方針（RTO / RPO / 冗長化レベル）
最終的な判断の仕方
この領域は後から変えられない決定が最も多いのが特徴で、他の全ての層（ソフトウェア・フロントエンド・データ）の土台になります。だから選定順序は上流から固める。これ1点に尽きます。
アプリケーション形態 → デプロイモデル → クラウドベンダー → 実行環境の順で、下流は上流の制約を受けて決まります。逆順で決めると必ず手戻りが出ます。
全項目に共通する判断軸は 「コードで管理できるか」（IaC化できるか） の1点に集約されます。単一クラウド ＋ コンテナ ＋ IaC ＋ OIDC ＋ 標準プロトコルの組み合わせが、AI駆動開発・運用コスト・人材確保のどの観点でも最も健全です。
ベンダーロックインを過剰に恐れるより、1つに寄せて徹底活用するほうが生産性は高い。これが2026年の実務的な結論です。
選定の優先順位をまとめると次の通りです。
- 上流から順に決める（アプリ形態 → デプロイ → ベンダー → 実行環境）
- IaC化可能性を全選定の必須チェック項目に
- 単一クラウドに寄せる（マルチクラウドは明確な理由がある時だけ）
- 標準プロトコル準拠（OIDC・OpenTelemetry等）をAI時代の必須条件に
「コードで全てを表現する」これが各論を貫く共通の背骨です。
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰しました。如何だったでしょうか。
システムアーキテクチャは最も戻せない領域です。規模・上流順・IaC化・セキュリティ標準装備の4点を最初に決めることが、その後の数年〜10年の運用コストとAI時代対応力を決定づけます。
次回からはこの領域の各論に入り、まずアプリケーション形態（Native / Web / Hybrid）の選び方から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（5/89）