Codex責任者がOpenAI内部開発を暴露:毎週再構築!Codexはチームメイト化、徹夜稼働・自己テスト可能に!新人へのアドバイス:基礎は永遠に時代遅れにならない;Windows版リリース予定

画像

画像

編集|雲昭

「将来的には、Agentのためにソフトウェアを構築することになるかもしれません。そのとき、Agentはプロダクトマネージャーやプロダクトエンジニアになる可能性があります。」

昨日、OpenAI Codexのエンジニアリング責任者Tibo Sottiaux氏とOpenAIアプリケーションCTOのVijaye Raji氏がPragmatic Summitにゲスト出演し、OpenAI内部のエンジニアの生の実感と経験を共有しました。

2025年を振り返り、Tibo氏はその変化の度合いを「衝撃的」と表現しました。

わずか最近の6か月だけを見ても、私たちは『Codexをツールとして扱う』状態から『拡張として扱う』、さらには『Agentとして扱う』へと進化し、今では『チームメイトとして扱う』段階に達しています。

あるエンジニアは、複数のAgentを実行するために週に数千億ものトークンを消費するほどです。

Codexの能力がますます強くなるにつれ、ソフトウェア開発におけるボトルネックは、週単位で変化しています。

以前のボトルネックはコード生成でしたが、その後はコードレビューになり、現在はもっと多くが、どうやってユーザーのニーズをより速く理解するか?どうやってissueを処理するか?どうやってTwitterやRedditなどの重要なプラットフォームでのフィードバックを追跡し、その情報を統合して製品戦略とするか?という点にシフトしています。

Tibo氏はさらに、OpenAI内部の一部のエンジニアが週に消費するトークン数が数千億の規模に達していると暴露しました。しかもこれは単一のAgentではありません。

また、内部には一般に比べてより「SF的」な開発ツール、Codex Boxが存在します。

先週、私たちはCodex Boxを内部リリースしました。これを使うと、サーバー上に開発環境を予約し、直接promptを送って作業させることができます。あなたはノートパソコンでフローを設計し、それがクラウド上でタスクを実行します。多くの人がパソコンを閉じて会議に行き、帰ってくると作業が完了しています。

また例えば、CodexチームがCodexについて話し合うとき、会議室で直接Codexスレッドを起動して問題の診断や分析の振り返りを行うこともあります。

未来について、ソフトウェア開発業界がどのように変化するかについて、Tibo氏とRaji氏はいくつかの方向性を示しました。

まず、開発のスピードはさらに一桁向上する可能性があり、これが新たな変化をもたらすでしょう。

次に、OpenAIは大規模なマルチエージェントコラボレーションネットワークを実際に実現させ、非常に大きな目標に向かって協調動作させることになります。

第三に、次に構築されるシステムに対して防護策を設けます。開発者はコードを一行一行見る必要がなくなり、何らかの方法でその正確性を検証したり、制約を通じて安全性を確保したりするようになります。コード自体は抽象化され、真の焦点は問題自体と、システムが備えるべき性質に向かうでしょう。

第四に、Raji氏は言います。「おそらく今年中にも、開発者は自分自身のために、一、二百もの小さなAgentの状態をチェックしてくれる『個人的な代表型アシスタント』を持つことになるでしょう。これはバックグラウンドであなたのために効率的に働くすべてのAIエージェントを代表して要約してくれます。あなたは監視したり一つ一つ確認する必要はなくなります。(※これは昨日筆者が報じた前GitHub CEOが手がけるEntireに少し似ています!)」

また、司会者は、OpenAIがプロダクト型エンジニアを採用する傾向があると暴露しました。Raji氏は説明します。「製品の直感は依然として重要です。結局のところ、本質的に製品は人のために構築されるものだからです。」

AI時代にソフトウェア業界に携わりたい新人にとって、Tibo氏とRaji氏は「基礎的な能力は永遠に時代遅れになりません!」と述べました。OpenAIはCodexに目を閉じて完全に依存するわけではありません。

