コマンドラインでファイルを受信する

最終更新: 2026-08-06

送信は話の半分にすぎません——いずれ受け取る側になります。同僚がインターネット越しにファイルを渡したいとき、自分のマシン同士で受け渡ししたいとき、あるいは自分が管理するサーバーから何かを取りに行きたいとき。Relayium CLI はそれぞれに異なるコマンドで、この3つすべてに対応しています。どれもアカウントは不要です。

相手がペアリングコードでこちらへプッシュしてくるなら receive、信頼できるマシンがいつでもプッシュできる常設の受信箱が欲しいなら serve、そして自分からすでに SSH でログインできるサーバーへ出向くなら pull を選びます。

受信の3つの方法と、それぞれが当てはまる場面

どのコマンドを使うかは、誰が転送を始めるのか、そして2台のマシンがどう互いを知っているかによって決まります:

relayium receive <code> [destdir] ——相手の CLI が発行し、帯域外で伝えられたペアリングコードを使って、相手がネットワークを越えて送ってきます。直接ピアツーピアで、照合用の SAS コードが表示されます。
relayium serve [--dir D] [--port N] [--once] [--allow-delete] ——このマシンがデーモン直結の relayium:// プッシュを待ち受けます。デフォルトのポートは 9031 です。
relayium pull [user@]host:src <dest> ——自分からすでにログインできるサーバーへ SSH で出向き、ファイルを取り込みます。

receive: 相手がネットワークを越えてファイルを送ってくる

手順1の前に必要なもの

このマシンに CLI。relayium version はバージョン文字列を表示します。command not found と返るなら、ここにはまだ入っていません。
いまサインイン済みで、いま端末の前にいる送信者。アカウントが要るのは送信者だけで、受信側がサインインすることはありません。
6桁の数字を、帯域外の手段で受け取ること。相手の CLI が発行した瞬間から5分間だけ有効なので、先にタイミングを合わせてください。
あとで6桁をもう一度読み返せる手段。SAS は画面上ではなく口頭で照合します。
相手側も CLI であること。ブラウザは CLI のペアリングコードに参加できません。手元にブラウザしかないなら、relayium up のリンクを頼んでください。

これは relayium send の受信側です。相手は自分の側で relayium send <path> を実行します（事前に relayium login 済み）。相手の CLI が 5 分間有効な 6 桁の数字コードを発行して表示するので、通話やチャットなど二人が信頼できる手段でそれを伝えてもらいます。受け取ったコードで receive を実行します:

relayium receive 483920

# 特定のディレクトリに受け取る場合
relayium receive 483920 ./downloads

送信者が send を実行するタイミングを先に決めます。コードの有効期限は発行された瞬間から始まり、受け取った瞬間からではありません。
互いに信頼できる経路で6桁を受け取ります——通話、チャット、あるいは同じ部屋にいるならその場で。
ファイルを置きたいディレクトリで receive を実行するか、置き場所を明示します。
```
relayium receive 483920
```
```
relayium receive 483920 ./downloads
```
両方の端末に確認コードが表示されたら、自分の側を読み上げて相手と一致するか確かめます。これはペアリングコードではなく、相手側がすり替えられていないことを否定できる唯一の材料です。
端末がプロンプトに戻るまで触らないでください。これは1つのライブセッションで、どちらかを閉じれば転送は止まります。

受信が成功したときの見え方

接続は direct と表示され、両方の端末が同じ確認コードを表示します。コードが食い違うことだけは受け入れてはいけません——そこで止めて、相手がどのマシンにいるのかを確認してください。

$ relayium receive 483920
verification code (SAS): 271044 — not the pairing code; compare it on both ends to rule out a substituted endpoint
path: direct

