RubyとGoでゼロから作る証券システム：高信頼性が求められるシステムのコードの外側にある設計と運用のリアル

• 小林悟史（小林ノエル） @free_world21 • ブルーモ証券株式会社取締役CTO • 旅行・世界のコワーキングスペースめぐり（ワーケーション的な何か）が好き • 趣味で【政治資金データベース】を開発してます好きなバンド • LʼArc~en~Ciel, Janne Da Arc, Acid Black Cherry, PIERROT THE FARM@NY ©2026 Bloomo Securities Inc. CARR WORKPLACE@Chicago

3.

Index 01 会社・プロダクト紹介 02 そもそも証券会社とは 03 証券会社スタートアップを作るための技術選定 04 第1の柱：アーキテクチャと境界設計 - Ruby on Railsが担う領域：顧客データ - Goが担う領域：金銭・取引データ 05 第2の柱：お金を守るための検証・ダブルチェック 06 第3の柱：二重言語構成がもたらしたチーム文化とインシデント対応 07 まとめ • 対象者：高信頼領域のシステムをどのように作り上げるかに興味がある人 • 持ち帰れる知見 – 複雑なシステムを作るための技術選定の判断軸の一例 – 発生するドメイン的/技術的な問題に対しての工夫ポイント – 証券システムもゼロから作れるということをイメージを持てる ©2026 Bloomo Securities Inc.

4.

5.

5

6.

7.

8.

9.

10.

11.

12.

13.

14.

金融業は規制産業証券会社とは • 証券会社＝第一種金融商品取引業の登録を受けた業者できること • 有価証券の売買 • 市場への取次ぎ • 有価証券の引受け、募集、私募など・・・登録を受けるには • 守らなければいけない（適用される）法律が多い – 金融商品取引法 – 個人情報保護法 – 犯罪収益移転防止法 – 各種税法のうち有価証券の投資に関わるもの • その他、監督官庁、業界団体の自主規制ルールなど多くのルールを守らなければいけない ©2026 Bloomo Securities Inc.

15.

当局からの規制ユーザのニーズ・社内からの要望・調達できるリソース • 要は制約条件が多いだけ • 制約条件を読み解いて、自社が守らなければいけないルールは何かを見極める • それさえ守っていれば技術は何でも良い • 参考：金融系のシステム開発が外注中心だった背景 – ベンダーが提供している製品パッケージだと規制に対応してる – 入れるだけで多くのルールに対応できる ©2026 Bloomo Securities Inc.

16.

17.

やりたいことと方向性ユーザに届けたい価値 • 最高に使いやすいUI/UX • それでいて本格的な長期投資ができる内部的なビューとこだわりたいポイント • 長期投資（デイトレの機能は作らない）、銘柄を米国株に絞るものの、システム規模はある程度大きくなる – 1つのモノリスとかにはしないほうが良さそう • スピード命、特に立ち上がりは早く • 内製するなら（意思決定者を含む）エンジニアが興味関心をもつ技術を使う ©2026 Bloomo Securities Inc.

18.

19.

20.

ネイティブアプリは基本的に3択 • 🙅Webビューを使ったガワだけネイティブアプリ • Swift & Kotolinの素のネイティブ – 🟢 アプリのパフォーマンスは最大化できる – ❌ 工数2倍 • React Native – 🟢 TypeScriptで書ける→バックエンドもTypeScriptに統一すれば人材探しも学習コストもだいぶ楽になる – ❌ JSエンジンを介してネイティブの機能を呼び出してるので、オーバーヘッドが発生する（パフォーマンスの懸念） • Flutter – 🟢 十分なパフォーマンス（実体験）。コンポーネントの見た目の一貫性。 – ❌ DartやFlutterそのものの学習コストはそこそこ ©2026 Bloomo Securities Inc.

21.

22.

ネイティブアプリは基本的に3択 • 🙅Webビューを使ったガワだけネイティブアプリ • Swift & Kotolinの素のネイティブ – 🟢 アプリのパフォーマンスは最大化できる – ❌ 工数2倍 • React Native – 🟢 TypeScriptで書ける→バックエンドもTypeScriptに統一すれば人材探しも学習コストもだいぶ楽になる – ❌ JSエンジンを介してネイティブの機能を呼び出してるので、オーバーヘッドが発生する（パフォーマンスの懸念） • Flutter – 🟢 十分なパフォーマンス（実体験）。コンポーネントの見た目の一貫性。 – ❌ DartやFlutterそのものの学習コストはそこそこ ©2026 Bloomo Securities Inc.

