部門と階層の隔離

AI 社員の委任制御：誰が誰に仕事を任せられるかは、reports_to ツリー・部門・ホワイトリストで決まる。

DuDuClaw 1.52 は、複数人チーム向けの委任制御を導入しました。あなたの AI 社員は組織構造に従う必要があり、誰の言うことでも聞くわけではなくなります。

問題の状況

初期バージョンには単層の親子チェックしかありませんでした——祖父階層は孫階層の社員に直接仕事を割り当てられず（飛び級は拒否）、同部門の同僚同士の委任もブロックされていました。バックエンド経路（タスクキュー、自動化ルール、外部 A2A 呼び出し）にはそもそもチェックがなく、誰でも委任指示を偽造できました。

3 つのポリシー、自由に選択

config.toml またはダッシュボードの「高度な設定」で [delegation] policy を設定します：

ポリシー	動作	用途
`department`（デフォルト）	上下関係の委任、同部門の横方向コラボ、ホワイトリストペアをすべて許可	ほとんどのチーム
`hierarchy`	上下関係とホワイトリストペアのみ許可、同部門の横方向はなし	厳格な指揮系統
`open`	旧バージョンの動作。「自分自身への委任禁止」以外のチェックなし	緊急時のフォールバック用

ホワイトリストペアは department と hierarchy の両ポリシーで有効です。open だけは使いません（もともと全開放のため）。

デフォルト値 department は一般的なコラボレーションに適しています——飛び級割り当ての穴を修正しつつ、同僚同士が助け合える柔軟性を保ちます。

ワークフローで影響を受ける箇所

委任のすべての経路が制御対象です：

1. 直接割り当て — ダッシュボード、Telegram、または API から send_to_agent / spawn_agent を呼び出す

リーダーは直属の部下に割り当てられ、孫階層にも割り当てられる（祖父→孫は現在許可）
同部門の社員同士は相互に割り当て可能
それ以外は拒否され、誰から誰への委任で、どの関係が欠けているかを明示するエラーメッセージが返る

2. タスクディスパッチ — タスクボードでのタスク作成（tasks_create）または再割り当て（tasks_update の assigned_to）で誰かに割り当てる

チェックは 1 と同じ。拒否時はタスクの作成／再割り当てが失敗する
自分のタスクの引き受け（tasks_claim）は制限なし
ダッシュボードでの割り当て操作は制限なし（すべて人間の操作）

2b. マルチステップ計画と定期業務 — create_task の各ステップは実行者を指定でき、schedule_task は他人のために定期業務をスケジュールできる

どちらも委任であり、作成時点でチェックされる。create_task のステップは実際のディスパッチ直前にもう一度チェックされる
自分のためのスケジュール、自分を実行者に指定するのは制限なし

3. 自動化ルール — autopilot ルール内の delegate アクション

autopilot システム身分でチェックされ、自動的に許可
ルール自体はダッシュボードが門番となり、管理者による設定が必要

4. 外部 A2A 呼び出し — 他のシステムが ACP プロトコルの message/send を通じてタスクを委任

デフォルトで拒否（fail-closed）
信頼できる外部パートナーが必要とする場合、[acp] trusted = true を設定して初めて開通
開通後、外部呼び出しは a2a-client 身分を使い、同様に委任ポリシーの制御下に置かれる

「同部門」とは

各 AI 社員の agent.toml [agent] department フィールドが所属部門を定義します。

同じ department 値を持つ社員は「同部門」と見なされ、department ポリシー下で相互に割り当て可能
フィールドが空または未設定 = 無部門。誰とも同部門と見なされない
部門値はプレーンテキスト比較。例えば sales と Sales は別部門と見なされる

部門をまたぐコラボレーション：ホワイトリストペア

営業部リーダーと倉庫リーダーは別部門だが、互いに仕事を任せたい？ホワイトリストを使います：

[delegation]
policy = "department"
allow = [
  ["sales-lead", "warehouse-lead"],
  ["HR-manager", "finance-lead"]
]

各エントリは 2 つの社員 ID のペアで、順序は不問（["A", "B"] は ["B", "A"] と同じ）
ペア成立後、両者は上下関係なしに相互割り当てが可能
自己ペア（["x", "x"]）は無視される
設定ファイルを手動編集する場合、形式が壊れたエントリ（ちょうど 2 つの文字列でない、空文字列を含む）は警告付きで無視され、他のペアには影響しない。ID のタイプミスは検出されず、そのペアが効かないだけ
ダッシュボードから保存する場合はより厳格：いずれかの ID に対応する AI 社員が見つからないと、どれが問題かを指摘して保存全体が拒否される。また 1 回の保存は最大 200 ペアまで

