BarclaysとClaudeが示す金融AI本番運用｜大企業は生成AIをどう安全に拡大するか

目次

---

1. 生成AIの本番導入は「使わせる」から「統制して広げる」段階へ進む

生成AIを全社で使うとき、最初の壁は「社員に使ってもらうこと」です。ところが、一定の利用が進むと次の壁が見えてきます。どの業務に使えば成果が出るのか。顧客情報や社内データをどう守るのか。AIが出した答えを誰が確認するのか。利用量とコストをどう管理するのか。つまり、本番導入の難しさは、モデルの性能だけではなく、業務設計とガバナンスに移っていきます。

Anthropicが2026年10月1日に発表したBarclaysとの協業拡大は、この段階をよく示しています。Barclaysは、Claudeをソフトウェア開発、レガシーシステムの近代化、顧客対応、業務効率化へ広げる方針を示しました。特に注目すべきなのは、Claude Codeの利用を2026年末までに開発者人口の50%へ、2027年にはソフトウェアエンジニアの過半へ広げる見通しです。これは、AIを一部の実験的なチームだけで使う話ではなく、大規模な金融機関の業務基盤に組み込む話です。

金融機関は、生成AIにとって最も分かりやすい実験場ではありません。規制、監査、個人情報、顧客対応、サイバーセキュリティ、レガシーシステムが重なります。その環境でAI活用を広げるということは、便利なツールを配るだけでは成立しません。どの情報にアクセスできるか、どの処理を自動化するか、どこで人間が確認するか、どのログを残すかを、業務ごとに設計する必要があります。

この記事では、AnthropicとBarclaysの公式発表を題材に、企業が生成AIを本番運用へ広げるときの実務設計を整理します。金融業界だけでなく、社内データ、顧客対応、開発組織、業務メール処理を持つ大企業にとって、同じ論点がそのまま当てはまります。

2. BarclaysとAnthropicの発表で何が示されたのか

Anthropicの公式発表によると、BarclaysはClaudeをグローバルな業務全体に統合し、ソフトウェア開発、レガシーシステムの近代化、業務効率化を進めています。AI導入を単体ツールの導入ではなく、顧客対応と社内業務の両方を変える取り組みとして位置づけている点が重要です。

すでに動いている例として、Barclays UKの従業員向けにColleague Knowledge Assistantが提供されています。Anthropicの発表では、この仕組みはClaudeを使ったRAG、つまり検索拡張生成のアーキテクチャで動いており、2025年から稼働しています。16,000人を超える同僚が採用し、100万件を超える検索を処理していると説明されています。Barclays UKは2,000万人を超える英国リテール顧客を支えているため、社内の情報検索速度は、そのまま顧客対応の速度に響きます。

もう一つの例は、Global Markets部門のメール処理です。Claudeモデルは、顧客からの問い合わせメールを分類し、補足情報を付け、処理ルートを判断する用途に使われています。公式発表では、このプラットフォームが1日約120,000通のメールを処理しているとされています。これは単なる要約機能ではありません。問い合わせをどの業務キューに流すか、必要情報が足りているか、優先度をどう見るかという、オペレーションの入口をAIが支える設計です。

さらに、BarclaysはClaude Codeを開発組織へ広げています。発表では、2026年末までに開発者人口の50%へ採用を広げ、2027年にはソフトウェアエンジニアの過半へ拡大する見通しが示されました。レガシーシステムの近代化、ソフトウェア品質の改善、技術者が複雑な課題へ集中するための支援が主な狙いです。

この三つの事例には共通点があります。すべて「AIに自由に質問する」使い方ではなく、業務の中にAIの役割を置いています。知識検索では、社内情報を探して回答案を出す。メール処理では、分類とルーティングを支える。開発では、コード作成や近代化作業を補助する。それぞれの用途で、入力、参照データ、出力、確認者、ログが異なります。大企業の生成AI導入では、この粒度で設計することが成果につながります。

3. 価値はチャット導入ではなく、業務単位の処理設計にある

