国内銀行データにおける取引摘要分類における
LLMの有用性の検証

サマリー

銀行取引データは、お金の動きそのものであり、事業者の経済活動の実態を直接的に捉えうるデータである。これを事業者に対するリアルタイムな与信判断へ活用する取り組みは、以前から行われてきた。このうち定量データ（残高・入出金額など）はフォーマットが安定しており取扱が比較的容易で、実務でも信用リスクモデルの特徴量として利用が進んでいる。一方、明細に記録された取引内容・取引相手といった定性データは、情報量が大きいにもかかわらず、表記が事実上無限に存在し銀行ごとに記帳ルールも異なる「銀行語の多方言問題」ゆえに、ルールベースでは十分なカバレッジを確保できず、活用は限定的であった。本研究は、この定性データの活用を主題とする。

本稿では、日本の法人銀行取引データの摘要欄を自動的に構造化情報へ変換するドメイン特化型LLMの開発経緯と成果を報告する。米国のB2B与信領域で先行するSlope TransFormerのアプローチ（OPT-125Mモデル）を参照し、LoRAファインチューニングを適用することで、日本語法人取引データへの高度な適応を試みた。

本モデルは、摘要テキストから「Category（取引分類）」「Transaction Description（取引内容）」「Counterparty/Intermediary（取引相手・仲介手段）」の3フィールドを一括抽出するタスクとして定式化されている。検証の結果、41,180社分（242,638件）のデータに対して完全一致精度99%を達成した。また、30,000 TPSという高い推論スループットを実現し、実務運用における高い処理能力とコスト効率を実証している。一定のテストデータの範囲においてではあるが、人間の判断と概ね同等の精度で取引内容・取引相手を構造化できることを確認した。これは、従来扱えなかった定性データを、与信モデルが利用可能な特徴量へ橋渡しする経路が成立することを意味している。

さらに本研究は、金融領域のAI実装において、単一の汎用LLM（Frontier Model）への依存ではなく、タスク・ドメインごとに最適なモデルを選択・組み合わせる「オーケストレーション」こそが重要であるという仮説を提示する。本モデルの構築は、このオーケストレーション戦略の一要素として位置づけられる。すなわち、汎用モデルではなく特定タスクに最適化された小型モデルこそが優位となる領域が存在することを、本研究は具体的に示すものである。

次のステップとして、LLMがラベリングした取引データからキャッシュフロー系の特徴量を構築し、これを倒産予測モデルへ組み込むことで、従来比でどの程度の予測精度向上（AR改善）を実現できるかを検証していく。

1. はじめに

昨今のLLM（大規模言語モデル）の精度の指数関数的な向上はあらゆる産業に変革をもたらしつつあり、金融業界もその例外ではない。問われているのは「LLMが使えるか」ではなく、「自社のドメインのどの課題にLLMを当てはめれば、実際に価値を生むか」である。Emeradaがこの技術を自社ドメインに適用していく中で、最も有望なユースケースの一つとして位置づけているのが、本稿で扱う法人銀行取引の摘要欄分類の問題である。

日本の銀行は毎日膨大な取引レコードを生成し、各レコードには取引の性質・相手先・目的を示す短い自由記述テキスト（摘要欄）が付与される。Emeradaの中小企業向けキャッシュフロー分析プラットフォームにとって、この摘要欄を自動的に構造化情報へ変換することは、リアルタイムのキャッシュフロー可視化・異常検知・与信判断を実現する上で根幹的な機能である。

問題は見かけよりも難しい。日本の法人取引の摘要欄は、標準コード・自由記述の社名・略語・銀行固有の表記規則が混在する。同じ経済的事象（例：給与振込）であっても、「給与」「給与振込」、半角カナの「ｷﾕｳﾖ」、あるいは振込依頼人名がそのまま入る「ｶ)○○ｼﾖｳｼﾞ」など、銀行・支店・依頼人によって多様な表現が生まれる。これが 「銀行語」の多方言問題であり、高次元・ロングテール分布を持つ。ルールベースのシステムだけでは十全なカバレッジを得ることは困難である。

