AIが直した後は何を確認？【後編】ChatGPTのレビュー・Git・Worktrees

前編はこちら：フック・接続・Cloudの使い分け

ChatGPTの設定で迷う方へ【前編】コーディング7項目と作業場所の選び方

こんなことありませんか？ 

AIから修正できたと返事があっても、本当に動くのか、変更を残せているのか、もう公開してよいのか判断できない。

ここでは、ChatGPTのコーディング設定7項目の後編として、コードレビュー、Git、Worktreesを使って変更を確認する考え方を書いていきます。

結論は、点検すること、履歴に残すこと、外へ届けることを分けることです。前編で作業場所を整理した方や、ファイルを直してもらった後の確認で迷う方に向けて、練習用の案内ページを例に手順を説明します。

5．コードレビュー：変更を読んで問題の可能性を点検する

コードレビューは、プログラムの変更内容を読んで、間違いやほかの部分への影響を点検する作業です。

AIに、どこが変わったか、どんな条件で問題が起こりそうかを説明してもらえます。ただし、何を正しい動きとするかが分からなければ、意図どおりかを十分に比べられません。

見直したいファイル、変更の目的、期待する動きをそろえてから頼みます。実画面は設定一覧の入口であり、詳細パネルの全項目を示したものではありません。

作文の見直しと、実際に動かす確認は違う

作文を読み返して意味や書き間違いを見るように、レビューでは変更の内容を読んで確認します。実際にプログラムを動かして確かめる作業は「テスト」です。

たとえば、申込ボタンを押したときの動きや、スマートフォンでの表示は、実物を動かす確認も必要になります。

レビューで指摘がないことは、すべての動作が正しい保証にはなりません。 何を読んだか、何を実際に動かしたか、まだ確認していない点は何かを分けて受け取ります。

手元の変更と、プルリクエストのレビュー

手元のGitの変更を確認する方法と、共有先への取り込み提案を確認する方法があります。プルリクエスト、略してPRは、この変更を共有している本体へ取り込みませんか、という提案のまとまりです。

手元のプロジェクトでは、入力欄の「/review」から、基準のブランチとの比較や、まだコミットしていない変更の確認を選ぶ方法があります。ブランチとコミットは、この後で整理します。

レビュー結果を読むことと、共有先へコメントを書くことは別です。 今回は点検だけなのか、修正や外への投稿も頼むのかを指定してください。

依頼するときは、正しい動きを先に伝える

「ボタンを見てください」だけでなく、「押すと、指定した案内ページが開く想定です」と、比べる基準を伝えます。

依頼例：今回の申込ボタンの変更をレビューしてください。指定した案内ページを開く想定です。リンクの間違い、意図と違う動き、スマートフォン表示への影響を点検してください。修正や外部へのコメント投稿はせず、該当箇所と理由を返してください。

返答では、対象の変更、問題が起きる条件、確かめ方を読みます。実行した確認と、実行できなかった確認も示してもらうと、次に何を確かめるか判断できます。

6．Git：ファイルの変更を履歴に残す

Gitは、ファイルの変更履歴を管理する道具です。似た名前のGitHubは、そのリポジトリをネット上で管理・共有するサービスの一つです。

ファイルを「最終版」「最終版2」と増やす代わりに、変更の区切りと理由を履歴へ残します。ただし、Gitを使うだけで、すべてのファイルや未記録の変更を戻せるわけではありません。

アプリ内のGitの道具で差分や変更を確認する際も、どのプロジェクト、どの作業場所を操作しているかを確かめます。

最初に知っておきたいGitの言葉

図の六つの言葉は、変更を見る、記録する、別の案を進める、共有する、といった役割の違いを表します。

たとえば、文章とボタンを直しても、今回はボタンの変更だけを記録したい場合があります。差分を確認し、記録する変更を選んでから、コミットで履歴に残します。

関係のない変更を、今回の記録に混ぜないことが大切です。AIには、変更したファイルだけでなく、記録する対象も説明してもらいます。

Gitの設定で決められること

ブランチ名の付け方や、コミット・PRの説明を作る指示を整えられます。「修正した」だけよりも、何を、なぜ変えたのかが読み取れる説明の方が、後から見直せます。

強制プッシュは、共有先の履歴を書き換える可能性がある操作です。普通の保存と同じ感覚では扱わず、チームの決まりと影響する作業を確認します。

