社内ITサポート向けHermes Agent：安全なセットアップガイド（2026年）

要点

社内ITサポート向けのHermes Agentは、カスタマーサポート向けよりも適しています。ユーザーが許可リストに入れられる同僚だからです。最も力を発揮するのは、ITアドミン個人の相棒としての使い方です。cronによるヘルスチェック、DatadogやGrafanaからのアラートのトリアージ、SSH経由でのサーバー上の実コマンド実行などです。

問題は、全社に開放したときに現れます。アクセス権はユーザーIDを1件ずつ付与する方式で、アドミンとユーザーの区別が制限するのはスラッシュコマンドだけです。さらにリスクのあるコマンドの承認は、ITではなく質問した本人に戻ります。対処法は2つのプロファイルです。全員向けにターミナルをオフにした読み取り専用の「it-desk」プロファイルと、アドミンだけが使える「ops」プロファイルです。

サーバーを持ちたくない場合、eesel はSlackでConfluenceをもとに社員のIT質問に答え、Jira Service Managementでは一次対応を担い、アクションを承認できるのはITアドミンだけです。

社内ITでHermesを調べた理由

私はeeselでAIエージェントを作っていますが、最近「Hermesをそのまま使えないか」という質問が最も多く来るのは、サポートチームよりもITチームからです。考えてみれば当然です。ITチームはすでにサーバーを運用し、SlackやTeamsを使い、YAMLファイルを苦にしないエンジニアが一人はいるものです。

私はこの問題を反対側から長く見てきました。eeselはInDebtedの社内ITデスクで一次対応を担当しました。5〜10人のITチームが、5つの市場にいる250人以上のスタッフからの依頼を処理していた現場です。問題の15%を自動対応し、過去の依頼で学習を続けて55%の目標を目指しています。同社のHead of ITは端的にこう述べています。

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Jason Loyola, Head of IT, InDebted

この経験から、社内ITのリスクがどこにあるのかが分かりました。見知らぬ人ではありません。ボットに「とりあえず再起動して」と頼む親切な同僚です。そこでHermesのドキュメントを端から端まで読み、ひとつの問いを頭に置きました。ターミナルを持つエージェントと200人の社員が話せるようになったら、何が起きるのか。

Hermes AgentがITチームにもたらすもの

Hermes Agentは、Nous Researchが公開しているオープンソースのセルフホスト型エージェントです。MITライセンスで、GitHubのスターは251,503、最新リリースは2026年9月24日公開のv0.21.5です。

製品全体はHermes Agentレビューで、同種のツールとの比較はオープンソースAIエージェントのまとめで扱っています。IT業務で重要なのは次の4点です。

• 7種類のターミナルバックエンド。 Hermesは、ローカル、Docker、SSH、そしてModal、Daytona、Vercel Sandbox、Singularityでコマンドを実行できます（Configuration）。SSHバックエンドはリモートサーバー上に常駐シェルを保ちます。エージェントが自分のコードを変更できないため、ドキュメントでは「Recommended for security」とされています（Tools）。
• メッセージングゲートウェイ。 Slack、Microsoft Teams、Google Chat、メールなど20以上のチャネルに対応します（Messaging Gateway）。多くのチームがすでにSlackでITSMを回している形です。
• cronとWebhook。 定期ジョブと、GitHub、GitLab、Jiraなどからの受信Webhookに対応し、HMAC署名の検証も行います（Webhooks）。
• MCPサーバー。 レビュー済みの65サーバーの厳選カタログで、既定では無効です（MCP catalog）。MCPが初めてなら、AIエージェントのMCPサーバーの解説が基本をカバーしています。

ITチーム向けの本格的な道具一式です。未解決なのは、誰がそれを使えるのかという点です。

2つの仕事、1つのエージェント

私が目にする「IT向けHermes」の計画の多くは、まったく性質の違う2つの仕事を混ぜています。

仕事1は、ITアドミンの相棒です。 2〜3人のアドミンがエージェントにDMを送ると、エージェントはサーバーのチェックやアラートのトリアージを行い、見つけたことを報告します。リスクのあるコマンドを承認するのは、その内容を理解しているアドミンです。

仕事2は、社員の窓口です。 全社員が#it-helpで「VPNがつながらないのはなぜ？」と聞きます。社内ITヘルプデスク向けAIと言うとき、多くの人が思い浮かべるのはこちらです。エージェントもツールも同じですが、リスクはまったく違います。

