金融機関の生成AIがRAGで止まる構造的理由とAIエージェントへの移行設計

「導入はした。でも、結局は社内文書の検索を少し楽にしただけだった」。地銀や信金、証券会社の担当者から、私たちが現場でよく聞く言葉がこれだ。日本銀行の調査によれば、国内金融機関の約5割がすでに生成AIを業務利用しており、検証中を含めると7割強が何らかの形で取り組んでいる。数字だけ見れば先進的に映るが、日本総研の調査が示すように、導入目的は文書の要約・校正・翻訳や規程検索など作業単位の効率化が大半を占めており、ビジネス変革につながるユースケースは未確立の状態が続いている。この「PoCはできた、でも止まっている」という状況の原因を、技術やガバナンスの問題として語る解説は多い。しかし私たちが現場で見てきた範囲では、根本にあるのはタスク分解設計の欠如という、もっと地味で実務的な問題だ。本記事では、その構造的な理由を整理したうえで、金融機関がAIエージェントへ進むための具体的な設計の考え方を示す。

この記事の対象読者

• 地銀・信金・証券会社でIT企画・DX推進を担っており、生成AIのPoC経験はあるが次フェーズに進めていない方
• 稟議・審査・融資判断などのコアプロセスにAIを適用したいが、どこから手をつければよいか分からない方
• 生成AIへの投資を継続するための社内説得材料（ROI・ガバナンス設計）を探している方
• AIエージェントという言葉は知っているが、自行庫の業務にどう接続するかイメージできていない方

なぜ金融機関の生成AIはRAGで止まるのか

金融機関が生成AIを導入する際、最初に手が届きやすいのは「社内文書をLLMに読ませて検索・要約させる」RAG構成だ。規程集・商品説明書・過去の稟議書をベクターデータベースに格納し、行員が自然言語で問い合わせると関連文書が返ってくる。初期の成果は出やすく、「検索時間が減った」という感触も得やすい。しかしこの段階で多くの組織が止まる。

NTTデータのレポートが指摘するように、LLM＋RAGの段階では効率化は「作業単位」に留まり、業務プロセス全体の変革にはAIエージェントによる複数タスクの自律実行が必要になる。ところが私たちが見てきた範囲では、このギャップを認識していても「次に何を設計すればよいか」が分からないまま時間が経過するケースが多い。

止まる理由は大きく3つに整理できる。

• タスク分解設計がない：稟議や審査を「1つの業務」として扱い続けている。AIが自律的に動くには、「情報収集」「リスク判定」「ドラフト生成」「承認ルーティング」といったサブタスクへの分解が前提になるが、この設計が行われていない
• 既存フローとの接続設計がない：RAGは「回答を返す」ところで完結するが、エージェントは「次のシステムに値を渡す」必要がある。既存の基幹システム・ワークフローツールとのAPI接続設計が未着手のまま止まるケースが多い
• ROI測定指標が曖昧なまま次フェーズに進もうとしている：RAGの段階で「時間削減」の数値が取れていないと、エージェント化への投資を社内で通すための根拠が薄くなる。初期PoC設計に測定設計が組み込まれていないことが後で響く

また、日本総研の調査が示すように、金融業界はコンプライアンス要件の高さからAIの自律的判断範囲が制限されやすい。これをガバナンス上の「壁」として捉えるのではなく、設計段階でAIが判断できる範囲と人間が介入するポイントを明示的に区切ることが、むしろ規制対応を前進させる設計になる。

みっちゃくんを見る

AIの適用領域：作業単位から業務フロー単位へ

現状の金融機関における生成AI活用は、以下のような「作業単位」が中心になっている傾向がある。

• 社内規程・商品説明書の検索・要約（RAG）
• 会議議事録の自動生成
• 顧客向け文書の校正・翻訳
• コンプライアンスチェックの一次スクリーニング支援

