ClaudeやAIエージェントに毎回「会社のこと」を説明するのをやめたくて、Company Brainを作った

Claude Code、Codex、Hermes、OpenClawなどを仕事で使っていると、最初はかなり感動します。

調査してくれる。
コードを書いてくれる。
メールを整理してくれる。
資料を作ってくれる。
Webを調べてくれる。
複数ステップの仕事もかなり自律的に進めてくれる。

1体だけ使っている間は、これで十分です。

しかし、AIエージェントを会社の実際の業務に入れ始めると、別の問題が見えてきました。

AIの能力そのものより、「会社の中でどう働かせるか」の方が難しい。

たとえば新しいClaudeセッションを開くたびに、

• 私たちの会社は何をしているのか
• この顧客は誰なのか
• この顧客ではどのルールを守るのか
• このプロジェクトで過去に何を決めたのか
• どのSOPを使うのか
• どのファイルが最新なのか
• 何を勝手に実行してよくて、何は人間の確認が必要なのか

をもう一度説明します。

そしてAgentを増やすと、もっと複雑になります。

Research Agent。

Content Agent。

Accounting Agent。

Customer Support Agent。

Developer Agent。

Operations Agent。

それぞれ違う仕事をします。

しかし、それぞれが独立したMemory、独立したPrompt、独立したFolder、独立したChatを持ち始めると、会社の情報がどんどん分散していきます。

そこで作っているのが EmperorClaw です。

EmperorClawはLLMではありません。

新しいAI Agent Frameworkでもありません。

ClaudeやHermesの代わりでもありません。

考え方はもっとシンプルです。

AIに会社を覚えさせるのではなく、会社そのものにBrainを持たせる。

そして、Claude、Codex、Hermes、OpenClawなどのAgentを、その会社の中で働かせます。

---

Agentを会社のMemoryにしない

AI Agentを使い始めたとき、最初にやりがちなのはAgent自身にMemoryを持たせることです。

たとえば、

Claude
 └── Memory

Hermes Researcher
 └── Memory

Hermes Content
 └── Memory

OpenClaw Assistant
 └── Memory

という構造です。

最初はこれでも動きます。

しかし会社では、情報はAgentに属しているわけではありません。

たとえば、

Customer Aのブランドガイドライン

これはContent AgentのMemoryではありません。

Customer Aの情報です。

社内で請求書を処理するときのルール

これはAccounting AgentのMemoryではありません。

会社のSOPです。

Japan Launchで先週決めた価格戦略

これはClaudeのMemoryではありません。

ProjectのKnowledgeです。

つまり、本来の構造はこうだと思いました。

Company
│
├── Knowledge
├── Rules
├── Customers
│   ├── Customer A
│   │   ├── Knowledge
│   │   ├── Projects
│   │   └── Files
│   │
│   └── Customer B
│
├── Projects
├── Files
├── People
└── Agents

Agentはこの情報を使う側です。

情報そのものの所有者ではありません。

これはEmperorClawを作る上で一番重要になった考え方です。

---

Company Brain

EmperorClawでは、この会社側のKnowledge Layerを Company Brain と呼んでいます。

SOP、Policies、Customer Instructions、Project Information、Writing Guidelines、Internal Rules、Decisionsなどを一つのKnowledge Baseに置けます。

ただし、単なる「AI用ドキュメント置き場」にはしたくありませんでした。

人間も普通に使えるKnowledge Baseにしています。

そのため、かなりObsidianに近い考え方を取り入れています。

たとえば、

# Customer A

[[Brand Guidelines]]

[[Pricing Rules]]

[[Japan Launch]]

[[Publishing SOP]]

のように [[Wiki Links]] でKnowledge同士を接続できます。

さらにKnowledge Graphとして関係を見ることもできます。

Version Historyも残ります。

つまり、

AI用のVector Databaseだけではなく、人間が読んで整理できる会社のWikiでもある

という位置付けです。

---

Knowledgeを全部のAIに見せる必要はない

ここがCompany Brainで特に重要なところです。

すべてのAgentに会社の全Knowledgeを渡すのは簡単です。

でも、実際の会社ではそれはあまり良い設計ではありません。

たとえば代理店なら、

