LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

MinIOとは何か　S3互換オブジェクトストレージの基本

MinIOとは、Amazon S3のAPIと互換性を持つオープンソースのオブジェクトストレージソフトウェアを指します^*1。オブジェクトストレージ（ファイルをオブジェクト単位で管理する保存方式で、メタデータとともにバケットに格納する）として、自社サーバーやプライベートクラウド上に構築できる点が特徴です。

MinIOのソースコードはGNU AGPLv3（GNU Affero General Public License v3、ネットワーク経由の利用でもソース公開義務が生じるライセンス）で公開されてきました^*1。アプリケーション側はAmazon S3向けに書かれたPUT・GETなどのAPI呼び出しをそのままMinIOに向けられるため、既存のS3クライアントツールやSDKを流用できる点が導入のしやすさにつながっています^*2。

単一サーバーでの稼働だけでなく、複数ノードを束ねた分散構成にも対応しており、Linux・macOS・Windows・Kubernetes・Dockerなど幅広い環境で単一バイナリとして動作します^*2。データレイクや分析基盤、AI・機械学習のデータ格納先、バックアップリポジトリなど、S3互換のオブジェクトストレージを自社の管理下に置きたい場面で採用されています^*2。

オープンソース版の提供終了とAIStorへの移行【最新動向】

MinIOを検討する際に外せないのが、オープンソース版（コミュニティエディション）の位置づけが2026年に大きく変わった点です。GitHub公式リポジトリは2026年2月12日付で「THIS REPOSITORY IS NO LONGER MAINTAINED（本リポジトリは保守されていません）」と明記され、その後アーカイブ状態に切り替わりました^*3。新機能の追加や課題・プルリクエストの対応は行われず、コンパイル済みバイナリの配布も終了しています^*3。

後継として案内されているのが「AIStor」です。README上ではAIStor Freeが「コミュニティ利用向けの無償ライセンス版フルスタンドアロン版」、AIStor Enterpriseが「商用サポート付きの分散版」として位置づけられています^*3。ライセンス条項では、AIStor Freeの利用範囲が「standalone mode（分散クラスタリングや高可用性構成を伴わない単一ノード運用）」に限定される旨が明記されています^*4。商用の実運用ワークロードへの利用自体は許可されていますが、対象はあくまで単一ノード構成に限られます^*4。

分散構成やErasure Codingによる高可用性を求める場合は、有償のAIStor Enterprise Lite（水平スケール可能なマルチノード構成、400TiB未満）またはAIStor Enterprise（容量無制限、24時間365日のサポート）を選ぶ形になります^*5。つまり本稿で解説する分散モードやマルチノードのErasure Codingを本番運用で使う場合、現時点では有償ライセンスの取得が前提になるということです^*4*5。この状況を踏まえた上で、次章以降の技術仕様を確認していきます。

Erasure Codingによるデータ保護の仕組み

Erasure Coding（イレイジャーコーディング、データを分割し冗長符号を付加して保存する誤り訂正技術）は、MinIOがデータを保護する中核の仕組みです。Reed-Solomon符号を用いてオブジェクトをデータブロックとパリティブロックに分割し、複数のドライブへ分散して書き込みます^*6。ドライブ1台が壊れても、残りのブロックから元のオブジェクトを復元できる設計です。

MinIOは2〜16台のドライブを1セット（erasure set）として扱い、用意したドライブの総数がこの範囲の値の倍数になるように構成します^*7。デフォルト構成では、ドライブ台数の半分をデータブロック、残り半分をパリティブロックに割り当てます^*6。12ドライブの環境であれば、6データ・6パリティを基準に、10データ・2パリティまでの範囲で構成を調整できます^*6。

もう一つ重要なのがビットロット対策です。ビットロットとは、ドライブ上でデータが徐々に劣化し、検知されないまま破損が進むサイレントデータ破損を指します^*6。MinIOは高速なHighwayHashチェックサムを使い、この種の破損を検出する仕組みを備えています^*6。ドライブの全面的な故障だけでなく、こうした静かな劣化にも備える設計になっている点は、自社でストレージ基盤を持つ際の利点といえます。

