Hermes Agentにバックオフィス作業を任せられるようにした話

私たちは、Hermes Agentにバックオフィス作業を任せるために、先に「安全に任せるための作業環境」を整えました。

AI Agentに社内業務を任せると聞くと、チャットからGitHub、AWS、GCP、社内ドキュメントを直接変更する姿を想像しやすいかもしれません。たしかに、技術的にはできることが増えています。

ただ、会社規定やCorporate ITの作業では、速さだけでは足りません。規定の文言、顧問からのフィードバック、GitHub Organizationの権限、AWSアカウント、GCPプロジェクトは、どれも事業運営の土台に関わります。AIが作業できても、人間が確認できない形で進むなら、むしろ危険です。

Chabitでは、Hermes Agentを「直接すべてを変更するAI」ではなく、「人間がレビューできる形に作業を進めるAI」として使っています。会社規定の改定案を作る。顧問コメントを整理する。GitHubやクラウドの管理作業をIssueやPull Requestにする。必要な確認事項をSlackで返す。

このように、AI Agentが作業できる範囲を広げながら、判断と承認は人間が持てる形にしています。

flowchart LR
  user["依頼者"] --> slack["Slack"]
  slack --> hermes["Hermes Agent"]
  hermes --> pr["Issue / Pull Request"]
  pr --> reviewer["人間のレビュー"]
  reviewer --> decision{"承認 / 差し戻し"}
  decision -- "差し戻し" --> hermes
  decision -- "承認" --> apply["必要な範囲だけ反映"]

Hermes Agentに任せたかったのは、判断ではなく作業の重さです

バックオフィス業務で重いのは、最終判断そのものだけではありません。むしろ、その手前にある調査、整理、反映、差分確認、説明文作成、記録化に時間がかかります。

たとえば、会社規定を更新するときには、次のような作業が発生します。

現行規定を探す
顧問税理士、社労士、弁護士などからのコメントを読む
どの条文に関係するかを確認する
文言の修正案を作る
修正理由を説明する
社内レビューに出す
GitHubやドキュメントに履歴を残す

このうち、税務・労務・法務上の最終判断は人間と顧問が行います。一方で、コメントを整理して、既存文書との差分を作り、Pull Requestとしてレビューできる形にする作業は、Hermes Agentに任せやすい領域です。

Corporate ITでも同じです。GitHubのTeam権限、AWSアカウント、GCPプロジェクト、社内SaaSの設定は、人間が最終判断すべき領域です。ただし、対象リポジトリを調べる、既存ルールを読む、変更案を作る、IssueやPRにまとめる、検証結果を残す作業は、AI Agentに向いています。

私たちがHermes Agentに任せたかったのは、会社の判断責任ではありません。判断できる状態まで作業を進めることです。

安全に任せるために、作業の入口をSlackとGitHubに寄せました

Hermes Agentへの依頼は、Slackから始まります。

たとえば、会社規定であれば次のように依頼します。

経費精算規程に顧問税理士のコメントを反映したいです。
現行規程との差分を確認して、修正案をPRにしてください。
判断が必要なところは質問してください。

Corporate ITであれば、次のような依頼です。

新しい開発メンバーにGitHubリポジトリの権限が必要です。
既存のTeam設計を確認して、必要な変更案をIssueにまとめてください。

ここで大事なのは、Slackの依頼だけで完結させないことです。Hermes Agentは、依頼内容を読んだあと、対象リポジトリ、既存ドキュメント、会社固有のスキル、過去の作業ルールを確認します。そのうえで、必要に応じてIssueやPull Requestに落とし込みます。

Slackは依頼の入口です。GitHubは作業と判断の記録です。

この分担にしておくと、チャットの流れで作業が消えません。なぜその変更をしたのか、どこを確認したのか、誰がレビューしたのかが、IssueとPRに残ります。

会社固有の作法は、スキルリポジトリに置きました

Hermes Agentを実務で使うには、一般的な知識だけでは足りません。

たとえば、同じGitHub管理でも、会社によってルールは違います。どのTeamにどの権限を付けるのか。管理者権限は誰が承認するのか。Terraformで管理するのか、手動でよいのか。PR本文に何を書くべきか。Slackにはどの粒度で報告するのか。

これらを毎回プロンプトで説明していると、運用は続きません。

そこでChabitでは、会社固有の作法をスキルとして管理しています。スキルは、Hermes Agentが必要に応じて読み込む業務手順書のようなものです。

