戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

システムアーキテクト 2017年 午後1 問01


生命保険会社のシステムの構築に関する次の記述を読んで、設問1~4に答えよ。

 A社は、多くの個人保険の契約を保有する大手生命保険会社である。保険金などを顧客に支払った場合に支払調書を税務署に提出している。社会保障・税番号制度(以下、マイナンバー制度という)の導入に伴い、支払調書にマイナンバーの記載が必要になることから、マイナンバーを含むデータを処理するための専用の情報システム(以下、新システムという)を構築することにした。   〔現在の業務と関連システムの概要〕  A社では、顧客から保険金請求の連絡があった場合、保険金部で契約管理システムを利用して手続書類を印刷し、送付する。顧客から記入済みの手続書類の提出を受け、内容を確認して保険金を支払う。一定金額以上の保険金を支払った顧客については、契約管理システムを利用して支払調書を作成し、CDに格納して税務署に提出する。支払調書には、契約者の氏名、契約者の住所、受取人の氏名、受取人の住所、支払金額、支払年月日などが記載されている。  現在のシステム概念図を図1に示す。
システムアーキテクト試験(平成29年度 午後1 問1 図1)
〔マイナンバーに関する業務とシステム化の方針〕  マイナンバー制度導入後は、現在の支払調書に契約者及び受取人のマイナンバーを記載するマイナンバー記載欄が追加される。それに伴い、A社では、マイナンバーに関する業務とシステム化の方針を、次のように決定した。  ・顧客のマイナンバーを取り扱う部署として、マイナンバー管理部を新設する。  ・一定金額以上の保険金を支払った顧客については税務署に支払調書を提出する必要があるので、保険金請求の連絡を受けた際に、契約者及び受取人双方にマイナンバーの提供を依頼する。そのために、マイナンバー提供のお願い、マイナンバー申告書、マイナンバー申告書記入例、返信用の封筒などを含んだマイナンバーの提供に関する書類(以下、マイナンバー提供依頼書類という)をA社から顧客に送付する。  ・顧客からのマイナンバーの提供が遅れても、手続書類を確認でき次第、保険金を顧客に支払う。  ・マイナンバーを含むデータは、新システムだけで扱うこととする。また、マイナンバー管理部だけが新システムを利用できることとし、業務はセキュリティレベルの高い執務室で行う。  
〔マイナンバー制度導入後の業務概要〕  A社では、マイナンバー制度導入後、現在の業務に加えて次のような業務を実施することを検討している。  (1)マイナンバー取得業務   契約管理システムで、顧客番号と顧客氏名を記載したマイナンバー申告書を印刷する。既に新システムにマイナンバーを登録済みの顧客のマイナンバー申告書は印刷しない。顧客番号は、A社の顧客を一意に特定する値であり、1人の顧客が複数の保険契約に関係している場合でも、顧客番号は一つである。   保険金部は、保険金の支払に必要な手続書類に、マイナンバー提供依頼書類を同封して顧客に送付する。顧客は、送付されたマイナンバー申告書にマイナンバーを記入してA社に提出する。マイナンバー管理部は、顧客から提出されたマイナンバー申告書の内容に不備がないことを確認した後、新システムにマイナンバーを登録する。不備があった場合は、マイナンバー管理部で顧客に連絡し、対応する。   顧客からマイナンバーが変更になった旨の連絡があった場合は、新システムで管理しているマイナンバーを即時削除し、再度マイナンバー提供依頼書類を顧客に送付する。支払調書を税務署に提出した後にマイナンバーの変更があっても、支払調書の再提出は行わない。  (2)マイナンバー申告書進捗管理業務   マイナンバー管理部は、マイナンバー申告書の状態(以下、申告書ステータスという)を新システムで照会し、進捗状況を管理する。  (3)支払調書提出業務   契約管理システムで作成した支払調書に、新システムでマイナンバーを追記して、毎月1回、CDに格納して税務署に提出する。まだマイナンバーが提供されていない場合又は書類に不備があった場合は、該当する契約者又は受取人のマイナンバー記載欄を空白で提出する。その後、マイナンバーが提供されたら、マイナンバーを記載した支払調書を、訂正支払調書として再度提出する。マイナンバーの誤登録によって、提出済みの支払調書を訂正する必要があった場合は、担当者が個別に確認して対応する。  (4)マイナンバー申告書督促業務   支払調書提出時までにA社にマイナンバー申告書が届かず、支払調書の契約者又は受取人のマイナンバー記載欄を空白で提出した場合は、対象の顧客にマイナンバー申告書の提出を督促する。新システムから督促対象の顧客リストを出力し、マイナンバー管理部から顧客に督促書類を送付する。その際、顧客に督促書類を送付したことを把握するために、新システムに督促履歴を登録する。  (5)マイナンバー削除業務   顧客から提供されたマイナンバーは、支払調書を最後に提出してから7年経過した際に新システムで一括削除する。また、提出後7年を経過した支払調書も削除する。  
〔新システムの設計〕  マイナンバー制度導入後の業務を踏まえ、新システムの設計を次のように検討している。マイナンバー制度導入後のシステム概念図を図2に、新システムで利用する主要なデータを表1に示す。  (1)システム間連携機能   ・マイナンバー提供依頼書類を送付した顧客の顧客番号、送付年月日、顧客氏名及び送付先住所をマイナンバー提供依頼書類情報として契約管理システムから受領し、申告書データに登録する。   ・マイナンバーを登録又は削除した顧客の顧客番号を、契約管理システムに送信する。   ・現在の支払調書情報に契約者及び受取人の顧客番号を追加した支払調書情報(以下、支払調書基本情報という)を、毎月1回契約管理システムから受領する。  (2)マイナンバー取得管理機能   ・マイナンバー申告書に記入されている情報を用いて、登録画面からマイナンバーデータのレコードを登録する。   ・マイナンバーデータのレコードを登録する際、①該当する顧客の支払調書データのレコードが存在し、最新のレコードのマイナンバーが空白である場合に、再度、支払調書データのレコードを作成し、登録する。支払調書データは、レコードを履歴で保存する。  (3)マイナンバー申告書進捗管理機能   ・申告書データに申告書ステータスを保有し、画面から照会、変更する。申告書ステータスの値は、“取得中”、“不備対応中”、“登録済み”又は“削除済み”である。申告書ステータスの初期値は“取得中”である。不備があった場合は、画面から申告書ステータスの値を“不備対応中”にする。不備がなくマイナンバーが登録された場合は、申告書ステータスは“登録済み”になる。  (4)支払調書提出機能   ・契約管理システムから支払調書基本情報を受領後、支払調書番号を採番し、支払調書データのレコードを作成して、登録する。その際、契約者及び受取人のマイナンバーを設定する。登録した支払調書データのレコードから、税務署に提出する支払調書を格納したCDを作成する。   ・支払調書データから訂正支払調書として税務署に提出するレコードを抽出し、訂正支払調書を格納したCDを作成する。  (5)マイナンバー申告書督促機能   ・支払調書提出機能の処理完了後に、支払調書データの各支払調書番号について最新の履歴であるレコードを対象に、督促が必要な顧客番号を抽出する。抽出した顧客番号に該当する申告書データを参照し、②申告書ステータスが特定の値であるレコードを除外し、督促対象の顧客リストとして帳票に出力する。   ・督促書類を送付した顧客については、画面から督促履歴情報を督促履歴データに登録する。  (6)削除機能   ・削除予定年月日を過ぎているマイナンバーデータのレコードを一括で削除し、対応する顧客の申告書ステータスを“削除済み”にする。なお、削除予定年月日は、マイナンバーデータのレコードを登録する際、システムで計算して設定する。また、削除予定年月日は、ある機能で変更する。   ・マイナンバーデータのレコードを一括で削除する処理に加えて、画面から1件ずつ削除可能とする。   ・提出後7年経過している支払調書データのレコードを一括で削除する。
システムアーキテクト試験(平成29年度 午後1 問1 図2)