Hermesのドキュメントに出てくるITの例は、すべて仕事1です。ドキュメント全体で「helpdesk」「IT support」「employee」を検索しましたが、ヒットはゼロでした。代わりに示されているのは、オペレーターが自分の運用を回す例です。オンコール用チャネルのアラートトリアージ、死活監視、ディスクアラートなどです。

仕事1：ITアドミンの相棒としてのHermes（これは機能する）

ここではHermesが役に立ちます。ドキュメント化されたパターンのいくつかは、ほぼそのままITチームに当てはまります。

• スケジュール実行のサーバーヘルスチェック。 Team Telegram Assistantガイドには、6時間ごとにdf -hでディスク使用量、free -hでメモリ、docker psでコンテナの状態を確認し、チームチャネルに届けるプロンプトが載っています。
• モデル呼び出しなしのスクリプト専用cron。 hermes cron create "*/15 * * * *" --no-agent --script disk-alert.sh --deliver telegramは、単純なスクリプトを実行して出力を送ります（Script-only cron）。安価で、ディスクチェックにトークンを使わずに済みます。
• 監視からのアラートトリアージ。 Automation Blueprintsのページには、P1〜P4のエスカレーション推奨を求め、「This goes to the on-call channel.」で終わるアラートトリアージ用Webhookがあります。
• 静かな失敗通知。 「A recurring job that keeps failing with the same error alerts you once, not on every run」（Cron）。うるさいアラートチャネルをミュートした経験があれば、ありがたさが分かるはずです。

ツール面では、ほとんどのITチームが使う監視スタックがすでにカタログにあります。Datadog、Grafana、Sentry、Better Stack、Cloudflareで、すべてOAuth接続です。これにSSHバックエンドを組み合わせれば、アラートを読み、マシンを確認し、何が悪そうかを報告してくれるエージェントになります。

安全面の既定値も2つ役立ちます。cronジョブは危険なコマンドを既定で拒否する（cron_mode: deny）ため、設定を変えない限り、スケジュールされたジョブがsystemctl restartを実行することはできません（Security）。危険コマンドのチェックはlocalとsshのバックエンドでも動作し、まさにIT業務が行われる場所をカバーします。

ホームラボのユーザーが語るのも、この構成です。あるHacker Newsのコメント投稿者は、承認ステップと元に戻す手段を備えて、まさにこの形で運用しています。

"I use Hermes at home. [...] it's a sysadmin for my homelab. It has a read-only mcp server to check the k8s status and has it's own ssh access to fix stuff after I approve it per session. It's magical. Each morning I get a small update whether the backup ran, if pods are stuck or behaving weirdly etc... Since the entire homelab is GitOps I can always reverse a change made by the agent."

apexalpha, Hacker News

ここで承認しているのは誰かに注目してください。サーバーの持ち主本人です。こうした作業が好きなエンジニアが一人いる小規模なITチームなら、仕事1は無料ツールの良い使い道です。

仕事2：社員の窓口としてのHermes（難しくなるところ）

同じエージェントを全員に開放すると、ドキュメントの4つの点が問題になってきます。念のため言うと、どれもバグではありません。Hermesはオペレーター向けのエージェントとして設計されており、その設計が表に出る継ぎ目です。

1. アクセス権はIDを1件ずつ付与する

チャットの許可リストはすべて個別IDのリストです。SlackのメンバーID、TeamsのAzure ADオブジェクトID、Google Chatのメールアドレスです（Environment variables）。*@company.comのようなドメインのワイルドカードは見つからず、テナント全体やワークスペース全体の設定もありません。

SLACK_ALLOW_ALL_USERSやTEAMS_ALLOW_ALL_USERSといった「全員許可」のスイッチは、リファレンスで「(dev only)」と表記されています。グループによるアクセスはDiscordのロールだけです。もう一つの方法はDMペアリングで、各社員にコードが発行され、アドミンがhermes pairing approveで手動承認します。200人なら200回の承認が必要で、そのうえ新入社員が入るたびに増えます。

シングルサインオンはありますが、Webダッシュボード向けで、自前のOpenID Connectプロバイダー経由です（Web Dashboard）。SCIMもないため、Oktaで退職処理をしても、ボットからは削除されません。

2. ユーザー階層が制限するのはコマンドで、ツールではない

Hermesにはアドミンとユーザーの区別があり、一般ユーザーができることを制限していると思いがちです。実際に制限されるのはスラッシュコマンドです。一般ユーザーが使えるのは、user_allowed_commandsに列挙したコマンドと、/help、/whoamiです（Slash commands）。