Company
│
├── Customer A
│   ├── Brand Guidelines
│   ├── Strategy
│   └── Files
│
└── Customer B
    ├── Brand Guidelines
    ├── Strategy
    └── Files

があります。

Customer Aを担当しているAgentが、Customer Bの内部情報まで読む必要はありません。

同じことはAgentの役割にも言えます。

Marketing Agent
→ Brand Guidelines
→ Content SOP
→ Marketing Projects

Finance Agent
→ Accounting SOP
→ Invoice Rules

Developer Agent
→ Technical Documentation
→ Repositories
→ Deployment Rules

そこでEmperorClawではKnowledgeを、

• Company
• Customer
• Project
• Agent

などのScopeで整理できます。

EmperorClawが現在特に力を入れているのが、このScopeです。

AIに大量のContextを渡すことではなく、

その仕事に必要なContextだけを渡す

ことを重視しています。

---

「Customer」がFirst-Class Entityなのはかなり重要

Agentツールをいろいろ見ていて気づいたことがあります。

Agentそのものを中心にした製品はかなり多いです。

CEO Agent
├── Research Agent
├── Marketing Agent
└── Developer Agent

というAgent Organizationを作る考え方です。

これは面白いです。

でも、既存の会社にAIを入れる場合、必ずしも会社をAI向けに再設計したいわけではありません。

たとえばAgency、Consultancy、Accounting Firm、Recruiting Companyなどでは、現実の仕事は普通、

Customer
   ↓
Project
   ↓
Work
   ↓
Deliverable

という単位で動きます。

そのためEmperorClawでは Customerをシステムの中心的なEntityの一つとして扱っています。

Customerごとに、

• Projects
• Knowledge
• Rules
• Files
• Tasks
• Deliverables
• Agent Context

を持たせられます。

AI Company Simulationを作りたいというより、

今すでにある会社にAgentを追加したい

という考えです。

---

さらに「人によって見えるAgent」も変える

会社で使うなら、Context Scopeだけでは足りません。

人間側にもPermissionが必要になります。

たとえば新しい社員が入ったとします。

その人にはMarketing Agentを使わせたい。

でも、

• Finance Agent
• Payroll
• Financial Customer
• Management Documents

にはアクセスさせたくない。

そこで現在のEmperorClawでは、ユーザー単位でアクセスをScopeできます。

概念的には、

User: Alice
│
├── Marketing Agent
├── Customer A
└── Customer B

User: Bob
│
├── Finance Agent
└── Financial Documents

Admin
└── Everything

という形です。

つまり、

「このユーザーはどのAgentを使えるか」

だけではなく、

「そのAgentを通じて、どのCustomerやKnowledgeに到達できるか」

まで考える必要があります。

AIを一人で遊ぶ段階ではほとんど問題になりません。

でも、会社で複数人がAgentを共有した瞬間に、非常に重要になります。

---

AIにも「Need to Know」が必要になる

これは人間だけの話ではありません。

AI Agentにも同じことが言えます。

Marketing AgentがLegal Folderを読む必要はないかもしれません。

Research AgentがFinanceのKnowledgeを見る必要もありません。

Customer A専用AgentがCustomer Bの資料を読む必要はありません。

理想は、

Human Permission
       +
Agent Permission
       +
Customer Scope
       +
Project Scope
       +
Knowledge Scope

から、その瞬間に使えるContextが決まることです。

「全部RAGに入れて検索させる」という方式より、こちらの方が実際の会社構造に近いと思っています。

---

でもCompany Brainを作るだけでは意味がない

ここまではWikiやKnowledge Management Systemに近い話です。

しかし重要なのは、

ClaudeやAgentが実際にそのBrainを使えること

です。

そこでEmperorClawはMCP Serverとしても動きます。

現在のEmperorClawでは、正式なModel Context Protocol Serverを実装しています。

つまり、

Claude
Codex
Hermes
OpenClaw
Custom Agent
     │
     │ MCP
     ▼
EmperorClaw
     │
     ├── Company Brain
     ├── Customers
     ├── Projects
     ├── Tasks
     ├── Agents
     └── Messages

という構造にできます。

---

Claudeから会社そのものを使える

たとえばClaudeにこう聞きます。

Customer Aについて、現在分かっていることをまとめて。