設問1:

問題文を見る
システム間連携機能について、マイナンバーを登録又は削除した顧客の顧客番号を契約管理システムに送信する目的を、35字以内で述べよ。

模範解答

契約管理システムでマイナンバー申告書の印刷を制御するため

解説

解答の論理構成

  1. 業務要件の確認
    • 問題文には、「契約管理システムで、顧客番号と顧客氏名を記載したマイナンバー申告書を印刷する。既に新システムにマイナンバーを登録済みの顧客のマイナンバー申告書は印刷しない。」とある。
    • つまり契約管理システムは「この顧客は申告書を印刷すべきか否か」を判断する必要がある。
  2. 設計方針の確認
    • 新システム側の「システム間連携機能」では、「マイナンバーを登録又は削除した顧客の顧客番号を、契約管理システムに送信する。」と定義されている。
    • 登録・削除どちらの場合も送信するのは、「印刷可否フラグ」を常に最新に保つためである。
  3. 両者の関係整理
    • 新システムでマイナンバーを“登録”したら、その顧客の申告書は「印刷不要」。
    • 新システムでマイナンバーを“削除”したら、再び「印刷対象」になる可能性がある。
    • したがって最新状態を契約管理システムへ通知し、「マイナンバー申告書」の印刷処理を制御することが目的となる。

