AIに奪われる前にエンジニア職を辞めた理由 | Better Stack Podcast 第16回

BBetter Stack
Computing/SoftwareSmall Business/StartupsAdult Education

Transcript

00:00:00Better Startポッドキャストへようこそ。ここではAIやソフトウェア、開発
00:00:04そしてあらゆる種類の新しいテクノロジーについて語り合います。ホストのRichardです。そして…
00:00:09Jamesです。
00:00:10Andresです。
00:00:11そしてElliotです。
00:00:13Elliot、参加してくれてありがとう。さっきオフラインでも話したけど、僕らはみんな
00:00:18君のYouTubeチャンネルのファンなんだ。実は両方のチャンネルともね。Dreams of Codeと
00:00:22Dreams of Autonomyだよ。まあ、その話は後で詳しく聞くとして。視聴者のために
00:00:27君のことを知らない人のために、自己紹介をお願いできるかな?
00:00:30もちろんです。Richardが言った通り、YouTubeチャンネルを2つ運営しています。
00:00:37YouTubeを始めてもう3年ほどになります。でも元々は
00:00:42ソフトウェア開発者でした。2012年からプロとして開発を続けています。
00:00:472007年に学習を始めて、大学でコンピュータサイエンスを学びました。それ以来
00:00:52ずっと夢中になり続けています。だから今こうして、ソフトウェア開発についての動画を作っているんです。
00:00:57素晴らしいですね。
00:00:59君の動画は、ある意味でプライマリー・ジェン(ThePrimeagen)に似ていると思うよ。
00:01:06ターミナルツールに焦点を当てているからね。君は
00:01:10ずっとNeoVimを使うようなターミナル派だったのか、それとも徐々にそうなったのかい?
00:01:13大学時代にコンパイラ作成の授業があったんです。その科目の前提条件の一つに
00:01:21Unix環境にSSH接続して、Vimで作業するというのがありました。だから強制的に
00:01:28C++でコンパイラを書くだけでなく、Vimもマスターしなければなりませんでした。多くの人は
00:01:34ストックホルム症候群のようにして好きになったんですが、僕も間違いなくそうでしたね。
00:01:40それでVimを学びました。当時はまだIDEも使っていましたが、その授業のおかげでVimの経験は積めました。
00:01:48最初の仕事も、Unix環境にSSHで入り、C++をVimで書くというものでした。そこから自然と
00:01:54定着したんです。それ以来、ほとんどずっとVimで作業しています。何でもできるエディタですからね。
00:02:01Appleのツールを使う必要があった時期にXcodeを使っていた以外は、ずっとVimです。
00:02:06Appleのツールを使う必要があった時期にXcodeを使っていた以外は、ずっとVimです。
00:02:11最近はYouTubeでVimユーザーのルネサンスというか、語る人が増えたよね。
00:02:17そうですね。ThePrimeagenの影響が大きいです。多くの人に
00:02:21NeoVimやその関連ツールを見るよう勇気づけてくれましたから。でも、昔から
00:02:27楽しんでいる層は常に存在していたと思います。僕がYouTubeを始める前、プログラミング系の
00:02:32動画を見る前ですら、ツールについて語り合っている人たちは
00:02:35ネット上にいました。NeoVimやEmacsには、ある種の熱狂的な支持者が常にいたんです。
00:02:41Emacsも試しましたが、僕にはあまり合いませんでしたね。
00:02:46以前、Bash Bunnyというゲストが来たんだけど、彼女はDoom Emacsの大ファンなんだ。
00:02:51元々はNeoVimユーザーだったんだけど、OrgモードのためにDoom Emacsに移ったそうで。
00:02:57僕はまだ使ったことがないけど、かなり気に入っているみたい。
00:03:00Orgモードは素晴らしいですよ。他には代えがたい、驚異的なツールです。
00:03:08Emacsをいじっていた時、設定ファイルのinit.el全体を
00:03:15Orgモードで書いたんです。ドキュメント形式なのですが、すべてのコードブロックを
00:03:20保存するたびに、実際にファイルとして書き出されるように設定できるんですよ。
00:03:26本当に強力なんです。できることが独特で、
00:03:30あれはElispがあるからこそ実現できるんですよね。ええ、全くその通りです。
00:03:35告白すると、僕はこれまでVimやNeoVimのファンではなかったんです。
00:03:40でも最近は少し心が揺れています。AIのおかげですね。Claude Codeが
00:03:46コードを書いてくれるので。最近はCursorなどのツールを開くのが嫌なんです。
00:03:50AI機能で埋め尽くされているから。僕はターミナルでClaude CodeやCodexを使っています。
00:03:55コードを読みたいだけなのに、AIが次々と出てきて邪魔なんです。
00:03:59ちょっとした編集をしたいのに、タブ補完が勝手に動いたり。Cursorは
00:04:03売り込みたい機能を見せつけてくるようで、少しうんざりします。
00:04:07コードを読み書きするだけでいいのに。それで最近、移行を考えているんです。
00:04:12それは本当によく分かります。君はもともとターミナルで作業しているから
00:04:17ターミナルに留まるのが一番理にかなっていますよね。
00:04:22今のNeoVimで僕が一番気に入っているのは、
00:04:25AIのオートコンプリートが一切入っていないことですね。純粋に
00:04:30コードを読み、ナビゲートし、編集したい時だけ編集する。それがいいんです。
00:04:33素晴らしいですね。君のコンテンツはCLIツールに焦点を当てたものが多いですよね。
00:04:38僕は君の動画でZeoxideを知りました。他にも色々な
00:04:44ツールを紹介しているよね。Crocとか、盆栽のツールとか。面白いツールはどうやって探しているの?
00:04:49そして、ツールにハマるきっかけは何なんだい?どうやって探すか、良い質問ですね。
00:04:55普段からネットを徘徊しています。フォーラムをチェックしたり、他の人が
00:05:01何を使っているか見たりして、自分の問題を解決してくれそうなものを探します。
00:05:06Zeoxideは本当に大きかった。ターミナルでのディレクトリ移動は
00:05:12これまでずっと面倒だったので。一度Zeoxideを使うと
00:05:18もう元には戻れませんね。少しニッチなツールを探すのは大変でした。
00:05:23以前人気ツールを紹介する動画を作ったんですが、今はみんな知っているものばかりだから、
00:05:28もっとマニアックなものを紹介したくて。徹底的に調査しましたよ。
00:05:32GitHubで星の数を探したりね。いいツールはたいていそこから見つかります。
00:05:38GitHubでCLIツールを探すと、良いものがすぐ見つかりますから。
00:05:43Zeoxide、本当に便利だよね。使っていない環境で
00:05:47いつものように`cd`で移動しようとして「ない!」ってなる時の絶望感。
00:05:51本当にZeoxideがないと耐えられないよ。圧倒的に速くて便利だ。
00:05:55新しいマシンに移った時に履歴がないのは悲しいですよね。
00:06:00そういえば、君がGoでコース作成プラットフォームを作っていた過程を追いかけていたんだ。
00:06:06そのことについて話してくれるかな?実は最近、Goから変更したんです。
00:06:12最初はGoで構築したのですが、それは経験としてはとても良かったですよ。
00:06:20当時はHTMXが盛り上がっていた時期で、大規模なプロジェクトで使えるか試したかったんです。
00:06:26実際に試して、大規模なプロジェクトで実用可能かどうかを確認したかったんです。結果としては賛否両論ですね。
00:06:32間違いなく使えるとは思いますが、現代的なウェブ体験を追求しようとすると難しくなってくるように感じました。
00:06:39少し難しくなってきます。Go自体はとても適していますね。
00:06:45特にTempleのようなパッケージは、Reactのようなコンポーネントベースの
00:06:51ビュー構築には最適です。HTMXとのハイパーメディアアプローチは、
00:06:56かなりうまく機能します。問題は
00:07:02より複雑なクライアントサイドの対話が必要になった時です。
00:07:06Alpine JSという良い選択肢もありますが、複雑になればなるほど
00:07:12JavaScriptをバニラで書く必要が出てきて、
00:07:18ええ、あの頃から脱却できて本当に良かったと思います。今よりずっと大変でしたから。
00:07:22なるほど。具体的にはdocument.selectElementのようなことを指しているのですか?それとも――
00:07:28そう、DOM操作もそうだし、JavaScriptの構成を
00:07:35適切に維持するのが大変なんです。フレームワークを使わずに
00:07:40スクリプトを読み込む昔ながらの方法だと特にね。
00:07:45jQueryを使おうかと本気で考えましたよ。それくらいひどかった。
00:07:50PHP/Laravel界隈でHTMXの代わりになるようなツールを作っている人がいて、
00:07:57…Alpine JSのことですね。Alpine AJAXというツールも
00:08:03あるのですが、知っていますか?そう、Alpine AJAX。あれも検討しましたよ。
00:08:08Alpineエコシステムに統一できたら良さそうだなと思って。
00:08:13結局、Next.jsで書き直すことにしました。ちょうどエージェントの時代が到来して
00:08:19Claude Codeを他より早めに使い始めたのですが、
00:08:24あれが驚くほどGoのWebサイトをNext.jsに変換できたんです。
00:08:29その結果としてNext.jsに移行しました。さて、Goのコースプラットフォームの話に戻りますが。
00:08:36君の旅路を追っていて、考えさせられました。
00:08:41YouTuberとして、何か別の収益源が必要ですよね。
00:08:47その代替としてコースプラットフォームを作ったわけですね。
00:08:52プロモーションや顧客獲得はどうでしたか?
00:08:58正直に言うと…
00:08:59プロダクトを売る人間としては最低限のマーケティングしかしていません。
00:09:06それは根本的な欠点です。ビルドは半分で、残りの半分はマーケティングですから。
00:09:11GoでCLIアプリをどう作るかを教えたくてコースを作ったのですが、
00:09:17システムレベルの話まで踏み込んでしまいました。ファイルストリームなど、
00:09:23CLIアプリを作る上で不可欠な基礎です。
00:09:27フレームワークをただ使うんじゃなくて、OSの深い理解に触れるような内容です。
00:09:33低レイヤーの技術的基礎を身につけることを目指しました。
00:09:38GoはOSの深淵までは行きませんが、必要な理解は十分に得られます。
00:09:44これをビジネスにするのは難しかった。YouTubeのAdSenseだけで
00:09:51食べていくのは厳しいですよね。
00:09:54AdSense収入は月数千ドルですが、アメリカで暮らすには十分とは言えません。
00:10:00だからプロダクト販売が必要でした。コースは悪くない収益でしたが、
00:10:07フルタイムの仕事として成り立つほどではありませんでした。
00:10:15AIが登場して、プログラミングの学習方法が劇的に変わってしまったから。
00:10:21それに僕はマーケティングが下手なんです。もっと必死にやっていれば成功したかもしれませんが。
00:10:28YouTubeで今一番稼げるのはスポンサー案件ですよね。
00:10:32コースの収益より、スポンサーを3つ受ける方が稼げたかもしれません。
00:10:38コースの需要は減っているように見えますか?プログラミング言語を学ぶ気力が…
00:10:45コース自体はもう下火になったのでしょうか?人々はもう
00:10:51プログラミング言語の学習に興味がないのでしょうか?ええ、まだ売れてはいます。それはそれで嬉しいことです。
00:10:59収益にはなっています。ただ、以前と比べるとなんとも言えません。なぜなら、今はもう以前ほどこのプラットフォームについて
00:11:05宣伝していないからです。多少はリンクを貼ったりしていますが。でも、確実に衰退はしています。その時期も大体わかります。
00:11:13Web Dev Simplifiedも最近動画で言っていました。AIが何でもやってくれるから、
00:11:21YouTubeのコーディングチュートリアルを見ても、視聴者数が激減しているのが分かります。
00:11:27Web Dev Simplifiedも最近、AIの登場以来再生数が落ちたと動画で語っていました。AIが代わりにコードを書いてくれるなら、わざわざ学ぶ必要はないと考える人が増えたのでしょう。
00:11:39興味深いジレンマですよね。学びは依然として重要だと思いますが、一方で時間の無駄だと感じる人がいるのも理解できます。いろいろな考えが頭をよぎりますが、何が正解なのか分かりません。私は今、基礎を再確認するためにRustの教本を読み返しています。やはり、それくらい重要なことだと思うからです。AIに対しては多くの人と同様に複雑な心境ですが、
00:12:09それでも学びには価値があるはずです。AIがすべてをこなす現在、結果が抽象的に感じられたとしても、基礎となる知識や理解を身につけておくことは非常に有意義だと考えています。
00:12:24AIでできるのは、せいぜい一人のユーザーが使うような基本的なアプリまででしょう。いざシステムをスケールさせたり最適化したりとなれば、基礎知識や新たに獲得した深い知識が必要になるはずです。
00:12:38必ず知識が必要になりますから。
00:12:39AIがコードをすべて書いてくれるとしたら、初心者はどうやって学べばいいのか。どうやって学習を促せばいいのか、悩ましいところです。私自身、システム言語は何も知りません。Rustは少し触りましたが、深くは理解していません。Zigがクールだという話を聞いて試そうかと思っているのですが、YouTubeコースを見るべきか、それともClaudeに教えてもらうべきかと考えていました。
00:13:07Claudeなら教えるのは早いでしょうが、実際にはコードを代わりに書いてしまうので、結局何も学べません。難しい状況です。みんなどうするんでしょうね。
00:13:16それに、AIはハルシネーション(嘘)もつきますからね。それも問題です。
00:13:19ええ、私もそう言おうと思っていました。AIに新しいことを教わるのは信頼できないんです。自分がよく知っていることについてAIに尋ねても、時々間違いを犯すことがありますよね。もし知らないことを教えてもらっている最中に間違いが含まれていたら、それを真実だと思い込んで学んでしまう。これは非常に危険です。
00:13:36それで、今のRustの学習はどう進めているんですか?オートコンプリートもエージェントもすべてオフにして、ターミナルで昔ながらの方法で書いているんでしょうか?
00:13:49今は両方を組み合わせています。何年も前にRustを使っていましたが、やめてGoに移行しました。どの言語を使うか迷う「決定疲れ」を避けるために、一つの言語に集中したかったからです。
00:14:02Rustは大好きですが、見た目が美しい言語とは言い難い面もあります。見栄えの良いコードを書くのが難しく、YouTubeでコンセプトなどを説明する際、視聴者にとって読みやすく理解しやすいコードを表示したいとなると、なおさらです。
00:14:18そこでGoに移行したところ、それが非常にやりやすくなりました。Rustのコードを書くと、いつも「理解しにくい」というコメントをもらっていたので、より多くの人が見て理解できるGoの方が適していたんです。
00:14:31ですから、完全にゼロからというわけではなく、Rustを再学習している感覚です。昔理解していたスキルを拾い上げながら、それを応用しているという感じです。
00:14:47とはいえ、初心者の心構えに戻ろうとは努めています。夜になるとRustの本を読んでいます。すでに知っている章は飛ばしていますが、それでも読み進めています。
00:14:56Rustの本、正式名称は何ですか?
00:15:01ええと、たしか…
00:15:04ああ。
00:15:05ウェブサイトで見られますが、誰もが知っているメインのものです。No Starch Pressが出版しています。
00:15:13『プログラミング言語Rust』というのが正式タイトルです。でもみんな単に「Rust本」と呼んでいます。それを読み返していますが、やはり基礎知識ですし、文法を学ぶには良いです。「Rustonomicon」もあって、いつか読みたいのですが、あれはかなり難解なことで有名ですね。
00:15:25非常に難しいことでも知られています。プロジェクトについては、今Rustで動画編集アプリを作っています。クロスプラットフォームのネイティブアプリで、Rustのフレームワークをいくつか使っていて、とても面白いですよ。
00:15:40AIにはかなり頼っていますが、「ここのドキュメントがひどい。どうすれば実装できる?」といった使い方がメインです。AIはコードを読み込んで情報を引き出すのが非常に得意ですから。
00:15:51Rustの新しいフレームワークの多くは、クロスプラットフォーム対応でもドキュメントがひどいものです。AIから例を出してもらい、自分で実装するのは簡単です。
00:16:02最初はAIに頼りすぎていました。メディアレンダリングや動画編集のような、タイムライン合成やレンダリングなどが絡む部分では、
00:16:14AIを使うのは完全にダメでしたね。ジェームズが以前言っていた通り、AIは単純な作業には強いのですが、少しでも複雑になると……むしろ最適化されてしまう感じでしょうか。
00:16:26いつも思うのですが、AIは原因ではなく症状を解決しようとするんです。動くようにはしてくれますが、後から拡張できるほど堅牢なコードにはしてくれない。
00:16:38このプロジェクトでもそれを痛感しました。動作はするけれど、メディアパイプラインが存在しないような状態でした。単に基本的なAPIで動画ファイルを再生するだけといった感じでしたね。
00:16:49編集機能を追加しようとして、スキップや複数ファイルの読み込みを試すと、すぐに破綻してしまいました。
00:16:55だから今はAIの実装を「正しく」修正するのが学習になっています。
00:17:01動画編集なんて、AIがあっても極めて困難なタスクですね。
00:17:08ええ、まさに旅ですよ。
00:17:10コーデックの扱いはどうしているの?
00:17:15プラットフォームに依存させています。
00:17:20AppleはAVFoundationという素晴らしいメディアツールキットがある。
00:17:27AVFoundationは本当に最高です。多くのコーデックに対応している。
00:17:31メディアエンジンのデコーダーモジュールを差し替え可能にしている。
00:17:37RustならFFI(外部関数インターフェース)でhookできるからね。
00:17:42Objective-Cのコードを叩く。unsafeなRustだけど、安全ではある。
00:17:48WindowsやLinuxはMedia Foundationが必要だが、コーデック対応がイマイチだ。
00:18:03なるほど。
00:18:04ここもAIがひどい実装をしてくれた箇所ですね。
00:18:09デコーダーやエンコーダーを容易に交換できない設計にされた。
00:18:14とにかく動けばいいと。
00:18:15結局Media Foundationでは対応しきれないケースが多くて。
00:18:19LinuxならGStreamerが事実上の標準で、FFmpegを叩ける。
00:18:29Linuxではパッケージ管理でFFmpegを配布できるから簡単だ。
00:18:36バイナリ配布時に同梱できるし。
00:18:44技術的な話に逸れすぎたら止めてくれ。
00:18:47いや、最高ですよ。
00:18:48WindowsはGPLライセンスのFFmpegを同梱できないのが悩みだ。
00:18:53LGPL版をリンクする形にするしかない。
00:18:56Media FoundationとFFmpegを併用してコーデック対応をする必要がある。
00:19:03特にH.264やH.265のエンコーディング問題。技術的な深い話に入っちゃったな。
00:19:12いや、素晴らしいよ。
00:19:13ありがとう。
00:19:15この知識はKiruを作り始める前からあったの?
00:19:18ええ。
00:19:19Kiruですね。
00:19:20YouTubeで動画を扱っていると、嫌でもコーデックに詳しくなるんですよ。
00:19:25それに昔はC++をかなりやっていたので。
00:19:27レンダリングやGPUの仕組みはある程度分かっていた。
00:19:30レンダリングやGPUの仕組みはある程度分かっていた。
00:19:32メディアパイプライン周りは作りながら学びましたね。
00:19:39全部FFmpegに任せればいいと思ってたけど、そうじゃないんだね。
00:19:42OSごとに違うから厄介なんです。
00:19:45技術的にはFFmpegで全部いける。
00:19:48でも本当に難しい。
00:19:50そしてライセンス問題がね。
00:19:53なるほど。
00:19:54趣味のプロジェクトならいいけど、商用アプリだとそうもいかない。
00:19:58その通り。
00:19:59GPLライセンスを受け入れるなら別ですが、私はそうしたくありませんでした。
00:20:02オフラインでも少し触れましたが、動画の中でRustにフルタイムで注力すると言っていましたよね。一方で、これまでの動画のほとんどはGoに関するものでした。
00:20:13なぜRustに移行するのか、その理由を教えていただけますか。
00:20:16ええ、素晴らしい質問ですね。
00:20:18私は2026年のRustに対して、かなり強気な見方をしています。
00:20:23今後、より多くの企業がRustへ移行していくと考えています。
00:20:27これまでの普及ペースは実際、少し遅かったと言えます。
00:20:29よく言われる「ミーム」がありますよね?
00:20:31「Rustで仕事を見つけるのは、言語自体を習得するより難しい」というあれです。
00:20:35これまで暗号資産関連企業以外では採用がほとんどありませんでしたし、多くの開発者は暗号資産分野で働きたいとは思っていないでしょうから。
00:20:41業界における他の用途としては、たいてい社内のベテラン開発者が、Rustエンジニアを新たに雇うのではなく、自らRust採用を提案するというケースが多いですね。
00:20:54そのため、YouTuberとして教育的な観点からRustについて語るのは非常に困難でした。仕事が見つかりにくい言語でしたから。
00:21:02しかし、状況は変わるはずです。AIやLLM、エージェントエンジニアリングを取り入れる企業が増えるにつれ、不安定さという欠点が顕在化しているからです。
00:21:12古典的なプロジェクト管理の三角形、つまり「安さ、速さ、安定性や品質」といった要素の話です。
00:21:22現在は「安さと速さ」を優先するあまり、安定性を犠牲にしています。
00:21:26多くの開発者が、そこから立ち返ろうとしているのです。
00:21:30そのための手段、あるいはRustを使うという選択が注目されています。
00:21:34正しくRustを書けば、バグの大部分を排除できるからです。
00:21:38だからこそ、移行する企業が増えているのだと思います。
00:21:40Bunが100万行の書き換えを行いましたが、結果がどうなるか楽しみです。
00:21:46その件については賛否両論あるようですね。
00:21:48ええ、興味深い試みですが、どう転ぶか見ていきましょう。
00:21:52PMPMもRustへ移行していますね。
00:21:54ちょうどメインブランチに統合されたばかりです。
00:21:56確か2つのバージョンを並行してメンテナンスする予定のようです。
00:21:58ブラウザのLadybirdも、最近C++コードの一部をRustに移植しました。
00:22:04こうした動きは今後ますます加速するトレンドになるでしょう。だからこそ、私はRustに強気なのです。
00:22:10純粋にRustが好きだという理由もあります。
00:22:123つか4つある言語のうちのひとつだと思っています。
00:22:14Rustは上限がない、つまり、どんなものでも構築できる数少ない4つの言語のひとつです。
00:22:18私にとって、常に非常にワクワクさせられる存在です。
00:22:20将来的にRustで構築されるプロジェクトはもっと増えるでしょうから、今学んでおく価値はさらに高まるはずです。
00:22:27ええ、同感です。
00:22:28コンパイラが遅いとか、いちいち厳格すぎるといった議論も耳にします。
00:22:36しかしAIがコードを書く時代であれば、その厳格なチェックはAIモデル側で行えばいいわけで、人間が過度に気にする必要はなくなるかもしれません。
00:22:44でも、上限のない「トップ4言語」と言うなら、残りの3つについても触れないといけませんね。
00:22:50ああ、そうですね。
00:22:51わかりました、あとの3つについてですね。
00:22:52当然ですが、まずC言語。Cなら何でもできます。
00:22:56まさに上限のない言語の筆頭でしょう。
00:23:00Zigも入ります。ただ、Zigに関する私の悩みは、言語としてまだ歴史が浅いという点です。
00:23:07言語仕様が頻繁に変わりますから。
00:23:08以前のバージョンのドキュメントを見ても、最新の0.16では動かない、なんてことはよくあります。学習にはかなりの根気が必要です。
00:23:19それを乗り越えれば、非常にやりがいのある言語だと言えます。
00:23:22Zigの利点は多く、特にC言語との相互運用性は信じられないほど優れています。
00:23:27FFI(外部関数インターフェイス)を活用するなら最高ですよ。
00:23:313つ目はもちろんRust。
00:23:34そして4つ目はC++です。
00:23:35C++にも同様に上限はありません。
00:23:37あの言語でできないことはありませんから。
00:23:39キャリアの大半をC++に費やしてきたので、どうしても贔屓目に見る部分はありますね。
00:23:44とにかく大好きな言語です。
00:23:46好きになれないという人も多いですが。
00:23:48扱いにくい部分はありますが、何でもこなせるパワーがあります。
00:23:52CとC++を同じ括りで考える人もいるでしょうね。
00:23:56まあ、Cの延長線上にある言語という認識でしょうし。
00:24:01Zigの点について付け加えると、比較的新しい言語であるという理由もBunの移行に関係していると思います。
00:24:07彼らはZigプロジェクト自体に多くのPR(プルリクエスト)を送り、問題を修正しようとしていました。
00:24:11ユーザーからBunのクラッシュ報告を受けて調査すると、実はZigのバグだった、というケースが多々あったからです。
00:24:16それがRustへ移行した理由であり、クラッシュの根本的な解決を期待しているわけですね。
00:24:22OpenCodeもBunをベースにしていたため、Zig由来のクラッシュを経験していたようです。
00:24:28ですので、今回の書き換えがどうなるのか非常に興味深いです。
00:24:31私もです。
00:24:32非常に興味深い出来事ですね。
00:24:34私ならそうしない書き換え方かもしれませんが、科学的な探究として、それが可能かどうかを検証するのは素晴らしいことです。
00:24:42観測者として見守るのがとても楽しいですよ。
00:24:45Bunを基盤にしている下流プロジェクトも多いですから、多くの議論が交わされています。
00:24:49多くの企業がBunの上に構築していますしね。
00:24:51少し無謀にも見えますが、もし成功すれば大きな転換点になるかもしれません。
00:24:58まあ、様子見ですね。
00:25:00確か7日前に、彼は実験としてやっているとツイートしていました。
00:25:04そしてわずか7日後に100万行のPRをメインにマージしたというのは、狂気じみた実験ですよ。
00:25:11もし成功すれば、Claudeにとっても強力なマーケティング素材になりますね。
00:25:14ええ。
00:25:15最高のストーリーができましたね。
00:25:16まさに。
00:25:17小さくPRを分けることを常に推奨してきた人間としては、少し胸が痛みます。
00:25:20少しだけですが。
00:25:22まあ、結果がどうなるか楽しみにしておきましょう。
00:25:25観測者としては最高にエキサイティングな状況ですから。
00:25:29Bunに依存していて、自分たちのコードベースへの影響を心配している人たちの気持ちもわかりますけどね。
00:25:38今日、Daxがツイートしていましたが、OpenCodeは当分、新しいバージョンにアップグレードするつもりはないそうです。現状では信用しきれないためです。
00:25:46でしょうね。
00:25:47言語選択についていくつか質問させてください。
00:25:50あなたのAI活用法にも興味があります。最初はAIに構築させておいて、後から難しい部分を修正したと仰っていましたね。
00:26:00修正において、AIにプロンプトを投げて解決させるのと、手動でコードを書くのはどちらが多いですか?あるいは両方ですか?
00:26:09両方ですね。
00:26:10修正する内容に完全に依存します。
00:26:13特にアーキテクチャに関わる部分だと話は別です。
00:26:15AIとRustの組み合わせで変なのは、プロンプトを任せっぱなしにすると、何でもかんでもmain.rsファイルに詰め込んでしまうことですね。
00:26:21気づいたら2万行のmain.rsになっていて、「これは酷い。最初からやり直そう」となりました。
00:26:28AIはアーキテクチャの意思決定に関しては非常に苦手なんです。
00:26:32効率やトークンコストの最適化を優先するあまり、長期的視点が欠けているんですよ。
00:26:40意思決定を丸投げするのは本当にダメですね。
00:26:46意思決定は非常に苦手ですから。
00:26:50だから、アーキテクチャの判断は自分で行い、その後の実装をAIと一緒に行うというスタイルに変えました。
00:26:56私が書き直すこともあれば、最小限のスタブを書いてから「これにならって埋めてくれ」と指示したり、各ファイルへの割り当てを定義したりします。
00:27:08そうするとAIがその設計に合わせてリファクタリングしてくれます。
00:27:10コーディングに伴う退屈なタイピング作業の自動化にこそ、AIを活用すべきですね。
00:27:14そうやって、タイピングを自動化するのが今のお気に入りです。
00:27:18設計の判断は、依然として自分で行うようにしています。
00:27:20コードのレビューも自分で行います。
00:27:22もし何か完全に的外れな内容であれば、AIに書き直させるか、時には自分で修正することもあります。
00:27:30新しい概念を学習する際は、手作業で行うようにしています。
00:27:34自分で実際に書かなければ、深く理解することはできないと思うからです。
00:27:39Rustのフロントエンドフレームワークをいくつか試しました。
00:27:44ZチームのGPUIを使っていますが、GPUIコンポーネントは素晴らしいフレームワークですね。
00:27:50AIに触らせる前に、まず自分で習得して小さなアプリを実装しました。AI任せにするよりも、そうやって仕組みを理解するのが一番の近道だと思ったからです。
00:28:03AIだけでは、ウィンドウ全体がいつ再描画されるのか、コンポーネントがいつ更新されるのか、あるいはアプリケーション全体の再読み込みが必要なタイミングなど、GPUIコンポーネントが提供する3つのコンテキストを真に理解することはできません。
00:28:20IcedやEGUIといった他のデスクトップフレームワークも触りましたが、同じプロセスを踏みました。手作業でコードを書いてみて、仕組みを理解し、自分のニーズに合うかどうかを確認しました。
00:28:32確かに、それは非常に理にかなっていますね。私も同じ経験があります。自分で製品を作るなら、独自のコーディング規約や好みの書き方をあらかじめ定めておくべきです。
00:28:43そうすればAIが機能を追加する際も、勝手なことをさせず、自分のスタイルに合わせることができます。
00:28:50ですから、最初にいろいろと試行錯誤して、自分がどうコードを構築したいかを把握しておくことは、長期的に見てAIに正しく作業させる助けになると思います。
00:28:58そうですね。スタブを使うという考え方も良いですね。そんな発想はありませんでした。空の関数を用意しておいて、そこに実装を埋めさせるわけですね。
00:29:05そうです、空の関数を作っておけばいいんです。いいですね。
00:29:07そうなんです。私は昔からそうしているのですが、これはC++の経験から来ています。C++ではヘッダーファイルを書く必要がありますよね?
00:29:14まず最初にそれを作ります。私はヘッダーファイルが大嫌いですが、特定の点においては非常に優秀です。パブリックインターフェースを定義できるという点です。
00:29:21クラスファイルを作り、構造を定義し、どの関数を公開するかを決めていきます。
00:29:28それが契約(コントラクト)になります。この方法は抽象化に役立つので、非常に理にかなった働き方だと感じます。
00:29:36LLMには、残念ながらそうしたプロセスが備わっていません。そこで、私はRustでも同じことを再現しています。
00:29:45欲しい構造体とパブリックインターフェースを先に定義しておくんです。AIが好んで行う「何でも公開してしまう」といった動作を防ぎ、設計に従わせるためです。
00:29:55何でも公開してしまうのは愚かなことです。ですから、まずスタブやパブリックインターフェースを定義し、残りの実装をAIに任せるという手法を好んで使っています。
00:30:09クールですね。気に入りました。今度のプロジェクトで試してみます。
00:30:12実際にうまく機能しますか?推論フェーズにおいて、AIが近道をしたがり、ヘッダーファイルまで戻って勝手に変更してしまうようなことはありませんか?
00:30:25ええ。
00:30:26そんな経験はありますか?
00:30:27数え切れないほどありますよ。
00:30:29自動化が完全に実現するとは思えません。人間が介在せず、プロンプトを投げて放置するだけで完璧な結果が出る時代は来ないでしょう。
00:30:45AIが望まない方向に進もうとしたときに止める作業があまりに多いため、人間の監視なしで任せるなど不可能です。
00:30:57もちろん、CLIツールを一つ作るような単純な作業ならAIに任せてもいいでしょう。ですが、本番環境で使うものや、後でメンテナンスしたいものに関しては、AIを誘導するために深く関与する必要があります。
00:31:10そうですね。ですから、AIが何をしているのかを常にチェックし、正しい方向に導く必要があります。
00:31:20AIは平気で制約を破ろうとします。私たちが与える指示なんて、あくまで「ガイドライン」に過ぎないからです。だからこそ、私は常にAIの出力を監視し、余計な動きをさせないようにしています。
00:31:35Gitのステージングも頻繁に活用しています。進捗に満足したら変更をステージングし、何かおかしな動きをされたら、ステージングした状態まですぐに戻せるようにしています。
00:31:47それは良いテクニックですね。やり忘れると面倒です。今のAIツールには、もっと手軽に特定のチェックポイントへロールバックする機能が欲しいですね。現状ではすべてが手動ですから。
00:32:05VS Codeにはそういった機能があった気がしますが、IDEだからこそできることですね。チェックポイントに戻れば、それまでの作業は破棄されます。他のIDEがどうなのかは分かりませんが。
00:32:22Claude Codeにそうした機能があったはずです。私はよくGitのワークツリーでステージングしていますが。確かエスケープキーを2回押すと履歴が表示され、チェックポイントへ戻れるはずですが、コードの状態も一緒に戻るのかは疑問ですね。
00:32:42それは試したことがありません。私は「さっきの操作を元に戻して」と言うことが多いですが、10メッセージも前となると、元に戻すのも一苦労です。
00:32:54そうなんですよね。最近はCodex CLIをメインに使っていますが、メッセージごとにコードのチェックポイントを作成して、AIによるパッチ適用を簡単に取り消せるようになれば最高だと思います。
00:33:06ところで、なぜClaude CodeではなくCodexを使うことにしたのですか?
00:33:10偏見が入るかもしれませんが、CLIツールにTypeScriptが使われているのが嫌いなんです。CodexはRust製だと知って、すぐに乗り換えました。以前のツールはRust Analyzerを動かす際にメモリを大量消費していましたが、Codexではその問題が起きなかったからです。
00:33:38パフォーマンスもわずかに優れています。バージョン5.2以降、Codexを愛用しています。Claude Codeも速いですが、望む結果を得るためには、より細かく指示を出さなければならず手間がかかりました。
00:33:59最近はちょっと色々問題も起きていますが、基本的にはClaud Codeより優れています。だから、今はほぼCodexを使っていますね。
00:34:12今のお話は、私が聞こうとしていた質問に触れていますね。以前、TypeScriptで書くのが好きだとおっしゃっていましたが、CLIツールをTypeScriptで書くのは好まないとのこと。私も同感です。ランタイム全体を持ち込む必要があり、動作が重く、メモリも食いますからね。
00:34:39ElectronやVercelのZeroNativeなど、Webviewでネイティブアプリを作る手法も増えています。「なぜネイティブ環境でWebコードを書くのか?」という疑問もありますが。
00:34:57例えば「xtimejs」というツールは、ウェブ上でターミナルを再現しています。それを使ってウェブターミナルを作り、Tauriでネイティブアプリ化する…ターミナルを作るには回りくどい方法ですが、動くことは動く。そうした開発の方向性についてどう思われますか?
00:35:23興味深いですね。色々と考えるところはあります。私はC++をやってきた人間なので、仮想マシンやブラウザベースのツールを使うよりも、常にネイティブなツールの方が好みなんです。
00:35:35ElectronやElectric Bun、ZeroNativeなどは、ユーザーではなく開発者にとっては良いツールです。クロスプラットフォームの体験を簡単に作れますし、開発者が素早くリリースするのを助けてくれる。製品を市場に早く出せるという意味で、結果的にユーザーにとっても良いことだという議論は成り立つでしょう。
00:36:03開発者としてネイティブで構築するのは大変ですが、やはり私はそちらの方が好きなんです。
00:36:15コンピューターが強力になるにつれ、ソフトウェアはむしろ無駄が多くなっています。リソース制限を気にせずコードを書けるようになったせいです。
00:36:43iOS開発の初期を思い出すと、RAMが非常に限られていました。そのため、モバイルアプリ開発では非常に慎重な設計が求められました。
00:36:53現代においても、そうした「 scarcity mindset(不足の意識)」を持つべきです。理由もなくメモリを大量に割り当てるのはやめるべきです。
00:37:05ユーザーのリソースを尊重し、マシンのスペックを意識する。私の考えが少々堅苦しいだけかもしれませんが、そう思わずにはいられません。
00:37:17実際、Electronやハイブリッドアプリの方が圧倒的に作りやすいのは事実ですし、それが業界の現状ですね。
00:37:27それに、この業界では市場投入までの時間が重要な判断基準になりますから。残念ながら、それが現状です。
00:37:33何かの記事で読んだのですが、ビデオゲームの話で、PS1やPS2の頃の開発者が限られたメモリを活かすために駆使していた工夫は本当に凄まじいものでした。
00:37:48今は「200GBのゲームをそのまま出せばPS5で動くからいいや」という時代です。
00:37:55公平に言えば、問題を解決するために、こうした裏技やあらゆる手段に頼らなくて済むようになったのは良いことですよね。
00:38:01開発者視点から見ると、物事がより身近になったと思います。優れた製品やゲームをリリースしたいとき、限られたシステムの中で動作させるために必要なことのすべてを考える必要はないのですから。
00:38:15パフォーマンスと開発の容易さの間に、もっと良い妥協点があるはずです。GPUを無駄に焼き尽くすことなく、かといって変なトリックに頼りすぎない方法が。
00:38:30私も最近、コードを動かすとMacが熱くなり、バッテリーがすぐに切れるので悩んでいます。
00:38:38クラウド上でClaude Codeを動かすリモートワークフローを検討していますが、まだ結論が出ていません。
00:38:47同感です。これからのコンピューティング資源がどうなるかも考慮すべき点ですね。
00:38:55最近はMacBook Neoのように、あえて性能を落とした安価なノートPCも出ていますし。
00:39:02実は一台、近々届く予定なんです。動画編集ソフトの動作テストをするのが楽しみですね。
00:39:07ええ、興味深いですよね。供給不足が続いた場合、将来の計算リソースがどうなるのか分かりません。NvidiaがAIの将来のために必要だとして発表した消費電力の規模は、とんでもないものでしたし。
00:39:24様子見ですね。予測は外れることが多いので控えたいのですが、もし計算リソースの制約が強まれば、開発者は『どうすれば低スペックなハードウェアで動かせるか』をもっと真剣に考える必要があるでしょう。
00:39:41AIの世界でもモデルの量子化(Quantization)という流れがあります。350億パラメータもの巨大モデルを圧縮して、個人のMacBookで動かそうという動きです。
00:39:57そうやって限界までパフォーマンスを引き出そうとする試みは、非常に興味深いですね。
00:40:10セルフホストLLMコミュニティは本当に活発ですね。Alex SiskindなどはMac Studioをいくつも繋いで面白いことをしています。
00:40:26あなたは普段、Mac派ですか?それともLinux派ですか?
00:40:30両方使っています。メインはMacBook Proですが、NixOSのファンなのでLinuxも使います。最高のディストリビューションだと思います。設定が難しいですが、AIの助けがあれば簡単ですしね。
00:40:52とにかく宣言的設定が好きなんです。インフラにはKubernetes、コンピューターにはNixOSを愛用しています。macOSのNixも悪くありませんが、NixOSほどではありません。だから何とか許容できています。ただ動画編集などに関しては、MacBookに勝るものは本当にないですね。macOSは動画制作に最適なプラットフォームなので、最近はほとんどそれを使っています。
00:41:14最近の新しいAIツールはどれもMacばかり重視しているようです。Windowsは多くのスタートアップから忘れ去られていますよね。「Mac用アプリしかありません、悪しからず」という製品ばかりです。
00:41:23その通りですね。動画の話ですが、あなたの撮影環境は本当に素晴らしいと思います。照明もカメラもいい。どうやっているのか分かりませんが、画面収録をしているところをほとんど見かけませんよね。実際にカメラで画面を直接撮影されている。私も試しましたが、光の反射がひどくて。秘訣は何ですか?
00:41:42ああ、それですね。そうですね、照明はカメラと同じ角度に置く必要があります。正面からでない限りは。横から当てるなら、ライトをカメラの後ろに配置すれば、反射を防げますよ。
00:41:54MacBookのナノテクスチャディスプレイモデルを選んだのも反射対策の一環です。
00:42:03正面から撮るならライトを上から当てるか、後ろから当てるのがベストです。
00:42:11画面収録動画も作りたいのですが、コードを映すと視聴者の離脱率が高まるというジレンマがあって。
00:42:20皮肉なことに、プログラミングチャンネルでコードを見せ始めると視聴者数が落ちてしまうんです。画面を見せられるだけでは、あまり面白くないからでしょう。
00:42:29映画や動画の素晴らしい点は、被写界深度があることです。それによって、視聴者の視線を自然と誘導できます。
00:42:38一方、画面収録ではすべてにピントが合っているため、それができません。それが画面収録を扱う際の大きな課題の一つだと思います。
00:42:45だからこそ、カメラで画面を撮ることで被写界深度を利用し、見せたい箇所を強調しているんです。
00:42:52被写界深度の話ですが、今のセットアップ、すごく綺麗な被写界深度ですね。ちなみに、使っているカメラのモデルとレンズは何ですか?
00:43:03そうですね。Aロールは常設のセットアップで、FX30を使っています。Aロール用としては十分ですね。レンズはシグマの23mmを使っています。フルサイズ換算で35mm相当ですね。
00:43:22F値はいくつですか?
00:43:23F1.4だったと思います。
00:43:25なるほど、だからピントの合う範囲が紙一枚分のように薄いんですね。
00:43:32でもSonyのオートフォーカスは優秀ですよ。
00:43:36Bロールには別のカメラを使っていますか?
00:43:38BロールにはFX3を使っています。暗所性能が非常に高いので。
00:43:44マクロレンズを使うこともありますが、低ISO感度で絞りを開放気味にすると、ピントを合わせるのがほぼ不可能な状態になります。
00:43:55本当に紙のような薄い被写界深度になりますからね。
00:43:58FX3ならISO12800まで上げても耐えられるので、絞り込んでも十分に綺麗な画が撮れます。
00:44:06画面上のコードをマクロで寄って撮る際に非常に重宝しています。
00:44:14これらすべてYouTubeのために学んだのですか?それとも元々カメラや撮影に情熱があったのですか?
00:44:20ハマるととことん突き詰める性格なんです。
00:44:24イギリスの大学で写真を専攻していました。
00:44:27A-Levelという課程で写真を学んだんです。
00:44:29その時は一生懸命学びましたが、当時はその後使う機会がありませんでした。
00:44:32大学時代はナイトクラブで撮影したりしていましたが、その後は疎遠になっていましたね。
00:44:37そして動画制作に戻りました。
00:44:39また、その昔の知識が役に立ったんです。
00:44:42スティーブ・ジョブズの有名な言葉にあるように、人生で起きる些細な出来事は
00:44:50その時はどう繋がるかなんて分からないものです。
00:44:53後になって振り返ると「ああ、今に繋がっていたんだ」と分かります。
00:44:56すみません。
00:44:57機材についてもう一つ質問です。
00:44:58オートフォーカス機能を使っていますか?それとも固定ですか?
00:45:03Aロールはオートフォーカスを使っています。
00:45:05なるほど。
00:45:06はい。
00:45:07Bロールにはマニュアルフォーカスを使います。
00:45:09ええ。
00:45:10本当に素晴らしいですよ。
00:45:11ピントが外れることが絶対にないですから。
00:45:12ソニーのオートフォーカス性能は優秀ですよね。
00:45:16いいですよね。
00:45:17はい。
00:45:18かなり優れています。
00:45:19ヘアライトも使っているようですが、フレームの外ですね。
00:45:21複数のライトを使っているんですか?
00:45:23はい。
00:45:24ここには「太陽」と呼んでいるものがあって、
00:45:26巨大なソフトボックスですね。
00:45:29ヘアライトもあります。
00:45:30アプチャーのAmaranライトもいくつか使っています。
00:45:35それから背景にはアクセントライトもいくつかあります。
00:45:39いいですね。
00:45:40はい。
00:45:41すごくいい感じです。
00:45:42機材セットアップが時間の経過とともに発展していくのは面白いですね。
00:45:43ライトや三脚など、買い揃えるものがたくさんあって。
00:45:46とても重要ですよね。
00:45:47最近気づいたのですが、ライトの角度も非常に重要です。
00:45:51真上から照らすと、少し疲れて見えるんですよ。
00:45:54目の下に大きな影ができてしまうので。
00:45:56今はほぼ正面から当てています。
00:45:58では、普段はどんな一日を過ごしているのですか?
00:46:01企業で働いているのか、フルタイムでYouTubeをやっているのか、
00:46:05あるいは個人でやっているのか気になります。
00:46:06典型的な一日とはどんな感じですか?
00:46:08そうですね。
00:46:09『一日に密着』系の動画を撮るべきですよね。
00:46:10そう思いませんか?
00:46:11ぜひ一本欲しいですね。
00:46:13ええと、何をしているかというと。
00:46:15フルタイムの開発者としてはもう働いていないんです。
00:46:18誰にも言っていなかったんですが、AIが登場した時に早々に辞めました。
00:46:23業界の先行きが不安でしたし、ずっと業界に対して葛藤があったので。
00:46:29素晴らしい職場もいくつか経験しましたが、この5年間で業界がより官僚的になっていくのを目の当たりにしました。
00:46:40スクラムリーダーなどが介入して、実際の開発というより計画そのものが重視されるようになってしまったんです。
00:46:48計画はもちろん大事ですが、以前のように「素早く実行する」姿勢から遠ざかっているように感じました。
00:46:54素早く進めるためという名目で、会議ばかりが増えてしまいましたね。
00:46:57実際のソフトウェア開発の側面が損なわれていくようで。
00:47:02AIによって、それがさらに悪化していると思います。
00:47:04今の開発現場の状況や雇用市場に満足している人は少ないでしょう。
00:47:11よく分かります。
00:47:12私なら今、あの環境で働くのは楽しくないと思います。
00:47:15それで2014年にYouTubeをフルタイムでやることにしたんです。クリエイティブであり続け、同時に自分のやりたいコードを書きながら、あわよくばそれで収入も得られる方法としてね。
00:47:25フルタイムのYouTuberではありますが、動画投稿ペースを考えると、実際はパートタイムのようなものですね。
00:47:33代わりに、プロダクトを開発しています。
00:47:35自分のペースでコーディングするのが好きなので。
00:47:37学び続けることも大事にしています。
00:47:38ですから、日常はネットで情報をチェックしてトレンドを理解し、そのトレンドについての動画を企画しながら、自分自身もコーディングやソフトウェア開発の学習を続けています。
00:47:55すみません。
00:47:56今、聞き間違えたでしょうか?
00:47:572014年?
00:47:58フルタイムでYouTubeを始めたのが?
00:48:002024年ですよ。
00:48:01ごめんなさい。
00:48:02ああ、なるほど。
00:48:03すみません。
00:48:04私の間違いでした。
00:48:05彼は大ベテランというわけですね。
00:48:06今の活動内容についてですが、
00:48:11YouTubeのスポンサー収入とプロダクト販売だけで生計は立てられているのですか?
00:48:16それとも、サイドで少し受託開発などもやっているのでしょうか?
00:48:20収益の構成はどうなっているのか気になります。
00:48:23はい。
00:48:24全てYouTube、スポンサーシップ、そして製品の売り上げからです。
00:48:29それで十分賄えています。
00:48:30Anthropicのような会社に行けば、もっと稼げるかもしれませんが。
00:48:34確かに。
00:48:35とてつもない大金でしょうね。
00:48:36ですが、生活するには十分ですし、十分に快適な暮らしができています。
00:48:43もっとフォーカスすればさらに稼げる可能性はありますが。
00:48:46それは私の集中力不足の問題ですね。
00:48:49でも、うまくいっていますよ。
00:48:51生活には困りませんから。
00:48:52外から見ると、あなたは非常にフォーカスしているように見えますよ。プロダクトもありますし、日々学習も続けている。
00:48:58動画もこれだけ多角的に撮影して、編集にも時間がかかっているはずですし。
00:49:07外から見れば非常に生産的です。
00:49:09ありがとうございます。
00:49:10中から見ると、そうは感じないんですが。
00:49:12では、業界についての「辛口な意見」はありますか?
00:49:16たくさんありますが、頻繁に発信していますね。
00:49:20もういくつかお聞きしましたね。
00:49:22はい。
00:49:23はい。
00:49:24Rustが今年は非常に重要になるというのも辛口な意見でしたよね。
00:49:27でも、今ではそこまで話題にはなっていません。
00:49:29私の去年の意見は、もっと多くの人がAIエージェントを使ってコードを書くようになるということでしたが。
00:49:34それは実現しつつありますね。
00:49:36今の辛口な予測は何でしょうか?
00:49:38そうですね。
00:49:39辛口な予測を一つ。
00:49:40はい。
00:49:41LLMは収穫逓減のポイントに達しているというのが私の考えです。
00:49:45これ以上の大きな飛躍は見られないでしょう。
00:49:48この予測は外れるかもしれませんが。
00:49:49少なくともモデルに関しては、現在の性能から劇的な改善は期待できないと思います。
00:49:55ツール側での進化はあるかもしれませんが、モデル自体はそうでもないかと。
00:49:58では『Claude 3.5 Sonnet』が完璧なモデルだと信じているわけではないと?
00:50:03素晴らしいとは思います。
00:50:04ただ、非常に高コストでしょう。
00:50:05繰り返しになりますが、収穫逓減の領域に入っています。
00:50:09消費者向けに提供するにはコスト効率が悪すぎるのです。
00:50:13今後は企業向けの非常に高価なモデルとして生き残る道を選ぶ企業が増えるかもしれません。
00:50:21しかし、消費者がそれを見ることはないでしょう。運用コストに対して見合うだけの出力を得られないからです。
00:50:30それが私の辛口な意見です。
00:50:31また、2027年にはAIマーケティングも下火になると見ています。
00:50:36AIを使ってマーケティングをするということか、それとも「AIを搭載しました!」と強調するような宣伝のことでしょうか?
00:50:43後者ですね。「AI搭載が革命的だ」と製品にAIを詰め込むような動きです。
00:50:53消費者がそれを望んでいないからです。
00:50:55何でもかんでもAIを組み込むことに対して、消費者は好意的ではないことを何度も示してきました。
00:51:02いつか、これは単なるバブルだったと気づくはずです。
00:51:05もちろん外れる可能性もありますが。
00:51:07あくまで予測ですね。
00:51:09それでも、AIブームは徐々に冷めていくと思っています。
00:51:132027年には熱狂が終わっているでしょう。
00:51:16チャットインターフェースに関しては同意できます。
00:51:20全てをチャットにする必要なんてありませんから。
00:51:23旅行の予約をChatGPTやチャットで行うというデモをよく目にしますが、
00:51:29私は自分で選びたい派です。
00:51:31「ChatGPT、よろしく!」と言って旅行を完結させたくはありません。
00:51:34ですので、その点には同意します。
00:51:35Windowsのあらゆる機能にCopilotボタンをつける必要だってないですよね。
00:51:39先日リストを見ましたが、Copilotと名のつく製品が70以上もありました。
00:51:43狂気じみています。
00:51:46すごいですね。
00:51:47頭がおかしい。
00:51:48皆さんの辛口な意見も聞かせてください。
00:51:50その質問を振られたのは初めてです。
00:51:52準備していませんでした。
00:51:54やはり、AIの話になるでしょうね。
00:51:57あなたがAIの話をしてくれてよかったです。私もそのつもりでしたから。
00:52:02まあ、辛口な意見というほどではないかもしれませんが。
00:52:05TUI(ターミナルUI)は好きですが、自分には合わないということです。
00:52:10Codexアプリをよく使っています。
00:52:13TheoのT3コードも素晴らしいのですが、Claudeがサブスクモデルを廃止してしまったのが少し残念です。
00:52:18とにかく面倒です。
00:52:19チャットインターフェースは多くの用途で不要になりつつあると思っています。
00:52:26もっと良いインターフェースが必要です。
00:52:28それがどんな形かは分かりませんが。
00:52:29ターミナルUIは素晴らしいですが、マルチエージェントワークフローでは限界がある気がします。
00:52:34私の辛口な意見は、Claudeなどの予測不可能な価格設定により、今後はローカル環境やローカルモデルへの移行が進むというものです。
00:52:48GPU価格が高騰する中で、価格がさらに上がる前に今こそ良いグラフィックボードを買っておくべきだと思います。
00:53:03将来的にクラウドが支払えなくなった時のために、ローカル環境を構築しておくべきだと。
00:53:09私としては逆の意見なのですが、多くのユーザーはあまり気にせず、値上がりし続けるサブスクリプション料金を払い続けるのではないでしょうか。
00:53:17もちろん限界はあるでしょうが、先ほど話したように企業が負担してくれるなら、そのまま払い続けるはずです。
00:53:24その通りですね。
00:53:25はい。
00:53:26個人ユーザーには当てはまるかもしれません。
00:53:29ただ、学生には現在のGPU価格は手が出ないでしょう。
00:53:33確かに。
00:53:34ええ。
00:53:35はい。
00:53:36何人かの「普通の人々」と話しましたが、開発者を雇うより200ドルのClaudeプランを払う方が安くて早いと言っていました。
00:53:46Claudeにやらせる方がいいと。
00:53:49開発者の仕事と完全に同等ではないということを啓蒙していく必要があるのかもしれません。
00:53:57リチャードの意見も聞かないと。
00:53:59まだ聞いていませんから。
00:54:00いや、まだ考えています。
00:54:02正直、全く思いつきません。
00:54:03AIに関連するものじゃないと。
00:54:05そうですね。
00:54:06最近面白いと思ったのは、『Claude Code』を使っている時に「何か作りたいんだけど、おすすめはある?」と聞くと、
00:54:15興味深い答えが返ってくることです。
00:54:16例えばWebサイトをホスティングしたい時、
00:54:21どこがいいか聞くと、
00:54:22予想もしない製品名を挙げてくるんですよ。
00:54:25AWSやDigitalOceanではなく、Fly.ioやRailway、時にはVercelを勧めたりします。
00:54:32そう選ばれるために、企業側で何か裏工作をしているはずです。
00:54:35「エージェント体験(Asian Experience)」なんて呼ぶ人もいますが。
00:54:37これこそが「次世代のSEO」になると思います。
00:54:40もはやH1タグなんかを気にしている場合ではありません。
00:54:43モデルに特定の製品を勧めさせるための「魔法の言葉」があるのです。
00:54:46人々はいずれそれに気づき、ハックしようとするでしょう。
00:54:50将来、重要な要素になるはずです。
00:54:52それを悪用されたら、AIのユーザーエクスペリエンスが崩壊するのでは?
00:54:56 ट्रिक (仕掛け) を見破られたらどうなるでしょう。
00:54:58イエスでもありノーでもあります。
00:55:00トリッキーですよね(ダジャレです)。
00:55:02はい。
00:55:03冗談はさておき。
00:55:04robots.txtやLLM向けのMDファイルを使って最適化するのは、かなり時間がかかるものです。
00:55:09簡単ではないですよ。
00:55:11ただUXの観点から言えば、『Claude、Google Cloudのアカウント設定とAPIキー設定をやって』と頼んで、
00:55:20巨大なクラウドツールのダッシュボードを彷徨わずに、安全に済ませられるなら便利なのは確かです。
00:55:28まあ、見ていきましょう。
00:55:30これが私の「そこまで熱くない」辛口意見でした。
00:55:33面白い観点ですね。
00:55:34トレッドミルで走っている時にふと思ったのですが、みんながAIに製品判断やインフラの指示を仰ぐようになったら、
00:55:44アイデアが収束(コンバージェンス)してしまい、直感に頼るような独創性が消えてしまうのではないかと。
00:55:52そこが他者と差をつける鍵になると思います。
00:55:56今、プログラミングを学ぶのが大事な理由はそこですね。
00:56:02AIに頼りきらず、自分で判断できる能力があれば、プロンプト通りのありきたりな提案しかできない人々に対して圧倒的な競争力を持てる。
00:56:11そう思います。
00:56:14ええ。
00:56:15製品の収束現象はすでに起きています。
00:56:17AIがVercel、Supabase、Resendなどを推奨するため、多くの人がそれらを使っています。
00:56:22ゆっくりですが、確実に進んでいます。
00:56:25仕組みを理解していれば、より適切なツールを選べるはずです。
00:56:29どうなるか楽しみですね。
00:56:30「トレッドミル思考」という言葉は初めて聞きましたが、意味はよく分かります。
00:56:33なるほど、シャワー中の思いつきのようなものですね。
00:56:37ええ、今度から使わせてもらいます。
00:56:42私の考えのほとんどは、トレッドミル中に浮かびますから。ポッドキャスト『Better Stuff』を聴いてくれてありがとう。
00:56:46各配信プラットフォームでフォローしてください。それでは、これにて。
00:56:52さようなら! さようなら! さようなら! さようなら!

