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