部門と階層の隔離

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 付きの tasks_create は他人のために定期業務をスケジュールできる

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

2c. 他人のレコードの変更・起動 — すでにいずれかの AI 社員のものになっているレコードに作用するツール

以前は作成時だけがチェックされ、既存レコードの変更はチェックされなかったため、更新を使えば作成時に拒否されたことができてしまいました。次のツールは同じ述語で呼び出し元とレコードの所有者を照合します：

ツール	レコードの所有者
`tasks_update`、`tasks_claim`、`tasks_complete`、`tasks_block`、`task_id` 付きの `activity_post`	タスクの割り当て先（割り当て先・引き受け者・作成者が関係なしで操作できる条件はタスクボードのページを参照）
`update_cron_task`、`delete_cron_task`、`pause_cron_task`、`run_cron_task`	その定期業務を実行する社員
`create_reminder`	`agent_id` で指定した社員（省略時は呼び出し元自身）

自分のレコードの操作は制限なし。それ以外は委任関係で決まる
所有者を判定できないレコードは拒否（未割り当て・未引き受けのタスクは先に引き受ける）
オペレーター（どの AI 社員にも対応しない MCP キーで、プロセスも社員用に起動されたものではない）は制限なし
社員身分のないプロセスで内部共有キーを使う場合、行為者は内部 client id になる。これは組織図のどのノードでもないため、誰のレコードに対しても拒否される
cron ツールは 1 件だけに作用する。name で指定したとき、同名の定期業務が複数あれば拒否され、返答に候補の id が並ぶ（この変更以前は delete_cron_task と pause_cron_task が同名のすべての行に、update_cron_task は最初の 1 件に作用していた）

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 / tasks_claim / tasks_complete / tasks_block / activity_post / create_task / cron 管理ツール / create_reminder）→ ~/.duduclaw/tool_calls.jsonl、同じく delegation_denied。create_agent / agent_update による組織変更のブロックは org_placement_denied
関係そのものとは別の理由によるレコード変更の拒否も tool_calls.jsonl に reason 付きで記録される：owner_unknown、caller_unknown、system_sender_identity、reserved_tag_change、goal_contract_frozen。AI 社員が agent_update で自分の権限系設定を変えようとした場合は agent_authority_refused（reason self_authority_change）

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 社員の作成に使用できません——さもなければ自分に通行証を発行するのと同じことになります。

これらの名前は MCP プロセスの身分としても受け付けません。MCP の create_agent ツール、ダッシュボード、duduclaw agent create コマンドはいずれも社員作成時にこれらの名前を拒否し、gateway は社員の MCP server を必ずその社員のディレクトリ id で起動します。社員がこれらの名前を使っていない限り、dashboard、cron、goal-loop-driver、heartbeat、autopilot、webhook を名乗るプロセスは自称でしかありえません。そうしたプロセスは信頼できない身分に解決され、上記のレコードチェックでも拒否されます。この置き換えが起きると、tool_calls.jsonl にプロセスごとに1件（ツール mcp_identity、reason system_sender_identity）が記録され、名乗った名前とその出所（DUDUCLAW_AGENT_ID なら env、[general] default_agent なら config）が残ります。

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

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

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

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

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

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

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

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

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

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

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

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

agent_update にも社員自身の設定についての対応する規則があります。AI 社員は自分について reports_to、db_sources、db_sources_add、db_sources_remove、budget_cents、role を送れません。呼び出し全体が拒否され、agent_authority_refused として記録されます。これらは社員が誰に報告するか、どのデータベースを読めるか、いくら使えるか、メイン agent と見なされるかを決める設定で、上司（委任ポリシーが許す上位者）またはオペレーターが変更します。部下の設定変更は従来どおりで、AI 社員は自分の権限以外のフィールド（表示名、モデル、ハートビートなど）は引き続き変更できます。

削除された社員の名前は予約されたままになる

agent_remove は社員を削除しません。ディレクトリを ~/.duduclaw/agents/_trash/<id>_<14 桁のタイムスタンプ> に移動します。さらなるルールがなければ、リーダーは部下を削除してから同じ名前で create_agent でき、新しい席は名前だけを引き継ぎ、運用者が古い席に設定していた制御（CONTRACT.toml、[capabilities] の制限、サンドボックス設定）は何も引き継ぎません。

そのため AI の caller は、次のいずれかに当てはまる名前の社員を作成できません：

_trash/ にエントリがある（id 全体の一致）、
ディレクトリがないのに org.toml に記録が残っている、または
_trash/ を一覧できないため確認できない（fail closed）。

すべての MCP caller は AI の caller として扱われます。CLI のスキャフォールド経路（duduclaw agent create、pack のインストール、migrate from）は、環境にエージェントの身元（DUDUCLAW_AGENT_ID / DUDUCLAW_AGENT_TOKEN）があるときに同じルールを適用し、agent-file-guard フックは Bash の duduclaw agent create <予約された名前> をブロックします。別の名前は常に許可されます。agent_remove は AI に、社員が削除されたこと、管理者が復元できること、名前が予約されていることを伝えます。ゴミ箱のパスや rm -rf のヒントはもう返しません。

