民間の金融機関が提供する預金口座サービスと接続し円通貨をデジタル上で扱える形にする取り組み”DCJPY”。高い信頼性とリアルタイム性が求められる決済基盤の開発においては、トレードオフの中で「何を優先し、どこで割り切るか」を決める必要がある。本イベントは、デジタル通貨を軸にしたエンタープライズ向けの新たな金融プラットフォーム構築を目指すディーカレットDCPの開発チームが、「現場でどう決め、どう作り、どう改善しているか」について、その取り組みを紹介した。

デジタル通貨プラットフォームを実現するためのシステムアーキテクチャ設計

はじめに、株式会社ディーカレットDCPプロダクト開発グループ開発チームヘッドの森浩貴氏が、「デジタル通貨プラットフォームを実現するためのシステムアーキテクチャ設計」というテーマで登壇。デジタル通貨プラットフォームの開発・運用を行う同社が、商用利用に耐えうる高いセキュリティと信頼性を備えたデジタル通貨基盤を目指すにあたってどのようなシステムアーキテクチャを採用しているか説明した。

同社は「Digital for all Value（すべての価値をデジタルに）」を掲げ、デジタル技術を活用することで、あらゆる価値のやり取りをよりスムーズかつ安全に行える社会の実現を目指している。デジタル通貨DCJPYを中心に、既存の通貨のやり取りをインフラレベルから変えていく取り組みを行っている。

デジタル通貨には複数の種類が存在する。中央銀行が発行するデジタル通貨や、民間銀行が発行するデジタル通貨など、その範囲は広い。これらの違いを理解するうえで重要なポイントが、法的位置付けだ。

例えば、ステーブルコイン。日常生活で広く利用されている決済手段で、交通系ICカードのSuicaや電子マネーのWAONなど前払式支払手段のものや、PayPayや楽天ペイといったQRコード決済のような資金移動業型のサービスなどが挙げられる。

資金移動業型は、資金移動業のライセンスを保有する事業者がステーブルコインの発行体となる。発行体は利用者預り金と同額以上の資金を供託し、償還の際は供託金から還付手続きを実施する。1回あたりの送金金額が100万円までという制約がある。

DCJPYは、決済用預金であることの3つの条件「決済サービスを提供できること」「預金者が払戻しをいつでも請求できること」「利息がつかないこと」を満たすため、銀行型として位置付けられる。

「このうち当社が扱うデジタル通貨DCJPYは、銀行型と呼ばれています。銀行預金と直接接続し、その預金をトークン化してブロックチェーン上で流通させる仕組みを採用している点が特徴といえます。預金として扱われるため、決済額の上限に制約がありません」（森氏）

実際に、デジタル通貨プラットフォームはどういう動作をするのか。森氏は下図を用いて説明した。

図の左下が、通常の預金口座だ。その上が、同社の銀行のデジタル通貨預金である。ユーザーはDCJPYネットワーク上に通貨口座を開設し、ID認証を行う。この認証でデジタル通貨口座と預金口座を接続する。

金融機関が管理・運営するフィナンシャルゾーンは預金領域に相当し、ここでトークン化された預金が管理される。単にデジタル通貨上で送金し、再び通常の預金口座へ戻すだけでは新たな価値は生まれないため、同社のプラットフォームではトークン化された預金があたかも右のビジネスゾーンへ移動するような振る舞いをする。

このとき、実際に資金そのものが移動するのではなく、指図トークンと呼ばれる仕組みが用いられる。指図トークンをビジネスゾーン間で発行することで事業者と接続し、決済手段として利用できるようになる。

こうしたフィナンシャルゾーンとビジネスゾーンからなる2層構造システムである点が、このプラットフォームの大きな特徴だ。

「フィナンシャルゾーンとビジネスゾーンの間をIBC（Inter-Blockchain Communication）というプロトコルで相互接続し、やり取りをしています。また、ブロックチェーンであることによって、NFTなど他のブロックチェーンのサービスと相互接続をすることも可能です。当社はこの2層構造の部分について、特許を取得しています」（森氏）

