MinIO Community Edition はこうして終わった — リポジトリの記録から再構成したタイムラインと、Garage・SeaweedFS・Ceph RGW の現在地

はじめに — 「デフォルトの選択肢」が読み取り専用になるまで
タイムライン — リポジトリ自身が残した記録
何が変わり、何が変わらなかったか
代替の実際の状態 — 2026年7月時点
では、いまMinIOを使っているなら
おわりに
参考資料

はじめに — 「デフォルトの選択肢」が読み取り専用になるまで

このブログの2026年5月の分散ストレージまとめでは、MinIOを「事実上のS3プロトコル参照実装」と呼びました。オンプレミスでS3互換ストレージが必要なら、とりあえずMinIOを入れて始めるのがデフォルトだった時代の表現です。その記事から2か月が経ったいま、minio/minioリポジトリはアーカイブ(読み取り専用)状態です。GitHubのバナー文言そのままに「archived by the owner on Apr 25, 2026」であり、その3日前、2026年7月14日にはmcクライアントのリポジトリまでアーカイブされました。

この出来事は怒りに満ちたスレッドが多い分、不正確な要約も多く出回っています。「ライセンスを変えた」(変えていません)、「コードを非公開にした」(アーカイブされたまま公開されています)といった言説がよく流れます。そこで本稿は世論ではなく記録をたどります — 主張の根拠はすべてリポジトリ自身のコミットとリリースノート、レジストリメタデータ、公式ブログであり、コミュニティの反応はあくまで反応として引用するにとどめます。後半では実際の代替であるGarage・SeaweedFS・Ceph RGWが2026年7月時点でどんな状態にあるか、そしていまMinIOを運用しているなら選択肢は何かを整理します。

タイムライン — リポジトリ自身が残した記録

時期	出来事	一次情報源
2025-05-24	組み込みコンソールを縮小、LDAP/OIDCログインを削除	リリースノート
2025-09-07	Docker Hubの最終イメージ更新	レジストリのタグ履歴
2025-10-15	最終リリース + 「ソースコード専用配布」宣言	リリース、コミット9e49d5e7a6
2025-10-16	high評価のCVE-2025-62506公開(修正は上記リリースのみに収録)	GHSA-jjjj-jwhf-8rgr
2025-12-03	READMEに「メンテナンスモード」を宣言	コミット27742d4694
2026-01-06	READMEがAIStor Free/Enterpriseの案内に置き換え	コミットbe7800c813
2026-02-12	「THIS REPOSITORY IS NO LONGER MAINTAINED.」	コミット7aac2a2c5b
2026-03-20	minio/operatorをアーカイブ	リポジトリのバナー
2026-04-25	minio/minioをアーカイブ	リポジトリのバナー
2026-07-14	minio/mcをアーカイブ	リポジトリのバナー

一つずつ見ていきます。

2025年5月 — コンソールから管理機能が消える

RELEASE.2025-05-24T17-08-30Zのリリースノートは、組み込みUIコンソールが非推奨となりobject-browserリポジトリへ移ることを明らかにし、LDAP/OIDC外部IdPログインの削除についてこう記しています — 「these are now available as part of the AiStor Product.」つまりコミュニティバイナリのWeb UIは管理コンソールから単なるオブジェクトブラウザへと縮小され、削除された機能の行き先は商用製品だと、リリースノート自身が明言したわけです。同じノートは有料顧客にAiStorへのアップグレードを勧めています。

反応は予想どおりでした — 当時のHNスレッド(176ポイント)、そして翌日の5月25日に作られたコンソールUIフォークOpenMaxIOは星を約1,900個集めました。ただしこのフォークの最後のpushは2025年6月24日です(GitHub API基準、2026-07-17時点で確認)。1年以上停止しており、リリースもありません。フォーク宣言とフォーク維持が別物であることを示すデータでもあります。付け加えると、リリースノートがコンソールの新しい行き先だと案内していたminio/object-browserリポジトリは、今日時点で404です — 公開リポジトリ一覧から消えています。

2025年9~10月 — イメージが止まり、最終リリースが出る

レジストリメタデータ基準で、Docker Hubのminio/minioは2025年9月7日(タグRELEASE.2025-09-07T16-13-09Z)が最後の更新です。latestタグもその日以降止まっています。参考までに、このイメージの累計pull数はDocker Hub APIによれば約18億回です — 止まったものがどれほどの規模の配布チャネルだったかが分かります。HNスレッド(733ポイント)がこのときの反応です。

