AIエージェントを社員にしてみた【第2部】Slack × Claude × GitHub アーキテクチャ概要

第1部では、なぜ社内にAIエージェントを常駐させようと考えたのかを書いた。記憶がリセットされる、毎回コンテキストを渡す必要がある、指示しないと動かない。これらの課題を解決するために、自前で構築する道を選んだ。

この第2部では、実際にどんな構成で作ったのかを概要レベルで紹介する。

先に言っておくと、使っている技術は特別なものではない。Slack、Claude、GitHub。どれも多くの企業がすでに導入済み、あるいは導入を検討しているサービスだ。ポイントは個々の技術ではなく、「どう組み合わせたか」にある。

---

全体構成：3つのレイヤー

構成は大きく3つのレイヤーに分かれる。

1. インターフェース層 — Slack

AIエージェントと人間が会話する場所。@メンションで指示を出し、結果もSlackに返ってくる。

2. 思考層 — Claude

指示を受け取って「何をすべきか」を考え、実行するエンジン。Claude CLIをDocker上で動かしている。

3. 記憶層 — GitHub

AIエージェントの記憶、目標、設定ファイルをすべてGitHubリポジトリで管理する。バージョン管理されるので、記憶の変更履歴が追える。

クラウド上のDockerコンテナ1つで完結する。

---

なぜSlackをインターフェースにしたのか

最初に決めた設計判断が「Slackに住まわせる」ことだった。

専用のWebダッシュボードを作る案もあった。チャットUIを自前で構築する案もあった。でも、それだと「もう一つのツール」が増えるだけだ。新しいツールを導入するたびに、ログインする場所が増え、通知が分散し、結局使わなくなる。

Slackには決定的な利点がある。

社員が毎日すでに開いている。

朝出社して（あるいは在宅で仕事を始めて）最初に開くのがSlack、という人は多いはずだ。AIエージェントもそこにいれば、わざわざ別のツールを開く必要がない。

もう一つの利点。Slackのチャンネル構造がそのまま「コンテキストの切り分け」になる。営業チャンネルでの会話と、開発チャンネルでの会話は、自然に分離される。AIエージェントはチャンネルの文脈を理解した上で応答できる。

実際に運用してみると、使用頻度が圧倒的に高い。専用UIだと「AIに聞こう」と意識的に切り替える必要があるが、Slackなら普段の会話の延長で自然にAIに仕事を振れる。

---

Claude CLIという選択

AIエンジンにはClaudeを採用した。理由はシンプルで、すでにサブスクリプションを契約していたからだ。

ここが重要なポイントなので強調しておく。

多くのAIエージェントフレームワークは、APIキーを取得して従量課金で利用する設計になっている。使えば使うほどコストが増える。月額の予測が立てにくい。中小企業にとっては、この「使うほど課金される」モデルは心理的なハードルが高い。

我々の場合、ClaudeのMax（サブスクリプション）プランをすでに契約していた。Claude CLIはこのサブスクリプションの範囲内で利用できる。つまり、AIエージェントがどれだけ仕事をしても、追加のAPI費用は発生しない。

これは導入を決断する上で、かなり大きな要因だった。

Claude CLIはDockerコンテナの中で動かしている。コンテナ化することで、環境の再現性が担保される。新しいサーバーにデプロイしても、同じ環境がそのまま立ち上がる。

---

GitHubで「脳みそ」をバージョン管理する

ここがこのシステムの設計上、最もユニークな部分かもしれない。

AIエージェントの「記憶」「目標」「設定」を、すべてGitHubリポジトリのMarkdownファイルとして管理している。

具体的には：

• MEMORY.md — AIが会話から学んだことを記録するファイル
• GOALS.md — KGI（最終目標）、KPI（中間指標）、ToDo（具体的タスク）の階層構造
• SOUL.md — AIの人格、判断基準、承認フローの定義

これらのファイルはGitHubで管理されているので、いつ、何が、どう変わったかの履歴がすべて残る。

「先週AIが学んだこと」を確認したければ、GitHubのコミット履歴を見ればいい。「なぜAIがこの判断をしたか」を追跡したければ、その時点のGOALS.mdを見ればいい。

通常のAIチャットでは、こうした透明性は得られない。会話が流れていって終わりだ。GitHubで管理することで、AIの思考過程が「監査可能」になる。

もう一つの利点として、デプロイしても記憶が消えない。コンテナを再起動しても、GitHubからファイルを取得すれば元通りだ。これは運用上、非常に安心感がある。

---

スキルシステム：AIに「手足」を与える

AIエージェントは「考える」だけでは不十分だ。実際に何かを「やれる」必要がある。

そこで、スキルシステムを設計した。スキルとは、AIエージェントが実行できるアクションをモジュール化したものだ。

現在、こんなスキルが稼働している：

• Google Workspace連携 — カレンダーの予定確認、Gmailの読み取り、Googleドライブのファイル操作
• CRM連携 — 顧客データベースの検索・更新
• ブラウザ操作 — Webサイトの閲覧・情報取得
• ブログ自動生成 — SEOキーワード調査から記事執筆、サムネイル生成、PR作成まで

各スキルは独立したモジュールになっている。新しいスキルを追加したいときは、スクリプトと設定ファイルを追加するだけでいい。本体のコードを触る必要がない。

この「プラグイン的な設計」が重要だ。最初からすべてのスキルを作り込む必要がない。「まずはSlackで会話できるだけ」から始めて、必要に応じてスキルを追加していける。

