AIエージェントを使い始めると、「前に教えたことを覚えている」「一度やった作業を次から再利用できる」「スマートフォンから指示できる」といった機能に惹かれます。便利さは本物でも、業務で使うには別の問いが必要です。
何を記憶させるのか。どの手順を再利用するのか。どのデータに触れさせるのか。失敗したとき、どこで止めて人に戻すのか。
この記事では、Nous Researchが公開しているオープンソースのHermes Agentを題材に、自己改善型エージェントを導入する前の境界線を整理します。個別の導入を推奨する記事ではなく、機能を業務へ接続する前に確認すべき設計の順番が主題です。
Hermes Agentはチャットボットより「運用基盤」に近い
公式ドキュメントでは、Hermes AgentはCLIやデスクトップアプリだけでなく、複数のメッセージングプラットフォーム、スケジュール実行、ツール、MCP、サブエージェントに接続できるエージェントとして説明されています。
ここで重要なのは、画面がチャットでも、内部では仕事を実行する環境が動いている点です。ファイルを読む、コマンドを実行する、外部サービスへ接続する、定期処理を起動する。これらが一つの窓口から見えると、便利さと権限の広さを混同しやすくなります。
したがって、最初に作るべきものは「何でもできる秘書」ではありません。対象業務、入力データ、許可する操作、承認者、停止条件を一枚にした運用カードです。
「使うほど育つ」は無制限の学習ではない
Hermes Agentの公式資料では、セッションをまたいで使われるメモリと、複雑な手順を再利用するスキルが別の仕組みとして説明されています。メモリは利用者やプロジェクトに関する事実を保持し、スキルは作業の進め方を必要なときに読み込む手順書です。
この区別をしないと、「前回の会話を全部覚えている」と誤解します。実際には、公式資料に示されているメモリは容量を抑えたファイルとして管理され、必要な記憶を検索・要約して利用する設計です。覚えているように見えることと、業務上の正本を保証することは別です。
業務では、次の3つを分けます。
- メモリ: 会社の用語、プロジェクトの前提、利用者の好みなど、短く安定した事実。
- スキル: 問い合わせを分類する、会議メモから確認事項を抽出する、といった再利用手順。
- 正本: 契約条件、最新価格、顧客情報、承認済みの判断など、必ず別管理して参照すべき情報。
メモリやスキルを正本の代わりに扱わないことが、自己改善型エージェントの最初の安全策です。
無料なのは本体であり、業務運用全体ではない
Hermes Agentの本体はオープンソースで、公式FAQではMITライセンスと説明されています。一方、利用するモデルのAPI料金、ローカルモデルの計算資源、サーバーやコンテナ、ログ管理、連携先の利用料は別に発生します。
「無料で手に入る」という表現を、業務が無料で動き続けるという意味に広げてはいけません。導入前に、少なくとも次の費用を分けて見積もります。
- エージェント本体と更新にかかる保守負担。
- モデル、検索、音声、ブラウザなどの従量費または契約費。
- 実行環境、バックアップ、監視、ログ保管の費用。
- 誤送信、誤更新、情報漏えいが起きた場合の確認・復旧コスト。
無料か有料かの二択ではなく、1件の業務を安全に完了させる総コストで比較するのが現実的です。
任せる仕事を「観測・準備・実行」に分ける
エージェントに任せる範囲は、職種ではなく作業の段階で切り分けると設計しやすくなります。
- 観測: メール、資料、チケット、ログを読み、事実と未確認を整理する。
- 準備: 返信案、差分案、チェックリスト、作業計画を作る。
- 実行: 送信、登録、更新、削除、公開など、外部状態を変える。
最初の導入では、観測と準備までを自動化し、実行は人の承認後に限定します。たとえば問い合わせ対応なら、受信内容の分類と返信案の作成までは任せても、送信は担当者が確認します。スプレッドシートなら、集計と差分の提示までは任せても、元データの上書きは止めます。
公式ドキュメントにも、危険なコマンドの承認、ファイル書き込みの安全策、コンテナ隔離、ユーザー認証など複数の防御層が記載されています。機能があるから任せるのではなく、実行段階だけを別ゲートに置く発想が必要です。
チャット連携とMCPは権限表で管理する
スマートフォンや普段のチャットからエージェントへ指示できると、いつでも呼び出せる秘書に近づきます。しかし、入口が増えるほど、誰が話せるか、どのアカウントを使うか、どの操作まで許すかを明確にしなければなりません。
Hermes Agentの公式セキュリティ資料では、メッセージングゲートウェイの許可リストやDMペアリング、危険なコマンドの承認、MCPへの資格情報の分離、セッション間の隔離などが説明されています。これらは「設定すれば安全」という保証ではなく、確認すべき境界の一覧です。
導入時はサービス名のリストではなく、次の表を作ります。
| 接続先 | 読み取り | 書き込み | 送信・削除 | 対象範囲 | 承認者 |
|---|---|---|---|---|---|
| メール | 必要な受信箱だけ | 下書きのみ | 送信不可から開始 | 指定ラベル | 担当者 |
| カレンダー | 予定の確認 | 仮予定のみ | 招待送信は停止 | 自社カレンダー | 代表者 |
| リポジトリ | 指定リポジトリ | ブランチ限定 | 本番変更は不可 | 検証用 | 開発担当 |
MCPを追加する場合も、接続できるかより、読める範囲と書ける範囲が説明できるかを先に確認します。
スキルと自動化は成功後に保存する
複雑な仕事を一度成功させたからといって、すぐ定期実行へ移すのは危険です。まず一回の実行を観測し、入力、判断、出力、例外、人の確認箇所を記録します。その後、再利用できる手順だけをスキルとして整理し、テストを重ねてからルーチン化します。
スキルには少なくとも次を含めます。
- 対象業務と対象外の業務。
- 必要な入力と、入力してはいけない情報。
- 作業の順序と判断ルール。
- 成功と失敗の確認方法。
- 人の承認が必要な操作。
- 失敗時の停止、通知、再開条件。
公式のスキル資料でも、エージェントがスキルを作成・更新できる仕組みと、スキル内容をスキャン・承認する設定が説明されています。自動生成された手順をそのまま信頼するのではなく、レビュー可能なファイルとして扱うのが重要です。
14日で小さく導入する
14日という期間は、導入を完了させる保証ではありません。どこまで確認でき、どこが未確認かを残すための区切りです。
- 1〜2日目: 対象業務を一つに絞り、入力、出力、承認者、禁止操作を書く。
- 3〜4日目: 読み取り専用の接続を作り、サンプルデータで観測だけを試す。
- 5〜7日目: 返信案や差分案など、外部状態を変えない準備作業を試す。
- 8〜10日目: 成功例と失敗例を記録し、再利用手順をスキルに整理する。
- 11〜12日目: 少量の定期実行を設定し、通知、タイムゾーン、重複実行、停止方法を確認する。
- 13〜14日目: 実行ログ、権限、入力データ、承認記録を再確認し、継続・修正・停止を決める。
この順序なら、エージェントの賢さではなく、実際の業務で必要な判断材料が蓄積されます。
任せない操作を先に決める
最初から自動化しない操作を決めておくと、便利さに引っ張られにくくなります。顧客情報の一括移動、外部への送信、支払い、権限変更、本番環境の更新、削除、契約に関わる判断は、少なくとも人の確認を必須にします。
これはAIを使わないという意味ではありません。調査、比較、下書き、差分表示、チェックリスト化までを任せ、最後の実行だけを人へ戻す設計です。失敗したときに「何を読んだか」「何を作ったか」「どこで止まったか」が残っていれば、改善の材料になります。
Hermes Agentの魅力は、記憶やスキルを使って手順を積み上げられることです。だからこそ、積み上げる対象を正本、権限、承認、例外と一緒に管理しなければなりません。
「使うほど育つ」エージェントを導入する最初の仕事は、ボットを増やすことではなく、育ててよい業務と、育ててはいけない境界を決めることです。