部署の一覧はできました。役職名も並びました。それなのに、実際に依頼を投げると誰も動かない。AI社員の体制図を作った直後に、この状態になることがあります。
原因は、熱意でも設計の粗さでもないことがほとんどです。人の組織図に書かなくても回っていたものが、そのまま抜け落ちているだけです。人の職場では、書かれていない部分をその場にいる誰かが埋めています。AI社員には、その埋め役がいません。
この記事は、埋め役がいない前提で組織を組み立てる順序を扱います。決めるのは肩書きではなく、発火条件・権限・承認の3点です。根拠は公式ドキュメントと、運営元WEBMARKSが自社で組んだときの記録です。稼働を数えた日は2026-07-28で、そのとき出た数字だけを載せています。
こんなふうに調べていませんか
- 部署と役職の一覧は作ったのに、依頼を投げても誰も動かない
- AI社員を増やしたいが、どこまで権限を渡してよいかを決められない
- 体制図はあるが、それが動いているかを確かめる方法を知らない
この記事を読み終えたときに手に入るもの
- 部署名ではなく、発火条件・権限・承認の順で役職を決められるようになります
- 役職の粒度が細かすぎるか粗すぎるかを、症状から見分けられるようになります
- 定義書に書いたことが動いているかを、自分の手で確かめられるようになります
結論30秒でわかる、この記事の結論
- AI社員の組織設計は、部署ではなく、発火条件・権限・承認の3点を役職ごとに固定する設計です。
- 3点には決める順番があります。順番を崩すと、決めた量は増えるのに機能する組織には近づきません。
- 書いた時点では完成しません。依頼を投げ、拒否を試し、記録を見て、はじめて設計と言えます。
進行役は3人です。高梨課長（自分の手で組む立場）が手順を聞き、大森部長（体制と投資を判断する立場）が線引きを聞き、鈴木さん（本誌監修）が答えます。近い立場の人の質問から読んでいただいて構いません。
01AI社員の組織設計は、いちばん最初に何を決めるんですか？
大森部長部署と役職の表は作りました。ただ、そこから先に進んでいる感触がありません。次は何を決めればいいのでしょうか。
鈴木さん誰が偉いかではなく、何が起きたら動くかを先に決めます。そのあとに触れてよい範囲、最後に通す人。この順で埋めていくと、途中で止まりにくくなります。
結論を先に置きます。決めるのは3点、しかも順番があります。
1つ目は発火条件です。何が起きたらその役職が動くのかを、依頼文から判定できる形で書きます。発火条件が無い役職は、名前だけの部署になります。
2つ目は権限です。役職の単位で上限を絞ります。人の組織図にある「上司の裁量」に相当する余白は、AI社員には残しません。
3つ目は承認です。最後に置きますが、後回しにできる工程ではありません。承認者が決まっていない役職は、誰の判断も経ずに動く役職になります。
ここで言うAI社員は、技術そのものの呼び名ではありません。Anthropicは、経路が事前に決まっている仕組みをワークフローと呼び、手順とツールの使い方をLLM自身が決める仕組みをエージェントと呼んで区別しています（出典: Anthropic公式）。AI社員は、このエージェントという技術の上に、担当業務・権限・責任の所在を人が設計して重ねた運用の型です。境界の詳しい線引きは『AI社員とAIエージェントの違い｜任せる前に決める3つの境界』が引き受けます。
運営元WEBMARKSは2026-06-24に7部署・30体のAI社員を定義しました。この記事で扱うのは、その定義作業で固まった順序です。
順序を崩すと、あとで戻る場所が変わります。承認を発火条件より先に決めると、誰も呼ばない役職に承認フローだけが用意されます。権限を発火条件より先に決めると、何に使うか決まっていない役職に、広い読み書き範囲だけが先に付きます。どちらも決めた量は増えますが、動く組織には近づきません。
この章のまとめ
決めるのは肩書きではなく、発火条件・権限・承認の3点です。順番を崩すと、決めた分だけ手戻りが増えます。
02AI社員の組織設計で、人の組織図はなぜAIエージェントにそのまま写せないんですか？
人の組織図は、役職名と上下関係だけを描いても機能します。判断に迷ったとき、隣の席の先輩か上司が拾ってくれるからです。新人が全体像を知らなくても、組織はその余白を吸収して動きます。
AIエージェントを並べた組織には、この拾ってくれる誰かがいません。役職名を書いただけでは、どんな依頼が来たときにその役職が動くのかを機械的に判定できません。組織図に書かれた暗黙の期待値を、明示のルールへ変換する作業が要ります。
| 人の組織図が前提にしていること | AI社員の組織設計が要求すること |
|---|---|
| 役職名を見れば、だいたいの担当が分かる | 依頼文から機械的に判定できる発火条件が要る |
| 判断に迷ったら、上司や周囲に聞ける | 権限の上限をあらかじめ役職単位で固定する |
| 責任は状況に応じて誰かが引き取る | 承認者を1人、または1役職に明示する |
| 新人は空気を読んで動く範囲を調整する | 動く範囲を発火条件として先に書いておく |
WEBMARKSの役職定義書は、担当業務・禁止操作・保存先の3種類だけを書いています。どの道具を何回呼ぶかは書きません。表の右列を満たすための最小セットが、この3種類です。
部署名と役職名だけを並べる進め方は、表の左列で止まります。右列を埋める作業を飛ばしたまま人数を増やすと、この記事の後半で挙げる失敗が出てきます。
03発火条件を書かないと、AI社員は誰からも呼ばれないんですか？
高梨課長発火条件と言われても、実際に何を書けばいいのかが分かりません。役職の説明文とは違うものですか。
鈴木さん違います。説明文は人が読んで納得するための文で、発火条件は依頼文と照らし合わせるための条件です。「請求書」「月次」といった言葉が来たら動く、という書き方に寄せると判定しやすくなります。
高梨課長読んで分かる文と、照らせる条件は別物ということですね。
発火条件は、依頼が届いたときに「これは自分の担当か」を判定するための条件です。人が読んで意味の通る紹介文とは、目的が違います。
条件を書いていない役職は、この判定に登場しません。定義書の中には存在していても、依頼の流れの中には存在しないのと同じ状態です。体制図の役職数が増えても稼働が増えないときは、まずここを疑います。
04部署と役職の粒度は、組織設計としてAI活用の現場でどこまで細かくするんですか？
役割の切り方には目安があります。Claude Codeのエージェントチーム機能に関する公式ドキュメントは、チームサイズを3〜5体から始めることを推奨しています。集中した3体のワーカーは、散漫な5体より成果を出すことが多いとも述べています（出典: Claude Code公式）。
部署の粒度は、この目安を業務ドメインに当てはめて決めます。1部署に役職を詰め込みすぎると、どの役職が何を担当するかが人にも読めなくなります。WEBMARKSは7部署・30体という構成で、1部署あたりの役職数はおおむねこの目安の範囲に収まっています。
役職の粒度は、担当業務を1行で言えるかどうかで判定します。「月次の請求書を作る」は1行で言えますが、「営業を手伝う」は言えません。1行で言えない役職は、発火条件も曖昧になりやすい役職です。
Anthropicは、委譲する各ワーカーに目的・出力形式・使うツールと情報源の指針・タスクの境界の4点を与えるべきだと述べています（出典: Anthropic公式）。役職定義に置き換えると、担当業務・成果物の置き場・使ってよい権限・触れてはいけない範囲に対応します。
粒度がずれているかどうかは、症状で見分けられます。
| 粒度の状態 | 症状 | 直し方 |
|---|---|---|
| 細かすぎる | 似た役職が並び、同じ依頼がどちらにも刺さる | 担当業務が重なる役職を1つに統合する |
| ちょうどいい | 依頼文から迷わず1役職に振り分けられる | そのまま運用し、発火条件を明文化する |
| 粗すぎる | 役職の説明が「〜全般」「〜サポート」で終わる | 業務ドメインごとに役職を分割する |
粗すぎる役職は、担当業務を1行で言えるかという基準に引っかかります。役職名に「〜全般」が付いた時点で、粒度の見直しを疑うサインです。
この章のまとめ
粒度は人数ではなく、言い切れるかと重なっていないかで見ます。境界がぼやけた役職を2つ並べると、依頼する側が毎回迷います。
05組織設計として、AI導入で権限を配るとき、役職ごとにどこまで絞るんですか？
高梨課長権限は最初から広めに渡したほうが、いちいち止まらなくて早い気がします。あとから絞るのでは遅いですか。
鈴木さん逆になりやすいです。広く渡すと、事故が起きたときにどこまで戻せばいいかが読めなくなります。狭く始めて、理由を書けたときだけ広げる。そのほうが、結果としては早く広がります。
権限は、役職を作った直後に広げすぎる失敗がいちばん多い箇所です。
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権限でも、下書き専用フォルダにしか書けない役職と、複数の案件フォルダを横断できる役職では、事故が起きたときの被害の広さが違います。役職を作るときは、ツールの一覧と一緒に、読み書きしてよいフォルダの一覧も同じ設定に含めます。
06組織設計で、AIエージェントに任せた作業はどこで人に戻すんですか？
発火条件と権限を決めても、承認者が決まっていなければ組織設計は終わりません。
Anthropicは、エージェントが処理の途中で立ち止まり、チェックポイントで人からのフィードバックを待つ設計を挙げています（出典: Anthropic公式）。チェックポイントは、誰が見るかを決めて初めて機能します。
Claude Codeのフックは、ツール実行の直前で処理を止めます。判定はallow（通す）・deny（止める）・ask（人に聞く）の3つで返します（出典: Claude Code公式ドキュメント）。どこで人に戻すかは、この3つの返し値を、どの役職のどの操作に割り当てるかという設計です。承認ゲートそのものの線引きは『AIエージェントの承認ゲート｜止める操作4種と3層の選び方』で扱っています。
07承認を置く層は、AI社員の対外性でどう変わるんですか？
大森部長承認を挟むほど遅くなりますよね。全部に人を置くのは体制として持ちません。どこまで置くか、判断の軸はありますか。
鈴木さん対外性で分けます。社内の下書きに閉じるものと、社外に届くものでは、置く層を変えます。全部に同じ重さの承認を置くと、確かに回らなくなります。
大森部長重さを変えるという発想はありませんでした。
組織設計の観点では、承認をどの層に置くかは役職の対外性で決まります。
| 役職の対外性 | 承認を置く層 | 例 |
|---|---|---|
| 社内の下書き・調査に閉じる | 運用ルール層（台帳の状態欄など） | 資料の下書き作成 |
| 社内の正式版への格上げに関わる | CLI/ワークフロー層（dry-run→承認済み実行） | ナレッジ・型の昇格 |
| 社外・第三者に届く操作に関わる | hook層＋人間の直接判断 | 送信・公開・削除・決済 |
対外性が高い役職ほど、承認を技術的な壁に寄せます。WEBMARKSは承認者の資格そのものもルール化していて、社内正式採用への昇格は、原則としてAI自身を承認者に指名できません。案件単位で明示的に委任されたときだけが例外です。
理由は単純です。AI社員同士が承認し合う設計は、チェックポイントを素通りする経路をもう1つ作るのと同じだからです。承認者の欄を空欄のまま役職を稼働させると、誰も止めない役職ができます。
08承認した事実は、AI社員の記録としてどこまで残すんですか？
承認は、置いただけでは後から検証できません。残す項目は4つです。承認者名・日時・承認の根拠・対象物のハッシュ値です。
ハッシュ値を残す理由は、承認が「そのときの中身」に対して下されるからです。承認後に対象が差し替わっても、ハッシュが一致しなければ気づけます。逆にここを残していないと、通したものと出ていったものが同じかどうかを、あとから誰も言えません。
4項目のうち、抜けやすいのは根拠です。承認者名と日時は仕組みが自動で書けますが、なぜ通したかは人が書く部分だからです。ここが空欄の記録は、次に同じ判断をするときの材料になりません。
09書いたAI社員の組織設計が動いているか、どう確かめるんですか？
高梨課長定義書は書き上げました。これで動いていると考えていいものでしょうか。
鈴木さんそこは分けて考えます。書いたことと、動いていることは別の事実です。確かめ方は、依頼を投げる、わざと拒否させる、記録を見る。この3つですね。
高梨課長読み返すだけでは足りない、ということですか。
鈴木さん足りないです。読み返して見つかる不備は、たいてい最初から気づいていたものだけなんです。
確認は3つに分かれます。
- 発火条件は生きているか：想定した依頼文を実際に投げ、狙った役職が反応するかを見ます
- 権限は想定どおり絞られているか：担当外の操作を試し、拒否されるかを見ます
- 承認は記録として残るか：承認者名・日時・対象物のハッシュが記録に残るかを見ます
WEBMARKSにも、書いたことと動いていることが別だと分かった実例があります。常駐実行するジョブ（launchd）の稼働は、設定ファイルを信じずlaunchctlで毎回数え直しています。2026-07-28時点で、8つ定義したうち稼働中と確認できたのは1本でした。残り7本は定義済みで検証待ちだと把握しています。
定義書と実測の突き合わせは、書いた本人以外が行うほうが精度が上がります。自分で書いた条件は、自分では想定どおりに読んでしまうためです。
確認の頻度にも目安があります。新しい役職を追加した直後はそのつど確認し、それ以降は四半期ごとの棚卸しに乗せます。稼働を確認した日付を記録に残しておくと、「定義したはず」を「動いているはず」と混同せずに済みます。
この章のまとめ
組織設計は書いた時点では完成していません。投げる・試す・見るの3つを通したものだけが、動いている設計です。
10AI社員の組織設計でつまずく3つの失敗は、どこが分かれ目ですか？
3工程のうち、どれか1つが欠けても組織設計としては機能しません。よく出る失敗は、欠けた要素で3つに分かれます。
| 失敗パターン | 何が起きるか | 欠けている要素 | WEBMARKSでの実例 |
|---|---|---|---|
| 肩書きだけ作って発火条件が無い | 役職は定義されているが、誰も呼び出さない | 発火条件 | 常駐ジョブ8本を定義、2026-07-28実測でロード済みは1本 |
| 承認者が居ない | 誰の判断も経ずに、役職が最終判断まで進む | 承認者の明示 | 昇格の承認者を「原則AI名不可・鈴木さんの直接承認または委任」に限定する規約で対処 |
| 同じ依頼が複数部署に刺さる | 2つ以上の役職が同じ対象へ同時に手を出す | 粒度・範囲の宣言 | 姉妹メディアで常駐プロセスと本体セッションが同じ記事へ同時に書き込み、記事3本が上書き |
1つ目は、設計と稼働を混同する失敗です。定義した瞬間に動くと思い込むと、眠ったままの役職が積み上がります。
2つ目は、承認を「そのうち誰かが見るだろう」で済ませる失敗です。承認者の欄を埋めないまま稼働させると、対外的に確定する操作まで人の目を通さずに進みます。
3つ目は、境界を宣言しないまま並行して動かす失敗です。範囲の宣言なしに複数の実行主体が同じ対象に触れると、重複だけでなく上書きも起きます。統合時の失敗を防ぐ具体策は『サブエージェント設計｜委譲の線引きと3つの失敗』の結果統合の章で扱っています。
3つに共通するのは、書いた時点では気づけないという点です。定義書を読み返すだけでは、発火条件が生きているか、承認者が実在するか、範囲が重なっていないかを判定できません。
11明日からのAI導入で、組織設計の何から手をつけますか？
ここまでの内容を、着手前に自分の体制へ当てはめる項目にまとめます。「いいえ」が1つでもあれば、役職を増やすより先にそこを埋めてください。
- 役職ごとに、依頼文から機械的に判定できる発火条件を書いたか
- 発火条件が実際に有効化されているか、依頼を投げて確認したか
- 権限を役職単位で固定し、確定版フォルダへの直接書き込みを拒否しているか
- 権限を広げるときは、2文以内で理由を書けるか確認したか
- 承認者を人、または明示的な委任先に固定し、AI自身を承認者にしていないか
- 承認した事実を、承認者名・日時・根拠・対象のハッシュで記録しているか
- 複数の役職が同じ対象へ同時に手を出さないよう、範囲を宣言する仕組みがあるか
- 役職の粒度を「担当業務が1行で言えるか」で確認したか
12よくある質問
AI社員の組織設計は、何体から始めればいいですか
1体からで構いません。発火条件・権限・承認の3点を1役職で通してみると、どこでつまずくかが分かります。そのうえで部署単位へ広げるほうが、あとの手戻りが小さくなります。最初から部署をそろえようとすると、埋まっていない欄を抱えたまま数だけ増える状態になりやすいです。1体で3点を埋め切る練習が、そのまま設計の型になります。
組織設計を先に決めず、動かしながら直していくのはだめですか
小さく試すこと自体は問題ありません。むしろ、投げてみないと発火条件の書き方は決まりません。ただし承認者を空欄のまま本番の依頼を通すと、誰も止めない状態で対外的な操作まで進みます。試す範囲を社内の下書きに閉じておくか、承認者だけは稼働前に決めておくか。このどちらかは先に済ませてください。
発火条件と権限は、どちらを先に決めるべきですか
発火条件が先です。何が起きたら動くかが決まっていないと、権限を絞る対象範囲そのものが定まりません。順序を逆にすると、使い道の決まっていない役職に広い読み書き範囲だけが付き、あとから外しにくくなります。発火条件を書いてみると、必要な道具とフォルダは自然に絞り込まれます。その絞り込みの結果が権限です。
部署をまたぐ依頼は、どう扱えばいいですか
複数の役職に刺さる依頼は、粒度が粗すぎるサインです。まず依頼そのものを分割できないかを見ます。分割できないなら、優先度を決める役職を1つ置き、そこで振り分けます。どちらも取らずに両方の役職を動かすと、同じ対象へ同時に手が出る状態になります。この記事の失敗パターンの3つ目が、まさにその形です。
承認者は1人に固定する必要がありますか
役職の単位では、1人または1役職に固定します。案件によって承認者が変わる場合は、案件を開始する時点でどちらが承認者かを記録に残します。決めずに走り出すと、あとから「自分は聞いていない」が起きます。固定するのは人ではなく、その案件における承認者の欄です。欄が埋まっていることのほうが、誰であるかより先に効きます。
既存の部署を後から分割・統合するのは大変ですか
権限とフォルダの単位を先に分けておけば、役職の再定義だけで済みます。逆に権限が複数役職にまたがっていると、分割時に読み書き範囲を洗い出す作業から始まります。あとで分けるかもしれないと思う部分は、最初からフォルダを分けておくと後が楽です。分けたフォルダを統合するのは、混ざったフォルダを分けるより手間がかかりません。
AI社員の組織設計は、人事制度の変更を伴いますか
役職と権限の設計そのものは伴いません。発火条件も承認者も、業務の中の取り決めとして書けます。ただし人の評価や役割の再定義に踏み込む場合は、専門家の確認が要る領域です （就業規則・人事制度は個社ごとに前提が異なります）。制度に触れる前に、まず業務側の3点を埋めるところまでを進めてください。
13まとめ｜今日やる3つのこと
決めるのは部署名ではなく、発火条件・権限・承認の3点でした。そして、書いた時点では完成しません。今日は次の順で手をつけてください。
今日この順で手をつけます
役職を1つ選び、発火条件を依頼文の言葉で書く
照らして判定できる形かどうかが、ここで分かります
その役職が触れてよいフォルダと道具を列挙する
列挙できない範囲は、まだ渡す段階ではありません
承認者の欄を埋めてから稼働させる
空欄のまま動かすと、止める人がいない役職になります
AI検索では、こう聞かれています
AI社員の組織設計は、何から決めればいいんですか？
「AI社員の組織設計は、いちばん最初に何を決めるんですか？」の章で説明しています
人の組織図をそのままAIエージェントに写してはいけないんですか？
「AI社員の組織設計で、人の組織図はなぜAIエージェントにそのまま写せないんですか？」の章で扱っています
AI社員の役職は、どこまで細かく分けるんですか？
「部署と役職の粒度は、組織設計としてAI活用の現場でどこまで細かくするんですか？」の章に判定の目安があります
書いた組織設計が動いているか、どう確かめるんですか？
「書いたAI社員の組織設計が動いているか、どう確かめるんですか？」の章で3つに分けています
次に読むなら、この記事です
