uv tool install で入れた CLI は便利です。
でも数が増えると、いつのまにか「入っているが古い」「どれを更新すべきかわからない」「本当に使っているツールかも怪しい」という状態になりがちです。
Python の依存関係には uv lock や uv sync がある一方で、個人の道具箱としての CLI 群は、少し管理の粒度が違います。
プロジェクトごとの再現性よりも、ローカル環境の衛生管理や、CI・Docker イメージ内のツール保守が課題になります。
uv 0.10.10 で入った uv tool list --outdated は、この地味だが確実に溜まる負債を見える化する機能です。
派手な新機能ではありませんが、CLI を「気分で足すもの」から「継続的に整備する資産」へ変える一歩だと感じました。
何が追加されたのか
uv 0.10.10 の release notes には、Enhancements として次の1行が載っています。
Add
--outdatedflag touv tool list
これまで uv tool list は、インストール済みのツールを列挙するコマンドでした。
そこに --outdated が付いたことで、**「何が入っているか」だけでなく「何が古いか」**を直接見られるようになりました。
ここで重要なのは、この機能が dependency management ではなく tool management に入ったことです。
- プロジェクト依存は
pyproject.toml/uv.lockで管理する - 個人や環境の CLI は
uv toolで管理する - その更新余地の確認は
uv tool list --outdatedで行う
つまり uv は、Python パッケージ管理だけでなく、開発者の作業道具一式の運用面まで責任範囲を広げ始めています。
なぜこれは嬉しいのか
1. 道具箱の負債は、壊れてから気づく
ローカルに入れた CLI ツールは、アプリ依存ほど厳密に監視されません。
たとえばこんな状態が起きます。
ruffは毎日使うから更新しているmypyは半年前のままhttpieやmkdocsは「入ってるけど最近使ってない」pre-commitは CI とローカルで微妙にズレている
この種の負債は、普段は困らないぶん見逃しやすいです。 そして問題が出るのは、次のようなタイミングです。
- 新機能や新しいフラグが使えない
- バグ修正が入っているのに古いまま
- チュートリアル通りのコマンドが動かない
- チームメンバーや CI と挙動がズレる
uv tool list --outdated があると、こうした状態を故障後の発見ではなく定期点検に変えられます。
2. 依存管理と違って、ツール管理は「全部上げればよい」とも限らない
ここが面白いところです。
アプリ依存なら、lockfile に従って更新を制御するのが基本です。 しかし CLI ツールは、次のような別の判断軸を持っています。
- そのツールを今も使っているか
- 更新でワークフローが壊れないか
- チームや CI とバージョンを揃える必要があるか
- Docker イメージや bootstrap script に反映すべきか
--outdated は自動更新ではなく棚卸しの入口です。
ここが設計として良い。
もし uv tool upgrade --all のような操作だけが先にあると、更新はできても「何を・なぜ上げるか」が曖昧になります。
一方、まず一覧で差分を見るようにすると、道具箱を **inventory（資産台帳）**として扱いやすくなります。
uvx 文化との相性
uv の tool interface は、そもそも「インストールしなくても実行できる」思想が強いです。
- 一回限りなら
uvx - 常用するなら
uv tool install
という住み分けになっています。
この設計の帰結として、常用ツールだけが persistent に残るはずです。
だから uv tool list --outdated が意味を持ちます。
もし何でもかんでもグローバル install する文化だと、一覧はすぐノイズだらけになります。
しかし uv は、短命な実行は uvx に逃がし、継続利用するツールだけを uv tool に残す。
その上で outdated を見るので、リストの密度が比較的高く保たれます。
これは単なる便利機能ではなく、使い捨て実行と常設ツール管理の境界が明確だからこそ効く機能です。
どんな運用が変わるか
個人開発: 「気づいたら古い」を減らせる
個人開発では、まず月1回でもよいので uv tool list --outdated を見るだけで変わります。
例えば次のような運用がしやすいです。
- outdated 一覧を見る
- 毎週使うツールだけ更新候補にする
- しばらく使っていないものは削除候補にする
- 重要ツールだけ更新後に
--versionや主要コマンドを確認する
ここで大事なのは、「全部更新する」よりも「使っている道具を把握する」ことです。
CI / Docker: ベースイメージの古さを見つけやすい
CI や Docker イメージでは、ビルド用・チェック用の CLI が層として固定されがちです。
ruffmypypytest関連の補助 CLImkdocspre-commit
こうしたツールを uv tool install ベースで組んでいる場合、uv tool list --outdated はメンテナンス対象の発見器になります。
特に良いのは、「今のイメージに何が残っていて、それがどれだけ遅れているか」を人間がすぐ見られることです。 ロックファイルの差分よりも直感的で、環境整備タスクに落とし込みやすい。
チーム運用: 『推奨ツール群』の見直しに使える
チームで onboarding ドキュメントや bootstrap script を持っている場合も有効です。
たとえば、開発者マシンに入れる前提のツール群を uv tool に寄せておくと、
- どのツールが現役か
- どれが更新停滞しているか
- そもそも消してよいものは何か
を見直しやすくなります。
つまり --outdated は更新のためだけでなく、標準道具箱のリファクタリングにも使えます。
これは「パッケージ管理」ではなく「衛生管理」の機能
この機能を見て最初に思ったのは、dependency solver としての uv がまた賢くなった、ではありませんでした。 むしろ逆で、運用の衛生管理に踏み込んできたという印象です。
開発環境の問題は、依存解決よりも次のようなところで起きます。
- 何が入っているかわからない
- どれが古いかわからない
- 誰も棚卸ししていない
- 消してよいものが放置される
これは npm / pip / cargo のようなエコシステム固有の問題ではなく、 開発者が自分の道具箱を長く使うと必ず起きる運用問題です。
uv tool list --outdated は、その問題に対する最小限で妥当な答えです。
いきなり全部自動化するのではなく、まず観測面を与える。
この順番が良いです。
まだ足りないもの
もちろん、これで道具箱管理が完成したわけではありません。 今後あると嬉しいのは例えば次のあたりです。
- JSON 出力などの機械可読フォーマット
- outdated の件数だけを簡単に取るモード
- 「最後に使った日時」のような棚卸し補助情報
- CI で扱いやすい exit status 設計
- ツール更新の dry-run / diff 体験の強化
特に JSON 出力があると、
- 定期ジョブで棚卸し
- 週次レポート化
- dotfiles / bootstrap script の見直し
までつなげやすくなります。
ただ、最初の一歩としては十分に価値があります。 なぜなら、道具箱管理で一番足りていないのはたいてい制御機能ではなく可視化だからです。
まとめ
uv 0.10.10 の uv tool list --outdated は、小さな追加に見えてかなり本質的です。
この機能が変えるのは、単なる更新手順ではありません。 開発用 CLI 群を、放置前提の私物から、点検対象の資産へ見立て直すことです。
uvxで一時実行uv tool installで常用ツールを保持uv tool list --outdatedで負債を棚卸し
この流れが揃うことで、uv は Python パッケージ管理ツールを超えて、 開発者のローカル環境そのものを整備する道具に近づいています。
派手ではないけれど、長く効く改善です。 個人的には、こういう機能こそ毎日の開発体験をじわじわ変えるタイプの進化だと思います。