世界を動かす技術を、日本語で。

ジュールズ:非同期コーディングエージェント

概要

このプロセスは、GitHubリポジトリでNext.jsをv15にアップグレードし、appディレクトリ構造へ移行する流れを説明しています。 JulesというAIアシスタントを活用し、タスク割り当てからコード修正、PR作成、マージまでを自動化します。 各ステップでのやり取りや承認フローが明確に示されています。 音声による変更サマリー機能も含まれています。 効率的な開発・レビュー・公開の一連の流れを理解できます。

GitHubリポジトリでのNext.js v15アップグレードとappディレクトリ移行プロセス

タスク割り当てと指示

  • GitHubリポジトリとブランチを 選択 し、Julesにタスク割り当てを 実施 すること
  • "assign-to-jules"ラベルを Issue に付与し、直接タスクを 割り当て すること
  • 例:@kathy/flipdisc mainリポジトリで、Next.jsをv15へアップグレードし、appディレクトリ構造へ 変換 することを指示

Julesによる計画立案と準備

  • Julesがリポジトリを 取得 し、Cloud VMへ クローン すること
  • 最新のGemini 2.5 Proモデルを活用し、 開発計画 を立案すること
  • appディレクトリ構造への移行に伴い、 22ファイルの更新 を計画
  • 計画内容を 確認 し、"Continue"で作業の 継続 を指示すること

コード変更の確認・承認

  • Julesが 差分(diff) を提示し、変更内容を 迅速に閲覧承認 すること
    • 例:package.json内で "next": "10.2.3" → "next": "15.0.1" への バージョン更新
  • 変更内容を 確認 し、問題なければ 承認 すること

プルリクエスト作成とマージ

  • Julesが PR(プルリクエスト) を作成し、レビュー・承認・マージを 実施 すること
  • マージ後、 GitHub上で公開 すること

変更内容の迅速把握

  • Julesが 音声サマリー を生成し、変更内容を 短時間で把握 すること
  • ブランチを 公開 し、音声サマリーも 活用 すること

この一連の流れにより、Next.jsプロジェクトの大規模アップデートと構造変更を 効率的かつ安全 に進めることが可能です。

Hackerたちの意見

すごい、GoogleとMicrosoftが同じ日に発表をするタイミングを合わせたみたいだね。もしかしたら、どちらかがもう一方の発表より早くなると思って急いだのかも。ワクワクする時代だね!

今週はGoogle IOとMicrosoft Buildが同時にあるね。注目を集める発表のバトルだ。

そうだね、みんなワクワクしてるのが伝わってくるよ。

OpenAI Codex Research Previewの発表の直後にこの2つの発表もあったけど、実質的には同じ製品だよね。

Googleが無料で推論を提供できるのは、他の企業に対する大きな競争優位だね。> ジュールは無料なの? > うん、今のところジュールは無料だよ。ジュールはベータ版で、使用から学ぶ間は支払いなしで利用できるんだ。将来的には価格を導入する予定だけど、今は開発者体験の向上に集中してるよ。

でも、ここでの製品は君自身だよ。EDIT: 法的リンクはここでは機能しないね。> いいえ。ジュールはプライベートリポジトリの内容でトレーニングしないよ。プライバシーはジュールのコア原則で、私たちは君のプライベートリポジトリをモデルのトレーニングに使わないんだ。君のデータがジュールを改善するためにどう使われるかについてもっと学ぼう。データ収集がどうなるかは分かりにくいけど、君の会話がトレーニングデータの一部になる可能性が高いね。リポジトリの内容のようなコンテキストが含まれるかどうかは不明だけど。

Googleが無料で推論を提供できるのは、他の誰よりも大きな競争優位だよね。自分はまだJulesを試してないけど、Codexで遊んでるところ。正直、無料かどうかはあんまり気にしてないかな。他のものよりも自分の問題をうまく解決してくれるなら使うし、そうじゃなければ他のものを使うよ。コストよりも、どれだけうまく機能するかに焦点を当ててるのは自分だけじゃないと思う(ある程度まではね)。

制限があるね: > 同時に2つのタスク > 1日に合計5つのタスク

これはスタートアップの標準的なやり方だね。無料のベータ版を用意して、そこから価格設定に移行する。

これ(そして大手テック企業の伝統だって知ってるけど)がダンピングと同じ経済的影響を持ってる気がする。 https://www.investopedia.com/terms/d/dumping.asp

OpenAIは2024年に50億ドルの損失を出して、2025年にはその損失が倍になるって言われてるよ。今のところ、それがプレイするためのコストって感じかな。

