Featuring

Sponsors

Depot – ビルドが10倍速くなる？ ぜひお試しください。 より速くビルドし、無駄な時間を減らしましょう。DockerイメージのビルドとGitHub Actionsのワークフローを高速化します。既存のCIプロバイダーや開発ワークフローに簡単に統合でき、ビルド時間を大幅に短縮できます。

Tiger Data – 開発者、デバイス、エージェントのためのPostgres IoTからWeb3、AIまで、数十万人が信頼するデータプラットフォーム。

Notion – Notionは、あらゆるチームが書き、計画し、整理し、遊び心を取り戻せる場所です。ただ進捗を生み出すだけでなく、インスピレーションを得るためのワークスペースです。Notionは、Fortune 500企業からフリーランスのデザイナー、新規スタートアップ、授業とクラブを両立させる学生まで、誰もが使えるものです。

Fly.io – Changelog.comのホーム — ユーザーの近くにアプリをデプロイしましょう。グローバルAnycastロードバランシング、ゼロ構成のプライベートネットワーキング、ハードウェア分離、即時WireGuard VPN接続を実現します。数千インスタンスまでスケールするワンクリックデプロイ。speedrunをチェックして、数分で始めましょう。

Notes & Links

📝 Edit Notes

Chapters

1 00:00 This week on The Changelog 01:26
2 01:26 Sponsor: Depot 02:18
3 03:44 Start the show! 01:47
4 05:31 AI Engineer (AIE) Code Summit 2025 03:58
5 09:29 What is/was Pusher? 03:34
6 13:03 How are today's days different? 02:17
7 15:20 SaaS is dead!? 13:52
8 29:12 Sponsor: Tiger Data 02:30
9 31:41 No code review? What's replacing it? 02:52
10 34:33 Opus 4.5 changed things (really Sonnet 4.5 first) 03:16
11 37:49 Is Saas REALLY dead? Hmm... 04:38
12 42:27 Inviting non-technical folks to Terminal 05:18
13 47:44 What if everything was JIT? 03:40
14 51:24 It's Layercode time 12:31
15 1:03:55 Sponsor: Notion 02:09
16 1:06:04 Set on Cloudflare workers (and TypeScript) 04:00
17 1:10:04 Why not Go (or...)? 03:53
18 1:13:58 Directing the interupt 02:41
19 1:16:39 API vs local models - latency and reliability 10:09
20 1:26:47 The era of the small giant 07:09
21 1:33:56 What's next? What's over the horizon? 02:23
22 1:36:19 Bye friends! 00:38
23 1:36:57 Closing thoughts and stuff 01:15

Transcript

📝 Edit Transcript

[00:00] 皆さん、こんにちは。長年の友人であり、このポッドキャストの最初のスポンサーでもあるDamien Tannerと一緒にいます。Damienさん、17年ぶりの再会ですね。The Changelogの制作18年目です。Wynn Netherlandと私が2009年にこの番組を始めた頃、DamienさんはPusherを運営していました。当時、ポッドキャストへのスポンサーはほとんど慈善活動のようなものでした。大きなオーディエンスはなくとも、ポッドキャスト制作者を応援したいという気持ちがあったのです。そして今、ソフトウェア開発の世界は大きく変わりました。GitHubが生まれたばかりの頃から、AIエージェント時代へと移り変わる中、Damienさんが最前線で何を築いているのか、お話を伺います。

ありがとうございます。Pusherを振り返ると、ロンドンを中心に世界中で素晴らしいコミュニティを築くことができました。Pusher Sessionsというイベントシリーズも始めました。そして今、Mastraで働くAlex MacCawが、私が主催するAI Engineer Londonミートアップで登壇することになっています。巡り巡ってまたつながるんですね。

了解です。最近のAIカンファレンスには参加されましたか？ 私はサンフランシスコで参加しました。

どんな感じでしたか？ Pusher時代の開発者と今の時代を比較して話したいので、深入りはしませんが、SFのAIカンファレンスはどうでしたか？

良い経験でした。SFに行くといつもエネルギーをもらえます。私はロンドン郊外に住んでいますが、会場はかなり大きく、競合他社のような一体感は少なかったですね。ただ、巨大なカンファレンスホールでWindsurfなどのセッションを聞きながら、「私たちは採掘の自動化に関するカンファレンスに来た鉱夫のようだ」と感じました。私たちはエンジニアとして興奮していますが、私たちの仕事そのものを変えようとしているわけです。明日自分がやっていることを全部変えようとしている、というのが奇妙な感覚でした。

