金融機関で生成AIの全顧客展開を検討している開発者・アーキテクトに向けて、ブラジルの大手銀行Itaúの事例を整理します。規制業種で生成AIを使うときの統制設計の参考になれば幸いです。
ItaúはOpenAIと組み、顧客向けの会話インターフェース「ia.i」と、社内ガバナンス基盤「IARA」を構築しています。特徴は、単発のチャットボット導入ではなく、全顧客・全従業員を対象にした「AI First」戦略の一部として位置づけている点です。ブラジルは金融規制が厳しい市場の一つであり、そこでの生成AI運用は日本の金融・保険業界にも示唆があります。
ia.iとIARA、2つの基盤が担う役割
ia.iは顧客が銀行アプリ内で自然文のまま問い合わせや取引操作をするための対話型インターフェースです。従来のメニュー階層型UIと異なり、LLM（大規模言語モデル）が自然言語を解釈して、必要なAPI呼び出しや検索処理に振り分ける構造を取ります。
IARAはその裏側で動くガバナンス基盤です。ガバナンスとは、AIがどのデータにアクセスできるか、どの回答を出してよいかを事前に定義し、逸脱を監視する仕組みを指します。顧客向けのia.iと、行員の業務支援を分離せず同じ統制レイヤーの上に乗せている点が、この取り組みの技術的な軸になっています。
LLMパイプラインとして見た場合の構造
この構成をML（機械学習）パイプラインの観点で分解すると、一般的な企業向け生成AI導入と同じ3層構造が見えてきます。
- 入力層: ユーザーの自然言語リクエストを受け取り、意図分類・エンティティ抽出を行う層
- 推論・検索層: LLM単体の知識ではなく、社内データベースや商品マスタを参照するRAG（検索拡張生成、外部知識を検索してLLMの回答に組み込む手法）を組み合わせる層
- 統制層: 回答前にコンプライアンスルールやPII（個人を特定できる情報）マスキングを適用し、ログを記録する層
IARAはこの3層目、統制層をプラットフォーム化したものと捉えると理解しやすくなります。金融機関がLLMを顧客接点に出す際、最大のリスクは「モデルが規制に反する発言をする」「個人情報を漏らす」という点にあり、ここをアプリケーションごとに個別実装すると監査が困難になります。共通基盤として切り出すことで、新しいユースケースを追加するたびに同じ統制ロジックを再実装せずに済みます。
RAGとファインチューニング、どちらを選ぶか
金融機関のドメイン知識をLLMに持たせる方法は大きく2つあります。ファインチューニング（追加学習でモデルの重みを更新する手法）と、RAG（都度検索して最新情報をプロンプトに注入する手法）です。
商品約款や金利、キャンペーン情報のように更新頻度が高いデータは、ファインチューニングでは陳腐化が早く、再学習コストも発生します。こうした領域はRAGとの相性がよく、ベクトルデータベース（文章を数値ベクトル化して意味的に近い文書を検索する仕組み）に最新の商品情報を格納し、問い合わせ時に検索して回答を生成する構成が一般的です。
一方で、銀行特有の言い回しや行内の文書フォーマットへの適応は、軽量なファインチューニング（LoRAなどのパラメータ効率的手法）と組み合わせることもあります。全顧客規模での展開では、更新コストと精度のバランスを取るため、RAGを主軸にしつつ応答スタイルの調整にファインチューニングを併用する設計が現実的な落としどころです。
日本の金融機関が確認すべきポイント
日本でも全銀協のガイドラインや金融庁のモニタリング方針の中で、AI活用における説明可能性やログ保存が論点になっています。Itaúのような会話型AI基盤を検討する場合、以下を自社のプロジェクトに当てはめて確認すると判断がしやすくなります。
- 統制層の分離: コンプライアンスチェックをアプリケーション層に埋め込まず、独立したミドルウェアとして設計できているか
- 監査ログの粒度: LLMへの入力プロンプト・検索結果・最終出力の3点をそれぞれ別ログとして保存できているか
- RAGのデータ鮮度: ベクトルDBの更新頻度と、商品改定のリリースサイクルが一致しているか
- PIIマスキングのタイミング: LLMに渡す前段でマスキングするか、出力後にフィルタするかを明確に決めているか
- フォールバック設計: LLMが回答できない・信頼度が低いと判断した場合に、有人対応へエスカレーションする閾値があるか
自社で生成AIプロジェクトの設計書やアーキテクチャ図がある場合は、統制ロジックがどのレイヤーに実装されているかを一度洗い出してみると、Itaúの構成との差分が見えてきます。個別のチャットボットごとにガードレール（モデルの出力を制限する安全策）を実装していないか、共通化できる部分が埋もれていないかをチェックする出発点になります。
まとめ
Itaúのia.iとIARAは、生成AIを顧客接点に出す際の統制設計を基盤化した事例として参考になります。
振り返ると要点は次の3つです。
- 顧客向けUIと社内統制基盤を分離し、共通ガバナンス層の上に両方を乗せる構造
- 更新頻度の高いドメイン知識はRAG、応答スタイルの調整は軽量ファインチューニングという使い分け
- 監査ログ・PIIマスキング・フォールバック設計を独立したレイヤーとして持つことの重要性
自社の生成AI計画が個別アプリ単位の実装にとどまっていないか、統制ロジックの共通化余地があるかを、まず現行アーキテクチャ図の見直しから始めてみてはいかがでしょうか。