命名や説明のルールは自分のプロジェクトに合わせます。設定をそろえることと、今回の変更が正しいことは分けて判断してください。

保存、コミット、プッシュ、公開を分ける

保存はファイルへの反映、コミットは履歴への記録、プッシュは記録した変更を共有先へ送ることです。ウェブサイトの公開・更新とは、作業の意味が異なります。

ただし、共有先へ送ると自動で公開される仕組みもあります。どの操作が本番の更新につながるかを、先に確認します。

依頼例：今回の変更だけを差分で説明し、実行した確認と未確認の点を示してください。コミットやプッシュは、今回は行わないでください。

7．Worktrees：別の変更を、別の作業場所で試す

Worktreesは、同じGitプロジェクトに別々の作業フォルダーを用意する仕組みです。各場所にはそれぞれファイルがあり、Gitの履歴の情報は共有します。

文章を直す案と見た目を変える案を同時に進めたいときなどに使えます。単にチャットを二つ開くこととは違い、実際にファイルを編集する場所を分けます。

手元のパソコンに作ったWorktreeなら、そのパソコンで作業します。Worktreeを使うだけで、クラウドへ移るわけではありません。

案内ページの日時とボタンを、別々に直す

学校行事の案内ページで、Aの作業場所では日時の文章、Bではボタンの見た目を直す例です。同じサイトの違う変更を、それぞれの場所で試します。

これは仕組みを説明する仮の例です。実際に制作・公開した成果を示したものではありません。

分けて作業しても、取り込む前の確認は必要です。同じ箇所を直せば、変更を合わせるときに調整が必要になることがあります。 作業場所を分けることは、競合がなくなる保証ではありません。

Gitのブランチとの違い

ブランチは、変更を進める流れを分けるものです。Worktreeは、ファイルを広げて編集する場所を分けるものです。

A案とB案という作業の道筋と、それぞれの案を広げる机、と考えると違いをつかめます。別のチャットを開いても、同じフォルダーを使っていれば、同じファイルに影響する可能性があります。

画面上のチャット名だけで判断せず、作業先のフォルダーとブランチを確認します。

初めてWorktreeを使うときの流れ

Gitで管理されているプロジェクトかを確認し、新しい作業でWorktreeを選びます。出発点にするブランチを選んだら、作られた別のフォルダーで変更と確認を進めます。

そのまま続けるか、普段の作業場所であるLocalへ引き継ぐかは、確認後に決めます。「Handoff」は、チャットとGitの作業状態を引き継ぐ操作です。

同じブランチを複数の作業場所で同時に開く制約もあります。フォルダーを普通にコピーする感覚で進めず、出発点と引き継ぎ先を確かめてください。

設定で確認するものと、足りなくなりやすいもの

保存先、管理する数、自動整理の設定を確認します。作業場所が増えると、ファイルだけでなく、動かすための部品なども容量を使います。

普段のフォルダーにだけある設定や、Gitの対象から外しているファイルは、新しい場所へ自動でそろうとは限りません。必要な道具を準備するローカル環境のセットアップも関係します。

作業場所を整理する前に、必要な変更が残っているかを確かめます。 保存先を変えたり整理したりする前に、どこで何を直したかを説明できる状態にします。

迷ったら、どこにある何をどうしたいかから選ぶ

接続は別の機械を使う入口、Cloudはクラウドに準備した環境、Worktreesは同じGitプロジェクトの作業場所の分離です。

「サイトを直したい」よりも、「家のパソコンにある練習用サイトで、トップページの日時だけを直したい」と伝えると、対象と範囲を絞れます。

手元のフォルダーで足りる作業なら、最初から接続先や環境を増やす必要があるとは限りません。目的を決めてから、必要な入口を選びます。

読む、変更する、記録する、外へ届ける

ファイルを調べること、書き換えること、Gitに記録すること、共有・公開することは、依頼する範囲が違います。

今回はどこまで進めてほしいかを、最初に伝えます。確認が必要な操作は、機能、環境、設定、依頼内容などでも変わるため、画面に出る案内も読んで進めます。

何を任せるか迷う場合は、まず読むところまでを頼み、対象と変更案を確認してから次の作業を決める方法があります。

案内ページづくりを、準備から確認まで分ける

