
MinIO を使おうとして、ライセンスのことを調べ始めた瞬間に面倒になった経験はないでしょうか。
「とりあえず法務に確認してから進めよう」という判断が入ると、スプリントが一本止まる感覚になりますよね。
Apache 2.0 ライセンスの S3 互換ストレージ RustFS を Docker Compose で立ち上げ、AWS CLI と boto3 から疎通確認するところまでを一気に走ります。
MinIO との違いを押さえながら、既存の S3 資産(CLI スクリプト・SDK・業務システム)がどこまでそのまま動くかを、実際に手を動かして確認します。
MinIOのAGPLライセンス、現場でどこが引っかかるのか
AGPL(GNU Affero General Public License v3)は、ネットワーク越しにソフトウェアを提供した場合にもソースコード公開を義務付けるライセンスです。
GPL がバイナリ配布のタイミングでソース公開を求めるのに対し、AGPL は「ネットワーク越しにサービスとして提供する」という行為まで対象を広げています。
クラウド時代の「ASP ループホール」を塞ぐために設計されたライセンスで、MinIO はこの AGPL を採用しています。
「社内システムなら問題ないのでは」と思う方も多いのですが、ここが少し微妙な部分です。
AGPL の開示義務は外部ユーザーへのサービス提供が発生したときに本格的に動きます。
純粋な社内利用であれば範囲は限定的なのですが、SaaS として顧客にサービスを提供している場合や、MinIO を組み込んだシステムをパートナー企業向けに展開するケースでは話が変わってきます。
さらに難しいのが、「AGPL コードと自社プロプライエタリコードを統合してネットワーク越しに提供した場合、自社コードにも開示義務が波及する可能性がある」という点です。
この「統合」の境界線がどこにあるかは技術的な判断だけでは決めにくく、法的な解釈の余地があります。
MinIO 社はデュアルライセンス戦略を採っており、商用ライセンスを購入すれば AGPL を回避できますが、そのための手続きとコストが発生します。
現場エンジニアが感じる摩擦は、「ライセンス違反かどうか」より手前の段階に宿っています。
「この使い方で AGPL が適用されるのか」を技術チームだけで判断できず、法務確認を挟まないといけない。
その確認待ちそのものが開発速度を落とす。
新しい環境にサクッと試したいだけなのに、そういう一手間がのしかかるわけです。
だからこそ Apache 2.0 ライセンスで提供されている RustFS が選択肢に入ってきます。
RustFSとは何か:Rust製であることの実際的な意味
RustFS は Rust で書かれた S3 互換の分散オブジェクトストレージです。
Apache 2.0 ライセンスで公開されており、商用利用・改変・再配布に対して AGPL のような制約がありません。
「法務確認なしでとりあえず動かせる」という状態が最初から確保されている点が、現場での導入障壁を大きく下げます。
Rust 製であることの実務上の特性を整理しておきます。
- GC ポーズがない: Rust にはランタイムのガベージコレクションが存在しません。GC ポーズ由来の突発的なレイテンシスパイクが起きないため、レイテンシの安定性という観点で有利です。「なんとなく詰まる瞬間がある」という挙動を避けられます。
- メモリ安全: コンパイル時の所有権チェックにより、バッファオーバーフローや use-after-free 系のバグが入り込みにくい構造になっています。
- バイナリ単体配布: 依存ランタイムを別途インストールする必要がなく、コンテナイメージをシンプルに保てます。
- 小オブジェクト・高並列に強い: 2025 年中頃に GitHub Issue #73 で公開された独立ベンチマークでは、小オブジェクト・高並列ワークロードで RustFS が MinIO の最大 2.3 倍速いという結果が出ています。
ただし、同じベンチマークでは大容量シーケンシャル読み取り(20 MiB オブジェクト、4 ノードクラスタ)で MinIO が約 53 Gbps・TTFB 24 ms に対し、RustFS は約 23 Gbps・TTFB 260 ms と差が開いています。
原因は非同期ストリーミングが十分に最適化されていないブロッキング I/O と特定されており、ロードマップには載っています。
「Rust だから無条件に速い」ではなく、ワークロードの特性によって得手不得手がある、という点は頭に入れておきましょう。
成熟度の観点では、MinIO より後発であることは正直に認めます。
エンタープライズ向けの細かな機能(レプリケーション設定の柔軟性・ライフサイクル管理の網羅度など)はまだ発展途上です。
一方で「AI エージェントのファイル保管・業務システムのドキュメント管理・開発環境のオブジェクトストレージ」といった小〜中規模のユースケースであれば、今でも十分に実用的な選択肢です。
Docker ComposeでRustFSを30分で立ち上げる
まず最初にやるべきことは、ホスト側のデータディレクトリを作って権限を設定することです。
RustFS コンテナは非 root ユーザー(UID/GID 10001:10001)で動くため、バインドマウントするディレクトリがそのユーザーから書き込めない状態だと起動時に permission denied で詰まります。
これが一番よくあるつまずきポイントなので、compose を書く前に先にやっておきましょう。
mkdir -p ./data/rustfs
sudo chown -R 10001:10001 ./data/rustfs
準備ができたら、docker-compose.yml を用意します。
services:
rustfs:
image: rustfs/rustfs:latest
container_name: rustfs
ports:
- "9000:9000" # S3 互換 API エンドポイント
- "9001:9001" # Web コンソール
environment:
RUSTFS_ACCESS_KEY: rustfsadmin # アクセスキー(任意の文字列)
RUSTFS_SECRET_KEY: rustfsadmin123 # シークレットキー(16文字以上推奨)
RUSTFS_VOLUMES: /data # コンテナ内のデータ保存先
RUSTFS_ADDRESS: ":9000" # S3 API のリスニングアドレス
RUSTFS_CONSOLE_ADDRESS: ":9001" # Web コンソールのリスニングアドレス
volumes:
- ./data/rustfs:/data # ホストディレクトリをバインドマウント
restart: unless-stopped
ポート 9000 が S3 互換 API、9001 が Web コンソールです。
MinIO と同じポート番号をデフォルトにしているため、既存の設定をそのまま流用しやすくなっています。
シークレットキーは短すぎると起動時に警告が出ることがあるので、16 文字以上にしておきましょう。
起動コマンドはシンプルです。
docker compose up -d
# ログを確認したい場合
docker compose logs -f rustfs
コンテナが正常に起動したら、ブラウザで http://localhost:9001 を開いてみてください。
設定したアクセスキーとシークレットキーでログインできれば、Web コンソールの画面が表示されます。
ここまで来たら S3 API も動いているはずです。
AWS CLIで疎通確認:バケット作成からファイルのアップロードまで
Web コンソールが開いたら、AWS CLI からも確認します。
--endpoint-url にローカルの RustFS アドレスを渡すだけで、あとは通常の S3 操作とまったく同じコマンドが使えます。
最初に aws configure で認証情報を登録しておきます。
リージョンは RustFS が参照しないので、us-east-1 のような任意の値で大丈夫です。
aws configure
# AWS Access Key ID [None]: rustfsadmin
# AWS Secret Access Key [None]: rustfsadmin123
# Default region name [None]: us-east-1
# Default output format [None]: json
設定が済んだら、バケット作成からオブジェクト操作までを一気に通します。
# バケット作成
aws --endpoint-url http://localhost:9000 s3 mb s3://my-bucket
# テキストファイルを作ってアップロード
echo "hello rustfs" > hello.txt
aws --endpoint-url http://localhost:9000 s3 cp hello.txt s3://my-bucket/
# バケット内のオブジェクト一覧を確認
aws --endpoint-url http://localhost:9000 s3 ls s3://my-bucket/
ls の結果に hello.txt が表示されれば、S3 互換 API が正常に動いています。
ここで実感できるのが、既存の CLI スクリプトや CI/CD パイプラインへの影響が ほぼゼロ という点です。
AWS S3 向けに書かれたシェルスクリプトでも、エンドポイント URL の向き先を差し替えるだけで RustFS に流すことができます。
「S3 互換」という言葉の意味が、ここで体感として確認できます。
boto3から繋ぐ:AIエージェント・業務システムへの組み込みイメージ
AWS CLI で動いた確信が持てたら、Python からも確認しておきましょう。
boto3 では S3 クライアントの初期化部分に endpoint_url とパススタイルのアドレッシング設定を加えるだけで、接続先を RustFS に切り替えられます。
以下は、バケット作成・ファイルアップロード・ダウンロードを一本にまとめた最小スクリプトです。
import boto3
from botocore.config import Config
# クライアント初期化:endpoint_url と addressing_style の指定だけが差分
s3 = boto3.client(
"s3",
endpoint_url="http://localhost:9000",
aws_access_key_id="rustfsadmin",
aws_secret_access_key="rustfsadmin123",
region_name="us-east-1",
config=Config(s3={"addressing_style": "path"}),
)
# バケット作成
s3.create_bucket(Bucket="my-bucket")
# ファイルアップロード
s3.upload_file("hello.txt", "my-bucket", "hello.txt")
# ファイルダウンロード
s3.download_file("my-bucket", "hello.txt", "downloaded.txt")
print("完了")
addressing_style を path に設定しているのは、セルフホスト環境では RustFS へのアクセスがパススタイル(http://localhost:9000/bucket/object)になるためです。
デフォルトのバーチャルホストスタイル(http://bucket.localhost:9000/object)はローカルでは DNS 解決が通らないことが多いので、セルフホスト時は path を明示しておくのが安全です。
業務システムや AI エージェントへの組み込みも、同じ要領で対応できます。
LangChain のドキュメントローダーや AI エージェントのファイル保管機能が boto3 を使っている場合、クライアントを生成する一箇所を書き換えるだけで保管先を RustFS に向けられます。
RAG パイプラインで PDF をオブジェクトストレージに置いているなら、S3 クライアントの初期化ブロックを差し替えるだけで完結します。
本番運用を考えるなら、いくつか確認しておく点があります。
使用するイメージのバージョンを latest ではなく特定タグに固定すること、レプリケーション設定が自分のユースケースに対して十分な成熟度にあるかの確認、認証情報を環境変数やシークレット管理ツールに逃がすこと。
「今すぐ使えないわけではないが、MinIO ほどの実績の厚みはまだない」というのが現時点での正直な見立てです。
開発ペースが速いプロジェクトなので、公式の Changelog とロードマップを定期的に確認しておくと、機能の成熟状況を追いやすいです。
ライセンスの余計な摩擦を排除しながら、S3 互換の既存資産をそのまま活かしたい用途であれば、RustFS はすぐ試す価値のある選択肢だと思います。
株式会社ホコサキは山口県宇部を拠点に、Web 制作・業務システム開発・AI 活用支援・DX 推進に取り組んでいます。
「セルフホストで S3 互換のストレージ基盤を整えたい」「既存システムへのオブジェクトストレージ組み込みを相談したい」という方は、お気軽にご連絡ください。
お問い合わせはこちら

