integration-patterns

統合パターン

コアコンセプト

1. 金融システムの API 設計

金融 API は、ポジションデータ、取引履歴、口座情報、参照データ、注文送信を提供します。金融データの機密性、監査可能性、量の多さから、設計規約は汎用 API とは異なります。

REST の規約： 金融エンティティには名詞を使った、リソース指向の設計を採用します。例：/accounts/{id}/positions、/transactions、/orders/{id}/executions。HTTP メソッドは意味に沿って使用します。GET は読み取り（ポジション、残高）、POST はアクション（注文送信、振替の開始）、PUT/PATCH は更新（口座設定、モデルの割り当て）に使用します。標準の HTTP ステータスコードを返し、追跡可能性を確保するため、エラーコード、人が読めるメッセージ、相関 ID を含むドメイン固有のエラーボディを返します。金融 API では、同期操作（ポジション照会は直ちに結果を返す）と非同期操作（振替の開始は、ステータス確認用 URL または Webhook コールバックとともに 202 Accepted を返す）を区別する必要があります。一括リバランスやバッチ注文送信などの長時間実行操作では、クライアント側のタイムアウトを避けるため、非同期パターンを使用します。

WebSocket とストリーミング： リアルタイムのユースケース（ポジション更新、注文ステータス、市場データ）では、WebSocket 接続により、ポーリングのオーバーヘッドなしにサーバーからデータをプッシュできます。金融 WebSocket API では、接続の停止を検知するハートビート／ピンポン、状態復旧を伴う自動再接続（再接続時にクライアントが未受信の更新を受け取る必要があります）、およびコンシューマーがプロデューサーに追いつけない場合のバックプレッシャー処理が必要です。

バージョン管理： URL ベースのバージョン管理（/v2/positions）は、可視性とキャッシュ可能性の高さから、金融 API で主流のパターンです。破壊的変更（フィールドの削除、型の変更、意味の変更）には新しいバージョンが必要ですが、追加的な変更（新しい任意フィールド）には必要ありません。公開された廃止スケジュール（金融サービスでは通常 12～18 か月）を設け、少なくとも 2 つのバージョンを並行して維持します。

大規模データセットのページネーション： ポジションや取引のエンドポイントでは、通常、数千件のレコードが返されます。同時書き込み中の一貫性を保つため、オフセットベースよりも、カーソルベースのページネーション（不透明な次ページトークン）が推奨されます。総件数の推定値、ページサイズの上限、ソートパラメーターを含めます。一括データ抽出には、ページネーション付き API 呼び出しではなく、ファイルを返す個別のエクスポート／ダウンロードエンドポイントを用意します。

レート制限とスロットリング： 市場イベント（取引開始、終了、ボラティリティの急上昇）時のバーストトラフィックからシステムを保護します。トークンバケットアルゴリズムまたはスライディングウィンドウアルゴリズムを使用します。Retry-After ヘッダーとともに 429 Too Many Requests を返します。クライアントごと、エンドポイントごと、操作タイプごと（読み取りと書き込み）にレート制限を区別します。

認証と認可： サービス間の連携には OAuth 2.0 クライアントクレデンシャルフローを使用します。より簡易な連携には、HMAC リクエスト署名付き API キーを使用します。高セキュリティのカストディアン接続や清算接続には、相互 TLS（mTLS）を使用します。ロールベースアクセス制御の対象は、口座、操作（読み取り専用と読み書き可能）、データの機密レベルに限定します。トークンの有効期限とローテーションのポリシーは自動化する必要があります。有効期限切れの認証情報は、連携停止の主な原因です。

統合テスト： 金融 API の統合には、本番環境の動作（現実的なデータ量、エラーシナリオ、レイテンシ特性を含む）を再現した専用のテスト環境（UAT／サンドボックス）が必要です。契約テスト（プロデューサーとコンシューマーの双方が API 仕様に準拠していることの検証）により、個別のデプロイ時に発生する統合のリグレッションを防止できます。カストディアンやデータベンダーは通常、認証用環境を提供しており、本番環境への接続には認証の完了が前提条件となります。正常系、文書化された各エラーコード、タイムアウト時の動作、ページネーションの境界条件、レート制限への応答を網羅する統合テストスイートを維持します。

2. FIX プロトコル

Financial Information eXchange（FIX）プロトコルは、電子取引における主要なメッセージング標準であり、バイサイド企業、セルサイド企業、取引所、ECN、代替取引システムを接続します。

プロトコルの構造： FIX メッセージは、SOH（ASCII 0x01）で区切られたタグ=valueの組み合わせの並びです。各メッセージは、ヘッダー（BeginString、BodyLength、MsgType、SenderCompID、TargetCompID、MsgSeqNum、SendingTime）、本文（メッセージタイプ固有のフィールド）、トレーラー（CheckSum）で構成されます。タグは数値です（例：Tag 35 = MsgType、Tag 55 = Symbol、Tag 44 = Price、Tag 38 = OrderQty）。

セッションレイヤー： 接続、シーケンス管理、復旧を管理します。Logon（MsgType=A）は、シーケンス番号の同期を行ってセッションを確立します。Heartbeat（MsgType=0）とTestRequest（MsgType=1）は接続の健全性を監視します。ResendRequest（MsgType=2）とSequenceReset（MsgType=4）は、切断後のギャップ復旧を処理します。Logout（MsgType=5）はセッションを終了します。シーケンス番号はセッションごと、方向ごとに厳密に単調増加し、ギャップが発生すると自動復旧が開始されます。

