Anthropic Research ・ 翻訳

AnthropicにおけるAIによるワークフローの変革

社内エンジニア・研究者132名を調査した一次データ。AIが「働き方の本質」をどう変えつつあるか、希望と懸念の両面から。

読了目安 約 25 分日本語訳

2025年12月2日

主要な知見

AIは私たちの働き方をどう変えつつあるのか。AIが経済に与える影響に関するこれまでの調査では、労働市場全体を俯瞰し、多種多様な職種を対象にしてきた。が、ここで視点を変えて、AI技術を最も早くから取り入れている組織の一つ——つまり「私たち自身」を詳しく分析してみたらどうなるだろうか。

自らにレンズを向け、2025年8月、私たちは132名のAnthropicのエンジニアとリサーチサイエンティストにアンケートを実施した。さらに53件の詳細な定性的インタビューを行い、内部のClaude Code利用データを分析することで、AIがAnthropicの現場をどう変えているのかを調査した。結論から言えば、AIの活用はソフトウェア開発者の仕事の本質を劇的に変えており、そこには希望と懸念の両方が混在している。

調査から明らかになったのは、大きな変革に直面している職場の姿だ。エンジニアのこなせる仕事量は大幅に増え、専門外のタスクも遂行できる「フルスタック化」が進んでいる。学習と試行錯誤のスピードは加速し、これまで放置されていたタスクにも手が回るようになった。一方で、こうした「幅」の広がりに伴うトレードオフを危惧する声もある。深い技術的能力が失われるのではないか、あるいはClaudeの出力を効果的に監督できなくなるのではないかという懸念だ。対照的に、より広い視野で、高いレイヤーから思考できる機会を歓迎する向きもある。また、AIとの協働が増えたことで同僚との協力が減ったと感じる者や、最終的には自分自身の仕事を自動化して消し去ってしまうのではないかと自問する者もいた。

もちろん、AIを作っている会社でAIの影響を調べるのは、ある種「特権的な立場」からの報告であることは自覚している。うちのエンジニアは最先端のツールにいち早く触れられるし、比較的安定した分野にいて、他業界に影響を与えるAI変革そのものを担っているからだ。とはいえ、こうした知見を調査・公表することには十分な意義があると思う。Anthropic内部のエンジニアに起きていることは、より広い社会変革を予見する「教訓に満ちた先触れ」になり得るからだ。私たちの知見は、あらゆるセクターで早期に対処すべき課題や検討事項を示唆している（ただし、付録の「限界事項」セクションの注釈は参照してほしい）。なお、データ収集時点ではClaude Sonnet 4とClaude Opus 4が最高性能のモデルだったが、能力は今この瞬間も進化し続けている。

高性能なAIは生産性向上という恩恵をもたらすが、同時に技術的な専門性の維持や、意味のある協働のあり方、そして学習やメンターシップ、キャリア形成に新しいアプローチが求められる不透明な未来への備えについて、多くの問いを投げかけている。これらの問いに対して社内で進めている初期段階の取り組みについては、後述の「今後の展望」で触れる。また、AI関連の経済政策に関する最近のブログ記事でも、潜在的な政策対応について考察している。

主要な知見

このセクションでは、調査、インタビュー、およびClaude Codeのデータから得られた知見を簡潔にまとめる。詳細なデータや手法、留意事項については後続のセクションで詳述する。

調査データ

定性的インタビュー

Claude Codeの利用トレンド

調査データ

私たちは、組織横断的に132名のエンジニアとリサーチサイエンティストを対象に、日々のClaude利用実態を把握するためのアンケートを実施した。リサーチ部門からプロダクト部門まで多様なチームに展開している。手法の詳細については付録の「限界事項」に記載したが、他の組織でも同様の調査ができるよう質問項目も公開している。

どのようなコーディングタスクにClaudeを使っているか？

「デバッグ」「コード理解（既存コードの解説）」「リファクタリング（構造の再構築）」「データサイエンス（データ分析やチャート作成）」などの各項目について、利用頻度を尋ねた。