接続は直接のピアツーピアでエンドツーエンドに暗号化されています。接続後、両方のターミナルに同じ SAS（short authentication string）が表示されます。送信側と帯域外で照合すると、固定された TLS 証明書フィンガープリントが差し替えられておらず、ランデブーサービスがどちらのエンドポイントにもなりすましていないことを確認できます。SAS はエンドポイントを認証するもので、ネットワーク経路上のすべてのホップを証明するものではありません。
宛先を指定しない場合、ファイルはカレントディレクトリに置かれます。
send と同じく直接接続のみのルールです。2つのネットワークの間に直接の経路が見つからなければ、リレー経由で送るのではなく転送が失敗します。
これは CLI 独自のペアリングコード・プロトコルです——CLI のコードは CLI 同士でしかペアリングできません。現時点では relayium.com のブラウザ側のペアリングコードや QR フローとは相互運用しません。将来追加される可能性はありますが、今はまだ頼れるものではありません。ブラウザしかない場合は、代わりに relayium up のダウンロードリンクを送ってもらってください。
受信側はどのネットワークにいても、アカウントは一切不要です。サインインするのは送信側だけで、その CLI がコードを発行できるようにするためです。

serve: このマシンを待ち受け型の受信箱にする

serve は逆方向に動作します。こちらから出向くのではなく、他のマシンが relayium:// 経由で直接プッシュしてきます——自分のノート PC が NAS へプッシュする、ビルドサーバーが成果物を自分のマシンへ落とすなど、すでに信頼しているマシン向けです。証明書ピンニング付き TLS 1.3 接続で、SSH もランデブーも不要です。

relayium serve

# ディレクトリとポートを指定し、削除要求を許可する場合
relayium serve --dir ~/incoming --port 9031 --allow-delete

受信先ディレクトリを指定してリスナーを起動します。
```
relayium serve --dir ~/incoming
```
新しいマシンが初めて push してくると、serve はそのアドレスとフィンガープリントを示して確認を求めます。一度承認すれば、同じフィンガープリントからの push は以後そのまま通ります。
このリスナーを端末なしで動かすつもりなら、そのプロンプトを当てにしないでください。答える人がいないため、見知らぬ送信元は問答無用で拒否されます。次の節にある事前承認を使ってください。

新しいマシンが初めてプッシュしてくると、serve は（ターミナルで実行している場合）そのアドレスとフィンガープリントを表示し、一度だけ承認するよう求めます。以降、同じフィンガープリントからのプッシュは黙って通過します。
ターミナルがない場合——systemd サービスや TTY のないスクリプト——確認する相手がいないため、未知のプッシュ側はそのまま拒否されます。代わりに、プッシュ側が relayium id で表示するフィンガープリントを使って事前に承認してください:

無人稼働の serve のために事前承認する

無人で動作する serve（systemd、バックグラウンドスクリプト）では、プッシュ側に relayium id を実行させてフィンガープリントを表示させ、受信側であらかじめそれを承認しておきます:

relayium authorize <fingerprint>

--dir はファイルの置き場所を設定します（デフォルトはカレントディレクトリ）。--once は1回の転送だけ受け入れて終了します。--allow-delete は受信した --delete（ミラー）要求によって実際にここでファイルを削除できるようにするもので、デフォルトでは無効です。
--config-dir（デフォルト ~/.config/relayium）は、このホストのアイデンティティと承認済みフィンガープリントのリストが置かれる場所です——serve を専用サービスとして動かす場合は上書きしてください。

pull: すでに SSH でログインできるサーバーから取り込む

pull は push の鏡像です。誰かが何かを送ってくるのを待つのではなく、すでに持っている SSH アクセスを使って自分から出向き、ファイルを取り込みます。

relayium pull user@host:/path/to/files ./local-dest

リモートに本当に CLI が入っているか確認します。pull はリモート側で relayium を実行し、push と違って tar のフォールバックがないため、バイナリがなければコマンド全体が失敗します。
```
ssh user@host command -v relayium
```
入っていなければ、まずリモートに入れます。
```
curl -fsSL https://relayium.com/install.sh | sh
```
既存の SSH アクセスでファイルを取り戻します。-i と -p は ssh 自身と同じ挙動です。
```
relayium pull user@host:/path/to/files ./local-dest
```

push と異なり、pull は常にリモート側にすでに relayium がインストールされている必要があります——素のサーバーから pull するための tar フォールバックはありません。リモートにまだ入っていない場合は、先に curl -fsSL https://relayium.com/install.sh | sh でインストールしてください。
ファイルはファイルごとの SHA-256 チェックで検証され、中断しても自動的に再開します（--no-resume で無効化できます）。
-i と -p は ssh 自体の -i/-p と同様に、特定のアイデンティティファイルやポートを指定するために使えます。

