Claude Codeの生みの親、ソフトウェアエンジニアの終焉を語る [YouTube]

• エージェント型コーディングツール Claude Codeは、コードを書く行為そのものよりも、製品づくりや業務フローの再構成に大きな変化をもたらしている
• Microsoftの業務AI利用者調査では、AIの迅速な導入圧力、新しい成果物の創出、より価値の高い業務に使う時間の増加が同時に見られた一方で、AI実験への報酬は低水準にとどまった
• 組織が単純な利用量を目標にすると、トークン・リーダーボードや利用量の水増しが発生し、AIで価値を上乗せする方法と結びついた指標のほうが重要になる
• Boris Chernyは、エンジニアという肩書きがbuilderに近い役割へ変わる可能性があり、非エンジニアもコードを作るようになり、エンジニアは直接タイピングすることより判断・計画・ユーザー理解にさらに集中するようになると見る
• AIによる生産性向上は、労働時間の減少や雇用減少にだけつながるわけではなく、企業はワークフローをAI中心に再構成し、個人はより大きな選択肢とレバレッジを持つようになる

---

AI業務データと組織指標の落とし穴

• Microsoftは実際の業務でAIを使うユーザー20,000人を調査し、「変革の逆説(transformation paradox)」と呼ぶ現象が現れた
  • 65% はAIをすばやく導入しなければ取り残されるのではと不安を感じている
  • 58% は、1年前なら作れなかった成果物をAIのおかげで作れている
  • 66% は、AIのおかげでより価値の高い業務に時間を使えるようになったと回答した
  • 一方で、AI実験について職場で報われていると答えた人は13% にとどまり、利用意欲と組織のあいだにギャップがある
• 別のMicrosoft研究では、管理職がAI利用を直接見せると利用が17% 増え、エージェントへの信頼度が30% 上昇した
  • 「AIが未来だ」といったスローガンよりも、管理職が自分が実際に使っている具体的な方法を見せるほうが結果につながる
  • 社員がAIで高めた生産性の成果を分かち合えると信じられれば利用動機は変わりうるが、そのように金銭的に報酬を与える職場はほとんどない
• 一部の職場ではトークン費用を補助しているが、その支援が常によい結果につながるとは限らない

トークン・マキシング — 利用量指標の副作用

• 主要テック企業ではトークン・マキシング(token maxing)、つまり利用量を増やすためにトークンを過剰消費する現象が起きている
  • Financial TimesにAmazon社員が語ったところによると、AmazonはOpenClawに着想を得た社内ツールmesh clawを導入し、利用を奨励している
  • チーム内にトークン利用量ランキングがあり、一部の社員は生産的でないエージェントを意味もなく回して利用量を引き上げている
  • Metaでは最大利用量が数千億トークン規模に達し、数百万ドル相当の量が事実上無駄になっていた
• Amazonの公式見解ではトークン利用量は管理職の評価指標ではないとされるが、社員は管理職が見ていると感じて生の利用量を増やしている
  • Amazonには開発者の80%が毎週AIを使うようにするという上位目標がある
  • 具体的な報酬がなければ、「AIを使え」という文言だけ守って「仕事をより良くしろ」という本来の趣旨を見失う
  • 開発者には曖昧な追跡方法より、価値創出と結びついた生産的な指標が明確に必要だ

Claude Codeの誕生と急速な普及

• Claude CodeはAnthropicが前年5月に公開したエージェント型コーディングツールで、言葉を入力するとコードを出してくれるツール
  • 公開8か月以内にGitHubへ上がった全コードの約4% を担うようになった
  • その年2月には年間売上ランレート25億ドルに到達し、その水準に最速で達したエンタープライズ製品となった
  • 生みの親であるBoris Chernyはコンピュータサイエンス学位を持たず、経済学専攻で、18歳で大学を中退してスタートアップを運営し、ヘッジファンドを経てMetaで主任エンジニアとして5年間勤務した後、2024年末に加わった
  • 現在のChernyはコードを自分で1行も書かないまま、5つのターミナルタブで5つのエージェントを並列実行し、1日に20〜30件のプルリクエストを処理している
• コーディングツールを作れという任務ではなく、APIに慣れようとして始めたサイドプロジェクトだった
  • 当初はClaudeをAppleScriptにつなぎ、自分が聴いている音楽を表示するだけのシンプルなものだった
  • 2か月以内にClaude Code版が生まれ、初日にAnthropicのエンジニアリングチームの20% が利用した