たとえば、次のような内容をスキルにします。

会社規定を更新するときの確認観点
顧問コメントを反映するときの進め方
GitHub Organization管理のルール
AWS / GCPの変更をPull Request化するときの注意点
ChabitのSlack報告の文体
危険な操作を止める条件
Pull Request本文やIssue本文の書き方

スキルをGitHubリポジトリで管理すると、Agentのふるまい自体もレビューできます。

これは、AI Agentを会社で使ううえで重要です。プロンプトが個人の手元に散らばるのではなく、会社の運用資産として残ります。ルールを変えたいときは、スキルを更新し、レビューし、次の作業から反映できます。

Agent Registryで、任せる範囲を分けました

バックオフィス作業をAI Agentに任せるとき、すべてを1体のAgentに任せると危険です。

会社規定を見るAgentと、GitHub権限を見るAgentと、AWSアカウントを見るAgentでは、必要な知識も、触ってよい範囲も違います。会社規定の修正案を作るAgentに、クラウド本番環境の変更権限は必要ありません。GitHub Teamを確認するAgentに、税務判断はできません。

そこで、ChabitではAgentの役割を分けて考えています。

たとえば、次のような分け方です。

会社規定・社内ルールを扱うAgent
GitHub Organizationやリポジトリ権限を扱うAgent
AWSアカウントやDNSを扱うAgent
GCPプロジェクト管理を扱うAgent
記事や社内ドキュメントを書くAgent
Pull Requestレビューや品質ゲートを見るAgent

この役割分担をAgent Registryとして管理します。

Agent Registryは、誰に何を任せるかを整理する場所です。どのスキルを読むのか、どのリポジトリを見るのか、どこまで実行してよいのか、どこで人間に確認するのかを決めます。

これにより、Hermes Agentは「何でもできるAI」ではなく、「担当範囲を持った作業者」として扱いやすくなります。

実行環境は、Docker ComposeとWorkspaceで再現できるようにしました

AI Agentの作業は、実行環境がぶれると安定しません。

ある人のPCではGitHub CLIが使える。別の環境ではAWS CLIがない。スキルの置き場所が違う。作業対象のリポジトリが古い。認証方式が違う。こうした状態では、Agentに同じ依頼をしても同じ結果になりません。

そこで、ChabitではHermes Agentが作業する環境をできるだけそろえています。

構成要素としては、次のようなものがあります。

Hermes Agent本体
長めの作業を受け持つCodex App Server
会社固有のスキルリポジトリ
Agent Registryリポジトリ
作業対象になるGitHub Workspaceリポジトリ
それらをまとめて立ち上げるDocker Compose

ただし、この記事で伝えたいのはDocker Composeの細かい設定ではありません。

大事なのは、AI Agentが作業する場所をチームでそろえることです。どのスキルを読み、どのリポジトリを見て、どの認証で、どのルールに従って作業するのか。ここを再現できるようにすると、AI Agentの作業は個人の実験から、会社の運用に近づきます。

変更は、できるだけPull Requestにします

Hermes Agentに作業を任せるとき、私たちはできるだけPull Requestに寄せています。

会社規定の修正であれば、規定ファイルの差分をPull Requestにします。Corporate ITであれば、Terraformや管理用リポジトリの変更としてPull Requestにします。社内ドキュメントであれば、Markdownの修正としてPull Requestにします。

この形にすると、人間が見るべきものがそろいます。

何を変えるのか
なぜ変えるのか
どのファイルが変わるのか
検証は何をしたのか
未確認事項は何か
どこで人間の判断が必要か

Hermes Agentが直接変更を完了させるのではなく、レビュー可能な差分を作る。これが、安全に任せるための中心です。

特にCorporate ITでは、この考え方が重要です。GitHub、AWS、GCPのような管理対象は、便利さだけで触ると事故につながります。Hermes Agentが変更案を作り、Pull Requestで人間が確認し、必要な場合はGitHub ActionsやTerraformを通じて反映する。この流れにしておくことで、速さと統制を同じ場所に置けます。

会社規定も、AIに「書かせる」のではなく、レビューできる形にします

会社規定の作成や改定でも、考え方は同じです。

Hermes Agentに「就業規則を作って」と丸投げするのではありません。現行の規定、会社の実態、顧問からのコメント、過去の判断、関連する社内ルールを見ながら、修正案として出してもらいます。