主なアプリケーションメッセージ： NewOrderSingle（MsgType=D）は注文を送信します。ExecutionReport（MsgType=8）は約定、部分約定、キャンセル、拒否を報告します。OrderCancelRequest（MsgType=F）とOrderCancelReplaceRequest（MsgType=G）は注文を変更またはキャンセルします。MarketDataRequest（MsgType=V）は市場データを購読します。MarketDataSnapshotFullRefresh（MsgType=W）とMarketDataIncrementalRefresh（MsgType=X）は市場データを配信します。

FIX のバージョン： FIX 4.2は、株式注文のルーティングで今も広く導入されています。FIX 4.4では、複数レッグ商品、アロケーション、ポジション管理へのサポートが改善されました。FIX 5.0（FIXT 1.1トランスポートを使用）ではセッションレイヤーとアプリケーションレイヤーが分離され、トランスポートの独立性とバージョン管理されたアプリケーションメッセージが実現しました。新規実装の多くは、取引相手の要件に応じてFIX 4.4またはFIX 5.0/FIXT 1.1を対象とします。

FIX エンジンとライブラリ： QuickFIX（オープンソース、C++/Java/.NET/Python）、QuickFIX/J（Java）、Chronicle FIX（低レイテンシーのJava）、Cameron FIX（商用）、Onix FIX（商用、高性能）があります。エンジンはセッション管理、メッセージ解析、シーケンス管理、永続化を処理します。アプリケーションロジックは、コールバック（メッセージタイプごとのonMessageハンドラー）を介して接続します。

FIX 接続の管理： 各取引相手について、合意済みのCompID、メッセージバージョン、カスタムタグを設定した個別のFIXセッションが必要であり、本番環境の前にUATでテストする必要があります。ブローカー、取引所、カストディアンをまたいで20～50のFIXセッションを管理することは、相当な運用負荷になります。セッション管理を一元化するには、FIXハブまたは注文管理システムを使用します。

カスタムタグと拡張： 取引相手から、独自のフィールド（内部注文ID、戦略コード、清算指示、規制関連識別子など）にカスタムFIXタグ（タグ番号5000超）を求められることがよくあります。取引相手ごとに、すべてのカスタムタグをFIX仕様合意書に記載してください。合意済みの仕様に照らして受信したカスタムタグを検証し、スキーマのドリフトを検出してください。

ドロップコピーセッション： ドロップコピー（FIXセッションの種類）は、主要な取引セッションに影響を与えることなく、すべてのExecutionReportのリアルタイムコピーをセカンダリコンシューマー（リスクシステム、コンプライアンス、ミドルオフィス）に提供します。OMSと並行してリアルタイムの取引監視や独立したポジション追跡を必要とする企業にとって、ドロップコピーは不可欠です。

FIX のパフォーマンスに関する考慮事項： 高頻度取引では、FIXメッセージの解析とシリアライズのレイテンシーが重要です。バイナリーFIXエンコーディング（SBE -- Simple Binary Encoding、FIX 5.0 FIXTで使用）は、テキストベースのFIXと比べて解析のオーバーヘッドを桁違いに削減します。一般的なバイサイドの注文ルーティング（1日あたり数百～数千件の注文）では、テキストベースのFIX 4.4で十分であり、デバッグもはるかに容易です。ログファイルは人間が読める形式です。 FIX によるアロケーションとポストトレード： FIX は、注文執行にとどまらず、ポストトレードのワークフローもサポートします。アロケーションメッセージ（MsgType=J、AllocationInstruction）は、ブロック取引を各口座にどのように分割するかを伝えます。AllocationReport（MsgType=AS）は、アロケーション処理を確認します。Confirmation（MsgType=AK）は、アロケーションごとの取引レベルの詳細を提供します。翌朝ではなく、執行から数時間以内にアロケーションを伝達する必要がある T+1 のもとで、こうしたポストトレードメッセージの重要性が高まっています。

3. ISO 20022 メッセージング

ISO 20022 は、決済、証券、貿易金融、外国為替において従来の形式に取って代わる、XML ベースの金融メッセージング標準です。SWIFT によるクロスボーダー決済の MT（Message Type）から ISO 20022 MX メッセージへの移行は、2025 年 11 月に完了しました。

メッセージ構造： ISO 20022 メッセージは、ビジネスドメインごとに構成された XML スキーマを使用します。各メッセージは、送信者、受信者、メッセージタイプ、作成日を含む Business Application Header（BAH）と、それに続くビジネス文書で構成されます。メッセージは、ドメインカテゴリ内の 4 文字のコードで識別されます。

ドメインカテゴリ： pain（決済開始）、pacs（決済の清算および決済）、camt（資金管理）、semt（証券管理 -- 明細、残高）、setr（証券取引 -- 注文、確認）、sese（証券決済 -- 指図、確認、ステータス）、secl（証券清算）、colr（担保管理）、reda（参照データ）。

主なメッセージタイプ：

メッセージ ID	名称	ユースケース
semt.002	保有証券の保管明細	保管機関からの日末ポジション報告
semt.017	証券取引明細	保管機関からの取引履歴
setr.004	解約注文	投資信託の解約指図
setr.010	購入注文	投資信託の購入指図
sese.023	証券決済取引指図	保管振替機関への受渡指図
sese.024	証券決済ステータス通知	決済ステータスの更新（照合済み、決済済み、失敗）
pacs.008	金融機関間の顧客信用送金	クロスボーダー決済指図
pacs.009	金融機関間の金融機関信用送金	銀行間送金
camt.053	銀行から顧客への明細書	現金口座明細書