結果、日常的に行われるタスクが浮き彫りになった。従業員の55%が毎日デバッグに、42%がコード理解に、37%が新機能の実装にClaudeを使用している。利用頻度が低かったのは、高度な設計やプランニング（おそらく人間が主導権を握りたい部分だからだろう）、およびデータサイエンスやフロントエンド開発（業務全体として頻度が低いためと思われる）だった。これは前述のClaude Codeの利用データとも概ね一致している。

（図1：各コーディングタスク（縦軸）における、デイリーユーザーの割合（横軸））

利用状況と生産性

自己申告データによれば、12ヶ月前は日々の業務の28%でClaudeを使い、生産性向上は+20%程度だった。それが現在では、業務の59%で活用され、平均して+50%の生産性向上を達成している。（これは、エンジニア一人当たりの1日のマージ済みプルリクエスト数が、Claude Code導入後に67%増加したという社内データとも大筋で整合している。）前年比で見ると驚異的な伸びだ。利用率と生産性には強い相関があり、分布の極端な例では、回答者の14%が「生産性が100%以上向上した」としている。彼らはいわば社内の「パワーユーザー」だ。

ただし、この知見（および以下の自己申告データ）には注意が必要だ。生産性を正確に測定するのは極めて難しいからだ（付録の限界事項を参照）。AI研究の非営利団体であるMETRによる最近の研究では、使い慣れたコードベースでAIを使う熟練開発者は、AIによる生産性向上を過大評価する傾向があることが示されている。とはいえ、METRが生産性を低下させる要因として挙げたもの（大規模で複雑な環境でのパフォーマンス低下や、暗黙知・文脈が必要なケースなど）は、うちの従業員が「Claudeには任せない」と答えたタスクの種類と密接に対応している。私たちの報告にある生産性向上は、従業員が「AIに何を任せるべきか」という戦略的なスキルを身につけた結果を反映しているのかもしれない——これはMETRの調査では考慮されていなかった要素だ。

興味深いことに、現在Claudeを使っているタスクにおいて「所要時間」と「アウトプット量」がどう変わったかを尋ねると、一つのパターンが見えてきた。ほぼすべてのタスクカテゴリーで、所要時間は純減し、アウトプット量はそれ以上に純増しているのだ。

（図2：タスク別の所要時間（左）とアウトプット量（右）への影響。横軸は自己申告による増減を示す。エラーバーは95%信頼区間。円の大きさは回答数に比例。）

しかし、生のデータを深掘りすると、時間の節約については回答が二極化していることがわかる。中には、Claudeを使ったタスクに「以前より大幅に時間をかけている」人もいるのだ。

なぜか。話を聞くと、Claudeが書いたコードのデバッグや後片付け（「適当にコードを生成させて、自ら袋小路に迷い込んだとき」など）に時間がかかることや、自分で書いていないコードを理解するための認知的負荷が増えることが理由として挙げられた。一方で、ポジティブな意味で時間をかけているケースもある。「以前ならすぐに諦めていたタスクを、Claudeのおかげで粘り強くこなせるようになった」という声や、より徹底したテストや新しいコードベースの探索に時間を使えるようになったという意見もあった。つまり、時間を節約できているエンジニアは「すぐに検証可能なタスク」をClaudeに切り出せており、逆に時間をかけているエンジニアは、AI生成コードのデバッグに苦戦しているか、あるいはClaudeに手厚い指導が必要な領域で戦っている、ということなのだろう。

また、節約された時間がどこに再投資されているのか（追加のエンジニアリング作業か、非エンジニアリング業務か、Claudeの出力レビューか、あるいは私生活か）については、今回のデータからは判然としない。私たちのタスク分類フレームワークでは、エンジニアの時間の使い道のすべてを捕捉しきれていないからだ。時間の節約という回答自体、自己申告による認識バイアスの可能性も否定できない。このあたりは今後の研究課題だ。

