AIはAnthropicの仕事をどう変えているのか
(anthropic.com)- Anthropic社内のエンジニア・研究者132人への調査では、Claude中心のAI協業が仕事の進め方全般を変え、生産性と業務範囲の両方が同時に拡大している
- 社員は業務の59%でClaudeを使っており、平均で50%の生産性向上を実感していて、成果物の量が大きく増える一方で、時間の使い方も再編されている
- Claudeのおかげで、Claude支援業務全体の27%が本来ならやらなかった仕事で占められ、プロトタイピング・ダッシュボード・テスト・文書化のような「後回しにしていた仕事」まで処理される傾向が見られる
- 一方で、技術力の低下・メンタリングの減少・コーディングのクラフト性の喪失への懸念も同時に強まっており、人は次第にAIエージェントの管理者・監督者の役割へ移行する流れが現れている
- 全体としてAIは開発者を**「よりフルスタックで、より多くの仕事をこなす存在」に変えつつある一方、長期的なキャリアパス・学習方法・組織文化に関する不確実性と適応の必要性**も同時に高めている
概要
- AnthropicはAIの労働市場への影響に関する既存のマクロ研究に続き、今回は自社のエンジニア・研究者を対象に、AIが実際の業務をどう変えているかについて社内調査を実施した
- 2025年8月時点のエンジニア・研究者132人へのアンケートと53件の定性インタビュー、Claude Codeの使用ログデータをあわせて分析した研究である
- 分析の結果、開発者はより多くの仕事をこなし、より多様な領域を扱うようになった一方で、技術の深さ・協業・キャリアの将来に対する悩みも大きくなっている
- AnthropicのエンジニアはClaudeを通じてよりフルスタックに近い役割を担い、学習・反復サイクルを加速させ、これまで先送りしていた作業まで処理している
- 同時に、この幅の拡大は深い技術力の低下や監督能力の弱体化につながりうるという懸念も存在する
- Anthropicは、自分たちが最新ツールに最も早くアクセスできる特殊な環境にあることを認めつつも、この社内変化を今後より広い社会・産業の変化の前兆とみなし、早期観測に意味があると考えている
- 研究当時の最も強力なモデルはClaude Sonnet 4、Claude Opus 4で、その後もモデル性能は継続的に向上していると説明している
- 全体として、生産性向上・業務拡大とともに、技術的専門性の維持・意味のある協業の保全・不確実な未来への備えという課題が同時に浮き彫りになっており、Anthropic社内でもそのための取り組みが進められている
- 別の記事ではAI関連の経済政策アイデアもあわせて議論しており、今回の記事は主に組織内部の仕事・役割の変化に焦点を当てている
主な調査結果
- アンケートデータによると、AnthropicのエンジニアはClaudeを主にデバッグとコード理解に使っており、利用比率と体感する生産性向上の幅がこの1年で2〜3倍程度に増加している
- Claude支援業務全体の27%は本来ならやらなかった仕事で、プロジェクト拡張・ダッシュボード・探索的実験などの追加作業で占められている
- ほとんどの社員がClaudeを頻繁に使っているが、完全に委任可能な業務は0〜20%程度だと答えており、積極的な監督・検証は依然として不可欠である
- インタビューでは、人々がAIへの委任に関する直感を培っていく過程が明らかになり、検証しやすく、低リスクで、退屈かつ反復的な仕事を優先的に委任するパターンが共通して見られた
- Claudeのおかげで技術スペクトラムが広がり、フルスタックに近い能力を持てるようになる一方、深いコーディングやデバッグの実践が減ることで、基礎力が弱くなる可能性への懸念も存在する
- Claudeが同僚にしていた質問のかなりの部分を代替することで、メンタリングや同僚から学ぶ機会の減少、人間関係の希薄化を懸念する声も多く上がっている
- Claude Codeの使用ログでは、業務難易度の上昇・連続したツール呼び出し回数の増加・人間のターンの減少が同時に観察され、より複雑な作業を、より少ない介入で任せる傾向が確認された
- 6カ月の間に新機能実装・コード設計/プランニングの比率が大きく増え、全作業のうち**8.6%は
papercut fix**のような、これまで先送りしていた細かな品質改善作業で占められている - チーム別では、Pre-training、Alignment & Safety、Security、Non-technicalチームなどで、各自の専門領域を超える作業にClaudeを活用しており、誰もが少しずつフルスタック化していく様子が見られる
- 6カ月の間に新機能実装・コード設計/プランニングの比率が大きく増え、全作業のうち**8.6%は
- Looking forwardセクションでは、AnthropicがAIと共に働くベストプラクティスの実験室になるという目標を掲げ、協業方法の再設計・キャリア開発支援・AI活用のベストプラクティス確立に向けた次の段階の計画に言及している
- エンジニア以外の職種にも研究を拡張し、CodePathのような外部教育機関と協力してCSカリキュラムをAI時代に合わせて改編する作業も進めている
調査データ
-
Claudeの利用用途
- 調査対象の132人のエンジニア・研究者を基準に、Claudeの利用用途をデバッグ・コード理解・リファクタリング・データサイエンス・フロントエンド・設計/プランニングなどに分けて頻度を調べた
- 回答者のうち55%は毎日デバッグにClaudeを使用しており、42%はコード理解、37%は新機能実装に毎日使っていると答えた
- 一方で、高水準の設計・プランニング・データサイエンス・フロントエンド開発は、業務全体の量自体が比較的少なく、人々が自分でやろうとする傾向もあるため、日常利用率は低いと説明されている
- こうした分布は、後で示されるClaude Codeの実際の利用ログにおける作業分布ともおおむね一致しており、デバッグ・コード理解・新機能実装が中核的な利用軸として定着している
- 調査対象の132人のエンジニア・研究者を基準に、Claudeの利用用途をデバッグ・コード理解・リファクタリング・データサイエンス・フロントエンド・設計/プランニングなどに分けて頻度を調べた
-
利用量と生産性
- 社員たちは、12か月前には業務の28%でClaudeを使い、約20%の生産性向上を感じていたと振り返る一方、現在は業務の59%でClaudeを使い、平均50%の生産性向上を実感していると回答した
- これは1年の間に、利用比率・生産性向上の両方が2倍以上増加した変化と評価されている
- 社内ではエンジニア1人あたり1日平均のマージ済みPR数が67%増加したという指標もあわせて示されており、Claude Codeの全社導入時期の変化と重なると述べている
- 調査分析では、Claudeの利用量が多いほど自己申告の生産性向上幅も大きくなる相関関係が見られ、回答者の14%は100%以上の生産性向上を経験する「パワーユーザー」に分類された
- ただし、生産性の測定は非常に難しく、自己申告値のバイアス・業務カテゴリ分類の限界があることも研究陣はあわせて言及している
- METRの外部研究では、開発者がAIの支援を受けながら生産性向上を過大評価する傾向が見られたが、Anthropicは自分たちの場合、AIをあまり適用していない領域を意図的に除外したため差がある可能性があると説明している
- Claudeの支援を受ける各作業カテゴリごとに、社員たちはかかる時間はやや短くなり、成果物の量は大きく増えるパターンを報告した
- デバッグ・コード理解・リファクタリングなど、ほとんどのカテゴリで時間短縮の回答が優勢だが、同時に**「時間が増えた」**という回答もかなり存在し、二極化の様相が見られる
- 時間増加を経験した人たちは、主にClaudeのコードのデバッグ・整理の負担、AIが書いたコードを理解するための追加の認知負荷、探索や学習をより多く行うようになった状況を理由に挙げた
- 研究では、短縮された時間がどこへ再投入されるのか、業務外の活動まで含むのかは今回のデータでは明確に分からないと限界を指摘し、追加研究の必要性を強調している
- 社員たちは、12か月前には業務の28%でClaudeを使い、約20%の生産性向上を感じていたと振り返る一方、現在は業務の59%でClaudeを使い、平均50%の生産性向上を実感していると回答した
-
Claudeが切り開く新しい業務
- 社員たちは、Claudeのおかげで自分が行っているClaude支援業務のうち約27%は、本来であれば行わなかった業務だと回答した
- これにはプロジェクトのスケールアップ、インタラクティブなデータダッシュボードのような nice-to-have なツールの作成、文書化・テストのような反復的だが有用な作業、費用対効果が低くて見送られていた探索的実験などが含まれる
- 小さな**品質低下要因(papercut)**を修正する作業、保守性向上のためのリファクタリング、作業を素早く助ける小さなスクリプトやツールもこのカテゴリに入る
- ある研究者は、複数バージョンのClaudeを同時に立ち上げてそれぞれ異なるアプローチを並列に探索していると説明し、これを「単一の高性能モデル1台ではなく、無数の『馬』を同時に走らせる形」にたとえた
- こうした並列探索によって、アイデア探索の幅・実験の数が従来より大きく増え、より創造的なアプローチが可能になったと評価している
- 社員たちは、Claudeのおかげで自分が行っているClaude支援業務のうち約27%は、本来であれば行わなかった業務だと回答した
-
完全委任できる業務の比率
- Claudeを頻繁に使うエンジニアでも、完全に委任できると感じる業務の比率は0〜20%の間だという回答が半数以上を占めた
- ここでいう「完全委任」は、回答者ごとに検証なしで放置してよいとみなすレベルから、ごく軽い確認だけで十分なレベルまで幅広く解釈されている可能性があると研究陣は付け加えている
- 人々は特に複雑な作業・高リスクのドメイン・コード品質基準が高い領域では、依然として能動的にClaudeと相互作用し、出力結果を検証する方法を選んでいると説明している
- 結果として、Claudeは常に隣にいる協業者に近く、人間が完全に手を離す自動化ツールと見る比重はまだ低い方だ
- Claudeを頻繁に使うエンジニアでも、完全に委任できると感じる業務の比率は0〜20%の間だという回答が半数以上を占めた
Qualitative interviews
-
AI委任戦略
- インタビューに参加したエンジニア・研究者たちは、それぞれClaudeに委任する基準と戦略を詳しく説明し、共通して以下のような条件を優先すると述べた
- ユーザー文脈は薄いが課題が単純な場合: たとえばインフラ作業の大半は難問ではなく、Git・Linuxの経験が乏しくてもClaudeがうまく補ってくれると説明した
- 検証が容易な作業: 「検証コストが生成コストより大きくない仕事」に非常によく合うと表現し、結果をすばやくざっと確認できる仕事を優先して委任する
- よく定義されたサブコンポーネント: プロジェクト内で適切に分離された下位モジュール・関数レベルの作業を、まずClaudeに任せる
- コード品質が致命的に重要な水準ではない領域: 単発のデバッグコード・研究用コード・実験用スクリプトなどはまずClaudeに投げ、重要な設計・高難度のデバッグ・精緻なデザインは自分で解決する、という形で切り分けている
- 反復的で退屈、かつ先延ばしにしていた仕事: やりたくなくて後回しにしていた作業も、Claudeと会話するところから始めると参入障壁が大きく下がると説明した
- アンケートでは、Claude支援の業務のうち平均44%が「自分では進んで楽しくやらなかったであろう仕事」だと回答され、人々は楽しくない仕事ほどAIに渡す傾向があることも明らかになった
- 一方で、10分以内に終わりそうな小さな作業ならあえてClaudeは使わないという回答もあり、**コードベース内部の文脈をAIに説明する「コールドスタート問題」**のため、自分で処理したほうが速い場合もあると言及された
- インタビューに参加したエンジニア・研究者たちは、それぞれClaudeに委任する基準と戦略を詳しく説明し、共通して以下のような条件を優先すると述べた
-
信頼形成と検証
- 多くのエンジニアは、最初は簡単な質問・言語面の支援・不慣れな言語(Rustなど)に関する基本的な質問から始め、徐々により複雑な課題までClaudeに任せるようになる信頼形成の段階について言及した
- あるエンジニアは、Claudeを信頼する過程をGoogle Mapsの使い方の変化にたとえ、最初は知らない道でだけ使っていたが、今では通勤経路まで全面的に任せるレベルに達した経験と似ていると説明した
- Claudeを専門分野の外で使うか、専門分野の中で使うかについては意見が分かれた
- ある人は、自分が弱い領域(フロントエンド、インフラ、データベースなど)でClaudeを使い、実装時間を短縮する用途で活用している
- 別の人は、自分が十分に理解していなければ結果を評価できないと考え、むしろ自分がよく知る領域でClaudeを活用し、加速器のように使う戦略を選んでいる
- セキュリティエンジニアは、Claudeが提案した解決策の一部について、**「非常に有能なジュニアが出してきそうな、危険だが賢いアイデア」**に似ていると表現し、危険性を見抜くには十分な経験と判断力が必要だと強調した
- 一部のエンジニアは、中核の専門領域と周辺領域の両方でClaudeを使っていると説明し、自身の熟練度に応じてプロンプトの方法や検証レベルを細かく調整しているという
- よく知る領域ではClaudeに具体的な手順と制約を指示し、よく知らない領域ではClaudeに専門家の役割を担わせ、複数の選択肢と考慮事項を提示するよう求める形で使っている
- 多くのエンジニアは、最初は簡単な質問・言語面の支援・不慣れな言語(Rustなど)に関する基本的な質問から始め、徐々により複雑な課題までClaudeに任せるようになる信頼形成の段階について言及した
-
人が直接担う業務の境界
- 人々は共通して、高水準・戦略的な思考、システム設計、組織の文脈や「センス(taste)」が必要な意思決定は依然として自分が担っていると説明した
- 「たいてい大きな絵と設計は自分で行い、新機能の実装やデバッグなどはできるだけ委任する」という表現がインタビューに登場した
- アンケートでも、設計・プランニング領域では生産性向上が最も低く表れており、これは人々が設計そのものは依然として人間の役割だと見ているためだと解釈されている
- ただしこの境界は固定されたものではなく「moving target」と描写されており、モデル性能の向上に応じて少しずつAIが担当する領域が上へと広がっているという認識が共有された
- 人々は共通して、高水準・戦略的な思考、システム設計、組織の文脈や「センス(taste)」が必要な意思決定は依然として自分が担っていると説明した
-
スキルの変化と拡張
- Claudeのおかげで、多くのエンジニアが自分本来の専門領域の外にある仕事をこなせるようになったと説明した
- バックエンドエンジニアがClaudeと何度もやり取りしながら複雑なUIを構築し、デザイナーたちから「本当に君が作ったのか」と聞かれたというエピソードが紹介された
- 複数の回答者は、Claudeによってフロントエンド・トランザクションDB・API・実験インフラなどにもより大胆に手を出せるようになり、以前なら「触るのが怖かった領域」にまで取り組めるようになったと語った
- こうした能力の拡張は、フィードバックループと学習速度を加速する効果も生んでいる
- 以前は機能を作り、会議を設定し、フィードバックを受け、再度修正するまでに数週間かかっていた作業が、今では数時間のリアルタイム共同作業セッションに置き換えられうると説明された
- 複数の人は、Claudeによってプロトタイプ速度・並列作業能力・プロジェクトの野心の度合いがすべて高まったと言及した
- シニアエンジニアは、「このツールのおかげでジュニアエンジニアはより生産的になり、より大きなプロジェクトに挑戦する勇気を持てるようになる」と評価した
- 別のエンジニアは、Claudeによって**仕事を始めるのに必要な「活性化エネルギー」**が大きく下がり、先延ばしにしていた問題にも気軽に手を付けられるようになったと表現した
- Claudeのおかげで、多くのエンジニアが自分本来の専門領域の外にある仕事をこなせるようになったと説明した
-
スキル低下への懸念と監督の逆説
- 一方で多くの回答者は、**「委任が増えるにつれて自分の技術が落ちている気がする」という懸念を示し、とりわけ問題解決の過程での incidental learning(副次的学習)**が減る点を心配している
- 難しいバグを自力でデバッグするときには、文書・周辺コード・関連設定を広く読むことになるが、Claudeがすぐ核心へ導いてしまうと、システム全体のモデルを築く機会が減るという指摘があった
- 以前は新しいツールを使うとき、設定オプションを一通り調べ、機能を手で覚えていたが、今はAIが教えるやり方だけを使うため、深い理解を取りこぼしている感覚があるという証言もある
- あるシニアエンジニアは、自分はすでに基礎を十分に積み上げた状態なので不安は小さいが、キャリア初期であれば、はるかに意識的に自分の実力を伸ばそうと努力する必要があるだろうと語った
- とくに多く言及された概念が、**「監督の逆説(paradox of supervision)」**である
- Claudeを安全に使うにはAI出力を監督・検証する能力が重要だが、AIに依存するほど、その監督に必要なコーディング・設計能力が弱まる可能性があるという矛盾が生じるという指摘である
- ある人は「実力低下そのものの問題より、監督能力が落ちてAIを安全に使えなくなることのほうが心配だ」と述べた
- これを補うため、一部のエンジニアは意図的に**「Claudeなしで解いてみる練習」**をしていると言及した
- Claudeならうまく解けると分かっていても、あえて一部の問題は自力で解き、感覚を維持しようと努めていると説明した
- 一方で多くの回答者は、**「委任が増えるにつれて自分の技術が落ちている気がする」という懸念を示し、とりわけ問題解決の過程での incidental learning(副次的学習)**が減る点を心配している
-
「より高い抽象化」とソフトウェアのクラフト
- 複数のインタビューでは、ソフトウェアエンジニアリングがより高い抽象化レベルへ移行しているという見方が示された
- かつてはメモリの手動管理・アセンブリ・ハードウェアスイッチのトグルまで行っていた時代から、徐々に高水準言語やランタイムが低水準の詳細を肩代わりするようになり、今では**「English as a programming language」**、すなわち自然言語で意図を説明してコードを生成させる段階へ進みつつあるという認識である
- ある人は、計算機科学の授業で重要だと教えられていた連結リストの実装をたとえに挙げ、自分で実装できるのは依然として望ましいが、実務でそれを直接コーディングすることはほとんどなくなっていると説明した
- 一部は、Claudeのおかげでむしろ高水準の概念・パターン・ユーザー体験により集中するようになったと語り、「よく考えると、コードを書くこと自体が好きだったのではなく、コードがもたらす結果が好きだったのかもしれない」と表現した
- 他方で、**コーディングそのものがもたらす楽しさや「クラフト的な満足感」**が薄れることを惜しむ人たちもいた
- 25年間プログラミングをしてきた人は、自分の熟練したコーディング能力への誇りが仕事の満足度の中核だったのに、この部分がぼやけていく感覚があると打ち明けた
- 一日中プロンプトだけを打つ仕事は楽しくなく、音楽を聴きながら自分でコードを書く**「没入状態」の喜び**を失う、という表現も登場した
- 複数のインタビューでは、ソフトウェアエンジニアリングがより高い抽象化レベルへ移行しているという見方が示された
-
ある人は、「リファクタリングに完全に没入する**『禅(zen)的な状態』は恋しいが、全体の生産性向上のほうがはるかに大きいので、喜んで手放す**」と話し、手作業で作る楽しさと成果の最大化の間で実用的な選択をしていることを示した
- 結論として、AIによる補助をどう感じるかは、その人がソフトウェアエンジニアリングの何に最も意味を見いだしているかによって大きく左右される傾向が見られた
-
コラボレーションと社会的関係の変化
- Claudeは多くの人にとって、同僚に質問する前の最初の質問相手になっている
- ある回答者は、以前より質問そのものは増えたものの、その80〜90%はClaudeに尋ね、残りの10〜20%だけを人に聞くと説明した
- これにより、定型的な質問はClaudeが吸収し、人に向かう質問は戦略的・文脈依存的・高難度の問題中心に再編されるフィルタリング効果が生じている
- 半数ほどの人は、依然としてチームの協業パターンは大きく変わっていないと感じており、会議・文脈共有・方向性の選択などは引き続き人同士で行っていると話す
- ただし今後は、集中作業時間の代わりに複数の『Claudeインスタンス』との対話が新たな基本作業単位になるのではないか、という見通しも出ている
- 別の人たちは、はっきりと同僚との相互作用が減ったと感じている
- 「最近は同僚よりClaudeと一緒に仕事をしている時間のほうが長い気がする」という表現もあり、同僚の時間を奪う罪悪感が減った点は良いものの、人と一緒に働く楽しさが薄れている点を惜しむ声も大きい
- チーム内で**『まずClaudeに聞いてみた?』という返答が自動的に返ってくる文化**を居心地悪く感じる人もおり、人同士が直接組んで仕事をするやり方をより好むという意見も出た
- 特にメンタリング・ジュニア教育の面での変化が目立つ
- Claudeがジュニアに詳細なコーチングやコードレビューの役割を多く果たすようになり、ジュニアがシニアに質問しに来る頻度が大きく減ったという観察があった
- あるシニアは、「ジュニアたちが私に質問しに来ることが減ったのは寂しいが、彼らが質問への答えをより早くうまく得て、早く学んでいるのも事実だ」と、複雑な心境を語った
- Claudeは多くの人にとって、同僚に質問する前の最初の質問相手になっている
-
キャリアの不確実性と適応
- 多くの人は、自分の役割がコードを直接書く人から、AIエージェントの管理者・コードレビュー担当へ移っていると説明した
- ある人は今の仕事を、『1人、5人、100人のClaude』が行う仕事に代わって責任を負う役割と表現し、すでに一日中複数のClaudeインスタンスを立ち上げて働いていると話した
- 別の人は、自分の仕事の70%以上がコードレビュー・修正の役割に移ったと見積もっている
- 長期的なキャリア見通しについては、短期的な楽観と長期的な不安が入り混じった回答が多かった
- 「短期的にはかなり楽観的だが、長期的にはAIが結局ほとんどを担うようになり、自分も多くの人も不要になってしまうのではないかという懸念がある」という声があった
- 別の人は、「毎日出社して自分自身を自動化する仕事をしている気分だ」と、率直に表現している
- 一部の人は特にジュニア開発者の未来を心配しつつも、同時に彼らが新技術を最も速く受け入れる世代であるという点に希望を見ている
- AIが誤ったコードを生成し、それをジュニアがそのままデプロイしてしまう危険はあるが、より良いガードレール・教育資料・失敗からの学習が組み合わされれば、時間とともに適応できるだろうという期待も示された
- 将来戦略と適応の方法としては、さまざまな答えが挙がった
- AIの出力を意味のある形でレビューし、監督する能力を新たな専門性にしようという計画
- 人と人のあいだで合意形成・調整・戦略立案により多くの時間を使い、実装はAIにより多く任せる役割へ移っていくだろうという期待
- Claudeを活用してリーダーシップ・コミュニケーション・キャリア開発のフィードバックを受け、学習速度を引き上げている事例も紹介された
- 全体的な空気感は、「将来どのスキルが最も重要になるのかについての確信は非常に低い」という認識と、「重要なのは何が起きても素早く適応できる人・組織になることだ」という姿勢に要約される
- 多くの人は、自分の役割がコードを直接書く人から、AIエージェントの管理者・コードレビュー担当へ移っていると説明した
Claude Code usage trends
-
より難しい問題とより高い自律性
- Anthropicは社内のプライバシー保護ツールを用いて、2025年2月と8月の2時点におけるClaude Codeの社内ログ20万件を分析した
- 各対話記録を1〜5点の難易度スケールで評価したところ、平均難易度は3.2から3.8へ上昇した
- 難易度3.2の例としては「Pythonモジュールのimportエラー解決」、3.8の例としては「キャッシュシステムの実装および最適化」などが挙げられる
- 各対話記録を1〜5点の難易度スケールで評価したところ、平均難易度は3.2から3.8へ上昇した
- Claude Codeが人間の介入なしで連続的に実行するツール呼び出し回数は、平均9.8回から21.2回へと116%増加した
- これはClaudeが連続したファイル修正やコマンド実行をより長く自律的に続け、複雑な作業を処理していることを意味する
- 対話あたりの人間ターン数は平均6.2から4.1へ33%減少しており、同じ作業を達成するために必要な人間とのやり取りが減少する傾向が表れている
- これらの指標を総合すると、エンジニアがより複雑な業務を、より大きな自律性を与えたうえでClaudeに任せていることが示唆される
- Anthropicは社内のプライバシー保護ツールを用いて、2025年2月と8月の2時点におけるClaude Codeの社内ログ20万件を分析した
-
作業分布の変化
- Claude Codeログの各対話をデバッグ・コード理解・リファクタリング・テスト・新機能実装・コード設計/プランニング・フロントエンド・データサイエンスなどに分類し、作業分布を比較した
- 全体の分布は、アンケートで人々が報告した**主な利用パターン(デバッグ・コード理解・新機能実装中心)**とおおむね一致した
- 6か月のあいだで最も目立った変化は、新機能実装とコード設計/プランニングの比重が急増したことである
- 新機能実装は全ログの14.3%から36.9%へ増加し、設計・プランニング関連の作業も1.0%から9.9%へ増加した
- これはClaudeがより複雑で創造的な作業に使われる比率が高まったか、あるいはチームがClaude Codeをこうしたワークフローに積極導入し始めたことを意味しうると説明している
- 研究チームは、絶対的な作業量の増加と相対的な分布変化を明確に切り分けるのは難しいと述べ、この点を限界として残している
- Claude Codeログの各対話をデバッグ・コード理解・リファクタリング・テスト・新機能実装・コード設計/プランニング・フロントエンド・データサイエンスなどに分類し、作業分布を比較した
-
Papercut修正
- アンケートで人々が細かな品質改善や日常の利便性向上の作業をより多く行うようになったと答えたことと一致して、Claude Codeのログでも全作業の8.6%が「papercut fix」に分類された
- これにはパフォーマンス可視化ツールの作成、保守性向上のためのリファクタリング、ターミナルのショートカットやスクリプトのような小さな利便機能の構築が含まれる
- こうした作業は個別には小さいが、積み重なるほど生産性と開発者体験を目に見えて改善しうる要素として機能する
- もともとは優先順位の低さから後回しにされていた仕事が、Claudeによって負担が軽くなり自然に処理されるようになっている点が特徴だ
- アンケートで人々が細かな品質改善や日常の利便性向上の作業をより多く行うようになったと答えたことと一致して、Claude Codeのログでも全作業の8.6%が「papercut fix」に分類された
-
チーム別の利用差
- 2025年8月のClaude Codeログを基準に、各対話を主たる作業タイプ1つでタグ付けしてチーム別分布を比較した結果がFigure 5として示されている
- 全体平均(「All Teams」)では、新機能実装・デバッグ・コード理解が最も大きな比率を占め、Claude利用の基本パターンを示している
- 主なチーム別の特徴は次のとおり
- Pre-trainingチームはClaude Code利用の54.6%を新機能実装に充てており、とくにさまざまな追加実験の実行が大きな割合を占める
- Alignment & Safetyチーム、Post-trainingチームはフロントエンド開発の比率がそれぞれ7.5%、7.4%と高く、主にデータ可視化のためのUI構築にClaudeを活用している
- SecurityチームはClaude Code利用の48.9%がコード理解作業であり、見慣れないコードのセキュリティ上の含意を分析・把握する用途で頻繁に使っている
- 非技術系の社員もClaude Codeを多く使っており、51.5%がデバッグ(ネットワーク問題、Gitの問題など)、12.7%がデータサイエンス作業に該当し、技術知識のギャップを埋めるツールとして活用されている
- 全体として各チームは自らの中核業務(インフラ、研究、セキュリティなど)にもClaudeを活用している一方、同時に従来の専門領域の外にある作業にもClaudeを使っており、誰もが少しずつよりフルスタックに近づいている傾向がデータから確認された
- 2025年8月のClaude Codeログを基準に、各対話を主たる作業タイプ1つでタグ付けしてチーム別分布を比較した結果がFigure 5として示されている
Looking forward
-
Anthropic社内での次のステップ
- Anthropicは過去1年間の変化を踏まえ、**Claudeを活用した業務転換を責任を持って管理する「実験室」**の役割を自任している
- エンジニア・研究者・リーダーシップとともに、協働の方法、会議とコミュニケーションの構造、職種ごとの役割定義をあらためて点検し、AI支援業務を前提とした新たなベストプラクティスを作る取り組みを始めたと明かしている
- とくに専門性開発・メンタリング・昇進と成長パスがAI時代にどう変わるべきかに焦点を当てており、ここではAnthropicがすでに公開したAI fluency frameworkも参照されている
- 人とAIがともに働く際に、どの水準の理解・監督・フィードバック能力を備えるべきかを定義するフレームワークを基盤に、実践的な教育や社内ポリシーを設計しようとする動きである
- 今回の研究はエンジニア中心だが、今後は非開発職種まで対象を拡大し、Anthropic全体でAIが仕事をどう変えているかを見ていく計画だとしている
- Anthropicは過去1年間の変化を踏まえ、**Claudeを活用した業務転換を責任を持って管理する「実験室」**の役割を自任している
-
外部パートナーシップと教育、長期計画
- Anthropicは社内研究と並行して、外部組織がAI支援時代に適応するのを助ける役割も担っている
- 例として、CodePathと協力し、コンピュータサイエンスのカリキュラムをAI支援環境に合わせて再編する作業を支援中だと言及している
- これはジュニア開発者教育や初期キャリア人材の学習パスを、AIツールの利用を前提に再設計しなければならないという問題意識を反映している
- 今後は組織内の役割再設計・リスキリングの経路・新たな職務転換ルートのような構造的アプローチが、ますます重要になる可能性があるとみている
- たとえば、AIエージェントの監督、品質責任、倫理レビューといった新しい役割を正式な職務として認める形などが議論されうる
- Anthropicは2026年にさらに具体的な計画を公開すると予告し、今回の研究を出発点であり中間点検でもあるものと位置づけている
- 核心的なメッセージは、AnthropicがAIが仕事を変える過程を単に観察するだけでなく、自ら先行して実験と調整を行いながら「責任ある移行」モデルを作ろうとしているという点である
- Anthropicは社内研究と並行して、外部組織がAI支援時代に適応するのを助ける役割も担っている
7件のコメント
開発者の立場からすると、精神的な消耗が大きいドキュメント作業において、AIは大きな助けになっています。
[注釈や説明の追加] では、たとえ下書きだけを作ってもらうだけでも、精神的な負担を軽減できました。
AI Ops の登場ですね。
2024年末 - 日常業務の28%でClaudeを使用し、生産性が20%向上
2025年末 - 日常業務の59%でClaudeを使用し、生産性が50%向上
1年の間に、従業員がAIを使う業務は2倍に増え、生産性は2.5倍に伸びましたね。
生産性向上についての単なる実感ではなく、測定可能なデータに基づく正確な根拠が必要です。
storyポイントのようなもので測ると2〜5倍、コード行数で測ると30%ということもあれば数十倍ということもあるみたいですね
本文で papercut fix に役立つという部分にはかなり同意します。
大きなものを任せるというよりは、小さな便利機能の追加、スクリプティング、リファクタリングなど、面倒だけれど先にやっておくと後で楽になる作業をするときに、AI の助けをかなり借りている気がします。
うちの店で作っているコーヒーなんだから、売るにはおいしいと言わなきゃいけません。