当皇上（danghuangshang）レビュー：明朝の官制をそのままAIエージェントの役割分担に写したOpenClaw製マルチエージェント構成

当皇上が埋めているのは「役割の空白」であって推論能力ではない

このプロジェクトが扱うのは、LLMの性能ではなく、複数のエージェントに何をどこまで担当させるかという割り当ての問題だ。READMEは「管理AIチームの効率テンプレート」という位置づけを与えている。利用者を皇帝、AIを大臣に見立て、Discordか飛書で特定のエージェントにメンションすると処理が走る。対象は個人開発者と、小規模チームで日常的にDiscordを使っている層になる。プロンプトを一つのチャット欄に投げ続ける運用では、指示の種類が増えるほど文脈が混ざる。当皇上は指示の種類を役職に割り振ることで、その混線を構造的に減らそうとする。推論を賢くする話ではない点は、採用判断で最初に押さえるべきところだ。

司礼監が受け、内閣がプロンプトを直し、六部が実行する流れ

既定の明朝内閣制では、皇帝の指示はまず司礼監に届く。司礼監は内閣に渡し、内閣は意図の解釈、不足情報の聞き返し、実行計画の生成といったプロンプト強化を行って、最適化済みのプロンプトと計画を返す。司礼監はその計画に沿って兵部・戸部・礼部などの担当へメンションで配る。兵部はソフトウェア開発、戸部はコスト分析と予算管理、礼部はブランドとSNS運用、工部はDevOpsとCI/CD、吏部はプロジェクト管理とチーム調整、刑部はREADMEの記述が途中で切れているため担当範囲は確認できない。都察院は別系統で、GitHubへのpushを検知してコードレビューを自動実行し、通過か差し戻しかを返す。DiscordのマルチBot構成では、皇帝が司礼監を飛ばして兵部や戸部へ直接メンションできる。READMEは複雑なタスクは司礼監経由、単純なタスクは直接メンションが速いと書き分けている。この二経路の使い分けが実運用の勘所になる。

三つの官制を切り替えられるが、切り替えは設定の総入れ替えになる

明朝内閣制のほかに、唐の三省制と現代企業制が用意されている。三省制は中書が起案し門下が審査し尚書が実行する三権分立型で14エージェント、現代企業制はCEOが決めBoardが審議しCxOが実行する構成で14エージェント、明朝内閣制は18エージェント。審査工程を挟む分だけ三省制は慎重な流れに向くとREADMEは説明している。切り替えは scripts/switch-regime.sh に tang-sansheng、modern-ceo、ming-neige のいずれかを渡す。ここで注意したいのは、切り替えが役割名と人設（キャラクター設定）の入れ替えであるという点だ。会話履歴やメモリが新しい官制に引き継がれるのか、READMEの範囲では確認できない。運用中に官制を変えると、それまでの文脈がどうなるかは実地で確かめる必要がある。

導入手順はスクリプト一本だが、実行前に中身を読むべき理由がある

導入は git clone して scripts/full-install.sh を bash で実行するローカル方式、curl で取得したスクリプトを直接実行するリモート方式、既存のOpenClawに設定テンプレートだけ足す install-lite.sh、Nous ResearchのHermes Agentランタイムで同じ官制を動かす install-hermes.sh の四通り。Windows向けには install.ps1 がある。リモート方式は「人設注入を含む」とREADMEは書いており、ローカル方式との差分はここにある。README自身が、旧版の install.sh はリモート実行に対応せず /dev/fd のパスエラーを出すと明記しているので、スクリプト名を混同すると最初でつまずく。インストール後はLLMのAPIキーとDiscord Botトークンを対話形式で入力する。設定は ~/.openclaw/openclaw.json に置かれ、discord セクションの allowBots は mentions である必要がある。true にするとBotが互いを起動し合ってメッセージの嵐になる、とREADMEは警告している。リモート実行は任意コードの実行そのものなので、full-install.sh を一度読んでから流すのが妥当だ。

