AIエージェントを社員にしてみた【第1部】なぜ社内にAIを常駐させたのか

「また最初から説明するのか」

AIツールを開くたびに、同じことを繰り返している自分がいた。うちの会社の事業内容、チームの構成、今進んでいるプロジェクト、使っている技術スタック。毎回ゼロからコンテキストを渡して、ようやく使える回答が返ってくる。

正直、途中から面倒になってやめてしまうことも多かった。

これは我々だけの悩みではないはずだ。AI活用に積極的な企業ほど、この「コンテキスト問題」にぶつかっているのではないだろうか。

---

中小企業の「人手が足りない」は構造的な問題

株式会社Atsumellは、AI開発のプロフェッショナルサービスを提供している会社だ。クライアントの要件定義から設計・開発まで、AIネイティブなアプローチで伴走する。

聞こえはいいが、実態は少数精鋭のチームだ。

営業もやる、提案書も作る、開発もする、採用もする。中小企業ならどこも同じだと思うが、「手が足りない」は慢性的な問題だった。大企業なら専任のマーケティングチームがいて、専任のインサイドセールスがいて、専任の分析担当がいる。うちにはいない。

だからAIに頼った。Claude、Gemini、ChatGPT。色々使った。

でもどれも「その場限りのアシスタント」だった。

---

AIに毎回「うちの会社はね…」と説明する虚しさ

2025年あたりから、AIの性能は劇的に上がった。Claude Sonnet、Gemini Pro、GPT-4o。どれも優秀だ。コードも書けるし、提案書のドラフトも作れるし、データ分析もできる。

ただ、一つ決定的な問題がある。

毎回、記憶がリセットされる。

月曜日にClaudeで提案書の構成を一緒に考える。火曜日に「昨日の続きで」と話しかけると、何も覚えていない。プロジェクト機能でドキュメントを渡しても、毎回整理してアップロードする手間がかかる。Geminiも同様で、会社固有の文脈を継続的に保持する仕組みがない。

結局、AIを使いこなすために「AIに食わせるためのドキュメント管理」という新しい仕事が生まれる。本末転倒だ。

もう一つ。AIは「聞かれたことに答える」のは得意だが、「自分から動く」ことはしない。

「先週の商談の後、フォローメール送った？」と聞いてくれるAIがいたらどんなに楽か。「ブログのアクセス数が下がっているから、新しい記事を書いた方がいい」と提案してくれるAIがいたら。

そんなAIが欲しかった。

---

「道具としてのAI」と「社員としてのAI」の違い

ここで我々の中で、明確に考え方が変わった瞬間がある。

AIを「ツール」として使うフェーズは終わった。次は「メンバー」として迎え入れるフェーズだ。

これは単にAIを擬人化してかわいがるという話ではない。具体的に何が違うかというと：

ツールとしてのAI:

• 人間が起動する
• 人間がコンテキストを渡す
• 人間が結果を受け取る
• 終わったら忘れる

社員としてのAI:

• 自分で状況を把握する
• 会社のことを覚えている
• 自分で判断して動く
• 学んだことを次に活かす

この差は小さいようで、運用してみると天と地ほど違う。

たとえば、ツールとしてのAIにブログ記事を書かせるとする。毎回、SEOキーワードの調査結果を渡し、過去の記事一覧を渡し、会社のトーン＆マナーを渡し、ターゲット読者を説明して、ようやく1本書ける。準備だけで30分。

社員としてのAIなら、「ブログ書いておいて」の一言で済む。SEOキーワードは自分で調べる。過去記事との重複は自分でチェックする。会社のトーンは覚えている。勝手にやって、終わったら報告してくれる。

---

求めたのは「指示待ちしないAI」

我々が作りたかったものを整理すると、こうなる。

1. 会社を覚えているAIであること

チームメンバーの名前と役割、進行中のプロジェクト、クライアントの情報、過去にやったことの結果。これらを蓄積して、会話のたびにコンテキストが厚くなっていく。デプロイし直しても記憶が消えない。

2. 自分で目標に向かって動くAIであること

KGI（最終目標）とKPI（中間指標）を与えたら、そこから逆算してタスクを分解し、優先順位をつけて、自律的に実行する。人間は「方向」を示すだけでいい。

3. チーム全員がアクセスできるAIであること

特定の人だけが使えるのではなく、Slackで@メンションすれば誰でも指示を出せる。チーム全体の集合知として機能する。

4. やっていいことと悪いことの区別がつくAIであること

お金が動くこと、外部にメールを送ること、データを削除すること。これらは勝手にやってはいけない。人間の承認を求めてから動く。逆に、情報を調べる、レポートを作る、社内ドキュメントを整理する、といったことは自律的にやってほしい。

この4つの要件を満たすツールやサービスは、当時どこにもなかった。

---

「なければ作る」がエンジニア集団の強み

既存のサービスやフレームワークも検討した。

MicrosoftのCopilot Studio、GoogleのVertex AI Agent Builder、各種のAIエージェントプラットフォーム。どれも素晴らしいプロダクトだが、我々の求めるものとは少しズレていた。

大企業向けに設計されていて、中小企業が日々の業務でカジュアルに使うには重すぎる。あるいは、汎用的すぎて「うちの会社を理解する」仕組みがない。あるいは、追加のAPIコストが発生して、すでに契約しているAIサブスクリプションとの二重課金になる。

我々はシステム開発を生業としている会社だ。「なければ作る」は自然な選択だった。

すでにClaudeのサブスクリプションは契約している。Slackは全員が毎日使っている。GitHubでコードは管理している。

この3つを組み合わせれば、「社員としてのAI」が作れるのではないか。

そう考えて、プロジェクトが始まった。

---

最初の一歩は「Slackに住まわせる」こと

具体的にどう作ったかは第2部以降で詳しく書くが、最初の設計判断だけ共有しておく。

AIエージェントの「居場所」をSlackにした理由は明確だ。

社員は毎日Slackを開く。会話し、ファイルを共有し、意思決定をする。AIエージェントもそこにいれば、特別なUIは不要になる。新しいダッシュボードにログインする必要もない。

@メンションすれば応答する。チャンネルの会話を見て文脈を理解する。人間の社員とまったく同じインターフェースで働く。

この「同じ場所にいる」というのが、想像以上に重要だった。わざわざ別のツールを開くのと、いつものSlackでメンションするのでは、使用頻度がまったく違う。

結果的に、チーム全員が自然にAIに仕事を振るようになった。

---

第1部のまとめ：AIを「使う」から「迎え入れる」へ

振り返ると、我々がやったことはシンプルだ。

「AIツールの課題」を整理し、「こうあってほしい」を定義し、「すでに使っているサービスの組み合わせ」で解決した。

• Claude/Geminiの「記憶がリセットされる問題」 → 長期記憶の仕組みを自前で構築
• 「毎回コンテキストを渡す問題」 → 会社情報を常に保持する設計
• 「指示待ちの問題」 → 目標管理と自律実行ループの導入
• 「特定の人しか使えない問題」 → Slackを共通インターフェースに

特別な技術を使ったわけではない。Claude、Slack、GitHub。どれも多くの企業がすでに使っている、あるいは使い始めているサービスだ。

ポイントは「組み合わせ方」と「設計思想」にある。

次の第2部では、実際のアーキテクチャを概要レベルで紹介する。Slack × Claude × GitHubをどう繋いで、AIエージェントに「脳」と「手足」を与えたのか。

技術的に深い話も出てくるが、概要レベルで書くので、エンジニアでなくても読める内容にするつもりだ。

---

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

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

---

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