提案書とレビュー
レビューは誰が、いつ、何を見ているのでしょうか
作業中のPRと、確認を終えたPRの違いを見てみましょう。
01疑問
もう完成したの？
提案と完成を混同「PRできました」と連絡が来ました。もう使えるのでしょうか？
02体験
まだ下書きだった
下書きでも共有できるDraftは下書きです。変更は読めますが、まだ合流できません。
03仕組み
点検して直す
指摘を直して再点検AIが変更を点検します。重大な問題が残っていれば、直してから再確認します。
04納得
業務の意図は私が確認
役割を分けて確認私は変更の目的と画面を確認します。AIの合格だけでは終わらないのですね。
プルリクエストの一生はどう進む？
プルリクエスト（PR）は、変更を main へ合流させるための提案書です。5slab では、統合を頼む生成AIへの指示 /git land が変更を送信し、下書き（Draft）のPRを作ります。途中経過を見せるために /git save --push で送信して開くこともあります。下書きでも説明や変更内容は読めますが、マージはできません。「PRができた」は、完成や公開の合図ではありません。
状態やイベント名をクリックすると、その内容の説明がここに表示されます。
この図をテキストで読む
状態遷移図「プルリクエストの状態と合流までの道筋」。4状態・5遷移。 【状態】 1. Draft（作業中の見せる化）〔開始〕 2. Ready（正式な統合待ち） 3. Merged（本流への合流完了）〔終了〕 4. Closed（合流しない決着）〔終了〕 【遷移】（A —[イベント [条件] / 動作]→ B） - Draft —[push で差分を最新化]→ Draft（自己ループ） - Draft —[/git land でレビュー確認を通過し Draft を解除 [レビュー確認を通過] / Draft を解除]→ Ready - Ready —[squash マージで本流へ [検査が全部緑] / 履歴を集約して合流]→ Merged - Ready —[/git land が Draft へ戻す [レビュー後の変更・main の進行で印が失効] / レビュー印が失効]→ Draft - Draft —[方針変更による取り下げ]→ Closed 開始: Draft から始まる。 終了: Merged / Closed で終わる。 注記: どの状態からも取り下げ（Closed）は起きる 【流れ】 - 通常の経路: Draft →[push で差分を最新化]→ Draft →[/git land でレビュー確認を通過し Draft を解除]→ Ready →[squash マージで本流へ]→ Merged
依頼する人は、目的と結果を確かめる
PRの Conversation（会話）には、変更の目的や検証結果がまとまります。依頼する人は「頼んだことが含まれているか」「画面や業務の流れが合っているか」を見ます。分からないコードを無理に読む必要はありません。確認したい操作や、期待する結果をコメントで伝えましょう。
担当者は修正を手元に保存し、/git land でまとめて送信して同じPRを更新します。保存前には、パスワード入りの設定ファイル、手で直すべきでない生成物、今回と無関係な変更が混ざっていないか点検します。送信しただけではレビュー済みにはなりません。
秘密は履歴に乗せない
一度 push した秘密は取り消しても履歴に残り得ます。誤ってコミットしたら削除だけでなく、発行元での失効・交換が必要です。
生成AIが、枝の差分をまとめて点検する
コードの点検は、5slab のレビュー手順 cross-review に沿って生成AIが担当します。実行環境に応じて生成AIの道具（Codex や Claude）を使い、担当を切り替えた場合は記録します。main と作業枝の変更全体を見て、見落としを減らします。ただし、AIも誤るため、合格しても不具合がないという保証にはなりません。
重大な指摘が残る間は統合を止め、修正して再点検します。やり取りが堂々巡りになった場合も止めます。点検した版と結果は記録に残り、統合時に照合されます。後から変更を追加した場合や main が進んだ場合は、その記録をそのまま使わず、再確認します。
気になるセルはクリックで説明が出ます →
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表「誰が、何を確かめるか」。2列 × 4行。 【列】 1. 依頼する人（業務の意図と使い方） 2. 開発担当者・AI（コードと検査結果） 【比較】（観点ごとに） ■ 目的 - 依頼する人: 頼んだ変更が含まれるか - 開発担当者・AI: 変更が仕様と一致するか ■ 動作 - 依頼する人: 普段の業務ができるか - 開発担当者・AI: テストとエラーの確認 ■ 問題があるとき - 依頼する人: 操作と期待する結果を伝える - 開発担当者・AI: 原因を調べ、修正して再検査 ■ 公開前 - 依頼する人: 試した候補を指定して承認 - 開発担当者・AI: 候補と配備対象の一致を確認
押さえておきたい用語
- プルリクエスト（PR）
- Draft PR
- レビュー
- cross-review
- レビューの記録