多くの企業が生成AI導入でつまずくのは、AIを「全社員が使えるチャット」として配って終わってしまうことです。もちろん、個人の文章作成や調査補助には効果があります。しかし、本番運用として大きな成果を出すには、業務ごとにAIの役割を定義する必要があります。Barclaysの発表が示しているのは、まさにこの違いです。

知識検索の領域では、AIは社員の質問に答えるだけでは不十分です。どのドキュメントを参照したのか、古い規程を使っていないか、顧客対応に使ってよい内容なのか、回答に不確実性があるときにどう人間へ戻すのかを決める必要があります。RAGは、社内文書を検索して回答に使う便利な仕組みですが、検索対象の品質が低ければ、AIの回答も揺れます。実務では、ナレッジベースの棚卸し、文書の版管理、アクセス権限、回答ログの確認までセットで考えるべきです。

メール処理の領域では、AIの価値は文面の要約だけではありません。どの部署が処理すべきか、必要な情報がそろっているか、緊急性が高いか、過去の似た問い合わせと同じ対応でよいかを判断する支援に価値があります。1日約120,000通のメールを扱う規模では、人間がすべてを同じ精度で分類することは難しくなります。AIは、この入口処理を標準化し、例外を人間へ戻す役割を担えます。

開発組織では、AIの導入効果はコード補完だけでは測れません。レガシーシステムの理解、影響範囲調査、テスト作成、リファクタリング案、セキュリティ指摘、レビュー補助まで含めて、開発プロセスのどこにAIを入れるかが重要です。特に金融機関のように長く使われてきたシステムが多い環境では、AIに「新規コードを書かせる」だけでなく、既存システムを安全に読み解く支援が大きな価値になります。

ここで見るべき指標も、利用者数だけでは足りません。知識検索なら、解決率、再検索率、人間へのエスカレーション率、回答修正率を見る。メール処理なら、分類精度、処理時間、差し戻し率、未処理滞留を見る。開発支援なら、レビュー差し戻し、テスト通過率、脆弱性指摘、変更リードタイムを見る。AI導入のKPIを業務KPIに接続しないと、利用は増えても成果が見えなくなります。

4. 金融AIで先に整えるべきガバナンス

金融機関のAI活用では、スピードだけを追うと危険です。顧客情報、取引情報、規制対応、システム変更、サイバーセキュリティが関わるため、AIが便利なほど、統制の設計が重要になります。Anthropicの発表でも、Barclaysが堅牢なガバナンス、セキュリティコントロール、人間の監督を適用していることが強調されています。

第一に、データアクセスを用途ごとに分ける必要があります。顧客対応向けの知識検索AIが参照すべきなのは、承認済みのFAQ、手続き資料、商品説明、運用ルールです。一方で、開発支援AIが参照すべきなのは、コードベース、仕様書、チケット、テスト結果です。顧客情報や本番認証情報に無制限に触れられる状態は避けるべきです。用途が違えば、アクセスできるデータも変える必要があります。

第二に、AIの出力をそのまま業務判断にしないことです。知識検索の回答は顧客へ伝える前に確認が必要です。メール分類は、低リスクな振り分けから始め、重要顧客や例外処理は人間へ戻す方が安全です。コード修正は、AIが提案やPull Request作成を支援しても、レビュー、テスト、マージ、本番反映は既存の変更管理に乗せるべきです。AIを使うからといって、業務上の責任分界を消してはいけません。

第三に、ログを後から説明できる粒度で残します。誰がAIに依頼したのか。AIはどのデータを参照したのか。どのような回答や分類を返したのか。人間がどこを修正したのか。どの業務結果につながったのか。これらが追えなければ、品質改善も監査対応も難しくなります。特に金融、医療、公共、法務のような説明責任が重い領域では、AIのログは単なるデバッグ情報ではなく、業務証跡です。

第四に、モデル利用量と費用を部門別・用途別に見る必要があります。全社でAI利用を広げると、利用量は自然に増えます。チャット利用なら個人単位の費用管理で足りる場合もありますが、メール処理や開発支援のように業務システムへ組み込むと、費用はトランザクション量に連動します。1件あたりの処理費用、手戻り削減、対応時間短縮、品質改善を合わせて見なければ、投資対効果を判断できません。