ダッシュボードの「高度な設定 → 委任権限」カードが編集画面を提供し、各ペアには両者の部門バッジが同時に表示されるため、コラボレーションの意図が一目で分かります。

ダッシュボード設定（管理者のみ）

高度な設定 → 委任権限

3 つのコントロール：

ポリシー選択（ラジオボタン）：department / hierarchy / open
- 各項目に一行の説明付き
- open には赤いリスク警告付き：“すべてのチェックを放棄し、旧バージョンの動作に戻る”
部門をまたぐコラボレーション（ペアリスト）
- 各行に 2 人の AI 社員名 + 部門バッジを表示
- 「+」でペアを追加（agent picker ドロップダウン）、「✕」で削除
- 変更は即時反映、再起動不要
ステータス表示
- 現在のポリシー、ペア数
- 設定警告（例：無効な ID）があれば表示

監査とデバッグ

拒否された委任の試みはすべて痕跡を残し、インターセプト地点によって 2 つのファイルに分かれます：

ディスパッチが実際に実行される直前にブロック（bus キュー、マルチステップ計画）→ ~/.duduclaw/security_audit.jsonl、イベント型 delegation_denied
MCP ツールの時点でブロック（send_to_agent / spawn_agent / tasks_create / tasks_update / create_task / schedule_task）→ ~/.duduclaw/tool_calls.jsonl、同じく delegation_denied。create_agent / agent_update による組織変更のブロックは org_placement_denied

security_audit.jsonl のレコードはこのような形です：

{
  "timestamp": "2026-08-06T10:30:00Z",
  "event_type": "delegation_denied",
  "agent_id": "bob",
  "severity": "warning",
  "details": {
    "sender": "alice",
    "target": "bob",
    "reason": "different_department",
    "policy": "department",
    "path_kind": "bus_dispatch",
    "task_id": "…",
    "message": "委派遭拒：…"
  }
}

トラブルシューティングの手がかり：

agent の department フィールドのスペルが正しいか確認する
ホワイトリストペアが正しいか照合する（大文字小文字を区別）
チーム全体で仕事の受け渡しができない場合、hierarchy または open に切り替えて部門隔離が原因かを確認する

アップグレード時の注意

初期バージョンから 1.52 にアップグレードする際：

表玄関経路はゼロリグレッション：親子間の委任はすべて引き続き通過（新ポリシーはより寛容）
裏口経路は厳格化：bus_queue.jsonl への直接 append（送信者フィールドがある場合）、タスクボード割り当て、マルチステップ計画、定期業務、外部 A2A 呼び出しといった、以前チェックのなかった経路がすべて隔離を実施するようになる
- 旧来の「誰でも誰にでも割り当てられる」動作に依存する自動化スクリプトがあると、拒否エラーが発生する
- 対処法：policy = "open" を設定して一時的にロールバックするか、組織構造を整備する（department を追加、ホワイトリストを補充）
[acp] trusted はデフォルト false：外部 A2A 呼び出しは現在拒否され、明示的な開通が必要

デフォルトの department ポリシーを維持することを推奨します。旧バージョンには一切チェックがなかったとしても、新ポリシーは既存の正当な割り当てにゼロ影響で、不合理な横断的試行に対してのみ警告を発します。

技術詳細

誰が「システム」と見なされるか（隔離制御の対象外）

以下の身分による割り当ては自動的に許可されます：

dashboard（ダッシュボード操作、人間の身分）
webhook（webhook 由来のスケジュールタスク）
goal-loop-driver（自律ゴールループ）
cron（スケジュールタスク）
heartbeat（ハートビート応答）
autopilot（自動化ルール、ルール自体が検証済みであることが前提）

外部 A2A 呼び出しはデフォルトで a2a-client 身分を使用し、リストには含まれません。[acp] trusted = true の場合のみ組み込まれます。

上記の名前（および a2a-client、default、__ で始まるすべての名前）は予約語であり、AI 社員の作成に使用できません——さもなければ自分に通行証を発行するのと同じことになります。

この防衛線がカバーする範囲、しない範囲

カバーする範囲：AI 社員同士がプラットフォーム機能を通じて相互に仕事を委任するすべての経路（MCP ツール、タスクボード、マルチステップ計画、定期業務、タスクキュー、外部 A2A）。これは組織的権限境界であり、「誰が誰に仕事を命じられるか」を組織図に沿わせるものです。

