AI社員の組織設計｜AIエージェントに人の組織図は写せない

組織図をそのまま人からAI社員へ移すと、部署名だけが並び、誰にも呼ばれない役職が残ります。AI社員の組織設計は、肩書きではなく発火条件・権限・承認の3点から決める設計です。本記事は、設計の順序と、組織図をそのまま写すと起きる3つの失敗を、公式ドキュメントと自社の実測から整理します。

01結論：AI社員の組織設計は、部署ではなく発火条件・権限・承認の3点で決まる

結論は3点です。

1. 組織設計は、誰が偉いかではなく「何が起きたら動くか」を先に決める設計です。発火条件が無い役職は、名前だけの部署になります。
2. 権限は役職単位で絞ります。人の組織図にある「上司の裁量」に相当する余白は、AI社員には残しません。
3. 承認は最後に置きますが、後回しにできる工程ではありません。承認者が決まっていない役職は、誰の判断も経ずに動く役職になります。

Anthropicは、経路が事前に決まっている仕組みをワークフローと呼びます。手順とツールの使い方をLLM自身が決める仕組みはエージェントと呼び、両者を区別しています（出典: Anthropic公式）。AI社員は、このエージェントという技術の上に、担当業務・権限・責任の所在を人が設計して重ねた運用の型です。詳しい境界は『AIエージェントとAI社員の違い｜責任範囲をどこで切るか』で扱っています。

運営元WEBMARKSは2026-06-24に7部署・30体のAI社員を定義しました。本記事は、この定義作業で固まった「発火条件→権限→承認」という設計順序を扱います。

順序を守らないと、手戻りの種類が変わります。承認を発火条件より先に決めると、誰も呼ばない役職に承認フローだけが用意された状態になります。権限を発火条件より先に決めると、まだ何に使うか決まっていない役職に、広い読み書き範囲だけが先に付与されます。どちらも「決めた量」は増えますが、「機能する組織」には近づきません。

02人の組織図を、なぜ組織設計にそのまま写せないのか

人の組織図は、役職名と上下関係だけを描いても機能します。判断に迷ったとき、隣の席の先輩か上司が拾ってくれるからです。新人が全体像を知らなくても、組織はその余白を吸収して動きます。

AI社員には、この「拾ってくれる誰か」がいません。役職名を書いただけでは、どんな依頼が来たときにその役職が動くのかを機械的に判定できません。組織図に書かれた暗黙の期待値を、明示のルールへ変換する作業が要ります。

WEBMARKSの役職定義書は、担当業務・禁止操作・保存先の3種類だけを書いています。どの道具を何回呼ぶかは書きません。この3種類は、表の右列を満たすための最小セットです。

人の組織図をコピーして部署名と役職名だけを並べる進め方は、表の左列で止まります。右列を埋める作業を飛ばすと、後述する3つの失敗が起きます。

03組織設計で役割をどこで切るか｜部署と役職の粒度

役割の切り方には目安があります。Claude Codeのエージェントチーム機能に関する公式ドキュメントは、チームサイズを「3〜5体から始める」ことを推奨しています。「集中した3体のワーカーは、散漫な5体より成果を出すことが多い」とも述べています（出典: Claude Code公式）。

部署の粒度は、この目安を業務ドメインに当てはめて決めます。1部署に役職を詰め込みすぎると、どの役職が何を担当するかが人にも読めなくなります。WEBMARKSは7部署・30体という構成にしており、1部署あたりの役職数はおおむねこの目安の範囲に収まっています。

役職の粒度は、担当業務を1行で言えるかどうかで判定します。「月次の請求書を作る」は1行で言えますが、「営業を手伝う」は言えません。1行で言えない役職は、発火条件も曖昧になりやすい役職です。

Anthropicは、委譲する各ワーカーに「目的・出力形式・使うツールと情報源の指針・タスクの境界」の4点を与えるべきだと述べています（出典: Anthropic公式）。役職定義に置き換えると、この4点は「担当業務・成果物の置き場・使ってよい権限・触れてはいけない範囲」に対応します。

粒度を誤ると起きるのが、後述する「同じ依頼が複数部署に刺さる」失敗です。境界がぼやけた役職を2つ並べると、依頼する側は毎回どちらに聞けばいいか判断できません。

粒度がずれているかどうかは、症状で見分けられます。

粗すぎる役職は、担当業務を1行で言えるかという基準に必ず引っかかります。「〜全般」という言葉が役職名に付いた時点で、粒度の見直しを疑うサインです。

04組織設計における権限配分の原則｜役職ごとの読み書き範囲とツール制限

権限は、役職を作った直後に広げすぎる失敗が最も多い箇所です。Claude Codeのサブエージェントは、name・description・toolsの3項目を設定ファイルに書きます。指定すると、使えるツールがその範囲だけに絞られます（出典: Claude Code公式ドキュメント）。

---
name: article-writer
description: AGI Journalの記事執筆を担当。公開判定はしない
tools: Read, Grep, Glob, Write
---

この例ではWriteが入っていますが、確定版フォルダへの書き込みは別の仕組みで拒否します。WEBMARKSは、確定版フォルダ（納品/）への直接書き込みを拒否し、承認済みの遷移だけを専用の手順で実行する設計にしています。

権限配分の基本は、まず狭く始め、理由を書けたときだけ広げることです。理由を2文以内で書けない権限追加は、たいてい「念のため」で足された権限です。WEBMARKSの委譲ルールも、実働の子エージェントへ人間ゲート級の権限を後から足さないことを明記しています（2026-07-24制定）。

