リサーチ
金融特化LLMで金融テキスト分析はどう変わったか
決算短信や有価証券報告書からシグナルを取り出す試みは、機械学習の応用としては古くから続いてきた領域です。辞書ベースの極性判定から始まり、単語の分散表現、事前学習済みの言語モデルへと手法が移り、いまは大規模言語モデルを前提とした設計が主流になりつつあります。
手法が置き換わるたびに何かが良くなり、同時に別の難しさが現れました。ここでは、実際に金融テキストの分析基盤を作り替えてきた立場から、何が変わって何が変わっていないのかを書きます。
辞書ベースの限界と、それでも残る利点
初期に広く使われたのは、肯定的な語と否定的な語を並べた辞書で文書のトーンを測る手法です。金融文書向けに調整された辞書は一般的な感情辞書より妥当な結果を返し、いまでもベースラインとして意味を持ちます。
限界は明確で、否定や条件節を扱えません。「減益懸念は後退した」という文は否定的な語を含みますが、内容は肯定的です。文脈を読まない手法では、この種の判定を誤ります。
もう一つの限界が、金融特有の語法です。「想定の範囲内」「概ね計画通り」といった表現は、一般的な語彙としては中立ですが、開示の文脈では含意を持ちます。辞書に金融特有の語を追加しても、こうした婉曲表現までは捉えきれませんでした。
それでも辞書ベースには残る利点があります。結果が完全に説明できる点です。どの語が判定に寄与したかを一意に示せるため、なぜこのスコアになったのかという問いに即答できます。この性質は、モデルを刷新した後も比較対象として保持する価値があります。
言語モデルで実際に楽になった工程
大規模言語モデルを導入して明確に改善したのは、分類そのものより前段の工程でした。具体的には、文書の構造化です。決算資料は企業ごとに見出しの付け方や項目の並びが異なり、従来は企業別の抽出ルールを書き続ける必要がありました。
この作業が大きく減りました。定義した項目に対して該当箇所を拾わせる用途では、表記の揺れをある程度吸収してくれます。新しい企業を対象に加えるときの立ち上げ工数が下がったことが、実務では最も効いた変化でした。
もう一つは、長文の要約です。中期経営計画のような長い文書から、投資判断に関わる論点を抽出する用途では、従来は人手に頼っていた部分を下読みとして任せられるようになりました。ただし、これは絞り込みの用途に限るという前提つきです。
変わらなかった難しさ
期待していたほど改善しなかった部分もあります。第一に、数値の正確な取り扱いです。表形式のデータから正しい値を取り出す作業は、依然として構造化された抽出処理のほうが確実です。言語モデルに表を読ませると、似た数値の取り違えが一定の頻度で起こります。
第二に、ラベルの定義そのものの難しさです。ある開示が肯定的か否定的かという判定は、何を基準にするかで答えが変わります。株価への影響を基準にするのか、業績への影響を基準にするのかで、正解が入れ替わる事例が出てきます。手法を変えても、この曖昧さは残ります。
第三に、評価の難しさです。テキストから得たシグナルが運用成果につながるかを検証するには、結局のところ時点管理されたデータと厳密なバックテストが要ります。前段の精度が上がっても、検証の厳密さを要求する部分は何も減りません。
実装の落としどころ
いくつか作り直した結果、現在は工程を分ける構成に落ち着いています。文書の取得と正規化、構造の把握、項目の抽出、そして判定という四段階です。言語モデルを使うのは主に構造の把握と抽出で、判定は定義済みのルールと従来型のモデルで行います。
# 判定までモデルに委ねず、根拠の抽出に限定する。
# 抽出結果を保存しておけば、判定ロジックの変更時に再抽出が要らない。
from dataclasses import dataclass
@dataclass(frozen=True)
class Extraction:
doc_id: str
section: str # 該当セクション（業績概況 / 見通し など）
verbatim: str # 原文からの抜粋。必ず原文に存在すること
char_start: int # 原文中の位置。監査時に参照する
char_end: int
def assert_grounded(extraction: Extraction, source: str) -> None:
"""抽出結果が原文に実在することを機械的に確認する。"""
if source[extraction.char_start:extraction.char_end] != extraction.verbatim:
raise ValueError(f"ungrounded extraction in {extraction.doc_id}")
この分離には二つの利点があります。判定基準を変えたときに文書を読み直さずに済むこと、そして抽出結果が原文に紐づいているため後から検証できることです。運用に入ってから効いてくるのは、この検証可能性のほうでした。
日本語の金融文書に固有の課題
日本語を扱ううえで、いくつか固有の手当てが必要でした。まず単位の表記です。百万円、千円、億円が混在し、同じ資料内でも表によって単位が変わります。抽出した値を正規化する処理を入れないと、桁が三つずれた値が混ざります。
次に和暦と西暦の混在です。第何期という表記も企業ごとに起点が異なり、決算期の対応付けを誤ると時系列が崩れます。日付の正規化は地味ですが、後工程すべてに影響する基礎処理です。
さらに、括弧書きの扱いに苦労しました。日本語の開示文書では、注記や補足が括弧内に置かれることが多く、その中に条件が書かれている場合があります。括弧を単純に除去する前処理を入れると、条件が落ちた文が残ります。
運用してみて分かったこと
基盤を動かし続けてみると、精度以外の要素が想像以上に重要でした。もっとも手を焼いたのは、開示の様式変更への追随です。企業が資料の構成を変えると抽出が崩れますが、崩れたことに気づく仕組みがないと、静かに欠損が増えます。
いまは、抽出率の推移を企業別に監視し、前期比で大きく落ちた企業を検出する仕組みを入れています。抽出漏れは値がゼロになるのではなく、そもそも出力されない形で現れるため、能動的に検査しないと見逃します。
コストの管理も継続的な課題です。開示が集中する時期には処理量が跳ね上がり、費用も比例します。優先度の低い文書は安価な処理に回す、変更のない文書は再処理しないといった制御を入れないと、費用が読めなくなります。文書のハッシュ値で再処理の要否を判定する仕組みを入れてから、費用の変動は落ち着きました。
処理の再現性にも手を入れました。モデルの版が変わると同じ入力に対する出力が変わるため、抽出結果には使用したモデルの版とプロンプトの版を記録しています。過去の分析結果を説明する場面で、この記録がないと何も答えられません。
もう一点、運用に入ってから重みを増したのが処理の順序保証です。開示が集中する時期に並列度を上げると、同じ企業の複数文書が同時に処理され、後から出した文書の結果が先に確定することがありました。企業単位で直列に処理する制御を入れて解消しています。
結果を使う側との対話も、続けてみて必要性が分かった部分です。分析基盤が出す値を運用担当者がどう解釈しているかは、こちらが想定した通りとは限りません。抽出項目の定義を口頭で説明すると認識のずれが残るため、実際の抽出例をいくつか並べて確認する形に変えました。定義は例で共有するほうが早く揃います。
まとめ
金融テキスト分析における言語モデルの導入で明確に良くなったのは、企業ごとの個別対応が減ったことと、新しい対象を加える立ち上げが速くなったことです。一方で、数値の正確な取り扱い、ラベル定義の曖昧さ、そして検証の厳密さという難しさは残りました。抽出と判定を分け、抽出結果を原文に紐づけて保存する構成が、いまのところ扱いやすい落としどころだと感じています。
金融テクノロジー総合研究所では、開示資料の抽出パイプライン、金融特化 LLM の適用設計、検証基盤の構築を受託しています。既存の分析フローの点検からご相談いただけます。お問い合わせよりご連絡ください。
FTL の技術スタックと受託開発の進め方は FTLの技術とは？ にまとめています。
