合成データとは、実際の個人情報を一切使わずに、元データの統計的特性や変数間の相関を再現した人工的なデータセットです。本物の顧客データと区別がつかないほどリアルな分布を持ちながら、特定の個人に紐づく情報を含まない点が最大の特徴です。

本記事の対象読者は、マイクロファイナンス機関（MFI）や金融機関で AI モデルの開発・運用を担う担当者およびデータサイエンティストです。プライバシー規制への対応やデータ不足に悩みながら、信用スコアリングモデルの構築を目指している方を想定しています。

記事を読み終えると、次の 3 点が理解できます。

結論: 合成データはプライバシー規制への対応とデータ不足の解消を同時に実現できる、金融 AI 開発の有力な選択肢です。

信用スコアリングの開発では、実データの取得・利用に伴う法的リスクとデータ量の制約が大きな壁となりやすいです。合成データはこの二つの課題を同時に緩和できる点で注目されています。

信用スコアリングモデルの開発では、「実際の顧客データを使えば精度が上がる」と考えがちです。しかし実際には、実データをそのまま学習に使うことで、規制違反や情報漏洩リスクが生じるケースが報告されています。

金融機関が実データを扱う際に直面する主なリスクは以下の通りです。

• 再識別リスク: 氏名や口座番号を除いても、年齢・居住地・取引履歴の組み合わせから個人が特定される可能性がある
• 規制上の制約: GDPR（Regulation (EU) 2016/679）の Recital 26 は「匿名化されたデータは GDPR の適用範囲外」と定めているが、不完全な匿名化は保護対象外とみなされないリスクがある
• モデルリスク管理: 米国では SR 11-7（Supervisory Guidance on Model Risk Management）が学習データの適切な管理と検証を求めており、データガバナンスの不備はモデル承認の障壁になり得る
• データ収集コスト: MFI（マイクロファイナンス機関）では顧客同意の取得や安全な保管環境の整備に相当のコストと時間がかかる傾向がある

日本においても、改正個人情報保護法の全面施行（2017年5月30日）以降、匿名加工情報の基準を満たさない学習データの第三者提供は規制対象となっています。

このような制約を踏まえると、実データに依存したモデル開発は規制対応コストと情報漏洩リスクを同時に抱えることになります。

信用スコアリングモデルの開発で最初につまずくのが、学習データの絶対量不足とクラス不均衡の問題です。MFI では融資件数そのものが少なく、特にデフォルト事例は全体の数パーセントにとどまるケースが多いため、モデルが「正常返済」に偏った判定をしやすい構造的な課題があります。

合成データはこの問題に対して、次の 2 つのアプローチで対処します。

• データ量の補完: 実データが数百件しかない場合でも、統計的特性を保持した合成サンプルを数千件規模で追加生成し、モデルが汎化できる学習量を確保できます。
• 少数クラスの増強: デフォルト事例だけを狙い撃ちで合成生成することで、クラス比率を意図的に調整できます。

判断軸として覚えておきたいのは次の点です。実データが一定量あり不均衡が主な問題であれば、少数クラスの合成増強だけで対応できる場合があります。一方、実データ自体が極端に少ない場合は、全体的なデータ量の補完と少数クラス増強を組み合わせるアプローチが有効です。

ただし、合成データで増やしたサンプルが元の分布を正確に反映していなければ、モデルの精度はむしろ低下します。生成後の品質検証を省略しないことが前提条件となります。

「融資審査の実績データが少なすぎて、AI モデルの学習が進まない」——この壁は、多くの MFI 担当者が最初にぶつかる現実です。合成データはこの課題に対し、実務上いくつかの具体的なメリットをもたらします。

規制対応コストの削減 実データを外部ベンダーや開発環境に持ち出す場合、GDPR の仮名化要件や各国のデータローカライゼーション規制への対応が必要になります。合成データはそもそも個人を特定できる情報を含まないため、データ共有時の法的リスクと審査工数を大幅に抑えられる傾向があります。

少数クラス（デフォルト事例）の増幅 MFI の融資ポートフォリオでは、デフォルト件数が正常返済件数に比べて極端に少ないケースが多く見られます。合成データ生成によってデフォルト事例を人工的に増やすことで、モデルが稀なパターンを学習しやすくなります。

