drivebase解説｜複数クラウドをブラウザの仮想デスクトップで束ねるセルフホスト型ファイル管理OSS

クラウドストレージは増えるほど散らかる。 仕事用のGoogle Drive、バックアップ用のS3、共有用のDropbox。 それぞれ別のタブ、別のログイン、別の操作感で開くことになる。

drivebase は、この散らばりを1つのブラウザ画面にまとめるセルフホスト型のファイル管理OSSだ。 複数のクラウドストレージを接続し、横断して閲覧・転送・削除できる。

セルフホスト型のインフラ系OSSをどう選ぶかという視点では、AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 もあわせて参照すると、ツール選定の軸を整理しやすい。

drivebaseとは何か

drivebaseは、作者 Monawwar Abdullah（GitHub: @mxvsh）が中心となって開発するオープンソースのファイル管理プラットフォームだ。 リポジトリの説明文は「複数のストレージプロバイダを使う個人やチームのための、クラウド非依存なファイル管理プラットフォーム」と書かれている。

タグラインは「Your cloud storage. One desktop. Runs anywhere.」。 日本語にすると「手元のクラウドストレージを、1つのデスクトップで、どこでも動かす」になる。

数字で輪郭をつかむと次のようになる。

・GitHubスター244、Fork 29、Watch 3（2026-06-18時点、GitHub APIで実測）
・初コミットは2025-03-09。リリースは累計84本
・最新の正式リリースはv4.0.0（2026-06-03）。mainブランチのpackage.jsonは次サイクルの4.0.0-beta.1
・言語構成はTypeScriptが98%。残りはCSS・Shell・Dockerfileなど
・主要コントリビュータはほぼ1名（@mxvshが362コミット、他は数コミット規模）

作者の@mxvshはAppointy所属を公言し、開発者向けソフトやOSSを多数公開している人物だ。 個人が主導するプロジェクトという規模感は、採用判断の材料として頭に入れておきたい。 リポジトリのトピックにはbun・docker・s3・self-hosted・file-managerなどが並び、想定する利用層がセルフホスト志向の開発者寄りであることが読み取れる。

READMEには動作を映したデモ動画へのリンクと、コードベースを質問形式で読めるDeepWikiのバッジが置かれている。 実際の挙動を先に見たい場合は、READMEのデモ動画から触り心地を確かめる入口がある。

スコープははっきりしている。 drivebaseはファイルの保管庫そのものではない。 ファイルは接続先の各クラウドに置かれたままで、drivebaseはそれらを横断して操作する管理層として動く。

drivebaseが解決する問題

複数のクラウドストレージを併用すると、3つの面倒が積み上がる。

1つ目は、コンテキストの切り替えだ。 Google Driveのタブ、S3のコンソール、Dropboxのアプリを行き来するたびに、操作のお作法が変わる。

2つ目は、プロバイダをまたぐ移動の難しさだ。 S3にあるファイルをDropboxへ移したいだけなのに、いったんローカルへダウンロードして再アップロードする、という遠回りになりがちだ。

3つ目は、全体像の把握だ。 どのクラウドにどれだけ容量を使っているのか、横並びで見える場所が標準では用意されていない。 容量が逼迫してから慌てて確認する、という後手に回りやすい。

drivebaseはこの3つに対して、1つの統合UIで答えを出そうとする。 接続したプロバイダのフォルダを同じ画面で開き、ファイルをプロバイダ間で直接転送し、容量の使用状況をプロバイダごとに並べて表示する。

ダウンロードと再アップロードの往復をUIの中に畳み込む、という発想がdrivebaseの軸になっている。

似た課題に答える既存ツールはあるが、多くはCLIか、単一ウィンドウのWeb UIだ。 drivebaseはここに「ブラウザの中のデスクトップ」という操作モデルを持ち込み、複数のプロバイダ画面を同時に開いて見比べながら作業できる形を狙う。 ファイルをドラッグして別プロバイダのウィンドウへ落とす、という直感的な操作を、Webの統合UIで再現しようとしている。

アーキテクチャ全体像

drivebaseはモノレポ構成で、役割ごとにアプリとパッケージが分かれている。 リポジトリのapps配下には、API、ワーカー、Web、テレメトリ、アップデータが並ぶ。