たとえば、顧問税理士から経費精算規程へのコメントが来た場合、Hermes Agentは次のように作業します。

現行の経費精算規程を確認する
顧問コメントの論点を分ける
該当する条文や文言を探す
修正案を作る
判断が必要な箇所を質問として残す
差分をPull Requestにする
Pull Request本文に変更理由と確認事項を書く

この流れなら、AIが文章を作っても、人間と顧問がレビューできます。

flowchart LR
  advisor["顧問\n税理士・社労士・弁護士"] --> comment["コメント / 指摘"]
  current["現行規定"] --> hermes["Hermes Agent"]
  comment --> hermes
  hermes --> draft["修正案"]
  hermes --> questions["確認事項"]
  draft --> pr["Pull Request"]
  questions --> pr
  pr --> human["人間・顧問レビュー"]

会社規定は、きれいな文章であればよいわけではありません。実態に合っているか。税務・労務・法務の観点で問題ないか。運用できるか。例外時に困らないか。こうした判断は、人間が確認します。

Hermes Agentは、その確認をしやすくするために働きます。

Corporate ITでは、権限変更を「作業ログ付きの変更案」にします

Corporate ITでは、GitHub、AWS、GCPのアカウント管理が代表的なユースケースです。

たとえば、GitHubで新しいメンバーにリポジトリアクセスを付ける場合、いきなり権限を付与するのではなく、Hermes Agentに次のことを確認させます。

対象者は誰か
どのリポジトリにアクセスが必要か
既存のTeam設計に合っているか
最小権限になっているか
Terraformや管理リポジトリで扱うべき変更か
人間の承認が必要な権限か
変更後にどこへ記録を残すか

AWSやGCPでも同じです。アカウントやプロジェクトを作る、IAMや請求設定を変える、DNSを触る。こうした作業は、直接実行よりも、変更案、差分、plan、レビューを通すほうが安全に進められます。

flowchart LR
  requester["依頼者"] --> request["権限・アカウント変更依頼"]
  request --> hermes["Hermes Agent"]
  rules["既存ルール\nTeam設計 / Terraform / 管理方針"] --> hermes
  hermes --> issue["Issue"]
  hermes --> pr["Pull Request / plan"]
  pr --> reviewer["Corporate ITレビュー"]
  reviewer --> target["GitHub / AWS / GCP"]

Hermes Agentは、作業の速度を上げます。ただし、権限の最終判断は消しません。

この線引きをしておくことで、AI AgentをCorporate ITに入れやすくなります。

全体像は、レビュー可能な作業導線を作ることです

構成を図にすると、次のようになります。

flowchart TB
  subgraph actors["登場人物"]
    requester["依頼者"]
    reviewer["レビュー・承認者"]
    advisor["顧問\n税理士・社労士・弁護士"]
  end

  subgraph runtime["実行環境"]
    compose["Docker Compose"]
    hermes["Hermes Agent"]
    codex["Codex App Server"]
  end

  subgraph knowledge["会社固有の知識"]
    skills["Skill Repository"]
    registry["Agent Registry"]
  end

  subgraph work["作業と記録"]
    workspace["GitHub Workspace"]
    issue["Issue"]
    pr["Pull Request"]
  end

  requester --> hermes
  advisor --> requester
  compose --> hermes
  hermes --> codex
  hermes --> skills
  hermes --> registry
  hermes --> workspace
  workspace --> issue
  workspace --> pr
  issue --> reviewer
  pr --> reviewer
  reviewer -- "差し戻し" --> hermes
  reviewer -- "承認" --> targets["会社規定 / GitHub / AWS / GCP"]

この流れで大事なのは、Hermes Agentが本番環境や会社規定を勝手に書き換えるのではなく、レビュー可能な変更案にそろえることです。Slackは依頼の入口、GitHubは判断と履歴の場所、人間のレビューは承認ポイントとして残します。

技術要素はいくつかあります。Hermes Agent、Codex App Server、スキルリポジトリ、Agent Registry、GitHub Workspace、Docker Compose。ただし、目的はシンプルです。AI Agentが作業し、人間が確認できる導線を作ることです。

人間の仕事は、手作業からレビューと判断に移ります

Hermes Agentを入れると、人間の仕事がなくなるわけではありません。位置が変わります。

