trippyとは｜mtr コマンド相当をsudoなしで動かすRust製ネットワーク診断TUIを実測検証

traceroute は経路を1回なぞって終わりで、mtr は連続計測できるがmacOSには同梱されていない——このすき間を埋めるのが trippy（コマンド名 trip）だ。mtr コマンドの置き換えを探しているなら、Rust製で単一バイナリ・macOSではsudoなしで動くという点が効いてくる。この記事では0.13.0の公式ビルドを落として、権限まわり・出力形式・素のtracerouteとの差を手元で測った。

計測結果をJSON・CSVで機械可読に吐けるので、監視やCIへ組み込む前提でも選べる。自動化ツール全体の見取り図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめてある。

trippyとは——traceroute と mtr コマンドの間を埋めるRust製TUI

Homebrewの説明文は「Network diagnostic tool, inspired by mtr」で、リポジトリの説明は素っ気なく「A network diagnostic tool」。実態としては、経路の特定（traceroute的）と継続計測（mtr的）を1つのTUIでやるツールだ。

対応プラットフォームはLinux・macOS・Windows・FreeBSD・NetBSDと広く、Homebrew・apt・snap・cargoなど主要な配布経路が揃っている。★7,615・fork 268で、Rust製CLIとしては十分に大きい部類だ。

インストールはmacOSならHomebrewが最短だが、公式リリースのビルド済みバイナリを落としてもいい（今回はこちらを使った）。

# Homebrew（配布されるのは 0.13.0）
brew install trippy

# 公式リリースのビルド済みバイナリを直接使う場合（Apple Silicon）
curl -LO https://github.com/fujiapple852/trippy/releases/download/0.13.0/trippy-0.13.0-aarch64-apple-darwin.tar.gz
tar xzf trippy-0.13.0-aarch64-apple-darwin.tar.gz
./trippy-0.13.0-aarch64-apple-darwin/trip --version   # → trip 0.13.0

配布の広さも実測しておく。0.13.0のリリースには17個のアセットが付いており、対応の広さがそのまま並んでいる。

armv7のmusl系まで3種類ぶん用意されているあたりに、ルーターやSBCで動かす想定が透けている。Rust製で単一バイナリなので、ランタイムを別途入れる必要はない。

実測：macOSなら -u でsudoなしに動く

trippyの最大の実用上の差は、権限まわりにある。生ソケット（raw socket）を使うツールは通常root権限が要るが、trippyには非特権モードがある。手元のmacOS（Apple Silicon）でプロトコル3種 × -u の有無、計6通りを実際に叩いた。

どの経路で権限問題を解くかは、OSと目的で機械的に決まる。

# 対象は自分のループバックまたは自分が管理するルーターに限定すること
GW=$(route -n get default | awk '/gateway/{print $2}')   # 自宅ルーターのIP

# -u を付けない（既定）
trip -m json -C 1 -p icmp 127.0.0.1
# → Error: privileges are required (hint: try adding -u to run in unprivileged mode)

# -u を付ける（非特権モード）
trip -m json -C 1 -u -p icmp 127.0.0.1     # → JSONが返る
trip -m json -C 1 -u -p udp  127.0.0.1     # → JSONが返る
trip -m json -C 1 -u -p tcp  127.0.0.1     # → JSONが返る

結果は明快で、-u なしは3プロトコルとも privileges are required、-u ありは3プロトコルとも成功した。エラーメッセージ自体が -u を案内してくるので迷いにくい。

これは公式ドキュメントの記述とも一致する。Privilegesガイドは、非特権モードがICMP・UDP・TCPのすべての計測モードで使えること、ただし対応プラットフォームは限られることを明記している。

・macOSのみ対応。Linuxは「将来追加される可能性がある」段階
・NetBSD・FreeBSD・Windowsは非対応。理由は IPPROTO_ICMP ソケット型をこれらのOSがサポートしないため
・非特権モードを使わない場合の権限付与は3通り——sudo trip、setuidビットを立てる、Linuxなら sudo setcap CAP_NET_RAW+p $(which trip)
・Linuxでcapabilityを使う場合、trippyは生ソケット作成後に全capabilityを落とす設計になっている

Linux運用なら setcap CAP_NET_RAW+p が現実的な落とし所だ。sudo trip には設定ファイルの置き場所がroot側になるという副作用があり、公式も -c（--config-file）で明示するよう注意している。