本研究はSlope TransFormer（Wu, 2023）に着想を得ている。同研究は、OPT-125Mをわずか66Kの高品質ラベルでLoRAファインチューニングすることで、米国のB2B（事業者）取引の分類においてPlaidの62%を上回る 72%のExact Match精度 と 500取引/秒 の処理速度を実現し、前世代のGPTベース手法と比較して250倍の高速化を達成した。

本研究の中心的な問いは：同様のアプローチは日本の法人銀行データに通用するか？ である。

2．問題設定

2.1 タスク定義

本研究が対象とするタスクは、日本の法人銀行取引データの摘要欄テキストから、以下の3つの構造化フィールドを自動抽出することである。

Category（取引分類）は、取引を財務分析上の意味カテゴリへ分類したラベルである（例：営業性収入、借入返済、同社間の振替）。CounterpartyやTransaction Descriptionとは異なり、Categoryは摘要欄に直接記載されているわけではなく、取引内容の文脈から推論される。

Transaction Description（取引内容） は、取引の経済的な内容・性質を示すテキストである（例：ローン返済、給与振込、社会保険料）。摘要欄に明示的に記載されている情報から導出されるが、銀行固有の略語やコードの解釈を要する場合がある。

Counterparty/Intermediary（取引相手・仲介手段）は、取引の相手先企業・個人（例：ｴｰｼﾖｳｼﾞ）、または取引に用いられた決済手段・仲介サービス（例：PayPay、FBサービス）を指す。摘要欄には取引相手のみ、仲介手段のみ、あるいは両方が記載される場合があるため、これらを単一フィールドとして統合して扱う。

以下にモデルのインプットとアウトプットの具体例を示す。

この例では、摘要欄「振込入金 ｴｰｼﾖｳｼﾞ」から、取引相手として「ｴｰｼﾖｳｼﾞ」、取引内容として「振込入金」がそれぞれ抽出される。一方、Categoryの「通常売上」は摘要欄に直接記載されてないため、振込入金という取引形式と相手先の文脈から推論されたラベルである。この点が、本タスクを単純なキーワード抽出ではなく意味的推論を要する問題として位置づける根拠となる。

形式的には、本タスクは摘要欄のテキストを入力値として受け取り、3つのフィールドのテキストを出力するシーケンス-to-シーケンス問題として定式化される。

2.2 なぜLLMか

摘要欄の分類に対する従来のアプローチとして、ルールベース手法がある。例えば、摘要欄が「カリイレキン」に完全一致する場合に「借入」カテゴリを付与するといった規則を事前に定義し、パターンマッチングによって分類を行う方法である。このアプローチは解釈性が高く、小規模・固定的な環境では有効に機能する。

しかし、日本の法人銀行取引データに対してルールベース手法を適用する場合、Category・Transaction Description・Counterparty/Intermediaryの3フィールドそれぞれに対して、異なる性質の限界が存在する。

• Categoryにおける限界
  カテゴリはキーワードから直接導き出せないケースが多く、取引の文脈や方向性、相手先の業種などを推論する必要がある。ルールベースの手法では、こうした暗黙的な意味推論を行うことは困難である
• Transaction Descriptionにおける限界
  取引内容を示すキーワードは銀行や依頼人によって表記が大きく異なる。また、略語や銀行固有コード（例：「FB」「PE」）の解釈には高度なドメイン知識が必要であり、汎用的なルールの作成には限界がある
• Counterparty/Intermediaryにおける限界
  取引相手となる企業・個人の名称は無限に存在し、表記ゆれが激しいため、網羅的なパターンマッチングは難しい。また、取引相手と仲介手段が同一の摘要欄に混在するケースでは、単純な照合での切り分けが困難である

その上に、金融機関ごとに記載形式が異なるため、銀行ごとにルールセットを個別に作成・維持する必要がある。この管理コストは金融機関の数に合わせて線形以上に増大してしまう。

以下に、複数の銀行は同じ給料支払いの取引に対して、それぞれ異なった摘要欄記載をしている例を示す。