一方で、アウトプット量の増加はより明白で、かつ相当な規模だ。全カテゴリーで大きな純増が見られる。これは、人々が「個別のタスク」ではなく「カテゴリー（デバッグ全般など）」として報告していると考えれば納得がいく。つまり、デバッグという作業全体にかける時間は少し減らしつつ、その中で生成されるデバッグのアウトプット（成果）の総量は大幅に増やしている、というわけだ。生産性の直接測定は至難の業だが、このデータを見る限り、AnthropicにおけるAIによる生産性向上は、主に「アウトプット量の爆発的増加」によってもたらされていると言っていいだろう。

AIが「新しい仕事」を可能にする

私たちが気になっていたのは、Claudeが「質的に新しい種類の仕事」を可能にしているのか、それとも単に「人間がいずれやるはずだった仕事」をスピードアップさせているだけなのか、という点だ。

従業員の推定では、Claudeが関与した業務の27%は、AIがなければそもそも行われなかったはずのものだった。エンジニアが挙げた具体例は、プロジェクトの規模拡大、QOL向上のためのツール作成、ドキュメント作成やテストといった「有用だが退屈な」作業、そして手動ではコストが見合わない探索的調査などだ。ある社員は、以前は放置されていた「小さなトゲ（Papercuts）」、例えば構造の悪いコードのリファクタリングや、別のタスクを高速化するための小さなツール作成などができるようになったと語っている。利用データの分析でも、タスクの8.6%がこうした細かい修正であった。

また、あるリサーチャーは、Claudeを同時に何個も走らせて、一つの問題に対して異なるアプローチを並行して探索させているという。

「超高性能なモデルを単一の個体として、例えば『速い車』のように捉えがちだが、実は『100万頭の馬』を持っているようなものだ……。それによって、大量のアイデアを同時に試せるようになる。探索の幅が広がることで、仕事はより刺激的でクリエイティブになるんだ」

次節で見るように、こうした「新しい仕事」の多くは、エンジニアが本来の専門領域を超えたタスクに挑戦することを意味している。

どの程度の業務がClaudeに「完結」を委ねられるか？

利用頻度は高いものの、半数以上のエンジニアは、Claudeに「完全に任せられる（Fully delegate）」のは業務全体の0〜20%に過ぎないと答えている。（なお、「完全に任せられる」の定義には、検証が一切不要な状態から、軽い監視だけで済む状態まで、回答者によって解釈の幅があることには留意してほしい）。その理由として、エンジニアたちは、Claudeと対話しながら反復的に作業を進める必要があることや、特に出力がクリティカルな複雑なタスクにおいては徹底した検証が欠かせないことを挙げている。つまり、エンジニアはClaudeに丸投げするのではなく、密接に協働し、常にその成果をチェックしている。彼らは「完全に任せる」ことのハードルをかなり高く設定しているようだ。

定性的インタビュー

アンケートの結果から、大幅な生産性向上と業務パターンの変化が見えてきた。が、エンジニアたちが日々の現場でそれをどう実感しているのかという疑問は残る。この数字の裏側にある「人間的な側面」を探るため、アンケートに回答した53名のエンジニアとリサーチサイエンティストに詳細なインタビューを行い、職場の変化に対する彼らの本音を聞いた。

AIへの委任アプローチ

彼らは、Claudeをワークフローに組み込むためのさまざまな戦略を編み出しつつある。一般的に、以下のようなタスクがClaudeに任される傾向にある。

「自分があまり詳しくない（文脈がない）けれど、全体の複雑さ自体は低いと思えるものにClaudeを使う」 「インフラ周りの問題の多くは、難しくはないけれど自分がLinuxやGitに詳しくないから、Claudeがその経験不足をうまく補ってくれる」

「作成の手間に比べて、検証の手間が少なくて済むものには最高だ」

「プロジェクトの特定コンポーネントが他と十分に切り離されていれば、Claudeにやらせてみる」

「使い捨てのデバッグ用コードや研究用コードなら、即Claude行き。概念的に難しかったり、特殊なデバッグの仕込みが必要だったり、設計上の問題だったりすれば自分でやる」

