第2章 · Lesson 06 / 17

やる一周を完結する

変更を確認し、反映を決める

差分と Pull Request を恐れない

  • 目安 15 分
  • 進捗 6/17

このレッスンのゴール

  • Pull Request を『変更の提案書』として説明できる
  • 差分で見るべきポイントを挙げられる
  • マージと差し戻しの判断基準を持つ
操作イメージ3 ステップ
Pull Request の確認イメージ。要約 → Files changed → チェックリスト → マージの流れ
  1. Conversation で Agent の要約を読む
  2. Files changed で意図しない変更がないか見る
  3. 問題なければ Merge(反映)
コードが読めなくても、要約・差分・チェックリストで判断できます。

Pull Request は提案書

Pull Request(よく PR と略します)は、「この変更を本番の流れに入れてよいですか?」という提案です。Agent が作業を終えると、この提案の形で返ってくることが多くあります。

まだマージしていなければ、main ブランチ(本番に近い本線)は変わっていません。安心して中身を読めます。

非開発者が見るチェックリスト

コードが読めなくても、次は確認できます。

  • 意図した画面・文言だけが変わっているか
  • 関係ないファイルまで大量に触っていないか
  • 秘密情報(鍵、パスワード、個人情報)が入っていないか
  • Agent の説明と、実際の差分の主張が一致しているか
  • 成果物(スクショ・動画・ログ)やプレビューがあれば、見た目と手順で確認する

成果物とリモートデスクトップ

Cloud Agent は、マージしやすい PR に加えて、デモ用の成果物(artifacts)としてスクリーンショット、動画、ログを残せます。文言や見た目の確認なら、差分より先に成果物を見る方が早いことが多いです。

Agent が動いているクラウド上のデスクトップを一時的に操作して、自分で画面を触って試す機能(remote desktop control)もあります。手元にブランチを落とさなくても、『動いたか』を体感で確かめられます。試し終わったら操作を返し、Agent に続きを任せます。

反映のしかた

問題なければ Merge(反映)します。チームによっては Approve(承認)が先に必要なこともあります。だめなら Close したり、追加コメントで Agent に修正させたりします。

スマホの Cursor アプリからも、差分確認やマージ操作が行えます。通勤中に確認し、大きな判断だけデスクで行う、といった使い方が現実的です。

理解チェック

  • PR が『まだ本番に入っていない提案』だと説明できる
  • マージ前に見る観点を3つ以上言える
  • 成果物(スクショ/動画)を確認の手がかりに使える

実践(ここが本丸)

実在する PR(Agent が作ったものか、過去のチームの PR)を1つ開き、上記チェックリストと成果物の有無でメモを取る。マージはしなくてよい。

いま身についている開発者スキル

コードレビュー / リリース判断