誤りやすいポイント

  • 「登録時のみ送信」と誤解し、“削除”を見落とす。
  • 送信目的を「顧客情報更新」や「データ同期一般」とぼかしてしまい、“印刷制御”という具体的業務を示さない。
  • 契約管理システム側が自動で削除を検知できると誤認し、新システムからの通知不要と考えてしまう。

FAQ

Q: なぜ削除時も送信するのですか?
A: 削除後は再取得が必要になるため、契約管理システムで再び「マイナンバー申告書」を印刷し、顧客へ送付する必要があるからです。
Q: 送信内容は顧客番号だけで十分ですか?
A: 問題文では顧客番号のみを送信すると規定されています。顧客番号で一意に顧客を特定できるため、追加情報は不要と設計されています。
Q: 契約管理システムが判断ミスをしないようにする仕組みは?
A: 新システムが登録・削除の度に即時通知することで、契約管理システム内の状態をリアルタイムに保ち、印刷処理を確実に制御します。

関連キーワード: システム間連携、データ同期、帳票制御、状態管理

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

本文中の下線①で登録した支払調書データのレコードの利用目的を、25字以内で述べよ。

模範解答

訂正支払調書を格納したCDを作成するため

解説

解答の論理構成

  1. 下線①の動作
    • 【問題文】「①該当する顧客の支払調書データのレコードが存在し、最新のレコードのマイナンバーが空白である場合に、再度、支払調書データのレコードを作成し、登録する」
    • ここで “再度” =既存レコードとは別に新レコードを作成する点が重要です。
  2. 支払調書提出機能との連携
    • 【問題文】「支払調書データから訂正支払調書として税務署に提出するレコードを抽出し、訂正支払調書を格納したCDを作成する。」
    • 訂正対象となるのは「マイナンバーが後から提供された契約」であり、①の条件に合致します。
  3. 結び付け
    • ①で追加したレコードがないと、訂正支払調書を生成できません。
    • よって①のレコードの利用目的=「訂正支払調書CD作成」に帰結します。

誤りやすいポイント

  • 「履歴保存のため」とだけ答えるミス
    → 履歴保存は副次的効果であり、目的は訂正提出です。
  • 「再提出」ではなく「再登録」と答えてしまう
    → 問われているのは“利用目的”なので提出行為(CD作成)まで言及する必要があります。
  • 「支払調書提出機能」と「マイナンバー取得管理機能」の関連を見落とす
    → 2つの機能をセットで読むことが必須です。

FAQ