23.

インフラ：『コンテナベースで組むことを前提に、オーケストレーションをどうするか』も3択 • VMインスタンス用意してその中でdocker composeでがんばる – 🟢 構成がシンプルでバックエンド書ける人なら大体さわれる – ❌ 自動復旧やオートスケールとか自分で設定しないといけない • Managed系コンテナサービス（＝要はAWS ECS） – 🟢 ↑のデメリットがmanagedになる – ❌ ロックオン • Kubernetes – 🟢 ポータビリティ。「k8s使ってます！」って言えるとなんかｶｯｺｲｲ（個人の感想です） – ❌ 学習コスト ©2026 Bloomo Securities Inc.

24.

インフラ：コンテナベースで組むことを前提にこちらも3択 • VMインスタンス用意してその中でdocker composeでがんばる – 🟢 構成がシンプルでバックエンド書ける人なら大体さわれる – ❌ 自動復旧やオートスケールとか自分で設定しないといけない • Managed系コンテナサービス（＝ECS） – 🟢 ↑のデメリットがmanagedになる – ❌ ロックオン • Kubernetes – 🟢 ポータビリティ。「k8s使ってます！」って言えるとなんかｶｯｺｲｲ（個人の感想です） – ❌ 学習コスト・長期的なポータビリティー・技術的な興味関心 ©2026 Bloomo Securities Inc.

25.

バックエンド（ビジネスロジック） • 選択肢が多く、かなり悩んだ Ruby Python TypeScript Golang Framework Fullstack (Rails) Fullstack (Django) microframework (Flask, FastAPI等) 無限 (Express, Nest等) microframework (gin, echo等) ORM ActiveRecord Django ORM SQLAlchemy TypeORM, Prisma等自作, ent migration ActiveRecord::Migration Django migration alembic db-migrate等 golang-migrate, goose テスト minitest, rspec Django test, pytest pytest Jest, Jasmine等 built-in 型サポート RBS Type Hints(built-in) built-in （ただしコンパイルオプ built-in ション多数）勢い下火？ web単独では？（基本AIとセット）あるあるその他ライブラリ多数、コミュニティが成熟 TypeScriptの native runtimeはまだまだ黎明期なかったらとりあえず自分で作る的な文化が強め同左だが、あくまでAIというcontextで語られることが多い ©2026 Bloomo Securities Inc.

26.

バックエンド（ビジネスロジック） • 選択肢が多く、かなり悩んだ Ruby Python TypeScript Golang Framework Fullstack (Rails) Fullstack (Django) microframework (Flask, FastAPI等) 無限 (Express, Nest等) microframework (gin, echo等) ORM ActiveRecord Django ORM SQLAlchemy TypeORM, Prisma等自作, ent migration ActiveRecord::Migration Django migration alembic db-migrate等 golang-migrate, goose Django test, pytest pytest Jest, Jasmine等 built-in minitest, rspec 自分で選ぶ必要がない（脳死で開発できる）テストミドルウェアも自分で選ぶ必要がある型サポート RBS Type Hints(built-in) built-in （ただしコンパイルオプ built-in ション多数）勢い下火？ web単独では？（基本AIとセット）あるあるその他ライブラリ多数、コミュニティが成熟 TypeScriptの native runtimeはまだまだ黎明期なかったらとりあえず自分で作る的な文化が強め同左だが、あくまでAIというcontextで語られることが多い ©2026 Bloomo Securities Inc.

27.

ビジネスロジックレイヤーの採用技術を決めるための考え方：本質的複雑性と偶有的複雑性フレデリック・ブルックス著『人月の神話』より本質的複雑性 • • ソフトウェアが解決しようとしている「問題そのもの」に根ざした複雑さユーザーの要求、法令、ビジネスロジックなど、それを取り除くとソフトウェアが成立しなくなる部分偶有的複雑性 • 実装方法に付随して発生する複雑さ • プログラミング言語の制約、インフラの構築、ツールの設定、古いライブラリの互換性など、「もっといい道具や手法があれば消せるかもしれない」部分 ©2026 Bloomo Securities Inc.

