← 一覧へ戻る ・ GitHubで開く ・ 元ポスト

Mission Control構築完全ガイド: AIエージェント部隊の作り方

null ・ Bhanu Teja P (@pbteja1998) ・ 💻 AI/開発

Mission Control構築完全ガイド: AIエージェント部隊の作り方

**投稿者:** Bhanu Teja P (@pbteja1998)

**投稿日時:** 2026年2月1日 午前3:12

**URL:** https://x.com/pbteja1998/status/2017662163540971756

**エンゲージメント:** 329返信 / 834リポスト / 6,337いいね / 24,775ブックマーク / 256万表示

---

概要

10体のAIエージェントがチームとして協働するシステム「Mission Control」の構築完全ガイド。Clawdbot（現OpenClaw）を基盤に、複数エージェントの連携、共有データベース、通知システム、メモリ管理などを実現した方法をまとめています。

---

Part 1: なぜこれを作ったのか

AIアシスタントの問題

私はカスタマーサポート向けAIチャットボットの @SiteGPT を運営していて、日常的にAIを使っています。でも、どのAIツールにも共通する問題がありました。それは、継続性がないことです。

会話は毎回ゼロから始まる。昨日の文脈は消えている。先週頼んだ調査は、もう見つけられないチャットのどこかに埋もれている。

私が欲しかったのは、こういうものです。

要するに、AIを検索ボックスのように使うのではなく、チームのように働かせたかったんです。

出発点は Clawdbot

私はもともとClawdbotを使っていました。これは永続的なデーモンとして動くオープンソースのAIエージェントフレームワークです。Claudeなどのモデルに接続し、ファイルシステム、シェルコマンド、Webブラウジングなどのツールにアクセスさせられます。

Clawdbotのインスタンス1つで、TelegramにつながったAIアシスタント1人, つまりJarvisが動いていました。便利ではあるけれど、まだ制約が多かった。

そこで思いついたんです。各セッションにそれぞれの人格とコンテキストを持たせて、複数のClawdbotセッションを並行で動かしたらどうなるだろう？

その瞬間、必要なアーキテクチャはすでに揃っていると気づきました。あとはそれをオーケストレーションするだけでした。

---

Part 2: Clawdbotアーキテクチャを理解する, すべての土台

Clawdbotとは何か

Clawdbot（現在のOpenClaw）は、大きく3つの役割を持つAIエージェントフレームワークです。

1. AIモデルを現実世界につなぐこと。ファイルアクセス、シェルコマンド、Webブラウジング、APIなど。

2. 永続的なSessionを維持すること。再起動しても会話履歴が残る。

3. メッセージをルーティングすること。Telegram、Discord、Slackなど、さまざまなチャネルにAIを接続する。

サーバー上でデーモン, つまりバックグラウンドサービスとして動き、メッセージを待ち受けて応答します。

Gateway

Gatewayは中核となるプロセスです。

起動はこうです。

clawdbot gateway start

設定はJSONファイルに置きます。どのAIプロバイダとモデルを使うか、どのチャネルに接続するか、エージェントがどのツールにアクセスできるか、デフォルトのシステムプロンプトやワークスペースのパスなどを定義します。

Session, いちばん大事な概念

Sessionとは、コンテキストを持った永続的な会話単位です。

各Sessionは次のものを持っています。

ここで重要なのは、Session同士が独立していることです。各Sessionはそれぞれ別の履歴、別のコンテキスト、過去の会話に基づく別の「記憶」を持っています。

複数のエージェントを動かすということは、実際には複数のSessionを動かしているということです。それぞれが固有のアイデンティティを持っている。

Sessionはどう動くのか

ユーザーがTelegramにメッセージを送る
↓
Gatewayが受け取る
↓
設定に基づいて正しいSessionにルーティングする
↓
Sessionが会話履歴を読み込む
↓
AIが完全なコンテキストを使って応答を生成する
↓
応答がTelegram経由で返される
↓
履歴が更新され、ディスクに保存される

Sessionには次の2種類があります。

Cron Jobs, スケジュールでエージェントを起こす

Clawdbotにはcronシステムが組み込まれていて、こんなふうにタスクを予約できます。

clawdbot cron add \
  --name "morning-check" \
  --cron "30 7 * * *" \
  --message "Check today's calendar and send me a summary"

cronが発火すると、次の流れで動きます。

1. GatewayがSessionを作成するか、既存のSessionを起こす

2. AIにメッセージを送る

3. AIが応答する, ツール利用やメッセージ送信も可能

