Rust製P2P基盤にirohが選ばれる理由｜libp2pとの違いと1.0の要点

Rust で P2P 機能を実装しようとしたとき、多くのエンジニアが最初に直面するのが「NAT 越え」と「アドレッシング」の壁ではないでしょうか。IP アドレスは変わり、NAT の背後にいる端末には直接届かず、公衆 Wi-Fi の裏側からは接続の半分以上が失敗する—そんな環境で、いかに端末同士を「確実に」繋げるかは、設計上の大きな悩みどころです。

libp2p を検討したことがあるエンジニアなら、モジュール構成の柔軟さと引き換えに、学習曲線の急さや設定項目の多さに疲弊した経験もあるかもしれません。かといって Quinn（Rust の pure な QUIC 実装）を土台に自作しようとすれば、Node の発見・ホールパンチ・Relay フォールバックまで自前で組む必要があり、実装ボリュームは一気に膨らみます。

そこで名前が挙がるのが、2026 年 6 月に 1.0 をリリースした「iroh」です。iroh は「IP アドレスではなく公開鍵で相手を dial する」というコンセプトを掲げる Rust 製 P2P ネットワーキングライブラリで、GitHub スター数は 11,000 を超え、公式が運営するパブリック Relay は直近 30 日で 2 億超のエンドポイント作成を捌く実運用実績を持ちます。

本記事では iroh の設計思想と仕組みを整理したうえで、Rust 製 P2P 基盤の選定でよく比較される libp2p / Quinn との違い、周辺プロトコル（Blobs / Docs / Gossip）の位置づけ、1.0 リリースが保証するワイヤプロトコル互換性、本番採用時に押さえておきたい留意点を、公式ドキュメント・README・1.0 リリースノートに基づいて解説します。「自社プロダクトに採用すべきか」を一次判断できる状態を目指す、初見の Rust エンジニア向けの俯瞰記事です。

irohとは何か｜Rust製P2P QUICライブラリの立ち位置

iroh は、N0, Inc. が開発する Rust 製の P2P ネットワーキングライブラリです。公式サイトのタグラインは "less net work for networks" で、GitHub リポジトリの説明文にも「IP addresses break, dial keys instead. A library that adds QUIC + NAT Traversal to your apps.」と記されています（出典: n0-computer/iroh GitHub）。日本語で噛み砕くと、「IP アドレスは壊れやすいので、代わりに鍵（公開鍵）で相手を呼び出そう。あなたのアプリに QUIC と NAT 越えを追加するライブラリです」という趣旨です。

一言でいえば、iroh は「エンドポイント同士を、ネットワーク条件に関わらず、E2E 暗号化された QUIC 接続で繋ぐ」ことを目的にしたライブラリです。libp2p のように多数のトランスポート・プロトコルを差し替え可能にする「フレームワーク」ではなく、Quinn のように QUIC トランスポート層だけを提供する「純粋なライブラリ」でもない、その中間の位置づけを取ります。

リポジトリ基本情報

現時点（本記事執筆時点）のリポジトリ基本情報は次のとおりです。

出典: gh api /repos/n0-computer/iroh の応答（本記事執筆時点）。リポジトリはアクティブに開発中（アーカイブされていません）で、本家のリポジトリ（フォークではありません）です。

なお、README にはライセンスとして「Apache License, Version 2.0」または「MIT license」のデュアルライセンスであることが記載されています（出典: iroh README）。GitHub の API が返すライセンス識別子（Apache-2.0）は代表値ですが、実際は利用者が Apache-2.0 と MIT のどちらかを選択できます。商用利用時にどちらを採用するかは、社内の OSS ライセンスポリシーに従って選定してください。

公式サイト・ドキュメント・リポジトリの導線は次のとおりです。

• 公式サイト: https://www.iroh.computer/
• 公式ドキュメント: https://docs.iroh.computer/
• GitHub リポジトリ: https://github.com/n0-computer/iroh
• Rust API ドキュメント: https://docs.rs/iroh