SWIFT の移行状況（2026 年 6 月時点）： SWIFT は、2023 年 3 月からクロスボーダー決済で MT/MX の併存運用を実施し、2025 年 11 月 22 日に移行を完了しました。ISO 20022（CBPR+）は現在、金融機関間のクロスボーダー決済指図における唯一の標準です。ネットワークは、従来の MT 決済指図メッセージ（MT103、MT202 など）を拒否します。証券メッセージングの移行は別のより遅いスケジュールで進むため、MT 証券メッセージ（MT535、MT548）は引き続き使用されています。社内で MT ベースの処理を行う企業は、境界で変換する必要があります。より豊富な ISO 20022 形式から制約の多い MT フィールドに戻す変換では、情報が失われる可能性がある点に注意してください。

従来の形式との比較： MT メッセージは、フィールド長に制限がある固定フィールド構造を使用します（顧客送金は MT103、銀行送金は MT202、保管明細は MT535、決済ステータスは MT548）。ISO 20022 は、より豊富で構造化されたデータを提供します。たとえば、より長い参照フィールド、構造化された住所、LEI のサポート、目的コード、送金情報などです。証券向けの前身である ISO 15022 は、SWIFT MT に似たタグ付き形式を使用していました。ISO 20022 はその両方に取って代わります。

実装上の考慮事項： ISO 20022 メッセージは冗長で、同等の MT メッセージより 10～50 倍大きくなります。大量処理における XML の解析オーバーヘッドは無視できません。処理前に不正なメッセージを検出するには、スキーマ検証が不可欠です。多くの企業は、ISO 20022 を全体でネイティブに処理するのではなく、標準的な内部形式を実装し、統合境界で ISO 20022 との相互変換を行っています。

テストと認証： SWIFT では、ISO 20022 に移行する前に、参加者が準備状況の評価と認証テストを完了することを求めています。テストでは、メッセージ形式への準拠、フィールド設定ルール、文字セットの処理（ISO 20022 は MT 形式では使用できなかった拡張 UTF-8 文字をサポート）、エンドツーエンドの取引フロー検証を確認します。決済の併存運用が終了した（2025 年 11 月）ため、MT/MX の並行処理が現在必要なのは、証券メッセージングなど、従来の形式が引き続き使われているメッセージカテゴリのみです。

4. イベント駆動型アーキテクチャ

イベント駆動型アーキテクチャ（EDA）は、直接 API を呼び出すのではなくイベントを介して通信することで金融システムのコンポーネントを疎結合にし、取引の約定、決済状況の変更、コーポレートアクション、参照データの更新をリアルタイムに伝播できるようにします。

主なパターン： パブリッシュ・サブスクライブ（プロデューサーがトピックにイベントを発行し、コンシューマーがそれぞれ独立して購読）、イベントストリーミング（順序が保証された永続的なイベントログを、コンシューマーが各自のペースで読み取る）、イベントソーシング（変更可能なレコードとして保存するのではなく、連続したイベントログからシステムの状態を導出）。

金融イベントの種類： 取引イベント（注文の送信、注文の受領確認、一部約定、全量約定、取消、拒否）、決済イベント（指図の送信、照合、決済完了、失敗）、コーポレートアクションイベント（発表、選択期限、権利落ち日、支払日）、参照データイベント（新しい証券の作成、識別子の変更、価格の更新）、口座イベント（開設、取引制限、閉鎖）、コンプライアンスイベント（アラートの発生、アラートの解決）。

金融分野のメッセージブローカー：

ブローカー	強み	一般的な用途
Apache Kafka	高スループット、順序が保証されたログ、再生、パーティショニング	取引イベントのストリーミング、監査証跡、ポジションの更新
Solace	金融グレードのメッセージング、マルチプロトコル（JMS、AMQP、MQTT、REST）	市場データの配信、リージョン間のメッセージング
RabbitMQ	柔軟なルーティング、AMQP 0-9-1、シンプルな運用	タスクキューイング、リクエスト・リプライ、例外処理
TIBCO EMS/FTL	エンタープライズミドルウェア、レガシーシステムとの統合	資本市場、メインフレーム接続
IBM MQ	トランザクション対応、厳密に1回の配信、銀行グレードの信頼性	銀行決済、高額取引のメッセージング

選定は、スループット要件、順序保証、既存のインフラストラクチャ、運用の専門知識によって異なります。資本市場や資産運用の新規構築では Kafka が主流ですが、銀行や清算機関では IBM MQ と TIBCO が依然として深く定着しています。

監査証跡のためのイベントソーシング： 金融規制では、完全かつ不変の監査証跡が求められます。イベントソーシングでは、すべての状態変更がタイムスタンプ、実行者、ペイロードを含むイベントとして追記されるため、こうした監査証跡が自然に生成されます。任意の時点における口座、ポジション、注文の状態を再構築するには、その時点までのイベントを再生します。これは帳簿・記録の保存要件（SEC Rule 17a-4、FINRA Rule 4511）に適合します。

金融システムの CQRS： コマンドクエリ責務分離では、書き込み操作（取引の記帳、決済指図）と読み取り操作（ポジションクエリ、レポート作成）を分離します。金融システムは読み取り中心であり、取引を書き込むユーザー1人に対して、レポートを利用するユーザーが数百人いることも珍しくありません。CQRS を使うと、厳格で監査可能な書き込み経路を維持しながら、読み取りモデル（マテリアライズドビュー、特定のクエリパターン向けに非正規化されたデータ）を独立して最適化できます。