開発サイクルの短縮 実データの収集・匿名化・承認フローには数週間から数か月を要することがあります。合成データを活用すれば、プロトタイプ段階から十分なボリュームのデータセットを用意でき、モデル検証のサイクルを早められます。

チーム間のデータ共有の円滑化 データサイエンスチームとシステム開発チームが同一の合成データセットを安心して共有できるため、アクセス制限による作業の分断が起きにくくなります。

結論: 合成データ生成の品質は、着手前の準備段階で大きく左右される。元データの品質・プライバシー要件・生成手法の選定という三つの前提条件を整えることが、モデルの信頼性確保につながります。

合成データの品質は、元データの品質に直接依存します。「とりあえず生成ツールに投入すれば何とかなる」と考えがちですが、実際はゴミを入れればゴミが出る（Garbage In, Garbage Out）原則が合成データにも厳密に当てはまります。前処理の精度が、後工程のモデル性能を大きく左右します。

品質評価でまず確認したいのは、欠損値の分布です。ランダム欠損（MAR）なのか、特定属性に偏った欠損（MNAR）なのかを区別しておかないと、MNARのままデータを合成した場合に偏った分布がそのまま引き継がれてしまいます。あわせて、返済記録や取引金額に混入している入力ミスや一時的な異常値も事前に取り除いておく必要があります。合成モデルはこうした外れ値も「正しいパターン」として学習してしまうからです。信用スコアリング特有の問題として、デフォルト事例が全体の数パーセント程度にとどまるクラス不均衡も見落としやすいです。不均衡の度合いを定量的に把握せずに合成を始めると、少数クラスの再現性が著しく低下します。さらに、収入・借入残高・返済履歴といった変数間の相関構造を相関行列で記録しておくことで、合成後に「構造が壊れていないか」を検証する基準値として使えます。

前処理として具体的に行うのは、日付フォーマットや通貨単位（ラオス キープ（LAK）表記の揺れなど）の表記統一、変数ごとの欠損補完方針の決定（平均値・中央値・モデルベースのいずれが適切かは変数の性質による）、そして外れ値を削除するか上下限クリッピングで丸めるかを業務ルールに基づいて選択することです。この判断を曖昧なまま進めると、合成ステップで問題が表面化するのではなく、最終的なモデル評価の段階になって初めて原因が分からない性能劣化として現れることになります。

合成データ生成を始める前に、どのプライバシー保護レベルを満たす必要があるかを明確にしておくことが重要です。要件定義を後回しにすると、生成後に「規制要件を満たしていない」と判明し、作業をやり直すリスクがあります。

主な保護手法として以下の 2 つを押さえておきましょう。

• k-匿名化: 同じ属性の組み合わせを持つレコードが k 件以上存在するよう加工する手法。k=5 であれば、特定の年齢・職業・地域の組み合わせが 5 件未満にならないよう調整します。実装が比較的容易で、金融機関の内部利用に向いています。
• 差分プライバシー（Differential Privacy）: ノイズを付加することで、特定個人の情報がデータセットに含まれるかどうかを統計的に判別できないようにする手法。NIST SP 800-226 ではプライバシー係数 ε（epsilon）を用いた評価方法が定められており、ε が小さいほど保護強度が高くなります。

保護手法の選択はユースケースによって異なります。外部への合成データ提供や研究機関との共有を想定する場合は差分プライバシーが適しており、社内モデル学習のみに限定するケースでは k-匿名化でも対応できる場合があります。

また、GDPR の Recital 26 では「匿名化されたデータは GDPR の適用範囲外」とされています。ただし「匿名化」の基準は高く、仮名化（pseudonymisation）では適用範囲外とはならない点に注意が必要です。

「どの生成手法を選べばよいか分からない」という問いは、合成データ導入の現場で最初にぶつかる壁のひとつです。手法ごとに前提条件と得意領域が異なるため、プロジェクト要件に照らした選定が不可欠です。

主要な手法と選定の目安は以下のとおりです。

• 統計モデル（コピュラ・ベイジアンネットワーク等）: 表形式の金融データとの相性が良く、実装コストが低い。学習データが少ない MFI の初期段階に適しています。
• VAE（変分オートエンコーダ）: 連続変数と離散変数が混在するデータに対応しやすく、潜在空間での補間によって多様なサンプルを生成できます。
• GAN（敵対的生成ネットワーク）: 高い忠実性が期待できる一方、学習の不安定さ（モード崩壊）が起きやすく、チューニングコストが高くなる傾向があります。