また、同一の金融機関であっても、普通預金と当座預金の間で摘要情報が含まれる列名やデータの記録形式（フォーマット）が異なる場合がある。そのため、従来のルールベース手法を適用する際には、口座種別ごとに個別のルールを策定・拡張する必要が生じ、運用の煩雑化や開発コストの増加という課題が存在する。 以下に、同一金融機関における普通預金と当座預金のデータ形式の相違例を示す。

普通預金データ形式の事例 ：

当座預金データ形式の事例 ：

これらの課題に対し、LLMは摘要欄テキストを文脈レベルで意味的に理解した上で分類・抽出を行うことができると考えられる。ルールの明示的な列挙を要さず、学習データから暗黙的に表記の多様性・略語・銀行固有コードに対する解釈能力を獲得できる。取引先名称のような開放語彙（open vocabulary）の問題に対しても、LLMは学習時に見たことのない企業名を文脈から推定できる点で、パターンマッチングに対する構造的な優位性を持つ。本研究は、この仮説を日本の法人銀行データという具体的なドメインで実証することを目的の一つとする。

下表の例において、摘要情報が「DF.ｼｰｼﾖｳｼﾞ」である取引に対し、従来ルールベース手法では取引分類が「ナシ（分類不能）」となっている。これは、当該企業との過去の取引履歴が存在せず、既存のルールセットでカバーされていなかったことが原因と考えられる。

一方で、LLM（大規模言語モデル）は、過去の取引実績の有無に依存せず、摘要情報から当該企業を営業取引先であると正しく推論し、「営業キャッシュフロー」へと分類できている。

3. 関連研究

3.1 SlopeGPT：GPT-4を用いた取引分類の試み

銀行取引データへのLLM適用の先駆的事例として、米国のB2B決済企業Slopeが2023年4月に発表したSlopeGPT（Wu, 2023）がある。

従来、フィンテック企業は取引データを辞書・キーワード・その他のルールベースのアプローチによって分類してきた。しかしこの方法には二つの問題があった。第一に、取引摘要の多様性と独自性により、ルールで取引を確実に特徴づけることは困難または不可能である。第二に、同一の取引摘要であっても、事業者によって全く異なる意味を持つ場合がある。例えば、ACH（米国の電子決済ネットワーク ）の入金が、ある事業者には売上であっても、別の事業者には資金調達源となりうる。

これらの課題に対しSlopeGPTは、GPT埋め込みを活用して取引データを取り込み、キャッシュフローを収益・費用・ローン・投資等の構成要素へ分解するアプローチをとった。SlopeGPTは、GPT-4を用いて銀行データをより正確に分類し、事業の高解像度な全体像を提供するとともに、リスク検知の精度向上を実現した。

しかしSlopeGPTには実用上の制約があった。取引ごとにGPT-4 APIを逐次呼び出す方式は、処理速度・コストの両面でスケーラビリティに乏しく、大規模な本番運用には適さなかった。本研究においても同様の課題が観察されており、取引ごとのAPI呼び出し方式は時間・コスト両面で非効率であることが確認されている。

3.2 Slope TransFormer：ドメイン特化小型モデルへの転換

SlopeGPTの限界を克服するため、SlopeはSlope TransFormer（Wu, 2023）を発表した。本手法は本研究の直接的なインスピレーションであり、そのアーキテクチャと学習戦略を日本語法人取引データへ適用することが本研究の出発点となっている。

TransFormerは効率的なオープンソース基盤モデルであるOPT-125Mを採用している。なぜこれほど「小さな」モデルなのか。取引言語の次元数を考えると、ルールで解決するには広大すぎるが、英語全体と比べれば極めて小さい。また、タスクは一つであり、LLMの基準からすればシンプルである。

Slope TransFormerは学習手法として、LoRA（Low-Rank Adaptation of Large Language Models）を採用した。LoRAは元のモデルの重みを固定したまま、簡略化された表現を学習することで基盤モデルの効率的なファインチューニングを実現する。また、モデルの重みが大幅に変更されることで以前に学習した重要な知識が失われる現象を軽減する効果もある。

