1. 背景：移行は終わった、でも“夜間バッチが終わらない”問題
COBOL資産を bit-exact で Java や PostgreSQL に移送できても、移行先が汎用DBだと VSAM時代の性能が出ない。特に金融・保険・医療の基幹系では「夜間バッチ window 崩壊」が多発しています。
現場の悩み
- PostgreSQL/MySQL だと KSDS の順次読込が遅い
- RRDS/ESDS のランダムアクセスが重く、SLA違反
- DBチューニングしてもメインフレームVSAMの10%も出ない
- audit/改竄検知を後付けするとさらに遅くなる
2. SlimeTree-VSAM が刺さる3つのニーズ
ニーズ1: 夜間バッチを終わらせたい
従来の課題: 10億件処理で19.5時間→業務開始に間に合わない
SlimeTree-VSAMの解: VSAM互換のネイティブストレージ。Sequential cursor が PostgreSQL 16 比 480倍速
実測値: 19.5h → 4.4分
ニーズ2: オンライン性能を落としたくない
従来の課題: ランダムキー参照が遅く、画面遷移でタイムアウト
SlimeTree-VSAMの解: Random key access 267倍速。Rust単体バイナリで余計なミドルウェア無し
実測値: KSDS/ESDS/RRDS 全対応
ニーズ3: 監査対応を軽くしたい
従来の課題: DB+別ツールで改竄検知→2重書き込みでI/O倍
SlimeTree-VSAMの解: SHA-256 audit chain 内蔵。air-gap 環境でも改竄検知が成立
実測値: backend内蔵、追加I/O無し
3. “BLACKBOX上等”な導入インパクト
ジャバテルは COBOL 移行で「意味を理解せず bit-exact 転写」を提唱。ストレージも同じ思想です。
ポイント
1. アプリ改修ゼロ: VSAM API互換なので、移行後の Java/C# 側は JCL/COBOL の READ/WRITE をそのまま使える
2. Rust単体 272KB: WASMでも動く。サーバレス/エッジ/メインフレーム代替機にそのまま載る
3. 将来は SlimeOS(DB) に統合予定: 記録体 SlimeTree-RLM と組み合わせて「意味駆動 + 超高速I/O」を両立
4. こんな現場にフィットする
銀行 勘定系
典型的な詰まり: 日中オンライン + 夜間10億件更新でCPU張り付き
SlimeTree-VSAM適用後: 4.4分で夜間バッチ完了、余剰CPUを日中与信に回せる
生保 契約管理
典型的な詰まり: RRDS参照が多く、Web申込が昼ピークで遅延
SlimeTree-VSAM適用後: 267倍速のランダムアクセスでレスポンス0.1秒台維持
医療レセプト
典型的な詰まり: 月次1セント違算が許されない + 大量順次
SlimeTree-VSAM適用後: FIPS 21-3 で 5,270/5,270 bit-exact + audit chain で厚労省監査対応
製造 在庫/生産
典型的な詰まり: air-gap工場で監査ログが取れない
SlimeTree-VSAM適用後: DB不要・単体バイナリなので閉域網でSHA-256保証
5. まとめ：移行後に残る“最後のボトルネック”を消す
COBOL移行は終わった。でもPostgreSQLに載せた途端、夜間バッチが終わらなくなった——。
そんな“VSAM難民”のために、ジャバテルが Rust 製ネイティブストレージ SlimeTree-VSAM を公開。
同ホスト bench で Sequential 480倍速、Random 267倍速。10億件バッチが 19.5時間→4.4分 に短縮され、SHA-256 audit chain も内蔵。
アプリ改修ゼロで、VSAM の性能をそのまま取り戻せます。
図解イメージ
Before: COBOL → PostgreSQL = 夜間バッチ 19.5h
After: COBOL → Java + SlimeTree-VSAM = 4.4分
6. 次のアクション
1. PoC: 既存のVSAMダンプをSlimeTree-VSAMに投入して、同ホストでPostgreSQLと比較bench
2. 監査観点: audit chain のログを SIEM に流す設計を先に決める
3. ロードマップ: 将来の SlimeOS(DB) 統合を見据えて、SlimeTree-RLM との意味駆動レイヤー併用を検討
出典: 株式会社ジャバテル DEVICE I/O セクション 2026-05-24時点
関連: SlimeCOBOL / SlimeRESCUE / SlimeTree-RLM