1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

金融の現場から学ぶLLM時代のAI実装論――モデル、文脈、組織をどう設計するか

1
Last updated at Posted at 2026-07-03

目次

はじめに

今年5月15日、Trust株式会社が主催するイベント『金融の現場から学ぶ AI活用の現在地』に参加した。全体を通じて非常に学びが多く、AIが急速に発展している現在において、個人として、あるいは企業としてどのように向き合うべきかを考えるうえで、多くの示唆を得ることができた。

【金融の現場から学ぶ】AI活用の現在地

そこで今回、当日のメモをもとに、イベントで得た学びや自分なりの考察を整理し、共有したいと思う。

なお、当日のメモは講演を聞きながら急いで取ったものであり、本記事には私自身の理解や解釈も多く含まれている。そのため、もし本文中に誤りや不正確な点があれば、その責任はすべて筆者である私にある。

イベントの冒頭では、友田恭輔さんより、Trust株式会社の紹介があった。同社は2023年に設立された、金融領域に特化したスタートアップであり、会社の理念やこれまでの歩み、金融業務におけるAI活用の取り組み、そして事業面・技術面での最新の進展について説明があった。

同社が提供するTLanP(トランプ)というプロダクトである。これは、レガシーモダナイゼーションを支援するAIエージェントプラットフォームであり、まさにAI活用そのものから生まれた具体的な成果だと感じた。

日本では現在も多くの企業、とりわけ金融機関において、古い基幹システムの刷新が大きな課題となっている。その意味で、TLanPは非常に現実的なニーズに応えるプロダクトであり、大きな価値を持っているように思う。

個人的にも、ここ数年、金融システムの障害に関するニュースを見るたびに、レガシーシステムの問題は決して抽象的な技術課題ではなく、ユーザー体験や社会インフラそのものに直結する問題だと感じてきた。特に、ATMでの出金や振込など、日常生活に密接に関わる場面でシステム障害が発生すると、その影響は非常に大きい。

また、いまだに一部の銀行システムでCOBOLが使われていると知ったときには、強い驚きを覚えた。もちろん、COBOLは長年にわたり金融システムを支えてきた重要な技術であり、過去において高い信頼性を示してきたことは間違いない。しかし、「これまで使えていたから」という理由だけで、古い仕組みをそのまま維持し続けることには限界がある。すでにさまざまなレガシーシステムの問題が表面化しており、今後も同じように安定して使い続けられるとは限らない。

さらに、AI技術が発展していくにつれて、古いシステムの構造的な弱点や脆弱性がこれまで以上に可視化される可能性もある。もしそれが悪意ある人々に利用されれば、単なる業務効率の問題では済まない。金融システムは社会の信頼を支える基盤であるからこそ、レガシーモダナイゼーションは避けて通れないテーマだと感じた。

1. データに基づく意思決定を支えるという本質

最初の講演では、深澤優太さんが「LLM時代、“モデル”を作らないデータサイエンティストはどこで価値を出すのか」というテーマで登壇された。

講演全体を通じて特に印象に残ったのは、データサイエンティストの価値を、単に「モデルを作る人」としてではなく、データから環境を捉え、そこから価値を創出する存在として捉え直していた点である。深澤さんは、冒頭で「データ → 環境 → 創出」という流れを示し、これを講演全体の軸としていた。これは、LLMが急速に普及している現在においても、データサイエンスの本質が変わっていないことを示す非常に重要な視点だと感じた。

LLMと従来のデータサイエンスは、一見すると同じ「AI活用」の領域に見える。しかし、実際には得意領域が大きく異なる。LLMは、プロンプト設計、RAG、ワークフロー構築、テキスト生成、翻訳、照会対応など、非構造化データや自然言語を扱う場面で大きな力を発揮する。一方で、従来のデータサイエンスは、特徴量設計、データ処理、モデリング、評価、予測、A/Bテスト、ダッシュボード構築など、構造化データを用いた分析と意思決定支援に強みを持つ。