1.0 リリース（2026年6月15日）で何が変わったか

iroh は 4 年以上にわたる開発と 65 回の pre-release を経て、2026 年 6 月 15 日に 1.0 stable リリース を迎えました（出典: Iroh 1.0 - Dial Keys, not IPs）。1.0 の意義として、公式が特に強調しているのが次の 2 点です。

1. ワイヤプロトコル互換性の保証: 公式ブログには「An iroh v1 endpoint will be able to communicate with another iroh v1 endpoint, regardless of minor version or language.（v1 のエンドポイントは、マイナーバージョンや言語バインディングを問わず、別の v1 エンドポイントと通信できる）」と明記されています（出典: Iroh 1.0 - Dial Keys, not IPs）。長期運用するプロダクトにとって、この互換性保証は採用判断に直結する重要な要素です。
2. stable な言語バインディング: Rust 本体に加え、Python / Node.js / Swift / Kotlin の言語バインディングが安定版として提供されるようになりました（出典: Iroh 1.0 - Dial Keys, not IPs）。異なる言語で書かれたアプリケーション同士が、iroh を介して直接通信できることになります。

加えて、公式運営のパブリック Relay は直近 30 日で 2 億超のエンドポイント作成 を捌いた実績を持つと発表されています（出典: Iroh 1.0 - Dial Keys, not IPs）。「実運用に耐えるか」という検証段階のエンジニアにとっては、無視できない数字です。

IPアドレスではなく公開鍵でdialする設計思想

iroh を理解する上で、まず押さえておきたいのが「dial by public key（公開鍵で dial する）」というコンセプトです。従来の TCP/UDP ベースの通信は、IP アドレスとポート番号で相手を特定します。しかしモバイル環境や NAT 環境では、IP アドレスは頻繁に変わり、直接届かないケースも多々あります。

IPベースP2Pの限界とNAT越えの難しさ

IP アドレスをそのまま相手の識別子として扱う設計には、以下のような課題がつきまといます。

• IP アドレスの再割当て: モバイル端末はセルラーと Wi-Fi の切り替えや基地局の移動で IP が頻繁に変わります
• NAT の背後の到達不能性: 家庭・オフィスの NAT やキャリアグレード NAT の背後にいる端末には、外部から直接パケットが届きません
• ホールパンチの成功率のばらつき: NAT 越え（ホールパンチ）は、対称型 NAT や厳格なファイアウォールでは失敗しやすく、環境依存が大きい
• エンドポイントのアイデンティティ問題: IP アドレスが変わると「同じ端末」を追跡できなくなる

これらは P2P 通信を設計する誰もがぶつかる壁で、libp2p も iroh もそれぞれのアプローチで解決を試みています。

エンドポイントID（公開鍵）ベースのアドレッシングとDNS/Pkarrによる発見

iroh のアプローチは、IP アドレスの代わりに公開鍵で相手を識別するというものです。README には次のように記されています。

Iroh gives you an API for dialing by public key. You say "connect to that phone", iroh will find & maintain the fastest connection for you, regardless of where it is.

出典: iroh README

具体的には、Endpoint を bind すると鍵ペアが生成され、EndpointId（公開鍵から導出される識別子）が発行されます。dial 時には、この EndpointId を指定するだけで、iroh 側が「相手が今どこにいるか」を発見し、最速のルートで接続を維持してくれます。相手の発見は、公式が運営する dns.iroh.link の DNS サーバー（iroh-dns-server）と Pkarr プロトコルを通じて行われます（出典: iroh README）。

この設計により、モバイル環境で IP が変わっても、Wi-Fi と 4G/5G を切り替えても、同じ EndpointId を持つ端末とは繋がり続けられます。IP アドレスの管理から解放され、「相手のアイデンティティ」だけを気にすれば良くなる—これが iroh の中心的な体験改善です。

