Relayium

Relayium と magic-wormhole の比較：CLI ファイル転送

最終更新: 2026-07-12

magic-wormhole は静かに熱心な支持者を集めてきました。実行すると 7-crossover-clockwork のような短く読み上げやすいコードが得られ、それを相手に伝えるだけでファイルが届きます。全行程が暗号化され、アカウントも気にするサーバーも不要です。Relayium CLI も似た発想で作られており、短いコードで2台のコンピュータを直接ペアリングし、その間のすべてを暗号化します。

両者にはかなりの重なりがあり、重ならない部分は正確に述べる価値があります。magic-wormhole が今日、実際に Relayium CLI より頑健な点も含めてです。

両者の共通点

どちらのツールも同じ核心的な課題を、同じ誠実な方法で解決しています。管理下にないサーバーにファイルが留まることはなく、両端が帯域外で受け渡すのは短いコードだけです。magic-wormhole はアカウントが一切不要で、Relayium はサーバーがそのコードを発行できるよう送信側にのみサインインを求め、受信側は依然として不要です。

magic-wormhole がより頑健な1点：リレーを持っている

これは正直なトレードオフであり、ぼかさずはっきり述べる価値があります。magic-wormhole には Transit Relay が同梱されており、両端が互いに直接接続を開けない場合（たとえば両方とも厳格または対称 NAT の内側にいて経路を開通できない場合）にフォールバックできます。リレーが見るのは常に暗号文だけですが、それが存在するおかげで転送は完了します。

Relayium の send/receive は直接接続専用です。ハンドシェイクの直後に数秒間だけ直接接続を試み、見つからなければリレーにフォールバックせずそのまま失敗します。設計上、Relayium のサーバーはネットワークをまたぐ CLI 転送のファイルバイトに一切触れません。実際にはこれは稀なケースです（ほとんどの家庭やオフィスのネットワークは直接経路を許可します）が、両方とも異常に厳格な NAT の内側にある2台のマシン間でファイルを移動する場合、magic-wormhole の方がそのまま動く可能性が高いです。直接経路が見つからず、リレーを避けることより確実性の方が重要なら、magic-wormhole を選ぶべき場面です。あるいは、直接 P2P ホップに依存しない Relayium の push/pull や、到達可能なサーバーへのデーモン直結を使うのも手です。

始める前に

以下はすべて relayium CLI なので、未インストールならまず入れてください。macOS または Linux では、1つのコマンドでビルド済みバイナリが PATH に入ります：

curl -fsSL https://relayium.com/install.sh | sh

SSH とデーモン直結：すでに運用しているサーバーと話す

Relayium CLI が本当に付加価値を持つのは、一回限りのペアリングコードのケースの外側です。すでに持っているインフラを活かし、magic-wormhole がカバーしようとしていない2つの方法があります。

relayium push / pull は既存の SSH アクセスを再利用するため、新しく信頼するものも共有するペアリングコードもありません。push は relayium がまったくインストールされていないサーバーに対しても動作し、SSH 接続上の単純な tar ストリームにフォールバックします。このフォールバックは push 専用です。pull は常にリモートに relayium が必要です。そこでは pull が送信側として動作するためです。

relayium serve は、所有する任意のマシンをデーモン直結のターゲットに変え、証明書ピンニング付きの TLS 1.3 経由で、SSH もペアリングコードもなしにアクセスできます。信頼は最初の接続時に成立し（対話的に承認するか、無人運用向けに事前承認しておく）、以後は固定されます。SSH のホスト鍵と同じ考え方です。

relayium push ./photos user@your-server:backups/
relayium serve --dir ~/incoming
relayium push ./build relayium://your-server

フォルダ同期と、セルフホスト可能なサーバー

magic-wormhole はファイルのバッチ（またはフォルダを圧縮したもの）を送って終了します。相手側を更新するには再度送るしかなく、何を削除すべきかという概念もありません。Relayium CLI は relayium sync を追加し、上記どちらの転送方式の上でも動く増分の一方向ミラーリングを行います。変化した分だけを送り、--delete はソース側から消えたファイルを宛先側からも削除します（daemon は --allow-delete 付きで起動している場合のみこれに従うため、受信側が自らオプトインする必要があります）。--watch はファイルの変化に応じてリアルタイムに再同期し続け、cron ジョブは不要です。

relayium.com に頼らず自分ですべてを運用したい場合、Relayium のサーバーは単一の Docker コンテナとしてセルフホストできます。--server で CLI をそこに向けてください。

relayium sync ./photos user@your-server:backups/photos --delete --watch

機能の一覧比較

最も重要な違いを並べて示します。

よくある質問

Relayium の CLI は無料ですか？

はい、完全に無料です。有料プランはなく、計測するものもありません。どのモードでも両端が直接つながり、CLI はオープンソースです。

アカウントは必要ですか？

send と、クラウドの up で必要です。push/pull は自分の SSH アクセスを使い、デーモン直結はマシン間の TLS 証明書ピンニングによる信頼を使うので、どちらも Relayium アカウントには触れません。send/receive は例外です。ペアリングコードを発行できるのはサーバーだけで、しかもサインイン済みのアカウントに対してだけなので、送信側は一度 relayium login を実行します。相手から渡されたコードを指定した send は発行を行わないのでログインは不要です。受信側にアカウントは決して必要ありません。

厳格な NAT の内側にいて直接経路がない場合はどうなりますか？

その場合 Relayium の send/receive は直接接続専用のため失敗します。リレーにはフォールバックしません。magic-wormhole の Transit Relay は暗号化ストリームを運んで転送を完了させることができます。ネットワークの状況にかかわらず確実に動作させたい場合、magic-wormhole は今日その状況に対応します。到達可能なサーバーに対する Relayium の push/pull やデーモン直結も、直接 P2P ホップに依存しないため同様に動作します。

CLI のペアリングコードは Relayium のブラウザ版と使えますか？

現時点ではリアルタイムのペアリング転送はできません。CLI の send/receive は独自の直接ハンドシェイクを使っており、ブラウザの WebRTC ベースのペアリングフローとは別物なので、今は相互運用できません。ブラウザだけを使って相手にファイルを渡したい場合は、Relayium の保存型ダウンロードリンクか、ブラウザ版自体のペアリングコードモードを使ってください。

セルフホストできますか？

はい。Relayium のサーバーは Docker イメージとして配布されており（docker compose up -d --build）、CLI の send/receive も --server https://your-domain で自分のインスタンスを指定できます。

無料の Relayium CLI をインストールして push、sync、send を試してみましょう。完全無料で、magic-wormhole と同じくらいすぐに始められるコードベースの転送です。

CLI を入手

続けて読む