しかし、両者の違いを整理したうえで、深澤さんが強調していたのは、データサイエンスの変わらない核心である。つまり、最終的な目的は「データに基づく意思決定」を支援することにある。モデルを作ること自体が目的なのではなく、ビジネスや業務の現場において、より良い判断を可能にすることこそが本質である。

金融業務の文脈では、この役割分担がより明確になる。従来のデータサイエンスは、不正検知、与信リスク評価、市場動向予測など、構造化データをもとにした目的志向の分析に向いている。一方、LLMは、通知書や社内規程の読み取り、文書の要約、照会対応、報告書作成、翻訳といったテキスト中心の業務に適している。つまり、LLMは「読む」「まとめる」「書く」といった細かな作業を高速化し、データサイエンティストや業務担当者は、その結果をどのように意思決定に接続するかを設計する必要がある。

特に興味深かったのは、金融業務における意思決定の流れを、「小から大へ」と「大から小へ」という二つの方向で捉えていた点である。たとえば、融資審査のような場面では、まず通知書を読み、社内ルールと照合し、反社会的勢力との関係を確認し、最終的に融資の可否を判断する。この流れは、細かな情報処理から大きな意思決定へ進む「小から大へ」のプロセスである。この小さく煩雑な情報整理の部分では、LLMが大きな力を発揮できる。

一方で、最終的な意思決定は人間が担うべき領域である。なぜなら、人間の判断には、明文化されていない暗黙知、複数の要素を総合的に考慮する力、そして一定の揺れや例外を受け入れる容錯性があるからだ。LLMは文書処理や要約には優れているが、事業上の責任を引き受け、トレードオフの中で最終判断を下す存在ではない。

逆に、人間が先に大きな判断を行い、その根拠をもとに文書化する「大から小へ」の流れもある。この場合、人間は判断と根拠を提供し、LLMはそれを標準的で分かりやすい文書に落とし込む。ここでも、人間は意思決定を担い、LLMは整理・生成を担うという分担が見えてくる。

この話を聞いて、私は「AIによって知的作業の価値が下がる」という言い方は、かなり限定的に理解すべきだと感じた。たしかに、定型的で反復可能な低階層の知的作業は、LLMによって大きく自動化される。しかしその一方で、人間が本来持っている価値、すなわち、曖昧な状況で判断する力、複数の制約の中でトレードオフを設計する力、そして最終的な責任を持って意思決定する力は、むしろより強調されるようになるのではないか。

深澤さんが挙げていたデータサイエンティストの価値は、特にこの点をよく表している。第一に、人間の暗黙の判断を評価可能な形に変えること。第二に、精度だけを追求するのではなく、コスト、速度、安全性、倫理、運用負荷、人的レビューなどの制約下でトレードオフを最適化すること。第三に、これまで人間だから許容されていた業務判断の曖昧さを、AIシステムとして設計し直すことである。

私自身、特に「トレードオフ」という観点に強く共感した。現実のビジネスでは、資源は無限ではない。精度、コスト、速度、安全性、公平性、運用負荷のすべてを同時に最大化することはできない。そのため、何を優先し、何をどこまで許容するのかを判断する必要がある。この判断には、データだけでなく、経験、文脈理解、将来への見通し、そして説明責任が求められる。これは今後、データサイエンティストに限らず、あらゆる職種においてますます希少な能力になるだろう。

大規模モデル時代のデータサイエンティストは、必ずしも全員が「ハンマーを作る人」、つまり基盤モデルを訓練する人である必要はない。むしろ重要になるのは、既存のハンマーをどのように組み合わせ、どこで使い、どこで人間に判断を戻すのかを設計することである。

言い換えれば、これからのデータサイエンティストは、LLMを含む複数の要素を組み合わせた自動化されたワークフローの設計者であり、同時にそのリスク、コスト、評価、責任分界を管理する存在でもある。

LLMに小さく煩雑な作業を任せ、人間が大きな判断と容錯の役割を担う。その仕組みをデータに基づいて設計し、評価し、改善していくこと。そこにこそ、LLM時代における「モデルを作らないデータサイエンティスト」の価値があるのだと感じた。

2. RAGは「検索」ではなく「文脈を設計する」技術である

