AIはいかにして自律的にコードを書き、テストし、最適化するのか？独立した思考から、ターミナルへのアクセス、そして未来の書き換えへ！
編集 | Eric Harrington
提供 | AIテクノロジー本部（ID：rgznai100）
コードの世界の次の波は誰によって起こされるのか？AIが単なる補助ツールではなく、独立して思考し、ターミナルにアクセスし、さらには「専用コンピューター」を持つインテリジェントなソフトウェアエンジニアに変貌するとき、ソフトウェア開発の未来像は完全に書き換えられようとしています。昨年最初に登場した「初のAIプログラマー」と称されるDevin、GitHub Copilotが世界中のプログラマーの主流ツールになりつつあること、今年のCursorの爆発的な人気、そして数日前にOpenAIが発表したコーディングエージェント製品Codexに至るまで、これらの幻想は徐々に現実になりつつあります。
本日は、著名なAIエンジニアのポッドキャストLatent Spaceの最新の深掘りインタビューを共有します。司会者はCodexチームの主要メンバーであるJosh Ma氏とAlexander Embiricos氏を招きました。
彼らはCodexプロジェクトの起源について語りました。モデルにターミナルアクセス権を与えることで見えた「AGIの兆し」の瞬間から、「インテリジェントなソフトウェアエンジニア」を構築するという壮大なビジョンまで。この対談は、Codexの背景にある技術的思想と製品哲学を明らかにするだけでなく、人間とAIのペアプログラミングの新しいパラダイム、そしてこのインテリジェント時代に開発者がいかに波に乗るべきかについても議論しています。
AIは補助ツールから、独立して思考し、ターミナルにアクセスし、「専用コンピューター」を持つインテリジェントなソフトウェアエンジニアへと進化しており、ソフトウェア開発の未来を完全に書き換えています。
AIモデルにターミナルアクセス権を与えることは、OpenAIチームが「AGIの兆し」を初めて見た重要な瞬間であり、エージェントに専用コンピューターを装備するという構想が生まれました。
OpenAIの主要メンバーは、今後2年以内に、ソフトウェアエンジニアリング作業を独立して完了できる「インテリジェントなソフトウェアエンジニア」を構築できる可能性があると予測しています。
Codexは単なるコーディングモデルではなく、ソフトウェアエンジニアリング作業を独立して完了することに優れており、長時間自律的に動作できるインテリジェントなエージェントであり、複雑なタスクを「一発で終わらせる」ことを追求しています。
AI時代において、モデル自体が製品の核となります。将来、モデルはより多くの意思決定を担い、人間の開発者はAIがまだ得意としないアーキテクチャ設計や革新的な作業に焦点を当てることになります。
今回のインタビューのハイライトは以下の通りです。
司会者：本日のゲストは、ChatGPT CodexチームのJosh Ma氏とAlexander Embiricos氏です。Alexanderとは初めての顔合わせですが、彼はCodexの多くのテストとデモンストレーションを主導してきました。
Alexander：皆さんこんにちは、OpenAIのChatGPT CodexプロダクトチームのAlexanderです。
司会者：読者の皆さんがCodexの発表ライブ配信をご覧になっていることを前提に進めさせていただきます。当日、皆さんは多くのテストデモ動画を含むブログ記事も公開されており、非常に興味深かったです。デモ動画では、エンジニアたちが一人で、孤独に、AIパートナーに向かって独り言を言いながら、一緒にコードを書いているように見えました。これが皆さんが作りたかった雰囲気なのかは分かりませんが、私にはそう感じられました。
Alexander：そうですね。あの動画では、私たちは究極のリアリティを追求しました。つまり、エンジニア自身が、AIがいかに彼らを助けてくれたかを語るものです。そのフィードバックは受け止めます。
司会者：でも、それは本当のことですね。時には夜勤は孤独ですし、モバイル開発もかなり寂しいものです。そういう職種は人が少ないですから。だから、完全に理解できます。ところで、皆さんは具体的に何をされてきたのですか？そこから始めましょうか。どのようにしてこのプロジェクトに参加されたのですか？その後の進展はどうなっていますか？
「人間とAIのペアプログラミング、モデルにターミナルアクセスを許可することの絶大な価値」
Alexander：たぶん私が先に話しますね。私たち二人がどうやって一緒に仕事を始めたか、面白い話があるんです。OpenAIに入社する前、私はMaltiというmacOSネイティブソフトウェアを作っていました。人間同士のコラボレーション、一種のペアプログラミングツールに焦点を当てていました。その後、ChatGPTのようなものが流行し始め、私たちは人間同士のペアプログラミングではなく、人間とAIのペアプログラミングだったらどうなるだろうと考え始めました。
それで、その間の曲折は詳しく話しませんが、とにかくそれが私の道のりでした。そして私たちは二人ともOpenAIに入社しました。私は以前、主にデスクトップソフトウェア開発をしていました。その後、私たちは推論モデルをリリースしました。推論モデルの価値を理解する上では、皆さんは私よりずっと先を行っていると思いますが、私にとってそれは最初はより強力なチャットツールに過ぎませんでした。しかし、それにツールを与えられるようになると、それは真に「エージェント」へと変貌するのです。エージェントとは、ツールを備え、環境と安全な境界を持ち、そして特定のタスクのために訓練されている可能性のある推論モデルのことです。
とにかく、私たちはこれに深く興味を持ち、推論モデルをデスクトップに導入する方法を考え始めました。同時に、OpenAI内部でも、これらの推論モデルにターミナルアクセス権を与えるための多くの実験が行われていました。最初に言っておきますが、私はそれらの最初の実験には参加していませんでしたが、それらの実験は私が初めて「AGIの兆し」を本当に感じた瞬間でした。その経験は、David Kというデザイナーと話していたときに起こりました。彼は当時Scientistというプロジェクトに取り組んでいました。彼はそれが自己更新できるデモンストレーションを私に見せてくれました。今では背景色を変えることくらいでは誰も驚かないかもしれませんが。
司会者：彼自身のコードを修正するということですか？
Alexander：はい、そうです。しかも、彼らは当時ホットリロードも設定していました。私はその時、本当に驚きました。今日に至るまで、それは依然として非常にクールなデモです。私たちは当時、似たようなことをたくさん試しており、その後、私はこの方向で活動しているグループの一つに参加しました。私たちは、推論モデルにターミナルアクセス能力を与える方法を解明することが、非常に大きな価値があることに気づきました。そして、それを有用な製品にする方法、そしてその安全性を確保する方法を解決しなければなりませんでしたよね？ローカルファイルシステムでモデルを好き放題にさせるわけにはいきませんが、人々は最初、実際にそのように使おうと試みていました。
これらの経験の多くは、最終的に最近リリースされたCodex CLIに発展しました。その中で私が最も誇りに思っているのは、全自動モードなどの機能を実装する上での考え方です。このモードでは、ユーザーの安全を確保するために、実際にサンドボックスの分離を強化しました。
私たちは当時そのようなことをしていて、その後、モデルにもっと長い「思考」時間を持たせたい、モデルを大きくしたい、モデルに承認なしで安全にもっと多くのことをさせたい、と気づき始めました。そこで私たちは、もしかしたらモデルに専用のコンピュータ、このエージェントに専用のコンピュータを与えるべきではないかと考えました。同時に、私たちはCLIを継続的インテグレーション（CI）プロセスに組み込み、テストを自動的に修正させようともしていました。また、弊社の課題追跡ツールLinear上のチケットを自動的に修正させるという突飛なハッキングも試みました。このようにして、最終的にCodexというプロジェクトを作成しました。その核となる考え方は、エージェントにコンピュータへのアクセスを許可することです。ああ、私が具体的に何をしたかという質問に答えていなかったかもしれませんが、とにかく、話は終わりましたので、大丈夫だと思います。
司会者：あなたは個人の経験を壮大な物語に巧みに織り込んでいますね。Joshさんも補足があると思います。
「2年以内にインテリジェントなソフトウェアエンジニアを構築！」
Josh：私の話は少し違います。私はOpenAIに来て2ヶ月になりますが、人生で最も面白く、そして最も慌ただしい2ヶ月でした。しかし、おそらく数年前に私が設立したAirplaneという会社の話から始めるべきでしょう。当時私たちは、開発者が非常に簡単に内部ツールを構築でき、本当に開発者のニーズに深く入り込めるような、内部ツールのプラットフォームを構築していました。これは今やっていることとはあまり関係がないように聞こえるかもしれませんが、多くの点で、似たようなテーマが再浮上しました。ローカル開発の最良の形態は何でしょうか？ツールをクラウドにデプロイするにはどうすればよいでしょうか？クラウドでコードを実行するにはどうすればよいでしょうか？ストレージ、コンピューティング、ユーザーインターフェースといった基本モジュールを組み合わせて、開発者がソフトウェアを極めて迅速に構築できるようにするにはどうすればよいでしょうか？
私たちはいつも、ただ2年早すぎただけだと冗談を言っていました。プロジェクトの終盤に差し掛かった頃、私たちはGPT-3.5を試して、もっとクールにしようとしました。当時、すでにReactビューを素早く構築できるようになっていました。もし続けていれば、おそらく今日皆さんが見ているAI構築ツールに進化していたでしょう。しかし、その会社は最終的にAirtableに買収され、私はそこでいくつかのAIエンジニアリングチームを担当していました。
個人的には、今年の初め、私はエージェント型ソフトウェア開発における私たちの進歩を目の当たりにしました。私にとって、それはある種の私自身の「月面着陸の瞬間」のようなもので、この大きな出来事が間もなく起こることを予感しました。私がそれに参加するかどうかに関わらず、今後2年以内に、私たちはエージェントソフトウェアエンジニアを構築すると考えています。そこで私はOpenAIの友人に連絡を取り、「ねえ、君たちも似たようなことをやっているの？」と尋ねました。彼は目を大きく見開いて私を見て、「何も言えませんが、チームと話してみるといいかもしれません」と言いました。
それで、幸運なことに、当時AlexとFosterがちょうど関連プロジェクトを立ち上げるところでした。面接のとき、私たちは製品の形態について激論を交わしたことを覚えていますよね？それはコマンドラインツール（CLI）であるべきなのか？その形態の問題点は、タスクが完了するのを待つ間、頻繁に中断できないこと、そして同時に4回、10回と実行したいと思うかもしれないことです。おそらくその時、私は両方備わっていた方が良いと言ったのでしょう。私たちは今、その方向に向かって努力しています。とにかく、私は当時も、そして今も、このプロジェクトを推進することに非常に興奮しています。Codexはまだ非常に初期段階にあると思います。それを世界と共有できるのは嬉しいですが、やるべきことはまだたくさんあります。
Alexander：初めて会った時の会話は非常に面白かったです。彼は入ってくるなり—こんな経験は初めてでしたが—こう言いました。「世界はこのような変革期にあり、だから私はこのような製品を作りたい。皆さんがこれをやっているかどうかは確認できないが、これこそ私が唯一やりたいことだ。」そして私がいくつかのオープンな質問をすると、私たちはすぐにツールの形態に関する核心的な論点に入り込みました。私は「素晴らしい、一緒に働くしかない」と思いました。
司会者：開発者ツールの世界の人たちは、お互いに同じ道を歩む者だと一目でわかるものですよね。
余談ですが、アップルの初期のiPhoneチームもそうでした。チームメンバーがお互いに同じプロジェクトグループにいるかどうかわからなかったのです。彼らは情報を漏らすことを許されていなかったので、彼らは「三角測量」で判断するしかなかったのです。
製品形態の議論：CLIかクラウドか？
司会者：製品形態についてですが、すでにリリースされているCLIについて触れられましたね。市場にはAiderなどの他のクラウドベースのコードツールもあるかと思います。皆さんはChatGPTの中のCodexを、ホストされたCodex CLIと見なすべきでしょうか？両者には大きな違いがありますか？この点についてお話ししましょう。
Alexander：どうぞ。
Josh：簡単に言えば、OpenAIのクラウドでCodexエージェントを実行できる、ということだと思います。しかし、製品の形態は、コンピュータがどこで実行されるかという単純なこと以上のものだと私は考えています。それは、ユーザーインターフェースとどのように結合するか、時間の経過とともにどのように拡張するか、キャッシュと権限をどのように管理するか、そしてどのようにコラボレーションを実現するかに関わります。ですから、同意していただけるかは分かりませんが、私は製品の形態こそが核心だと考えています。
Alexander：正直なところ、それは非常に興味深い旅でした。先日、あるいは昨晩だったかもしれませんが、Joshはライブ配信があったので寝ていましたが、私はそうではありませんでした。とにかく、私たち数人で、当初どのような機能をリリースする予定だったかの文書を見返したところ、プロジェクトの範囲がいつの間にかかなり拡大していることに気づきました。しかし実際には、これらの範囲の増加はすべて当然のことでした。なぜなら、私たちは「これは単にコーディングが得意なモデルではなく、ソフトウェアエンジニアリングの作業を独立して完了することに長けたエージェントである」という考え方をますます深く受け入れるようになったからです。この考え方に深く入り込むほど、物事はますます異なって見えてきました。
ですから、Joshが担当しているコンピューティングプラットフォーム全体の話は一旦置いておきましょう。モデル自体について言えば、私たちは単にコードを書くのが得意なだけでなく、SWeBench上のタスクを解決できるだけでもなく、それを望んでいます。SWeBenchについてご存じない方のために説明すると、これは評価ベンチマークであり、出力結果を機能的に採点する特定の方法があります。しかし、SWeBenchでテストされたエージェントの出力の多くを見ると、それらは実際にはコードベースにマージするプルリクエスト（PR）ではありません。なぜなら、コードスタイルが大きく異なる可能性があるからです。動作はするが、スタイルが間違っている。
そのため、私たちはモデルが指示に従うこと、コードスタイルを推測することに非常に長けていることを確認するために多くの時間を費やしました。そうすれば、明示的に伝える必要がありません。しかし、それでも、もしあなたがコードスタイルが良好で、指示にもきちんと従ったPRを受け取ったとしても、モデルがその構築方法について延々と長い説明を提供した場合、そのPRは依然としてマージが難しいかもしれません。そして、変更をテストし、その有効性を確認するために、おそらくローカルコンピュータにプルする必要があるでしょう。1つの変更を実行するだけなら許容できるかもしれませんが、私たちが想定する未来の世界では、ほとんどのコードが実際に、私たちから委任されたエージェントによって並行して完了される可能性があります。その場合、人間の開発者がこれらの変更を簡単に統合できるかどうかが非常に重要になります。
たとえば、私たちが訓練を始めたもう一つの内容はPRの説明です。私たちは、「良い、簡潔で、要点を強調したPRの説明を書く」ということを本当に極めたいのです。ですから、私たちのモデルは実際に美しく簡潔なPRの説明を書き、PRのタイトルもあなたのコードリポジトリのフォーマットに合致するようにします。もし望むなら、私たちはagents.mdファイルも提供しており、より細かくガイドすることができます。そしてPRの説明では、その過程で見つけた関連コードやPR内の関連コードも参照するので、マウスオーバーで確認できます。
おそらく私が最も気に入っている機能は、テストの扱い方です。モデルは変更をテストしようとし、そして非常に分かりやすい方法で、まるでチェックマークのように、これらのテストが合格したかどうかを教えてくれます。同様に、テストが合格した場合は、ログで特定された参照情報を引用してくれるので、あなたはそれを見て「よし、このテストは合格した」と確信できます。テストが失敗した場合は、「ねえ、うまくいかなかったよ。pnpmなどをインストールする必要があるかもしれないよ」と言ってくれて、あなたはログを見て問題の所在を突き止めることができます。これらが私たちずっと取り組んできた方向性であり、基本的にはこのソフトウェアエンジニアエージェントをクラウド上で構築しているのです—ああ、最初の質問が何だったか忘れてしまったようですが、これらが私たちが深く掘り下げてきたことです。
Josh：私も非常に違うと感じます。機能だけを見ることもできますが、私にとってはその感覚は、「信じる心の飛躍」が必要だということです。最初の数回使うときは、「これが本当に機能するのかどうか、よくわからないな」と思うでしょう。そしてそれが30分間動きます。しかし、結果を持って帰ってきたとき、あなたは驚嘆するでしょう。「うわー、このエージェントは実際に出て行って、たくさんのコードを書き、そのコード自体を変更するのを助けるスクリプトまで書き、それらをテストし、そして行いたい変更について本当に完全に考えたんだ！」最初、私はそれが成功するとは全く信じていませんでした。しかし、数回使ってみると、「うわー、本当にやり遂げた！」と感じるでしょう。長時間独立して作業する能力は、言葉で表現するのが難しいもので、自分で試してみるしかありません。しかし最終的に、それは全く異なる、非常に特別な感覚を与えてくれます。
司会者：私は使いました。数分前にPRを出したばかりです。幸運なことに、最初の25%の内部テスターの一人でした。非常に使いやすいです。ただ、Rails環境でRSpecを実行する方法がわからなかったので、Rubyファイルのシンタックスチェックだけをして、「問題ない」と言ってショートカットを使いました。でも、agents.mdはまだ使っていないと思います。それを設定すれば、問題ないはずです。
agents.mdから「意識的なネーミング」へ
司会者：もしベストプラクティスをいくつか挙げてもらえると、とても助かります。ライブ配信で、プロのユーザーはリンターやフォーマッターをインストールすると言っていましたね。そうすることで、エージェントが開発環境でこれらのバリデーターを利用できるようになる、と。これらは開発者にとってもベストプラクティスであることが証明されていますが、今はエージェントが自動的にそれらを利用できるようになったわけですね。コミットフックは人間にとって常に厄介な問題でした。私が所属していたチームでは、すべてにコミットフックがなければならないと主張するチームもあれば、それが邪魔だと感じてすべて削除してしまうチームもありました。しかし実際には、エージェントにとってコミットフックは非常に便利です。
Josh：あなたが次に言おうとしていたことを全部言ってしまいましたね。私が言いたいのは3つです。まず、agents.md。私たちはエージェントがこの指示の階層構造を理解できるように、多大な労力を費やしました。サブディレクトリに置くことができ、どの指示がより高い優先度を持つかを理解できます。そして、私たちは今、GPT-3とGPT-4を使ってagents.mdファイルを作成し始めています。
司会者：そういうテクニック、好きですよ。実際に、ここのプロンプト記述をオープンソースにしましたね。
Josh：はい。
司会者：何か強調すべき点はありますか？
Josh：最初はシンプルに始めるのが良いと思います。いきなり複雑にしすぎないでください。簡単なagents.mdファイルでも、何もないよりはるかに役立ちます。そして、使っていくうちに徐々に学んでいくことです。私たちが本当に望んでいるのは、将来的にあなたが作成したPRとあなたが提供したフィードバックに基づいて、このファイルを自動的に生成できることですが、完璧を追求するのではなく、早めにリリースすることに決めました。
司会者：GPT-3、GPT-4もagents.mdの作成に使っている、とおっしゃいましたね。
Josh：私はディレクトリ全体をそれに与え、「ねえ、agents.mdを生成して」と言います。実際、最近はCode One—ああ、ごめんなさい、Codex One—を使ってこれを行っています。なぜなら、それがディレクトリツリーを辿ってこれらのファイルを生成できるからです。ですから、私はagents.mdの構築に段階的、漸進的に取り組むことをお勧めします。そして、あなたが言ったように、最も基本的なリンターとフォーマッターを設定してください。これは実際にかなりの利益をもたらします。なぜなら、VS Codeで新しいプロジェクトを開いたときに、すぐに使えるチェック機能を得られるのと似ているからです。エージェントは最初は、人間に例えるなら、このような利点を欠いているのです。ですから、これを行うことで、その利点をエージェントに返すことになります。
Alexander：それについて私にはアナロジーがあります。それから、他のコーディングエージェント、いや、あらゆるコーディングエージェントを使った経験から、それにどう備えるかについて話したいです。私が好きなアナロジーはこうです。もしあなたが基礎的な推論モデルから始めたなら、基本的には非常に早熟で、頭脳明晰で、知識豊富だが、少し風変わりで才能豊かな大学の卒業生を得ることになります。私たちは皆知っていますが、もしあなたがそのような人を雇って、彼らにソフトウェアエンジニアリングの仕事を単独でやらせたら、彼らは実務的なことがたくさんわからないでしょう。
それで、私たちがCodex Oneでやったことの多くは、基本的にその最初の数年間の実務経験を与えることでした。それがトレーニングの本当の意味であり、より実用的になるようにするのです。考えてみてください、良いPRの説明を書くというのは典型的な例で、もしかしたら何を含めるべきでないかを知ることも含まれるかもしれません。
そして、あなたはこれを得るのです。少し奇妙なほど知識が豊富で、才能はあるけれど少し変わり者で、数年の実務経験を持つ大学の卒業生です。そして、タスクを開始するたびに、それは彼らがあなたの会社で初めての日であるかのようなものです。だから、agents.mdは基本的に、彼らがやらなければならない「オンボーディングの探索」の時間を圧縮し、より多くのことを学ばせる方法なのです。Joshが言ったように、もちろん私たちは、今はまだ研究プレビュー版なので自分で更新する必要がありますが、自動化をどう実現するかについて多くのアイデアを持っています。これは単に面白いアナロジーです。
Josh：おそらく最後に言いたいのは、あなたのコードベースを発見しやすくすることです。これは、新入社員があなたのコードベースをより速く理解できるように、良好なエンジニアリングプラクティスを維持することに相当します。私の多くのプロンプトは、「私はこのサブディレクトリで作業しています。これを完了したいのですが、手伝っていただけますか？」という形で始まります。ですから、そのようなガイダンスと範囲の限定は非常に役立ちます。
Alexander：私は通常、3つのアドバイスをします。まず、言語選択です。先日、AI分野の新参者である友人と話していて、彼が「エージェント製品を作ってみたいんだけど、JavaScriptを使うべきかな？」と尋ねてきたので、私は「まだJavaScriptを使っているの？なるほどね。せめてTypeScriptを使って、型情報を与えなさい」と答えました。ですから、それが最も基本的な点だと思います。このポッドキャストを聞いている皆さんには、もう強調する必要はないと思いますが。
もう一点は、コードをモジュール化することです。コードがモジュール化され、テストしやすければ、それだけ効果は高まります。自分でテストを書く必要さえなく、エージェントが書くこともできますが、アーキテクチャをモジュール化するように設計する必要があります。最近、ここで誰かが行ったデモンストレーションを見ました。彼は基本的に—彼は感覚でコードを書くタイプではなく、プロのソフトウェアエンジニアですが—Codexのようなツールを使って新しいシステムを構築していました。彼はゼロからこのシステムを構築し、彼のコードコミット速度を示すグラフがありました。その後、彼のシステムは一定のユーザー数を獲得し、「今度はChatGPTの巨大なモノリシックコードベースに移植しよう」という段階になりました。そのコードベースは狂気的な超高速成長を経験していたため、おそらくアーキテクチャ計画はそれほど完璧ではなかったでしょう。結果として、同じエンジニアが、同じツールを使い、AIツールも進化し続けているにもかかわらず、彼のコードコミット率は直線的に低下しました。
だから、もう一点は、アーキテクチャ、良いアーキテクチャがこれまで以上に重要になるということです。そして興味深いことに、今のところ、これはまだ人間が本当に得意なことです。ですから、ソフトウェアエンジニアが本来の仕事をしっかりとこなす上で、これは良いことであり、重要なことでもあります。
司会者：エージェントの理解しやすさのために、人間の可読性を犠牲にして命名を始めることはありますか？あなたにとって、そのトレードオフは何ですか？
Josh：それはとても面白いですね。OpenAIに入社したばかりの頃、確かにいくつかの先入観を持っていましたが、今ではこの二つのシステム（人間の可読性とエージェントの可読性）は実際には高度に収束していると考えています。おそらく、人間とAIの両方がそれを書いているのを見るからでしょう。おそらくAIだけがコードベースを維持する世界では、前提が変わるでしょう。しかし、一度その「第四の壁」を破って人間がコードレビューやコードのデプロイに介入しなければならなくなると、コードのあらゆる部分に人間の痕跡が必要になります。ですから、人間がAIにどこを修正すべきか、どのバグを修正する必要があるか、あるいはビジネス要件をどのように伝えるか、これらすべてがすぐに消え去ることはありません。したがって、システム全体は実際にはまだ非常に「人間的」であると私は考えています。おそらく、まるでエイリアンのようで、全く違う、というようなクールな答えを言うこともできたかもしれませんが、これらのものは大規模言語モデルから始まっており、その根源は人間のコミュニケーション方法に深く根ざしていると私は考えています。
Alexander：ちなみに、もし話題を変えたければ、遠慮なく遮ってください。二人で話が盛り上がってしまっていることに気づいたので。
agents.md vs. readme.md
司会者：いいえ、これはagents.mdにも関係すると思います。なぜagents.mdで、readme.mdではないのですか？エージェントと人間が情報を消費する方法には、根本的な違いがあると皆さんは考えているのですね。そこで気になるのですが、この違いはクラスの命名レベルにあるのか、それとも単に指示レベルにあるのか、あるいはその境界線はどこにあると思いますか？
Josh：どうぞ。
Alexander：この命名については、いくつかの選択肢を検討しました。readme.mdを使うこともできますし、contributors.mdを使うこともできます。Codex agent.md、そしてCodex CLI.mdとして、ブランドの識別子を持つ2つの独立したファイルにすることも可能です。
司会者：cursor.rulesとか、Witserf rulesとか、各社が独自のルールファイルを持っていますよね。
Alexander：そして、agents.mdを選ぶこともできます。ここにはいくつかのトレードオフがあります。一つは開放性、もう一つは特異性といったところでしょうか。私たちが考えたのは、エージェントに伝えたいけれど貢献者には伝える必要のない情報があるかもしれない、ということです。同様に、貢献者には伝えたいけれどエージェントには伝える必要のない情報（エージェント自身で解決できること）もあります。そこで、この二つは異なる可能性があると考えました。そして、エージェントは結局readmeも読みますから、agents.mdは、エージェントに伝える必要があるけれど、readmeから自動的に取得できない情報を置く場所として使われるかもしれない、と。それで私たちはその決定をしました。
それから、エージェントには異なる形態があると考えました。私たちが構築し、リリースしているものの最も特殊な点は、クラウドエージェントを使用する既製の手段を提供することです。このエージェントは、多くのタスクを並行して処理でき、長時間思考でき、そして多くのツールを安全に使用できます。そこで私たちは、そのようなエージェントに与えたい指示のセットと、ローカルコンピューターでより協調的に使用するエージェントに必要な指示のセットとの間に、一体どれほどの違いがあるのかと考えました。正直なところ、私たちはこれについてかなりの議論をしました。最終的に私たちは、これらの指示セット間の違いは、このファイルに名前空間を設定する必要があるほど大きくないという結論に達しました。もし本当に名前空間を区別する必要があるなら、おそらくファイル内で自然言語で直接説明すればよいでしょう。
最後に考えたのは、私たちのエージェントに与えるべき指示と、異なるモデルで動作する、あるいは異なる企業によって構築されたエージェントに与えるかもしれない指示との間に、どれほどの違いがあるかということです。もし、これらすべての異なるエージェントファイルなどを作成しなければならないとしたら、ユーザー体験は非常に悪いものになるだろうと感じました。これがCodex CLIをオープンソースにした理由の一部でもあります。これらのものを安全にデプロイする方法に関するセキュリティ問題など、多くの問題は解決される必要があり、誰もが車輪の再発明をするべきではありません。ですから、ブランド名なしの選択肢を選んだのはそのためです。
Josh：readmeとagents.mdが異なる理由について具体的な例があります。エージェントの場合、コードスタイルについて教える必要は実際にはないと思います。エージェントはあなたのコードベースを見て、それに一貫したスタイルのコードを書きます。しかし、人間の開発者は、コードベース全体を読み通してすべての慣習に従うことに時間を費やすことはありません。これはほんの一例ですが、結局のところ、これら2種類の「開発者」が問題を処理する方法には違いがあるのです。
モデルが製品？
司会者：これらの提案は非常に素晴らしいと思います。今お話しいただいた内容は、まさに今回のポッドキャストのタイトルになりそうですね。「ChatGPT Codexのベストプラクティス」と名付けましょう。皆さんもベストプラクティスが何なのか知りたいと思っているでしょうから。
非常に興味深い現象に気づきました。エージェントの構築に関して、常に2つの考え方があるようです。一つは、より強く制御し、より決定論的にすること。もう一つは、直接プロンプトを与え、モデルを信頼すること。皆さんのアプローチは、「プロンプトを与え、モデルを信頼する」という方向性に非常に傾いていると感じます。agents.mdのシステムプロンプトを見ると、皆さんは期待する通りに行動するように指示しているだけで、あとはモデルがそうすることを期待しています。もちろん、モデルを制御できるので、もしパフォーマンスが悪ければ、トレーニングできます。しかし、一つ疑問に思うのは、どうやってすべてをコンテキストに含めているのかということです。もしagents.mdファイルが超長くなったらどうなるのでしょう？皆さんのライブデモでは、OpenAIの巨大なモノレポで実行していましたね。では、キャッシュやコンテキストウィンドウなどはどのように管理しているのですか？
Josh：もし私が今、すべてがまだコンテキストウィンドウに収まると言ったら、あなたは信じますか？
司会者：OpenAIのコードベースでは無理でしょう？
Josh：いいえ、エージェントが必要とするすべてのものです。
司会者：なるほど。では、agents.mdを簡略化して、先頭に置くのですか？まるで別のシステムプロンプトのように。
Josh：いいえ、それはファイルであり、エージェントはそれを検索（grep）し、見つけてコンテキストに読み込む方法を知っています。なぜなら、そのようなファイルが複数存在する可能性があるからです。実際、作業ログを見ると、それが積極的にagents.mdを探しているのが分かります。それはそうするように訓練されています。
私が言いたいのは、OpenAIに入社して気づいたことですが、モデルの将来の方向性や数年後のAI製品がどうなるかを考えるとき、製品を異なる方法で設計することになるという点で、本当に面白いです。OpenAIに入社する前、特に研究チームや大量のGPUリソースがない場合、あなたはこれらの決定論的なプログラムを構築し、その動作方法の周りに多くの足場を組むでしょう。しかし、あなたは実際にモデルの潜在能力を最大限に引き出しているわけではありません。
私が初めて入社した時、面白い現象がありました。私はよく質問されたものです。「ねえ、なんでこれを直接ハードコードしないんだ？君はこのツールをいつも間違って使っているから、プロンプトで『そうするな』と言えばいいじゃないか。」すると研究者たちはこう言いました。「いやいや、そうはしない。私たちは正しい方法でやるんだ。モデルに、なぜこれが正しい方法なのかを教えるんだ。」私はこれが、より大きな考察に関係していると思います。つまり、どこに決定論的な「ガードレール」を設定し、どこでモデルに真に「思考」させるべきか、ということです。
計画段階についても同様の議論があります。明確な計画段階を設定すべきでしょうか、例えば「まず声に出して考え、何をしたいかを書き出し、それから実行する」といったように？もちろん可能です。しかし、タスクが非常に簡単だったらどうでしょう？本当にずっと考えさせたいですか？もし実行中に再計画が必要になったら？そのためにあらゆるif-else条件やヒューリスティックなルールを設定すべきでしょうか？それとも、非常に優れたモデルを訓練し、これらの思考モード間を切り替える方法を知っているようにすべきでしょうか？ですから、それは難しいです。私は確かに、次のトレーニングが完了するまでは、いくつかの小さな「ガードレール」を設定することを主張したこともありました。しかし、私たちが本当に構築しようとしているのは、モデルがこれらすべての決定を下せる未来だと思います。本当に重要なのは、コンテキストの管理、メモリの管理、コードベースの探索方法といった、正しいツールをモデルに提供することです。これらは依然として非常に重要です。
Alexander：はい、よく言われました。ここで製品を作るのは非常に面白く、そして異なっていると感じます。モデルが製品のすべてではありませんが、モデルそのものが製品なのです。あなたは多少謙虚な態度で考える必要があります。ここにはユーザー、開発者、そしておそらくモデルという3つの当事者がいます。ユーザーが最初に決定する必要があることは何でしょうか？次に、私たち開発者がモデルよりも良い決定を下せることは何でしょうか？そして、モデル自体が最適な決定を下せることは何でしょうか？すべての決定はこれら3つのうちのいずれかに帰属しなければなりません。
すべてがモデルによって決定されるわけではありません。例えば、現在ユーザーインターフェースには「質問する」と「コーディングする」という2つのボタンがあります。これらの2つの機能は、モデルが下す決定にインライン化できるかもしれません。しかし、現状では、ユーザーに選択権を最初から与えることは非常に合理的です。なぜなら、ユーザーが押すボタンに基づいて、まずモデルのために異なるコンテナを起動するからです。したがって、もしあなたがコーディングを要求した場合、私たちはすべての依存関係を含めます—ここでは簡略化して言っています。しかし、もしあなたがコーディングを要求せず、ただ質問するだけなら、モデルが何かを選択する権限を得る前に、はるかに速いコンテナ設定を行います。ですから、それはユーザーの決定かもしれません。
ある意味で、ユーザーと開発者の決定は環境レベルで交差します。しかし最終的に、私が目にする多くのエージェントは印象的ですが、その印象的な部分の理由は、開発者のグループが、一連の短いモデル呼び出しの周りに非常にカスタマイズされたステートマシンを構築したからです。その結果、モデルが解決できる問題の複雑さの上限は、実際には開発者の脳が収容できる範囲によって制限されます。そして私たちは、時間の経過とともに、これらのモデルがますます複雑な個々のタスクを独立して解決し、ますます複雑な問題に対処できるようになることを願っています。最終的には、エージェントで構成されたチームが協力して作業し、おそらくそれらのエージェントを管理するエージェントもいる、ということを想像することもできます。そうなれば、複雑さは爆発的に増大するでしょう。
ですから、私たちは可能な限り多くの複雑性、可能な限り多くの状態機械をモデルに処理させたいと心から願っています。そうすれば、これら二つの構築モードが得られます。一方では、製品のユーザーインターフェースとルールを構築しています。もう一方では、モデルに何かを学ばせるための作業はまだ必要ですが、その作業とは、このモデルが学習するためにトレーニング中にどのような正しいものを見る必要があるかを理解することです。ですから、このような変化を実現するには、依然として多大な人的投入が必要ですが、それは「モデルにこれを見せる」という全く異なる考え方なのです。
「コーディング」対「質問」
司会者：しかし、それらのシグナルを収集するために、どのように製品を構築しているのですか？「コーディング」と「質問」という2つのボタンを考えると、これはほとんどユーザーに何らかの形でプロンプトをタグ付けさせていることになります。なぜなら、彼らが「質問」と言えばそれが質問プロンプトになり、「コーディング」と言えばそれがコーディングプロンプトになるからです。この製品を構築する過程で、他に何か面白い製品設計がありましたか。「モデルはこれを学習できると考えるが、データがないので、データを収集するためにCodexをこのように設計する」という考え方に基づいたものは？
Josh：ファイルコンテキストと範囲限定は、現時点では優れた組み込み機能ではありませんが、明らかに私たちが追加する必要がある機能の一つです。これは、その種の状況のもう一つの例です。あなたは、私たちがよく驚くように、「ああ、それは私が考えていたまさにそのファイルを見つけた！」と気づくかもしれませんが、それには時間がかかります。だから多くの場合、「ねえ、このディレクトリで探しているんだけど、何か見つけるのを手伝ってくれる？」と直接言うことで、一連の思考プロセスを短縮することになります。ですから、より優れたアーキテクチャ化されたインデックス作成と検索機能を持つまでは、この状況がしばらく続くと思います。
司会者：なるほど、クールですね。Codex自体について、あといくつか事実に関する質問を締めくくってから、計算プラットフォーム側の話に深く掘り下げたいと思います。Joshさんはこの点についてもっと話したいでしょうね。詳細で、タスクの長さが1〜30分と書かれているのに気づきました。これは厳密な制限ですか？もっと長いタスクに遭遇したことはありますか？タスクの長さについて何かコメントはありますか？
Josh：ここに来る前に、ちょうどコードベースを調べたところです。他の人も同様の質問を持っていました。現在の厳密な上限は1時間です。ただし、あまり真に受けないでください。これはいつでも調整される可能性があります。私が最長で見たのは2時間で、それは開発モードで、モデルが完全に制御不能になっていました。ですから、私たちが解決しようとしている種類のタスクにとって、30分というのは妥当な範囲だと思います。これらは骨の折れるタスクであり、多くの反復とテストが必要で、モデルには考えるための時間が必要です。
Alexander：平均時間は30分よりはるかに短いですが、骨の折れるタスクを与えれば、確かに30分かかることもあります。
司会者：ここにはいくつかのアナロジーがあると思います。一つは、Operatorチームがベンチマークを実行し、上限を2時間に設定せざるを得なかったことです。もう一つはMetrの論文ですが、普及しているかどうかわかりませんが、彼らは現在の平均自律実行時間はおよそ1時間で、7ヶ月ごとに倍増する可能性があると推定しています。ですから1時間というのはだいたい合っていますが、それは中央値なので、確かにその時間を超えるタスクもあるでしょう。
Alexander：全くその通りです。
司会者：SWeBenchで検証された例で、23個実行できないものがあったとのことですが、これは時間の制限と関係していますか？それとも他の理由でしょうか？
Alexander：正直なところ、あまり確実ではありませんが、SWeBenchのいくつかのケース自体は、無効と言うのは少し言い過ぎかもしれませんが、実行時に確かにいくつかの問題があるように感じます。だから、うまく動かないのです。
司会者：なるほど。では、最大同時実行数についてはどうですか？同時実行の制限はありますか？もしCodexインスタンスを同時に5個、10個、100個実行したらどうなりますか？
Alexander：5個、10個は全く問題ありません。実際、乱用防止のために上限を設定しているとは感じています。具体的な数字は分かりません。
Josh：私の記憶では、現在1時間あたり60個です。
司会者：1分に1つですね。
Josh：でも、聞いてください、そこが肝なんです。長期的に見れば、私たちはAIにタスクを委任しているのか、AIと協力しているのか、あなたが気にする必要がなくなることを望んでいます。AGIのスーパーアシスタントを想像してみてください。あなたはただ質問し、ただ話しかけるだけで、それが物事を片付けてくれるんです。素早い答えが必要な時は素早く、長い思考が必要な時はゆっくりと。そして、あなたはそれと話すだけでなく、それがあなたの様々なツールに統合されている。それが長期的な目標です。しかし短期的には、それはあなたがタスクを委任するためのツールなのです。
私たちが観察した最適な使用法は—今回のポッドキャストのテーマ「ベストプラクティス」に戻ると—「豊富なマインドセット」を持つことであり、それをあなたの時間を消費するのではなく、物事を探索する手助けとして見なすことです。ですから、通常、エージェントがあなたのコンピューター上で作業するとき、あなたは非常に慎重にプロンプトを検討します。なぜなら、それがあなたのコンピューターをしばらく占有し、他のことができなくなるかもしれないからです。しかし、Codexを最も愛用している人々を見ると、彼らはそうではありません。彼らがプロンプトについて考える時間は、せいぜい30秒です。それは、「ああ、アイデアがある、行こう！」「ああ、これをやりたい、やろう！」「ああ、このバグや顧客からのフィードバックを見たばかりだ」といった感じで、すぐにタスクを送信するのです。ですから、あなたが並行して実行するタスクが多ければ多いほど、私たちは実際により嬉しく、ユーザーもその状況を見てより満足するだろうと考えています。それがこの製品の特性です。
司会者：私も自身の経験を共有させてください。私はこのプロジェクトの信頼できるテスターの一人でしたし、お二人ともご存じですね。後になって、私が間違った使い方をしていたことに気づきました。Cursorのように使って、チャットウィンドウを開いて、コードが書かれるのを見ていたんです。そして、私はそうすべきではないことに気づきました。はっとしました。「ああ、皆さんは直接タスクを投げ出して、あとは自分のことをやっているんだな」と。それは確かに考え方の転換でした。
Alexander：一点だけ手早く補足させてください、短く話すように心がけます。非常に面白い使い方の一つが、携帯電話で使うことです。なぜかわかりませんが、携帯電話で操作すると、人々の思考方法が変わるのです。ですから、私たちはウェブサイトをレスポンシブにしましたし、最終的にはアプリにも統合する予定です。ぜひ試してみてください。本当に面白くて、満足できる体験です。
司会者：それでは、それは動画の一つで示された、モバイルエンジニアが携帯電話でプログラミングしているのとは違うのですね。現状ではChatGPTアプリでは使えない、と。
Alexander：まだです。
司会者：モバイルで受け取る通知に問題があります。「研究を開始しています」と表示されますが、これは深層学習の通知と同じです。深層学習をツールとして使っているのですか、それとも単に同じ通知を再利用しているのですか？
Alexander：同じ通知を再利用しているだけです。
エージェントは何にアクセスできるのか？セキュリティ境界はどこにあるのか？
司会者：コンピューティングプラットフォームについて言及されましたし、強化学習（RL）とインフラストラクチャを共有していることについても触れられましたね。Codexが何にアクセスでき、何にアクセスできないかについて、リスナーに大まかに説明してもらえますか？ユーザーはコマンドを自分で実行できないようで、モデルに指示するしかないようですが。他に注意すべき点はありますか？
Josh：これは継続的に進化している議論であり、私たちはまだ、ユーザーとエージェントにどの部分を公開できるか、どの部分を現時点では保持する必要があるかを模索しています。ですから、私たちはまだ学んでいる途中であり、安全とセキュリティの制約に合致することを前提に、可能な限り多くのアクセス権を人間ユーザーとエージェントと共有したいと強く願っています。
現在できることは、人間ユーザーとして、環境を設定し、スクリプトを実行することです。これらのスクリプトは通常、依存関係をインストールするために使用され、これが利用シナリオの約95％を占めると予想しています。目的は、すべての正しいバイナリを準備し、エージェントが使用できるようにすることです。実際、私たちはいくつかの環境編集体験も提供しており、人間ユーザーはインタラクティブインタープリタ（REPL）に入って、いくつか試すことができます。ですから、悪用はしないでくださいが、そこで環境と対話する方法は確かに存在します。
Alexander：私たちはインタラクティブに環境を更新するREPLを作るつもりはありませんでしたが、試してみました。Joshが「なんてこった、これが必要だ！」と言ったので、それが範囲拡大の例です。作ってくれてありがとう。
Josh：私たちは確かにレート制限を設定しており、非常に慎重に監視しています。しかし、そこには確かに、あなたが始めるのに役立つインタラクティブな機能がいくつかあります。エージェントが動作を開始すると、私たちが現在実際に行っていること—そして、この点で改善したいと願っていること—は、インターネットアクセスを切断することです。なぜなら、エージェントが自身の環境で自由に活動した場合に何が起こるか、まだ完全には理解していないからです。これまでのところ、すべてのセキュリティテストは、プロンプトインジェクションを狙った特定の窃取の試みには簡単に影響されないことを非常に厳密に示していますが、この分野には依然として多くのリスクが存在するため、まだ確信が持てません。だからこそ、私たちは当初より保守的な戦略を取りました。エージェントが実行されている間、完全なネットワークアクセス権は持っていません。
しかし、私はこの点を変えたいと強く願っています。例えば、特定のドメインや特定のコードリポジトリへの限定的なアクセスを許可するなどです。要するに、これらの機能をサポートする正しいシステムを構築するにつれて、この点も常に進化しています。それがあなたの最初の質問に完全に答えているかは分かりませんが。
ただ、最後に一点だけ触れておきたいのは、インタラクティブ性に関する問題です。エージェントが実行中に、「ああ、それを修正して別の場所に行かせたいな」とか、「この部分は私が埋めて、あとはあなたが引き継いで」と思うことがあります。これらの問題はまだ完全には解決していません。私たちが最初から本当に追求したかったのは、完全に独立して、一度で大きな価値を提供できるモードです。しかし、人間とエージェントをより良く組み合わせる方法については、間違いなく考えています。
司会者：公平に言って、「一発で終わらせる」という視点は素晴らしいと思います。他の人々は、皆さんとDevin、Factory、その他の競合製品を比較しています。彼らは複数回の手動フィードバックに重点を置いています。私は現在開発中のウェブサイトを持っていて、それに要件を与え、他のツールとも比較してみましたが、それがCodexのテストでした。確かに一発で終わらせてくれました。
これは本当に素晴らしいことです。特に同時に60のタスクを実行しているときは。だから、これは非常に理にかなっていると思います。しかし、これは非常に壮大な目標です。なぜなら、人間のフィードバックは私たちが頼りがちな「杖」だからです。これはまた、私たちにさらに多くのテストを書くことを強制します。テストを書くのは嫌いなので、これはかなり迷惑ですが、今はCodexにテストを書いてもらえるので幸いです。また、ライブ配信でデモンストレーションされた、コードベースを見せて何か提案させる機能も特に気に入っています。なぜなら、何をすべきか考える気力さえもなくなっているからです。
Alexander：他人に権限を与える、これは非常によく言われた言葉だと思います。明確にしておきたいのは、私たちはある形態が他の形態よりも必ずしも優れていると言っているわけではないということです。私はCodex CLIを使うのがとても好きですし、私たちが本当に望んでいるのは、OpenAIの面接で話したように、両方のモードを兼ね備えることです。しかし、Codexがここで果たしている役割は、「一発で終わらせる」という自律的なソフトウェアエンジニアの境界を真に押し広げることだと私は考えています。
はい、私は今回の研究プレビュー版を、ある種の思考実験として捉えています。それは、コーディングエージェントが、最も純粋な形、つまりAGIの可能性や規模効果を最もよく体現する形で、どのようなものになるかを探るようなものです。そしておそらく、私個人にとって、OpenAIで働くことが興奮する理由の一部は、開発者の問題を解決するだけでなく、AGIがいかに全人類に利益をもたらすか、そして非開発者がこれについてどう感じるかを真に考えることでもあります。ですから、私にとって本当に興味深いのは、Codexを実験として捉え、他の機能部門で働くことがどのような感じになるかを見ることです。私が目指している目標は、曖昧で創造的、あるいは自動化が難しい作業は私たちが行い、それ以外のほとんどの作業はエージェントに委任するというビジョンです。そしてこれらのエージェントは、遠い未来の産物でも、一時的な短期的なツールでもなく、遍在し、常にあなたのそばにいるものです。ですから、私たちは最も純粋な形から始めることにしました。当初はそれが最もリリース範囲の小さいものになると思っていましたが、そうではなかったかもしれません。しかし、最終的にはこれらの異なるものを統合していくでしょう。
AGIスーパーアシスタントへの道
司会者：はい、まだいくつか質問する時間があると思います。この研究プレビュー版について、もう少し詳しくお話ししましょう。なぜ「研究プレビュー版」なのですか？まだ何が不足しているのですか？正式リリースと見なされるには、どのような基準を満たす必要があると考えていますか？ライブ配信でグレッグ氏は、クラウドとCLIの間のシームレスな移行について言及していました。それが理由ですか、それとも他の考慮事項がありますか？
Alexander：正直なところ、私たちが反復的な展開をこれほど強く信じている理由の一部は、私が今自分の考えをいくつか共有できますが、最終的にどうなるか本当に興味があるからです。なぜなら、これは全く新しい製品形態だからです。しかし、現時点で私が最も注目している点は、以前にも議論したマルチモーダル入力を含みます。
司会者：それがお好きだと知っています。
Alexander：もう一つの例は、外部世界へのアクセスをもう少し許可することです。多くの人が様々な形式のネットワークアクセスを求めています。また、私たちが現在リリースしているユーザーインターフェースは、実際には私たちが反復してきたバージョンだと考えています。ここには面白い話がありますが、全体として、これは人々が役に立つと感じるインターフェースですが、最終的な形ではありません。私たちは、それが開発者が日常的に使用するツールにもっと密接に統合されることを強く望んでいます。これらは私たちが考えているテーマの一部です。しかし、明確にしておきたいのは、私たちは常に反復を続け、答えを見つけ出すということです。
司会者：正式リリース後の価格設定が心配ですが、今は無料で利用させてもらいます。利用しない手はないでしょう？
Alexander：価格設定についても、ぜひフィードバックをお願いします。
司会者：価格設定について話すのはまだ早いですか？
Alexander：はい、まだ早すぎます。
司会者：そうですか。Claude Codeの状況を考えると、それは確かに皆が心配している点です。Claudeはすでに固定料金と変動料金を導入し始めていますが、それがひどい状態になっていると感じています。標準的な答えはありません。誰もが、得られる中で最も安価なコード処理能力だけを求めています。ですから、頑張ってください。
Alexander：ありがとうございます。
Josh：私の見解は、私たちの目標は莫大な価値を提供することであり、それを実証し、「わあ、これは私にとって経済的に非常に価値のある仕事をしている」と人々に本当に認識させる責任があるということです。多くの価格設定の問題は、この点から出発できると考えています。しかし、私はこの会話がここから始まるべきだと思います。私たちは本当にその価値を提供しているのか？
司会者：素晴らしいです。それでは。お二人とも本当にありがとうございました。皆さんの努力に感謝しますし、お時間を割いてくださったことにも感謝します。私たちはこの日をずっと待っていましたが、OpenAI全体としてエージェントに対してますます真剣になっていることを、皆が理解し始めていると思います。これは単なるコーディングではありませんが、コーディングは明らかに自己加速する閉ループであり、皆さんもそれに対して情熱を注いでいることと思います。これらを見るのは本当に励みになります。
Alexander：このコーディングエージェントを皆様にお届けできること、そして最終的にそれを汎用AGIスーパーアシスタントに統合できることを大変嬉しく思います。お招きいただきありがとうございました。
元のポッドキャストのリンク：https://open.spotify.com/episode/7soF0g9cHqxKaQWWJBtKRI