運用者は制限されません。ダッシュボードと、ターミナルの人間は名前を再利用できます。削除された社員の復元や完全削除は、~/.duduclaw/agents/_trash/<id>_<timestamp> を手作業で操作して行い、ダッシュボードにその操作はありません。拒否は security_audit.jsonl に agent_name_reserved（requested_name、path_kind = mcp_create_agent / cli_scaffold / cli_bash_agent_create、reason = removed_to_trash / dangling_org_record / trash_unlistable）として、削除は agent_removed（subject、moved_to_trash）として監査されます。

制限：Claude、Codex の社員は身元を Bash の環境ではなく .mcp.json に持つため、CLI は、その Bash から実行された pack install、migrate from が AI セッションだと判別できません。Bash のルールはヒューリスティックであり、本当の封じ込めは Bash を与えないことです。社員自身の登録情報を使い、実際の MCP サーバー経由で確認済みです（削除、同名での再作成の拒否、別名での作成、hook によるブロック、監査行）。CLI の scaffold 経路は単体テストのみです。

非内部の MCP キーで HTTP 越しに呼ばれた create_agent と agent_remove は、そのキー自身の client id で判定されます（以前はサーバープロセスの既定エージェントとして扱われていました）。そのため、上のサブツリーのチェックは実際の 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`	これらの変更は組織図の変更に等しく、セルフサービス権限昇格の穴
`agent.toml`	`[capabilities]` セクション全体	これは権限エンベロープ（`allowed_tools`／`denied_tools`、`computer_use`／`browser_via_bash`／`os_native`／`git_credentials` の各スイッチ、`db_sources`、承認／不可逆／task-scoped ツール一覧、`autonomy_level`、`wiki_visible_to`）。チームのロールメンバーは社員のワークスペースを cwd として動くため hook は社員本人と判定する——安価なサードパーティモデルが「自分を閉じ込めているはずのエンベロープ」を広げられる唯一の場所だった。比較は両側のキーの和集合をたどるので、将来のリリースで追加される権限キーも同時に凍結される
`config.toml`	`[delegation]`, `[acp]` セクション全体	ポリシー設定はチーム全体の安全に関わり、勝手に変更できない
`.mcp.json`（社員ディレクトリ内の任意の階層）	AI 社員：ファイル全体／オペレーター：`DUDUCLAW_AGENT_ID`、`DUDUCLAW_AGENT_TOKEN`	CLI はファイルに列挙されたすべてのサーバーをオペレーターの OS ユーザーとして起動するため、AI 社員は一切書き込めない。オペレーターには身分トークンのみを検査する（変更は他人へのなりすましに等しい）
`.claude/`、`.claude.json`（任意の階層）、`.codex/`、`.gemini/`、`.grok/`、`.agents/`（最上位）	AI 社員：すべて	そこにある設定、hook、スラッシュコマンド、サブエージェントは、そのディレクトリで CLI が起動するときに読み込まれる。社員ディレクトリ内に複製したプロジェクトも同じで、その `.claude/` は読めるが書けない
`.claude/settings.json`	ファイル全体	権限リストなどの機微な設定はダッシュボードが一元管理
`identity.key`	（ファイル全体）	署名鍵。いかなる変更も身元検証を破壊する

AI 社員身分の呼び出し元に対しては、社員自身の agent.toml のセキュリティ設定と DuDuClaw ホームの状態も凍結される。セキュリティ防御を参照。

正しい変更経路

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

name、reports_to、department の変更 → ダッシュボード「AI 社員 → 詳細 → 編集」、または MCP agent_update ツール（AI 社員は部下には使えるが、自分の reports_to には使えない。前述）
権限の調整やツールの追加 → ダッシュボード「AI 社員 → 詳細設定」、MCP agent_update ツール、またはオペレーターが通常のエディタで agent.toml [capabilities] を編集。いずれもこの hook を通らない（hook が見えるのは Claude Code 自身の Write／Edit／Bash 呼び出しだけ）ため、社員（およびそのチームロールメンバー）はセッション内からこの経路を取れない。agent_update では、AI 社員は部下にデータベースソースを付与できるが、自分には付与できない
権限の調整やツールの追加 → ダッシュボード「AI 社員 → 高度な設定」、または agent.toml [capabilities] を編集して手動指定（ファイルツールを通さない）
委任ポリシーやホワイトリストの変更 → ダッシュボード「高度な設定 → 委任権限」、または config.toml [delegation] を直接編集して gateway を再起動
MCP server の追加 → オペレーターがダッシュボード「高度な設定 → MCP サーバー」で追加するか、ダッシュボードで MCP インストール申請を出しオペレーターが承認する。AI 社員は .mcp.json を編集して追加できない。オペレーターが手で編集する場合は通常のエディタを使い、社員ディレクトリ内で claude を起動しない（そのセッションはその社員として判定される）。アップグレード後は duduclaw doctor を実行すると、社員の .mcp.json にある DuDuClaw が書いていないサーバーがすべて一覧表示される

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

システム身分は無制限

システム送信者（dashboard、webhook、cron、autopilot）の操作は制限を受けず、あらゆる設定を変更できます。これは設計上の保証です：これらのソースはすべてオペレーターの意志の体現だからです。これは gateway 自身の経路にだけ当てはまり、これらの名前を名乗る MCP プロセスは信頼できない身分として扱われます（前述の「誰が『システム』と見なされるか」参照）。

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

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

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

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

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

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

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