システム設計とは
この記事の結論
- システム設計とは、要件定義で決めた条件を満たすために、システムをどんな部品に分け、部品どうしをどうつなぐかを決める工程のことです。
- 決める中身は、部品の構成・扱うデータの形・部品の間のやりとり・品質の作り込み方の4つに整理できます。どれも、何かを得る代わりに何かを手放す選択です。
- AIに実装を任せるほど、設計の判断を文章で残しておく価値が上がります。残っていない判断は、依頼のたびに別の答えで埋められます（2026-09-26 時点の整理）。
しすてむせっけい／System Design
要件を満たすために、システムをどんな部品に分け、部品どうしをどうつなぐかを決める工程のことです。
最終更新: 2026-09-26
システム設計とは（意味と読み方）
システム設計（しすてむせっけい）とは、要件定義で決めた条件を満たすために、システムをどんな部品に分け、部品どうしをどうつなぐかを決める工程です。英語では System Design と呼ばれます。
要件定義が「何を満たすか」を決める工程なら、システム設計は「どうやって満たすか」を決める工程です。順番としては要件定義の後に来ます。
IPAの共通フレーム2013は、開発の作業項目を整理した共通の枠組みで、システム開発とソフトウェア開発を明確に分けた点を特徴に挙げています。システム全体をどう組むかを決めてから、その中のソフトウェアを作り込む、という順番です。
システム設計で決める4つのこと
| 決めること | 問いの例 |
|---|---|
| 部品の構成 | 画面・処理・保存をそれぞれどこに置くか |
| データの形 | 何を、どんな項目と型で保存するか |
| 部品の間のやりとり | 画面と処理の間で、何をどの形式で受け渡すか |
| 品質の作り込み | 止まったとき、混み合ったとき、不正な入力が来たときにどうするか |
どれにも唯一の正解はなく、選ぶたびに得るものと手放すものがあります。AWS Well-Architected フレームワークは、クラウド上のシステムについて設計判断の長所と短所を理解するための枠組みで、信頼性・安全性・効率・費用対効果・持続可能性という観点から設計を見直す問いを並べています。
設計を図にするときは、粗い図から細かい図へ段階を下りていく描き方が分かりやすくなります。Simon Brown が考案したC4モデルは、ソフトウェアシステム・コンテナ・コンポーネント・コードという4段の抽象度で構成を描く方法です。
AI開発でのシステム設計の具体例
家族で共有する買い物リストを作る場面で考えます。実装を頼む前に、docs/design.md に設計の判断を数行ずつ書きます。
- 構成：画面はブラウザで動く1ページ、保存はサーバー側のデータベースに置く
- データの形：
items(id, name, done, updated_at)の1表だけにする - やりとり：画面とサーバーの間は、追加・一覧・完了の3つのAPIに限る
- 同時に編集されたとき：後から保存したほうを残す。消えた変更は今回は復元しない
そのうえでAIコーディングエージェントに「design.md に反する変更が必要になったら、実装する前に理由を書いて止まって」と伝えます。設計の判断が文章で残っていれば、エージェントがその場の都合で表を増やしたり、やりとりの形を変えたりするのを防げます。
システム設計のよくある誤解
- 誤解：設計とは図を描くこと → 実際：図は判断を伝える道具です。中心にあるのは「なぜその分け方にしたか」という判断で、図だけでは理由が残りません。
- 誤解：大きなシステムにしか要らない → 実際：規模が小さければ決めることが少ないだけで、保存先やデータの形はどんな規模でも誰かが決めています。決めずに進めると、実装の途中で成り行きに決まります。
- 誤解：AIに任せれば最適な設計になる → 実際：AIはよく見かける構成を提案するのは得意ですが、使える費用や運用に割ける手間といった前提は、伝えない限り知りません。
- 誤解：設計は一度決めたら動かさない → 実際：作りながら分かることで設計は変わります。変えたときは、何をなぜ変えたかを設計メモに追記します。
システム設計を進めるときのコツ
- 後から変えにくいものから決める：データの形と、外部とのやりとりの形は、後で変えると影響が広がります。画面の配置より先に固めます。
- 判断と理由を1行ずつ残す：「保存はサーバー側。複数の端末から見るため」のように、理由まで書きます。理由があれば、前提が変わったときに見直せます。
- 手放したものも書く：「同時編集の復元はしない」のように、選ばなかったことを書いておくと、後で不具合と取り違えずに済みます。
関連用語
関連記事
出典・参考資料
- 共通フレーム2013（IPA）：開発のライフサイクル全体の作業項目の共通の枠組み。システム開発とソフトウェア開発の分離。
- AWS Well-Architected Framework（AWS 公式ドキュメント）：設計判断の長所と短所を見直すための枠組み。
- The C4 model（考案者による公式サイト）：4段の抽象度でソフトウェアの構成を描く方法。
よくある質問
Q1. システム設計とは何ですか？
要件定義で決めた条件を満たすために、システムをどんな部品に分け、部品どうしをどうつなぐかを決める工程です。要件定義が「何を」、システム設計が「どうやって」を受け持ちます。
Q2. 要件定義とシステム設計の違いは何ですか？
要件定義は、システムが満たすべき条件を決めて合意する工程です。システム設計は、その条件を満たすための部品の分け方、データの形、部品の間のやりとりを決める工程で、要件定義の後に行います。
Q3. 個人開発でもシステム設計は必要ですか？
大がかりな設計書は要りませんが、保存先やデータの形は規模に関係なく誰かが決めることになります。数行の設計メモに判断と理由を書いておくだけでも、後からの作り直しを減らせます。
Q4. AIコーディングエージェントに設計を任せてもよいですか？
構成案を出させて比べる使い方は有効です。ただし費用や運用の手間といった前提は伝えない限り反映されないため、案を選んで設計メモに残すところは人が行います。