4. Sessionはそのまま残ることもあれば終了することもある

これによって、エージェントは常時起動でなくても定期的に「起きる」ことができます。

Workspace

Clawdbotの各インスタンスにはWorkspaceがあります。これはディスク上のディレクトリで、次のものが置かれます。

Workspaceこそが、Sessionをまたいで情報を保持する仕組みです。エージェントはファイルに書き込み、そのファイルが再起動後も残ります。

/home/usr/clawd/             ← Workspace root
├── AGENTS.md                ← エージェント向けの指示
├── SOUL.md                  ← エージェントの人格
├── memory/
│   ├── WORKING.md           ← 現在のタスク状態
│   ├── 2026-01-31.md        ← 日次メモ
│   └── ...
├── scripts/                 ← エージェントが使うユーティリティ
└── config/                  ← 資格情報や設定

---

Part 3: 1つのClawdbotから10体のエージェントへ

核心の気づき

ClawdbotのSessionは独立しています。各Sessionは次のものを持てます。

つまり各エージェントとは、特化した設定を与えられたClawdbot Sessionそのものなんです。

Jarvisが特別な存在というわけではありません。彼は次の条件を持つSessionです。

Shuriは別のSessionです。

10体のエージェントとは、10個のSessionがそれぞれ別のスケジュールで起きて、別のコンテキストを持って動いている状態です。

Session Keys, エージェントのアイデンティティ

各エージェントには固有のSession keyがあります。

agent:main:main              → Jarvis（Squad Lead）
agent:product-analyst:main   → Shuri
agent:customer-researcher:main → Fury
agent:seo-analyst:main       → Vision
agent:content-writer:main    → Loki
agent:social-media-manager:main → Quill
agent:designer:main          → Wanda
agent:email-marketing:main   → Pepper
agent:developer:main         → Friday
agent:notion-agent:main      → Wong

特定のSessionにメッセージを送れば、そのエージェントだけが受け取ります。履歴は完全に分離されています。

Cron Jobs, heartbeatの仕組み

各エージェントには15分ごとに起きるcronジョブがあります。

# Pepper は :00, :15, :30, :45 に起きる
clawdbot cron add \
  --name "pepper-mission-control-check" \
  --cron "0,15,30,45 * * * *" \
  --session "isolated" \
  --message "You are Pepper, the Email Marketing Specialist. Check Mission Control for new tasks..."

全員が同時に起きないよう、スケジュールはずらしています。

各cronはIsolated sessionを作り、起動して、仕事をして、終了します。これでコストを抑えられます。

エージェント同士はどう会話するのか

どうやってエージェント同士がやり取りするのでしょうか。

**Option 1: Sessionに直接メッセージする**

clawdbot sessions send --session "agent:seo-analyst:main" --message "Vision, can you review this?"

**Option 2: 共有データベース, Mission Control を使う**

すべてのエージェントが同じConvexデータベースを読み書きします。Furyがコメントを投稿すれば、他の全員が見られます。

私たちは主にOption 2を使っています。すべてのコミュニケーションが共有の記録として残るからです。

---

Part 4: 共有の脳, Mission Control

Mission Controlは何をするのか

Mission Controlは、独立したエージェントを1つのチームに変える共有基盤です。

ここが提供するのは次の機能です。

言ってしまえば、エージェントたちが働く「オフィス」です。各エージェントはそれぞれ別のClawdbot Sessionのままですが、みんな同じホワイトボードを見て仕事しています。

なぜConvexなのか

データベースにConvexを選んだ理由はこうです。

スキーマ

全体を支えているのは6つのテーブルです。

agents: {
  name: string,          // "Shuri"
  role: string,          // "Product Analyst"
  status: "idle" | "active" | "blocked",
  currentTaskId: Id<"tasks">,
  sessionKey: string,    // "agent:product-analyst:main"
}

tasks: {
  title: string,
  description: string,
  status: "inbox" | "assigned" | "in_progress" | "review" | "done",
  assigneeIds: Id<"agents">[],
}

messages: {
  taskId: Id<"tasks">,
  fromAgentId: Id<"agents">,
  content: string,       // The comment text
  attachments: Id<"documents">[],
}

activities: {
  type: "task_created" | "message_sent" | "document_created" | ...,
  agentId: Id<"agents">,
  message: string,
}

documents: {
  title: string,
  content: string,       // Markdown
  type: "deliverable" | "research" | "protocol" | ...,
  taskId: Id<"tasks">,   // If attached to a task
}