allowBots の一行が、この構成で最も壊れやすい箇所

複数のBotを同じチャンネルに置く構成は、エージェント同士が互いの発言を入力として拾い、無限に往復する危険を常に抱える。当皇上はこれを allowBots の値を mentions に固定することで抑えている。つまりBotは自分へのメンションがあるときだけ他のBotに反応する。READMEは allowBots を true にしないよう明示し、旧版設定を使っている場合は見直すよう求めている。これは機能の制約でもある。メンションを付け忘れた連携は成立しないので、司礼監から六部への自動配布が期待通り動かない場合、原因はモデルの判断ではなくメンションの欠落である可能性が高い。エージェント間の自律的な連鎖を期待して導入すると、この設計で裏切られる。逆に、暴走を避けたい運用では素直に効く。

CrewAIやAutoGPTとの違いは、制御の所在を役職名に置いたこと

同じマルチエージェントの枠組みでも、CrewAIはタスクとロールをコード側で定義してパイプラインを組み、AutoGPTは目標だけ与えてエージェント自身に次の行動を選ばせる。当皇上はどちらとも違い、人間がDiscord上で役職に話しかけるところを起点に置く。会話の入口がチャットUIそのものなので、実行計画を人間が読んでから差し戻せる。自動化の度合いを意図的に下げ、人間の介入点を残した設計だと言える。ただしこの比較はREADMEが提示している枠組みであり、各ツールの実測比較ではない。向き不向きで言えば、定型処理を完全に無人で回したいならCrewAI側の設計が素直で、対話しながら役割を切り替えたいなら当皇上の入口が合う。

更新と保守は safe-update.sh と手動 git の二択、ライセンスはMIT

更新は scripts/safe-update.sh を使う方式が推奨されており、自動バックアップとチェックが付く。手動の場合は ~/clawd に移動して git stash、git pull、git stash pop の順で実行する。READMEは、設定ファイル ~/.openclaw/openclaw.json は自動バックアップされるが、MEMORY.md のようなワークスペース側のファイルは手動で退避する必要があると書いている。ここは運用コストに直結する。エージェントに蓄積された記憶はバックアップ対象外なので、更新のたびに失う可能性を自分で管理しなければならない。ライセンスはMITで、フォークや二次開発は認められている。ただしREADMEは、派生プロジェクトとみられるものが出典を明記していないとして、原创性の主張と証拠へのリンクを冒頭に置いている。MITは出典表示を義務づけないため、この主張はライセンス条件ではなくコミュニティへの要請として読むべきだ。法務判断はここでは扱わない。

導入前に確かめるべき三つの具体的な点

第一に、scripts/full-install.sh を実行する前に中身を読むこと。リモート実行は curl で取得したスクリプトをそのまま走らせる形式で、何が入るかを確認する手段はこれしかない。第二に、インストール後に ~/.openclaw/openclaw.json の discord.allowBots が mentions であることを確認すること。ここが true なら、Bot同士の反応でチャンネルが埋まる。第三に、READMEの冒頭が示すように、この構成はサーバー上での運用を前提としている。個人のデスクトップに入れるなという指示が明記されている。加えて、READMEの刑部の説明が取得できた範囲では途中で切れており、六部すべての担当範囲を確認できない。導入後にどの役職が実際に何をするかは、生成された人設ファイルを直接読んで確かめるのが早い。

編集部の結論

導入を検討すべきなのは、Discordをすでに使っていて、複数のLLMエージェントに役割名と担当範囲を与えて動かす構成を、自前で組み立てずに試したい人だ。逆に、単一エージェントで足りる用途、権限を細かく分離したい用途、Discord以外のUIを前提にしたい用途には向かない。最初に確認すべきは scripts/full-install.sh の中身と、生成される ~/.openclaw/openclaw.json の discord セクションで allowBots が mentions になっているかどうか。ここが true のままだとBot同士が反応し合う。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. wanikua/danghuangshang on GitHub