選定時に確認すべき判断軸は次の 3 点です。

1. データ規模: 元データが数千件未満の場合、GAN の学習は不安定になりやすいため、統計モデルや VAE が現実的な選択肢です。
2. プライバシー要件: 差分プライバシー（ε 値の設定）を組み込む必要がある場合は、対応ライブラリが整備されている手法（例: DP-SGD と組み合わせ可能な VAE / GAN）を優先します。NIST SP 800-226 はプライバシー係数 ε の評価指針を示しており、要件定義の参照資料として活用できます。

結論: 合成データ生成は「元データ分析 → モデル選択 → 品質検証」の 3 ステップで進める。

元データの統計的特性を正確に把握したうえで、GAN・VAE・統計モデルから適切な手法を選び、生成後は忠実性とプライバシー保護の両面から品質を検証します。

合成データ生成を「とりあえず始める」アプローチは失敗しやすく、実際には元データの統計的特性を丁寧に把握してから生成ステップに進むほうが最終的な品質が格段に高まります。

まず確認すべき項目を整理します。

• 変数の分布形状: 連続変数（融資残高・月次返済額など）は正規分布か歪分布かを確認し、カテゴリ変数（職業区分・担保種別など）はクラス頻度を集計する
• 欠損パターン: 欠損が完全ランダム（MCAR）か、特定属性に偏った欠損（MAR・MNAR）かで生成モデルの設計が変わる
• 変数間の相関構造: スピアマン相関やクラメールの V などで数値・カテゴリ間の依存関係を可視化する
• クラス不均衡の程度: デフォルト率が低い MFI データでは、少数クラスの比率と件数を必ず把握する
• 時系列依存性: 返済履歴のように時間軸を持つ変数は、ラグ相関やトレンドも記録する

これらをまとめた「データプロファイルシート」を作成しておくと、Step 2 で生成モデルを選ぶ際の判断基準として機能します。

特に注意したいのが相関構造の扱いです。変数を独立に扱って個別に分布を再現しようとすると、生成データが現実の融資判断ロジックを反映しない歪んだサンプルになりがちです。ペアプロットや相関行列を使い、強い依存関係を持つ変数ペアを事前にリストアップしておくことが重要です。

最後に、元データの件数が少ない場合は統計的特性の推定精度自体が低くなるため、「推定の不確かさ」も記録しておくと、生成後の品質評価で役立ちます。

生成手法の選択は、手元にあるデータの規模と特性によって大きく変わります。大きく分けると、GAN系・VAE・統計モデルの3系統です。

GAN（敵対的生成ネットワーク）は、GeneratorとDiscriminatorが互いに競い合いながら学習することで、元データの分布に近いサンプルを生成します。表形式の金融データにはCTGANやTVAEが実績を持ちます。VAE（変分オートエンコーダー）は潜在空間への圧縮・復元という構造により、データの連続的な分布を滑らかに再現できるため、欠損値が多い信用スコアリングデータとの相性がよいとされています。統計モデル（コピュラ・ベイジアンネットワーク等）は変数間の依存構造を明示的にモデル化する手法で、解釈性が高く、規制対応の説明資料を求められるMFIに向いています。

どれを選ぶかは、データ量とインフラ環境によって判断が分かれます。学習サンプルが数万件以上あってGPU環境が整っているならGAN系が高い忠実性を発揮しやすく、数千件以下でかつ解釈性を重視するならコピュラ等の統計モデルのほうが安定した結果をもたらします。

実装面では、PythonライブラリのSDV（Synthetic Data Vault）やGretel.aiのオープンソース版がCTGAN・TVAE・GaussianCopulaをワンストップで提供しており、MFIのような小規模チームでも導入しやすい選択肢です。

「生成した合成データが本当に使えるものかどうか、どうやって確認すればいいのか」——現場でこの問いに直面するケースは少なくありません。品質検証は忠実性・多様性・プライバシーの三軸で行うのが基本です。

忠実性（Fidelity）の確認

元データと合成データの統計的特性が一致しているかを検証します。

• 各特徴量の平均・分散・歪度を比較する
• Kolmogorov–Smirnov 検定や Jensen–Shannon 距離で分布の乖離を定量化する
• 特徴量間の相関行列を並べて、関係構造が再現されているか目視確認する

