Anthropic社内調査 — Claudeを60%使うエンジニア132人が示す「AIマネージャー化」

Anthropicは2025年12月2日、自社エンジニア・研究者を対象にした内部調査「How AI Is Transforming Work at Anthropic」を公開しました。Claudeを開発する当事者が、自分たちの現場でClaudeをどう使い、何が変わり、何が痩せかけているかを書いた報告です。

中心にあるのは3点です。自己申告で生産性が平均約50%上がったこと。利用ログでは、Claudeが人の介入なしに進められる作業が約2倍に伸びたこと。そして、役割が「コードを書く人」から「複数のClaudeを見る人」へ寄る一方で、同僚への相談やメンタリングが減り始めたことです。

調査の対象はAnthropic社内に限られます。ただ、Claudeを業務に入れた企業が半年から1年後に当たる論点を、開発元が先に通っている事例として読めます。本記事では、調査の設計、主要な数字、実際に任せている仕事の線引き、利用ログの変化、社内で出ている懸念を順に追い、最後に自社へ持ち帰れる論点を挙げます。

調査の設計 — 回答者の偏りを先に知っておく

2025年8月に実施した調査は3層です。エンジニア・研究者132人へのアンケート、そのうち53人への質的インタビュー、約20万件の社内Claude Codeセッションの利用ログ分析で構成されます。

アンケートの132人は、社内Slackの複数チャンネルへの投稿で集まった68人と、20チームの5〜10人ずつに直接声をかけて得た64人(依頼207人、回答率31%)の合計です。インタビューは回答が早かった53人でした。

偏りは報告書自身が挙げています。

• 回答は匿名ではなく、全員が社員なので、Claudeの効果を高めに答える方向に傾きうる
• 12か月前の利用や生産性を思い出して答えるため、記憶のずれが入る
• Claude Codeのログは時期ごとの比率でしか比べられず、作業量の絶対的な増減は測れない
• 調査時点の最上位モデルはClaude Sonnet 4とClaude Opus 4で、その後の新モデルで傾向が動いている可能性がある

つまり、数字は「Claudeを使い込んだ社員の自己申告」と「実ログ」を突き合わせて初めて意味を持ちます。外部の企業がそのままの値を期待すると過大評価になります。それでも、使い込んだ場合にどこまで伸びるかの観測値としては貴重です。

数字で見る変化 — 利用の深さと「着手しなかった仕事」

数字

アンケートの主な数字

• 業務に占めるClaude利用

  28% → 59%

  12か月前と現在の自己申告

• 生産性向上

  +20% → +50%

  平均。+100%超が14%

• マージされたPR

  +67%

  1人1日あたり。Claude Code導入後

• Claudeなしでは着手しなかった仕事

  27%

  Claudeを使った仕事のうち

利用比率も生産性向上も、1年で2倍超になった計算です。なお、題名の「60%」は報告書の要約にある約60%で、詳細の数字は59%です。生産性が+100%を超えると答えた14%は、社内で「パワーユーザー」と呼ばれています。PR数の67%増は自己申告と別系統のデータで、方向が合っていることを裏づけます。

27%は、既存の仕事が速くなった話ではありません。手作業では割に合わず手を付けていなかった仕事を指します。拡張作業、あると便利な社内ツール(対話型のデータダッシュボードなど)、ドキュメントやテストのような地味だが有用な作業、手作業では割に合わない探索的な試作が挙がっています。

一方、委任の天井は低めです。「完全に任せられる」と答えた割合が0〜20%の人が半数を超えました。Claudeは常に隣にいますが、特に失敗の許されない仕事では、人が見張って検証する前提が崩れていません。

時間は減る人と増える人に割れる

時間配分の回答にはもう1つ特徴があります。ほぼ全てのタスクカテゴリで、時間は純減し、アウトプット量はそれより大きく純増しました。ただし個票を見ると、時間の節約は両極に分かれています。

くらべる

Claudeを使った作業の所要時間

節約が出る側

短くなる人

検証が早く済む仕事をClaudeに切り出している人です。確認コストが小さい作業ほど、節約が素直に出ます。

