\ せっかくなら /
システムアーキテクトを
クイズ形式で学習しませんか？
クイズを始める→
すぐに利用可能！
システムアーキテクト試験 過去問・解説一覧
年度・セッション別のシステムアーキテクト試験過去問題集
システムアーキテクト試験の過去問演習について
本ページではシステムアーキテクト試験の過去問を年度・セッション別に計445問収録しています。システムアーキテクト試験は過去問演習が合格への最短ルートです。年度別・セッション別の問題リストから自由に問題を選び、解答・解説を確認できます。
スマートフォンにも最適化されているため、通勤・通学などのスキマ時間学習にも活用してください。システムアーキテクト試験の試験概要・出題形式・難易度・合格率の推移は、このページ下部にまとめて掲載しています。
システムアーキテクト試験とは（試験概要）
システムアーキテクト試験（SA）は、企業・行政組織における情報システムの構想・企画段階から要件定義、システム方式設計、開発・移行、運用・保守、さらには契約・調達・プロジェクト計画立案支援までを技術面でリードできるレベル4（最上位）の国家試験。最新シラバス Ver.5.2 では、提案依頼書（RFP）作成・評価、業務モデル策定、AI／クラウド／DX 技術の適用検討、投資効果評価など、経営戦略を踏まえたアーキテクチャ策定力と総合的な実践力が問われる。
| 項目 | 内容 |
|---|---|
| 区分 | SA |
| レベル | レベル4 |
| 実施方式 | CBT方式（令和8年度〜） |
| 実施時期 | 前期（2026年11月頃）※年1回 |
| 試験科目 | 科目A-1 / 科目A-2 / 科目B-1 / 科目B-2（旧:午前Ⅰ/午前Ⅱ/午後Ⅰ/午後Ⅱ） |
| 公式情報 | IPA公式ページ |
| シラバス | シラバス Ver.5.2（2023-12 公開） |
特徴・概要
- 取得者側のビジネス戦略・情報戦略を理解し、RFP 作成・提案評価を技術／業務双方の観点で主導する。
- システム化計画立案では業務モデル・業務課題を整理し、サービスレベル・品質・投資効果の方針を策定する。
- 要件定義フェーズで機能・非機能要件、制約条件、スケジュール要件を明確化し、関係者合意形成を行う。
- システム方式設計ではアーキテクチャ案を評価し、クラウド／オンプレ混載・AI・IoT・マイクロサービス等を踏まえ最適解を選定する。
- 開発プロセス選定（ウォーターフォール・アジャイル・DevOps 等）、開発環境整備、レビュー／テスト計画策定を統括する。
- 運用・保守計画、移行計画、教育訓練計画を立案し、移行後の運用評価・投資効果レビューを通じて継続改善をリードする。
試験の形式・出題構成・採点方式
システムアーキテクト試験（SA）は、令和8年度（2026年度）試験からCBT（Computer Based Testing）方式へ移行し、従来の「午前Ⅰ・午前Ⅱ・午後Ⅰ・午後Ⅱ」がそれぞれ「科目A-1・科目A-2・科目B-1・科目B-2」へ名称変更されました。出題形式・出題数・試験時間は従来から変更ありません。
| 試験科目 | 旧名称 | 時間 | 出題形式・構成 |
|---|---|---|---|
| 科目A-1 | 午前Ⅰ | 50分 | 多肢選択式（四肢択一）30問。情報技術の共通知識。一定条件で免除可 |
| 科目A-2 | 午前Ⅱ | 40分 | 多肢選択式（四肢択一）25問。システム開発分野の専門知識 |
| 科目B-1 | 午後Ⅰ | 90分 | 記述式。3問出題・2問選択。要件定義・方式設計・移行計画など |
| 科目B-2 | 午後Ⅱ | 120分 | 論述式（論文）。2問出題・1問選択。アーキテクチャ提案・DX推進事例など |
採点・合格基準： 科目A-1・科目A-2・科目B-1はいずれも100点満点で60点以上が基準点。科目B-2（論述式）は評価ランクA〜DのうちランクAのみ合格。科目A-1→A-2→B-1→B-2の順に採点され、いずれかが基準を満たさないと、その時点で不合格（以降は採点されない）。
科目A-1免除制度： 応用情報技術者試験の合格者や、過去2年以内に高度試験・支援士試験の科目A-1（旧午前Ⅰ）で基準点を満たした受験者などは、申請により科目A-1が免除されます。
実施時期・受験機会： 令和8年度は前期（2026年11月頃）の年1回実施予定。CBT化により、受験者が試験期間内で日時・会場を選んで受験します。最新の日程・申込方法はIPA公式で必ず確認してください。
2027年度からの新試験制度： IPAが2026年3月31日に公表した試験区分体系の見直しにより、システムアーキテクト試験を含む現行の高度試験は2026年度（令和8年度）の試験実施をもって終了する予定です。2027年度夏〜秋頃からは「プロフェッショナルデジタルスキル試験（PDS）」の**システム区分（システム領域）**へ大括り化・再編されます。現行区分での合格を狙う場合は、2026年度前期が最後の受験機会になる見込みです。
対象者像・求められる知識と技能
対象者像
- 高度IT人材として確立した専門分野をもち、ITストラテジストによる提案を受けて、情報システムを利用したシステムの開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計し、開発を主導する者
求められる主な能力・役割
- RFP 作成・提案評価・契約合意支援に関する実践力
- システム化計画立案（業務モデル策定・サービスレベル／品質方針・投資対効果予測）の推進力
- 要件定義（機能・非機能・制約・スケジュール）の整理と利害調整・合意形成力
- クラウド／AI／IoT／OSS／マイクロサービス等の技術動向を踏まえたアーキテクチャ評価・設計力
- 開発プロセス／品質保証／レビュー・テスト計画・移行計画を統括するマネジメント力
- 運用・保守・改善フェーズでの効果測定・投資効果評価・フィードバック力
求められる知識
- 契約・調達（RFP、提案書、外部委託契約、SLR/SLA、知財・法規）
- 業務分析・業務モデル表記（BPMN、DFD、UML、業務プロセス最適化）
- 要件工学：利害関係者分析、要求獲得技法、機能／非機能要件定義
- アーキテクチャ設計原則（モジュール化、疎結合、高可用性、性能、セキュリティ）
- クラウド設計（IaaS/PaaS/SaaS, マルチクラウド, コンテナ/K8s, IaC）
- 最新技術動向（AI/生成 AI、IoT、ビッグデータ、マイクロサービス、DevOps）
- 開発プロセス・ライフサイクルモデル（ウォーターフォール、スパイラル、アジャイル、DevOps）
- 品質保証・レビュー・テスト（システム結合、適格性確認、運用テスト）
- 移行計画・運用設計・BCP/DR 計画・サービスマネジメント（ITIL）
- 投資効果分析（コスト見積り、ベネフィット分析、ROI、業務効果測定）
求められる技能
- 業務／利用者ヒアリング・課題抽出・RFP 要求事項整理
- 提案評価・ベンダ交渉・契約条件整理・リスク調査
- 業務モデル／データモデル／業務フロー作成・説明・合意形成
- アーキテクチャ案の費用対効果・技術的実現性・リスク比較評価
- プロジェクト計画立案支援（WBS、スケジュール、体制、リソース計画）
- レビュー技法・品質ゲート運営・テスト計画／データ設計・残存不具合分析
- 運用移行・バックアップ計画・教育訓練計画策定と実行支援
- システム運用／業務運用評価報告の分析と改善提案
シラバス概要
- I. 契約合意支援
- RFP 作成・提案書評価・契約条件整理
- プロジェクト計画立案支援・承認プロセス対応
- II. 企画（システム化計画）
- 業務分析・業務モデル策定・サービスレベル／品質方針
- 実現可能性検討・投資効果予測・開発スケジュール策定
- III. 要件定義
- 利害関係者要件・業務要件・機能／非機能要件・制約条件の定義
- 要件レビュー・トレーサビリティ・合意形成
- IV. 開発・移行
- ライフサイクルモデル選択・開発環境整備・方式設計／詳細設計
- レビュー・結合／適格性確認テスト・移行計画と実施・教育訓練
- V. 運用・保守・評価
- 運用設計・運用テスト・業務／システム移行・訓練
- 運用評価・業務評価・投資効果レビュー・保守問題管理
分野別の出題数・出題傾向（学習テーマ別）
システムアーキテクト試験の午前問題の出題範囲を、情報処理推進機構（IPA）が公表する公式シラバス（Ver.5.2）を読み解いたうえで、戦国IT独自の切り口で学習テーマ別に整理し、テーマごとの出題数を集計しました。そのため、IPA公式の分野区分とは、分類のまとめ方や名称が一部異なります（公式の正式な分野構成はIPAのシラバスでご確認ください）。どのテーマが多く問われているかの目安としてご活用ください。
午前問題 全400問を、戦国IT独自の学習テーマ別に分類した出題数の分布です。
| 学習テーマ | 出題数 | 割合 |
|---|---|---|
| 契約・合意（RFP／提案） | 15問 | 3.8% |
| システム化計画・企画 | 9問 | 2.2% |
| プロジェクト計画・開発プロセス | 14問 | 3.5% |
| 要件定義（業務・機能・非機能） | 30問 | 7.5% |
| システム方式設計（アーキテクチャ） | 75問 | 18.8% |
| ソフトウェア要件定義・設計 | 69問 | 17.2% |
| データベース設計 | 25問 | 6.2% |
| インタフェース・システム連携 | 13問 | 3.2% |
| 品質保証・レビュー・監査 | 22問 | 5.5% |
| テスト（結合・適格性確認・運用テスト） | 34問 | 8.5% |
| 導入・受入れ・移行・運用準備 | 3問 | 0.8% |
| 運用評価・投資効果・保守・変更管理 | 16問 | 4.0% |
| 情報セキュリティ・先端技術（AI・クラウド） | 60問 | 15.0% |
| 組込み（IoTシステム開発） | 11問 | 2.8% |
| 横断・複合領域 | 1問 | 0.2% |
| その他 | 3問 | 0.8% |
出題範囲とサンプル問題（学習テーマ別）
ここからは、上の分布で示した学習テーマごとに、何が問われるかの要点と、実際に出題された午前の過去問を1問ずつ紹介します。
本セクションで扱う学習テーマは全15テーマです。
- 契約・合意（RFP／提案）
- システム化計画・企画
- プロジェクト計画・開発プロセス
- 要件定義（業務・機能・非機能）
- システム方式設計（アーキテクチャ）
- ソフトウェア要件定義・設計
- データベース設計
- インタフェース・システム連携
- 品質保証・レビュー・監査
- テスト（結合・適格性確認・運用テスト）
- 導入・受入れ・移行・運用準備
- 運用評価・投資効果・保守・変更管理
- 情報セキュリティ・先端技術（AI・クラウド）
- 組込み（IoTシステム開発）
- 横断・複合領域
契約・合意（RFP／提案）
このテーマで問われること
調達・外部委託を前提に、発注側はRFPで目的、対象範囲、前提条件、評価観点、期待SLAなどを明確化し、受注側は提案書で解決策、体制、見積り、リスク、スケジュールを整合させて提示する。試験では、曖昧さを残さない要求提示と、提案の比較可能性・公平性、契約後の手戻りを防ぐ合意形成の作法が問われる。
出題の焦点
- RFPに盛り込むべき項目（目的・範囲・前提）
- 提案の評価基準と比較可能性の確保
- 見積り根拠と前提条件の明確化
- 責任分界（発注者・受注者・第三者）
- SLA/品質要求の提示方法
- リスクと代替案の提示
問題 ― 平成27年午前2 問16
システム開発におけるベンダとの契約方法のうち、実費償本型契約はどれか。
- ア：委託業務の進行中に発生するリスクはベンダが負い、発注者は注文時に合意した価格を支払う。
- イ：契約期間が長期にわたる場合などで、インフレ率や特定の商品コストの変化に応じて、あらかじめ取り決められた契約金額を調整する。
- ウ：注文時に、目標とするコスト、利益、利益配分率、上限額を合意し、目標コストと実際に発生したコストの差異に基づいて利益を配分する。
- エ：ベンダの役務や技術に対する報酬に加え、委託業務の遂行に要した費用の全てをベンダに支払う。
正解と解説
正解：エ
- 結論：実費償本型契約は、ベンダがかかった実費を全額請求し、報酬を別途支払う契約形態です。
- 根拠：この契約は費用の透明性が高く、発注者が実際のコストを負担するため、リスク分担が明確です。
- 差がつくポイント：契約形態の特徴を理解し、リスク負担や費用負担の違いを正確に把握することが重要です。
システム化計画・企画
このテーマで問われること
経営戦略・情報戦略と整合させつつ、対象業務の現状把握（業務内容・課題・分析）から業務モデルを作成し、システム化の狙いと範囲、機能の整理、運用保守・環境整備・再利用・教育などの基本方針を定める。さらに実現可能性、概算スケジュール、選定方針、コスト見積りと投資効果を整理し、文書化して承認を得るまでの一連が出題対象となる。
出題の焦点
- As-Is/To-Be整理と業務モデル化
- 課題定義からシステム化目的への落とし込み
- フィージビリティ（技術・費用・要員・期間）
- システム選定（自社開発/パッケージ/サービス）方針
- 概算コストと投資効果の算定
- 運用・保守/環境整備/教育の基本方針
- 承認を得るための計画書構成と論理
問題 ― 令和3年午前2 問16
B.H.シュミットが提唱したCEM（Customer Experience Management）における、カスタマーエクスペリエンスの説明として、適切なものはどれか。
- ア：顧客が商品、サービスを購入・使用・利用する際の、満足や感動
- イ：顧客ロイヤルティが失われる原因となる、商品購入時のトラブル
- ウ：商品の購入数・購入金額などの数値で表される、顧客の購買履歴
- エ：販売員や接客員のスキル向上につながる、重要顧客への対応経験
正解と解説
正解：ア
- 結論：カスタマーエクスペリエンスは「顧客が商品やサービスを購入・利用する際の満足や感動」を指します。
- 根拠：B.H.シュミットのCEM理論では、顧客の体験価値を重視し、感情的な満足度が企業の成功に直結するとされます。
- 差がつくポイント：単なる購買データやトラブル対応ではなく、顧客の感情や体験そのものを理解する視点が重要です。
プロジェクト計画・開発プロセス
このテーマで問われること
システム化計画を実行に移すため、プロジェクト計画の立案・承認を支援し、推進体制や役割、意思決定、管理方法を整える。開発作業のライフサイクルモデル（ウォータフォール、反復、アジャイル等）の選定、開発環境の準備、プロセス実施計画（成果物、レビュー、構成管理、進捗/品質/リスク管理）を具体化する力が問われる。
出題の焦点
- WBS/マイルストンと計画の整合
- ライフサイクルモデルの選定理由
- 体制・役割分担と意思決定プロセス
- 開発標準・手順・テンプレート整備
- 進捗/品質/リスク/課題管理の仕組み
- 開発環境（CI/CD、ツール、権限）の準備
問題 ― 平成30年午前2 問13
スクラムを適用したアジャイル開発において、スクラムチームで何がうまくいき、何がうまくいかなかったのかを議論し、継続的なプロセス改善を促進するアクティビティはどれか。
- ア：スプリントプランニング
- イ：スプリントレトロスペクティブ
- ウ：スプリントレビュー
- エ：デイリースクラム
正解と解説
正解：イ
- 結論：継続的なプロセス改善を促進するのは「スプリントレトロスペクティブ」である。
- 根拠：スプリントレトロスペクティブは、チームがスプリントの振り返りを行い、成功点や課題を議論して改善策を決定する場だからである。
- 差がつくポイント：スプリントレビューは成果物の検証、スプリントプランニングは計画立案、デイリースクラムは進捗共有であり、改善議論の場はレトロスペクティブに限定される点を理解すること。
要件定義（業務・機能・非機能）
このテーマで問われること
ステークホルダを洗い出し、業務要件（目的・範囲・業務ルール）と、組織・環境などの制約を具体化したうえで、機能要件と非機能要件を定義する。サービスレベルや品質方針を要件へ落とし込み、スケジュール要件などプロジェクト制約も明確にする。さらにシステム要件として全体に統合し、矛盾や抜けのない要求に仕立てる観点が頻出となる。
出題の焦点
- 利害関係者分析と要求の優先順位付け
- 業務要件・機能要件・非機能要件の切り分け
- 制約条件（組織/環境/法令）の定義
- SLA・品質方針の要件化（測定可能性）
- 要求のトレーサビリティ確保
- スコープ管理と変更影響の考え方
問題 ― 平成25年午前2 問14
BABOKでは、要求をビジネス要求、ステークホルダ要求、ソリューション要求及び移行要求の4種類に分類している。ソリューション要求の説明はどれか。
- ア：経営戦略や情報化戦略などから求められる要求であり、エンタープライズアナリシスの活動で定義している。
- イ：新システムへのデータ変換や要員教育などに関する要求であり、ソリューションのアセスメントと妥当性確認の活動で定義している。
- ウ：組織・業務・システムが実現すべき機能要求と非機能要求であり、要求アナリシスの活動で定義している。
- エ：利用部門や運用部門などから個別に発せられるニーズであり、要求アナリシスの活動で定義している。
正解と解説
正解：ウ
- 結論：ソリューション要求は、組織やシステムが実現すべき機能要求と非機能要求を指し、要求アナリシスで定義されます。
- 根拠：BABOKでは要求を4種類に分類し、ソリューション要求は具体的なシステムや業務の仕様に関わるため、詳細な分析が必要です。
- 差がつくポイント：ソリューション要求と移行要求の違いを正確に理解し、どの段階で定義されるかを押さえることが重要です。
システム方式設計（アーキテクチャ）
このテーマで問われること
要件を満たすためのシステム方式（全体アーキテクチャ）を確立し、構成、分割方針、基盤・ネットワーク、セキュリティ、性能・可用性、運用設計との整合などを設計判断としてまとめる。方式の評価では、複数案比較（コスト、拡張性、リスク、運用性）やトレードオフを論理的に説明できることが重要で、設計根拠の明確さが採点点となる。
出題の焦点
- アーキテクチャ分割と責務配置
- 品質特性（性能・可用性・保守性）の実現策
- 方式選定のトレードオフ（コスト/リスク/運用性）
- セキュリティ/認証認可の全体設計
- 冗長化・DR・バックアップ方針
- 評価観点と設計根拠の説明
問題 ― 平成29年午前2 問20
マルチプロセッサによる並列処理で得られる高速化率（単一プロセッサのときと比べた倍率）Eを、次の式によって評価する。r=0.9のアプリケーションの高速化率がr=0.3のものの3倍となるのは、プロセッサが何台のときか。 $$ E = \frac{1}{1 - r + \frac{r}{n}} $$
ここで、 n：プロセッサの台数（$(1 \leq n)$） r：対象とする処理のうち、並列化が可能な部分の割合（$0 \leq r \leq 1$） とし、並列化に伴うオーバーヘッドは考慮しないものとする。
- ア：3
- イ：4
- ウ：5
- エ：6
正解と解説
正解：エ
- 結論：並列化率が0.9のアプリケーションの高速化率が0.3の3倍になるのはプロセッサ6台のときです。
- 根拠：高速化率はAmdahlの法則に基づき、$E = \frac{1}{1-r + \frac{r}{n}}$で計算し、条件を式に代入して解きます。
- 差がつくポイント：並列化率の違いが高速化率に与える影響を正確に理解し、式の変形と代入を丁寧に行うことが重要です。
ソフトウェア要件定義・設計
このテーマで問われること
システム要件を受け、ソフトウェア要件を確立して、コンポーネント構造や処理分担、内部設計（詳細設計）へ落とし込む。モジュール分割、凝集度/結合度、例外・エラー処理、ログ、性能を意識した設計、テスト容易性を高める設計などが対象となる。要求から設計、テスト要件までの整合を保ち、変更に強い設計方針を説明できるかが問われる。
出題の焦点
- ソフトウェア要件の具体化と境界定義
- コンポーネント分割と責務・依存関係
- 詳細設計（データ構造、処理、例外）の要点
- 非機能（性能・可用性）を意識した設計
- テスト容易性（疎結合、モック化）の確保
- 要件-設計-テストのトレーサビリティ
問題 ― 平成25年午前2 問3
イベント駆動型のアプリケーションにおけるイベント処理のタイミングを設計するのに有用な図はどれか。
- ア：E-R図
- イ：シーケンス図
- ウ：データフロー図
- エ：ペトリネット
正解と解説
正解：イ
- 結論：イベント処理のタイミング設計にはシーケンス図が最も適している。
- 根拠：シーケンス図はオブジェクト間のメッセージのやり取りや時間的順序を表現できるため、イベントの発生と処理の流れを明確に示せる。
- 差がつくポイント：他の図は構造やデータの流れを示すが、時間軸に沿った処理の順序を表現できない点が重要。
データベース設計
このテーマで問われること
業務データを整合的に扱うため、上位レベルの設計でエンティティや関係、主要キー、データの粒度・履歴方針を定め、詳細設計でテーブル定義、制約、索引、ビュー、パーティション、トランザクションやロック方針などを具体化する。性能と保守性、データ品質、セキュリティ（アクセス制御・マスキング）を両立させる設計判断が出題される。
出題の焦点
- 概念/論理設計（ER、正規化、キー設計）
- 物理設計（索引、パーティション、容量見積り）
- 整合性制約と参照整合性
- 性能対策（SQL/索引/統計情報）
- 同時実行制御（ロック、分離レベル）
- データ保護（権限、暗号化、監査ログ）
問題 ― 平成26年午前2 問15
情報システムの全体計画立案のためにE-Rモデルを用いて全社のデータモデルを作成する手順はどれか。
- ア：管理層の業務から機能を抽出し、機能をエンティティとする。次に、機能の相互関係に基づいてリレーションシップを定義する。さらに、全社の帳票類を調査して整理し、正規化された項目に基づいて属性を定義し、全社のデータモデルとする。
- イ：企業の全体像を把握するために、主要なエンティティだけを抽出し、それらの相互間のリレーションシップを含めて、鳥瞰図を作成する。次に、エンティティを詳細化し、全てのリレーションシップを明確にしたものを全社のデータモデルとする。
- ウ：業務層の現状システムを分析し、エンティティとリレーションシップを抽出する。それぞれについて適切な属性を定め、これらを基にE-R図を作成し、それを抽象化して、全社のデータモデルを作成する。
- エ：全社のデータとその処理過程を分析し、重要な処理を行っている業務を基本エンティティとする。次に、基本エンティティ相互のデータの流れをリレーションシップとして捉え、適切な識別名を与える。さらに、基本エンティティと関係のあるデータを属性とし、全社のデータモデルを作成する。
正解と解説
正解：イ
- 結論：全社のデータモデル作成は、主要エンティティの鳥瞰図作成から詳細化し、全リレーションシップを明確化する手順が正しいです。
- 根拠：E-Rモデルは全体像を把握しつつ、段階的に詳細化することで整合性の高いデータ構造を設計できるためです。
- 差がつくポイント：機能や処理ではなく「エンティティとリレーションシップの抽出順序」と「全体像から詳細化する段階的アプローチ」が重要です。
インタフェース・システム連携
このテーマで問われること
他システムとの連携方針から、具体的なインタフェース方式設計・詳細設計へ落とし込み、データ授受、API仕様、電文/ファイル形式、エラー処理、再送・冪等性、性能、監視、セキュリティを整備する。疎結合化や責任分界（障害時の切り分け、運用手順）を意識し、オンライン/バッチ/イベント連携など方式選択の理由を説明する力が問われる。
出題の焦点
- 連携方式の選定（API/メッセージ/ファイル）
- データ形式・項目定義と変換ルール
- エラー処理（再送、冪等、タイムアウト）
- 性能・スループットとピーク対策
- セキュリティ（認証、暗号化、署名）
- 運用設計（監視、障害切り分け、責任分界）
問題 ― 平成30年午前2 問22
磁気ディスク装置や磁気テープ装置などの外部記憶装置とサーバを、通常のLANとは別の高速な専用ネットワークで接続してシステムを構成するものはどれか。
- ア：DAFS
- イ：DAS
- ウ：NAS
- エ：SAN
正解と解説
正解：エ
- 結論：高速な専用ネットワークで外部記憶装置とサーバを接続するのはSANです。
- 根拠：SANはストレージ専用のネットワークで、通常のLANとは分離され高速かつ安定した通信を実現します。
- 差がつくポイント：NASはファイル共有用のネットワークストレージ、DASは直接接続型ストレージ、DAFSは分散ファイルシステムであり、専用ネットワークの意味合いが異なります。
品質保証・レビュー・監査
このテーマで問われること
要件・設計・テスト結果・移行結果など各成果物を評価し、共同レビューで欠陥を早期に除去して合意形成を図る。観点は妥当性、完全性、一貫性、追跡可能性、標準適合で、指摘の根拠と是正方針を明確にすることが重要。監査支援では、統制や証跡、手続き遵守を示す資料整備と説明責任が問われ、品質とガバナンスを両立する実務力が試される。
出題の焦点
- レビュー観点（妥当性・完全性・一貫性）
- 要件/設計/テストのトレーサビリティ
- 合意形成（参加者、記録、判定基準）
- 欠陥の是正・再発防止の進め方
- 監査対応（証跡、手続き、責任分界）
- 移行/リリースの判定と品質基準
問題 ― 平成22年午前2 問13
構成管理ツールを使用して開発用のソースコードを取得する際に、リポジトリ上の位置やリビジョンなどの構成情報を保持したままでソースコードを入手したい。このとき、構成管理ツールに対して行う操作はどれか。
- ア：インポート
- イ：エクスポート
- ウ：コミット
- エ：チェックアウト
正解と解説
正解：エ
- 結論：構成管理ツールで構成情報を保持したままソースコードを取得するには「チェックアウト」を行います。
- 根拠：チェックアウトはリポジトリの指定リビジョンのファイルを作業コピーに取得し、構成情報を保持する操作です。
- 差がつくポイント：単にファイルをコピーする「エクスポート」と異なり、チェックアウトは変更管理や履歴追跡に必要なメタ情報も含めて取得します。
テスト（結合・適格性確認・運用テスト）
このテーマで問われること
結合から適格性確認、さらに運用テストまで、テスト要件の定義・更新、計画作成、準備、実施を一貫して扱う。観点は機能だけでなく性能、障害時動作、回復、運用手順、監視、バックアップ/リストアなど実運用に直結する検証である。試験では、テストレベルごとの目的と責任分担、判定基準、欠陥管理、環境・データ準備の妥当性が問われる。
出題の焦点
- 結合テストの範囲・観点（IF、データ整合）
- 適格性確認テストの目的と判定基準
- 運用テスト（監視、障害対応、復旧）の設計
- テスト環境・テストデータの準備
- 欠陥管理と是正のクローズ条件
- 非機能（性能・可用性）の検証方法
問題 ― 平成24年午前2 問8
プログラムテスト仕様書の作成手順として、作業項目を適切な順序に並べたものはどれか。
a.テスト環境、テスト方法などのプログラムテストに関する概要を記述する。 b.テストケースごとのテストデータの作成と予想結果の作成を行う。 c.テストケースを設定する。 d.テスト項目を全て列挙する。 e.テストを実行するときの個々の詳細な手順を設定する。
- ア：a, d, c, b, e
- イ：a, d, e, c, b
- ウ：a, e, c, b, d
- エ：a, e, d, c, b
正解と解説
正解：ア
- 結論：プログラムテスト仕様書は「概要記述→テスト項目列挙→テストケース設定→テストデータ作成→詳細手順設定」の順で作成します。
- 根拠：テスト仕様書は全体像の把握から具体的なテスト実施手順へ段階的に詳細化するため、この順序が合理的です。
- 差がつくポイント：テスト項目の網羅性を確保し、テストケースとデータの整合性を取ることが重要で、順序を誤るとテストの抜け漏れや混乱を招きます。
導入・受入れ・移行・運用準備
このテーマで問われること
導入計画に基づくインストール/展開、受入れレビュー・受入れテスト支援、納入と引渡し、教育訓練、運用プロセス計画や運用方式設計、運用訓練、移行計画と実行、旧環境データの保全までを扱う。利用者用文書の作成・更新や運用保守への引継ぎなど、運用開始を成功させるための準備が中心で、切替時のリスク低減と手順の具体性が重要となる。
出題の焦点
- 導入手順（展開、設定、ロールバック）
- 受入れの観点と引渡し条件（納入物、証跡）
- 教育計画・マニュアル整備と定着化
- 移行方式（並行/一斉/段階）とリスク対策
- データ移行の整合性確認と保全
- 運用保守への引継ぎ（体制、手順、SLA）
問題 ― 令和6年午前2 問10
JIS X 0160:2021（ソフトウェアライフサイクルプロセス）によれば、移行プロセスで実施するタスクはどれか。
- ア：システムの利用及び支援に必要な情報ニーズを識別し、利用者用文書、並びに運用操作者、利用者及びその他の利害関係者への教育訓練を用意する。
- イ：システム又はシステム要素が明示された要件（要求事項）に合致していることについて、利害関係者の合意を得る。
- ウ：ソフトウェアシステム又は要素が利害関係者ニーズに合致していることについて、利害関係者の合意を獲得する。
- エ：統合されたソフトウェアのインタフェース及び機能が、始動時点から期待されている終了時点まで、期待されるデータ値の範囲内で実行動作することのチェックを実施する。
正解と解説
正解：ア
- 結論：移行プロセスでは利用者支援のための文書作成や教育訓練の準備が重要なタスクです。
- 根拠：JIS X 0160:2021はソフトウェアライフサイクルの各プロセスで実施すべき具体的なタスクを定めており、移行プロセスはシステム導入後の利用環境整備に焦点を当てています。
- 差がつくポイント：移行プロセスは単なる動作確認や合意形成ではなく、利用者が新システムを円滑に使えるよう支援体制を整えることが求められます。
運用評価・投資効果・保守・変更管理
このテーマで問われること
稼働後のシステム運用・業務運用を評価し、サービスレベル、処理性能、障害傾向、利用定着、業務KPIなどから改善点を抽出する。投資効果・業務効果の評価では、目標と実績の差分を分析し、追加投資や改善施策の意思決定につなげる。保守では問題報告や修正依頼を分析し、対応方針の選択肢を提示して承認を得るなど、変更管理の実務が問われる。
出題の焦点
- 運用実績の評価指標（SLA、可用性、性能）
- 業務KPIと業務改善の結び付け
- 投資効果（ROI等）と効果測定の前提
- 障害・問題の原因分析と恒久対策
- 変更の影響評価と承認プロセス
- 保守リリース計画とリスク管理
問題 ― 平成22年午前2 問14
情報システムの導入に伴って変化するキャッシュフローの現在価値を計算することで、投資効果を評価する指標はどれか。
- ア：BSC
- イ：EVA
- ウ：NPV
- エ：ROI
正解と解説
正解：ウ
- 結論：投資効果を評価する指標として、キャッシュフローの現在価値を計算する「NPV」が正解です。
- 根拠：NPVは将来のキャッシュフローを割引率で現在価値に換算し、投資の収益性を定量的に評価します。
- 差がつくポイント：BSCやEVA、ROIは経営指標や利益率評価に使われますが、投資の現在価値評価に特化しているのはNPVだけです。
情報セキュリティ・先端技術（AI・クラウド）
このテーマで問われること
クラウドやAIなどの適用情報技術を調査し、課題解決にどう活用できるかを評価する。対象は、クラウドのサービスモデル選定、可用性・スケーラビリティ、運用責任分界、コスト最適化、データ保護、AI活用時のデータ準備や精度評価、説明可能性、ガバナンスなど。試験では、流行語ではなく要件と制約に照らして適用可否とリスクを論理的に述べる力が問われる。
出題の焦点
- クラウド導入の目的と適用判断（IaaS/PaaS/SaaS）
- 責任分界と運用設計（監視、障害対応）
- コスト見積りと最適化（従量課金、予約等）
- セキュリティ（鍵管理、権限、データ所在）
- AI活用の前提（データ品質、学習/評価）
- AIのリスク（バイアス、説明可能性、統制）
問題 ― 平成24年午前2 問20
自律コンピューティングの説明はどれか。
- ア：システム内の各コンピュータの役割は固定されず、状況に応じてサーバにもクライアントにもなる対等な関係のことである。
- イ：従来は人手で対応してきたシステムの複雑さに起因する問題を、システムに自己管理機能を実装することによって、システムが自ら解決することを目指した技術のことである。
- ウ：生活や社会のいたるところにコンピュータが存在し、コンピュータ同士が連携して動作することによって、人間の生活を支援する情報環境のことである。
- エ：ネットワークに接続された各コンピュータ内の情報を探索して取得するために、オーバレイネットワークと呼ぶ仮想ネットワークを利用する技術のことである。
正解と解説
正解：イ
- 結論：自律コンピューティングとは、システムが自己管理機能を持ち、自ら問題を解決する技術です。
- 根拠：従来は人手で対応していた複雑なシステム運用を自動化し、効率化と安定性を高めることを目的としています。
- 差がつくポイント：単なる役割の変動やネットワーク技術ではなく、「自己管理・自己修復」という自律性の本質を理解することが重要です。
組込み（IoTシステム開発）
このテーマで問われること
IoT/組込み領域では、センサ・デバイスからクラウドまでのエンドツーエンド設計、リアルタイム性、低消費電力、通信の不安定さ、フィールド更新（OTA）など固有の制約を踏まえた開発が中心となる。安全性やセキュリティ（機器認証、鍵保護）、故障時のフェイルセーフ、量産・保守まで含めたライフサイクル管理が重要で、要求から方式・検証まで一貫した説明力が問われる。
出題の焦点
- リアルタイム性と資源制約（CPU/メモリ/電力）
- 通信方式選定と接続断対策
- デバイス認証と鍵管理（安全なプロビジョニング）
- OTA更新とバージョン管理
- フェイルセーフ/フェイルオペ設計
- フィールドデータ収集と監視・保守
問題 ― 平成28年午前2 問9
組込みシステムの開発におけるソースコードの品質向上のために、C言語のコーディング規則をまとめたものはどれか。
- ア：CSS
- イ：GCC
- ウ：MISRA-C
- エ：SystemC
正解と解説
正解：ウ
- 結論：組込みシステムのC言語コード品質向上には「MISRA-C」が最適なコーディング規則である。
- 根拠：MISRA-Cは安全性・信頼性を重視し、組込み開発で広く採用されている標準規約だからである。
- 差がつくポイント：他選択肢はCSS（スタイルシート）、GCC（コンパイラ）、SystemC（ハードウェア記述言語）であり、コーディング規則ではない点を理解すること。
横断・複合領域
このテーマで問われること
複数分野にまたがる論点として、セキュリティ、性能、可用性、運用性、法令順守、データガバナンスなどを、企画から要件・方式・設計・テスト・移行・運用まで貫いて整合させる力が問われる。部分最適ではなく全体最適の観点で、トレードオフを整理し、関係者間の責任分界と合意形成を行いながら、変更に強いアーキテクチャと運用体制へ落とし込むことが重要である。
出題の焦点
- 全体最適のトレードオフ整理（品質特性間）
- セキュリティを要件〜運用まで一貫適用
- 運用・保守を踏まえた設計判断（運用性）
- 責任分界と合意形成（社内外・部門間）
- 変更時の影響分析と継続改善
- 標準・法令・ガイドラインへの適合
問題 ― 平成28年午前2 問23
JIS Q 27014:2015（情報セキュリティガバナンス）における、情報セキュリティを統治するために経営陣が実行するガバナンスプロセスのうちの“モニタ”はどれか。
- ア：情報セキュリティの目的及び戦略について、指示を与えるガバナンスプロセス
- イ：戦略的目的の達成を評価することを可能にするガバナンスプロセス
- ウ：独立した立場からの客観的な監査、レビュー又は認証を委託するガバナンスプロセス
- エ：利害関係者との間で、特定のニーズに沿って情報セキュリティに関する情報を交換するガバナンスプロセス
正解と解説
正解：イ
- 結論：モニタは「戦略的目的の達成を評価する」ガバナンスプロセスを指します。
- 根拠：JIS Q 27014:2015では、モニタは経営陣が情報セキュリティの効果を継続的に評価し、改善に役立てる役割と定義されています。
- 差がつくポイント：モニタは単なる監査や指示ではなく、戦略の達成度を評価し、経営判断に反映させるプロセスである点を理解することが重要です。
攻略ポイント・学習アドバイス
- 午後Ⅰは『RFP／提案評価』『システム化計画』『要件定義／非機能要件』『方式設計と移行計画』などの頻出パターンを整理し、90 分で 2 問解く演習を繰り返す。
- 午後Ⅱは自身のプロジェクト経験を軸に、導入背景→課題→要件→アーキテクチャ選定→方式設計→移行／運用計画→効果の流れで論述する構成メモを準備する。
- 午前Ⅱはシラバス大項目（契約合意・企画・要件定義・開発・運用保守）を網羅的に学習し、特に RFP 作成／アジャイル・DevOps／クラウド設計／投資効果分析を重点確認。
- IPA 公式シラバス／過去問／採点講評を熟読し、評価観点（論理性・具体性・一貫性）を意識して答案をブラッシュアップする。
関連リンク
システムアーキテクト試験の難易度・合格率の推移
以下は年度ごとの受験者数・合格者数・合格率・合格者平均年齢の推移データです。合格率の傾向を把握し、学習計画の目安にしてください。
年度別 統計データ（表形式）
各年度ごとの合格率・平均年齢・合格者数などの推移です。
※ 表は横にスクロールできます
| 年度 | 受験申込者数(人) | 受験者数(人) | 合格者数(人) | 合格率(%) | 合格者平均年齢(才) |
|---|---|---|---|---|---|
| 2009 春期 | 13056 | 8395 | 1112 | 14.2 | 34.7 |
| 2010 春期 | 12553 | 8167 | 1022 | 12.5 | 34.5 |
| 2011 春期 | 9954 | 6509 | 966 | 14.8 | 35.5 |
| 2012 春期 | 9901 | 6683 | 965 | 14.4 | 35.7 |
| 2013 春期 | 9346 | 6113 | 864 | 14.1 | 36.1 |
| 2014 春期 | 8814 | 5735 | 860 | 15.0 | 36.7 |
| 2015 春期 | 8181 | 5274 | 697 | 13.2 | 36.3 |
| 2016 春期 | 8157 | 5363 | 748 | 13.9 | 37.2 |
| 2017 春期 | 8678 | 5539 | 703 | 12.7 | 36.6 |
| 2018 春期 | 9105 | 5832 | 736 | 12.6 | 36.5 |
| 2019 春期 | 8340 | 5217 | 798 | 15.3 | 37.3 |
| 2021 秋期 | 5447 | 3433 | 567 | 16.5 | 36.4 |
| 2022 秋期 | 5369 | 3474 | 520 | 15.0 | 36.6 |
| 2023 秋期 | 5684 | 3679 | 581 | 15.8 | 36.6 |
| 2024 秋期 | 5696 | 3666 | 549 | 15.0 | 36.3 |
年度別 統計推移グラフ
各年度ごとの合格者数・受験者数・合格率・平均年齢の推移
合格者数
受験者数
合格率（%）
合格者平均年齢