第二の講演では、大野広翔さんが「金融現場のしくじりから学ぶルーティングRAGとコンテキストエンジニアリング」というテーマで、RAGを実際の金融業務に導入する際の難しさと、その改善の方向性について共有された。

個人的に非常に印象的だったのは、RAG(Retrieval Augmented Generation,検索拡張生成)という技術が、2020年頃に登場してから現在に至るまで、まだその潜在力を十分に使い切れていないのではないか、という点である。特に金融のように、大量の社内規定、審査資料、過去事例、ガイドライン、通知文書などを扱う現場では、RAGは単なる検索補助ではなく、業務知識を扱うための中核的な仕組みになり得る。

RAGは、ある意味で1970年代のSQLや、2000年代以降に広がったデータマイニングの自然言語領域への延長線上にあるようにも見える。SQLが構造化データに対する問い合わせを可能にし、データマイニングが大量データからパターンやルールを発見しようとしたのに対して、RAGは大量のテキスト情報に対して、意味的な検索と生成を組み合わせる技術である。ただし、RAGはそれらの単なる延長ではなく、むしろ新しいアップグレード版とも言える。なぜなら、RAGは「検索」だけでなく、文章の意味、文脈、類似性、そして最終的な回答生成までを一つの流れとして扱うからである。

その基盤にあるのが、Vector(ベクトル)とEmbedding(エンベディング)である。現代の自然言語処理では、テキストをそのまま扱うのではなく、Embeddingによって単語や文章をベクトル空間上の数値表現に変換する。意味的に近い言葉や文章は、ベクトル空間上でも近い位置に配置される。この考え方は、TransformerやLLMの学習にも深く関係している。そしてRAGにおいても同様に、ユーザーの質問をベクトル化し、社内文書や規定集の中から意味的に近い情報を検索し、それをLLMに渡して回答を生成する。

しかし、大野さんの講演で示されたように、RAGを「関連しそうな資料を検索してLLMに渡せばよい」と単純に考えると、現場ではすぐに問題が起きる。最初の仮説としては、審査対象に近い規定やガイドラインを検索し、LLMに渡せば、指摘箇所、根拠、修正案まで自動で出せるはずだ、という期待があった。しかし実際には、Recallを重視して検索範囲を広げるほど、必要な情報だけでなく不要なノイズも大量に混ざってしまう。その結果、LLMが混乱し、ハルシネーションや誤検知を引き起こす。

ここには、前の講演でも触れられていたトレードオフの問題が再び現れている。情報を取り逃したくないのでRecallを上げると、ノイズが増える。ノイズを減らそうとPrecisionを上げると、今度は必要な情報を取り逃す可能性がある。

さらに、長い資料を丸ごとLLMに渡せばよいかというと、そうでもない。トークン数の制限、コスト、応答速度の問題に加えて、入力が長すぎると中間部分の情報が無視されやすくなる「Lost in the Middle」の問題もある。

つまり、RAGの本質は「検索して渡す」ことではない。むしろ重要なのは、LLMが判断できるように文脈を組み立てることである。この点で、大野さんが示したRoute(論点出し)、Retrieve(ルールを探す)、Assemble(文脈を作る)の流れは非常に示唆的だった。まず、どの論点で見るべきかを整理する。次に、関連するファイル、チャプター、セクションを絞り込む。そして最後に、それらの情報をLLMが理解しやすい文脈として組み立てる。

特に重要なのが、Context Packの設計である。LLMに何を渡すかによって、出力の品質は大きく変わる。単に検索結果をバラバラに渡すのではなく、チェック観点、業務規定、対象資料、過去の指摘例、NG例、出力フォーマットなどを一つの「文脈の塊」として構成する必要がある。これは、モデルそのものを変更する前に、入力する文脈を設計することでエラーを制御するアプローチであり、まさにコンテキストエンジニアリングの核心だと思う。

