AIを活用した最新の開発手法であるエージェントエンジニアリングについて、シニアデベロッパーのミッキー氏が実践的なツールスタックやワークフローを解説する動画。従来の感覚的なプログラミングから脱却し、正確なコンテキスト管理や自動レビューを組み合わせることで、圧倒的な速度と品質で開発を進める具体的なアプローチを紹介している。
エージェントエンジニアリングの到来
エージェントエンジニアリングこそが未来です。2026年現在、100倍速くプロダクトを出荷している人たちは、チャットボットにプロンプトを打ち込んでいるわけではありません。彼らは複数のエージェントハーネスを並列で走らせています。そこで今回は、AIにコードの95%を書かせているシニアデベロッパーのミッキーをポッドキャストに迎え、彼が実際に使っているAIスタック、ツール、モデル、そしてループについて詳しく聞いていきます。デビッド・アンドレのポッドキャストをどうぞお楽しみください。
それじゃあミッキー、2026年におけるAIを使った開発について、君はどう考えているかな。
ええ、最後に話したときからかなり変わりましたね。もうバイブスで開発する時代ではありません。私たちはこのテクノロジーに対して真剣に向き合う必要があります。ただ同時に、正直に言うと、ここ3ヶ月の間に私が書いたすべてのコードのうち、およそ95%はAIによって生成されたものだと言えます。
君は本物のデベロッパーなんだよね。
はい、本物のエンジニアでありデベロッパーです。趣味でコードを書く楽しさが恋しくなることもあって、週末にたまに書くこともありますが、私たちがどこに向かっているのかを見ようとしないのは愚かなことだと思います。モデルは完璧ではありません。それでも、特に自分が担当している垂直領域を理解していれば、生産性の向上が得られる段階に達しています。人々が構築しているアプリケーションの90%は、少しの頭脳とAIがあれば、非常に遠くまで行くことができます。ですから、私が使用しているツールやワークフローを共有しようと思います。誰でも真似ができる、非常に再現性の高い方法です。具体的なツールをそのまま紹介しますし、アンドレイ・カルパシーの自動研究ループのような感覚も味わえると思うので、きっと楽しめるはずです。
素晴らしいね。さっそく本題に入ろう。
ハーネスと最適なAIモデルの選択
まずはハーネスについてです。私はモデルを追いかけるタイプで、モデルそのものがより重要だと考えていますが、エディタはCursorを使用しており、現在はGPT-5.5を使っています。
面白いね。それは興味深いな。私はCursorの中で、Opus 4.7 Max fastを使っているんだ。ただ、多くの人が知らない大きな違いがCursorにはあります。実際のデベロッパーによって行われたベンチマークテストのデータがあるのですが、Cursorは彼らのモデルにおいて、Cloud CodeやCodexの双方を上回るパフォーマンスを発揮しているんですよね。ですから、多くの人がOpus 4.5を叩いて、あれはひどいモデルだと言ったり、Twitterの一部ではスローパスと呼んだりしていましたが、特にUIの変更に関しては依然として優れたモデルです。そこは前置きしておきます。UIやフロントエンドに関する作業を行うときはいつでもOpus 4.7を使いますが、必ず最高スペックのMaxモードで動かしています。他のバリアントを使っている時間はありません。
しかし、それ以上にハーネスが重要なのです。現在、多くの人がCursorの価格設定に躊躇していますが、それはCursorがCodexやClaudeのように補助金を出して安く提供していないからです。それでも、私の意見ではCursorが最高のハーネスです。モデルを簡単に切り替えることができますし、彼らの新しいエージェントビューはかなり素晴らしい出来栄えです。
ハーネスという言葉について少し触れておこうか。ここ2、3ヶ月でこの言葉の人気が急速に高まっているよね。もちろん以前から存在していた言葉だけど、多くの人にとっては本当に初めて聞く言葉で、まだ完全に理解されていないと思うんだ。モデルがあるとして、ではハーネスとは一体何なのかな。
モデルの周囲にあるすべて、と言えます。信じられないかもしれませんが、モデル単体では何もできません。モデルは次に続くテキストを予測するだけの存在です。技術的には、モデルは思考すらしていません。あなたが与えた英語が何であれ、それはトークンに変換されます。それらのトークンはグラフ上にマッピングされ、モデルはそのグラフを見て次のトークンを予測するのです。そこでいくつかの高度な数学的処理が行われ、トークンがあなたに返され、それが英語に再変換されます。つまり、モデルは考えているわけでも、何かを実行しているわけでもなく、ただ次のテキストを予測しているだけなのです。
ハーネスが何をするかというと、モデルを包むラッパーのようなものだと考えてください。そしてこのラッパーには、API、ツール、特定のシステムプロンプト、agent.mdファイルのようなマークダウンファイルが含まれます。これらはすべてモデルを包み込み、特定の行動を実行したり、専門化したりするようにガイドするためのものです。
少しお知らせですが、この動画で紹介されているすべてのものを完全に無料で手に入れたい方は、動画の下にある最初のリンクをクリックしてください。このポッドキャストで言及されたすべてのスキル、リポジトリ、ツールをメールでお送りします。繰り返しになりますが、完全に無料ですので、動画の下から今すぐ手に入れてください。
さて、CursorやCloud Code、Codexにおいて最も重要なのは、モデルに与えられるツールの存在です。Cursorや何らかのエージェントを使用するとき、その実行トレースや返答の中で、このファイルを読み込んだ、これを検索した、といった表示を目にするはずです。それらはエージェントが自ら行っているツールコールです。繰り返しますが、エージェント自体にその能力はありません。しかし、ハーネスがツールを提供することで、エージェントはこれを実行できるようになります。モデルがこれほどのレベルに達した今、優れたハーネスに投資することは、モデルからの出力を最大化することに繋がります。私たちはこれを知っています。なぜなら、Cloud CodeとCursorでの人々の体験は同じではないからです。
そうですね、利用可能な最高のモデルを使っている限りは。そして、まさにモデルが重要であるという点において、私はGPT-5.5 extra highを使っています。私は主に大規模なコードベースを扱っているので、多少の偏見はあるかもしれませんが、大規模で複雑なコードベースを理解することに非常に長けています。ここ2週間、UIの変更を除けば、私が使っているモデルはこれだけです。
ソースコードを真の事実のソースにする
ここで私が強くお勧めしたいツールがいくつかあります。1つ目はオープンソースのツールです。オープンソースという一般的な言葉のように聞こえますが、実際にはリポジトリの名前です。Googleで検索すると出てきますが、実際にはVercelが開発したものです。これをオープンソース化してくれたVercelに感謝します。
基本的にこのopen-sourceというツールが何をするかというと、あなたが扱っているパッケージのソースコードをフェッチして、それをそのままコードベースに投入してくれます。具体的な例を挙げましょう。これは私が開発しているアプリのかなり大規模なコードベースです。構造自体はそれほど重要ではありませんが、重要なのは、ここにopen-sourceと書かれたグレーアウトしたフォルダがあり、その中にreposというフォルダがあることです。それをクリックすると、github.comというフォルダがあります。その中には、browser-use、composio、Daytona、open-clawなど、皆さんが聞いたことがあるかもしれない多くの人気プロジェクトや企業のフォルダが見えます。
これらのテクノロジーの多くは実際にソースコードが公開されており、これはエージェントにとって素晴らしいことです。人間が作成したドキュメントなどをエージェントに与える代わりに、最高の事実のソースであるコードそのものを与えることができます。コードこそが単一の最高の事実のソースだからです。
私が何をしたかというと、agent.mdファイルを用意しました。私はエージェントが手動では知り得ないような情報が含まれていない限り、agent.mdファイルの大ファンというわけではありません。例えば、これはReactのコードベースです、といった情報をagent.mdファイルに書き込む人がいますが、Sonnet 4.5やOpus 4.0を使っていた頃であれば、それは良いアイデアだったと思います。しかし、モデルは非常に賢くなったため、コードベースを読み込むだけで技術スタックなどを正確に把握してしまいます。ですから、ハーネスはどんどん軽量に、薄くなってきていることに気づくはずです。これがPIがこれほど勝っている理由でもあります。実際には多くのものを必要としません。モデルが本当に優秀だからです。そのため、このプロジェクトがどのように使われるか、その背景にあるビジョンは何か、といった明白ではないことだけを伝える必要があります。
その通りだね。私独自の特定の構造がある場合などにね。
今回のケースでは、追加のソースコードをフェッチできることをエージェントに伝えています。ちなみに、これはすべてAIが生成した記述です。私が手書きしたわけではありません。誰かがこれを読んだら、なんてスマートなんだと思うでしょうが、AIが生成したのです。私は考え、AIに何をすべきかを伝えているだけで、そこにはパッケージやリポジトリのソースコードをフェッチして理解し実行するために必要な手順が小さなブロックとして書かれています。
基本的にはパッケージの追加方法をエージェントに教えているのですが、その最適な方法の例として、open-source自体を実行してみましょう。例えば、このパッケージやオープンソースのリポジトリを使用する製品を構築しているとします。あるいはbrowser-useのようなものを使っているとしましょう。リポジトリを見つけたら、文字通りターミナルに行って、npx open-sourceと入力し、リポジトリのURLを貼り付けるだけです。見ていてください。
おっと、これは失敗しましたね。なぜ失敗したのかな。使い方の問題か、あるいは私がLinuxマシンを使っているからですね。まあ、それは気にしないでください。しかし、文字通りこのコマンドを実行するだけで、ここにフォルダが表示されるようになります。
ここからがクールなところです、デビッド。そのテクノロジーを使用した機能を構築したいときはいつでも、プロンプトでコードベースを参照するように指示します。設計の段階に戻るたびに、毎回プロンプトを出します。例えばこのプロジェクトでは、非常に強力なサンドボックスプラットフォームであるDaytonaを多用しています。非常にテクニカルで深い部分まで多くのクールなことができます。時間を費やして深く潜ることもできますが、私は速く構築し、速く出荷したいのです。競合は光の速さで出荷していますからね。そこで、プロンプトの中でそのフォルダをタグ付けし、このコードベースを参照してください、と言います。
これは、基本的にはドキュメントの終焉のようなものだね。コードこそが最高の事実のソースだからだ。ただ、これによってコンテキストウィンドウが膨れ上がってしまうのではないかと心配する人もいるかもしれないけれど。
昔のハーネスはコードベース全体をインデックス化し、ベクトル検索やRAGなどあらゆる手法を使っていました。しかし現在のモデルは検索能力が非常に高いため、必要なのは検索ツールだけです。そのため、どこを検索すべきかをガイドしてあげるだけで、モデルはコードベースを参照し、正確な関数を見つけ出します。推測に頼る必要はありません。正確な関数を見つけてくれるので、10回のうち8回は完璧に正確な結果を得られています。
そうだね。コンテキストエンジニアリングを適切に行えば、テストやデバッグの時間を大幅に削減できるため、結果的に多くの時間を節約できる。エラーが発生しなくなるからね。
コンテキストエンジニアリングの原則
ええ、コンテキストエンジニアリングは非常に重要です。これがあなたの227Kのコンテキストウィンドウだとして、エージェントがスマートに機能するのはおそらくこのレベルまでです。少し厳しめの見方かもしれませんが、もう少し先まで行けるとしても、情報を詰め込めば詰め込むほど、エージェントは愚かになります。ですから、このようなスイートスポットに留まりたいわけです。
そのため、必要な正確なスニペットを提供したり、必要なことを正確に説明したりすることが求められます。これこそが、エージェントティックエンジニアリングがバイブコーディングよりも優れた結果をもたらす理由です。なぜなら、バイブコーディングでは思考をエージェントに丸投げしてしまっているからです。
そうだね。
エージェントティックエンジニアリングでは、人間が思考を行い、その後に手下たちに作業をさせます。非常に優秀ですが多くの指導を必要とする新卒のジュニアエンジニアの集まりに作業を任せるようなものです。もし272Kのコンテキストモデルを持っているなら、私はCodexが好きなのですが、画面上に現在77%消費していると表示されたら、そこでそのスレッドは終了にして、新しいスレッドを開始する必要があります。エージェントにとって情報が多すぎるからです。
多くのハーネスには、スラッシュコンパクトのような機能があることは知っています。面白いことに、Claude Codeの開発において、リードデベロッパーの一人がチュートリアル動画の中で、彼自身すらそのコンパクトエンジンを使わず、新しいセッションを開始していました。それほど動作が重くなるということです。
なるほどね。
ですから、単に新しいセッションを始めればいいのです。何が言いたいかというと、このツールを使うことで、非常に正確なプロンプトを維持できるということです。エージェントはウェブ検索をする必要がなく、文字通り最高のドキュメントであるコードそのものを与えられているからです。
ここまでのスタックを整理すると、ハーネスはCursorで、モデルはGPT-5.5 extra high fast、あるいはOpus 4.7 maxを使用。そしてツールとして、プロンプトのコンテキストエンジニアリングに最適なopen-sourceを活用し、正確な参照先を与えているわけだね。
コンテキストエンジニアリングのコツとしては、コンテキストを低く保つこと、つまり機能を最小限に抑えることです。これを短く保つための方法は、機能の計画を非常に計画的に進めることです。例えば、Twitterで多くの人が、計画はAIに立てさせるべきか、人間が立てるべきか、それともすぐに機能の実装に飛び込むべきか、という議論をしていました。私は計画を立てますが、それはエージェントのためというよりも、自分自身のためです。時々複数のスレッドを走らせることがあるので、計画はエージェントに責任を持たせるための素晴らしい方法になります。
驚くかもしれませんが、計画を作成した時点では良い計画に思えても、実際に生成を開始させると、どこかでつまずき始めることがよくあります。その理由は、モデルが計画を生成するときに、自身のコンテキストウィンドウのことを考慮していないからです。タスクを与えられると、そのタスクを完了するために必要なすべてを計画に詰め込んでしまいます。そのため、これほどのコンテキストを必要とする大きなタスクがある場合、決して正しく実行されることはありません。
ですから、まずは計画を生成させ、それができたら、これは少し大きすぎるから、レビューしやすいように非常に小さなプルリクエストや小さなチャンクに分割できないか、と問いかけます。そうして複数のアクションステップを作成していくのです。つまり、コンテキストエンジニアリングはそれ自体がエンジニアリングにおける一つの原則と言っても過言ではありません。出力の質を左右する決定的な要素だからです。
そしてその原則とは、人間が主導権を握り続けるということだね。AIが基本的にすべてのコードを書いているとしても、ある程度は人間がコントロールし続けなければならない。なぜなら、どの時点であっても、このコードベースの問題点は何か、と問いかければ、たとえ問題が何もなくても、AIは喜んで10個の問題を提案してくるからだ。この分野に不慣れな人は、あまりにも簡単にコントロールを手放してしまい、信頼すべきでない領域までAIを信頼しすぎてしまう傾向がある。
ええ、モデルは人間と同じようには考えません。これを見ている方で気づいた人がいるか分かりませんが、OpenAIが4oを一時的にシャットダウンしたとき、大きな抗議の声が上がりました。ユーザーがモデルとの間に一種の関係性を築いていたからです。モデルがあまりにも同調的で聞き分けが良いため、人々はそれに恋をしてしまったのです。
クレイジーだね。
奇妙だと思うかもしれませんが、コードを使ってアプリケーションを構築しているとき、多くの人に実際に同じようなことが起こります。自分は本当にスマートで、モデルが正しい方向に導いてくれている、正しい決定を下したと思い込んでしまうのです。しかし、モデルには何のアイデアもなく、ただ次のテキストを予測しているだけで、その次のテキストが間違っていることもあります。
しかし、あなたが運転席に座って決定を下し、ガイドしているときは、これをカメラアイ（写真記憶）を持っていてすべてを知っているけれど、その使い方が分からない、非常に不器用な人物として扱う必要があります。そのような関係性を持つことで、ここ3ヶ月、4ヶ月の間、私の仕事におけるコードの90%から95%をAI生成に委ねることができています。もし悪いコードが出荷されれば、責任を問われるのは私ですからね。
コードのクリーンさと自動レビューの仕組み
2つ目のツールについて続けます。この2つ目のツールは、私のスキル、つまりプロンプトのプリセットのようなものです。開発のバックグラウンドがあれば誰でも作成できますし、AIとやり取りしながら作り上げることもできます。エージェントがよくやってしまう傾向の一つに、すでに存在するコードを再書き込みしてしまうという点があります。
例えば、エージェントからのレスポンスをストリーミングする関数があるとします。基本的にはチャット機能を構築していると想定してください。誰かがメッセージを送信した後にメッセージをストリーミングする応答関数があり、そこにTelegramを統合したいと考えたとします。エージェントにTelegramを統合してくれと頼むと、エージェントはそれを作成してくれますが、10回のうち9回は、すでに作成されている既存の関数を再利用しません。新しい関数を新しく書き直してしまうのです。
これがなぜ問題になるかというと、コードの不吉な匂い（コード臭）が発生し始めるからです。コードベースが巨大化し、動くパーツが多すぎると、多くのタッチポイントが存在するため、エージェントが何が間違っているのかをデバッグするのが非常に困難になります。このスキルが何をするかというと、コードをサービスレイヤーと呼ばれる構造に整えます。サービスレイヤーが何をするかというと、何度も再利用できるこれらの関数を作成することです。
私はまず、機能を生成します。CursorとGPT-5.5 extra highを使って最初に機能を構築するのです。そしてもちろんローカルでテストを行い、納得のいく状態にします。後でこの機能に戻ってきたときには、おそらくその仕組みを忘れているでしょうし、コードがどこにあるかも忘れているでしょう。最初に書かれたコードは、おそらく最適な形状をしていません。モデルにはその能力がありますが、指示しない限り、最初から綺麗なコードを出してくれるわけではありません。
それは怠け者と同じです。デビッド、君が私にこのタスクをやってくれと頼んだとして、人間の本性として、私はおそらく最も抵抗の少ない、楽な道を選びますよね。モデルもおそらく同じことをします。ですから、このスキルを使うことで、誰でもまるでスタッフエンジニアであるかのようにモデルと会話をすることができるようになります。
ご覧のように、ここにはこれらすべての計画があります。ちなみに、このポッドキャストで話しているすべてのスキル、ツール、リポジトリは動画の下から無料で入手できます。最初のリンクをクリックして手に入れてください。
これはエージェントのためというよりも、私が記憶しておくためのものです。そして、ここにある目標を見てください。重複するランタイムメカニクスを、より深い構造化されたモジュールに移動させることで、デプロイ、プロビジョニング、修復をよりシンプルにすると書かれています。重複するランタイムメカニクスがある場合、必要なのは1つだけで、5つも6つも必要ありません。これが問題を引き起こすのです。
私はこのスキルを実行し、コードベースを見て、重複しているコードがどこにあるかを探すよう指示します。するとエージェントがそれを指摘し、このファイルとこのファイルを修正します、と提示してくれます。これらは重複すべきではないコードが含まれているファイルです。このようなスキルを使うことで、コードをよりクリーンに保つことができます。
そして私が気づいたのは、コードの構造がクリーンであればあるほど、エージェントが新しいセッションで作業を引き継ぐのが容易になるということです。もしコードが散らかっていて、あちこちに散乱していれば、人間が読むのが難しいのと同様に、エージェントにとっても難しくなります。クリーンな構造が重要なのです。ありがたいことに、その具体的な形を100%知っている必要はありません。このようなスキルを使用すればいいのです。
他にも、マット・ポコという名前だったと思いますが、彼も非常によく似たスキルを公開しています。彼のものは、あなたが少し技術的な知識を持っている場合により役立つと思います。知識がないと墓穴を掘るかもしれませんが、彼はこのコードベース構造の改善という優れたスキルを持っています。これも非常に役立つものの1つです。
何が言いたいかというと、機能を1つ構築するたびに、私はこれらのいずれかを実行しています。なぜなら、エージェントが再びそのコードを扱う必要が生じたとき、高確率で自分自身を混乱させるような書き方になっていることを知っているからです。
それは、古くからある優れたエンジニアリングの原則を、新しい方法で適用しているということだね。何かを構築した後に、他の人のためにドキュメントを残すようなものだけど、今やそれは人間のためではなく、エージェントのために行われている。
面白いことに、多くのエンジニアが面倒くさがったり、生活を地獄のように変えるとして敬遠してきた古いエンジニアリングの慣行の多くは、信じられないかもしれませんが、エージェントにとっては素晴らしい効果を発揮します。コードが適切に構造化されていることや、テストが明確に定義されていることは、エージェントにとって非常に有利に働きます。
自動研究ループの実践
私はopen-sourceを使い、コード構造の最適化を行っていますが、さらに具体的なツールを1つお勧めします。これはツールの宣伝ではなく、私が実際に使っていて、その証拠もあるから紹介するのですが、コードレビューにはGravtileを使用しています。
私がGravtileを気に入っている理由は、Grep loopという特定の機能があるからです。この機能を使うと、カルパシーの自動研究ループを使っているような感覚になります。例を挙げて説明しましょう。ここにPR 80というプルリクエストがあります。エージェントがスプレッドシートのすべての行を完全にインジェストできるようにいくつかの変更を加えました。
Gravtileは私に、5点満点中4点、3点、5点といった信頼度スコアを提示してくれます。例えば、3点というスコアが出たとしましょう。すると、ほぼ確実にその問題点と、なぜ3点なのかという理由を教えてくれます。これが完璧だとは言いませんが、私のテストの範囲では、かなり素晴らしい精度です。特に技術的なバックグラウンドがない人には、これが絶対に、どうしても必要になります。
3点のスコアが出たとします。私はそのスキルをインストールしているので、/grep loop と入力してエンターを押すだけです。するとエージェントがプルリクエストを読み、フィードバックを読み、そのフィードバックを修正して、新しいレビューが行われるのを待ちます。もし2点だったものが3点になったとしたら、デビッド、エージェントはどうすると思いますか。そのまま進め続けます。5点満点を得るまで止まりません。
これが、私が最初にコンテキストの重要性や、コードを構造化するツールの話をした理由です。ここに到達するまでに、シンプルな機能、最小限のプルリクエスト、そしてクリーンなコード構造が用意されています。そこでGravtileのレビューエージェントがレビューを行います。おそらく最初は3点や4点が得られるでしょう。そこで私は文字通り /g loop を実行し、自分は別の作業に移ります。そして作業が終わって戻ってくる頃には、10回のうち9回は5点満点を獲得しています。
5点満点が取れない唯一のケースは、9,000行、10,000行、12,000行といった巨大なプルリクエストを渡してしまったときだけです。彼らも私たちと同じエージェント、同じモデルを使っている可能性が高いことを理解する必要があります。つまり、コンテキストウィンドウは有限なのです。ですから、スマートにならなければなりません。
コンテキストを最小限に抑えるという最初のルールを守り、プルリクエストの50%から60%程度を出荷していれば、Gravtileがこれをレビューするときに提示されるエラーは、その機能の中に実際に存在する正確なエラーになります。そしてGreploopがそれらを捉えて修正します。
ここ3ヶ月間、私は間もなくリリースするかなり大規模なアプリを開発していますが、その全体をエージェントティックエンジニアリングで構築しました。それは私がすべてのコードを読み込んだという意味ではありません。私は構造を確認しました。もう一人のデベロッパーも参加していて、彼から質問を受けていますが、依然として知識は重要です。構文を理解していなくても、現代においては構文そのものはそれほど重要ではありませんが、優れたコードやアーキテクチャがどのように機能するのかを理解していることは大きな助けになります。
本当に、ものすごいスピードで遠くまで進んでいます。私が近々立ち上げるアプリを、2週間や3週間、あるいは1ヶ月で構築したと言ったら、誰も信じないでしょう。しかし、この正確な数式、つまりハーネスとしてのCursor、最高クラスのモデルの組み合わせがあれば可能です。もし誰かが、これをKimmyや他の無料ツールでできるかと聞いたら、答えはノーです。最高クラスのモデルを使わなければなりません。それらはOpenAIやAnthropicとは違いますからね。
そうだね、まったくの別物だ。ローカルモデルの大きなムーブメントがあるのは知っているし、それも素晴らしいと思う。私のマシンでもGemmaを走らせているけれど、これほどのコードを書くことはできないよ。
ええ。そしてopen-sourceを使って、使用しているパッケージやライブラリを何でもダウンロードし、機能を構築するたびに構造化してプルリクエストを作成し、Grep loopを実行します。画面にあるように、PR 80はマージして問題なし、Gravtileで5点満点、と表示されています。このようにエージェントは自ら進め続けます。
時には20分から30分ほどループが続くこともあり、Cursorが、間違いを犯してこれを見落としていました、Gravtileがこれを検知したので修正をデプロイしてGitHubにプッシュします、と報告してきます。そしてGravtileが再びレビューを送り、5点満点になった時点で自動的に停止します。
そして、これらの超優秀なモデル、特にOpus 4.7やGPT-5.5 extra highに共通する特徴として、彼らは大量のテストコードを書きます。デビッド、気づいているか分かりませんが、彼らは非常に多くのテストを書くのです。これは素晴らしいことです。なぜなら、モデルは何かが壊れているというフィードバックを受け取るたびに、その機能が動作し、そのバグが再現されるようなテストを書き、そのテストがパスするまで作業を止めないからです。
カルパシーが提唱した自動研究は非常に興味深くユニークなパラダイムでしたが、エージェントティックエンジニアリングの本質はまさにそれになっています。エージェントに十分なツールと十分なコンテキストを与えてループ内で動作させることで、作業が完了する頃には機能が完成しているのです。
これらのスキルを使い、適切なコンテキストを提供する理由は、最終的な成果を明確にするためだね。テストがパスすることであれ、アプリがデプロイされることであれ、何であれね。それこそが、Codexの内部にあるスラッシュゴール（/goal）機能の背景にある主要なアイデアでもあると思う。エージェントに最終状態を与えるんだ。使っていない人が誤解しているような、永遠に走り続ける愚かなループではない。望む結果をどれだけうまく説明できるかがすべてであり、そこをクリアできれば、エージェントは基本的にはそこに到達する方法を見つけ出してくれる。
私はこのように考えています。例えば、私とあなたがバスケットボールのコートにいて、あなたが私に、マイケル、シュートはこうやって打つんだ、と教えてくれているとします。あなたが一度、適切に説明してくれたとしても、私はおそらく1回目では正しく打てないでしょう。2回目も上手くいかないかもしれません。あなたは2回目に割って入って、さらにフィードバックをくれるでしょう。しかし、3回目、4回目、5回目となるうちに、私はコツを掴みます。
私たちがやっているのは、基本的にはそういうことです。これらはすべて、エージェントに対する巨大なマッサージマシンのようなもので、十分な情報を提供すれば、エージェントは正しいことを行います。これこそがエージェントティックエンジニアリングの全体像です。十分な情報、十分なガードレール、そして十分なフィードバックループを与えることです。
もし、open-sourceも使わず、コード構造も考慮せず、機能についての思考も放棄して、ただ、これを構築して /gloop を実行してくれ、とだけ頼んだとしたら、私たちはRalph Wickhamの二の舞を踏むことになります。それがどのような結果を招いたかは、誰もが目にしていますよね。最初はクールでしたし、私自身もRalphieというカスタム実装を持っていますが、それでは遠くへは行けません。
現在のエンジニアリングにおいて、人間の承認と思考は極めて重要です。多くの人がアプリを構築し立ち上げていますが、思考のプロセスまでエージェントに委ねてしまっています。だからこそ、今は際立つための絶好のチャンスなのです。ユニークで、実際にしっかりと動作するものを作り出す絶好の機会です。これが私のプロセスです。
技術選定とコンテキストとしてのコード
もう一つ言えるのは、人気のあるツールを使うだけでなく、非常にコード化（明確に体系化）されたツールを使うことです。例えば、私はReactよりもSvelteというライブラリを好んで使っています。なぜReactではなくSvelteを使うかというと、遥かに新しいフレームワークであり、モデルの学習が十分に蓄積されていないのではないかと議論する人も多いですが、その構文の大部分はHTMLとTypeScriptであり、これはエージェントが非常に得意とする領域だからです。
一方でReactは、特に新しいバージョンを使用している場合、あらゆるフックや、自爆しかねない罠（foot guns）が溢れています。しかしSvelteは、HTMLとTypeScriptの核心的な原則に非常に忠実です。
そして面白いことに、私は自分が説くことを自ら実践しています。このプロジェクトのreposフォルダに行けば、open-sourceの配下にsvelte.jsのコードベースがあるのを確認できるはずです。エージェントの挙動が正しくないと感じたときはいつでも、svelte.jsのコードベースを参照してください、と指示します。すると、エージェントは標準的なベストプラクティスに従って処理を行います。だから私はSvelteを使っています。
なるほど。ということは、この理由によって、今後は人々が基本的にオープンソースのプロジェクトやフレームワークの上だけで開発を行うようになっていく、ということなのかな。
ええ、それが最高のコンテキストだからです。考えてみてください。マークダウンファイルかHTMLファイルかという議論がありますが、それらはストレートな英語ではなく、ある種のコード化され構造化された言語ですよね。つまり、コードこそが最高のコンテキストなのです。
もし企業がデベロッパーツールを構築しているなら、これはビジネス上の決定として、オープンソース化しなければなりません。なぜなら、人間が書いたドキュメントというのは、エージェントにとって最悪の、これ以上ないほど最悪のコンテキストだからです。リポジトリを渡せばドキュメントを生成してくれるスタートアップがあるのは知っていますが、正確なコードをそのまま渡せるのに、なぜわざわざその余計なステップを踏む必要があるのでしょうか。
それは優れた洞察だね。
他にも、みんなが絶賛しているeffectというライブラリがあります。TypeScriptのライブラリで、非常に厳密に型定義されているようなものです。私はそんなことは気にしません。リポジトリを見つければ、ライブラリなのだからオープンソースであるはずです。それを持ってきて、open-sourceツールを使ってコードベースにダウンロードします。そうすれば、私とエージェントはそれを使ってセットアップのやり取りを行うことができます。使用しているフレームワーク、今回のケースではSvelteでも、open-sourceを活用しています。
バックエンドに関しては、Supabaseのファンが多いのは知っていますし、それが上手く機能しているならそれでも構いません。私はConvexで働いているので、ひいき目に見えるかもしれませんが、完全に正直なところ、私はConvexを使っています。理由は、Convexにあるものはすべてコードだからです。ダッシュボードに行く必要があるのは、本番インスタンスをセットアップするときか、アプリのトラフィックが爆発して支払いの段階になったときだけです。
スケジュール関数を設定したい、つまりアプリを閉じた状態でバックグラウンドで何かを走らせたいとします（アプリにはそういう機能が必要ですよね）。それもコードです。APIを書きたいときも、コードです。Convexのすべての機能はTypeScriptのコードで完結しています。
これがなぜ素晴らしいかというと、デビッド、エージェントが私のバックエンドで行われていることの完全なコンテキストを把握できるからです。スキーマについて推測する必要はありませんし、ダッシュボードのスクリーンショットを撮って、これが今起きていることで、どのタブをクリックすればいいか教えてくれ、なんてエージェントに頼む必要もありません。たまに少し怠けたくなることもありますが、Convexはすべてがコードなのです。
私が言っているすべてのことは、エージェントに完璧なコンテキストを提供するという点に帰結します。バックエンドはコードであり、フレームワークのコードベースへのアクセスも与えている。この2つをこの構造と組み合わせることで、私はほぼあらゆるものを出荷することができています。
もちろん、すべてが順風満帆というわけではありません。何かを構築するとき、これはあなたがよく発信していて、今の多くの人が忘れてしまっているマインドセットだと思いますが、人々はジムでも人生でも、一生懸命努力しなければならないことは理解しています。しかしなぜか、エージェントを使ったエージェントティックエンジニアリングになると、一発で上手くいかなければ、もう終わりだ、となってしまうのです。
そうだね。
ある種の図太さ、大胆さが必要です。社内ツールならまだしも、人々に使ってもらいたいソフトウェアを構築しているなら、こだわりを持つこと、思慮深くあること、時間をかけることが重要です。人々の資格情報や情報を扱うことになるわけですからね。
技術的なバックグラウンドを持たない人たちが、あらゆる技術的コンセプトに対して心を閉ざしてしまっているのを見かけるけれど、それは本当にクレイジーだと思うよ。
ええ、誰かが、これはCLIのターミナル作業だから、と言うのを聞きますが、実際には信じられないほどシンプルです。本当にとてもシンプルなのです。面白いことに、私はこれまで触ったこともないようなテクノロジーを使って開発を始めています。私はネットワークエンジニアではありませんが、エージェントを使って説明させ、デスクトップをクリーンアップし、これらの作業を行っています。
ちょうど昨日、Twitterで見たかもしれませんが、ウォレットのパスワードを紛失した男性がいました。
ああ、それ見たよ。知っている。
彼はCloud Codeを使ってそれを解決したのです。ですから、むしろこれらのツールはあなたの視野を広げるものであるべきです。ある種、妄想的でクレイジーになってもいい。自分は何でも構築できると信じるべきです。たとえ実際にはできなくても、やってみる価値はあります。正直な努力を注ぐのです。デビッド・ゴギンズのモチベーションを高める言葉のように、失敗に向かって進む、といったことがエンジニアリングにもそのまま当てはまります。私はこれらのツールとこの組み合わせによって、本当に強固な出力を得ることができています。
投資としてのAIツールとナレッジワークの未来
多くのバイブコーダーたちが、これらのツールを一切持っていないというのは驚くべきことだね。あるいはツールを1つだけ持っていたとしても、他の原則や既存の他のツールの存在に全く気づいていない。あるいは、安価なモデルや何らかのツールの無料版を使っている。AIの最先端にいると思い込んでいながら、無料のChatGPTや無料のClaudeを使っている人たちに、私は毎日会うよ。
ええ、残念ながら、これは資金力の勝負（money game）になっていくでしょう。現在は補助金が出ている状態ですが、どこかの時点でその補助金は終わります。そうなると、プレイするためのお金を持っている人たちが、より良い結果を得ることになります。
もちろん、月に200ドルというのは大金ですし、誰もが子供を持っていたり、責任や住宅ローンがあったりと、異なるライフステージにいることは理解しています。それは全く別の人生です。しかし、もしあなたが若くて仕事を持っていて、Codexの200ドルのサブスクリプションを支払っていない理由が、友達と飲みに行っているからだとしたら、それはクレイジーなことです。
大人の場合、100ドルのCodexサブスクリプションであっても、信じられないほどの恩恵を受けることができます。彼らは狂ったように補助金を出しています。もしその補助金を継続させたいなら、Twitterに行ってOpenAIを絶賛し続ければ、彼らはプッシュし続けるでしょう。ですから、Codexで100ドルのサブスクリプションを契約し、それを限界まで使い倒す価値は間違いなくあると思います。投資に見合う価値があります。今や彼らはそれを、ワークフローなどを実行できるスーパーアプリに変えようとしています。
そして、それらの多くはコーディングの領域すら超えています。それが何をもたらすか想像してみてください。プログラミングの側面しか見ていない人は、自分はデベロッパーではないし、それほど多くのツールを作らないから関係ないと思うかもしれません。しかし、ChatGPTの無料プランと、月額100ドルを支払うことの差は凄まじいものです。GPT-5.5 Pro Extendedが手に入り、文字通りプロの弁護士やプロの医師を指先一つで呼び出せるようなものです。
チームの誰かとのトラブルや、訴訟をちらつかされているような問題に直面したとき、ディープリサーチを走らせれば、15分以内に、人間の弁護士に支払えば数千ドルかかるような凄まじいクオリティの回答が返ってきます。
実際の生活の例を挙げましょう。私はある企業から、任せたい作業の契約書を送られました。その契約書は27ページにも及ぶものでした。長い間、私は古い人間（ブーマー）だったので、エージェントが見落としをするかもしれないと恐れて、契約書に関しては弁護士を雇っていました。しかし弁護士は高額です。特にカナダやアメリカでは非常に費用がかかります。
そこで、これをClaudeに、Claude Desktopに渡してみようと考えました。すると、すべてのページがハイライトされ、すべての項目に対して反論のポイントを提示してくれたのです。結果として、契約書の中に潜んでいた不条理な内容を指摘できたおかげで、彼らが私に支払う予定だった報酬を3倍にすることができました。
その後、私は自分がこれまで行ってきた成果や仕事の分析データをClaudeに与えました。するとエージェントは、あなたもっと請求すべきですよ、と言ってきたのです。私はエージェントに、でも怖いんだ、契約を失いたくないし、私はセールスパーソンではないから、と本音を漏らしていました。するとエージェントは、弱気になるな、とまるで同僚のように励ましてくれて、メッセージの文面まで書いてくれたのです。
もちろん、AIが書いたそのままのメッセージを送るわけにはいかないので、自分の言葉に書き直して送りました。
当然そうだね。
すると彼らから返答があり、条件を変更し、価格を3倍にすることに同意してくれました。月額200ドルの投資に対して、これは無限大とも言えるほどの計り知れない価値をもたらしてくれました。ですから、まずは試してみることが最善の方法です。
私も似たような経験があって、会計処理でクソみたいに大量のお金を節約できたんだ。ある会社で2024年から2025年の会計をやり直す必要があって、会計士に見積もりを依頼した。大手の高額なファームではなく一般的な会計士だったけれど、3,000件のトランザクションがあるから42,000ディルハム（UAEの通貨）、ドルに直すと5,000ドルか6,000ドルほどかかると言われた。
私は、ちょっと待て、トランザクションの量だけでそれだけの金額を請求するのか、と考えた。そして、その会計ソフトウェアにAPIがあるかどうかを確認したところ、APIが存在していた。だから、こんなものはCursorとCloud Codeで自分でやると決めたんだ。2時間ほど席に座って作業したら、すべて終わったよ。文字通り5,000ドルから6,000ドルを節約できた。そして正直なところ、そのファームの会計アソシエイトよりも、CursorとCloud Codeの方を信頼している。
ええ、まさにそういうことです。私たちは今エージェントティックエンジニアリングや開発の話をしていますが、私は実際、開発よりもナレッジワーク（知識労働）の領域に対して、より強気（ブル）の見方を持っています。なぜなら、ビジネスを運営していたり、起業家であったり、副業をしていたり、あるいはコーポレートの仕事をしていても、退屈で日常的な作業が膨大に存在するからです。
私の友人で、企業勤務で常に最新の情報にアップデートしている人たちがいますが、レポートやスプレッドシートの作成など、本来なら何時間もかかるような作業における生産性の向上は凄まじいものがあり、100ドルのサブスクリプションがそれをすべて解決してくれます。
もしあなたがまだ決断を下していないなら、言っておきますが、私はこれらの企業から1円もお金をもらっていません。株をもらえればいいなとは思いますけどね。しかし、個人的に伝えているのは、もし月額500ドルに値上げされたとしても、私はおそらく払い続けるだろうということです。私は支払いますし、買い続けます。
デビッドは考えるまでもなく支払うだろうね。
ツールに触れて、実際に使ってみることが最高の経験になります。テレビに出ている億万長者のような口振りに聞こえたくないですが、新しいツールを使うことで確実にアドバンテージを得られます。仮に来年もっと優れたツールが登場したとしても、今これらのツールに触れているという事実は、来年さらに優れたツールが出たときに、それをより上手く使いこなし、学び、初めて触る人よりも遥かに速く動けるということを意味します。
構築の沼から抜け出し、早期にローンチせよ
完全に同意するよ。ここで一つ触れておきたいんだけど、君は何かを3週間ほどで構築していると言ったよね。多くの人は構築のフェーズで永遠に立ち往生してしまう。私が「ローンチまであと2週間だよ」と言っていた人たちを6ヶ月追跡しても、彼らはまだ「あと2週間でローンチだ」と言い続けている。そういった人たちにどんなアドバイスを贈るかな。
ええ。私は最近サンフランシスコに行ってきたのですが、同じような経験をしている人たちに向けて話すと、私自身もサンフランシスコに行くまでは同じ沼にはまっていました。デビッド、君はそこに行ったことがあるかい？
あそこの「妄想（思い込み）のレベル」は凄まじいです。悪い意味で言っているのではなく、自分たちは絶対に成功するという盲信の度合いが極めて高いのです。自分を信じる必要があるとは誰もが言いますが、断言します。ほとんどの人は、サンフランシスコの人たちが自分を信じているほどのレベルでは、自分を信じられていません。
それが第一です。彼らは自分たちが構築しているものが世界を変えると本気で信じています。例えば、誰かが「AIを使ったUGC（ユーザー生成コンテンツ）アプリを作っているんだ」と言ったとします。すでに市場にはいくつか存在していますし、別の領域でより良くできる部分もあるでしょう。しかし、彼らがそれを説明するときの熱量があまりにも凄いため、世界最高のアプリであるかのように感じさせられます。
最初は、彼らは単なる詐欺師（グリフター）なのかと思っていましたが、そうではありません。彼らは心からそれを信じているのです。そしてそれを信じているからこそ、半ば機能する程度のMVP（最小限の実装）ができた瞬間に、たとえそれがまともに動かなくても、あるいはサイトに100人アクセスしただけでサーバーが落ちるような状態であっても、とにかくローンチしてしまうのです。彼らはローンチし、ハイプ（熱狂）を作り出します。そして何が起きるかというと、彼らは資金を調達し、人を雇い、チームを拡大していきます。
そうして、ある時点で彼らのプロダクトは本当に優れたものになっていくのです。その一方で、あなたや私はシンプルな機能について考えすぎてしまい、まだローンチすらしていません。彼らはすでに1000万ドルを調達しているというのに。
ですから、これがブートストラップ（自己資金）であれ資金調達であれ、とにかく早くローンチしなければなりません。自分が気づいているバグをユーザーに見つけられたくないという気持ちは分かりますし、それは辛いことです。しかし信じられないかもしれませんが、多くの人、特にコミュニティの人たちは、技術的な人たちに限らず、試してみたい新しいMacアプリを常に探しています。
つまり、多くの人は退屈していて、何か新しいものを試したいと思っており、あなたのプロダクトを試す意志を持っています。もしそれが最悪な出来栄えであれば、彼らはフィードバックをくれます。あなたはそれを修正して、また進めばいいのです。現実世界との接点を持たないまま、これは素晴らしいものだと自分を欺いて手元に抱え込んでいるよりも、プロダクトは遥かに良くなります。
Twitterに行って、それらのローンチ動画をすべて見てみてください。スタイリッシュなアニメーション動画がたくさんありますよね。なぜアニメーションなのか分かりますか？ プロダクトがまともに動いていないからです。それなのに彼らはローンチし、ユーザーを獲得し、私やあなたよりも多くのMRR（月間定期収益）を稼いでいます。私たちは何をしているでしょうか。あと1つだけ機能を修正しよう、と引きこもっている。これは最大の罠です。私自身もその罠と戦っていますが、文字通り最大の罠なのです。
何度も何度も、そういう光景を目にしてきました。妄想的（デリュージョナル）になる必要があります。もちろん、愚かな決定を下せという意味ではありません。例えば、自分たちは最高のSOC 2（セキュリティ基準）プラットフォームだと言い張りながら、実際には犯罪行為に手を染めている、といったような愚かなことはしてはいけません。しかし、自分が構築しているものを信じることです。自分が提示している能力を信じるのです。「今はこれだけれど、将来的にはこうなる」というビジョンを伝え、世界と共有するのです。
コミュニティという意味だけでなく、パブリックの場でオープンに構築（Build in Public）してください。影に隠れていてはいけません。多くの競合が存在するからです。あなたがアンドレイ・カルパシーのようで、何か全く新しいパラダイムを構築しているなら影に潜んでいても構いませんが、そうでないならあなたには競争相手がいます。彼らは素早く動き、あなたよりも多くのトークンを消費し、彼らのアプリはあなたのものほど優れていないかもしれませんが、最終的に勝つのは彼らです。それなら、私たちが勝者になるべきです。
実際、ここ数週間の間に、本当に素晴らしいアプリを持っていながら「あと1つだけ機能を追加してから」と言っていた数人の人たちに、文字通りそう伝えました。「そんな風に続けていたら、競合に一瞬で煙に巻かれるよ」と。
そうだね。その盲信と信念こそが成功の半分を占めている。それによって他の多くのパズルがカチッとはまる。そして、それを強く信じていれば、どんな障害があっても、単にそれを払いのけて進むことができる。しかし、確信を持てずに境界線の上にいると、諦めてしまうんだ。
ええ。個人的な例を共有すると、私はフルタイムの仕事を持っています。そしてフルタイムの仕事の後に、近々立ち上げる予定のこのアプリの開発に取り組んでいます。その代償となるのは睡眠です。あるいは、友人との集まりやソーシャルなイベント、娯楽の時間かもしれません。それが何であれ、もしあなたが本当に強気になれるプロダクトで、自分自身でも使いたいと思えるものなら、とにかくローンチしてフィードバックを得てください。
もし人々から酷評されたら、素晴らしいことです。それを踏まえてV2（バージョン2）をリリースすればいいのです。そしてマーケティングにおいて少しユーモアを持たせることです。私は最高のマーケターではありませんが、人々の目の前で、表に出て構築していく姿勢は、実際に人々に好まれます。人々はアンダードッグ（勝ち目の薄い挑戦者）が好きなのです。アンダードッグの段階で嫌悪を向けられることは通常ありません。嫌われるのは成功した後です。それなら、今はすべての愛を吸収して成功を収め、その後のことは後から考えればいいのです。ですから、どうか早くローンチしてください。
エージェント時代におけるサイバーセキュリティ
エージェント時代におけるセキュリティ、サイバーセキュリティについて君がどう考えているか話を聞きたいな。毎日新しいデータ漏洩、新しい脆弱性、ハッキング、攻撃のニュースを目にする。君ほど技術的に詳しくない人たちに向けて、これにどう向き合うべきか教えてくれるかい。
ええ、終わっています（cooked）。私たちは終わっています。率直に言いますが、本当に恐ろしい時代です。笑い事ではなく、モデルが非常に優秀になってきているため、機能を修正するためにループでエージェントを回せるということは、非常に悪質な行為を行うためにもエージェントをループで回せるということを意味します。
現在でもHugging Faceに行けば、ガードレールが取り外された多くの蒸留モデルが存在します。悪意のあるプロンプトを入力すれば、それをそのまま実行してくれます。
個人レベルでの対策として、これは少しクレイジーに聞こえるかもしれませんが、例えば私の家族の間では、秘密の合言葉（パスフレーズ）を決めています。音声クローニングの技術が非常に高くなっているため、もし私の声にそっくりな音声で「お金を貸してくれ」という連絡が来たら、家族はその合言葉が何かを尋ねることになっています。
2要素認証（2FA）は今や必須です。パスワードマネージャーすら使っていない人がどれほど多いか、驚くばかりです。1Passwordなどのツールを使って、非常に複雑なパスワードを設定する必要があります。そして1Passwordが提供するマスターキーの半分を、母親や父親、あるいは信頼できる誰かに預けておくのです。自分たちが持っているアカウントや情報に対して、非常に厳重なセキュリティ意識を持つ必要があります。
そして、2要素認証はテキストメッセージ（SMS）経由で行ってはいけません。私は少し前にSIMスワップの被害に遭いました。現実に起きていることです。誰かがSIMスワップを通じてあなたを狙おうと思えば、実際にできてしまいます。Google Authenticatorなどの認証アプリによる2要素認証を使用してください。
しかし最も重要なこととして、特にあなたがエージェントの領域にいて、ツールなどを構築している場合、ダウンロードするパッケージなどに対して非常に慎重になる必要があります。なぜなら、多くの人が使っている一般的なコンシューマー向けのアプリは非常に高い警戒態勢にあり、過去にハッキングされた経験から対策が進んでいますが、それでもまたハッキングされる可能性はあるからです。
危険な攻撃ベクトル（侵入経路）となるのは、パッケージやコードをダウンロードするときです。そこで、エージェントに対してプロンプトで明確に制限をかけることができます。エージェントに対し、「リリースから14日未満のパッケージは絶対にインストールするな」と指示するのです。なぜなら、攻撃ベクトルの多くは、文字通りここ数日、あるいはここ数時間の間にドロップされたパッケージだからです。これが第一の対策です。
第二に、一般的にTwitterでの議論に参加しておくことです。Twitterは素晴らしい場所です。デビッドがフォローしている人や私がフォローしている人をフォローしておけば、タイムラインが適切にチューニングされ、何かが起きたときに最初の段階で知ることができるようになります。
第三に、このセキュリティ領域は、今後も成長を続けるセクターになるでしょう。これを見ている若い方で、学校でセキュリティなどの勉強をしている人がいたら、そのまま進み続けてください。求人市場はあなた方にとって非常に明るいものになるはずです。
コンシューマーアプリにおいては、2要素認証は必須です。あと、余談ですが、家族に高齢の方がいる場合は、どうかこれらのリスクを説明してあげてください。おじいちゃんが、孫や昔生き別れた家族だと思い込んで、見知らぬ人にお金を送金してしまったという話をよく耳にします。私たちにとっては理にかなわないことでも、高齢の方にとっては、AIが生成した動画や画像、GPT Image 2などはほぼ完璧に見えるため、十分に説得力を持ってしまうのです。
そうだね。
ですから、高齢の家族には、何か行動を起こす前にまずあなたに相談するように伝えておくことをお勧めします。その結果、私のWhatsAppにも、高齢の家族から「これはAI？ これは詐欺？」というメッセージが6件も届くようになりましたが、彼らは格好の標的にされているのです。これは皆さんがコミュニケーションを取るべきことだと思います。まとめると、2要素認証の徹底、1Passwordなどのパスワードマネージャーの導入です。
あなたがTwitterに関して付け加えた点について、もう一つ言えるのは、何か異変を数分で察知したとき、ChatGPTやPerplexityを使ってそれをリサーチさせ、その脆弱性に関するあらゆる情報を取得できるということだね。そして、自分のMacBookが影響を受けているかどうかを分析するための1段落の指示文（コマンド）を作成させ、それをCloud CodeやPI、ハーネスなどの環境に貼り付ければ、「はい、このパッケージはこのプロジェクトに含まれています」あるいは「いいえ、安全です」と教えてくれる。それがおそらく最善の方法だ。
ええ、それは非常に大きなポイントです。特にClaudeはそのような作業が非常に得意です。ツイートを文字通りコピーして貼り付け、「私は終わっている（被害に遭っている）？」と聞けば、理解してシステムディレクトリなどのファイルを読み込んでチェックしてくれます。
実際、ある特定のケースで、自分が被害に遭ったかもしれないと思ったことがありました。詐欺化されたバージョンのまさに一つ前のバージョンのパッケージをダウンロードしていたのです。Claudeはすべてのディレクトリを直接確認し、システムディレクトリをチェックした上で、「あなたのマシンはクリーンです」と教えてくれました。
そのような確認を行うことは必要不可欠ですし、インストールするものに対してスマートである必要があります。現在、大規模な攻撃ベクトルはパッケージを通じて発生しています。この動画を見ている方は、おそらくエージェントを使って開発をしているでしょうから、「14日未満のパッケージはインストールしない」というプロンプトを設定しておけば、その間に脆弱性が発見されてキャッチされるため、安全を保つことができます。これが最大の対策です。
技術の波に乗り、未来に備える
この先、未来はどこに向かっていると思うかな。例えば3ヶ月後、あるいは6ヶ月後に何が可能になっているだろう。
ええ。私はエージェントティックエンジニアリングよりも、ナレッジワークの未来に対してより強気の見方を持っています。なぜなら、エンジニアリングにおける表面積（カバーすべき領域）があまりにも広すぎるため、モデルがそのすべてにおいて一様に優れることは難しいと感じているからです。
お気づきかもしれませんが、GPT-5.5はアーキテクチャやバックエンドに関する事柄において少しスマートであり、OpusはUIの作業において非常に優れているように見えます。このようにあまりにも大きな垂直領域が2つ存在しており、現在の問いは、これによって私たちはより巨大なモデルを作るべきなのか、それともより小さく専門化されたモデルを作るべきなのか、という点にあります。そこには多くの思考が存在し、当然ながらモデルプロバイダーには、それを解決するための最もスマートな人たちが揃っています。
しかし、私がナレッジワークにより期待している理由は、現在のナレッジワークにおける問題が、モデルの能力不足ではなく、その周囲のツールが十分に構築されていない点にあると考えているからです。モデルはすでに、膨大なナレッジワークをこなせるほど十分にスマートです。単にそれを取り巻くツールスタックが不足しているだけなのです。
だからこそ、OpenAIとAnthropicの双方が、このようなコンサルティング企業を立ち上げているわけです。彼らはフォワード・デプロイ・エンジニア（顧客常駐型エンジニア）を企業や中小企業に派遣し、セットアップを支援しようとしています。もしあなたが、まだあまりツールが導入されていない職場にいて、昇進を狙いたいと考えているなら、これらの手法を共有し、実際に使用して手本を示し、リーダーシップを発揮するといいでしょう。
デビッド、あるイベントで出会ったばかりの男性から聞いた話なのですが、冗談抜きで、彼は職場での契約書関連の業務（彼らは法律事務所ではなく、大手の法律事務所を雇う余裕がないため、顧問料として多額の費用を支払っていたそうです）において、同僚の前で一度だけプレゼンテーションを行い、Claude Codeがどのように機能するかを示しただけで、マネージャーに昇進したそうです。彼はまだ24歳ですよ。
ナレッジワークにおいて、これらがどれほど価値のあるものであるかを示したからです。ですから、これからの3〜6ヶ月の間に、ナレッジワークの領域でもエージェントティックエンジニアリングのブームが起き始めると思います。
個人的には、Opus 5がリリースされて、私たちの期待を遥かに超えてくれることを心から願っています。誰もが覚えている通り、12月4日がゲームのルールを変えました。あの時、私たちはこれがパラダイムシフトだと気づいたのです。Anthropicはまさにそこに向けて準備を進めているのだと思います。OpenAIがシェアを取りすぎているので、彼らはそれを止めにかかるでしょうし、そうあってほしいと思います。この競争こそが、進化を促進するからです。
したがって、3ヶ月の間、ナレッジワークは拡大を続けるでしょう。新しいモデルが登場するかもしれませんが、これらがもたらす長期的な影響については、実際のところ私には全く分かりません。そしてそれはある種、恐ろしいことでもあります。「仕事がこれこれに置き換わる」と言われるとき、完全にではないにせよ、一部の仕事は確実に置き換わるからです。
その時、どのような世界になるのか、仕事の影響を受けない（job proof）状態とは何なのか、どの仕事が安全なのか。もし3年前に「エージェントがコーディングにおいて素晴らしい成果を上げるようになる」と言われていたら、私はあなたを笑い飛ばしていたでしょう。プログラミングは誰にでもできることではないから、プログラマーこそが世界を支配すると言っていたはずです。それなのに、現在の私たちの立ち位置を見てみてください。
ですから、情報を常にキャッチし、先回りして行動し、そして何よりもこれを楽しむことです。デビッド、君も気づいているかもしれませんが、多くの人がこれらのツールの進化を恐れ、憂鬱に感じています。しかし、マインドセットを少し変えて、これらの事柄を楽しめるようになれば、結果的に業界とともに成長していくことができます。新しいことを学び、新しい仕事や案件、コンサルティングなどを獲得できるようになるのです。
変化を「自分に対して敵対的に起きているもの」として捉えるのではなく、マインドセットを少し変えて「自分のために起きてくれているもの」と考え、ツールとともに学ぶ姿勢を持てば、本当に楽しい時間になるはずです。業界が好景気に向かおうと不景気に向かおうと、私はどちらにせよ勝ちますし、そのようなマインドセットの変化が大きな助けになります。
そのマインドセットについて触れてくれて嬉しいよ。君ほど技術的でなかったり、最先端にいない人たちも同じように感じていて、私たちのことを、まるですべての答えを知っていて、次に何が起きるかを正確に把握している特権的なクラブか何かのように思っている。しかし、答えは「誰も知らない」なんだ。変化が激しすぎ、予測不可能すぎる。だからこそ、それを受け入れ、君が言ったように正しいマインドセットを持って自分のアドバンテージとして活用し、もし6ヶ月ごとにすべてが変わるなら、それは6ヶ月ごとに新しいビジネスのチャンスが生まれるということを意味している、と捉える必要があるね。
その通りです。100%同意します。そして、このバブルの中にいる私たちですら、思考は6ヶ月ごとに変わっています。昨年、Windsurfなどが流行していた頃、目標はエージェントに「すべてのコンテキスト」を与えることでした。覚えているかもしれませんが、コードベースをXMLなどに圧縮してコンテキストとして与えるサービスすら存在し、エージェントにコンテキストを詰め込むことこそがスマートな手法だと信じられていました。しかし現在、私たちは全く逆のことを行っています。
ですから、たとえ技術が遥か先まで進んでしまっていると感じたとしても、追いつき、先頭に立つことは非常に簡単です。技術的なバックグラウンドを持たない人に向けて、もう一つグラフを描きましょう。「自分たちはこれこれの仕組みを理解しているけれど、あなたは理解していない」と考えている人がいるかもしれないので。
ここに、非技術的な人々から超技術的な人々までの直線があるとします。Twitterでこれらの事柄を毎日最先端で語っている本当に詳しい人たちは、このグラフのほんの一部のセクションに過ぎません。何が言いたいかというと、あなたがこの位置にいるだけでも、ほとんどの人より遥かに先を行っているということです。
ですから、「私は技術に詳しくないから」と言い訳をするのはやめましょう。あなたには2つの選択肢があります。文句を言うのをやめるために技術を身につけるか、あるいは、ただその胸に野性味（dog）を宿すかです。ツールを使ってください。CLIの使い方が分からないなら、エージェントに聞いてください。私はRustの書き方を知りませんし、おそらく今後も学ぶことはないでしょう。私が何をするかというと、エージェントに「Rustを書きたいんだけど、どうすればいい？」と尋ねるのです。
また、失われつつある芸術として「本」があります。何冊か本を手に取って、読んでみるのもいいでしょう。エンジニアリングの原則を学びたいなら、読めるエンジニアリングの本は山ほどあります。私にとって「技術に詳しくないから」という言い訳は少し腹立たしく感じられます。なぜなら、私の周りには技術的なバックグラウンドを持っていなくても、デビッド、君のように最先端にいる友人がいるからです。それは単に気概（grit）とマインドセット、そしておそらく月に200ドルのサブスクリプションの問題に過ぎません。ですから、本当に言い訳は通用しません。ただモチベーションを高め、興奮を持ってこれらのツールを使用すれば、それはあなたを非常に遠くまで連れて行ってくれます。
楽しんでいれば、仕事のように感じられません。デビッド、君に「自分がやっていることは仕事のように感じられるかい？」と聞いたら、どう答えるかな。
AIを使って構築している時間は、ノーだね。それを1日12時間やっていて、それ以外のすべてのことが仕事のように感じられるよ。
ええ。そして正直なところ、それらはまるでスロットマシンのようです。カジノにいるような感覚すらあります。私の妻からも言われたのですが、以前はリラックスするために少しゲームをしていましたが、今はそれを完全にやめました。現在の私のゲームは、エージェントを立ち上げて、ランダムな何かを構築することです。ですから、人々がこれを楽しめるようになる余地は確実にありますし、そうすることで、今後数ヶ月の間に自分が遥かに社会の役に立つ存在になっていることに気づくはずです。
君の意見をさらに補強すると、「私は技術に詳しくない」とは言えない時代になっている。なぜなら、すべてのものがテクノロジーになるからだ。AIはあらゆる場所に偏在するようになる。私たちはまずそれをソフトウェアの領域で目撃しているけれど、間もなくヒューマノイドロボットやドローンなどを通じて、物理的な原子の世界（atom world）にも浸透してくる。だから「私は技術に詳しくない」というマインドセットは、「私は過去の人間です。未来の人間ではありません」と言っているようなものなんだ。「私は未来の人間ではない」と言い換えてみると、誰もが未来に備え、未来に適応していたいと思うはずだから、その異常さに気づく。誰もが技術的になるんだ。問題は、どれだけ早くこれを受け入れ、どれだけ早く最先端に立とうとするかだね。
100%その通りです。本当に、あなたの中にその気概があるかどうかの問題です。私よりも遥かに技術的知識が少なくても、これらのツールやハーネスを使いこなし、設定する点において、同等かそれ以上に優れている人たちを知っています。彼らはコードの書き方すら知りません。ですから、この機会を最大限に活用してください。
そうだね。さて、ミッキー、人々は君をどこで見つけることができるかな。
YouTubeやXで Ross Mike Ric として活動しています。クールな事柄について発信しています。デビッドほど頻繁には投稿していませんが、努力しています。そして、今回番組に呼んでくれて本当に感謝しています。とても意味のある時間でした。ありがとう。
どういたしまして。君のソーシャルリンクはすべて下に貼っておくよ。素晴らしい一日を、ミッキー。
良い一日を。バイバイ。
最後までご視聴いただきありがとうございました。しかし、行動を伴わない視聴は無意味です。ですから、動画の下にある最初のリンクから、このポッドキャストで言及されたすべてのスキル、プリセット、リポジトリを含むバンドルを手に入れ、ミッキーが語ったすべての内容を今すぐ実践してください。今すぐそれを手に入れて、あなた自身のエージェントティックエンジニアリングのワークフローに組み込んでください。繰り返しになりますが、完全に無料です。
コメント