実行ランタイムにはBunを採用する。 APIはGraphQL Yoga、リアルタイム通知はgraphql-sse、バックグラウンド処理はBullMQ、永続化はPostgreSQL（Drizzle ORM）、キャッシュとキューはRedis（ioredis）、認証はBetter Authという組み合わせだ。

全体の流れを図にすると次のようになる。

apps配下には、Web・APIに加えてワーカー、テレメトリ、アップデータが分かれて置かれている。 テレメトリは利用イベントの収集、アップデータはバージョン更新の補助を担う独立アプリだ。 役割をアプリ単位で切ることで、APIの応答とバックグラウンドの重い処理が互いを止めにくくなる。

packages配下には、共通インターフェースを担うパッケージ群が置かれている。 providers（各クラウドの実装）、storage、upload-staging（アップロードの中継）、db、cache、kernel、ui、loggerなどだ。 プロバイダ実装をpackages/providersに閉じ込め、ほかのパッケージは共通の抽象だけを見る構造になっている。

ファイル転送のような重い処理は、APIが直接さばかずBullMQ経由でワーカーに渡す。 設定ファイルでは、アップロード・ダウンロード・転送・コピー・移動・削除の同時実行数をそれぞれ4、同期や容量更新は1、プレビュー生成は2、と用途ごとに並列度を調整できる。

upload-stagingは、アップロード中のチャンクを一時的に受け止める中継の役割を持つ。 再開可能アップロードがブラウザのリロードをまたいで続くのは、この中継とチャンク管理があるためだ。 プレビューは最大辺400ピクセルに縮小し、512MBを上限にローカルへキャッシュする設定になっている。 小さな画像から先に見え始めるのは、この縮小とキャッシュの効果だ。

主要機能の詳細

READMEが挙げる機能を、使う側の言葉で並べ直す。

仮想デスクトップUI が見た目の核になる。 ファイル、プロバイダ、設定といった画面が、移動やリサイズができるウィンドウとして開く。 タスクバーを備え、ブラウザの中なのにネイティブのファイルマネージャに近い操作感を狙った設計だ。

統合ファイルブラウザ は、接続した全プロバイダのフォルダを1か所で辿れる。 S3のバケットもGoogle Driveのフォルダも、同じツリーの中に並ぶ。

バッチ操作 は、コピー・移動・転送・削除をまとめて実行する。 実行前に競合を解析する「プリフライト」が入り、上書きが起きそうな箇所を先に洗い出す。

スマートな競合解決 は、衝突が起きる前に検知し、上書き・スキップ・リネーム・手動確認から選ばせる。 転送を走らせてから事故に気づく、という事態を避ける作りだ。 同名ファイルが転送先にある、容量が足りない、といった問題を実行前のプリフライトで洗い出し、その場で方針を決めてから処理を流す。 大量のファイルを一括で移すときほど、この事前チェックが上書き事故の保険になる。

リアルタイム進捗 は、Server-Sent Events（SSE）で操作状況を流す。 ポーリングを使わずに、転送の進み具合が画面に反映される。

再開可能アップロード は、チャンク分割したアップロードセッションがブラウザのリロードをまたいでも継続する。 大きなファイルの途中でタブを閉じても最初からやり直しにならない。

S3への直接アップロード は、署名付きのマルチパートURLを使い、クライアントからS3へ直接送る。 サーバーを経由しないぶん、サーバー帯域のボトルネックを避けられる。

このほか、プロバイダごとの容量・使用状況の追跡、新しいバックエンドを足しやすいIStorageProviderインターフェース、すべての機能を型付きで公開するGraphQL APIが並ぶ。

GraphQL APIは、UIが使う操作をそのまま外から呼べる窓口になる。 ファイル一覧の取得や転送の起動を型付きのスキーマで叩けるため、自前のスクリプトや別アプリからdrivebaseの機能を再利用する余地が生まれる。 READMEはこのAPIを「すべての機能を公開する」と位置づけており、UIはこのAPIの利用者の一つという見立てだ。

IStorageProviderの抽象は、対応プロバイダが増えていく前提を支える。 Dropboxとも OneDriveも、v4.0.0でこの共通インターフェースの実装として加わった。 Box・Azure Blob・SFTPが計画項目として並ぶのも、同じ抽象に乗せれば足せるという見通しがあるからだ。

なお、CHANGELOGには「use dark mode only」というスタイル変更が記録されており、現状のUIはダークモード固定だ。 v4.0.0では画像のプレビュー対応や、テレメトリのレート制限・ペイロードサイズ上限の追加も入っている。