この話を聞いて、私は「ルールを探す」という行為が、SQLにおける問い合わせや、データマイニングにおける関連ルール抽出と似ていると感じた。ただし、自然言語は構造化データよりもはるかに曖昧である。同じ意味でも表現が異なり、同じ言葉でも文脈によって意味が変わる。そのため、RAGでは検索結果の量や質が不安定になりやすく、LLMの回答精度も上下しやすい。だからこそ、人間による設計、評価、調整が不可欠になる。

最終的に、大野さんの講演から見えてきたデータサイエンティストの価値は、単にプロンプトを書くことではない。プロンプト入力、検索・抽出、文脈生成、ルールの結合、LLMによる生成・評価、結果の分析・可視化という複数のステップを、一つの処理パイプラインとして実装し、評価し、改善することにある。

特に、検索・抽出と文脈生成・ルール結合の二つの工程は、RAGの品質を左右する重要な部分である。LLMに任せる前に、どの情報を、どの順番で、どの粒度で渡すのかを設計しなければならない。ここで必要になるのは、単なるAIツールの利用スキルではなく、業務理解、情報設計、評価設計、そしてトレードオフを扱う力である。

RAGは、単なる検索技術ではない。それは、大量のローカルな業務知識を、LLMが扱える文脈へと変換するための技術である。そしてその文脈をどう設計するかにこそ、LLM時代のデータサイエンティストの重要な役割があるのだと感じた。

3. CoEがつなぐ技術・業務・組織変革

第三の講演では、小西宏明さんが「AI活用推進のためのCoE組織づくりの実践ポイント」というテーマで、AIやデータ活用を単なる技術検証で終わらせず、実際の業務価値や組織変革につなげるための方法について話された。

この講演を聞いて改めて感じたのは、日本企業におけるDX推進の難しさは、単に「デジタル人材が足りない」という問題だけでは説明できないということである。もちろん人材不足は大きな課題だが、それ以上に、組織の動き方、業務プロセス、意思決定の仕組み、そして部門間の連携のあり方そのものが問われている。業務の属人化、目的やゴールの曖昧さ、既存システムへの依存、現場への浸透不足といった問題は、多くの日本企業が共通して抱えている課題だと思う。

DX推進の壁は人材不足「だけじゃない」 業務の属人化や目的の曖昧さが浮き彫りに

小西さんが整理していた「技術の壁」「業務の壁」「ガバナンスの壁」は、まさにこの問題を非常に分かりやすく表していた。技術の壁とは、スキルや知見が不足していたり、データが整備されていなかったりする状態である。業務の壁とは、AIを導入しても実際の現場業務に乗らない、業務プロセスが未整備で活用が定着しないという問題である。そしてガバナンスの壁とは、リスク対応、制度設計、人材育成、責任分界が十分に整っていないことを指す。

これらの壁を乗り越えるための仕組みとして紹介されたのが、CoE(Center of Excellence)である。CoEは、単なる専門家集団ではなく、経営、現場、IT、データ人材をつなぐハブであり、AI活用を全社的に推進するための司令塔である。特に印象的だったのは、CoEが「ユースケース創出」「人材育成」「利活用環境の整備」を三位一体で進める点である。

AI活用は、最初から全社一斉に進めようとしてもうまくいかない。むしろ、まずは具体的なユースケースを見つけ、単点突破で成果を出し、その成果をもとに周囲を巻き込み、横展開していくことが重要である。これは非常に現実的で、かつ日本企業の組織文化にも合った戦略だと感じた。特に、レガシーシステムや旧来型の組織運営が残る中でDXを進める場合、抽象的な理想論よりも、「小さく始めて、成果を見せ、仕組みにして広げる」ことが重要になる。

また、このプロセス自体が人材育成の場にもなる。講演では、AI活用を推進する人材像として「CoE Builder」という概念が紹介されていた。CoE Builderには、AIやデータに関するテクニカルスキルだけでなく、ビジネス理解、課題設定力、構造化思考、プロジェクト推進力、ガバナンス理解、コミュニティ運営力などが求められる。これは、単にAIを「作る人」でも、AIについて「語る人」でもない。現場の曖昧な課題をデジタルの要件に翻訳し、仕組み化し、実装まで進める人材である。