Slope TransFormerは毎秒500件以上の取引をラベリングし、SlopeGPTと比較して250倍の高速化を達成した。人間によるラベリング精度を100%の完全一致（Exact Match）精度とした場合、Slope TransFormerの精度は72%以上であり、62%にとどまるPlaid（※ 北米の金融アプリにおいて幅広く利用されている銀行取引データ等のデータ連携を行うフィンテックサービスで、同サービスでも独自に取引のラベリングが提供されている）を上回ったとされている。

本研究はこのアプローチを日本の法人銀行取引データという新たなドメインへ適用する試みであり、日本語特有の表記多様性（半角カナ・全角文字・銀行固有コードの混在）と、摘要欄に直接書いてない「Category」を追加的に推論する点が、Slope TransFormerとの主要な差異となる。

3.3 Rogo Big Finance Benchmark：モデルオーケストレーションの重要性

金融AIにおける単一モデル依存の限界を示す知見として、Rogo AIが2026年5月に発表したBig Finance Benchmark（BFB）が参考になる。

BFBは928問の評価セットであり、銀行・PE・リサーチ・資産運用において実際に行われる業務を対象としている。その主要な結論は「最良の単一モデルは存在しない」というものである。上位モデルであるOpus 4.7、GPT-5.5、Sonnet 4.6は全体スコアで0.3ポイント未満の差しかないものの、各モデルは異なるワークフローで強みを持ち、全領域でリードするモデルは存在しない。

さらにワークフローとソース種別による粗いルーティングだけでも最良の単一モデルに対して約4.5ポイントの精度向上が得られ、最適なオラクルルーティングでは13.2ポイントの改善が確認された。この知見は、「どの単一モデルが最も優れているか」ではなく「どのタスクにどのモデルを充てるか」こそが金融AI実装の本質であることを示唆しており、本研究における特定タスク向け小型特化モデルの構築はこのオーケストレーション戦略の一要素として位置づけられる

4. データ

データソース

本研究では、国内銀行の普通預金および当座預金データを使用した。全データセットは41,180社分の242,638件の取引データを収録している。データの80%（194,110件）と20%（48,528件）をランダムに分割し、それぞれ学習データとテストデータとして使った。データは業種・業歴・規模等による絞り込みは行わず、同行が保有する全取引先データを対象としている。

摘要欄の前処理

取引の摘要欄情報は必ずしも単一フィールドに収まらず、複数フィールドに分散している場合がある。例えば当座預金の入金取引では、「明細部_摘要」フィールドに取引先情報、「明細部_お支払金額」フィールドに取引内容が記載されるケースが多い。このような場合、「明細部_摘要」と「明細部_お支払金額」フィールドの情報を一つのテキストにマージして「摘要」として使う。一方、出金取引において「明細部_お預り金額」フィールドに取引内容が記載されるため、「明細部_摘要」と「明細部_お預り金額」フィールドをマージして「摘要」として使う。

教師ラベルの作成

マージした「摘要」を利用し、各取引レコードに対して、以下のフォーマットで教師データを作成した。

=>はモデルがインプットとアウトプットの境界を認識するための特別トークンとして機能する。モデルは「摘要欄 =>」をインプットとして受け取り、その後の3フィールドをカンマ区切りで出力するよう学習する。

教師ラベルの作成は、ルールベースと人手による手動アノテーションを組み合わせたハイブリッドアプローチを採用した。具体的には以下の通りである。

• Category：エメラダが保有する取引分類ルールを基盤としつつ、ルールの適用結果を人間が確認・修正するレビュープロセスを経て最終ラベルとした。
• Counterparty/Intermediary・Transaction Description：まず摘要欄の大量サンプルを人手で精査し、繰り返し出現するパターンを人間が識別・分析した上でルールを設計した。その後、ルールでカバーできないケースや曖昧なケースについては、人間が個別に判断して手動でラベルを付与した。
• 普通預金と当座預金はそれぞれ異なるルールセットを用いた。なお、両口座種別間の摘要欄フォーマットの差異が大きいため、ルール設計においても口座種別ごとに個別の人手分析が必要であった。