権限を役職単位で固定すると、失敗したときの影響範囲も役職単位に閉じます。逆に、複数の役職が同じフォルダへの書き込み権限を持っていると、どちらが書いたか分からない上書きが起きやすくなります。

権限は、ツールの種類だけでなくディレクトリの単位でも絞ります。同じWrite権限でも、下書き専用フォルダにしか書けない役職と、複数の案件フォルダを横断できる役職では、事故が起きたときの被害が桁違いです。役職を作るときは、ツールの一覧だけでなく「読み書きしてよいフォルダの一覧」も同じ設定に含めます。

05承認をどこに置くか｜役割設計で最後に決まること

発火条件と権限を決めても、承認者が決まっていなければ組織設計は完成しません。Anthropicは、エージェントが処理の途中で立ち止まり、チェックポイントで人からのフィードバックを待つ設計を挙げています（出典: Anthropic公式）。チェックポイントは、誰が見るかを決めて初めて機能します。

Claude Codeのフックは、ツール実行の直前で処理を止め、allow（通す）・deny（止める）・ask（人に聞く）のいずれかを返します。判断しないときはdeferを返し、通常の権限フローに戻ります（出典: Claude Code公式ドキュメント）。承認をどこに置くかは、この4つの返し値をどの役職・どの操作に割り当てるかという設計です。

組織設計の一部として、WEBMARKSは承認者の資格そのものをルール化しています。社内正式採用への昇格は、原則としてAI自身を承認者に指名できません。案件単位で明示的に委任されたときだけが例外です。承認ゲートそのものの詳しい線引きは『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』で扱っています。

組織設計の観点では、承認をどの層に置くかは役職の対外性で決まります。

対外性が高い役職ほど、承認を技術的な壁（hook層）に寄せます。承認者を人に固定する理由は単純です。AI社員同士が承認し合う設計は、チェックポイントを素通りする経路をもう1つ作るのと同じだからです。承認者の欄を空欄のまま役職を稼働させると、誰も止めない役職ができます。

承認した事実は、承認者名・日時・承認の根拠・対象物のハッシュ値の4項目で記録します。ハッシュ値を残す理由は、承認が「そのときの中身」に対して下されるからです。承認後に対象が差し替わっても、ハッシュが一致しなければ気づけます。

06AI社員の組織設計が機能しているかを確かめる方法

組織設計は、書いた時点では完成していません。定義書に書いたことと、実際に動いていることは別の事実です。確認は3つの問いに分かれます。

1. 発火条件は生きているか：想定した依頼文を実際に投げ、狙った役職が反応するかを確認します
2. 権限は想定どおり絞られているか：担当外の操作を試し、拒否されるかを確認します
3. 承認は記録として残るか：承認者名・日時・対象物のハッシュが記録に残るかを確認します

WEBMARKSにも、書いたことと動いていることが別だと分かった実例があります。常駐実行するジョブ（launchd）の稼働は、設定ファイルを信じずlaunchctlで毎回実測しています。2026-07-28時点で、8つ定義したうち稼働中と確認できたのは1本、残り7本は定義済みで検証待ちだと把握しています。

定義書と実測の突き合わせは、書いた本人以外が行うほうが精度が上がります。組織設計は一度確認して終わりではなく、役職を増やすたびに繰り返す工程です。

確認の頻度にも目安があります。新しい役職を追加した直後は必ず確認し、それ以降は四半期ごとの棚卸しに乗せます。稼働を確認した日付を記録に残しておくと、「定義したはず」を「動いているはず」と混同する事故を防げます。

07組織設計でつまずく3つの失敗パターン

ここまでの3工程（発火条件・権限・承認）は、どれか1つが欠けても組織設計として機能しません。3つの失敗は、それぞれ発火条件・承認・粒度のどこが欠けたかで分かれます。

1つ目は、設計と稼働を混同する失敗です。定義した瞬間に動くと思い込むと、実際には眠ったままの役職が積み上がります。

2つ目は、承認を「そのうち誰かが見るだろう」で済ませる失敗です。承認者の欄を埋めないまま稼働させると、対外的に確定する操作まで人の目を通さずに進みます。

3つ目は、境界を宣言しないまま並行して動かす失敗です。範囲の宣言なしに複数の実行主体が同じ対象に触れると、重複だけでなく上書きも起きます。統合時の失敗を防ぐ具体策は『サブエージェント設計｜ディレクターとワーカーの分け方』の結果統合の章で扱っています。

3つの失敗に共通するのは、書いた時点では気づけないという点です。役職定義書を読み返すだけでは、発火条件が生きているか、承認者が実在するか、範囲が重なっていないかは判定できません。実際に依頼を投げ、実際に稼働を確認して、初めて見つかる失敗です。

08AI社員の組織設計チェックリスト

• 役職ごとに、依頼文から機械的に判定できる発火条件を書いたか
• 発火条件が実際にOS・アプリ側で有効化されているか実行して確認したか
• 権限を役職単位で固定し、確定版フォルダへの直接書き込みを拒否しているか
• 権限を広げるときは、2文以内で理由を書けるか確認したか
• 承認者を人、または明示的な委任先に固定し、AI自身を承認者にしていないか
• 承認した事実を、承認者名・日時・対象のハッシュで記録しているか
• 複数の役職が同じ対象へ同時に手を出さないよう、範囲を宣言する仕組みがあるか
• 役職の粒度を「担当業務が1行で言えるか」で確認したか

09FAQ