銀行は、基幹銀行システムを負債として捉える説明を、ほぼ2十年のあいだ続けてきました。会話の内容はほとんど変わっていません。レガシー・インフラは、維持にコストがかかり、変更が難しく、そして現代の オペレーティング・モデルに必要なものとのズレがますます大きくなっています。ここまでは概ね理解されています。あまり理解されていないのは、基幹システムが、いま銀行が行っているあらゆる他の戦略的投資の上限（天井）になって、ひそかにそうなってきたということです。2026年に多くの組織が直面するのは、順序（シーケンス）の難題です。取締役会がエージェンティックAIのプログラムを承認しています。テクノロジーチームはトークン化されたインフラに向けて構築しています。支払いの近代化が進行中です。リスクおよびコンプライアンス機能は、 バッチ・サイクルではなくリアルタイムで稼働することを求められています。これらの各プログラムには、確かなビジネス上の根拠があります。どれもまた、ある時点で、基幹システムが本来設計されていなかったことを行う必要が出てきます。自律的に実行するエージェンティックAIのワークフローには、リアルタイムの決済確認が必要です。トークン化された預金には、モノリシックなバッチ処理型コアがネイティブにサポートできない、プログラマブルな取引ロジックが必要です。リアルタイム決済は、日次の処理ではなく継続的な照合作業を要求します。24/7のプログラマブルなマネーフローのためのコンプライアンス監視は、 真夜中に閉じるチェックポイントに依存できません。基幹システムは、取引がバッチで行われ、決定性（ファイナリティ）が後送りされ、そして夜間ウィンドウが機能だった世界のために設計されました。その世界は、多くの近代化ロードマップが想定するよりも速く終わりを迎えています。基幹銀行の近代化プログラムにおける失敗率が高いことが、切迫感をむしろ行動しやすくするのではなく、難しくしています。全取替を試みるほとんどのプログラムは、長期化し、見込んだ以上にコストがかかり、約束された以上の成果を届けられません。IBMの研究では、基幹近代化プログラムの94%が 当初のタイムラインを逃したことが分かりました。そうした経験で痛い目を見た組織が、次の試みに対して慎重になるのは、理解できます。しかし、基幹近代化に対する慎重さは、安全（セーフティ）と同じではありません。それは、取り除くのではなく 制約を取り込むという選択であり、その選択は時間とともに増幅していきます。基幹システムができることと、ビジネスが必要とすることの間の距離が広がるからです。この局面を最も効果的に乗りこなしているのは、全取替を目指していない機関です。彼らは、サイドカー型のアーキテクチャを運用しています。レガシー・システムと並行して、モダンなコアが稼働し、特定のプロダクト、クライアントのセグメント、または取引 種別など、レガシーの制約が最も深刻に現れる領域を扱っています。IDCは、2026年までに世界の銀行の40%がこのアプローチを追求していると見込んでいます。ロジックは妥当です。新しいコアを限定されたスコープで検証し、移行がビジネスが依存しているものを壊さないことを示し、そして段階的に拡大する。これは取替よりも遅いです。しかし、それでも成功する可能性はかなり高くなります。ただし、より重要な言い換え（リフレーム）は、どの近代化アプローチを選ぶべきか、という話ではありません。問題は、コアが組織の戦略的な順序（シーケンス）の中でどこに位置するか、ということです。ほとんどの銀行は、基幹近代化をテクノロジープログラムとして扱い、テクノロジー部門が管理し、コスト削減や業務効率の改善を軸にしたビジネスケースを作ります。その捉え方によって、予算サイクルが締まったときや、 より目立つイニシアティブがリソースを競ったときに優先度を下げやすくなります。さらに、取締役会レベルの議論が実際に関心を向けている戦略的アウトカムに、コアを結び付けにくくなります。たとえば、スケールでエージェンティックAIを展開する能力、トークン化されたインフラに参加するための機能、そして最初からモダンなスタックに基づいて構築してきたノンバンク新規参入者からの競争圧力に迅速に対応するスピードです。基幹システムは、戦略の下流にあるテクノロジーの問題ではありません。組織が行っているほぼあらゆるテクノロジー投資の、上流に位置する戦略上の制約です。そう名付けることで、会話のあり方、誰がそれを担うのか、そして解決に必要な許容タイムラインが何に見えるのかが変わってきます。すべての計画サイクルで問う価値があるのは、「現行の基幹システムが、ロードマップ上のプログラムをサポートできるか」ということではありません。ロードマップ上のプログラムが、基幹システムにできないことではなく、ビジネスが実際に 必要としていることを中心に設計されているのか、ということです。それは別種の技術的負債です。貸借対照表には出てきません。発表された内容と、実際に提供される内容のギャップとして現れます。
コアはレガシーの問題ではない。それは戦略の問題だ。
銀行は、基幹銀行システムを負債として捉える説明を、ほぼ2十年のあいだ続けてきました。会話の内容はほとんど変わっていません。レガシー・インフラは、維持にコストがかかり、変更が難しく、そして現代の オペレーティング・モデルに必要なものとのズレがますます大きくなっています。ここまでは概ね理解されています。
あまり理解されていないのは、基幹システムが、いま銀行が行っているあらゆる他の戦略的投資の上限（天井）になって、ひそかにそうなってきたということです。
2026年に多くの組織が直面するのは、順序（シーケンス）の難題です。取締役会がエージェンティックAIのプログラムを承認しています。テクノロジーチームはトークン化されたインフラに向けて構築しています。支払いの近代化が進行中です。リスクおよびコンプライアンス機能は、 バッチ・サイクルではなくリアルタイムで稼働することを求められています。これらの各プログラムには、確かなビジネス上の根拠があります。どれもまた、ある時点で、基幹システムが本来設計されていなかったことを行う必要が出てきます。
自律的に実行するエージェンティックAIのワークフローには、リアルタイムの決済確認が必要です。トークン化された預金には、モノリシックなバッチ処理型コアがネイティブにサポートできない、プログラマブルな取引ロジックが必要です。リアルタイム決済は、日次の処理ではなく継続的な照合作業を要求します。24/7のプログラマブルなマネーフローのためのコンプライアンス監視は、 真夜中に閉じるチェックポイントに依存できません。
基幹システムは、取引がバッチで行われ、決定性（ファイナリティ）が後送りされ、そして夜間ウィンドウが機能だった世界のために設計されました。その世界は、多くの近代化ロードマップが想定するよりも速く終わりを迎えています。
基幹銀行の近代化プログラムにおける失敗率が高いことが、切迫感をむしろ行動しやすくするのではなく、難しくしています。全取替を試みるほとんどのプログラムは、長期化し、見込んだ以上にコストがかかり、約束された以上の成果を届けられません。IBMの研究では、基幹近代化プログラムの94%が 当初のタイムラインを逃したことが分かりました。そうした経験で痛い目を見た組織が、次の試みに対して慎重になるのは、理解できます。しかし、基幹近代化に対する慎重さは、安全（セーフティ）と同じではありません。それは、取り除くのではなく 制約を取り込むという選択であり、その選択は時間とともに増幅していきます。基幹システムができることと、ビジネスが必要とすることの間の距離が広がるからです。
この局面を最も効果的に乗りこなしているのは、全取替を目指していない機関です。彼らは、サイドカー型のアーキテクチャを運用しています。レガシー・システムと並行して、モダンなコアが稼働し、特定のプロダクト、クライアントのセグメント、または取引 種別など、レガシーの制約が最も深刻に現れる領域を扱っています。IDCは、2026年までに世界の銀行の40%がこのアプローチを追求していると見込んでいます。ロジックは妥当です。新しいコアを限定されたスコープで検証し、移行がビジネスが依存しているものを壊さないことを示し、そして段階的に拡大する。これは取替よりも遅いです。しかし、それでも成功する可能性はかなり高くなります。
ただし、より重要な言い換え（リフレーム）は、どの近代化アプローチを選ぶべきか、という話ではありません。問題は、コアが組織の戦略的な順序（シーケンス）の中でどこに位置するか、ということです。
ほとんどの銀行は、基幹近代化をテクノロジープログラムとして扱い、テクノロジー部門が管理し、コスト削減や業務効率の改善を軸にしたビジネスケースを作ります。その捉え方によって、予算サイクルが締まったときや、 より目立つイニシアティブがリソースを競ったときに優先度を下げやすくなります。さらに、取締役会レベルの議論が実際に関心を向けている戦略的アウトカムに、コアを結び付けにくくなります。たとえば、スケールでエージェンティックAIを展開する能力、トークン化されたインフラに参加するための機能、そして最初からモダンなスタックに基づいて構築してきたノンバンク新規参入者からの競争圧力に迅速に対応するスピードです。
基幹システムは、戦略の下流にあるテクノロジーの問題ではありません。組織が行っているほぼあらゆるテクノロジー投資の、上流に位置する戦略上の制約です。そう名付けることで、会話のあり方、誰がそれを担うのか、そして解決に必要な許容タイムラインが何に見えるのかが変わってきます。
すべての計画サイクルで問う価値があるのは、「現行の基幹システムが、ロードマップ上のプログラムをサポートできるか」ということではありません。ロードマップ上のプログラムが、基幹システムにできないことではなく、ビジネスが実際に 必要としていることを中心に設計されているのか、ということです。
それは別種の技術的負債です。貸借対照表には出てきません。発表された内容と、実際に提供される内容のギャップとして現れます。