これらは確かに有用だが、各タスクが独立して完結しており、業務プロセス全体への影響は限定的だ。次のフェーズで狙うべきは「業務フロー単位」の適用で、金融機関の文脈では以下の領域が実装可能性と業務インパクトのバランスが取りやすい。

重要なのは、エージェントに「判断」を委ねるのではなく、「情報収集・整理・ドラフト生成」までを担わせ、判断は人間に残す設計から始めることだ。これは規制対応上の要件でもあるが、同時に現場の受容性を高める実務上の工夫でもある。

導入の進め方とROI：稟議・審査フローのAPI化から始める

「AIエージェントを導入する」と宣言すると、技術選定や新規システム構築の話に引っ張られやすい。私たちが現場で有効だと見てきたのは、「既存の稟議・審査フローをAPIとして再定義する」という切り口から入ることだ。つまり、今ある業務フローを分解し、各ステップの「入力・処理・出力」を明示化する作業から始める。

ステップ1：対象フローのタスク分解

まず1つの業務フロー（例：中小企業向け融資の稟議準備）を選び、現状を以下の粒度で書き出す。

• どのデータソースから何を取得しているか（財務諸表、信用情報、担保評価データなど）
• 取得したデータをどう加工・判定しているか（計算式、チェックリスト、担当者の経験則）
• どのドキュメントを生成しているか（稟議書のフォーマット、添付書類の一覧）
• どのシステム・人物に渡しているか（承認者、基幹システムへの入力）

この「書き出し」自体が、エージェント設計の仕様書になる。多くの場合、ここで初めて「実は担当者のExcel管理に依存しているステップがある」「承認フローが文書化されていない」という実態が可視化される。

ステップ2：AIが担えるステップの特定とROI測定設計

タスク分解が終わったら、各ステップを以下の基準で仕分けする。

• AIが担えるステップ：ルールが明確・入力データが構造化されている・出力フォーマットが固定されている
• 人間が担うべきステップ：例外判断が必要・顧客との対話が含まれる・規制上の最終承認が必要
• 現状では自動化できないステップ：データが紙ベース・システム間の連携APIが存在しない

このフェーズで同時にROI測定設計を組み込む。「現在このステップに何分かかっているか」「月何件処理しているか」を記録しておく。これを怠ると、エージェント化後の効果を数値で示せなくなり、次フェーズへの予算確保が難しくなる。

ステップ3：ガバナンス要件の先行設計

NTT東日本のレポートが示すように、企業がAI導入を進める際にはセキュリティやコンプライアンスへの対応が主要な課題になり、金融機関ではとくにこの傾向が強い。ガバナンス設計は後付けにするほど修正コストが上がる。エージェント化の実装前に、以下の3点を設計しておく。

• 監査ログの自動生成：エージェントがいつ・何のデータを参照し・何を出力したかを記録する仕組み。金融機関の検査対応上、これは必須になる
• 承認フローとの連携：エージェントが生成したドラフトがどのルートで承認者に届き、どのシステムに反映されるかを既存フローと接続する
• 例外処理時の人間介入設計：エージェントが処理できないケースを検知し、担当者にエスカレーションする条件と通知方法を決める

この3点が先に決まっていれば、「AIが勝手に判断した」という批判を避けながら段階的に自動化範囲を広げていける。

ステップ4：小さく実装・測定・拡張

最初のエージェント実装は、ステップ1〜3で特定した「AIが担えるステップ」のうち1〜2つに絞る。全フローの自動化を一度に目指さない。測定設計を入れたうえで4〜8週間稼働させ、処理時間・エラー率・担当者の手戻り件数を記録する。この数値がフェーズ2・3への投資を社内で通すための根拠になる。

現場で見てきた事例と留意点

私たちが関わってきた案件の中で、金融機関がRAGからエージェントへ進めた場面には共通するパターンがある。一方で、見落としがちな落とし穴もある。

進めた場面に共通するパターン