irohの仕組み｜QUIC＋ホールパンチ＋Relay フォールバック

「公開鍵で dial する」というコンセプトは魅力的ですが、実際に接続を確立するには複数の技術要素が必要です。iroh は QUIC、ホールパンチ、Relay フォールバックを組み合わせて、あらゆるネットワーク条件下で接続を確立しようとします。

接続確立の4ステップ

iroh の接続確立は、おおまかに次の 4 ステップで進みます（出典: iroh 公式ドキュメント、iroh README）。

1. Endpoint の bind: アプリケーション側で Endpoint::bind() を呼ぶと、鍵ペアが生成され EndpointId が確定します
2. 相手のエンドポイント発見: EndpointId をキーに、DNS/Pkarr ベースの lookup（dns.iroh.link）で相手の候補アドレスを取得します
3. QUIC による直接ホールパンチ: 取得した候補アドレスに対して QUIC で直接接続を試み、NAT 越えのホールパンチを行います
4. Relay 経由へのフォールバック: 直接接続が確立できない場合は、公式運営または自己ホストのステートレスな Relay サーバーを経由して接続を維持します。Relay 経由でも、可能な限りダイレクト接続への昇格を継続的に試みます

README には「The fastest route is a direct connection, so if necessary, iroh tries to hole-punch. Should this fail, it can fall back to an open ecosystem of public relay servers.（最速ルートは直接接続。必要ならホールパンチを試み、それでも失敗する場合はパブリック Relay サーバーのオープンなエコシステムにフォールバックできる）」と説明されています（出典: iroh README）。

QUICを選ぶ理由とE2E暗号化

iroh は QUIC トランスポートに noq（Quinn 由来の QUIC 実装）を採用しています。QUIC を選ぶ理由は、README に次のとおり明記されています。

Iroh uses noq to establish QUIC connections between endpoints. This way you get authenticated encryption, concurrent streams with stream priorities, a datagram transport and avoid head-of-line-blocking out of the box.

出典: iroh README

つまり、QUIC を土台にすることで、以下がデフォルトで得られます。

• 認証付き暗号化（TLS 1.3 ベースの相互認証・E2E 暗号化）
• 優先度付きの並行ストリーム（1 コネクション内で複数のストリームを同時に扱える）
• データグラム輸送（順序保証不要のメッセージ配送）
• head-of-line blocking の回避（TCP のようにパケットロスで全ストリームが詰まらない）

「iroh の接続は、ただの QUIC 接続」というシンプルな抽象化は、既存の IETF 標準（QUIC）を土台にした設計思想の表れです。特殊な暗号プロトコルを覚え直す必要はなく、QUIC を知っていれば iroh のワイヤ層の理解も早まります。

最小コード例（Rust）

README の Getting Started には、ecoh プロトコルを想定した最小の接続例が掲載されています。以下は connecting side（接続する側）の抜粋です。

const ALPN: &[u8] = b"iroh-example/echo/0";

let endpoint = Endpoint::bind().await?;

// Open a connection to the accepting endpoint
let conn = endpoint.connect(addr, ALPN).await?;

// Open a bidirectional QUIC stream
let (mut send, mut recv) = conn.open_bi().await?;

// Send some data to be echoed
send.write_all(b"Hello, world!").await?;
send.finish()?;

// Receive the echo
let response = recv.read_to_end(1000).await?;
assert_eq!(&response, b"Hello, world!");

// As the side receiving the last application data - say goodbye
conn.close(0u32.into(), b"bye!");

// Close the endpoint and all its connections
endpoint.close().await;

出典: iroh README

Endpoint::bind() で自身のエンドポイントを起動し、endpoint.connect(addr, ALPN) で相手を dial、open_bi() で双方向 QUIC ストリームを開いて write_all / read_to_end でやり取りする—Rust の非同期プログラミングに慣れているエンジニアであれば、コードの見た目からライブラリの API 感覚を掴めるはずです。ALPN（Application-Layer Protocol Negotiation）でアプリケーションプロトコルを識別する QUIC の仕組みも、そのまま踏襲されています。