28.

29.

30.

Ruby/Rails ❌ 本質的複雑性 Python TypeScript ⭕ 条件付き⭕ ・⾔語の表現⼒が乏しい分、誰が書いても同じような・⾔語やフレームワークがハイレベルなメソッドやコードになる＝2年後の⾃分や他の誰かが読んでも追従・とくに数値計算や信号処理・機械学習と DSL機能があり、抽象度⾼く表現できる。つまり記述可能＝開発チームはスケールしやすいいった分野における豊富なツールと知⾒、エ・ドメインへの複雑性に対する向き合い⽅としては量は減る。コシステムが確⽴ •個⼈や少⼈数でやる分には⾼速 DDDの⽂化が他の⾔語より醸成されているので、⽂化とコミュニティーのサポートがしてる。・チーム開発になると抽象度の⾼さが仇になる・動的型付け⾔語という特性もあり、『このメソッドの裏で何がおきてるのか︖』などが置いづらい・上記のような問題に対処するためにチームや組織ごとのルールを決める必要がある＝偶有的複雑性が発⽣している ⭕ 機能⾯における偶有的複雑性 Golang ⭕ ・Goより表現⼒が⾼い静的型付け⾔語なので、複雑なドメインロジックの記述に向いてる・⾼度な数値計算、機械学習、AIなどがコア・⾔語そのものの表現⼒は⾼くないので、純粋な記述ドメインにこない純粋なWEBアプリは⾮メイ量は増えるンストリーム ❌ ・Railsという1強のフレームワークがあり、Railsを中⼼としたエコシステムと知⾒が⾮常に豊富・ライブラリなどは豊富・WEB開発におけるよくある機能は⼤体デファクトのgemがある。 🔺 ⭕ ・ライブラリは豊富だが、あくまで機械学習・多くのライブラリがあるがメインストリーム・偶有的複雑性に類する問題に対して本質的複雑性同・機械学習に関する周辺ライブラリなどが豊・結局カスタマイズが必要になりgemの独⾃拡張など様に泥臭く⾃分たちで記述する必要がある（本来的に富ではあるが、純粋なWEBアプリやるならをする⽻⽬になるケースもままあるはあまり時間をかけたくない領域） Railsと⽐較すると⼿薄 ⭕ 🔺 - ActiveRecordという最強のORMapper 技術⾯における偶有的複雑性・ビルドも⾼速で,ビルドイメージも⼩さい。よってデ ❌ プロイも⾼速・gofmtによってフォーマットが⾔語レベルで標準化してる・テストツールも標準で提供・Python2系3系問題・パッケージ管理ツールの乱⽴・本質的複雑性のデメリットに対応するために型シ・環境構築が沼ステムの導⼊を検討したり,Linterのルールをチームで・ミドルウェア（HTTPサーバ、ORMapper、DB ・Django以外を選んだ場合以外は、ミドル migrationなど）を⾃分で選ぶか作らなくてはいけない育てる必要があるウェア（HTTPサーバ、ORMapper、DB ・ビルドイメージがでかい=デプロイが遅い migrationなど）を⾃分で選ばなければいけない ❌ ・フロントエンドもTypeScriptにするならエンジニア1⼈でも⼀気通貫の開発が可能・コンパイル（トランスパイル）オプションどうするか、実⾏環境をどうするか（nodejsなのかdenoなのか）といった問題がつきまとう・ツールの移り変わりが激しい ©2026 Bloomo Securities Inc.

31.

