概要
- Mermaidは、テキストベースで図表を生成するマークアップ言語です。
- GitHub、GitLab、多くのMarkdownエディタでサポートされています。
- 以下のように様々なチャートを書くことができます。
カレーの作り方
graph TD
A[材料を用意する] --> B[玉ねぎ・人参・じゃがいもを切る]
B --> C[油で玉ねぎを炒める]
C --> D[人参とじゃがいもを加える]
D --> E[水を注ぎ煮込む]
E --> F[野菜が柔らかくなったら...]
F --> G[カレールーを加える]
G --> H[弱火で10分程度煮詰める]
H --> I[完成！]
基本的な構文
1. フローチャート（Flowchart）
基本的なフローチャート
graph TD
A[開始] --> B{条件判定}
B -->|Yes| C[処理1]
B -->|No| D[処理2]
C --> E[終了]
D --> E
graph TD
A[開始] --> B{条件判定}
B -->|Yes| C[処理1]
B -->|No| D[処理2]
C --> E[終了]
D --> E
記法の説明:
graph TD: 上から下（Top Down）のフローチャートgraph LR: 左から右（Left Right）のフローチャート[ ]: 四角形（処理）{ }: ひし形（条件判定）( ): 角丸四角形-->: 矢印（接続）-->|ラベル|: ラベル付き矢印
サブグラフ（グループ化）
graph TB
subgraph "フロントエンド"
A[Webアプリ]
B[モバイルアプリ]
end
subgraph "バックエンド"
C[API]
D[データベース]
end
A --> C
B --> C
C --> D
graph TB
subgraph "フロントエンド"
A[Webアプリ]
B[モバイルアプリ]
end
subgraph "バックエンド"
C[API]
D[データベース]
end
A --> C
B --> C
C --> D
2. シーケンス図（Sequence Diagram）
sequenceDiagram
participant U as ユーザー
participant W as Webアプリ
participant A as API
participant D as データベース
U->>W: リクエスト送信
W->>A: API呼び出し
A->>D: データ取得
D-->>A: データ返却
A-->>W: レスポンス
W-->>U: 結果表示
sequenceDiagram
participant U as ユーザー
participant W as Webアプリ
participant A as API
participant D as データベース
U->>W: リクエスト送信
W->>A: API呼び出し
A->>D: データ取得
D-->>A: データ返却
A-->>W: レスポンス
W-->>U: 結果表示
記法の説明:
participant: 参加者（アクター）の定義->>: 実線矢印（同期通信）-->>: 点線矢印（非同期/返却）->: 破線矢印（非同期）
3. ER図（Entity Relationship Diagram）
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
PRODUCT ||--o{ LINE-ITEM : "ordered in"
CUSTOMER {
string customer_id PK
string name
string email
}
ORDER {
string order_id PK
string customer_id FK
datetime order_date
}
PRODUCT {
string product_id PK
string name
decimal price
}
LINE-ITEM {
string line_item_id PK
string order_id FK
string product_id FK
int quantity
}
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
PRODUCT ||--o{ LINE-ITEM : "ordered in"
CUSTOMER {
string customer_id PK
string name
string email
}
ORDER {
string order_id PK
string customer_id FK
datetime order_date
}
PRODUCT {
string product_id PK
string name
decimal price
}
LINE-ITEM {
string line_item_id PK
string order_id FK
string product_id FK
int quantity
}
記法の説明:
||--o{: 1対多（One to Many）||--||: 1対1（One to One）}o--o{: 多対多（Many to Many）PK: Primary Key（主キー）FK: Foreign Key（外部キー）
4. ガントチャート（Gantt Chart）
gantt
title プロジェクトスケジュール
dateFormat YYYY-MM-DD
section 設計
要件定義 :a1, 2025-01-01, 30d
基本設計 :a2, after a1, 20d
詳細設計 :a3, after a2, 15d
section 開発
フロントエンド開発 :b1, after a3, 40d
バックエンド開発 :b2, after a3, 45d
section テスト
単体テスト :c1, after b1, 20d
結合テスト :c2, after c1, 15d
gantt
title プロジェクトスケジュール
dateFormat YYYY-MM-DD
section 設計
要件定義 :a1, 2025-01-01, 30d
基本設計 :a2, after a1, 20d
詳細設計 :a3, after a2, 15d
section 開発
フロントエンド開発 :b1, after a3, 40d
バックエンド開発 :b2, after a3, 45d
section テスト
単体テスト :c1, after b1, 20d
結合テスト :c2, after c1, 15d
5. タイムライン（Timeline）
timeline
title システムの歴史
1980年代 : メインフレーム導入
: COBOL/CICS
1990年代 : 3社合併
: 中間DB導入
2000年代 : Webアプリ開始
: REST API導入
2020年代 : クラウド移行
: マイクロサービス化
timeline
title システムの歴史
1980年代 : メインフレーム導入
: COBOL/CICS
1990年代 : 3社合併
: 中間DB導入
2000年代 : Webアプリ開始
: REST API導入
2020年代 : クラウド移行
: マイクロサービス化
6. クラス図（Class Diagram）
classDiagram
class Customer {
+string customer_id
+string name
+string email
+createOrder()
+updateProfile()
}
class Order {
+string order_id
+datetime order_date
+calculateTotal()
+cancel()
}
class Product {
+string product_id
+string name
+decimal price
+updatePrice()
}
Customer "1" --> "*" Order
Order "*" --> "*" Product
classDiagram
class Customer {
+string customer_id
+string name
+string email
+createOrder()
+updateProfile()
}
class Order {
+string order_id
+datetime order_date
+calculateTotal()
+cancel()
}
class Product {
+string product_id
+string name
+decimal price
+updatePrice()
}
Customer "1" --> "*" Order
Order "*" --> "*" Product
7. ステート図（State Diagram）
stateDiagram-v2
[*] --> 未登録
未登録 --> 登録中: 登録開始
登録中 --> 審査中: 情報入力完了
審査中 --> 承認: 審査OK
審査中 --> 却下: 審査NG
承認 --> アクティブ: 初回ログイン
アクティブ --> 停止: 規約違反
停止 --> [*]
却下 --> [*]
stateDiagram-v2
[*] --> 未登録
未登録 --> 登録中: 登録開始
登録中 --> 審査中: 情報入力完了
審査中 --> 承認: 審査OK
審査中 --> 却下: 審査NG
承認 --> アクティブ: 初回ログイン
アクティブ --> 停止: 規約違反
停止 --> [*]
却下 --> [*]
8. パイチャート（Pie Chart）
pie title システム構成の技術スタック
"レガシー（COBOL/CICS）" : 40
"モダン（Python/Node.js）" : 35
"中間層（Java/Spring）" : 15
"その他" : 10
pie title システム構成の技術スタック
"レガシー（COBOL/CICS）" : 40
"モダン（Python/Node.js）" : 35
"中間層（Java/Spring）" : 15
"その他" : 10
スタイリング
ノードの色付け
graph TD
A[通常] --> B[警告]
B --> C[成功]
C --> D[エラー]
style A fill:#e1f5ff
style B fill:#fff4e1
style C fill:#e1ffe1
style D fill:#ffe1e1
graph TD
A[通常] --> B[警告]
B --> C[成功]
C --> D[エラー]
style A fill:#e1f5ff
style B fill:#fff4e1
style C fill:#e1ffe1
style D fill:#ffe1e1
クラス別のスタイル
graph TB
subgraph "レガシー層"
A[メインフレーム]
B[COBOL]
end
subgraph "モダン層"
C[API]
D[Webアプリ]
end
style A fill:#ff6b6b
style B fill:#ff6b6b
style C fill:#51cf66
style D fill:#51cf66
graph TB
subgraph "レガシー層"
A[メインフレーム]
B[COBOL]
end
subgraph "モダン層"
C[API]
D[Webアプリ]
end
style A fill:#ff6b6b
style B fill:#ff6b6b
style C fill:#51cf66
style D fill:#51cf66
実践的な例
複雑なシステム構成図
graph TB
subgraph "ユーザー層"
WEB[Webアプリ]
MOBILE[モバイルアプリ]
end
subgraph "API層"
GATEWAY[API Gateway]
AUTH[認証サービス]
end
subgraph "アプリケーション層"
APP1[アプリ1]
APP2[アプリ2]
end
subgraph "データ層"
DB1[(データベース1)]
DB2[(データベース2)]
end
WEB --> GATEWAY
MOBILE --> GATEWAY
GATEWAY --> AUTH
GATEWAY --> APP1
GATEWAY --> APP2
APP1 --> DB1
APP2 --> DB2
style WEB fill:#4dabf7
style MOBILE fill:#4dabf7
style GATEWAY fill:#ffd43b
style AUTH fill:#ffd43b
style APP1 fill:#51cf66
style APP2 fill:#51cf66
style DB1 fill:#ff6b6b
style DB2 fill:#ff6b6b
graph TB
subgraph "ユーザー層"
WEB[Webアプリ]
MOBILE[モバイルアプリ]
end
subgraph "API層"
GATEWAY[API Gateway]
AUTH[認証サービス]
end
subgraph "アプリケーション層"
APP1[アプリ1]
APP2[アプリ2]
end
subgraph "データ層"
DB1[(データベース1)]
DB2[(データベース2)]
end
WEB --> GATEWAY
MOBILE --> GATEWAY
GATEWAY --> AUTH
GATEWAY --> APP1
GATEWAY --> APP2
APP1 --> DB1
APP2 --> DB2
style WEB fill:#4dabf7
style MOBILE fill:#4dabf7
style GATEWAY fill:#ffd43b
style AUTH fill:#ffd43b
style APP1 fill:#51cf66
style APP2 fill:#51cf66
style DB1 fill:#ff6b6b
style DB2 fill:#ff6b6b
よく使う記号とその意味
| 記号 | 意味 | 例 |
|---|---|---|
[ ] |
四角形（処理） | A[処理] |
{ } |
ひし形（条件） | B{判定} |
( ) |
角丸四角形 | C(開始) |
(( )) |
円（データベース） | D((DB)) |
--> |
矢印 | A --> B |
-.-> |
点線矢印 | A -.-> B |
==> |
太線矢印 | A ==> B |
| `--> | ラベル | ` |
ヒントとベストプラクティス
-
可読性を重視
- 長すぎるラベルは避ける
- 適切にサブグラフでグループ化
-
色の使い方
- レイヤーごとに色を統一
- 重要なノードは目立つ色に
-
方向性
TD（上から下）: 一般的なフローチャートLR（左から右）: 時系列やプロセスBT（下から上）: 階層構造RL（右から左）: 特殊な場合
-
複雑な図は分割
- 1つの図に詰め込みすぎない
- 複数の図に分けて、関連を説明文で補足
参考リンク
- Mermaid公式ドキュメント
- Mermaid Live Editor - リアルタイムでプレビューできるエディタ
- GitHubでのMermaidサポート
まとめ
Mermaidを使うことで、コードと同じようにバージョン管理できる図表を作成できます。ドキュメントと図表を同じリポジトリで管理できるため、保守性が向上します。
レガシー金融システムの複雑なアーキテクチャ例
システム構成図（Mermaid）
graph TB
subgraph "フロントエンド層"
WEB[Webアプリ<br/>React/Next.js]
MOBILE[モバイルアプリ<br/>iOS/Android]
ATM[ATM端末<br/>Windows Embedded]
BRANCH[店舗端末<br/>Java Swing]
end
subgraph "API Gateway層"
APIGW[API Gateway<br/>Kong/AWS API Gateway]
AUTH[認証サービス<br/>OAuth2/SAML]
RATE[レート制限<br/>Redis Cluster]
end
subgraph "アプリケーション層（モダン）"
CUSTOMER[顧客管理API<br/>Node.js/FastAPI]
PRODUCT[商品管理API<br/>Java Spring Boot]
TRANSACTION[取引API<br/>Python/FastAPI]
NOTIFICATION[通知サービス<br/>Node.js]
end
subgraph "アプリケーション層（レガシー）"
LEGACY_MAIN[メインフレーム連携<br/>COBOL/CICS]
LEGACY_BATCH[バッチ処理<br/>JCL/COBOL]
LEGACY_REPORT[帳票生成<br/>PL/I]
end
subgraph "中間DB層（データ連携）"
SYNC_DB1[同期DB-1<br/>Oracle 11g<br/>3社合併時の統合DB]
SYNC_DB2[同期DB-2<br/>DB2 z/OS<br/>旧A社勘定系]
SYNC_DB3[同期DB-3<br/>PostgreSQL<br/>旧B社勘定系]
SYNC_DB4[同期DB-4<br/>SQL Server<br/>旧C社勘定系]
MQ_DB[メッセージキューDB<br/>IBM MQ Series]
end
subgraph "メインフレーム層"
MAINFRAME[メインフレーム<br/>IBM z/OS<br/>COBOL/CICS/VSAM]
MAINFRAME_DB[メインDB<br/>DB2 z/OS<br/>勘定系コア]
TAPE[磁気テープ<br/>バックアップ/アーカイブ]
end
subgraph "レガシーミドルウェア"
CORBA[CORBA ORB<br/>IIOP通信]
SOAP[SOAPサービス<br/>Apache Axis]
ETL1[ETL-1<br/>Informatica<br/>日次バッチ]
ETL2[ETL-2<br/>Pentaho<br/>リアルタイム連携]
FILE_TRANSFER[ファイル転送<br/>FTP/SFTP/FTPS<br/>複数プロトコル混在]
end
subgraph "外部連携層"
PAYMENT[決済ネットワーク<br/>Zengin/全銀システム]
CREDIT[信用情報機関<br/>CIC/JICC]
REGULATORY[規制報告<br/>金融庁/日銀]
PARTNER1[パートナーAPI-1<br/>REST/GraphQL]
PARTNER2[パートナーAPI-2<br/>SOAP/XML]
end
subgraph "監査・ログ層"
AUDIT_DB[監査DB<br/>PostgreSQL<br/>7年保存]
LOG_AGG[ログ集約<br/>ELK Stack]
BACKUP[バックアップ<br/>Veeam/Tivoli]
end
subgraph "セキュリティ層"
FIREWALL[ファイアウォール<br/>複数段階]
WAF[WAF<br/>F5/Cloudflare]
IDS[侵入検知<br/>Snort/Suricata]
end
%% フロントエンド → API Gateway
WEB --> APIGW
MOBILE --> APIGW
ATM --> APIGW
BRANCH --> APIGW
%% API Gateway → 認証・レート制限
APIGW --> AUTH
APIGW --> RATE
AUTH --> RATE
%% API Gateway → アプリケーション層（モダン）
APIGW --> CUSTOMER
APIGW --> PRODUCT
APIGW --> TRANSACTION
APIGW --> NOTIFICATION
%% モダンアプリ → 中間DB
CUSTOMER --> SYNC_DB1
CUSTOMER --> SYNC_DB2
PRODUCT --> SYNC_DB1
PRODUCT --> SYNC_DB3
TRANSACTION --> SYNC_DB1
TRANSACTION --> SYNC_DB2
TRANSACTION --> SYNC_DB4
NOTIFICATION --> MQ_DB
%% モダンアプリ → レガシー連携
CUSTOMER --> LEGACY_MAIN
TRANSACTION --> LEGACY_MAIN
LEGACY_MAIN --> CORBA
LEGACY_MAIN --> SOAP
%% レガシー → メインフレーム
CORBA --> MAINFRAME
SOAP --> MAINFRAME
LEGACY_BATCH --> MAINFRAME
LEGACY_REPORT --> MAINFRAME
MAINFRAME --> MAINFRAME_DB
MAINFRAME --> TAPE
%% 中間DB間の同期
SYNC_DB1 <--> ETL1
SYNC_DB2 <--> ETL1
SYNC_DB3 <--> ETL1
SYNC_DB4 <--> ETL1
SYNC_DB1 <--> ETL2
SYNC_DB2 <--> ETL2
MAINFRAME_DB --> ETL1
MAINFRAME_DB --> ETL2
%% メインフレーム → 中間DB
MAINFRAME --> SYNC_DB1
MAINFRAME --> SYNC_DB2
%% ファイル転送
FILE_TRANSFER --> SYNC_DB1
FILE_TRANSFER --> SYNC_DB2
FILE_TRANSFER --> SYNC_DB3
FILE_TRANSFER --> MAINFRAME
%% 外部連携
TRANSACTION --> PAYMENT
CUSTOMER --> CREDIT
LEGACY_BATCH --> REGULATORY
CUSTOMER --> PARTNER1
PRODUCT --> PARTNER2
%% 監査・ログ
CUSTOMER --> AUDIT_DB
TRANSACTION --> AUDIT_DB
MAINFRAME --> AUDIT_DB
CUSTOMER --> LOG_AGG
TRANSACTION --> LOG_AGG
APIGW --> LOG_AGG
MAINFRAME_DB --> BACKUP
SYNC_DB1 --> BACKUP
SYNC_DB2 --> BACKUP
%% セキュリティ
FIREWALL --> APIGW
WAF --> FIREWALL
IDS --> WAF
style MAINFRAME fill:#ff6b6b
style MAINFRAME_DB fill:#ff6b6b
style SYNC_DB1 fill:#ffd93d
style SYNC_DB2 fill:#ffd93d
style SYNC_DB3 fill:#ffd93d
style SYNC_DB4 fill:#ffd93d
style CORBA fill:#ff8787
style SOAP fill:#ff8787
style ETL1 fill:#ff8787
style ETL2 fill:#ff8787
graph TB
subgraph "フロントエンド層"
WEB[Webアプリ<br/>React/Next.js]
MOBILE[モバイルアプリ<br/>iOS/Android]
ATM[ATM端末<br/>Windows Embedded]
BRANCH[店舗端末<br/>Java Swing]
end
subgraph "API Gateway層"
APIGW[API Gateway<br/>Kong/AWS API Gateway]
AUTH[認証サービス<br/>OAuth2/SAML]
RATE[レート制限<br/>Redis Cluster]
end
subgraph "アプリケーション層（モダン）"
CUSTOMER[顧客管理API<br/>Node.js/FastAPI]
PRODUCT[商品管理API<br/>Java Spring Boot]
TRANSACTION[取引API<br/>Python/FastAPI]
NOTIFICATION[通知サービス<br/>Node.js]
end
subgraph "アプリケーション層（レガシー）"
LEGACY_MAIN[メインフレーム連携<br/>COBOL/CICS]
LEGACY_BATCH[バッチ処理<br/>JCL/COBOL]
LEGACY_REPORT[帳票生成<br/>PL/I]
end
subgraph "中間DB層（データ連携）"
SYNC_DB1[同期DB-1<br/>Oracle 11g<br/>3社合併時の統合DB]
SYNC_DB2[同期DB-2<br/>DB2 z/OS<br/>旧A社勘定系]
SYNC_DB3[同期DB-3<br/>PostgreSQL<br/>旧B社勘定系]
SYNC_DB4[同期DB-4<br/>SQL Server<br/>旧C社勘定系]
MQ_DB[メッセージキューDB<br/>IBM MQ Series]
end
subgraph "メインフレーム層"
MAINFRAME[メインフレーム<br/>IBM z/OS<br/>COBOL/CICS/VSAM]
MAINFRAME_DB[メインDB<br/>DB2 z/OS<br/>勘定系コア]
TAPE[磁気テープ<br/>バックアップ/アーカイブ]
end
subgraph "レガシーミドルウェア"
CORBA[CORBA ORB<br/>IIOP通信]
SOAP[SOAPサービス<br/>Apache Axis]
ETL1[ETL-1<br/>Informatica<br/>日次バッチ]
ETL2[ETL-2<br/>Pentaho<br/>リアルタイム連携]
FILE_TRANSFER[ファイル転送<br/>FTP/SFTP/FTPS<br/>複数プロトコル混在]
end
subgraph "外部連携層"
PAYMENT[決済ネットワーク<br/>Zengin/全銀システム]
CREDIT[信用情報機関<br/>CIC/JICC]
REGULATORY[規制報告<br/>金融庁/日銀]
PARTNER1[パートナーAPI-1<br/>REST/GraphQL]
PARTNER2[パートナーAPI-2<br/>SOAP/XML]
end
subgraph "監査・ログ層"
AUDIT_DB[監査DB<br/>PostgreSQL<br/>7年保存]
LOG_AGG[ログ集約<br/>ELK Stack]
BACKUP[バックアップ<br/>Veeam/Tivoli]
end
subgraph "セキュリティ層"
FIREWALL[ファイアウォール<br/>複数段階]
WAF[WAF<br/>F5/Cloudflare]
IDS[侵入検知<br/>Snort/Suricata]
end
%% フロントエンド → API Gateway
WEB --> APIGW
MOBILE --> APIGW
ATM --> APIGW
BRANCH --> APIGW
%% API Gateway → 認証・レート制限
APIGW --> AUTH
APIGW --> RATE
AUTH --> RATE
%% API Gateway → アプリケーション層（モダン）
APIGW --> CUSTOMER
APIGW --> PRODUCT
APIGW --> TRANSACTION
APIGW --> NOTIFICATION
%% モダンアプリ → 中間DB
CUSTOMER --> SYNC_DB1
CUSTOMER --> SYNC_DB2
PRODUCT --> SYNC_DB1
PRODUCT --> SYNC_DB3
TRANSACTION --> SYNC_DB1
TRANSACTION --> SYNC_DB2
TRANSACTION --> SYNC_DB4
NOTIFICATION --> MQ_DB
%% モダンアプリ → レガシー連携
CUSTOMER --> LEGACY_MAIN
TRANSACTION --> LEGACY_MAIN
LEGACY_MAIN --> CORBA
LEGACY_MAIN --> SOAP
%% レガシー → メインフレーム
CORBA --> MAINFRAME
SOAP --> MAINFRAME
LEGACY_BATCH --> MAINFRAME
LEGACY_REPORT --> MAINFRAME
MAINFRAME --> MAINFRAME_DB
MAINFRAME --> TAPE
%% 中間DB間の同期
SYNC_DB1 <--> ETL1
SYNC_DB2 <--> ETL1
SYNC_DB3 <--> ETL1
SYNC_DB4 <--> ETL1
SYNC_DB1 <--> ETL2
SYNC_DB2 <--> ETL2
MAINFRAME_DB --> ETL1
MAINFRAME_DB --> ETL2
%% メインフレーム → 中間DB
MAINFRAME --> SYNC_DB1
MAINFRAME --> SYNC_DB2
%% ファイル転送
FILE_TRANSFER --> SYNC_DB1
FILE_TRANSFER --> SYNC_DB2
FILE_TRANSFER --> SYNC_DB3
FILE_TRANSFER --> MAINFRAME
%% 外部連携
TRANSACTION --> PAYMENT
CUSTOMER --> CREDIT
LEGACY_BATCH --> REGULATORY
CUSTOMER --> PARTNER1
PRODUCT --> PARTNER2
%% 監査・ログ
CUSTOMER --> AUDIT_DB
TRANSACTION --> AUDIT_DB
MAINFRAME --> AUDIT_DB
CUSTOMER --> LOG_AGG
TRANSACTION --> LOG_AGG
APIGW --> LOG_AGG
MAINFRAME_DB --> BACKUP
SYNC_DB1 --> BACKUP
SYNC_DB2 --> BACKUP
%% セキュリティ
FIREWALL --> APIGW
WAF --> FIREWALL
IDS --> WAF
style MAINFRAME fill:#ff6b6b
style MAINFRAME_DB fill:#ff6b6b
style SYNC_DB1 fill:#ffd93d
style SYNC_DB2 fill:#ffd93d
style SYNC_DB3 fill:#ffd93d
style SYNC_DB4 fill:#ffd93d
style CORBA fill:#ff8787
style SOAP fill:#ff8787
style ETL1 fill:#ff8787
style ETL2 fill:#ff8787
データフロー図（複雑な依存関係）
flowchart TD
subgraph "顧客登録フロー"
START[顧客登録開始]
START --> WEB_CHECK[Webアプリで入力]
WEB_CHECK --> APIGW_CHECK[API Gateway経由]
APIGW_CHECK --> CUSTOMER_API[顧客管理API]
CUSTOMER_API --> SYNC_DB1_WRITE[同期DB-1に書き込み]
CUSTOMER_API --> SYNC_DB2_WRITE[同期DB-2に書き込み]
SYNC_DB1_WRITE --> ETL_TRIGGER[ETL-1が検知]
ETL_TRIGGER --> MAINFRAME_SYNC[メインフレーム同期]
MAINFRAME_SYNC --> MAINFRAME_DB_WRITE[メインDB書き込み]
SYNC_DB2_WRITE --> CORBA_CALL[CORBA経由で旧A社システム呼び出し]
CORBA_CALL --> LEGACY_MAIN_CALL[レガシーメイン呼び出し]
LEGACY_MAIN_CALL --> MAINFRAME_DB_WRITE
MAINFRAME_DB_WRITE --> BATCH_TRIGGER[バッチ処理トリガー]
BATCH_TRIGGER --> CREDIT_CHECK[信用情報機関チェック]
CREDIT_CHECK --> SYNC_DB3_UPDATE[同期DB-3更新]
SYNC_DB3_UPDATE --> FILE_EXPORT[ファイルエクスポート]
FILE_EXPORT --> PARTNER_SEND[パートナーAPI-2送信]
MAINFRAME_DB_WRITE --> AUDIT_LOG[監査ログ記録]
SYNC_DB1_WRITE --> AUDIT_LOG
SYNC_DB2_WRITE --> AUDIT_LOG
AUDIT_LOG --> END_FLOW[完了]
PARTNER_SEND --> END_FLOW
end
style MAINFRAME_DB_WRITE fill:#ff6b6b
style CORBA_CALL fill:#ff8787
style ETL_TRIGGER fill:#ff8787
flowchart TD
subgraph "顧客登録フロー"
START[顧客登録開始]
START --> WEB_CHECK[Webアプリで入力]
WEB_CHECK --> APIGW_CHECK[API Gateway経由]
APIGW_CHECK --> CUSTOMER_API[顧客管理API]
CUSTOMER_API --> SYNC_DB1_WRITE[同期DB-1に書き込み]
CUSTOMER_API --> SYNC_DB2_WRITE[同期DB-2に書き込み]
SYNC_DB1_WRITE --> ETL_TRIGGER[ETL-1が検知]
ETL_TRIGGER --> MAINFRAME_SYNC[メインフレーム同期]
MAINFRAME_SYNC --> MAINFRAME_DB_WRITE[メインDB書き込み]
SYNC_DB2_WRITE --> CORBA_CALL[CORBA経由で旧A社システム呼び出し]
CORBA_CALL --> LEGACY_MAIN_CALL[レガシーメイン呼び出し]
LEGACY_MAIN_CALL --> MAINFRAME_DB_WRITE
MAINFRAME_DB_WRITE --> BATCH_TRIGGER[バッチ処理トリガー]
BATCH_TRIGGER --> CREDIT_CHECK[信用情報機関チェック]
CREDIT_CHECK --> SYNC_DB3_UPDATE[同期DB-3更新]
SYNC_DB3_UPDATE --> FILE_EXPORT[ファイルエクスポート]
FILE_EXPORT --> PARTNER_SEND[パートナーAPI-2送信]
MAINFRAME_DB_WRITE --> AUDIT_LOG[監査ログ記録]
SYNC_DB1_WRITE --> AUDIT_LOG
SYNC_DB2_WRITE --> AUDIT_LOG
AUDIT_LOG --> END_FLOW[完了]
PARTNER_SEND --> END_FLOW
end
style MAINFRAME_DB_WRITE fill:#ff6b6b
style CORBA_CALL fill:#ff8787
style ETL_TRIGGER fill:#ff8787
データベース関係図（ER風）
erDiagram
MAINFRAME_DB ||--o{ SYNC_DB1 : "日次バッチ同期"
MAINFRAME_DB ||--o{ SYNC_DB2 : "リアルタイム同期"
SYNC_DB1 ||--o{ SYNC_DB3 : "ETL-1経由"
SYNC_DB2 ||--o{ SYNC_DB4 : "ETL-2経由"
SYNC_DB1 ||--o{ AUDIT_DB : "監査ログ"
SYNC_DB2 ||--o{ AUDIT_DB : "監査ログ"
MAINFRAME_DB ||--o{ AUDIT_DB : "監査ログ"
MAINFRAME_DB {
string account_id PK
string customer_id
decimal balance
datetime last_update
}
SYNC_DB1 {
string sync_id PK
string account_id FK
string source_system
json data_snapshot
datetime sync_timestamp
}
SYNC_DB2 {
string legacy_id PK
string account_id FK
string company_code
json legacy_data
datetime sync_timestamp
}
SYNC_DB3 {
string product_id PK
string account_id FK
string product_type
json product_data
}
SYNC_DB4 {
string transaction_id PK
string account_id FK
decimal amount
datetime transaction_date
}
AUDIT_DB {
string audit_id PK
string table_name
string record_id
string operation
json before_data
json after_data
datetime audit_timestamp
}
erDiagram
MAINFRAME_DB ||--o{ SYNC_DB1 : "日次バッチ同期"
MAINFRAME_DB ||--o{ SYNC_DB2 : "リアルタイム同期"
SYNC_DB1 ||--o{ SYNC_DB3 : "ETL-1経由"
SYNC_DB2 ||--o{ SYNC_DB4 : "ETL-2経由"
SYNC_DB1 ||--o{ AUDIT_DB : "監査ログ"
SYNC_DB2 ||--o{ AUDIT_DB : "監査ログ"
MAINFRAME_DB ||--o{ AUDIT_DB : "監査ログ"
MAINFRAME_DB {
string account_id PK
string customer_id
decimal balance
datetime last_update
}
SYNC_DB1 {
string sync_id PK
string account_id FK
string source_system
json data_snapshot
datetime sync_timestamp
}
SYNC_DB2 {
string legacy_id PK
string account_id FK
string company_code
json legacy_data
datetime sync_timestamp
}
SYNC_DB3 {
string product_id PK
string account_id FK
string product_type
json product_data
}
SYNC_DB4 {
string transaction_id PK
string account_id FK
decimal amount
datetime transaction_date
}
AUDIT_DB {
string audit_id PK
string table_name
string record_id
string operation
json before_data
json after_data
datetime audit_timestamp
}
技術スタックの時系列（レガシー度）
timeline
title システムの歴史的積層
1980年代 : メインフレーム導入
: COBOL/CICS
: DB2 z/OS
: VSAMファイル
1990年代 : 3社合併
: 中間DB-1導入（Oracle）
: CORBA連携
: バッチ処理強化
2000年代 : 旧A社システム統合
: 中間DB-2導入（DB2）
: SOAPサービス
: ETL-1導入
2010年代 : 旧B社システム統合
: 中間DB-3導入（PostgreSQL）
: Webアプリ開始
: REST API一部導入
2020年代 : 旧C社システム統合
: 中間DB-4導入（SQL Server）
: モダンAPI拡大
: マイクロサービス化開始
: クラウド移行検討
timeline
title システムの歴史的積層
1980年代 : メインフレーム導入
: COBOL/CICS
: DB2 z/OS
: VSAMファイル
1990年代 : 3社合併
: 中間DB-1導入（Oracle）
: CORBA連携
: バッチ処理強化
2000年代 : 旧A社システム統合
: 中間DB-2導入（DB2）
: SOAPサービス
: ETL-1導入
2010年代 : 旧B社システム統合
: 中間DB-3導入（PostgreSQL）
: Webアプリ開始
: REST API一部導入
2020年代 : 旧C社システム統合
: 中間DB-4導入（SQL Server）
: モダンAPI拡大
: マイクロサービス化開始
: クラウド移行検討
問題点の可視化
主な課題
-
データ整合性の問題
- 4つの中間DBが非同期で更新される
- メインフレームとの同期タイミングがバラバラ
- トランザクション境界が不明確
-
技術的負債
- CORBA、SOAP、REST、GraphQLが混在
- ファイル転送が複数プロトコル（FTP/SFTP/FTPS）
- レガシー言語（COBOL/PL/I/JCL）とモダン言語（Python/Node.js/Java）の混在
-
運用の複雑さ
- バッチ処理の依存関係が複雑
- 障害時の影響範囲が広い
- 監査ログが複数システムに分散
-
スケーラビリティ
- メインフレームがボトルネック
- 中間DBの同期遅延
- 外部連携のタイムアウト
Comments