対応するクラウドサービス一覧

対応プロバイダはREADMEのチェックリストで管理されている。 有効化済みと計画中をはっきり分けて読むのが大事だ。

DropboxとOneDriveは、2026-06-03のv4.0.0で追加されたばかりだ。 CHANGELOGに「add dropbox provider」「add onedrive provider」というコミットが残っている。

接続したプロバイダは、共通の抽象を通して同じように扱われる。 ユーザーから見たファイル操作と、その裏で各クラウドのAPIへ翻訳される流れを図にすると次のようになる。

S3互換に幅広く乗っている点は実務で効く。 Cloudflare R2やMinIOを自前で運用している環境なら、追加のプロバイダ実装を待たずにそのまま接続できる。

導入手順

最短経路はDockerだ。 READMEのクイックインストールは、インストーラを実行してComposeと設定ファイルを生成する。

# Docker Compose と config.toml を生成（シークレットは自動生成）
curl -fsSL https://drivebase.io/install | bash

cd drivebase
docker compose up -d
# ブラウザで http://localhost:4000 を開く

ソースから動かす場合は、Bun 1.3.5以上、PostgreSQL 15以上、Redis 7以上を用意する。

git clone https://github.com/drivebase/drivebase.git
cd drivebase
bun install

# 設定ファイルを用意
cp packages/config/config.example.toml config.toml

# マイグレーション実行
bun run db:migrate

# 開発サーバー起動（API: 4000 / Web UI: 3000）
bun run dev

設定はconfig.tomlに集約される。 最小限で埋めるべき項目は、サーバー、データベース、Redis、暗号鍵、認証だ。

[server]
env = "prod"
port = 4000
host = "0.0.0.0"

[db]
url = "postgres://user:password@localhost:5432/drivebase"

[redis]
url = "redis://localhost:6379/0"

[crypto]
# openssl rand -base64 32 で生成
masterKeyBase64 = "<base64エンコードした32バイト鍵>"

[auth]
# openssl rand -hex 32 で生成
betterAuthSecret = "<長いランダム文字列>"
baseUrl = "http://localhost:4000"
trustedOrigins = ["http://localhost:3000"]

config.tomlには、このほかにキャッシュのTTL（フォルダ一覧60秒、容量600秒）、ワーカーの並列度、プレビューの最大辺400ピクセルやキャッシュ上限512MBといったチューニング項目も並ぶ。 開発用のcompose.ymlは、PostgreSQL（pgvectorイメージ）、Redis、MinIOをまとめて立ち上げる構成になっている。 MinIOが同梱されるので、外部のS3アカウントを用意しなくても手元でS3互換の挙動を試せる。

本番向けには、リポジトリにcompose.prod.ymlが別途用意されている。 クイックインストールが生成するComposeはこの本番構成をベースにしており、シークレットは自動生成される。 外部に公開する場合は、auth.trustedOriginsとbaseUrlを実際のドメインに合わせ、リバースプロキシでHTTPSを終端する前提で設計を組むことになる。

設定の核は4つの値だ。 データベースURL、Redis URL、暗号化のマスター鍵、認証シークレット。 このうちマスター鍵と認証シークレットは外部から推測できない乱数で、一度決めたら使い回さず安全に保管する。

rclone・Filestash・OpenCloudとの違い

同じ「複数ストレージを扱うOSS」でも、得意分野と前提が違う。 代表的な3つと並べて立ち位置を切り分ける。

rcloneは、コマンドで同期やマウントを自動化したいときの定番だ。 Go製でスター約5.8万、対応プロバイダ数は70近くと群を抜く。 cronで定期バックアップを回す、リモートをローカルにマウントする、といった自動化はrcloneの土俵になる。 反面、操作はCLIが基本で、複数クラウドを目で見て手作業で整理する用途は得意ではない。

Filestashは、Webのファイルマネージャとして成熟している。 Go製でスター約1.4万、S3・FTP・SFTPなど多様なバックエンドに対応する。 ライセンスがAGPL-3.0なので、改変版をネットワーク越しに提供する場合のソース公開義務に注意が要る。

OpenCloudは、ownCloud系譜の組織向けプラットフォームで、ファイルの共有や共同編集まで含む。 Go製・Apache-2.0・スター約5,600で、用途は単なる横断管理より広い。 チームの共同作業基盤を求めるならOpenCloud、複数クラウドの操作窓口を1つにしたいならdrivebase、と目的で分かれる。

