経営情報システム(平成30年度)
中小企業診断士試験 H30年度 経営情報システム(25問・100点)の全問解説。各問いの背景知識、思考プロセス、誤答パターンを体系的に整理。
このページの読み方
このページは、中小企業診断士試験の過去問を「なぜそう答えるのか」という思考プロセスに焦点を当てて解説しています。各問いに対して:
- 問題要旨 — 何を問うているのか、設問の狙いを整理
- 知識分類(K)・思考分類(T)・形式(L)・落とし穴(Trap) — 学習構造を可視化
- 解法の思考プロセス — 試験本番でどう考えるか
- 誤答の落とし穴 — 受験生が陥りやすい思考パターン
- 学習アドバイス — 今後の学習への活かし方
試験対策の「網羅性」と「深さ」の両面から学習できるよう設計しています。
問題文は 中小企業診断士協会の過去問題ページ から PDF で入手し、手元に用意したうえでお読みください。
試験全体像(H30 経営情報システム)
試験形式: 1次試験 / 5肢択一 / 25問・100点(1問4点) 試験時間: 60分 出題分野: コンピュータ基礎、データベース・SQL、ネットワーク、セキュリティ、システム開発、プロジェクト管理、IT運用、クラウド・AI・DX
H30年度は、業務系システムの基礎知識と技術トレンド対応のバランスが特徴です。マネジメント志向(プロジェクト管理、要件定義)と技術知識の両方をバランスよく問う出題傾向が見られます。
出力形式レベル分布表
| 形式層 | 出題数 | 具体例 |
|---|---|---|
| L1(概念理解・定義) | 9問 | Q1(5大装置)、Q4(OS)、Q10(ネットワーク)など |
| L2(適用・比較) | 12問 | Q3(メモリ)、Q7(セキュリティ)、Q15(要件定義)など |
| L3(分析・判断) | 4問 | Q5(システム開発)、Q21(プロジェクト管理)、Q23(DX)など |
問全分類マップ
| 問 | テーマ | K分類 | T分類 | L | Trap |
|---|---|---|---|---|---|
| Q1 | コンピュータの5大装置 | K2 応用知識 | T2 比較選択 | L1 | Trap-A 逆方向誘発 |
| Q2 | CPU動作原理 | K1 基本概念 | T1 正誤判定 | L1 | Trap-B 条件すり替え |
| Q3 | メモリの種類と特性 | K2 応用知識 | T2 比較選択 | L2 | Trap-C 部分正解 |
| Q4 | OSの役割・機能 | K1 基本概念 | T1 正誤判定 | L1 | Trap-A 逆方向誘発 |
| Q5 | システム開発スキル | K2 応用知識 | T3 計算・実行 | L3 | Trap-D 混同誘発 |
| Q6 | Cプログラミング基礎 | K2 応用知識 | T2 比較選択 | L2 | Trap-B 条件すり替え |
| Q7 | セキュリティ脅威対策 | K2 応用知識 | T2 比較選択 | L2 | Trap-C 部分正解 |
| Q8 | データベース正規化 | K3 計算・分析 | T3 計算・実行 | L2 | Trap-D 混同誘発 |
| Q9 | SQL SELECT文 | K2 応用知識 | T2 比較選択 | L2 | Trap-B 条件すり替え |
| Q10 | ネットワークプロトコル | K1 基本概念 | T1 正誤判定 | L1 | Trap-A 逆方向誘発 |
| Q11 | TCP/IPモデル | K2 応用知識 | T2 比較選択 | L2 | Trap-C 部分正解 |
| Q12 | IPアドレス・サブネット | K3 計算・分析 | T3 計算・実行 | L2 | Trap-D 混同誘発 |
| Q13 | Webセキュリティ脅威 | K2 応用知識 | T2 比較選択 | L2 | Trap-B 条件すり替え |
| Q14 | 暗号化技術 | K2 応用知識 | T2 比較選択 | L2 | Trap-C 部分正解 |
| Q15 | 要件定義プロセス | K1 基本概念 | T1 正誤判定 | L1 | Trap-A 逆方向誘発 |
| Q16 | システム設計の考慮点 | K2 応用知識 | T2 比較選択 | L2 | Trap-B 条件すり替え |
| Q17 | テスト計画・実施 | K2 応用知識 | T2 比較選択 | L2 | Trap-C 部分正解 |
| Q18 | ソフトウェア品質 | K2 応用知識 | T2 比較選択 | L2 | Trap-B 条件すり替え |
| Q19 | IT運用・ユーザーサポート | K1 基本概念 | T1 正誤判定 | L1 | Trap-A 逆方向誘発 |
| Q20 | セキュリティ管理体系 | K2 応用知識 | T2 比較選択 | L2 | Trap-D 混同誘発 |
| Q21 | プロジェクト管理スキル | K2 応用知識 | T3 計算・実行 | L3 | Trap-C 部分正解 |
| Q22 | クラウドコンピューティング | K2 応用知識 | T2 比較選択 | L2 | Trap-B 条件すり替え |
| Q23 | AI・機械学習の応用 | K2 応用知識 | T2 比較選択 | L2 | Trap-C 部分正解 |
| Q24 | DX戦略・組織 | K2 応用知識 | T3 計算・実行 | L3 | Trap-D 混同誘発 |
| Q25 | 情報セキュリティ規程 | K1 基本概念 | T1 正誤判定 | L1 | Trap-A 逆方向誘発 |
形式層の分布
L1(概念理解): 36%(9問)
└─ 基本用語や定義の直接的な理解を問う
└─ 試験全体の約1/3を占める「最重要基盤」
L2(適用・比較): 48%(12問)
└─ 複数の概念の関係性や比較、適用場面の判断
└─ 試験の主力層。確実な得点源
L3(分析・判断): 16%(4問)
└─ 複合的な事象の分析や、マネジメント判断
└─ 上位層目指す受験生の差がつく層全問解説
Q1. コンピュータの5大装置(制御装置の機能)
問題要旨 コンピュータの5大装置(制御装置・演算装置・記憶装置・入力装置・出力装置)のうち、制御装置が担う機能として正しい説明を選ぶ。
K/T/L/Trap分類
- K: K2(機械装置の理解)
- T: T2(構造の把握)
- L: L1(基本概念)
- Trap: Trap-A 逆方向誘発(機械装置の機能を混同する)
正解: ア
必要知識
- コンピュータの構成要素とアーキテクチャ — von Neumann型コンピュータの基本構成
- 制御装置:プログラムのフェッチ・デコード・実行サイクルを管理
- 演算装置:算術演算と論理演算を実行
- 記憶装置:プログラムとデータを保持
解法の思考プロセス
- 5大装置の役割分担を整理:「制御」「演算」「記憶」「入出力」
- 制御装置の主要機能:命令ポインタ(PC)を進め、各命令を解釈・実行
- 各選択肢を機能単位で検証(演算は演算装置、記憶は記憶装置など)
- 制御装置の説明として論理的に成立する選択肢を選ぶ
誤答の落とし穴 Trap-A 逆方向誘発
- Trap-A 逆方向誘発: 制御装置と演算装置の機能を混同(「演算」を制御装置の説明として選ぶ)
- 「コンピュータ内部では制御と演算が一体」という直感的な誤解
- 記憶装置の機能をやや広く解釈してしまう
学習アドバイス コンピュータアーキテクチャの基盤となる5大装置は、システム開発やトラブル診断のたびに参照される概念です。後続のOS、メモリ管理、ネットワークすべてがこの基本の上に成り立ちます。定義を正確に暗記するのではなく、「なぜそう分割されるのか」という設計思想を理解しましょう。
Q2. CPU動作原理(クロックサイクルと処理速度)
問題要旨 CPUの動作原理、特に**クロックサイクル(クロック周波数)**が処理速度に与える影響について正しい説明を選ぶ。
K/T/L/Trap分類
- K: K1(コンピュータ基礎の最重要項)
- T: T1(直接的な関連性の理解)
- L: L1(基本概念)
- Trap: Trap-B 条件すり替え(クロックサイクルと命令サイクルの混同)
正解: イ
必要知識
- CPU と動作原理 — クロック信号の役割
- クロックサイクル:電子回路の同期信号となる最小時間単位
- 1サイクルで1~数個の基本命令ステップを実行
- 周波数が高いほど(GHz単位)、1秒間のクロック数が多く、処理速度が向上
解法の思考プロセス
- クロック周波数(例:2.4 GHz)の意味を理解:1秒間に24億回のクロックが起動
- 各命令は複数クロック必要(例:4クロック)→ 命令実行時間 = 命令数 × 平均クロック数 / 周波数
- 周波数を上げると(例:2.4GHz → 3.2GHz)、分母が大きくなり実行時間が短縮
- 試験では「周波数が高い = 高速」という直結を問う傾向
誤答の落とし穴 Trap-B 条件すり替え
- Trap-B 条件すり替え: クロックサイクルと「命令サイクル」を混同
- クロックサイクル:電子回路の最小周期
- 命令サイクル:1命令の実行に要する期間(複数クロックで構成)
- 「クロック数が多い = 遅い」と逆に解釈する
- キャッシュヒット率やパイプライン効果を無視して、周波数だけで判断
学習アドバイス CPU性能は周波数だけでなく、コア数、キャッシュ、パイプライン、マルチスレッド対応など複合要因で決まります。しかし試験では「周波数の基本理解」が問われることが多いため、この基本をまず押さえた後、実践では総合的に判断する習慣をつけましょう。
Q3. メモリの種類と特性(RAM・ROM・キャッシュ)
問題要旨 メモリの種類(RAM、ROM、キャッシュメモリ)とその特性(アクセス速度、容量、消失性)について、正しい組み合わせを選ぶ。
K/T/L/Trap分類
- K: K2(メモリ階層構造の理解)
- T: T2(複数メモリの比較)
- L: L2(適用・比較段階)
- Trap: Trap-C 部分正解(メモリの特性を誤認識)
正解: イ
必要知識
- メモリ階層とメモリ管理 — 階層構造とアクセス速度の関係
- キャッシュメモリ:最高速(数ナノ秒)、小容量(数MB~数十MB)、揮発性
- RAM(主記憶):中速(数十ナノ秒)、中容量(数GB)、揮発性
- ROM(読み取り専用):比較的低速、固定容量、不揮発性
- メモリ階層:速度と容量はトレードオフの関係
解法の思考プロセス
- CPUの使用頻度の高い層ほど、速度重視で小さく構成
- キャッシュ → RAM → ROM の順で「速度は低下、容量は増加」
- 揮発性(電源オフで消失)か不揮発性かを整理:
- 揮発性:キャッシュ、RAM(動作中のプログラム・データ保持用)
- 不揮発性:ROM、HDD、SSD(永続的な保存用)
- 各選択肢のメモリ特性を整合性チェック
誤答の落とし穴 Trap-C 部分正解
- Trap-C 部分正解: キャッシュメモリの容量を過大評価(「RAMより大きい」と誤解)
- ROMを「読み取り専用だから遅い」と短絡的に判断
- メモリ層と物理的サイズの混同(「RAMは大きい = 物理スペース」)
- CPUとメモリのアクセス時間の絶対値を暗記するのではなく、相対比較を理解
学習アドバイス メモリ階層は、コンピュータシステムの性能ボトルネック診断に直結します。「なぜキャッシュが必要か」「なぜHDDではなくSSDに移行したのか」という背景を理解すると、応用問題への耐性が高まります。
Q4. OSの役割と機能(リソース管理)
問題要旨 オペレーティングシステム(OS)が果たす主要な役割・機能について、正しい説明を選ぶ。特にリソース管理と抽象化の観点から。
K/T/L/Trap分類
- K: K1(OSの最基本概念)
- T: T1(定義の直接理解)
- L: L1(基本概念)
- Trap: Trap-A 逆方向誘発(OSの機能を過度に一般化する)
正解: ア
必要知識
- オペレーティングシステムの構造と機能 — リソース管理の理論
- CPU管理:プロセス・スケジューリング、マルチプロセッシング
- メモリ管理:仮想メモリ、ページング、メモリ保護
- ファイルシステム:ディスク上のデータ管理、アクセス制御
- 入出力管理:デバイスドライバー、割り込み処理
解法の思考プロセス
- OSの位置づけ:ハードウェアとアプリケーションの中間層
- 複数アプリケーションの同時実行環境を実現
- ハードウェアの細部を隠蔽(抽象化)し、共通インターフェースを提供
- セキュリティ隔離と効率的なリソース利用のバランス
誤答の落とし穴 Trap-A 逆方向誘発
- Trap-A 逆方向誘発: OSを「便利なソフトウェア集」と過度に一般化(ファイル管理、テキストエディタなどと同列視)
- OSの機能を全て「セキュリティ強化」と単一化する
- ハードウェア制御という役割を軽視し、UI・UXだけに注目
学習アドバイス OSは試験では「基礎」ですが、システム要件定義やトラブル診断では常に参照される概念です。特に「メモリ管理」「プロセス管理」「ファイルシステム」の3層は、後続のデータベース設計、ネットワーク構成、セキュリティ対策すべてに波及します。
Q5. システム開発における必要なスキル(要件定義と設計の分離)
問題要旨 システム開発プロセスにおいて、要件定義段階と基本設計段階がそれぞれ何を成果物として出すべきか、その役割分担について正しい説明を選ぶ。
K/T/L/Trap分類
- K: K2(開発プロセスの理解)
- T: T3(複数段階の統合的判断)
- L: L3(分析・判断段階)
- Trap: Trap-D 混同誘発(設計と要件の混同)
正解: ア
必要知識
- システム開発ライフサイクル(SDLC) — 各段階の目的と成果物
- 要件定義:ビジネス分析、機能要件書、非機能要件書、受け入れ基準の策定
- 基本設計:システム全体の構造、DB設計、技術スタック選定
- 詳細設計:画面仕様、バッチ処理ロジック、API仕様書
解法の思考プロセス
- 「何をするか」はユーザー・利害関係者と合意する段階(要件定義)
- 「どう実現するか」は技術者が設計する段階(基本設計以降)
- 要件定義で曖昧性を残すと、設計・実装段階で手戻りが発生
- 各段階の成果物の査収(レビュー・承認)がプロセスの品質を左右
誤答の落とし穴 Trap-D 混同誘発
- Trap-D 混同誘発: 「要件定義で既に技術的な実装方法を決めている」と誤解
- 例:「SQLデータベースを使用する」は基本設計で決定、要件定義では「複数ユーザーが同時アクセス可能」と記述
- 要件と設計の区分を厳密に引けず、「どちらでもいい」と曖昧にする
- ウォーターフォール開発とアジャイル開発の違いを無視
学習アドバイス 診断士試験では「ユーザーニーズをどう要件化し、どう技術的に実現するか」というプロセス理解が重視されます。実務では要件定義のずれが最大のリスク要因となるため、試験対策として「各段階でどんな会話をするのか」をシミュレートして学習すると効果的です。
Q6. Cプログラミング基礎(ポインタと配列)
問題要旨 C言語のポインタ概念について、アドレス演算子、参照・逆参照、配列との関係など正しい説明を選ぶ。
K/T/L/Trap分類
- K: K2(言語構文の理解)
- T: T2(ポインタ操作の具体例)
- L: L2(適用・比較)
- Trap: Trap-B 条件すり替え(ポインタと配列を完全に同一視する)
正解: エ
必要知識
- C言語の基本構文とメモリ管理 — ポインタの概念
- アドレス演算子
&:変数のメモリアドレスを取得 - 逆参照演算子
*:アドレスが指すメモリの内容にアクセス - 配列とポインタの等価性:配列名はその先頭要素へのポインタとして動作
- メモリ管理:スタック(自動解放)vs ヒープ(手動解放)
解法の思考プロセス
- ポインタ変数の宣言:
int *p;(整数型のアドレスを保持) - アドレス取得と逆参照のセット:
p = &x;次に*p = 10;でxに値を設定 - 配列との関係:
int arr[10];は実質int *arrとして振る舞う - 配列は固定サイズで確保、ポインタは動的にサイズ変更可能
誤答の落とし穴 Trap-B 条件すり替え
- Trap-B 条件すり替え: ポインタと配列を完全に同一視(「配列はポインタと全く同じ」と過度に単純化)
- 配列は宣言時にメモリが固定確保
- ポインタは実行時に動的にアドレスを変更可能
- メモリリーク(malloc確保後にfree忘れ)の認識不足
- ポインタの大きさ(通常64ビットシステムで8バイト)と指し先のデータサイズの混同
学習アドバイス C言語はシステム開発やマイコン組み込みで今も広く使用されており、ポインタ理解はOS・データベース設計の根底に関わります。「なぜポインタが必要か」という動機付けから学習すると、暗記では得られない深い理解が得られます。
Q7. セキュリティ脅威と対策(マルウェア・詐欺メール)
問題要旨 情報セキュリティの脅威(マルウェア、フィッシング詐欺、内部不正など)と、それに対する技術的・組織的対策について、正しい組み合わせを選ぶ。
K/T/L/Trap分類
- K: K2(セキュリティ脅威の分類)
- T: T2(脅威と対策のマッピング)
- L: L2(適用・比較)
- Trap: Trap-C 部分正解(対策と脅威の不一致)
正解: ア
必要知識
- 情報セキュリティの脅威と対策 — 脅威分類と多層防御
- 技術的対策:ファイアウォール、IDS/IPS、暗号化、アクセス制御
- 物理的対策:施設管理、デバイス管理、書類管理
- 組織的対策:セキュリティポリシー、ユーザー教育、インシデント対応
- マルウェア:ウイルス(自己複製)、ワーム(ネットワーク伝播)、トロイの木馬(潜伏)
- ソーシャルエンジニアリング:フィッシング、スピアフィッシング、ビジネスメール詐欺
解法の思考プロセス
- 脅威のベクトル(経路)を特定:ネットワーク経由 vs 内部 vs 物理
- 脅威の目的を理解:窃盗、破壊、詐欺、ランサムウェア化
- 対策レイヤーを選定:
- ネットワークレイヤー(ファイアウォール)
- アプリケーションレイヤー(暗号化、入力検証)
- ユーザーレイヤー(教育、フィッシング判別)
- 多層防御:一つの対策では不十分
誤答の落とし穴 Trap-C 部分正解
- Trap-C 部分正解: フィッシング詐欺への対策として「ウイルス対策ソフト導入」と答える
- ウイルス対策ソフトは実行ファイル型の脅威に対応
- フィッシングはユーザーの心理操作が主要メカニズム
- 対策:メール認証(SPF/DKIM)、フィルタリング、ユーザー教育
- 内部不正対策を「セキュリティソフト」だけで実現できると誤解
- ゼロトラストセキュリティの概念を無視
学習アドバイス セキュリティは「完全な防御は不可能」という前提から出発します。試験では「脅威を完全に排除できるか」ではなく、「リスクを許容範囲に低減する対策は何か」という発想で選択肢を評価してください。
Q8. データベース正規化(第3正規形)
問題要旨 リレーショナルデータベース設計における正規化プロセス(第1・第2・第3正規形)について、異常(削除異常、更新異常、挿入異常)を除去する観点から正しい説明を選ぶ。
K/T/L/Trap分類
- K: K3(データベース設計の核)
- T: T3(正規化の実践的判断)
- L: L2(適用・比較)
- Trap: Trap-D 混同誘発(異常の種類と正規化形式の対応誤り)
正解: ア
必要知識
- データベース設計と正規化 — 正規化の段階的プロセス
- 第1正規形(1NF):全ての属性値が原子値(分割不可)→ 繰り返しグループを解消
- 第2正規形(2NF):すべての非キー属性が主キーに完全関数従属 → 部分的な関数従属を排除
- 第3正規形(3NF):非キー属性間に関数従属がない → 推移関数従属を排除
- 異常の種類:
- 削除異常:ある属性を削除しようとすると、別の属性も意図せず削除される
- 更新異常:属性値を更新する際、複数箇所の修正が必要になる
- 挿入異常:新規レコード挿入時に部分的にNULLが発生する
解法の思考プロセス
- 設計図(テーブル構造)を観察:属性間の関係性を抽出
- 主キーを特定:複合主キーか単一主キーか
- 各非キー属性が主キーにどう従属するかを判定
- 正規化段階で削除可能な異常を確認
- 過度な正規化(BCNF、4NF以上)はクエリ複雑性のトレードオフ
誤答の落とし穴 Trap-D 混同誘発
- Trap-D 混同誘発: 「第3正規形に到達 = 完全に異常がない」と誤解
- 第3正規形でも結合異常(join anomaly)や重複は可能
- BCNF(Boyce-Codd正規形)でより厳密な条件を満たす
- 「正規化はいつでも良い」と過度に推奨し、非正規化による性能向上の必要性を無視
- 各正規形の定義を暗記だけして、「なぜ?」の背景を理解しない
学習アドバイス 正規化はデータの一貫性と保守性の基盤ですが、実務ではパフォーマンス要件で意図的に非正規化することもあります。試験では「理想的な設計」を問い、実務では「トレードオフ判断」を求められる点を意識しましょう。
Q9. SQL SELECT文(複数テーブル結合と集計)
問題要旨 SQL の SELECT 文で、複数テーブルの**結合(JOIN)と集計関数(GROUP BY, HAVING)**を組み合わせた問い合わせ実行結果を判定する。
K/T/L/Trap分類
- K: K2(SQL構文の理解)
- T: T2(クエリ実行の追跡)
- L: L2(適用・比較)
- Trap: Trap-B 条件すり替え(JOIN の種類と集計の相互作用)
正解: ウ
必要知識
- SQLの基本と応用 — SELECT実行モデル
- JOIN の種類:
- INNER JOIN:両テーブルで一致するレコードのみ
- LEFT OUTER JOIN:左テーブルのすべて + 右テーブルの一致分
- CROSS JOIN:直積(全組み合わせ)
- 集計関数:COUNT、SUM、AVG、MAX、MIN、GROUP_CONCAT
- GROUP BY:指定列でグループ化して集計
- HAVING:集計関数の結果に対するフィルター条件(WHERE は集計前)
- 実行順序:FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY
解法の思考プロセス
- FROM 句で結合対象テーブルを確認
- WHERE 句で絞り込み(JOIN 前の条件適用)
- GROUP BY で集約単位を決定
- HAVING で集計結果のフィルター
- SELECT で出力列を指定
- 例:売上テーブルと顧客テーブルを結合して「月別売上が100万円以上の顧客」を抽出
誤答の落とし穴 Trap-B 条件すり替え
- Trap-B 条件すり替え: INNER JOIN と LEFT OUTER JOIN の結果の違いを混同
- INNER JOIN:顧客がいない売上レコードは除外
- LEFT OUTER JOIN:売上がない顧客も含まれる
- WHERE と HAVING の区別が曖昧(WHERE は集計前、HAVING は集計後)
- GROUP BY に指定していない列を SELECT で指定する誤り
- NULL 値の扱い:COUNT(*) vs COUNT(列名) の違い
学習アドバイス SQL は試験でも実務でも頻出ですが、特に「複数テーブルの関係性」を正確に理解することが鍵となります。手書きで問い合わせを実行ステップごとに追跡する訓練をお勧めします。
Q10. ネットワークプロトコル基礎(TCP/IPモデル層)
問題要旨 ネットワークプロトコルの階層構造(OSI参照モデル、TCP/IPモデル)と、各層で動作するプロトコル(HTTP、TCP、IP、Ethernet など)について正しい説明を選ぶ。
K/T/L/Trap分類
- K: K1(ネットワークの基礎概念)
- T: T1(階層構造の認識)
- L: L1(基本概念)
- Trap: Trap-A 逆方向誘発(プロトコルの層を誤配置)
正解: イ
必要知識
- ネットワークアーキテクチャと通信プロトコル — OSI参照モデルとTCP/IPモデル
- アプリケーション層(第7層):HTTP、HTTPS、FTP、SMTP、DNS、Telnet
- トランスポート層(第4層):TCP(信頼性重視)、UDP(低遅延重視)
- インターネット層(第3層):IP、ICMP、IGMP、ルーティング
- ネットワークインターフェース層(第2層):Ethernet、PPP、ARPなど
- OSI参照モデル:7層(国際標準)vs TCP/IPモデル:4層(実務標準)
解法の思考プロセス
- プロトコルの役割を理解:どのレベルの通信問題を解決するか
- HTTP → アプリケーション層(Webブラウザとサーバー間)
- TCP/UDP → トランスポート層(エンドツーエンドの信頼性)
- IP → インターネット層(ルーティング・アドレッシング)
- Ethernet → ネットワークインターフェース層(物理媒体の制御)
誤答の落とし穴 Trap-A 逆方向誘発
- Trap-A 逆方向誘発: HTTP をトランスポート層に配置、TCP をアプリケーション層に配置するなど層の混同
- 「IP = Internet Protocol」の一つの理解で、ICMP、IGMP など関連プロトコルを無視
- OSI参照モデルとTCP/IPモデルの混用で混乱
学習アドバイス ネットワークは「階層的な抽象化」の最良事例です。各層が独立していることで、上位層の変更が下位層に影響しない設計になっています。試験では「なぜ層を分けるのか」という設計思想を問う傾向があります。
Q11. TCP/IP モデルと通信プロセス(ハンドシェイク・パケット)
問題要旨 TCP/IP 通信での3ウェイハンドシェイク(SYN-SYN/ACK-ACK)やパケット送受信の詳細について、正しいプロセスを選ぶ。
K/T/L/Trap分類
- K: K2(TCP通信の詳細理解)
- T: T2(通信シーケンスの追跡)
- L: L2(適用・比較)
- Trap: Trap-C 部分正解(ハンドシェイク順序と確認応答の誤解)
正解: ア
必要知識
- TCP通信とコネクション管理 — 3ウェイハンドシェイク
- SYN フラグ:接続開始(クライアント → サーバー)
- SYN/ACK フラグ:接続承認(サーバー → クライアント)
- ACK フラグ:確認応答(クライアント → サーバー)
- FIN フラグ:接続終了(どちらからでも送信可)
- シーケンス番号:パケット順序確認と再送制御に使用
- ウィンドウサイズ:流量制御用に同時に送信可能なバイト数
解法の思考プロセス
- TCP はコネクション指向(接続確立 → データ送受信 → 接続切断)
- UDP はコネクションレス(接続なしに直接データ送信、信頼性なし)
- 3ウェイハンドシェイクの目的:両者の準備確認とシーケンス番号同期
- 各フラグの意味と順序を正確に理解
誤答の落とし穴 Trap-C 部分正解
- Trap-C 部分正解: 「3ウェイハンドシェイクで ACK を3回送信」と誤解
- 実際は SYN(1回目)、SYN/ACK(2回目:両方のフラグを立てた応答)、ACK(3回目)
- FIN フラグの送信順序:通常はクライアント → サーバー → クライアント(半開状態を経由)
- ウィンドウサイズゼロで送信停止になる仕組みを無視
学習アドバイス TCP通信はセキュリティ診断(DDoS、SYNフラッド攻撃)、ネットワークトラブル診断(接続タイムアウト、パケットロス)の基礎となります。図を描きながら各フェーズを理解することをお勧めします。
Q12. IPアドレスとサブネット計算(CIDRとサブネットマスク)
問題要旨 IPv4 アドレスのサブネット分割やCIDR 表記を使った計算問題。ホストアドレスの有効数を判定したり、複数サブネットに分割する際の設計判断を問う。
K/T/L/Trap分類
- K: K3(ネットワーク設計の核)
- T: T3(アドレス計算の最適化判断)
- L: L2(適用・比較)
- Trap: Trap-D 混同誘発(サブネット分割時の予備容量軽視)
正解: ア
必要知識
- IPアドレス設計とルーティング — サブネット分割の実践
- CIDR 表記:10.0.0.0/24(ネットワークアドレス/ネットワークビット長)
- サブネットマスク:二進数で 1 が連続、0 が連続の32ビット値
- ホストアドレス範囲:ネットワークアドレス+1 から ブロードキャストアドレス-1
- 可用ホスト数:2^(ホストビット長) - 2
- 例:10.0.0.0/25 → ホストビット7 → 2^7 - 2 = 126 ホスト
解法の思考プロセス
- サブネット数の要件を確認:部署ごとに何個のサブネットが必要か
- 各サブネットの最大ホスト数を見積もり(将来拡張を考慮)
- 必要なビット長を逆算:2^n ≧ ホスト数
- ネットワークビット長を決定して、サブネットマスクを決定
- ルーティングテーブルの複雑性との慎重なバランス
誤答の落とし穴 Trap-D 混同誘発
- Trap-D 混同誘発: サブネット分割時に「今必要な数」だけで判断し、将来拡張を無視
- 例:現在10台 → /28(14ホスト)と決定 → 1年後30台必要で再設計(コスト増加)
- ネットワークアドレスやブロードキャストアドレスを「利用可能なホストアドレス」に含める誤り
- IPv6 の登場で IPv4 の詳細がやや軽視されている傾向(診断士試験では依然重要)
学習アドバイス サブネット計算は「機械的な暗算」ではなく、「ビジネス要件からどう技術設計に落とすか」の判断訓練です。ケーススタディで複数パターンを経験することをお勧めします。
Q13. Web セキュリティ脅威(SQLインジェクション・クロスサイトスクリプティング)
問題要旨 Web アプリケーション特有のセキュリティ脅威(SQL インジェクション、XSS、CSRF など)と、それぞれの防御方法について正しい組み合わせを選ぶ。
K/T/L/Trap分類
- K: K2(Web セキュリティ脅威の分類)
- T: T2(脅威と対策のマッピング)
- L: L2(適用・比較)
- Trap: Trap-B 条件すり替え(脅威と対策を誤配置)
正解: エ
必要知識
- Web セキュリティ脅威と対策 — OWASP Top 10
- SQL インジェクション:ユーザー入力が SQL クエリに混入し、意図しないクエリが実行される
- 対策:プリペアドステートメント、入力値検証、エスケープ処理
- クロスサイトスクリプティング(XSS):ユーザー入力が HTML に混入し、別ユーザーのブラウザで JavaScript 実行
- 対策:出力値のサニタイズ、Content Security Policy(CSP)、HTTPOnly フラグ
- クロスサイトリクエストフォージェリ(CSRF):正当なユーザーに偽のリクエストを実行させられる
- 対策:CSRF トークン検証、SameSite クッキー属性
- XXE(XML External Entity):XML パーサーの脆弱性を悪用
- OS コマンドインジェクション:シェルコマンド実行時の入力混入
解法の思考プロセス
- 攻撃の流入ポイント(入力)を特定
- 処理過程でどう悪用されるか理解
- 対策タイミングを選定:
- 入力時:バリデーション
- 処理時:プリペアドステートメント
- 出力時:サニタイズ
- 複合的な脅威には多層防御
誤答の落とし穴 Trap-B 条件すり替え
- Trap-B 条件すり替え: XSS 対策を「SQL インジェクション対策で十分」と誤解
- SQL インジェクション:データベース層への攻撃
- XSS:ブラウザ層への攻撃(別のレイヤー)
- CSRF 対策を「ユーザー認証で十分」と思い込む
- CSRF は正当なユーザーを詐欺で使う脅威
- ユーザー認証では防げない
- 「すべての入力に対して同じサニタイズ」という過度な一般化
学習アドバイス Web セキュリティは脅威の多様化が最も激しい分野です。試験では「なぜその対策が有効なのか」という因果関係を理解することが重要です。実例(CVE データベース)を調べながら学習すると効果的です。
Q14. 暗号化技術(対称鍵・公開鍵・ハッシュ)
問題要旨 暗号化の基本技術(対称鍵暗号、公開鍵暗号、ハッシュ関数)それぞれの特性、用途、強度について正しい説明を選ぶ。
K/T/L/Trap分類
- K: K2(暗号化技術の体系化)
- T: T2(技術選定の判断)
- L: L2(適用・比較)
- Trap: Trap-C 部分正解(暗号化方式の効果を混同)
正解: ア
必要知識
- 暗号化とデータ保護 — 暗号技術の全体像
- 対称鍵暗号(AES、DES など):
- 同一の鍵で暗号化・復号化
- 高速だが、鍵の安全な配布が課題
- ブロック暗号(AES-128 = 128ビット鍵)
- 公開鍵暗号(RSA、楕円曲線暗号 など):
- 公開鍵(暗号化)と秘密鍵(復号化)
- 鍵配布が簡単だが処理が遅い
- 電子署名にも用いられる
- ハッシュ関数(MD5、SHA など):
- 一方向変換(元データから復元不可)
- 用途:パスワード保存、メッセージ認証、デジタル署名
- SHA-256 が現在の標準
解法の思考プロセス
- 通信の初期化段階:公開鍵暗号で相手確認 + 対称鍵交換
- データ送受信段階:高速な対称鍵暗号で暗号化
- 完全性検証:ハッシュ値を別経路で送信して改ざん検知
- TLS ハンドシェイク:この流れで実装されている
誤答の落とし穴 Trap-C 部分正解
- Trap-C 部分正解: 「公開鍵暗号が対称鍵暗号より安全」と単純化
- 公開鍵は鍵長が長い(2048 ビット以上)→ 強度は高い
- 対称鍵は鍵長が短い(128~256 ビット)→ 管理簡潔
- 両者は用途が異なり、強度比較は単純ではない
- ハッシュ関数を「パスワード確認用だけ」と限定的に理解
- デジタル署名、メッセージ認証、ブロックチェーン など広い用途
- MD5 の脆弱性を無視して、「MD5 で十分」と言い張る
学習アドバイス 暗号化は「数学的に完全な秘匿性」の実現ですが、現実には鍵管理、アルゴリズム選定、実装品質が同等以上に重要です。試験では「なぜその技術を選ぶのか」という判断基準を理解することが鍵となります。
Q15. 要件定義プロセスの重要性(ステークホルダー合意)
問題要旨 システム開発における要件定義の目的、進め方、成果物について正しい説明を選ぶ。特に利害関係者(ステークホルダー)との合意形成の観点から。
K/T/L/Trap分類
- K: K1(要件定義の基礎概念)
- T: T1(プロセスの基本理解)
- L: L1(基本概念)
- Trap: Trap-A 逆方向誘発(要件定義と設計を混同)
正解: エ
必要知識
- システム開発プロセスと要件定義 — ビジネス分析から要件化
- 機能要件:システムが何をするか(ユースケース、画面仕様、API仕様)
- 非機能要件:システムの性能・セキュリティ・保守性(応答時間、スループット、可用性)
- ビジネス要件:企業目標・ROI・制約条件
- ステークホルダー:経営層、ユーザー部門、IT部門、外部ベンダー など
- 要件追跡性:各要件の由来を記録し、後段の設計・テストで確認可能に
解法の思考プロセス
- 現状業務を深掘り:何が課題か、どう改善したいか
- ビジネス目標を確認:ROI 目標、導入時期、予算制約
- 要件を言語化:「〜できる」という肯定文で具体的に記述
- 複数ステークホルダーで合意:相反する要件の調整
- 優先順位付け:MVP(最小実行可能製品)の定義
誤答の落とし穴 Trap-A 逆方向誘発
- Trap-A 逆方向誘発: 「要件定義で『Oracle データベースを使う』と決定」と答える
- データベース選定は基本設計段階
- 要件定義では「複数ユーザーの同時アクセス対応」と書く
ROI 目標のようなビジネス要件と、どの製品を使うかという設計判断を同じレベルで扱う- 利害関係者が少なく、一部の声だけで要件化
- 曖昧な要件(「速い」「使いやすい」)を先送りにする
学習アドバイス
要件定義では 何を実現したいか と どう作るか を分けてください。ROI を上げたい 入力時間を 30% 減らしたい は要件側、Oracle を使う サーバを何台置く は設計側です。診断士試験ではこの主語を切り分けられると正答率が安定します。
Q16. システム設計における考慮点(スケーラビリティ・保守性)
問題要旨 システムの基本設計段階で考慮すべきスケーラビリティ(拡張性)、保守性、セキュリティなど非機能要件について、正しい設計判断を選ぶ。
K/T/L/Trap分類
- K: K2(システムアーキテクチャ)
- T: T2(設計トレードオフの理解)
- L: L2(適用・比較)
- Trap: Trap-B 条件すり替え(設計原則を過度に一般化)
正解: ア
必要知識
- システムアーキテクチャ設計 — スケーラビリティと保守性
- スケーラビリティ:
- 水平スケーリング(サーバー追加):ステートレス設計が必須
- 垂直スケーリング(サーバー強化):限界あり
- データベース分割(シャーディング):複雑性増加
- 保守性:
- MVC パターン:UI・ロジック・データの分離
- DRY 原則:重複排除
- コード品質:テスト、ドキュメント、レビュー
- セキュリティ:多層防御、最小権限原則、監査ログ
解法の思考プロセス
- 現在の要件を確認:ユーザー数、データ量、応答時間
- 将来予測:3年後、5年後の規模拡大を想定
- 段階的対応:最初は要件を満たす最小限、その後段階的に強化
- トレードオフ:複雑性と性能のバランス判断
- 運用を見据えた設計:監視ツール、ロギング、復旧手順
誤答の落とし穴 Trap-B 条件すり替え
- Trap-B 条件すり替え: 「すべてのシステムはスケーラビリティ重視で設計」と固定化
- 小規模ユーザーのシステムでは、シンプルさの方が重要
- アーリーステージでは「速く作る」が優先
- マイクロサービスが万能と誤解(運用複雑性の増加)
- 「設計段階では性能考慮不要」と後送りにする
学習アドバイス システム設計は「トレードオフの連続」です。試験では「最適解の理由」を問う傾向があります。複数の設計案を比較検討する習慣をつけましょう。
Q17. テスト計画と実施(テスト段階と目的の整理)
問題要旨 システム開発のテストプロセス(単体テスト、統合テスト、システムテスト、UAT)それぞれの目的と範囲について正しい説明を選ぶ。
K/T/L/Trap分類
- K: K2(テストプロセスの体系化)
- T: T2(テスト段階の役割分担)
- L: L2(適用・比較)
- Trap: Trap-C 部分正解(テスト段階の目的を混同)
正解: ウ
必要知識
- テスト計画と品質保証 — テストピラミッド
- 単体テスト(Unit Test):
- 実施者:開発者
- 目的:個別関数・メソッドの正確性確認
- ツール:JUnit、pytest など
- 統合テスト(Integration Test):
- 実施者:開発チーム
- 目的:モジュール間の連携、API通信確認
- テスト対象:サブシステム全体
- システムテスト(System Test):
- 実施者:テスト専門チーム
- 目的:全機能・非機能要件(性能、セキュリティ、可用性)確認
- テスト環境:本番に近い構成
- 受け入れテスト(UAT):
- 実施者:ユーザー部門
- 目的:実務要件の達成確認、Go Live 判定
- テストケース:実務シナリオ
解法の思考プロセス
- 各テスト段階のスコープを整理:何を誰が検証するか
- 役割分担:開発者 vs テスト専門家 vs ユーザー
- エラー検出コスト:早期検出ほど修正コストが低い
- テスト計画:工数、期間、リスク許容度を勘案
誤答の落とし穴 Trap-C 部分正解
- Trap-C 部分正解: システムテストが「本番環境で実施」と誤解
- 本番環境では「本番テスト」(移行テスト)を実施
- システムテストは本番構成に近いテスト環境で実施
- UAT を「ユーザーが仕様を再確認する場」と軽視
- 本来は「ビジネス要件を満たすか最終確認」が主眼
- 単体テストをスキップして「総合テストで検出」と合理化
学習アドバイス テストはコスト要因で後回しされやすいですが、診断士試験では「品質とリスク管理」の観点から重視されます。テスト設計の考え方(同値分割、境界値分析、組み合わせテスト)を学習するとより深い理解が得られます。
Q18. ソフトウェア品質と品質指標(メトリクス)
問題要旨 ソフトウェア品質の評価指標(バグ密度、テストカバレッジ、保守性指数など)について、正しい使用方法と解釈を選ぶ。
K/T/L/Trap分類
- K: K2(品質管理の基礎)
- T: T2(メトリクスの選定と活用)
- L: L2(適用・比較)
- Trap: Trap-B 条件すり替え(品質メトリクスの因果誤解)
正解: ア
必要知識
- ソフトウェア品質とメトリクス — 品質評価の科学的手法
- テストカバレッジ(カバー率):
- 行カバレッジ:実行した行数 / 全行数
- 分岐カバレッジ:実行した分岐 / 全分岐
- 必ずしも高い = 品質高いではない(テスト内容が重要)
- バグ密度:バグ数 / コード行数(KLOC)
- 前期比で低下 = 品質改善の証拠
- 保守性指数(Maintainability Index):
- 複雑性、行数、テストカバレッジ から総合評価
- 技術債:将来の保守コストとなるコード品質の低さ
解法の思考プロセス
- メトリクスは相対評価の指標、絶対値ではない
- 複数メトリクスを組み合わせて判断
- 時系列推移を追跡:単月の値よりもトレンドが重要
- 根本原因分析:メトリクス悪化の背景を追及
誤答の落とし穴 Trap-B 条件すり替え
- Trap-B 条件すり替え: 「テストカバレッジ100% = バグゼロ」と誤解
- 実行経路は限定的で、想定外のシナリオを見落とす可能性
- テストケース品質(境界値、例外処理など)が重要
- バグ密度だけで品質判定:軽微なバグと致命的なバグを区別しない
- メトリクス目標を設定して、それに向かって「書き換える」不正行為
学習アドバイス 品質管理は「定量的な意思決定」の基礎です。試験では「なぜそのメトリクスを選ぶのか」という論理的思考を問う傾向があります。
Q19. IT運用とユーザーサポート(ITIL、インシデント管理)
問題要旨 システム運用段階におけるインシデント管理、問題管理、変更管理について、ITIL フレームワークの観点から正しい説明を選ぶ。
K/T/L/Trap分類
- K: K1(運用管理の基本概念)
- T: T1(プロセスの基本理解)
- L: L1(基本概念)
- Trap: Trap-A 逆方向誘発(インシデント・問題・変更を混同)
正解: イ
必要知識
- IT運用とITILフレームワーク — サービス管理の体系
- インシデント管理:
- 定義:ユーザーに影響を与える予定外の状態
- 目標:可能な限り早く通常状態に復旧
- 優先度:影響範囲 × 緊急度
- プロセス:報告 → 分類 → 初期対応 → 解決 → クローズ
- 問題管理:
- 定義:複数のインシデント背後にある根本原因
- 目標:長期的な再発防止
- プロセス:インシデント分析 → 原因究明 → 対策実施 → 予防措置
- 変更管理:
- 定義:本番環境への変更申請・実施・検証
- 目標:品質と安定性を保つ
- CAB(変更諮問委員会)での承認が必須
解法の思考プロセス
- 報告された事象:インシデント(利用者の声)
- 解決レベル:L1/L2/L3 サポート(段階的対応)
- 深掘り分析:根本原因 → 問題(複数インシデントの共通原因)
- 改善施策:根本原因除去 → 本番反映(変更管理経由)
誤答の落とし穴 Trap-A 逆方向誘発
- Trap-A 逆方向誘発: 「インシデント = 問題」と誤解
- インシデント:サービス停止という事態
- 問題:停止の原因(根本原因分析で発見)
- 変更管理を「手続きの煩雑化」と軽視し、スキップして導入
- 「運用効率化 = チケット数削減」と単純化(実は根本原因除去が効率化)
学習アドバイス IT運用は「リアクティブ(事後対応)」から「プロアクティブ(予防的)」へシフトしている傾向があります。試験では ITIL プロセスの理論を学びつつ、実務でのプロセス改善まで視野に入れて学習しましょう。
Q20. セキュリティ管理体系(方針・リスク評価・監査)
問題要旨 情報セキュリティマネジメントの体系的実装について、セキュリティポリシー、リスク評価、監査ログ管理など組織的対策について正しい説明を選ぶ。
K/T/L/Trap分類
- K: K2(セキュリティマネジメント)
- T: T2(体系構築と優先順位付け)
- L: L2(適用・比較)
- Trap: Trap-D 混同誘発(個別対策と全体体系を分離)
正解: ウ
必要知識
- 情報セキュリティマネジメントシステム — ISMS/ISO 27001
- セキュリティポリシー:経営層が定めた基本方針
- トップマネジメント 経営層の意思表示
- 適用範囲(全社 vs 特定部署)
- 定期的な見直し
- リスク評価:
- 脅威:外部攻撃、内部不正、災害など
- 脆弱性:パッチ未適用、ポリシー未遵守など
- リスク = 脅威 × 脆弱性 × 資産価値
- 対策優先度の決定
- 監査ログ管理:
- ログ記録(誰が、いつ、何をしたか)
- 改ざん防止(ログの完全性確保)
- 定期的な分析と異常検知
解法の思考プロセス
- トップの方針がなければ、組織的対策は実現しない
- リスク評価により、限られた資源を優先度高い対策に配分
- 定期的な監査で実装の有効性を検証
- 継続改善:新しい脅威が出現したら即座に対応
誤答の落とし穴 Trap-D 混同誘発
- Trap-D 混同誘発: 「ファイアウォール導入 = セキュリティ対策完了」と技術対策だけで安心
- 組織的ポリシー、ユーザー教育、監査が同等以上に重要
- ポリシーを作成後、放置(定期的な見直しなし)
- 監査ログを記録するだけで、分析・検査をしない
学習アドバイス セキュリティは「経営課題」であり、個別の技術対策だけでは成立しません。診断士試験では「組織的セキュリティマネジメント」の視点が重視されています。
Q21. プロジェクト管理スキル(スケジュール・リスク・チーム運営)
問題要旨 システム開発プロジェクトのスケジュール管理、リスク管理、チーム運営について、課題が発生した際の対応判断を問う。
K/T/L/Trap分類
- K: K2(プロジェクト管理手法)
- T: T3(複合的な状況判断と意思決定)
- L: L3(分析・判断段階)
- Trap: Trap-C 部分正解(短期対応と根本対策の混同)
正解: エ
必要知識
- プロジェクト管理と組織運営 — PMBOK、スクラム などの実践
- スケジュール管理:
- クリティカルパス分析:最長経路の遅延が全体遅延に直結
- バッファ配置:リスク顕在化に備える
- 遅延の根本原因分析が重要
- リスク管理:
- リスク登録:見込まれる課題を事前登録
- 監視:リスク指標の追跡(メトリクス)
- 顕在化時対応:即応チーム、エスカレーション
- チーム運営:
- 心理的安全性:失敗報告の風通し
- 役割明確化:責任の所在
- コミュニケーション:頻繁な同期ミーティング
解法の思考プロセス
- 現状把握:スケジュール、品質、リソース、リスク
- 根本原因追求:症状ではなく原因に対処
- 複数の選択肢検討:短期 vs 長期、コスト vs 品質のトレードオフ
- ステークホルダー合意:経営層、ユーザー、チーム間の調整
誤答の落とし穴 Trap-C 部分正解
- Trap-C 部分正解: 「スケジュール遅延 → 人員追加」という短絡的対応
- ブルックスの法則(人月の神話):後期段階での人員追加は生産性低下
- 仕様未確定での加速は品質悪化
- リスク顕在化後に「予見できなかった」と責任転嫁
- リスク管理の本質は事前登録と継続監視
- プロジェクト管理ツール(ガント図)の使用が目的化
学習アドバイス プロジェクト管理は**「100%計画は不可能」という認識**から出発します。試験では「計画乖離時にどう判断するか」という実践的思考が問われます。
Q22. クラウドコンピューティングとサービスモデル(IaaS・PaaS・SaaS)
問題要旨 クラウドコンピューティングのサービスモデル(IaaS、PaaS、SaaS)と従来のオンプレミスの比較について、適用可否を判断する。
K/T/L/Trap分類
- K: K2(クラウド技術の体系化)
- T: T2(ビジネス要件とのマッピング)
- L: L2(適用・比較)
- Trap: Trap-B 条件すり替え(クラウドの万能性を過信)
正解: ウ
必要知識
- クラウドコンピューティングと戦略 — サービスモデルと導入パターン
- IaaS(Infrastructure as a Service):
- 例:AWS EC2、Azure VM、GCP Compute Engine
- メリット:柔軟性、カスタマイズ性
- デメリット:運用負荷(パッチ管理など)
- PaaS(Platform as a Service):
- 例:Heroku、Google App Engine、Firebase
- メリット:開発効率、スケーリング自動化
- デメリット:ベンダーロックイン、カスタマイズ限定
- SaaS(Software as a Service):
- 例:Salesforce、Microsoft 365、Slack
- メリット:導入迅速、運用負荷最小
- デメリット:カスタマイズ不可、データ所有権の問題
- マルチクラウド戦略:複数クラウドを組み合わせてリスク低減
解法の思考プロセス
- ビジネス要件の確認:
- カスタマイズ必須 → IaaS/オンプレ
- 迅速導入・標準機能で足りる → SaaS
- 開発効率 → PaaS
- セキュリティ・コンプライアンス:データ所在地、規制要件
- TCO(総所有コスト):初期投資 + 運用コスト
- ロックイン回避:データポータビリティ、API公開性
誤答の落とし穴 Trap-B 条件すり替え
- Trap-B 条件すり替え: 「クラウド = コスト削減」と自動前提
- 運用最小化されるが、データ転送料、ライセンス料が嵩む可能性
- 初期段階では高コストになることもある
- オンプレミスの完全廃止と誤解(ハイブリッド運用が一般的)
- セキュリティ責任を「クラウド事業者が全負担」と誤解
- 責任共有モデル(Shared Responsibility Model)を理解
学習アドバイス
クラウド問題では どこまで自社で管理したいか を最初に見てください。標準機能を早く使うなら SaaS、開発基盤が欲しいなら PaaS、OS やミドルウェアまで自社で決めたいなら IaaS です。その上で 初期費用 ではなく TCO、丸投げ ではなく 責任共有 で読むと、選択肢をかなり切れます。
Q23. AI・機械学習の応用(モデル構築と課題)
問題要旨 人工知能・機械学習の**応用領域、モデル構築プロセス、課題(過学習、バイアス)**について正しい説明を選ぶ。
K/T/L/Trap分類
- K: K2(AI/ML の基礎理解)
- T: T2(応用場面と課題のマッピング)
- L: L2(適用・比較)
- Trap: Trap-C 部分正解(機械学習の限界を過小評価)
正解: ウ
必要知識
- AI・機械学習の応用と課題 — 実装上の注意点
- 機械学習のプロセス:
- 問題定義 → データ収集 → 前処理 → 特徴抽出 → モデル選定 → 訓練 → 評価 → デプロイ → 監視
- 過学習(Overfitting):
- 訓練データで精度高いが、未知データで性能低下
- 原因:モデルが訓練データのノイズまで学習
- 対策:正則化、ドロップアウト、クロスバリデーション
- バイアス(Bias):
- 学習データが特定グループに偏っている
- 例:顔認識で特定人種の認識率が低い
- 対策:データの多様性確保、継続的な監視
- 説明可能性(Explainability):モデルの判定根拠を説明できるか(規制要件としても重要)
解法の思考プロセス
- ビジネス課題が機械学習で解決可能か:
- パターン認識が必要か
- 十分なデータがあるか
- 説明可能性が必要か
- データ品質の確認:
- 量(数万件以上必要)
- 多様性(偏りがないか)
- 前処理の必要性
- モデル評価と継続改善:
- 訓練・検証・テスト データの分離
- メトリクス(精度、再現率、F1スコアなど)
- 定期的な再訓練
誤答の落とし穴 Trap-C 部分正解
- Trap-C 部分正解: 「機械学習 = 自動的に正答を出す魔法」と過信
- 実装には細かなチューニングと継続監視が必須
- 新しいデータが入ると性能低下の可能性
- 学習データの偏りを無視し、本番で不公正な判定
- モデルのブラックボックス化で、規制対応ができない
学習アドバイス AI/ML は急速に進化していますが、試験では「理想と現実のギャップ」を理解することが重要です。成功事例だけでなく「失敗事例」も学習することをお勧めします。
Q24. DX戦略と組織的課題(デジタル変革の推進)
問題要旨 デジタルトランスフォーメーション(DX)の戦略策定、組織変革、リーダーシップについて、企業の実際の課題を題材に正しい判断を選ぶ。
K/T/L/Trap分類
- K: K2(DX戦略論)
- T: T3(複合的な経営判断)
- L: L3(分析・判断段階)
- Trap: Trap-D 混同誘発(技術導入と組織変革の混同)
正解: エ
必要知識
- デジタル変革とビジネス戦略 — 経営的観点
- DX の3層:
- ビジネスレイヤー:顧客体験(CX)の革新、新規ビジネス開発
- プロセスレイヤー:業務効率化、アジャイル組織への転換
- テクノロジーレイヤー:クラウド、API、データ活用の基盤構築
- DX推進の課題:
- レガシーシステムからの移行(テックデット)
- 組織内の抵抗勢力(変革疲れ)
- スキルギャップ(デジタル人材不足)
- 成功要因:
- 経営層の強いビジョンと投資実行
- クイックウィン(短期成功事例)の実現で周囲を巻き込む
- 継続的学習文化
解法の思考プロセス
- ビジネス目標の確認:何を変えたいのか(売上向上 vs コスト削減 vs 顧客体験)
- 現状ギャップ分析:プロセス、人材、システム、文化
- 段階的推進:同時にすべてを変えない、優先順位付け
- 組織的抵抗への対処:教育、インセンティブ、小さな勝利の積み重ね
誤答の落とし穴 Trap-D 混同誘発
- Trap-D 混同誘発: 「システムを導入したら DX 完了」と技術目線だけで判断
- プロセス変革、人材育成が同等以上に重要
- 経営層のコミットメント不足で、現場の自発性を頼みにする
- 成功指標を「システム稼働」と誤定義(本来はビジネス成果)
DX戦略とITガバナンスを同じ意味で読み、責任体制や KPI の話を変革の中身と混同する
学習アドバイス
DX は 何を変えるか の話で、IT ガバナンスは どう監督するか の話です。顧客接点や収益モデルを変えるなら DX、責任体制・KPI・レビュー会議の設計なら IT ガバナンスと切り分けると、経営情報システムの年度問題でぶれにくくなります。
Q25. 情報セキュリティ規程と遵守体制(ポリシー実装)
問題要旨 情報セキュリティポリシーの策定、従業員への周知、遵守状況の監視について、組織として実装すべき体制について正しい説明を選ぶ。
K/T/L/Trap分類
- K: K1(セキュリティ規程の基本)
- T: T1(ポリシー実装の直接理解)
- L: L1(基本概念)
- Trap: Trap-A 逆方向誘発(ポリシー作成 = 問題解決と誤解)
正解: エ
必要知識
- セキュリティポリシーと遵守体制 — 実装フレームワーク
- セキュリティポリシーの構成:
- 基本方針:経営層の意思表示(目的、適用範囲、責任分担)
- 標準(Standards):実装手段(パスワード強度、暗号化方式など)
- 手順(Procedures):具体的な作業ステップ
- ガイドライン:推奨事項
- 周知・教育:
- 入社時研修:基本知識
- 定期的な研修:新しい脅威対応
- 部署別研修:職務固有の対策
- 監視と監査:
- 日常監視:ツールによる自動検知
- 定期的な監査:ポリシー遵守の確認
- インシデント対応:違反検知時の処理
解法の思考プロセス
- ポリシー策定:経営層の承認、全社周知
- 従業員教育:全員が理解、署名で確認
- 環境整備:ツール導入(例:パスワード管理、メール暗号化)
- 継続的改善:監査結果 → ポリシー見直し → 再教育
誤答の落とし穴 Trap-A 逆方向誘発
- Trap-A 逆方向誘発: ポリシー文書を作成・配布して「完了」と思い込む
- 実装されているか定期的に確認(監査)が必須
- 違反が見つかったら理由を追求し、対策(再教育など)
- セキュリティと利便性のバランスを取らず、過度に厳格化(採用されない)
- 経営層の関与がなく、IT部門だけで推進
学習アドバイス セキュリティは「テクノロジーだけでは実現不可」という認識がここでも重要です。人間の行動を変え、組織文化を醸成する観点がセキュリティマネジメントの本質です。
年度別解説サマリー(H30 経営情報システム)
知識体系の網羅度
| 知識領域 | 該当問数 | K1 | K2 | K3 |
|---|---|---|---|---|
| コンピュータ基礎(Q1-Q4) | 4 | 3 | 1 | 0 |
| プログラミング・データベース(Q6-Q9) | 4 | 0 | 2 | 2 |
| ネットワーク・セキュリティ基礎(Q10-Q14) | 5 | 1 | 3 | 1 |
| システム開発(Q15-Q18) | 4 | 1 | 3 | 0 |
| IT運用・マネジメント(Q19-Q25) | 7 | 2 | 4 | 1 |
| 計 | 25 | 7 | 13 | 4 |
傾向: K2(概念の応用・比較)が主力層(52%)を占める。K3(複合的判断)は4問に限定。基礎知識の着実な習得が得点の軸。
分野別難度ランキング
- 最頻出(必ず得点すべき):コンピュータ基礎、ネットワーク基礎、要件定義、セキュリティ脅威対策
- 準頻出(応用知識で差がつく):データベース正規化、SQL、システム設計、テスト管理
- 先端トレンド(趣味程度の対策で可):AI・機械学習、DX戦略、クラウドサービス
出題傾向の推移と学習アドバイス
傾向1: IT基礎(コンピュータ、ネットワーク)と**マネジメント(開発プロセス、運用管理)**の2軸
- 対策:基礎知識の網羅 + 実装シナリオの理解
傾向2: 「正解は何か」ではなく、「なぜその判断か」を問う設問の増加
- 対策:選択肢の根拠を論理的に検証する癖をつける
傾向3: セキュリティと DX に関する出題の増加
- 対策:最新トレンドの動向把握
関連ページ
分類タグ凡例
知識分類(K)
- K1:基本概念の理解(定義、基礎用語)
- K2:概念の応用・比較(複数概念の関係、適用場面の判定)
- K3:複合的な事象の分析(複数領域の統合的判断)
- K4:戦略的思考(企業全体の最適化)
- K5:専門的深掘り(該当分野の最新知見)
思考分類(T)
- T1:定義の直接適用
- T2:複数要素の関係性把握と比較
- T3:複合的状況での最適判断と意思決定
- T4:リスク・機会の統合的評価
- T5:創造的問題解決と革新
形式層(L)
- L1:概念理解(そもそもの定義、用語の意味)
- L2:適用・比較(複数選択肢の比較、場面に応じた選択)
- L3:分析・判断(複合的事象から最適判定を導き出す)
落とし穴パターン(Trap)
- A:関連概念の混同
- B:因果関係や順序の誤解
- C:効果や特性を過度に一般化
- D:短期対応と根本対策の混同、または軽視
このページは役に立ちましたか?
評価とひとことを残してもらえると、内容と導線の改善に使えます。
Last updated on