多様性（Diversity）の確認

合成データが元データの少数クラスや外れ値を適切にカバーしているかを確認します。

• デフォルト事例（少数クラス）のサンプル比率が目標値を満たしているか確認する
• t-SNE や UMAP などの次元削減で元データと合成データの分布を重ねて可視化する
• 訓練用合成データで学習したモデルを実データで評価し、AUC の乖離が許容範囲内かを確認する（Train on Synthetic, Test on Real）

プライバシー（Privacy）の確認

NIST SP 800-226 では差分プライバシーの保証を評価する際にプライバシー係数 ε（epsilon）の定量評価を推奨しています。以下の観点でリスクを検証してください。

結論: 合成データは生成して終わりではなく、実データとの組み合わせ方やモデル選択の工夫が最終的な予測精度を左右する。

合成データを用いた信用スコアリングモデルの学習では、特徴量設計・データ混合比率・アルゴリズム選定の三つが鍵となります。各ステップを順に解説します。

合成データをそのままモデルに投入すれば精度が上がると考えがちですが、実際は特徴量の設計段階で合成データの使い方を整理しておくほうが効果的です。生成されたデータが元の分布を正確に再現していても、特徴量の意味を無視した組み合わせではモデルの汎化性能は向上しにくい傾向があります。

特徴量エンジニアリングの基本的な進め方は以下の通りです。

• 元データで特徴量を定義する: 返済履歴の遅延回数、借入残高対収入比率（DTI）、取引頻度など、信用リスクに関連する特徴量はまず実データから導出します
• 合成データで特徴量空間を拡張する: 実データだけではカバーできない稀なパターン（例：短期間に複数ローンを申請したケース）を合成データで補完し、モデルが学習できる事例を増やします
• スケーリングと変換は統一する: 実データと合成データで同一の前処理パイプライン（正規化・対数変換など）を適用しないと、分布の乖離がモデルに悪影響を与えます
• カテゴリ変数のエンコードに注意する: 職業区分や地域コードなどのカテゴリ変数は、合成データ生成時に元の頻度分布を引き継いでいるか確認してからエンコードします

MFI の文脈では、正式な銀行口座を持たない顧客の代替データ（携帯電話の支払い履歴、グループローンの返済記録など）を特徴量として組み込むケースが増えています。こうした代替特徴量は実データのサンプル数が少ないため、合成データで補完する効果が特に高い領域です。

合成データをどの割合で混ぜるかは、モデルの汎化性能を左右する重要な設計判断です。

実データが十分に確保できている場合は合成データの比率を比較的低く抑え、分布の補完に限定するのが安定した出発点とされています。一方、実データが極端に少ない立ち上げ期や、デフォルト事例が希少なクラス不均衡の状況では、合成データの比率を大きく引き上げてクラスバランスを補正するアプローチが有効です。

比率を決める際の実践的な手順を以下に示します。

• ベースライン確認: 実データのみでモデルを学習し、AUC・KS 統計を記録する
• 段階的な混合: 合成データを段階的に追加しながら同指標を再計測する
• 劣化の検出: 実データのみのベースラインと比較し、AUC が低下し始めた比率を「上限」として記録する
• PSI によるドリフト監視: 本番データへの適用後、Population Stability Index（PSI）で分布ズレを継続的に追跡する

注意すべき点として、合成データの比率を上げるほどモデルが「合成分布」を学習しやすくなり、実際の申込者分布との乖離が広がるリスクがあります。このため、混合比率の最終決定は検証セットを必ず実データのみで構成することが前提となります。合成データを検証セットに混入させると過大評価につながるため、学習セットと検証セットのデータソースを厳密に分離してください。

混合比率は固定値ではなく、データ蓄積状況に応じて定期的に見直すことが求められます。

「合成データで学習させるなら、どのモデルを選べば現場で使えるのか」という問いは、実装フェーズで最初にぶつかる壁です。

モデル選択の基本的な判断軸は、解釈可能性・精度・データ量の 3 点のバランスにあります。

ロジスティック回帰は、係数がそのまま各特徴量の影響度を示すため、融資担当者や監督当局への説明が容易です。合成データ特有の微細なノイズに対して過学習しにくい点も利点です。ただし、変数間の非線形な関係を捉えにくいため、信用スコアの分離性能に限界が生じるケースがあります。