通常のチャットはまったく制限されません。つまり、許可された社員なら誰でも、ターミナルを含め、エージェントのツールが許す範囲のことを頼めます。カスタマー側でも同じ壁に当たりました。カスタマーサポート向けHermesの記事をご覧ください。

3. 承認は質問した本人に届く

IT責任者の方には、これを二重線で強調したいところです。Hermesがsystemctl restart、chown -R root、/etc/内のファイルへのsed -iといったフラグ付きコマンドを実行しようとすると、同じチャットで承認を求めます。「the agent sends the dangerous command details to the chat and waits for the user to reply」（Security）。

approvals設定にはmode、timeout、cron_modeなどがありますが、承認者リストはなく、承認カードをITアドミンや別のチャネルに送る方法もありません。Teamsでは、カードにAllow Once、Allow Session、Always Allow、Denyの4つのボタンがあります（Teams）。グループチャットで誰がそれを押せるのかは、ドキュメントに書かれていません。

「Always Allow」も残り続けます。承認されたコマンドはconfig.yamlに保存され、「silently approved in all future sessions」となります（Security）。急いでいる社員が1回クリックしただけで、そのコマンドは全員に対して事前承認されます。

4. メモリは共有で、チャットの監査ログはない

組み込みメモリは、プロファイルごとにMEMORY.md（2,200文字）とUSER.md（1,375文字）が1つずつあり、そのプロファイルが動かすすべてのセッションに読み込まれます（Memory）。共有のITボットでは、エージェントがある社員のチャットで保存した内容が、次の社員のセッションに現れることになります。ドキュメントが用意する対策はmemory.write_approval: trueで、メッセージングからのすべての保存を保留にし、アドミンが/memory pendingで確認します。

マルチユーザー構成を試したある開発者は、さらに踏み込んでいます。

"we need a container per user, because, without modifications, if multiple users talk to the same Hermes instance then they can access each other's conversations by asking the agent."

GTP, Hacker News

Hermesのドキュメントは、セッション間の分離を8つのセキュリティレイヤーの1つに挙げています。そのため、これは文書化された欠陥ではなく、一人のビルダーの体験として受け取ってください。それでも、パスワードリセットの質問が飛び交うチャネルを公開する前に、最初に試すことだと思います。

監査については、ゲートウェイの監視ページに「analytics, audit logs, or detailed execution traces」ではないと書かれています（Gateway monitoring）。セキュリティのチェックリストは「check ~/.hermes/logs/」と案内しています。ITチームがSOC 2の監査人に説明する立場なら、自分で埋めるべき穴です。

HermesをSlack、Teams、Google Chatにつなぐ

チャットアプリごとに仕組みが違い、その違いがゲートウェイをどこにホストできるかを左右します。

出典：Slack、Teams、Google Chat。

Slackが最も簡単です。 Socket Modeは「works behind firewalls, on your laptop, or on a private server.」ITにとって重要な設定は2つあります。#it-helpのようなチャネルでセッションが始まるたびにスキルを読み込むchannel_skill_bindings（スレッドも継承します）と、@メンションされても他のチャネルをすべて無視させるallowed_channelsです。知っておきたい癖が1つ。DMはallowed_channelsの対象外です。

Teamsは手間がかかります。 「Teams delivers messages by calling a public HTTPS webhook,」なので、ゲートウェイには到達可能なエンドポイントが必要で、「Teams rejects self-signed certificates.」登録はMicrosoftの@microsoft/teams.cli（「no Azure portal needed」）で行い、クライアントID、シークレット、テナントIDが発行されます。ドキュメントの警告は文字どおりに受け取るべきです。TEAMS_ALLOWED_USERSがないと、「anyone who can find or install your bot can interact with it.」

Microsoft Graphのリスナー（msgraph_webhook）もありますが、現状は主にTeams会議サマリーのパイプラインを動かすものです（Graph webhook）。ユーザーディレクトリやデバイス管理へのアクセスは得られないため、パスワードのリセットやIntuneの確認までは期待しないでください。Teams経由の全体像は、Microsoft Teamsサポートの自動化のガイドで広く扱っています。

HermesがつながるITツール

ITチームがMCPカタログで驚くのはここです。監視には強い一方で、ID管理やサービス管理は手薄です。

Jira Service Managementには見えにくい穴があります。 カタログのAtlassianの項目は「Jira issues and Confluence pages」と説明され、OAuthで接続します。AtlassianのRovo MCPサーバーにはJSMのツールグループがありますが、その4つのツールはオンコールのアラートとスケジュール用で、組織の管理者が有効にしたAPIトークン認証のときにしか現れません。カタログのOAuth経由では、Hermesはリクエストを通常のJiraワークアイテムとしてしか見られません。リクエストタイプ、キュー、SLA、承認のためのツールはありません。同じサーバーの詳細は、Claude for JSMの記事で解説しています。