drivebaseが埋めるのは、「ブラウザの統合UIで複数クラウドを手作業で束ね、プロバイダ横断の転送を1操作で回す」という位置だ。 図にすると、操作系（CLIかWeb UIか）と守備範囲（同期特化か統合管理か）の2軸で見分けられる。

自動化を組みたいならrclone、ブラウザで束ねたいならdrivebase、という補完関係に近い。 実際、rcloneでバックアップを自動化しつつ、日々の手作業はdrivebaseで、という併用も成り立つ。

想定ユースケース

drivebaseが噛み合う場面は、複数クラウドを日常的に行き来する運用だ。

第一に、個人の散らばったストレージの一元化だ。 無料枠を稼ぐために複数サービスに分散したファイルを、1画面で見渡してS3の安いバケットへ寄せる、といった整理に向く。 どのサービスにどれだけ容量を使っているかが横並びで見えるため、片付けの優先順位を付けやすい。

第二に、小規模チームの共有ストレージ運用だ。 Google DriveとS3を併用するチームが、自前サーバーにdrivebaseを立てて窓口を1つにまとめる。 ファイルの実体は各クラウドに残るので、既存の権限やバックアップの仕組みを壊さずに操作の入口だけを集約できる。

第三に、クラウド移行の作業台だ。 あるプロバイダから別のプロバイダへファイル群を移す際、競合チェック付きのバッチ転送が効く。 S3への直接アップロードや再開可能アップロードがあるため、大量・大容量の移送でも途中で止まりにくい。

実際の操作フローは、接続から転送まで一直線に進む。

逆に噛み合わないのは、コマンドでの定期同期を主目的にする運用だ。 そこはrcloneのほうが素直に組める。

認証情報の暗号化とデータの扱い

セルフホスト型でクラウドの資格情報を預ける以上、鍵の扱いは確認しておきたい。

drivebaseは、各プロバイダの接続情報をcrypto.masterKeyBase64 という32バイトのマスター鍵で暗号化する設計だ。 READMEはこの鍵を openssl rand -base64 32 で生成するよう案内する。 認証はBetter Authのクッキーベースを採用する。

クイックインストール経路では、これらのシークレットが自動生成される。 公式サイトは「何も自分のインフラの外に出ない」と説明しており、セルフホストの前提に沿った設計になっている。

一方で、線引きも明確にしておきたい。 drivebaseが暗号化するのは接続情報であって、ファイル本体は接続先の各クラウドに置かれたままだ。 ファイルの暗号化やバックアップは、結局のところ各プロバイダ側と運用者の責任範囲になる。

マスター鍵を失えば、保存済みの接続情報は復号できなくなる。 鍵そのもののバックアップと保管は、運用設計の最初に決めておくのが安全だ。

クッキーベースの認証を採る以上、公開運用ではHTTPSの終端が前提になる。 平文HTTPで外部に晒すと、セッションクッキーが盗まれる経路を自分で開けることになる。 設定のtrustedOriginsで許可元を絞り、リバースプロキシでTLSを終端する構成が基本線だ。

S3への直接アップロードは、署名付きのマルチパートURLを使う。 この方式はサーバー帯域を節約する一方で、URLの有効期限やスコープの設計が効いてくる。 細かな権限設計は接続するS3側のIAMやバケットポリシーに依存するため、最小権限のキーを発行して渡すのが堅い。

制限事項と既知の課題

採用判断の前に、現実の角も見ておく。 2026-06-18時点のOpen Issuesと公開情報から拾える注意点は次のとおりだ。

・コピー&ペースト未実装（#67）。基本的なファイル操作の一部がまだ揃っていない
・CLI未提供（#103）。操作はWeb UI前提で、コマンドからの利用は要望段階
・プレビューが効かないとの報告（#135）
・Termux環境で動かない（#139）、Raspberry Pi 4でクラッシュ（#138）など、低リソース環境での不安定さ
・主要コントリビュータがほぼ1名で、スター244という規模感。バス係数の低さは個人主導OSSの宿命として織り込みたい

加えて、開発の鮮度も両面で見たい。 v4.0.0が2026-06-03に出たばかりで機能追加が活発な反面、破壊的変更が続く可能性もある。 mainは4.0.0-beta.1へ進んでおり、バージョン更新時はマイグレーションとバックアップを前提にしたい。