GoogleとMicrosoftは、カスタムのエンドツーエンドシステムよりも、まずは低レベルの自動化に注力することを賢く選んだね。深さよりも幅ではなく、むしろ能力よりも信頼性を重視してる。エージェント開発の観点からいくつかの利点があるよ: - アクセスが少なくて済むから、災害のリスクが低くなる - 構造化されたタスクは、より良い強化学習のためのデータを増やす - リスクが低いから、タスクやプロセスレベルの信頼性が向上し、シニアレベルの仕事で意味のあるエンドツーエンドの結果を得るための前提条件になる - ジュニアレベルのタスクでも、インターフェースや統合を正しくする必要があって、これはスケーラブルなデータとトレーニングパイプラインにも必要だね。エージェントコーディングの展開段階にやっと入ったみたいで、具体的な製品なしに見えるアウトラインから必然的に生じる持論から解放されるのは嬉しいね。

そのコピーにはちょっとしたニュアンスがあるね。「やりたいことに時間を使おう!」って、ゲームをしたり、自転車に乗ったり、本を読んだり、卓球をする画像が続いてる。全部いいと思うけど、コーディングは避けるべき面倒なことだって言ってるみたいで、クリエイティブで楽しい活動だとは思えないな。

彼らは、君が書きたいコードに集中できるって言ってるんじゃないかな、何であれ。特に最初の行が「ジュールは君がやりたくないコーディングタスクをやる」って言ってるからね。最初の画像は誰かがコンピュータで作業してるように見えたよ。あるいは、自分の好きなことをするために時間を取り戻すってことだね - 例えば、自転車や卓球など。

探索する価値のあるニュアンスだね。世の中は、最小限の努力で仕事をしたい時計を気にする人たちのために最適化されている。もうすぐ(もしまだなら)自分の仕事を楽しむ人たちが、自分でやりたいと思うことを嘲笑されるようになるだろうね。

なんか、コーディングが避けるべき面倒な作業だって言ってるみたいに感じる。クリエイティブで楽しい活動じゃなくて。たまに楽しみでコーディングするけど、普段はあんまりしない。プログラミングは最後の手段として使うツールだと思ってる。目標を達成するための最善の方法がコーディングじゃないなら、普通はコーディングなしでできる方を選ぶよ、トレードオフが本当にひどくない限りはね。

うん、趣味でプログラミングするのが好きなんだ。このセールスピッチは、俺のために自転車に乗ってくれるロボットを売ろうとしてるみたいだ。ちょっと待って…自転車に乗るのが好きなんだよ!

楽しさは前に進む力を維持できるかどうかに関連してると思う。もし、何かをするのに複雑なプロセスがある会社で働いてるなら、このピッチは響くかも。特に、リーダーシップがAIに飢えてるけど、もっと意味のある変化にはあまり興味がない場合はね。

正直言って、95%の人はコーディングよりもゲームをしたり自転車に乗ったりするのが好きだと思うよ。

フードデリバリーの配達員を入れるべきだったね。

ほんとに馬鹿げてる。上司がジュールズが仕事してるからって、昼間にテニスしに行くのを許すわけないじゃん。もしこれらのツールが言われてる通りに人を20-100%も生産的にするなら(私は疑ってるけど)、その価値は労働者じゃなくて所有者に集まることになるよ。

バグを直したり、同僚のコードを直したりしたくないってことも含んでるけど、それが開発者として一番好きなことなんだよね。バージョンアップも全然気にしないし、「テストを書くのが好きじゃない」理由は、「良い」テストを書くのが開発で一番難しいから(何をテストすべきか、なぜテストするのか、何をモックするか、いつするか、常にエッジケースを忘れてる気がする…)で、AIはまだテストを書く部分が苦手で、しばらくはそうだと思う。

もしかしたら、あなたのコメントを読んでスローガンを変えたのかも?それはこうだよ: > あなたが書きたいコードのためのもっと多くの時間、そしてその他すべて。今。

"やりたいことをして時間を過ごそう!" - かっこいい新しいコードを書くのが好きだなぁ…。

それがAIエージェントが売りたいポイントだと思う。やりたいコーディングタスクにもっと時間を使って、やりたくないタスクには使わないように。

興味があったから、試すボタンをクリックしたら、また待機リストだった。GoogleはGmailでうまくいった方法がもう通用しないことをいつになったら学ぶんだろう。今は遊ぶためのキラキラしたおもちゃがたくさんあるから、明日にはこれのことなんて忘れてるだろうな。

