システムアーキテクト 2013年 午後1 問02
銀行のATM(現金自動預払機)サービスに関する次の記述を読んで、設問1~3に答えよ
E銀行は、このたび、国内普通預金口座を対象にした海外ATMサービスを実施することにした。
〔海外ATMサービスの概要〕
(1)海外ATMサービスを利用できる時間は、24時間365日である。
(2)海外で共通にATMサービスを提供する国際ネットワーク(以下、海外共通ネットワークという)を使用することによって、世界各国にある海外共通ネットワーク加盟店のATMを利用できる。
(3)海外ATMで利用できる取引は、現金の出金だけである。現地通貨で払い出し、即時に円に換算して、円貨で口座から引き落とす。
〔E銀行の勘定系システム及び海外ATMサービスのシステム概要〕
(1)E銀行の勘定系システム(以下、E銀行システムという)は、システムメンテナンス時間を除いて常時稼働している。システムメンテナンス時間は、毎週日曜日の23:00から翌月曜日の6:00までである。なお、曜日・時間はすべて日本を基準に示す。
(2)国内ATMでは、現金の入出金、振込及びカード暗証番号変更サービスが利用できる。国内ATMは、毎週日曜日の21:00から翌月曜日の7:00まで停止している。
(3)口座の開設、及び顧客名、顧客住所、顧客電話番号などの顧客属性の変更は、平日の8:00から21:00まで支店窓口で受け付けている。
(4)国内ATMからの出金については、次の条件をすべて満たしたときに実行している。海外ATM利用時の出金についても、同様の処理を行う。
①ATMから送信された出金取引の情報と口座元帳データベース(以下、E銀行元帳という)の店番号、口座番号及びカード暗証番号が一致すること
②カードの盗難又は紛失の設定(以下、事故カードの設定という)がないこと
③出金額が支払可能残高の範囲内であること
(5)海外ATMサービスを利用するには、事前に支店窓口又はWebでの申込みが必要である。申込みの受付は、平日の8:00から21:00までとする。
(6)海外ATMサービスでは、リアルタイムで海外ATMからの出金取引を可能にする。ただし、日曜日の21:00から翌月曜日の7:00までについては、業務提携会社D社に海外ATMサービスの業務代行を委託する。D社は、既に海外でのATMサービスの業務代行を24時間365日実施するシステム(以下、D社システムという)を稼働させている。
(7)D社で代行処理する出金取引の場合も(4)と同じチェックを行う。
(8)D社で代行処理した出金取引については、代行処理時間終了後に、E銀行システム宛てに送信し、E銀行元帳に反映する。この元帳反映時には、E銀行で(4)のチェックを再度行う。
(9)キャッシュカードを保有している全口座(約500万口座)のうち、3年間で約5%の25万口座が海外ATMサービスの対象になると予測している。また、海外ATMの1日の出金取引件数は約2,400件、全時間帯でほぼ同様な取引件数になると予測している。
〔ATMヘルプデスクの業務〕
(1)E銀行では、国内ATMサービス稼働時間帯は、ヘルプデスクで、顧客の入出金状況の照会対応、事故カードの設定など各種届出の受付・設定を実施している。事故カードの設定の受付時は、店番号・口座番号、顧客名、顧客住所及び顧客電話番号を確認した上で、設定処理を行っている。
(2)代行処理時間帯については、ヘルプデスクの業務もD社に委託する。委託内容は、海外ATMサービスを申し込んだ顧客だけについて、D社のヘルプデスクで出金状況の照会及び事故カードの設定を行うこととし、事故カードの設定の受付時は、E銀行と同じ確認をした上で、設定処理を行う。
〔海外ATM利用時の処理概要〕
海外ATM利用時のデータの流れを図1に、曜日・時間帯ごとの処理概要を図2に示す。海外ATMの利用時は、海外共通ネットワーク及びD社システムを経由して、E銀行元帳を更新する。時間帯によって、D社システムで代行処理を行い、D社の代行口座元帳データベース(以下、D社元帳という)を更新する。
代行処理した取引の件数が増加した場合、図2の処理3の開始時刻の見直しを行う。見直しを行わない場合、E銀行元帳に不整合が生じる可能性がある。
〔D社元帳の更新処理の概要〕
D社で代行処理を行うために、海外ATMサービス対象口座(以下、対象口座という)について、E銀行元帳の情報を基に、D社元帳の更新を行う。
E銀行からD社への送信データ及びD社元帳の属性を表1に、D社元帳の更新処理の概要を表2に示す。
D社元帳は、次の2種類のタイミングで更新を行うことにし、D社帳の整合性を確保する対応をD社で実施する。
(1)E銀行がバッチ処理で送信したデータについては、全データ受信後にD社元帳を更新する。全データ受の終了予想時刻は2:00、D社元帳の更新処理性能は3,000件/分である。
(2)E銀行がリアルタイムで送したデータについては、受信後、即時にD社帳を更新する。
〔商品企画部からの追加要望〕
商品企画部からの追加要望とその対応を表3に示す。