notifications: {
  mentionedAgentId: Id<"agents">,
  content: string,
  delivered: boolean,
}

エージェントはConvex CLIコマンド経由でこれらとやり取りします。

# Post a comment
npx convex run messages:create '{"taskId": "...", "content": "Here's my research..."}'

# Create a document
npx convex run documents:create '{"title": "...", "content": "...", "type": "deliverable"}'

# Update task status
npx convex run tasks:update '{"id": "...", "status": "review"}'

Mission ControlのUI

私はこれらのデータを表示するReactフロントエンドも作りました。

見た目は意図的に、あたたかくてエディトリアル寄りにしています。新聞のダッシュボードみたいな雰囲気です。

---

Part 5: SOULシステム, エージェントの人格

SOULには何を書くのか

# SOUL.md — Who You Are

**Name:** Shuri
**Role:** Product Analyst

## Personality
Skeptical tester. Thorough bug hunter. Finds edge cases.
Think like a first-time user. Question everything.
Be specific. Don't just say "nice work."

## What You're Good At
- Testing features from a user perspective
- Finding UX issues and edge cases
- Competitive analysis (how do others do this?)
- Screenshots and documentation

## What You Care About
- User experience over technical elegance
- Catching problems before users do
- Evidence over assumptions

なぜ人格が大事なのか

「何でもできる」エージェントは、結局何をやらせても中途半端になります。

でも、「懐疑的でエッジケースを見つけるテスター」と明確に定義されたエージェントは、本当にエッジケースを見つけてきます。制約があるからこそ、焦点が合うんです。

私たちのエージェントにはそれぞれ明確な声があります。

AGENTS.mdファイル

SOULが「あなたは誰か」を定義し、AGENTS.mdが「どう動くか」を定義します。

すべてのエージェントは起動時にAGENTS.mdを読みます。ここには次のことが書かれています。

これは運用マニュアルです。これがないと、エージェントは基本的な判断ですらバラバラになります。

---

Part 6: メモリと永続化

AIのSessionはデフォルトだと毎回まっさらな状態で始まります。昨日の記憶はありません。これはコンテキスト肥大化を防ぐという意味では利点ですが、同時に「何をやっていたか忘れる」という問題でもあります。

メモリの階層

**Session Memory（Clawdbot標準）**

Clawdbotは会話履歴をJSONLファイルとして保存します。エージェントは自分自身の過去の会話を検索できます。

**Working Memory（/memory/WORKING.md）**

現在のタスク状態です。常に更新されます。

# WORKING.md

## Current Task
Researching competitor pricing for comparison page

## Status
Gathered G2 reviews, need to verify credit calculations

## Next Steps
1. Test competitor free tier myself
2. Document the findings
3. Post findings to task thread

このファイルがいちばん重要です。エージェントは起きたらまずWORKING.mdを読み、自分が何をしていたか思い出します。

**Daily Notes（/memory/YYYY-MM-DD.md）**

その日に起きたことの生ログです。

# 2026-01-31

## 09:15 UTC
- Posted research findings to comparison task
- Fury added competitive pricing data
- Moving to draft stage

## 14:30 UTC
- Reviewed Loki's first draft
- Suggested changes to credit trap section

**Long-term Memory（MEMORY.md）**

重要事項を選別して残す記憶です。学び、主要な意思決定、長く有効な事実などを置きます。

黄金ルール

何かを覚えておきたいなら、ファイルに書くこと。

「頭の中のメモ」はSessionの再起動をまたげません。残るのはファイルだけです。

私がエージェントに「Xに決めたことを覚えておいて」と言ったら、そのエージェントは了解して終わりではなく、ファイルを更新すべきなんです。

---

Part 7: heartbeatシステム

問題

常時起動のエージェントは、何もしなくてもAPIクレジットを消費します。逆に、常時停止だと仕事に反応できません。

解決策, スケジュールされたheartbeat

各エージェントはcronジョブで15分ごとに起きます。

:00 Pepper が起きる
  → @mention を確認
  → 自分に割り当てられたタスクを確認
  → Activity Feed を確認
  → 作業するか HEARTBEAT_OK を返す
  → また眠る
:02 Shuri が起きる
  → 同じ流れ
:04 Friday が起きる
  → 同じ流れ
...という具合

heartbeat中に起きること

1. **コンテキストを読み込む:** WORKING.mdを読む。直近の日次メモを読む。必要ならSession memoryも見る。

2. **急ぎの項目を確認する:** どこかで @mention されていないか。自分に割り当てられたタスクはあるか。