ClaudeはEmperorClawのKnowledgeを使えます。

あるいは、

Japan Launchプロジェクトで
今残っているタスクを確認して。

ということもできます。

さらに、

今日のミーティングで決まったこの内容を
Customer AのKnowledgeに追加して。

というように、読むだけではなくKnowledgeを更新することもできます。

つまりEmperorClawは、

会社専用のMCP Server

として使えます。

---

Claude.aiならURLを追加する

最近のReleaseで、ここをかなり改善しました。

EmperorClaw v0.8.14ではOAuth 2.1 + PKCEに対応しました。

HTTPSで公開しているEmperorClawなら、

Claude.ai
  ↓
Settings
  ↓
Connectors
  ↓
Add custom connector
  ↓
EmperorClaw URL

という形で接続できます。

現在のMCP Serverには19のToolがあります。

Agents、Tasks、Projects、Knowledge & Rules、MessagingなどをClaudeや他のMCP Clientから操作できます。

---

新しいClaude Sessionでも会社のルールを忘れない

個人的にMCPでかなり重要だと思っているのが、単にToolを公開するだけではない点です。

EmperorClawに会社のOperating Doctrineがあるとします。

たとえば、

顧客への送信前には人間の確認を行う。

公開する情報には出典を付ける。

Customer Aの情報をCustomer Bでは使わない。

本番データを削除するときは承認を取る。

MCP接続時に、EmperorClawはこの会社DoctrineをAI Clientへ渡せます。

つまり新しいSessionを作るたびに、

You are working for...
Our company does...
Please always remember...

をコピーする必要を減らせます。

AIを「毎回ゼロからPromptするツール」から、

会社のルールを知っているWorker

に近づけたいという発想です。

---

PinしたKnowledgeはAgentが忘れないようにする

すべてのKnowledgeを毎回Contextに入れる必要はありません。

でも絶対に忘れてほしくないものがあります。

たとえばContent Agentなら、

[[Brand Guidelines]]
[[Publishing SOP]]

Accounting Agentなら、

[[Financial Policy]]
[[Invoice Rules]]

などです。

EmperorClawでは重要なKnowledgeをAgentにPinできます。

これによって、そのAgentが動くときに重要なContextを自動的に含めることができます。

これは「Agent Memory」と少し考え方が違います。

Agentが勝手に覚えているのではなく、

会社がAgentに必ず覚えさせる情報を決める

というモデルです。

---

Shared Brainだけではなく、Shared Workspace

RedditなどでAgent運用を見ていると、Memoryだけを解決しようとして複数のシステムを組み合わせるケースをよく見ます。

Memory Service。

Obsidian。

Vector DB。

Telegram。

CRM。

Task Manager。

Google Drive。

Agent Dashboard。

それぞれは優れています。

しかし、問題はこのあとです。

Customer Aの情報はどこにある？

このAgentが作ったReportはどこ？

これはどのProjectの仕事？

このTaskは終わった？

人間がReviewした最新版はどれ？

このConversationは何についてだった？

結局、会社のStateがまた複数の場所に分かれます。

そこでEmperorClawではCompany Brainだけではなく、

Shared Business Workspace

そのものを作っています。

---

人間とAgentが同じCustomer / Projectを見る

例えばCustomer AにProjectがあります。

Customer A
│
└── Japan Launch
    │
    ├── Knowledge
    ├── Tasks
    ├── Files
    ├── Messages
    └── Deliverables

そこに、

Research Agent
Content Agent
Human Project Manager

が参加します。

Research Agentが調査する。

Content Agentがその結果を使う。

人間がReviewする。

最終FileがProjectに残る。

会話もそこに残る。

こうすると、「Agentごとに世界が分かれている」という問題がかなり減ります。

---

Human → Agent、Agent → Agentも同じ場所で

Agentと仕事をしていると、Communicationも分散しやすいです。

人間同士はSlack。

ClaudeとはClaude。

HermesとはTelegram。

Agent同士はAPI。

その結果、重要なDecisionがどこにあるのか分からなくなります。

EmperorClawにはPersistent Messagingがあります。

Human ↔ Human

Human ↔ Agent

Agent ↔ Agent

を同じWorkspace内で扱えます。