しっかりとした基礎があり、製品への直感があり、自分が何を構築しているかを理解し、技術スタックの上流・下流を自由に行き来して問題を解決できる能力こそが重要です。そしてこれは決して時代遅れにはなりません。

「私たちがここに座っていられるのは、しっかりとした基礎があるからです。しかし、ソフトウェアエンジニアの役割は、確かに大きく変化しました!」

最後に、一言付け加えます。数時間前、Tibo氏はさらに重大なニュースを発表しました。CodexはWindows版の招待制テストを開始しました。

これは間違いなく、OpenAIが企業向け開発者領域でさらに力を入れていることを意味します。

画像

以下は、編集者が皆様のために整理したCodexチーム版の「プログラマー進化物語」です。

OpenAI内部開発で起きていること:

Codexはすでにチームメイトへと進化

一部のエンジニアは週間トークン消費量が数千億の規模に

司会者:多くの人が疑問に思っている問題があります。OpenAIでは今、内部でいったい何が起こっているのでしょうか? もっと具体的に言うと、ソフトウェア開発の観点から見て、エンジニアの働き方はどう変わったのでしょうか?

Raji:良い質問です。確かにたくさんの変化がありました。私はOpenAIに約6か月いますが、最も深く感じたことの一つは、社内の研究能力があまりにも強力だということです。ほんの少し未来の可能性を投影してみるだけで、衝撃を受けます。

まずソフトウェア開発の方法について。Codexは私たちのコードの書き方を完全に変えました。変化は非常に激しいものです。わずか最近の6か月だけを見ても、私たちは『Codexをツールとして扱う』状態から『拡張として扱う』、さらには『Agentとして扱う』へと進化し、今では『チームメイトとして扱う』段階に達しています。私はエンジニアがすぐに自分のAgentに名前をつけて、本当のパートナーとして扱い始めることさえあると思います。この変化は非常に速く起こっています。

私は内部のランキングを見ましたが、一部のエンジニアは週に消費するトークン数が数千億の規模に達しています。しかもこれは単一のAgentではありません。先週、私たちはCodex Boxを内部リリースしました。これを使うと、サーバー上に開発環境を予約し、直接promptを送って作業させることができます。あなたはノートパソコンでフローを設計し、それがクラウド上でタスクを実行します。多くの人がパソコンを閉じて会議に行き、帰ってくると作業が完了しています。

これが現在のOpenAI内部でのソフトウェア開発方法です。それは根本的に変わりました。私は数か月以内に、シリコンバレーの中心部でこれが普及し始め、その後広がっていくと確信しています。今後、誰もがこの方法でソフトウェアを開発するようになるでしょう。

司会者:もし私が6か月前、あるいは一年前に戻って、あなたの話を聞いたら、おとぎ話を聞いていると思うかもしれません。しかし今は違います。多くの人が使っています。私自身も使っています。OpenAIのエンジニアとも話しました。私はエンジニアと話すのが好きです。彼らはほとんど「メディアトレーニング」を受けていないので、とても率直に話すからです。

少し安心したのは、すべてのエンジニアが100% Codexを使ってコードを書いているわけではないということです。みんなたくさん使っていますが、レベルは異なります。あるチームは確かに最先端を行っています。それがCodexチームです。

Tibo、あなたはCodexチームを率いていますね。今、あなたたちが毎日どのように仕事をしているのか、エンジニアの典型的なワークフローはどんなものか、話してもらえますか?

Codexチームの働き方は毎週急速に変化

Tibo:状況は非常に速く変化しています。Codexチームには面白い特徴があります。私たちはほぼ毎週、自分の働き方を再構築しています。

私たちは常にボトルネックを特定しますが、ボトルネックは常に移り変わります。以前のボトルネックはコード生成でしたが、その後はコードレビューになり、現在はもっと多くが、どうやってユーザーのニーズをより速く理解するか?どうやってissueを処理するか?どうやってTwitterやRedditなどの重要なプラットフォームでのフィードバックを追跡し、その情報を統合して製品戦略とするか?という点にシフトしています。