このように、教師データはルールの自動適用のみに依存するものではなく、ドメイン知識を持つ人間による判断と検証が不可欠な作業として位置づけられる。教師データの品質がモデルの精度を直接左右するという観点から、この人手アノテーションのプロセスは重要だと考えられる。

教師データの具体例を以下に示す。

ラベルの分布

データの各取引に対して3フィールド全てのラベルが存在するとは限らない。例えば、摘要欄に取引のみ記載されて、取引内に該当する情報がない場合は多くある。ラベルが付与できない場合は「ナシ」とし、3フィールド全てが「ナシ」となる取引は学習・テストデータから除外した。

全体のデータの中で、各フィールドにおける「ナシ」の分布は以下の通りである。

5. モデルアーキテクチャと学習方法

5.1 モデル選択：OPT-125M

本研究では、Slope TransFormer（Wu, 2023）と同様に、Meta AIが公開するオープンソース基盤モデルOPT-125M（Open Pre-trained Transformer, 125Mパラメータ）をベースモデルとして採用した。

大規模な汎用LLM（例：GPT-4、Gemma 2 9B等）ではなく、125Mという比較的小規模なモデルを選択した理由は以下の通りである。

第一に、タスクの次元数の観点からである。取引言語の次元数は、ルールで解決するには広大すぎるが、英語全体と比べれば極めて小さい。また、タスクは一つであり、LLMの基準からすれば大分シンプルである。汎用的なAGIの構築には770億パラメータが必要かもしれないが、取引分類にはオーバースペックである。摘要欄の語彙空間は確かに広大であるが、あくまで銀行取引という限定されたドメインであり、汎用的な言語理解能力を持つ大規模モデルは本タスクには過剰である。

第二に、推論速度とスケーラビリティの観点からである。大規模モデルはAPI呼び出しコストが高く、かつレスポンスが遅いため、数十万件規模の取引データをバッチ処理する本研究のユースケースには適さない。OPT-125Mのような小型モデルは自己ホスティングが可能であり、十分なインフラ環境を整備すれば、毎秒500件以上の取引をラベリングできる処理速度の実現が報告されている（Slope TransFormer（Wu, 2023））。

第三に、コスト効率の観点からである。クローズドな大規模APIモデルを全取引に適用した場合、APIを呼び出す度コストが線形以上に増大する。小型の特化モデルは、デプロイする推論環境を用意する費用が一度だけ発生し、APIの呼び出し費用はかからない。

5.2 学習方法：LoRAファインチューニング

モデルの学習手法として、LoRA（Low-Rank Adaptation of Large Language Models）（Hu et al., 2021）というファインチューニング方法を採用した。

具体的には、モデルの各層が持つ大きな行列（重み）を直接更新する代わりに、その変化分だけを非常に小さな2つの行列の掛け算で近似する。例えば元の重みが1000×1000の行列だとすると、それを1000×16と16×1000という2つの細長い行列の組み合わせで表現する。この「16」がランクと呼ばれる値であり、本研究ではr=16を採用した。

この工夫により、学習が必要なパラメータ数をモデル全体の約0.5%程度まで削減できる。OPT-125Mは約1.25億個のパラメータを持つが、LoRAで実際に更新するのは約60万個に過ぎない。結果として、全パラメータのファインチューニングと比較して少ないGPUメモリと時間で学習が完結できる。

LoRAを採用した理由は以下の通りである。

第一に、計算効率である。全パラメータを更新するフルファインチューニングと比較して、学習に必要なGPUメモリと計算時間を大幅に削減できる。本研究ではAzure ML上での学習を前提としており、コスト面での優位性は重要である。

第二に、壊滅的忘却（Catastrophic Forgetting）の回避である。LoRAは元のモデルの重みを固定したまま簡略化された表現を学習するため、モデルの重みが大幅に変更されることで以前に学習した重要な知識が失われる「壊滅的忘却」を軽減する効果がある。銀行取引のドメイン知識を獲得しつつ、OPT-125Mが事前学習で獲得した一般的な世界知識（例：企業名・地名の認識）を保持することが、本タスクにおいても重要である。

