編集 | 伊風
これは私がこれまで聞いた中で最も堅実で客観的なAIプログラミングの講演だったに違いありません。
それは「奇跡」を語らず、「不安」を煽ることもありません。代わりに、非常に現実的な問いを投げかけました：
「今日、私たちは現実を検証できるでしょうか：
あの極度に楽観的なAIプログラミングの予測は信頼できるのか？それとも現実はそれほど魔法的ではないのか？」
マイクロソフトのCEOは、「コードの30%はAIによって書かれている」と言いました；
AuthoropicのCEOは数ヶ月前、「1年以内にすべてのコードがAIによって生成される」と主張しました；
しかし、なぜこれがエンジニアが実際に動かしている感覚と異なるのでしょうか？
なぜあるスタートアップの人がDevinを使ったのに、効率が上がらなかっただけでなく、バグが出て700ドルの事故コストを失った事故があったのでしょうか？
この講演はGergely Oroszによるものです――かつてUberのテクニカルリードを務め、後に専業の技術著者へと転身しました。
彼が書いた『The Tech Resume Inside Out』は一時「プログラマーの履歴書バイブル」と呼ばれ、現在は世界で最も人気のあるエンジニアリング系ニュースレターであるThe Pragmatic Engineerを通じて、数十万人の技術者に影響を与え続けています。
上記の問いに答えるため、彼は2ヶ月を費やし、AI DevToolsのスタートアップチーム、大手企業の社内エンジニア、AIバイオスタートアップ、そして「コードそのものを愛する」独立系開発者たちにインタビューを行いました。最終的に、AIプログラミングの現状についての多角的な視点を示す一枚の絵を組み上げました。
まず、予備的な結論をお伝えします：
- AI DevTools スタートアップ：ヘビーユーザー（当然ですが）；
- 大手企業：巨額の投資をしており、利用率は上昇中；
- AI スタートアップ：利用状況は不安定で、効果がある場合とそうでない場合がある；
- 独立系開発者：以前よりも興奮しており、使うことに積極的。
最も驚くべきは、真の「ベテランプログラマー」であるKent Beck（そうです、『Extreme Programming』の著者です）です。彼は第四のタイプの代表者です：
「私は今、過去52年間で最も楽しくコードを書いています。」 ——Kent Beck氏は今年でコードを書き始めて52年目です。
AIのおかげで、彼はSmalltalkを使って並列計算サーバーを書くなど、ずっとやりたかったけれど「複雑すぎたり、高価すぎたりする」と感じていたプロジェクトにようやく取り組むことができるようになりました。彼は言いました：
「技術スタックにおける『何が安く、何が高価か』という構図が書き換えられています。以前は諦めていたことの多くが、今では笑えるほど安価になっています。」
編集者がこの実りの多い講演を、読みやすく、情報満載の記事にまとめました。これからお読みいただく内容は以下の通りです：
- AI DevTools スタートアップ：9割のコードがAI生成、何千ものMCPリクエストが同時に実行される！
- GoogleとAmazon：LLMを開発ツールにどう統合するか？
- AI スタートアップ：Claude Code、Cursor、Windsurfなどの開発者はどう使っているのか？
- 独立系開発者：誰が「完全に変化」し、誰が「理性的に観察」しているのか？
- 最後に彼が残した4つの反省的な問い。どれも実際のエンジニアリングシーンに突き刺さるものばかりです。
Claude Code、Windsurfは9割がAIコード、Cursorはその半分
まず、AI DevToolsのスタートアップ企業についてです。
先週、Anthropicチームと話す機会があり、彼らが社内でどのようなトレンドを観察しているかを尋ねました。これらの企業には「自己利益的なフィルター」がかかっているのは避けられませんが、彼らの回答は非常に興味深いものでした。
彼らによると、初めて社内でClaude Codeをエンジニアに公開した際、ほぼ全員がすぐに毎日使い始め、その熱意は今も続いています。この「自然な利用開始」は彼ら自身にとっても少し意外だったそうです。
当時、これはまだ社内バージョンでした。Claude Codeが一般公開されたのはわずか1ヶ月前で、実際にはIDEではなく、ターミナルで動作するコマンドラインツール（CLI）です。
彼らはまた、現在Claude Codeという製品自体の90%のコードがClaude Codeを使って書かれていると教えてくれました。この数字は非常に誇張されており、まるで広告文のようです。しかし、私は専門にエンジニアに確認しました――彼らはマーケティング部門のように「演技」をすることはないので、この発言はかなり信頼できます。
彼らはまた、非常に興味深いデータも挙げました。Claude Codeが正式にリリースされた初日には、使用量が40%も急増し、3週間足らずで増加率は160%に達しました。理由が何であれ、このツールには確かに魅力があることを示しています。
さらに、AnthropicはMCP（Model Context Protocol）というプロジェクトも開始しました。彼らの目標は、IDEやAgentを、データベース、GitHub、Google Drive、Puppetなど、開発者が既存のコンテキスト環境に接続するためのプロトコルを使うことです。
私自身も試してみました。自分のAPIデータソースに接続し、直接「あるクーポンコードを受け取った人は何人いますか？」と尋ねたところ、自動的にSQLクエリを生成し、結果もかなり信頼できるものでした。この「自然言語でデータに接続する」体験は、確かに目を見張るものがありました。
彼らによると、MCPは昨年11月にオープンソース化されました。今年の初めには、いくつかの中規模企業が採用を開始し、3月、4月にはOpenAI、Google、Microsoftといった「大手プレイヤー」もMCPのサポートに参加しました。
現在、毎日何千ものMCPリクエストが実行されており、この講演の後半でもその重要性について言及されます。
Claude以外にも、私は他の2つのAI IDEチームと話しました：
- Windsurf：彼らは現在、チームの95%のコードがWindsurfのAgentまたは自動補完によって生成されていると言いました；
- Cursor：彼らの見積もりでは、40%から50%のコードがAIを使用しているとのことです。前の2つには及びませんが、彼らも率直に言って、一部は確かに役立つが、一部はまだ改善が必要だと述べています。
私はCursorの正直さに感銘を受けました。これらの企業はAIプログラミングツールを開発しており、「AI利用率」をできるだけ100%にしたいのは当然の売り文句です。しかし、Cursorは隠し立てしなかったわけで、それだけでも非常に貴重です。
Google：「慎重かつ長期主義」、すべてのAIツールは自社開発
私は匿名のGoogleエンジニア数名（約5人）と話しました。まず知っておくべきことは、Googleのすべてのエンジニアリングシステムはほぼ自社開発であるということです。
- Kubernetesは使わず、社内で自社開発したBorgを使用；
- GitHubは使わず、独自のコードリポジトリシステムを使用；
- 公開されているコードレビューツールは使わず、社内ツールであるCritiqueを使用；
- 彼らのIDEは自社開発システムであるCider（正式名称：Integrated Development Environment and Repository）です。
Ciderは当初ウェブツールでしたが、現在はVS Codeをベースとしたカスタムブランチへと進化しており、Googleの社内インフラストラクチャと高度に統合され、開発体験は非常にスムーズで、連携度も高いです。
エンジニアによると、現在AIツールはほとんどどこにでも存在しています。
Google社内では、すでに大規模言語モデルを独自のIDE「Cider」に統合しています。CiderはVS Codeをベースにしたカスタムブランチで、Cider Vというウェブ版もあり、自動補完や会話ベースのIDEが統合されています。彼らによると、使い勝手は悪くなく、Cursorほどではないかもしれませんが、全体的なパフォーマンスはかなり良好だとのことです。コードレビューツールCritiqueでは、AIがレビューフィードバックを提供することもでき、「非常に合理的で使える」と評価されています。
例えば、Google社内で非常に強力なツールであるコード検索も、現在LLMのサポートを統合しています。いくつかの質問をすると、関連するコード部分を特定してくれます。ほんの1年前には、これらの機能はGoogle社内ではほとんど使われていませんでした。しかし、半年で全てが変わりました。
現役のGoogleエンジニアの一人によると、Google社内でAIツールを推進する方法は非常に「慎重かつ長期主義的」だそうです。彼らはこれらのツールがエンジニアに真に信頼され、継続的に使用されることを望んでいます。
さらに、Google社内専用のツールも多数あります。例えば：
- Notebook LM：ドキュメントをアップロードして、それと対話できます；
- Prompt Playground：OpenAIのPlaygroundに似ていますが、GoogleはOpenAIがリリースする前からすでに開発していました；
- Moma：LLMベースの知識検索システムで、Googleエンジニアの間で広く使われています。
あるGoogler（匿名希望）の話では、現在、各組織（org）が独自のGenAIツールを開発しているとのことです。理由は単純で、リーダーシップ層がこうしたイノベーションを望んでおり、そうすることで社内リソースや予算の支援を受けやすいからです。Notebook LMのようなツールも、「あるチームが予算を確保して自ら開発を始めた」ものだそうです。
しかし、最も印象的だったのは、元SREの一人から聞いた話です。彼は多くのGoogleのSREと今も連絡を取り合っているのですが、現在、Googleのインフラストラクチャチームは「10倍のコード量」の増加に備えて準備を進めているそうです。彼らはデプロイメントパイプライン、コードレビューツール、機能スイッチメカニズムなどをアップグレードしています。
この話を聞いて、私は非常に興味を持ちました。Googleは、私たちがまだ気づいていない何らかのトレンドをすでに察知しているのでしょうか？
Amazon：AI採用はGoogleより積極的だが、かなり控えめ
AIツールについて語るとき、ほとんどの人は最初にAmazonを思い浮かべないでしょう。
AmazonのAI能力は外部にはあまり知られていませんが、内部のエンジニアと話してみると、ほぼすべての開発者がAmazon Q Developer Proというツールを使っていることがわかりました。これはAWS関連のタスクに非常に役立つとのことです。
私が驚いたのは、Amazonの内部の人々が、なぜ外部がこのツールについてほとんど知らないのかと疑問に思っていることでした。彼らは、「AWSを扱うなら、このツールのコンテキスト理解能力は特に素晴らしい」と述べていました。
約半年前、彼らはこのツールが「あまり良くない」と言っていましたが、今では多くの人が「本当に使いやすくなった」と言っています。
彼らはまた、AmazonのPR FAQ（6ページのプレスリリース風文書）を書く際にもAIツールを使っていると教えてくれました。年中行われるパフォーマンス評価の時期には、多くの文章作成タスクでAIを活用して加速させているそうです。
AmazonはAnthropicと提携しており、社内版のClaudeを持っています。
Amazonについて最も興味深いと感じたのは、社内でのMCP（Model Context Protocol）の推進です。
Anthropicが最初にMCPを提案しましたが、現在Amazonはそれを全面的に導入しているようです。
少し背景を説明します。Amazonは「API駆動」の企業であり、2002年にはJeff Bezosが有名な命令を発しました：
「すべてのチームは、サービスインターフェース（API）を通じて機能とデータを公開しなければならない。内部通信の使用は禁止されており、違反者は解雇される。」
これがAWSが誕生した根本的な理由でもあります。彼らのすべてのサービスはAPIを通じて公開されているため、今ではAPIに「アドオン」としてMCPサーバーを接続するだけで、AI Agentが直接接続して呼び出すことができ、非常に簡単です。
あるAmazon従業員から聞いたところによると、現在Amazon社内のほとんどのツールやウェブサイトがMCPをサポートしているとのことです。これはおそらく今回初めて公に言及されたことでしょう。
Amazon社内では自動化が至る所で見られます。多くの人がAIツールを使ってチケットシステム、メール、内部プロセスなどを自動処理しており、一部のエンジニアはすでにほとんどのワークフローを自動化していると聞きました。
外部では誰もこれらのことについて議論していませんが、それは確かに進行しています。Amazonは「API First」の企業として、2025年までに「MCP First」のリーダーに静かに転換しているのかもしれません。
スタートアップの二極化：熱狂する者と「手書きの方がマシ」と言う者
私はまた、いくつかの小規模なスタートアップ企業とも話しました。彼らはAIツールを専門としているわけではありませんが、日常の業務プロセスに徐々にAIを統合し始めており、中には「AI優先」の方向へと転換している企業もあります。
1. 支持者 Incident IO：チーム全体で利用し、「知識共創」の濃厚な雰囲気を形成
Incident IOは、もともとオンコールアラートプラットフォームを開発している会社でした。オンコールプラットフォームを扱っていましたが、AIは明らかにアラート、問題調査、解決策の推論に適しています。そのため、彼らは徐々にAIファーストの企業へと変貌を遂げました。
私は共同創設者であるLawrence Jones氏（今回のカンファレンス講演者でもあります）にインタビューしました。彼は私にこう語りました：
チーム全体がAIを大規模に利用して効率を向上させており、Slackでは利用テクニックやベストプラクティスを共有し、一種の「知識共創」の雰囲気が形成されています。
いくつかの具体的な例は非常に代表的です：
- ある人は、別のMCPサーバーを使って複雑なチケットを処理しようと試みたところ、AIが出した最初の草案が非常に信頼できるものでした；
- 彼がこの経験をグループに投稿すると、他のメンバーも次々に試用し、プロンプトの設計や生成ロジックについて議論しました；
- またある人は、「プロンプトの新しい使い方」を発見しました。AIに3～5つの異なるコード案を出させ、さらに「なぜこのように書くのか、別の方法ではどうなるのか」と問いかけるのです。
Lawrence氏は、最も重要な転換点はClaude Codeがリリースされてからの3週間だったと述べています。
彼はデータを確認したところ（当時は日曜日）、チーム全体がすでに日常的にClaude Codeを使用していることが判明しました。ブランドからの支援は一切なく、純粋にClaudeが非常に使いやすいと感じたからだそうです。
2. 不採用者 あるAIバイオスタートアップ：最新モデルでもニーズを満たせず、分野がニッチすぎたのか？
この会社はおよそ3年前に設立され、チーム規模は50人から100人程度で、システムアーキテクチャは非常にモダンです。Kubernetesをベースとした自動数値パイプライン、Python、Hugging Faceなどの技術を使用しています。
彼らのエンジニアは私にこう言いました：「多くのLLMを試しましたが、どれも本当に使えるものはありませんでした。なぜなら、AIが書いたコードを修正するよりも、手動で正しいコードを書く方がはるかに速かったからです。最新モデル、例えばClaude 3.7や、さらにはClaude 4を使っても、やはり同じでした。」
彼らは、自分たちの分野がニッチすぎて、LLMが効果を発揮するのに適していないのかもしれないと感じています。
このエンジニアはまた、匿名を希望するのは「AI懐疑派」のレッテルを貼られたくないからだ、と率直に語りました――しかし、これは真実です。
彼らは非常に速いペースで動くスタートアップ企業で、様々なAIツール（コードレビューアシスタントを含む）を試しましたが、最終的にこれらのツールが、彼らが開発している新型の複雑なソフトウェアには適用できないことを発見しました。彼らは試さなかったのではなく、試してみてダメだと判断し、すぐに方向転換したのです。
「これほど興奮したことはない！」――独立開発者とベテランプログラマーはAIコーディングをどう評価するのか？
スタートアップ企業の話を終えた後、私は何人かの独立系ソフトウェアエンジニアにもインタビューしました。彼らはAI時代が到来する前から非常に優秀で、「コードを書く」ということに深い愛情を抱いていました。
1、Flaskの作者Armin：私は今、AIエージェントエンジニアになりたい
Armin Ronacherは、Python WebフレームワークFlaskの作者であり、10年以上にわたって「純粋なコード書き」の技術者でした。彼は最近Sentryを退職し、自身の会社を立ち上げる準備をしています。
最近、彼は「AIがすべてを変えた」というタイトルの記事を発表しました。彼は非常に革新的な言葉を述べました：
「もし6ヶ月前に、私が自分でコーディングするよりも『AIエージェントエンジニア』になりたいと思うだろう、と誰かに言われたら、私は絶対に信じなかったでしょう。」
彼の変化には3つの理由があります：
- Claude Codeが本当にスムーズに使えること；
- LLMを集中的に使用した後、ついに「心理的な障壁を突破」し、AIとの協調モデルを受け入れ始めたこと；
- 最も重要な点：エージェントが自動的に実行し、フィードバックを観察できるというメカニズムが、「幻覚エラー」の影響を大幅に軽減できることです。
2、iOSツール作者Peter：私は再び「コードを書く情熱」を取り戻した
Peter SteinbergerはPSPDFKitの作者であり、iOSで最も人気のあるPDF SDKの創設者です。彼は会社を売却した後、新しい技術を探索し続けており、最近「The Spark Returns（情熱が戻ってきた）」というタイトルの記事を発表しました。
彼は転換点が訪れたと感じていると言いました。言語やフレームワークはもはや重要ではなく、AIツールのおかげでObjective-CからTypeScriptへ簡単に移行でき、何でも書けるようになったと。ツール層のデカップリング能力が非常に強力で、生産性が爆発的に向上したと語りました。
彼はまた、ソーシャルプラットフォームに投稿したジョークを私に共有してくれました：「多くの技術者がAIツールをいじって興奮して眠れない。」
興味深いことに、私たちは午前5時にメッセージをやり取りしていました。私は別の用事で早く目が覚めましたが、彼はコードを書いていて全く寝ていませんでした。
3、ThoughtWorksのBrigita：LLMは技術スタックの「横断的な力」
BrigitaはThoughtWorksのDistinguished Engineerであり、彼女はLLMの意義を次のようにまとめています。LLMは任意の抽象レベルで使用できるごく少数のツールの1つです。
それをアセンブリレベルのローコードツールとして使うこともできますし、高級言語を操作することも、さらには自然言語でプログラミングすることさえできます。これは単に「AIを一層追加する」のではなく、技術スタック全体に横断的に浸透するものです。
まさにこの「階層横断的な抽象利用能力」が、LLMを真にエキサイティングなものにしています。この言葉を語る人物自身も、AIが登場する前からすでに名声を築いていたベテランエンジニアです。
4、Django共同創設者Simon：真のブレークスルーは始まったばかり
Simon WillisonはDjangoフレームワークの共同創設者であり、ブログ執筆とオープンソースで生計を立てています。彼はAndrej Karpathyから「LLMブログの必読著者」と呼ばれています。
彼は言いました：
「コードエージェントは確かに動作し、繰り返し実行し、コンパイラをデバッグし、実務をこなすことができます。過去6ヶ月間で、大規模言語モデルの進化は明らかに一段階上のレベルに達し、今や本当に『使える』ものになりました。」
5、Kent Beck：52年のプログラマー人生、今が一番楽しい！
最後は重量級ゲスト：Kent Beck氏、エクストリームプログラミング（XP）の父、JUnitの作者、ソフトウェア工学界の生きる伝説です。
彼は言いました：
「私は今、過去52年間で最も楽しくプログラミングしています。」
彼は現在、Smalltalkを使って並列仮想サーバーのプロジェクトに取り組んでいます――それは長年の夢でした。
彼はLLMの登場により、ようやく本当にやりたいことに集中できるようになり、ツールフレームワークに縛られる必要がなくなったと言いました。
彼の目には、LLMはマイクロプロセッサ、インターネット、スマートフォンに続く、コスト構造を完全に変えるもう一つの技術の波として映っています：
「かつて高価で非現実的だと諦めていたことが、今や突然、信じられないほど安く、簡単になりました。」
考察：考えるべき4つの問い
これらのトレンドは非常に興味深いですが、私は「AIがソフトウェア開発を完全に変革した」とはまだ言えないと考えています。それは決して「確定的で、未来がすでに到来した」という話ではありません。
そこで私自身も4つの問いを立てました：
❓問い1：なぜ創業者やCEOはエンジニアよりもはるかに興奮しているのか？
一部のエンジニアは確かに非常に興奮していますが、例えばArminやPeterのように、彼ら自身が起業家タイプなのかもしれません。しかし、Warpの創業者Zack Lloydは的を射た問いを投げかけています：
「最もベテランのエンジニアがAIをあまり使わない一方で、最も熱心なのは創業者やプロダクトマネージャーであることに誰か気づいていますか？」
これはAIツールを開発する会社の創業者が反省している言葉です。
さらに、CEOたちの公開発言を見ると、ほとんどがAIの可能性を熱心に宣伝しています。これは私たちが考えるべきことです。
❓問い2：開発者におけるAIツールの使用はどれほど主流なのか？
私は会場で挙手してもらいました。「週に一度はAIツールを使ってコードを書く人は何人いますか？」
会場の約60～70%が挙手しました。
これはDXの調査データと一致しています。彼らが最近3.8万人の開発者を調査した結果は以下の通りです：
- 典型的な組織では、約半数の人が週にAIツールを使用；
- トップ企業では6割に達することも。
しかし、私の講演で述べたほとんどの例は、この中央値よりも高いことに注意してください（AIバイオスタートアップを除いて）。
サンプルバイアスもあるかもしれません――経験を共有したがる人は、もともとAIを使うことに積極的である傾向があります。
❓問い3：私たちは一体どれくらいの時間を節約したのか？
例えば、Peteは私に、生産性が10～20倍向上したと感じると言いました。
しかし、DXの調査では、AIツールは週に約3～5時間、平均で約4時間、開発者の時間を節約できると示されています。
4時間も悪くはありませんが、「10倍の効率向上」と言うと少し誇張に聞こえます。問題は、私たちは節約した時間を本当にさらなる価値創造に使っているのか？ということです。
私には分かりません。
❓問い4：なぜAIは個人開発者には特に効果的で、チームには効果が低いのか？
この現象は非常に一般的です。DXのLaura Tachoも私に、AIツールは「個人レベル」ではうまく機能するが、「組織レベル」ではまだ価値を発揮していない、と語りました。
CEOや創業者がこれほど熱心なのは理解できます。彼らの会社はAIに賭けており、財務的なプレッシャーも抱えているからです。
大手企業がAIツールに積極的に投資し、探索しているのも納得できます。
しかし、私が最も気になるのは、長年の経験を持つベテラン開発者たちです。彼らは本当に成果を出し、変化を感じ、さらなる投資を厭わないのです。
私たちは今、ソフトウェア開発の方法における「段階的な変革」の瞬間にいるのかもしれません。
私はソフトウェア工学の思想的リーダーであるMartin Fowler氏に連絡を取り、私がレビューした記事について意見を求めました。彼の返答は以下の通りです：
「LLMがソフトウェア開発に与える影響は、かつてのアセンブリ言語から高級言語への変革に匹敵するでしょう。
その後の様々な高級言語の更新は生産性を向上させましたが、あの『質的な変化』はありませんでした。
しかし、LLMは異なります。これはコンピュータの歴史上初めて『非決定性』を導入したツールであり、これが非常に重要です。」
結び
私の結論は：変化は起きており、私たちはより大胆に実験する必要があります。
私たちはスタートアップ企業のように、試行錯誤を重ねて、以下のことを明確にすべきです：
- 何が効果的なのか？
- 何が無用なのか？
- 何が本当に安くなったのか？
- 何が本当に投資に値するのか？
この講演はここで終わりですが、その内容は堅実で、視点は多角的であり、深く考えさせられます。
この講演における観察について、あなたは共感を覚えましたか？
AIによるコード記述は、あなたにとって力になるものでしょうか、それとも混乱の元でしょうか？コメント欄で率直な感想をぜひお聞かせください。