AI技術とLLMの急速な進化によって、従来のソフトウェア開発の常識や開発支援ツールのあり方がどのように変貌しつつあるかを語る対談。エディタの開発やAI assistantsの黎明期から最前線に携わってきた開発者が、自らのキャリアの歩みや哲学的な視点を交えながら、コードを書くという行為の本質的な価値の変化、そしてこれからのエンジニアに求められる新たな役割について、深く刺激的な洞察を展開している。
従来のソフトウェア開発の終焉
私たちが知っているようなソフトウェアは死にました。これはかなり大胆な発言ですね。私の社内での肩書はディクテーター、つまり独裁者です。
今までに自分がやってきたことのすべてが、今ではまるで白黒映画のように見えます。Vimを使いこなすために10年を費やしました。
私はかなりタイピングが速い方です。しかし、その後、こうしたことはもう何の意味もないと気づいたのです。誰もが、適切なエージェントハーネスとは何かについて、独自の定義を与えようとしています。AIの登場により、基本的には数ヶ月ごとにすべてを根本から作り直さなければならなくなっています。モデルは括弧がどこに入るかを自分で判断できます。そうした時代はもう終わったのです。人間が作成したコードは貴重なものです。だからこそ、皆さんにはコントリビューショングラフがあるわけです。しかし、2026年にもなって誰がコントリビューショングラフなど気にするでしょうか。AIは信じられないほど奇妙で、稀有で、これまでにない製品です。そして私は、すべてをひっくり返さなければならないという、とてつもない衝撃の瞬間を迎えました。2つ目のモデルも、制限も必要ありません。ただモデルにトークンを与え、ツールを与え、邪魔をせずにいれば、モデルがそれをやってのけるのです。
ホストのあなた、来てくれて本当にありがとうございます。ついに実現しましたね。実は以前、AMPのメンバーであるクイン・スラックともポッドキャストで話をしました。彼とも良い会話ができました。エージェントによるコーディングや、この1年間にテクノロジー界隈で起きているあらゆることについて語り合いました。あなたもモバイル・ウェストで、この1年間に私が語ってきた多くのことについて耳にしているかもしれません。私が間違った言い方をしてしまっているかもしれませんが、あなたがこの1年間にたくさんのことについて話しているのを聞いていました。私は2025年の8月か9月頃にAMPを試してみて、その時からあなたやAMPの他のチームメンバーをフォローし始めました。皆さんが私のコーディングスタイルや開発ワークフローに与えてくれた視点の変化は非常に大きなものでした。その話はまた後ほど詳しくしましょう。ですが、まずはあなた自身について詳しくお聞きしたいです。少し前に知ったのですが、あなたはインタープリタに関する本とコンパイラに関する本の2冊を執筆されているのですね。それらを知って、私は本当にあなたのファンになりました。なぜなら、それらは非常にコアなテーマだと信じているからです。私が初めてこれらのテーマに触れたとき、すべてを理解することの奥深さに畏敬の念を抱きました。そして、この人がそれらのテーマで本を書いていると知ったとき、このようなテーマについて、どうやってアプローチすればいいのかを純粋に理解させてくれるこれほど深い本が存在するのかと驚き、その日にファンになったのです。そこで、過去6年ほどの間にあなたがどのような活動をしてきたのかをお聞きしたいです。これまでの旅路のすべてを要約してもらうのは大変かもしれませんが、これまでのキャリアのハイライトを教えていただくとしたら、どこから始めますか。
キャリアの歩みとAIとの出会い
そうですね、6年ですか。6年というのは良い区切りですね。2冊目の本を出版したのは2018年なので、それはもうその期間からは外れてしまいますが、今から7年前の2019年のことです。
私はSourcegraphで働き始めました。当時もCEOはクイン・スラックでした。それが私にとって最初の米国スタートアップ、あるいはシリコンバレーのスタートアップでの経験となりました。
それが私にとって多くのことの始まりでした。それ以前はドイツのスタートアップで働いており、常にスタートアップや製品チーム、全員が何でもこなすようなチームに身を置いていました。Sourcegraphでもそれは同じでしたが、米国のスタートアップのメンタリティは、ドイツのスタートアップとは完全に異なっていました。そこで経験を積み、タイムラインを細かく描くつもりはありませんが、振り返ってみると、過去10年ほどのテック業界が経験してきたこと、私たちがSourcegraphで経験してきたことは比較的典型的だったと言えます。資金調達を行い、私が加入したときは20人ほどだった組織が、ある時点では300人以上にまで拡大しました。
そしてその後、規模が縮小し、人員削減を余儀なくされるなど、その後の4、5年で一通りのことを経験しました。私はエンジニアからスタートし、スタッフエンジニア、マネージャーを経て、ある時点からはクインの直属のポジションのようになりました。そこでもあらゆる業務をこなし、多くのチームをサポートしました。Sourcegraphで本当にたくさんの経験を積んだ後、4年半ほど主にフルタイムでGo言語を扱い、ランゲージサーバーの開発やバックエンド、コードインテリジェンスなどの業務に携わっていましたが、あることに気づきました。話を進める前に補足しておくと、当時も私はSourcegraphのCodyチームに所属していました。これは2023年の初めのことです。
当時における最初期のコーディングアシスタントの一つでしたね。アシスタント。この言葉を長い間耳にしていませんでした。私たちはClaudeを使用していました。当時はまだ誰もClaudeが何であるかを知らないような時期に、私たちはAnthropicのClaudeを利用する最初期のエンタープライズ顧客の一つだったのです。私はそのプロジェクトに参加していました。そのプロジェクトに携わった後、自分の中に何か思うところがあり、プログラマーとしての自分の限界をまだ見極めていないのではないか、もっとプログラミングをする必要があるのではないかと感じ、テキストエディタのZedに移籍しました。そこで1年間、Rustを使ったハードコアなRustプログラミングを行いました。Zedのチームは、誰かを悪く言うつもりはありませんが、私がこれまでに一緒に働いた中で最も優れたプログラマーたちの集まりだったと言えます。
信じられないほどの技術力を持ったチームで、高度にテクニカルで、美しいコードベースと美しいテクノロジーが揃っていました。そして、私はそれを見届けて、自分の中の一つの頂点に達したと感じたのです。GoogleやMetaのような規模の会社であれば、もっと多くのことを見られるかもしれませんが、個人の純粋な技術力やコードベースなどの観点から言えば、これを超えるものを見つけるのは難しいだろうと思いました。そこで自分の中の何かが満たされたと同時に、AIがどんどん大きく進化していきました。
いくつかの要因が絡み合っていて完全には分解できませんが、私はテキストエディタの開発をこれ以上続けたくないと考え、周囲を見渡しました。そして面白いことに、再びクインと話す機会があり、私たちが二人とも同じ意味でAIに完全に魅了されていることに気づいたのです。Zedでは、最後の2、3ヶ月間、アントニオと一緒にZedのタブ補完機能の開発に取り組んでおり、ファインチューニングを行っていました。ファインチューニングを行い、タブ補完がどのように実装されているかを調べていくうちに、自分の中で多くのことが腑に落ちました。
そして、明確な瞬間が訪れたと感じたのです。私はVimがかなり得意です。何年も何年もかけてVimを使いこなせるようになりました。実用的なVimの本を読み、ブログ記事を書き、10年を費やしてVimに精通しました。かなり速く操作できますし、よく理解しています。しかし、モデルをファインチューニングし、当時最先端だったCursorなどのタブ補完を使用してみたとき、これらのスキルがもう何の意味も持たないことに気づいたのです。これはエージェントが登場する前の話ですが、Vimのキーバインドを駆使して素早くナビゲートし、特定の場所にジャンプしてコードを移動させていたのに、モデルがそれをただ予測してくれて、自分がタブ、タブ、タブと叩くだけで済むなら、なぜこれらすべての操作を行う必要があるのだろうか、という瞬間でした。これまでのすべてが白黒映画のように色褪せて見えました。そんなことが起きていたのです。そこで私はSourcegraphに戻り、クインと一緒にこれらのモデルを使った開発を始めました。当時の最新のClaude、おそらくClaude 3.5は、ツール呼び出しが非常に優れていました。当時もまだCodyはありましたが、今でこそAIについて人々が語るようなことを、私たちは1年半前の時点で急進的な形で主張していました。人々はAIの登場によって、数ヶ月ごとにすべてを根本から作り直し、これまでの前提を再確認しなければならないということを理解していません。当時の状況を説明すると、少し長くなりますが、当時Cursorはシステム全体を統括するような存在でした。サイバーコンポーザーですね。彼らは世界のトップに君臨しており、その仕組みは、アシスタントに指示を出してもツールは一切使わず、単にチャットをして、このファイルをどのように修正すべきかを尋ね、文脈を与えると、プロポーザルやdiffが返ってくるというものでした。特定のdiff形式で返答するように厳しく指示を出すこともありました。そして別のモデルを使い、このdiffとファイルの文脈を踏まえて、最終的なファイル出力はどうなるかを処理していました。このように複数のモデルを連鎖させており、Cursorは現在もその処理が非常に得意です。そのため、人々はこれが正しいあり方だと考えていました。複数のモデルを用意し、それらを繋ぎ合わせるという方法です。しかし、最新バージョンのClaudeが登場すると、パッチの適用やファイルの編集といったツール呼び出しを1回行うだけで、古い文字列と新しい文字列、文字列の置換を処理し、これまでのやり方をすべて圧倒してしまったのです。そして昨年の3月、これはClaudeのコード生成機能が正式にリリースされる前のことですが、クインと私は、すべてを根こそぎ引き剥がさなければならないという衝撃的な瞬間を迎えました。2つ目のモデルも、制限も、モデルの上で余計な装飾をすることも不要です。ただモデルにトークンを与え、ツールを与え、邪魔をせずにいれば、モデルがそれをやってのけるのです。そうしてAMPが始まりました。そして私たちはAMPを立ち上げました。現在、私の社内での肩書はディクテーターですが、これは蔑称ではなく、AMPの共同創作者の一人として、適切な決定を下す責任がある、あるいは決断を下す人物であることを意味しています。基本的には、多くの意思決定を行っています。私たちはその開発を続け、昨年Sourcegraphから独立した別の会社としてスピンアウトしました。
素晴らしいですね。あなたがこれまでの歩みを簡潔に、しかし非常にスピーディーに要約してくれたので、今度はあなたが活動を始めた原点に話を戻してみたいと思います。あなたの学歴は哲学だとお聞きしましたが、それは間違いありませんか。
学校は中退してしまったので、学位は持っていません。
なるほど。では、どのようにしてすべてが始まったのでしょうか。どのようにしてプログラミングやコンピュータサイエンスに魅了されていったのですか。その始まりについて教えてください。
独学の時代とプログラミングへの情熱
10代の頃のことです。私は昔からコンピュータが好きで、コンピュータの前に座るのが好きでした。そして10代の時に、ウェブサイトを作り始めました。偶然、姉のコンピュータサイエンスの授業を覗く機会があり、そこではMicrosoft FrontPageを使ってウェブサイトを作っていました。その時、以前にも書いたことがあるのですが、明確な瞬間がありました。
先生がウェブサイトの仕組みについて説明してくれたとき、これをどうやってインターネット上に公開すればいいのかを理解したのです。無料のウェブスペースに登録し、FTP経由でアップロードすればいいのだと。そうすれば、ドメイン自体は貧弱なものかもしれませんが、自分のウェブサイトがCoca-Cola.comやNew York Times.comといった大企業のサイトと並んでインターネット上に存在することになります。それは同じことです。大手プレイヤーと同じ通りに並び立つことができ、そのために必要なのはコードを書くことだけなのです。それだけで、彼らと同じくらい見栄えの良いものを作ることができ、ソースコードを表示すれば、他の人たちがどのように実装しているかを調べることができます。
ライセンスも学位も許可も必要ありません。自分とコンピュータがあれば、ただ掘り下げて理解し、独学で学ぶことができる。そのことに信じられないほど大きな力を与えられたと感じました。読む意欲さえあれば、すべての情報がインターネット上に転がっているのです。それが、私がこれらすべての活動を始めるきっかけとなりました。その後、HTMLを始め、Pythonなどでいくつかのボットを書きたくなり、友人がLinuxのCDをくれたことをきっかけにLinuxにものめり込んでいきました。それが10代の頃のことです。その後、数年間はプログラミングを離れ、音楽に没頭していました。そして、おそらく23か24歳くらいの頃だったと思います。音楽活動を並行して行うために哲学を学んでいました。その頃、義理の父親のために再びウェブサイトを作ることになり、プログラミングに戻ってきました。コンピュータの中にあるウェブサイト関連の古いフォルダを引っ張り出し、PHPなどで作業をしていたのですが、その時に「そういえば、今は何か新しいものが登場していないか」と気づいたのです。今はHTML5というものがあるのではないか、jQueryとは何だろう、Ruby on Railsとは何だろう、と。そしてRuby on Railsの本を買い、開発を始めて、完全にその魅力に取り憑かれました。私の10代の頃を知っている友人に、学位がなくてもこれを職業にするチャンスはあると思うかと尋ねました。すると彼は、実力さえあればいい、誰も学位なんて気にしないと言ってくれました。もちろん、Facebookで働くにはどうすればいいかといった大それた話ではなく、単にこれで お金を稼ぐことができるか、仕事をしていけるかというレベルの問いでしたが、彼は、できることを証明できさえすれば可能だと言ってくれました。それが私に火をつけました。それからは、ただ本を買い続け、それを読み、実践していくだけでした。コンピュータの前に座って、その扱いが上達していくプロセスが楽しかったのです。そして、ギターの練習をするよりも、プログラミングの練習をする方が自分にとってはるかに楽しいことだと気づきました。
バグに直面したり、たとえばコンパイラを書いていてうまく動かなかったりすると、確かに深い絶望を味わうことになります。しかし、最終的には、コンピュータの前に座って物事を解決しようとすること自体が好きなのです。そして、コンピュータが返してくれる「動くか、動かないか」というバイナリな答え、ある程度の明確さが好きなのです。チャットボット、当時はIRCのチャットボットのようなものを書いているとき、それが動くか動かないかははっきりと分かります。しかし音楽の場合、それは常に曖昧です。これが良い曲なのか、きれいに演奏できているのか、耳が肥えていなければ判断することすらできません。リズム感がなければ、自分がリズムから外れていることすら分かりません。それらは全く異なる種類のものです。ですから、コンピュータの前で練習し、プログラミングが上達していくことは、時に苦痛を伴うものの、自分が耐えることのできる心地よい痛みのように感じられました。そのおかげで、私は人一倍のスピードで走り続けることができ、やがてインターンシップを得ることができたのです。
それは、ある意味であなたにとって自然な傾向、天性のようなものだったのですね。
自分が何を耐えられるか、ということだと思います。たとえば営業職の人を例に挙げると、彼らはそれを気まずいと感じたり、簡単ではないと言ったりするかもしれませんが、多くの人と話をして、拒絶されても再び挑戦できるという、異なる特性やプロフィールを持っています。他の人にはそれができないかもしれません。私の場合は、コンピュータの前に座っていることが苦になりません。ソフトウェアが好きで、製品が好きで、ウェブやインターネットが好きで、文章を書くことや読むことが好きなのです。
文章を書くことについて言及されましたが、私もその点に注目していました。あなたがXやニュースレターで書いている文章を読むたびに、私たちプログラマーや開発者が日々の業務の中で、あるいはコーディングエージェントを扱う中で、あるいは開発全体について考えているときに頭の中でぐるぐると考えている事柄のほとんどを、あなたがそのまま言葉にしてくれていると感じます。それらは大抵、私たちの頭の中にだけあるものです。私たちはそれについて考えているか、あるいは開発やエンジニアリングに熱心な親しい友人と、こういう時はどうするべきか、どのように意思決定を下すべきかといった、プログラマーとして進むべき道の細かなディテールについて議論しているかのどちらかです。あなたはニュースレターやXの投稿を通じて、そうした事柄をまさに大声で言葉にしてくれています。だからこそ、あなたの文章は私に強く響くのだと思います。あなたが書いたものを読むたびに、そこに多くの自分自身を見出すことができます。自分もまさにそんな風に考えていた、と感じるのです。これが、あなたの文章を読むときの私の率直な反応です。
探求としての執筆活動
それは、ある意味で自然なことだと思います。私はどのような文章を書くときも、自分が読者より上の立場にいると考えたり、自分がスマートであると考えたりしたことは一度もありません。自分を突き動かす最大の原動力、あるいは唯一の原動力は、学び、理解し、世界にある次のパズルを解き明かすことです。
ですから、私にとってプログラミングの多くは、先ほどコンパイラの話をしましたが、ゲームで言うところのコンプリートを目指すような、すべてのサイドクエストやチェックマークを網羅しようとするタイプとは真逆のスタンスです。10個のうち1個を解き明かし、残りの9個をどうやって解けばいいかの見通しが立てば、そこで興味を失ってしまうのです。重要なのは、その仕組みを解き明かすことです。私にとって、執筆活動、そして皆さんが私の文章の中で目にするものは、しばしば私自身が物事を理解しようと試みているプロセスそのものなのです。そして、傲慢さや不遜な態度からは、物事を真に理解することはできないと思います。ですから、私は何かのふりをしようとはしません。科学的な文章を書いたこともありませんし、三人称で文章を書くこともできません。それは常に自己中心的に、私という主観から出発しています。それしかできないのです。ですから、私が文章を書くときは、それが私の世界の捉え方であり、物事を理解するアプローチそのものです。長年にわたり私の文章を読んできてくれた方なら分かると思いますが、そこには常に問いが存在しています。私の文章には多くの問いがあり、答えはそれほど多くありません。そして、それが特に私が書いた本などを通じて、多くの人々に響いているようです。それらは教科書ではありません。これが最高のコンパイラを作る方法だ、あるいはすべてのコンパイラはこう動くべきだ、と提示しているわけではありません。導入部分でもそのように述べています。これは私がその仕組みを理解したかったからであり、読者の皆さんをその旅に連れ添って、自分が何を発見したかを共有しているのです。
幸運なことに、私が世界を認識し、物事を理解し、それを自分自身のために説明して筋を通そうとするその方法が、多くの人々の共感を呼んでいるようです。それは幸運なことです。なぜなら、教科書を読んでも一部の人にしか理解できないことがありますが、同じ主題について10個の文章があれば、それら10個の文章は人によってそれぞれ異なる響き方をするということを、私は時間をかけて学んできたからです。私は、適切な読者層と良いオーバーラップを持てているのだと思います。
それは素晴らしいことです。私たちはそれを読むのが大好きですので、ぜひそのままのあなたで発信を続けてください。それだけで十分です。
ここで少しトリッキーな質問をさせてください。あなたや、会社としての見解、そしてクインの見解の多くは、本質的にかなり急進的であるため、その点については疑いの余地がありません。しかし同時に、現在エンジニアリングを学んでいる人や、エンジニアリングの学部を卒業したばかりの人は、これが未来だ、あれが未来だ、あるいは人間のレイヤーとしてのエンジニアリングにはもう未来はない、といった混沌とした状況の中で、どのように自らの進むべき道をナビゲートしていけばよいのでしょうか。現在、多くの雑音が存在し、様々なグループがそれぞれの未来のナラティブを主張しています。これが、テック業界に新しく参入しようとしている人々に大きな混乱をもたらしていると私は信じています。
その点について、あなたの視点をお聞きしたいです。私個人としては、あなたがこの点について言及している文章をまだ読んだことがありません。私の認識が間違っているかもしれませんが、今日、そのことについてどのように考えているのかをぜひお聞きしたいです。これは重要な問いだと思います。私たちはやがて50代、60代になり、その後は次の世代の誰かが物事を解決していかなければなりません。ですから、私たちの文章や動画を楽しみにしている人々に、進むべき道、あるいは少なくとも一つのナラティブを示すべきだと思うのです。
ソフトウェアエンジニアリングの新しい定義
そうですね、これについて書いてこなかったのは、私自身にも分からないからだと思います。多くの人が分かっていないのではないでしょうか。ただ、少し揺り戻しが起きているようにも感じます。人々は今、将来的にもソフトウェアエンジニアは存在するだろうと言い始めています。
私が言えるのは、純粋にプログラミングだけを目的としたソフトウェア構築のアプローチ、それはもう終わった、死んだということです。
プログラマーになりたい、だからRustやその他の言語を書きたい、というアプローチです。
特定の言語でコードを書くこと自体は、もう重要なことではありません。その言語を書くスキルさえも、もはや最も重要なことではないのです。一部の人々は、そんなものは最初から重要ではなかったと言います。確かにその通りです。シニアエンジニアやスタッフエンジニアであれば、常にビジネスへの影響は何か、製品は何か、顧客のどのような問題を解決しているのか、顧客にどのような価値をもたらしているのか、そもそもビジネスとは何なのか、ということが本質であるべきでした。しかし、多くのプログラミングの仕事において、情熱的なプログラマーの多くがビジネスにも顧客にも関心を持っていなかったという事実を認めなければ、私たちは自分自身を欺くことになるでしょう。彼らはただプログラミングが好きで、毎日小さなパズルを解くことが好きだったのです。彼らは家に帰り、一日の終わりに「今日は良い一日だった。なぜなら借用チェッカー（ボローチェッカー）の問題に直面し、それをリサーチして型を構築し、それらを使って解決できたからだ」と満足していました。もし、あなたがプログラミングから得たいものがそれだけで、それだけを目的にしているのであれば、これからの時代、それに投資する価値はあまりないと思います。それに対する需要が今後多くなるとは思えません。
とはいえ、ソフトウェアエンジニアであり、同時にテクノロジストである人材への需要は今後もあると考えています。物事がどのように機能しているかを理解し、複雑なシステムを構築し、概念化し、理解し、デバッグし、維持し、強化することができる人々です。そして、ビジネスが何であるかを知り、自らの顧客が誰であり、彼らが何を望んでいて、なぜそれを望んでいるのか、そしてソフトウェアを構築することによってビジネスがどのようにそれらの価値を解決し、前進させることができるのかを理解している人々です。それがソフトウェアエンジニアの仕事であり、コードをタイピングして適切な行にセミコロンを置くことではありません。
ですから、もしあなたがソフトウェアに関心があり、製品に関心があり、ソフトウェアを通じて何かを表現することに関心があり、伝えたいことがあり、ビジネスに関心があり、ビジネスやソフトウェアビジネスを用いて問題を解決することに関心があるのであれば、そこには未来があると思います。しかし、その全盛期、たとえば2019年のように、8週間のブートキャンプに通えば誰でもエンジニアになれるといった時代は終わりました。当時はとにかく頭数が必要で、PMがチケットを書き、デザイナーがデザインしたものをエンジニアに渡して構築させるという、今思えば信じられないような体制のチームがたくさんありました。私はそのようなチームにいましたし、私自身がまさにチケットを受け取って実装するだけの存在でした。しかし、そうした性質の仕事はどんどん縮小しています。
私たちはより高いレベルへと移行しており、問題はそうした人材に対する需要がどうなるかということです。一方で、私たちが知っているようなソフトウェア、あえて強調しますが、「私たちが知っているような形」のソフトウェアは死んだと考えています。私たちが現在も使用しているソフトウェアの多くは、数年後にはもう存在しなくなるでしょう。これらのモデルの進化の軌跡や、データセンターの建設規模、処理速度などを考えれば、多くのことが変わり、多くのエンタープライズソフトウェアが変貌を遂げるはずです。
内製するか購入するかといった議論も、単純な二者択一にはならないでしょう。誰もがこれをやり、誰もがそれをするというわけではなく、多くの事柄が変化し、ソフトウェアは全く異なる姿になるはずです。それがどのような姿になるかは分かりませんが、それらの製品を構築し、技術的な理解を持つ人材が必要とされることは間違いありません。
他の職業を例に挙げると、私はよくファッションの例を出します。パリにいるファッションデザイナーは、使用されるテキスタイルを知り、色彩を知り、製造プロセスを理解しています。「この色を発注してこれを1000着作れば、このような色合いに仕上がる」といったことを理解しているのです。彼らは自分で布を裁断することなく、製品をどのように製造するかを熟知しています。他にも多くの例があります。BMWでエンジンを設計する人物は、必ずしも自分でエンジンを組み立てたり、機械を操作したりする人物である必要はありません。私たちはより高い抽象レイヤーへと移行しており、ソフトウェアに対する需要自体も高まっていくと考えていますが、私たちが知っているようなソフトウェアのあり方は変化しつつあります。
ソフトウェアは死んだ、と結論づけられたのですね。
私たちが知っているようなソフトウェアは死んだ、ということです。ソフトウェアを実行するCPUは今後も走り続けるでしょうし、トークンを出力するGPUも存在し続けるでしょう。それらは両方とも大量に存在することになります。ただ、ソフトウェアがどのような姿になるかが問題なのです。私の考えを共有させてください。
ここ数年の動き、そして根本的な部分に目を向けると、これらのモデルはソフトウェアに全く新しい要素をもたらしました。それは、モデルが「曖昧（ファジー）」であるということです。バイナリ（二者択一）ではありません。コンピュータがこれまで扱うことのできなかった方法で、言語を扱うことができます。
そして、コンピュータがこれまでできなかった方法で、コンピュータ自体を操作することができます。画像を生成することも、画像を理解することもできます。「理解する」という表現に対して批判的な人や嫌悪感を抱く人がいるかもしれませんが、これはコンピューティングにおける根本的な変化です。
そして、これらのモデルの進化のグラフを見ると、過去3、4年間、比較的安定して、あるモデル世代の到達した最高点が、次の世代のベースラインになっています。つまり、Claude 3.5のツール呼び出しが素晴らしいものであったなら、Claude 3.7ではそれが当然の前提となります。次の世代で「これは本当に賢く、この処理が非常に得意だ」と評価されたものは、さらにその次の世代では当たり前の機能になります。この先の2年間を予測するだけでも、非常に強力なモデルを手にすることになります。私は最近、Opus 47や最新のGPTモデルを頻繁に使用しています。昨日を例に挙げると、私はある機能の開発に取り組んでいました。基本的には、クライアントがサーバーからデータをダウンロードし、特定の要素を反転させてサーバーに送り返すという処理です。これは、かつてデータをアップロードする必要があった時代の古いレガシーな処理の名残りでした。現在はデータがすでにサーバー上にあるため、その必要はありません。私はその問題の概要をハイレベルな言語で説明しました。私はもう基本的にはコードを一切タイピングしません。内容を説明すると、モデルは完璧な分析を返し、書き上げられたコードは信じられないほど素晴らしいものでした。昨年であれば、これを見せられたら狂っていると言ったでしょうし、それが今やベースラインになっているのです。では、次のベースラインはどうなるでしょうか。
これを踏まえて、ジャックとジミーが取り組んでいるような事例、彼らは1つのモデル、確かLLaMAモデルのために巨大な専用チップを構築し、1秒間に1万7000トークンを出力できるようにしました。これを利用して、どれほど長いプロンプトを与えても、一瞬で処理されてしまいます。
仮にフロンティアモデルがこの速度の半分、現在は1秒間に40トークンや60トークン、あるいは100トークン未満の速度ですが、これが1秒間に5000トークンに達したと想像してみてください。Opus 47が1秒間に5000トークンで動作する姿を想像してみてください。物理的な限界によってそれが不可能であるとする理由は存在しないと思います。現在、私たちの足枷になっているのは、さらに多くの資金とエネルギーをそこに投入しようとしている段階だからに過ぎません。人々が理解していないのは、これらのAI企業は立ち止まることができないという事実です。彼らは「ここで一旦立ち止まり、Opus 47を最適化して5倍高速にしよう」とは言えません。なぜなら、競争の本質はそこにはないからです。競争の本質はAGIに到達すること、あるいはより優れたモデルを構築することにあります。彼らはサメのようなもので、泳ぎ続けなければ死んでしまいます。常にレースを続けなければならないのです。最適化が行われるのは、トレーニングの実行においてコストを削減できる最低限の部分だけです。もしAnthropicが「トレーニングパイプラインを最適化するために、今後1年間は新しいモデルのトレーニングを行わない」と言えば、彼らはその瞬間に脱落することになります。OpenAIが彼らの市場を奪うでしょうし、逆もまた然りです。さらに、中国のモデルも猛追しています。それが現実です。
この競争は狂気じみています。これらの異なるメカニズムが働き、モデルがどんどん進化していくことを考えれば、仮に2年後に進化が停滞するとしても（現時点で停滞すると信じる理由はありませんが）、仮にOpenAIや中国のモデル開発者たちが「ここでストップだ、もう十分だ、モデルの性能はこれで満足だ」と合意したとしても、今度はそれを徹底的に最適化する人々が現れます。その結果、1秒間に1万トークン、5000トークン、あるいは2000トークンといった速度が実現します。その時、何が可能になるかを想像してみてください。あなたの画面を理解できるこの曖昧性を備えたマシンが、10倍の速度で動作するのです。それは、システムをループで実行し、自己修正させることができるということを意味します。そうなれば、コンピューティングのあり方そのものが完全に変わってしまいます。本当にクレイジーなことです。さらに価格も下がっていけば。
ですから、これからの10年間でソフトウェアは根本的に変わると考えています。フロンティアが「ギザギザ（一様ではない進化）」になるかどうか、あるいは私が以前言ったように、コーディングの領域において狂気的なほど優れた進化を遂げるかどうかは分かりません。一部の要素が古く見えたり、SF映画のように、人々が宇宙船に乗っていながら古いライフルを持っているような、何世紀ものテクノロジーが混在する形になるかもしれません。ソフトウェアもそのようになる可能性があります。ワードプロセッサを使い続けながら、同時にSiriに話しかけて、自分がVimでタイピングして行えるようなあらゆる処理を代わりに実行してもらう、といった形になるかもしれません。それは分かりませんが。
そして、それはモデル単体の話に過ぎません。もう一つの側面として。
ソフトウェア業界全体、そしてソフトウェアエンジニアリングの実践は、いくつかの基礎的な柱の上に築かれてきました。それは、「ソフトウェアエンジニアリングは高コストである」「ソフトウェアエンジニアリングは時間がかかる」そして「人間の手が必要であり、コードを生み出すことは難しい」「正確なコードを生み出すことは難しい」という柱です。私は過去7年間、開発者向けツールの開発に携わってきました。
そして今日、キッチンにいるときにふと気づいたのです。私はこの分野の仕事が大好きですが、ランゲージサーバーという存在が、今やいかに面白みのないものになってしまったかということに。4、5年前、ハッキングやプログラミング、コンパイラに関心を持つすべての人が、ランゲージサーバーの開発に携わりたいと考えていました。それはクールな仕事でした。コードを提案し、自動補完を行う。しかし今では、誰もそんなことを気にしません。モデルは括弧がどこに入るかを自分で判断できるのです。その時代は終わったのです。
それは非常に多くの情報量で、圧倒されました。私が投げかけた問いに対して、本当に深い答えを返していただきました。同時に、あなたが触れた多くのテーマについて考えていましたが、私たちはまだそこには到達していません。最近、Xでもこれらのテーマについて多くの議論が交わされています。
過去2、3週間にわたり、「エージェントハーネス」に関する議論を耳にされたかと思います。今や誰もがそれを追い求めています。誰もが、適切なエージェントハーネスとは何かについて、独自の定義を与えようとしています。エージェントハーネスに何かを加えるべきなのか、あるいはそれを厚くするべきか薄くするべきか。同様に、この1年間、プロンプトエンジニアリングやコンテキストエンジニアリングについても多くの議論がありましたね。
はい、私もすでに多くの議論を経験してきました。
その視点からお聞きしたいのですが、私はプロンプトエンジニアリングは今後も残り続けると考えています。エージェントハーネスについて考えるとき、非常に大きな部分、重要かつ有意な部分は、プロンプトやシステムプロンプトをどのように記述するかを模索することにあると思うのですが。
エージェントハーネスの役割の変化
しかし、モデルの進化に伴い、その重要性はどんどん低くなっていると言えます。
重要性が低くなっていると言えるかもしれませんが、それでも依然として存在しています。
しかし、私が昨年も言ったように、AMPにおけるハーネスの仕事、そして私たちがCodyで経験したことですが、Codyはある種のエージェントハーネスであり、ハーネスがモデルを囲んでいたために、モデルがどれほど優れているかを見落としていました。適用モデルがあり、別のモデルがあり、意図検出モデルがあり、あれこれの処理が存在していました。ハーネスが果たすべき役割とは、モデルが優れていくにつれて、基本的には「剥がれ落ちていく」ことなのです。
剥がれ落ちていく、ですね。
そうです。私が以前表現したように、それはまるで木製の足場のようなものです。モデルがあり、その周囲に木製の足場を組み立てていきますが、モデルが大きく、あるいは優れたものになるにつれて、足のギプスが治癒した後に取り外されるように、それは剥がれ落ちていくべきなのです。
例を挙げると、昨年の初め、モデルにツール呼び出しを行わせてファイルを編集させたいと考えた場合、私は昨年「エージェントの構築方法」という大きな反響を呼んだブログ記事を書きましたが、エージェントに関心があるならぜひ読んでみてください。当時は、文字列置換やファイル編集といった関数をモデルに与え、古い文字列と新しい文字列を指定して置換させていましたが、モデルがそれを間違えることがよくありました。ファイル内に同じ文字列が複数存在する場合にエラーを投げる必要があったり、モデルが行番号を理解していなかったり、ファイル内のどこを探すべきか分からなかったりしたためです。そのため、ファイルを読み込むための複数のツールを用意していました。ファイル全体を読み込むツールや、特定の行番号を指定するツールなどです。しかし、Claude 3.5は数字の扱いがあまり得意ではありませんでした。行番号を入れると混乱してしまったのです。ところがClaude 3.7が登場すると、突然行番号を理解できるようになりました。行番号を入力すれば、それに基づいて読み込むことができるようになったのです。「このファイルの1行目から50行目がこれだ」と提示すれば、モデルは「なるほど、次は50行目から99行目を読み込む必要があるな」と自分で判断できるようになりました。
モデルは数字の扱いが非常に得意になり、ある時点では、セマンティックマッチを見つけてモデルの作業を最小限に抑えるような、スマートなファイル編集ツールを備えた多くのGitHubプロジェクトが存在していました。さらに、トークン効率の良いカスタムのdiff形式を使用するなど、ハーネス（ツール）側がどんどん巧妙になっていきました。しかし現在、最新のモデル、たとえばGPTの最新世代などは、あなたが用意したツールなど微塵も気にしません。彼らはただシェルコマンドを実行します。catを実行し、wc -lを実行し、sedを実行し、ファイルを置換するためのPythonスクリプトを自分で書き上げます。あなたが与える必要があるのは、基本的にはbashの実行環境、それだけです。他に何も必要ありません。それだけで、ほぼ最高のパフォーマンスを得ることができるのです。
私はこれを何度も実行し、多くの人々と検証してきました。彼らは「シンボル名を変更したい場合、ランゲージサーバーのツールを与えて、参照を検索できるようにすべきではないか」と言います。私は「実際に作って試してみるといい」と答えました。誰もがそのプロセスを通過します。
問題は、モデルが賢くなったことだけではなく、モデルに固有の「性質」があるということです。モデルが好む処理と、好まない処理があります。覚えているかどうか分かりませんが、昨年の5月頃、Claudeはコードを削除する際、実際にコードを削除する代わりに「削除されたコード」というコメントを残す傾向がありました。
そのため、人々はハーネスの中に、このコメントを見つけるたびにそれを削除するような処理を組み込んでいました。しかし、現在のモデルは非常に優れているため、そのような工夫は一切不要です。彼らはただ編集を行い、それを実行するためのコードを自分で書くことができます。
では、エージェントハーネスという存在も、ある意味で死に絶えつつあるとお考えですか。
ハーネスをどのように定義するかによりますが、そのブログ記事の中で、あなたはエージェントを構築することを、いくつかの基本的な処理を実装しさえすれば、基本的なコード編集エージェントとしては十分であるかのように表現されていましたね。
それがPiであり、まさにその通りです。
人々がハーネスをどう定義するかによります。ブログ記事を書いた理由、そのサブタイトルは「裸の王様」でした。なぜなら、人々は「Claudeのコード生成はどう動いているのか」「Cursorはどうやっているのか」と驚いていましたが、実態は単なるループに過ぎないからです。
もちろん、プロンプトの履歴やメタデータ、どのファイルを開いているかを伝える処理、いくつかの特化型ツールなどを追加することはできます。しかし、本質的な魔法はそのループであり、モデル自身がその処理方法を知っているという点にあります。そして、その魔法の領域はどんどん小さくなっています。最新のモデルを見れば分かりますが、それは「コンピュータ・ユース（Computer Use）」の領域に入っています。今や、モデルがコンピュータの画面を操作し、テキストを出力するようになっています。
ですから、モデルの周囲にあって、現実世界への触手やセンサーの役割を果たすもの、現実世界と対話するためのツールとしてのハーネスという意味では、その重要性は低くなっていると言えます。目や耳としての役割は依然として必要ですが。
今年が終わる頃には、ハーネスはごくわずかな要素へと解体されていると思いますか。
はい、そう考えています。私たちがAMPで行っていることもまさにそれです。AMP自体、過去の期間において非常に多くの機能を削除してきました。それはモデルがどんどん進化してきたからであり、今後もさらに多くの機能を削除していく予定です。しかし、今年の最大のテーマは、それらのエージェントを「どこで、どのように実行したいか」を突き詰めることにあります。
個々のツールの詳細や、コンテキストウィンドウの70%を消費しているといった細かな話ではなく、人工知能と共に働くことの本質へとシフトしているのです。
それが出意味することは何でしょうか。
生産性の拡大と組織の再定義
たとえば、ある工場を経営していると想像してみてください。人を作業に従事させようとしても、彼らがその仕事のやり方を知らなければ、機械の前に立たせてこの部品をここに組み込むといったことを一つずつ教え、示さなければなりません。それが大きなボトルネックになります。工場内で彼らにどのようにパフォーマンスを発揮してもらうかを模索する必要があります。
では、人間の代わりに、要求されるすべての動作を完璧にこなせるロボットが工場に導入されたと想像してください。あなたが次に考えるべきことは、「手元には無限のロボットがあり、彼らは昼夜を問わず働くことができる。このリソースを活かして、どのようにビジネスを組織化すべきか」「彼らの成果をどのように追跡し、成果を失わないようにするか」ということです。私たちは再び、もう一段高いレベルへとズームアウトしているのです。オーケストレーションのような。
オーケストレーションというよりも、会社を経営していて、業務をサポートしてくれる人材がもっと必要だと感じている時に、誰かが「ここに20人の人間がいます。彼らは非常にスマートで、全員が博士号（PhD）を持っています。優秀であり、あなたが要求することは何でもこなせます」と提示してくれたような状況です。あなたならどうしますか。ビジネスとして20人の優秀な人材を利用できるとしたら、彼らをいつ、どのように配置し、どのように情報を集約するかを考えなければなりません。
それが、解決すべき大きな謎であり、大きな課題なのです。多くのビデオでも語ってきましたが、現在のソフトウェア開発ライフサイクル（SDLC）の多くはかなり時代遅れだと思います。人間が直線的なチケットを書き、それをエージェントに割り当て、エージェントがプルリクエスト（PR）を作成し、別のエージェントがそれをレビューするというアイデアは、狂気の沙汰です。そのような方法が正解だとは思いません。ワークフロー開発全体が、これによって変貌を遂げるはずです。
開発全体、つまりSDLC全体が、人間が操作すること、そして人間がコードを作成することを前提に構築されていますね。
以前のビデオで、数ヶ月前のことですが、「GitHubは死んだ」と言いました。当時は狂気じみて聞こえたかもしれませんが、今ではそれほど突飛には聞こえないはずです。GitHub Nextのマッキー・アップルトンはこれを非常によく理解していますが、製品自体が、人間がそれを使用し、人間が作成したコードは貴重なものであるという前提に立っています。だからこそコントリビューショングラフがあるのです。しかし、2026年にもなって誰がコントリビューショングラフなど気にするでしょうか。プルリクエストに対して絵文字でリアクションする機能がありますが、エージェントに対してそれを行うでしょうか。エージェントが成し遂げた仕事に対して、ハートの絵文字でリアクションを返すなど、そんな時代はもう終わったのです。
タスクを割り当て、アカウントを用意し、ラベルを貼るといったアイデアも不自然です。それは「ペットか家畜か（Pets vs. Cattle）」という議論と同じです。私たちは今、5000頭の牛を飼う牧場を運営しているようなものです。すべての牛に名前をつけるようなことはしません。しかし、人々はエージェントをそのように扱っています。私たちはペットから家畜への移行期にあり、コードは今や家畜のように、安価に大量生産できるものになったのです。
もし社内に5人のインターンがいて、プロトタイプの作成を依頼する場合、5人全員に同じものを作らせて、後から4人の成果物をゴミ箱に捨てるようなことはしません。なぜなら、彼らの感情を傷つけてしまうからです。しかし、エージェントであれば、まさにそのようなアプローチを平気で行うことができます。私たちが使用しているすべてのソフトウェアは、人間が使用することを前提に、人間のために作られています。その前提が今、変わりつつあるのです。
具体的な例を挙げると、CI（継続的インテグレーション）システムがそうです。もちろん、大企業においては様々な事情がありますが、CIも根本的に変わるはずです。現在、エージェントは自らのコードが機能しているかどうかを、テストを実行することによって判断しています。彼らはどのテストを実行すべきかを判断するのが非常に得意ですし、その精度はさらに向上しています。そうなると、どうなるでしょうか。エージェントがどこかでテストを実行し、それを別の場所にプッシュして再びテストを実行し、その処理を待ってからさらに別のエージェントが処理を引き継ぐ、といった従来のプロセスを、なぜ一つのシームレスな処理に圧縮しないのでしょうか。
エージェント自身が実行環境を持っているなら、それがそのままCIの役割を果たせばよいのです。人間がCIを必要とする理由の一つは、テストの実行によって自身の作業がブロックされないようにするためですが、同じ人間のコピーを無数に生成できる環境であれば、一人のエージェントがテストの完了を待つことになっても、何の問題もないのです。ボトルネックの場所がシフトしているのです。
人間のレイヤーであるソフトウェアエンジニアは、これにどのように適応していくのでしょうか。この1年間、彼らはまず新しいツールに触れ始めました。エンタープライズ企業に所属する開発者たちの話をしているのではありません。彼らは現在起きている変化から数年は遅れていると感じます。これは非常に大真面目に言っています。なぜなら、WalmartやAirtel、Deutsche Telekomといった大企業で働く友人たちと話をする機会がありますが、彼らに「Claudeのコード生成が新しい機能をリリースして、これこれができるようになったけれど試したか」と尋ねると、「Claudeのコード生成は名前は聞いたことがあるけれど、これから試すところだ」といった返答が返ってくるからです。
これは2025年の話ではなく、現在の2026年の話です。彼らはまだ「Cloudのサブスクリプションを購入した」「これまではPulserを試していて、かなり気に入っている」という段階にいます。私は、全く異なる性質のオーディエンスが存在していると感じます。ですので、まずはスタートアップコミュニティにおける開発者たちの動きに焦点を当ててみましょう。彼らはこれまでCodeやCodex、Cursor、過去にはWindupなど、あらゆるツールを試してきました。そしてその後、AMPに移行しました。特に私自身、先ほど述べたように昨年の8月か9月頃にAMPに移行しました。そして今年、Piコーディングエージェントが登場しました。これは実質的には昨年から開発されていたものだと思いますが。
これらすべての新しいツールが登場する中で、私たちは誰もが何かを構築しようとしており、それぞれに固有のワークフローや、ツールの扱い方、ガードレールの設定方法、エージェントに与えるスキルの方向性など、独自の習慣を持っています。このように、あらゆる開発者が個別のユニークな方法でこれらのツールやコーディングエージェントを試している中で、このユースケースが、世の中の多くの開発者にとっての「マス（大衆向け）のユースケース」として定着していくプロセスを、あなたはどのように捉えていますか。ユースケースと言うよりは、開発者に提供すべき「ユーザー体験（UX）」のあり方、あるいは開発者が将来的に期待するようなユーザー体験のイメージを、どのように形作ろうとされているのでしょうか。私の問いの意図が伝わっていれば幸いです。
素晴らしい問いですね。
私がこの問いに至ったのは、クインと話し、あなたの文章を読み、マリオとも話をしたときに、皆さんが思い描く未来のイメージが非常に似通っていると感じたからです。もし私があなたの立場に立ち、皆さんと同じように未来を想像しようとするならば、すべての開発者、少なくともマスの開発者にとって最高のユーザー体験となる意思決定を下す際、何がその判断の助けになり、どのようなパラメータが「よし、次の6ヶ月間はこのアプローチを試して、その結果を見てみよう」という決定を導くのだろうか、と考えたのです。
開発者体験（DX）の本質と市場の二極化
私は自分自身の考えしか語ることはできません。製品に関する多くの決定を下してきましたが、AMPにおいて私たちが目指しているのは、ソフトウェアの構築者が人工知能の持つフルパワーを最大限に活用できるようにすることです。それが私たちのミッションです。
1年前も、そして現在も、最も重要なのは「モデルとユーザーの間に余計なものを介在させず、邪魔をしないこと」であり、多くの要素を覆い隠したり、隠蔽しようとしたりしないことです。そうした隠蔽を行えば、最終的には失敗することになります。それが一つの思想です。
もう一つの視点として、AIは信じられないほど奇妙で、稀有で、これまでにない製品だという点です。なぜなら、AI以前の製品においては、製品側がユーザーに対して、自分が何か間違った操作をしているか正しい操作をしているかを明確に伝えてくれていたからです。たとえばWordを使ってドキュメントを作成する場合、探していたドキュメントが開いたかどうかは一目で分かります。「ここをクリックしてファイルを見つけ、それを開き、見出しを大きくした」という一連のフィードバックが視覚的に得られます。しかしAIの問題は、UIが単なるテキストボックスであり、そこにどんな魔法のような願い事を投げ込むこともできる一方で、自分が何をしたか、それが間違っているか否かについての製品フィードバックが完全にゼロであるという点です。
ユーザーはモデルに対して「あなたはOpus 46ですか、それとも47ですか」と尋ね、モデルは適当な返答を返します。「あなたの仕組みはどうなっているのか」と尋ねても、モデル自身が自らを内省する（イントロスペクション）能力を持っていないということを、ユーザーは理解していません。しかし、製品の側からは、あなたが間違った方向に進んでいることを教えてくれるシグナルは何も提供されません。テキストボックスは何も教えてくれないのです。ChatGPTが登場し、人間のフィードバックによる強化学習（RLHF）を経て、どんなタイポ（誤字）があろうとも、単一の単語であれ、クエリであれ、質問であれ、エッセイであれ、チャットボックスに投げ込めば、それなりの答えが返ってくるようになったことは驚異的な出来事です。「ホッキョクグマを隠す」と書けば、モデルは「ホッキョクグマとは〜」と返してくれますし、「ホッキョクグマの大きさを説明して」と書いても、モデルはそれを理解して同じように答えてくれます。
しかし、コーディングにおいては、情報を空中から都合よく引き出すことはできません。あなたが提供しなければならない明確なシグナルが存在します。あなたが何を望んでいるのかというシグナルを提供しない限り、製品の側でできることは何もありません。1年前、人々は「モデルに多くの質問をさせるようにプロンプトを工夫すべきだ」という、あまりスマートではないアイデアを持っていました。私はそれは時間の無駄だと考えています。Q&Aモードや、ユーザーの意図を検出する処理を挟むようなアプローチは、良い結果につながらないと思います。これらの製品の未来がどのような姿になるかは分かりません。
市場の普及（ディフュージョン）という問題もあります。パワーユーザーはこれらのモデルから多大な価値を引き出している一方で、ライトユーザーはそれらがどう機能しているかさえ理解していません。これを解消するには多くのトレーニングや時間が必要になるでしょう。そして、先ほど話した「ソフトウェアの終焉」というテーマにおける最大の掛け算（マルチプライヤー）がここにあります。世界中の異なる専門性レベルや、異なる企業、異なる開発体制におけるポジティブおよびネガティブな価値が、これらのモデルの価値と掛け合わされることになります。それは、一部の企業においては、このテクノロジーが導入されるまでに非常に長い時間がかかる可能性があることを意味しています。
問題は、市場が「その企業の遅れは間違いだった」と判断するかどうか、つまり、その企業が市場から淘汰されるか否かということです。AI懐疑論者たちは「AIがそれほど優れているなら、なぜ目に見える成果が出ないのか」と主張するかもしれません。しかし、現実には成果はすでに現れています。OpenAIやAnthropicは多額の利益を上げており、優れたプロダクトを次々と出荷しています。私たちも彼らと共に多くの優れた価値を出荷していますし、多くのAIネイティブな企業も同様です。もしこれらすべての事実を無視したいのであれば、そもそもその企業を成功させていたのはソフトウェアそのものではなかった、という議論も成り立ちます。成功の要因はソフトウェアを書く「人」にあり、コードを実行したり書いたりする行為そのものにあったわけではない、ということです。私が今、史上最高のMP3プレイヤーを書き上げたとしても、それが優れたビジネスになり、価値を持つわけではありません。そういう意味です。
世界中の企業において、ソフトウェアの扱われ方は一様ではありません。ドイツの製造業の会社におけるソフトウェアチームのあり方と、シリコンバレーのあり方を比較すれば、それは完全に異なります。ですから、そこにAIを投入したときのビジネスへの影響も全く異なるものになります。一方は産業主体の企業であり、もう一方はソフトウェア主体の企業です。その間には様々なグラデーションが存在します。テクノロジーの普及のスピードやその効果は一様ではありません。私が10年前にブログにも書いたことですが、過去20年間、ソフトウェアエンジニアたちは互いに話をするとき、まるで全員が同じ仕事をしているかのように扱ってきましたが、実際は異なります。Googleで働く人物と、ゲームデザイナーやゲームエンジニア、ドイツのWebエージェンシーのWebデベロッパーの仕事は、全く異なるものです。
私たちは誰もがソフトウェアを使用していますが、インターネットが世界の異なる場所にそれぞれ異なる影響を与えたように、AIも同様の軌跡をたどるはずです。将来の製品がどのような姿になるかは分かりませんが、すべてはシグナルに基づいた試行錯誤の連続になるでしょう。システムに情報を提供し、文脈を伝える必要性が消え去ることはありません。「これを作りたい」とだけ伝えて、あとは何も気にしない、というわけにはいかないのです。自分が何を求めているかを理解していながら、それを言語化して表現できないのであれば、経験豊富なエンジニアがあなたから要件を引き出し、問いを投げかけるようなプロセスが必要になります。将来的にはAIがその役割を担うようになるかもしれませんが。
まさにその通りですね。私自身、好奇心から何かを構築しようとする際、実装したい機能のイメージが明確でなく、「おそらくこのようなものだろう」という前提だけで進めようとすると、技術的なアプローチが分からず、結果として当初頭の中で想像していたものとは全く異なるものの開発という、別のラビットホール（深い迷宮）に迷い込んでしまうことがよくあります。だからこそ、「何を構築しようとしているのかが明確であるべきだ」というあなたの発言は非常に強く響きます。オペレーターであるあなた自身が明確なビジョンを持っていなければ、エージェントを主導することはできません。最終的にエージェントは作業をサポートしてくれますが、エージェントに何を期待しているのかを、あなた自身が正確に把握していなければならないのです。
ソフトウェア開発における不変のスキル
その点については、ニュースレターでも書いたことがあります。あなたが何を望んでいるのか、それがどのように機能すべきかという情報は、あなたの頭の中にあるか、コードベースの中にあるか、あるいはモデルのトレーニングデータの中にあるかのいずれかでなければなりません。もしそれがコードベースの中にもトレーニングデータの中にもなく、あなた自身もそれを表現しないのであれば、モデルは何かしらのアウトプットをでっち上げるしかなく、それはあなたが望むものとは異なる結果になるでしょう。私がこれに気づいたのは、ある特殊なランタイム環境の上で動く機能開発に取り組んでいた時のことです。コード自体は通常のコードのように見えましたが、ランタイムの挙動が異なっていました。私自身、そのランタイムが正確にどのように振る舞うかを完全に把握していませんでした。モデルにそのことを伝えていれば、モデルは挙動を理解できたはずですが、誰もその指示を与えなかったため、モデルは情報を捏造してしまいました。その結果、何も機能しない奇妙な状態に陥ってしまったのです。しかし、一度その泥沼から抜け出してみれば、理由がはっきりと分かります。
Next.jsやSvelteKitなどを使って標準的なWebアプリケーションを構築している場合、そこには多くの前提があらかじめ組み込まれています。Webアプリケーションがあり、リクエストがあり、クライアントがあり、レスポンスがある、といった事柄をいちいち説明する必要はありません。しかし、UIインターフェースのあり方さえ明確でないような、真に新規性の高いアプリケーションを構築する場合は、それらを明確に指定する必要があります。標準的なmacOSのUIを求めているのであれば、特に指定しなくてもそれなりのものが得られます。しかし、ユニークなUIを作りたいのであれば、それを言葉で説明しなければなりません。UIと言うと表面的な話に聞こえるかもしれませんが、私が言っているのはドメインロジックやビジネスロジックのことです。それらを何らかの方法でインプットしなければなりません。
そして現在も、それらのビジネス要件を、エンジニアリング可能なタスクや作業の塊へと翻訳するプロセスが必要です。私が長年、シニアエンジニアやスタッフエンジニアとして学んできたことのすべて、つまり「現在の立ち位置を把握し、プロジェクトのゴールを見定め、2週間でこれを達成するために、テストやデバッグ、段階的な構築、あるいは一部の並行処理を組み合わせて、最終的にそれらをどのように統合していくかという道筋を立てる」という営み。これこそが、私にとってのソフトウェアエンジニアリングの本質なのです。Googleの書籍にある『Programming Over Time（時間軸に沿ったプログラミング）』の概念の通り、時間を考慮に入れる必要があります。モデルには時間の概念がありません。物事の要件を見定め、大まかなステップを予見し、どの順番で進めるべきか、どのタイミングで方向転換すべきかを判断する。この営みは現在も、そしてこれからも長い間、必要とされ続けるはずです。私の予測が間違っている可能性もありますが。
モデルが進化し、モデルの進化に伴って多くのハーネスレイヤーが剥がれ落ちているという事実を踏まえて、エージェントにおける評価（Evals）のあり方はこの1年間でどのように変化したでしょうか。2025年当時と比較して、評価の手法も向上しているのでしょうか。
評価（Evals）の現実と「バイブス」
1年前は誰もが「評価が必要だ、評価がすべてだ」と言っていました。それに対して私たちは「評価環境はなく、バイブス（直感や雰囲気）ベースでやっている」と答えていましたが、結果的にそのアプローチは間違っていませんでした。誰もが最終的にはバイブスで判断していたことが分かったからです。
カスタマーサポートの要求やメール対応のエージェントのように、特定の形式の入力が決まっている場合は、評価環境を構築することは比較的容易です。しかし、あらゆるコードベースで動作することが求められるコーディングエージェントを構築する場合、何をもって「正確」とし、何をもって「優れている」とするかを定義することは極めて困難です。
そしてモデル自体がどんどん進化していきました。ですから、評価の微調整だけに何ヶ月も費やすのは、時間を無駄にしているとまでは言いませんが、その間に市場は変化してしまいます。評価をいくら繰り返しても、最終的には「このモデルの方が明らかに優れている」という大まかな結論に至るだけです。
現在、私たちは評価プロセスを取り入れていますが、一日の終わりに最も重要なのは、そのツールを実際に徹底的に使い込むことだと考えています。評価環境は安全網やガードレール、数値を可視化するための仕組みとしては機能しますが、評価シートからは「この説明がこれまでに見た中で最高である」とか「実行ステップ数は増えたが、最終的な解決策の質ははるかに高い」といったニュアンスを汲み取ることはできません。500個の評価ケースが存在する場合、そのすべてを人間の目で詳細にチェックすることは不可能です。これは、自分たちで評価環境を構築した経験から言っています。私はZedで自動補完の機能を開発していたときに評価の重要性に魅了されましたし、評価環境なしにはそれを成し遂げることはできませんでした。しかし、タブ補完の開発と、あらゆるコードベースでツールを駆使して動作するコーディングエージェントの開発とでは、その性質が全く異なります。これらは完全に別物なのです。
少し軽めの質問をさせてください。これまでコードに関する硬い話をたくさんしてきました。
あなたはニュースレターの中で、非常に多くのコンテンツを消費していることに言及されています。どのような体験をされているのでしょうか。私が個人的に気になっているのは、それほど多くのものを読む時間を一体どうやって確保しているのかという点です。私は読む時間の管理に非常に苦労しており、フォローしているニュースレターはせいぜい2、3個です。技術的には多くのものをフォローしていますが、真に専念して読んでいるのは2、3個に過ぎません。技術的な内容だけでなく、最近のニュースレターでは哲学関連のトピックやその他の書籍など、コアなテック以外のコンテンツについても語られていますね。どのようにして時間をマネジメントしているのですか。
時間管理と「ビルドモード」の日常
まず、ニュースレターを見ると大量に消費しているように見えるかもしれませんが、その中にはYouTubeの動画やポッドキャスト、いくつかのツイートなども含まれています。純粋な長文のブログ記事は全体の50%ほど、あるいは一号あたり6、7個のブログ記事を1週間かけて読んでいるだけですので、それほど現実離れした量ではありません。
私はビデオゲームもやりませんし、他の趣味も多くありません。ただ読むようにしています。ただ、最近は「ニュースレターのために読まなければならない」というプレッシャーがあり、純粋な書籍を読む時間が大幅に減ってしまっているのが課題です。
たとえば先日は、夕食を食べながらマッキー・アップルトンのブログ記事を1つ読みました。昼休みに3つ、4つ、5つほどのコンテンツに目を通す習慣を数日間続けるといった形です。秘訣は、対象を厳選すること、そして読んでみて面白くない、関心がないと感じたら途中で読むのをやめることです。
私はそれを最優先事項にしていますし、量としてもそれほど多くはないと思っています。読む量が多い週もありますが、たとえば今日は木曜日ですが、これからの2時間をソファに横になって3つの記事を読むことに費やすかもしれません。そして、そのうちの1つか2つがニュースレターに掲載されることになります。
平日の典型的な1日のスケジュールはどのようなものですか。
最近はかなりハードに働いていますが、基本的には朝5時45分に起きます。コーヒーを淹れて、6時10分頃には作業を開始します。
そこで1時間ほど働いた後、家族で朝食をとり、子供を学校へ送り届けます。その後、ジムへ行き、9回から夜7時頃まで、昼休みを挟みながら仕事をします。
大体そのようなスケジュールです。朝にジムへ行き、その後はひたすら働き、本を読みます。テレビのドラマをイッキ見することもありませんし、映画もそれほど見なくなりました。ワークアウトをして、たくさん働き、本を読む。それが日常です。
私自身もあまり読書に多くの時間を割けないため、タイムマネジメントには苦労しています。自分自身で何かを構築している「ビルドモード（開発集中モード）」にあるときは、なおさら時間がありません。あなたたちも近々何か大きな発表を控えているとお聞きしていますが、そのようなビルドモードにあるときは、家族、健康、食事といった最低限のチェックマーク以外のすべての優先順位が下がってしまいますよね。
まさにその通りだと思います。
もっと多くの質問をしたいのですが、時間も限られているため、このあたりで最後の質問にしたいと思います。録音を止めた後に少し雑談できれば幸いです。
最後の質問ですが、このエージェントによるコーディングという絶え間なく進化するフェーズにおいて、あなたたちは常に「次の大きな変化」を追い求めています。私個人の意見として、この進化が今後5、6年にわたり続くとするならば、あなたたちは今後も既存の仕組みを破壊し、ゼロから作り直すことを選び続けますか。あるいは、「ここをベースラインとして、今後はこの上に積み上げていく」という安定の道を選びますか。技術的な好奇心からの質問ですが、ユーザーとしては、あるツールが一定の基本部分を維持しつつ、機能の追加や削除を模索していくことを期待する側面もあります。AMPは今後もその安定のレールを進むのか、それとも現在の思想に基づき、今後も完全に急進的な破壊と創造の道を突き進むのでしょうか。
破壊と創造、そしてフロンティアに立ち続けること
予測に過ぎませんが、私たちは今後も既存の仕組みを破壊し続けるでしょう。そうしなければなりません。私たちはフロンティア（最前線）に立ち続けなければならないのです。
立ち止まって安定を選択することができない理由は、過去30年間のソフトウェア業界における標準的なプレイブックが、「いくつかの試みを重ね、プロダクトマーケットフィット（PMF）を見つけ、機能するものを確立し、営業人員を雇って会社を拡大していく」というものであったのに対し、現在の状況は全く異なるからです。それが長年の定石でしたが、現在の問題は、ソフトウェアにおけるほぼすべての前提が、これらのモデルの進化によって3ヶ月ごとに根底から覆されている（ラグプルされている）という点にあります。
かつてのプレイブックを適用しようとすることは、次のような状況に似ています。ある優れたソフトウェアがあり、その3ヶ月後にパーソナルコンピュータが登場し、その3ヶ月後にインターネットが登場し、さらに3ヶ月後に携帯電話が登場する。そのような激動の時代に、メインフレーム向けの優れたソフトウェアがあるからといって、そこに立ち止まってビジネスを維持することは可能かもしれませんが、それでは一体どのような顧客を惹きつけることになるでしょうか。携帯電話の未来へ向かう人々を惹きつけたいですか、それともメインフレームに留まり続ける人々を惹きつけたいですか。
それは単なる顧客の数の問題（皆がモバイルに向かっているという賭け）だけでなく、どのようなマインドを持った人々を引き寄せるかという問題でもあります。安定を重視する顧客を引き寄せると、彼らによって自身の足が縛られることになります。半年後に「皆がモバイルに移行したのに、自分はまだメインフレームのビジネスに縛られている」と気づいたとき、手元に残るのは、あなたに「モバイルへ移行しないでくれ」と対価を支払う顧客だけです。そうなれば身動きが取れなくなります。
だからこそ、AMPにおいて私たちは「現在の場所に留まることではなく、私たちと共にフロンティアへ進むことを望むユーザー」を対象にしたいと考えています。
奇妙なことに、人々は私たちの足を縛るような要望を頻繁に伝えてきます。昨年であれば、「PRD（製品要求仕様書）ベースのワークフローを構築してほしい」「サブエージェントを第一級の機能として組み込んでほしい」といった要望がありました。しかし現在、そうしたアプローチを語る人は誰もいません。そうした仕様書ありきのロジックを律儀に提供している会社もありますが、それは今やスマートなアプローチとは言えません。そうした機能を維持しようとすれば、特定の顧客層は維持できても、次の破壊的な変化を起こすことができなくなり、ユーザーからの不満に直面することになります。私たちは自動補完（オートコンプリート）の機能を削除しました。AMPにおいて自動補完は未来のあり方ではないと判断し、それを廃止したのです。一部のユーザーは激怒しましたが、他の多くのユーザーは「完全に筋が通っている。確かにそれが未来ではない」と理解してくれました。
つまり、誰を顧客にしたいのか、という問いに帰着します。これほど巨大な技術的変化が起きている時代において、列車に乗り遅れ、置き去りにされるリスクがある中で、変化に追いつき続けなければなりません。「ここに座って、快適で居心地の良い生活を送りながら、変化の列車を無視する」という選択肢は存在しません。メインフレームのソフトウェアを作って優れたビジネスを維持できるような時代ではないのです。ビジネスの主戦場は別の場所へと移っています。それがテクノロジーの力学です。ですから、追いつき続けなければなりません。そして、追いつき続けることを原則とするならば、あなたの足を引っ張る顧客と、あなたと共に進んでくれる顧客のどちらを望むか、ということです。
クインも同じようなことを言っていましたか。
彼はこれほど詳細には語りませんでしたが、根本的には同じ方向性でした。これは具体的な手法というよりも、原則やイデオロギーの問題だと思います。彼も同じイデオロギーを持っており、私たちは今後も破壊と構築を繰り返していくというスタンスです。ただ、彼が言及していたもう一つの視点として、たとえばある会社に100人の開発者がいるとして、私たちはその100人全員のためにツールを作っているわけではない、という点があります。私たちは、このソフトウェアの価値を真に理解してくれる、コアな10人のために構築しているのだと。あなたもまさにその点に言及されていましたね。
面白いことに、その進化の軌跡は今後も続いていくように見えます。私たちは未来を正確に予測することはできません。しかし、もし2000年や2004年に、誰かがあなたに「これからiPadやiPhoneが登場する」と予言していたら、あなたはデスクトップコンピュータのビジネスに全精力を注ぎ続けたでしょうか、それともiPhoneの到来に備えたでしょうか。
デスクトップのビジネスも依然として優れたビジネスであり続けたでしょうが、私たちが知っているのは「モデルは確実に進化している」ということです。私たちはその事実を信頼しています。だからこそ、私たちはその進化の傾きの上にいるのだと確信し、未来を少しだけ覗き見ることができるのです。問題は、その曲線のどの位置を目指して製品を構築するかということです。
昨日、Twitter（X）で誰かが言及していましたが、多くの人々は、ローカルモデルやオープンソースモデルの文脈で様々な連携機能を構築しようとしていますが、それらは最先端のフロンティアモデルではうまく機能しません。もし私がローカルモデルへの対応だけに特化しているわけでなく、現にフロンティアモデルがここに存在しているのなら、なぜすでに過去のものとなりつつある地点を目指して開発を行わなければならないのでしょうか。私たちは技術的変革の真っ只中にいます。「追いつき続けなければならない」という原則に立つならば、フロンティアが遥か先にあるのに、なぜ5ステップも後ろの地点を目指す必要があるのでしょうか。目指すべきは常にフロンティアそのものです。
その言葉が、今回の会話のすべて、そして特に最後の質問の答えから得られた最大の収穫を要約していると思います。未来を構築したいのであれば、次に来るものへの強い信念を持ち、構築を続けながら、何が残り、何が剥がれ落ちていくかを見極めなければならない。
そしてそれを何度も繰り返す。それこそが、あらゆる分野において未来を構築していくプロセスそのものだと思います。開発者やソフトウェア業界においても同様です。エンドユーザーであるすべての開発者、そして一日の終わりにエンジニアリングの本質を大切にしている人々のために、このような情熱を持って取り組んでくれている方々がいることを本当に嬉しく思います。彼らを代表して、そして今日多くの深い洞察を共有してくれたことに感謝します。あなたをより深く知りたい人は、あなたのニュースレターを読めば、彼が技術的にどのようなスタンスで語っているのかを完全に理解できるはずです。
ありがとうございます。
私自身、多くのことを学びましたし、まだ他にもたくさんの質問がありますので、また別の機会に、異なるセッティングでお話しできれば幸いです。
ありがとうございました。こちらこそ、お会いできて光栄でした。本当にありがとうございます。
コメント