AIの労働市場への影響：新たな指標と初期の証拠

46日前原文(www.anthropic.com)

概要

AIによる雇用リスクを測定する新指標「観測露出度」の提案
理論上のLLM能力と実際の業務利用データを組み合わせて評価
AI利用が進む職業は今後の雇用成長が低い傾向
高露出職種の労働者は高学歴・高収入・女性比率が高い
現時点で失業増加の証拠は限定的だが、若年層の採用減少の兆し

AIによる雇用リスクの新たな測定指標「観測露出度」

AIによる職業代替リスクを測るため、**「観測露出度」**を新たに導入
理論上のLLM（大規模言語モデル）能力と実際の業務利用状況を組み合わせて算出
- 自動化利用や業務関連利用を重視した重み付け
AIの理論能力と実際の業務カバー範囲には大きなギャップ
- 現状、実際のAI利用範囲は理論的に可能な範囲の一部にとどまる

観測露出度の測定方法

O*NETデータベース：米国約800職種の業務タスクを網羅
Anthropic Economic Index：実際のAI利用データ
**Eloundouら（2023）**のタスクごとのAI理論能力評価（β値）を活用
- β=1：LLM単体で2倍効率化可能
- β=0.5：追加ツール等が必要
- β=0：非対応
理論能力≠実利用：法規制や業務フロー、検証手順などで普及が遅れる例も多い

職種ごとのAI露出度と特徴

Computer ProgrammersやCustomer Service Representativesなどが最もAI露出度が高い
- 例：Computer Programmersの75%の業務がAIでカバー
30%の職種はAI利用がほぼゼロ
- 例：調理師、バーテンダー、ライフガード等
AI露出度が高い職種は、今後10年間で雇用成長が低い傾向（BLS予測と相関）
高露出職種の労働者属性
- 女性比率・白人比率・アジア人比率が高い
- 平均年収47%高、大学院卒比率も4倍近く

AI露出度と雇用動向

失業率：2022年末以降、高露出職種で顕著な失業増加は見られず
若年層の採用がAI露出度の高い職種で鈍化傾向
AIの労働市場インパクトは、インターネットや中国貿易のように、徐々に現れる可能性
- 短期的な失業率の急上昇は見られないが、職種構成や採用動向の変化に注目が必要

今後の研究・政策への示唆

観測露出度は、AIによる経済的な変化を早期に捉える有効な指標
失業率や職種構成の変化を継続的に観測し、政策対応の必要性を判断
AIによる経済的混乱や影響の早期特定に向けた分析基盤の構築が重要

Hackerたちの意見

影響はあんまりないと思うな。AIを使える人はちょっとだけ生産性が上がったけど（だって、そんなに仕事が早く終わるって上司に言ったら、10倍の仕事を振られるだけじゃん？）、AIの知識がない人はそのままだし。実際の影響はインディー開発者やフリーランスにあるけど、GDPにはあんまり影響しないよね。

└

仕事が採用を凍結して、みんなにトークンの支出を増やしてる。これが効果的かどうかは分からないし、経営陣も分かってないと思うけど、今やってることはそれだね。

└

2025年の12月からの数字の変化が気になるな。

└

みんなが10倍生産的だったら、各プラットフォーム用のネイティブなClaude Codeアプリがあったはずだよね。でも、実際にはElectronを使って終わりにしてる。なんか皮肉だよね？AIがそんなに優れてるなら、なんでAnthropicからネイティブソフトが出てこないんだろう？

AI製品を売る会社の言葉なんて、全く信用しないよ。

└

… そしてIPOを狙ってる。

└

それに、新しい指標を発明したのが面白いと思ったよ（驚き！）それが彼らの製品の長期的な予測をすごく良く見せるんだ（財務的に）。

ソフトウェアエンジニアとしての経験から言うと、生産性が倍増しても仕事量は減らない。1時間あたりのアウトプットは増えたけど、期待や要求も同じくらい増えてる。ソフトウェア開発は実質的に終わりのない仕事で、AIは主に納期を短縮するだけで、全体の需要を減らすわけじゃないんだよね。

└

目標は常に、与えられた時間内にできるだけ多くのことを終わらせることだよね。

