令和6年度 春期 システムアーキテクト 午後問題
練習用オリジナル問題です
本ページの設問・題材・模範解答は、IPA 試験本番の出題傾向を模して作成した練習用オリジナル問題であり、 実際の試験で出題された問題ではありません。AI 採点機能の動作確認用としてご活用ください。 本番形式の学習には、実際の IPA 過去問（午前問題）をご利用ください。
⚠️ 練習用オリジナル問題です。本ページに掲載している午後問題は、IPA過去問の形式を模して作成した練習用オリジナル問題であり、実際の試験で出題された問題ではありません。
AI採点は目安です。本試験の採点とは異なる可能性があります。 採点結果は学習の参考程度にご利用ください。
業務のデジタル化を実現するシステムアーキテクチャの設計について
設問ア
0 / 800 字あなたが携わった、業務のデジタル化を実現するシステムの概要と、デジタル化の対象業務及び業務上の課題について、800字以内で述べよ。
構成のポイント（ヒント）
- 冒頭2〜3行で業界・規模・対象業務・自身の役割を提示し、読者が文脈を即座に把握できる構成にする
- 対象業務の流れは時系列または工程順に整理し、後続のアーキテクチャ論述で参照しやすい粒度にする
- 業務上の課題は3点程度に絞り、それぞれに具体的な数値（件数／リードタイム／差戻率）を添える
- 設問イへの橋渡しとして、最終段落で「これら課題に対しアーキテクチャ設計上の論点が生じた」と着地させる
- 「私は〜の立場で」と主語を明示し、当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私が携わったのは、地方銀行B社における法人融資稟議業務のデジタル化プロジェクトである。B社は預金量約3.2兆円・行員約1,800名の地域金融機関で、法人融資の年間稟議件数は約12,000件、平均稟議リードタイムは14営業日を要していた。私はB社のシステムアーキテクトとして、システム企画段階から本番稼働までの設計統括を担った。 デジタル化の対象業務は、営業店での稟議書作成、本部審査部での与信判断、決裁権限者の承認、契約書作成、貸出実行までの一連の流れである。従来は、Excelで作成された稟議書を本部に紙で回送し、審査部・本部関連部署を経由して決裁する運用であった。 業務上の課題は3点に整理された。第1に、稟議書の差戻しが平均2.4回発生し、リードタイム長期化の主因となっていた。差戻しの大半は、財務分析項目の入力漏れや、過去取引履歴との整合性不備など、形式的な不備であった。第2に、決算書・登記簿などの添付資料が紙で回送されるため、本部での参照可能性が低く、判断品質のばらつきにつながっていた。第3に、案件ごとの審査履歴・対応履歴がシステムに残らず、後続案件の参考や監査対応で都度ヒアリングが必要であった。 経営層は、これらの課題を放置すれば優良法人取引の機会喪失と、コンプライアンス対応コストの増大が避けられないと判断し、本件のデジタル化を中期計画の中核施策に位置付けた。私は、業務再設計と一体でアーキテクチャを構築する役割を担った。
採点の観点
【A評価相当】 - システム概要（業界／規模／対象業務／自身の立場）が具体的に記述されている - 対象業務の流れが論理的に整理され、読者が業務像を把握できる - 業務上の課題が複数の論点（手続／品質／統制）から立体的に分析されている - 設問イへの伏線として、課題の構造化が為されている 【B評価相当】 - 業務概要は記載されているが、規模感や立場が曖昧 - 課題の記述が単発的で構造化が弱い - 対象業務と課題の対応関係が不明確 【C評価相当（要改善）】 - どの企業でも当てはまる一般論に終始 - 自身の立場・役割が見えない - 課題が抽象的で、後続設問の前提として機能しない
設問イ
0 / 800〜1600 字設問アで述べた業務上の課題を解決するために、あなたが設計したシステムアーキテクチャの内容と、複数の方式案を比較評価して採用案を決定した経緯について、800字以上1,600字以内で具体的に述べよ。
構成のポイント（ヒント）
- アーキテクチャの全体像を冒頭で要約し、読み手に骨格を先に提示する（パラグラフ・ライティング）
- 比較した方式案は最低3案、それぞれの利点・欠点を対称的に整理する
- 採用判断の重視点は2〜3点に絞り、それぞれを独立した節として論述する
- 設問アの業務課題と設計要素を1対1で対応させ、論理的整合性を見せる
- 数値（投資額／期間／カスタマイズ率／効果）を最低3箇所に織り込む
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私が設計したシステムアーキテクチャは、稟議業務を「入力品質」「判断支援」「履歴蓄積」の3層で構造化し、それぞれをクラウド／パッケージ／内製の最適な組み合わせで実装するハイブリッド構成である。具体的には、(1)BPMS（ワークフロー基盤）をSaaS型製品で導入し承認経路を統一、(2)財務分析エンジンを内製で構築し稟議書入力時に自動チェック、(3)添付資料管理をクラウドストレージ＋AI-OCRで電子化、(4)案件履歴を行内データレイクに集約、の4要素を疎結合に連携させる構成とした。 このアーキテクチャ採用に至る過程で、私は3つの方式案を比較評価した。 方式A案は、既存基幹勘定系を拡張する内製フルスクラッチである。利点は既存データとの整合性が高く運用一元化が容易な点だが、開発期間が約36か月、初期投資が約18億円と大きく、後続の機能追加リードタイムも長い。方式B案は、稟議業務一体型のERP系パッケージを全面採用する案で、業界標準業務に準拠でき開発期間も短いが、B社固有の稟議経路や審査ロジックがパッケージ標準に収まらず、カスタマイズ率が約45%に達する見込みであった。方式C案が私の最終採用案で、層ごとに最適技術を組み合わせるハイブリッド構成である。 採用判断で重視した点は3つである。 第1に、「業務再設計の自由度の確保」である。設問アで述べたとおり、本案件の本質的課題は手続きの形式不備と判断品質ばらつきであり、稟議経路や審査基準の継続的改善が成功要因となる。方式A・Bは経路改定にシステム改修を要するが、方式CはBPMS層で経路定義を変更でき、改修なしで経路改定を反映できる。これにより継続改善のサイクルを月次回せる構造を担保した。 第2に、「初期投資と段階的価値提供のバランス」である。方式A・Bは大規模一括投資となり、稟議リードタイム短縮効果が出るのは稼働後3年目以降となる。方式Cは、(1)BPMS導入＋電子化（6か月）、(2)財務分析自動化（6か月）、(3)履歴データ活用（6か月）と機能単位で段階稼働できる構造とし、初年度から差戻率の半減を実現できる設計とした。経営層が投資効果を早期に確認できる構造を組み込んだ。 第3に、「将来の外部連携への拡張性」である。法人融資業務は、近い将来、決算書AI解析サービスや事業性評価データベースなど外部サービス連携が拡大することが見込まれる。方式Cは各層がAPIで連携する構造のため、外部サービス追加を内部改修なしで取り込める。一方、方式A・Bはモノリシック構成となるため、外部連携追加のたびに大規模回帰テストが必要となる。アーキテクチャの寿命を10年と想定したとき、拡張性が運用コストの累計に大きな差を生むと判断した。 これら3観点の比較を、定量評価表（評価項目×重み）と稟議書として経営会議に提示し、方式Cの採用承認を得た。
採点の観点
【A評価相当】 - アーキテクチャの内容（層構成／要素技術／連携方式）が具体的に記述されている - 設問アの業務上の課題と設計要素が論理的に対応している - 複数の方式案（最低3案）が比較評価されている - 採用判断の理由が定量的・構造的に説明されている - 数値（金額／期間／カスタマイズ率／件数）が適切に織り込まれている 【B評価相当】 - アーキテクチャは記述されているが、要素技術の具体性が低い - 比較評価が形式的で採用理由が薄い - 設問アとの対応が弱く、設計が独立して語られている 【C評価相当（要改善）】 - 「クラウド活用」「マイクロサービス」など標語の繰り返しで具体性に欠ける - 比較評価がなく単一案を提示するのみ - 自身の判断・関与が見えず、評論的記述に終始
設問ウ
0 / 600〜1200 字設問イで述べたシステムアーキテクチャについて、設計時に懸念した非機能要件上のリスクと、その対策として採った設計上の工夫、及び稼働後の評価と今後の改善点を、600字以上1,200字以内で具体的に述べよ。
構成のポイント（ヒント）
- 非機能要件上のリスクと、設計上の工夫を、それぞれ独立段落で論じる
- リスクには「なぜそのリスクが顕在化しうるか」の根拠を必ず添える
- 工夫は2〜3点に絞り、性能数値・運用効果まで踏み込む
- 評価点と改善点を明確に分け、改善点には今後への具体的アクションを添える
- 数値（応答時間／削減率／満足度／精度）を散りばめて当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
設計時に最も懸念した非機能要件上のリスクは、「ハイブリッド構成に起因する性能・可用性のばらつき」であった。BPMSと内製財務分析エンジンが別基盤で動作するため、稟議書登録から自動分析結果表示までのレスポンスが、ピーク時間帯に5秒を超えるリスクがあった。営業店の利用シーンでは応答3秒超で操作放棄が増えることが社内調査で判明しており、性能要件は厳格であった。 対策として3つの設計上の工夫を採った。第1に、財務分析エンジンの呼出を非同期化し、稟議書入力中はバックグラウンドで分析を進めて入力完了時に結果を表示する構造とした。これにより体感応答時間を1.2秒に圧縮した。第2に、各層間の連携をAPIゲートウェイ経由とし、サーキットブレーカーとリトライポリシーを統一実装することで、特定層の障害が稟議業務全体を停止させない構造とした。第3に、添付資料のAI-OCR処理を別キューに分離し、OCR遅延が稟議承認の停止条件にならないよう業務フローを再設計した。OCR未完了の案件も決裁権限者の判断で承認できる例外フローを設けた。 稼働後の評価は次のとおりである。評価点としては、稟議リードタイムが14営業日から6営業日へ短縮（57%減）、差戻率が38%から12%へ低下、本部審査部の作業工数が月次1,200時間から540時間へ削減された点が挙げられる。導入後12か月の利用者満足度調査では、営業店から94%、本部から87%の支持を得た。 一方、改善点は2点ある。第1に、稼働6か月後に電子契約サービスとの連携要望が現場から上がったが、契約書テンプレート管理がパッケージ層に閉じている設計だったため、連携実装に追加3か月を要した。設計時に外部連携対象として電子契約まで想定範囲を広げておくべきであった。第2に、AI-OCRの帳票認識精度が想定より低く（当初目標92%に対し実績78%）、人手確認工数が想定の1.4倍となった。今後は帳票種別ごとに精度評価を行い、低精度帳票を別ワークフローに振り分ける仕組みを追加する。これらは、業務再設計とアーキテクチャ設計を並走させる際に、外部環境変化や精度実績への余裕を持たせる必要性という、再利用可能な学びとなった。
採点の観点
【A評価相当】 - 非機能要件上のリスクと設計上の工夫が両方具体的に記述されている - 「評価」と「改善点」が両方明示され、改善点には次への学びがある - リスク・対策・評価が時系列または論理的に関連付けられている - 自身の関与と判断が明確 【B評価相当】 - リスクと対策は記述されているが、対策の具体性が弱い - 評価のみで改善点が形式的、または逆 - 設問イとの連携が薄い 【C評価相当（要改善）】 - 「監視を強化した」「冗長化した」と一般論で過程が不明 - 改善点が当たり障りのない一般論 - リスクの根拠が薄く、対策の必然性が見えない