この記事の途中に、以下の記事の引用を含んでいます。
An oral history of Bank Python (2021)
金融の裏側で使われる異形のPython、その正体とは？
「ハイ・ファイナンス──金融の最先端は、まるで異国の地」。こう語るのは、投資銀行で用いられている独自派生型Python「Bank Python」の実態を伝える記事です。
投資銀行の多くは一般的なPythonから大きく逸脱した自前のPythonエコシステムを構築し、何千人ものエンジニアが運用しています。
本記事では、その全体像と核心技術（Barbara, Dagger, Walpole, MnTable）、そしてその文化的・技術的影響について、「Minerva」と呼ばれる架空のシステムを例に紐解いています。
なぜ投資銀行はここまで独自志向なのか？ その背景には「超巨大組織の特殊な要求」「レガシー技術との折り合い」「Excel文化」などが複雑に絡み合っています。
意外すぎる実装──データベースもコードも「全部Pythonオブジェクト」
まず筆者は、Minervaを構成する主要コンポーネントのうち、「Barbara」なるグローバル・オブジェクト・データベースを紹介しています。
“Barbara is a simple key value store with a hierarchical key space. It’s brutally simple: made just from pickle and zip.”
（Barbaraは階層化されたキー空間を持つ単純なキーバリューストアで、その実体はpickleとzipのみでできている）
Barbaraは想像以上に荒削りなシステムです。Pythonオブジェクトをそのまま直列化してグローバル空間に保存し、「現金出納」「金融商品」「取引履歴」などの大半がここから取出せます。
データの保存にファイルシステムを使わず、ソースコードさえBarbara内に格納。分散レプリケーションこそあるものの、その堅牢性は「むしろ原始的な構造故」といいます。
また、独自の「階層的ネームスペース（ring）」や、複数ringを重ねて参照する「オーバーレイ機構」も。大規模な金融組織の特殊なニーズが色濃く投影されています。
「依存グラフで全自動価値計算」──Excel文化からの脱却
金融の現場で核となるのは「資産価値評価（アセットプライシング）」ですが、これは何層にも連なる金融商品の依存関係で成り立っています。
Minervaの「Dagger」はそれらをDAG（有向非巡回グラフ）として明示的に管理し、下層で数値が変わると自動で派生商品すべてを再計算します。
“Dagger tracks the edges in the graph of underlying instruments and automatically reprices derivatives in Barbara when the value of the underlying instruments changes.”
（Daggerは金融商品の依存グラフのエッジを追跡し、基礎資産の価値が変化したときに派生商品の価格を自動換算する）
これは、Excelスプレッドシートのセル計算に酷似した思想です。ただし「データ＝テーブル」「依存＝DAG」「再計算＝オートマチック」という形で、Pythonのプログラムとして管理します。
金融現場ではかつてExcelが「パッチワーク状に拡張されることで容易にグローバル運用」されてきました。Minerva/Daggerの設計は、この伝統的なExcel文化をPython上に移植しつつ、型安全性・バージョン管理で補強するものとも言えます。
コードもデータも一元管理──独自インフラ「Walpole」と徹底した統制
さらに筆者が驚きの事実として強調するのは、「コードもBarbara内に保存される」という点です。
“the source code is in Barbara too, not on disk. Remain composed. It’s kept in a special Barbara ring called sourcecode.”
（ソースコードもファイルシステム上ではなくBarbara内の特別なringに格納されている）
この「全行内管理主義」を支えるのが「Walpole」──全銀行共通のジョブランナーです。システム全体で一つのみ運用され、簡単なiniファイルさえ書けば即座に新ジョブ（スクリプト）が投入・定期実行・監視・エラーハンドリングまで行えます。
これにより、大銀行でネックになりがちな新規システム投入時の部門間調整・手続き・インフラ調達ラグを一気に圧縮しているのです。これは、現代クラウドネイティブ（Kubernetesなど）で求められる高度な知識よりも、全社的な即応性を優先した極めて”現場志向”な設計哲学です。
テーブル文化と“中途半端な”汎用性──MnTableの役割
通常の言語が「ハッシュテーブル偏重」であることに警鐘を鳴らし、金融界（とExcel）で当然の「テーブル」データを実装したのがMnTableです。
Pandasが未発達だった当時に導入され、今なお独自拡張で実装。多くはC++による高速化やsqlite3をラップして動作します。Python流の直感的な記法で大量データのフィルタ・結合・解析・スプーリングが可能です。
“A lot is talked about high-frequency traders but the majority of financiers are not looking at tick level or frankly even intra-day level data. ‘Medium-sized’ is big enough that you cannot create an object for every row but not so big that you are going to need some distributed compute cluster thingy.”
（実際の銀行内では多くの「ミドルサイズ」データがあり、それは1行1オブジェクトで扱うには大きすぎ、分散クラスタが必要なほどには大きくない）
この「中間レンジ」データへの最適化は、国内外の一般企業システムではあまり見られない発想です。一般的なハッシュテーブルによるメモリ過食でもなく、超分散型でもない。まさに“金融独自文化”の結晶です。
現場に君臨する「Minerva」の影と光
Minerva型のシステムは圧倒的な統制力・即応性を持つ一方、その排他性・情報遮断性は「IT鎖国状態」を生み出しています。
“Over time the divergence between Bank Python and Open Source Python grows. Technology churns on both sides, much faster outside than in of course, but they do not get closer.”
（Bank PythonとOSS Pythonの乖離は年月を経てますます拡がっている）
外部エンジニアとの協調は困難で、出力データのやり取り一つとっても「Minervaのソースコードを引いて読め」と言うしかないのが実情です。パッケージ管理の常識も失い、「Pythonの外の世界」から隔絶され、職業的にも技術的にも“ガラパゴス化”します。
さらに「独自IDE」「独自Webフレームワーク」までを内部実装しており、OSSへの還元も薄い。「NIH症候群（Not Invented Here）」が極端な例として生きている領域でもあります。
筆者の視点：なぜここまで独自化が進んだのか？
一見、「金融業界の頑迷な縦割り文化」と揶揄したくなる設計ですが、それには合理性も見受けられます。
1. 即時応答性と“現場主導”への異常なこだわり
Excel文化というべき「現場が自ら計算モデルを改変し即時反映」を実現するには、モノリシックかつ即応的なインフラが必須。「外部クラウド」や「細分化マイクロサービス」では現場のアジリティ（敏捷性）が損なわれ、実質的な運用が回らなくなるのです。
2. 情報漏洩・コンプライアンスへの超高圧スクリーニング
金融という業界特性上、OSSとの過度な交流＝情報漏洩リスクです。プロプラ製を徹底することで一貫した可視化・統制・監査性を担保しています。
3. ExcelからPythonへの進化＝資産蓄積の意志
「表計算→コード化→自動テスト・バージョン管理」への移行は大きな進歩です。ただし、それが囲い込まれた专制的なシステムでしか活かされないのは非常に残念なことです。
4. 技術的負債と人材流動性の限界
全てが自前システムのため、外部で通用する「ソフトウェア工学的スキル」は急激に減退します。転職市場やキャリア開発の文脈では痛恨のリスクです。
ユーザー視点で考える：「Bank Python」から学べること
Bank Python/Minerva流からの最大の教訓は、「現場のアジリティ・即応力こそが超巨大組織の生命線」という事実です。
ただし、その独自性・囲い込みがもたらす負の側面：
– エンジニアリングスキルの閉塞
– 他産業との断絶
– モダン技術へのキャッチアップの困難さ
– 外部との相互運用性の劣化
……なども同時に浮き彫りになります。
たとえば日本の大企業に完全内製志向がいまだ強く残っている現状や、特定ベンダーに塩漬けされた基幹系などと重なり合う現象です。
OSSやクラウド技術は複雑ですが、相互運用・モダン化・イノベーションを担保します。片や、Minerva流は強烈な現場指向・一体運用・即時性でwhile他を圧倒します。両者のバランス感覚は、どの業界でも永遠の課題です。
結論：異文化の深層を知ることが、自分の現場を変える
本記事の筆者は、「実際に現場で使われている巨大金融システムの設計哲学と、皮肉混じりな批判」を通じて、極端な囲い込み進化の事例を読者に投げかけています。
この経験から気づくべきは、自分たちの慣れ親しんだ手法が世界の標準ではないこと。見知らぬ異文化システムが持つ合理性や欠点に目を向けることが、真のイノベーションや現場改善につながるという真理です。
たとえばあなたの現場がExcelだらけの非効率地獄でも、それは数百億円を動かす投資銀行と構造的に共通しているかもしれません。そこから「自分たちだけの工夫」にこだわるべきなのか、「外部と接続するオープンな設計思想」を選ぶべきなのか──この記事は、その判断にヒントを与えてくれます。
異文化の深層を知ること、それが自分たちの現場の盲点を突破するきっかけになるのです。
categories:[technology, business]
コメント