Ruby/Rails Python TypeScript ⭕ ❌ 本質的複雑性 Golang 条件付き⭕ ・⾔語の表現⼒が乏しい分、誰が書いても同じような・⾔語やフレームワークがハイレベルなメソッドやコードになる＝2年後の⾃分や他の誰かが読んでも追従・とくに数値計算や信号処理・機械学習と DSL機能があり、抽象度⾼く表現できる。つまり記述可能＝開発チームはスケールしやすいいった分野における豊富なツールと知⾒、エ・ドメインへの複雑性に対する向き合い⽅としては量は減る。コシステムが確⽴ •個⼈や少⼈数でやる分には⾼速 DDDの⽂化が他の⾔語より醸成されているので、⽂化とコミュニティーのサポートがしてる。 ⭕ ・Goより表現⼒が⾼い静的型付け⾔語なので、複雑なドメインロジックの記述に向いてる分析は見る人の目線により変わる・チーム開発になると抽象度の⾼さが仇になる・動的型付け⾔語という特性もあり、『このメソッドの裏で何がおきてるのか︖』などが置いづらい・上記のような問題に対処するためにチームや組織ごとのルールを決める必要がある＝偶有的複雑性が発⽣している ⭕ ・⾼度な数値計算、機械学習、AIなどがコア・⾔語そのものの表現⼒は⾼くないので、純粋な記述ドメインにこない純粋なWEBアプリは⾮メイ量は増えるンストリーム・深い知見を持ってる人から見たら偶有的複雑性が殆どない場合もある機能⾯における偶有的複雑性 ❌ ・Railsという1強のフレームワークがあり、Railsを中⼼としたエコシステムと知⾒が⾮常に豊富・ライブラリなどは豊富・WEB開発におけるよくある機能は⼤体デファクトのgemがある。 🔺 ⭕ ・ライブラリは豊富だが、あくまで機械学習・多くのライブラリがあるがメインストリーム・偶有的複雑性に類する問題に対して本質的複雑性同・機械学習に関する周辺ライブラリなどが豊・結局カスタマイズが必要になりgemの独⾃拡張など様に泥臭く⾃分たちで記述する必要がある（本来的に富ではあるが、純粋なWEBアプリやるならをする⽻⽬になるケースもままあるはあまり時間をかけたくない領域） Railsと⽐較すると⼿薄生成AIの登場により前提が変わってきてる ⭕ 🔺 ・AIは偶有的複雑性の解消は得意・ビルドも⾼速で,ビルドイメージも⼩さい。よってデ - ActiveRecordという最強のORMapper 技術⾯における偶有的複雑性 ❌ プロイも⾼速・gofmtによってフォーマットが⾔語レベルで標準化してる・テストツールも標準で提供・Python2系3系問題・パッケージ管理ツールの乱⽴・本質的複雑性のデメリットに対応するために型シ・環境構築が沼ステムの導⼊を検討したり,Linterのルールをチームで・ミドルウェア（HTTPサーバ、ORMapper、DB ・Django以外を選んだ場合以外は、ミドル migrationなど）を⾃分で選ぶか作らなくてはいけない育てる必要があるウェア（HTTPサーバ、ORMapper、DB ・ビルドイメージがでかい=デプロイが遅い migrationなど）を⾃分で選ばなければいけない ❌ ・フロントエンドもTypeScriptにするならエンジニア1⼈でも⼀気通貫の開発が可能・コンパイル（トランスパイル）オプションどうするか、実⾏環境をどうするか（nodejsなのかdenoなのか）といった問題がつきまとう・ツールの移り変わりが激しい ©2026 Bloomo Securities Inc.

32.

あとは意思決定者（メインでドライブする人）が持ってるリソースとパッション＊意思決定者＝小林の場合＊意思決定当時のもの 3＝得意 2＝そこそこ 1＝あまり得意でない Ruby/Rails Golang Python TypeScript 意思決定者の能⼒ 3（経験あり） 1（実務経験はなし） 2（経験あり） 2（経験あり）意思決定者のパッション 2.5 2 2 2 意思決定者が持ってこれそうな⼈的リソース 3 1 1 2 時代の潮流（あくまで⽇本から⾒た時） 2弱 3 AI分野︓3 それ以外だと1.5~2くらい︖ 3 市場からの調達しやすさ（⼈材の多さと単価⽔準） 1.5 2.5 2 3 ©2026 Bloomo Securities Inc.

33.

最終意思決定 Ruby/Rails：採用 • 金融・投資というドメインにおいてある程度のチーム規模で継続的に本質的複雑性の領域を記述していくのは辛そう（長期的なスピードダウンを招きそう） • よくある機能の開発や、他言語を選んだときに発生するミドルウェアの技術選定をする必要がない点は明確なアドバンテージ • 意思決定者がコミュニティーへのアクセスがあり、人や知見を探しやすい • 意思決定者自身の知見や経験もあり、技術的な偶有的複雑性に対してある程度の解や実例を知っていた/経験していた • いざとなったら自分でゴリッと書ける • →捨てるのはもったいない。偶有的複雑性の領域を中心に活用したい。一方で時代の潮流（言語やフレームワークの流行り）を考えるとRuby/Rails以外の言語も採用し、本質的複雑性はその言語に託すのが良さそう。 ©2026 Bloomo Securities Inc.

