Hermes と Solid のどちらを選ぶか迷っているなら、ここに挙げる 5 つの質問を先に自分に投げかけてみてほしい。
初めて Hermes と Solid を比較したとき、私は機能の差で決まると思っていた。
メモリ。ツール使用。ブラウザ自動化。長時間実行タスク。
しかし、両方のプロジェクトを詳しく調べれば調べるほど、その比較はあまり意味をなさないと気づいた。両者は同じ問題を解決しようとしているわけではないのだ。
Hermes は、ユーザーが自分のインフラに合わせて形作れる、オープンで持続可能なエージェントを提供することに重点を置いている。Solid は、エージェントがコード生成を超えて現実世界の実行にまで作業を進めるために必要なリソースを提供することに焦点を当てている。以下の 5 つの質問は、個々の機能ではなく、この違いに基づいている。
質問 1: スタックを自分で所有したいか、それとも委任したいか?
これは通常、最初に問う質問であり、同時に毎日エージェントを実際に使うのは誰かという問いにもなる。
Hermes では、エージェントをどこで実行するか、どのモデルを使うか、メモリをどう保存するか、どのサービスに接続するか、システムをどう進化させるかを自分で決められる。この柔軟性は最大の強みの 1 つであり、インフラの管理、統合、継続的なメンテナンスに慣れている開発者や技術チームに自然にフィットする。
Solid は、その運用環境の多くをプラットフォームの一部として提供する(管理されたマシン、ID、決済機能、デプロイインフラなど)。いくらかの制御を譲る代わりに、結果に集中する時間が増え、配管作業に費やす時間が減る。
ユーザーによっては、制御こそが重要なポイントである。別のユーザーにとっては、それを委ねることこそが大きな利点となる。

質問 2: 実際の作業はどこで行われるのか?
モデルそのものだけでなく、作業が行われる環境にも目を向けよう。
エージェントが主に、すでに自分が管理しているインフラ(自分のマシン、サーバー、コンテナ、SSH ホスト、クラウド環境)で動作するのであれば、Hermes はその設定に自然に適合する。
ワークフローが単一の環境を超えて広がる場合、Solid の方が面白くなる。タスクによっては、異なるオペレーティングシステムとの連携、Android デバイスへのアクセス、SMS 確認コードの受信、購入、アプリケーションのデプロイなど、作業が完了するまでに様々なステップが必要になる。
Hermes は、その環境を構築する柔軟性を提供する。Solid は、その多くを最初から備えている。

質問 3: エージェントはどの ID を使うべきか?
エージェントが外部サービスとやり取りし始めると、ID が議論の一部になる。
Hermes では、エージェントは通常、接続したアカウントと認証情報を通じて動作する。これにより、権限を完全にコントロールできるが、同時にアクセス管理の責任も負うことになる。
Solid は、管理された ID と電話番号を使って動作でき、個人の認証情報は実際に必要なときだけ関与する。タスクにサービスへのサインアップ、アカウント確認、外部プラットフォームとのやり取りが含まれる場合、エージェントがどの ID を使うかは、どのモデルを搭載するかと同じくらい重要な判断になる。見落としがちな細かい点だ。

質問 4: タスクにはお金の支出が伴う可能性があるか?
多くのワークフローは、最終的に有料リソースを必要とする。ドメイン購入、API の上位プラン、タスク完了に必須のサブスクリプションなどだ。
Hermes では、これらはすでに管理しているアカウント、プロバイダー、課金システムを通じて行われる。エージェントがアクセスできるものと、どのような保護策を講じるかを自分で決める。
Solid は、エージェントに管理されたワークスペース残高を与え、タスク完了に必要な場合に承認された購入に使用できるようにする。支出上限や承認チェックポイントを設定することで、ユーザーがコントロールを維持できる。エージェントが購入 できる かどうかよりも、購入がワークフローの一部として 想定されている かどうかの方が重要だ。

質問 5: 「完了」とは実際には何を意味するのか?
この質問が、私にとってすべてを結びつけるものだった。
ある人にとって、「完了」とは、エージェントがトピックを調査し、コードを書き、ブラウザタスクを自動化し、以前の会話を記憶し、完成した結果を提供することを意味する。それが目標であれば、Hermes はすでに強力な基盤を提供している。
別の人にとって、「完了」には、コードを書いた後に起こるすべてが含まれる。
アカウントの作成。確認コードの受信。サービスの購入。アプリケーションのデプロイ。本番環境で実際にすべてが正しく動作することを確認する。
Solid はそこに焦点を当てている。どちらのプラットフォームを選ぶ前に、自分の仕事における「完了」の意味を定義しよう。
TLDR: クイック決定ガイド
Hermes は以下の場合に適している可能性が高い:
- オープンソースのエージェントを希望する。
- セルフホスティングまたはローカルモデルを好む。
- 既にインフラが整っている。
- エージェントの構築方法と拡張方法を完全にコントロールしたい。
- ワークフローのカスタマイズや新しい機能の実験を楽しむ。
Solid は以下の場合に適している可能性が高い:
- 管理されたエクスペリエンスを好む。
- 管理されたデバイス、ID、電話番号が必要。
- ワークフローに支払い、デプロイ、外部サービスが含まれると予想される。
- インフラを自分で運用するよりも、結果を重視する。
3 つの実世界のシナリオ
個人用 AI アシスタントの構築。 Hermes に傾く。会話を記憶し、自分のハードウェアで動作し、ローカルモデルと連携し、時間をかけてカスタマイズできるアシスタントは、まさにそのオープンなアーキテクチャが構築された目的だ。
Web アプリケーションの構築とリリース。 ここで Solid がより理にかなってくる。アプリケーションを書くのは作業の一部に過ぎない。ワークフローには、アカウント作成、サービスの購入、ID 確認、デプロイ、本番環境で正しく動作するかの確認も含まれる可能性がある。これらの運用ステップこそ、Solid が実行するために構築されたものだ。
研究と実験。 Hermes。新しいモデルをテストしたり、カスタムエージェントワークフローを構築したり、メモリシステムや異なる実行環境を探求したりする場合、スタックを完全に制御できることは真の利点である。
ワークフロー全体の委任。 もう一度 Solid を見てみよう。今度は、最初からコードとは無関係の作業に対してだ。競合他社を調査し、必要なツールを購入し、ダッシュボードを立ち上げ、結果を確認してから返すようにエージェントに依頼することを想像してほしい。そのようなエンドツーエンドの実行こそ、Solid が存在する理由そのものだ。
最後にひとこと
自分が解決しようとしている問題がわかれば、両者の選択は簡単だ。