「ワクワクする仕事ほど、自分でやりたくなる。逆に抵抗感を感じるタスクなら、Claudeと会話を始める方が楽だと気づくことが多い」 ※調査では、Claudeが支援した業務の平均44%が「自分では楽しめなかったであろうタスク」だった。

「10分以内に終わりそうなタスクなら、わざわざClaudeを使おうとは思わない」 「今の最大のネックは『コールドスタート』問題だ。自分のチームのコードベースに関する暗黙的な情報をClaudeは持っていない。完璧なプロンプトを練る時間をかけるくらいなら、自分でやってしまった方が早い」

こうした従業員たちの判断基準は、前述のMETRによる外部調査で示された「AIによる生産性低下の要因（開発者がコードベースに詳しすぎる、あるいはリポジトリが巨大で複雑すぎるなど）」と酷似している。インタビューを通じて得られたこれらの基準は、AIによる生産性向上の鍵が「適切なタスク選択」にあることを示唆している（今後の生産性調査において、この変数は慎重にコントロールされるべきだろう）。

信頼、されど検証

多くのユーザーが、時間の経過とともに徐々に複雑なタスクを任せるようになる「信頼の進展」について語っている。「最初はRustの基本的な質問から始めたが、今ではコーディングのすべてにClaude Codeを使っている」といった具合だ。

あるエンジニアは、このプロセスをGoogleマップなどの技術の普及に例えている。

「最初は知らない道（自分が知らないSQLの作成など）にだけ使っていた。自分が知っているPythonのコードには使わなかった。そのうち、だいたい知っている道だけど最後の1マイルが怪しいときにも使うようになった。今では毎日の通勤（日常的なコーディング）でも常に使っている。Googleマップが違う道を勧めたら、あらゆる選択肢を検討した結果だろうと信じて従う。今のClaude Codeの使い方もそれと同じだ」

エンジニアの間では、Claudeを「自分の専門分野内」で使うべきか「専門外」で使うべきかについて、意見が分かれている——。

実装時間を節約するために「周辺領域」でClaudeを使う人もいれば、出力の妥当性を検証できる自分の「得意分野」であえて使うことを好む人もいる（「Claudeが何をしているか完全に把握できる状態で使いたい」というわけだ）。あるセキュリティエンジニアは、Claudeが提案してきた解決策が「めちゃくちゃ賢いんだが、危なっかしい。極めて優秀なジュニアエンジニアが出しそうな危うさだ」と指摘していた。つまり、判断力と経験を備えたユーザーにしか、それが問題であると見抜けないようなケースだ。

一方で、タスクの種類を問わずClaudeを使い倒すエンジニアもいる。「とりあえずコードの問題にはすべてClaudeで初撃を入れる」という実験的なスタンスもあれば、自分の習熟度に応じてアプローチを変えるパターンもあるようだ。

「自分の専門分野（コアスキル）では、結果が予測できるしエージェントをうまく誘導できるので、加速装置として使う。逆に、専門から少し外れる領域では、大枠はわかっていても細かい定義の記憶が曖昧だったりするので、そこをClaudeに埋めてもらう感じだ」 「熟知している内容なら、強気な姿勢で『これを探してこい』とClaudeに指示を出す。自信がないときは、逆にClaudeを専門家として扱い、検討すべき選択肢やリサーチのポイントを聞き出すようにしている」

人間が手放さないタスクとは？

一貫して挙がったのは、ハイレベルな戦略的思考や、組織のコンテキスト、あるいは「センス」が問われるデザイン上の決定にはClaudeを使わない、という声だ。あるエンジニアは「全体的な思考や設計は自分でやる。新規機能の開発からデバッグまで、それ以外の下仕事はできる限り丸投げしている」と語っている。これは調査データにも表れており、設計やプランニングのタスクでは生産性の向上が最も低い（図2）。ただし、委譲の境界線は「動く標的」のようなもので、モデルの進化に合わせて常に更新され続けている（後述するClaude Codeの使用データを見れば、6ヶ月前よりも設計やプランニングでの利用が相対的に増えているのがわかる）。

