この用語をシェア
システム設計とは
システム設計（System Design）とは、要件定義で洗い出された機能要件・非機能要件を満たすために、サーバー・データベース・API・キュー・キャッシュといった構成要素をどう組み合わせ、どう分散させ、どこにトレードオフを許容するかを決定していく設計行為です。単発の「設計書を書く作業」ではなく、要件定義→概算見積もり→アーキテクチャ選定→詳細設計→検証というサイクルを、サービスの成長やトラフィックの変化に合わせて繰り返す継続的なプロセスと捉えるのが実務的です。
AIエンジニアにとってのシステム設計は、Webサービス一般の設計原則（可用性・スケーラビリティ・一貫性・保守性）に加えて、「モデル」という重くて確率的な出力をするコンポーネントをシステムに組み込む難しさが加わる点が特徴です。学習済みモデルは数百MB〜数十GBのサイズを持ち、GPU/TPUという高コストなリソースを前提とし、レスポンスにはミリ秒〜秒単位のばらつきが生じます。したがってAIシステム設計では、モデルサービングの遅延・スループット・コストのバランス、データパイプラインの信頼性、推論結果の品質劣化（ドリフト）の検知といった、通常のバックエンド設計にはない論点を扱う必要があります。
非機能要件は一般に「可用性（Availability）」「スケーラビリティ（Scalability）」「パフォーマンス（Performance）」「一貫性（Consistency）」「保守性（Maintainability）」「セキュリティ（Security）」「コスト（Cost）」の7つの軸で整理されることが多く、システム設計とはこれらの軸の間でどこを優先し何を犠牲にするかを、根拠を持って決める技術だと言えます。すべてを同時に満点にすることはできないため、「なぜこの構成にしたのか」を説明できることが設計者としての実務価値になります。
実務では、こうした意思決定の経緯を「ADR（Architecture Decision Record）」と呼ばれる短い文書として残す進め方が定着しつつあります。検討した選択肢、選んだ理由、捨てたトレードオフを数行〜1ページ程度で記録しておくことで、半年後にチームメンバーが変わっても「なぜこの構成なのか」を追跡できるようになり、後から構成を見直す際の判断材料にもなります。設計は一度きりの成果物ではなく、要件変化・トラフィック増加・新技術の登場に応じて継続的に見直される前提で運用するのが実務的な考え方です。
仕組み・詳細解説
非機能要件の定義とトレードオフ分析
設計の出発点は「1秒間に何リクエスト処理する必要があるか（QPS）」「p95・p99レイテンシの目標値は何msか」「稼働率（SLA）は99.9%か99.99%か」といった数値を明文化することです。数値がないまま「速くて落ちないシステム」を作ろうとすると、判断基準を持てず設計がぶれます。分散システムの基礎理論としてCAP定理（一貫性 Consistency・可用性 Availability・分断耐性 Partition tolerance の3つを同時に満たすことはできないという定理）があり、ネットワーク分断が起きた際に一貫性を優先するか可用性を優先するかは、システムの性質（決済システムか、レコメンド表示かなど）によって答えが変わります。AI推論システムでは多くの場合、多少古いモデルバージョンの結果が返っても止まらないことを優先する「可用性寄り」の設計が選ばれる傾向があります。
アーキテクチャパターンの選択
代表的なアーキテクチャパターンには、単一アプリケーションにすべての機能を持たせる「モノリシック」、機能単位でサービスを分割し独立してデプロイできる「マイクロサービス」、サービス間をイベントとメッセージキューで疎結合につなぐ「イベント駆動アーキテクチャ」、UI・ビジネスロジック・データアクセスを層で分離する「レイヤードアーキテクチャ」があります。AI機能を持つサービスでは、モデル推論部分だけをマイクロサービスとして切り出し、gRPCやREST API経由で呼び出す構成がよく採用されます。理由は、GPUリソースを必要とする推論サービスと、CPUで十分なWebアプリ本体とではスケーリングの単位・コストの性質が全く異なり、別々にオートスケールさせたいためです。
AIワークロード特有の設計要素
AIシステム設計に固有の構成要素として、以下が挙げられます。①モデルサービング層: NVIDIA Triton Inference ServerやKServe、vLLM、Text Generation Inference（TGI）などを用い、バッチ処理と動的バッチング（continuous batching）でGPU利用率を上げる。②特徴量ストア（Feature Store）: Feastなどを用い、学習時と推論時で同じ特徴量計算ロジックを使う「学習・推論スキュー」の防止を行う。③ベクトルデータベース: Pinecone、Weaviate、Milvus、pgvectorなどで埋め込みベクトルの近似最近傍探索（ANN）を行い、RAG（検索拡張生成）の検索部分を担う。④非同期推論キュー: 重い画像生成・音声生成などはリクエストを即時返さず、SQSやKafkaでジョブキューに積み、ワーカーが処理後にWebhookやポーリングで結果を返す設計にする。
キャパシティプランニングと概算見積もり
実務の設計面談やアーキテクチャレビューでは「back-of-the-envelope estimation（概算見積もり）」がよく行われます。例えば「月間アクティブユーザー100万人、1人あたり1日5回リクエスト」であれば、1日あたり500万リクエスト、秒間平均では約58QPS、ピーク時（平均の3〜5倍と仮定）では200〜300QPS程度を見込む、といった計算です。LLM推論であれば「1リクエストあたり平均500トークン生成、1トークンの生成に数十ms」という前提から、1台のGPUインスタンスが処理できるスループットを見積もり、必要なインスタンス台数を逆算します。こうした概算は精緻さより「桁を外さない」ことが重要で、設計初期の意思決定（キャッシュを入れるべきか、CDNは必要か、DBはシャーディングすべきかなど）の判断材料になります。
具体例・ユースケース
抽象論だけでは設計力は身につきません。実際によく題材になる3つのケースで考え方を確認します。
ケース1: 社内文書検索チャットボット（RAG）の設計
ユーザーの質問を受け取り、①埋め込みモデルでベクトル化→②ベクトルDBで類似文書をtop-k検索→③検索結果をプロンプトに埋め込みLLMへ送信→④回答を生成、という4段のパイプラインになります。設計上の論点は、全体のレイテンシ予算（例えば3秒以内に返したい場合、埋め込み生成に200ms、ベクトル検索に100ms、LLM生成に2.5秒、といった内訳をあらかじめ割り振る）、文書更新頻度に応じた埋め込みの再生成バッチのスケジューリング、LLM呼び出し失敗時のリトライとタイムアウト、そして同じ質問が繰り返された場合のレスポンスキャッシュです。
ケース2: ECサイトのレコメンド機能
「重い計算はあらかじめバッチで済ませ、リアルタイムでは軽い処理だけ行う」というバッチ推論とオンライン推論のハイブリッド設計が定番です。夜間バッチでユーザーごとの推薦候補リストを数百件計算しRedisなどのインメモリKVSに保存しておき、ユーザーがサイトにアクセスした瞬間はKVSから取り出して簡易な再ランキングのみをその場で行う、という構成にすることで、リアルタイム側のレイテンシを数十ms程度に抑えられます。
ケース3: 画像生成サービスのスケーリング
画像生成は1リクエストあたり数秒〜数十秒かかりGPUを占有するため、Webのリクエスト・レスポンスをそのまま同期で待たせる設計は破綻しやすくなります。フロントはジョブ登録APIのみを提供し、ジョブIDを即座に返却、実処理はGPUノードのワーカープールがキューから取り出して実行し、完了後にステータスをポーリングまたはWebSocketで通知する非同期設計が一般的です。GPUノードはKubernetesのHorizontal Pod Autoscaler（HPA）やKEDA（イベント駆動オートスケーラー）でキュー長に応じて台数を増減させ、アイドル時のGPUコストを抑えます。
メリット・デメリット（設計の質による違い）
システム設計を丁寧に行うことのメリットと、やり過ぎ・不足によるデメリットは表裏一体です。実務では「今のフェーズに見合った設計」を選ぶバランス感覚が求められます。
| 観点 | 適切な設計のメリット | 不足・過剰時のデメリット |
|---|---|---|
| 障害耐性 | 単一障害点を排除し、一部障害でもサービス継続 | 設計不足だと1台の障害が全体停止に直結する |
| コスト | 負荷に応じたオートスケールで無駄な支出を抑制 | 過剰設計（初期からマイクロサービス化等）は運用コスト増 |
| 開発速度 | 責務が明確で並行開発・保守がしやすい | 複雑な分散構成は初期の開発速度を落とす場合がある |
| 拡張性 | 将来のトラフィック増に段階的に対応できる | 将来を見込みすぎた抽象化は変更時にかえって足かせになる |
特にAIプロダクトは初期段階では要件・利用パターンが読みにくいため、「YAGNI（You Aren't Gonna Need It）」の原則に立ち、まずはシンプルな構成でリリースし、実測されたボトルネックに対してピンポイントで設計を強化していくアプローチが失敗しにくいというのが実務的な経験則です。
混同されやすい用語・類似技術との違い
| 用語 | 意味・スコープ | システム設計との違い |
|---|---|---|
| ソフトウェアアーキテクチャ | 1つのアプリケーション内部のクラス・モジュール構造 | システム設計はより広く、複数サービス・インフラ・DBを含む全体構成を扱う |
| インフラ設計 | サーバー・ネットワーク・クラウドリソースの構成 | システム設計の実現手段の一部。IaC（Terraform等）で構築される対象 |
| MLOps | モデルの学習・評価・デプロイ・再学習を自動化する実践 | システム設計はMLOpsを実行する土台となるシステム全体の構成を決める上位概念 |
| DevOps | 開発と運用の文化・プロセス（CI/CD、自動化など） | システム設計が「何を作るか」なら、DevOpsは「どう作り続け運用するか」に近い |
| データベース設計 | テーブル・スキーマ・インデックスの設計 | システム設計の中の一要素で、正規化・シャーディング戦略などを含む |
実務でよくある混同は「システム設計＝インフラ構築」という誤解です。インフラはあくまで実現手段であり、システム設計の本質は「どのコンポーネントに」「どういう責務を」「どういうトレードオフのもとで」持たせるかという意思決定にあります。クラウドの知識だけでは良い設計はできず、非機能要件を言語化する力とトレードオフを比較検討する力が中核のスキルになります。
AIエンジニアのための学習ロードマップ
システム設計はAI開発工程のうち、主に「モデルを本番環境に組み込む設計フェーズ（実装・デプロイ設計）」と「サービス全体のスケール対応フェーズ」で必要になります。データ分析・モデル開発だけを担当している段階では優先度は低くても、モデルを実サービスに載せる段になった瞬間に必須のスキルへと変わります。
初級（基礎を固める段階）
まずはHTTP・REST APIの基本、リレーショナルデータベースとNoSQLの違い、キャッシュ（Redis等）の役割、ロードバランサーの仕組みといった単一要素を理解します。この段階で「なぜキャッシュを入れると速くなるのか」「なぜDBのインデックスが重要か」を自分の言葉で説明できることを目標にします。Dockerでコンテナ化し、簡単なAPIサーバーを自分で立ててみる経験も有効です。
中級（構成要素を組み合わせる段階）
複数コンポーネントを組み合わせた設計に挑戦します。ロードバランサー＋複数APIサーバー＋DBレプリケーション、メッセージキューを用いた非同期処理、CDNによる静的コンテンツ配信などです。AI文脈では、学習済みモデルをFastAPIやFlaskでAPI化し、Dockerコンテナとしてパッケージングし、Kubernetes上にデプロイしてオートスケールさせる、という一連の流れを一度手を動かして経験しておくと理解が大きく進みます。
実務レベル（トレードオフを判断できる段階）
実務レベルでは「なぜこの構成にしたか」を数値と代替案付きで説明できることが求められます。RAGパイプラインのレイテンシ内訳を計測し、ボトルネックを特定してキャッシュ層やベクトルDBのインデックス方式（HNSW、IVF等）を調整する、GPU推論のコストとレイテンシのトレードオフをバッチサイズ・量子化（INT8/FP16）で調整する、障害訓練（カオスエンジニアリング的な発想）でフェイルオーバーを検証する、といった実践経験を積んでいきます。
定番の学習リソース
書籍では、分散システムの原理を体系的に扱う "Designing Data-Intensive Applications"（Martin Kleppmann著）が定番として広く読まれています。日本語では技術面接対策も兼ねた「システム設計の教科書」的な書籍やオンライン教材（ByteByteGoのSystem Design Interviewシリーズなど）も、パターンを俯瞰する入り口として役立ちます。運用・信頼性の観点ではGoogleのSite Reliability Engineering（SRE）に関する書籍・公開資料が、可用性設計の考え方を学ぶ上で参考になります。加えて、AWSやGoogle Cloudが公開しているアーキテクチャのリファレンス設計集やWell-Architected Frameworkは、実際のクラウド構成パターンを学ぶ上で実務に直結します。
2025〜2026年の最新動向
生成AI・LLMの普及に伴い、システム設計で扱う対象は「モデルを1つサービングする」段階から「複数モデル・複数ツールを連携させるAIエージェントを設計する」段階へと広がりつつあります。エージェント同士やツール呼び出しを協調させるオーケストレーション層の設計、長時間実行されるタスクの状態管理、途中経過の永続化（チェックポイント）といった論点が新たに重要視されています。
推論コスト最適化の観点では、vLLMやTGIに代表されるcontinuous batching（動的バッチング）やPagedAttentionといった手法によりGPUのスループットを引き上げる工夫が標準化しつつあり、量子化（INT4/INT8）やモデル蒸留を組み合わせてコストとレイテンシのバランスを取る設計判断が一般的になっています。また、マルチモーダルモデル（テキスト・画像・音声を同時に扱うモデル）を前提としたサービング基盤や、入力トークン数に応じて課金が変動する特性を踏まえたコスト設計（プロンプトキャッシュの活用など）も実務での関心事になっています。
クラウド各社は生成AIワークロードに特化したアーキテクチャガイダンス（AWSのGenerative AI Well-Architected Lens、Google CloudのAIアーキテクチャセンターなど）を継続的に整備しており、AIシステム設計の「型」が徐々に業界標準として蓄積されてきている段階にあると言えます。設計者としては個々のツールの流行を追うだけでなく、レイテンシ予算・コスト構造・障害モードといった普遍的な設計原則に立ち返って評価する姿勢が引き続き重要です。
よくある質問（FAQ）
Q. AIシステム設計で特有の考慮事項は何ですか？
A. AIシステム設計では通常のソフトウェア設計に加え、①データパイプラインの設計（特徴量エンジニアリング・ストレージ）②モデルサービング（レイテンシ・スループット・GPU利用）③モデルバージョン管理（MLflow・DVC）④モデルモニタリング（データドリフト・精度劣化の検知）⑤A/Bテスト基盤、の5点が典型的な追加の考慮事項になります。
Q. MLOpsとはどのような概念ですか？システム設計とどう関係しますか？
A. MLOps（Machine Learning Operations）はMLとDevOpsを組み合わせた実践で、モデルの開発・デプロイ・監視・再学習を自動化し、本番環境でのAIシステムの信頼性を高めることを目的とします。主要ツールはMLflow（実験管理）・Kubeflow（Kubernetes上でのML）・Airflow（パイプライン）・Seldon（モデルサービング）です。システム設計はこのMLOpsが動作する全体の器（アーキテクチャ）を決める、より上位の意思決定だと位置づけられます。
Q. 大規模LLMシステムのアーキテクチャ設計のポイントは何ですか？
A. 近年のLLMシステム設計では、①RAGアーキテクチャ（ベクトルDB＋LLMの組み合わせ）②非同期・ストリーミングレスポンス（トークンを逐次返しUXを保つ）③コスト最適化（プロンプトキャッシュ・モデル選択の使い分け）④プロンプト管理・バージョン管理⑤LLMモニタリング（LangSmith、Phoenixなどの可観測性ツール）⑥エラーハンドリング（ハルシネーションの検知とフォールバック）が重要なポイントです。
Q. システム設計を勉強するのにコーディングスキルはどれくらい必要ですか？
A. システム設計は「構成要素をどう組み合わせるか」を考える設計スキルであり、特定言語の高度な実装力そのものとは別軸です。ただし、APIサーバーを自分で書いた経験、DBのクエリを実際にチューニングした経験がないと、机上の議論に終始しがちです。PythonやGoなどでシンプルなWebアプリケーションを一通り自作した経験があると、設計上のトレードオフを具体的にイメージしやすくなります。
Q. システム設計の面接（デザイン面接）では何が評価されますか？
A. 単一の「正解構成」を答えることよりも、要件の確認（誰が何回使うか、読み書きの比率はどうかなど）、概算見積もり、複数の設計選択肢の提示とトレードオフの説明、ボトルネックの特定と対策という「思考プロセス」が評価される傾向にあります。結論の構成図そのものより、なぜその構成を選んだかを筋道立てて話せるかが重要視されます。
関連用語
システム設計と合わせて理解しておきたい、AIエンジニアスキルカテゴリの関連用語です。
外部リンク・参考資料
- AWS Well-Architected Framework: 可用性・パフォーマンス・コストなど6つの柱でクラウド設計を評価するAWS公式のフレームワーク。
- Google Cloud アーキテクチャ フレームワーク: Google Cloud公式のシステム設計ベストプラクティス集。
- Kubernetes 公式ドキュメント: オートスケーリング・サービスディスカバリなど、分散システム設計を支えるコンテナオーケストレーションの公式リファレンス。
- Site Reliability Engineering（Google, 無料公開版）: 可用性・信頼性設計の考え方をGoogleの実践から学べる公開書籍。