• 2024年9月に加わり、ごく小さなlabsチームに所属
  • このチームがClaude Code、MCP、skills、デスクトップアプリを作っており、成功するか分からない実験的アイデアが多かった
  • Anthropicは企業向け・コーディング・安全性に注力してきたため、製品を作るならより良いコーディングモデルと安全性研究の両方に役立つコーディング製品が合理的だと判断した
• 当時のコーディング製品の多くはIDE拡張で、Sonnet 3.5の水準では高度な自動補完に近かった
  • モデルにはできるのに、その能力を引き出す製品がないというモデル・オーバーハング(model overhang) を実感しており、その感覚は今も同じだ
  • 別個のUIやアプリなしでターミナル上で動く最も安価な形として数日で作られた
  • 身近なところから利用者が広がり、数週間で社内の多くが毎日使うようになり、公開5日以内にエンジニアリングチームの半数が利用した
  • ターミナルを敬遠するエンジニアでさえ使い、Chernyは「ソフトウェアエンジニアリングは永遠に変わった」を分析するより、公開に集中していた

エンジニアは消えるのか — 役割の混ざり合い

• 最初の衝撃は、Claudeが聴いていた音楽を教えてくれた瞬間だった
  • 質問に対しClaudeは音楽プレーヤーを開くAppleScriptコードを書き、Chernyはその言語を知らず、そんな答え方を思いつきもしなかった
  • エンジニアが選ばなかったであろう方法で問題を解決した
• モデルは非常に速く進化しており、モデルの上に製品を作ると毎月の再調整が必要になる
  • Co-workで航空便8件とホテル5件を予約し、唯一のミスは1泊約5,000ドルのホテルで予算超過だったため、その件だけ予約し直した
• トレンドは指数曲線で、誰にも正確には分からず、2つのことが同時に起きている
  • エンジニアの生産性が高まり、同じ仕事に必要なエンジニアが少なくて済む企業
  • 1人あたりの生産性向上でより多くの製品・事業に取り組み、より多くのエンジニアが必要になる企業（Chernyのチームは優秀なエンジニア不足に引き続き阻まれており、できる限り速く採用中）
• 役割が興味深い形で混ざり始めている
  • マネージャーのFionaは15年間コーディングしていなかったが、参加後にコーディングし、プロダクトマネージャーのCatやデザイナーのMeganなどチーム全員がコーディングしている
  • 非エンジニアは少し多くコードを書くようになり、Chernyのようなエンジニアは6か月以上コードを直接書かなくても、1日中何かを作っている
  • ビルダー・エンジニア・プロダクトマネージャーのどれと呼ぶべきかは不確かだが、役割そのものが変化しているのは明らかだ

トラクターの比喩 — 技術普及にかかる時間

• トラクターは1890年代のIowaでJohn Frickが発明したが、米国でトラクターが馬より多くなったのは1960年代で、約70年かかった
  • トラクターは収穫量と生産性を大きく高めたが、使い方を学ぶ訓練が必要で、初期は高価で馬のほうが安かった
  • 性能も十分ではなく、小麦には使えてもトウモロコシには使えないといった具合で、多様な作物に対応するまで長い時間がかかった
  • 現在のAI転換では、同じ問題が超高速(speedrun) で起きている
• これは普通の技術としてのAI(AI as normal technology) という見方につながる — きわめて有能なモデルが出てきても、人と組織の変化は遅い
  • ただしAnthropicの売上推移を見ると今回はその速度が速いという反論もあり、実際の変化速度を見極めている段階だ
• コンピュータは生産性を高めるが、それがそのまま労働時間の減少を意味するわけではない — 同じ時間でより多くの仕事をするようになる

コーディングは「解決」されたのか

• 「coding is solved」は、「自分がやっている種類のコーディング」についてだけ成り立つ表現だ
  • Chernyの作るcloud CLI、デスクトップアプリ、モバイルアプリは比較的新しくシンプルなコードベースだ
  • 一方でNASAのような大口顧客の大規模で複雑なコードベースでは、まだ解決されておらず、モデルも完璧ではないためミスをする
• エンジニア側の反論（コーディングはタイピングではなく判断・センス・批判的思考であり、エージェントはそこが弱い）は妥当だ
  • Chernyの以前の1日も約50%だけが実際のコード入力で、残りはユーザーとの会話・ブレインストーミング・デバッグ・設計・計画だった
  • モデルがコーディングを担えば、エンジニアはユーザーと話し、次を構想するというより楽しい仕事へ解放される