ServiceNowはカタログに項目がありません。 ServiceNow自身のMCPサーバーはNow AssistとAI NativeのSKUに含まれ、Quickstartサーバーには読み取りと要約のツールが4つあります。オープンソース側では、コミュニティ製サーバーをmcp_serversに自分で設定する方法になります。ServiceNow MCP連携のガイドをご覧ください。

IDとデバイスは自前で組む領域です。 Okta、Entra、Intune、Jamf、Google Workspace管理の項目はありません。skills.shのコミュニティスキルは小規模で、ServiceNowの上位スキルのインストール数は135、Freshserviceは118、Jamfは4です。例外はGoogle自身のpersona-it-adminスキルで、インストール数は28,951です（skills.sh）。どれもNousがレビューしていないサードパーティ製コードである点にご注意ください。

スタックがJira、Confluence、Datadogなら、Hermesはかなりの範囲をカバーします。ServiceNow、Okta、Intuneなら、相応の構築時間を見込んでください。後者のスタック向けに作られたツールは、ITサービス管理向けAIのまとめで紹介しています。

社内ITのためにHermesを安全に設定する方法

私が採るパターンは、2つの仕事を2つのプロファイルに分けることです。Hermesのプロファイルは、設定、メモリ、スキル、ボットトークンを独立して持つ別個のエージェントで、1つのゲートウェイで複数を扱えます（Profiles）。

Hacker Newsのあるビルダーも、別のリスクに対してですが、同じ発想に行き着いています。

"My solution to the problem, which I am implementing as a Hermes plugin + custom iOS / macOS app, is simple: an airlock architecture. One Hermes profile runs with local FS access and no internet access, inside an Apple container, and one Hermes profile runs with internet access and no FS access, inside an Apple container."

elliotbnvl, Hacker News

私ならこう組み立てます。順を追って説明します。

1. ゲートウェイは専用のマシンで動かす

ドキュメントははっきり書いています。「For maximum security, run the gateway on a separate machine or VM. Set terminal.backend: ssh」（Security）。そして、認証なしでダッシュボードを公開してはいけません。Dockerドキュメントには「the June 2026 MCP-config persistence campaign」が記されており、スキャナーが公開ダッシュボードに到達して「drove the agent into planting an SSH-key backdoor」とあります（Docker）。

2. 社員向けプロファイルではターミナルをオフにする

it-deskプロファイルでは、agent.disabled_toolsetsにterminalとcode_executionを追加します。ドキュメントによれば、そこに載せたツールセットは「even if a platform's saved config still lists it」常に取り除かれます（Configuration）。ターミナルがなくなれば、承認が依頼者に戻る問題はほぼ消えます。承認すべき危険な操作が残らないからです。

残るのは、読み取りと振り分けの仕事です。ConfluenceやNotionにある社内ナレッジベースから回答し、Jiraのイシューを調べ、チケットを作成します。これで「VPNはどう設定する？」といった問い合わせの大半をカバーでき、残りを振り分けるのは単純なチケットトリアージです。

3. 1つのチャネルと1つのスキルに固定する

allowed_channelsを#it-helpに設定し、channel_skill_bindingsでそのチャネルをITスキルに紐づけます。strict_mentionも使うと、長いスレッドでは誰かが再びメンションするまでボットは黙っています。ドキュメントはまさにこのケースを挙げています。「a long tech-support thread where the bot helped at the start and you'd rather it stay silent unless explicitly pinged again」（Slack）。

4. メモリへの書き込みを保留にする

it-deskプロファイルでmemory.write_approval: trueを設定し、ある社員のチャットが、エージェントが他の全員に伝える内容を気づかれないまま書き換えられないようにします。

5. opsプロファイルを固める

opsプロファイルには、SSHバックエンド、approvals.mode: manual、ITアドミンだけの許可リストを設定します。さらに、チャットからは絶対に実行させたくないコマンドのapprovals.denyリストを追加し、/etc/やサービスに触れる操作には「Always Allow」を使わないでください。ハードラインのブロックリストは、rm -rf /、フォークボム、生のディスク書き込みを何があっても拒否するため、これらはすでにカバーされています。

6. 社員に見せる前にテストする

