開発中に困ったら——エラーとChatGPTの報告を読み解く

まず、どこで止まったかを確認

ChatGPTにサイト作業を頼むと、「エラーが出ました」「処理に失敗しました」という報告を受けることがあります。エラーは、何かが期待どおりに進まなかったことを知らせる手掛かりです。これだけで、すべての作業が消えたとは限りません。

エラーは何を知らせている？

まず「何をしようとしたときに止まった？」「どの操作は終わっている？」と聞きます。記事の文章を作る途中で止まったのか、できた文章をGitHubへ送るときに止まったのかでは、次に確認する内容が変わります。

たとえば「記事の本文と画像は作成できたが、GitHubへのpushに失敗した」という報告なら、作成と送信は別の工程です。作業環境にファイルが残っている可能性がありますが、実際にどこにあるか、コミット済みかも確かめましょう。

作業の段階に分けてみる

ほかにも、画面のプレビュー、テスト、mainへの反映、本番公開など、止まる場所はさまざまです。「保存したか」「確認できたか」「読者に公開されたか」を混ぜずに聞くと、全体を把握しやすくなります。

英語の長いメッセージを見ても、すべて覚える必要はありません。「このエラーを初心者向けに説明し、止まった工程と、確認すべきことを教えて」と頼めます。専門用語も、意味が分かる言葉に言い換えてもらいましょう。

文章が分からなくても大丈夫

画面のどこで表示されたか、いつごろ起きたか、何を頼んでいたかも手掛かりです。原因を一つに決めつける前に、分かっている事実と、まだ推測の部分を分けて説明してもらいます。

例えば「公開に失敗」と一言で書かれていても、公開処理を始められなかったのか、途中で失敗したのか、処理後の画面確認だけができなかったのかでは状況が違います。次に何をすべきかは、その違いを確かめてから考えましょう。

作業の途中で接続が切れた場合も、まず実行履歴やファイルの状態を見ます。接続が切れた時点と処理が止まった時点が必ず一致するとは限らないので、落ち着いて確認しましょう。 不明なことは不明のまま報告してもらいます。

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

完了・失敗・未確認を分ける

作業報告を読むときは、完了したこと・失敗したこと・まだ確認していないことを分けます。同じ報告に複数の状態が書かれていても、それぞれが別の工程なら矛盾しません。

一つの報告を分解する

例えば「記事を作り、作業ブランチに保存しました。テストは成功しました。本番公開は行っていません」という報告では、作成と保存とテストは完了、公開は未実施です。「公開していない」ことが、保存やテストの失敗を意味するわけではありません。

一方で「mainに反映しました。公開処理の結果は確認できていません」なら、mainへの反映と公開結果は別です。サイトの設定によっては自動公開が始まることもあるので、本番の状態を推測せず調べます。

「未確認」は「失敗」と違う

「未確認」は、調べられていないという状態です。失敗したと決めることも、成功したと決めることもできません。「何が見られなかった？ ほかに確かめる方法は？」と質問します。

テスト成功の報告にも範囲があります。例えば自動テストが成功しても、スマートフォン実機での見た目を確認したとは限りません。第11記事のように、「どの画面、どの幅、どの操作」を確かめたかを聞きましょう。

確認した範囲も聞く

具体的には「今回の作業を、完了・失敗・未実施・結果不明に分けて。保存先と公開先も教えて」と依頼できます。分からない項目を空欄にせず、分からないまま明示してもらうと、次に必要な確認を選びやすくなります。

分かりにくい報告は、その文章をそのまま渡して「専門用語を説明し、作業の段階ごとに表現し直して」と頼めます。ChatGPTの言い換えも、元の報告が示していない成功や失敗を付け足していないか確かめます。

再実行する前に現在の状態を見る

結果が分からないときは、同じ操作をすぐに繰り返す前に、現在の状態を確認します。例えば「公開処理の後に報告だけ受け取れなかった」場合、実際には公開が終わっている可能性も、終わっていない可能性もあります。

結果不明のまま繰り返さない

ChatGPTに「公開の実行結果と本番サイトを確認して。確認できるまでは同じ公開操作を繰り返さないで」と頼めます。どの変更を対象にしたか、実際にどのURLが更新されたかも、分かる範囲で確認します。

やり直しによって同じ変更や登録が二重になる場合があります。逆に、すべて最初から作り直すと、すでに完了した作業と途中の変更を取り違えるかもしれません。今ある状態を調べてから、必要な操作を選ぶことが大切です。

保存先や変更を確認

GitHubへの保存に失敗した場合も、作業環境のファイル、コミット、送信先のブランチ、GitHub上の状態を確かめます。作業環境にしかない変更があれば、消したり別の作業で上書きしたりする前に、その所在を説明してもらいましょう。

確認の結果、接続の一時的な問題など、原因に合った再試行ができる場合もあります。一方、権限がない、対象が違う、他の作業と衝突しているなど、先に確認や判断が必要な場合もあります。無理に同じ操作を続けません。

安全に進められる作業を選ぶ

「現状を読み取る確認だけ先に進めて、変更や削除はまだしないで」と作業を分けることもできます。どこまでが安全に確認でき、何がまだ不明かを報告してもらい、必要な次の作業を依頼しましょう。

例えば、画像は完成したが保存だけが失敗したなら、画像の作り直しではなく、保存先と接続を調べることが次の一歩になるかもしれません。何が残っているかが分かると、不要なやり直しを減らせます。

困ったときの情報を整理して聞く

困ったときは、完璧な技術的説明より、分かる範囲の状況を伝えることが役立ちます。「何をしたかったか」「どの画面や操作で止まったか」「表示されたメッセージ」「すでに試したこと」を短くまとめましょう。

何を伝えるとよい？

例えば「第14記事を作業ブランチへ保存したかった。pushでエラーが表示された。もう一度は実行していない。完了済みの作業と、現在の保存先を確認して」と依頼できます。エラー文があれば、関連する部分を添えると調査の手掛かりになります。

「確認だけして、まだ変更しないで」と添えると、最初に状態を整理できます。画面に何が見えているかを言葉にするのが難しければ、必要な範囲のスクリーンショットを使う方法もあります。

画像やエラー文を渡す前に

ただし、画像やログにパスワード、APIキー、認証用の文字列、個人情報などが写っている場合は、共有前に隠します。秘密情報の値そのものを教える必要はありません。「認証でエラーが出た」と伝え、正規の設定方法を確認します。

ChatGPTには「確認できた事実と推測を分けて、原因候補と次に調べることを教えて」と聞けます。エラーの文章が似ていても原因は一つとは限らないため、実際の状態に照らして考えることが大切です。

次の依頼につなげる

問題が解決したら、変更の保存先、テストの結果、mainへの反映、本番公開の状態を最後に確認しましょう。直った部分だけでなく、まだ確認できていない部分も把握できます。次の記事では、自動検査などに使われるGitHub Actionsと無料枠を学びます。

画面に「権限がありません」と表示された場合も、何の権限なのか、どのアカウントやリポジトリで起きたかを確認します。必要な権限はサイトの所有者や管理者に相談し、分からない設定を勝手に変えないようにしましょう。

報告を受けてもすぐに理解できなければ、「この記事を読む人向けに、一つずつ順番に説明して」と頼めます。作業の名前を全部覚えるより、今の状態と次に確認することが分かることを目指します。