2025年10月15日付のRELEASE.2025-10-15T17-29-55Zが、このリポジトリの最終リリースとなりました。同じ日のREADMEコミット9e49d5e7a6は、コミュニティエディションがこれから「distributed as source code only」になると宣言し、既存のバイナリについては「These legacy binaries will not receive updates.」と釘を刺しています。最終リリースノートが案内するインストール方法そのものが、新しい配布モデルを要約しています。

# RELEASE.2025-10-15T17-29-55Z のリリースノートが案内するインストール方法
go install -v github.com/minio/minio@RELEASE.2025-10-15T17-29-55Z

# コンテナは自分でビルドする
git clone https://github.com/minio/minio
cd minio && git checkout RELEASE.2025-10-15T17-29-55Z
TAG=myregistry.com/minio/minio:RELEASE.2025-10-15T17-29-55Z make docker

CVE-2025-62506 — 配布停止が実際に痛みへ変わる場所

この最終リリースは単なる締めくくりのリリースではありませんでした。GHSA-jjjj-jwhf-8rgrとして公開されたCVE-2025-62506 — サービスアカウント・STSのセッションポリシーバイパスによる権限昇格、深刻度high — の修正がここに含まれています。アドバイザリ基準の脆弱範囲は、2025-10-15の修正コミットより前のすべてです。

ここで配布停止の実務的な意味が正確になります。

Docker Hubの公式イメージは5週間前(9月7日)に止まっていたため、この修正を含む公式な公開イメージは存在しません。quay.io側にも該当のリリースタグはありません(タグ照会結果は空)。
quay.ioには2026年4月に至るまで、旧バージョンリリースのhotfixタグが折々アップされていました。ところが、たとえば2026-04-01にアップされたhotfixタグが指すコミット7aa24e772は、公開リポジトリに存在しません(GitHub APIが該当SHAを見つけられない)。つまり公開ツリーの外でビルドされたイメージであり、コミュニティ側には中身をソースと照合する手段がありません。
結論として、イメージをpullして使っていたユーザーがこのhigh評価の脆弱性をパッチする公式な経路は、「ソースから自分でビルドする」だけでした。

「バイナリを配らない」という言葉は抽象的に聞こえますが、「公開された権限昇格の脆弱性の修正がイメージとしては来ない」という言葉はそうではありません。この出来事こそ、10月の転換を実感させた実物の事例でした。

2025年12月 ~ 2026年7月 — メンテナンスモードからアーカイブ連鎖まで

12月3日のREADMEコミットは、プロジェクトがメンテナンスモードであり、新機能・改善・PRを受け付けず、致命的なセキュリティ修正のみ個別に検討され得ると宣言しました(HN 511ポイント)。1月6日のコミットはその場所にAIStor FreeとAIStor Enterpriseの案内を入れ、2月12日のコミットはバナーを一文にまとめました — 「THIS REPOSITORY IS NO LONGER MAINTAINED.」(HN 500ポイント)

そしてアーカイブが続きました。Kubernetes用のminio/operatorが2026年3月20日、サーバー本体のminio/minioが4月25日、CLIのminio/mcが7月14日。一方でminio-go・minio-py・minio-jsといったSDKリポジトリは、この記事を書いている時点でも活発に更新されています(minio-jsは昨日もpushされています) — AIStorの顧客にもS3クライアントSDKは必要なので、どこが製品の境界線なのかを、アーカイブのパターンそのものが示しているわけです。

何が変わり、何が変わらなかったか

この一件を「ライセンスのラグプル」として記憶するのは不正確です。記録に基づいて整理するとこうなります。

変わらなかったもの — ライセンス。 minio/minioは最初から最後までAGPLv3です。リポジトリのメタデータ、README、LICENSEファイルはすべてそのままです。BSLやSSPLへの転換のようなことは起きていません。アーカイブされたコードは、いまもAGPLv3のもとで誰でも取得できます。

変わったもの — 順に4つ。 (1) 機能: コミュニティバイナリから管理コンソールと外部IdPログインが消えました(2025-05)。(2) 配布: 公式バイナリとコンテナイメージの提供が終わりました(2025-09~10)。(3) メンテナンス: PR・イシューを受け付けなくなりました(2025-12)。(4) リポジトリ自体: 読み取り専用になりました(2026-03~07、アーカイブの連鎖)。