Key Takeaway

AIによる自動生成に依存せず、システム言語の基礎やアーキテクチャの意思決定を自ら主導できるスキルを持つことが、技術者にとっての圧倒的な競争優位性となる。

Highlights

  • AIエージェントの台頭により、大規模なコードベースにおいて長期的な堅牢性を考慮しない「症状解決型」のコーディングが蔓延している。

  • Rustは、バグの大部分をコンパイル時に排除できるため、安定性と品質を重視する企業での採用が今後加速する。

  • 動画編集などの複雑なパイプライン開発において、AIはコード生成はできるが、拡張性やメディアフレームワークの深い設計には依然として不向きである。

  • AIが推奨する技術スタック(Vercel, Supabase等)への依存が進むことで、製品の独創性が失われ、アイデアの収束現象が起きている。

  • LLMの性能向上は収穫逓減のフェーズに入っており、消費者向けサービスに組み込むにはコスト効率が悪化している。

Timeline

開発環境とツール選定の変遷

  • Vim/NeoVimは、Unix環境での作業効率化に不可欠なツールとして長年支持されている。
  • ZeoxideなどのCLIツールは、ターミナルでのディレクトリ移動やファイル操作の時間を劇的に削減する。
  • AIツールが統合されたIDEは、過度なオートコンプリートが開発者の思考を妨げる場合がある。