• Claude Codeは6か月以上、100% Claude Codeで書かれており、Co-workなど他の製品も同様だ
  • 最新のY Combinatorバッチとの対談では、「コードの100%をClaude Codeで書いている」に数百人中半分が手を挙げ、「モデルでまったく書いていない」には1人だけで、残りは50〜100%の間だった
  • エンジニアリングの変化は、エンジニアリング以外のあらゆる分野に先行する指標だと見ている

• 能力低下への懸念とプログラミングの変遷

  • 直接コードを書かないと、自分の職業への理解が萎縮(atrophy) するのではないかという懸念がある
    • チームのエンジニアLenaは楽しみのために毎週末手でC++を書くといい、その余地は常にある
    • Chernyはこれを能力低下ではなく、プログラミングが常に変化してきた流れの一部と見る
      • ソ連時代のパンチカード、アポロ計画期の紙上での手計算も当時は「プログラミング」だった
      • その後、機械語 → アセンブリ → JavaScript・Pythonへと移り、今はエージェントと対話する方式へ、さらに近いうちにエージェントがエージェントに指示してコーディングする方式へもう一度変わると予想する
    • 関数電卓によって数学力の一部が衰えても、それでも使い続けるのと同じだが、その道具が超知能化してひそかに利用者を弱体化させる状況は別問題だ

• モデル性能後退論争

  • 新モデル公開後、「性能が大きく後退した」という反発が周期的に起きる
    • 実際にバグが原因だった事例は2件あり、Anthropicは原因と修正内容をブログで公開した
    • それ以外の多くは、ハネムーン期間のようにモデルに慣れるにつれて最初の驚きが薄れる現象である可能性が高い
  • 1年前と違って今は、モデルのコードのほうがChernyが自分で書くコードより優れている
    • 以前は1行ずつ3回確認する必要があったが、今はClaudeに任せ、結果を再確認・テストさせつつ、同時に15体のClaudeを並列実行している

生産性の逆説と選択肢の拡大

• 生産性が上がっても労働時間が減るとは限らないのは、かなりの部分が個人の選択と企業の状況に左右される
• 洗濯機の逸話で説明できる
  • 洗濯機以前は、1回の洗濯に5〜6時間かかり、約3,000ft歩く必要があり、火を起こし、水を沸かし、洗濯板でこすり、絞る作業を家族の人数分だけ毎日繰り返していた
  • 洗濯機は1回あたりの洗濯時間を約3時間短縮した
  • これは女性の大規模な労働市場参加を可能にした要因の1つだった
  • 節約された時間は、子どもと過ごす、散歩する、読書する、友人に会う、あるいは工場やオフィスの仕事に就くなど、個人の選択肢を生み、AIも同じように選択を広げる
• CS学位を取りたての22歳への助言：初級職は依然として存在するが、少しでも起業志向があるならスタートアップ創業を勧める
  • 歴史上もっとも起業しやすい黄金期であり、「あなたとエージェントたち」で巨大企業を作れる
  • 実際に1〜3人で10億ドル規模の企業や優れたスタートアップを作っており、1人あたりのレバレッジは巨大だ
• 3年後には「エンジニア」と呼ばれないかもしれないが、コードを書くか、エージェントでコードを作る人は今の100倍になるという見通し

Claude Co-work — 非エンジニア向けへの拡張

• Co-workは、人々が確定申告をしようとしてターミナルにClaude Codeをインストールするなど、コーディング以外の用途で使っている様子を見て始まった
  • 会計・財務・法務はもちろん、航空便予約、コンサートチケット購入、ワシントン州の貝採り許可の購入まで、さまざまな非エンジニアリング業務に使われている
  • コーディング製品はエンジニアが自分たちのために作ったものが他者にも役立ったが、Co-workは非エンジニア全般のために作る新しい挑戦だ
• 長時間実行能力が重要な方向性
  • 約1年半前のClaude Codeは、モデルの限界により30秒も経つと道を外れ、介入が必要だった
  • 今では毎晩、数百〜数千のエージェントが5・10・20時間動き続けており、これが現在のエンジニアリングのやり方になっている
  • Co-workも同じ方向へ進むが、どんな業務にそれほど長い実行が必要なのかはまだ不明だ
• メモリとユーザー理解が良くなれば、ニーズを先回りして予測する方向へ進化する
  • 例：残っているポッドキャスト回と未出演ゲストを把握し、候補をブレインストーミングして、最初の連絡メールを下書き保存しておく
  • 業務定義は「デザイン全体」のような水平的な方式と、特定目標を最後まで遂行する垂直的な方式に分かれうる
  • 垂直の例：Claudeが機能を作り、テスト・マージ・公開まで進める