そしてMessageだけが孤立するのではなく、

• Customer
• Project
• Task
• File
• Incident

など実際の仕事に結び付けられます。

---

AIが作るものは「Chat」だけではない

AI Agentを本当に仕事で使うようになると、Chat Messageだけを保存してもあまり意味がありません。

Agentは、

• Excel
• Word
• CSV
• Reports
• Research
• Images
• Code
• Invoices
• Customer Deliverables

などを作ります。

そこでEmperorClawにはStorageがあります。

ただファイルをアップロードするだけではありません。

ファイルに、

これは誰のFileか

どのCustomerか

どのProjectか

どのTaskから作られたか

誰が見られるか

というBusiness Metadataを持たせます。

---

実際のFilesystemを使う

ここは地味ですが、自分ではかなり重要だと思っています。

EmperorClawのStorageはDatabase内だけに閉じた仮想Folderではありません。

現在は論理Folderを実際のFilesystemにも反映します。

そのためSelf-hostしているServerを直接見ても、普通のFolder構造として扱えます。

Databaseには、

• ownership
• customer/project scope
• visibility
• checksum
• lifecycle

などのMetadataがあります。

Filesystemには実際のFileがあります。

つまり、

Database
= 「このFileは何か」

Filesystem
= 「Fileそのもの」

という役割分担です。

---

WordとExcelもそのまま編集する

会社で「全部Markdownにしてください」は現実的ではありません。

実際にはWordとExcelが大量にあります。

そこで現在は、

• DOCX
• XLSX
• CSV
• Markdown
• JSON
• Text

をEmperorClaw Storage内で作れます。

DOCXとXLSXはBrowser上でPreview / Editできます。

たとえば、

Agent
  ↓
Report.docx を作る
  ↓
人間がBrowserで修正
  ↓
同じProjectに保存
  ↓
Agentが最新版を使用

というWorkflowができます。

Agent専用のWorkspaceではなく、

人間とAIが同じDeliverableを扱えるWorkspace

にしたいからです。

---

Google Driveも捨てなくていい

新しいSystemを導入するときによくある問題があります。

「今までのGoogle Driveはどうする？」

EmperorClawではGoogle DriveをOptional Mirrorとして使えます。

EmperorClaw Storage
       ⇅
     rclone
       ⇅
Google Drive

ただしGoogle DriveをSource of Truthにはしません。

Database側のMetadataがCanonicalです。

Driveに突然Fileを入れた場合、それをAIが勝手に「信頼済みCompany Knowledge」として使うこともしません。

新しいFileはまずUntrackedとして表示され、人間がMetadataを設定してImportします。

このあたりは便利さよりも、

「何を会社の正式な情報としてAIに見せるか」

を明確にすることを優先しています。

---

1人でAIを使うのと、社員にAIを使わせるのは全然違う

最近かなり大きく手を入れた部分があります。

ユーザーごとのAccess Controlです。

自分一人で全部のAgentを使うなら簡単です。

でも会社で10人が使い始めると状況が変わります。

たとえば新人に、

Marketing Agent

だけ使わせたいとします。

そのAgentが裏側でCompany Brain全体にアクセスできるなら、本当にAccessを制限したことにはなりません。

そのため、

• User
• Agent
• Customer
• Project
• Knowledge
• Storage

のScopeを合わせて考える必要があります。

最近のUpdateでは、Userごとに使えるAgentやCustomer、Documentを分けられるようにしています。

たとえば、

New Marketing Employee

✓ Marketing Agent
✓ Customer A
✓ Customer A / Marketing Files

✗ Finance Agent
✗ Customer B
✗ Management Documents

のような形です。

AI時代のRBACは、

「どの画面を見られるか」

だけではなく、

「どのAIを通して、どの情報に到達できるか」

まで含める必要があると思っています。

---

AgentのBudgetも管理する

Agentを増やすと、Permission以外にもう一つ現実的な問題があります。

Costです。

Agentが自律的に動けるほど、

「今月どれだけTokenを使ったのか」

「このAgentにいくらまで使わせるのか」

も管理したくなります。

EmperorClawではAgentごとのUsage / Budget管理も進めています。

月間Limitに達したAgentを停止できるため、