イベントスキーマの設計と進化： 金融イベントでは、慎重なスキーマ設計が必要です。メタデータ（イベント ID、タイムスタンプ、ソースシステム、相関 ID、スキーマバージョン）とビジネスペイロード（取引の詳細、決済状況、口座属性）を含めます。スキーマの進化では後方互換性を維持する必要があります。新しいコンシューマーは古いイベントを処理でき、古いコンシューマーは新しいフィールドを許容できなければなりません。スキーマレジストリ（Confluent Schema Registry、AWS Glue）を使用して、発行時に互換性をチェックします。互換性を破るスキーマ変更では、新しいトピックまたはバージョン管理されたイベントタイプを使用し、移行中は並行して消費します。

順序保証： 金融イベントの順序は重要です。対応する注文の受領確認イベントより先に約定イベントを処理すると、状態が破損します。Kafka はパーティション内の順序を保証します。最も重要な順序に関わるキー（ポジション更新には口座 ID、注文のライフサイクルには注文 ID）でパーティショニングします。パーティションをまたいだ順序の保証には、アプリケーションレベルでのシーケンス管理（タイムスタンプ、シーケンス番号）と、順序が入れ替わって届いたイベントへの対応が必要です。 コンシューマーの障害と復旧： Kafka コンシューマーに障害が発生して再起動すると、最後にコミットしたオフセットから処理を再開します。メッセージを処理した後、オフセットをコミットする前にクラッシュした場合、再起動後にそのメッセージを再処理するため、冪等な処理が必要です。金融関連のコンシューマーでは、標準的なパターンは次のとおりです。（1）メッセージを処理する、（2）結果とメッセージのオフセットを単一のトランザクションでデータベースに書き込む、（3）Kafka のオフセットをコミットする。ステップ 3 が失敗した場合、メッセージは再処理されますが、データベースのトランザクションが保存済みのオフセットを使って重複を検出し、再処理をスキップします。

5. バッチ処理パターン

リアルタイム処理への移行が進む中でも、バッチファイルの交換は、アドバイザリー会社とカストディアン、ファンド管理会社、名義書換代理人、データベンダーとの間で、依然として主流の統合パターンです。

一般的なバッチファイルの種類： ポジションファイル（口座ごとの日次終値時点の保有資産）、取引ファイル（売買、収益、手数料、コーポレートアクション）、現金残高ファイル、パフォーマンスリターンファイル、請求ファイル、照合ファイル、参照データファイル（証券マスタの更新、価格）、税務ロットファイル。

ファイルの種類	一般的な頻度	通常の配信時間帯	重要な締め切り
ポジションファイル	毎日	東部標準時 午前1:00～4:00	朝のポートフォリオレビュー前
取引ファイル	毎日	東部標準時 午前1:00～4:00	照合処理の実行前
現金残高ファイル	毎日	東部標準時 午前2:00～5:00	現金管理の前
価格ファイル	毎日	東部標準時 午後6:00～8:00（前日の夕方）	夜間評価の前
税務ロットファイル	毎日または毎週	東部標準時 午前2:00～6:00	税務報告の前
照合ファイル	毎日	東部標準時 午前3:00～6:00	オペレーションレビューの前
コーポレートアクションファイル	イベント発生時＋毎日	不定	権利落ち日の処理前

ファイル形式： CSV（カストディアンのフィードで最も一般的。列の順序はカストディアンごとに異なります）、固定長形式（一部のカストディアンや清算会社が現在も使用しているレガシー形式。列位置は仕様で定義されています）、XML（より豊富なデータに対応するため利用が増加しており、証券分野では ISO 20022 に準拠）、JSON（最新の API ベースのファイル配信で普及しつつあります）、独自形式（専用のパーサーが必要なベンダー固有の形式）。

ファイル配信の仕組み： SFTP（主流。スケジュールに基づくプッシュまたはプル）、S3／クラウドストレージ（カストディアンのフィードでの採用が増加）、API ベースのファイルダウンロード（REST 経由で新しいファイルをポーリング）、MQ／メッセージベース（ファイル通知をトリガーに取得）、暗号化された添付ファイル付きメール（レガシー方式で、利用は減少傾向）。すべてのファイル転送で、通信中の暗号化を使用する必要があります（SFTP では標準で提供され、S3 では HTTPS が必要です。TLS を使用しない FTP は、金融データでは決して許容されません）。ファイル内容を PGP／GPG で暗号化すると、さらに保護を強化できます。これにより、転送経路が侵害された場合や、ファイルが中間ステージング領域に保存された場合でも、機密性を確保できます。

処理パイプラインの段階： （1）ファイル監視 — ファイルの到着を検出し、締め切りまでに予定されたファイルを受信したことを確認する、（2）ファイル検証 — チェックサムの検証、末尾レコードに対するレコード数の検証、スキーマ検証、文字エンコーディングの確認、（3）解析 — レコードを構造化形式に抽出し、ソースごとの形式の違いに対応する、（4）ビジネス検証 — 参照整合性（口座や証券の存在）、値の範囲チェック、フィールド間の整合性、（5）変換 — 標準形式へのマッピング、識別子の変換、参照データによる拡充、（6）ロード — 対象システムへの挿入／更新と重複への対応、（7）照合 — ロードしたデータをソースの件数および管理合計と比較する。

シーケンス番号と冪等なロード： カストディアンのファイルには、シーケンス番号またはファイル日付が含まれています。ソースごとに最後に処理したシーケンスを追跡し、欠落（ファイルの未着）と重複（ファイルの再処理）を検出します。ロード処理は冪等になるように設計し、同じファイルを再処理しても、二重計上せずに同じ結果が得られるようにします。 バッチ処理とリアルタイム処理のトレードオフ： バッチ処理はシンプルで、自然なチェックポイントを設けられ、EOD の照合サイクルにも適合します。リアルタイム処理は即時性を実現できますが、複雑さ（状態管理、エラー復旧、順序保証）が増します。ほとんどの企業はハイブリッド方式を採用しています。注文フローと取引執行にはリアルタイム処理を、EOD のポジション、照合、レポート作成にはバッチ処理を使用します。