Q: 履歴番号が付くのに、なぜ履歴保存が主目的ではないのですか?
A: 履歴保存はマイナンバー訂正の過程で結果として行われる処理です。訂正支払調書を提出しなければ税務署側のデータが更新されないため、主目的は提出用データ生成となります。
Q: CD以外の媒体でも提出できる場合、答案はどう書くべきですか?
A: 本問は【問題文】が「CD」を明示しているので、解答にも必ず「CD」を含める必要があります。
Q: 「再度、支払調書データのレコードを作成」とあるが、どのタイミングで作られますか?
A: 顧客からマイナンバー申告書が届き、取得管理機能でマイナンバーを登録する瞬間に同時生成されます。

関連キーワード: マイナンバー、支払調書、履歴管理、訂正処理、データ登録

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問3:マイナンバー申告書督促機能について、(1)、(2)に答えよ。

問題文を見る
(1)支払調書データの最新の履歴であるレコードの中から、督促が必要な顧客番号を抽出する。督促が必要な顧客番号の抽出条件を、表1の属性を用いて35字以内で述べよ。

模範解答

契約者マイナンバー又は受取人マイナンバーが空白である顧客番号

解説

解答の導き方

  1. 督促が必要なのはどんな顧客か
    業務概要の(4)に、「支払調書の契約者又は受取人のマイナンバー記載欄を空白で提出した場合」は、対象の顧客にマイナンバー申告書の提出を督促するとあります。つまり、提出した支払調書のマイナンバー記載欄が空白であることが、督促が必要かどうかの目印です。
  2. マイナンバー記載欄が空白になるのはいつか
    業務概要の(3)に「まだマイナンバーが提供されていない場合又は書類に不備があった場合は、該当する契約者又は受取人のマイナンバー記載欄を空白で提出する。」とあり、マイナンバーが提供されたあとで訂正支払調書を提出し直します。表1の支払調書データには「契約者マイナンバー」と「受取人マイナンバー」があるので、記載欄が空白かどうかはこの二つの属性で判定できます。
  3. なぜ最新の履歴を見るのか
    下線①のとおり、マイナンバーを登録するときに最新のレコードのマイナンバーが空白であれば、支払調書データのレコードを新たに作成します。「支払調書データは、レコードを履歴で保存する。」ので、マイナンバーが空白の古いレコードもそのまま残ります。古いレコードまで見ると、すでにマイナンバーを提供した顧客にも督促してしまうので、各支払調書番号の最新の履歴だけで判定します。
  4. 契約者と受取人を別々に確認する
    マイナンバーは契約者と受取人がそれぞれ提供するので、どちらか一方でも空白なら督促が必要です。督促する相手は、空白になっている側の顧客(契約者顧客番号又は受取人顧客番号)です。そのため、二つの条件は「又は」でつなぎます。
  5. 解答
    以上から、抽出条件は「契約者マイナンバー又は受取人マイナンバーが空白である顧客番号」です。

誤りやすいポイント

  • 最新の履歴に絞らずに抽出してしまう。マイナンバーを登録すると新しいレコードが作られ、空白の古いレコードも残るので、提供済みの顧客まで督促対象になります。
  • 「又は」を「かつ」にしてしまう。契約者と受取人のどちらか一方でも空白なら、その顧客への督促が必要です。
  • 申告書ステータスを抽出条件に含めてしまう。申告書ステータスによる除外は、抽出したあとに申告書データを参照して行う別の処理(下線②)です。
  • マイナンバーデータに登録があるかどうかで判定しようとする。設問は支払調書データの最新の履歴であるレコードの中から抽出するよう求めているので、支払調書データの属性で条件を書きます。

FAQ

Q: 抽出条件に申告書ステータスは入れないのですか?
A: 入れません。督促機能では、まず支払調書データから督促が必要な顧客番号を抽出し、そのあと申告書データを参照して、申告書ステータスが特定の値であるレコードを除外します。この除外の内容は設問3(2)で問われています。
Q: 督促したあと、同じ顧客が再び抽出されることはありますか?
A: マイナンバーが提供されて登録されるまでは、最新の履歴のマイナンバー記載欄が空白のままなので、次の督促処理でも抽出されます。督促書類を送ったことは、督促履歴データに登録して把握します。