• 業務フローを「知っている人」が設計チームにいた：システム部門だけで進めず、実際に稟議書を書いている融資担当者や審査部門の担当者がタスク分解に参加していたケース
• 「使わなかった時との比較」を最初から測定していた：時間削減・手戻り削減・検索回数などの指標を、PoC開始前にベースライン計測していたケース
• コンプライアンス部門を設計の早い段階に巻き込んでいた：後からガバナンス要件を追加するのではなく、監査ログと介入ポイントを設計段階から組み込んでいたケース

見落としがちな落とし穴

• RAGのチューニングコストを過小評価している：データの前処理・チャンキング設計・検索精度の調整には相応の工数がかかる。RAGの段階で予算を使い切ってしまい、エージェント化への投資余力がなくなるケースがある
• 「エージェント化」と「RPA」を混同している：RPAはルールベースの操作自動化であり、エージェントは状況判断を伴う。既存RPAと生成AIエージェントの役割分担を設計段階で整理しておかないと、後で二重管理が発生する
• ベンダーの「全自動」デモを鵜呑みにする：デモ環境では整備されたデータで動いているが、実業務では非構造化データ・例外ケース・紙書類のスキャンデータが混在する。実データでの動作確認を早期に行うことが不可欠

金融機関向けAIエージェント設計の相談をする

よくある質問

RAGをすでに導入している場合、エージェント化にどれくらいの期間がかかりますか？

対象フローの複雑さとシステム連携の状況によって大きく変わるが、私たちが見てきた範囲では、タスク分解設計から最初のエージェント稼働まで3〜4ヶ月が目安になるケースが多い。RAGで整備したデータ基盤はそのまま活用できるため、ゼロからの構築よりは短縮できる。ただし、既存システムとのAPI接続が未整備な場合はここが工数のボトルネックになる。

IT専任部門が小さい地銀・信金でも実現できますか？

可能だが、全社横断の大規模実装から始めることは推奨しない。1つの支店・1つの業務フローを対象に限定し、外部支援を活用しながら設計・実装・測定のサイクルを回すことが現実的だ。内部に設計の知見が蓄積されれば、2件目以降は自走できる範囲が広がる。重要なのは「全部やろうとしない」ことと、「測定できる形で始める」ことだ。

金融庁の監督指針との関係はどう整理すればよいですか？

2026年時点では、金融庁はAIの活用を禁止するスタンスではなく、「説明可能性」「モニタリング」「ガバナンス体制の整備」を求める方向で議論が進んでいる。本記事で示した監査ログの自動生成・承認フロー連携・人間介入設計の3点は、こうした監督上の観点とも整合する。ただし個別の案件では法律・コンプライアンス専門家への確認を必ず行うことが前提になる。

AIが生成した稟議ドラフトの品質はどう担保しますか？

「品質」の定義を先に決めることが重要だ。「誤字脱字がない」「必要項目が揃っている」「数値の計算が正しい」といった確認可能な基準に分解し、チェックリストとして実装する。人間の担当者が最終確認する前提で使うなら、「ドラフトの完成度7〜8割」を目標にする方が安定した運用につながる。完璧な自動生成を目指すよりも、担当者の確認・修正コストを下げることを目的に設定した方がROIの測定もしやすい。

金融機関の生成AIが「RAGで止まる」のは、技術が追いついていないからでも、ガバナンスが厳しすぎるからでもない。既存の業務フローをタスク単位に分解し、各ステップの入出力を明示化するという設計が行われていないことが根本にある。稟議・審査フローをAPIとして再定義する視点を持ち込み、監査ログ・承認フロー連携・人間介入ポイントの3点を先に設計したうえで小さく実装・測定するサイクルを回すことが、地銀・信金・証券会社がPoCループから抜け出すための実務的な道筋になる。大手行と同じ規模の投資をする必要はない。1つのフローを正しく設計・測定することが、次への投資根拠をつくる。