続けて森氏は、デジタル通貨プラットフォームの商用化事例を紹介した。

この事例では、「非化石証書」と呼ばれる証明書を対象としている。非化石証書は、カーボンニュートラルなエネルギーの利用に応じて発行されるもので、従来はエネルギー利用に伴う支払いと証書の発行が別々のタイミングで行われていた。

そのため、支払いが完了しているにもかかわらず証書が発行されないといった事象が発生する可能性があり、さらに支払い確認や証書発行のプロセスには人手によるチェックが介在していた。

これに対し、同社はブロックチェーンの特性を活用した「DVP（Delivery Versus Payment）決済」を導入。支払いや商品、証明書、資産の移転を同時に実行することで、プロセスの分断を解消した。これにより、人手による作業を削減し、運用コストの低減を実現している。

次に森氏は、システム構成について解説した。前提として、デジタル通貨が預金として扱われるということは、システムの品質・運用・セキュリティにおいて金融機関と同等の対応が必要である。このため、金融機関向けのFISC安全対策基準に準拠した統制基準・実務基準・設備基準・監督基準が求められるのだ。このうち、システムのアーキテクチャに関わるのが実務基準である。例えば、冗長構成・バックアップ構成や、障害時の縮退・再構成機能などについて、厳しく定められている。

DCJPYのシステム構成は下図の通りだ。

中央のコアパッケージがブロックチェーンのシステム、その左右にあるBPMが外部のAPIなどを管理している。このコアパッケージ部分を標準機能として提供しており、BPM側で外部接続に必要なカスタマイズを行う。

なお、万が一災害が起こった場合に備え、マルチリージョン構成で構築を行っている。AWS上にシステムを構築し、グローバルサービスに分類されるリソースを全面に配置して、東京・大阪で分散できるよう冗長化して構成している。

森氏はさらに、DCJPYのブロックチェーンネットワークについても言及する。

「フィナンシャルゾーンは一つのブロックチェーンネットワークで構成していて、ビジネスゾーンはそれぞれのゾーンごとにブロックチェーンネットワークを構成しています。これらをIBC（Relayer）で接続し、他のパケットのやり取りが可能です」（森氏）

そして最後に、システムアーキテクチャについて説明がなされた。

一般的にシステムアーキテクチャとは、「システムの構造」「アーキテクチャ特性」「アーキテクチャ決定」「設計指針（ガイドライン）」という4つの要素を組み合わせ、トレードオフのバランスを取りながら定義される、システム全体の土台である。

例えば、構成をシンプルにすれば、開発や運用は容易になる。一方で、この構造を採用した場合、システム全体を一体としてスケールさせる必要があるため、拡張性の面では制約が生じやすい。

DCJPYにおけるアーキテクチャは下図のとおりだ。前面に「サービスベースアーキテクチャ」を置き、その後ろに「イベント駆動アーキテクチャ」を置く。

サービスベースアーキテクチャとは、システムを業務ドメイン単位で、比較的粗い粒度に分割する手法である。具体的には、認証・署名サービス、ユーザー向けサービス、管理者向けサービスといった単位で機能を分割しつつ、データベースは一つを共有する形を採用している。

モノリシックアーキテクチャでは、1つのアプリケーションの中に、顧客ロジックとして注文ロジックや在庫ロジックといった形でロジックが分割されて存在しており、密結合になっている。人がコードを読もうとした場合、データベースのスキーマやテーブルの構造が変わっても影響範囲が追いやすい。

一方、サービスアーキテクチャは、モノリスの中でロジックとして実装していた機能を独立したサービスとして切り出し、別のアプリケーションとして構築する。マイクロサービスではデータベースを分割することが一般的だが、サービスアーキテクチャではデータベースは分割しないため、移行は比較的容易だ。

ただ、例えば顧客向けサービスの改修に伴ってデータベーススキーマを変更した場合、その変更が注文サービスや在庫サービスなど、他のサービスに影響を及ぼす可能性がある。そうした影響範囲の調整がしづらい点がデメリットだ。また、マイクロサービスにすることで、金銭面のコストが上がる点もデメリットの1つとなる。