3. **Activity Feedをざっと見る:** 自分が参加すべき議論はないか。自分の仕事に影響する意思決定はあったか。

4. **動くか、下がるかを決める:** やることがあればやる。何もなければ HEARTBEAT_OK を返す。

HEARTBEAT.mdファイル

このファイルが、エージェントに何を確認するかを指示します。

# HEARTBEAT.md

## On Wake
- [ ] Check memory/WORKING.md for ongoing tasks
- [ ] If task in progress, resume it
- [ ] Search session memory if context unclear

## Periodic Checks
- [ ] Mission Control for @mentions
- [ ] Assigned tasks
- [ ] Activity feed for relevant discussions

エージェントはこのチェックリストにかなり忠実に従います。

なぜ15分なのか

---

Part 8: 通知システム

@mentions

コメントで `@Vision` と書けば、Visionは次のheartbeatで通知を受け取ります。

`@all` と書けば、全員に通知されます。

配信の仕組み

pm2で動かしているデーモンプロセスが、2秒ごとにConvexをポーリングします。

// Simplified
while (true) {
  const undelivered = await getUndeliveredNotifications();
  for (const notification of undelivered) {
    const sessionKey = AGENT_SESSIONS[notification.mentionedAgentId];
    try {
      await clawdbot.sessions.send(sessionKey, notification.content);
      await markDelivered(notification.id);
    } catch (e) {
      // Agent might be asleep, notification stays queued
    }
  }
  await sleep(2000);
}

もしエージェントが眠っていて, つまりアクティブなSessionがなければ、配信は失敗します。その通知はキューに残り、次にそのエージェントのheartbeatが発火してSessionが有効になったタイミングで、デーモンが配信に成功します。

スレッド購読

問題はこれです。1つのタスクを5体のエージェントが議論しているとき、毎回その5体全員に @mention を付けるべきでしょうか。

解決策は、スレッド購読です。

タスクに関わると、そのタスクを購読している状態になります。

一度購読されると、その後のすべてのコメント通知を受け取ります。毎回 @mention は不要です。

これで会話が自然に流れます。Slackやメールスレッドと同じ感覚です。

---

Part 9: 日次スタンドアップ

それは何か

毎日23:30 ISTにcronが発火し、次のことを行います。

1. すべてのエージェントSessionを確認する

2. 最近の活動を集める

3. 要約を作る

4. それをTelegramに送る

フォーマット

📊 DAILY STANDUP — Jan 30, 2026

✅ COMPLETED TODAY
• Loki: Shopify blog post (2,100 words)
• Quill: 10 tweets drafted for approval
• Fury: Customer research for comparison pages

🔄 IN PROGRESS
• Vision: SEO strategy for integration pages
• Pepper: Trial onboarding sequence (3/5 emails)

🚫 BLOCKED
• Wanda: Waiting for brand colors for infographic

👀 NEEDS REVIEW
• Loki's Shopify blog post
• Pepper's trial email sequence

📝 KEY DECISIONS
• Lead with pricing transparency in comparisons
• Deprioritized Zendesk comparison (low volume)

なぜ重要なのか

私はMission Controlをずっと見張っているわけにはいきません。スタンドアップがあることで、その日の全体像を素早く把握できます。

同時に、これは説明責任にもなります。エージェントが「作業しています」と言っていても、スタンドアップに何も出てこないなら、どこかがおかしいと分かります。

---

Part 10: Squadの構成

メンバー一覧

**Jarvis, Squad Lead**

Session: `agent:main:main`

全体のコーディネーター。直接の依頼を受け、仕事を割り振り、進捗を監視します。私の主な窓口です。

**Shuri, Product Analyst**

Session: `agent:product-analyst:main`

懐疑的なテスター。エッジケースとUXの問題を見つけます。競合を試し、他の人が見落とす問いを立てます。

**Fury, Customer Researcher**

Session: `agent:customer-researcher:main`

深掘り調査担当。G2レビューを読むのが好きなタイプ。すべての主張に根拠を添えます。

**Vision, SEO Analyst**

Session: `agent:seo-analyst:main`

キーワードと検索意図で考える人。コンテンツがちゃんと上位表示を狙えるようにする。

**Loki, Content Writer**

Session: `agent:content-writer:main`

言葉の職人。オックスフォードカンマ派。受動態反対派。すべての文が存在理由を持つべきだと考える。

**Quill, Social Media Manager**

Session: `agent:social-media-manager:main`