5.3 オープンソースモデル vs. クローズドモデル

本研究においてOPT-125Mのようなオープンソースモデルを採用した背景には、クローズドモデル（GPT-4、Claude等）との比較における実用的な判断がある。

クローズドモデルの懸念点として、以下が挙げられる。

• データプライバシー：銀行取引データは機密性が高く、外部APIに送信することはデータガバナンス上のリスクを伴う。オープンソースモデルであれば自社環境内での完結した推論が可能であり、取引データを外部に送出する必要がない。
• コスト：数十万件規模の取引を逐次APIで処理した場合、運用コストが現実的でないレベルに達する。
• 本研究以前、EmeradaはAzure OpenAI APIを用いた取引分類の推論を試みた。一取引の平均処理時間が12秒で、たった350社分の取引データ（数万件の取引）の処理に数日もかかる計算となり、取引ごとにAPIを逐次呼び出す方式は時間・コスト両面で非効率であることが明らかとなった。
• レイテンシと予測可能性：ChatGPTは同一プロンプトを10回尋ねても10種類の異なる回答を返す可能性がある一方、特定タスクに向けてファインチューニングされたモデルは実用上決定論的な挙動を示す。本番システムにおける信頼性の観点から、この一貫性は重要な特性である。

オープンソースモデルの優位性として、以下が挙げられる。

• 自己ホスティングによる完全なデータコントロールと低レイテンシ推論の実現
• カスタマイズ性：LoRAによるドメイン特化ファインチューニングが可能であり、銀行取引という特殊な言語空間への適応が容易である。
• コスト効率：一度学習すれば、追加のAPI費用なく大量推論が可能。

6. 推論パイプラインと評価方法

6.1 推論パイプライン

インプットの準備

第4章で述べたデータ前処理と同一の手順でインプットを準備する。具体的には、複数フィールドに分散した摘要欄情報をマージした上で、以下のフォーマットで推論用テキストを構成する。

=>以降は空白のままモデルに入力し、モデルが後続のテキスト（Counterparty/Intermediary、Transaction Description、Categoryのカンマ区切り）を生成する。具体的なインプット例を以下に示す。

デプロイ環境：AzureMLバッチエンドポイント

学習済みモデルはAzure Machine Learning（AzureML）のバッチエンドポイントとしてデプロイした。バッチエンドポイントとは、大量のデータをまとめて非同期で処理するための推論基盤であり、リアルタイムでの即時応答を目的とするオンラインエンドポイントとは異なり、数万〜数十万件規模のデータを効率的に一括処理することに最適化されている。

本研究のユースケースでは、月次・週次で蓄積される取引データをまとめてバッチ処理するという運用形態を想定しており、バッチエンドポイントはこの要件に適合する。推論時には学習済みLoRAアダプタをベースモデル（OPT-125M）に結合し、4ビット量子化を適用することでメモリ効率を高めた状態で実行している。推論環境のGPUとしてNVidia H100（40コア320GB RAM）を1台使用している。NVidia H100は、LLM学習と推論においてCPUサーバーと比較して高速化を実現することができ、本研究における大規模バッチ推論の要件に十分対応できるスペックを備えている

6.2 評価方法

①精度評価指標

モデルの推論結果の精度の評価方法として、各推論フィールド（Category・Transaction Description・Counterparty/Intermediary）に対して以下の2つの定量的な指標を使用する。

Exact Match Accuracy（完全一致精度）：モデルの予測出力が教師ラベルと完全に一致した割合を示す指標である。値域は0から1（または0%〜100%）であり、1文字でも異なれば不一致と判定される厳格な基準である。本研究の主要評価指標として位置づけるとともに、Slope TransFormer（Wu, 2023）においても同指標が採用されており、比較可能な形でのベンチマーク評価が可能となる。