Relayフォールバックとステートレス設計

iroh の Relay は「ステートレス」に設計されている点が特徴です。公式リポジトリの構成として、iroh-relay（Relay クライアント + サーバー実装）が同梱されており、パブリック Relay のコードも OSS 化されています（出典: iroh README）。この設計により、公式運営の Relay に依存したくない場合でも、社内やクラウド上に 自前で Relay を立てる ことが可能です。

Relay 経由の接続は、直接接続よりレイテンシ・帯域面で不利ですが、iroh は「Relay 経由でも継続的にダイレクト接続への昇格を試みる」設計を取ります（出典: Comparing Iroh & Libp2p）。ネットワーク条件が改善したタイミングで自動的にダイレクト接続に切り替わるため、アプリケーション側は接続経路を意識せずに済みます。

irohのエコシステム｜Blobs・Docs・Gossip と多言語バインディング

iroh 本体は「エンドポイント同士を接続する」ためのライブラリですが、その上に「よくある P2P アプリケーションのユースケース」を素早く実装するための 上位プロトコル群 が同組織から提供されています。

主要プロトコル一覧

README には次のように紹介されています。

Use pre-existing protocols built on iroh instead of writing your own:

• iroh-blobs for BLAKE3-based content-addressed blob transfer scaling from kilobytes to terabytes
• iroh-gossip for establishing publish-subscribe overlay networks that scale, requiring only resources that your average phone can handle
• iroh-docs for an eventually-consistent key-value store of iroh-blobs blobs

出典: iroh README

各プロトコルの位置づけを整理すると、次のとおりです。

これらは全て独立した crate として提供されており、必要なものだけを組み合わせて採用できます。たとえば「大容量ファイルを P2P で配布したい」なら iroh-blobs のみ、「複数端末での分散通知を実装したい」なら iroh-gossip のみ、といった選び方が可能です。上位プロトコルの詳細は iroh 公式ドキュメント のプロトコル章を参照してください。

多言語バインディングとプラットフォーム対応

先述のとおり、1.0 リリースで Rust 以外の言語バインディングも安定版として提供されるようになりました。

• Rust（本体、cargo add iroh）
• Python
• Node.js
• Swift
• Kotlin

出典: Iroh 1.0 - Dial Keys, not IPs

異なる言語で書かれたクライアント同士でも、ワイヤプロトコル互換性が保証されているため直接通信できます。README には「If you want to use iroh from other languages, make sure to check out iroh-ffi, the repository for FFI bindings.」と、FFI バインディング用のリポジトリ iroh-ffi への導線も明記されています（出典: iroh README）。

1.0 リリースブログでは、WebAssembly 対応や BLE / LoRa / WiFi Aware / Tor などのカスタムトランスポート対応にも触れられており（出典: Iroh 1.0 - Dial Keys, not IPs）、モバイル・組み込み・ブラウザまで幅広く展開できる方針が示されています。

libp2p・Quinnとの違い｜irohの選定判断軸

「なぜ libp2p や Quinn ではなく iroh を選ぶのか」は、多くの Rust エンジニアが最初に抱く疑問ではないでしょうか。ここでは iroh 公式の比較記事を主なソースに、選定判断軸を整理します。

libp2pとの違い

Protocol Labs（IPFS 開発元）が提供する rust-libp2p は、P2P フレームワークとしての完成度が高く、iroh と最もよく比較されます。公式比較記事の主な差分をまとめると、次のとおりです（出典: Comparing Iroh & Libp2p）。