ここからは、学校行事の日時、場所、持ち物を知らせる練習用ページを考えます。完成や公開を行った実績ではなく、依頼の組み立てを示す例です。

資料をそろえる、作業場所を決める、小さく変更する、表示と内容を点検する、履歴と公開を判断する、という順番で進めます。

最初からすべてを一度に頼まず、結果を確かめられる区切りを作ります。

1．まず、伝える内容をそろえる

日時、場所、対象者、持ち物などの資料をまとめ、使ってよいファイルを指定します。既存ページを直す場合は、元のファイルと変更したい内容も渡します。

資料にない日時や決まっていない申込先を、AIに推測で埋めさせないようにします。分からないところは未確認と残してもらえば、人が確かめる場所を追えます。

公開用の連絡先や個人情報を含む資料は、載せてよい内容かを先に確認します。

2．次に、作業場所を決める

練習なら、手元に専用フォルダーを用意して始める方法があります。繰り返し使う環境が必要ならCloud、別のパソコンのプロジェクトなら接続を検討します。

同じプロジェクトで別々の案を試す必要があるなら、Worktreeが候補になります。目的が一つなら、場所を分ける必要があるかを先に考えます。

依頼の最初に作業先を説明してもらい、使いたい資料がそこで読めるかを確かめます。

3．変更をお願いするときは、範囲を小さくする

依頼例：練習用の案内ページを作りたいです。指定した資料の日時、場所、持ち物だけを使い、まず構成案を示してください。資料にない情報は未確認とし、外部への公開は行わないでください。

構成案を確認してから、文字の大きさやボタンの配置などを一つずつ決めます。変更するファイルを説明してもらうと、結果を追いやすくなります。

一度の依頼で変える範囲を絞れば、何が原因で表示や動きが変わったかを確認しやすくなります。

4．表示とレビューで、別々の確認をする

ブラウザでページを開き、文字が読めるか、必要な情報が見えるか、リンクが正しいかを確認します。ブラウザは、ウェブサイトを見るための道具です。

コードレビューでは、変更した内容やほかの部分への影響を点検します。どちらの確認を実施したかを分け、実行できなかった確認も残してもらいます。

確認の報告を受け取ったら、実際のページと照らし合わせて、直したかった問題に答えているかを見ます。

5．履歴を残してから、公開を別に判断する

確認した変更を選び、理由の分かる説明を付けてGitに記録します。共有するなら、送り先やPRで点検する進め方も確認します。

ただし、日時が確定しているか、連絡先を載せてよいか、申込先が公開用かは、人が判断する必要があります。履歴に残せたことを、公開してよい根拠にはしません。

繰り返す確認がはっきりしてきたら、前編のフックの利用を検討できます。まずは必要な確認を把握してから、自動化する処理を考えます。

使えないときは、止まっている段階を確かめる

設定項目が見えていても、利用に必要な条件がそろっているとは限りません。接続、環境の準備、認証、作業先の道具など、どこで止まったかを図と照らし合わせます。

原因が分からない場合は、何をしようとしたところで止まったか、どんなエラーが出たかを伝えます。パスワードや秘密の値は、そのまま貼り付けないでください。

原因を確認する前に、フルアクセスや強制プッシュへ変える必要はありません。対象や接続先の取り違えなら、権限を広げても解消しません。

最初の依頼は、六つの条件をそろえて小さく試す

目的、対象、作業場所、変更範囲、確認方法、止める場所をそろえます。AIの返答では、案を考えたのか、ファイルを変えたのか、動かして確かめたのかを読み分けます。

依頼例：この練習用ページで、資料にある日時と場所を見つけやすくしてください。作業先と変更するファイルを先に説明し、変更後は表示とリンクを確認してください。実行できなかった確認も示してください。コミットや外部公開は、今回は行わないでください。

この記事の要点は、次のとおりです。

直した内容と確認結果を見比べ、履歴に残すことと公開することを別々に判断する。

今日の一歩として、上の依頼例を自分の練習用ファイルに合わせて書き換えてみてください。まず小さな変更と結果の確認までを行い、次の作業を決めます。

自分の仕事で何をAIに任せ、どこを人が確認すればよいか迷う場合は、AI活用のお悩み解決でご相談いただけます。現在の作業と困っている点をもとに、ツールの使い方や進め方を整理する相談です。