関連キーワード: 履歴管理、データ抽出、抽出条件、督促、マイナンバー

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問3:マイナンバー申告書督促機能について、(1)、(2)に答えよ。

問題文を見る
(2)本文中の下線②で除外しているレコードの申告書ステータスの値を答えよ。また、除外している理由を35字以内で述べよ。

模範解答

申告書ステータスの値:不備対応中 理由:A社にマイナンバー申告書が届いていない顧客を対象とするから

解説

解答の論理構成

  1. 督促対象の定義
    • 【問題文引用】「A社にマイナンバー申告書が届かず…提出を督促する」
      ⇒ 督促は“まだ届いていない”顧客のみ。
  2. ステータスの意味
    • 【問題文引用】「不備があった場合は…申告書ステータスの値を“不備対応中”にする」
    • 【問題文引用】「申告書ステータスの初期値は“取得中”」
      ⇒ “取得中”=未着、“不備対応中”=着荷済み(内容に不備)。
  3. 除外すべきステータス
    • 督促対象は“未着”の“取得中”。
    • “不備対応中”は着荷済みで督促対象外。
      ⇒ 「申告書ステータスが特定の値であるレコードを除外」の“特定の値”は「不備対応中」。
  4. 理由
    • 【問題文引用】「A社にマイナンバー申告書が届いていない顧客を対象とするから」
      ⇒ 到着済み(不備対応中)は抽出リストに入れる必要がないため。

誤りやすいポイント

  • “取得中”を除外と早合点しやすい
    ステータスの初期値=未着なので督促対象に含める側です。
  • “登録済み”や“削除済み”に着目しすぎる
    督促抽出前段階でマイナンバーが空白の支払調書番号だけを対象にしているため、登録済み・削除済みはそもそも候補に挙がりません。
  • 「不備対応中 = まだ提出されていない」と誤認
    文面で“届いたが不備あり”と明示されている点を見落としがちです。

FAQ

Q: “取得中”を除外しないと重複督促になりませんか?
A: 取得中はそもそも未着の状態なので、督促すべき対象として正しいです。重複督促は督促履歴で管理します。
Q: “登録済み”は除外条件に入らないのですか?
A: 支払調書作成時にマイナンバーが空白でなければ督促抽出対象外になるため、追加の除外判定は不要です。
Q: 不備解消後の再督促はどう制御しますか?
A: 不備が解消されれば“登録済み”へ変更され、次回抽出時に自動的に対象外になります。

関連キーワード: 顧客番号、マイナンバー、申告書ステータス、支払調書、データ削除

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問4:削除機能について、(1)、(2)に答えよ。

問題文を見る
(1)削除予定年月日を変更している機能を答えよ。また、その理由を35字以内で述べよ。

模範解答

機能:支払調書提出機能 理由:支払調書を提出してから7年後の日付を設定する必要があるから

解説

解答の導き方

  1. 削除予定年月日の扱いを確認する
    【問題文】の(6)削除機能には「削除予定年月日は、マイナンバーデータのレコードを登録する際、システムで計算して設定する。また、削除予定年月日は、ある機能で変更する。」とあります。登録時に一度設定した値を、後から別の機能が書き換える構造です。
  2. 削除の起算点を確認する
    (5)マイナンバー削除業務には「顧客から提供されたマイナンバーは、支払調書を最後に提出してから7年経過した際に新システムで一括削除する。」とあります。起算点は登録日ではなく「支払調書を最後に提出」した日です。
  3. 起算点が動くタイミングを考える
    同じ顧客について支払調書を提出するたびに「最後に提出」した日が新しくなります。そのため、削除予定年月日もその都度、提出日から7年後の日付へ設定し直す必要があります。
  4. 支払調書を提出する機能を特定する
    (4)支払調書提出機能は「支払調書データのレコードを作成して、登録する。その際、契約者及び受取人のマイナンバーを設定する。」とあり、さらに「税務署に提出する支払調書を格納したCDを作成する。」機能です。支払調書の提出を扱うのはこの機能なので、ここで削除予定年月日を変更します。
  5. 以上から、機能は「支払調書提出機能」、理由は「支払調書を提出してから7年後の日付を設定する必要があるから」となります。

