概要
上記の記事のように Jules という自律型コーディング AI エージェントが発表され、 2025/06/01 現在でベータテスト中ということで使ってみた。ご存知の方も多いと思うが Github Copilot や Cursor のように伴走するようなエージェントではなく、 Devin 同様に指示出ししておけば AI が勝手にコードを書いたり修正したりしてくれるものとなっている。 GitHub と接続して作業レポジトリとブランチを指定し下記のように指示を出す。
すると Jules が実装計画を投げてくるので Approve すれば、あとは待っているだけで PR が上がってくる。ちょうど Gemini DeepResearch と同様の UX である。今もこの記事の作成中裏で Jules はコードを書いている。
下記から試せるので使ってみたい方はここからアクセスしてみてください。
βテストでできること
記事作成時の 2025/06/01 日本時間では下記ができる。
- 5 並列でのタスク実行
- 日に 60 回までのタスク実行制限
- 日に 5 回のコードキャスト
60 回もタスク実行できてしまうのでこの土日で遊ぶ分には非常に楽しめた。ただ制限はテスト中に変わるでしょうからあくまで現時点のものである。
書いている人のバックグラウンド
やれることのレベル感をお伝えするのにバックグラウンドがないと厳しそうなので記載しておく。
- キャリア感
- Web エンジニア 13 年目
- バックエンド・インフラ・マネジメント寄り
- 最近はプロダクションコードはまあ書いていない
- AI エージェントの導入具合
- 4 月くらいから Cursor 使っている
- Devin 使いたいけどほんま小粒が多くて使えてない
- プライベート
- 2 歳, 4 歳の子どもあり共働きフルタイム家事育児半々
なお今回採用した tauri + React + TypeScript は TypeScript は普段使っているものの私には他の２つは知見がまったくない。
何をしたのか
VOCALOID や UTAU といったピアノロールを利用した歌声合成の UI の入りを作ろうとしてみた。環境は Windows ネイティブ。最初のプロンプトに書いたとおりだが下記のような感じ。
tauri の UI 部分にボーカロイドや UTAU, Synthesizer V などのようなメロディを扱うピアノロールを作ってください。 ピアノロールの下にはコントロールカーブなどの編集スペースを作るためあとから入れられるようにするか、ピアノロールを独立したコンポーネントとして作るかしてください。
これをプロンプト変えながらわーわー言って作ってもらった。なお私は今回コードを一行も実装していない。
何ができたのか＆感想
２日間、子どもの世話と買い物と家事をしながら合間を見て指示出しをする形で、自分は一切コードを書かずに Jules だけにコードを書かせてみた。できたものとしては下記のような感じ、自分で集中する時間取って書くより数倍では効かないくらい早い。というかそも二児の世話と家事を半分していたら集中タイムなんてほぼゼロでなにも作れないんだからゼロの何倍かは測れない。これで家事と育児はちょっとしかサボっていない（と思っているものの配偶者に言わせれば噴飯ものかもしれないが）ので驚異的だ。
案外マネジメントやりながらのコード修正に近い感じがして、慣れたコードベース上であればおそらく自分より実装の早い自分の分身（ただし指示は多めに必要なエージェント）に実装を任せられる。これはマネージャー等実装に時間の割けない人間にとってはかなりの革命のように思う。とはいえ指示出しとコンパイルは実施しているわけでそのための時間はどうしても必要。実装面側は久しくメインで実装業務をしていないので、そちらの視点の感想は他の方に譲るとする。
また、生成物は下記のレポジトリに出力しているので興味がある方は参照ください。
TIPS と気になった点
プロジェクトの初期構築は毎回構成が異なるので自分で誘導したほうがいい
何回か tauri のプロジェクトを作ってもらったが、そもそも外部からのファイル作成数上限に引っかかりうまくいかないときもあるし、毎回構成が違う。パッケージマネージャが pnpm なのか npm なのか yarn なのか。指示出ししていない私が悪いと言われればそれはそう。でも知識ゼロだったんだもん、 Gemini にでも聞いたら良かったか。
ビルドやテストを実行してほしいときはきちんと指示すること
最初何回か自信満々に Jules が出してくるコードを手元でビルドするとビルドが通らない。子どもが騒いでるから全部消して指示出しし直そう、みたいなことが２～３回あった。有料版になると値段が怖いので指示出しちゃんとしましょう。
これは X で下記のように AK Kulkarni 氏（Jules の PM の方とのこと）から教わりましたがこうしておくだけでちゃんとビルドとテスト通してくれるようになるのですごい。氏に感謝。
That’s great! Jules has the ability to actually run the code - try to ask it to compile the code after it’s done and verify its changes. You might have to be a bit forceful and give it some help (we’re working on making this easier)
— AK Kulkarni (@itsakdev) 2025年5月31日
指示出しは具体的に
当たり前体操。これは Cursor でも同じなので設計が頭にあるならちゃんと言葉にしておく必要はある。私は上述の粒度で指示してうまく行ったように感じる。ただし React のところは正直私のレベルが低すぎて私と同等よりちょっと良いくらいにしかなってないと思う。
コンテキスト保持強めっぽいので一貫するタスクは一つのタスクでやる
Gemini は DeepResearch と素の 2.5 Pro をよく使っているのだが、コンテキストを長期間保持できた上に薄まらないし判断を間違えない印象がある。今回面白かった例を挙げておく。
PianoRoll の実装タスクで下記のように指示を出した。
このアプリでは VOCALOID や UTAU, Synthesizer V と言った歌声合成に関わるエディタを作ろうとしています。今回はフロントエンド側のデータ構造のうち、特に Note について UI を作っていきます。３つのコンポーネントを作ります。
* PianoKeyboard コンポーネント
* PianoRoll の左に表示されるピアノ鍵盤を表す
* 白鍵・黒鍵によって色分けされており鍵盤ごとにノート名、 C6 などが書かれている
* C6, note=60 のところは基準ドなのでハイライトされたい
* 0-127 の 127 ノートを表示し、それ単体では表示域の調整を持たなくてよいです
* PianoRoll コンポーネント
* ピアノロール本体で 0-127 まで表示されそれ単体では表示域の調整を持たなくてよいです
* 罫線についてはアーキテクチャ上非常に要素が増えてしまうので div 等ではなく canvas で実装してください
* PianoRoll 上にノートが配置されるようにしてください
* Note コンポーネント
* ノートの表示と編集を行うコンポーネントです
* クリックで選択できます
* 選択時に Del キーで削除できます
* 選択時に Enter キーでテキストボックスによる歌詞の修正ができます、再度 Enter で確定し Esc でキャンセルします
* 選択時に Tab で次のノートが選択されます
* ドラッグ＆ドロップで位置と音高を変更でき音高はグリッドにひっつく形にします
* 右端をドラッグ＆ドロップで長さを調整できます。
作成後テストが必要ならテストも追加してください。
README.md を変更に合わせ更新してください。必要とあらばファイルを分割し、 README.md からリンクをはるかたちにしてもよいです。
最後にビルドやテストなど README.md 上の手順をひと通り試しコマンドが正しく実行できるようにしてください。
この指示からできた UI がこれ。
なんやねんと思ったが指示が悪い。普通はボカロエディタなんて使ったことないもんね、と思い直しそれなりにしっかり作られているので再指示を実施。
1. PianoKeyboard の向きは、垂直方向に変更し、各鍵が PianoRoll のノートの高さ（ピッチ）に対応する形でよろしいでしょうか？（例：上が高音、下が低音）
2. PianoKeyboard と PianoRoll を「くっつけて表示」とは、隙間なく配置し、各鍵の高さとピッチレーンの高さを一致させるという理解でよろしいでしょうか？
3. PianoRoll の黒鍵部分の薄い色は、黒鍵に相当するピッチの行（レーン）に薄い背景色を付けるという理解でよろしいでしょうか？
詳細を教えていただけると幸いです。
再質問あり、急に日本語喋るじゃん助かる。
2. 良いです。ただし PianoKeyboard の幅を調整できるよう、 PianoKeyboard と PianoRoll の間の境界線をドラッグアンドドロップでサイズ変更する可能性はあります。
3. あってます！色については一旦お任せします。
再回答して出てきたのがこれ。
それなりに良さそうなので再指示。
PianoRoll を表示しているエリアの Piano Roll Area のラベルは不要です。
PianoKeyboard を表示しているエリアの Piano Keyboard Area のラベルは不要です
PianoRoll を表示しているコンポーネントにパディングなどの設定があるので０にしてほしいです
PianoKeyboard を表示しているコンポーネントにパディングなどの設定があるので０にしてほしいです
PianoKeyboard の白鍵の高さをしっかり見るために境界線を 1px 追加してください
PianoKeyboard の黒鍵の幅は白鍵と同じで良いです。ビジュアルよりこちらを優先してください
PianoKeyboard と PianoRoll のスクロールを同期させてください
1点確認させてください。「PianoKeyboard と PianoRoll のスクロールを同期させてください」についてです。 現状、これらのコンポーネントは全域（0-127鍵）を表示しており、単体ではスクロール機能を持っていません。App.tsxのメインコンテンツエリアにスクロールが発生する場合、その親のスクロールを同期させるイメージでしょうか？ それとも、各コンポーネントに表示範囲を限定する機能（例：画面に収まらない場合にスクロールバーを出す）を追加し、そのスクロールを同期させるイメージでしょうか？
この点をもう少し詳しく教えていただけますでしょうか。
現状、App.tsx 内の main-content という div が PianoKeyboard と PianoRoll を含んでおり、この main-content が画面の高さを超える場合にスクロールします。
この main-content のスクロールを同期させる、つまり main-content がスクロールされたら、PianoKeyboard と PianoRoll の表示されている部分が常に同じ高さになるように調整する、という理解でよろしいでしょうか？
この理解でよろしければ、新しい計画を立てさせていただきます。
これで出てきたのが成果物なので同一タスク内での一貫性がかなり良いように思う。 Gemini のコンテキスト窓が長いのは感じていたけれどちょっとすごいと思った。
とりあえず記事にしておくべきだと思ったのでこんなもん、今日はここまで。