スキルの変容

新たな可能性……

Claudeに助けられた仕事の27%が「AIがなければそもそも着手しなかった」という調査結果は、エンジニアが専門外の領域に踏み出している現状を象徴している。バックエンドエンジニアがUIを構築したり、リサーチャーが可視化ツールを作ったりと、以前の自分ならできなかった仕事を完遂したという報告が相次いでいるのだ。あるバックエンドエンジニアは、Claudeとの対話を繰り返して複雑なUIを作り上げた経験をこう語る。「自分がやるよりずっとマシなものができた。自分一人じゃ絶対無理だったし、納期にも間に合わなかったはずだ。（デザイナーたちに）『え、これ君が作ったの？』と驚かれたが、『いや、Claudeがやった。僕はプロンプトを叩いただけだ』と答えたよ」

エンジニアたちは「よりフルスタックに近づいている」と実感している。「フロントエンドでもトランザクションDBでもAPIでも、以前なら怖くて手が出せなかった領域のコードを難なく書けるようになった」。この能力拡張によってフィードバックループは短縮され、学習速度も上がっている。あるエンジニアによれば、以前なら「構築、会議の調整、修正」に数週間かかっていたプロセスが、同僚からその場でフィードバックをもらう数時間の作業セッションで済むようになったという。

総じて、迅速なプロトタイピングや並列作業が可能になり、泥臭い作業が減ったことで、より野心的な目標を掲げられるようになったことを皆が喜んでいる。あるシニアエンジニアは「このツールのおかげで、ジュニア勢の生産性が爆上がりし、挑戦するプロジェクトの規模も大胆になった」と語る。また、Claudeを使うことで「着手へのエネルギー（活性化エネルギー）」が下がり、先延ばし癖を克服しやすくなったという意見もあった。「問題を解き始めるための心理的ハードルが劇的に下がったので、以前ならスルーしていたような付加的な課題にも取り組む意欲が湧いてくるんだ」

……失われる「手ざわり」の練習

その一方で、「丸投げしすぎることでスキルが退化するのではないか」という懸念や、手作業での試行錯誤を通じて得られる「副次的な学び」が失われることへの不安も根強い。

「自力で難解なバグを追っているときは、ドキュメントやコードのあちこちを読み漁ることになる。それは一見、目の前の問題解決には直結しないが、その過程でシステム全体の構造（メンタルモデル）が頭の中に構築されていく。Claudeが最短距離で答えを提示してしまうと、そういうプロセスが丸ごと抜け落ちてしまうんだ」 「以前はツールの機能を理解するために設定ファイルを隅々まで調べていたが、今はAIに使い方を教えてもらうだけ。だから、深い専門知識が身につかない。以前ならチームメイトとの会話ですぐに思い出せたことが、今はAIに聞かないとわからなくなっている」 「Claudeを使うと、簡単なケースをこなしてコツを掴むというステップをスキップしてしまう。そのせいで、後でもっと複雑な問題に直面したときに苦労する可能性がある」

あるシニアエンジニアは、自分がもし若手だったらもっと不安だっただろう、と話す。

「自分は基本的に『正解がどうあるべきか』がわかっている状態でAIを使っている。その感覚は、かつて苦労してエンジニアリングを学んだからこそ得られたものだ。……でも、もしキャリアの初期段階にいたら、モデルの出力を鵜呑みにせず、自分の能力を伸ばし続けるために相当な意識的努力が必要になると思う」

コーディングスキルの退化がなぜ問題か。それは「監督のパラドックス」にある。前述の通り、Claudeを使いこなすには「監督（スーパービジョン）」が必要であり、その監督にはAIの使いすぎで失われかねないコーディングスキルそのものが要求されるからだ。

「正直、自分個人のスキルセットよりも、この『監視と監督』の問題の方がずっと心配だ。スキルが錆びつく、あるいは成長が止まることで何が困るかといえば、独立して作業できないこと以上に、自分がやりたいタスクのためにAIを安全に使いこなす能力が損なわれることだ」