34.

金融業は規制産業 Golang：採用 • ミドルウェアの選定はしなくてはいけないが、他言語に比べて技術面における偶有的複雑性が少ない • 他言語と比較したときに表現力は乏しいので記述量は増えるが、Ruby/Railsで偶有的複雑性の領域をカバーしてくれるなら、本質的複雑性に全集中しやすい Python：不採用 • 将来的にどこかで使うことになるとは思うが、『ゼロから作る』段階でそこまで高度な数値計算や機械学習はない＝強みを活かせない • 偶有的複雑性に対して自分自身や開発チームが向き合わないといけない＝自分たちのベスプラを時間をかけて探していかないといけない TypeScript：不採用 • フロントエンド（アプリ）はFlutterを採用することが決まっていたので技術面における偶有的複雑性が1つ増えてしまっていた（メリットが消えてしまった） • Goと比較したときに言語の表現力は高いので本質的複雑性の記述力は高いが、偶有的複雑性の高さが気になった（開発メンバーの意識が本質的複雑性の領域に全集中しづらい） ©2026 Bloomo Securities Inc.

35.

バックエンドの結論：Ruby on RailsとGoを併用お金お金以外の部分（アプリのAPIサーバ、管理画面）＝Ruby on Rails ■ 認証認可やセキュリティーとかはいったんフレームワークやデファクトのライブラリで対応 ■ 要件がころころ変わるフロントや管理画面に柔軟に対応できる ■ Rails人材：スタートアップ界隈、プログラミング初学者など人数はそれなりにいるお金を取り扱う部分＝Golang ■ インターネットから直アクセスなし：こまかい認証認可とかセキュリティーとかの考慮・調査工数を減らす ■ ブルーモ証券が扱う本質的複雑性＝お金の計算領域で言語との相性も良い ■ Golang人材：メガベンチャーでの採用事例が多いので、メガベンチャー転職組とかの受け皿になれたらいいな ©2026 Bloomo Securities Inc.

36.

37.

38.

顧客データ管理 • 顧客に氏名や住所をアプリで入力してもらう • 本人確認フローは外部のeKYCサービスを活用 • 個人情報管理と暗号化はRailsレイヤーで自前実装 – Ruby on RailsにはActiveRecordが提供する暗号化機構があるが、より高度な要件を満たすためにattr_enctypted gemを活用して実装 – 個人情報のレコードごとに暗号鍵が異なる、安全性の高い構造 https://kaigionrails.org/2024/talks/f-world21/ ©2026 Bloomo Securities Inc.

https://kaigionrails.org/2024/talks/f-world21/

39.

個人情報の暗号化について ‒ 暗号化をする際に考慮すべきポイント • 暗号化のアルゴリズム – DES, AES, RSA, ECC, … – ほとんどの場合フレームワークやライブラリのデフォルト（推奨）のものを使えばOK • 本日のお話のスコープ外 • 鍵の管理方針鍵の管理方針 – 暗号鍵をどこにおいて誰が管理するのか？ • 暗号化の単位暗号化の単位 – どのような単位で暗号化するか • • • • アプリケーションすべてを1つの鍵で一括暗号化ある程度まとまった単位（テーブルごととか）で暗号鍵をわけるレコードごとに暗号鍵をわける検索性能検索性能 – 暗号化したデータを DB に入れると多くの場合で検索ができなくなる – 必要に応じてアプリケーションレイヤで検索機能を実装する必要がある ©2026 Bloomo Securities Inc.

40.

個人情報の暗号化について ‒ ブルーモ証券の管理方針を例に • 鍵の管理方針鍵の管理方針 – 人間が管理したくない – （ここは ActiveRecord Encryption でも実現できる） • • 暗号化の単位暗号化の単位 – 会社そのものの性質＆扱うデータの重要性から、レコードごとに異なる暗号鍵を使いたい • 個人情報 • マイナンバー（一時的） • 本人確認書類画像（免許証など）検索性能検索性能 – お客様からの問い合わせがあったときに、本人確認のために一定項目での検索は必要 • 名前と生年月日 • 住所 ©2026 Bloomo Securities Inc.

