執筆時点で、Artie は 17 人のチームです。私たち全員が Hermes とともに仕事をしています。Hermes は @NousResearch が提供するオープンソースの AI エージェントハーネスです。ドイツにある単一の物理マシン上で動作し、各チームごとに異なるペルソナを持ち、夜には「夢」を見ます。
これは、どのようにして実現されたのかという物語です。
始まりは、あるエンジニアの WhatsApp 連絡先だった
数ヶ月前、私たちのエンジニアの一人（Ani、@anirudhsriramzz）が、個人用に Hermes を運用していました。あくまで個人的なセットアップで、WhatsApp を通じてやり取りをしていたのです。
同じ頃、CTO の Robin はハッカソンから戻ってきました。友人が、業務をこなすエージェント群を実演していたからです。彼が持ち帰った問いはシンプルでした。「どうすれば Artie の全員、特にエンジニア以外の人々にもこれを活用できるのか？」
まず OpenClaw を検討しました。確かに良いツールです。しかし、エージェントが頼んでもいない方向へ逸脱していくのを簡単に見て取れる状態であり、スケールさせる前にガードレールが必要だと考えていました。そこで Hermes を選び、どのようなガードレールを設けるべきか考え始めました。
視野を狭めた脳
私たちの考え方としては、すべてのラボが「脳」を提供していると言えます。何を聞いても答えてくれる。同じ質問を 5 回すれば、もっともらしい答えが 5 つ返ってきますが、それぞれ形は異なります。
チャットウィンドウではそれで構いません。しかし、「仕事」をさせたい場合には問題になります。セールスエンジニアが 25 件の顧客対応スレッドに関するリスク評価を求めた場合、毎回同じフォーマットで出力されなければ、行動に移せず、週ごとの比較もできず、信頼も置けません。
競走馬にブリンカー（目隠し）をつけるのは、観客ではなくコースだけに集中させるためです。スキルとツールこそがブリンカーであり、ハーネスはそれを装着するための仕組みです。Hermes、Codex、Claude Code などはすべて、同じアイデアのバリエーションです。モデルに何をしてよいか、そして出力をどの形にするかを決定する方法論なのです。
このように捉えた瞬間、プロジェクトは「チャットボットの構築」から「Artie の各業務用のブリンカーを作る」へと変わりました。
ドイツにある月 60 ドルのサーバーがすべてを動かす
Robin と Ani は、ある週末の約 3 時間で最初の Hermes セットアップを完了しました。Railway で最も安いプランを契約し、デフォルトのプロファイルで Hermes を起動して、エンジニアリングチームに任せたのです。
5 日もしないうちに、Railway の使用制限に何度も引っかかるようになりました。アラートが出るたびにアップグレードを検討する羽目に。これが最初の重要な教訓でした。チームが実際にエージェントを導入した瞬間、コストは「サイドプロジェクト」のものではなくなるということです。
本番環境のインフラは AWS 上にあり、今後もそこに留まります。しかし、これはエージェント向けの社内サンドボックスであり、顧客向けインフラではありません。どこまで低コストに抑えられるか試したかったのです。そこでドイツのホスティング会社 Hetzner (@Hetzner_Online) を見つけ、年間 60 ドルで物理マシンを購入しました。現在、Artie のすべての Hermes はこのマシン上で稼働しています。
私たちは小規模で機動的な会社です。Artie における AI の課題はずっと、「予算を無駄遣いせずに、いかにチームを AI ネイティブにできるか」というものでした。Hetzner のマシンはその第一歩でした。
本当に求めていたもの
負荷を処理できるマシンを手に入れた後、私たちは座り込み、Hermes の目的を定めました。目標は 2 つです。
全員に相棒を。 エンジニア、セールス、オペレーション、マーケティング、デザイン。あなたを置き換えるものではなく、より多くのことを達成できるよう支援する「あなたのジュニア版」です。業界では「エージェントが仕事を奪う」という恐怖がありますが、私たちの経験は逆でした。全員が持てば、全員がより早く成果を出し、以前ならできなかった仕事にも挑戦できるようになるのです。
人間は常にループの中にいる。 Hermes は指示されたことは何でもできます。しかし、プロダクション、ドキュメント、あるいは顧客の前に出すものは、必ず人間がレビューします。
人は得意分野を持つ、だからエージェントもそうあるべきだ
17 人のチームにいる誰も、一つのことにしか長けてはいません。しかし、誰もが何か特定の分野で尖っています。私たちはその「尖り」を見て採用します。
では、なぜエージェントが違う必要があるのでしょうか？ マーケティングコピーを書くためにジュニアエンジニアを使うのは無駄です。コードベースの中でジュニアマーケターを使うのはもっと悪手です。私たちはエージェントを人と同じようにモデリングしました。それぞれにドメイン、ペルソナ、そしてそのドメインに必要なアクセス権を与えたのです。
これにより、チームごとに一つずつ、Hermes プロファイルのファミリーが生まれました。
Hermes Plan と Hermes Code はエンジニアリング担当です。Plan はテックリード用で、「A してから B か、それとも A と B を並行して C は後回しにするか」を判断し、書き残します。Plan は作業を Kanban ボードにディスパッチします。Code はチケットを受け取り、既存のコードベースに対してバックグラウンドで実行し、PR を作成して待ちます。人間が PR をレビューし、承認されて初めて master にマージされます。タスクが完了すると、次のタスクが自動的に開始されます。
誰も予測していなかった副作用として、エンジニアリングの時間の大半が「計画」に使われるようになりました。従来、人々はコードと実行に生きていましたが、今はシステム設計とレビューに生き、中間部分を Hermes Code が担っているのです。
Hermes Sales はディスカバリーコール前の準備を行います。見込み客のリサーチ、既存スタックの特定、案件に関する最新コンテキストの取得などです。さらに、当社のドキュメントやエンジニアリング知識にもアクセスできるため、一歩踏み込んだことができます。例えば、見込み客がある特定のツールでデータを移行中だとしたら、Hermes はそのツールがスキーマドリフトなどでどこが破綻しやすいかを、コールが始まる前に担当者へ教えてくれます。
Hermes Design と Hermes Code を組み合わせることで、マーケティングチームはエンジニアを巻き込まずにランディングページのデザイン、構築、公開ができるようになりました。当社のマーケティングサイトは Next.js で構築されており、CMS は使っていません。Design は既存のコンポーネントシステム内で作業し、新しいコンポーネントを発明する前に既存のものがないか確認し、実装のために Code へ引き継ぎます。
Hermes BizOps は反復的な運用業務を担当します。パイプラインレビュー、照合、トラッカー更新、そして人間の介入が必要な例外事項の検出などです。
その他、どれにも当てはまらないもののためのデフォルトプロファイルもあります。
多くは Slack を通じてこれらのエージェントと会話しますが、一部は Hermes デスクトップアプリを使います。いずれにせよ、全体の流れは受動的から能動的へとシフトしました。エージェントはすでにコードベース、ドキュメント、CRM、インターネットへのアクセスを持っているため、コンテキストを与えられるのを待つのではなく、あらゆる場所から回答を引き出せるようになったのです。
初日から、コードのようにバージョン管理されたスキル
プロファイルはペルソナです。スキルは、エージェントを実務的に機能させるものです。
スキルとは、実際の業務クラスに対する再利用可能な手順書です。何を最初にチェックするか、どの情報源が権威あるか、出力はどのような形か、どう検証するか。私たちは最初の週から独自にスキルを作成し、Git リポジトリに格納しました。すべての Hermes がそこから読み込みます。スキルに変更があればコミットとなり、履歴が残ります。すべてのプロファイルがこの変更を反映します。
あまりにも多くのスキルを書かないよう、意図的に慎重になりました。AI を活用する方法は無数にあり、ネット上の大半は「自律型エージェントの 24/7 ファクトリーを作れ」と言います。トークンが無制限ならいいでしょう。しかし、私たちは違います。数百ものスキルの中から使うものを選ぶためにエージェントが翻弄されると、判断そのものにトークンを消費してしまいます。そのため、コストに見合う価値が明白でないものはすべて切り捨て、今も削り続けています。
最終的に辿り着いたルールはこうです。「価値が明白なら、コストは正当化される。価値が曖昧なら、作らない。」
Hermes は夢を見る
Hermes には cron システムがあります。タスクと頻度を与えれば、自律的に実行します。
Anthropic のエージェントメモリに関する研究に触発され、私たちは人間が行うことの一つを模倣することにしました。REM 睡眠中、脳は一日の出来事を整理します。いくつかは長期記憶に昇格し、いくつかは破棄されます。引っ越しや旅行が続いた一年が印象深いのは、繰り返しがなかったからです。
そこで毎晩、誰も使っていない時間帯に、各 Hermes は「夢」を見ます。その日の行動を振り返り、何が有用で何がそうでないかを判断し、有用な部分をメモリに昇格させ、他を降格させます。その後、エンジニアにレポートを送信します。レポートにはこう書かれています。「ここを間違えました。あそこも間違えました。修正しました。修正内容を保存しました。そして、ミスを招いた習慣を忘れました。」
数週間経つと、各プロファイルは自分のチームにとって何をすべきか、何をすべきでないかについて、より強い意見を持つようになります。私たちは意見をプログラムしたわけではありません。それは「夢」から生まれたのです。
なぜ自社でハーネスを運用するのか
なぜ Cursor や Codex、Claude Code を使わないのかと聞かれます。
使ってもいいですし、技術的には明日にでもワークロードを移行できます。しかし、Hermes を自社で運用・管理しているからこそ、基盤となるモデルは誰のものを採用しても構わないのです。もしあるラボが来週値上げするなら、私たちは乗り換えます。現在のプロファイルは十分に安定しており、モデルを入れ替えても壊れません。月曜日は Anthropic のモデルを使っていても、価格が変われば金曜日には OpenAI に移行しているかもしれません。
二つ目の理由は機能です。Cursor が必要な認証に対応していなかったり、コードベースで同じミスを繰り返したりする場合、あなたはチケットを切って待つしかありません。Hermes が必要なものがあれば、私たちは自分で作ります。Hermes は Artie の一部であり、内部ツールとしてシステムに組み込まれています。後付けで「うまく動くことを祈る」ようなものではありません。
現在、AI エンジニアリングが高価なのは、トークン経済学がまだ確立されていないからです。いつか、こうしたことの運用はほぼ無料になるでしょう。それまでは、ハーネスを所有することが、コストをコントロールするための唯一の方法なのです。
現状とこれから
Hermes はおそらく完成度の 85〜90 パーセントといったところです。毎日、実際の仕事をこなしています。ただし、最初のパスが常にベストとは限りません。
そこで私たちは評価（Evals）への投資を進めています。Hermes が質問を受けて回答を生成するたびに、何に時間がかかり、どのスキルを呼び出し、どのツールが失敗し、その理由は何なのかを知りたいと考えています。オープンソースである Arize Phoenix をセルフホストすることで、追加のツール購入なしにこれを可能にしました。Hermes のトレースは Phoenix に送られ、Phoenix はこう教えてくれます。「このタスクは 5 つのスキルと 2 つのツールを呼び出しました。このツールが最も時間がかかり、こちらは失敗しました。理由はこれです。」
その下層では、Datadog を通じてテレメトリを収集しています。消費トークン数、タスク別の成功率、Hermes のダウンやメモリストアの満杯時にオンコールへ通知するアラートなどです。すべてのタスクはサンドボックス内で実行され、サンドボックスを毎日クリーンアップする独自のプリューニングシステムを構築しました。
これらすべての狙いは、変更が Hermes を改善したかどうかを推測する必要がなくなった点にあります。スキルを変更すれば、レポートが届きます。良ければ残す。悪ければロールバックする。
また、Hermes サーバー自体にドキュメントを組み込みました。設定内容、許可されている操作、データの解釈などを記載しています。任意の Hermes がこれを読めます。つまり、評価データを読み取り、他のプロファイルを改善することだけを専門とする Hermes を立ち上げることも可能です。
それは基本的に「Hermes Coach」です。Hermes をコーチングする Hermes です。
17 人の人間、1 台のドイツ製サーバー、毎晩眠りにつくたびに少し鋭くなって目覚めるエージェントのファミリー。私たちは小さくても、大きく成果を出すためにこれを構築しました。