私は現地には行けませんでしたが、Swyxをはじめとする多くの素晴らしい人々のコンテンツをオンラインで見ていました。技術の最前線を形作っている人々が集まっているのを感じました。技術者として長年関わってきた私たちにとって、技術は人類の未来を形作る大きな力です。そして今、次の大きな変革の瀬戸際に立っていることを実感します。すべてが変わっていく様子を目の当たりにするのは本当に刺激的です。

[04:05] Pusher時代を振り返ると、当時はWeb 2.0と呼ばれる時期で、インターネット上で素晴らしいソフトウェアが次々と生まれていました。特にRailsコミュニティでは、職人技を活かした素晴らしいウェブアプリケーションが作られていました。その後、SaaSの商業化・産業化が進みました。今、私がAI Engineer Londonを運営する中で感じるのは、あの頃のエネルギーが再び戻ってきているということです。新しいものが生まれ、誰もが参加でき、みんなで手探りで作り上げている。そのエネルギーが本当に興奮します。

ユーモアのあるトークもありました。真剣になりすぎず、楽しく取り組む姿勢が印象的でした。

Pusherとは何だったのか、そして当時と今とで何が違うのか、改めて説明していただけますか？

PusherはWebSocketを使ったプッシュAPIでした。ウェブアプリにリアルタイムで何かをプッシュできるサービスです。金融や暗号資産など、価格をリアルタイムで更新する必要がある分野で多くの顧客がありました。初期の頃はUberもPusherを使って車両の位置をリアルタイムで更新していました。私たちはRailsアプリを構築するコンサルティング会社を運営していましたが、WebSocket接続を管理する独立したサービスが必要だと考え、シンプルなアイデアを真剣に取り組んで、数百万人の開発者に使われるツールに成長させました。現在も広く使われており、最終的にMessageBird（欧州のTwilio競合企業）に買収されました。Twilioに売却する話もあったのですが、実現すれば全く違う道筋になっていたでしょう。

私のメモによると、920万ドルの資金調達をされました。当時としては非常に大きな金額でしたね。2010年か2011年頃ですか？

大部分は後でBaldertonから調達したものです。最初のラウンドは50万ドル程度の小規模なものでした。最初はエージェンシーとしてスタートし、最初のバージョンをそこで作りました。遊び心もあったと思います。

そして最終的に買収に至りましたが、Twilioとの話があったそうですね。もしTwilioに売却していたら、どのように違っていたと思いますか？

[08:09] Twilioのチームと働くのは素晴らしい経験だったでしょう。TwilioはDevRelや開発者コミュニティの先駆けとなりました。私たちはTwilioと合同イベントやハッカソンを多く開催しました。あの頃は本当に楽しかったですね。

Jeff Lawsonをはじめとする人々が、開発者向けマーケティングの新しい形を作り上げました。DevRelという概念の種を蒔いた一人だと思います。

Pusher時代、ウェブやAPI、SaaSサービスの構築、そしてRailsアプリへのメッセージプッシュといった活動と比べて、今日の時代はどのように違うと感じていますか？

ウェブとソフトウェアは再び大きく変わろうとしています。Web 2.0の頃は、インターネット上でホストされるソフトウェアが生まれる時代でした。今、私たちはSaaSの時代に生きていますが、SaaS以前の時代があったように、SaaS以後の時代も来る可能性があります。技術は常にレイヤー状に積み重なっていきます。銅線電話回線がまだ残っているように、変化には時間がかかりますが、方向性は急速に変わります。近年、私は自分でエージェントやLLMを実際に使ってみて、ポストSaaSの時代が来る可能性を強く感じています。開発者たちはすでに、SaaSを構築する代わりにエージェントやLLMを使って作業を進めています。

SaaS以前の時代と、SaaS以後の可能性について考えるのは興味深いですね。あなたは事前の打ち合わせで「すべてのSaaSは死ぬ」とおっしゃいました。その理由を詳しく説明していただけますか？

まずはその結論に至るまでの経緯をお話しします。

まず結論（TLDR）を教えてください。その後、経緯を詳しくお聞きします。

了解です。TLDRはこうです。ソフトウェアには「構築」と「運用」の2つの側面があります。開発者は「構築」の変化をよく理解していますが、「運用」の部分も大きく変わろうとしています。SaaSは人間が使うために作られています。UIは人間が理解し、操作できるように設計されています。しかし、AIがその作業を行うのであれば、SaaSツールは必要なくなるかもしれません。AIはSaaSツールを必要とせず、作業を直接行うことができます。人間が使うソフトウェアの概念自体が変わる可能性があります。

APIやSaaSに長年携わってきたあなたが、SaaSのUIが人間向けに作られているという点に同意するのは当然だと思います。では、SaaSの真の解決策は何でしょうか？ 私はCLIが新しいアプリになると思います。SaaSはCLIに移行し、エージェントがAPIやJSON、明確に定義されたエンドポイントを通じて作業を行うようになるでしょう。