みんなAgentを最大限に活用してこれらのことをやろうと試みています。

数日前に面白い場面がありました。ある人がCodexチームに参加したいと言って、私に尋ねました。「OpenAIでプロダクト開発をする場合、私はどれだけのコンピューティングパワーを割り当ててもらえますか?」

この質問は新鮮でした。確かに私たちは多くのコンピューティングパワーを持っていますが、私は「従業員一人当たりのコンピューティングパワー割当」について考えたことはありませんでした。通常、コンピューティングパワーは大規模モデルを訓練する研究者に多く割り当てられます。

現在、人々は気づき始めています。コンピューティングパワーを使って自分の能力を何倍にも増幅できるということに。もし優れたセンス、優れたアイデア、ソフトウェア開発の知識があれば、この時代は本当に刺激的です。あなたができることはとても驚くべきものになるでしょう。

Agentはプロダクトエンジニアになる

司会者:よりマクロな視点から見ると、OpenAIは常に「プロダクト型エンジニア」を採用してきました。現在、彼らの仕事はどう変化しているのでしょうか?

Raji:本質的に、私たちはまだ人間のためにプロダクトを構築しています。製品への直感は依然として重要です。私は最近、新版のCodexデスクトップアプリを使っていますが、それはコードを書くことをより容易にします。しかし、プロダクト開発は依然として「私たちは何を構築するのか」から始まり、繰り返し改善され続けます。

私たちが人間のためにソフトウェアを作る限り、これは変わりません。

もちろん、将来的には、Agentのためにソフトウェアを構築することになるかもしれません。そのとき、Agentはプロダクトマネージャーやプロダクトエンジニアになる可能性があります。

しかし現在は、ペースがより速く、より面白くなっています。ソフトウェアの構築はより楽しいものになりました。なぜならフィードバックサイクルが大幅に短縮されたからです。

私は一度、飛行機でコードを書いていました。その時はリモートdev boxを使えませんでした。客室乗務員がパソコンを閉めるように言っても、私は惜しくてAgentを止めたくなかったので、パソコンを半ば閉じたままにしていました(笑)。今、多くの人が仕事を実行させるためにパソコンを半分閉じたままにしています。

正直に言うと、今のソフトウェア開発は以前よりずっと楽しいです。すぐに成果を見ることができ、テストし、検証し、またCodexに戻って調整することができます。

新しいエンジニアリング実践:

ソリューションの並列探索、デザイナーがコードを書く;コードレビューがボトルネックに

司会者:エンジニアリング実践の面で、新しい、奇妙だが理にかなった変化はありますか?

Tibo:以前は複雑な技術的トレードオフに遭遇すると、私たちは設計文書を書き、さまざまなソリューションについて議論し、一つを選んでいました。

今、面白いのは、人々が複数の実装ソリューションを並行して探索し、実験データを通じて最適解を選び出すようになっている点です。

もう一つの変化は、役割の境界が曖昧になっていることです。デザイナーが今書いているコードは、半年前のエンジニアが書いていたコードよりも多いかもしれません。これはモデルが十分に優れていて、生成されたコードの品質がそのままマージできるレベルになったからです。

司会者:他の観察はありますか?

Raji:あります。例えばコマンドラインツール。ffmpegのようなツールは、完全なコマンドを覚えている人はほとんどいません。今ではCodexを使うと、あなたは単に「これをしたい」と言えば、それに応じてコマンドを生成して実行してくれます。

私たちは単に「コードを書く」ことから、「コードレビュー」「セキュリティレビュー」へと領域を拡大しました。

コーディング効率が5倍に向上すると、何が起こるでしょうか?コード量が急増し、コードレビューがボトルネックになります。その後は、継続的インテグレーション・デプロイメント(CI/CD)が新たなボトルネックになります。

ボトルネックは絶えず移り変わっています。この革命はまだ終わっていません。

Tibo:だからこそ、私たちは絶えず次の問題を解決し続けなければなりません。これは実は非常にエキサイティングなことです。