セルフホストで運用するなら、ファイル管理単体ではなくバックアップやログ収集も併せて設計したい。 データのバックアップは Databasement完全解説：MySQL/PostgreSQL/MongoDBを一括管理するセルフホスト型バックアップOSS が、運用ログの集約は Log Bull徹底解説：Docker一発で立つOSSログ収集システム、ELK/Lokiの軽量代替 が、同じセルフホスト前提の道具立てとして組み合わせやすい。

機能の歯抜けは、Issueの顔ぶれにも表れている。 copy/paste（#67）、CLI（#103）、ファイル操作ツールの実装（#130）、サイドバーへの個別ストレージのマウント（#129）、オンボーディングの刷新（#111）といった要望が並ぶ。 逆に言えば、基本機能はまだ拡充の途中で、ロードマップが公開のIssueとして見える状態にある。

これらは「使えない」という話ではなく、「重要データの唯一の管理経路にする前に検証を挟む」ための材料だ。 評価環境で対応プロバイダと転送挙動を確かめてから本番に寄せる順序が無難になる。 特にDropboxやOneDriveはv4.0.0で入ったばかりのため、これらを主軸に使うなら自分のファイル種別での挙動確認を先に済ませたい。

ライセンスと料金、Drivebase Cloud

ライセンスは、導入前にもっとも丁寧に確認したい部分だ。

READMEの末尾は「MIT」と書かれ、MITライセンスを宣言している。 ところが2026-06-18時点のリポジトリには、リンク先となるLICENSEファイルが存在しない。 該当パスはGitHub上で404になり、ライセンスの自動判定もnone、package.jsonにもlicenseフィールドがない。

意図がMITであることは表記から読み取れる。 それでもライセンス本文が同梱されていない以上、現状を「MITで配布されている」と断定はできない。 商用や社内導入を検討するなら、最新リポジトリでLICENSEファイルの整備を確認するか、作者へ確認するのが堅実だ。

料金面では、セルフホストに費用は発生しない。 別にREADMEのバッジから、運営側が管理するDrivebase Cloud（cloud.drivebase.io）の存在が確認できる。 ただしそのページは2026-06-18時点でサインイン画面のみが表示され、料金プランの公開ページを確認できなかった。 本記事では、managed版の具体的な価格は未確認として扱う。

セルフホスト版は無料で自前運用、managed版は別途提供、という二本立ての構図だけが現時点で読み取れる事実だ。

まとめ

drivebaseは、増えすぎたクラウドストレージを1つのブラウザ画面に束ねるセルフホスト型のファイル管理OSSだ。

仮想デスクトップというUXと、TypeScript / Bun / GraphQLという構成、プロバイダ横断のバッチ転送を競合チェック付きで回す設計が持ち味になる。 Google Drive・S3・ローカル・Dropbox・OneDriveの5系統に対応し、Dockerで自前サーバーに設置できる。

一方で、スター244・主要開発者ほぼ1名という規模、コピー&ペーストやCLIが未整備な点、そしてLICENSEファイルが同梱されていない点は、導入前に天秤にかけたい。 コマンドでの自動化が主目的ならrcloneのほうが素直で、drivebaseはブラウザで手作業の窓口を1つにまとめたい場面で光る。

向いているのは、複数クラウドを日常的に行き来し、ブラウザの統合UIで手作業を1か所にまとめたい個人や小規模チームだ。 逆に、定期同期の自動化が主目的なら、まずrcloneを検討するほうが近道になる。

評価環境で対応プロバイダと転送挙動を確かめ、バックアップ前提で扱うところから始めるのが、現時点での現実的な付き合い方になる。 LICENSEファイルの整備状況とmanaged版の料金は、本番採用の前にとくに最新情報を確かめたい2点だ。 最新の正確な仕様は、本記事末尾の典拠に挙げた一次ソースを起点に確認してほしい。

参照ソース

・drivebase/drivebase 公式リポジトリ（README）
・drivebase CHANGELOG（v4.0.0まで）
・drivebase config.example.toml（設定項目）
・drivebase Issues（既知の課題）
・Drivebase 公式サイト
・作者 Monawwar Abdullah（@mxvsh）GitHubプロフィール
・rclone 公式リポジトリ・Filestash 公式リポジトリ・OpenCloud 公式リポジトリ