eClear Deskの@hase1031です。
enechainの子会社である株式会社eClearは2025年5月に現物・先物市場を効率的につなぐソリューションを提供することを目的に株式会社三菱UFJ銀行と資本提携を発表しました。
eClearは2022年9月から提供しているサービスですが、今回新たに提供するソリューションは、既存のものとは設計思想から求められる機能まで大きく異なり、コードベースの大部分を再構築する必要がありました。 本記事では、eClearが果たす役割と、先物取引への対応に向けたシステム開発の裏側、そしてそこから得た学びを紹介します。 今後はeClearに関する技術記事をさらに公開していく予定のため、本稿では詳細な技術仕様には踏み込みすぎず、全体像にフォーカスしています。 これから公開される記事をぜひ楽しみにしていてください。
eClearの存在意義
まずは、eClearが「何を解決するサービスなのか」を簡単に整理します。 たとえばA電力がB電力に対し、1年後に利用する電力を売るケースを考えてみます。電力の現物取引では、約定（2025/11）時点で代金は支払われず、需要月を経過した後（2026/12〜）に支払いが行われるという特徴があります。
そのため、そこには以下のようなリスクが存在します。
A電力から見たリスク
- 1年以内にB電力が電力を受け取れなくなる（不履行、破綻など）
- 受け渡し後にB電力から支払いが行われない
B電力から見たリスク
- A電力が電力を供給できなくなる（事業停止など）
eClearは、このようなリスクを低減するために、買い手には売り手として、売り手には買い手として介在し、決済と履行の確実性を保証します。 これにより市場参加者は、相手方の信用を気にせず取引できるようになります。
このような仕組みが市場に存在しないと、A電力が倒産した際に、A電力と取引があったその他の電力会社に影響が出て、倒産の連鎖が起こりかねません。
eClearによる現物・先物取引
日本電力はTOCOM・EEX・ICEといった電力先物市場で取引されており、電力会社はヘッジ目的、外資系企業は収益目的で積極的に利用しています。
現物と先物の違いは明確です。
| 種類 | 決済方法 | 必要なライセンス |
|---|---|---|
| 現物電力 | 電力受渡＋代金支払い | 小売電気事業者の登録 |
| 電力先物 | 価格差の金銭決済のみ | 不要（先物取引所における口座開設） |
市場参加者も異なるため、両市場はこれまで分断されていました。
今回eClearが取り組んだのは、現物市場と先物市場を橋渡しし、双方の流動性を高めることです。
たとえば、
A電力が現物を売る
C社（外資系トレーダー）が先物を買う
といった取引を、弊社が提供する卸電力取引プラットフォームeSquare Liveを通じて一貫して行えるようにします。
出典：eClearホームページ
この取り組みのために必要だった大きな変更点は次の2つです。
- 保証方式の転換：保険ベース → 銀行保証・証拠金ベース
- 日次の先物時価評価（Mark-to-Market）への対応
証拠金ベースのリスク管理では、eClearが顧客資金を預かり、必要に応じてマージンコールを行います。まさに金融先物取引における追証(追加保証金)の世界です。
また、先物は日々価格が変動するため、未実現損益や将来のリスク量を精緻に評価しなければ、eClearの財務リスクに直結します。
こうした新しい要件に対応するため、システムはほぼ全面的に再構築されました。
新システムのざっくり概要
必要となる主要機能はざっくり以下の通りです。
- 必要証拠金の計算
- 日次の時価評価（Mark-to-Market）
- マージンコール判定
- 顧客・金融機関向けレポートの生成
- 金融機関口座の残高管理
- オペレーション業務に必要な管理画面
- eSquare Live注文・約定時のリアルタイムの手数料・リスク計算
特に金融機関との連携では、APIを通じた残高照会を毎日行う必要があります。 開発時にはモックサーバーを用意して開発し、外部接続を吸収しつつ開発速度を維持しました。
また、eSquare Liveとの連携では、約定のたびにポートフォリオ全体のリスクを再計算し、注文の新規受付可否をリアルタイム判定する必要があり、高速化・正確性・整合性のすべてが求められました。
技術スタック
以下はeClearの技術スタックの一覧になります。基本的にはenechainの標準に則る形で技術選定しています。
- インフラ: Google Cloud（GKE上で稼働）。今後マルチリージョン化に対応予定
- データベース: Cloud SQL（PostgreSQL）
- 言語・フレームワーク: Go（バックエンド）、React + TypeScript（フロント）
- データパイプライン：dbt Cloud（enechainでデータ基盤以外への適用は初）
最も難しかったのは「リスク計算」
今回の開発でもっとも苦労したのは、ビジネスロジックの理解と、リスク計算の正しさを担保することでした。
金融機関のリスク管理は極めて複雑であり、リスク管理経験者を中心に関係者の認識を揃えるところからのスタートでした。 PdM坂田の発表資料に、ビジネス仕様の言語化と合意形成プロセスが詳細にまとめられています。
Excel依存からの脱却の難しさ
enechainにはクオンツが作成したリスク計算Excelがあり、これを読み解いて実装します。
しかし、これは次の理由で非常に難度が高いものでした。
- 数百〜数千のセルに計算ロジックが散らばっている
- Goとはインターフェースが異なり、同じデータ構造で検証しにくい
- 数値の突き合わせは手作業になりがちで、時間も工数も大きい
結果として、計算ロジックの整合性をとる作業は開発の大きなボトルネックとなりました。 現在ではソフトウェアエンジニアやQAエンジニアも計算ロジックへの理解が進んだり、一部自動化されていることもあり、徐々に工数が小さくなってきています。
将来的には、クオンツがPythonなどでモックロジックを作成し、エンジニアがGo/C++に実装する構造を目指しています。 金融業界ではクオンツがC++でライブラリを開発し、それをソフトウェアエンジニアが組み込むこともあるようです。
DevToolという「救世主」
この数値検証プロセスでは人海戦術で数字の突き合わせもしましたが、それ以上に活躍したのが２人のエンジニアが自発的に開発した シミュレーションツール（通称：DevTool） です。
DevToolにより誰でも以下が行えるようになりました。
- 任意のインプットデータを登録
- リスク計算を実行
- その結果をUIで比較・可視化
これにより、不整合箇所の検出が劇的に効率化され、DevToolは後に社内公式ツールとして、 現在では営業・オペレーションメンバーも日常的に利用するまでに進化しました。
今後の展望
eClearはまだ進化の途上にあります。今後も以下のような拡張が必要です。
- 電力業界特有の燃料調整費への対応
- デリバティブ商品であるSwapへの拡張
- 参加者向けポータルのUX改善
- 初期構築時に残った技術的負債の解消
また、機能追加と並行して、アーキテクチャのリファクタリングも進めていきます
eClearの各コンポーネントやDevToolの詳細については、今後さらにブログ記事として公開予定です。 お楽しみに！
enechainでは一緒に働くメンバーを募集しています。
興味がありましたら是非ご応募お待ちしております。