これに対抗するため、一部のエンジニアはあえてAIを使わない「自主トレ」を取り入れている。「たまに、Claudeなら一瞬で解けるとわかっている問題でも、あえて自力で解くようにしている。自分の感覚を鈍らせないためだ」

手作業のコーディングスキルは、これからも必要なのか？

あるいは、ソフトウェアエンジニアリングという仕事自体が、過去に何度もあったように「抽象化のレベル」が一段上がる段階に来ているのかもしれない。かつてのプログラマは、メモリを直接管理し、アセンブリを書き、物理スイッチで命令を入力するといった、よりマシンに近い場所で働いていた。やがて、人間にとって読みやすく、低レベルな処理を自動化してくれる高水準言語が登場した。そして今、「バイブス・コーディング（vibe coding）」という言葉に象徴されるように、プログラミング言語としての「英語」へと移行しようとしているのかもしれない。弊社のスタッフの一人は、エンジニア志望者に向けて「AIにコードを書かせるのが上手くなれ。そして、より抽象度の高いコンセプトやパターンを学ぶことに集中しろ」と助言している。

この変化によって、単なるコードではなく「最終製品やエンドユーザー」といった、より高次元の思考に集中できるようになったと感じている社員も少なくない。ある人は、今の変化を「かつての計算機科学で連結リストを学ばなければならなかった頃」に例えた。今では高水準言語が自動で処理してくれる基本的な構造だ。「やり方を知っていて良かったとは思うけれど、……そういう低レベルな操作をすること自体に情緒的な価値はあまり感じない。それよりも、そのコードで何ができるかの方に興味があるんだ」。別のエンジニアも同様の比較をしつつ、抽象化には代償が伴うことも指摘している。高水準言語への移行によって、ほとんどのエンジニアはメモリ管理に関する深い洞察を失ってしまった、と。

特定の領域でスキルを磨き続けることは、Claudeの監督の精度を上げ、作業効率を高めることにつながる（「手慣れた作業なら、自分でやったほうが早いことも多い」）。だが、それが重要かどうかについては意見が分かれている。楽観的な意見もある。

「スキルの侵食はそれほど気にしていない。AIを使っても問題について深く考える必要はあるし、新しいアプローチを学ぶ助けにもなる。むしろ、アイデアを素早く検証できるようになったことで、特定の分野では学習が加速したくらいだ」 より現実的な声もある。「ソフトウェアエンジニアとしてのスキルは間違いなく退化している。……でも、もし必要になればまた鍛え直せばいいし、そもそも今はもう必要ないんだよ！」 また、失われたのはチャート作成のような「それほど重要ではないスキル」だけで、「クリティカルなコードについては、今でも十分なレベルで書ける」という指摘もあった。

そして最も興味深いのは、前提そのものを疑う意見だ。「『腕が鈍る』という考え方は、コーディングがいつかClaude 3.5以前のやり方に戻るという仮定に基づいている。でも、そんな日は二度と来ないと思う」

ソフトウェアエンジニアリングという「工芸（クラフト）」と意義

手作業でのコーディングが恋しいかどうかについては、エンジニアの間でも激しく意見が割れている。喪失感を抱く者もいる。「自分にとっては一つの時代の終わりだ。25年間プログラミングを続けてきて、そのスキルに習熟していることはプロとしてのアイデンティティの一部だった」。仕事の性質が変わることを楽しめないのではないか、という懸念もある。「一日中プロンプトを叩くのは、あまり楽しくないし充足感もない。音楽を聴きながらゾーンに入って、自分の手で実装している時の方がずっと楽しいんだ」

一方で、このトレードオフを真っ向から受け入れている人もいる。「リファクタリング中に禅のようなフロー状態に入る感覚など、確かに恋しい部分はいくつかある。でも、全体としては今の方が圧倒的に生産性が高い。そのメリットのためなら、喜んで以前のスタイルを捨てるよ」

Claudeとの試行錯誤の方が楽しい、という意見もあった。人間相手よりも遠慮なく細かなフィードバックを出せるからだという。また、成果そのものに価値を見出す人もいる。