ファイルの遅延と欠落への対応： ソースごとにファイル到着の SLA を定め、エスカレーション手順を設けます。ファイル到着履歴を追跡して通常の配信時間帯を把握し、異常を検出します。ファイルが遅延した場合、パイプラインでは、待機する（下流の処理がすべて遅延する）、ファイルなしで処理を進める（データが不完全になるリスクがある）、または前日のデータを古いデータであることを示すフラグ付きで使用する、という判断が必要です。選択はファイルの重要度によって異なります。ポジションファイルが欠落するとポートフォリオのレポート作成ができませんが、請求ファイルは翌日に処理できます。

ファイルの再配信と訂正： カストディアンや取引相手は、訂正版のファイルを再配信することがあります。パイプラインでは再処理に対応する必要があります。再配信されたファイル（同じ日付でシーケンス番号またはタイムスタンプが更新されているもの）を検出し、元のロードを取り消して、訂正データを適用します。そのためには、元のロードを取り消せる必要があります。方法としては、バージョン追跡を伴う論理削除、またはファイルの日付とソースをキーとした完全置換があります。

6. 冪等性とExactly-Onceセマンティクス

金融取引では、Exactly-Onceでの処理が求められます。注文送信の重複、決済指図の再送、配当の二重計上は、検出と修正に多大なコストがかかる、実際の金銭的な誤りにつながります。

冪等性が重要な理由： ネットワークは不安定です。TCP接続が切断され、HTTPリクエストがタイムアウトし、メッセージブローカーがメッセージを再配信することがあります。呼び出し元は、「リクエストが失敗した」のか「リクエストは成功したが、応答が失われた」のかを区別できない場合がよくあります。冪等性がなければ、タイムアウトした注文送信を再試行することで、注文が重複する可能性があります。

冪等性キーの設計： クライアントは、論理操作ごとに一意のキー（UUID、または口座＋証券＋売買区分＋数量＋タイムスタンプなどの決定論的な複合キー）を生成します。サーバーは結果とともにキーを保存します。重複するキーを受信すると、サーバーは再実行せずに保存済みの結果を返します。保存量を制限するため、キーには定義済みのTTL（数時間から数日）が必要です。金融操作では、ランダムなUUIDよりも、業務属性（注文ID、取引参照番号、決済指図ID）を含む複合キーが推奨されます。異なるクライアントインスタンスからの再試行でも重複排除できるためです。

重複検出のパターン：

1. サーバー側の冪等性テーブル（キー、結果、有効期限）を処理前に確認する方法。REST APIで最も一般的なパターンです。
2. データベースの一意制約で業務キーに基づく重複挿入を防ぐ方法。データベースを利用する操作では、シンプルで信頼性があります。
3. メッセージブローカーによる重複排除（冪等なプロデューサーとトランザクション対応コンシューマーによるKafkaのExactly-Onceセマンティクス）。ブローカーからコンシューマーまでの経路に対応します。
4. 複数のシステムにまたがる操作で分散ロックを使う方法。処理は重くなりますが、単一の操作で複数のデータストアに書き込む場合には必要です。
5. コンテンツベースの重複排除（メッセージペイロードのハッシュ）。ソースから冪等性キーを取得できない場合の二次的な確認として役立ちます。

At-Least-Once配信と冪等な処理： 金融システムにおける実用的なパターンです。メッセージブローカーはAt-Least-Once配信を保証します（障害や再試行時に、メッセージが複数回配信されることがあります）。コンシューマーは、同じメッセージを2回処理しても追加の影響が生じないよう、冪等に設計します。これにより、真の分散Exactly-Onceプロトコルの複雑さや性能コストを伴わずに、実質的なExactly-Onceセマンティクスを実現できます。

再生の安全性： 冪等なシステムでは、復旧、移行、照合のためにイベントストリームを安全に再生できます。運用チームは、二重計上を心配することなく、照合のために1日分の取引を再処理できます。これは、金融監査や例外処理に不可欠です。

システム境界をまたぐ冪等性： 統合が複数のシステムにまたがる場合（例：ブローカーへの取引送信と内部での記帳）、冪等性キーは両方のシステムで一貫していなければなりません。ブローカーが取引を受け付けたものの、内部の記帳がタイムアウトした場合、再試行では、ブローカーへの再照会（「注文はすでに約定しましたか？」）と内部の記帳試行の両方で同じキーを使う必要があります。冪等性キーは個々のAPI呼び出しではなく、業務操作のレベルで設計してください。

7. エラー処理とレジリエンス

金融システム連携では、下流への影響が深刻なため、障害を適切に処理する必要があります。決済指図の見落としはフェイルを引き起こし、取引確認の消失は照合不一致を生み、コーポレートアクション通知の喪失は誤った処理につながります。

再試行戦略： 一時的なエラー（ネットワークタイムアウト、HTTP 503）には即時再試行を行います。長時間利用できない場合は、ジッターを加えた指数バックオフ（基本遅延 * 2^試行回数 + ランダムなジッター）を使います。再試行回数と合計時間に上限を設けます。エラーを再試行可能（タイムアウト、429、503、接続リセット）と再試行不可能（400、401、403、422）に分類します。冪等性キーのない非冪等操作は、決して再試行しないでください。 サーキットブレーカーパターン： アップストリームシステムが停止した際の連鎖的な障害を防ぎます。動作は次の3つの状態によって制御されます。

