朝、AIに三つの仕事を頼む。昼には下書きもコードも比較表もそろっている。ところが夕方になっても、どれを採用してよいか決まらない。
作る速さは上がった。仕事が終わる速さは、思ったほど上がっていない。AIを使い込むほど、こんな場面が増えていないでしょうか。
Anthropicが10月16日に公開した社内調査「How employment is changing at Anthropic」は、この問題を考える具体的な材料になります。同社は、社員のAI利用、業務成果、採用記録、社内のやり取りなどを調べ、17人へのインタビューと合わせて報告しました。
注目したいのは、人がAIを動かす仕事から、AIの成果を見渡し、判断し、仕事の流れを組み直す仕事へ移っていることです。ただし、これはAI開発企業一社の観察研究です。どの会社でも同じ変化が起きる、AIが雇用をこう変える、と決めつける材料ではありません。
「AIが6倍働く」の数え方を確かめる
報告では、8月の社員が指示する対話型エージェントの稼働時間は、人の労働時間の6倍に達しました。子エージェントも合算しています。
ここでいう人の時間は、社員数に週40時間を掛けた推定です。AI側は推論やツール操作の稼働時間で、30分を超える待ち時間を除いています。図2とその注記に定義があります。
並列に動くAIの時間は積み上がります。同じ一時間でも、複数のAIがそれぞれ作業すれば合計は増える。したがって、6倍という値を、そのまま人6人分の成果や利益に読み替えることはできません。
さらに、報告は対話型セッションの経過時間のおよそ80%が、人の入力を待つ時間だったとしています。こちらは、セッション全体の時間からAIの活動時間を引いた別の指標です。「社員が勤務時間の80%を無駄にしている」という意味ではありません。
二つの値が照らすのは、供給能力と受け取り能力のずれです。AIが並列に成果を生み出しても、それを受け取り、次の判断を返す人は急には増えません。
新しいのは、生成の後にある仕事を見ていること
従来のAI導入では、文章が何分で書けたか、コードをどれだけ生成したかが分かりやすい成果でした。今回の調査は、その先に発生する仕事も見ています。
同社は、エージェントが出した文章を全部読むとどれほど時間がかかるかを推計しました。計算には1トークン当たり0.75語、毎分250語という前提を使っています。非技術職でも、出力量を読むだけで週の労働時間の半分を超える規模になったと報告しています。これは実測した読書時間ではなく、一定の読み速度を置いた換算です。日本語のトークンに、その係数をそのまま当てはめることもできません。
すると必要になるのは、長い回答をもう一つ増やすことだけではありません。どの案件が止まっているか、どの結果に根拠が足りないか、何を人が決める必要があるかを見えるようにする仕事です。
報告は、エージェントへの仕様作成、レビュー、監視画面や運用手順の整備などを「メタワーク」として集計しています。その比率は、平均的な社員の対話型セッションの10%から22%へ増えました。図7の分類は、2,000件の一行チャット要約を自動で判定したものです。勤務時間の22%を直接計測した数字ではありません。
ここからはAICompanyの解釈です。AI導入を評価するとき、生成物の量だけを見ていると、確認待ちの山を成果と数えてしまうおそれがあります。書き上がった下書きと、公開できる原稿は違う。テストを通った修正と、利用者の環境で安心して使える修正にも距離があります。
成果が増えたことと、AIだけの効果は分ける
報告は、エージェント導入後の社員の成果も調べています。例えば、導入したエンジニア192人を、調査期間中に導入しなかった74人と比較しました。導入時期は、月に少なくとも5回のエージェント利用があった最初の月で定義し、個人差と暦月の違いを統計的に調整しています。
それでも、導入は無作為ではありません。大きな案件が始まる人ほど先にAIを使うかもしれません。同社の事業拡大や、ほかの業務改善も同時に進んでいます。著者ら自身が、この選択の偏りを注意点として挙げています。
コード品質についても、削除や取り消しなどの指標で差が見つからなかったことと、品質全体が同等であることは別です。見逃した不具合、将来の保守負担、利用者にとっての価値まで、その指標だけでは決まりません。
採用の数字にも同じ注意が要ります。技術職の採用に占めるジュニアの割合は27%から9%へ下がりましたが、技術職の採用そのものは絶対数では増えたと報告されています。「割合が下がった」を「採用しなくなった」に置き換えてはいけません。
この調査を読む面白さは、派手な倍率を取り出すことより、AIが仕事のどこを速くし、どこに新しい負担を移すかを考えられる点にあります。
確認時間の予算で、小さく計算してみる
ここからは報告の再現実験ではなく、AICompanyが作った架空の計算例です。
一日に120件の成果物が届き、人が確認に使える時間を240分とします。会議や実作業を除いて確保できる時間、という設定です。一件6分ずつ確認すると720分かかり、その日の処理能力を480分超えます。
確認に3分しかかからない要約を付けても、必要なのは360分。短くしただけでは、まだ120分足りません。
では、すべての案件で自動チェックと根拠付きの短い一覧を用意し、人は各案件の一覧を15秒で確認、追加の精査が必要な30件には各6分を使う、と仮定したらどうでしょう。合計は210分です。自動チェックの計算時間や整備費用は、この人の確認時間には含めていません。
| 架空の確認方法 | 一日の確認時間 | 240分の予算との差 |
|---|---|---|
| 120件を各6分で確認 | 720分 | 480分超過 |
| 120件を各3分で確認 | 360分 | 120分超過 |
| 全件の一覧確認と30件の追加精査 | 210分 | 30分の余裕 |
同じ計算は、標準のPythonで実行できます。外部への通信やAI呼び出しはありません。
items = 120
budget = 240
review_minutes = {
"full": items * 6,
"short": items * 3,
"triage": items * 0.25 + 30 * 6,
}
for name, minutes in review_minutes.items():
excess = max(0, minutes - budget)
print(name, minutes, excess)出力は順に「720分、超過480分」「360分、超過120分」「210分、超過0分」です。この計算が示すのは時間の足し算だけです。15秒で必要な判断ができることや、追加精査が30件で済むことを実証したわけではありません。精査対象を見逃す仕組みなら、速くても使えません。
しかも30分の余裕は、相談の集中や手戻りですぐに埋まります。平均の時間が予算内なら必ず運用できる、という話でもありません。
明日試すなら、回答より「判断できる一件」を作る
記事制作なら、AIに本文だけを渡してもらう代わりに、今回変えた点、出典、未確認の主張、公開前に人が決める点を一緒に出してもらう。開発なら、変更理由、影響範囲、実行したテスト、実行できなかった確認をそろえる。
これは今回の報告から考えた運用案です。Anthropicがこの形式の有効性を比較実験で証明した、という意味ではありません。
最初は一つの繰り返し業務で十分です。成果物を受け取った時刻、確認を始めた時刻、採用した時刻、修正に戻した理由を記録します。AIが出した件数に加え、人の確認時間、採用できた件数、手戻り、確認待ちの件数を見る。下書きが増えた分だけ、確認待ちも増えていないかを確かめます。
要約から根拠に戻れることも欠かせません。「問題ありません」の一言では、何を確認したか分かりません。出典の該当箇所、テスト結果、変更前後の差へたどれる形にする。根拠が欠ける場合は、通過扱いにせず、確認待ちとして残します。
AIに任せる範囲と、人が決める範囲も、案件ごとに見えるようにしておきたいところです。下書きが完成したことと、公開や送信の判断が済んだことを同じ状態にしない。確認用の画面では、進んだ仕事と止まった仕事を両方見せる。AIの返事が元気な日ほど、未解決の案件が隠れていないかを見る価値があります。
短くまとめること自体を目標にすると、判断に必要な不都合まで消えてしまいます。必要なのは、短い入口と、確かめられる奥行きです。
人が決める時間を、最初から仕事に入れる
今回の調査から、AIを増やせば会社が何倍も成長するという結論は出せません。公開データだけでは社員の個別記録を追試できず、一社の結果がほかの職場にも当てはまるかも未確定です。AICompanyでも、社内データの再分析や組織での比較実験は行っていません。
それでも、導入後に観察すべき場所は具体的になります。AIの生成時間に加えて、人が確認し、根拠をたどり、決め直す時間を見ることです。
速いAIの隣に、読むものだけが積み上がっていく。その状態を避けるには、成果物の作り方と、受け取る側の仕事を一緒に設計する必要があります。次に増やすべきものはエージェントの台数なのか、それとも判断しやすい仕事の単位なのか。まず自分の確認待ちを見てみると、答えに近づけるはずです。
出典：Nathan Wilmers、Regina Catipon、Maxim Massenkoff、Peter McCrory、How employment is changing at Anthropic、2026年10月16日。数値と定義は本文の図2、図4、図6、図7および注記を参照。図と確認時間の計算例はAICompanyによる独自作成です。