大学でのコンパイラ授業がきっかけでVimを習得し、それ以来一貫してターミナル環境での作業を維持している。最近はCursorのようなAI統合型IDEよりも、純粋にナビゲーションと編集に集中できるNeoVimを好む傾向がある。ツール探しの際は、GitHubのスター数やフォーラムの活用を通じて、自身の問題を解決するニッチなCLIツールを徹底的に調査している。

GoからRustへの移行戦略

  • Goによるコースプラットフォーム構築は経験としては良好だったが、複雑なクライアントサイドの対話には不向きだった。
  • Rustはバグを排除し堅牢なシステムを構築できるため、2026年以降の重要な言語として評価している。
  • RustはFFIを活用してネイティブOSのメディアツールキット(AVFoundation等)を安全に呼び出せる利点がある。

当初はGoでWebプロジェクトを構築したが、複雑なフロントエンド操作の維持に限界を感じ、Next.jsへ移行した。現在は動画編集アプリの開発を通じてRustを再学習している。Rustはコンパイラによる厳格なチェックがAIのハルシネーション対策にもなり、かつOS深層部への制御も可能なため、将来的に多くの企業が移行すると予想している。

AIとの共存と設計プロセス

  • アーキテクチャの決定はAIではなく人間が行い、AIはタイピング作業の自動化に活用するのが最適である。
  • AIに実装を任せる前にパブリックインターフェースやスタブを定義しておくことで、設計の逸脱を防げる。
  • AIの出力を監視し、Gitのステージング機能を活用してチェックポイントをこまめに作成することが不可欠である。

AIは「動くコード」を作ることは得意だが、長期的な保守性や堅牢性は担保できない。そのため、最初にC++のヘッダーファイルのようなパブリックインターフェースや構造体を定義し、その契約に従ってAIに詳細を実装させる手法を推奨している。AIを完全に自動化ツールとみなさず、あくまで開発のガイドラインを守らせるための監視と手動介入が重要である。

ソフトウェア業界の現状と辛口な未来予測

  • LLMのモデル性能向上は収穫逓減に達しており、過度なAI搭載マーケティングは2027年までに下火になる。
  • AIが推奨するツール(Vercel, Supabase等)の画一化により、製品の独創性が失われるリスクがある。
  • 市場投入速度を優先しすぎる現在の開発現場は、リソース制限を意識する「不足の意識」を欠いている。

現状のAI開発は効率化の名の下に、クラウドコストの増大やコードの品質低下を招いている。特にチャットインターフェースで何でも解決しようとする手法は持続不可能であり、今後はローカルモデルや計算リソースを意識した設計が重要になると指摘。AIエージェントによるツール推奨が新しいSEOとして機能し始めており、システムの本質を理解しているエンジニアだけがそのハックを回避できる。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video