カバーしない範囲（設計上の既知の境界であり、バグではない）：

旧形式タスク：1.52 では送信者フィールドがまったくないキュータスクは引き続き通過させ、warning を 1 件記録するだけ（アップグレード時にキューに残っている仕事を全部潰さないため）。次のバージョンで拒否に変わる。
設定ファイルレベルの変更：v1.52 以降、PreToolUse hook が機微な組織データフィールドを凍結——agent は Write/Edit/Bash ツールを通じて agent.toml の name / reports_to / department、config.toml の [delegation] / [acp] セクション、.mcp.json の身分ブロック、.claude/settings.json、identity.key を書き換えられない。これらの設定変更はダッシュボードまたは agent_update MCP ツールという、審査済みの正式な経路を通す必要がある。社員をまたぐファイル変更（例：他人の SOUL.md の変更）も拒否される。非 Claude runtime（codex/gemini など）は workspace-write サンドボックス下で ~/.duduclaw/ ディレクトリに書き込めず、サンドボックス層の防衛線となる。FullAccess サンドボックスのみが例外で、これはオペレーターが明示的に選択した極端な権限である。
システムと人間が起点の操作：ダッシュボード、webhook、スケジュール、自動化ルールはもともとオペレーターの意志であり、一律に許可される。

可視範囲のフィルタリング

list_agents と agent_status コマンドは、caller が見る権限を持つ社員リストのみを返します。

ポリシーに応じて、可視範囲は以下を含みます：

自分自身
自分のサブツリー全体
自分のすべての祖先
（department ポリシー）同部門のすべての社員
（すべてのポリシー）ホワイトリストのペアパートナー

不可視の社員を探ろうとした場合（例：alice に bob を見る権限がないのに agent_status bob を実行）、「not found or not visible」が返り、どちらなのかは区別されません。

セルフサービスの権限昇格の禁止

create_agent で新しい社員を作成するとき、caller は新しい社員を自分自身、または自分のサブツリー内のノードにしか接続できません。

リーダーは自分の直属の部下を作るか、部下の下に接続することしかできない
上司の下に社員を作ることはできない（オペレーターがその上司またはさらに上位である場合を除く）
ダッシュボードからの社員作成は制限なし（人間の操作）

身元検証（上級）

MCP 身分 token の仕組み

v1.52 以降、各 agent の MCP 呼び出しには署名付き身分 token が付与され、なりすましを防ぎます。

動作原理：

Gateway は起動時に ~/.duduclaw/identity.key に 256-bit のランダム鍵を生成（ファイル権限 0600）
子 agent を spawn するとき、gateway は署名付き token を生成（HMAC-SHA256、agent ID にバインド）
Token は環境変数 DUDUCLAW_AGENT_TOKEN に注入され、子 agent は起動時にそれを携行する
MCP server 側が token の有効性と授権者の身元を検証する

ソフト／厳格モード：

ソフトモード（デフォルト）：config.toml [delegation] require_identity_token = false
- token の欠落や無効は警告のみで、MCP 起動を拒否しない
- フォールトトレランス用：アップグレード中や token が一時的に未同期の移行期間
厳格モード：config.toml [delegation] require_identity_token = true
- 無効な身元は MCP 起動を直ちに拒否し、失敗メッセージをログに書き込む
- セキュリティ要件の高い環境に適する

アップグレードの順序が重要：まず gateway を再起動し（agent の MCP 設定を再署名させる）、その後で厳格モードに切り替えます。順序が逆だと、agent は無効な token で起動し、厳格モードに入った途端に拒否されます。

組織データの保護

凍結対象

Agent がファイルツール（Write/Edit/Bash）を通じて行う変更は PreToolUse hook にインターセプトされます：

ファイル	フィールド / セクション	理由
`agent.toml`	`[agent]` の `name`, `reports_to`, `department`	これらの変更は組織図の変更に等しく、セルフサービス権限昇格の穴
`config.toml`	`[delegation]`, `[acp]` セクション全体	ポリシー設定はチーム全体の安全に関わり、勝手に変更できない
`.mcp.json`	`DUDUCLAW_AGENT_ID`, `DUDUCLAW_AGENT_TOKEN`	身分トークン。変更は他人へのなりすましに等しい
`.claude/settings.json`	ファイル全体	権限リストなどの機微な設定はダッシュボードが一元管理
`identity.key`	（ファイル全体）	署名鍵。いかなる変更も身元検証を破壊する