• Closed（通常）： リクエストはアップストリームシステムに渡されます。障害はカウントされます。
• Open（トリップ状態）： アップストリームシステムには接続せず、すべてのリクエストを即座に失敗させます。これにより、呼び出し元（無駄なタイムアウト待ちが発生しない）とアップストリーム（復旧中に追加の負荷がかからない）の両方を保護します。
• Half-open（テスト中）： 設定可能なタイムアウトの経過後、アップストリームが復旧したかを確認するため、限られた数のリクエストを通します。

状態遷移のしきい値：N回連続で失敗するか、一定期間内のエラー率がX％を超えるとOpenに移行します。設定可能なクールダウン期間の経過後にHalf-openに移行し、Half-open状態でN回連続して成功するとClosedに戻ります。金融システムでは、サーキットブレーカーによって、カストディアンへの接続障害から取引プラットフォームを保護し、劣化したクリアリングインターフェースに決済システムが過剰な負荷をかけるのを防ぎます。サーキットブレーカーが作動した場合、連携機能には、メッセージを後で配信するためにキューに追加する、キャッシュデータを提供する、または手動対応のために運用担当者へアラートを送るなど、明確に定義されたフォールバック動作が必要です。

デッドレターキュー（DLQ）： すべての再試行後も処理に失敗したメッセージは破棄せず、DLQに振り分けます。DLQには、失敗に関するメタデータ（エラーの理由、試行回数、タイムスタンプ）とともにメッセージが保持されます。運用担当者はDLQの項目を確認して原因を診断し、再処理するか、手動で解決します。DLQは金融業務において非常に重要です。決済指図が破棄されることは、遅延することよりはるかに深刻です。運用上の主要な指標として、DLQの深さを監視してください。

補償トランザクション： 複数ステップのプロセスが途中まで完了した後、後続のステップで失敗した場合、補償トランザクションによって先行するステップを取り消します。例：注文がブローカーに送られて承認されたものの、社内の記帳に失敗した場合、補償トランザクションによってブローカーの注文をキャンセルします。複数システムにまたがるワークフローの各ステップについて、補償アクションを設計してください。データベースのロールバックとは異なり、補償トランザクションは新たに実行する前向きのアクション（キャンセル、取消、クレジット）であり、それ自体が失敗する可能性もあるため、監視と手動対応が必要です。

タイムアウト管理： すべての連携境界でタイムアウトを設定します。接続タイムアウト（秒）、読み取りタイムアウト（処理に応じて数秒から数分）、複数ステップのワークフローに対するエンドツーエンドのタイムアウトを設定してください。金融システムでは、タイムアウト値に市場取引時間中の負荷、1日の終わりの処理ピーク、カストディアンのバッチ処理時間帯を考慮する必要があります。

部分的な失敗の処理： 複数レコードを処理する操作（注文の一括送信、ポジションの一括更新）では、一部のみ成功した場合も適切に処理する必要があります。100件中95件が成功し、5件が失敗した場合、どのレコードが成功し、どのレコードが失敗してその理由は何か、また5件の失敗を個別に再試行できるかをシステムが報告しなければなりません。バッチ処理の失敗を黙って破棄しないでください。レコードごとの詳細な結果一覧を返してください。金融業務では、明示的なレコードごとの確認がなければ、バッチ応答にレコードがないことは、取引が失われたことと区別できません。

監視とアラート： 連携機能の健全性に関する指標を追跡します。メッセージ処理量（チャネルごとの1秒あたりのメッセージ数）、エラー率（失敗したメッセージの割合）、レイテンシ（ソースイベントからターゲットシステムの更新までのエンドツーエンドの時間）、キューの深さ（コンシューマーごとのバックログサイズ）、DLQの深さ（未解決の失敗件数）を監視してください。重大度を段階的に設定してアラートを構成します。警告（エラー率の上昇）、重大（連携機能の停止またはDLQのしきい値超過）、緊急（データ損失のリスク）です。連携機能の健全性をダッシュボードで確認できることは、連携機能そのものと同じくらい重要です。

8. データ変換とマッピング

金融システムの統合では、異なるスキーマ、識別子体系、コードセット、規約の間でデータを変換する必要が常にあります。

フィールドマッピング： ソースからターゲットへのマッピング文書では、ソースシステムの各フィールドがターゲットにどのように対応するかを定義します。金融分野のフィールドマッピングは単純でないことがよくあります。1つのソースフィールドが複数のターゲットフィールドに対応する場合（氏名をまとめたフィールドを姓と名に分割するなど）、複数のソースフィールドを1つのターゲットフィールドに結合する場合、参照検索や導出が必要なフィールドもあります。マッピング仕様はバージョン管理された成果物として維持してください。これは統合の契約です。

識別子の変換： 同じ証券が、あるシステムではCUSIP、別のシステムではISIN、さらに別のシステムでは独自IDで識別されることがあります。統合レイヤーでは、識別子を変換するためにクロスリファレンステーブル（証券マスターを情報源とする）を維持します。N対Nのマッピングの複雑さを避けるため、外部識別子同士を直接変換せず、必ず正規の内部IDを介して変換してください。

通貨とコードの正規化： 通貨コードはISO 4217（USD、EUR、GBP）に統一します。国コードはISO 3166（US、GB、DE）に統一します。取引タイプコードはシステムごとに大きく異なるため、正規のコードセットにマッピングし、ソースごとの変換テーブルを維持してください。日付形式（YYYYMMDD、MM/DD/YYYY、ISO 8601）は、パイプラインの早い段階で正規化する必要があります。

