【ITニュース解説】Contract-First Engineering in Distributed Core Banking

ITシステムでは、マイクロサービスと呼ばれる小さなプログラムが連携し、一つの大きなサービスを動かす。特に銀行のように大規模なシステムでは、多数のマイクロサービスが独立したチームで開発されるため、分散型の環境で「セマンティックドリフト」という問題が起こりやすい。

セマンティックドリフトとは、システム設計書で定められたデータの意味や形式と、実際に各チームが作ったプログラムでのデータの扱い方との間に、微妙なズレが生じることである。例えば、設計書で通貨を「ISO4217に沿った3文字の文字列」と定めても、あるプログラムでは自由な文字列として、別のプログラムでは数値コードとして実装されたり、データが省略されたりする。このようなズレが積もり、システム全体でデータ連携が破綻し、エラーや障害の原因となる。

従来の「コードファースト」開発では、まずプログラムを書き、後からAPI（アプリケーション同士のやり取りの窓口）の仕様書を自動生成することが多かった。この方法では、コードが事実上の正となり、仕様書がコードに追いつかず不正確になることが多い。結果として、プログラムの変更による「破壊的変更」が、統合テスト段階で初めて発覚し、手戻りや遅延を招く。BIAN（Banking Industry Architecture Network）のような業界標準で定められたサービス境界も曖昧になる危険性がある。

この問題を解決するのが「コントラクトファースト・エンジニアリング」である。プログラム開発前に、システム間のやり取りやデータ交換の「契約（コントラクト）」を機械可読な形で厳密に定義する。この契約書が、システム全体の「唯一の信頼できる情報源」となる。

Xenonアーキテクチャ標準では、コントラクトファーストを厳格に適用する。同期的なAPIには「OpenAPI 3.1」、非同期的なイベントには「AsyncAPI 3.0」の仕様書を用いる。これらの仕様書は、データの内容、形式、必須項目、パターンなどを詳細に記述する。

そして、この仕様書から開発環境でプログラムのひな形（インターフェース、データ転送オブジェクト、イベントスキーマなど）を自動生成する。すべての開発チームが同じひな形を使うため、プログラム間のデータズレ、すなわちセマンティックドリフトがコンパイル時にエラーとして検出される。仕様書が変更されれば、ひな形も更新され、プログラムもそれに合わせて修正しないとコンパイルが通らないため、開発者は常に最新の仕様に準拠したプログラムを作る。

セマンティックドリフトはシステム統合の失敗リスクを高める。コードファーストでは、各マイクロサービスにわずか5%のドリフト可能性があった場合、10個のマイクロサービスをまたがる処理でシステム全体の整合性が保たれる確率は約60%に低下する。コントラクトファースト・エンジニアリングでは、仕様の不一致がコンパイルエラーとして早期に発見されるため、ドリフトの可能性をほぼゼロに近づけ、システム全体の整合性を大幅に高める。

コントラクトファーストの開発では、まずシステム全体の契約（API仕様書）を中央のバージョン管理リポジトリに保存する。この契約は、マイクロサービスのソースコードとは独立して管理する。次に、CI/CDパイプライン（自動ビルド、テスト、デプロイの仕組み）で、契約書がBIANなどの業界標準に準拠しているかLINT（静的解析）し、既存契約との互換性（破壊的変更でないか）を検証する。これらのチェック後、契約書からJavaのJARファイルやTypeScriptパッケージなどのSDK（ソフトウェア開発キット）が自動生成され、企業内の共有ライブラリリポジトリに公開される。各マイクロサービスは、このバージョン管理されたSDKをライブラリとして取り込み、その中の自動生成されたインターフェースやデータ構造を使ってプログラムを実装する。

例えば、支払い実行の同期APIはOpenAPI 3.1、支払い完了イベントの非同期ストリームはAsyncAPI 3.0で仕様書が記述される。これらの仕様書には、リクエストのURL、HTTPメソッド、必須ヘッダー、送受信データ形式（JSON）、各データの型、最小値、最大値、正規表現パターンなどが詳細に定義される。開発者は、Mavenなどのビルドツールに組み込まれたコード生成プラグイン（例: openapi-generator-maven-plugin）を使い、仕様書からJavaのインターフェースやDTO（データ転送オブジェクト）を自動生成する。開発者はこの生成されたインターフェースに沿ってビジネスロジックを実装する。仕様書変更がインターフェースに影響する場合、プログラムはコンパイルエラーとなり、速やかな修正が促されるため、仕様書とプログラムのズレを防ぐ。

契約の品質とガバナンス維持には、自動化されたルールチェックが不可欠だ。SpectralのようなLINTツールは、OpenAPI仕様書に対し、BIAN準拠のルール（必須ヘッダー、キャメルケースのプロパティ名、ISO4217通貨パターンなど）を自動検査する。また、GitHub ActionsなどのCI/CDワークフローでは、openapi-diffのようなツールで、新しい契約変更が既存システムとの後方互換性を持つか自動検証する。必須フィールド削除、列挙型の値変更、必須リクエストパラメーター追加といった破壊的変更が適切なバージョンアップなしに行われた場合、ビルドがブロックされ、意図しない破壊的変更が本番に導入されることを防ぐ。

大規模システムで多数のサービスドメインがある場合、契約ファイルを各マイクロサービスのリポジトリに分散すると、依存関係が複雑になり管理が困難になる。そのため、契約ファイルは一つの集中管理されたスキーマモノリポジトリに集約するのが望ましい。変更があると、自動的に様々な言語のSDKが生成され共有リポジトリに公開され、マイクロサービスはそれらを共通ライブラリとして利用できる。

既存のレガシー銀行システムとの連携も重要だ。これらの古いシステムは、OpenAPIやAsyncAPIのようなモダンな形式に対応していないことが多い。そのため、レガシーシステムの古いデータ形式がモダンなシステムに漏れ出さないよう、Anti-Corruption Layer（ACL）という特別なマイクロサービスを導入する。ACLサービスは、外部にモダンなBIAN準拠のコントラクトファーストインターフェースを提供し、内部でレガシーなデータ形式との変換を担う。

このように、コントラクトファースト・エンジニアリングは、システム統合における手作業のエラーを減らし、自動化されたコンパイル時の保証へと変革する。バージョン管理されたOpenAPIやAsyncAPIの仕様書から直接コードを生成することで、モダンな銀行アーキテクチャはセマンティックドリフトを排除し、BIANなどの厳格なドメイン境界を強制し、分散チーム間のシームレスな相互運用性を保証する。