• Opus 4.7からClaudeはより能動的になった
  • 機能公開後、12時間後にユーザーフィードバックを確認するよう自分でリマインダーを予約し、バグがあれば直そうとする — 人が忘れがちなことを先回りして処理するため満足度が高かった
• Claude Mythosはほとんどの人には外部公開されておらず、公開情報は主にコーディングとサイバーセキュリティ性能に関するもの — 通常の進歩より大きなジャンプで、サイバーとコーディングにとくに強い

雇用代替の責任は誰にあるのか

• この転換は良い効果と悪い効果が混ざり合い、正確な時期や比率は予測できない
  • Anthropicはソフトウェアエンジニアなどの失業要因になりうる特異な立場にある
  • エンジニアとして、近づく変化を知らせ、ツールの使い方を教えて一緒に連れていくべきだという強い責任感をチームで頻繁に議論している
• これは1社で解決できる問題ではなく、1社で解決するのも望ましくない（誤った解決策になりうる）
  • 社会全体で議論・討論すべき問題であり、Anthropicは経済レポートや政策議論、観察内容の公開で貢献している
• Anthropicが安全性研究所でありながら製品も作る理由の1つは、人々が実際に体験して理解し、社会的対応に参加できるようにするためだ — 技術を閉じ込めてしまうと、誰も視点を形成しにくい

パワーユーザーとAI格差

• デジタル格差がAI格差へ変わる懸念があり、これまでのデータはAIをもっとも上手く使う人がすでに高所得層に近いことを示している
  • Anthropicにはアクセス拡大のためのいくつかのプログラムがあるが、具体名や方法は示されていない
• もっとも大きな価値を得る利用者は、予想と異なることが多い
  • Opus 4.7公開ハッカソンの優勝者は、たいてい専門エンジニアではなく、電気技師・医師・大工がアプリを作ったケースで、直前の4.6ハッカソンでも同じ傾向だった
  • モデルが十分に洗練され、非専門家でもうまく扱える段階に来ている
• 大企業導入の鍵は、業務プロセスを変えてClaudeを中心に据えること
  • うまく機能する方法の1つは、全員にトークンを配り、安全に実験できるようにして、予想外の人からアイデアが出るようにすること
  • 最良のアイデアはシニアエンジニアではなく、隅にいる経理担当者やGTM担当者が作った社内ダッシュボードから出てくるかもしれない
  • 今日もっとも上手くツールを使う人が明日もそうだとは限らないため、全員がツール利用を学ぶことが重要だ

今後1年の見通し

• 来年は多くの混乱があり、大手プレイヤーは適応を試み、その多くが成功するだろう
• 一部の従来型ビジネスの堀は弱まり、一部は維持される
  • ネットワーク効果（利用者が多いほど価値が上がる）はAIと無関係に維持される
  • 規模の経済（限界費用の低下）も自然な優位性であり、消えない
  • 一方で切り替えコストは弱まる — ClaudeがベンダーAからBへの移行を手伝えるなら、もはや大きな堀ではない
  • 消えゆく堀に依存していた企業は苦しくなり、多くは新しい堀を探すことになる
• 予想よりはるかに大きなイノベーションが起きるだろう
  • 新しいアイデアは大企業ではなく、1・2・10人規模の小さなスタートアップからあふれ、その数は爆発的に増える
  • 素材発見スタートアップの例：石器時代・鉄器時代を経てシリコン時代に至ったという物語になぞらえ、新素材を見つければ次の時代に入ると考え、Claudeで可能な分子や設計を探索している
  • 以前なら資金調達すら難しかったことを、少人数チームが20年前には不可能だった突破口に変えられる
  • ドメインを深く理解した人が**「Claude軍団」**を持てば、人間の軍団を率いるよりはるかに多くのことを成し遂げられる
• ChernyはXとThreadsでのユーザー対応を自動化しているが、直接対応するほうを好んでいる
  • Claude Codeのループをルーティンへ移し、30分ごとに実行して、Threads API・X APIでフィードバックを収集している
  • ユーザーとの直接のやり取りがいちばん好きな仕事であり、「動かない」というフィードバックでさえ製品改善の源泉になる
  • Claude Codeには欠点が多く、理想的な製品にはほど遠いが、フィードバックを聞いて毎日少しずつ改善することが良い製品を作る唯一の方法だ