└

あなたの仕事量は減らないよ。むしろ、同僚の一人がいなくなるだけ。

└

経済全般についてだけど、労働を省力化するイノベーションは生産性を上げるけど、仕事をあまり減らすことはないんだよね。ただ、仕事のやり方が劇的に変わることはあるけど。これはゲーム理論的な理由もあるし、ヘドニック・トレッドミルみたいな現象も関係してる。

└

これ、開発がバックログや技術的負債を上回った職場なんて思いつかないな。

└

参照: https://en.wikipedia.org/wiki/Jevons_paradox

└

自転車選手の有名な言葉があるんだ。「楽にはならない、ただ速くなるだけだ」

コードを書く仕事ではないけど、管理やメンテナンスはしてるよ。これ言うとみんなすごく怒るんだけど、今のところAIは私の仕事にほとんど影響を与えてない。開発チームもベンダーも、2年前より早くソフトウェアを提供してくれてるわけじゃないし。Dockerの方が、AIよりも私のパイプラインに大きな影響を与えたよ。もしかしたら状況は変わるかもしれないけど、今はただ面白がって見てるだけ。

└

開発チームは以前よりも多くコミットしてるみたい。ログを見る限り、かなりの量だね。でも、それが私にソフトウェアを提供するペースが速くなったってことには繋がってない。これも、もしかしたら変わるかもしれないけど。

└

こっちも似たような感じ、オペレーションの世界ではね。AIは使ってるけど、正直言って生産性が劇的に向上したり、仕事が大きく変わったとは言えない。唯一変わったのは、他のマネージャーからのメールが明らかにAIによって書かれてることかな。スクリプトを少し早く作れるようになったり、ググるよりも早く答えを見つけられることはあるけど、ほとんどの時間は他の人を待ってるし、全体の会社のプロセスは改善されてないし、効率も上がってない。いつも通りのブロッカーがまだ存在してる。君が言ったように、AIよりも私の仕事を変えた技術は他にもあるし、クラウドへの移行、Docker、Terraform、Ansibleなどが私の仕事に与えた影響はずっと大きい。内部でも外部でも、他の人の成果に全く変化を感じないよ。だから、これは大げさなバブルなのか、私が何か見落としてるのか。

└

LLMをプロセッサーと呼ぶことにしたよ。アセンブリでの「Hello World」は約20行で、ほとんどの未熟なプロンプトと同じくらいだね。そこからRustやFirefox、強力なベクタープロセッサーで動く1Tパラメータのトランスフォーマーに到達するまでに時間がかかった。今はこのプロセッサーでHello Worldを超えたところにいる。特定の状況にどう適用されるかは、まだ見つかってないか、君のところには届いてないんだと思う。本当にまだ初期段階だね。

└

新しい機能を作ってみて。もし官僚主義に悩まされてなければ、もっと早く実現するよ。

└

> これまでのところ、AIは私の仕事にほとんど影響を与えていません。採用してますか？

└

そうだね。AIが私にしてくれたことは、10年以上前の検索エンジンの力を与えてくれたことだけ。何かを検索して、実際に関連性のある役立つ情報をすぐに見つけられるようになった。AIがプロジェクトを基本的にコーディングできるって言ってる人も多いけど、分野によると思う。ボイラープレートコードや非常に一般的なプロジェクトを除けば、ゲーム開発に関しては、私の意見ではほとんど役に立たない。数年前にエンジンのドキュメントを読んだことがある人が、なんとなく覚えていて間違いをたくさんするのと同じくらい役に立たない。最良の結果は、必要な方向を指し示すことだけど、基本的な機能を幻覚して論理をめちゃくちゃにすることもある。

└

これは、80年代にパソコンが職場に導入されたときの生産性パラドックスの典型的な例だね。有名な経済学者が「コンピュータ時代はどこにでも見えるが、生産性統計には見えない」と言ったことがある。生産性向上の遅れには多くの理由があるけど、確実に来ると思う。 https://en.wikipedia.org/wiki/Productivity_paradox

└

