---
title: RubyとGoでゼロから作る証券システム： 高信頼性が求められるシステムのコードの外側にある設計と運用のリアル
tags:  #ruby #ruby on rails #go #golang #技術選定 #インシデント  
author: [小林ノエル](https://convert.docswell.com/user/free_world21)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4EZLMPW973.jpg?width=480
description: https://event.shoeisha.jp/devsumi/20260218/session/6493  Developers Summit 2026「Beyond the Code」の発表で使用したスライドです。 （多少の加筆修正）
published: February 25, 26
canonical: https://convert.docswell.com/s/free_world21/5M6488-2026-02-25-111519
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4EZLMPW973.jpg)

RubyとGoでゼロから作る証券システム：
高信頼性が求められるシステムのコードの
外側にある設計と運用のリアル
2026.02.20(Fri.)
Developers Summit 2026 Day 3
小林悟史(noel)
ブルーモ証券株式会社
©2026 Bloomo Securities Inc.


# Page. 2

![Page Image](https://bcdn.docswell.com/page/Y76WNMGD7V.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/G75M5ZV874.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/9J29NR3VER.jpg)

01 会社・プロダクト紹介 – 会社概要
社名
ブルーモ証券株式会社
所在地
東京都中央区日本橋兜町5-1 FinGATE BASE 404
設立日
2022年6月9日
資本金
1億円
代表者
中村 仁
事業概要
資産運用サービスの提供
従業員数
正社員数28名（業務委託・インターン25名）
4
©2026 Bloomo Securities Inc.


# Page. 5

![Page Image](https://bcdn.docswell.com/page/DEY4PD1QJM.jpg)

5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/VJNY562278.jpg)

01 創業からこれまでの歩み
6
©2026 Bloomo Securities Inc.


# Page. 7

![Page Image](https://bcdn.docswell.com/page/YE9PYL1DJ3.jpg)

01 会社・プロダクト紹介 ‒ プロダクト機能
ブルーモは2つのラインで資産運用サービスを提供
世界基準の全自動の資産運用
理想のポートフォリオで米国株・ETFを取引
©2026 Bloomo Securities Inc.


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GE8D6X45ED.jpg)

©2026 Bloomo Securities Inc.


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LELM98637R.jpg)

©2026 Bloomo Securities Inc.


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4JMYZ65MJW.jpg)

©2026 Bloomo Securities Inc.


# Page. 11

