ChatGPTの作業報告を読んでみよう

作業報告は4つに分けて読む

ChatGPTに記事の修正を頼んだ後、「本文を更新し、作業ブランチにコミット・pushしました。テストは未実行。本番には未反映です」と報告されたとします。専門用語が並ぶと難しそうですが、ひとつずつほどいてみましょう。

何を変更した？

最初に見るのは何を変更したかです。上の例なら記事の本文を更新しました。ただし、どの記事か、どこを直したかまでは分かりません。「変更した記事名と主な内容を教えて」と聞くと、依頼と結果を比べられます。

どこまで保存した？

次はどこまで保存したか。コミットは変更をGitの履歴に記録する操作、pushはその履歴をGitHubなどへ送る操作でした。作業ブランチにpushしたという報告は、作業の履歴をその名前の流れへ送ったことを示します。

確認と公開はどうなった？

そして何を確認したか。この例の「テスト未実行」は、失敗したという意味でも、成功したという意味でもありません。テスト自体をまだ行っていないという状態です。必要な確認が何かを聞き、結果と分けて考えましょう。

最後に公開状態を見ます。「本番には未反映」なら、GitHubに保存されていても一般の読者が見るサイトにはまだ表示されていません。こうして4つに分けると、短い報告でも次の行動を考えやすくなります。

報告を受けたら、依頼した内容と見比べることも大切です。「第5記事だけの修正」を頼んだのに、別の記事も変更されたと書かれていたら、意図した関連作業か、確認が必要な差分かを質問しましょう。

報告に書いていないことは、完了しているとも未完了とも決められません。たとえば「記事を更新した」とだけ書かれていれば、テストや公開の有無は別途聞きましょう。分からない点を不明なまま残すことが、正確な判断につながります。

なるほど！ まずは何が起きているか、ひとつずつ確かめればいいんだね。

ファイル・コミット・ブランチを見る

作業報告に `content/ai-articles.json` のような名前が出てきたら、それは変更対象のファイルを表しています。スラッシュで区切られた部分は、フォルダの中の場所を示すパスです。名前を覚えるより、どんな役割のファイルか聞いてみましょう。

コミットIDは履歴を探す手掛かり

コミットは、その時点で選んだ変更を記録したものです。報告に短い英数字があれば、コミットを識別するためのIDの一部かもしれません。IDは履歴を特定する手掛かりですが、それだけで内容の正しさや公開を保証するものではありません。

ブランチは変更の流れ

ブランチは、変更の履歴を分けて進めるための名前です。たとえば `feature/ai-note` という名前の作業ブランチに記録した場合、mainに自動的に入るとは限りません。mainとの関係は第7記事で詳しく見ます。

「どのファイルを何のために変更し、どのコミットを、どのブランチに保存した？」と聞けば、それぞれの役割を結びつけて説明してもらえます。長いコードやIDを理解できなくても、結果をたどる入口は作れます。

関係なさそうな変更があったら

また、変更一覧に自分の依頼と関係なさそうなファイルがあれば、何のための変更か尋ねましょう。他の作業のファイルを勝手に消したり元に戻したりせず、AIに状態と影響を確認してもらうのが大切です。

ファイル名だけでは、変更の中身までは分かりません。「記事のどの見出しや文章が変わった？」「画像は追加した？」と具体的に尋ねると、自分の依頼に沿っているかを確かめやすくなります。

成功・失敗・未確認を区別する

報告の「テスト」とは、決められた方法で動作やデータを確かめることです。文章の表示、リンク、プログラムの動きなど、確認する対象はさまざまです。すべてのテストがサイト全体のすべてを保証するわけではありません。

成功した範囲を確認

成功は、実行した確認がその条件で通ったということです。「パソコンでトップページを表示できた」なら、その結果は心強い情報です。ただし、それだけでスマートフォンや別の記事も確認できたとは言えません。

失敗した場所を特定

失敗なら、どの確認が、どの段階で、なぜ止まったのかを聞きます。記事の作成自体は終わっていても、画像の読み込み確認だけが失敗している場合があります。完了済みのことを含めて整理すれば、最初からやり直す必要があるか判断できます。

未確認は未確認のまま受け取る

未確認は、まだ確認していない、あるいは確認できなかった状態です。「問題なし」と同じではありません。環境の制約で本番の表示を確認できなかった場合も、確認できた範囲と理由を分けて受け取ります。

公開操作の結果が不明なときは、同じ操作を繰り返す前に実際の状態を確認してもらいましょう。「何を実行し、何が成功し、何が未確認か」を尋ねれば、重複操作を避ける助けになります。

「ブラウザで確認した」という場合も、どのページを、どの画面幅で確認したのか聞いてみましょう。トップページだけの確認と各記事の確認は違います。確認内容を細かく聞くのは、作業を疑うためではなく、次に必要な確認を選ぶためです。

分からない報告は質問に変える

報告の中に知らない言葉があっても、すべてを調べてから質問する必要はありません。文章をそのまま貼り付け、「初心者向けに、専門用語を使うときは意味も添えて説明して」と頼んでみましょう。秘密の情報や認証情報が含まれる場合は、そのまま共有しないようにします。

保存先を聞く

例えば「コミット済み・push済み」の意味が気になれば、「今回の作業はどの環境で、GitHubのどのブランチに保存された？」と聞けます。報告が曖昧なら、対象の名前と状態を具体的にしてもらいます。

確認の範囲を聞く

「テスト未実行」と書いてあれば、「何を確認していない？ 実行するなら何を確かめられる？」と質問できます。実施済みと未実施を分けてもらうと、確認の範囲を理解できます。

公開の状態を聞く

最後に「mainに取り込んだ？ 本番サイトは更新された？」と聞きます。GitHubへの保存、mainへの反映、公開は別の段階です。AIが実際に行った操作と、まだ行っていない操作を区別して受け取りましょう。

分からない部分を、小さな質問に分けるのがコツです。次は、報告によく出るブランチとmainを詳しく見て、作業を分ける理由を学びます。

たとえば「画像は表示できたが、スマートフォンでの確認はまだ」という返答なら、次はスマートフォン幅での確認を頼めます。「全部大丈夫？」だけで終えるより、確認済みと残件が具体的になります。

質問は一度にすべてしなくても大丈夫です。まず「何を変更したか」を聞き、次に「保存と公開はどこまでか」と続ければ、返答を読みながら理解できます。