僕の会社はこのツールを開発にかなり進んで使ってて、すごくすべてが加速してる。今や6ヶ月分のロードマップを数週間で消化しちゃうくらい。ただ、まだこういう風に運営してる会社は少ないと思う。ツールや技術が普及するには時間がかかるし、Claude Codeだけじゃ足りないよね。基本的に、ほとんどのプロダクトマネージャーやエンジニアマネージャーを手放すつもりみたいで、AIツールを最も効果的に使ってる人を測ってるんじゃないかな。そうじゃない人は、年内には解雇されると思う。Salesforceで見た以前のバージョンとは違って、今回は本当に実行すると思ってる。35年のキャリアの中で一番の変化だし、周りの人の生活に大きな影響が出るのは分かってるけど、こういう状況を経験できるのはちょっとワクワクしてる。これが終わったら引退するつもりだけど、この部分は面白いと思う。でも、次に何が来るかははっきり見えてるから、あんまり楽しみじゃない。

└

どんなスキルレベルのツールでも、自分の専門分野で見ると平凡に見えるけど、知らない分野だと画期的に見えるよね。でも、みんなが急に多才になるのが本当のゲームチェンジャーになるんじゃないかな。

マーケティング部門の同僚から聞いた面白い話なんだけど、彼は会社が承認したLLM（Gemini）を「お仕事ごっこ」や基本的なタスクに使ってるんだって。で、個人アカウントではClaudeを使って、実際に仕事をサポートしてるらしい。彼の考えは、会社にプロンプトやレスポンスを記録させないことで、自分の代わりにエージェントを作られないようにしてるってこと。企業のシャドーITに関するルールなんて無視だね。やっぱり、疑り深い人だけが生き残るのかな。

└

彼のプロンプトを使ってトレーニングするのは彼の会社じゃないよ。個人アカウントだし、完全に有料で、彼がプロンプトでのトレーニングをオプトアウトしていない限り。

今、AIに大きく影響を受けたプロジェクトに取り組んでるんだけど、助けがなかったら絶対にやらなかったと思う。かなり大きな仕事だしね。でも、実際に出力を見ていると、バイブコーダーが何かを出荷するとは思えない。LLMの出力をしっかり管理しないといけないんだ。時々、エラーはPEBCAK（問題は自分）で、プロンプトを間違えたせいで微妙な問題が起きることもある。もうすべての行をレビューすることはないけど、まだ「LLMを信頼できる」段階には達してない。問題が出るだろうなと思ってるけど、まだ失望したことはない。良いニュースは、LLMはどこで間違えたかを見つけるのが得意だってこと。SwiftLintをオンにするのが怖い。LLMのコードは…冗長すぎる…それでも、プロジェクトはものすごく加速したよ。最初に書くのに数年かかったサーバーとネイティブクライアントのリライトを、もう1ヶ月で半分以上終わった。公平に言うと、遅い部分はまだ先にあるけどね。バックエンドやコミュニケーションの部分は一人で（速く）作業できるけど、チームの他のメンバー（特に、うわっ、グラフィックデザイナー）が参加すると、ペースが遅くなるだろうな。

└

>> もうすべての行をレビューすることはないけど、まだ「LLMを信頼できる」段階には達してない。私も同じ。だから、何度も試みたけどClaude Codeに切り替えられなかったんだ。Cursorの方が、生成されたコードを「信頼する」よりも、レビューして受け入れたり拒否したりしやすいUXだと思う。

└

> でも、実際にバイブコーダーが何かを出荷する姿は想像できない。僕はバイブコーダーだけど、たくさん出荷してるよ！重要なのは、ユーザーが一人（自分）だけのアプリをバイブコーディングすることだね。1月まで15年間何もコードを書いてなかったけど。

└

なんでフックを使って、コードを見直す前に全てのコードをリンターに通さないの？