もう1つのイベント駆動アーキテクチャとは、システム内で発生した状態の変化をイベントとして配信し、それをイベントコンシューマーで各サービスが非同期に処理を行う構成を指す。これは疎結合で独立したサービスであり、比較的管理はしやすい。イベント駆動アーキテクチャは、AWS上で「イベントプロデューサー」「イベントブローカー」「イベントコンシューマー」の3つで構成している。

処理は「①ブロック生成イベント取得」「②メッセージファンアウト」「③メッセージサブスクリプション」の流れで行われる。

同社ではHYPERLEDGER BESUというイーサリアムベースのブロックチェーンクライアントを使用している。subscribeNewHeadでブロック生成した際のイベントを開き、そこから仮にブロック情報を取得するとトランザクションイベントログも同時に拾うことができる。これがイベントのプロデューサー部分であり、これをDynamoDBに登録すると、Data Streamsでレコード内容をそのまま連携する。この内容をLambdaでSNS管理転送することで、各サービスのSQSにそのままメッセージを転送する。

「このとき、1つのLambdaからSNSを経由せずにSQSに直接メッセージを送ると、2つ目以降のSQSに登録する際にエラーが返されてしまいます。反対に、Lambdaを増やすと、今度はエラー発生率が高くなり、この対応も好ましくありません。AWS側の制約により、先に紹介した実装方法が適切と言えます」（森氏）

最後に、各サービスがSQSからメッセージを取得して処理を実施する。このとき、Dead Letter Queueを用意することで、各サービスの特性に応じたリトライポリシーを設定できる。また、SQSを増やすことで後続サービスを容易に増やすことができる拡張性の高さもメリットだ。

最後に森氏は、アーキテクチャの今後の課題として、「監視運用の複雑化」と「データ構造変更時の予期しない不具合」を挙げた。

「これまで述べてきたように、アーキテクチャはトレードオフのバランスによって成り立っています。サービスの独立性やモジュール性を高めたことで、エラー発生時の原因特定が困難となる側面があります。この課題には分散トレーシングなどの技術で対応できますが、その分金銭コストが増えてしまいます。また、サービスベースアーキテクチャではアプリケーションレベルでの依存性は低いものの、データベースやデータ構造には依存が発生しています。そのため、データへの修正が予期せぬ不具合につながることがあります。これもマイクロサービス化が可能ではあるものの、サービス全体がさらに独立するうえに、システム全体がより複雑化することで運用コストが高くなります。このようなトレードオフを踏まえながら、今後どのようにアーキテクチャを進化させていくかが重要な検討課題です」（森氏）

フロントエンドのモノレポ実践

続いて、ディーカレットDCPプロダクト開発グループ 開発チームの川上明里氏が、「フロントエンドのモノレポ実践」というテーマで登壇した。講演では、いかに低コストで迅速に、かつ継続的なリリースを実現するための設計について解説がなされた。

川上氏はまず、当時のディーカレットDCPの状況と課題について説明。プロダクトは立ち上げ期にあり、すでに1つのプロダクトをリリースした段階から、複数の顧客に向けてスケールしていくフェーズにあったという。

スケールの方法としては、基本機能は同様としながら、UIや一部機能に差分を持つプロダクトを展開していく方針を採っていた。川上氏は、この「少しずつの差分」がコードの複雑化を招きやすいポイントであると指摘する。

こうした状況のもと、課題となっていたのが開発効率である。限られたリソースで開発コストを抑えつつ、増えていくアプリケーションを開発していく必要があった。この課題に対し、フロントエンドで採用したのはモノレポだった。

モノレポとは、複数のプロダクトを単一のリポジトリで管理し、コード共有と変更管理を効率化する手法である。従来採用していたポリレポでは、アプリケーションごとにリポジトリが分かれていたのに対し、モノレポではすべてのアプリケーションを1つのリポジトリに集約して管理する。開発初期のフェーズであれば、パッケージを導入するだけで比較的容易に構築できる点も特徴の一つだという。