「今の段階では、恐怖や退屈を感じているだろうと予想していたんだ。……でも、実際はそのどちらでもない。それどころか、できることが大幅に増えたことにワクワクしている。自分はコードを書くのが好きなんだと思っていたが、実は『コードを書くことで得られる結果』が好きだったんだと気づいたよ」 AIのアシストを受け入れるか、手作業の喪失を嘆くかは、その人がエンジニアリングのどの側面に「意義」を見出しているかによって決まるようだ。

職場における社会動向の変化

顕著な変化の一つとして、かつては同僚に向けられていた質問が、まずClaudeにぶつけられるようになったことが挙げられる。「全体的な質問の数は増えたが、その80〜90%はClaudeに聞いている」という。これによって、日常的な問い合わせはClaudeが処理し、人間（同僚）はAIの手に負えないような複雑、戦略的、あるいはコンテキストに依存した課題に集中するというフィルタリングが機能している（「チームへの依存度は8割減った。だが、残りの2割が極めて重要であり、そこを相談しに行っている」）。また、人間の協力者と同じように、Claudeを「壁打ち相手」として使う人も増えている。

約半数のメンバーは、チーム内のコラボレーションのパターンに変化はないと回答している。あるエンジニアは、今でも同僚と会ってコンテキストを共有し、方向性を決めており、近い将来もコラボレーションは重要であり続けるだろうと考えている。ただし、「標準的な作業（フォーカスワーク）をする代わりに、たくさんの『Claudeたち』と対話することになるだろう」とも付け加えている。

しかし、同僚との交流が減ったと感じている人もいる（「どの同僚よりもClaudeと一緒に仕事をしている時間が長い」）。これを「気兼ねなく同僚の時間を奪わずに済む」と、対人摩擦の減少として歓迎する声もあれば、「『Claudeに聞いた？』が合言葉になるのは好きじゃない。対面での共同作業を大切にしたい」と抵抗を感じる人や、「人を必要としなくなったことが少し寂しい」と漏らす人もいる。また、従来のメンターシップ（教育）への影響を指摘する声も複数あった。シニアが教える代わりに「Claudeがジュニアにコーチングを提供できてしまう」からだ。あるシニアエンジニアはこう語る。

「若手が質問に来なくなったのは少し寂しいね。まあ、彼らにとってはそっちの方が効率的に回答を得られるし、学習も早いんだろうけど」

キャリアの不確実性と適応

多くのエンジニアが、自分の役割が「コードを書くこと」から「AIを管理すること」へシフトしていると述べている。エンジニアは自らを「AIエージェントのマネージャー」と見なすようになりつつあり、すでに「常に数個のClaudeインスタンスを走らせている」という者もいる。ある人は、自分の仕事の「70%以上が、新規コードの作成ではなくコードのレビューと修正になった」と見積もっており、別の人は「1人、5人、あるいは100人のClaudeがやった仕事の責任を取ること」が将来の役割になると見ている。

長期的なキャリアの不確実性については、広く不安が共有されている。エンジニアたちは、これらの変化を業界全体の変革の前触れと捉えており、数年後のキャリアがどうなっているかは「何とも言えない」という声が多い。短期的な楽観と長期的な不安の板挟みになっている者もいる。「短期的にはポジティブだが、長期的にはAIがあらゆることをこなすようになり、自分も他の多くの人も不要になるのではないか」というわけだ。「自分の仕事を奪うために毎日出社しているような気分だ」という皮肉な言葉もあった。

一方で、より楽観的な見方もある。「ジュニア層の将来は心配だが、彼らこそが新しい技術に最も貪欲だ。この職業の先行きについては、概ね楽観視している」。未熟なエンジニアが問題のあるコードをリリースしてしまうリスクはあるものの、AIのガードレールが進化し、教育リソースが組み込まれ、失敗から学ぶことで、分野全体が時間をかけて適応していくだろう、という主張だ。