SaaSを「ビジネス」と「ソフトウェア」の2つに分けて考える必要があります。インターフェースは変わります。視覚的なUI、CLI、チャット会話など、ソフトウェアとのコミュニケーション方法は自然言語に近づいていきます。また、SaaSとしてリモートでアクセスしていたソフトウェアの多くが、ローカルや社内で直接利用可能になる可能性があります。SaaSビジネスの課題は、企業がどのようにシフトしていくかです。認証、データストレージ、クラウドインフラなど、依然として必要なものはありますが、すべての企業が同じバージョンのソフトウェアを購入する必要はなくなるでしょう。

その考えに同意します。では、SaaSが死ぬ（または衰退する）という発言の背景にある経緯を詳しく教えてください。

私の会社Layercodeについて簡単に説明します。私たちは音声エージェントプラットフォームを提供しています。開発者はAPIを使って自分のエージェントに音声を追加できます。最初は通常の方法で営業・マーケティングを始め、CRMやマーケティングツールを導入しましたが、これらのツールは非常に遅く、使いにくいものでした。そこでClaude CodeやCodexを使って、音声で15分程度ブレインストーミングを行い、「自分が必要とするCRM」を作ってもらいました。結果として、非常に良いCRMが完成しました。そして、既存のCRMを解約し、他のツールも同様に置き換えていく予定です。ソフトウェアを構築した後で使うのではなく、使いながら改善していくサイクルが生まれています。

GitHubなどのリポジトリをハブとして使い、プルリクエストやコードレビューを行っているのですね。

はい。ただし、それも変わっていくでしょう。

その点について詳しく教えてください。

CRMや今週構築した新しいソフトウェアは、既存のコードベースではなく、ゼロから作ったものです。既存のプロジェクトでLLMを使うと、LLMの「味」が悪く、防御的なtry-catchや冗長なコードを生成しがちです。しかし、新規プロジェクトでYOLOモードで構築すると、コードレビューは必要ないかもしれません。人間がコードを書かなくなるので、コードレビューやSOC 2などのプロセスを根本的に見直す機会があります。

エージェントファーストの方向に進んでいるように感じますね。

潮流に引き込まれている感覚です。CursorやTabを試し、通常の泳ぎ方で進もうとしていたら、急に「リラックスして流れに身を任せろ」と言われているようなものです。

コードレビューがなくなることについては、まだ答えはありません。しかし、AIコーディングエージェントを使っているチームでは、PRが大量に発生し、レビューがボトルネックになっています。一方、コードレビュープロセスを持たない新しいチームは、すでに数倍速く開発を進めています。

コードレビューに代わるものは何でしょうか？ 何もないのでしょうか？

PMやデザイナー、マネージャーの視点で考える必要があります。彼らはコードを見ず、機能要件が満たされているかを確認します。LLMがまだ完璧ではないため、人間が関与する必要がありますが、これは変わっていくでしょう。

LLMはまだミスをしますが、Opus 4.5以降、変化を感じています。「モデルを信頼せよ」という考え方にシフトし、ミスを恐れず、むしろミスから学ぶ姿勢が重要だと感じています。

[30:03] モデルを信頼することで、予想外の結果を得られることがあります。以前は関数を正しく書けた瞬間にドーパミンが得られましたが、今はアプリケーション全体が動作した瞬間に大きな達成感があります。

非常にエキサイティングです。ソフトウェアの作り方は変わりますが、作るべきソフトウェアはまだたくさんあります。政府サービスなど、まだ改善の余地があるソフトウェアは多いです。開発速度が10倍、100倍になっても、作るべきものは尽きないでしょう。

SaaSが死ぬ（または衰退する）という場合、私たちは何を作ることになるのでしょうか？ プラットフォームを構築し、人々がそれを利用するのであれば、それはSaaSではないのでしょうか？ インターフェースが変わるということでしょうか？

次の段階として、私はCRMを使い始めた後、「なぜ自分がこの作業をしているのか」と疑問を持ちました。Claude Codeに作業を任せられるのではないかと考え、LinkedInやX、必要なAPIに接続して作業を自動化しました。最初は遅かったですが、非常に良い結果が得られました。Claude Codeは人間がコンピュータ上で行う作業を代行できる可能性を示しています。ツールへのアクセスやインターフェースとの統合が改善されれば、さらに可能性が広がります。

非技術者にもターミナルを開いてCLIを使ってもらうことで、開発者への一歩を踏み出せる可能性があります。

実際に試してみましたが、非技術者にとってターミナルはまだハードルが高いようです。

ターミナルをClaude Codeだけに特化したものにすればどうでしょうか。