libp2p 側の測定でホールパンチ成功率が約 70% とされる一方、iroh は「Tailscale で培われた技法を活用し、多様なネットワーク環境で顕著に高い成功率と一貫性のある信頼性を提供する」と公式が述べています（出典: Comparing Iroh & Libp2p）。「特定の相手に確実に接続したい」ユースケースでは iroh、「Kademlia DHT ベースのルーティングが必要」「分散化を極限まで追求したい」場合は libp2p、という棲み分けが基本の判断軸になります。

Quinnとの違い

Quinn は Rust の pure な QUIC 実装ライブラリで、IETF QUIC 準拠のトランスポート層のみを提供します。iroh との棲み分けはよりシンプルです。

iroh の QUIC 実装は Quinn 由来の noq を活用しており（出典: iroh README）、Quinn を「土台」に P2P 特有の課題を上位で解決した構成と捉えると分かりやすくなります。「純粋な QUIC でクライアント/サーバーを実装したい」なら Quinn、「Node 同士を公開鍵で dial したい」なら iroh、というのが基本の判断軸です。

選定判断軸のまとめ

以上を踏まえた、実務での選定判断軸を整理します。

「iroh か libp2p か」は思想面での違いが大きく、単純な機能比較では決着しません。「どの分散度合いで、どの成功率が必要か」を先に決めると、選定の見通しが良くなります。

どんなユースケース・チームに向くか

公式サイト・ドキュメントでは、iroh の代表的なユースケースがいくつか挙げられています（出典: iroh 公式サイト、Iroh 1.0 - Dial Keys, not IPs）。

irohが向くユースケース

• 分散 AI トレーニング: 複数のクラウド・データセンター間で高速にモデル・データを同期
• 端末間のビデオストリーミング: リアルタイム性の高い映像・音声通信
• モバイルアプリのリアルタイム同期: モバイル環境の IP 変動に耐えるアプリケーション同期
• POS 決済システム: 拠点間の直接通信で信頼性を担保
• IoT / 組み込みデバイス: ESP32、Raspberry Pi、Linux などの組み込み用途
• コンテンツアドレス指定型のファイル転送: iroh-blobs を活用した大容量ファイル配信

これらに共通するのは、「特定の相手に確実に、E2E 暗号化された経路で」接続したいという要件です。中央サーバーを最小化しつつも、実運用の成功率を高くしたいプロダクトに向いています。

チームプロファイルの観点では、以下のようなチームに適しています。

• Rust に慣れている少人数のプロダクトチーム（API がシンプルで、学習コストが低い）
• モバイル/組み込みなど複数プラットフォーム対応が求められるチーム（多言語バインディングと WebAssembly / 組み込み対応）
• 本番の接続成功率と E2E 暗号化を最優先したいチーム（ホールパンチ成功率とデフォルト暗号化）

irohより他の選択肢を検討すべきケース

一方、以下のようなケースでは、libp2p や Quinn を先に検討したほうが要件にフィットする場合があります。

• 完全な分散化が必須で、DNS ベースの発見も許容できない: libp2p の Kademlia DHT が候補
• 既に libp2p ベースのエコシステム（IPFS 等）と統合する必要がある: libp2p 一択
• IP アドレッシングで十分な pure QUIC クライアント/サーバー: Quinn のほうが薄く軽い
• 独自のプロトコルスタック（トランスポート層から自作）を組みたい: libp2p のモジュール性が有利

「何を諦めて何を取るか」を意識すると、選定の議論が進めやすくなります。

本番採用時の留意点と 1.0 の互換性保証

「本番投入に耐えるライブラリか」は、企業向けプロダクトで採用を検討する際の最重要ポイントです。iroh は 1.0 リリースで、この観点に真正面から答える保証をいくつか打ち出しています。

1.0のワイヤ互換性保証と意味

先述したとおり、iroh 1.0 では「v1 のエンドポイントは、マイナーバージョンや言語バインディングを問わず、別の v1 エンドポイントと通信できる」ことが保証されています（出典: Iroh 1.0 - Dial Keys, not IPs）。この保証は、以下のような実務上のメリットに直結します。

