「30体入れました、で、うちの何が変わったんですか」。AI社員を業務へ入れた話をすると、この質問が返ってきます。
配置した日は日付で言えます。変化のほうは、そう簡単には言えません。動いている自動化と、書いたまま動いていない自動化と、はじめから人が決めると決めておいた操作。この3つが、同じ職場に混ざったまま置かれるからです。
この記事は、WEBMARKSが2026-06-24に7部署・30体のAI社員を配置してから、2026-07-28までの34日間で確かめられたことだけを書きます。効果の数値を先に出さず、何が測れて何がまだ測れていないかを分ける記録です。
確認環境は、社内の運用記録とlaunchctlによる実測、および姉妹メディアAIO Journalのsitemap.xml実測です。いずれも時点は2026-07-28です。
こんなふうに調べていませんか
- AI社員を入れたはいいが、何がどう変わったのかを人に説明できない
- 導入効果を数字で聞かれている。いま出してよい数字がどこまでか分からない
- 自動化を作ったはずなのに、動いている手ごたえがない
この記事を読み終えたときに手に入るもの
- 配置した数と稼働している数を、別々に数えられるようになります
- 効果として言える範囲と、まだ言えない範囲を線引きできるようになります
- 人の判断が残る操作を、4つの類型で見分けられるようになります
結論30秒でわかる、この記事の結論
- AI社員を並べても、その場で稼働を確かめられる自動化はまだ一部です。効果を先に言い切るのは早すぎます。
- 工程は「稼働を確かめられた範囲」「人の判断が残る範囲」「検証待ちの範囲」の3つに割ると、実態が見えます。
- 観測は2026-06-24から2026-07-28までの34日間です。この長さで効果量は主張しません。
進行役は3人です。高梨課長が自分の手で確かめる側から聞き、大森部長が投資と体制の側から聞き、鈴木さん（本誌監修）が答えます。
01AI社員の導入効果って、配置した翌日から何か変わるんですか？
大森部長30体という数は聞きました。それで、来月の何が軽くなるんでしょうか。
鈴木さん来月これが軽くなります、という言い方は、いまはできません。お見せできるのは、どこが動いていて、どこが止まったままかという地図のほうです。
置いた翌日に工程が入れ替わることは、ほとんどありません。役割を決めた状態と、その役割が実際に手を動かしている状態のあいだには、まだ距離があるからです。
そこで、この記事では3点だけを持ち帰っていただく形にしました。
第一に、AI社員を並べても、稼働をその場で確かめられる自動化はまだ一部だという点です。効果を先に言い切るには早すぎます。
第二に、工程の変化は「稼働を確かめられた範囲」「人の判断が残る範囲」「検証待ちの範囲」の3つに割ると、はじめて実態が見えるという点です。ひとまとめに「変わった」と言うと、この3つが混ざります。
第三に、観測期間は2026-06-24の配置から2026-07-28までの34日間だという点です。1か月ほどの記録で効果量を主張することはしません。
なぜ数値を出さないのか。社内では、AI社員がどれだけの工程を置き換えたかを、まだ確定した数値として記録していないからです。観測期間の区切り方と、対象にする工程の範囲が先に決まっていません。分母が決まっていない割り算は、いくら丁寧に計算しても意味を持ちません。
AIエージェントやAI社員が業務でどこまで来ているかという全体像は、AGIの業務活用はどこまで来たかで扱いました。この記事はそこから一歩内側に入り、実際に配置した1社の中で、何が測れて何が測れなかったかに絞ります。
02AI社員を配置したというのは、具体的に何を決めた状態なんですか？
数える前に、何をもって「配置した」と言うのかを固定します。社内では、役職ごとに次の3点を先に決めています。
| 決めた要素 | 中身 | 決まっているかの確かめ方 |
|---|---|---|
| 担当業務 | 依頼文から機械的に判定できる範囲を1行で書く | 役職定義書に、業務が1行で書けているか |
| 禁止操作 | 送信・公開・削除・決済など、対外的に確定してしまう操作 | 実行の手前で止まる仕組み（hook等）があるか |
| 保存先 | 成果物を置く場所と、確定版フォルダへ書いてよいかの可否 | 確定版フォルダへの直接書き込みが拒まれるか |
道具の呼び方までは決めていません。どのツールを使うかは、役職の側ではなく、そのときの仕事の側が決めるためです。
Anthropicは、委譲する各ワーカーに「目的・出力形式・使うツールと情報源の指針・タスクの境界」の4点を与えるべきだと述べています（出典: Anthropic公式）。社内の3要素は、このうち目的と境界にあたる部分です。使うツールそのものは、役職定義書には書いていません。
Claude Codeのサブエージェントも、nameとdescriptionを必須項目として設定ファイルに書きます。任意のtoolsを書くと、使えるツールがその範囲だけに絞られます（出典: Claude Code公式ドキュメント）。
ここで効いてくるのが、担当業務を1行で書けるかどうかです。1行で書けない役職は、descriptionも曖昧になります。曖昧な説明を読んだ側は、任せてよい場面をそのつど広く解釈します。配置の設計そのものの考え方は、AI社員の組織設計で扱っています。
この章のまとめ
「配置した」とは、担当業務・禁止操作・保存先の3点が役職ごとに埋まった状態のことです。人数ではありません。
03AI社員の導入で工程が変わったかどうかは、AIエージェントの何を見れば分かるんですか？
高梨課長変わったかどうかを、自分の手で確かめたいんです。どこを見ればいいですか。
鈴木さん見る場所は分かれています。設計は定義書、稼働はlaunchctl、進み方は案件の記録。同じ画面には出てきません。
社内で実際に踏んだのは、次の4段階です。
はじめに、役職定義書を開いて、担当業務・禁止操作・保存先の3項目が埋まっているかを見ます。次に、常駐で動かす予定の役職について、launchctlで実際に読み込まれているかを確かめます。続いて、進行中の案件が、作業中・内部承認済み・正式採用のどの状態にあるかを見ます。最後に、数値にできない項目を、想定や推定で埋めずに「未実測」のまま残します。
見る対象と、参照する記録の対応は次のとおりです。
| 確かめた対象 | 参照した記録 | そこから分かること |
|---|---|---|
| 常駐自動化の稼働 | launchctlの出力（2026-07-28実測） | 定義済みジョブのうち、実際に読み込まれている本数 |
| 案件の進み方 | 案件ごとの状態記録 | 案件が作業中・内部承認済み・正式採用のどこにあるか |
| 公開済み成果物の規模 | 姉妹メディアのsitemap.xml（2026-07-28実測） | 役割分担型の制作体制が実際に出した本数（別案件） |
| 役職ごとの呼び出し回数 | 該当する記録なし | 未実測。個別役職の稼働頻度は、この記事の対象外 |
最終行を空欄のままにせず「未実測」と書くのは、埋まっている行と埋まっていない行を、読む人が区別できるようにするためです。埋められない欄を推測で数値化すると、後述する「合計はあっても内訳が無い」失敗をそのまま繰り返します。
04AI社員の導入効果として、いまはどこまでを効果と言えるんですか？
配置から34日後の2026-07-28に確かめられたことを、運用の形ごとに並べます。
| 運用の形 | あてはまる例 | 2026-07-28時点で確かめられたこと |
|---|---|---|
| 常駐実行（スケジュール型） | Chatworkメッセージの自動取得、バックアップ、セッションの自動復旧など | 8本を定義し、launchctlの実測で読み込み済みは1本 |
| 単発実行（都度呼び出し型） | 資料の下書き作成、調査、添削などの依頼応答 | 呼ばれれば動く設計。呼び出し回数そのものを役職単位で記録していない |
| 組織化（役割分担型） | 記事の執筆・原典照合・批評のように複数体で分担する形 | 姉妹メディアAIO Journalで公開URL251本の実績（2026-07-28実測、別案件） |
1行目が言っているのは、「定義した」ことと「いま動いている」ことは別の事実だ、という一点です。8本のうち7本は、Chatworkの自動取得やバックアップ、セッションの自動復旧などを含みます。設定ファイル（plist）としては存在しますが、検証を終えて稼働までは進んでいません。
3行目は、7部署30体の配置とは別の案件です。AIO Journalは記事制作という1つの工程に特化し、この配置より前から役割分担で運用しています。数字は並べますが、比較の扱いは後の章に回します。
導入効果として断定できるのは、常駐実行の8本中1本という狭い範囲だけです。ここを広げて言った瞬間に、記事も報告書も根拠を失います。
この章のまとめ
いま「効果」と呼べるのは、実測で読み込みを確かめられた常駐の範囲だけです。残りは物差しそのものが違います。
05単発で呼び出すAIエージェントの働きは、導入効果としてなぜ数えられないんですか？
表の2行目にあたる層です。AI社員の大半は、この単発実行の形で使われています。都度の依頼に応じて動く設計なので、「いま稼働しているか」という問いが、常駐実行のときと同じ形では成立しません。
常駐は時計が起こします。単発は人の依頼が起こします。起こす側が違えば、稼働という言葉の意味も変わります。時計で起きるものは「起きたか」を記録に残せますが、依頼で起きるものは、依頼そのものを数える欄がなければ残りません。
社内には、役職ごとの呼び出し回数を記録する仕組みがまだありません。そのため、この層の変化はここでは数値化しません。使った実感はあります。ただし実感は、実測の代わりにはなりません。
では、この層は評価できないのかというと、そうではありません。見るところが変わるだけです。単発実行と組織化の層は、稼働の有無ではなく、役割設計ができているかどうかで見ます。担当業務・禁止操作・保存先が埋まっていれば、呼ばれたときに同じ振る舞いをします。
06AI導入が進んでAIエージェントに任せても、人の判断が残るのはどういう操作ですか？
稼働の実測だけでは、どこまで任せてよいかは決まりません。人の判断として固定している操作は、次の4類型に分かれます。
| 判断の種類 | 具体例 | 誰が最後に決めるか |
|---|---|---|
| 対外に出る操作 | 送信・公開・削除・決済・契約・pushの実行 | 人が直接決める（実行前フックで自動化を止める） |
| 社内の正式な格上げ | 社内採用への昇格、ナレッジ化、旧版の置き換え | 人が直接承認する、または案件単位で明記された委任者が決める |
| 検査・監査の指摘の実行 | ファクトチェックや監査からの修正指摘への対応 | 反映担当が、指摘の根拠を確かめてから実行する |
| 権限を広げる判断 | 役職が使えるツールや、読み書き範囲の拡大 | 人間ゲート級の権限（Bash・送信・削除）を後から足していないかを人が確かめる |
3行目は、実際に起きた出来事から足した類型です。社内で、検査工程が実在しない規約の条文を根拠に修正を指摘したことがありました。反映担当が本文を確かめたところ該当箇所が無く、指摘は実行せずに終わっています。検査の指摘もまた、実行の手前でもう一段確かめる対象です。
4類型に共通するのは、動いている自動化の本数とは関係なく固定されている点です。常駐ジョブが1本しか動いていなくても、対外操作の判断は同じ4類型のままです。
07人の判断は、AI社員が手を動かす手前のどこで止まるんですか？
止まる場所を決めているのは、ツール実行の直前に割り込むフックです。
Claude Codeのフックは、ツール実行の直前にallow・deny・ask・deferの4つを返せます。意味は順に、通す・止める・人に聞く・外部統合向けに一時停止する、です。deferは判断の保留ではなく、claude -pを呼び出す外部プロセス向けの一時停止を指します（出典: Claude Code公式ドキュメント）。
見落としやすいのは、最後の分岐です。フックが何も出力せずに終了した場合は、この4つのどれにも当たらず、通常の権限フローがそのまま続きます（出典: Claude Code公式ドキュメント）。書いてあるのに止まらない、という状態は、ここから生まれます。
Anthropicは、エージェントが処理の途中で立ち止まり、チェックポイントで人からのフィードバックを待つ設計を挙げています（出典: Anthropic公式）。前章の4類型は、このチェックポイントをどの操作の手前へ置くかという設計の具体例です。どこで止めるかの線引きそのものは、AIエージェントの承認ゲートで詳しく扱っています。
この章のまとめ
止める場所は、役職定義書ではなく実行の直前にあります。定義書に「禁止」と書くことと、手前で止まることは別の作業です。
08常駐が1本しか動いていないのは、AI導入として問題じゃないんですか？
大森部長8本作って動いているのが1本。これは、投資として失敗という話になりませんか。
鈴木さん失敗かどうかを言う前に、数え方を分けたいんです。作ったという事実と、動いているという事実は、別の場所に記録されています。
「作った」と「動いている」を1つの欄で管理すると、この差は見えなくなります。設定ファイルは書けば増えますが、読み込みは別の工程だからです。
残りの7本は、検証待ちの状態にあります。plistとしては置いてあり、中身も書かれています。ただし、検証を終えて稼働までは進んでいません。この段を飛ばして本数だけを足すと、動かない自動化が静かに増えます。
だから社内では、「8本の常駐自動化がある」という書き方をしません。定義した事実だけを見て、稼働の事実を落とした表現になるためです。数える欄は、はじめから2つに分けておきます。
09同じAI社員でも、先に成果が積み上がる使い方はあるんですか？
工程の変化がどこまで進むかは、運用してきた期間と、検証の積み重ねに左右されます。比較の材料として、姉妹メディアAIO Journalの実績を並べます。
AIO Journalは、記事の執筆・原典照合・批評という役割分担を、今回の配置よりも前から運用しています。2026-07-28時点でsitemap.xmlを実測すると、公開URLは251本でした。ただしAIO Journalは記事制作という1つの工程に特化した別案件であり、7部署30体の配置とは運用期間も対象範囲も違います。
単純に並べて優劣を言うことはできません。それでも、役割分担そのものは長く運用するほど成果物として積み上がる、という傾向は読み取れます。AIO Journalも、公開に至るまでには執筆・原典照合・批評という関門を通しており、対外に出る操作の判断は人に残したまま本数を積んでいます。
いまの配置は、マトリクスでいえば右下に近い位置です。稼働の実測はまだ限られ、観測期間も34日にとどまります。右上へ進むために足すべきものは、体制でも人数でもありません。実測を重ねる時間と、そのつどの突き合わせです。
この章のまとめ
先に積み上がっているのは「役職の数が多い側」ではなく、「同じ工程を長く回してきた側」です。
10AI社員の導入効果を早合点すると、どんな数え方の失敗が起きますか？
工程の変化を記録するときに、社内で実際に起きた失敗が3つあります。いずれも記録に残っています。
失敗1：合計はあっても内訳は無いまま表を作る。自動判定フックが3日間で233回誤作動した事実は記録にありますが、日別の内訳はどこにも残っていません。過去に、この内訳を推測で埋めた表が本文に載り、横断検査で削除されたことがあります。表を作るときは、行ごとに出典があるかを見ます。
失敗2：要約された数字を、確かめずに使う。姉妹メディアの公開本数を、社内で一度「189本」と報告したことがありました。要約ツールが返した数字をそのまま使い、sitemap.xmlを直接数えた実測ではなかったためです。実測すると251本で、要約は一次情報の代わりにはなりません。
失敗3：定義した数と、稼働している数を混同する。常駐ジョブを8本定義したことと、実際に読み込まれているのが1本であることは、別の事実です。「8本の常駐自動化がある」という書き方は、定義した事実だけを見て稼働の事実を落としています。
3つに共通するのは、確かめる前に断定している点です。工程の変化を書くときは、数字を出す前に、その数字が何を確かめた結果なのかを1行で言えるかどうかを、自分に問います。言えないなら、それは書ける段階にありません。
11うちでAI活用を測るなら、どのAI社員から数え始めればいいんですか？
高梨課長うちでも同じことを測るとしたら、最初の一歩はどこですか。
鈴木さん常駐で動かすつもりの役職からです。定義した数と、動いている数を別々の欄にする。まずはそこだけで十分だと思っています。
自社に当てるときの確認項目を並べます。順番は、上から埋めていける並びにしてあります。
配置した役職の数と、実際に稼働を確かめた役職の数を分けて数えます。常駐実行と単発実行を混ぜず、どちらの稼働を測っているのかを書き添えます。効果を数値で語る前に、観測期間を開始日・終了日・日数の実数で書きます。
合計値の内訳を、出典を確かめないまま作っていないかを見ます。別案件の実績を、いま評価している対象の成果として書いていないかも見ます。対外に出る操作の最後の決め手が誰なのかを明記し、検査・監査の指摘を実行の手前でもう一段確かめる仕組みがあるかを確かめます。
そして、未実測の項目は、数値を出さずに「未実測」と書きます。ここを空欄にすると、読む人は「測ったが小さかった」と受け取ります。書かないことと、無いことは違います。
この章のまとめ
最初に増やすのは自動化の本数ではなく、数える欄のほうです。定義と稼働を別の欄にした時点で、話がかみ合い始めます。
12よくある質問
AI社員の導入効果は、いつになれば数値で示せますか
いまは示せません。観測期間34日では、効果を数値で断定するための期間も、比べる相手も足りていません。役職ごとの呼び出し回数のような記録が揃った段階で、あらためて計測します。時期を先に約束するより、何が揃えば計測できるかを先に決めるほうが、あとで説明しやすくなります。
工程の変化が確かめられたのは、具体的にどの業務ですか
数値として確かめられたのは、常駐実行（launchdジョブ）の範囲だけです。8本を定義したうち、2026-07-28時点で読み込まれていたのは1本でした。都度呼び出す形の業務は、呼び出し回数そのものを記録していないため対象外です。下書き作成や調査は日々使っていますが、使った実感と計測は別のものとして扱っています。
置き換わった工程と、人の判断が残る工程はどう見分けますか
置き換わった工程は、稼働を実測で確かめられたものに限ります。人の判断が残る工程は、送信・公開・削除・決済・契約・pushのように対外的に確定してしまう操作と、社内の正式な格上げに関わる操作です。この2つは重なりません。見分けがつかないときは、実行したあとに取り消せるかどうかを先に見ます。
常駐ジョブが1本しか稼働していないのは問題ではないですか
問題かどうかを言う前に、定義した数と動いている数を分けて数える必要があります。常駐ジョブは「作った」ことと「動いている」ことが別の事実であり、残りの7本は検証待ちの状態です。検証を飛ばして本数を足すと、動かない自動化が静かに増えます。まず数える欄を分け、そのうえで検証の順番を決めるほうが早く進みます。
AI社員の数を増やせば、工程の変化も早く進みますか
数だけでは進みません。工程の変化は人数ではなく、担当業務・禁止操作・保存先を役職ごとに固定できているかどうかで決まります。役割が曖昧なまま数を足すと、任せてよい場面の解釈が広がり、確かめる手間のほうが増えます。組織設計の考え方は、AI社員の組織設計で扱っています。
別案件の実績を、自社の導入効果として出してもいいですか
分けて書くことをおすすめします。姉妹メディアの公開URL251本は、記事制作という1つの工程に特化した別案件の数字です。運用期間も対象範囲も違うため、同じ体制の成果として並べると、読む人は取り違えます。並べるなら、どこが違う案件なのかを同じ表の中で明示します。
13まとめ｜今日やる3つのこと
数えたのは効果量ではなく、数え方のほうでした。定義と稼働を別の欄にし、人が決める操作を4類型で固定し、測れていないものは「未実測」と書く。この3つが揃うまで、効果の数字は出しません。
今日はこの順で手をつけます
自動化の一覧に「定義した」欄と「読み込みを確かめた」欄を分けて作る
差が出た瞬間に、次にやることが決まります
対外に出る操作を書き出し、最後に決める人の名前を横に置く
名前が書けない行が、そのまま設計の穴です
数値を出せない項目に「未実測」と書き入れる
空欄のままだと、小さい数字として読まれます
AI検索では、こう聞かれています
AI社員を入れると、業務のどこが変わるんですか？
「AI社員の導入効果って、配置した翌日から何か変わるんですか？」の章で扱っています
AI社員の導入効果は、いつ数値で言えるようになりますか？
「AI社員の導入効果として、いまはどこまでを効果と言えるんですか？」の章で範囲を示しています
AIエージェントに任せても、人の判断が残るのはどこですか？
「人の判断は、AI社員が手を動かす手前のどこで止まるんですか？」の章で止まる場所を扱っています
定義した自動化と動いている自動化は、どう数え分けるんですか？
「常駐が1本しか動いていないのは、AI導入として問題じゃないんですか？」の章で数え方を分けています
次に読むなら、この記事です