設問1:〔海外ATM利用時の処理概要〕について、(1)、(2)に答えよ
(1)図2中の処理3の開始時刻を見直す必要があるのは、日の代行取引件数が何件を超える場合か。その件数を答えよ。
模範解答
1800
解説
解答の論理構成
-
処理速度の前提を確認
【問題文】の図2処理3説明に
「D社からの送信時間は、1件/秒である。」
と明示されています。 -
処理に充てられる時間を把握
同じく図2処理3説明に
「代行処理した取引の送信は、6:30から開始し、国内ATMサービスが開始する7:00までに完了させる。」
とあります。よって送信可能な時間は
7:00 − 6:30 = 0.5 時間 = 30 分 = 1,800 秒。 -
送信可能件数を計算
送信速度 1件/秒 × 1,800秒 = 1,800件。 -
境界の決定
「代行処理した取引の件数が増加した場合、図2の処理3の開始時刻の見直しを行う。」
との注意書きにより、1,800件を超えると完了できず E銀行元帳に不整合 が生じる危険があるため、見直し条件は “1,800件を超える場合” となります。
誤りやすいポイント
- 30分=30秒と読み違え、30件と計算してしまう。
- “1取引ごとに送信” をバッチ送信と誤解し、同時並列送信を想定して件数を過大評価する。
- 見直し条件を「1,800件ちょうど」ではなく「1,799件」を超えた時点と勘違いする。
FAQ
Q: 「事故カードの設定」も 1取引として 1秒かかるのですか?
A: はい。図2処理3の①で「出金取引及び事故カードの設定を、取引発生順に1取引ごとに」送信すると明記されています。したがって両者とも 1件/秒の扱いです。
A: はい。図2処理3の①で「出金取引及び事故カードの設定を、取引発生順に1取引ごとに」送信すると明記されています。したがって両者とも 1件/秒の扱いです。
Q: 6:30より前に送信を始めればよいのでは?
A: そのとおりで、送信総件数が1,800件を超える場合は「処理3の開始時刻の見直し」を行い、前倒しして 7:00開始の国内ATMサービスまでに完了させる運用を検討します。
A: そのとおりで、送信総件数が1,800件を超える場合は「処理3の開始時刻の見直し」を行い、前倒しして 7:00開始の国内ATMサービスまでに完了させる運用を検討します。
関連キーワード: スループット、バッチ処理、リアルタイム更新、タイムウィンドウ
設問1:〔海外ATM利用時の処理概要〕について、(1)、(2)に答えよ
(2)図2中の処理3の開始時刻の見直しを行わない場合、E銀行元帳に不整合が生じる可能性がある。。その理由を35字以内で述べよ。
模範解答
代行処理した取引と国内 ATM取引の順序が逆転する可能性があるから
解説
解答の論理構成
- 処理3の前提
- 「代行処理した取引の送信は、6:30から開始し、国内ATMサービスが開始する7:00までに完了させる。」
- 送信速度は「1件/秒」。
- 背景イベント
- 国内ATMは「月曜日7:00」から稼働し、出金等を「リアルタイムでE銀行元帳を更新」する。
- 潜在的な問題
- もし6:30〜7:00で送り切れず、7:00を過ぎても D社側の送信が残っていると、
①国内ATM→元帳書込み
②その後に遅延した代行取引→元帳書込み
の順となり、実際の発生順(②→①)と逆になります。
- もし6:30〜7:00で送り切れず、7:00を過ぎても D社側の送信が残っていると、
①国内ATM→元帳書込み
- 帳尻が狂う理由
- 出金額は“支払可能残高”で判定します。順序が逆だと、残高が足りる/足りないの評価が変わるケースが生じ、元帳の整合性が破綻します。
- したがって
- 開始時刻を見直さなければ「代行処理した取引と国内ATM取引の順序が逆転する可能性があるから」という解答になります。
誤りやすいポイント
- 件数の大小に目を奪われ、1件/秒×30分=1,800件という送信能力を計算し忘れる。
- 「海外ATM取引が少ないから問題なし」と早合点し、国内ATMの即時書込みを軽視する。
- 不整合=データ欠落と誤解し、「未反映だから」と書いてしまう。実際は“順序”が論点です。
FAQ
Q: なぜ国内ATMだけを問題視するのですか?
A: 「月曜日7:00」以降に最初に元帳へ到達するのが国内ATMであり、代行分が後着すると実際の時系列と逆になるためです。
A: 「月曜日7:00」以降に最初に元帳へ到達するのが国内ATMであり、代行分が後着すると実際の時系列と逆になるためです。
Q: 残り件数が少なければ影響はないのでは?
A: 1件でも順序が逆になれば残高判定が変わり得ます。安全を確保する設計では「可能性」を排除する必要があります。
A: 1件でも順序が逆になれば残高判定が変わり得ます。安全を確保する設計では「可能性」を排除する必要があります。
Q: 開始時刻以外の対策は?
A: 代行分のバッチ化やトランザクションのタイムスタンプ比較で到着順ではなく発生順に更新する方法もありますが、本件仕様では開始時刻調整が最も低コストです。
A: 代行分のバッチ化やトランザクションのタイムスタンプ比較で到着順ではなく発生順に更新する方法もありますが、本件仕様では開始時刻調整が最も低コストです。
関連キーワード: トランザクション整合性、競合制御、残高チェック、リアルタイム更新
設問2:【D社帳の更新処理の概要〕について、(1)、(2)に答えよ。
(1)リアルタイムでの送信時に送信を省略した属性は何か。三つを全て答えよ。また、省略しても問題がないと判断した理由を述べよ。
模範解答
属性:顧客名、顧客住所、顧客電話番号
理由:
・三つの属性は、日曜日には更新されないから
・三つの属性の変更は、平日だけ可能だから
解説
解答の論理構成
- 送信対象となる全属性の確認
表1には送信データとして「顧客名、顧客住所、顧客電話番号」などが列挙されています。 - リアルタイム送信が行われる時間帯
表2の「日曜日の0:00〜21:00」にリアルタイム送信を行う旨を確認します。 - 顧客属性の更新が行われる時間帯
【問題文】(3) に「平日の8:00から21:00まで支店窓口で受け付けている」と明記されています。 - 両者を突き合わせて結論
リアルタイム送信が行われる「日曜日」には顧客名・住所・電話番号が更新されないため、送信を省略しても整合性を損なわないと判断できます。 - したがって、電文長削減の対象は「顧客名」「顧客住所」「顧客電話番号」となります。
誤りやすいポイント
- 「事故カードの設定情報」も平日窓口業務と勘違いして省略候補に入れてしまう
→ 代行処理時間帯に「事故カードの設定」を受け付けるため、省略不可です。 - 「支払可能残高」を省略しても良いと考える
→ 出金可否判定に必須なので送信必須です。 - 平日と休日の区分を日本時間で考え忘れる
→ 全て「曜日・時間はすべて日本を基準」に示されている点に注意します。
FAQ
Q: 電文長削減は他の曜日でも適用できますか?
A: いいえ。「日曜日の0:00〜21:00」でのみ電文長制約に対応するリアルタイム送信があります。平日はこの方式を採用していません。
A: いいえ。「日曜日の0:00〜21:00」でのみ電文長制約に対応するリアルタイム送信があります。平日はこの方式を採用していません。
Q: 今後、休日窓口を拡大した場合は同じ三属性を省略できますか?
A: 顧客属性変更の受付時間が休日にも広がれば、送信省略によって不整合が起こる可能性が出るため、再検討が必要です。
A: 顧客属性変更の受付時間が休日にも広がれば、送信省略によって不整合が起こる可能性が出るため、再検討が必要です。
Q: 「顧客名」など文字列以外の項目で省略候補はありますか?
A: ありません。出金判定や本人特定に直接用いるデータはリアルタイムで必須です。
A: ありません。出金判定や本人特定に直接用いるデータはリアルタイムで必須です。
関連キーワード: リアルタイム送信、電文長、顧客属性、バッチ処理、整合性
設問2:【D社帳の更新処理の概要〕について、(1)、(2)に答えよ。
(2)D社元帳の整合性を確保する対応をD社で実施する必要がある。どのような対応が必要か。40字以内で述べよ。
模範解答
リアルタイムで更新した口座は、バッチ処理で受信したデータで更新しない。
解説
解答の論理構成
- リアルタイム更新の性質
- 【問題文】「(2)E銀行がリアルタイムで送したデータについては、受信後、即時にD社帳を更新する。」
- よって 0:00 以降に発生した残高変動は即座に D社元帳へ反映される。
- バッチ更新の性質
- 【問題文】「(1)E銀行がバッチ処理で送信したデータ…抽出日の0:00時点で完了している取引までを反映」
- バッチデータはリアルタイム更新より“古いスナップショット”である。
- 不整合が起こるケース
- 同一口座に対し、①0:30 にリアルタイム送信→最新残高に更新
②1:30 に同日のバッチデータ受信→0:00 時点の残高で上書き - これでは「D社元帳」と「E銀行元帳」で差異が生じる。
- 同一口座に対し、①0:30 にリアルタイム送信→最新残高に更新
- 必要な対応策
- 古いスナップショットであるバッチデータを適用する際、直近の「抽出日時」またはフラグを確認し、「リアルタイム更新済み」口座のバッチ適用をスキップする。
- 結論として「リアルタイムで更新した口座は、バッチ処理で受信したデータで更新しない」が正答となる。
誤りやすいポイント
- 「バッチが後に来る=最新」と思い込み、時点管理を見落とす。
- バッチとリアルタイムの重複検知を「口座番号だけで判定する」とし、取引時刻を考慮しない。
- 「D社元帳の更新処理性能は3,000件/分」を速度調整の根拠と誤解し、論点を性能に寄せてしまう。
FAQ
Q: 抽出日時を比較する以外にフラグ管理でもよいですか?
A: 可能です。重要なのは「リアルタイム更新済み」を識別し、古いデータを適用しないことです。方法としては抽出日時比較、更新フラグ、または更新シーケンス番号などがあります。
A: 可能です。重要なのは「リアルタイム更新済み」を識別し、古いデータを適用しないことです。方法としては抽出日時比較、更新フラグ、または更新シーケンス番号などがあります。
Q: バッチを完全に止めてリアルタイムだけにすればよいのでは?
A: 対象口座約「25万口座」の全件同期を毎週実施する設計意図(大量データの一括整備)があるため、バッチを廃止すると業務・運用フローを大きく変える必要が生じます。整合性維持策を入れる方が低コストです。
A: 対象口座約「25万口座」の全件同期を毎週実施する設計意図(大量データの一括整備)があるため、バッチを廃止すると業務・運用フローを大きく変える必要が生じます。整合性維持策を入れる方が低コストです。
Q: 抽出日の「0:00」を別時間に変えれば解決しますか?
A: 時点を動かしても“古いスナップショット”である事実は変わりません。リアルタイム更新との重複は残るため、本設問の対応策が必要です。
A: 時点を動かしても“古いスナップショット”である事実は変わりません。リアルタイム更新との重複は残るため、本設問の対応策が必要です。
関連キーワード: リアルタイム更新、バッチ処理、データ整合性、スナップショット、二重更新
設問3:〔商品企画部からの追加要望〕について、(1)、(2)に答えよ。
(1)表3中の要望1の対応によって、E銀行元帳の更新に影響が出る口座はどのような口座か。35字以内で述べよ。また、影響を回避するために行ったチェック方法の変更内容を25字以内で述べよ。
模範解答
口座:代行処理時間中に出金、事故カードの設定の順で取引をした口座
変更内容:事故カードの設定の有無をチェックしない。
解説
解答の論理構成
- 通常チェックの確認
【問題文】(4)②では「事故カードの設定という)がないこと」を出金実行条件にしています。 - 送信順序の変更
表3 要望1の対応内容で「事故カードの設定…出金取引よりも先に送信」と仕様変更しました。 - 時系列の食い違い
代行処理時間帯では実際の発生順が「出金→事故カード」ですが、送信順が「事故カード→出金」になります。 - 影響が出る口座
この順序逆転が存在する口座だけが、E銀行側チェック(4)②により出金が否認されるため「影響が出る口座」となります。 - 回避策
送信対象が代行処理済みの取引であることを前提に、反映時は「事故カードの設定有無をチェックしない」ようにチェックロジックを緩和します。これにより実際の取引順を尊重しつつ整合性を確保できます。
誤りやすいポイント
- 「事故カード設定が先→出金が後」と誤解し、影響口座を逆に書いてしまう。
- チェックを全面的に廃止と勘違いし、通常時間帯の出金まで対象に含めてしまう。
- 送信順序の変更が「同時送信」だと考え、影響がないと判断してしまう。
FAQ
Q: なぜ事故カード設定チェックを完全に外しても安全なのですか?
A: 対象は「代行処理済みで時系列が保証された取引」に限定されるため、リアルタイム出金には従来チェックを継続します。
A: 対象は「代行処理済みで時系列が保証された取引」に限定されるため、リアルタイム出金には従来チェックを継続します。
Q: 送信順序を変更せずに整合性を取る方法は?
A: 送信順序を維持しながら、E銀行側で事故カード設定を優先適用する排他制御を追加する方法がありますが、処理複雑化と送信遅延の懸念があります。
A: 送信順序を維持しながら、E銀行側で事故カード設定を優先適用する排他制御を追加する方法がありますが、処理複雑化と送信遅延の懸念があります。
Q: 全口座を海外ATM対象にしても今回の問題は起きますか?
A: 起きます。対象口座数は影響せず、順序逆転そのものが問題です。
A: 起きます。対象口座数は影響せず、順序逆転そのものが問題です。
関連キーワード: リアルタイム送信、事故カード、データ整合性、チェックロジック、時系列制御
設問3:〔商品企画部からの追加要望〕について、(1)、(2)に答えよ。
(2)表3中の要望2については、初の仕様のままとした。全口座を海外ATMサービス付与の対象とした場合、どのような問題が発生するか。D社元帳の更新処理の観点から40字以内で述べよ。
模範解答
D社元帳の更新処理時間が大幅に増加し,1日では更新できなくなる。
解説
解答の論理構成
- 対象口座数の確認
- 【問題文】「キャッシュカードを保有している全口座(約500万口座)」
- 処理時間枠の確認
- 表2「土曜日の0:00〜2:00及び日曜日の0:00〜2:00」でバッチ抽出・送信
- (1)「全データ受信後に D社元帳を更新する。…終了予想時刻は2:00」
→ 更新処理自体に確保できるのは 120 分。
- 更新性能の確認
- (1)「D社元帳の更新処理性能は3,000件/分」
→ 120 分 × 3,000 件/分 = 360,000 件
- (1)「D社元帳の更新処理性能は3,000件/分」
- ボトルネックの導出
- 必要件数 5,000,000 件 > 処理能力 360,000 件
→ 未処理 4,640,000 件が残る
- 必要件数 5,000,000 件 > 処理能力 360,000 件
- 影響
- バッチが翌日にずれ込み、リアルタイム反映や国内 ATM の開始前整合確認に間に合わず、データ不整合・サービス停止リスクが発生
→ 模範解答のとおり「1日では更新できなくなる」。
- バッチが翌日にずれ込み、リアルタイム反映や国内 ATM の開始前整合確認に間に合わず、データ不整合・サービス停止リスクが発生
誤りやすいポイント
- 「抽出は土曜・日曜に分割されるから大丈夫」と考え、更新処理性能を無視する。
- 更新性能 3,000 件/分を「送信速度」と誤認し、重複計算してしまう。
- 「25 万口座→500 万口座」で 20 倍と気付きながら、処理時間枠も 20 倍必要と気付かない。
FAQ
Q: 抽出・送信が終われば更新は並列で進むのでは?
A: (1)で「全データ受信後に D社元帳を更新する」と明示されており、並列実行できません。
A: (1)で「全データ受信後に D社元帳を更新する」と明示されており、並列実行できません。
Q: 日曜 0:00〜21:00 のリアルタイム送信で補完できないのか?
A: ここは「送信」だけで、バッチ更新が完了していないと元帳の整合性が取れません。処理遅延は解消できません。
A: ここは「送信」だけで、バッチ更新が完了していないと元帳の整合性が取れません。処理遅延は解消できません。
関連キーワード: バッチ処理、処理性能、データ連携、スループット


