みゅとすの衝撃 付録2：J金融IT多重下請構造3例提示、米銀等はモダナイズを推進

前号（付録1）でご紹介したパワポファイル（NotebookLMで作成、下に再掲）の基礎原稿を、お示しします。

日本の金融IT構造における多重下請体制：具体例3つ

巨大システムを更改する時、あるいは複数組織のシステムを統合する時などにも多重下請体制で対応してきた日本の金融業界においては、意図しないセキュリティホールが発生することが多く、またそのことに気づかないまま放置されてきた状況があります。そこへClaude Mythosのように強力なAIが登場すると、容易に脆弱性が発見されるため、高度なAIで武装したサイバー攻撃に対しては、今後、本質的に新しい防御体制の構築が要求されます。

日本の金融市場（主に金融機関のITシステム開発・運用分野）における多重下請け体制の具体例を通じて問題意識の前提を再確認します。日本では、金融機関の大規模システム開発・保守・運用が「金融市場の基盤」として極めて重要ですが、大手SIer（システムインテグレーター）を頂点とした多重下請け構造（元請け→2次・3次・…下請け）が常態化しています。これは、巨額の開発需要、人材不足、リスク分散を背景に生まれたもので、コスト削減の一方でセキュリティリスクや責任所在の曖昧化、品質低下を招く問題点も指摘されています（公正取引委員会のソフトウェア業下請取引実態調査でも、金融業・保険業は発注上位業界の一つ）。 以下に具体例を3つ挙げます（主に銀行・証券などの金融機関の基幹・取引システム関連）。

1. みずほ銀行の新勘定系システム「MINORI」開発プロジェクト
みずほ銀行（現・みずほFG）が銀行合併後のシステム統合で構築した大規模勘定系システム（総額約4,000億円規模）。大手SIer（富士通、日立、NTTデータ、日本IBMなど4社が主要元請け・共同開発）が一次請けとして全体を統括し、約1,000社規模のITベンダー（2次請け以下の中堅・中小SIer、SES企業）が多層的に関与した極端な多重下請け事例です。2021年の大規模システム障害では、「責任所在が不明瞭になった」「下請けの管理が不十分だった」との指摘があり、多重下請け構造が問題視されました。金融市場の基幹処理（預金・融資・決済など）を支えるシステムとして典型例です。

2. NTTデータの「地銀共同センター」運用（地方銀行向け共同基幹システム）
NTTデータが運営する地方銀行・第二地方銀行向け勘定系共同利用センター（参加行：京都銀行、千葉興業銀行など複数）。NTTデータが元請け・運用主体となり、システム開発・保守・運用を2次・3次下請け企業に多重委託する構造です。2012年のキャッシュカード情報不正取得事件では、多重下請けによるセキュリティ管理の抜け穴（下請け先での不正アクセス）が露呈し、情報サービス業界全体の弱点として話題になりました。現在も地銀の勘定系・取引系システムの多くを支えるインフラで、金融市場の地域金融基盤として多重下請けが定着しています。

3. 野村證券・NRI「STARシステム」障害（2013年） — 市場系システムの多重下請けが露呈した大規模影響事例
野村證券をはじめとする大手証券会社は、株式・債券の注文処理、約定、クリアリングなどの市場系システムを野村総合研究所（NRI）に一次委託しています。NRIは「STAR」（証券共同利用プラットフォーム）を開発・運用し、国内約49社の証券会社に提供していました。 2013年5月13日、STARシステムのバージョン更新作業中にバージョンの不整合が発生。接続不具合により、東証など取引所システムへの発注・約定処理が停止。午前中に障害が発生し、午後1時30分に全面復旧するまで約40社超の証券会社に影響が及びました（野村證券を含む複数社で発注・取引に支障）。

多重下請け構造の特徴
・元請け：NRI（野村證券などから一次受託）
・二次・三次以降：NRIグループ企業や中堅SIer、SES企業による開発・保守・更新作業
・保守運用フェーズで多層化が進み、更新時のテスト・整合性確認が十分に共有されなかったと指摘されました。

この障害は金融市場の取引インフラに直接影響を与えるクリティカルな事例で、顧客の注文遅延・機会損失が発生。責任所在の曖昧化（誰が最終的な整合性検証を担うか）が問題視され、多重下請けによる管理の盲点が顕在化しました。NRIは以降、STARの運用体制強化を図りましたが、人材不足と大規模共同システムの複雑さから、こうした多層委託構造は今も根強く残っています。

これらの事例は、金融機関自身が直接開発せず外部委託を多用する日本特有の事情（レガシーシステムの複雑さ、合併統合の頻発）によるものです。最近はDX推進やクラウド移行で「多重下請け脱却」や内製化の動きも見られますが、まだ根強い構造です。