司会者:Tibo、私たちは以前、「徹夜稼働」と「自己テスト」という私が聞いたことのない手法について話しました。これについて話してもらえますか?これはとても新しいように聞こえます。

Codexの徹夜稼働と自己テスト

Tibo:Codexを「スーパーなオートコンプリート」として理解するのは簡単です。小さな機能を実装するのを助けてくれるだけで、10分で終わると思いがちです。

しかし、私たちが見ているのは、モデルに十分大きなタスクを与えれば、その能力はそれだけにとどまらないということです。それは連続して数時間稼働することができます。

私たちはCodexが完全に自律的に自分自身をテストできるよう、完全な環境と能力を構築しました。私たちは夜間に実行し、QAをループ実行させ、自動的にリグレッション問題を検出させます。

もう一つ面白いことがあります。私はよく、モデルトレーニングを担当するチームの研究者と話をします。彼がCodexより自分が優れていると思った時はいつでも、最終的には自分のpromptの書き方が悪かったか、環境の設定が間違っていたことに気づく、と言っています。

これはエキサイティングであると同時に、少し打撃でもあります(笑)。

今では、モデルは一回の完全なモデルトレーニングを独立して完了し、最後に独自の洞察を盛り込んだPDFレポートを書くことさえできます。私たちはその中から最も有望な方向性を選び、さらに繰り返し、またCodexに戻すのです。

このような超長時間のタスク実行と、モデルが複雑な作業を独立して完了する能力は、見ていて本当に圧倒されます。

会議でCodexを「召喚する」2つのシナリオ:

振り返りと障害対応

司会者:もう一つとてもSF的なシナリオがあります。CodexチームがCodexについて話し合う会議で、直接会議室でCodexスレッドを起動して問題を診断する、とあなたは言いましたね。これは自己循環のように聞こえます。これについて話してもらえますか?

Tibo:私たちには2つの典型的なシナリオがあります。

第一は、毎週の分析振り返り会議です。私たちは機能の採用率、定着率、コンバージョンファネルを見ます。会議が始まると、いつもダッシュボードには表示されない問題が参加者にあります。

データアナリストは言います。「よし、バックグラウンドでCodexスレッドを一つ開こう、20分で答えを出してもらう。」

会議の最後の10分で、私たちはこれらの新しい結果について議論することができます。一つの会議の中で五つか六つの質問を実行することができます。まるでバックグラウンドで私たちのために働く一群の目に見えない顧問がいるような感じです。

第二のシナリオは、オンライン障害対応です。Codexは問題の原因分析と、最も速い回復経路を見つけるのを助けてくれます。情報収集と問題解決の速度が大幅に向上します。

新卒・ジュニアエンジニアについて

司会者:業界内で繰り返される問題の一つは、新卒やジュニアエンジニアはどうなるのか?ということです。OpenAIのエンジニアリング責任者が、あなたたちが多数の若手エンジニアを採用していると言っているのを聞きました。状況はどうですか?

Raji:私たちは確かに多くの新卒を採用しています。今年は規模の大きいインターンシッププログラムもあります。

私は、次世代のソフトウェアエンジニアは「AIネイティブ」になるだろうと信じています。彼らは自然にこれらのツールに精通し、初日からAIを使えるようになるでしょう。彼らにそのような環境を与えることが極めて重要です。

今年の夏、私たちは初めての大規模な新卒、約100人を迎えます。彼らのパフォーマンスを見るのがとても楽しみです。インターンシッププログラムも拡大し続けるでしょう。

これはとても面白い時代です。

Codexチームはどのように新人を育成するか?

フラットな管理、Codexが最初のメンター

司会者:Tibo、あなたのチーム自体が社内の他のチームよりも数歩先を行っています。新人が参加する時、どうやって素早く順応させるのですか?

Tibo:私のチーム構造は非常にフラットです。私は33人の直接の報告者を持っています。私はボトルネックになりたくありません。

もし一人の人間がすべての決定に参加しなければならないとしたら、その構造は現在のこのスピードでは成り立ちません。