• アップグレードのリスク低減: v1.x 系のマイナーバージョンアップで、既存クライアントとの通信が壊れることを避けられる
• 異言語クライアントの混在許容: Rust サーバーと Python/Node.js/Swift/Kotlin クライアントを組み合わせても互換性が保たれる
• 段階的なロールアウトが可能: 全端末を一斉に更新しなくても、通信が破綻しない

長期運用するプロダクトにとって、ワイヤ互換性の明示的な保証は「メジャーバージョンアップまで壊さない」というコミットメントであり、意思決定の重要な材料になります。

Relayの自己ホストとマネージド提供

iroh のパブリック Relay は、直近 30 日で 2 億超のエンドポイント作成を捌く実績があり（出典: Iroh 1.0 - Dial Keys, not IPs）、スケール面での実運用実績は十分と言えます。一方で、「公式運営の Relay に依存したくない」という要件がある場合、iroh は次の選択肢を提供します。

• iroh-relay の自己ホスト: Relay のクライアント + サーバー実装は同一リポジトリ内で OSS 化されており、社内やクラウド上に自前で立てられます（出典: iroh README）
• 開発元 N0, Inc. のマネージドサービス: 自己ホストのコストを避けたい場合、開発元がマネージド Relay を提供しています

Relay の運用主体を選べる設計は、コンプライアンス要件（データの経路・所在の管理）が厳しい業界でも採用しやすい構造です。

ライセンスと商用利用

先述したとおり、iroh は Apache-2.0 と MIT のデュアルライセンスで提供されています（出典: iroh README）。両方ともパーミッシブなライセンスで、商用製品への組み込み・改変・再配布が認められます。企業のプロダクトに組み込む際のライセンス面のハードルは低く、コピーレフト系のライセンス（GPL 等）で懸念される「派生物のソース公開義務」もありません。

社内の OSS ライセンスポリシーで「Apache-2.0 を優先」または「MIT を優先」と定めている場合、そちらを選択して採用できます。

irohを検討する際の3つの視点

iroh は「IP アドレスではなく公開鍵で dial する」というシンプルなコンセプトを、QUIC・NAT 越え・Relay フォールバック・上位プロトコル（Blobs / Docs / Gossip）・多言語バインディングという実装レイヤで支える、Rust 製の P2P ネットワーキング基盤です。1.0 リリース（2026 年 6 月 15 日）でワイヤプロトコル互換性と言語バインディングの安定化が保証され、本番採用の判断材料が揃いました。

自プロジェクトへの採用を検討する際は、以下の 3 つの視点で整理するとよいでしょう。

1. 接続の確実性: 「特定の Node に高い成功率で E2E 暗号化された経路で繋げたい」なら iroh の得意領域。「完全な分散化」「Kademlia DHT」「モジュール性」を最優先するなら libp2p の再検討を
2. エコシステムの適合: 本体だけで足りるのか、Blobs / Docs / Gossip のような上位プロトコルまで含めた採用になるのかを先に決める。多言語バインディングが必要なら 1.0 の stable 化は大きな追い風
3. 本番運用の互換性保証: v1 のワイヤ互換性・Relay の自己ホスト可否・デュアルライセンスの許容度をチェックリスト化し、社内の OSS ポリシーと照らし合わせる

より深く検討を進めたい方は、以下の一次情報源が起点になります。

• 公式ドキュメント: https://docs.iroh.computer/
• GitHub リポジトリ: https://github.com/n0-computer/iroh
• 1.0 リリースブログ: Iroh 1.0 - Dial Keys, not IPs
• libp2p との比較（公式）: Comparing Iroh & Libp2p

「Rust で P2P」を検討している段階のエンジニアにとって、iroh は「まず試す価値のある選択肢」の一つに位置づけられます。libp2p / Quinn との比較軸を明確に持って議論を進めれば、社内の技術選定もスムーズに進むはずです。