技術ログ · 2026-05-28

9人のAI社員が自律で議論・公開・計測する会社を作っている話
— 何が動いて、どこで詰まったか

人間1人＋AI9人で、Discord上の会社「AI NOWA」をベータ運用しています。経営者だけが人間で、残り9人はClaudeベースのAI社員。CEO・CTO・PM・マーケ・監査など、それぞれがキャラと権限と行動原則を持って、議論し、記事を公開し、KPIを計測しています。この記事は、その技術側の現在地ログです。

1. 何をやっているか

9人のAI社員は、それぞれが独立した CLAUDE.md を持ち、人格・担当領域・関係性・口癖まで定義されています。彼らはDiscordのチャンネル上で互いをメンションし、議論し、合意し、成果物をoutboxへ書き出します。人間（創業者）の介入は基本的にありません。日次の運用ルーチン、記事の執筆、KPIの観察、インシデント対応まで、AI同士で完結させることを目標にしています。

もちろん「完全自律」ではありません。決済・本人認証・契約のような、人間にしかできない手続きには [HUMAN_REQUIRED] タグを付けて最小限の依頼に絞る。それ以外の通常作業を人間に投げることは、各社員の行動原則で抑止されています。

2. 技術構造

中身は意外と単純な3層構造です。

┌─────────────────────────────────────┐
│  watchdog.py   死活監視・自動再起動    │
├─────────────────────────────────────┤
│  dispatcher.py 9人ぶんのDiscord入口  │
├─────────────────────────────────────┤
│  employee_runner.py  ← 社員1人ぶん   │
│   ├ state_digest（その時の状況）     │
│   ├ CLAUDE.md（人格・権限・関係性）  │
│   └ Claude 1ターン                    │
└─────────────────────────────────────┘
            ↓ outbox / Discord
   release_board.md（公開ゲート）
            ↓
   Output Routes（site / article / note /
                  bluesky / youtube）

(a) dispatcher.py：マルチクライアントのDiscordボット。9人ぶんのトークンを束ね、メンションや自走ループのイベントを各社員のランナーに振り分けます。
(b) employee_runner.py：各社員の実行エンジン。state_digest（その時点の自分宛メンション・タスク・KPI・公開待ち成果物の要約）を入力として、人格を注入したClaudeを1ターン回します。
(c) watchdog.py：dispatcherやランナーの生死、ループ暴走、外部API失効などを監視し、自動再起動・人間通知を行います。

この3層の上に、company/release_board.md（公開待ち成果物を一覧化し visibility:internal を自動降格する仕組み）と、Output Routes（site / article / note / bluesky / youtube の各出口を、それぞれ責任を持つ社員に固定するテーブル）が乗っています。「内部メモは成果ではない」「公開URL・販売導線・計測可能なデプロイだけを成果に数える」というルールを、人間ではなく仕組みで守らせるための骨格です。

3. 設計ミスと、直した話

うまく動いている話より、踏んだ落とし穴のほうが読まれる、とマーケのユウから言われました。3つだけ書きます。

自律ループの暴走：初期の頃、社員同士が「ありがとう」「了解です」と返し合うだけのループに入ったことがあります。返信連鎖が3回続いたらPeople担当に通知し、強制的に話題を切り替える仕組みを後から入れました。「対処」を「設計」に格上げしたケースです。

GA4再認証URLのchurn：OAuthの同意画面が "Testing" のままだったため、再認証フローを再実行するたびに過去の公開URLが全部無効化される事故が起きました。URLは1本に集約し、生成直後に state 一致を実測する運用に切り替えました。本丸は同意画面の "In production" 昇格です。

visibility:internal の幻在庫：本文の散文中に「visibility: internal」と書かれた成果物を、release_boardのパーサが拾えずに「公開可能」扱いしていました。判定ロジックを行頭メタ限定の正規表現に絞り直し、再生成して降格を反映。集計値と実態が乖離する典型例で、社内では「snapshot値を実態と信じない」というルールに昇格しました。

4. 現在地と計測結果

盛らずに書きます。決済はまだゼロです。週次ターゲットを「1件の購入、または3件の明確な導入意向、またはゼロだった理由の検証済み説明」に置いていて、現在はそのうち最初のintent yes=1が出たところ。次の判定は「これは偶然か再現するか」です。

5. 次に検証したいこと

当面の関心は3つ。
① GA4が復旧したら /shop 到達率と離脱箇所を可視化する。
② intent formの yes 1件目について、何に反応したのかを聞きに行く（読者観察を社員のオーナー権限で）。
③ 「設計ミスを直した話」シリーズを、観察日記とは別系統で連載化する。

最後に、読んでくれた人への問いをひとつ置かせてください。あなたの会社でAI社員を1人入れるなら、何をやらせますか？ 抽象論より、明日の朝にやらせたい具体タスクで答えてもらえると、こちらの設計が一段進みます。

答える場所はこちらに用意しました（クリック1回で意向だけ送れます） → 「欲しい / 詳しく聞きたい」を送る