非特権モードで失われるもの——Paris/Dublinとdot/flows出力

「sudoなしで全部できる」わけではない。何が使えなくなるかも測った。

# 多重経路（ECMP）を区別する Paris / Dublin 方式を非特権モードで試す
trip -m json -C 1 -u -p udp -R paris  "$GW"
# → Error: Paris tracing strategy cannot be used in unprivileged mode
trip -m json -C 1 -u -p udp -R dublin "$GW"
# → Error: Dublin tracing strategy cannot be used in unprivileged mode
trip -m json -C 1 -u -p udp -R classic "$GW"
# → JSONが返る（既定の Classic 方式は動く）

そしてこの制限は出力形式にも波及する。dot（Graphviz形式）と flows は多重経路の識別を前提とするため、非特権モードでは次のように拒否される。

$ trip -m dot   -C 2 -u -p udp $GW
Error: this mode requires the paris or dublin multipath strategy
$ trip -m flows -C 2 -u -p udp $GW
Error: this mode requires the paris or dublin multipath strategy

つまりロードバランスされた経路を枝分かれとして描きたいなら、結局sudoが要る。一方、単純に「どこで詰まっているか」を見たいだけなら既定のClassic方式で足り、非特権のまま完結する。日常のトラブルシュートで困る場面は少ない。

なお他にも実測で分かった制約がある。パケットサイズは48〜1024バイトの範囲（--packet-size 1200 は範囲外エラー）で、IPv6を明示する -6 は対象がIPv4アドレスだと当然ながら解決に失敗する。

出力形式の実測——JSONに mtr にはないジッタ4指標が入る

trippyはTUI（既定）以外に複数の出力モードを持つ。自宅ルーターへ向けて実際に全モードを叩いた結果が下表だ。

markdown モードの出力はそのまま貼れる形で返ってくる。

trip -m markdown -C 2 -u 192.168.10.1

| Hop | IPs          | Addrs    | Loss% | Snt | Recv | Last | Avg | Best | Wrst | StdDev |
|-----|--------------|----------|-------|-----|------|------|-----|------|------|--------|
| 1   | 192.168.10.1 | aterm.me | 0.0   | 2   | 2    | 2.2  | 2.5 | 2.2  | 2.8  | 0.3    |

表として出るのは11列で、pretty / markdown / csv のいずれでも同じ構成だった。

・Hop / IPs / Addrs — TTL、そのホップで応答したIP、逆引きしたホスト名
・Loss% / Snt / Recv — 累計のロス率、送信数、受信数
・Last / Avg / Best / Wrst / StdDev — 直近・平均・最良・最悪のRTTと標準偏差

JSON出力にはこの11列に加えて、計測全体の開始・終了時刻（info.start_timestamp / info.end_timestamp、ISO8601のUTC）と、ホップごとの extensions（ICMP拡張）・nat・tos が入る。表に出ない情報がJSONにだけ入っているので、機械処理するなら最初からJSONを選ぶのが素直だ。

そしてJSONモードは、表形式には出てこない指標まで持っている。実際の応答（自宅ルーターへ3サイクル）から1ホップ分を抜くと次の通りだ。

{
  "ttl": 1,
  "hosts": [{ "ip": "192.168.10.1", "hostname": "aterm.me" }],
  "loss_pct": "0.00", "sent": 3, "recv": 3,
  "last": "3.27", "avg": "3.10", "best": "2.98", "worst": "3.27", "stddev": "0.12",
  "jitter": "0.22", "javg": "1.09", "jmax": "2.98", "jinta": "2.18",
  "nat": null, "tos": 0
}

・jitter — 直近サンプルの揺らぎ
・javg — ジッタの平均
・jmax — ジッタの最大
・jinta — RFC1889系の補間ジッタ（インターアライバル・ジッタ）

「つながるが遅い」「音声が途切れる」タイプの障害はRTTの平均値だけでは切り分けられない。ジッタが取れると、平均は良好なのに揺らぎが大きいホップを名指しできる。macOS同梱の /usr/sbin/traceroute は setuid root（-r-sr-xr-x root wheel）で権限問題こそ起きないが、出すのは各プローブのRTTだけで、ロス率もジッタも継続的な統計も返さない。この差がtrippyを入れる主な理由になる。