Co-Workというツールを試しています。PDFのディレクトリを指定して分析させたり、アイデアを出させたりしましたが、まだ改善の余地があると感じています。Claude Codeのインスタンスにディレクトリを指定して、データベースと連携させることで、非技術者でも「最新のリードを表示して」と簡単に操作できるようになります。

「これを簡単にできないか」と頼むと、Claude CodeがUIを自動生成してくれることもあります。

「I like it, implement it.」という短い返事で機能を実装できるほど、簡単になってきています。

私は「Y」とだけ返事することが多いです。曖昧でもLLMが判断してくれることが多いので。

AnthropicがリリースしたCo-Workは、社内でClaude Codeを使う人々のニーズから生まれたものです。LLMが10倍速くなれば、静的なインターフェースではなく、必要に応じて即座にインターフェースを生成する時代が来るでしょう。

すべてがジャストインタイム（JIT）になる世界を想像しています。チームメイトと共有する必要がなく、それぞれが自分のブランチで必要なインターフェースをその場で作り、問題を解決する。保守性やコードの品質は二の次で、問題を解決できれば良い。そうした考え方は、ソフトウェアの概念そのものを変えるでしょう。

究極の形は「誰もが開発者になる」ことです。認証と認可があれば、誰でも自分の望むソフトウェアを作れるようになります。

エージェントは先回りして、ユーザーが必要とするUIを自動生成することも可能になるでしょう。

これは人間同士のコミュニケーション方法に似ています。会話、メール、非同期のやり取り、プレビューURLの共有など、エージェントとのコミュニケーションも多様なチャネルを持つようになるでしょう。

人間とコンピュータのインタラクションという観点で非常にエキサイティングです。Layercodeが提供する音声は、人間が最も古くから使ってきたコミュニケーション手段です。エージェントが音声、テキスト、ウェブUIなど、複数のメディアを柔軟に扱えるようになれば、コミュニケーションの境界はなくなっていくでしょう。

では、Layercodeについてお聞きします。私はポッドキャストを制作しているので、音声からテキストへの変換にも関心があります。Layercodeとは何で、どのようなことを目指しているのでしょうか？

AIの進化は、あなたのLayercodeに対する考え方や、1日ごと、さらには分単位でのモチベーションにどのような影響を与えていますか？

[46:29] 今日のファウンダーは、会社を構築するだけでなく、会社をどのように運営するかも重要です。数年前と同じ方法で会社を運営していては、AIを活用する競合に大きく遅れを取ることになります。私たちは「小さいチームで大きな会社を作る」ことに注力しています。チームが大きくなると、HRや政治、文化の変化が避けられませんが、小さいチームであれば文化を維持しつつ、素早く動くことができます。

Layercodeが提供するのは、リアルタイム音声AIエージェントを構築するための音声インフラ・音声APIです。会話の割り込みやバックチャネリングなど、リアルタイムの会話特有の問題を解決しています。開発者は既存のエージェントバックエンドにLayercodeのAPIを接続し、任意のLLMやエージェントライブラリを使うことができます。Next.jsアプリケーションであればVercel AI SDKと組み合わせ、ブラウザSDKを追加するだけで音声エージェントのマイクボタンが利用可能になります。電話通話にも対応しています。

ユーザーの発話が完了したと判断されると、トランスクリプトをバックエンドに送信し、LLMで応答を生成、ストリーミングでテキストを返却します。Layercode側でテキストを音声に変換し、ユーザーにストリーミングで返します。低遅延でリアルタイムな会話を可能にするため、さまざまな最適化を行っています。また、トランスクリプションやテキスト-to-スピーチのモデルを切り替えることも可能で、遅延、価格、品質のトレードオフを調整できます。

Next.js SDK、ストリーミング、低遅延——Layercodeは実装とユーザーへのフィードバックの間にあるミドルウェアのような役割を果たすのですね。

はい。音声に関するすべての処理をLayercodeが担当し、開発者はテキストベースのチャットボットと同じように扱うことができます。

MP3やWAVファイルがダウンロードされるわけではなく、ストリーミングなのですね。

すべてがストリーミングで処理されます。新しいセッションが開始されると、Cloudflare Workers上でユーザーの近くで実行されます。マイク入力はリアルタイムでトランスクリプションモデルにストリーミングされ、部分的なトランスクリプトが返されます。ユーザーが話し終えたかどうかを判断するのは非常に難しい問題で、AIモデルを活用して検出しています。十分な信頼度が得られた時点でトランスクリプトを確定し、バックエンドに送信します。

ユーザーが話し終えたかどうかを判断するため、追加のAIモデルを使って検出しています。会話は動的で、途中で沈黙したり、言い直したりするので、確実な判断は難しく、十分な信頼度が得られた時点でトランスクリプトを確定しています。