新人が入社すると、最初の「メンター」は実はCodex自体です。あなたは直接それに質問し、それを使ってコードベースを閲覧し、プロジェクトを理解し、日報を受け取ります。

一方、本当のonboardingや文化構築を担当するのは、多くの場合、最近入社した人たちです。

新卒について言うと、私は6か月前に非常に優秀な新人を採用しました。彼は極めて優れたパフォーマンスを示しています。最初は私は少し驚きました。しかしその後、彼には無限のエネルギーと非常に速い学習能力があることに気づきました。

正直に言うと、私の脳はすでに下降傾向にあるかもしれませんが、彼の脳はピークにあります(笑)。彼がチームで達成している成功は、私をとても幸せにしてくれます。

新人へのアドバイス:基礎は永遠に時代遅れにならない

司会者:「反対意見を述べる」という視点から見ると、過去には多くの新卒が優れたエンジニアに成長したのは、しっかりとした基礎を築いたからでした。

現在、もし新人が最初からAIに大きく依存し、私たちが過去10年から20年にかけて経験した訓練プロセスを飛び越えてしまったら、基礎が不足してしまうのではないでしょうか?

Tibo:基礎は依然として非常に重要です。

私たちはコードベース全体のアーキテクチャ設計と、コードレビューを非常に重視しています。私たちは目を閉じて完全にCodexに依存するわけではありません。トップクラスのエンジニアがチェックしています。

コード構造が適切に設計され、防護策が設定されていれば、新人は極めて効率的になります。重要なのは、あなたがどのような環境を構築するか、そして事前にコードベースが将来どのように進化していくかを考えることです。

ソフトウェアエンジニアの役割は変わった

司会者:もし今新人が「Rajiさん、私は具体的に毎日何をすればいいですか?」と尋ねたとしたら、ソフトウェアエンジニアの日常業務は6~8か月前と比べてどう変わったのでしょうか?

Raji:基礎は決して時代遅れになりません。私たちがここに座っていられるのは、しっかりとした基礎があるからです。しかし、ソフトウェアエンジニアの役割は、確かに大きく変化しました。

私は年齢を暴露するかもしれませんが、この業界で25年、あまりにも多くのパラダイムシフトを見てきました。私は以前Microsoftで開発者ツールに携わり、Visual Studioのエディターと言語サービスを書きました。IntelliSenseを初めて見たとき、それは本当にカッコいい感じでした――点を一つ打つと、すべてのオプションが自動的にポップアップするのです。

司会者:当時私は入ったばかりで、周りの開発者は「IntelliSenseを使うのは本物のプログラマーではない」と言っていましたね。

Raji:そうですね(笑)。さらにさかのぼると、アセンブリを書かないのは良いエンジニアではないと思っていた人もいたかもしれません。その後はC++、そして抽象度はどんどん高くなりました。JavaScriptをみんなが文句を言っていた時代を覚えていますか?

これらの議論は実は重要ではありません。しっかりとした基礎があり、製品への直感があり、自分が何を構築しているかを理解し、技術スタックの上流・下流を自由に行き来して問題を解決できる能力こそが重要です。そしてこれは決して時代遅れにはなりません。

プロダクトマネージャー、デザイナー:皆コードを書いている

設計を検証済みのプロトタイプまで直接進める

司会者:私たちは主にエンジニアについて話してきました。では、プロダクトマネージャーとデザイナーはどうでしょうか?エンジニアも彼らも機能をより速く構築できるようになったとき、彼らの役割はどう変わるでしょうか?ますます似てくるでしょうか?

Raji:私たちが人間のためにプロダクトを構築する限り、人間のデザイナーとプロダクトマネージャーが必要です。プロダクト感覚とデザイン感覚に簡単な代替品はありません。

もちろん、彼らも進化し、ますます効率的になっています。プロダクトマネージャーはコードを書き、デザイナーもコードを書いています。彼らはデザインを直接プロトタイプ段階まで進め、検証した後でエンジニアに渡します。

