2026 年 5 月 21 日、InfoQ が Bintrail: MySQL Time-Travel Queries Using Indexed Binlogs を公開しました。Bintrail は ProxySQL の背後でインデックス化された binlog を活用し、MySQL に「過去時点のデータ参照」「行ごとの履歴追跡」を後付けで提供する OSS レイヤです。MySQL 本体やアプリケーションコードを一切変更せずにタイムトラベルクエリを実現できるため、フォレンジック / 監査 / インシデント調査 の選択肢が一気に広がります。
受託で中堅企業の基幹システムを支える立場では、これは 「PostgreSQL のような temporal table を持たない MySQL でも、本格的な監査基盤を組める」ことを意味します。これまで MySQL 9.7 LTS SMB 受託モダナイゼーション で扱った MySQL 本体のアップグレード に加えて、過去時点参照 という別軸が加わります。本記事では弊社が提供する 「Bintrail + MySQL DB フォレンジック」 受託パッケージを整理します。
なぜ MySQL に「タイムトラベルクエリ」が必要になったか
| 観点 | 従来手段 | Bintrail |
|---|---|---|
| 過去時点クエリ | フルバックアップ復元 → 別 DB 起動 | SQL で AS OF '2026-05-01 12:00' 風指定 |
| 行ごと履歴 | アプリ層で監査テーブル実装 | binlog から自動再構築 |
| MySQL 改修 | スキーマ追加・トリガ実装が必要 | 不要（インデックス化のみ） |
| アプリ改修 | ORM レベルで監査追加 | 不要（ProxySQL 経由） |
| ストレージ | 監査テーブル分二重 | 既存 binlog の再利用 |
| PCI / SOC2 対応 | 部分対応 | 完全対応可 |
| インシデント調査速度 | 数時間〜数日 | 数分 |
つまり Bintrail は 「MySQL のスキーマもアプリも改修せず、過去時点参照 + 行履歴を実現する」という、監査基盤の設計の常識を覆す位置付けにあります。
Bintrail が変える 3 つの構造
構造 1: 「フルバックアップ復元」から「即時タイムトラベル」へ
これまで「先週火曜日 14 時の顧客マスタを見たい」という要求には、フルバックアップ復元 + 別 DB 起動 + クエリ実行という数時間〜半日の作業が必要でした。Bintrail では SELECT * FROM customers AS OF '2026-05-15 14:00' 風の SQL で即座に取れます。
構造 2: 「アプリで監査ログ実装」から「ProxySQL レイヤで吸収」へ
監査要件のために アプリ側で更新前後の値を別テーブルに記録するパターンが一般的でしたが、これは アプリ改修 + テストコスト + 監査テーブル肥大化という三重苦を生みます。Bintrail は ProxySQL レイヤでこれを吸収するため、アプリは一切触らない設計が可能です。
構造 3: 「PostgreSQL に乗せ換える」から「MySQL のまま監査要件達成」へ
これまで監査要件のために PostgreSQL（temporal table） / Oracle / SQL Serverへの移行が議論されてきました。Bintrail があれば MySQL のまま で同等機能を実現でき、Monzo Governed Data Mesh 受託 で扱ったような データガバナンス の現実解になります。
受託で提供する「Bintrail + MySQL DB フォレンジック」5 フェーズ
フェーズ 1: 現状診断（2 週間）
- 既存 MySQL クラスタの 棚卸し（バージョン / レプリカ構成 / binlog 設定）
- 監査要件の洗い出し（PCI / SOC2 / ISMS / プライバシーマーク）
- インシデント対応履歴の確認（過去どれだけの工数が消費されたか）
- 既存監査ログ実装の棚卸し（アプリ層 / トリガ層）
- ProxySQL / HAProxy 等の中継層導入可否
フェーズ 2: 設計（1〜2 週間）
- Bintrail を ProxySQL 配下に配置する構成設計
- binlog 保持期間 + インデックス保持期間 の決定
- ストレージ見積もり（S3 / EBS / GCS）
- 重要テーブル抽出（顧客 / 注文 / 決済 / 権限）
- アクセス制御（読み取り専用ロール + 監査用ロール）
- 既存監査ログ実装の 退役計画
フェーズ 3: 段階導入（3〜4 週間）
- 検証環境で Bintrail インストール
- 既存アプリの 無停止で ProxySQL 経由化
- インデックス化の負荷検証（マスタへの影響）
- 検索性能ベンチマーク
- 本番カナリア（1 クラスタ → 全クラスタ）
フェーズ 4: 運用基盤構築（2〜3 週間）
- 監査クエリの テンプレート集作成（よくあるインシデント）
- タイムトラベル SQL 教育（顧客 SRE / セキュリティチーム）
- ダッシュボード構築（Grafana / Metabase）
- 月次フォレンジックレポートのフォーマット
- インシデント時の エスカレーション手順
フェーズ 5: 月次フォレンジックレビュー（継続）
- 監査要件の充足状況確認
- インシデント対応の 平均解決時間 モニタリング
- binlog 保持期間 + ストレージコスト最適化
- 監査クエリテンプレートの更新
- 監査レポート提出
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| DB 本体 | MySQL 8.4 LTS / 9.7 LTS | MariaDB 11.6 |
| タイムトラベル層 | Bintrail | Debezium + ClickHouse |
| 中継 | ProxySQL | HAProxy + MaxScale |
| binlog ストレージ | S3 / GCS（ライフサイクル管理） | 専用 EBS / NFS |
| インデックス | Bintrail 内蔵 | OpenSearch / Elasticsearch |
| 可視化 | Grafana + Metabase | Looker |
| 監査ロール管理 | MySQL native role | HashiCorp Vault |
| アラート | PagerDuty / Slack | Opsgenie |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| MySQL を本番運用 + 監査要件あり | 監査要件ゼロの小規模 |
| PCI / SOC2 / ISMS 対応 | 規制対象外 |
| インシデント調査が頻発 | 単純な読み取り中心 |
| 顧客マスタ / 決済 / 権限を扱う | 一時データのみ |
| 「過去時点参照」要求が出ている | バックアップ復元で十分 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 保持期間 SLA | binlog / インデックス保持期間 | 法定保管期間との整合 |
| 検索性能 SLA | 過去 N 日のクエリ応答時間 | 監査調査時の要求速度 |
| ストレージコスト分担 | 顧客側 / 受託側の負担境界 | 拡張時の精算ルール |
| インシデント SLA | 検知 → 調査開始時間 | 重大度別の対応速度 |
| 監査レポート | 月次 / 監査時提出物 | 法務 / 監査人確認 |
| 退会時引き渡し | binlog + インデックス + ロール | 自社運用継続性 |
価格モデル — Bintrail + MySQL DB フォレンジックパッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 | 80 万円〜（3 週間） | 全 MySQL クラスタ棚卸し + 監査要件評価 | レポート + 改善ロードマップ |
| Lite | 30 万円〜 / 月 | クラスタ 1〜3 本 | binlog 監視 + 月次レポート |
| Standard | 70 万円〜 / 月 | クラスタ 4〜10 本 | + フォレンジック調査 月 3 件まで |
| Enterprise | 140 万円〜 / 月 | クラスタ 11 本〜 | + 24h インシデント対応 + 専任担当 |
| 初期構築 | 250 万円〜（一括） | Bintrail + ProxySQL 構築 | 全プラン共通オプション |
顧客側 ROI 試算（MySQL クラスタ 6 本 / 監査要件あり想定）
| 項目 | 既存運用（現状） | Bintrail 導入 | 差分 |
|---|---|---|---|
| インシデント調査時間 / 件 | 平均 16h | 1.5h | -14.5h |
| インシデント発生 / 年 | 12 件 | 12 件 | 同 |
| バックアップ復元工数 / 年 | 60h | 8h | -52h |
| 監査テーブル運用工数 / 月 | 30h | 5h | -25h |
| 監査落ち / 受注機会損失 | 年 1 件級 | 0 件 | 数千万円規模 |
| 年間効果 | — | — | 約 1,800 万円相当 + 信用維持 |
時給 8,000 円換算で 年間 1,440 万円超の工数削減効果。Standard プラン（年額 840 万円）でも 6 ヶ月以内で回収可能です。
ハマりやすい 5 つの落とし穴
落とし穴 1: binlog 形式が STATEMENT のままになっている
Bintrail は ROW 形式 の binlog を前提とします。STATEMENT / MIXED 形式の場合、過去時点の行値を完全に復元できないため、まずバイナリログ形式の変更が必須です。
落とし穴 2: ProxySQL 単一障害点
ProxySQL を 単一インスタンスで配置すると、Bintrail を経由する全クエリが落ちます。HA 構成 + 自動フェイルオーバー が必須です。
落とし穴 3: インデックス肥大化を放置
Bintrail のインデックスは テーブル更新頻度に比例して肥大化します。月次のサイズ監視 + 古いインデックスのアーカイブ手順を運用に組み込む必要があります。
落とし穴 4: アクセス制御を「フォレンジックチームに全権付与」
過去データを参照できる権限は 強権です。監査ロールと閲覧ロールの分離 + 全クエリ監査ログ を運用に組み込まないと、Bintrail 自体が監査リスクになります。
落とし穴 5: PostgreSQL 移行プロジェクトを止める
「Bintrail で MySQL 維持できるからもう PostgreSQL 移行不要」と判断すると、他の PostgreSQL 由来要件（JSONB / 全文検索 / PostGIS）を見落とします。監査要件単独の判断として扱うべきです。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | 全 MySQL クラスタ棚卸し + 監査要件評価 |
| Week 3〜4 | binlog 形式統一 + ProxySQL HA 設計 |
| Week 5〜7 | Bintrail 段階導入（検証 → ステージング → 本番カナリア） |
| Week 8〜9 | フォレンジック SQL テンプレート整備 |
| Week 10〜11 | 顧客 SRE / セキュリティ向け教育 |
| Week 12〜13 | 月次レビュー会議立ち上げ + 監査レポート初出 |
まとめ — MySQL を「監査基盤の主役」に格上げする
Bintrail は、MySQL に PostgreSQL 並みのタイムトラベルクエリを後付けで実現する転換点です。受託で中堅企業を支える立場では、棚卸し + 設計 + 段階導入 + 運用基盤 + 月次レビューを一体で設計する 「Bintrail + MySQL DB フォレンジック」 が新しい標準サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「MySQL のまま監査要件を満たしたい」「インシデント調査時間を 1 桁短縮したい」「PostgreSQL 移行を回避したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
