Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — フォーク2年、感情ではなくリリースノートで
背景 — どこで分岐し、所有権はどう動いたか
バージョン別に見る実際の分岐 — OpenBaoが加えたもの
ネームスペース — Enterprise機能が越境した瞬間、そしてその先
逆方向の分岐 — OpenBaoが削るもの
同じ方向に動いたもの — セキュリティデフォルトとCVE移植
Vault側で背負うもの — CEのパッチ崖
では何を選ぶべきか
おわりに
参考資料

はじめに — フォーク2年、感情ではなくリリースノートで

今日(2026-07-17)はOpenBao v2.0.0 GAが出てからちょうど2年、v2.6.0が出てから3日です。そしてこの話題は今も陣営が分かれます — 一方は「BUSLへの移行は裏切りだ」と言い、もう一方は「フォークは機能もサポートも追いつけない」と言います。ライセンス移行の背景自体はオープンソースライセンス 2026 — BSL・SSPL・FSL、クラウドへの 8 年間の反乱を読み解く徹底解説 (2026)の回で扱ったので、本稿は別の問いに答えます。フォークは実際どこで分岐したのか — マーケティング文句ではなく、両プロジェクトが自ら発行したリリースノートとチェンジログ、コミットで確認できることだけを。

同じフォーク系列であるOpenTofuが、アップストリームのTerraformにない機能を先に出し始めた話はOpenTofuのdynamic lifecycleの回で扱いました。本稿はそのシークレット管理版です。

背景 — どこで分岐し、所有権はどう動いたか

時系列で確認できる事実だけを並べるとこうなります。

