セルフホスト型のエージェントを誰かに乗せてやった経験が何度かあれば、次の場面をスローモーションで見たことがあるはずだ。
友人が「Hermes で web search ってどうやるの」と聞いてくる。あなたは説明する：Firecrawl にサインアップして、ダッシュボードから API key を引っ張り出して、.env に貼って、hermes tools を回して、チェックを入れる。彼はやる。動く。2 日後、彼は画像生成が欲しくなる。あなたは説明する：FAL にサインアップして、ダッシュボードから API key を引っ張り出して、.env に貼って、hermes tools を回して、チェックを入れる。彼は少し疲れた顔をする。次に TTS が欲しいとき、彼はもう聞いてこない。
セルフホスト型のエージェントには、エージェント自身とは関係ない摩擦税がかかっている。ツール単位の key 探しダンス、ツール単位のダッシュボード、ツール単位の更新カレンダー。2026 年 4 月 16 日、v0.9.0 から 3 日後、v0.10.0 が、Nous Portal のサブスクリプションを持つ全員に対してその税の一塊を取り払った。
行数で見るとこのリリースは小さい——3 日でだいたい 180 commits。だが、その 3 日で着地した一つの機能のせいで、v0.10 は記憶の中ではあの一つの名前と等号で結ばれることになる：Nous Tool Gateway。
「マネージドツール」って結局なんなのか
Nous Tool Gateway はサーバサイドのマルチプレクサだ。あなたのマシン上のエージェントは、相変わらず web_search や generate_image を呼ぶ——呼び方そのものは何も変わらない。変わるのは、その呼び出しが今度は Nous のゲートウェイに着地し、ゲートウェイ側が上流の API key を持って、あなたではなくあなたのポータルサブスクリプションに請求するという点だ。
第一波は 4 つのツール、リリースノートからそのまま：
- •Web search、Firecrawl 経由
- •画像生成、FAL 経由、モデルは FLUX 2 Pro
- •テキスト読み上げ、OpenAI TTS 経由
- •ブラウザ自動化、Browser Use 経由
これらは新しいツールではない。あなたが今までずっと自分で繋げたツールだ——アカウント 4 つと .env 4 行で。v0.10.0 が変えたのは、もうそうする必要がない、という点だけだ。
ツール単位でゲートウェイを使うかどうかを選べる。スイッチは hermes model が公開する use_gateway 設定にぶら下がっている。あるツールに直結の API key を既に設定していれば、ランタイムは引き続き直結を優先する——ゲートウェイは保険であり、乗っ取りではない。粒度は個別ツール単位であって、インストール全体ではない。
ドアの前で死んだあの環境変数
v0.8/v0.9 系を回していたなら、たぶん HERMES_ENABLE_NOUS_MANAGED_TOOLS を覚えているはずだ。v0.10.0 はこれを削った。サブスクリプションそのものが今や信号だ：ポータルにログインすれば、ゲートウェイが点灯し、ツールが動く。覚えるスイッチはなく、マシン間で同期する .env 行もない。
hermes tools と hermes status もどちらもゲートウェイを意識するようになった。前者はどのツールが直結で、どれがマネージドで、どれがオフかをひと目で見せる。後者はゲートウェイ接続そのものを確認する。小さなコマンド 2 つだが、これで「今どの key が動いてるんだっけ」という問いが一行の出力に圧縮された。
これが見かけより大きい理由
上で書いた摩擦税は、どんなベンチマークにも出てこない。「Firecrawl をセットアップするのに友人が浪費した分」というグラフを描いた人はいない。だが、セルフホストでエージェントを回している人は誰もがこの税を払っていて、ほとんどの人は 5 つ目か 6 つ目のツールを足す前にやめる。限界の手間が限界の便益を上回るからだ。
趣味でやっている人にとっては、この税は単に煩わしい。共有 VPS で Hermes を回している小さなチームにとっては、これは所有権の問題に変わる：Firecrawl の請求書を引き受けているのは具体的に誰で、その人が辞めたら web search はどうなる？
ゲートウェイはその表面積を一括で巻き取る。サブスクリプション一つ、ツール 4 つ、請求の管理は一箇所。データベースをマネージドサービスに預ける日にあなたが結ぶ取引と同じ形だ——コントロールを少し手放して、その代わりに日曜の午後を取り戻す。
代償もあって、リリースノートはその部分を糊塗していない。ゲートウェイを通すというのは、Nous を経由するということで、Nous がこれまで見ていなかったクエリのメタデータを見るということだ。ゲートウェイがツール単位でオプトインになっているのはまさにこれが理由だ——取引は無条件ではない。あるツールでゲートウェイを使いたくないなら、あなたの直結の API key はそこに残っていて、ランタイムはそれを使い続ける。重要なのは、これが今や「使う／使わない」を選ぶ行為になったことであって、選ぶ前段階で飛び越えなければならない輪ではなくなったことだ。
それ以外は、さっと
v0.10.0 は tool gateway 中心のリリースだ。このリリースには TUI の書き直しは含まれない——それは v0.11.0 の仕事だ。新しいチャットプラットフォームもない——その波は v0.12.0 から再起動する。それでも 180 以上の commit がエージェントのコア、ゲートウェイ、CLI、tool 基盤を横断している。v2026.4.13 から v2026.4.16 までの完全な diff は GitHub にある、行ごとに読みたければそちらへ。
ケイデンスは進み続ける。前のリリースから 3 日、メジャーな新機能 1 つ、誰も見ていないところで片付けられた deprecation 1 つ。
---
v0.10.0 が面白いのは、行数で見るとこんなに小さいのに、変えたもの——「誰が Hermes を回せるか」——はこんなに大きい、というギャップにある。v0.9.0 はプラットフォームを 3 つ増やした。v0.10.0 は 1 つも増やしていない。だがすでに持っているツールを回すコストを十分に下げて、「key の管理が面倒で諦めた」というカテゴリの利用者群を丸ごと連れ戻している。
このあたりのリリースカレンダーを通して見ると、一つのパターンが浮かんでくる：半分の版が能力を積み、もう半分が摩擦を剥がす。v0.10.0 は紛れもなく後者だ。2 週間後の v0.12.0 も同じ系統になる——あなたが寝ているあいだに Autonomous Curator が現れて、skill ライブラリを刈り込みにいくのがそれだ。ケイデンスはこのプロジェクトを速く見せる。形状——能力の週、摩擦の週、能力の週——がこのプロジェクトを持続可能に感じさせる。