**勾配ブースティング（XGBoost・LightGBM 等）**は、非線形パターンや変数間の交互作用を自動的に学習できるため、デフォルト予測の精度面で優位に立つ傾向があります。一方で、SHAP 値などの説明可能性ツールを併用しないと内部ロジックが不透明になるため、規制対応の観点から追加の工数が必要です。

選択の目安を整理すると以下のようになります。

• データ量が少ない・説明責任が最優先: ロジスティック回帰を基準モデルとして採用
• 精度向上が必要・SHAP 等で説明可能性を担保できる: 勾配ブースティングに移行
• 合成データ比率が高い段階: まず単純なモデルで分布の再現性を確認してから複雑なモデルへ進む

なお、合成データで学習したモデルを実データで評価する際、モデルの複雑さが高いほど分布ズレの影響を受けやすい点に注意が必要です。

精度が高くても、プライバシーリスクが残っていれば合成データを使う意味が半減します。逆に、プライバシー保護を厳しくしすぎると、モデルの識別力が落ちて実運用に耐えられなくなります。この両者はトレードオフの関係にあるため、AUC や KS 統計などの精度指標と、プライバシーリスクの指標を切り離して評価すると、どちらかに偏った判断をしがちです。以降では、それぞれの評価手法を具体的に見ていきます。

合成データで学習させたモデルを評価する際、精度指標の選び方を誤ると「良く見えるが実際には使えない」モデルを見逃しやすくなります。最初は Accuracy（正解率）だけで判断しがちですが、デフォルト率が低い信用スコアリングではクラス不均衡の影響を受けるため、AUC・KS 統計・PSI の三指標を組み合わせて評価する方が実態を正確に把握できます。

**AUC（Area Under the ROC Curve）**は、モデルがデフォルト顧客と健全顧客を識別する総合的な能力を示します。値が 1.0 に近いほど判別力が高く、0.5 はランダムと同等です。合成データ学習モデルでは、実データのみで学習した場合と AUC を比較することで、合成データの有効性を確認できます。

**KS 統計（Kolmogorov-Smirnov Statistic）**は、スコア分布においてデフォルト群と非デフォルト群の累積分布関数の最大乖離幅を測ります。値が大きいほど両群の分離が明確であり、信用スコアリングの実務では重要な指標となります。

**PSI（Population Stability Index）**は、学習時と本番運用時のスコア分布のズレを定量化します。主な判断基準は以下のとおりです。

• PSI < 0.1: 分布は安定、モデル再学習不要
• 0.1 ≤ PSI < 0.2: 軽微な変化、監視を強化
• PSI ≥ 0.

メンバーシップ推論攻撃とは、攻撃者がモデルの出力を観察することで「特定の個人データが学習に使われたか否か」を推定する手法です。合成データを使って学習した場合でも、元データの統計的特性が過度に保持されていると、このリスクが残存する可能性があります。

攻撃テストの基本的な手順は以下の通りです。

• シャドウモデルの構築: 攻撃者の視点を模倣したシャドウモデルを別途学習させ、本モデルの予測スコア分布と比較する
• 信頼スコアの差分分析: 学習データに含まれるサンプルと含まれないサンプルとで、モデルの出力確率に有意な差が生じていないかを確認する
• 攻撃成功率の測定: ランダム推測（成功率 50%）と比較して攻撃精度が有意に高い場合、プライバシーリスクが存在すると判断する

テスト結果の解釈では条件分岐が重要です。攻撃成功率がランダム水準（50% 前後）に収まっている場合は許容範囲と見なせますが、成功率が顕著に高い場合は差分プライバシーの ε（epsilon）値を小さく設定し直すか、合成データの生成パラメータを見直す必要があります。

NIST SP 800-226 では、差分プライバシーの保証水準と合成データの関係が整理されており、プライバシー係数 ε の設定がリスク評価の基準として機能します。ε 値が小さいほどプライバシー保護は強まりますが、データの有用性（忠実性）とのトレードオフが生じるため、信用スコアリングの精度要件と照らし合わせながら調整することが求められます。

結論: 合成データ活用の落とし穴は「過学習」と「少数クラスの再現不足」の2点に集約される。事前に対策を知ることで、モデル劣化を未然に防げます。