正しい変更経路

これらの設定を変更する必要があるとき：

name、reports_to、department の変更 → ダッシュボード「AI 社員 → 詳細 → 編集」、または MCP agent_update ツール
権限の調整やツールの追加 → ダッシュボード「AI 社員 → 高度な設定」、または agent.toml [capabilities] を編集して手動指定（ファイルツールを通さない）
委任ポリシーやホワイトリストの変更 → ダッシュボード「高度な設定 → 委任権限」、または config.toml [delegation] を直接編集して gateway を再起動
MCP server の追加 → .mcp.json の tools 配列を編集（身分ブロックは触らない）、ダッシュボード「高度な設定 → MCP サーバー」で手動追加

インターセプトは ~/.duduclaw/tool_calls.jsonl に org_placement_denied マーカー付きで記録され、デバッグに役立ちます。

システム身分は無制限

システム送信者（dashboard、webhook、cron、autopilot）の操作は制限を受けず、あらゆる設定を変更できます。これは設計上の保証です：これらのソースはすべてオペレーターの意志の体現だからです。

ホワイトリスト入力の柔軟性

ダッシュボードの委任権限カードでペアを編集するとき、両方のフィールドは以下を受け付けます：

AI 社員の表示名（agent.toml [agent] display_name）：例「Alice」
ディレクトリ名（agent.toml [agent] id）：例「alice-engineer」

入力時の検索は両フィールドを同時にスキャンしますが、保存は常にディレクトリ名に正規化されるため、表示名が変わってもペアは安定して無効になりません。

チームデプロイ時の自動部門設定

ダッシュボードの「新しいチームをデプロイ」機能を使う場合、メンバーの department フィールドを一つずつ編集する必要はありません：

業界テンプレートをアップロードまたは選択（team.toml が [team] industry を定義。例：retail, healthcare）
デプロイ時、すべてのフロント agent（カスタマーサポート、営業など）+ バックグラウンド worker（データ整理、レポートなど）の department が自動的にその業界コードに設定される
業界パックを単独インストールする場合も department が付与される。新しい社員を追加するときは手動で同じ部門を指定するか、ダッシュボードで複数を一括変更する

これによりチーム全体が自動的に同部門となり、ほとんどの業界チームの組織構造に合致します。部門をまたぐコラボレーションが必要になったらホワイトリストペアを補充します。

よくある Q&A

Q：アップグレード後、社員が仕事を割り当てられなくなった

A：エラーメッセージを確認してください。「部門が異なる」なら、department フィールドを埋めるかホワイトリストペアを追加します。「階層が不足」と書かれているなら、reports_to ツリー構造を確認します。

Q：policy = "open" を有効にすべきか

A：推奨しません。デフォルトの department は「誰もが部下に割り当てられ、同僚は助け合える」に相当します——これは一般的なコラボレーションパターンです。open に戻すのは一時的なデバッグ用途に限るべきです。

Q：ホワイトリストペアに数の上限はあるか

A：ダッシュボードから保存する場合、1 回最大 200 ペアです。それ以上必要になるのは、例外を追加し続けるのではなく、組織構造や部門の区分を見直すべきサインであることが多いです。

Q：新しい社員の department フィールドには何を入れればいいか

A：部門コードで十分です（例：sales、engineering、hr）。リテラル比較で、大文字小文字を区別します。空値または未設定 = 無部門で、誰とも同部門と見なされず、上下関係またはホワイトリストを通じてのみコラボレーションできます。

組織データの権威ソース

v1.52 以降、組織構造には中央の権威ストアが 1 つあり、複数人の編集による不整合を防ぎます。

`org.toml` — 組織図の単一の信頼できる情報源

Gateway は初回起動時に、すべての agent ディレクトリ下の agent.toml を自動スキャンし、組織データ（reports_to、department）を中央ファイル ~/.duduclaw/org.toml に取り込みます。以降、組織構造に対するすべての変更はこのファイルを通じて行われます：

# ~/.duduclaw/org.toml — v1.52+ で新規追加
[agents."alice-engineer"]
display_name = "Alice"
reports_to = "sales-lead"
department = "sales"

[agents."bob-qa"]
display_name = "Bob"
reports_to = "alice-engineer"
department = "sales"

このファイルは gateway が管理します。直接編集して形式を壊すと起動に失敗する可能性があるため、コマンドの使用を推奨します。