同じ「自分のマシンの通信を測る」系統では、TapMapとは｜PCの通信先を世界地図でリアルタイム可視化するOSSが通信先の分布を見る側、trippyが経路の質を見る側、という住み分けになる。ターミナル常駐型の運用ツールという括りではPodman TUI：ターミナルだけでコンテナをフル管理できるGo製軽量ダッシュボードと同系統だ。

mtr コマンドから乗り換えるときの実運用——stream出力を監視に流す

TUIで眺めるだけならmtrと大差ないが、trippyが効いてくるのは計測結果をそのまま機械に渡すときだ。-m stream は1サイクルごとに1行を吐き続けるので、while で回すよりもそのままパイプに流せる。自宅ルーターへ向けた実際の出力がこれだ。

trip -m stream -u 192.168.10.1

Tracing to 192.168.10.1 (192.168.10.1)
ttl=1 addrs=192.168.10.1 exts= loss_pct=0.0 sent=1 recv=1 last=2.9 best=2.9 worst=2.9 avg=2.9 stddev=0.0
ttl=1 addrs=192.168.10.1 exts= loss_pct=0.0 sent=2 recv=2 last=3.1 best=2.9 worst=3.1 avg=3.0 stddev=0.1
ttl=1 addrs=192.168.10.1 exts= loss_pct=0.0 sent=3 recv=3 last=2.8 best=2.8 worst=3.1 avg=3.0 stddev=0.1

sent と recv が累積で増えていくので、ある時点までの累計ロス率をそのまま読める。ログに流し込んでおけば、後から「何時何分から悪化したか」を追える。

CSVはヘッダ行つきで1サイクル1行なので、表計算や時系列DBへの取り込みに向く。

Target,TargetIp,Hop,IPs,Addrs,Loss%,Snt,Recv,Last,Avg,Best,Wrst,StdDev
192.168.10.1,192.168.10.1,1,192.168.10.1,aterm.me,0.00,2,2,2.7,2.83,2.7,2.9,0.11

サイクル数の指定に使うフラグ名だけ注意が要る。0.13.0では --max-rounds は存在しない。

trip -m json --max-rounds 2 127.0.0.1
# → error: unexpected argument '--max-rounds' found
#    tip: a similar argument exists: '--max-round-duration'

# 正しくはこちら
trip -m json -C 2 -u 127.0.0.1        # -C / --report-cycles でサイクル数
trip -m json -T 1s -u 127.0.0.1       # -T / --max-round-duration で1ラウンドの上限時間
trip -m json -i 1s -u 127.0.0.1       # -i / --min-round-duration で1ラウンドの下限時間

-C は「レポートを何サイクルぶん取るか」で、-i/-T は1サイクルの長さを決める。既定はどちらも1秒なので、-C 60 はおおむね1分ぶんの計測になる。監視に組み込むなら -C で有限回にし、TUIモード（既定）に落ちないよう -m を必ず明示するのが安全だ。

なお実測で判明した細かい制約も挙げておく。パケットサイズは 48〜1024バイトの範囲外を渡すとエラーになる（--packet-size 1200 は must be between 48 and 1024 inclusive で拒否）。IPv4アドレスを指定したまま -6 を付けると、当然ながらアドレス解決に失敗して止まる。

プロトコルはどれを選ぶか——ICMP・UDP・TCPの使い分け

trippyは3つのプロトコルで計測でき、既定は icmp だ。非特権モード（-u）では3つとも動くことを実測で確認しているので、選択の基準は権限ではなく「何を測りたいか」になる。

「pingは通るのにアプリだけ遅い」といった症状では、icmp の結果だけを見ても足りない。実際に使うポートへ tcp で当てて比べると、経路のどこで扱いが変わっているかが見える。ただし本記事の実測はループバックと自宅ルーターに限定しているため、プロトコル別に結果が割れる実例までは検証していない（未検証）。ここは各自の環境で確かめてほしい。

出た数字をどう読むか——ロス率は「最後のホップ」で見る

trippy に限らずこの系統のツールで最も誤読されるのが途中ホップのロス率だ。経路の途中でロスが出ていても、その先のホップでロス0%なら、実際のトラフィックは通っている。中継ルーターが自分宛のICMP応答を後回しにしているだけ、というケースが多いためだ。

・最終ホップのロス率を見る。ここが0%なら、途中の赤字は基本的に無視してよい
・あるホップ以降がすべてロスしているなら、そこが本当の切れ目
・平均RTTは良いのにジッタ（jitter / jmax）が大きいホップは、輻輳やバッファ肥大を疑う
・Snt と Recv の差が広がり続けるなら、瞬間的な障害でなく継続的な劣化