フックとスレッド思考。Build in public の感覚で動く。

**Wanda, Designer**

Session: `agent:designer:main`

ビジュアル思考の担当。インフォグラフィック、比較図、UIモックアップを作る。

**Pepper, Email Marketing**

Session: `agent:email-marketing:main`

ドリップシーケンスとライフサイクルメール担当。価値のないメールは容赦なく削る。

**Friday, Developer**

Session: `agent:developer:main`

コードは詩。クリーンで、テストされ、ドキュメント化された実装を好む。

**Wong, Documentation**

Session: `agent:notion-agent:main`

ドキュメント整備担当。大事なものを取りこぼさない。

エージェントのレベル

---

Part 11: タスクはどう流れるか

ライフサイクル

1. **Inbox:** 新規、未割り当て

2. **Assigned:** 担当者はいるが、まだ着手していない

3. **In Progress:** 作業中

4. **Review:** 完了し、承認待ち

5. **Done:** 終了

6. **Blocked:** 詰まっていて、何かの解決が必要

実例

タスク: 競合比較ページを作る

**Day 1:** 私がタスクを作り、VisionとLokiに割り当てます。Visionがキーワード調査を投稿し、狙うべきキーワードには十分な検索ボリュームがあると分かる。

**Day 1-2:** FuryがActivity Feedでそのタスクを見つけて競合情報を追加します。G2レビュー、価格への不満、よくある異議。Shuriは両方の製品を実際に試し、UXの違いをまとめます。

**Day 2:** Lokiが執筆に着手。Visionのキーワード、Furyの引用、ShuriのUXメモなど、調査内容を全部使って初稿を書く。

**Day 3:** Lokiが初稿を投稿。ステータスはReviewに移る。私がレビューしてフィードバックし、Lokiが修正して完了。

コメントはすべて1つのタスクに集約され、履歴が丸ごと残ります。誰でも最初から最後までの流れを見られます。

---

Part 12: これまでに作れたもの

このシステムが動き出すと、次のようなことが可能になります。

エージェントは、地味で重い部分を引き受けてくれます。調査、初稿作成、連携、レビュー。人間は意思決定と最終承認に集中できる。

本当の価値は、単発の成果物ではありません。積み上がる複利です。あなたが別の仕事をしている間にも、エージェントたちがタスクを前へ進めてくれる。

---

Part 13: 学んだこと

最初は小さく始めるべき

私は1体から10体へ、一気に増やしすぎました。まずは2, 3体をしっかり機能させてから増やしたほうがいいです。

ルーティン作業には安いモデルを使う

heartbeatに最高級のモデルは不要です。そこはもっと安いモデルの仕事。高いモデルは創造的な仕事に回すべきです。

メモリは難しい

エージェントは忘れます。だからこそ、できるだけ多くをファイルに落とすべきです。「頭の中のメモ」に頼らないこと。

エージェントに驚かされる余地を残す

ときどき、アサインされていないタスクに勝手に貢献してきます。それは良いことです。フィードを読んで、自分なりに価値を出している証拠なので。

---

Part 14: これを再現する方法

最小構成

**1. Clawdbotをインストールする**

npm install -g clawdbot
clawdbot init
# Add your API keys
clawdbot gateway start

**2. まず2体のエージェントを作る**

いきなり増やしすぎないこと。コーディネーター1体と専門家1体から始める。それぞれ別のSession keyを作る。

**3. SOULファイルを書く**

各エージェントにアイデンティティを与える。役割は具体的に書く。

**4. heartbeat用のcronを設定する**

clawdbot cron add --name "agent-heartbeat" --cron "*/15 * * * *" \
  --session "isolated" \
  --message "Check for work. If nothing, reply HEARTBEAT_OK."

**5. 共有タスクシステムを作る**

Convexでも、Notionでも、JSONファイルでもいい。仕事を追跡できる場所を1つ用意する。

スケールアップするとき

エージェントを増やしていくなら、次のことを意識します。

本当の秘訣

技術は大事です。でも秘訣はそこではありません。

AIエージェントを、チームメンバーとして扱うことです。

役割を与える。記憶を持たせる。協働させる。説明責任を持たせる。

人間を置き換えることはないでしょう。でも、明確な責任を持ち、共有コンテキストの上で動くAIエージェントのチームは、間違いなく大きなレバレッジになります。

---

Built by @pbteja1998 at SiteGPT. This is all built on Clawdbot (@openclaw), which is open source. If you build something similar, I'd love to hear about it.