令和7年度 春期 システムアーキテクト 午後問題
練習用オリジナル問題です
本ページの設問・題材・模範解答は、IPA 試験本番の出題傾向を模して作成した練習用オリジナル問題であり、 実際の試験で出題された問題ではありません。AI 採点機能の動作確認用としてご活用ください。 本番形式の学習には、実際の IPA 過去問（午前問題）をご利用ください。
⚠️ 練習用オリジナル問題です。本ページに掲載している午後問題は、IPA過去問の形式を模して作成した練習用オリジナル問題であり、実際の試験で出題された問題ではありません。
AI採点は目安です。本試験の採点とは異なる可能性があります。 採点結果は学習の参考程度にご利用ください。
クラウドネイティブを前提とした業務システムのアーキテクチャ設計について
設問ア
0 / 800 字あなたが携わった業務システムの対象業務と、クラウドネイティブを前提とした設計に至った背景について、800字以内で述べよ。
構成のポイント（ヒント）
- 冒頭2-3行で対象（業種／規模／自身の役割）を提示し、文脈を即座に把握できる構成にする
- 背景は3要素以上を挙げ、具体的な数値や事実を添える
- 設問イへの橋渡しとして、最終段落で次の論点に着地させる
- 「私は〜の立場で」と主語を明示し、当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私は、中堅企業の基幹業務システム刷新プロジェクトにおいて、システムアーキテクトとして従事した。 対象業務は、受発注管理、在庫管理、顧客管理、会計連携を含む販売管理システムである。従来のシステムは、オンプレミス環境で稼働するモノリシックなアプリケーションであり、約10年前に構築された。 このシステムは、事業成長に伴うトランザクション量の増加や、市場変化への迅速な対応が困難になっていた。具体的には、ピーク時の処理性能不足による応答遅延、新機能追加時の開発期間長期化、および老朽化したハードウェア保守費用と運用コストの増大が課題であった。特に、近年増加するECサイト連携や外部サービス連携において、既存システムでは柔軟なAPI連携が困難であり、手動でのデータ連携やバッチ処理に依存していたため、業務効率の低下を招いていた。 これらの背景から、私は、将来的な事業拡大と市場競争力強化のためには、スケーラビリティ、俊敏性、コスト最適化を同時に実現できるアーキテクチャへの転換が不可欠であると判断した。そこで、クラウドネイティブ技術を前提としたシステム設計を提案し、経営層および関連部門の合意を得て、プロジェクトを推進することになった。クラウドネイティブ技術の導入により、変化に強いシステム基盤を構築し、ビジネス価値の最大化を目指した。
採点の観点
【A評価相当】 - 対象事業／プロジェクトの概要（規模／自身の立場）が具体的に記述されている - 背景・前提が複数の論点から立体的に分析されている - 設問イ・ウへの伏線として論点の構造化が為されている 【B評価相当】 - 概要は記載されているが規模感や立場が曖昧 - 背景の記述が単発的で構造化が弱い 【C評価相当（要改善）】 - どの組織でも当てはまる一般論 - 背景・前提が当該事業／プロジェクトに紐付いていない
設問イ
0 / 800〜1600 字設問アで述べた背景を踏まえて、あなたが設計したクラウドネイティブ前提のアーキテクチャ内容と、設計上で重視した点を、800字以上1,600字以内で具体的に述べよ。
構成のポイント（ヒント）
- 全体像を冒頭で要約し、読み手に骨格を先に提示する（パラグラフ・ライティング）
- 「重視した点」は2〜3点に絞り、それぞれを独立した節として論述する
- 各重視点には『なぜそう判断したか』『代替案を取らなかった理由』を添える
- 設問アとの整合を1対1で対応させ、論理的整合性を見せる
- 数値（投資額／期間／顧客数／市場規模）を最低3箇所に織り込む
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
設問アで述べた背景を踏まえ、私は、販売管理システムをクラウドネイティブ前提のアーキテクチャとして設計した。具体的には、マイクロサービスアーキテクチャを採用し、各業務機能（受発注、在庫、顧客、会計連携など）を独立したサービスとして構築した。これにより、各サービスを個別に開発・デプロイ・スケール可能とし、システム全体の俊敏性と可用性を向上させた。 基盤にはマネージドKubernetesとデータベースを用い、サービスをコンテナで配置した。メッセージキューによる非同期連携で、受信先の一時停止を送信側へ波及させない設計とした。重複配信に備えてイベントIDを記録し、再試行しても注文や在庫が二重に更新されないようにした。 設計上で特に重視した点は、以下の3点である。 1. **スケーラビリティと耐障害性**：業務量の変動に柔軟に対応できるよう、コンテナのオートスケーリング機能やマネージドサービスの自動スケーリング機能を最大限に活用した。また、単一障害点（SPOF）を排除するため、冗長構成と複数アベイラビリティゾーンへの分散配置を徹底した。これにより、ピーク時の処理性能を旧システム比で約3倍に向上させ、年間を通して安定したサービス提供を可能にした。 2. **運用コストの最適化と効率化**：マネージドサービスを積極的に利用することで、インフラの構築・運用負荷を大幅に軽減した。また、宣言的IaC（Infrastructure as Code）としてTerraformを導入し、インフラのプロビジョニングと構成管理を自動化した。これにより、手作業によるミスを削減し、インフラ運用の工数を約40%削減することに成功した。さらに、リソースの利用状況をモニタリングし、不要なリソースの削減やインスタンスタイプの最適化を継続的に実施する仕組みを設計に組み込んだ。 3. **セキュリティとデータ整合性**：ゼロトラストネットワークの原則に基づき、すべての通信を認証・認可の対象とした。APIゲートウェイを導入し、外部からのアクセスを一元的に管理し、WAF（Web Application Firewall）による保護を実装した。また、サービス間の通信はTLSで暗号化し、最小権限の原則に基づいたIAM（Identity and Access Management）ポリシーを適用した。データ整合性については、各マイクロサービスが自身のデータストアを持つ「Database per Service」パターンを採用したが、トランザクション境界を考慮した設計が困難な場面に直面した。例えば、受発注と在庫の連携において、在庫引き当てと注文確定の整合性をどう保つかという課題である。この**困難**に対し、私はSagaパターンを適用し、補償トランザクションを導入することで、分散トランザクションにおけるデータ整合性を確保する**対応**を行った。これにより、複雑な業務フローでも一貫性を維持できるようになった。 また、もう一つの**困難**として、既存のモノリシックシステムからの移行計画が挙げられる。全ての機能を一度にマイクロサービス化することはリスクが高く、現実的ではなかった。この**困難**に対し、私は「ストラングラーパターン」を採用し、既存システムの一部機能を段階的に新しいマイクロサービスに置き換えていく**対応**を行った。まず、比較的独立性の高い顧客管理機能から移行を開始し、その後、受発注、在庫管理と順次切り替えていった。これにより、システム停止時間を最小限に抑えつつ、安全かつ着実に移行を進めることができた。
採点の観点
【A評価相当】 - 戦略／設計／計画／監査手続の内容が具体的に記述されている - 設問アの背景と論理的に対応している - 「重視した点」が3つ程度、それぞれに具体的判断と理由が明示されている - 数値（金額／期間／規模）が適切に織り込まれている 【B評価相当】 - 戦略／設計／計画は記述されているが、提供価値が一般論にとどまる - 重視点が単に列挙されているだけで判断理由が弱い - 設問アとの連携が弱く、戦略が独立して語られている 【C評価相当（要改善）】 - 標語の繰り返しで具体性に欠ける - 自身の役割が見えず、評論的記述に終始
設問ウ
0 / 600〜1200 字設問イで述べたアーキテクチャについて、実装・運用設計の工夫、関係者との合意形成、及び評価と今後の改善点を、600字以上1,200字以内で具体的に述べよ。
構成のポイント（ヒント）
- 経営層／関係者への説明と合意形成を、それぞれ独立段落で論じる
- 反対意見や困難の具体例を必ず1つ以上盛り込み、それへの対応を描く
- 評価点と改善点を明確に分け、改善点には今後への具体的アクションを添える
- 数値（期間／工数／合意までのステップ数）を散りばめて当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
設問イで述べたアーキテクチャについて、実装・運用設計の工夫、関係者との合意形成、及び評価と今後の改善点について述べる。 **実装・運用設計の工夫** 実装においては、DevOpsプラクティスを導入し、CI/CDパイプラインを構築した。これにより、コード変更からデプロイまでのリードタイムを大幅に短縮し、開発効率を向上させた。具体的には、Gitリポジトリへのプッシュをトリガーに自動テスト、コンテナイメージビルド、本番環境へのデプロイまでを自動化し、デプロイ頻度を週に数回にまで高めた。運用設計では、オブザーバビリティを重視し、集中ロギング、分散トレーシング、メトリクス収集の仕組みを導入した。これにより、システム全体の状況をリアルタイムで可視化し、障害発生時の迅速な原因特定と復旧を可能にした。ITILのフレームワークに基づき、インシデント管理、変更管理、問題管理のプロセスを整備し、運用チームと開発チームが密接に連携する体制を構築した。 **関係者との合意形成** クラウドネイティブへの移行は、従来の開発・運用プロセスからの大きな変革を伴うため、関係者との合意形成が非常に重要であった。私は、プロジェクト初期段階から、経営層、業務部門、開発チーム、運用チームに対して、クラウドネイティブ技術のメリット（スケーラビリティ、俊敏性、コスト最適化）だけでなく、デメリット（運用責任分界の見直し、サービス依存の管理、新たなスキルの習得）についても丁寧に説明し、共通理解を醸成した。特に、業務部門に対しては、プロトタイプやデモンストレーションを通じて、新システムがもたらす業務効率化や新サービス創出の可能性を具体的に示し、期待感を高めた。また、セキュリティ要件については、ISO/IEC 27001に基づいた情報セキュリティポリシーとの整合性を確認し、情報セキュリティ部門と連携して設計レビューを重ねることで、リスクを最小限に抑える合意を形成した。 **評価と今後の改善点** 新システム稼働後、旧システムと比較して、システムの可用性は99.9%から99.99%へと向上し、年間システム停止時間は約90%削減された。また、新機能開発にかかる平均リードタイムは、旧システムと比較して約50%短縮され、市場変化への対応力が大幅に向上した。コスト面では、初期投資は増加したものの、運用コストは年間で約20%削減される見込みである。これは、マネージドサービスの活用とIaCによる自動化の効果が大きい。 今後は実測した負荷を基に予約割引の適用範囲を決め、過剰な長期契約を避ける。また、障害時の再送・補償処理の訓練を増やし、分散したデータの照合と復旧を運用担当だけでも実行できるかを確認する。費用削減と引き換えに可用性や復旧性を落とさないよう、業務部門と四半期ごとに指標を見直す。
採点の観点
【A評価相当】 - 関係者への説明・合意形成の両方を具体的に記述 - 「評価」と「改善点」が両方明示され、改善点には次への学びがある - 反対意見・困難への対応プロセスが具体的に描かれている - 自身の関与と判断が明確 【B評価相当】 - 説明や合意形成は記述されているが、困難の描写が弱い - 評価のみで改善点が形式的、または逆 【C評価相当（要改善）】 - 「説明した」「合意を得た」と結果のみで過程が不明 - 改善点が当たり障りのない一般論