分散モードでの耐障害構成

分散モードとは、複数のサーバー（異なる物理マシン）にあるドライブをまとめて1つのオブジェクトストレージとして扱う構成です^*7。ドライブが複数ノードに分散しているため、単一ノードの障害だけでなく複数ノードの同時障害にもデータ保護を維持できる設計になっています^*7。

公式ドキュメントでは、mサーバー・nドライブで構成した分散MinIOについて「m/2台以上のサーバー、あるいはm×n/2台以上のドライブが稼働していればデータは保全される」という基準が示されています^*7。16サーバー構成を例に挙げると、4台までサーバーがオフラインになってもデータへのアクセスを継続できる計算です^*7。容量拡張のためにプールを追加する場合は、既存プールと同じErasure Codingのパリティ設定を維持する必要があります^*7。

この耐障害性は自動的に得られるものではありません。サーバー・ドライブの台数設計、ネットワーク構成、電源系統の分離など、物理インフラ側の設計が伴って初めて意味を持ちます。分散モードの計算式だけを理解していても、データセンター側の冗長化が不十分であれば、想定した可用性は実現できない点に注意が必要です。

バケット・アクセスキーの運用設計

MinIOでオブジェクトを格納する際は、まずバケット（オブジェクトを格納する論理的な入れ物）を作成し、その中にオブジェクトを配置します。バケット単位でポリシーを設定できるため、アプリケーションやチームごとにアクセス範囲を分離する運用が可能です^*2。

クライアントがMinIOへ認証する際は、ユーザーに紐づくアクセスキーとシークレットキーの組を使います^*8。管理コマンド（mc admin accesskey）を使うと、アクセスキーは20文字、シークレットキーは40文字の値を自動生成できます^*8。各アクセスキーは親ユーザーに紐づき、親ユーザーやその所属グループに付与されたポリシーを継承する仕組みです^*8。さらに、アクセスキーの発行時にインラインポリシーを付与すれば、親ユーザーが持つ権限の範囲内でアクセス可能な操作やリソースをさらに絞り込むこともできます^*8。

S3 APIとしては、オブジェクト操作・バケットポリシー・バージョニング・ライフサイクル管理・マルチパートアップロードといった基本機能に加えて、サーバーサイド暗号化、オブジェクトロック、リーガルホールド、バケットレプリケーション、イベント通知、署名付きURLといった機能に対応しています^*9。これらの機能を組み合わせることで、削除保護や外部システムへの通知連携を含む実運用に耐える設計を組めます。

オンプレ・プライベートクラウドでMinIOを選ぶ理由

MinIOがオンプレミスやプライベートクラウドで選ばれる背景には、データ主権（データが物理的にどこに存在し、誰の管理下にあるかを自社で確定できること）への要求があります。業種や契約によっては、データを社外のクラウド事業者の管理下に置けない、あるいは特定の国・拠点内に留める必要があるケースがあります。自社のデータセンター内にS3互換ストレージを構築できれば、こうした要件に対応しやすくなります。

レイテンシの観点も見逃せません。データ処理を行うアプリケーションサーバーと同一のネットワーク内、あるいは同一ラック内にストレージを配置できれば、外部のクラウドサービスにアクセスする場合と比べて通信経路が短くなります。大量データを高頻度で読み書きする分析基盤やAI学習用途では、この物理的な近接性がスループットに影響します。

外部ネットワークから遮断されたエアギャップ環境（インターネットや外部システムとの接続を持たない、または厳格に制限された環境）で稼働できる点もオンプレ構築の理由の一つです。金融・官公庁・製造業の機密データを扱うシステムなど、外部との通信自体をリスクとみなす環境では、クラウドサービスへの常時接続を前提にできません。MinIOであれば、こうした閉じたネットワークの中でもS3互換のAPIでアプリケーションを開発・運用できます。

パブリッククラウドS3との使い分け