参照データによるエンリッチメント： 受信データには、ターゲットシステムが必要とするフィールドが含まれていないことがよくあります。変換時に、証券マスター（資産クラス、セクター、発行体）、クライアントマスター（世帯、アドバイザー）、口座マスター（登録種別、税務上のステータス）を参照してデータをエンリッチします。エンリッチメントによって、参照データの可用性に対する実行時の依存関係が生じます。参照データが一時的に利用できない場合に適切に縮退できるよう設計してください（バッチ全体を失敗させるのではなく、レコードをリトライ用にキューに入れます）。

マッピングされていない値の処理： 統合パイプラインでは、変換テーブルにマッピングがないソース値（新しいカストディアン取引コード、認識されない証券種別、別形式の国コードなど）に必ず遭遇します。パイプラインでこうした値を黙って破棄したり、デフォルト値を設定したりしてはいけません。マッピングされていないレコードは例外キューに送り、データスチュワードの確認用に未マッピング値をログに記録し、解決後に新しいマッピングを変換テーブルに追加します。データ品質指標として、ソースごとの未マッピング値の発生頻度を追跡してください。急増は、マッピングテーブルの更新を必要とするソースシステムの変更を示しています。

正規データモデル： 主要なエンティティ（取引、ポジション、口座、証券、クライアント）の全社共通の正規表現を定義します。すべての統合では、境界でソースデータを正規モデルに変換し、反対側の境界でターゲット固有の形式に変換します。これにより統合の複雑さをN対NからN対1対Nに抑え、新しいシステムやデータソースの追加が大幅に簡素化されます。

データ型の変換： 金融データ型の変換には慎重さが必要です。小数精度は重要です。丸め誤差を避けるため、金額には浮動小数点数ではなく固定小数点の十進数を使用してください。数量フィールドは、投資信託では小数値、株式では整数になる場合があります。日付／時刻フィールドにはタイムゾーン情報が必要です（タイムゾーンのない取引タイムスタンプは、国際的な業務では曖昧になります）。ブール値フィールドの表現（Y/N、true/false、1/0、T/F）はさまざまなため、境界で正規化する必要があります。

9. インテグレーションのセキュリティとコンプライアンス

金融インテグレーション基盤は、機密データ（PII、口座番号、ポジション、取引）を扱うため、データ保護、監査可能性、アクセス制御に関する規制要件の対象となります。

通信のセキュリティ： 転送中のすべてのデータに TLS 1.2 または 1.3 を使用します。カストディアン、清算機関、取引相手との接続には相互 TLS（mTLS）を使用します。両者が証明書を提示することで、強固な双方向認証を実現します。証明書の管理（発行、ローテーション、失効、期限の監視）は重要な運用機能です。証明書の期限切れは、インテグレーション停止の主な原因です。

保存データの暗号化： 保存するすべてのインテグレーションデータ（メッセージストア、ファイルのステージング領域、DLQ、監査ログ）を AES-256 または同等の方式で暗号化します。キー管理には HSM またはクラウド KMS を使用します。暗号化は本番環境と非本番環境の両方に適用します。本番データから派生したテストデータには、明示的に匿名化しない限り、実際の PII や口座データが含まれます。

PII の取り扱い： インテグレーションのペイロードには、SSN/TIN、生年月日、口座番号、金融情報が頻繁に含まれます。転送する PII は最小限に抑え、受信側システムが必要とする情報のみを送信します。ログや監視ダッシュボードでは、機密フィールドをマスキングまたはトークン化します。インテグレーションチャネルにはデータ分類ラベル（公開、社内、機密、制限付き）を適用し、それに応じて管理策を実施します。

監査ログ： すべてのインテグレーションイベントを記録します。メッセージの送信、受信、変換の適用、検証の成功／失敗、エラーの発生、再試行、手動対応を記録します。タイムスタンプ、ソースシステム、ターゲットシステム、メッセージ識別子、相関 ID、結果を含めます。企業の帳簿・記録に関するポリシーに従ってログを保持します（通常、SEC Rule 17a-4 に基づきブローカーディーラーは 6～7 年、SEC Rule 204-2 に基づき投資顧問会社は 5 年）。監査ログは変更できないものにする必要があります。書き込み後変更不可のストレージ、または追記専用システムを使用します。

相関 ID と分散トレーシング： 1 つの業務処理（たとえば、注文入力から決済までの顧客取引の処理）が 5～10 のシステムを経由することがあります。発生元で生成し、すべてのシステムに伝播させる相関 ID により、取引の経路、所要時間、結果をエンドツーエンドで追跡できます。相関 ID がなければ、決済の失敗を調査する際に、独立した各システムのログでタイムスタンプを手作業で照合する必要があり、数分ではなく数時間かかることがあります。HTTP ヘッダー、FIX のカスタムタグ、メッセージメタデータ、ファイルのレコードフィールドなど、すべてのインテグレーションチャネルで相関 ID を伝播させることを必須標準として実装します。

SOC 2 管理策： インテグレーション基盤は SOC 2 Type II 監査の対象範囲に含まれます。関連する管理策には、アクセス管理（インテグレーションの設定、変更のデプロイ、本番データへのアクセスが可能なユーザー）、変更管理（インテグレーションの変更は企業の SDLC に従い、テストと承認を経ること）、可用性（監視、アラート、フェイルオーバー）、機密性（暗号化、アクセスログ、データ分類）があります。サードパーティのインテグレーションベンダー（iPaaS、ミドルウェア）には、自社の SOC 2 レポートの提出を求める必要があります。