誤りやすいポイント

  • 「削除機能」と答えてしまう。削除機能は「削除予定年月日を過ぎているマイナンバーデータのレコードを一括で削除」する機能で、削除予定年月日を使う側であって変更する側ではありません。
  • マイナンバーデータを登録する処理を答えてしまう。登録時の値は「システムで計算して設定する」と別に書かれており、設問が問うのは登録後に値を「変更」している機能です。
  • 理由に「7年間保存するため」とだけ書き、起算点が支払調書の提出であることを落としてしまう。提出のたびに削除の期限が延びることが、変更が必要になる理由です。

FAQ

Q: 登録時にすでに計算しているのに、なぜ変更が必要なのですか?
A: 削除の起算点が「支払調書を最後に提出してから」だからです。登録後に支払調書を提出すると起算点が後ろにずれるため、提出のたびに削除予定年月日を設定し直す必要があります。
Q: 解答する「機能」は、本文のどこから選べばよいですか?
A: 〔新システムの設計〕には、(1)システム間連携機能から(6)削除機能まで、機能ごとの説明が並んでいます。この中から、削除の起算点になる出来事(支払調書の提出)を扱う機能を選びます。

関連キーワード: 個人情報保護、データ保持期間、データライフサイクル管理、バッチ処理

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問4:削除機能について、(1)、(2)に答えよ。

問題文を見る
(2)画面から1件ずつ削除可能とした目的は、二つある。一つは、誤登録時に再度登録可能とするためである。もう一つの目的を35字以内で述べよ。

模範解答

顧客からマイナンバーの変更の連絡があった場合に削除するため

解説

解答の論理構成

  1. 問題文は、個別削除機能の背景として
    “削除機能・・画面から1件ずつ削除可能とする。”
    と定めています。
  2. また、業務フローには
    “顧客からマイナンバーが変更になった旨の連絡があった場合は、新システムで管理しているマイナンバーを即時削除し、再度マイナンバー提供依頼書類を顧客に送付する。”
    という運用が明示されています。
  3. すなわち、顧客が変更を届け出た時点でただちに旧番号を抹消しないと、誤ったマイナンバーを基に支払調書を作成・提出するリスクが生じます。
  4. バッチで一括削除する仕組みだけでは「即時削除」の要件を満たせません。そこで、人手による“1件ずつ削除”オプションを設け、変更届が届いた瞬間に迅速な対応を可能にしています。
  5. 以上より、個別削除機能の第二の目的は「顧客からマイナンバー変更連絡があった際に直ちに削除できるようにすること」と結論付けられます。

誤りやすいポイント

  • 「一括削除で十分」と考え、業務上の“即時削除”要件を読み落とす。
  • “訂正支払調書”の提出タイミングと混同し、削除ではなく訂正処理だと誤解する。
  • “誤登録時の再登録”を唯一の理由と決めつけ、変更届という別シナリオをイメージできない。

FAQ

Q: 個別削除が間に合わず誤った支払調書を提出したらどうなりますか?
A: 問題文の“支払調書データから訂正支払調書として税務署に提出する”機能で訂正します。ただし、個別削除で未然に防ぐほうが効率的です。
Q: 顧客が同日に複数契約を解約した場合でも個別削除が必要ですか?
A: はい。顧客番号は“一つ”と定義されているため、その顧客に紐づくマイナンバーを1回の個別削除で抹消できます。
Q: 削除予定年月日は誰が変更できますか?
A: 問題文では“ある機能で変更する”とだけ記載されており、具体的な権限者は設計時に要件定義する必要があります。

関連キーワード: 個別削除, マイナンバー管理, 顧客通知, データライフサイクル

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

戦国ITクイズ機能

\ せっかくなら /

システムアーキテクトを
クイズ形式で学習しませんか?

クイズ画面へ遷移する→

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について