増える側

長くなる人

Claudeが書いたコードのデバッグや後始末に時間を使う人です。自分で書いていない分、理解に要る負荷も増えます。

長くなる側には、前向きな理由も挙がっています。「前なら即座に諦めていた作業を粘れるようになった」「テストを手厚くできる」「新しいコードベースを探索する時間が増えた」といった声です。節約できた時間の行き先(別のエンジニアリング作業か、Claudeとのやり取りか、仕事の外か)は、調査でも分かっていません。

報告書は、アウトプット量の増加のほうが明確だとみています。「デバッグ」のようなカテゴリ全体で答えているため、1回あたりの時間は少し短い程度でも、カテゴリ全体の産出は大きく増えうるからです。

何を任せ、何を手元に残すか

インタビューでは、任せる仕事に共通点がありました。外部の研究(METRの開発者実験)が、AIで生産性が下がる条件として挙げた要素と重なる点が目を引きます。METRの実験では、慣れたコードベースを扱う経験豊富な開発者が、AIによる向上を過大に見積もっていました。

線引き

Claudeに任せやすい仕事の条件

• 検証が安い

  「作る労力に比べて確認の労力が大きくない作業ならすごい」という声です。ざっと見て正しさを判断できる仕事が先に任されます。

• 品質が重要でない

  使い捨てのデバッグコードや調査用コードは、そのままClaudeへ回します。概念的に難しい作業や設計の問題は自分でやる、という切り分けです。

• 切り離されている

  他の部分から十分に独立したサブコンポーネントなら、まず任せてみる、という使い方です。

• 退屈で気が進まない

  アンケートでは、Claudeを使った仕事の平均44%が、自分では楽しめなかっただろう作業でした。逆に、楽しみな作業ほどClaudeを使わない傾向があります。

任せない側にも条件があります。見積もりが10分以内で済む作業は、プロンプトを書く手間のほうが重くなります。チーム固有の暗黙知が多い作業も、「コールドスタート問題」(Claudeがその文脈を最初から持たないこと)が壁になり、自分でやるほうが早いと語られています。

設計や、組織の文脈・センスが要る判断は、手元に残る傾向が強い領域です。アンケートでも、設計・計画の生産性向上は最も小さくなりました。ただし、この境界は「動く標的」だと本人たちが言っています。モデルが変わるたびに引き直されています。

任せ方には段階もありました。最初は知らない言語の簡単な質問から入り、いまはコーディング全般をClaude Codeでこなす人がいます。ある人はこれを、地図アプリに例えました。知らない道だけで使い始め、最後の1マイルだけ使い、いまは毎日の通勤路でも指示に従う、という流れです。Claudeにも同じ使い方が広がっているという話です。

Claude Codeの利用ログ — 自己申告より強い証拠

アンケートは自己申告に過ぎないため、報告書は実ログで裏を取っています。対象は2025年2月と8月のClaude Codeセッション計20万件で、プライバシーに配慮した分析ツールで処理されています。

数字

2025年2月 → 8月のClaude Code

• タスクの複雑さ(1〜5)

  3.2 → 3.8

  3.2は「Pythonのimportエラー調査」、3.8は「キャッシュ機構の実装と最適化」の水準

• 連続ツール呼び出しの最大数

  9.8 → 21.2

  +116%。人の介入なしにつなげる作業

• 人間のターン数

  6.2 → 4.1

  33%減

複雑な仕事ほど、人の介入が少なくなっています。報告書が「生産性向上を押し上げている可能性がある」と書くのは、この組み合わせのことです。

タスクの種類の比率も変わりました。新機能の実装は14.3%から36.9%、コード設計・計画は1.0%から9.9%です。注意したいのは、これが2025年2月から8月の半年間の変化で、前年比ではない点です。ログは時期ごとの比率でしか比べられないため、機能実装の絶対量が増えたとまでは言えません。報告書も、Claudeが上位の作業に強くなったためか、チームの使い方が変わったためかは切り分けられないと断っています。