これまでは、人間がファイルを探し、コメントを読み、修正し、Pull Requestを書き、権限を確認し、手順書を更新していました。Hermes Agentに任せると、人間はそのすべてを毎回手でやる必要が減ります。

代わりに、人間は次のことに集中します。

その変更を受け入れてよいか
会社のルールとして自然か
顧問に再確認すべき点はないか
権限が過剰ではないか
変更範囲が正しいか
反映タイミングに問題がないか
例外として記録すべきことはないか

これは、バックオフィス業務を軽く見るという話ではありません。むしろ逆です。人間が見るべき判断に集中するために、AI Agentに作業の重さを持たせています。

AI Agentに任せるほど、ルールはコードとドキュメントに寄せる

Hermes Agentを使うほど、会社のルールは暗黙知のままだと困ります。

「この場合は松岡さんに確認する」「このTeamにはpush権限まで」「この規定は顧問確認が必要」「このTerraform stateは勝手に分けない」「このSlack報告は短く結論から」。こうしたルールが人の頭の中だけにあると、Agentは毎回迷います。

だから、Chabitではスキル、ドキュメント、Issue、Pull Request、Terraform、GitHub Actionsに寄せています。

AI Agentに任せるためには、AIだけを賢くするのではなく、会社の運用をAgentが読める形にする必要があります。

これは少し手間がかかります。しかし、一度整えると、人間にも効きます。新しく入ったメンバーも、業務委託の人も、別のAgentも、同じルールを読めるようになるからです。

AI Agentは、統制を外すためではなく、統制の中で速く進めるために使う

Chabitでは、Hermes Agentにバックオフィス作業を任せられるように、先に安全な作業環境を整えました。

Slackから依頼を受け、スキルリポジトリで会社固有の作法を読み、Agent Registryで担当範囲を分け、GitHub Workspaceで対象リポジトリを扱い、Docker ComposeやCodex App Serverで実行環境をそろえる。細かい構成要素はいくつかありますが、目的はひとつです。

AI Agentが、レビュー可能な形で仕事を進められるようにすることです。

会社規定の改定では、Hermes Agentが顧問コメントを整理し、修正案をPull Requestにします。Corporate ITでは、GitHub、AWS、GCPの変更案をIssueやPull Requestにし、人間が確認できる形にします。

AI Agentに任せるとは、人間の判断をなくすことではありません。人間が判断できる状態まで、作業を前に進めてもらうことです。

私たちは、Hermes Agentを開発だけでなく、会社運営の実務にも組み込んでいます。安全に任せるための作業環境を整えることで、バックオフィス業務もAI Agentが実際に作業できる領域になってきました。

Hermes Agentにバックオフィス作業を任せられるようにした話

Hermes Agentに任せたかったのは、判断ではなく作業の重さです

安全に任せるために、作業の入口をSlackとGitHubに寄せました

会社固有の作法は、スキルリポジトリに置きました

Agent Registryで、任せる範囲を分けました

実行環境は、Docker ComposeとWorkspaceで再現できるようにしました

変更は、できるだけPull Requestにします

会社規定も、AIに「書かせる」のではなく、レビューできる形にします

Corporate ITでは、権限変更を「作業ログ付きの変更案」にします

全体像は、レビュー可能な作業導線を作ることです

人間の仕事は、手作業からレビューと判断に移ります

AI Agentに任せるほど、ルールはコードとドキュメントに寄せる

AI Agentは、統制を外すためではなく、統制の中で速く進めるために使う

関連サービス

関連記事

松岡秀樹

Hermes Agentにバックオフィス作業を任せられるようにした話

Hermes Agentに任せたかったのは、判断ではなく作業の重さです

安全に任せるために、作業の入口をSlackとGitHubに寄せました

会社固有の作法は、スキルリポジトリに置きました

Agent Registryで、任せる範囲を分けました

実行環境は、Docker ComposeとWorkspaceで再現できるようにしました

変更は、できるだけPull Requestにします

会社規定も、AIに「書かせる」のではなく、レビューできる形にします

Corporate ITでは、権限変更を「作業ログ付きの変更案」にします

全体像は、レビュー可能な作業導線を作ることです

人間の仕事は、手作業からレビューと判断に移ります

AI Agentに任せるほど、ルールはコードとドキュメントに寄せる

AI Agentは、統制を外すためではなく、統制の中で速く進めるために使う

関連サービス

関連記事

松岡 秀樹

松岡秀樹