素朴に考えて、しかし例えばアメリカの金融業界に同様な構造問題はないのか？

顕著な多重下請体制の弊害事例は、上記のように確認できます。しかし、アメリカでは、このような構造はないのでしょうか？　多重下請を使わなくとも完結できるシステムが本当にあるのか、と疑問に思う方がいても不思議ではありません。例えば、多数の金融機関がM&Aで統合されて現在のJPモルガンチェースがありますが、彼らのシステムには「つぎはぎ状態」の構造などないのか、確認しなければなりません。

はい、アメリカの金融機関（特に大手銀行）では、日本のような「大手SIerを頂点とした極端な多重下請け構造（元請け→2次→3次以下のSES [System Engineering Service] を多用）」は一般的ではなく、構造的に異なります。ただし、完全になくはない（規制で厳しく管理される形）ですし、M&A後の「つぎはぎ状態（legacy systemsの patchwork）」も歴史的に存在しました。ただし、大手銀行は巨額投資と内製力を活かして、それを解消する動きが強く進んでいます。以下で、具体的な金融機関の例に沿って詳しく説明します。

1. アメリカ金融ITの基本構造（日本との違い）

• 多重下請けの度合いが浅い：
  米国ではThird-Party Risk Management (TPRM)という規制が非常に厳しく、OCC（通貨監督庁）や連邦準備制度理事会（Fed）のガイドラインで、第三者（third-party）だけでなく第四者（fourth-party = 下請けの下請け）までのリスクを銀行自身が直接監視・管理する義務があります。
  これにより、日本のように「元請けSIerが責任を丸投げ→多層下請けで責任曖昧」という構造は抑えられています。
  実際の委託形態はTier-1ベンダー（Accenture, IBM, Cognizant, TCS, Infosysなど）と直接契約が主流で、そこから先の下請けは浅く、契約で明確に制限・監査権を確保します。

• 内製（in-house）重視が強い：
  大手銀行は自社に数万人のITエンジニアを抱え、コアシステムの多くを内製開発しています（日本企業はユーザー企業内のIT人材比率が低い一方、米国は逆）。
  アウトソーシングは主にコスト削減目的のオフショア（インドなど）やクラウド（AWS, Azure）に限られ、多重下請けに頼らず完結できるケースが多いです。

2. JPモルガン・チェース（JPM）の具体例 — M&A後の「つぎはぎ状態」はどうなったか？

JPモルガンチェースはChase Manhattan、Bank One、Bear Stearns（2008年）、Washington Mutual、First Republic（2023年）など大規模M&Aを繰り返した典型例です。

• 過去のつぎはぎ状態：
  M&A直後は確かに複数のレガシーシステム（勘定系、取引系、顧客管理など）が混在し、統合が大きな課題になりました。2002年にはIBMにIT運用を大規模アウトソース（約90億ドル契約）しましたが、2004年に大部分をインソース（自社回帰）しました。これは「外部依存のリスク」と「統合の遅れ」を痛感した結果です。

• 現在は積極的に解消中：

  • 年間IT投資額は150〜200億ドル超（日本大手銀行の数倍規模）。

  • 約65,000人のソフトウェアエンジニアを抱える世界最大級の内製チーム。

  • 6,000以上のアプリケーションのうち70%超をクラウド（主にAWS）に移行済み。4,000アプリを事前モダナイゼーション（マイクロサービス化・API化）してから移行。

  • コアバンキングシステムもThought Machine（クラウドネイティブ）採用など、legacyを段階的に置き換え中。

  • 支払いプラットフォームも自社フルスタック（Helixなど）で統合し、「つぎはぎ」を減らしています。

つまり、M&Aで一時的に「つぎはぎ状態」になったことは事実ですが、日本のような慢性化した多重下請け構造に依存せず、大規模内製投資で解消できるのがJPM（および他の米大手銀行）の特徴です。完全になくなったとは断定できませんが、構造的に「つぎはぎを許容しない」方向に大きく進んでいます。

3. 多重下請けを使わずに「完結できる」システムは本当に存在するのか？

• 存在します（特に大手レベルで）。
  JPモルガンの事例で確認できるように、米国大手銀行は「内製＋Tier-1直接委託＋クラウド」という組み合わせで大規模システムを運用しており、日本特有の「多重下請け依存」は薄いです。理由は①規制の厳しさ、②人材市場（専門家を直接雇用しやすい）、③巨額IT投資余力の3点です。

ただし、中小金融機関ではコアプロセッシングを外部ベンダー（FIS、Jack Henryなど）にアウトソースするケースはあり、そこに一定の階層化は生じ得ます。日本との違いは文化・制度的なものが大きく、日本では人材不足＋レガシー複雑さで多重下請けが定着しやすい一方、米国は「責任を明確に持ち、内製でコントロールする」文化が強いと言えます。