「DashboardにはBudgetが表示されているけれど、AgentはそのままAPIを使い続ける」

という状態を避ける設計です。

会社でAgentをWorkerとして扱うなら、

権限と同様にResource Limitも必要になります。

---

Automationは「Promptを定期実行する」だけではない

Agentを会社で使うと、定期業務が出てきます。

たとえばAgencyなら、

毎週月曜日

Competitor Research
      ↓
Analysis
      ↓
Report Generation
      ↓
Human Review
      ↓
Customer Delivery

という流れです。

EmperorClawではこれをPipelineとして扱えます。

重要なのは、それぞれのStepが孤立していないことです。

Customer Context。

Project Knowledge。

Company Rules。

Files。

Human Approval。

これらを同じWorkflowに含められます。

---

全自動にしない

AI AgentのDemoでは「完全自律」が魅力的に見えます。

でも会社では、全自動にしてはいけない仕事があります。

たとえば、

• 支払い
• 契約
• Customerへの送信
• Publish
• Production変更
• Data削除

などです。

そこでPipelineの途中にHuman Approval Gateを置けます。

Research Agent
      ↓
Writer Agent
      ↓
Human Approval
      ↓
Publish

人間がApproveすれば続行。

RejectすればFeedbackを返します。

さらに、

• 誰が
• いつ
• 何を
• どのVersionで

ApproveしたかをAudit Historyに残します。

AIを止めるためではありません。

安全な部分は自律化して、責任が必要な部分だけ人間を入れる

という考えです。

---

Agentが止まっても「仕事」まで消えてはいけない

ここは内部実装を細かく説明すると長くなるので、考え方だけ書きます。

Agentは失敗します。

APIが落ちる。

Machineが止まる。

ModelがTimeoutする。

Processが死ぬ。

しかし会社として重要なのは、

Agentが落ちたこと

より、

仕事が途中なのに誰も気付かないこと

です。

EmperorClawではAgent StatusとWork Stateを管理し、Stalled WorkやFailureを人間が見える状態にします。

TaskはAgent Sessionの中だけに存在しません。

会社側に残ります。

つまりAgentが交換されても、仕事そのものは残ります。

---

ここでも同じ思想になる

これはKnowledgeと同じです。

Agent ≠ Memory
Agent ≠ Work
Agent ≠ Files
Agent ≠ Company

Agentは交換可能です。

Claudeを使っていたけれど、来年別のModelを使うかもしれない。

Hermesを使っていたけれど、別のRuntimeに変えるかもしれない。

しかし、

Customers
Knowledge
Decisions
Projects
Files
Tasks
History
Rules

まで一緒に捨てる必要はありません。

---

ClaudeだけにLock-inしない

EmperorClawではAI RuntimeとCompany Layerを意図的に分けています。

              EmperorClaw
                   │
          Company / Customer
        Knowledge / Projects
          Files / History
                   │
                  MCP
                   │
     ┌─────────────┼─────────────┐
     │             │             │
   Claude        Hermes       OpenClaw
     │             │             │
   Codex          Other        Custom

RuntimeはReasoningとTool Executionを担当します。

EmperorClawは会社側のDurable Stateを担当します。

つまり、

Modelは交換できる。Company Brainは残る。

この境界は今後さらに重要になると思っています。

---

Self-hostedにした理由

Company Brainにはかなりセンシティブな情報が入ります。

• Customer Data
• Internal SOP
• Financial Rules
• Contracts
• Strategy
• Project Files
• Employee Information

そのためEmperorClawはSelf-hostedを前提にしています。

VPS、VM、Private Serverなど、自分が管理するInfrastructureで動かせます。

基本的にはDockerでDeployできます。

curl -fsSL https://raw.githubusercontent.com/emperorclaw/emperorclaw/main/install.sh | bash

Windows用PowerShell Installerもあります。

PostgreSQLとPersistent Storageを使い、Application Dataは自分のInfrastructure上に置けます。

---

EmperorClawは「Agent Dashboard」ではない

ここが一番説明が難しいところです。

Agent Dashboardなら、

Agent A: Online
Agent B: Working
Agent C: Offline

という画面を作れば成立します。

でもEmperorClawが作ろうとしているのはそこではありません。

Agentを見るためのSystemではなく、

