対象試験と出題頻度
内部設計（詳細設計）は、ITパスポート・基本情報技術者・応用情報技術者で出題されるテーマです。
ソフトウェア開発工程の中でも、外部設計との違いを問う形式で繰り返し出題される定番論点です。
「誰が読む設計書か」「何を決めるか」を正確に区別できるかが得点の分かれ目になります。
詳細をクリックして確認
ITパスポート
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
情報処理試験を勉強していると、「内部設計と外部設計って結局何が違うの？」と混乱しがちです。名前が似ている上に、参考書によって表現が微妙に違うので余計に厄介です。
内部設計（詳細設計／Internal Design）とは、一言で言うと
「外部設計で決めた仕様を、プログラマがコードを書ける粒度まで分解する開発工程」
のことです。
イメージとしては、「家を建てるときの内部構造図」です。
外部設計は施主に見せる「完成イメージのパース図」、つまり外観や部屋の配置を決めるものです。
一方の内部設計は、大工さんが実際に作業するための「柱の太さ・配線の通り道・水道管の経路」を描いた図面に相当します。施主は見ませんが、これがないと家は建ちません。
📊 内部設計の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Internal Design / Detailed Design |
| 別名 | 詳細設計、ソフトウェア詳細設計 |
| 視点 | 開発者（プログラマ）視点 |
| 位置づけ | 外部設計の後、プログラミングの前 |
| 対応するテスト | 結合テスト（V字モデル） |
解説
システム開発は、いきなりコードを書き始めるわけではありません。要件定義で「何を作るか」を決め、外部設計で「利用者から見てどう動くか」を決め、その後にようやく内部設計で「中身をどう作るか」を決めます。
この段階の主役は開発者です。画面や帳票、データベースといった外側の仕様はすでに固まっているので、それを実現するためのプログラム構造を組み立てるフェーズになります。
開発工程の中での位置づけ
内部設計が開発工程のどこに位置するかを、V字モデルで確認します。V字モデルとは、ウォーターフォール型の開発工程をアルファベットの「V」の形に並べた考え方で、左半分が上流から下流へ向かう設計・実装工程、右半分が下流から上流へ戻るテスト工程を表します。
V字の最大の特徴は、同じ高さに置かれた左右の工程が対応関係にあるという点です。「ある工程で決めたこと・作ったものは、対になるテスト工程で検証する」というルールが図の形に表れています。下の図で、内部設計（左）と結合テスト（右）が同じ高さに並んでいることに注目してください。
V字モデル：内部設計の位置
▲ 同じ高さの工程同士が対応する。内部設計の成果物（モジュール仕様）は結合テストで検証される
図の見方を上から順に整理すると、要件定義で決めた「業務上やりたいこと」は最終的に受入テストで発注者が確認します。
外部設計で決めた「画面や機能の振る舞い」はシステムテストで全体動作として検証されます。
内部設計で決めた「モジュール同士の連携」は結合テストで検証され、最後にプログラミングで作った個々のモジュールが単体テストで検証される、という対応関係になります。
この対応関係を理解しておくと、「内部設計の成果物が何のために必要なのか」が腹落ちします。
内部設計でモジュール分割と内部インタフェースを明確にしておかないと、結合テストの観点（どのモジュール同士をどう繋いで動作確認するか）が決まらないからです。
試験でも「内部設計と対応するテスト工程はどれか」という問い方で頻繁に出題されます。
外部設計との違い
試験で最も問われるのが、外部設計と内部設計の役割分担です。「視点」と「成果物」で整理すると一発で区別できます。
| 観点 | 外部設計 | 内部設計 |
|---|---|---|
| 視点 | 利用者（ユーザ）視点 | 開発者（プログラマ）視点 |
| 決めること | 画面レイアウト、帳票、データの入出力、機能の振る舞い | モジュール分割、データ構造、アルゴリズム、内部の処理ロジック |
| 読み手 | 発注者・利用部門 | プログラマ |
| 主な成果物 | 画面設計書、帳票設計書、論理データ設計書 | モジュール設計書、物理データ設計書、プログラム構造図 |
| 別名 | 基本設計、ソフトウェア方式設計 | 詳細設計、ソフトウェア詳細設計 |
| 対応するテスト | システムテスト | 結合テスト |
内部設計で決める4つの中身
内部設計で具体的に何を決めるのかを、4つの観点で押さえます。
① モジュール分割
プログラムを機能単位の小さな部品（モジュール）に分割する。STS分割・TR分割・共通機能分割などの手法を使い、独立性を高める。
② 物理データ設計
外部設計の論理データ設計を、実際のDBMSに合わせて物理的な形（テーブル定義、インデックス、データ型）に落とし込む。
③ アルゴリズム設計
各モジュール内部の処理手順を決める。フローチャート・擬似コード（PAD・NSチャート等）で具体化する。
④ 内部インタフェース設計
モジュール同士のやり取り（引数・戻り値・呼び出し関係）を定義する。プログラム間の境界をはっきりさせる。
モジュール分割の評価指標：強度と結合度
モジュール分割の良し悪しは、「モジュール強度（凝集度）」と「モジュール結合度」という2つの指標で評価します。
良いモジュール分割の原則
モジュール強度：高いほど良い（モジュール内部の機能のまとまりが強い）
弱 → 暗号的 ＜ 論理的 ＜ 時間的 ＜ 手順的 ＜ 連絡的 ＜ 情報的 ＜ 機能的 ← 強
モジュール結合度：低いほど良い（モジュール同士の依存が弱い）
強 → 内容 ＜ 共通 ＜ 外部 ＜ 制御 ＜ スタンプ ＜ データ ← 弱
強度と結合度の詳細は別記事で扱うため、ここでは「強度は高く、結合度は低くするのが理想」という結論だけ押さえれば十分です。
💡 内部設計の核心を3行で
・外部設計の仕様を「プログラマがコードを書ける粒度」まで分解する開発工程
・決めるのはモジュール分割・物理データ設計・アルゴリズム・内部インタフェース
・V字モデルでは結合テストと対応する（個々のモジュールは単体テストで検証）
では、この用語が試験でどのように出題されるか見ていきましょう。
試験ではこう出る！
内部設計は、IPの午前、FE・APの午前問題で繰り返し出題される定番論点です。出題パターンは大きく3つに分類できます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H30秋 午前 問46 |
ソフトウェア詳細設計で行う作業を選ぶ問題。 | ・「コンポーネントを単体テストできるレベルまで分解する」が正解 ・要件定義・方式設計の作業がひっかけ |
| AP R元秋 午前 問46 |
ソフトウェア詳細設計の成果物として適切なものを問う問題。 | ・モジュール仕様書が正解 ・画面遷移図・業務フローは外部設計の成果物 |
| IP R5 問42 |
外部設計と内部設計の作業内容の違いを問う問題。 | ・利用者視点＝外部設計、開発者視点＝内部設計 ・モジュール分割は内部設計に該当 |
| FE H29春 午前 問47 |
モジュール強度（凝集度）が最も高いものを選ぶ問題。 | ・機能的強度が最高 ・暗号的・論理的強度がひっかけ |
📝 IPA試験での出題パターン
パターン1：「詳細設計の作業内容を選べ」
各工程の作業内容が選択肢に並び、内部設計（詳細設計）に該当するものを選ぶ形式。キーワードは「単体テストできるレベルまで分解」「モジュール仕様の作成」。要件定義の「業務分析」、外部設計の「画面設計」がひっかけで紛れ込む。
パターン2：「外部設計と内部設計の成果物を区別せよ」
画面設計書・モジュール仕様書・業務フロー図などが並び、どれが内部設計の成果物かを選ばせる形式。「画面・帳票・業務」は外部、「モジュール・物理データ・アルゴリズム」は内部、と機械的に判定できる。
パターン3：「モジュール強度・結合度の順序」
強度の最高は「機能的」、結合度の最弱（最良）は「データ結合」と覚える。順序を逆に書いた選択肢が定番のひっかけ。
用語の揺れに注意してください。「内部設計」「詳細設計」「ソフトウェア詳細設計」は同じ工程を指します。共通フレーム（SLCP）では「ソフトウェア詳細設計」と表記されるため、試験ではこの呼び方も出ます。また、V字モデルでの対応関係は「内部設計↔結合テスト」「プログラミング↔単体テスト」が基本ですが、参考書によっては「内部設計↔単体テスト」と簡略化された4段モデルで描かれることもあります。試験では問題文の選択肢に合わせて柔軟に判断してください。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. 内部設計（詳細設計）の説明として、最も適切なものはどれでしょうか？
- A. 外部設計で決めた仕様を基に、モジュール分割・物理データ設計・アルゴリズムなど、プログラマがコードを書けるレベルまで具体化する開発工程である。
- B. 利用者視点で画面レイアウトや帳票、機能の振る舞いを決め、発注者と仕様を合意するための開発工程である。
- C. システム化の目的・対象範囲・業務要件を整理し、何を作るかを発注者と合意するための開発工程である。
正解と解説を見る
正解：A
解説：
内部設計は外部設計で固めた仕様を受け取り、モジュール分割・物理データ設計・アルゴリズム設計・内部インタフェース設計を行う開発者視点の工程です。コードを書ける粒度まで具体化することがゴールであり、V字モデルでは結合テストと対応します。
選択肢Bは外部設計（基本設計）の説明です。利用者視点で画面・帳票・機能の振る舞いを決めるのは外部設計の役割であり、内部設計とは視点も成果物も異なります。選択肢Cは要件定義の説明です。「何を作るか」を発注者と合意する工程は要件定義であり、設計工程よりも前段階に位置します。
よくある質問（FAQ）
Q. 「内部設計」と「詳細設計」と「ソフトウェア詳細設計」は同じ意味ですか？
同じ工程を指します。歴史的経緯で呼び方が複数あり、古くからの開発現場では「内部設計」、ウォーターフォール文脈では「詳細設計」、共通フレーム（SLCP-JCF）では「ソフトウェア詳細設計」と表現されます。試験では問題文の言い回しに合わせて読み替えれば問題ありません。なお、共通フレームでは外部設計を「ソフトウェア方式設計」と呼ぶ点もセットで覚えておくと得点源になります。
Q. アジャイル開発でも内部設計はやりますか？
行いますが、ウォーターフォールほど厳密に文書化しません。アジャイルでは「動くソフトウェアを優先」する原則のもと、設計は最小限のドキュメントとコード自体（自己文書化されたコード）で表現します。モジュール分割やデータ構造の決定は当然行いますが、専用の設計書を作る代わりにペアプログラミングやコードレビューで知識を共有するチームが多数派です。試験ではウォーターフォールを前提とした出題が中心なので、アジャイル文脈は参考程度で十分です。
Q. プログラム設計と内部設計は違うものですか？
古い参考書では別物として扱われることがあります。かつての3層構造では「外部設計→内部設計→プログラム設計」と分かれており、内部設計でモジュール分割まで、プログラム設計でアルゴリズムや擬似コードまでを担当する考え方でした。現在のIPA試験では2層構造（外部設計＋詳細設計）が主流で、プログラム設計の作業内容は詳細設計に統合されています。試験で「プログラム設計」という選択肢が出たら、詳細設計の一部と考えれば対応できます。
Q. 設計書は誰がレビューしますか？
外部設計書は発注者・業務部門・SEがレビューし、利用者から見た仕様の妥当性を確認します。内部設計書はSEと開発リーダー、プログラマがレビュー対象で、技術的な実現性・モジュール独立性・性能要件への適合性をチェックします。発注者は通常レビューに加わりません。レビュー観点が違うことを意識すると、設計書の書き分けがしやすくなります。
Q. 内部設計の成果物の例をコードで見せてもらえますか？
擬似コード（pseudocode）の形で表現するのが代表例です。たとえば「会員ログイン処理」のモジュール仕様は次のように書きます。
MODULE: 会員ログイン処理
INPUT : ユーザID（文字列）, パスワード（文字列）
OUTPUT: 認証結果（boolean）, セッションID（文字列）
BEGIN
IF ユーザIDが未入力 OR パスワードが未入力 THEN
RETURN (false, null)
END IF
user ← DB.SELECT(ユーザマスタ, ユーザID)
IF user IS NULL THEN
RETURN (false, null)
END IF
IF HASH(パスワード) ≠ user.password_hash THEN
ログ出力（"認証失敗", ユーザID）
RETURN (false, null)
END IF
sessionId ← セッション生成()
RETURN (true, sessionId)
ENDこの粒度まで落とせば、プログラマは特定の言語に翻訳するだけでコーディングできます。これが内部設計のゴールです。