パブリッククラウドのS3（Amazon S3など）は、容量やアクセス頻度に応じた従量課金モデルで、インフラの物理的な管理を自社で行う必要がありません。一方、MinIOを自社インフラに構築する場合は、サーバー・ドライブの調達、Erasure Codingやネットワークの設計、稼働後の監視・保守を自社側の責任範囲として持つことになります。どちらを選ぶかは、コストだけでなくデータ主権・レイテンシ・運用体制の3点を軸に判断する必要があります。

比較の軸を整理すると、両者は排他的な選択ではなく、要件に応じて併用されることも少なくありません。例えばアプリケーション本体はオンプレのMinIOでデータ主権を確保しつつ、災害対策用のバックアップ先としてパブリッククラウドのオブジェクトストレージを併用する構成も考えられます。

外注と内製　構築を任せる際の判断軸

MinIOのセルフホスト構築には、専門的な知識が複数の領域にわたって求められます。Erasure Codingのセット設計とパリティ配分、分散モードにおけるサーバー・ドライブ台数の設計、ネットワークやストレージの物理構成、バケットポリシー・アクセスキーを含むIAM（アイデンティティ・アクセス管理）の設計まで、単一の知識では足りません。設計を誤ると、想定していた耐障害性が得られないまま本番運用に入ってしまうおそれがあります。

加えて、前述したオープンソース版の提供終了という動向への対応も必要です。既存システムでコミュニティ版のMinIOを稼働させている場合、セキュリティ修正が今後提供されなくなる可能性があるため、AIStor Freeへの移行かAIStor Enterpriseへのライセンス切り替えかを判断しなければなりません^*3*4。この移行判断は恒久的な変更であり、一度AIStorに切り替えると元のコミュニティ版には戻せない点も踏まえた計画が必要です^*4。

内製で対応する場合、Erasure Codingや分散モードの設計知識を持つ人員の確保、AIStorのライセンス動向を継続的に追う体制、稼働後の監視・パッチ適用までを担う人員が必要になります。要件定義からインフラ設計、構築、稼働後の運用保守までを一貫して依頼できる外部パートナーに委ねる選択肢は、この体制構築の負担を軽減する手段になります。委託先を選ぶ際は、Erasure Coding・分散モードの設計実績と、AIStorのライセンス体系を踏まえた提案ができるかどうかを確認することが、導入後の手戻りを防ぐ観点で重要です。

まとめ：MinIO構築で押さえるべき3つの判断軸

本稿では、MinIOのS3互換性とErasure Coding・分散モードの技術的な仕組み、オンプレでMinIOを選ぶ理由、そしてオープンソース版の提供終了とAIStorへの移行という最新動向を整理しました。要点を3つに集約すると、第一にErasure Codingと分散モードの設計が耐障害性を左右する技術的な土台になっている点、第二にデータ主権・レイテンシ・エアギャップ要件がある場合にオンプレのMinIOとパブリッククラウドS3を使い分ける判断が必要になる点、第三にオープンソース版の保守終了に伴いAIStor Free（単一ノード）かAIStor Enterprise（分散構成・有償）かのライセンス判断が避けられない点です。自社の要件と体制を踏まえ、これら3つの軸で構築方針を検討することが求められます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：MinIO「minio/minio: MinIO is a high-performance, S3 compatible object store」（GitHub）
2. *2　出典：MinIO「High Performance Data Store for AI & Analytics」（MinIO公式サイト）
3. *3　出典：MinIO「minio/minio README」（GitHub、2026年2月アーカイブ）
4. *4　出典：MinIO「MinIO AIStor Free Tier License Agreement」（MinIO公式サイト）
5. *5　出典：MinIO「Introducing New Subscription Tiers for MinIO AIStor: Free, Enterprise Lite, and Enterprise」（MinIO公式ブログ）
6. *6　出典：MinIO「MinIO Erasure Code QuickStart Guide」（GitHub）
7. *7　出典：MinIO「MinIO Distributed Server Design Guide」（GitHub）
8. *8　出典：MinIO「mc admin accesskey」（MinIO AIStor Documentation）
9. *9　出典：MinIO「S3 API Compatibility」（MinIO AIStor）

Tweet