![Page Image](https://bcdn.docswell.com/page/PJR96P3L79.jpg)

©2026 Bloomo Securities Inc.


# Page. 12

![Page Image](https://bcdn.docswell.com/page/PEXQM396JX.jpg)

©2026 Bloomo Securities Inc.


# Page. 13

![Page Image](https://bcdn.docswell.com/page/3EK9GYPGED.jpg)

02
そもそも証券会社とは？
©2026 Bloomo Securities Inc.


# Page. 14

![Page Image](https://bcdn.docswell.com/page/L73WN9X575.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/87DKWG2YJG.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/VJPK9312E8.jpg)

03
証券会社スタートアップを
ゼロから作るための技術選定
©2026 Bloomo Securities Inc.


# Page. 17

![Page Image](https://bcdn.docswell.com/page/2EVVM4YXEQ.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/57GLG19REL.jpg)

背景、やりたいことや目指すべき方向
性はなんとなくわかった・・・！
しかしこれを
どういうテックスタックで実現してい
こうかなぁ・・・
©2026 Bloomo Securities Inc.


# Page. 19

![Page Image](https://bcdn.docswell.com/page/4EQYXDWYJP.jpg)

技術選定：決めるべき３つの要素
フロントエンド
（ネイティブアプリ）
バックエンド
（ビジネスロジック）
インフラ
（コンテナオーケストレーション）
©2026 Bloomo Securities Inc.


# Page. 20

![Page Image](https://bcdn.docswell.com/page/KJ4W6ZKZ71.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/LE1YVRXD7G.jpg)

Flutter vs React Nativeのトレンド
日本
アメリカ
全世界
全体的にFlutter優勢
©2026 Bloomo Securities Inc.


# Page. 22

![Page Image](https://bcdn.docswell.com/page/GEWGL1N8J2.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/47ZLMP39J3.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/YJ6WNMXDJV.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/GJ5M5ZX8J4.jpg)

バックエンド（ビジネスロジック）
•
選択肢が多く、かなり悩んだ
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.


# Page. 26

![Page Image](https://bcdn.docswell.com/page/LE3WN9XGE5.jpg)

バックエンド（ビジネスロジック）
•
選択肢が多く、かなり悩んだ
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.


# Page. 27

![Page Image](https://bcdn.docswell.com/page/8EDKWG2N7G.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/V7PK931NJ8.jpg)

もう一歩踏み込んで考える
本質的複雑性
機能面における
偶有的複雑性
•
対象とするドメインを選んだことにより付随
的に発生する機能の複雑さ・難しさ
•
競争力のコアではない部分
•
対象ドメインそのものの複雑さ・難しさ
•
競争力のコアとなる部分
技術面における
偶有的複雑性
•
実装方法に付随して発生する複雑さ
©2026 Bloomo Securities Inc.


# Page. 29

![Page Image](https://bcdn.docswell.com/page/2JVVM4YYJQ.jpg)

各項目の複雑性マッピング
本質的複雑性
取引ロジック
投資した資産の管理
手数料の計算
投資の税制対応
技術面における偶有的複雑性
機能面における偶有的複雑性
厳格な本人確認プロセス
暗号化
不正利用防止を防ぐ
顧客通知
証券業務を効率的に行う
業務システム
厳格なログイン・認証
異常検知
複数コンポーネントにまたがる
整合性管理
（分散トランザクションなど）
©2026 Bloomo Securities Inc.


# Page. 30

![Page Image](https://bcdn.docswell.com/page/5EGLG19WJL.jpg)

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.


# Page. 31

![Page Image](https://bcdn.docswell.com/page/4JQYXDWQ7P.jpg)

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.


# Page. 32

![Page Image](https://bcdn.docswell.com/page/K74W6ZKYE1.jpg)

あとは意思決定者（メインでドライブする人）が持ってるリソースとパッション
＊意思決定者＝小林の場合
＊意思決定当時のもの
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.


# Page. 33

![Page Image](https://bcdn.docswell.com/page/LJ1YVRXNEG.jpg)

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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/GJWGL1KM72.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/4EZLMPZM73.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/Y76WNMZ57V.jpg)

04 - 1
第1の柱：アーキテクチャと境界設計
〜Ruby on Railsが担う領域：顧客データ〜
©2026 Bloomo Securities Inc.


# Page. 37

![Page Image](https://bcdn.docswell.com/page/G75M5ZWG74.jpg)

Ruby on Railsが担う領域
•
顧客データ管理
– 本人確認・同意フロー
– 暗号化と個人情報管理
•
前段ゲートウェイ
– 認証・認可
– 入力内容の正規化やvalidation
•
証券オペレーション向け管理画面
– 口座開設審査
– 顧客対応、取引状況の確認
– 重要書面管理
•
外部システム連携と表記揺れ・名寄せ
©2026 Bloomo Securities Inc.


# Page. 38

![Page Image](https://bcdn.docswell.com/page/9J29NRQDER.jpg)

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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/DEY4PDWMJM.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/VJNY569378.jpg)

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


# Page. 41

![Page Image](https://bcdn.docswell.com/page/YE9PYL2PJ3.jpg)

個人情報の暗号化について ‒ 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.


# Page. 42

![Page Image](https://bcdn.docswell.com/page/GE8D6X5XED.jpg)

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[&#039;kms_cmk_id’],
key_spec: &#039;AES_256’,
)
self.encrypted_data_key = resp.ciphertext_blob
resp.plaintext
end
end
©2026 Bloomo Securities Inc.


# Page. 43

![Page Image](https://bcdn.docswell.com/page/LELM98YN7R.jpg)

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


# Page. 44

![Page Image](https://bcdn.docswell.com/page/4JMYZ6NQJW.jpg)

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
# =&gt; “ノエル”
puts personal_info.last_name
# =&gt; “小林”
©2026 Bloomo Securities Inc.


# Page. 45

![Page Image](https://bcdn.docswell.com/page/PJR96PDK79.jpg)

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
# =&gt; “ノエル”
puts personal_info.last_name
# =&gt; “小林”
個人情報の堅牢に保存する機構をRailsを活用して実現できた
©2026 Bloomo Securities Inc.


# Page. 46

![Page Image](https://bcdn.docswell.com/page/PEXQM315JX.jpg)

04 - 2
第1の柱：アーキテクチャと境界設計
〜Goが担う領域：金銭・取引データ〜
©2026 Bloomo Securities Inc.


# Page. 47

![Page Image](https://bcdn.docswell.com/page/3EK9GY2RED.jpg)

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


# Page. 48

![Page Image](https://bcdn.docswell.com/page/L73WN94G75.jpg)

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


# Page. 49

![Page Image](https://bcdn.docswell.com/page/87DKWGQNJG.jpg)

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


# Page. 50

![Page Image](https://bcdn.docswell.com/page/VJPK93LNE8.jpg)

05
第2の柱：
お金を守るための検証とダブルチェック
©2026 Bloomo Securities Inc.


# Page. 51

![Page Image](https://bcdn.docswell.com/page/2EVVM4QYEQ.jpg)

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


# Page. 52

![Page Image](https://bcdn.docswell.com/page/57GLG1WWEL.jpg)

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


# Page. 53

![Page Image](https://bcdn.docswell.com/page/4EQYXD3QJP.jpg)

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


# Page. 54

![Page Image](https://bcdn.docswell.com/page/KJ4W6Z1Y71.jpg)

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


# Page. 55

![Page Image](https://bcdn.docswell.com/page/LE1YVRGN7G.jpg)

06
第3の柱：
二重言語構成がもたらした
チーム文化とインシデント対応
©2026 Bloomo Securities Inc.


# Page. 56

![Page Image](https://bcdn.docswell.com/page/GEWGL15MJ2.jpg)

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


# Page. 57

![Page Image](https://bcdn.docswell.com/page/47ZLMPNMJ3.jpg)

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


# Page. 58

![Page Image](https://bcdn.docswell.com/page/YJ6WNM85JV.jpg)

参考情報：金融商品取引業者等向けの総合的な監督指針
令和７年10月版
https://www.fsa.go.jp/common/law/guide/kinyushohin/
©2026 Bloomo Securities Inc.


# Page. 59

![Page Image](https://bcdn.docswell.com/page/GJ5M5Z9GJ4.jpg)

ブルーモ証券のインシデント対応プロセス
©2026 Bloomo Securities Inc.


# Page. 60

![Page Image](https://bcdn.docswell.com/page/9E29NR2D7R.jpg)

ブルーモ証券のインシデント対応プロセス
アラート
• プログラムでエラーが発生するとシステ
ムアラート（Slack通知）される
• or 人間がたまたま不具合を発見する
• 手動アラートを発報して全体に周知する
©2026 Bloomo Securities Inc.


# Page. 61

![Page Image](https://bcdn.docswell.com/page/D7Y4PDYMEM.jpg)

ブルーモ証券のインシデント対応プロセス
トリアージ
• 重大インシデントかどうかを判断する
– 重大インシデントの基準は文書化されてい
る
– 自分で判断できない場合は上長など別の人
に判断を仰ぐ
• 重大インシデントと判断された場合はインシデ
ント対応プロセスを開始する
• 重大インシデントでないと判断されたら対応チ
ケットを作るなどして終わり
©2026 Bloomo Securities Inc.


# Page. 62

![Page Image](https://bcdn.docswell.com/page/VENY56P3J8.jpg)

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


# Page. 63

![Page Image](https://bcdn.docswell.com/page/Y79PYL3PE3.jpg)

ブルーモ証券のインシデント対応プロセス
ポストモーテム
•
インシデントレポートを作成
– 根本原因調査
– 恒久対応
– 再発防止策
•
インシデントレポートをレビューし、完了したら
ポストアクション（再発防止策の実施）へ移行
•
ポストアクションまで実施して本当の終了
©2026 Bloomo Securities Inc.


# Page. 64

![Page Image](https://bcdn.docswell.com/page/G78D6XMX7D.jpg)

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


# Page. 65

![Page Image](https://bcdn.docswell.com/page/L7LM983NJR.jpg)

とある日の当社のエンジニアの一言
©2026 Bloomo Securities Inc.


# Page. 66

![Page Image](https://bcdn.docswell.com/page/4EMYZ6DQEW.jpg)

とある日の当社のエンジニアの一言
＊進撃の巨人の『おそらく2年前の地獄を見
てきた者達だ』『面構えが違う』のシーンを
参考にChatGPTが生成
©2026 Bloomo Securities Inc.


# Page. 67

![Page Image](https://bcdn.docswell.com/page/PER96P4KJ9.jpg)

とある日の当社のエンジニアの一言
実際のメンバーは
こんな怖い顔はしてませんのでご安
心ください😂
＊進撃の巨人の『おそらく2年前の地獄を見
てきた者達だ』『面構えが違う』のシーン
を参考にChatGPTが生成
©2026 Bloomo Securities Inc.


# Page. 68

![Page Image](https://bcdn.docswell.com/page/P7XQM325EX.jpg)

07
まとめ
©2026 Bloomo Securities Inc.


# Page. 69

![Page Image](https://bcdn.docswell.com/page/37K9GYMR7D.jpg)

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


# Page. 70

![Page Image](https://bcdn.docswell.com/page/LJ3WN9YGJ5.jpg)

ご静聴ありがとうございました！
https://careers.bloomo.co.jp/
©2026 Bloomo Securities Inc.