何かをリリースしなきゃならなかったんだろうね、OpenAIはめっちゃ速いペースで動いてる。

この方法は確かに効果があるけど、友達に自分の製品を褒めてくれる忠実な支持者が必要だね。できれば、すでに君のところに来てるユーザーがいるといい。

Googleは待機リストと地域制限で死ぬだろうね。

発表されたときに待機リストにサインアップしたけど、今日招待状が来たよ。

もし自分の番が来た後にすぐにサインアップしなかったら、サービス自体を逃しちゃうかもしれないよ、だってGoogleがもうシャットダウンしちゃってるかもしれないから。

今日はリリースするつもりじゃなかったと思うし、準備もできてなかったけど、GitHubの後を追ってると思われたくなかったんだろうね。

つまり、これにGitHubの課題を割り当てて、処理して、結果を統合して、バグを修正済みとしてマークできるってこと?もし「リードデベロッパー」AIを追加して、バグを書き出して、割り当てて、作業を「レビュー」させたらどうなるんだろう。それから「ボス」AIを追加して、リードデベロッパーAIに新しい機能の要求をする。ボスAIがプログラムを実行して、何らかの方法で体験を検査して、もっと具体的な変更を要求できるかもしれない。しばらくそれを動かしてみたらどうなるんだろう。多分、何か狂ったノイズに変わってしまうだろうけど、見るのは面白そうだね。これをスタートアップシミュレーターとしてパッケージ化して、小さなアリの巣のように、彼らのメモアプリがどう進んでいるかを見ることができる。

実際、エージェントのための良いパターンだよ。アナリストエージェント、意思決定エージェント、レビューエージェントを使って価格設定システムを作ったんだ。彼らはポリシーに従った決定を下すために協力してる。時々彼らがおしゃべりしてるのを見るのは面白いよ、ちゃんと役割を果たしてるし、意思決定エージェントがアナリストにポリシーのガイダンスを求めると、拒否して自分の役割は分析だって説明するんだ。でも、そうやって間違いを見つけることも多いし、役割演技がいい結果を生むんだ。

ユニコーンを求める「VC」AIはどうなるの? :D

To-doアプリがノート取りアプリに取って代わられたっていうメモを見逃したみたい。 1. https://todomvc.com

直感的に、すぐにおかしくなると思う。

エージェントシステムで人間レベルの反エントロピーを達成するには、かなりの時間がかかると思う。複雑なシステムはたくさんの反復が必要で、各反復の信頼度は、反復間で良い再調整システムがないと下がっちゃう。パワー法則によれば、繰り返しの些細な劣化はすぐに混沌に変わるんだ。意味のある複雑なプロジェクトでの人々の協力には、軌道修正のために大量の反エントロピーが必要になるよ。ドキュメントには載ってないし、経験から来るもの(やったことある)、常識的なもの、集団知性のものもある。

ステロイドを打ったコンウェイのライフゲームを思い出す。

この列車を止めて!降りたいんだ。

これからわかるね。今の私たちの集団的な軌道だ。これから数年の間に役立つスキルセットは、いろんな形のAIツールをうまく管理する能力だと思ってる。[2] - 文字通り、自分のAIをリードしたり、パフォーマンスを評価したり、全体をうまくビジネスの成果に向けて動かすことが大事だよ。

あなたは大きな問題の枝から一つの幻覚を感じているようで、たくさんのトークンが無駄になっているね。

それからボスAIを追加する これがもっと現実的な気がする。ロボットは感情を気にしないから、道徳的な問題なしに決定を下せるよね。

人の管理が嫌だったから、マネージャーじゃなくてエンジニアになることにしたんだけど、今は人みたいに話すロボットを管理しなきゃいけないみたい。少なくとも、思いやりを持たなくてもいいから楽だよね。もしスタートアップがAIエージェントの人事を始めたら、やばいけど。

今、一番大事なのは共感だけだね。

依存関係ツリーを壊さずに「バージョンアップ」ができるのを本当に楽しみにしてる。Dependabotがほぼ正しくやってることだけどね。セキュリティの観点から見ると、アプリを壊さずにほとんどの脆弱性を修正するライブラリをアップデートできるのは素晴らしいことだよ。今のところ、どのツールもそれを実現してないから、コードと壊れる変更に気を配ってほしいな。

これは興味を測るためのスタートアップの立ち上げみたいだね(ウェイトリストを作って、誰が反応するか見る感じ)。