Jaccard Similarity Index（ジャカード類似度）：予測テキストと教師ラベルを単語（トークン）の集合として扱い、その重複の割合を測定する指標である。値域は0から1であり、0は完全不一致、1は完全一致を意味する。Exact Matchを補完する指標として、部分的な正解も定量化できる点が特徴である。

具体例として、教師ラベルが「ｲｰ ガス コウギヨウ」、予測が「ｲｰ ガス」であった場合は完全一致精度は０となるが、ジャカード類似度は、

となり、部分的な一致を定量的に捉えることができる。このようにJaccard Similarity Indexは、モデルが完全一致には至らないものの概ね正しい方向を示している場合を評価するのに適しており、Exact Match Accuracyと組み合わせることでより多角的な精度評価が可能となる。この指標もSlope TransFormer（Wu, 2023）において使用されている。

②速度評価指標

Tokens per Second（TPS）：精度評価に加え、モデルの処理速度をTokens per Second（TPS）で測定する。TPSとは、モデルが1秒間に生成できるトークン（モデルがテキストを処理する際の情報の最小単位、短い文字列 ）数を示す指標である。

TPSは、本番運用における処理能力の見積もりに直結する指標である。例えば月次で数万件の取引データを処理する際に必要なGPUリソースやコストを逆算する根拠となり、精度指標だけでは捉えられないシステムとしての実用性を評価する上で不可欠な補完指標である。

一秒当り推論取引数：TPSを補完する、より直感的な処理速度指標としてモデルが一秒間で処理できる取引数を計算する。この指標はテストデータの全引数推論にかかった合計推論時間をその取引数で割った平均値である。

③その他指標

推論カバレッジ率：教師ラベルが「ナシ」でない取引に対して、モデルが「ナシ」または空白を出力せずに有効な推論結果を返した割合として定義される。

7. 実験結果

7.1 テスト結果

学習済みモデルをテスト取引データ（48,528件）に対して推論し、そのアウトプットを評価した結果を以下に示す。

完全一致精度、ジャカード類似度、推論カバレッジ率

完全一致精度は各推論フィールドとそれらを合わせた全フィールドにおいて99%以上を精度を出しており、非常に高い。そのため、ジャカード類似度も100%に近い数値が出た。推論カバレッジ率は、Categoryフィールドは100%だが、Transaction DescriptionとCounterparty/Intermediaryはそれぞれ99.8%と99.9%と、推論できなかった取引が数件あったことを示している。これは、学習データにおいて、Transaction DescriptionとCounterparty/Intermediaryの「ナシ」教師ラベルの取引が多かった（それぞれ69%と23%あった）ことが背景にあると考えられる。言い換えると、この二つのフィールドが「ナシ」の取引が多いことをモデルが学習しているが、実際に「ナシ」ではない数件を「ナシ」と推論してしまっている。

推論速度

本モデルの推論速度は30,000 TPS（Tokens per Second）であり、極めて高い処理性能を示している。検証では、48,528件のテストデータを約54秒で処理し、1秒あたり899件の取引推論を達成した。

この処理能力を実務に適用した場合、ある金融機関の年間取引データ（約200万件）を約37分で処理可能である。また、インフラコストの観点でも、Azure Machine Learning（インスタンス：Standard_NC40ads_H100_v5、1ノードあたり10.12米ドル/時）を基準とした試算において、200万件の処理に要する費用は約1,200円に抑えられる。これにより、実運用における高いコストパフォーマンスが実証された。

7.2 目標ベンチマークとの比較

本研究の目標ベンチマークはSlope TransFormer（Wu, 2023）の結果に基づく。なお、Slope TransFormerはCounterparty/Intermediaryのみを推論対象としているのに対し、本研究は3フィールドを同時に推論している点に留意が必要である。そのため、推論フィールドCounterparty/Intermediaryのみに対して、下記ベンチマーク比較を行う。

精度・カバレッジのベンチマーク比較表