「モノレポの一般的なメリットは、コードの再利用が容易になること、一度の変更で複数のアプリケーションに反映できること、依存関係の把握がしやすくなることなどが挙げられます。また、開発ルールの統一や開発体験の向上にも寄与します」（川上氏）

一方で、モノレポを採用しただけでは解決できない課題もあった。まず、差し替えたい機能がネストされたモジュールとなっており取り出せない、モジュール間の結合度が高いといった点だ。

この状況について、川上氏はアプリケーションを「木」に例えて説明した。最初に開発されたプロダクトは、いわば「リンゴの木」のような構造で、実・葉・幹といった要素を一体のモジュールとして実装していた。これらは常にセットで使われる前提で設計されており、個別の要素だけを切り出して利用することが難しい構成になっていた。

そのため、例えば次に「桜の木」のようなアプリ、つまりリンゴの実を桜の花に置き換えたプロダクトを開発しようとすると、葉やその他の部分と一体で作り直す必要があり、開発コストが大きくなってしまう。そこで、モジュラーモノリスという考え方に従い、アーキテクチャをあらためることとなった。

モジュラーモノリスとは、モノリス構造を保ちながら、機能ごとに明確なモジュール境界を保たせたアーキテクチャを指す。昨今流行しているマイクロサービスは、分割をしすぎて開発と運用が複雑になってしまうのに対し、モジュラーモノリスはその課題を解決する手法として注目されている。

モジュール分割は、縦軸と横軸でシステムを整理し、網目状に境界を引く。縦軸には「技術的関心による分割」、横軸には「ドメインのコンテキストによる分割」を置いている。

「モジュラーモノリスを導入後、当社では3つの点を工夫して運用しました。1つ目は、小粒度なモジュール境界を設定すること。2つ目は、最上位ですべてのモジュールを組み合わせられるよう、フラットな設計にすること。3つ目は、はじめからすべてをモジュール化しないようにしたことです。これにより、細かなパーツであっても差し替え可能となり、最小限のメンテナンスで済むようになりました」（川上氏）

最後に川上氏は、今後の課題について触れた。現在のフロントエンド設計は一定の成果を上げているものの、さらに検討すべき論点としてモジュールでの個別のバージョン管理やPoCからプロダクト版へ迅速リリースする方法など、いくつかの課題が残っているという。

「ここに初期フェーズ以外でポリレポをモノレポに移行するヒントがあるのかもしれないと考えています。当社のような少しの差分が発生するケースでは、モジュラーモノリスによる開発が合っています。集約だけでなく、分割することが重要だという点が、今回の一番の学びでした」（川上氏）

DD実現のためのバックエンドのリファクタリング

続いて、「DD実現のためのバックエンドのリファクタリング」をテーマに、ディーカレットDCPプロダクト開発グループ 開発チームの竹房透氏が登壇した。

まず、同社のシステムは大きく「コアパッケージ」と「BPMパッケージ」に分かれており、このうちBPMパッケージは顧客ごとのビジネスロジックを吸収する役割を担っている。このBPMのソフトウェアアーキテクチャは、第1号案件の前に導入されたものであり、当時はDDD（ドメイン駆動設計）とクリーンアーキテクチャに基づく構成とされていた。

下図はクリーンアーキテクチャの図だ。中央がビジネスロジックを表しており、外側にユースケースが表示されている。外側の層は内側の層を使うことができるが、逆は不可能だ。

当時のソフトウェアアーキテクチャには問題もあった。DDDとクリーンアーキテクチャで開発していると聞いてはいたものの、実態は「値オブジェクト＋トランザクションスクリプトパターン＋クリーンアーキテクチャ」という独自のアーキテクチャになっていたと言う。それが、認知負荷と修正コストの高さという2つの問題を生んでいた。

「認知負荷に関しては、パッケージ構成を見るとユースケース層の下に数十に及ぶクラスが配置されていたり、ドメイン層にもvalueパッケージの中にクラスが山のように格納されていたり、エンティティやリポジトリ、サービスといったDDDで一般的に用いられるパターンとは異なるテーブルやクラスが格納されていました。また、ユースケースが異なるのに同じクラスにメソッドを定義しており、そこからdoCommonのような共通メソッドを呼び出していたため、修正を加えようとするとそれだけで1日かかってしまうといったことが起こっていたのです」（竹房氏）