将来の役割をどう描き、どう適応しようとしているか。専門性をさらに深めるという計画（「AIの仕事を意味ある形でレビューするには、より長い時間と高い専門性が必要になる」）を挙げる人もいれば、対人スキルや戦略的な仕事にシフトすると予想する人もいる（「合意形成に時間をかけ、実装はAIに任せるようになる」）。また、Claudeをキャリア開発そのものに使い、リーダーシップスキルなどのフィードバックを得ているという人もいた。「物事を学ぶスピード、あるいは完全に学びきらなくても成果を出すスピードが完全に変わった。自分を抑えていた天井が粉砕されたような気分だ」

結局のところ、多くの人が深い不確実性を認めている。「将来、具体的にどのスキルが役に立つのか、確信が持てない」というのが本音だろう。あるチームリードはこう締めくくった。「何が起こるかなんて誰にもわからない。大切なのは、とにかく適応力を高めておくことだ」

Claude Codeの使用傾向

調査とインタビューからは、Claudeの利用が増えることで作業がスピードアップし、新たな仕事に挑戦できるようになっている一方で、委譲の加減やスキルの習得について葛藤があることがわかった。とはいえ、自己申告のデータは全体の一部に過ぎない。そこで、Anthropic社内チームにおける実際のClaudeの使用データも分析した。調査回答者の多くがClaude Codeをメインで使っていると答えたため、プライバシーに配慮した分析ツールを用い、2025年2月から8月までの社内Claude Codeのログ20万件を解析した。

監視を減らし、より困難な課題に挑む

この6ヶ月間で、Claude Codeの使用はより難易度が高く、自律的なタスクへとシフトしている（図3）：

（図3：2025年8月と2月のClaude Code使用状況の比較。左パネルは平均タスク複雑度、中央は連続ツール呼び出し数の最大値、右は人間とのターン数。エラーバーは95%信頼区間。時間が経つにつれ、ユーザーがClaudeにより多くの自律性を委ねていることがわかる）

これらのデータは調査結果を裏付けている。エンジニアはより複雑な仕事をClaudeに任せるようになり、Claude側もより少ない監督でそれに応えられるようになっている。これが生産性向上の原動力になっていると見て間違いないだろう。

タスクの分布

Claude Codeのログをタスクの種類ごとに分類し、過去6ヶ月で使い道がどう変わったかを調査した。

（図4：全記録に対する各種コーディングタスクの割合。2025年2月（ピンク）と現在（紫）を比較。y軸は2月時点の頻度順）

使用データから推計されたタスク分布は、自己申告による分布とおおむね一致している。2025年2月から8月にかけての最も顕著な変化は、「新規機能の実装」（14.3% → 36.9%）と「設計・プランニング」（1.0% → 9.9%）にClaude Codeを使う割合が激増したことだ。この変化は、Claudeが複雑なタスクをよりうまくこなせるようになったことを示唆しているが、一方でチームがワークフローの中でClaude Codeをどう活用するか、その「使い所」が変わったことを反映している可能性もある。

「チクチクした不快感（ペーパーカット）」の解消

調査では、エンジニアがQoL（作業の質）を向上させる小さな改善に時間を割くようになったという結果が出ていた。これと呼応するように、現在のClaude Codeのタスクの8.6%は「ペーパーカット（小さな問題）の修正」に分類されている。これには、パフォーマンス可視化ツールの作成や保守性のためのリファクタリングといった大きめのものから、ターミナルのショートカット作成といった些細なものまで含まれる。放置されがちだった「ちょっとした不便」を解消することが、結果として長期的な効率化につながり、日々の仕事のストレスを軽減しているのだろう。

チームごとのタスクの違い

チーム間でタスクがどう異なるかを調べるため、8月のログを主要なタスクごとに分類し、社内のチーム別（y軸）に集計した。

（図5：各バーは各チームを表し、セグメントはタスクの種類ごとの割合を示す。一番上の「All Teams」は全体の分布）

「All Teams」のバーを見ると、新機能開発、デバッグ、コード理解が最も一般的なタスクであることがわかる。これを基準に各チームの特徴を見ると面白い。