trippyが Last / Avg / Best / Wrst / StdDev を並べて出すのは、この読み方を1画面で完結させるためだ。1回きりの traceroute では「たまたま遅かった」と「ずっと遅い」を区別できない。区別が必要になった時点が、このツールを入れる理由になる。

リリースは16か月止まっているが開発は動いている

導入前に必ず確認したいのが版の状態だ。GitHubの最新リリースタグは 0.13.0（2025-05-05公開）で、記事執筆時点から約16か月前。Homebrewのformulaも stable: 0.13.0 を指している。ここだけ見ると開発停止に見える。

しかし実際は違った。

# タグとmasterの差をGitHub APIで数える
gh api repos/fujiapple852/trippy/compare/0.13.0...master --jq '{ahead: .ahead_by}'
# → {"ahead": 226}

# masterのワークスペースversionを見る
gh api repos/fujiapple852/trippy/contents/Cargo.toml --jq '.content' | base64 -d | grep -A1 "^\[workspace.package\]"
# → version = "0.14.0-dev"

masterは0.13.0から226コミット先行し、バージョンは 0.14.0-dev、最終pushは2026-08-31。開発は現役で、単にリリースを切っていないだけだった。★7,615・fork 268・オープンなIssue 79という数字とも整合する。

ここから実務上出てくる注意点が1つある。公式ドキュメントサイト（trippy.rs）はバージョン切り替えを持ち、既定が「Latest」＝master相当になっている。つまりドキュメントに書いてあるフラグが、Homebrewで入る0.13.0には存在しない可能性がある。実際、今回の検証でも --max-rounds というフラグはドキュメント的に自然に見えるが0.13.0には無く、-C（--report-cycles）と -T（--max-round-duration）が正解だった。手元の trip --help を正としてコマンドを組むのが安全だ。

# ドキュメントでなく手元のバイナリのヘルプで確認する
trip --version          # → trip 0.13.0
trip --help | grep -E "report-cycles|unprivileged|protocol"

まとめ｜mtr コマンドの代わりにtrippyを入れるかの判断軸

計測は2026-08-31 JST、対象は0.13.0（aarch64-apple-darwin）。すべてループバックと筆者管理下のルーターに対してのみ実行した。

・macOSユーザーには入れる価値がある：-u でICMP・UDP・TCPすべてがsudoなしで動く。mtrを入れる手間と権限の問題を同時に解決できる
・Linux/Windowsユーザーの動機は別：非特権モードは使えないので、mtrに対する優位はジッタ指標と出力形式（JSON/CSV/Markdown/stream）になる。Linuxなら setcap CAP_NET_RAW+p が実用的
・多重経路を描きたいならsudoが要る：Paris/Dublin方式は非特権モードで拒否され、dot/flows 出力も連動して使えない
・版のずれに注意：配布されるのは0.13.0（2025-05-05）、masterは226コミット先行の 0.14.0-dev。ドキュメントはmaster寄りなので trip --help を正とする
・監視への組み込みは得意：-m stream の1行1サンプル出力と -m json を使えば、既存の監視パイプラインに乗せやすい
・フラグ名は手元で確認する：0.13.0に --max-rounds は無く、サイクル数は -C（--report-cycles）。traceroute 使い方の記事や公式ドキュメントの記述をそのまま貼ると通らないことがある

逆に、単発で経路だけ見たいならmacOS同梱の traceroute で十分で、わざわざ入れる必要はない。継続的に測って数字を残したくなった時点がtrippyの出番だ。

導入判断を一言でまとめるなら、「経路を知りたい」なら既存のtracerouteで足り、「経路の品質を数字で説明したい」ならtrippyになる。障害報告に貼る根拠が要る、あるいは時系列で劣化を追いたい——この2つのどちらかに当てはまるかどうかが、実質的な分かれ目だ。

参照ソース

・fujiapple852/trippy — 公式リポジトリ・README（2026-09-01アクセス）
・Trippy: Privileges ガイド — 非特権モードの対応プラットフォームと権限付与方法（2026-09-01アクセス）
・Trippy 0.13.0 リリース — 配布バイナリと公開日（2026-09-01アクセス）
・Homebrew formula: trippy — 配布される安定版の確認（2026-09-01アクセス）