非本番環境のセキュリティ： インテグレーションのテスト環境では、現実的なテストを行うため、本番データから派生したデータを頻繁に使用します。このデータには実際の PII や金融情報が含まれます。非本番環境では、完全に匿名化したデータまたは合成データを使用するか、本番環境と同じアクセス制御と暗号化を実装する必要があります。規制当局や監査人は、検査時に非本番環境でのデータの取り扱いを重点的に確認します。

実例

エンドツーエンドの設計シナリオ 3 件（複数カストディアンを利用する RIA のインテグレーションアーキテクチャ、Kafka を使ったイベント駆動型の取引通知、回復性のある EOD 決済バッチパイプライン）は、references/examples.md にあります。具体的なインテグレーションを設計するときや、ユーザーがアーキテクチャの設計例を求めたときは、このファイルを読み込んでください。

よくある落とし穴

• 金融取引 API に冪等性がありません。 タイムアウトした注文送信や決済指示を冪等性キーなしで再試行すると、重複が発生し、実際の金銭的な誤りにつながります。
• バッチファイル処理を単純なファイル読み込みとして扱っています。 チェックサムの検証、レコード数の確認、シーケンス番号の追跡を省略すると、破損、途中で切り詰められたファイル、または重複したファイルによって、記録原簿が気付かないうちに破損する可能性があります。
• すべてのシステム間をポイントツーポイントで統合しています。 N 個のシステムを直接接続すると、N*(N-1)/2 個の統合が必要になります。標準データモデルと中央統合レイヤーを用いれば、接続数を N 個に削減できます。
• FIX シーケンス番号の管理を無視しています。 FIX セッションの復旧は、シーケンス番号が正しく保持されていることを前提とします。相手方と調整せずにシーケンス番号をリセットすると、メッセージの損失や重複処理が発生します。
• 時間に敏感なデータに対して、イベント駆動型ではなくポーリングを使用しています。 ポーリングでは平均してポーリング間隔の半分に相当する遅延が発生し、結果のないポーリングでリソースを浪費し、ポーリング間の空白時間に発生したイベントを見逃します。
• 失敗したメッセージ用のデッドレターキューがありません。 処理に失敗したメッセージを DLQ に送らず破棄すると、気付かないうちにデータが失われます。金融業務では、決済指示の遅延よりも、その指示の欠落のほうがはるかに深刻です。
• 統合ロジックで識別子の種類をハードコードしています。 すべての証券に CUSIP がある、または CUSIP は決して変更されないと想定すると、国際証券やコーポレートアクションの際に問題が発生します。必ず証券マスターを介して変換してください。
• タイムアウト設定が不十分です。 デフォルトの HTTP タイムアウト（30 秒、60 秒）は、金融業務には適さないことがよくあります。大量のポジション照会には数分かかることが正当な場合がある一方、注文送信はすぐに失敗させるべきです。
• mTLS 接続の証明書有効期限の監視を怠っています。 証明書の有効期限が切れると、統合は直ちに完全に停止します。30 日前、14 日前、7 日前の事前アラートを含む自動監視が不可欠です。
• スキーマ検証なしで ISO 20022 メッセージを処理しています。 基本的な解析は通るものの ISO 20022 スキーマに違反する不正な XML は、後続処理で気付きにくいデータ破損を引き起こす可能性があります。
• 複数ステップのワークフローに対する補償トランザクションの設計がありません。 5 ステップの処理でステップ 3 が失敗した場合、システムはステップ 1 と 2 を元に戻す必要があります。事前に補償トランザクションを設計していなければ、手動介入しか復旧方法がありません。
• 統合のデバッグログに PII を記録しています。 SSN、口座番号、金融データがアプリケーションログに含まれると、データ保護要件に違反し、検査時に規制上のリスクが生じます。

相互参照

• reference-data（data-integration プラグイン） -- 参照データは、統合によって配信されるデータの基盤です。証券マスター、顧客マスター、口座マスターが、統合ペイロードに含まれる識別子と属性を提供します。
• market-data（data-integration プラグイン） -- マーケットデータフィードは主要な統合領域です。リアルタイムデータや遅延データの配信には、ここで説明するものと同様のパターン（パブリッシュ／サブスクライブ、ファンアウト、コンフレーション）が数多く使われます。
• data-quality（data-integration プラグイン） -- 統合の失敗は、データ品質問題の主な原因です。統合境界における検証、監視、例外処理が、第一の防御線となります。
• settlement-clearing（trading-operations プラグイン） -- 決済は、清算会社、カストディアン、預託機関間のシステム間メッセージングに依存します。決済指図の送信には、FIX、ISO 20022、バッチファイルのパターンが使われます。
• exchange-connectivity（trading-operations プラグイン） -- 取引所接続では、注文ルーティングとマーケットデータにFIXプロトコルを使用します。このスキルではプロトコルレベルでFIXを扱い、exchange-connectivityでは運用面および規制面のコンテキストを扱います。
• order-lifecycle（trading-operations プラグイン） -- システム間（OMSからブローカー、取引所まで）の注文フローには、シーケンス管理、確認応答、エラー処理を備えた信頼性の高い統合が必要です。
• stp-automation（client-operations プラグイン） -- STPは適切に設計された統合に依存します。STP率は、上流の統合フィードの信頼性とデータ品質によって直接制約されます。
• portfolio-management-systems（advisory-practice プラグイン） -- PMSは、多くの統合（カストディアンの保有残高、マーケットデータ、参照データ、取引確認）からデータを取り込むハブであり、堅牢な統合アーキテクチャから最も大きな恩恵を受けます。
• books-and-records（compliance プラグイン） -- 統合の監査証跡（メッセージログ、ファイル処理記録、変換履歴）は、保存要件および検査要件の対象となる規制記録です。