BofA、Wells Fargo、Citiの事例も見てみる

引き続き、事例に沿って、アメリカの金融業界におけるM&A後の「つぎはぎ状態」の解消方法やクラウド活用の特徴も織り交ぜて説明します。米国銀行は日本とは異なり、巨額の内製IT人材（数万人規模）予算と直接クラウド契約を前提に、責任を明確に持ち、legacyシステムを段階的にモダナイズ（事前近代化）してから移行するアプローチが主流です。

4. Bank of America（BofA）のクラウド移行事例とIT構造

• クラウド戦略の特徴（2025-2026最新）：
  Hybridクラウド（仮想プライベートクラウド中心＋必要時パブリッククラウドバースト）を採用。CIO（Gopalkrishnan氏、2025年発言）によると、自社仮想プライベートクラウド（VPC）を主力とし、セキュリティ・コスト管理のためワークロードを「近くに置く」方針。AWS、Azure、Google Cloudなど複数パブリッククラウドに「必要に応じてバースト」する柔軟運用です。
  過去に自社データセンター大量統合で年間数十億ドルのコスト削減を実現した経験を活かし、現在もpayments（決済）インフラ全体をクラウド基盤に構築中（2025年11月、ISO 20022・SWIFT GPI対応）。AI（Erica仮想アシスタント）やデジタルプラットフォームもこの環境で動いています。

• 規模・投資額：
  年間技術予算約130億ドル（2025年）、うち40億ドルをAI・新技術に充当。クライアントとのデジタル接点は2025年に300億回超（前年比14%増）。M&A後のlegacy統合は大規模内製チームで進め、多重下請けに頼らず直接管理。

• M&A後のつぎはぎ解消：
  BofAは過去の合併（例：Merrill Lynchなど）でlegacyが混在しましたが、内製＋hybridクラウドでモダナイズを進め、責任所在を明確化。現在は「つぎはぎ」を最小限に抑えた状態です。

5. Wells Fargoのクラウド移行事例とIT構造

• クラウド戦略の特徴（2025-2026最新）：
  Multi-cloud / Hybridアプローチ。Azureをbusiness-criticalアプリのprimary public cloudとし、Google Cloudを先進AI・データ・複雑ワークロードに特化（2025年にGoogle Cloudとの提携拡大、Agentic AI（Google Agentspace）を全事業部門に展開中）。
  4,500以上のアプリケーションを対象に大規模モダナイゼーションを実施（CAST Highlightツールでコード自動分析・移行計画を数週間で作成）。Legacyアプリ（10年以上未更新のもの多数）が課題ですが、企業規模の自動化フレームワークでcloud-native移行を推進中。データセンター縮小・クラウドシフトの10年ロードマップを継続しています。

• デジタル成果：
  AI仮想アシスタント「Fargo」が2026年3月時点で10億回超の顧客インタラクション達成（ローンチから3年未満）。モバイルアクティブユーザー3300万人超。AI・クラウドを活用した効率化が明確です。

• M&A後のつぎはぎ解消：
  過去の合併でlegacyが蓄積しましたが、現在は内製エンジニアリングチームとTier-1ベンダー（直接契約）を組み合わせ、事前モダナイゼーションを徹底。TPRM規制により下請け階層は浅く、責任を銀行自身が直接監視しています。

6. Citigroup（Citi）の事例

• Google Cloudと多年度戦略的提携（2024年10月28日発表、2025-2026継続）：
  CitiはGoogle Cloudと直接提携し、企業アナリティクス、高性能コンピューティング（HPC）による市場業務・リスクモデル計算、顧客向けアプリ、従業員デスクトップ（顧客サービス担当者含む）など複数のワークロードをGoogle Cloudのセキュア・スケーラブルなインフラに移行中です。Vertex AIプラットフォームを活用したGenAIを全社展開し、開発者ツールキット、文書処理、顧客サービスチームのデジタル化を加速しています。

• モダナイゼーション、内製化に注力：                                                       過去3年間で2,000超のレガシーアプリを退役させ、モダナイゼーションを進めてきました（2025年時点でさらに130アプリ/四半期ペース）。 Tim Ryan氏（Technology & Business Enablement責任者）は「インフラ近代化で安全性・健全性を高め、クライアントに迅速・機敏なサービスを提供」と強調。AI/クラウドツールによりデータ移行時間やコードレビューを大幅短縮し、内製化を推進中。ITコントラクター依存を現在の50%から20%へ削減、外部サプライヤーも144社から50社へ集約し、内部技術者2,000名増員（48,000→50,000名）でコントロールを強化しています。