組織構造を管理する 3 つのコマンド

1. `duduclaw org sync` — ローカルの agent.toml を権威ファイルに同期

オペレーターがターミナルで実行します（AI 社員のセッション内で実行するものではありません）：

duduclaw org sync

すべての agent ディレクトリ下の agent.toml [agent] の reports_to / department フィールドをスキャンし、~/.duduclaw/org.toml を更新します。競合がある場合（例：alice-engineer が権威ファイルでは sales だが、ローカルの agent.toml では engineering と書かれている）、コマンドは各差分を列挙して確認を求めます。

使うタイミング：

ある agent.toml の組織フィールドを手動編集し、その変更を権威ファイルに同期したいとき
旧バージョンからアップグレードし、agent.toml に組織データが残っているが権威ファイルが空のとき

2. `duduclaw org show` — 現在の組織構造を確認

duduclaw org show

すべての社員、誰が誰に報告するか、各社員の部門をツリーまたは表形式で表示します。組織図が期待どおりかを確認するのに便利です。

3. `duduclaw doctor` — 組織データの不整合を診断

duduclaw doctor

以下の問題をスキャンして報告します：

権威ファイルの欠落または形式エラー
agent.toml の reports_to または department が権威ファイルと不一致（「ドリフト」と呼ぶ）
宙に浮いた reports_to（存在しない社員を指している）
循環依存（A→B→C→A）

出力は各問題と推奨される修復手順を明確に列挙します。

なぜ移行したのか——組織構造は意思決定であり、データではない

旧バージョンでは、agent が自分のディレクトリ下の agent.toml [agent] フィールドを手動変更でき、委任判定に直接影響しました（例：reports_to を変えれば上司が変わる）。これは穴を作りました：社員がセルフサービスで組織図を書き換え、権限昇格を達成できたのです。

新バージョンは組織データを中央権威に変更しました。これは次のことを意味します：

誰が報告関係を決めるか：オペレーター（人間）であり、AI 社員ではない
手動変更は効かない：agent.toml の組織フィールドを編集しても doctor にドリフトとして検出されるだけで、委任の動作が自動的に変わることはない
組織変更にはプロセスが必要：ダッシュボードまたは duduclaw org sync コマンドを通すことで、すべての変更に人間の承認意図が伴うことを保証する

社員をまたぐファイル隔離

AI 社員同士は明確に分離されるべきで、ある社員が別の社員のファイルを変更できてはなりません。

ファイルツールは越境禁止

v1.52 以降、Write / Edit / Bash ツールはファイルパスに対して境界チェックを行います：

自分の社員ディレクトリ内 ✅：alice-engineer は ~/.duduclaw/agents/alice-engineer/ 下のすべてのファイルを読み書きできる
他の社員のディレクトリ内 ❌：alice-engineer が bob-qa の SOUL.md やメモリファイルを変更しようとする → ツール実行が拒否され、tool_calls.jsonl に access_denied マーカー付きで書き込まれる
グローバル機微ファイル ❌：alice-engineer は ~/.duduclaw/config.toml、org.toml、identity.key などのグローバルファイルを変更できない

PreToolUse hook インターセプト層

あらゆるファイルの Write / Edit / Bash 操作は hook のチェックを経由し、拒否されると直ちにエラーを返します。ファイル I/O を待つ必要がなく、競合状態とログ漏洩を防ぎます。

サンドボックス層の防衛線 — 非 Claude runtime

Codex、Gemini、Antigravity などの非 Claude runtime は、workspace-write サンドボックス下で ~/.duduclaw/ ディレクトリに書き込めません。仮に PreToolUse に穴があっても、サンドボックスがシステムレベルでブロックします。FullAccess サンドボックス（オペレーターが明示的に選択した極端な権限）のみが開放され、その場合はその社員に一時的なグローバルアクセスを付与したものと見なすべきです。

社員をまたぐ正当な変更経路

別の社員の設定を変更する必要がある場合（例：リーダーが部下の department を調整）：

社員の基本情報 — ダッシュボード「AI 社員 → 詳細 → 編集」（人間／システムオペレーターが実施）
組織構造 — duduclaw org sync またはダッシュボード「高度な設定 → 組織構造」
能力・権限 — ダッシュボード「AI 社員 → 高度な設定」または MCP agent_update ツール（管理者検証が必要）

これらの経路はすべて人間の意思決定の体現であり、社員のセルフサービスで迂回されることはありません。