システムアーキテクト試験 2023年 午後1 問03
融資保証システムの再構築に関する次の記述を読んで、設問に答えよ。
L社は、大手クレジットカード会社である。L社は、融資保証で利用している融資保証システム（以下、現行システムという）の老朽化に伴い、新システムを構築することにした。
〔融資保証の概要〕
L社は、金融機関と提携し、法人顧客（以下、顧客という）に融資保証をしている。融資保証をすることで、顧客から所定の信用保証料（以下、保証料という）を受け取り、万が一、顧客の借入金の返済が滞った場合に、顧客に代わって金融機関に立替払をする。L社が融資保証をすることで、顧客には金融機関から融資枠の拡大や融資を受けやすくなるというメリットがある。融資保証の概要は、次のとおりである。
（1）申込み
顧客は、事業資金を調達するために、金融機関へ融資の申込みと同時にL社への保証委託を申し込む。L社への保証委託の申込みは、金融機関を通じて行う。
（2）承諾
L社は、顧客の事業内容、経営計画や申込人である顧客代表者の信用情報などを確認し、保証可能と判断した場合は金融機関に保証を承諾する旨を連絡する。
（3）融資
金融機関は、顧客と融資契約を締結し、顧客へ融資を実行する。この際、顧客は、所定の保証料を、金融機関を通じてL社へ支払う。L社は、金融機関と保証約を締結し、顧客と保証委託契約を締結する。
（4）返済
顧客は、返済条件に基づき借入金を金融機関に返済する。
（5）代位弁済
諸事情で顧客の借入金の返済が滞った場合、金融機関からの請求に基づき、L社が借入金残高の全額を顧客に代わって金融機関に立替払をし、その後、顧客はL社に返済する。
それぞれの契約関係の概要を図1に示す。
〔現在の業務と現行システムの概要〕 L社では、現行システムを利用し、融資保証をしている。金融機関と事前に締結している保証取引基本契約に基づき決められた融資保証の条件を融資保証商品（以下、商品という）として管理している。金融機関からの融資保証の申込みは、金融機関側の都合によりファックス（以下、FAXという）で受け付けている。申込みには、新規申込と契約変更申込の二つの種別（以下、申込種別という）があり、申込種別の単位に異なるFAX番号を設定して、金融機関と申込種別の単位で担当者を割り当てている。また、個人情用情報を外部用機関から取得し、審査に利用している。L社では、全てのシステムで遵守が求められている情報セキュリティ規則で、外部用機関との接続は特定の端末（以下、外信端末という）に限定しており、社内のネットワーク及びシステムとの接続を許可していない。現在の主な業務と現行システムの概要は、次のとおりである。ここで、契約変更申込の業務は省略している。 （1）保証申込業務 L社は、金融機関から顧客の財務諸表、保証委託契約申込書及びその他必要な書類（以下、申込書類という）をFAXで受する。申込対象の商品は、保証委託契約申込書に記載されている。商品ごとに必要な申込書類が異なっており、担当者は必要な申込書類とその内容を業務マニュアルで確認している。申込書類に不備があった場合、FAX送元の金融機関に問い合わせる。不備がなかった場合、現行システムに申込書類の内容を入力し、保証案件として登録する。現行システムは、保証案件の契約状態を管理しており、保証申込の受付時の契約状態を“受付中”にする。 （2）保証審査業務 担当者は、申込書類の記載内容を基に申込人の個人信用情報を外信端末で確認し、確認した内容を現行システムに入力する。また、顧客の売上高、用格付及び商品ごとの保証料の算出に用いる利率から保証料を計算し、現行システムに入力する。審査に必要な内容を現行システムに入力した後、保証審査を決裁者に依頼する。決裁者は、現行システムに入力されている保証案件の内容を確認して審査を行い、保証可能と判断した場合、可決と判定し、契約状態を“実行待ち”にする。保証不可能と判断した場合、否決と判定し、契約状態を“無効”にする。担当者は、契約状態を基に回答書を作成し、金融機関へFAXで送信する。回答書には、判定の結果と保証可能な場合だけ保証料を記載している。 （3）保証料入金及び保証契約書類受領業務 金融機関で顧客に融資が実行された際、顧客が金融機関を通じて保証料を入金する。L社は、保証料が全額入金されていること、及び金融機関から保証契約書類を受領していることを確認し、対応する保証案件の契約状態を“実行中”にする。また、外部信用機関に保証開始の報告をする。 （4）融資残高管理業務 L社は、金融機関から融資残高のデータ（以下、残高データという）を、毎月、第1営業日に受領する。金融機関から送付された残高データを現行システムに取り込み、保証案件ごとに融資残高を更新する。完済された融資があった場合、対応する保証案件の契約状態を“終了”にして、外部用機関に保証完了の報告をする。また、担当者は、必要に応じて現行システムを参照し、融資残高レポートを作成して経営層に報告している。融資残高レポートには、全ての保証案件が代位弁済になった場合にL社が金融機関に支払う金額を記載する。 （5）代位弁済管理業務 金融機関から代位弁済請求書を受領した場合、対応する保証案件の契約状態を“代弁”にする。契約状態が“代弁”となった保証案件は、債権管理システムに登録し、その後の業務を債権管理システムで実施する。
〔現在の業務と現行システムの概要〕 L社では、現行システムを利用し、融資保証をしている。金融機関と事前に締結している保証取引基本契約に基づき決められた融資保証の条件を融資保証商品（以下、商品という）として管理している。金融機関からの融資保証の申込みは、金融機関側の都合によりファックス（以下、FAXという）で受け付けている。申込みには、新規申込と契約変更申込の二つの種別（以下、申込種別という）があり、申込種別の単位に異なるFAX番号を設定して、金融機関と申込種別の単位で担当者を割り当てている。また、個人情用情報を外部用機関から取得し、審査に利用している。L社では、全てのシステムで遵守が求められている情報セキュリティ規則で、外部用機関との接続は特定の端末（以下、外信端末という）に限定しており、社内のネットワーク及びシステムとの接続を許可していない。現在の主な業務と現行システムの概要は、次のとおりである。ここで、契約変更申込の業務は省略している。 （1）保証申込業務 L社は、金融機関から顧客の財務諸表、保証委託契約申込書及びその他必要な書類（以下、申込書類という）をFAXで受する。申込対象の商品は、保証委託契約申込書に記載されている。商品ごとに必要な申込書類が異なっており、担当者は必要な申込書類とその内容を業務マニュアルで確認している。申込書類に不備があった場合、FAX送元の金融機関に問い合わせる。不備がなかった場合、現行システムに申込書類の内容を入力し、保証案件として登録する。現行システムは、保証案件の契約状態を管理しており、保証申込の受付時の契約状態を“受付中”にする。 （2）保証審査業務 担当者は、申込書類の記載内容を基に申込人の個人信用情報を外信端末で確認し、確認した内容を現行システムに入力する。また、顧客の売上高、用格付及び商品ごとの保証料の算出に用いる利率から保証料を計算し、現行システムに入力する。審査に必要な内容を現行システムに入力した後、保証審査を決裁者に依頼する。決裁者は、現行システムに入力されている保証案件の内容を確認して審査を行い、保証可能と判断した場合、可決と判定し、契約状態を“実行待ち”にする。保証不可能と判断した場合、否決と判定し、契約状態を“無効”にする。担当者は、契約状態を基に回答書を作成し、金融機関へFAXで送信する。回答書には、判定の結果と保証可能な場合だけ保証料を記載している。 （3）保証料入金及び保証契約書類受領業務 金融機関で顧客に融資が実行された際、顧客が金融機関を通じて保証料を入金する。L社は、保証料が全額入金されていること、及び金融機関から保証契約書類を受領していることを確認し、対応する保証案件の契約状態を“実行中”にする。また、外部信用機関に保証開始の報告をする。 （4）融資残高管理業務 L社は、金融機関から融資残高のデータ（以下、残高データという）を、毎月、第1営業日に受領する。金融機関から送付された残高データを現行システムに取り込み、保証案件ごとに融資残高を更新する。完済された融資があった場合、対応する保証案件の契約状態を“終了”にして、外部用機関に保証完了の報告をする。また、担当者は、必要に応じて現行システムを参照し、融資残高レポートを作成して経営層に報告している。融資残高レポートには、全ての保証案件が代位弁済になった場合にL社が金融機関に支払う金額を記載する。 （5）代位弁済管理業務 金融機関から代位弁済請求書を受領した場合、対応する保証案件の契約状態を“代弁”にする。契約状態が“代弁”となった保証案件は、債権管理システムに登録し、その後の業務を債権管理システムで実施する。
〔新システムへの要望〕
新システムに対して、利用部門の担当者から次のような要望が出された。
（a）インターネット経由で申込みができるポータルサイトを金融機関に提供したい。ポータルサイトでは、金融機関から審査状況の問合せや保証申込の結果を照会できるようにしたい。ただし、ポータルサイトが利用できない金融機関もあるので、FAXでの受付は継続したい。
（b）FAXで受信した申込書類を電子化し、新システムで参照できるようにしてほしい。また、受信した申込書類を一覧化し、担当者を割り当ててほしい。
（c）申込書類の内容を新システムに入力する業務を効率的にしてほしい。
（d）業務マニュアルを用いて実施している、必要な申込書類がそろっているかどうかのチェックを新システムで行ってほしい。
（e）外部用機関から情報を取得する機能を設けて、新システムで確認できるようにしてほしい。
（f）保証審査業務で必要な保証料を新システムで算出してほしい。
（g）保証審査業務で決裁者が審査する前に、新システムで確認可能な項目を用いて顧客に関する1次審査を行ってほしい。
（h）新システムで作成した回答書をFAXで金融機関に送付してほしい。
（i）保証申込業務と保証審査業務の作業の進捗状況が分かるようにしてほしい。
（j）金融機関からの保証料の入金を入金データとして新システムに取り込み、保証案件と突合してほしい。また、保証料が全額入金されたことが分かるようにしてほしい。
（k）保証可能と判断した後に、ある条件を満たした場合、新システムで契約状態を“実行中”に変更してほしい。
（l）融資残高レポートを新システムから出力してほしい。
〔新システムの方針〕
L社情報システム部のM課長は、次のような新システム構築の方針を立てた。①新システムへの要望のうち、一部の要望は、ある理由から新システムへの実装はL社として不適合と判断し、見送ることで利用部門と合意した。
・保証申込業務と保証審査業務の作業の進捗状況の可視化を目的として、保証案件に申込状態を設けて、管理する。
・保証料が全額入金されたことを管理するために、保証案件に入金状態を設ける。
・保証契約書類を金融機関から受領したことを管理するために、保証案件に書類受領状態を設ける。
・FAXで受信した情報を電子化するFAXサーバを導入する。FAXサーバからは、ヘッダー情報として送信日時、送信元FAX番号、受日時及び受情FAX番号、明細情報として申込書類イメージデータを取得する。
・申込書類の内容を新システムに入力する業務の効率化を目的として、OCRを導入しFAXで受信した申込書類イメージデータを読み取る。
〔新システムの設計〕
新システムへの要望と方針を踏まえ、M課長は、新システムの設計を次のように検討している。新システムの主な機能概要を表1に示す。
融資保証システムの再構築に関する次の記述を読んで、設問に答えよ。
設問1
本文中の下線①について、見送ることにした要望を〔新システムへの要望〕中の(a)~(l)で答えよ。また、見送ることにした理由を40字以内で答え
模範解答
要望：(e)
理由：情報セキュリティ規則で外部信用機関との接続は外信端末に限定しているから
解説
解答の論理構成
- 下線①は「一部の要望は…見送る」と述べているため、どの要望が社内ルールに反しているかを探す。
- 要望（e）「外部用機関から情報を取得する機能を設けて、新システムで確認できるようにしてほしい。」は、新システムが社内ネットワーク上で外部用機関と通信することを前提とする。
- これに対し【問題文】には「情報セキュリティ規則で、外部用機関との接続は特定の端末（以下、外信端末という）に限定しており、社内のネットワーク及びシステムとの接続を許可していない。」という制約が存在。
- したがって要望（e）は規則違反となり、新システムに組み込めない。
- M課長はこの理由で「不適合」と判断し、利用部門と見送りで合意した。
誤りやすいポイント
- 「ポータルサイトが利用できない金融機関もあるので、FAXでの受付は継続したい。」との記述から(a)を見送りと勘違いする。実際にはFAX併用で要望自体は採用。
- 「1次審査」自動化をセキュリティ上の理由で却下と考え、(g)を選んでしまう。
- 「外部用機関」と「外部信用機関」を別物と読み違え、規則の適用範囲を誤認する。
FAQ
Q: 外信端末は完全にスタンドアロンなのですか？
A: 文面上、「社内のネットワーク及びシステムとの接続を許可していない」とあるため、スタンドアロン運用が前提です。
A: 文面上、「社内のネットワーク及びシステムとの接続を許可していない」とあるため、スタンドアロン運用が前提です。
Q: 将来的に規則が緩和されたら要望（e）は実装できますか？
A: 規則改定後にリスク評価を行い、システム要件を再策定すれば実装可能です。ただし現行規則下では不可です。
A: 規則改定後にリスク評価を行い、システム要件を再策定すれば実装可能です。ただし現行規則下では不可です。
Q: 申込状態や入金状態の追加はどの要望に対応していますか？
A: 「作業の進捗状況が分かるようにしてほしい」（i）と「保証料が全額入金されたことが分かるようにしてほしい」（j）への対応として設計されています。
A: 「作業の進捗状況が分かるようにしてほしい」（i）と「保証料が全額入金されたことが分かるようにしてほしい」（j）への対応として設計されています。
関連キーワード: 情報セキュリティ規則, 外部接続制限, FAXサーバ, OCR, 進捗管理
設問2
FAX受管理機能について、表1中の(a)～(d)に入れる適切な字句を答えよ。(a，b と c，dの組合せは順不同)
模範解答
a：送信元FAX番号
b：金融機関
c：受信FAX番号
d：申込種別
解説
解答の論理構成
- ヘッダ情報の取得内容を把握
【問題文】に「FAXサーバからは、ヘダー情報として送信日時、送信元FAX番号、受日時及び受情FAX番号」を取得するとあります。 - 送信元FAX番号と金融機関の対応
「金融機関からの融資保証の申込みは…FAX…で受け付けている」ことから、送信してくるのは金融機関側です。さらに「金融機関と申込種別の単位で担当者を割り当てている」とあるため、金融機関は送信元で特定できます。
⇒ (a) 送信元FAX番号 から (b) 金融機関 を導出 - 受信FAX番号と申込種別の対応
【問題文】「申込種別の単位に異なるFAX番号を設定して」と明示されており、L社側では申込種別ごとに番号を使い分けています。したがって受信側の番号を見れば申込種別が分かります。
⇒ (c) 受信FAX番号 から (d) 申込種別 を導出 - 結果
表１「FAX受信管理」の「ヘッダ情報の（a）から（b）を、（c）から（d）に導出し」の空欄に当てはめると、
a：送信元FAX番号／b：金融機関／c：受信FAX番号／d：申込種別 となります。
誤りやすいポイント
- 送信元と受信先を逆に読み替えてしまう
- 「金融機関コード」や「金融機関名」を直接ヘッダに載せると早合点し、導出という手順を見落とす
- 申込種別が新規／契約変更の２種類であることとFAX番号の関係を結び付けられない
FAQ
Q: 金融機関コードを直接ヘッダに持たせる設計では駄目なのですか？
A: 本問は現行業務を前提にしており、既に「申込種別の単位に異なるFAX番号を設定」という運用が確立しています。従来のFAX番号を活用し導出する設計が求められているため、コードを直接送出する変更までは想定していません。
A: 本問は現行業務を前提にしており、既に「申込種別の単位に異なるFAX番号を設定」という運用が確立しています。従来のFAX番号を活用し導出する設計が求められているため、コードを直接送出する変更までは想定していません。
Q: OCRで読み取った後も人手での確認は必要ですか？
A: 問題文にはOCR結果を「その内容をチェックする」とあり、完全自動ではなくチェック工程が残る設計です。OCR誤読や書類不足を補正するために人的確認は前提となります。
A: 問題文にはOCR結果を「その内容をチェックする」とあり、完全自動ではなくチェック工程が残る設計です。OCR誤読や書類不足を補正するために人的確認は前提となります。
関連キーワード: FAXサーバ, OCR, ヘッダ情報, 申込種別, ワークフロー
設問3
実行管理機能において、ある条件がそろった場合に保証案件の契約状態を“実行中”に変更している。その条件を設定している機能を表1中の機能名から全て答えよ。
模範解答
保証料管理，書類管理
解説
解答の論理構成
-
“ある条件”の内容を特定
- 【問題文】「実行管理」の機能説明
「契約状態が『実行待ち』の保証案件のうち、ある条件がそろった保証案件について契約状態を『実行中』に変更する。」 - 同じく【問題文】の方針には、条件候補として
「保証案件に入金状態を設ける。」
「保証案件に書類受領状態を設ける。」
が明示されています。
- 【問題文】「実行管理」の機能説明
-
条件を“設定”する機能を抽出
- 表1「保証料管理」
「保証料が全額入金されている場合、当該保証案件の入金状態を『入金済』に更新する。」 - 表1「書類管理」
「保証契約書類を金融機関から受領した際、当該保証案件の書類受領状態を『受領済』に更新する。」
- 表1「保証料管理」
-
両機能がそろえる状態が実行管理の判定材料
入金状態＝「入金済」かつ書類受領状態＝「受領済」 ⇒ “ある条件がそろった”と判断。 -
したがって、条件を設定している機能は
「保証料管理」「書類管理」
の2つであると導けます。
誤りやすいポイント
- 「審査管理」が“ある条件”を設定すると勘違い
審査は保証可否を決めるだけで、入金・書類の受領には関与しません。 - 「保証案件管理」で書類チェックを行うため、ここが条件設定と早合点
書類が“そろっているか”と、契約書類を“受領したか”は別概念です。 - 「金融機関用ポータルサイト管理」でのアップロード機能を条件と混同
受領確認は「書類管理」の仕事です。
FAQ
Q: “ある条件”は入金・書類受領のほかにも存在しますか？
A: 問題文に示されている新システムの方針では、入金状態と書類受領状態のみが実行管理のトリガーと読み取れます。他条件は言及されていません。
A: 問題文に示されている新システムの方針では、入金状態と書類受領状態のみが実行管理のトリガーと読み取れます。他条件は言及されていません。
Q: 実行管理が自動で“実行中”へ変更できないケースは？
A: 「保証料管理」で入金状態が「入金済」にならない、または「書類管理」で書類受領状態が「受領済」にならない場合です。その場合は「実行待ち」のまま残ります。
A: 「保証料管理」で入金状態が「入金済」にならない、または「書類管理」で書類受領状態が「受領済」にならない場合です。その場合は「実行待ち」のまま残ります。
Q: 入金データと保証案件の突合は全機能で共通ですか？
A: いいえ。入金データの突合は表1の「保証料管理」だけが担当します。他機能はその結果を参照するだけです。
A: いいえ。入金データの突合は表1の「保証料管理」だけが担当します。他機能はその結果を参照するだけです。
関連キーワード: ステータス管理, ワークフロー制御, OCR, ポータルサイト, トランザクション管理
設問4：融資残高管理機能について答えよ。
（1）融資残高がゼロになった保証案件の一覧を出力した帳票の利用目的を、業務的観点から25字以内で答えよ。
模範解答
外部信用機関に保証完了の報告をするため
解説
解答の論理構成
- 【問題文】「完済された融資があった場合、対応する保証案件の契約状態を“終了”にして、外部用機関に保証完了の報告をする。」
- 完済＝融資残高ゼロであるため、ゼロになった案件を抽出した帳票は、上記報告業務のために必要となる。
- よって帳票の利用目的は「外部信用機関への保証完了報告」である。
誤りやすいポイント
- 社内向け管理（内部統制・実績分析）が主目的と早合点する。
- “終了”＝システム完了処理のみで帳票不要と考えてしまう。
- 「外部用機関」と「外部信用機関」を別物と誤認する。文脈上同一の外部報告先です。
FAQ
Q: 内部監査資料としても使われませんか？
A: 二次利用は否定できませんが、問題が問う「利用目的」は業務フローで明示された外部信用機関への報告です。
A: 二次利用は否定できませんが、問題が問う「利用目的」は業務フローで明示された外部信用機関への報告です。
Q: 新システムで自動報告するなら帳票は不要では？
A: 問題文の設計では帳票出力を要件化しているため、現行手続きと同じく帳票で報告する前提です。
A: 問題文の設計では帳票出力を要件化しているため、現行手続きと同じく帳票で報告する前提です。
Q: “外部用機関”と“外部信用機関”はどちらを答える？
A: 【問題文】全体で一貫して保証開始・完了を報告する相手として“外部信用機関”が使われており、模範解答も同語を採用しています。
A: 【問題文】全体で一貫して保証開始・完了を報告する相手として“外部信用機関”が使われており、模範解答も同語を採用しています。
関連キーワード: 融資残高, 保証案件, 帳票出力, 外部信用機関, 完済報告
設問4：融資残高管理機能について答えよ。
（2）融資残高レポートに記載する“L社が金融機関に支払う金額”を求める方法を、契約状態を用いて35字以内で答えよ。
模範解答
保証案件の契約状態が“実行中”である融資残高を合計する。
解説
解答の論理構成
- レポートに載せる金額の定義
【問題文】「全ての保証案件が代位弁済になった場合にL社が金融機関に支払う金額」
⇒ 代位弁済が発生するとき支払うのは、まだ返済が済んでいない融資残高。 - どの契約状態が未返済か
新システム設計：- “実行待ち” … 融資実行前
- “実行中” … 融資実行済で返済中
- “終了” … 返済完了
- “代弁” … 既に立替済
返済途中＝“実行中”。
- 求め方
よって「契約状態が“実行中”の保証案件について融資残高を合計」すれば、求める金額になる。
誤りやすいポイント
- “受付中”や“実行待ち”も将来リスクと考えて含めてしまう
- “代弁”状態を二重計上（すでに支払済み）
- “終了”を残し、ゼロ残高でも合計に入れる
- 契約状態ではなく申込状態で抽出してしまう
FAQ
Q: “実行待ち”を含めない理由は?
A: “実行待ち”はまだ融資が実行されておらず残高が存在しないため、支払対象外です。
A: “実行待ち”はまだ融資が実行されておらず残高が存在しないため、支払対象外です。
Q: “代弁”状態の残高は?
A: “代弁”は既にL社が立替払を済ませた状態なので、将来支払う金額ではありません。レポートの趣旨と異なります。
A: “代弁”は既にL社が立替払を済ませた状態なので、将来支払う金額ではありません。レポートの趣旨と異なります。
Q: “終了”状態はゼロ残高とみなす?
A: はい。融資残高がゼロになった時点で契約状態が“終了”へ更新されるため、合計に含める必要はありません。
A: はい。融資残高がゼロになった時点で契約状態が“終了”へ更新されるため、合計に含める必要はありません。
関連キーワード: 契約状態, 融資残高, 残高合計, リスク管理, データ抽出
設問5
新システムへの要望を実現するために新システムで新たに商品ごとに管理しなければならない内容を、30字以内で全て答えよ。
模範解答
申込書類のチェックのルールと保証料の算出に用いる利率
解説
解答の論理構成
- 現行業務の確認
- 【問題文】「商品ごとに必要な申込書類が異なっており」とある。
- 【問題文】「商品ごとの保証料の算出に用いる利率から保証料を計算し」とある。
これにより、現行でも両要素は商品依存であることがわかる。
- 新システム要件の抽出
- 表1「保証案件管理」に「申込書類のチェックのルールに基づいて書類がそろっているかをチェックする」とある。
- 同表に「審査に必要な情報が登録された後、保証料を算出する」とある。
自動チェック・自動算出を行うためには、両要素をマスタ管理する必要が生じる。
- “商品管理”機能に追加すべき内容
- 表1「商品管理」の説明は「商品ごとに必要な内容を管理する」とだけ記載。具体項目は利用者が設計で補完する。
- ①チェック対象となる書類の組合せや要否を表す「申込書類のチェックのルール」
- ②保証料算出式に使う「保証料の算出に用いる利率」
以上が“新たに”必要となる商品属性である。
誤りやすいポイント
- 書類自体のイメージデータを商品管理に入れると誤解する。必要なのはチェックルールであり、ファイルは別機能で管理。
- 「保証料の算出に用いる利率」を顧客属性と誤認しがちだが、【問題文】で明確に「商品ごと」と示されている。
- 既存システムにない要素だけが対象。“既に商品に紐付いている情報”と混同すると漏れや重複が起きる。
FAQ
Q: 「チェックのルール」とは具体的に何を指すのですか？
A: 商品別に定義された必要書類の種類・部数・有効期限などの判定条件一式です。システムはこのルールを参照して入力済み書類を検証します。
A: 商品別に定義された必要書類の種類・部数・有効期限などの判定条件一式です。システムはこのルールを参照して入力済み書類を検証します。
Q: 利率以外の係数（例：手数料率）は不要ですか？
A: 【問題文】で自動算出に言及されている商品依存パラメータは「保証料の算出に用いる利率」のみのため、設問の範囲ではそれだけを答えます。
A: 【問題文】で自動算出に言及されている商品依存パラメータは「保証料の算出に用いる利率」のみのため、設問の範囲ではそれだけを答えます。
Q: 書類チェックはワークフロー機能で代替できませんか？
A: ワークフローは手続き管理であり、商品ごとに異なる判定条件を保持するデータがなければ自動化できません。よって別途マスタ管理が必要です。
A: ワークフローは手続き管理であり、商品ごとに異なる判定条件を保持するデータがなければ自動化できません。よって別途マスタ管理が必要です。
関連キーワード: マスタ設計, OCR, ワークフロー, 自動照合, パラメータ管理