---

自律実行ループ：OODAサイクル

第1部で「指示待ちしないAI」が欲しいと書いた。それを実現しているのが、定期実行されるOODAループだ。

OODAとは、Observe（観察）→ Orient（状況判断）→ Decide（決定）→ Act（実行）のサイクルのこと。元々は軍事戦略のフレームワークだが、意思決定ループとして汎用性が高い。

AIエージェントは定期的にこのサイクルを回す：

Observe — 何が起きているか観察する

GOALS.mdを読み込み、現在のKPIをデータソース（GA4、CRM等）から取得する。Slackの会話履歴も確認して、新しい指示や情報がないかチェックする。

Orient — 状況を判断する

目標値と現在値のギャップを計算する。最もギャップが大きいKPIを特定し、期限が近いタスクの優先度を上げる。

Decide — 何をするか決める

ギャップを埋めるためのToDoを選択する。承認が不要なタスクならそのまま実行に移る。承認が必要なもの（メール送信、カレンダー変更など）は、Slackで人間に確認を取る。

Act — 実行する

タスクを実行し、GOALS.mdを更新してGitHubにプッシュする。結果をSlackに報告する。

このサイクルが数時間おきに自動で回る。人間が何も指示しなくても、AIエージェントは目標に向かって少しずつ前進し続ける。

---

複数エージェント体制

もう一つの設計上のポイントが、複数のAIエージェントを同じ基盤上で動かしていることだ。

現在、2つのエージェントが稼働している：

• 汎用エージェント — マーケティング、コンテンツ作成、リサーチ、社内業務全般
• CRM特化エージェント — 営業データの管理、顧客情報の整理、フォローアップ

なぜ分けるのか。1つのAIに全部やらせると、コンテキストが膨らみすぎて精度が落ちる。人間の組織と同じで、専門分化した方がパフォーマンスが出る。

エージェント間の連携もSlack上で行う。汎用エージェントが「この営業データを調べて」とCRM特化エージェントにメンションを飛ばす。人間のチームワークと同じ構図だ。

---

承認フロー：AIが勝手にやってはいけないこと

自律的に動くAIと聞くと、「勝手に変なことされたらどうするんだ」という不安が当然ある。

これに対する答えが、承認フローだ。

AIエージェントのアクションは2つに分類される：

承認不要（勝手にやってOK）：

• 情報の検索・調査
• レポートの作成
• 社内ドキュメントの整理
• GOALS.mdの更新

承認必要（人間の確認が必要）：

• メールの送信
• カレンダーの変更
• 外部サービスへの書き込み
• お金が発生するアクション

承認が必要なアクションを実行しようとすると、AIエージェントはSlackで「承認お願いします：○○を実行してもいいですか？」と聞いてくる。人間がOKを出して初めて実行される。

この線引きは明確にしておいた方がいい。「何でも自律的に」は危険だし、「何でも承認が必要」だと結局指示待ちAIに戻ってしまう。

---

コストの話

気になるのはコストだろう。

繰り返しになるが、我々の構成ではClaudeのサブスクリプション（Maxプラン）を利用している。AIエージェントの稼働コストは、このサブスクリプション料金に含まれる。

それ以外にかかるコストは：

• Dockerコンテナのホスティング — クラウドサービスの料金（月数千円程度）
• Slack — 既存の契約内
• GitHub — 既存の契約内

つまり、新たに大きな投資は不要だ。すでに使っているサービスの延長線上で構築できる。

これが、API従量課金ベースのAIエージェントフレームワークとの最大の違いだ。使えば使うほどコストが増えるモデルでは、AIエージェントを「遠慮なく使い倒す」ことが難しい。定額制なら、どんどん仕事を振れる。

---

第2部のまとめ：特別な技術は使っていない

振り返ると、使っている技術はどれも一般的なものだ。

• Slack — チームコミュニケーション
• Claude CLI — AIエンジン
• GitHub — コード＆設定管理
• Docker — コンテナ化

特別なAIフレームワークや、高価なエンタープライズツールは使っていない。

重要なのは「設計思想」だ。

• インターフェースは既存の場所（Slack）に統合する
• 記憶と目標はバージョン管理可能な形式で持つ
• スキルはモジュール化して段階的に追加する
• 自律実行と承認フローのバランスを設計する

この考え方は、ClaudeでなくてもGeminiでも、Slackでなくてもteamsでも応用できる。技術の選定よりも、設計の考え方が本質だ。

次の第3部では、AIが「会社を理解する」仕組みを詳しく紹介する。MEMORY、GOALS、そしてGitHub連動による記憶管理。使えば使うほど賢くなるAIの裏側を書く。

---

*この記事は「AIエージェントを"社員"にしてみた」シリーズの第2部です。*

• 第1部: なぜ社内にAIを"常駐"させたのか
• 第2部: Slack × Claude × GitHub — アーキテクチャ概要（本記事）
• 第3部: AIが会社を"理解する"仕組み
• 第4部: Slackから指示 → AIが自律実行 — 集合知の作り方
• 第5部: OpenClawとどう違うのか
• 第6部: 実際に何が自動化できたか — 導入のインパクト
• 第7部: 中小企業がAIエージェントを導入するためのロードマップ

---

*株式会社Atsumellは「つくりたいものがある人の、AI開発パートナー」として、要件定義から設計・開発まで、AIネイティブな体験で伴走します。AIエージェントの構築についてのご相談は、お問い合わせフォームからお気軽にどうぞ。*