41.

個人情報の暗号化について ‒ Key Management Service と Rails で独自実装 • Customer Master Key（CMK）を指定して、data key（新しい暗号鍵）を要求する – CMK A has_many :data_keys • 以下のものがKMSから返ってくる – A: 平文の暗号鍵 – B: Aが暗号化されたもの • 暗号化：Aで暗号化して、それは消去。BをDBなどに保存しておく。 • 復号化：BをKMSに投げつけると復号化して返してくれる（Aを得られる）ので、データ本体をAで復号化する ©2026 Bloomo Securities Inc.

42.

attr_encrypted を使った実装例 ‒ KMSを使ったレコードごとの暗号化実装例 1. KMSから取得した【暗号化された暗号鍵(B)】を保存するためのカラム encrypted_data_key を暗号化対象クラス（テーブル）に追加 2. 下記のようなメソッドをもつ module を定義 module KmsKey def data_key kms_client = Aws::KMS::Client.new(region: aws_region) if self.encrypted_data_key kms_client.decrypt(ciphertext_blob: self.encrypted_data_key) else resp = kms_client.generate_data_key( key_id: Rails.application.config.x.common['kms_cmk_id’], key_spec: 'AES_256’, ) self.encrypted_data_key = resp.ciphertext_blob resp.plaintext end end ©2026 Bloomo Securities Inc.

43.

attr_encrypted を使った実装例 ‒ KMSを使ったレコードごとの暗号化実装例 3. 暗号化対象フィールドを定義 class PersonalInfo < ApplicationRecord include KmsKey attr_encrypted :first_name, key: :data_key, algorithm: 'aes-256-gcm’ attr_encrypted :last_name, key: :data_key, algorithm: 'aes-256-gcm' ©2026 Bloomo Securities Inc.

44.

attr_encrypted を使った実装例 ‒ KMSを使ったレコードごとの暗号化実装例 4. レコードごとに暗号鍵を変えつつ、透過的に扱えるようになる personal_info.first_name = ”ノエル” personal_info.last_name = “小林” personal_info.save! personal_info = PersonalInfo.find(1) puts personal_info.first_name # => “ノエル” puts personal_info.last_name # => “小林” ©2026 Bloomo Securities Inc.

45.

attr_encrypted を使った実装例 ‒ KMSを使ったレコードごとの暗号化実装例 4. レコードごとに暗号鍵を変えつつ、透過的に扱えるようになる personal_info.first_name = ”ノエル” personal_info.last_name = “小林” personal_info.save! personal_info = PersonalInfo.find(1) puts personal_info.first_name # => “ノエル” puts personal_info.last_name # => “小林” 個人情報の堅牢に保存する機構をRailsを活用して実現できた ©2026 Bloomo Securities Inc.

46.

47.

Goが担う領域 • 投資をするうえでの目標値となる目標ポートフォリオと実際に保有している資産のポートフォリオ管理 • 注文計算 – 買付、売却、リバランス – 自動での配当金再投資 • 目標ポートフォリオ保有ポートフォリオ米国の証券会社（Alpaca Securities）に取り次いでもらって米国市場に発注 – Alpaca Securitiesが公開しているAPIを使用 – 日本の証券会社で米国株を買うときは他社も現地証券会社に取り次いでもらってる • 約定取込→顧客への資産配分→金銭照合 ©2026 Bloomo Securities Inc.

48.

Go側モジュールを実装するうえで気をつけていること • （今は）パフォーマンスより整合性重視 • 冪等性を担保できるようにAPI設計 – 例：同一顧客から注文リクエストが複数同時にきても、整合性が保たれるように実装 • 変更が入るリクエストがきた場合、処理の開始時点で、起点となるレコードの行Lockを取得してから排他処理を実現 • データが不整合な状態になっていないかを検証するバッチを複数回実行している • バッチ処理はKubernetesレイヤーで管理 ©2026 Bloomo Securities Inc.

49.

Go側モジュールを実装するうえで気をつけていること • （今は）パフォーマンスより整合性重視 • 冪等性を担保できるようにAPI設計 – 例：同一顧客から注文リクエストが複数同時にきても、整合性が保たれるように実装 • 変更が入るリクエストがきた場合、処理の開始時点で、起点となるレコードの行Lockを取得してから排他処理を実現 • データが不整合な状態になっていないかを検証するバッチを複数回実行している • バッチ処理はKubernetesレイヤーで管理偶有的複雑性の領域をRailsが引き取ってくれたことにより本質的複雑性の領域に集中できる環境が作れた ©2026 Bloomo Securities Inc.

50.

51.

整合性を保つ仕組み外部の証券基幹システム・米国の証券会社で、ブルーモ証券が顧客から受け付けた注文の取次先・AlpacaSecuritiesを通じて米国株の売買を行っている・お客様の注文の受け付け窓口・直接NYSEに注文を出せるわけではない・正確な平均取得単価の計算、正確な源泉徴収額の計算など、非常に複雑かつクリティカルかつ法改正により変化する領域を任せてる ©2026 Bloomo Securities Inc.

52.

整合性を保つ仕組み外部の証券基幹システム・米国の証券会社で、ブルーモ証券が顧客から受け付けた注文の取次先・AlpacaSecuritiesを通じて米国株の売買を行っている・お客様の注文の受け付け窓口・直接NYSEに注文を出せるわけではない・正確な平均取得単価の計算、正確な源泉徴収額の計算など、非常に複雑かつクリティカルかつ法改正により変化する領域を任せてる３者間の間で整合性が保たれているかを念入りにチェック開発時：単体テストや結合テストを通じてプログラムが期待通りの振る舞いをしているか実行・運用時：期待通りの結果になっているか、明らかにおかしい状態になっていないかをチェックするプログラムを定期的に走らせる ©2026 Bloomo Securities Inc.

53.

整合性を保つ仕組み外部の証券基幹システム取引の約定取り込みが終わっているか・市場が開く前に注文を出しておいて、翌朝（閉場後）に出した注文の結果を取り込み、顧客の資産に反映する流れ・上記の処理が終わった後にすべての注文が正しく処理されたかをチェック（注文レコードのステータスを中心に確認）不正な口座残高の検知保有資産数量の不一致検知・口座の各金額フィールドが負数になっていないかを検証・全ユーザーの保有数量＝ブルーモ証券が取引所に出した注文の合計＝外部の証券期間システム内で保有されている数量が成り立っているかを検証・例：累計入金額、未徴収の手数料、残余現金などなど ©2026 Bloomo Securities Inc.

54.

整合性を保つ仕組み外部の証券基幹システム取引の約定取り込みが終わっているか・市場が開く前に注文を出しておいて、翌朝（閉場後）に出した注文の結果を取り込み、顧客の資産に反映する流れ・上記の処理が終わった後にすべての注文が正しく処理されたかをチェック（注文レコードのステータスを中心に確認）不正な口座残高の検知保有資産数量の不一致検知・口座の各金額フィールドが負数になっていないかを検証・全ユーザーの保有数量＝ブルーモ証券が取引所に出した注文の合計＝外部の証券期間システム内で保有されている数量が成り立っているかを検証複数の異常検知処理が走っている・例：累計入金額、未徴収の手数料、残余現金などなど ↓ これらの処理はインシデントの再発防止策として実装されたものも多々ある ©2026 Bloomo Securities Inc.

55.

56.

異なる性質の言語を採用したことによる影響 • 特定の言語によらないプラクティスを意識するようになった – 採用時の目線もソフトウェアエンジニアリングそのものを見るようになった – そもそも証券ドメインに飛び込んでくる数字を細かく見るのが得意、好きな人だったりもする • 技術的な多様性 – エンジニアなので複数の技術に振れたい・身に着けたいという人が集まっている – それぞれの言語・フレームワークの良いところ/悪いところを持ち寄ってる • インシデント対応プロセスの構築もエンジニア主導で構築した ©2026 Bloomo Securities Inc.

57.

インシデント対応 • 第一種金融商品取引業（証券会社）としてのシステムである – ❌：決して落としてはいけないシステム – ⭕：様々なリスクを把握・管理し、適切な管理体制やルールを設ける • 様々なリスクにより障害は起きる – プログラムのバグ – 依存する外部サービス起因 – 急激なアクセス増 – サイバー攻撃、などなど・・・ • 障害対応時のプロセスや報告体制を構築しておくのが重要 ©2026 Bloomo Securities Inc.

58.

https://speakerdeck.com/free_world21/jin-rong-ji-guan-false-sisutemufalse-zuo-rifang

59.

60.

61.

62.

ブルーモ証券のインシデント対応プロセスインシデント対応プロセス • インシデントごとprivateなslackチャネルを立てる – 個人情報を含む顧客情報がやり取りされる場合もあるので • インシデントごとにIncident Commander(IC)を1 人割り当てて、Subject Matter Expert(SME)、 Responsible Compliance Oﬃcer(RCO)も割り当てる • ICの指揮の元、影響調査、原因調査、応急対応、社内外への報告をSME, RCOと手分けして対応する • 諸々の対応が完了したらICは終了宣言をしてポストモーテム担当者を割り振る ©2026 Bloomo Securities Inc.

63.

64.

とあるインシデントの紹介とそのポストモーテム原因（起きたこと）米国株資産運用アプリBloomoを提供中！ • WBS (World Business Satelite) に紹介された • 短時間でアクセス爆増・集中 • サーバー過負荷でつながりづらい状態応急対応 • インフラ増強（10倍）した根本原因 • • アクセスが増加が想定されるイベントに対する対応プロセスが整備されてなかった現状のシステムがどの程度負荷をさばけるか把握できてなかったコピペで「バフェット投資」スマホ完結で若者も気軽に YOUTH FINANCE① 恒久対応 • 負荷を鑑みてインフラ増強度合いを適切な水準に抑える再発防止策 • アクセス増加が予想されるイベントに対する対応プロセス整備 • 負荷試験を行いどの程度の負荷に耐えられるか計測する体制を作る ©2026 Bloomo Securities Inc.

65.

66.

67.

68.

69.

覚えて帰ってほしいこと • 技術選定 – 世の中の流れを踏まえつつ、自分が築いてきた資産と、最後はモチベーションで決めた • 第1の柱：アーキテクチャと境界設計 – Rails側：顧客データ • • – 外部世界との境界デフォルトより強固な暗号化施策をRailsのエコシステムを活用して実施 Go側 • • 投資というドメインに集中整合性チェックを厳格に行うように • 第2の柱：お金を守るための検証・ダブルチェック – ブルーモ証券、米国証券会社、外部の証券管理システムの3社間のデータの整合性を常にチェック – チェックプログラムはインシデントの再発防止策から生まれることもある • 第3の柱：二言語構成がもたらしたチーム文化とインシデント対応 – 採用やチームの文化に幅が生まれた（技術的な多様性） – インシデント対応プロセスの構築と対応もエンジニアが主導で行っている ©2026 Bloomo Securities Inc.

70.

https://careers.bloomo.co.jp/

RubyとGoでゼロから作る証券システム：高信頼性が求められるシステムのコードの外側にある設計と運用のリアル

小林ノエル

関連スライド

Ruby on Rails と Django を比較してみる

大事なデータを守りたい！ActiveRecord Encryptionと、より安全かつ検索可能な暗号化手法の実装例の紹介

Re: Ruby/Rails勉強会のおかげでブルーモ証券起業した

RubyとGoでゼロから作る証券システム：実際に開発してみて良かった点と辛かった点、そこから得た学び

Rails engineにpackwerkいれると大変（だからやめとけ）

Ruby on Rails on Kubernetesってどうなの?

各ページのテキスト

RubyとGoでゼロから作る証券システム： 高信頼性が求められるシステムのコードの外側にある設計と運用のリアル

小林ノエル

関連スライド

Ruby on Rails と Django を比較してみる

大事なデータを守りたい！ActiveRecord Encryptionと、より安全かつ検索可能な暗号化手法の実装例の紹介

Re: Ruby/Rails勉強会のおかげでブルーモ証券起業した

RubyとGoでゼロから作る証券システム： 実際に開発してみて良かった点と辛かった点、 そこから得た学び

Rails engineにpackwerkいれると大変（だからやめとけ）

Ruby on Rails on Kubernetesってどうなの?

各ページのテキスト

RubyとGoでゼロから作る証券システム：高信頼性が求められるシステムのコードの外側にある設計と運用のリアル

RubyとGoでゼロから作る証券システム：実際に開発してみて良かった点と辛かった点、そこから得た学び