もう1つの数字は8.6%です。Claude Codeの作業のうち、いわゆる「ペーパーカット修正」(性能の可視化ツールの作成、保守性のためのリファクタリング、ターミナルのショートカット作りなど、優先度は低いが日々の摩擦を減らす小さな改善)が占める割合です。

チームごとの使い方の違い

8月のログを主な作業ごとに分けて、チームで比べた結果も出ています。

• プレトレーニング担当は新機能の実装が54.6%で、その多くは追加の実験を回す作業
• アラインメント・セーフティ担当とポストトレーニング担当は、データの可視化を中心にフロントエンド開発が7.5%と7.4%
• セキュリティ担当は、コードの意味やセキュリティ上の影響を読み解くコード理解が48.9%
• 非技術職の社員はデバッグが51.5%、データサイエンスが12.7%で、ネットワークやGitの問題を自力で直せる場面が増えた

専門のチームは自分の本業にもClaudeを使いますが、使い方は本業の外側へも広がっています。研究者がデータを見やすくするためにフロントエンドを書く、といった形です。「全員がフルスタック化する」という見立ての根拠はここにあります。

役割の再定義 — 「書く人」から「マネージする人」へ

インタビューでは、自分を「AIエージェントのマネージャー」と呼ぶエンジニアが目立ちました。Claudeのインスタンスを常時いくつか動かしている人もいます。ある人は、自分の仕事が「新規コードの執筆」から「コードのレビューと修正」へ、7割以上移ったと見積もりました。別の人は、将来の役割に「1つ、5つ、あるいは100のClaudeの仕事に責任を持つこと」を挙げています。

専門外への進出も具体的です。バックエンド担当が、Claudeと対話しながら複雑なUIを作り上げた例があります。デザイナーから「これ、あなたが作ったの?」と聞かれ、「いや、Claudeです。自分はプロンプトを書いただけ」と答えたそうです。フィードバックの回し方も変わり、数週間かかっていた「作る・会議を設定する・直す」の往復が、同僚が同席する数時間の作業会に縮んだという証言もあります。

1人あたりの責任の幅が広がったので、仕事の測り方も変わる可能性があります。コード行数よりも、検証すべきPRの本数や、責任を持つ領域の広さのほうが実態に近づくかもしれません。

失われ始めているもの

生産性向上と並んで、3種類の懸念が語られています。

手を動かして身に付く力が減る

難しい問題を自力でデバッグすると、直接は関係のないドキュメントやコードを読むことになります。その時間に、システムの全体像が頭の中に組み上がります。Claudeがすぐ問題の場所まで連れて行くと、この「ついでの学び」が減ります。

ここで報告書が使うのが「監督のパラドックス」という言葉です。Claudeを安全に使うには監督が要り、監督するには、AIの使いすぎで衰えうるコーディングの力が要ります。ある人は、自分の力そのものより、AIを安全に使う能力への影響のほうを心配していました。

対策として、Claudeが解けると分かっていても、ときどきあえて頼まずに自分でやる人もいます。

見方は割れています。「抽象度が上がる過程の1つで、昔メモリー管理やアセンブリから離れたのと同じ」と受け止める人がいる一方、「文字どおり終わりを迎えた時代だ。25年プログラミングをしてきて、その力があることが仕事の満足感の中心だった」と惜しむ人もいます。

相談先がClaudeになり、同僚との接点が減る

あるエンジニアは、質問の80〜90%がClaudeに向かうと答えました。ルーチンの質問はClaudeが引き受け、同僚には文脈が重い複雑な相談が残る、という分業です。「チームへの依存は8割減ったが、残りの2割が決定的に重要なので、そこは直接話しに行く」という証言もあります。

チームの協働が変わらないと答えたのは約半数でした。ほかには、同僚との接点が減ったと語る人もいます。「Claudeに聞いた?が返事の定番になったのは好きではない」という声がある一方で、「同僚の時間を奪う罪悪感がなくなった」と歓迎する声もあります。

メンタリングへの影響は、シニア側の言葉に出ています。後輩が質問に来る回数は減りましたが、後輩は以前より的確に答えを得て、速く学んでいる、と。減ったのは相談の頻度であって、学習の質が落ちたかどうかは、この証言からは言えません。