整理すると、金融AIのガバナンスでは次の観点が必要です。

5. 大企業が生成AIを安全に拡大するための実装ステップ

Barclaysのような規模でAIを広げるには、全社展開を一度に狙うより、業務単位で実装し、評価し、横展開する方が現実的です。最初から全社員に「自由に使ってください」と配ると、便利な使い方は増えますが、成果の測定とリスク管理が難しくなります。

最初のステップは、業務を選ぶことです。候補は、問い合わせ量が多い、判断基準が文書化されている、人間確認を入れやすい、成果を測りやすい領域が向いています。社内FAQ、顧客対応ナレッジ、メール分類、開発支援、稟議文書の確認などです。逆に、責任が重く、前提が曖昧で、即時に外部へ影響する処理は後回しにした方が安全です。

次に、AIの役割を限定します。たとえば知識検索なら「承認済み文書から回答案を作る」までにする。メール処理なら「分類と不足情報の検出」までにする。開発支援なら「影響範囲調査、テスト案、修正候補」までにする。更新、送信、削除、本番反映のような操作は、最初は人間承認を必須にします。役割を小さく始めるほど、失敗の範囲を制御できます。

三つ目は、評価データを作ることです。AIを導入してから評価するのではなく、導入前に代表的な問い合わせ、メール、コード修正、ナレッジ検索の評価セットを用意します。正答例、許容できる回答、不許可の回答、エスカレーションすべきケースを決めておくと、モデルやプロンプトを変えたときにも比較できます。生成AIの本番運用では、評価データはセキュリティ設定と同じくらい重要です。

四つ目は、ログから改善する運用を作ることです。社員がどんな依頼をしているか、AIがどこで迷っているか、どの回答が修正されたか、どの文書が参照されすぎているかを見ると、AIだけでなく業務文書そのものの改善点も見えます。RAGの精度が低い場合、モデルを変える前に、社内文書の重複、古い版、曖昧な表現を直す方が効果的なこともあります。

導入ステップをまとめると、次の順番が現実的です。

1. 高頻度で成果を測りやすい業務を1つ選ぶ
2. AIに任せる範囲を、検索、分類、下書き、提案に限定する
3. 参照データとアクセス権限を用途ごとに分ける
4. 代表ケースとNGケースを含む評価データを作る
5. 人間確認、承認、差し戻しの流れを業務に組み込む
6. 利用ログ、品質ログ、費用ログを同じ業務IDで追う
7. 成果が見えた用途から、隣接業務へ横展開する

この進め方なら、AI導入を「話題のツールを使う」段階から、「業務プロセスを改善する」段階へ移せます。Barclaysの事例が示すように、大企業の生成AI活用は、派手なデモではなく、顧客対応、メール処理、開発支援のような日常業務の中で価値を積み上げる形に向かっています。

6. まとめ

AnthropicとBarclaysの発表は、生成AIの企業導入が実験段階から本番運用段階へ移っていることを示しています。16,000人を超える同僚が使う知識検索、100万件を超える検索実績、1日約120,000通のメール処理、開発者人口の50%へのClaude Code展開計画。これらは、AIを個人の便利ツールとしてではなく、業務の処理基盤として扱う動きです。

ただし、大企業でAIを広げるほど、設計すべきことは増えます。データアクセス、RAGの文書品質、メール分類の例外処理、開発支援のレビュー、監査ログ、費用管理、人間承認。これらを後回しにすると、利用は広がっても、信頼できる業務基盤にはなりません。特に金融のような高い説明責任が求められる業界では、AIをどこで使うかだけでなく、どこで止めるかを先に決める必要があります。

OpenBridgeでは、AIエージェント、RAG、社内ツール連携、監査ログ、権限管理、業務システム開発を組み合わせ、企業ごとの生成AI本番運用を支援しています。Barclaysのような大規模事例から学ぶべきなのは、特定のモデル名だけではありません。AIを業務の中に安全に置き、測定し、改善し、広げるための運用設計こそが、企業の生成AI活用を次の段階へ進める条件になります。