個人的には、「やりながら学ぶ」以上に有効な人材育成はないと思っている。ユースケースを作り、プロジェクトを支援し、成果を可視化し、社内に展開していく過程で、CoE Builderに必要なビジネススキル、テクニカルスキル、そしてアナログとデジタルをつなぐ変換力は自然に鍛えられていく。CoEは単なる推進組織ではなく、人材が育つための実践環境でもある。

さらに重要だと感じたのは、組織のデータ成熟度に応じた段階的アプローチである。最初は一部の専門家がデータで価値を出す段階から始まり、次に自社独自データを使った業務改善へ進み、最終的には経営判断や事業戦略に影響を与える段階へと発展していく。しかし、この移行は自然には起こらない。特に大企業では、トップマネジメントが本気で関与し、率先して旗を振ることが不可欠である。

もし経営層が本気で動かなければ、DXは形式的な取り組みに終わってしまう。ツールは導入されたが、組織構造も業務プロセスも意思決定の仕組みも変わらない。これでは、表面上はDXをしているように見えても、実質的には何も変わっていない。大きな組織ほど、トップが先頭に立ち、成果を可視化し、成功事例をストーリーとして広げることが重要になる。

最後に紹介された「CoE of CoE」という考え方も非常に興味深かった。個社ごとにCoEを作るだけでなく、業界全体で知見や成功パターンを共有し、共通知として蓄積していくという発想である。私はこれを聞いて、時系列分析におけるARIMAモデルを思い出した。非定常な時系列をそのまま扱うのではなく、差分を取ることで安定した構造を見出すように、個社のCoEだけでは解決しきれない課題も、業界横断の「二階層目のCoE」によって、より強い推進力を持てるのではないか。

Trust株式会社が掲げる「テクノロジーとコミュニティーで金融の未来を創る」という理念は、まさにこの考え方を表しているように感じた。最新のデジタル技術やAIを用いて古い金融システムを変革し、サービス品質を高める。そして一社だけに閉じず、複数の企業や専門家をつなぐコミュニティを形成し、成功経験を業界全体に広げていく。これは日本の金融業界だけでなく、今後の日本企業全体のDX推進にとって非常に重要な方向性だと思う。

AI活用の本質は、技術を導入することだけではない。技術を業務に接続し、人を育て、組織を変え、さらに業界全体の知見へと昇華させることにある。その意味で、CoEはAI時代の組織変革における極めて重要な装置であり、CoE of CoEはその可能性をさらに広げる概念だと感じた。

おわりに

今回のイベント全体を通じて、登壇者の方々にはそれぞれ異なる魅力があった。個人的な印象としては、友田さんは会社全体の方向性やビジョンについて、わかりやすく発信していた。深澤さんは細部まで丁寧に整理し、データサイエンスの本質を慎重に言語化されていた。大野さんはエネルギッシュで、現場での試行錯誤やRAG活用のリアルを臨場感をもって共有されていた。そして小西さんは落ち着いた語り口で、AI活用を組織としてどう推進していくべきかを大きな視点から説明されていた。

それぞれが異なる役割を担い、自分の強みを発揮しているように見えた点も、とても印象的だった。スタートアップでありながら、技術、事業、組織づくり、業界コミュニティの形成までを一体として進めようとしている姿勢から、非常に良い学習文化を感じた。

金融は社会経済の中核を担う領域であり、その現場でAIをどう活用するかは、日本全体のDXや産業競争力にも深く関わるテーマである。Trust株式会社は、まさにその難しくも重要な領域に挑戦している会社だと考える。

なお、同社は現在採用を行っているようであり、金融領域におけるAI活用やレガシーモダナイゼーション、AIエージェントとインテリジェント化などによる業務変革といった取り組みを進めている点も特徴の一つである。

金融の現場で語られたこれらの知見は、金融業界にとどまらず、AI活用やDX推進に関わるすべての人にとって重要な示唆を持っている。AIの価値は、モデルの性能だけで決まるのではない。それをどの業務に適用し、どの文脈で使い、どこに人間の判断を残し、どのような組織で支えるのか。そこまで設計して初めて、AIは現場で本当の価値を生み出すのだと思う。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?