キャリアの見通しが立たない

「短期的には楽観しているが、長期ではAIがすべてをこなし、自分を含む多くの人が不要になると思う」という声があります。「毎日、自分を失業させるために出社しているような気分だ」という言葉もありました。一方で、「若手の開発者は心配だが、新技術に最も貪欲なのも若手だ。職業としての先行きには楽観的だ」という意見も並んでいます。

具体的な対応策は人によって違います。AIの成果物をレビューする能力に特化する、人間同士の合意形成や戦略的な仕事に時間を回す、Claudeにキャリア面のフィードバックを求める、といった案が出ました。多くの人は、将来役立つスキルが何か、まだ見当がつかないと答えています。

Anthropicが次に取ると述べている手

報告書の結びで示された動きは3つです。エンジニア・研究者・リーダー層との対話を通じて、協働の組み立て方、専門性の育て方、AI併用のベストプラクティスを見直すことです。検討には「AI fluency framework」を参照します。もう1つは、調査をエンジニア以外の職種へ広げること。最後に、コンピューターサイエンスの教育を手がけるCodePathのような外部団体を支援することです。役割の移行や再教育の経路といった、構造面の選択肢も検討対象に挙がっています。

報告書は方向性を示した段階で、具体策は2026年に示すとしています。

Claude Codeとの関係 — 道具が組織の動き方を変える

調査の「AI」は、実体としてはClaude Codeです。アンケート回答者が使用の大半をClaude Codeだと答えたため、実ログの分析もClaude Codeに絞られました。20万セッションという規模は、社内で日常的に使われていることを示します。

Claude Codeを実務でどう組み込むかはClaude Codeワークフロー解説にあります。この調査は、その実運用を人と組織の側から見た記録です。

書く量が増えるほど、人の仕事は書くことから検証することへ寄ります。生産性を測る物差しも、書いた量から検証した量へ移る可能性があります。

Anthropicの他研究との接続 — 「使い手」を観測する内向きの動き

Anthropicが公開している利用の観測研究を並べると、対象が外と内に分かれます。

オーストラリアのレポートなどが「外の世界がClaudeをどう使うか」を見ていたのに対し、この調査は「自社内で何が起きているか」を見ています。AIの社会的影響を扱う同社の研究組織The Anthropic Institute(TAI)は、2026年3月に告知され、5月に研究アジェンダが公開されました。社内の経験を外部にも使える仮説に変える流れが、ここにつながっています。

訓練側の自己観測としては、Teaching Claude whyに見るアラインメント訓練の更新があります。社内調査は、その人間側に当たる1本です。

外部企業が持ち帰れる論点

母集団が限られるため、一般化には注意が必要です。それでも、次の4点はClaudeを業務に組み込む企業が先に考えておく価値があります。

• 生産性の指標を、コード行数から責任範囲(PR数、レビュー件数、担当領域の幅)へ置き換える
• 実装が速くなると人間のレビューが追いつかない場面が出るので、レビューの人員配置や自動化を先に用意する
• 「Claudeに聞く前に同僚に聞く」場面や、ペアプログラミング、コードレビューの頻度を意図的に残す
• 27%にあたる「Claudeがなければ着手しなかった仕事」を棚卸しして、投入に値するかを組織として判断する

報告書自身が、結果は他組織にそのまま当てはまらず、新モデルで傾向が動いている可能性があると述べています。自社で同じ設計の社内調査を回すときは、匿名にする、利用ログと並べて見る、といった点でこの調査より厳密にできます。

まとめ — 数字より先に、役割と学びの設計を見る

「生産性が50%上がった」より重要なのは、その内訳です。利用ログで見える変化は、人が介入せずに進む作業が増え、設計や新機能のような上位の仕事にClaudeが入ってきたことです。その代わりに、レビューと検証の比重が人間側に積み上がっています。2026年10月に公開された続報では、同社内で若手技術職の採用比率が下がったことも報告されています(Anthropic社内の雇用の変化)。導入を考える組織は、生産性の数字と同じ重さで、レビュー体制と若手の学びの場の設計を見ておく価値があります。