実運用環境向けの Hermes AI アシスタンスキル
本格的なワークロード向けのプロファイル優先の Hermes 構成
Hermes AI アシスタント（公式には Hermes Agent と呼ばれる）は、単なるチャットラッパーとして位置づけられていません。
インストール、プロバイダー設定、ツールのサンドボックス化、ゲートウェイ構成については、Hermes AI アシスタント ガイド を参照してください。本記事では、Hermes が稼働した後の動作を決定するスキルとプロファイルのアーキテクチャに焦点を当てます。
公式ドキュメントとリポジトリでは、経験からスキルを作成し、使用中にそれを改善し、セッション間で知識を持続させ、低コストの VPS からクラウドサンドボックスに至るまで、あらゆる環境で動作する自己改善型エージェントとして説明されています。
2026 年 4 月時点で、公開されている GitHub リポジトリは約 94.6k のスター、13.2k のフォークを記録しており、2026 年 4 月 16 日に v0.10.0 が最新リリースタグとして付与されています。これは、プロジェクトが急速に進化しており、広く採用されている一方で、運用面では依然として若々しいと言えるだけの活発な活動を示しています。
この二重性は、プロダクション設計において重要です。Hermes は実際の業務を支えるだけの成熟度を持っていますが、動的な性質も備えており、乱雑な設定はすぐに陳腐化してしまいます。以下では、構成とスキルを機能チェックリストではなく、運用アーキテクチャの観点として捉えます。
なぜ Hermes にはプロファーストなアーキテクチャが必要なのか
Hermes のスキルは、オンデマンドのナレッジドキュメントです。これらはプロGRESSIVE 開示（段階的開示）を利用しており、エージェントはまずコンパクトなスキルインデックスを表示し、必要に応じてのみ完全なスキルコンテンツを読み込みます。これにより、多数のスキルがインストールされてもトークン使用量を制御できます。インストールされた各スキルは、CLI およびメッセージングインタフェースでスラッシュコマンドとして機能し、ドキュメントでは、カスタムエージェントコードではなく、指示、シェルコマンド、既存のツールで表現可能な機能については、スキルを推奨拡張メカニズムとして位置づけています。
プロダクションにおける複雑さは、Hermes がスキルを「凍結されたパッケージ」ではなく「生きている状態」として扱う点にあります。バンドルされたスキル、ハブ経由でインストールされたスキル、エージェントが作成したスキルはすべて ~/.hermes/skills/ 下に存在し、ドキュメントではエージェントがスキルを修正または削除できると明記されています。同様に、スキル管理のための作成、パッチ、編集、削除、およびサポートファイルのアクションも公開されています。これは強力ですが、一方で「何でも屋」の巨大なエージェントが、手続き的なごみ箱へと変貌してしまうリスクも意味します。
その解決策が「プロファイル」です。Hermes プロファイルは完全に隔離された環境であり、それぞれ独自に config.yaml、.env、SOUL.md、メモリ、セッション、スキル、cron ジョブ、状態データベースを備えています。CLI はまた、プロファイルを独自のエイリアスコマンドに変換するため、coder という名前のプロファイルは coder chat、coder setup、coder gateway start などのコマンドとして機能します。実際には、プロファイルが個別のスキルではなく、運用上の所有の単位となります。
プロダクションのベースライン
ベースラインの形状は驚くほどシンプルです。Hermes は非機密の動作を ~/.hermes/config.yaml に、秘密情報を ~/.hermes/.env に、アイデンティティを SOUL.md に、永続的事実を memories/ に、手続き的知識を skills/ に、スケジュールされたジョブを cron/ に、セッションを sessions/ に、ログを logs/ に保存します。hermes config set コマンドは API キーを .env に、それ以外の設定を config.yaml にルーティングし、ドキュメントで定義された優先順位は、まず CLI フラグ、次に config.yaml、次に .env、そしてビルトインのデフォルト値となります。これはまた、秘密情報と設定をどのように分割すべきかというプロダクション FAQ に対する最も明確な回答でもあります。
実用的なマルチプロファイルのレイアウトは、一般的に以下のような形になります。これは人間ごとのプロファイルではなく、責任ごとのプロファイルです。
~/.hermes/profiles/
eng/
research/
ops/
execops/
ml/
このパターンは、Hermes プロファイルのドキュメント説明と一致しています。各プロファイルは独自の隔離された環境であり、共通のデフォルトが有用な場合はベース構成からクローンできます。また、ドキュメントでは、プロファイル間でメモリやセッションは共有されないこと、およびメインインストールが更新された際に更新されたスキルがプロファイル間で同期されることも記載されています。
次のプロダクションの境界は「実行」です。Hermes は 6 種類のターミナルバックエンド（ローカル、Docker、SSH、Modal、Daytona、Singularity）をサポートしており、セキュリティドキュメントでは、危険なコマントの承認、コンテナの隔離、MCP 認証情報のフィルタリング、コンテキストファイルのスキャン、クロスセッションの隔離、入力サニタイズ化などを含む多層防御モデルが説明されています。つまり、「プロファースト」の決定は「誰が状態を所有するか」を答え、バックエンドの決定は「危険な作業はどこで許可されるか」を答えられます。
オートメーションはこのベースラインの上に構築されます。Hermes の cron ジョブは 0 個、1 個、または複数のスキルをアタッチでき、現在のチャットを継承するのではなく、新しいエージェントセッションで実行されます。メッセージングゲートウェイもまた、セッションを管理し、cron を実行し、結果を Telegram、Discord、Slack、WhatsApp、Email、Matrix などのプラットフォームへルーティングするバックグラウンドプロセスです。公式の MCP ガイドでは、見落としがちなもう一つのプロダクションルールが追加されています。それは、すべてを接続するのではなく、最小限の有用な表面だけを公開することが最良のパターンであるというものです。
ソフトウェアエンジニアリングのプロファイル
Hermes の最も明らかなペルソナは、エージェントをチャットウィンドウではなく、繰り返可能なリポジトリオペレーターとして振る舞わせたいソフトウェアエンジニアです。このプロファイルは通常、リポジトリ認証、イシューのトリアージ、PR 作成、コードレビュー、デバッグ、プランに基づく実行に関心を持ちます。Hermes のカタログでは、この仕事のためのコアのビルトインスキルパックは異例の整合性を示しています：github-auth、github-issues、github-pr-workflow、github-code-review、code-review、plan、writing-plans、systematic-debugging、そして test-driven-development です。もし委任が重要であれば、Hermes はまた codex、claude-code、opencode、hermes-agent-spawning などのビルトインの自律エージェントスキルも提供しています。
このパックが有用な理由は、個々のスキルではなく、スキルが開発手順をどのように符号化しているかという点にあります。github-pr-workflow は PR ライフサイクル全体をカバーし、github-issues はイシュー操作を形式化し、github-code-review と code-review はレビューを事後の作業ではなく明確なステップとして扱います。また、systematic-debugging はエージェントが早急な修正に飛びつかないようにします。これは、コーディングワークフローにおいてどの AI アシスタントスキルが最も重要かという実用的な問いにも答えています。最も価値のあるスキルは、通常、生々しいコード生成を約束するものではなく、リポジトリの衛生状態とレビューの規律を確立するものです。
Hermes の委任機能は、このプロファイルをさらに強化します。プラットフォームは、独自の会話、ターミナルセッション、ツールセットを持つ隔離された子エージェントを生成し、最終的なサマリーのみを親へ返すことができます。コードベースにおいては、中間の差分、スタックトレース、レビューノートすべてを一つの会話しこむよりも、これがよりクリーンな解決策となります。運用用語で言えば、エンジニアリングプロファイルは、狭いスキルセット、Docker や SSH などのサンドボックス化されたバックエンド、そしてコンテキストノイズが支配的になり始めたら委任を惜しまない運用から恩恵を受けます。
研究とナレッジのプロファイル
研究プロファイルは、Hermes が通常のアシスタントとは異なる姿を見せ始める場所です。ビルトインのカタログには既に arxiv、duckduckgo-search、blogwatcher、llm-wiki、ocr-and-documents、obsidian、domain-intel、ml-paper-writing が含まれており、公式のオプションカタログには qmd、parallel-cli、scrapling、そして専門分野向けの広範な研究ティアが追加されています。このスタックは、論文検索、ソース監視、OCR、ローカルメモシステム、ドメイン偵察、執筆、ハイブリッド検索をカバーし、すべてを単一の RAG パターンに押し込むことなく対応します。
このプロファイルは、メモリとスキルの違いを最も明確に説明できる場所でもあります。Hermes のドキュメントでは、メモリはユーザー、プロジェクト、好に関する事実として定義され、スキルは「どのように行うか」の手続きとして定義されています。研究作業には両方が必要です。メモリは、アシスタントがすでにドメインや読者の好について学んだ事実を保持し、スキルは「arXiv をスキャンし、新しい論文を要約し、Obsidian にメモを書く」といった繰り返可能な手続きを符号化します。この区別は重要です。なぜなら、プロダクションの研究システムは、すべてをメモリとして扱うか、すべてをワークフローとして扱うかのどちらかで失敗するからです。Hermes はこれらの懸念にそれぞれ異なる場所を提供します。
研究プロファイルは、cron から不均衡な恩恵を受けます。Hermes の cron ジョブは実行前に明示的にスキルをロードでき、自動化ガイドでは、スケジュールされたプロンプトは新しいセッションで実行されるため、完全に自己完結している必要があると強調されています。したがって、blogwatcher、arxiv、obsidian、llm-wiki を組み合わせた再発パイプラインは、曖昧な「今日の変化を確認する」といったジョブよりも信頼性が高いです。つまり、研究プロファイルは、ソース発見、メモ執筆、長期的な保存がそれぞれ名付けられたスキルによって表現され、長い自然言語プロンプトの中に隠されていない場合に最もよく機能します。
オートメーションとオペレーションのプロファイル
Ops プロファイルは派手さはありませんが、しばしばより価値があります。これは、Hermes にイベントに反応し、システムを検査し、スクリプト化されたチェックを実行し、出力をチャンネルにルーティングさせ、かつホストをリスクに変えずにそれらを行いたいユーザーです。Hermes には、そのような作業スタイルに適したビルディングブロックが備わっています：イベント駆動のアクティブ化用のビルトイン webhook-subscriptions、MCP ベースのツール用のビルトイン native-mcp と mcporter、そしてワークフローがコンテナ、カスタム MCP サーバー、または秘密情報の注入に拡大する際に使用される docker-management、fastmcp、cli、1password などの公式オプションスキルです。
このパックが機能する理由は、各スキルが一つの境界を所有している点にあります。webhook-subscriptions は外部システムからのイングリスを処理します。docker-management はコンテナの雑務を自由なシェルのゲームではなく、名付けられた手続きに変換します。fastmcp は、Hermes が新しい MCP ツールを取り巻くオーケストレーターとなる必要がある際に有用で、1password は秘密情報の扱いを、シェル履歴や Markdown ファイルに隠匿するのではなく、明示的に保ちます。公式の MCP ガイドは、同じプロダクション感覚を強化しています：正しいものを、最小限の有用な表面で接続するべきです。
このプロファイルはまた、スケジュールされた AI ワークフローがどのように信頼性を保つかを最も明確に説明する場所でもあります。Hermes の cron ドキュメントでは、ジョブは新しいセッションで実行され、1 つ以上のスキルをアタッチでき、自己完結したプロンプトを使用すべきだと述べられています。cron のトラブルシューティングガイドでは、自動トリガーは通常の CLI チャットセッションではなく、ゲートウェイのタイカーに依存すると追加されています。したがって、信頼できるパターンは明確です：明示的なスキル、明示的な配信先、自己完結したプロンプト、隔離されたバックエンド、そして実際に稼働しているゲートウェイです。
経営オペレーションのプロファイル
quieter ですが非常に現実的な Hermes ペルソナに、参謀、オペレーションリーダー、あるいは過負荷な創業者のような存在があります。関連するスキルは派手さではなく、オフィス的な形状をしています：google-workspace、notion、linear、nano-pdf、powerpoint、そしてビルトインの himalaya メールスキル、さらに agentmail、telephony、one-three-one-rule などの公式オプションスキルです。この組み合わせは、Hermes にインボックス、カレンダー、ドキュメント、タスク、デック、PDF クリーンアップ、構造化されたコミュニケーションフレームワーク、そして実際に重要な場合の電話と SMS ワークフローへのアクセスを与えます。
ここでは、カタログよりもフローが重要です。google-workspace は日々の実行を定着させます。Notion と Linear は、アシスタントがタスク記録システム化しないように防ぎます。one-three-one-rule は意外にも有用で、意思決定支援は標準化するのが最も難しいものの一つであり、このスキルは Hermes に一般的な「これを要約する」といった振る舞いではなく、提案のための名付けられた手続きを与えます。nano-pdf と powerpoint は、チームが毎日デックや PDF に触れ始めると、その小ささが Operational Multiplier（運用倍率）として発揮されるタイプのスキルです。
Hermes のメッセージングと音声機能は、このプロファイルを思っていた以上に実用的にします。ゲートウェイはエージェントを Slack、Telegram、Discord、WhatsApp、Email、Matrix、そして他のいくつかのチャンネルを通じて公開でき、音声スタックはマイク入力、メッセージングでの音声返信、ライブ Discord 音声会話をサポートします。ドキュメントではまた、1 つの Hermes インスタンスがホワイトリストと DM ペアリングを通じて複数のユーザーにサービスを提供でき、ボットトークンは単一のプロファイルに限定されるとも記載されています。それが、コミュニケーション集約的なデプロイメントが、エンジニアリングや Ops と同じボットアイデンティティを共有するのではなく、少なくとも 1 つの専用プロファイルから恩恵を受ける理由です。
ML とデータプラットフォームのプロファイル
Hermes は研究ラボによって構築されており、その系譜は現れています。カタログには、ステートフルなノートブックスタイルの作業用の jupyter-live-kernel、モデルとデータセット操作用の huggingface-hub、評価と実験追跡用の evaluating-llms-harness と weights-and-biases、プロダクション RAG ストレージ用の qdrant-vector-search、そして axolotl、fine-tuning-with-trl、modal-serverless-gpu、lambda-labs-gpu-cloud、flash-attention、tensorrt-llm、pinecone、qdrant、nemo-curator などのスキルを含む大規模なビルトインおよびオプションの MLOps ティアが含まれています。
ここで注目すべきは、単に広範であることではありません。スキルが、ノートブックの反復からデータ整理、評価、ベクトル検索、ファインチューニング、推論最適化に至るまで、スタック全体を網羅している点です。ML プラットフォームのユーザーにとって、Hermes はアシスタントというよりも、ライフサイクル全体を通じて手続きを運ぶことができるコントロールプレーンとして感じられます。jupyter-live-kernel は反復的な探索を処理し、evaluating-llms-harness と weights-and-biases は測定を形式化し、オプションの計算と最適化スキルは、Hermes が実験とデプロイの両方について一貫して語ることを可能にします。
これもまた、自制心が最も重要なプロファイルです。オプションの MLOps カタログが非常に大きいため、ML 作業用のプロダクション Hermes 設定は、範囲について意見を持つことが通常、恩恵を受けます。評価とデプロイを所有するプラットフォームエンジニアリングプロファイルは、すべてのトレーニングフレームワークをインストールする必要はありません。論文とメモシステムを所有する研究プロファイルは、すべてのベクトルデータベーススキルを必要としません。Hermes は巨大なスキルインベントリを持ち運べますが、プロダクションでの有用性は依然として、アクティブな表面を狭めることから生まれます。
スキルが負債になる場所
Hermes スキルシステムの最も強力な部分は、同時にプロダクション設定が失敗する場所でもあります。Hermes は、ビルトインカタログ、公式オプションカタログ、Vercel の skills.sh、よく知られたスキルエンドポイント、直接的な GitHub リポジトリ、マーケットプレイススタイルのコミュニティソースからスキルを閲覧してインストールできます。セキュリティモデルは builtin、official、trusted、community ソースを区別し、ハブインストールスキルのセキュリティスキャンを実行し、--force は非危険なポリシーブロックに対してのみ許可します。危険なスキャン結果はブロックされ続けます。Hermes はまた、リポジトリ URL、週間のインストール数、監査シグナルなどのアップストリームメタデータを検査時に提示します。これは堅牢な信頼モデルですが、判断力を置き換えるものではありません。
また、スキルに求めることの限界もあります。Hermes のドキュメントでは、スキルは、ジョブが指示、シェルコマンド、既存のツールで表現可能な場合に優先される選択であり、プラグインはカスタムツール、フック、ライフサイクル振る舞いに対するより正直な抽象化であると明確にされています。プラグインガイドでは、プラグインが独自のスキルをバンドルする方法さえ示されています。プロダクションでは、これはスキルを再利用可能な手続きとして扱い、適切なツールやプラグイン設計の強制された代わりとして扱わないことを意味します。
コミュニティとサポートは健全に見えますが、変化の速度を消去するものではありません。Hermes のドキュメントはユーザーを Discord、GitHub Discussions、Issues、Skills Hub へ導き、公開リポジトリは頻繁なリリースと大きな貢献フットプリントを示しています。運用上の教訓は単純です：更新はシステムの一部であり、その外側にあるイベントではありません。真のプロダクション設定は、プロファイル、スキル、ワークフローの仮定が進化することを想定し、変化が避けられない際に局所的に留まるよう、隔離と狭いスキルパックを利用します。
Hermes は、スキルが明確に分離されたプロファイルを取り巻く手続き的契約として扱われるときに最もよく機能します。一つのプロファイルがエンジニアリングエージェント、研究アシスタント、Ops ワーカー、インボックスボット、ML プラットフォームすべてを一度に担う瞬間に、システムは複利効果を失い、責任の漏れが始まります。クリーンなプロダクションパターンは、より多くのスキルを持つことよりも、各プロファイルが実際に維持できる職務説明を与えることについてです。
本記事は、セルフホスト型アシスタント、検索アーキテクチャ、ローカル LLM インフラ、可観測性を取り扱う AI システム クラスタの一部であり、記憶、検索、ルーティング、可観測性を用いたアシスタントのオーケストレーションを学びます。