本研究のモデルは完全一致精度において99.5%を記録し、Slope Transformer（72.5%）を大きく上回る圧倒的な識別性能を示した。また、出力のテキスト構成やトークン類似性を評価するジャカード類似度においても、提案モデルは99.7%という極めて高い水準を達成し、既存のSlope Transformer（87.0%）に対する優位性を実証した。さらに、モデルは、取引分類の割合が99.9%と、当社の従来のルールベースの手法より非常に高い推論カバレッジ率を達成している。高いカバレッジ率と上述の超高精度を両立しており、実務運用における網羅性が高いと考えられる。

推論速度のベンチマーク比較

本研究で開発したモデルはプロンプト（入力）を除いた新規出力のみで約30,000 TPSという高い生成スループットを記録し、Slope Transformer（500 TPS）に対し約60倍の高速化を達成した。1秒あたりの推論取引数でも約900件に達し、Slope Transformer（500件以上）や外部APIを介するGPT-5-mini（約0.08件）を圧倒した。この驚異的な速度は、OPT-125Mという軽量モデルに対し、バッチサイズ256の大規模並列デコードを適用したことで、NVIDIA H100が持つ膨大なメモリ帯域幅を最大限に活用したハードウェアのメカニズムに裏付けられる。各モデルの推論環境が異なるため、アーキテクチャ単体での一対一の厳密な比較ではないものの、本モデルが実務上の大量取引処理において圧倒的なリアルタイム性と実用性を有することを示すベンチマークとして重要な意味を持つ 。

7.3 精度ギャップに関して

本研究の結果はいずれの指標においても極めて高い水準を示しており、特に完全一致精度がSlope TransFormerの72.5%を約27ポイント上回った点は注目に値する。この大幅な差異については、以下のような要因が考えられる。

教師データの性質

本研究の教師ラベルは第4章で述べた通り、ルールベースと人手アノテーションを組み合わせたハイブリッドアプローチで作成されている。すなわちモデルは、人間が設計したルールから導出されたラベルを学習していることになる。

テストデータも同一のルールで生成されたラベルで評価されているため、モデルが学習したパターンとテスト評価のパターンが高度に一致している可能性がある。言い換えれば、現在の評価は「ルールをどれだけ再現できるか」を測定しており、真の汎化性能を反映していない可能性がある。

Slope TransFormerとのタスク定義の差異

Slope TransFormerは人間の専門家によるアノテーションを正解ラベルとして採用しており、より高い多様性・曖昧性を含むデータに対して72.5%を達成している。一方、本研究の教師ラベルはルールに基づく一貫性の高いデータであり、タスクの難易度が異なる可能性がある。

今後の評価課題

モデルの検証するためには、以下の追加評価が必要と考えられる。

• ルールが未定義の新規取引先・新規パターンに対するモデルの挙動確認
• 別の金融機関データへの適用実験
• 人手アノテーションによる独立したテストセットでの再評価

8章 本検証の実用化に向けて

銀行取引データは、お金の動きそのものであり事業者の経済活動の実態を直接的に理解するための非常に有用なデータであることは疑いようがなく、これらのデータを事業者に対するリアルタイムな与信判断へ活用する取り組みは、以前から行われてきた。

残高や入出金額といった定量データはフォーマットが安定し、口座の残高や口座への入金・出金額の様なデータは取扱が比較的容易な定量データであり、実務でも信用リスクモデルの特徴量として利用が進んでいる。一方で、明細に記録された取引内容・取引相手などの定性データは情報量が大きいにもかかわらず、表記が事実上無限に存在し銀行ごとに記帳ルールも異なる「銀行語の多方言問題」ゆえに、ルールベースでは十分なカバレッジを確保できず、活用が限定的であった。

本検証では、この定性データのラベリングにドメイン特化型LLMを適用し、一定のテストデータの範囲で人間の判断と概ね同等の精度で取引内容・取引相手を構造化できることを確認した。これは、従来扱えなかった定性データを与信モデルが利用可能な特徴量へ橋渡しする経路が成立することを意味している。次のステップとして、LLMがラベリングした取引データからキャッシュフロー系特徴量を構築して倒産予測モデルへ組み込み、従来比でどの程度の予測精度向上（AR改善）を実現できるかを検証していきたい。