彼らが示している数字は、僕が解釈する限り、ほとんどノイズと区別がつかない。僕にとっての影響は、若手を雇うことにある。基本的に、もう考えるのをやめちゃった。今、若手ができる仕事は、AIに何らかの形で（若手がやるのとは違うかもしれないけど）渡した方が楽だと思う。ちょっと幻想的だけど、若手に仕事を渡す方が、自分でやるよりも手間がかかることが多かったのは事実。誰かを雇って、その生産性を上げるのは未来への投資だよね。今は専門性の形を再評価しているところだから、若手がやっていたことは以前より価値が下がっているのは分かるけど、未来の価値提案がどうなるかは分からない。だから、分かるまで一時停止している状態で、今のAIを使った効率化の成果は「保持」に投資されている。AIを中心に仕事を再構築するのに十分な時間を稼いでくれてる。そうなったら、リセットがあって若手の採用が再開されると思う。

└

若手の採用をやめるのは意味がないよ。AIが生産性を上げて、若手の方が安く雇えるなら、シニアと同じようにAIにタスクを渡せる若手をどんどん雇った方がいい。そうすれば、より早くアウトプットが出せて、収益も増える可能性がある。だから、唯一の制約は収益を増やせない可能性で、それはAIの問題とは関係なく、もっと広いマクロ経済の問題だよね。

生産性の向上が見られないって言ってる人、どこが失敗してるのか教えてくれない？僕は大規模なレガシーコードに取り組んでるときのアウトプットに恐怖を感じてるけど、ちゃんと動いてるよ。ここでワークフローの変更の一例を説明したけど：https://news.ycombinator.com/item?id=47271168 でも、全体的に見て、昔のやり方と比べて、コードベースの調査や新しいものの統合、修正をするのに、常に半分のステップを節約できてる。コードを書くのをやめて、たまにLLMが提案した変更に飛び込んで、実行可能なら手動で編集してる。そうじゃなければ、変更を元に戻して再生成をお願いしてるけど、過去の拒否されたアウトプットから学んだことを考えると、次に何が来るのかが恐ろしい。

└

> 生産性の向上が見られないって言ってる人、どこが失敗してるのか教えてくれない？レビューの時だよ。単に、著作権とレビューの両方を非人間に委譲できないソフトウェア業界が多すぎるから、特にライブラリや後方互換性に関する環境では、「目的が手段を正当化する」アプローチはまだ正当化できない。

└

解雇している会社はビジョンがないね。うちの会社は成功している非営利団体で、今めちゃくちゃ人を雇ってる。ソフトウェア会社じゃないけど、常に無限に仕事がある感じ。仕事が早く終わったからって、なんで縮小する必要があるの？もっと仕事をして、もっと成果を上げて、競争相手よりも良くなって、自分たちのビジョンを実現することに力を入れればいいじゃん。私たちは利益を地域に還元して、実際に人々の生活を良くしてるんだよ。なんてクレイジーなコンセプトなんだろうね？

└

AIは速度を劇的に上げるけど、その速度が生産性なの？生産性って、誰に対してのもの？自分、チーム、部門、会社？本当に大事なのは、「何の速度」なのかってこと。これ、HNのコメントから得たんだけど、エンジニアのデフォルトの考え方は「作ること」なんだよね。作れば作るほど良いって思ってる。でも、それが「間違い」ってわけじゃないけど、ビジネスの場では必要だけど十分じゃないんだよね。だから、生産性とか影響とか速度とか、どんなアウトプットの指標を考えるにしても、実際の質問は「何の」なの？もっとコード？もっとプロダクトの表面積？それが本当の問題じゃなかったんだ。実際、大抵の場合、生活を悪化させるだけなんだよね。

└

失敗率が高すぎるから。ボイラープレートコードやCRUDアプリを超えて、もし私がAIに自由にプロジェクトを任せたら、私が自分でやるよりも、その変更を直すのにもっと時間がかかるんだ。AIは機能的に幻覚を見たり、自分で行き詰まったり、私の指示に従わなかったり、簡単な機能のために余計なコードを書いたりする。約10年前にスタックオーバーフローがやってたことを置き換えるのは得意だけど、それは私の基準から見たら本当に改善とは言えない。

└