代替として提示されたもの — AIStor Free。 MinIOのサブスクリプション階層告知によれば、AIStor Freeはシングルノード専用で、ノード1台に収める容量に上限はなく、無料ではあるものの再配布・再販を制限するライセンスです(ダウンロードには無料のライセンスキーが必要 — アーカイブされたREADMEの案内基準)。マルチノードの分散構成はEnterprise Liteからで、告知基準では400 TiBを超えるとEnterpriseへ自動的に切り替わります。要するにAIStor Freeは「無料のプロプライエタリなシングルノード製品」です。オープンソースMinIOの後継ではなく別物であり、そう評価すべきです。

起きなかったもの — 成功したサーバー本体のフォーク。 HashiCorp Vaultのライセンス転換の際は、財団傘下のOpenBaoが分岐して自立しました。MinIOには、この記事を書いている時点までそうしたフォークは見当たりません。コンソールUIのフォーク(OpenMaxIO)は上で見たとおり停止しており、サーバー本体を引き継いで勢いを得たフォークは確認できませんでした。コミュニティの論評(例: MinIO Is Dead, Long Live MinIO)も、おおむねフォークより代替への移行を勧めています。AGPL・単一ベンダーCLAという構造のもとで、財団なしに大規模なGoコードベースを引き受ける主体が現れなかったこと — これがこの一件の静かな教訓の一つです。

代替の実際の状態 — 2026年7月時点

S3 APIが事実上の移植性レイヤーであることは、こうした瞬間にこそ輝きます。アプリケーションコードのほとんどは、エンドポイントと認証情報を差し替えるだけで済みます。問題は、サーバー側の運用特性が3つとも、MinIOとはかなり異なるということです。

Garage — もっとも軽い立ち位置、いまや移行組も狙う

Garageは、フランスのDeuxfleursが開発するRust製の軽量・地理分散S3ストレージで、ライセンスはAGPLv3です(リポジトリのLICENSEで確認)。リリース履歴(自前のGitea基準)を見ると、v2.0.0が2025-06-14 — 管理APIの全面刷新(v2エンドポイント)、replication_modeをreplication_factorとconsistency_modeに分割する破壊的変更 — で、v2.2.0とv1維持ラインのv1.3.1が2026-01-24に並んで出て、最新のv2.3.0は2026-04-16です。

v2.3.0の方向性は意味深長です。garage server --single-nodeでシングルノードクラスタを即座に立ち上げるオプション、環境変数でデフォルトのアクセスキー・バケットを作るブートストラップが入り、リリースノートの表現では、他のS3ストレージプロバイダからの乗り換えを楽にするために、インポートした(imported)アクセスキーの要件を緩和しました。「空のフォルダにminio serverを一つ」で始めていた、まさにあの層を狙った変化です。

限界も設計文書に明記されています。公式のgoals文書は、イレイジャーコーディングをせず複製(duplication)のみを使うと述べています — 3重複製なら保存オーバーヘッドが3倍になるということです。S3 API以上の機能を加える計画がないことも明示的なnon-goalです。プロジェクトの規模も考慮すべきです — 自サイトの資金内訳基準で、2025年の財源はNLnet/NGI0の支援で1.5 FTE規模です。ホームラボ、小規模組織、地理分散の小容量には申し分ない的であり、高密度・大容量の単一DCストレージには設計から向きません。

SeaweedFS — もっとも活発で、もっとも一人に依存する

SeaweedFSはApache-2.0ライセンス(星は約3.3万個)で、リリースの速さは3つの中で最速です — 4.00が2025-11-03、以降は週単位で続き、この記事の時点での最新は4.39(2026-07-10)です。4.00のリリースノートにも、S3 IAM設定ファイル対応などS3表面の改善がずらりと並んでいます。

アーキテクチャはMinIO式の単一バイナリではありません。README基準で、中央のマスターはボリューム配置だけを管理し、メタデータはボリュームサーバーに分散させるblobストアが中核で、その上にディレクトリ・POSIX属性を載せる別のステートレスサーバーFilerがあり、S3 APIはさらにその上のゲートウェイです。イレイジャーコーディングも実装されています(README明記)。つまり小ファイル大量ワークロードに強みがある一方、運用者が理解すべきデーモンの種類はMinIOより多くなります。

正直に指摘すべきリスクは集中度です。GitHub contributors API基準で、創業者chrislusfのコミットは9,968件、ボットを除く2位(530件)とは桁が違います。プロジェクトが死につつあるという意味ではなく — むしろいま最も活発です — バスファクターへの懸念が正当だという意味です。MinIOで単一ベンダーリスクを経験して移る立場なら、検討しておくべき点です。

Ceph RGW — 重いが、ガバナンスが異なる選択肢

