私たちは、Corporate ITのAIエージェント化で大事なのは「自動で何でも変更できること」ではなく、「人間が確認し、承認できる形に変更をそろえること」だと考えています。
GitHub Organizationの設定、AWSのDNS・Organization・Account・Billing、GCPのプロジェクト管理は、どれも事業運営の土台です。便利だからといって、チャットから直接変更できるだけでは危険です。一方で、すべてを人間の手作業に戻すと、設定変更のたびに依頼、調査、実装、レビュー、反映が分断されます。
Chabitでは、Hermes AgentをCorporate ITの実務に組み込み、Terraformでルールベースを守りながら、Pull Requestで人間が承認できる運用にしています。AIが作業を進め、人間は差分、リスク、applyのタイミングを確認する。この分担にすることで、速さと統制を同じワークフローに乗せています。
Corporate ITは「小さな変更」が大きな影響を持つ
Corporate ITの変更は、1行の設定でも影響範囲が広がります。DNSレコードを1つ追加する、GitHubのリポジトリ権限を変える、AWSアカウントやBudgetの設定を更新する。どれも作業自体は小さく見えますが、間違えると公開サイト、開発フロー、請求、セキュリティ境界に影響します。
たとえば、ドメイン管理では chabit.co.jp 配下のTXTレコードやGitHub Pages向けCNAMEを扱います。GitHub管理では、Organizationプロフィール、Teamの権限、リポジトリ設定、ブランチ保護を扱います。AWS側では、Organizations、アカウント、Route53、Billing、Budget、SCPのような管理者向けリソースが対象になります。
これらをAIに任せるときに避けたいのは、作業者がAIに変わっただけで統制が消えることです。私たちは、AIが変更を提案しても、最終的な反映はTerraformの差分とPull Requestレビューに戻す形にしています。
Hermes Agentは作業者、Terraformはルール、PRは承認ポイントです
Chabitの運用では、Hermes Agentが依頼内容を読み、対象リポジトリを確認し、Terraformの変更としてPull Requestを作ります。ここで重要なのは、Hermesが本番環境へ直接変更するのではなく、Terraformのコード差分として説明可能な状態にすることです。
運用の流れは、次のように分けています。
- チャットで依頼を受ける
- Hermes Agentがリポジトリ、既存ルール、関連ドキュメントを確認する
- 必要に応じてIssueを作り、作業範囲と受け入れ条件を整理する
- Terraformやドキュメントを更新し、検証コマンドを実行する
- Pull Requestを出し、差分、影響範囲、確認事項を日本語で説明する
- 人間がレビューし、必要なタイミングでmerge / applyを承認する
この形にすると、AIの成果物は「実行済みの操作」ではなく「レビュー可能な提案」になります。人間は、チャットのやり取りだけを信じるのではなく、GitHub上の差分、CI、Terraform plan、PR本文を見て判断できます。
安全に管理するメカニズム
Hermes Agent、Terraformリポジトリ、GitHub Actions、各管理対象を直列につなぐことで、変更は必ずレビュー可能な差分と自動検証を通ります。Hermes Agentは直接GitHub Organization、AWS、GCPを書き換えるのではなく、TerraformリポジトリにPull Requestを出します。GitHub Actionsは変更スコープに応じてplanを実行し、人間がPRとplanを確認してからmerge / applyへ進めます。
flowchart LR
request["依頼\nDiscord / GitHub Issue"] --> hermes["Hermes Agent\n調査・設計・PR作成"]
hermes --> repo["Terraform repo\nルールベース / state境界 / reviewable diff"]
repo --> pr["Pull Request\n差分・plan・リスク説明"]
pr --> review{"Human review\n承認する?"}
review -- "差し戻し" --> hermes
review -- "承認" --> actions["GitHub Actions\nfmt / validate / scoped plan / gated apply"]
actions --> github["GitHub Org\nrepos / teams / branch protection"]
actions --> aws["AWS\nDNS / Organizations / accounts / billing"]
actions --> gcp["GCP\nprojects / IAM / billing settings"]
classDef human fill:#fff3cd,stroke:#c58b00,color:#3b2a00;
classDef agent fill:#e7f0ff,stroke:#356ac3,color:#0a2b63;
classDef guard fill:#e8f7ef,stroke:#1f8f4d,color:#073b1e;
classDef target fill:#f3f4f6,stroke:#667085,color:#111827;
class request,review human;
class hermes agent;
class repo,pr,actions guard;
class github,aws,gcp target;この図のポイントは、AIの実行力を「直接反映」ではなく「Pull Request化」に寄せていることです。Terraform repoがルールとstate境界を持ち、Actionsがfmt、validate、plan、承認付きapplyを担うため、変更対象がGitHub、AWS、GCPに分かれても、人間が見る入口はPRにそろいます。
GitHub Organization管理もコードレビューの対象にする
GitHub Organizationは、開発組織の入口です。リポジトリ作成、Teamアクセス、メンバー招待、ブランチ保護、head branch削除設定、Organizationプロフィールの整備は、開発速度とセキュリティの両方に関わります。
Chabitでは、これらを場当たり的な管理画面操作だけで済ませないようにしています。Hermes Agentが依頼を受けたら、対象リポジトリがTerraform管理なのか、既存リポジトリのオンボーディングなのか、Team権限の変更なのかを切り分けます。そのうえで、TerraformのGitHubスコープに変更を入れ、PRとしてレビューできる形にします。
この運用の利点は、権限変更が後から追えることです。「誰に何を付与したか」だけでなく、「なぜそのグループにしたか」「どのリポジトリ設定を全体標準にしたか」「どこは例外にしたか」が、IssueとPRに残ります。AIが作業しても、組織の判断履歴はGitHubに残ります。
AWSとDNSは、state境界とapply承認を崩さない
AWS側の変更では、Route53、Organizations、Account、Billingのような管理リソースを扱います。ここでの原則は、state境界を勝手に変えないことです。Terraformのstateは、何を同じ運用単位として扱うかを決める境界です。AIが便利そうだからといって、既存のstateやbackend keyを安易に分けたり統合したりすると、後の運用リスクになります。
DNSのような比較的小さな変更でも、Hermes Agentは既存のTerraform構成を確認し、どのディレクトリ・どのスコープに置くべきかを見ます。ローカルでは terraform fmt やbackendなしのvalidateなど、権限なしでもできる検証を行います。本番反映はPRレビューとGitHub Actionsのapplyフローに戻します。
また、merge後に必要なワークフローだけを動かすことも大事です。AWS、GCP、GitHubのようにスコープが分かれる場合、変更されたパスに応じて必要なplan / applyだけを走らせます。全部を毎回applyするのではなく、変更範囲に応じて確認と反映を絞ることで、レビューの集中力と安全性を保ちます。
GCPプロジェクト管理も同じ型に寄せる
GCPプロジェクト管理でも、基本の考え方は同じです。プロジェクト、IAM、課金、API有効化のような設定は、管理画面で直接触ると早く見えます。しかし、誰がどの判断で変更したのかが残りにくくなります。
Hermes Agentに任せる範囲を広げるほど、実行経路をそろえることが重要になります。AWSだけ、GitHubだけ、GCPだけを個別の手順で管理すると、AIが扱う前提も人間が見る証跡も分散します。Terraform、Issue、PR、CI、承認付きapplyに寄せることで、クラウドやSaaSが違っても運用の見方をそろえられます。
ここでの目的は、すべてを1つの巨大なTerraformに押し込むことではありません。スコープごとにstateや実行単位を分けながら、変更の入口とレビューの型をそろえることです。
人間の仕事は、手作業から判断設計へ移る
Hermes AgentをCorporate ITに入れると、人間の仕事はなくなるのではなく、位置が変わります。DNSレコードの書き方やGitHub設定画面のクリックを毎回担当するのではなく、どのルールを守るか、どの差分なら承認できるか、どこで止めるかを設計する仕事へ移ります。
私たちが重視している確認ポイントは、次のようなものです。
- 変更対象のスコープが正しいか
- Terraform stateやbackendの境界を壊していないか
- 権限変更が最小権限になっているか
- apply前に人間が見るべきplanやリスクが説明されているか
- CIやGitHub Actionsが変更範囲に応じて必要なものだけ動くか
- 例外や未確認事項がPR本文に残っているか
AIに任せるほど、人間のレビュー観点は重要になります。AIは作業量を減らしますが、組織としての判断責任は消しません。だからこそ、PR承認という人間の判断点を残したまま、AIに調査、実装、検証、説明を任せる形にしています。
Corporate ITのAI化は、禁止ではなく安全に進める設計です
Corporate ITやセキュリティの役割は、事業を止めることではありません。危ないから全部禁止するのではなく、リスクを整理し、条件付きで安全性を確認しながら進める道を作ることです。
Hermes AgentとTerraformの組み合わせは、その考え方と相性があります。AIが変更案を作り、Terraformがルールベースを表現し、PRが人間の承認点になります。直接実行ではなく、レビュー可能な差分にする。暗黙の作業ではなく、IssueとPRに判断を残す。属人的な管理画面操作ではなく、再実行できるコードにする。
この形なら、Corporate IT業務はAIで前に進められます。安全のために必要以上に遅くするのではなく、統制を保ちながら速く進める。Chabitは、AIエージェントを開発だけでなく、組織運用の基盤にも組み込みながら、事業継続への影響を抑えて前進しやすいCorporate ITを設計しています。
関連サービス
- AI Agent開発: 業務の判断基準、権限、人間の確認ポイントを整理し、実務で動くAI Agentを設計・実装します。
- テクニカルディレクション: リポジトリルール、品質ゲート、PRレビュー、CI/CDを含め、AIエージェントを安全に運用できる開発・運用体制を設計します。
- AI駆動開発ブーストプログラム: コーディングエージェントを個人利用で終わらせず、Issue、PR、CI、レビューを含むチームの開発OSとして定着させます。