（改善活動の推進により、現在はこれらの問題は概ね解決に至っている。）

こうした課題に対し、竹房氏は次のようなプロセスで解決を試みた。平常業務の遂行と並行し別途リソースを割いて改善作業をスタートした竹房氏は、はじめにチームや上司に課題を共有し、クリーンアーキテクチャやDDDについて復習した。そのうえで、修正計画やパッケージ構成案、サンプルコード修正手順を作成し、コード規約の修正や作成を行った。

具体的な改善内容としては、従来の「クラスがパッケージ内に山のように格納された状態」を解消するために再設計を行っている。

まず、アプリケーション層では、コマンドとクエリを明確に分割。クエリは一覧取得など、ビジネスロジックの関与が少ないデータ取得系のAPIを格納する。コマンドはビジネスロジックを使った処理を行うAPIを配置した。かつ、コマンドの下も各ユースケースごとパッケージを分けたうえで、Data Transfer Object（DTO）や例外、ファクトリーなどで整理している。

さらにドメイン層については、DDDのコアとなる集約を表すパッケージに分割して、その下にルートやエンティティなどDDDのパターンに沿った構成を採用した。

アプリケーション層もドメイン層もうまく分かれることはなく、例えばアプリケーション層であれば言語機能をサポートする機能などを配置しなければならないため、Shareというパッケージを作ってそこに格納している。

こうした改善施策によって、コードの可読性が高くなったと竹房氏は手応えを語る。具体的には、各層の役割が明確化し、ユースケース層のアプリケーションクラスは「What」を書くのみとなった。また、ドメイン層のクラスは「How」と、かつ業務に関連するクラスのみだ。

コードの可読性が高くなったもう1つの要因として、共通処理の抽象化が容易になったことが挙げられる。共通処理に名前をつけること自体が難しく、粒度もまちまちになりがちだ。かつ、パッケージ構成も難しい。しかし、DDD＋クリーンアーキテクチャであればある程度パターン化が可能であるため、集約に属するエンティティやドメインサービスに共通処理を寄せることができる。

一方で、このプロジェクトには反省点もあると言う。

「ソフトウェアアーキテクチャ変更の効果を測定できる仕組みがまだ整っていません。このため、ビジネスにどれだけ貢献できたかを可視化することができないのです。また、今回はDDDの仕組みを利用しただけで、問題はまだ残っています」（竹房氏）

具体的には、BPMコンポーネントにおいてAPIが過剰に定義されており、本来は分割したほうがよい領域が未対応のままとなっている。また、DDD本来の考え方である「業務用語とコードの用語を統一する」という点も実現できていない。また、実装面での課題として、クラスのメンバ変数が多く、適切に分割すべき箇所が残っている。また、クリーンアーキテクチャの採用に伴い、Data Transfer Object（DTO）を大量に作成しなければならず、生産性の観点でも課題がある。そして、もっとも大きいのが組織の課題だ。個人に依存している面が強く、今後また同じ過ちが繰り返される可能性がある。

最後に竹房氏は、今後の方針について説明した。

「まずは、今回進めているDDD本来の考え方である業務用語とクリーンアーキテクチャの修正を確実に完了させること。そのうえで、メトリクスやソフトウェアアーキテクチャのテストを行える仕組みを導入し、改善の効果を継続的に確認できる状態を目指します。また、APIの分割も視野に入れています。それをモジュラーモノリスでするか、マイクロサービスにするか、コンポーネントの要否などについても、組織と技術力、ビジネスの要求などを踏まえ、検討していく必要があります」（竹房氏）

【質疑応答】

Q.冒頭でステーブルコインのお話がありましたが、ビジネスゾーンでの取り扱いとなるイメージでしょうか。

森氏：ステーブルコインを発生させるには別の金融ライセンスが必要となるので、当社ではできません。ステーブルコインは基本的には裏付け資産です。現金そのものや債権、金などを預け入れたうえで、その分だけ発行できるものです。当社が参入するのであれば、フィナンシャルゾーン側でステーブルコインをサービスとして提供している事業者と接続し、当社のDCJPYを担保に預け入れて、相手のサービス上でステーブルコインを発行することになります。