この工程ではHermesは助けになりません。先月のITチケットをエージェントに通して、どう答えたかを確認する機能は組み込まれていません。必要なのは、テスト用チャネルと過去の実際の質問のリスト、そして#it-helpの公開前にすべての回答を読む担当者です。

HermesがITチームに必要とするコスト

ライセンスは無料です。ただし、運用は別の話です。

Nous Portalでは、対象のChatGPTプランを推論用に接続することもでき、ツールとホスティングは別料金です。各レイヤーの内訳は、Hermesの代替ツールの記事でさらに詳しく解説しています。

最後の行は、請求書には決して現れません。許可リストの管理、新入社員のペアリングコードの承認、保留中のメモリのレビュー、ゲートウェイのパッチ適用を、誰かが担当する必要があります。仕事1ならアドミン本人がユーザーなので問題ありません。仕事2では、自分たちで保守する小さな社内プロダクトになります。自前で作らないと決めたある顧客が、このトレードオフをうまく言い表しています。

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

an engineering lead at a crypto-hardware company, on why they bought instead of building

社内ITサポートにおけるHermesとeeselの比較

IT責任者が最初に尋ねる点で、両者を比べます。

出典：eesel Internal Operationsドキュメント、eeselの承認、eeselの料金。

eeselの限界も正直にお伝えします。eeselはサーバー上でシェルコマンドを実行しません。これは意図的な設計です。サービスデスクのチームメイトであり、システム管理者ではありません。サーバーにSSHで入ってnginxを再起動するエージェントが必要なら、それはHermesの仕事1であり、eeselの役割ではありません。また、eeselには現時点でServiceNowやFreshserviceの連携がありません（そのスタックはFreshservice向けAIのまとめで扱っています）。Teamsはセルフサービスではなく、要望に応じて有効化されます。

社内ITでHermesを運用すべきか

仕事1なら、はい。 小規模なITまたはOpsチームに、こうした作業が好きなエンジニアがいるなら、アドミン専用の相棒としてのHermesは優れた無料ツールです。SSHバックエンドと手動承認、MCP経由のDatadogまたはGrafana、地味なチェック用のスクリプト専用cronで運用してください。

読み取り専用のit-deskなら、慎重に。 ナレッジがConfluenceに、チケットがJiraにあるなら、ターミナルをオフにして#it-helpに固定したプロファイルで「やり方」の質問に答えられます。ただし、許可リストの維持と、誰もやりたがらないテストの工数は見込んでください。

ターミナルつきの社員窓口なら、いいえ。 Hermesが承認をアドミンに回せるようになるまでは、systemctlを実行できるエージェントと200人の社員をチャットさせるのはおすすめしません。Hermesを責めているのではありません。もともとオペレーターのために作られたもので、ドキュメントにもそう書かれています。

まだ選択肢を検討中なら、窓口向けに作られたツールはITサポート向けAIツールと社内サポートチャットボットのリストで、チケット管理側はSlackチケットシステムのリストで紹介しています。

社内ITサポート向けeesel

本当にほしいのが仕事2、つまり誰もサーバーを動かさずに社員がSlackで質問できるITヘルプデスクなら、まさにeeselのヘルプデスクチームメイトの役割です。Confluence、Notion、Google Driveから、出典リンクつきで回答し、見つからないときはそう伝えます。

この記事にとって最も重要なのは承認です。すべてのアクションは、Auto、承認が必要、無効のいずれかに設定され、Slackで始まった実行の承認カードは、そのスレッドに届きます。承認できるのはワークスペースのOwnerとEditorだけで、Slackプロフィールのメールで照合されます（承認のドキュメント）。質問した社員が自分のリクエストを承認することはできません。

チケットを使うIT運用では、eeselはJira Service Managementの中で動きます。新しいリクエストを拾い、報告者に返信するか内部メモを残し、イシューの割り当て、ラベル付け、移動を行います。しかも、本番のリクエストに触れる前に、過去のチケットで実行して、返したであろうすべての回答を確認できます。

そして、チームがHermesのユーザーと同じくらいターミナルを好むなら、eesel CLIで同じチームメイトをシェルから動かせます。eesel approvalsは保留中のアクションを一覧表示し、eesel chat "how do I reset a password?"は回答をテストし、すべてのコマンドがJSONを出力するため、Claude CodeやCodexからセットアップを操作できます。社内の資産データベースに届かせたい場合は、Network Accessで、認証情報をAIに見せないままREST APIを呼び出せます。

eeselを無料で試せます。100クレジットつきで、カードは不要です。SlackとConfluenceをつなぎ、最もよくあるIT質問を10個聞いて、何が返ってくるか確かめてみてください。