合成データを用いた信用スコアリング開発では、特有の失敗パターンが繰り返されます。以降の H3 では、分布ズレによるモデル劣化とデフォルト事例の再現不足という2大課題を取り上げ、それぞれの回避策を解説します。

合成データは「元データの忠実なコピー」を目指すほど、かえってモデルを壊しやすくなります。これは料理のレシピを完璧に暗記しても、実際の食材の微妙なばらつきに対応できないのと似た構造です。

生成モデルが元データに過度に適合すると、合成データは元データとほぼ同一の分布を持つようになります。この状態で学習させたスコアリングモデルは、元データの統計的特性を「丸暗記」したに等しく、実運用の新規申込データに対して汎化性能が著しく低下します。

分布ズレ（Covariate Shift）の問題も見逃せません。合成データと実運用データの間で特徴量の分布が乖離している場合、モデルは現実に存在しないパターンを学習してしまいます。典型的な症状としては、訓練時のAUCは高いにもかかわらず本番環境でのKS統計が急落すること、PSI（Population Stability Index）が閾値を超えてモデルの再学習が頻繁に必要になること、特定の年齢層や職業カテゴリで承認率が不自然に偏ることなどが挙げられます。こうした兆候が出始めると、問題の根本が「合成データの質」にあるのか「モデルの構造」にあるのかの切り分けが難しくなるため、早期に気づくことが重要です。

過学習と分布ズレを防ぐには、生成段階と評価段階の両方で対策が必要です。

合成データを生成した後に「サンプル数が増えたから大丈夫」と考えがちですが、実際はデフォルト事例（少数クラス）の再現品質こそがモデル精度を左右します。

信用スコアリングのデータセットでは、返済不能に陥る顧客は全体の数パーセント程度にとどまるケースが多く、クラス不均衡が構造的に生じやすい状況にあります。合成データを生成する際、このデフォルト事例の統計的特性を十分に捉えられていないと、以下のような問題が連鎖します。

• 多数クラスに引きずられた生成: 生成モデルが正常返済パターンを過学習し、デフォルト特有の特徴量（返済遅延の頻度・収入変動の幅など）が平滑化される
• 偽の高精度: 全体の Accuracy は高く見えるが、デフォルト事例の Recall が著しく低い「見かけ上の優秀なモデル」が出来上がる
• 実運用での損失拡大: 本来リスクが高い申請者を「正常」と誤判定し、貸倒率が上昇する

この問題を回避するには、デフォルト事例だけを対象とした条件付き生成（Conditional GAN や CTGAN のクラス条件設定）を活用し、少数クラスのサンプルを意図的に増幅する手法が有効です。生成後は AUC だけでなく、少数クラスの F1 スコアや KS 統計を必ず確認してください。

また、元データのデフォルト事例が極端に少ない場合（数十件以下）は、生成モデル自体が過学習するリスクがあります。その際は、類似属性を持つ外部オープンデータや専門家知識を活用して元データを補完してから生成に臨むことを検討してください。

結論: 合成データは、プライバシー規制への対応と学習データ不足の解消を同時に実現できる有効な手段である。ただし、生成・評価・運用の各ステップを正しく踏まなければ、精度とコンプライアンスの両立は難しい。

本記事で解説した内容を以下に整理します。

• 前提条件の確認: 元データの品質評価と差分プライバシー・k-匿名化などプライバシー保護レベルの要件定義が出発点となります
• 生成手法の選定: GAN・VAE・統計モデルそれぞれに特性があり、MFI のデータ規模や目的に応じた選択が必要です
• 品質検証の徹底: 忠実性・多様性・プライバシーリスクの三軸で評価し、メンバーシップ推論攻撃テストまで実施することが望ましいです
• 混合比率の最適化: 実データと合成データの比率は固定せず、AUC や PSI を指標に継続的に調整します
• 失敗パターンの回避: 分布ズレによるモデル劣化と、少数クラス（デフォルト事例）の再現不足は最も起きやすい問題です

GDPR の Recital 26 が示すように、適切に匿名化された合成データは規制上の制約を大きく緩和できる可能性があります。一方で、生成プロセスの設計が不十分であれば元データの再識別リスクが残ります。規制要件は地域・業種によって異なるため、法務・コンプライアンス部門と連携しながら進めることを推奨します。

ラオスの MFI を含む新興市場の金融機関では、実績データが少ないほど合成データの恩恵が大きくなる傾向があります。