Q.DCJPYプラットフォームは特許取得した二層構造の構成ということでしたが、特徴はどういった部分にありますか。

森氏：例えば1層構造にしてしまうと、フィナンシャルゾーン、つまり預金システムに事業者が接続することになります。その場合、決済処理を行う際に、然るべき金融ライセンスを保有しておらず接続銀行が許可していない事業者がトークンを直接動かすことになりますが、これは預金債権そのものに触れることになり、金融法制上認められません。

当社の場合は金融ライセンスを保有しているため、事業者側はあくまで指図トークンを扱う形になります。ビジネスゾーンに存在するのは預金そのものではなく、あくまで指図トークンです。事業者がこのトークンを伝達すると、その内容が当社に伝達され、当社がフィナンシャルゾーン側へ送金指示を出す仕組みになっています。

つまり、二層構造を採っているのは、法的な壁を乗り越えるためのスキームであり、これが特許を取得している部分なのです。

Q.マイクロサービスに振り切らなかった理由は、技術に加え組織や運用の制約も大きかったのですか。

森氏：主な理由は、歴史的背景にあります。マイクロサービスの採用については、そこまで踏み込んだ検討はしていません。もともと商用化の前に、実証実験としてプロトタイプを開発しており、その時点で現在に近い構成を採用していました。その後、プロダクト化にあたっては、運用やメンテナンス性を考慮して一定の改善を加えたうえでリリースしています。

そもそも開発当時はプロジェクトが切迫した状況にあり、マイクロサービスについて検討する余裕がなかったという事情があります。ただ、今マイクロサービスを採用するかと問われたら、「しない」と考えています。

なぜなら、データベースやアプリケーションをより細かく分割することによるシステムコストの増大が無視できないからです。

Q.決めたルールを守るために取り組まれていること、苦戦していることなどがあれば教えてください。

竹房氏：前提として、現在はチーム数が増えており、かつ新規開発や既存機能の改修を止めることができない状況にあります。そのため、アーキテクチャの変更を担当するチームと、新規開発・改修を担当するチームを分けて進めています。

新規開発や改修を行うチームについては、既存APIの修正に関しては従来通りのやり方を維持してもらっています。一方で、アーキテクチャ変更を担当するチームについては、定めたルールに従って実装するようにしています。ルール自体も明文化しており、レビューについては私自身が確認することで一定の担保を図っています。

ただし、取り組み自体はまだ始まったばかりの段階であり、今後さらに検討や改善が必要だと考えています。

苦戦している点としては、やはり新規開発や改修を止められない一方で、どこかのタイミングで大きくアーキテクチャを切り替える必要がある点です。その際の教育コストは相当大きくなると見込んでいます。

また、今回の改善では、値オブジェクトやアダプタ層といった基礎的な部分については、影響範囲や改修コストの大きさから手を付けていません。本来であれば修正した方がきれいな構造になりますが、現時点では優先度との兼ね合いで見送っています。

Q.モノレポは一つのリポジトリで管理できる点で魅力的に感じます。一方で、Dockerなどコンテナ技術を使うっていう方法もありではないかと思うのですが、そもそもコンテナとモノレポはどう違うのでしょうか。

川上氏：Dockerのようなコンテナ技術は個人の開発環境をまとめるために使います。モノレポは、開発しているアプリをまとめます。このように、両者はそもそも使い方が異なります。環境設定や開発に付随するコストも含めて軽くしたり、アプリをデプロイして動かす場合はDockerが便利です。一方モノレポはCI/CDにおいて利点があります。デプロイを一度実行すればすべてのアプリで済むため、導入すればすぐにメリットを感じられるのではないでしょうか。

※所属組織および取材内容は2026年3月時点の情報です

株式会社ディーカレットDCP
https://www.decurret-dcp.com/

株式会社ディーカレットDCPの採用情報
https://www.decurret-dcp.com/recruit/