VaultリポジトリのLICENSEファイルはBUSL 1.1で、適用対象を「Vault Version 1.15.0 or later」と明記しています。つまり1.14系が最後のMPLコードベースです。
OpenBaoはその地点で分岐しました。v2.0.0リリースノートは「OpenBao is fully API compatible with Vault 1.14.9」と明言し、Enterprise機能はサポートしないとしています。GAは2024-07-17で、この時点ではWeb UIすら欠けていました。
IBMによるHashiCorp買収は2025-02-27に完了しました(IBMニュースルーム)。
OpenBaoは2025-06-17、LF EdgeからOpenSSFサンドボックスプロジェクトへ移管されました。
2026-03-26、VaultリポジトリのLICENSEでライセンサーが「HashiCorp, Inc.」から「International Business Machines Corporation (IBM)」に変わりました(コミットdiffでそのまま確認できます — 競合製品禁止条項の保護対象も「IBM Corp's paid version(s)」に変わっています)。
2026-04-14、Vault 2.0.0が出ました。1.0(2018)以来初のメジャー番号の跳躍で、FEATURES一覧には「IBM PAO License Integration」— IBMのライセンスキーでVault Enterpriseを使えるようにする機能 — が入っています。

買収後の統合がライセンスファイルと機能一覧にまで及んだわけです。ここからは、フォーク側がこれまで何を積み上げてきたかを見ていきます。

バージョン別に見る実際の分岐 — OpenBaoが加えたもの

すべてOpenBao CHANGELOGとGitHubリリースで確認した内容です。日付はGitHub APIのリリース公開時刻に基づきます。

v2.1.0  2024-11-29  トランザクショナルストレージ(GH-292)、マウントテーブルのサイズ上限撤廃(GH-622)、
                    PostgreSQLバックエンド復活 + ページネーションLIST(GH-467)
v2.2.0  2025-03-05  PKCS#11 HSMオートアンシール(GH-889)、リスナーTLSのACME自動発行(GH-857)、
                    再帰リストSCAN動詞・ACL(GH-763)、Web UI復帰(GH-940)、Raftノンボーター(GH-741)
v2.3.1  2025-06-25  ネームスペース(GH-1165)、ネームスペースUI(GH-1406)、
                    PKI・JWT認証のCELポリシー(GH-794, GH-869)、KMIPオートアンシール(GH-1144)
v2.4.0  2025-08-28  宣言的自己初期化(GH-1506)、インライントークンレス認証(GH-1433)、
                    LIST/SCANレスポンスフィルタリング(GH-1389)、設定ファイルベースの監査デバイス(GH-1700)
v2.5.0  2026-02-04  スタンバイ読み取りスケーリング(GH-1986)、OCIイメージベースのプラグイン配備(GH-1824)、
                    未認証rekeyエンドポイントのデフォルト遮断(GH-2125、破壊的変更)
v2.6.0  2026-07-14  ネームスペース封印(GH-3297)、オートアンシールのKMSプラグイン化(GH-2586)、
                    sys/workflows(GH-2728)、認証済みルートトークン生成(GH-3041)、distrolessイメージ

ここに2つの軸が見えます。一つはVault Enterprise専用機能のオープンソース化という軸です。ネームスペース、HSMアンシール、スタンバイノードの読み取りスケーリング(アップストリームのperformance standbyに相当)はすべてVaultでは Enterprise ドキュメントツリーにある機能です。もう一つはアップストリームにまったくない方向という軸です — トランザクショナルストレージ、CELポリシー、宣言的自己初期化、インライン認証といったものは、Enterpriseカタログを模倣したのではなく、フォーク独自の設計です。プロジェクトが2026年7月に出したトランザクショナルストレージ、ページネーションLISTの解説記事が、この差別化軸を自ら整理しています(プロジェクト自身の記述であることは踏まえて読んでください)。

ネームスペース — Enterprise機能が越境した瞬間、そしてその先

もっとも象徴的な分岐はネームスペースです。Vaultにおいてネームスペースはマルチテナンシーの基盤であり、Enterprise購入理由のかなりの部分を占めますが、OpenBaoはv2.3.1(2025-06-25)でこれをオープンソースとして出しました。チェンジログの表現が興味深いです — 「application API compatible with upstream's implementation」。パスベース(/my-namespace/secrets)とX-Vault-Namespaceヘッダールーティングの両方をサポートすると明記しており、公式発表記事は「Vault EnterpriseとのAPI互換を維持し、スムーズな移行経路を提供する」と記しています。互換性は目的ではなく、移行への誘因です。

そして3日前のv2.6.0はさらに一歩進みました。ネームスペース封印(namespace sealing) — ネームスペース作成時に別個のShamir sealを構成し、リリースノートの表現では「テナントストレージを異なる暗号学的キーマテリアルでパーティション化」し、あるテナントが他のテナントに影響を与えずに自分のネームスペースだけを封印してアクセスを遮断できるようにしました。比較すると、Vault EnterpriseのネームスペースロックAPIはドキュメント上「locks the API」— APIレベルの遮断です。キーマテリアルの分離は別の層の隔離であり、これは2025年5月の発表記事で「検討中」とされていた項目が1年余りで出荷されたものです。フォークがアップストリームのカタログ追随を超え、自らのロードマップで動いているもっとも具体的な証拠です。

もちろん割り引いて読む必要があります。ネームスペース封印は今回のリリースで初めて登場した機能であり、実運用での検証実績はありません。マルチテナント隔離をこれ一つに賭けるには早すぎます。

逆方向の分岐 — OpenBaoが削るもの

移行を検討しているなら、こちらのほうが重要です。OpenBaoは加える分だけ積極的に削っています。

ストレージバックエンド。 OpenBaoのドキュメントにあるバックエンドは、Raft、PostgreSQL、ファイル、インメモリ(開発用)がすべてです。Consul、DynamoDB、S3といったVaultのバックエンド一覧は、フォークの時点で整理されました。ファイルバックエンドすらv2.6.0で非推奨予告され、v2.7.0で削除されます(GH-2849)。Consulストレージ上で動いていたVaultをそのまま持ち上げて移すことはできない、ということです。

クラウドシークレットエンジン。 AWS・Azure・GCPの動的クレデンシャルエンジンはOpenBaoコアにはありません。openbao-pluginsリポジトリの外部プラグインとして提供されますが(認証: AWS/Azure/GCP/GitHub、シークレット: AWS/Azure/GCP/GCPKMS/Nomad/Consul)、同じREADMEはデータベースプラグインの項目に「None available at this time」と記しています — コアにあるもの(PostgreSQL、MySQL、Valkeyなど)以外のDBエンジンはない、ということです。

組み込みsealと配布物。 v2.6.0はオートアンシールを外部KMSプラグイン方式に切り替え、組み込みだったawskms・azurekeyvault・gcpckms・pkcs11などのsealをv2.7.0で削除すると予告しました。HSM専用配布物自体もv2.7.0まで段階的に廃止されます。LDAP・Kerberos・RADIUSプラグインもメインバイナリから外れ、外部プラグインへ移動します(GH-3371)。

方向性自体は一貫しています — コアを縮小し、境界をプラグインへ押し出す。しかし運用者の立場では、v2.6からv2.7へのアップグレードはseal設定・ストレージ・認証方式が一度に絡む地雷原になりかねません。リリースノートのDEPRECATIONSセクションを今回ばかりは本当に読む必要があります。

そして失われたもののうち最大の項目は、廃止予告リストにすら載っていません。クロスクラスタレプリケーション — Vault Enterpriseのperformance/DRレプリケーションに相当する機能がOpenBaoにはありません。v2.5.0のスタンバイ読み取りスケーリングは単一クラスタ内の拡張であり、チェンジログ自身が「結果は結果整合性(eventually consistent)」と明記しています。マルチリージョンのアクティブ-アクティブが必要なら、OpenBaoには現在答えがありません。

同じ方向に動いたもの — セキュリティデフォルトとCVE移植

分岐だけではありません。セキュリティ面では両プロジェクトは今も絡み合っています。

未認証運用エンドポイントの強化がよい例です。OpenBaoはv2.3.1(2025-06)で未認証rekeyを無効化できるリスナーオプションを追加し(CVE-2025-52894、チェンジログはアップストリームのHCSEC-2025-11を併記)、v2.5.0(2026-02)でデフォルトを遮断に反転させ、v2.6.0で認証済みルートトークン生成エンドポイントを追加しました。Vaultも2.0.0(2026-04)でsys/rekeyとsys/generate-rootをデフォルト認証に変えています。どちらがどちらに追随したのかは私には判定できませんが、日付は以上の通りです。

移植関係も実在します。OpenBao v2.3.2(2025-08-07)はアップストリームVaultのHCSEC-2025系セキュリティ修正8件(HCSEC-2025-13など)を移植し、自前のCVE番号(CVE-2025-54996など)を付けました。フォークから2年経ってもコードの系譜が重なっている以上、一方のセキュリティ告知はもう一方のユーザーにとっても警報だということです。どちらを運用するにせよ、両方のセキュリティアドバイザリを購読するのが正解です。

Vault側で背負うもの — CEのパッチ崖

Vaultを無償(CE)で使うチームなら、Vault CHANGELOGのリリースヘッダーのパターンを自分で確認してみることを勧めます。観察できる事実はこうです。

1.21系のCEパッチは1.21.4(2026-03-05)が最後です。Vault 2.0.0がGAした2026-04-14以降、1.21.5には「Enterprise」表記が付きます。1.20系も同じパターンでした — 1.21.0が出た日(2025-10-22)から、1.20.5はEnterprise専用に。
つまり新しいマイナーが出た瞬間、それ以前のブランチのCEセキュリティパッチは終わります。CEでパッチを受け続ける唯一の方法は、常に最新マイナーに乗り続けることです。
長期サポートは明示的に有料機能です。LTSドキュメントはEnterprise専用の注記とともに「基本1年保守 + LTSで1年延長」を説明しています。

これは陰謀ではなく公開された方針であり、HashiCorp/IBMの権利です。ただし「Vault CEだから無料で安定運用できる」という計算には、アップグレードのトレッドミルのコストが抜けている点を踏まえて選ぶ必要があります。参考までに、OpenBaoも永遠の無償サポートを約束する組織ではなく、OpenSSF傘下のコミュニティプロジェクトです — 2025-2026ロードマップによれば、過去1年のコミット741件、コントリビューター287人(プロジェクト自身の集計)が持続可能性のすべてです。ベンダーSLAが必要な組織なら、それはそれとして冷静に見るべきです。

では何を選ぶべきか

ツール比較の一般論はDevOpsシークレット管理 2026 完全ガイド - Doppler・Infisical・HashiCorp Vault・AWS Secrets Manager・1Password CLI・Bitwarden Secrets・SOPS・age 徹底解説の回にあるので、ここではこのフォーク構図に限定して整理します。

OpenBaoが実質的な候補になる場合

BUSL・ベンダーロックインが組織方針上の障害であり、ストレージをRaft(またはPostgreSQL)に収束できる場合
マルチテナンシー(ネームスペース)が必要だが、Enterpriseライセンス費用が正当化できない場合 — この機能ギャップ一つがフォークへ移る十分な理由になる組織は実際に存在します
Kubernetes・JWT・PKI・KV・Transit中心のワークロード — この経路はコアにすべてあり、CELポリシー・自己初期化といったアップストリームにない運用上の利便性まで付いてきます

Vaultに留まるのが正しい場合

マルチクラスタレプリケーション(performance/DR)が必要な場合 — OpenBaoに対応物はありません
AWS・Azure・GCPの動的クレデンシャルが中核経路である場合 — OpenBaoでは外部プラグイン依存になり、運用負担と成熟度リスクを自ら負う必要があります
ベンダーサポート契約とLTSが監査・規制要件である場合 — その要件自体がEnterprise購入理由です

どちらを選ぶにせよしてはいけないこと — 「API互換だからドロップインだ」という前提です。ストレージバックエンド、seal設定、プラグイン構成が異なり、OpenBaoのv2.7.0廃止スケジュールまで重なれば、移行はドロップインではなくプロジェクトになります。移行するかどうかにかかわらず、両プロジェクトのリリースノートのDEPRECATIONSとSECURITYセクションを四半期ごとに読むことが、この領域における最低限の防御です。

おわりに

フォーク2年目の姿はこうまとめられます。OpenBaoはEnterprise専用だったネームスペース・HSMアンシール・読み取りスケーリングをオープンソースに持ち込み、v2.6.0のネームスペース封印のようにアップストリームにない機能を先に出し始めました。同時にコアを積極的に削ぎ落とし、Vaultとの表面的な互換性の下に、ストレージ・クラウドエンジン・sealという実質的な非互換を積み上げています。VaultはIBM所有がライセンスファイル単位で確定し、2.0へと番号を上げながら、CEユーザーには最新マイナーの追随を、長期サポートが必要な組織にはEnterpriseを求める構造を維持しています。

どちらも合理的な選択肢になる組織がそれぞれ存在します。ただしこの領域の記事の多くは、どちらか一方の利害の上で書かれています — 本稿がリンクした一次資料と同様に、判断の根拠をリリースノートとコミットまで降ろして、ご自身で確認されることをお勧めします。