magic-wormhole: ワンタイムコードで安全にファイル転送

2026年2月18日 • 1 min read

こんにちは,

今日は、サポート対応やインシデント時に私がよく使う小さなCLIツール magic-wormhole を紹介します。派手な「エンタープライズ」ストーリーよりも、普通の会社で圧倒的に起きがちな問題を解決してくれます。つまり、誰かにファイル（またはディレクトリ）を 今すぐ 渡したいのに、メールは容量が足りない、クラウドの共有リンクはポリシーや法務的に面倒、そして「とりあえずポート開けよう」は論外…という状況です。

金曜日の16:47。社員60人ほどの会社で緊急事態。中央のファイルサーバが遅く、ユーザーはタイムアウトを訴え、外部のIT業者からはログと小さな設定エクスポートを含むサポートバンドルの提出を求められます。サイズは約900MB。メールでは弾かれ、SharePointはコンプライアンス上NG。急ごしらえのFTPを立てるなんて、2026年に自分で作りたい地獄ではありません。

こういう時に magic-wormhole が効きます。ワンタイムコードを共有して、エンドツーエンド暗号化で転送、終わり。

magic-wormholeとは？

magic-wormholeは、2台のコンピュータ間で ad-hocにファイルを転送 するための軽量ツールです。ポイントはwormhole code（例: 7-coral-lion）。両者が同じコードを入力すると、それを元に エンドツーエンド暗号化 の接続が確立されます。

magic-wormholeの良いところは「いらないもの」が多いことです。

アカウント不要
ログインポータル不要
「どこかにアップロードしてリンク共有」不要
インバウンドのファイアウォールルール不要

必要なのは、両側にwormholeが入っていて、アウトバウンドでインターネットに出られることだけ。実務的には、HTTP(S)のアウトバウンドが通っていれば、magic-wormholeもだいたい動きます。

SMBでよくある実例

先ほどの金曜日のケース。現場の現実的な流れはだいたいこうです。

サポートバンドル（ログ、エクスポート、スクリーンショットなど）を作る
必要ならハッシュを計算して、後で同一性を確認できるようにする
magic-wormholeで送る
コードは 別チャネル で共有する（電話、別のチャット、読み上げなど）

送信側:

tar -czf support-bundle.tgz ./logs ./config-export
sha256sum support-bundle.tgz
wormhole send support-bundle.tgz

magic-wormholeがコードを表示します。受信側は:

wormhole receive

コードを入れてダウンロードし、必要ならハッシュを照合。現場では、この「速いのに、ちゃんとしている」感じが本当にありがたいです。

実際の使い方

AからBへファイルを送る

送信:

wormhole send /path/to/file.zip

受信:

wormhole receive

ダウンロードはカレントディレクトリに保存されます。私はDownloadsやDesktopに紛れないよう、受信用フォルダを作ることが多いです。

mkdir -p ~/wormhole-recv && cd ~/wormhole-recv
wormhole receive

ディレクトリを送る

フォルダごと送りたい場合:

wormhole send --dir ./support-bundle/

裏側で何が起きている？（短く、マーケ抜きで）

magic-wormholeは、普通なら自分で頑張って組み立てる必要がある3つをうまく隠してくれます。相手の発見、安全な鍵合意、そして NAT/ファイアウォールに負けないデータ転送 です。

ステップ	何が起きるか	何が嬉しいか
1. コード	送信側が短いワンタイムコードを生成	この転送のための共有シークレットになる
2. Rendezvous	両クライアントがrendezvousサーバ（デフォルトは公開の"mailbox"）に接続	インバウンドを開けずに互いを見つけられる
3. PAKE	SPAKE2（PAKE）でコードから共有鍵を導出	E2E鍵を配布せずに合意できる
4. データ経路	まず直結を試し、ダメならrelay/transitにフォールバック	NAT環境でも動きやすい
5. E2E転送	データは暗号化＋改ざん検知でE2E保護	relayはciphertextしか見えない

要点はこれです。rendezvous/relayはインフラですが、データが平文で置かれる場所ではありません。

セキュリティ: 強み、限界、そしてルール

magic-wormholeのセキュリティモデルはわりと正直です。E2Eはある。でも、アイデンティティは自動では付いてきません。

得られるもの

エンドツーエンド暗号化: relay経由でも、内容は送信者と受信者の間で保護
短命なアクセス: コードは1回の転送向けで、長期パスワードではない
攻撃面が小さい: ハードニングすべきサーバやユーザー管理、Web UIがない

気をつけるべき点

コードはパスワード。 コードを知っている人が「相手」です。オープンなチケットに貼ったら危険。
監査はデフォルトでない。 DLPや承認、追跡が必要なら公式ルートを使うべき。
エンドポイントが全て。 送信側が侵害されていれば何でも送れるし、受信側が侵害されていれば受け取った後は危険。

実務で効くルール

コードはチケットリンクやファイル文脈と同じチャネルで共有しない。理想は電話や別のプライベートチャット。
ログにはトークンやホスト名、個人情報が入り得る。必要最小限だけ送る。
重要なアーティファクトはハッシュを別チャネルで渡し、受信後に検証する。

インストール（短く、現実的に）

多くの環境ではパッケージマネージャで一発です。

Debian/Ubuntu: sudo apt install magic-wormhole
macOS: brew install magic-wormhole

ディストリのパッケージが古い場合はpipxが無難です。

pipx install magic-wormhole
pipx ensurepath

Pythonを入れたくない（最小サーバ、コンテナ、rescue環境など）なら、互換Go実装の wormhole-william がsingle binaryで便利です。

自動化とセルフホスティング

管理されたワークフローなら、magic-wormholeはスクリプトでも使えます。

CODE="5-alpaca-orbit"
wormhole send --code "$CODE" /path/to/db.dump

受信側:

wormhole receive --code "$CODE" --accept-file

便利ですが、コードを固定するとシークレット管理に戻ります。自動化するなら、適切なsecret handlingと短い有効期限で。

rendezvous/relayを完全に自分で管理したい場合は、クライアントを自前インフラに向けられます。例えば:

--relay-url（自前rendezvousサーバ）
--transit-helper（自前transit relay）

まとめ

magic-wormholeは、ポリシーに沿った管理型のファイル転送を置き換えるものではありません。でも、日常の道具としてはとても優秀です。速く、手間が少なく、セキュリティモデルが明確。

特にSMBの現場では、サポート案件のたびに承認フローを作る時間も気力もありません。「今すぐ使えて、十分に安全」なツールがちょうど刺さる場面が多いです。

参考リンク

それでは、また次回お会いしましょう。 Joe