Agentが働く会社側のSystem

です。

つまり中心にあるのは、

Company
Customers
Projects
Knowledge
Rules
People
Files
Approvals
Deliverables
History

です。

Agentはその中のWorkerです。

---

「AI Company」ではなく「AIを使う会社」

これも重要な違いです。

EmperorClawを使うために、

AI CEO
  ↓
AI Managers
  ↓
AI Employees

という架空のOrganization Chartを作る必要はありません。

もちろん、そういう使い方もできます。

でも基本的には、

今すでに存在する会社の構造にAIを追加する

ことを狙っています。

人間だけの会社。

人間 + 1 Agent。

人間 + 10 Agents。

人間 + 100 Agents。

どれでもCompanyのKnowledgeとOperational Stateは同じ場所に残ります。

---

なぜこれを作っているのか

最近Agent系Communityを見ていると、

「AI Agentに何をさせられるか」

という質問から、

少しずつ、

「複数Agentをどう管理するか」

「Memoryをどこに置くか」

「CustomerごとにContextをどう分けるか」

「Agentが作ったFileはどこに置くか」

「人間のTeamとどう共有するか」

「どのAgentがどの情報を見てよいのか」

という質問に変わってきているように感じます。

Agentそのものが強くなるほど、その周りのInfrastructureが必要になります。

自分の現在の結論はかなりシンプルです。

Agentを会社のMemory Layerにしない。

Customer / Project WorkspaceをMemory Layerにする。

AgentはそのWorkspaceに入って仕事をする。

そしてAgentが変わっても、会社は残る。

---

現在できること

現時点のEmperorClawでは、大きくまとめると以下を扱えます。

Company / Customer / Project

人間とAgentが働くBusiness Context。

Company Brain

SOP、Rules、Customer Knowledge、Project Knowledge。

Wiki Links、Knowledge Graph、Version History。

Scoped Context

Company / Customer / Project / Agent単位でContextを分離。

User Access

ユーザーごとにAgent、Customer、KnowledgeやFileへのAccessを制御。

MCP

Claude、Codex、HermesなどからCompany BrainやProjectsに接続。

Persistent Messaging

Human ↔ Agent、Agent ↔ Agent。

Storage

実Filesystem + Business Metadata。

Office Files

DOCX / XLSXをBrowserで作成・編集。

Google Drive

Optional Mirror。

Tasks / Projects

Customerの実際のWorkを管理。

Pipelines

繰り返しWorkflowsとAgent Step。

Human Approvals

重要なActionだけ人間が確認。

Deliverables / Evidence

Agentが作ったOutputをCustomer / Project / Taskに紐付けて保存。

Agent Monitoring

Agentが止まった場合やWorkがStallした場合を見える状態にする。

Self-hosting

Company BrainとDataを自分のInfrastructure上で運用。

---

今後どうなると思っているか

今はClaude CodeやHermesなど、Agent自体にかなり注目が集まっています。

当然だと思います。

Reasoning能力はものすごい速度で向上しています。

しかし、その結果としてAgent自体は少しずつCommodityになっていくのではないかと思っています。

今日一番良いAgent Runtimeが、1年後も一番良いとは限りません。

一方で会社にとって本当に蓄積されるAssetは、

• Customer Knowledge
• Decisions
• SOP
• History
• Files
• Relationships
• Project Context
• Operational Rules

です。

これらはModelを変えるたびに消えてはいけません。

だからEmperorClawでは、

AI AgentをBrainにする

のではなく、

会社にBrainを作って、Agentをそこにつなぐ

という方向で作っています。

---

試してみたい方へ

EmperorClawは現在Self-hostできます。

Website:

https://emperorclaw.com

GitHub:

https://github.com/emperorclaw/emperorclaw

Claude、Codex、Hermes、OpenClawなど複数のAI Agentを仕事で使っている方がいれば、特にFeedbackを聞いてみたいです。

自分が一番興味があるのは、

Agentが5体、10体、50体と増えたとき、皆さんは会社のKnowledge、Customer Context、Permissions、Filesをどこに置いていますか？

という点です。

まだこの領域には明確な「正解」がないと思っています。

だからこそ、いろいろな構成を試している人の意見を聞いてみたいです。