Systems Architect Examination case studies
Systems Architect Examination · Put your knowledge to work in context.
システムアーキテクト試験（略号 SA、英語名称 Systems Architect Examination）は、IPA 独立行政法人 情報処理推進機構が実施する情報処理技術者試験の高度試験の一つです。位置づけは「業務とITのグランドデザイナー」であり、システム開発の上流工程を主導する立場で、豊富な業務知識に基づいて的確な分析を行い、業務ニーズに適した情報システムのグランドデザインを設計し完成に導く上級エンジニアを目指す方に適しています。対象者像は、高度IT人材として確立した専門分野をもち、ITストラテジストによる提案を受けて、情報システムを利用したシステムの開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計し、開発を主導する者です。役割としては、全体最適の観点からの情報システムの構造設計、要件の分析・整理・取りまとめ、情報セキュリティを確保できる最適なシステム方式の設計、品質確保に向けたソフトウェアの設計・開発・テスト・運用・保守の検討、そして情報システム及びその効果の評価が挙げられます。ネットワーク、データベース、セキュリティなどの固有技術は、必要に応じて専門家の支援を受ける前提です。期待する技術水準には、業務モデルや情報システム全体体系の検討、業務プロセスの専門知識とシステム知識の双方を活用した提案、ビジネス活動の抽象化・モデル化、業種ごとのベストプラクティスに関する知見、汎用的なシステムの適切な選択と適用、要素技術の技術リスクと影響を勘案した構築・保守、評価基準の設定と分析・評価、ソフトウェアやシステムサービスの汎用化の検討が含まれます。2026年度はCBT方式により前期に実施され、現行試験制度は2026年度の試験実施をもって終了し、2027年度から新試験制度に移行する予定です。準備では、シラバスと過去問題で出題範囲を確認し、要件定義から方式設計までの一連の流れを業務シナリオ単位で説明できるようにしておくことが有効です。. Topics on this exam: 科目A-1 (多肢選択式・四肢択一), 科目A-2 (多肢選択式・四肢択一), 科目B-1 (記述式), and 科目B-2 (論述式). The Systems Architect Examination case studies are 5 cases and about 245 words.
1APサーバ増設で改善しないECサイトのレスポンス劣化
小売業A社は、月間400万セッションのBtoC ECサイトを運用している。構成はロードバランサ1台、APサーバ4台（各4vCPU・8GB）、DBサーバ1台（16vCPU・64GB）の3層で、セッション情報はAPサーバのローカルメモリに保持し、LBはスティッキーセッションで振り分けている。平常時は同時接続1,200で平均レスポンスタイム0.8秒、APサーバのCPU使用率は45%である。しかし月次セール時には同時接続3,000に達し、APサーバのCPU使用率が95%、平均レスポンスタイムが6.5秒まで悪化する。対策としてAPサーバを8台に増設したところ、レスポンスタイムは6.2秒とほとんど改善しなかった。このときDBサーバのCPU使用率は60%、ディスクの平均I/O待ちが1件あたり40ms、レスポンスタイム全体のうちDB待ちが65%を占めていた。各APサーバのコネクションプールは20本（合計80本）、DBの最大同時接続数は100である。APサーバ増設後のピーク時に、DBのロック待ちが急増したとの監視結果も得ている。また、商品検索と在庫参照がピーク時リクエストの7割を占め、いずれも更新を伴わない。経営層はセール売上の拡大を優先し、追加投資は月額50万円まで認めている。. APサーバを8台に増設してもレスポンスタイムが改善しなかった原因を、提示された数値と待ちの構造から説明せよ。. セッション情報をAPサーバのローカルメモリから外部ストアへ移す場合の設計上の留意点を3つ述べよ。. 結論：ボトルネックはAPではなくDBであり、APの増設はDBへの同時要求を増やして競合を悪化させた。 レスポンスタイムの65%がDB待ちである以上、AP側の処理能力をいくら上げても全体の6割は短くならない。アムダールの法則でいえば、改善できる上限は約1.5倍（1÷0.35）にとどまる。 コネクションプールは4台で合計80本、8台なら160本になるが、DBの最大同時接続数は100本である。100本を超えた接続はDB側で待たされ、AP台数を増やすほど待ち行列の長さが増す。 DBのCPU使用率は60%で余裕があるのに待ちが大きい。これはCPU不足ではなく、I/O待ち（1件あたり40ms）とロック待ちによる直列化が支配的であることを意味する。CPUが空いていても処理は進まない。 増設後にロック待ちが急増したという監視結果は、同一行・同一ページへの更新競合が並列度の上昇で顕在化したことを示す。 したがって「APのCPU使用率95%」は、DB待ちでスレッドが滞留した結果としての見かけの高稼働であり、原因ではなく症状である。. 施策1：参照系をDBから引き離す（キャッシュまたはリードレプリカ） 根拠：ピーク時リクエストの7割が更新を伴わない検索・在庫参照である。ここをAP前段のキャッシュやリードレプリカへ逃がせば、DBに到着する要求を大きく減らせ、ロック競合も同時に下がる。効果はリクエスト比率から見積もれる。 副作用：在庫の鮮度が落ちる。何秒までの遅れを業務が許容するかを商品区分ごとに決め、TTLと無効化の契機（更新イベント）を設計する必要がある。カート投入時の在庫確認だけは本番DBを参照するなど、参照先の使い分けが要る。 施策2：ホットスポット行の排他制御を見直す 根拠：ロック待ちの急増は特定行への集中が原因と考えられる。在庫引当を行の分割（確保数のパーティション化）や非同期の引当キューに変えれば、直列化の範囲を狭められる。 副作用：引当確定までの遅延と、二重引当を防ぐ補償処理・冪等キーの実装が必要になる。売り越しが許されない商材では、同期処理を残す判断もありうる。 補足として、AP側のプール合計をDBの最大接続数以下に保ち、取得タイムアウトとサーキットブレーカで待ちをAP側で打ち切る設定変更は、追加費用なしで同時に実施すべきである。. レイテンシの積み上げ ：外部ストアへの参照が全リクエストに加わるため、往復回数を減らす（一度の取得でまとめる）、AP側に短TTLのローカルキャッシュを持たせる、同一AZ内に配置するなどの設計が要る。ここを誤ると、DB待ちを減らした分をセッション参照で食いつぶす。 2.
35 words, under 1 min2基幹ERPのRPO15分・RTO4時間を満たすDR設計
製造業B社は、受注から出荷までを支える基幹ERPをオンプレミスで24時間365日稼働させている。データベースのサイズは2TB、日次の更新差分は平均120GB、月末締め処理のある日は最大600GBに達し、その更新は夜間6時間に集中する。現行のバックアップは毎夜間のフルバックアップ（所要4時間、テープ装置2台）と、週1回の遠隔地へのテープ搬送である。復旧はテープの搬入から始まり、作業はすべて手順書を見ながらの手作業で、直近の訓練では7時間を要した。経営層は昨年の監査指摘を受け、RPO15分・RTO4時間を新たな要件として提示した。情報システム部は、DRサイトへの非同期レプリケーション（REDO転送）を検討している。本社とDRサイトは専用線1Gbpsで結ばれ、往復遅延は8ms、月額回線費用は120万円である。DRサイトのサーバ調達には2億円、切替は手動で、切替後の動作確認に2時間を要するとERPベンダが回答している。本番系の更改は3年後を予定しており、それまでの暫定対策が求められている。. 現行のバックアップ運用のままではRPO15分・RTO4時間を満たせないことを、数値を用いて説明せよ。. 非同期レプリケーションでRPO15分を満たすための設計要件を述べ、専用線1Gbpsで容量が足りるかを数値で検証せよ。. RTO4時間を満たすために、技術以外の面を含めて何を変えるべきか述べよ。. RPO（目標15分） 復旧できる時点は「直前の夜間フルバックアップ」であり、障害発生時刻によっては最大24時間分の更新が失われる。15分の96倍であり、桁が2つ違う。 さらに遠隔地のテープは週1回搬送のため、本社サイトごと失う災害では最大7日前の状態しか残らない。目標の672倍に相当する。 RTO（目標4時間） 手順は「テープ搬入 → 2TBのリストア → ロールフォワード → 業務確認」であり、搬入待ちだけで数時間から1日かかる。搬入を除いてもリストアと検証に時間を要する。 実測値は訓練で7時間であり、すでに目標の1.75倍。しかも訓練は年1回で、手作業の45ページ手順は属人的で、担当者が不在ならさらに延びる。 結論として、現行方式はRPO・RTOのいずれも満たさず、テープの高速化では目標に届かない。方式そのものの変更が必要である。. 容量の検証 平均：120GB/日 ÷ 86,400秒 ≒ 1.4MB/s ≒ 11Mbps。 最悪：月末の600GBが6時間に集中すると 600,000MB ÷ 21,600秒 ≒ 27.8MB/s ≒ 222Mbps。1Gbps（公称）の約22%で、帯域は足りる。 ただし8msの往復遅延に対し、TCPで1Gbpsを出すには帯域遅延積（1Gbps×8ms＝約1MB）以上のウィンドウが必要になる。ウィンドウスケーリングと転送ストリームの並列化を設定しないと、実効スループットが出ない点に注意する。 RPO15分を満たす設計 1.
69 words, under 1 min320年稼働の保険契約管理システムの段階的モダナイズ
保険会社C社の契約管理システムは、20年前に構築したJavaモノリスで、約250万行、画面800本、夜間バッチ1,200本からなる。リリースは年2回で、1回の変更に対し影響調査だけで3週間、回帰テストに2か月を要している。開発は3社のベンダに委託し、常駐要員は40名、設計書は一部にしか存在せず、業務ルールの多くはプログラム中に埋め込まれている。経営層は「新商品を3か月で投入したい」としており、競合は2週間で投入している。システム部はクラウド移行とマイクロサービス化を組み合わせた刷新を構想しているが、予算は3年で12億円、中断できない業務が多く、全面停止は年1回の年末年始の3日間のみ可能である。可用性は99.9%、ピーク時のトランザクションは毎秒300件である。直近3年の障害は、バッチ間のデータ受け渡しの不整合が4割を占めている。. テストとリリースの自動化 ：マイクロサービス化は独立したデプロイを増やす施策であり、回帰テスト2か月のままではサービスごとの頻繁なリリースは成立しない。テスト自動化、CI/CD、環境の即時払い出しを先行して整える。 3. 可観測性と運用手順の整備 ：分散すると1つの処理が複数サービスをまたぎ、障害調査は難しくなる。トレーシング、相関ID、ログ集約を先に入れる。また3社のベンダの責任分界をサービス単位に引き直す契約上の整理も必要になる。 予算12億円・停止は年1回3日という制約下では、一括リプレースは非現実的であり、上記の土台づくりに初年度を使う判断が妥当である。. 境界の決め方 業務能力（契約引受、請求、収納、保全、支払）とデータ所有権で切る。同一トランザクションで同時に更新されるものは同一サービスに残す。分散トランザクションを持ち込むと、現在の障害原因であるデータ不整合が悪化する。 バッチ1,200本は「即時性が要る処理」と「夜間にまとめてよい処理」に分け、前者をAPI化し、後者は当面そのまま残す。 優先順位は、変更頻度が高く独立性の高い領域から。新商品投入のリードタイム短縮が経営目的である以上、商品定義・見積・引受の周辺が最初の候補になる。 移行方式 1. 年末年始の停止期間に、APIゲートウェイと新フロントを入れ替える。このとき旧モノリスはAPIの裏に残す。 2. データはサービスごとに所有させ、他サービスからは直接テーブル参照させずAPI経由にする。 4.
48 words, under 1 min4在宅勤務の常態化に伴う境界型防御の見直し
建設コンサルタントE社は従業員1,800名、全国40拠点で、設計部門は大容量のCADファイルを扱う。全社員が本社データセンターのVPN終端装置に接続し、社内システムとSaaSの双方を利用してきた。在宅勤務が6割に達した現在、VPNの同時接続上限1,000に対してピーク時1,400の接続要求があり、待ち時間が最大15分発生している。さらにSaaS利用が通信量の7割を占めるようになり、本社経由でSaaSへアクセスする構成（バックホール）のため、在宅勤務者のSaaS応答は平均200ms、各拠点回線は常時80%の帯域使用率である。加えて、取引先200社の協力会社が設計データ共有システムにインターネットから直接アクセスしており、認証はIDとパスワードのみである。昨年、退職者のアカウントが3か月間有効なまま利用可能だった事案が発覚した。経営層は、現場の業務効率を落とさずにセキュリティを強化する方針を示している。. 何が起きているか VPN同時接続は上限1,000に対し1,400の要求があり、超過分が最大15分待たされている。終端装置が本社の1か所に集中していることが構造的な原因である。 通信量の7割がSaaS向けであるにもかかわらず、すべて本社を経由している。データが本社まで往復する分だけ遅延が積み上がり、SaaS応答200msのうち相当部分がこの迂回で説明できる。 その結果、拠点回線は常時80%使用率となり、CADファイルの転送など本来必要な通信を圧迫している。 方針：インターネットブレークアウトとVPNの役割縮小 1. SaaS向け通信は最寄り拠点またはクラウド型セキュリティゲートウェイ（SWG/CASB）から直接出す。本社経由をやめるだけで遅延と帯域の両方が改善する。 2. VPNは社内システム向けのみの分割トンネルとし、対象を絞る。これにより同時接続数は社内系利用者程度まで減り、上限超過が解消する。 3. VPN終端をクラウド型に分散し、拠点単位で接続を受けられる構成にする。 4. 目標値は、SaaS応答100ms以下、拠点回線使用率60%以下、VPN待ち時間ゼロとし、移行前後で実測比較する。.
47 words, under 1 min5倉庫管理システム刷新をめぐるSaaS・内製・現行更改の対立
物流F社は、全国12か所の倉庫を統括する倉庫管理システム（WMS）を刷新する。現行は10年前のパッケージに大量のアドオンを施したオンプレミス構成で、現場はハンディターミナルによるバーコード運用に習熟している。経営層は人件費削減と在庫可視化を掲げてクラウドSaaSへの移行を主張し、倉庫長は「繁忙期の作業が止まるリスク」と「ハンディ端末の更改費用」を理由に反対している。情報システム部は、SaaS、PaaS上でのスクラッチ開発、現行更改の3案を比較検討している。要件は、繁忙期の処理能力が現行の1.5倍、障害時の停止許容時間は2時間、RFID対応は2年以内、投資回収は5年である。予算は初年度4億円、運用費は現行比1.2倍まで許容される。ステークホルダは経営層、倉庫長12名、協力物流会社5社、監査部門である。繁忙期は年2回、それぞれ3週間続き、その間の出荷件数は平常日の約2.2倍に達する。. 停止許容2時間の実現手段（SaaSはベンダ依存で、SLAと補償の内容、復旧の可視性が問われる。自社で復旧手順を握れるのは内製・現行更改） 3. RFID対応の実現時期と追加コスト 4. 将来の拡張性とベンダロックインの度合い トレードオフの可視化 軸を「スピード・コスト」と「制御可能性・現場適合」の2面で整理し、3案の位置を図で示す。 定量項目は5年間のTCO表にし、感度分析（出荷量±30%、SaaS料金の値上げ、為替）を併記する。単一の点推定で比較しない。 定性リスクは「起きる確率×影響」で評価し、繁忙期停止のような低確率・大影響の事象は別枠で扱う。 結論は単一案の断定ではなく、条件付きの推奨（例：基幹はSaaS、繁忙期のピーク処理と端末制御はPaaSで補完）として提示し、どの条件が変われば判断を変えるかを明記する。. 合意形成 まずステークホルダを「関心」と「影響力」で整理する。経営層は投資対効果、倉庫長は現場の停止と作業量、協力物流会社は接続方法と端末、監査部門は統制と証跡に関心がある。論点を分けて対応者を変える。 倉庫長の反対意見を感情論として扱わない。「繁忙期に止まる」を、ピーク時の出荷件数と1時間停止あたりの損失額に換算して要件化する。数値になれば設計で答えられる。 パイロット倉庫を1か所選び、繁忙期を含む3か月間の実証を行う。議論の材料を意見から実測データへ変えるのが最も効く。 監査部門には統制要件（権限分離、ログ保全、変更管理）を早期にレビューしてもらう。後工程での手戻りを防ぐ。 対立が解けない論点は隠さず、経営判断を仰ぐ論点として明示する。エスカレーションの期限も先に決める。 決定の記録 記録の型は「状況（制約と背景）」「決定内容」「検討した代替案と却下理由」「根拠となるデータ」「影響と受容したリスク」「見直し条件」の6項目とする。 決定者と日付を必ず残し、後から「誰が決めたか分からない」状態を避ける。 見直し条件（例：繁忙期の実測が要件を下回った場合、SaaSのSLAが改定された場合）を書いておくと、決定は固定化せず、変更のたびに同じ議論を繰り返さずに済む。 記録は設計書とは別に一覧化し、後続の更改や監査の場で参照できるようにする。.
46 words, under 1 minMore study resources for Systems Architect Examination
- Cheat sheet浮動小数点数の表現: (-1)^S × 1.M × 2^(E-bias)。単精度(IEEE 754)は符号1・指数8・仮数23ビット、バイアス127。倍精度は指数11・仮数52、バイアス1023。.
- Study plan科目A-1の出題範囲（ハードウェア、ソフトウェア、ネットワーク、データベース、セキュリティ、システム開発、マネジメント系）を7分野のマップに整理し、各分野の重要用語を50語ずつ洗い出す.
- Exam-day guideBring the original physical ID (passport or national ID card) whose name matches your registration exactly.