反対意見は必ずしも生産性の欠如に関するものではないと思うけど、私の個人的な経験では大きな生産性の向上は感じてない。コードをずっと早く生産しているからって、ボトルネックを他のところに押しやるだけかもしれない。ソフトウェアの価値サイクルは長くて複雑なんだ。もし5年後にLLMが複雑なシステムの相互作用のせいで診断や修正ができない問題にぶつかったらどうする？それがどれくらい起こると思う？機能を正確に一致させて全てを新しく生成するのは現実的なの？5年後にLLMの理想的な運用方法から見て、正しいアーキテクチャの選択をしているのか？わからないよね。経験豊富な人たちは、物事がどれだけ悪くなるかを知っているから保守的になりがちなんだ。今回は違うかもしれないけど。

└

私はMLエンジニア/研究者として働いている。実験で変更を実施する時、結果が出るまでに通常1時間以上かかる。だから、その時間を使って別の実験を実施することができる。手作業でやるかエージェントにやらせるかは関係ない、十分な時間があるから。コードがボトルネックではないんだ。コードを書くのが安価だから、経済的価値のないことをあまり考えずに実装する人もいるって意見を聞いたことがある。

└

最後にAIを試した時、ストップウォッチでテストしたんだ。グループはフィーチャーフラグを使ってた... if (a) { // 新しいコード } else { // 古いコード } void testOff() { disableFlag(a); // まだ動くかテスト } void testOn() { enableFlag(a); // まだ動くかテスト } でも、どんなクリーンアップでもそうだけど、実際には起こらない。何千ものこれらのものがスペースを占有してる。私は「これをAIに任せれば、飽きたり文句を言ったりしないだろう」と思った。1つのフラグを約3分でできる。コード編集、PR準備して送信。AIは1つを10分でできるけど、目を離せなかった。巨大なリポジトリを探してシンボルを見つけようとして、find/grepを使おうとしてた（MCPサービスの代わりに）。それから指示を無視して、どちらかのテストをクリーンアップせず、使われていないフィールドやパラメータを残して、全体的にめちゃくちゃにした。結局、結果をレビューして修正する必要があって、さらに3〜5分かかって、コンパイルされる保証もなかった。その時点で、私が3分でできるタスクが15分かかってしまった。確かに、コードの変更はしたし、「クール」な感じはしたけど、会社にはAIを使わなかった時の5倍のコストがかかった（トークンコストを考慮する前に）。さらに悪いことに、CI/CDシステムは私のクリーンアップの個別の速度についていけなかった。自動化ツールを使う？うん、楽しくないだろうね。でも、もう一度試してみる必要がある。みんなが12月に大きな変化があったって言ってるから。

└

最近考えてるのは、私たちが作り出すシステムを理解することに価値があるのか、そしてそれを期待されているのかってこと。もし誰かに「なんで世界的に生産が落ちてるの？」って聞かれて、ただ「まあ、そんなもんだよね」って流せるなら、もっと機能を出せる気がする。でも、自分が作ったシステムを理解して修正することが求められるなら、ただ流してから状況を理解しようとするのが、考えて書くよりも実際に早いとは思えない。私の経験では、AIに任せれば任せるほど、結果を理解できなくなる。あの「遅さと考えること」は、バグじゃなくて機能なのかも。時々、AIが基準を下げるきっかけになった気がする。

└

「動く」っていうのは、ソフトウェアエンジニアリングにおいて非常に低い基準だよね。なんでAIが生成したコードを、コードレビューで仲間に求める基準と同じにしないの？コードをレビューする時に「動く」って言うのをポジティブに聞いたことないよ。確かに生産性は上がるけど、質が下がってないって言えないでしょ。

└

かなり人気のあるアプリがあるんだけど、今回のリリースサイクルではClaude CodeとCodexを使ってすべての変更や機能を実装したんだ。確かに前よりもずっと早く進めたけど、今ベータ段階に入ってるから、問題やバグの量がすごいことになってる。入れたコードもたくさんレビューしたけど、バグ修正の段階は初期の実装よりも時間がかかる気がする。問題が多すぎて、コードベースのメンタルモデルがかなり崩れちゃった。面白い実験だったけど、もうこんなやり方はしないと思う。

今、AIのせいで高給のキャリアを避ける子供たちがいるし、アーティストたちもどこを見ても諦めてる。ありがとう、AI。

生産性は10%上がったけど、幸福感や生活満足度、自尊心は20%下がった。

ハクソク