「AIエージェント」と「AI社員」は同じ技術を指すことがありますが、運用の結果は役割設計の有無で分かれます。本記事は、AI社員とAIエージェントの違いを責任範囲の設計という1点で切り分け、公式ドキュメントと自社の実測記録（計測日2026-07-28）から整理します。
01結論｜AI社員とAIエージェントの違いは、責任範囲の設計にある
AIエージェントは、目標を受け取って手順を自分で選び、実行と結果の確認を繰り返す技術です（詳しくは『AIエージェントとは｜そう呼べる3条件と、呼べない境界』）。AI社員は、その技術の上に「どの業務を」「どこまでの権限で」「誰が責任を持つか」を人が設計して重ねた運用の型です。同じClaude Codeの呼び出しでも、都度の資料作成に使えばエージェントの利用にとどまり、役職定義に沿って毎回同じ範囲だけを任せればAI社員としての運用になります。
運営元WEBMARKSは2026-06-24に7部署・30体のAI社員を定義しました。人が書いたのは担当業務・禁止操作・保存先の3種類で、どの道具を何回呼ぶかは書いていません。この線引きが、本記事で扱う責任範囲の設計の実物です。線引きを飛ばして権限だけを広げると、担当範囲が誰の目にも見えない状態になります。
02AIエージェントとは｜AI社員と比べる前に押さえる土台
AIエージェントは、目標を渡すと手順を自分で決めて動くAIです。Anthropicは、経路が事前に決まっている仕組みをワークフローと呼びます。手順とツールの使い方をLLM自身が決める仕組みはエージェントと呼び、両者を区別しています（出典: Anthropic公式）。人間は目標や指示だけを渡し、途中の判断はAIが担います。
Google Cloudも、目標に向けて自律的に動き、道具と推論で作業を進めるソフトウェアと説明しています（出典: Google Cloud公式）。この定義には、誰が担当し、失敗したら誰が責任を持つかという情報は含まれません。AI社員という呼び方が必要になるのは、ここから先です。技術としての性能が上がっても、この情報は自動では埋まりません。
実務での代表例は、GitHub Copilotのcoding agentです。課題（issue）を割り当てると、リポジトリを調査し実装計画を立て、バックグラウンドで変更をコードに反映します（出典: GitHub Copilot公式ドキュメント）。ただし利用には管理者による事前の有効化が必要で、開発者は差分を確認してからプルリクエストを作成します。
AIエージェントを紹介する製品ページの多くは、できることの一覧が中心です。誰が業務を担当し、失敗したら誰が責任を持つかという記述は、たいてい別の運用ドキュメントに分かれています。この分離こそが、AI社員という呼び方が別に必要になる理由です。
03AI社員はAIエージェントと何が違うのか｜責任範囲を持つかどうかが分かれ目
AI社員とAIエージェントの分かれ目は、技術の性能ではなく、人が何を先に決めているかです。AIエージェントの利用は、その場の指示と結果の確認だけで完結します。AI社員の運用は、着手前に担当業務・権限・報告先を書いた状態から始まります。
Claude Codeのサブエージェントは、この分かれ目を設定ファイルの形で確認できます。name・description・toolsの3項目を書くと、Claudeはその説明に一致する作業だけをサブエージェントへ委任します。使えるツールも、指定した範囲だけに絞られます（出典: Claude Code公式ドキュメント）。
---
name: report-writer
description: 月次レポートの下書き作成を担当。他の作業には使わない
tools: Read, Grep, Glob
model: sonnet
---このdescriptionとtoolsが、担当業務と権限の宣言にあたります。ここに書式が用意されていること自体が、役割を固定して人が読める形で残すという設計思想の表れです。ただし、この設定だけでは責任の所在（失敗したら誰に報告するか）までは書けません。WEBMARKSは、この部分を役職定義書と案件台帳で別途固定しています。
descriptionを曖昧に書くと、Claudeは委任すべき場面をそのつど判断することになり、担当範囲は実質的に広がります。具体的な業務名と対象範囲を書くほど、委任の境界がはっきりします。
04対比軸の詳細｜AI社員が持つ権限・記録・失敗時対応の3点
AI社員とAIエージェントを並べると、差は3つの軸に集約されます。担当業務の範囲・権限の固定単位・失敗時の報告先です。WEBMARKSは、この3列を役職ごとの定義書に書いています（2026-06-24時点・7部署30体）。
| 比較軸 | AIエージェント（技術としての利用） | AI社員（役割を設計した運用） |
|---|---|---|
| 担当業務の範囲 | その場の指示や単一タスクに閉じる | 部署・役職単位で固定し、他の業務は担当しない |
| 権限の固定単位 | 呼び出しのたびにツールを渡すことが多い | 役職ごとにtoolsと読み書き範囲を事前に固定する |
| 責任の所在 | 起動した人がその都度判断する | 役職定義の時点で人が責任範囲を書面化する |
| 稼働の形 | 単発実行が中心 | 常駐・単発を問わない（呼称は稼働形態と無関係） |
| 止める操作 | 実行直前のhookで都度判断されることが多い | 送信・公開・削除など役職共通の禁止操作として固定する |
表の4行目にある通り、常駐で動いていることはAI社員の条件に入りません。設定ファイルを書いた事実と、いま動いている事実は別に数えるべきだという考え方から、WEBMARKSは常駐ジョブの稼働をlaunchctlで毎回実測しており、2026-07-28時点では、定義した8本のうち稼働中は1本、残り7本は役職定義済みで検証待ちだと把握しています。役割設計の有無と、いま動いているかどうかは別の軸です。
この5行は、新しい役職を作るときのひな型にもなります。役職を1つ増やすたびに、同じ5つの軸を埋めるだけで責任範囲の設計が揃います。
05業務をAI社員に任せる前に決める3つの境界
役割を決めずに権限だけを広げると、担当外の場所まで書き換えてしまうことがあります。AI社員として任せる前に、次の3つを先に決めます。
- 担当業務を1つに固定する：入力は「対象の案件ID」、確認方法は「役職定義書に業務が1行で書けるか」です。書けない場合は業務が広すぎます。
- 触れてよい範囲を決める：入力は「読み書きするフォルダの一覧」、確認方法は「確定版フォルダ（
納品/等）への書き込みを拒否する設定になっているか」です。 - 失敗時の報告先を決める：入力は「送信・公開・削除など止める操作の一覧」、確認方法は「その操作の直前に人間ゲートが挟まっているか」です。
Claude Codeのhooks機能は、指定した操作の直前で処理を止め、実行してよいか・止めるか・人に聞くかを返せます（出典: Claude Code公式ドキュメント）。この3つが揃って初めて、AIエージェントの利用は「AI社員としての運用」に変わります。3つのうち1つでも空欄なら、その業務はまだAIエージェントの利用にとどまります。境界を先に決める作業は、AIではなく人が担います。
06実運用で出た差｜AI社員化した業務とツールのままの業務の分かれ目
WEBMARKSでは、同じClaude Codeという道具でも、担当業務が固定されているかどうかで扱いが分かれています。次は2026-07-28時点の実測です。
| 呼び出し方 | 担当業務の決め方 | 権限の固定単位 | WEBMARKSの実測（2026-07-28） |
|---|---|---|---|
| 都度呼び出すエージェント | その場の依頼で決まる | セッション単位 | 資料の下書き作成など単発の依頼に使用 |
| 役職を持つAI社員 | 役職定義で事前に固定 | 役職単位（読み書き範囲・禁止操作） | 7部署30体を2026-06-24に定義 |
| 常駐ジョブとしてのAI社員 | 役職定義＋起動条件で固定 | 役職単位＋実行時刻 | launchdジョブ8本を定義、ロード済みは1本 |
役職を持つAI社員でも、常駐ジョブ化しているとは限りません。本記事の執筆・原典照合・批評も役職に分かれていますが、いずれも呼び出しに応じて動く単発実行です。姉妹メディアのAIO Journal（公開URL251本・2026-07-28にsitemap.xmlで実測）の制作体制も同じ形を踏襲しています。
一方で、役割を決めないまま複数のAIプロセスを並行させると、担当範囲の重なりがそのまま事故になります。AIO Journalの制作では、番犬プロセスと本体セッションが同じ記事ファイルへ同時に書き込み、記事3本が上書きされました。原因は権限の強さではなく、どの範囲を誰が担当するかを先に宣言していなかったことです。
対策は3つです。着手前に担当範囲を宣言するファイル（WRITER_CLAIM）を作ること、記事マップの状態を「執筆中」へ進めること、宣言のない範囲には手を付けないことです。いずれも権限を絞る対策ではなく、担当範囲を先に見える形にする対策です。
07AI社員へ引き上げるかどうかの判断基準｜3つの条件
すべての業務をAI社員化する必要はありません。次の3条件がそろったときだけ、役職を設計する価値があります。
- 同じ種類の依頼が繰り返し発生する：毎回ゼロから指示を書き直すコストが、役職を定義するコストを上回っている
- 失敗したときの影響範囲が読める：担当業務が1つに絞られているため、何が壊れても影響先を特定できる
- 権限を役職単位で固定しても業務が回る：都度別の道具や別のフォルダへアクセスする必要がない
たとえば「月次の請求書を作る」という依頼は、毎月同じ形で繰り返し、失敗しても影響範囲は請求書1件に絞れます。権限も特定のフォルダに固定できるため、3条件がそろいAI社員として設計できます。一方で「今日だけ資料を1枚作ってほしい」という依頼は繰り返しがなく、AIエージェントとして都度呼び出すだけで足ります。
3条件のうち1つでも満たさない場合は、都度呼び出すAIエージェントのままにしておくほうが管理コストは小さくなります。役職を作ること自体が目的化すると、担当範囲だけあって稼働していない役職が増えるリスクがあります。WEBMARKSが対比表の「8本中1本」という内訳を把握しているのは、このリスクをlaunchctlの実測で継続的に確認しているからです。
08AI社員化でつまずきやすい点｜権限を広げすぎる失敗
いちばん多い失敗は、役職を作った直後に権限を広げすぎることです。担当業務を1つに絞ったつもりでも、toolsの設定を緩めると、担当外のファイルまで書き換えられる状態になります。権限設計の甘さは、担当業務の絞り込みより見落とされやすいところです。書き込み範囲は、ツールの種類だけでなくディレクトリの単位でも絞る必要があります。
権限を広げる判断をしたら、次の2文以内に理由を書きます。理由を書けない権限追加は、たいてい「念のため」で追加されたものです。WEBMARKSでは、確定版フォルダ（納品/）への書き込みを拒否する設定を役職の共通ルールとして持ち、個別の役職ごとに例外を作らない方針にしています。理由を書く習慣そのものが、担当範囲を意識させる仕組みになります。
もう1つの失敗は、役職定義を書いた時点で満足し、実際の稼働を確認しないことです。定義書に「常駐で監視する」と書いてあっても、launchctlのようなコマンドで実測しない限り、それが動いているかは分かりません。WEBMARKSはこの前提に立ち、書いた設定を信じずlaunchctlで毎回実測する運用にしており、2026-07-28の実測では、定義した8本のうち稼働中は1本だと把握しています。定義書と実測の突き合わせは、書いた本人以外が行うほうが精度が上がります。
09チェックリスト（AI社員として任せる前に確認する7項目）
提出前に、次を全部確認してから役職を設計します。1つでも埋まらない場合は、AIエージェントとして都度呼び出す運用にとどめます。
- 担当業務を1つの範囲に固定したか
- 触れてよいディレクトリ・ファイルの範囲を書いたか
- 送信・公開・削除・決済などの禁止操作を列挙したか
- 失敗したときに誰が報告を受けるかを決めたか
- 権限を役職の設定ファイル（
tools等）に固定したか - 常駐にするか都度呼び出しにするかを決め、実際の稼働を確認したか
- 案件IDや台帳など、責任の記録をどこに残すかを決めたか
10FAQ
AIエージェントを導入すれば、AI社員は要らなくなりますか
逆です。AIエージェントという技術は、AI社員を作るための土台にあたります。役割を設計しない限り、技術だけでは担当業務も責任の所在も決まりません。
AI社員という呼び方は、法律上の社員と同じ意味ですか
いいえ。雇用契約上の社員ではなく、役割・権限・責任範囲を人が設計して運用する型を指す呼び方です （業界内での用語の定着度は確認中です）。
小さく始めるなら、どの業務からAI社員として設計するのが安全ですか
繰り返し発生していて、担当範囲を1業務に絞りやすいものからです。社内向けの下書き作成や定型チェックのように、人が確認してから使う工程が向いています。
AIエージェントとAI社員は、同時に使ってもいいですか
問題ありません。WEBMARKSでも、役職化していない単発の依頼にはAIエージェントとしてClaude Codeを使い、繰り返す業務だけをAI社員として役職化しています。
AI社員の数は、多いほど良いのですか
いいえ。担当範囲が重なるほど、失敗したときに誰が責任を持つかが曖昧になります。役職を増やすときも、対比表の3列（担当業務・権限・報告先）を先に埋めてから増やします。