プロダクトマネージャーも、Codexを使ってPowerPointを作ったり、Excelアドインを書いたりしています。効率の向上はエンジニアだけでなく、組織全体で起こっています。

内部での知識共有と「Show & Tell」

司会者:あなたたちは内部で多くの知識共有、例えばshow and tellを行っていますね。どうやって考えついたのですか?仕組みは?面白い事例はありますか?

Tibo:私たちは実際、テクノロジーを発見しながら、それとともに進化しているのです。

外部と同様に、私たちも探求しています。AIは組織に何ができるのか?プロジェクトにとって何を意味するのか?効果がありそうな方向性が一つ見つかれば、私たちはできるだけ早く世界にリリースします。

ですから、私たちが本当に「未来を少し多く見る」ことができる時間枠は非常に短いのです。

このような環境では、良いアイデアは組織内で素早く広がらなければなりません。私たちには活発なSlackチャンネルがあります。例えばCodexチャンネルやhot tipsチャンネルです。また、定期的にハッカソンやshow and tellを開催します。

これは非常に創造的な段階であり、唯一正しい使い方はなく、すべてが探求中です。

私たちのCodexチームには、一人の非常に優れたプロダクトマネージャー、Alexander Emberos氏がいます。彼はチーム全体で唯一のプロダクトマネージャーですが、自分自身を「超拡大」させています。

数日前、彼はbug bashを主催しました。一時間でみんなが間もなくリリースされる機能を体験します。彼はCodexにフィードバックを収集させ、Notionドキュメントを生成させ、さらにCodexにLinearへのバグや機能改善タスクを作成させ、関連する責任者に割り当て、自動的に進捗を追跡させました。

彼はAIを使って自分を10倍、いや50倍効率的なプロジェクトマネージャーに変えました。

しかし重要なのは、プロダクトマネージャーを新たなボトルネックにしてはならないということです。組織構造もそれに合わせて調整されなければなりません。

Raji:一点追加します。最近のdemo dayやハッカソンで、私は一つの傾向に気づきました。発表されるプロジェクトの深さがますます高くなっています。

以前は「この能力はこれができる」というデモだけだったかもしれません。今では多くのデモが大量のエッジケースを処理し、ほとんどそのまま使える製品になっています。全体的な深さが持続的に向上しています。

トークンコスト問題

司会者:現実として言わなければならないのは、OpenAI内部では無限のトークンがあるということです。外部世界ではコストが依然として問題です。サブスクリプション枠を使い果たすと追加料金を払わなければなりません。多くのチームが予算に制限されています。

もし他の人がコスト制約を受けているなら、何かアドバイスはありますか?

Raji:コストは私たちが継続的に考える問題です。私たちはモデルをより強力にしたいし、ユーザーにも提供したいと考えています。

しかし、考え方も変える必要があります。あなたが今持っているのは、24時間365日稼働するチームメイトです。LinearやJiraのタスクを割り当てることができ、そしてそれが完了することを期待すべきです。

問題はもう「どれだけのトークンを使ったか」ではなく、「このチームメイトにいくら払うか」ということになります。

もし各エンジニアが4、5人のそのような「チームメイト」を持っているなら、生産性の観点から見るとより合理的になります。

もちろん、私たちはこれらのAgentが十分に強力で、「チームメイト」と呼ぶにふさわしいものにする必要があります。

Tibo:会社全体のコスト構造から見ることもできます。例えば市場調査、機能のバックログリストの分析、どのタスクが実現しやすいかのスクリーニング――これは以前なら15人のエンジニアが必要だったかもしれませんが、今ではほとんど無料でできます。

すべての会社が社員に無限の推論枠を提供できるわけではありません。しかし、早すぎる厳しい制限も一種のリスクです。

私たちはまだ非常に初期段階にあり、多くの人はまだ自分自身を拡大する方法を本当に学んでいません。

私のアドバイスは、十分な推論枠を会社で最も優秀な人に優先的に割り当てることです。彼らに十分に探求させてください。

変化の速度

司会者:変化は本当に速いですね。過去25年を振り返って、似たような瞬間はありましたか?