CephのRADOS Gateway(RGW)は、S3互換ストレージの中でもっとも長く検証されてきた部類です。現行の安定リリースはTentacle(v20.2.0、2025-11-18 GA)で、この記事の時点で20.2.2まで出ており、Squid(19.2.5)・Reef(18.2.8)が並行してサポート中です。Tentacleの発表文はダッシュボード改善の項目で、RGWのマルチサイト自動化、階層化(tiering)、ライフサイクル、通知、きめ細かなレプリケーションを挙げています — RGWの運用面が着実に磨かれ続けているサインです。

トレードオフはよく知られたとおりです。RGWだけが必要でも、Cephクラスタ(mon・mgr・OSD)がまるごとついてきます。cephadmがインストールの負担をかなり下げたとはいえ、依然として「ストレージチームがいる組織」向けの道具であり、ホームラボ向けではありません。その代わり、今回の一件と正確に対比される利点があります — Cephは、Linux Foundation傘下のCeph Foundationがガバナンスを担う多ベンダープロジェクトであり、一社の事業転換によって配布が止まる形のリスクが構造的に低いのです。

そのほか

Rustで書き直したS3ストレージRustFSのような新興勢力もあります(Apache-2.0、星は約3万個、2026-07-17時点で当日のpushを確認)。ただしデータの堅牢性は、星の数ではなく年月が証明する性質のものです — プロダクションデータを移す前に、各自でトラックレコードを検証してください。

では、いまMinIOを使っているなら

選択肢は4つです。4つとも代償があり、「何もしない」ことにも代償があります。

止まったバイナリで耐える。 2025-10-15以降パッチのないソフトウェアを動かすという決定です。CVE-2025-62506が示したとおり、次の脆弱性の修正はイメージとしては来ません。外部露出がまったくない隔離環境で、期限を区切ったときにのみ正当化されます。
ソースビルドで維持する。 アーカイブされたリポジトリはPRを受け付けないため、この経路は事実上の自前フォークです。Goツールチェーンとビルドパイプライン、そして今後出てくる脆弱性のバックポート判断まで、すべて自分で背負うことになります。
AIStor Freeへ移る。 シングルノードで十分で、プロプライエタリなライセンスキーが許容できる環境なら、率直に言って摩擦がもっとも少ない経路です。分散HAが必要になった瞬間、有料区間(Enterprise Lite、400 TiBの境界)に入ります。
移行する。 アプリケーション側はS3互換のおかげで、たいていエンドポイントの差し替え程度で済みますが、データ移動とIAMポリシー・ライフサイクルルールの翻訳は別作業です(mcもアーカイブされたので、移動にはrcloneのような中立的なツールが無難です)。方向性は上で見たとおり — ホームラボ・小規模・地理分散にはGarage、小ファイル大量・速いリリースを許容できるならSeaweedFS、組織規模・長期的なガバナンス重視ならCeph RGWが基本のマッピングです。

Kubernetes上でminio/operatorに乗せていたデプロイなら、その軸も併せて計画する必要があります — operatorリポジトリは2026年3月20日付でアーカイブされました。

最後に一般化を一つ。この一件の教訓は「MinIOが悪かった」ではなく、単一ベンダーがCLAを握るオープンソースインフラは、そのベンダーの事業転換がそのままプロジェクトの運命になるという、古くからの事実の再確認です。ストレージのようにデータが物理的に居座るレイヤーでは、このリスクは移行コストへ直結します。次の依存関係を選ぶときは、機能表と一緒にガバナンス構造 — 財団所有か、コントリビューターが分散しているか、フォークが実際に可能な規模かどうか — も見てください。

おわりに

記録で確認できたことだけを、もう一度まとめます。MinIO Community Editionは、2025年5月の機能縮小、9~10月の配布停止(最終イメージ9月7日、最終リリース10月15日)、12月のメンテナンスモード、2026年3~7月のリポジトリアーカイブ連鎖という順序で終わりました。ライセンスは最後までAGPLv3のままで、high評価のCVEの修正が公式公開イメージとしては配布されないという形で、転換のコストがユーザーへ回されました。公式な後継であるAIStor Freeは、無料ではあるもののシングルノード専用のプロプライエタリ製品です。

代替は成熟度も性格もそれぞれです — Garageは小さく明快な設計(複製専用、S3以上のことはしない)で小規模・地理分散を、SeaweedFSは速い開発速度と小ファイルの強みを(その代わり創業者への集中を)、Ceph RGWは運用の重さと引き換えに財団ガバナンスと実証された寿命を提供します。完全な後継者はいません。それがこの整理の正直な結論であり、だからこそ選択はベンチマークではなく、あなたの規模・チーム・リスク許容度が決めるべきものです。