うまくいかないとき

失敗する受信のほぼすべては次の5つのどれかです。どのコマンドを実行していたかで該当するものが決まり、どれにも読めば分かる1行か実行すれば決着がつくコマンドがあります。

症状、確認、対処

コードを入力したのに、ランデブーがそれを拒否する。

relayium receive 483920
# the rendezvous refuses the code

ほぼ確実に5分が経過しています。コードの有効期限は送信者の CLI が発行した瞬間から始まり、知らされた瞬間からではありません。もう一度 send を実行してもらい、新しい数字をその場で読み上げてもらってください。1桁の打ち間違いはこちらからは見分けがつかないので、期限切れと決めつける前に読み返して照合します。

転送は終わったのに、ファイルが見つからない。

relayium receive 483920 ./downloads

宛先を指定しない場合、receive は実行したディレクトリに書き込みます。そこは探している場所とは限りません。明示的に指定するか、先に pwd で確かめてください。

「no direct connection to the peer (both ends behind strict NAT?)」で失敗する。

relayium receive 483920
# no direct connection to the peer (both ends behind strict NAT?): …

CLI のペアリング経路は設計上ダイレクト専用で、直接の経路が見つからないときはファイルをリレー経由にせず失敗します。こちら側でできることはありません。送信者に relayium up のダウンロードリンクを頼むか、双方が管理するマシン同士ならデーモン直結か SSH 経由の push を使ってください。

pull が即座に失敗し、relayium が見つからないと言われる。

ssh user@host command -v relayium
# (no output)

pull はリモート側で relayium を実行します——その交換ではリモートが送信側です——そして push のような tar フォールバックはありません。先にリモートへ CLI を入れてから pull をやり直してください。

あるマシンが serve リスナーに push して拒否されたのに、こちらには一度も確認が出なかった。

relayium serve --dir ~/incoming

あの確認は serve に端末があるときにしか存在しません。systemd 配下、スクリプト内、パイプの先では尋ねる相手がいないため、未知のフィンガープリントは問答無用で拒否されます。送信側に relayium id を実行してもらい、こちらで relayium authorize <フィンガープリント> を、リスナーと同じ --config-dir で実行してください。

よくある質問

ファイルを受信するのにアカウントは必要ですか？

いいえ。receive、serve、pull の3つすべてが完全に無料で、受信側に Relayium アカウントは不要です。どこかでサインインが要るのは receive モードの送信側だけで、その CLI がペアリングコードを発行できるようにするためです。

relayium receive はブラウザのペアリングコードと相互運用しますか？

しません。CLI のペアリングコード・プロトコルは、relayium.com のブラウザ側の参加リンクや QR フローとは別物です——ハンドシェイクの方式が異なり、現時点では互いに通信しないので、CLI のコードは別の CLI としかペアリングできません。それはロードマップ上の話であり、今はまだ頼れるものではありません。それまでは、ブラウザで受け取る相手にはコードではなく relayium up のリンクを渡します。

未知のマシンが自分の serve リスナーへプッシュしてきたらどうなりますか？

ターミナルでは、初回のプッシュ時にアドレスとフィンガープリントを見せて承認するかどうか尋ねられ、その承認は記憶されます。ターミナルがない場合——systemd サービスや cron ジョブ——確認する相手がいないため、未知のプッシュ側は拒否されます。先に relayium authorize <fingerprint> で事前承認してください。

relayium がインストールされていないサーバーから pull できますか？

できません。pull は常にリモート側に relayium が必要です——push にあるような tar フォールバックはありません。先にリモートへ relayium をインストールしてください。

relayium は自分のアイデンティティと信頼済みの相手をどこに保存しますか？

デフォルトでは ~/.config/relayium にあります——アイデンティティや信頼に関わるどのコマンドでも --config-dir でこの場所を上書きできます。

最初の受信をしてみましょう。CLI をインストールして、receive、serve、pull のいずれかを選んでください。

CLI を入手する