Raji:私はこんな変化を見たことがありません。

私はインターネットバブル崩壊、Y2K、モバイル革命を経験し、ソーシャルネットワークの波にも参加しました。しかし今回は全く違います。

Raji:この波の変化は巨大な規模で起こっており、そしてその速度は極めて速いです。あまりにも速く、一部のグラフはもうほとんど説明がつかなくなっています。ですから、私は確かに、これは非常に特別で、非常にユニークな時期だと思います。このような時代に生きられること自体、とてもクールです。

次に、「エージェント」の上でさらに抽象化が進みます。

エンジニアはコードを気にせず、入力と出力に集中する

司会者:最後の質問として、変化は非常に速いですが、お二人はOpenAIで相当な期間働いていますね。正直な予測をしてもらいたいと思います。2年後、ソフトウェアエンジニアリングはどのようになっているでしょうか?エンジニアリングマネジメントはどうなっているでしょうか?あなた方が現在知っていることに基づいて。

Raji:明らかに、2年という時間軸はあまりにも長いです。

6か月後のことさえ言うのが難しいと思います。しかし、いくつか確信を持てることがあります。第一に、私たちの速度はさらに一桁向上する可能性があり、これが新たな変化をもたらすでしょう。第二に、私たちは大規模なマルチエージェントコラボレーションネットワークを実際に実現させ、非常に大きな目標に向かって協調動作させることになります。

例えば、Cursorで示された能力に基づけば、「ブラウザをゼロから再構築せよ」と一言言うだけで、24時間後には完成品が手に入るというシナリオは十分想像できます。それは200万行のコードからなるシステムで、その内部詳細を人間が完全に理解するのはほとんど不可能な規模になるでしょう。

私は次に私たちが行うことは、構築されたシステムに対して「防護策」を設けることだと思います。そうすれば、コードを一行一行見る必要がなくなり、何らかの方法でその正確性を検証したり、制約を通じて安全性を確保したりできるようになります。あなたは入力と出力だけに集中すればよいのです。コード自体は抽象化され、真の焦点は問題自体と、システムが備えるべき性質に向かうでしょう。

ソフトウェアの発展史は、本質的に抽象度が絶えず上昇する歴史です。抽象化は、より少ないコードでより大きなプロダクトを構築することを可能にします。長年にわたり抽象度は上昇し続け、今、私たちは抽象化が加速的に躍進する段階にいます。

しかし、私は少し懸念もあります。どんなに複雑で精緻なシステムでも、デバッグはより難しくなります。私たちは多くの場合、症状を通じて問題を特定するしかありません。数年後には、ソフトウェアは前例のないほど複雑になり、層が重なったものになると思います。私たちは「症状」を通じて問題を識別することが非常に得意になり、私たちのツールもこれを行うことが非常に得意になるでしょう。これが、ソフトウェア開発者が習得すべき一種の独特な能力になると思います。

Tibo:Rajiの話は素晴らしいです。私は未来の様子について一点補足したいと思います。

私はすぐに、あなたは自分のアシスタントと会話するだけで作業の進捗を確認できるようになると思います。あなたは専用の「個人代表型アシスタント」を持つことになります。これはバックグラウンドであなたのために効率的に働くすべてのAIエージェントを代表して要約してくれます。あなたは100個、いや200個の小さなAgentの状態を監視したり一つ一つ確認する必要はなくなります。

私はこの形態はすぐに現れると思います。今年中にも。

司会者:RajiとTibo、内部で起こっていることと、あなたたちチームの働き方を明らかにしてくれてありがとうございます。あなたたちは常に数週間、数か月、あるいはそれ以上先を行っているように感じます。しかしこれらは確かに起こっています。同時に、このエキサイティングな時代の展望を共有してくれてありがとうございます。本当にありがとうございます。

Raji/Tibo:ありがとうございました。

参考リンク:

https://www.youtube.com/watch?v=Bo6Gtq3nMXc


分享網址
AINews·AI 新聞聚合平台
© 2026 AINews. All rights reserved.