ChatGPTとGitHubを使ったサイト開発の全体像

ChatGPTへの依頼から何が始まる？

たとえば、あなたが「コツエイゴのAIページに、新しい記事を追加して」とChatGPTに頼んだとします。このひと言から、実際のサイトに記事が現れるまでには、いくつかの段階があります。まず依頼を理解し、変更する場所を調べ、ファイルを作成・編集します。その後、変更の確認や保存、必要に応じた公開が続きます。

ChatGPTに任せられること

ChatGPTは、あなたの要望を整理したり、文章やコードを考えたり、作業の結果を説明したりできます。接続された機能や開発環境がある場合は、許された範囲でファイルを調べたり編集したりすることもあります。ただし、いつでもどのサービスでも自由に操作できるわけではありません。使っている機能、接続状態、権限によって、できることは変わります。

ここでいう「コード」とは、コンピューターに表示や処理の方法を伝えるために書かれたものです。自分でコードを書けなくても、ChatGPTに「何をどこに追加したか、初心者向けに教えて」と聞けば、作業の内容をたどれます。名前がわからない段階では、画面に見えるものを「このボタン」「この記事の一覧」と伝えても大丈夫です。

目的や確認したいことを伝える

依頼は、完成形がはっきりしていなくても始められます。「こんな読者にわかりやすい記事にしたい」「公開する前に見たい」のように、目的や途中で確認したいことを伝えてみましょう。AIは必要に応じて構成や作業の順番を提案します。内容が意図と違う場合は、どの部分をどう変えたいか伝えて調整できます。

「依頼した」と「完了した」は違う

大切なのは、依頼したことと、作業が完了したことを同じにしないことです。「記事を書いた」「プレビューで確認した」「GitHubに保存した」は、それぞれ違う報告です。まずは、どの段階まで進んだのかを聞けるようになりましょう。

例えば、りんが「記事を作って、公開前に見せて」と依頼したとします。この場合、まず原稿と確認用の画面を用意し、りんが内容を確かめられるところまで進めます。公開まで自動で行われたと考えず、実際にAIが何をしたかを報告で確認します。依頼の言葉と実行された内容は、両方を見て判断します。

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

開発環境とGitHubは何をする場所？

開発環境は、サイトの材料となるファイルを調べたり、編集したり、動作を確かめたりする作業場所です。自分のパソコン上にある場合も、インターネットを通じて使うクラウド上にある場合もあります。ChatGPTに作業を任せるときは、接続されている環境で作業が行われます。

作業環境では何をする？

開発環境には、変更した結果を確認するためのプログラムや、必要な道具が用意されることがあります。AIが「環境を準備します」と言ったら、作業の前に必要な道具や接続を確かめているのかもしれません。準備の内容が気になれば、「何を確認して、何ができる状態になった？」と聞いてみましょう。

GitHubは変更を管理する場所

一方、GitHubは、プロジェクトのファイルや変更履歴をオンラインで管理・共有できるサービスです。プロジェクトのまとまりは「リポジトリ」と呼ばれます。コツエイゴにもリポジトリがあり、サイトを作るためのファイルや設定の一部が管理されています。ただし、サイトの情報がすべてGitHubに入っているとは限りません。データベースや別の保存場所を使うこともあります。

たとえるなら、開発環境は作業机、GitHubは変更を記録したものを管理する場所です。ただし、実際には開発環境にも履歴を持つことができ、GitHubにも確認や共同作業の機能があります。たとえは入口として使い、実際の状態はAIの報告で確かめましょう。

作業・保存・公開を分けて考える

ファイルを編集しただけでは、その変更がGitHubに送られたとは限りません。逆に、GitHubに保存しただけで読者の画面に出るとも限りません。「作業場所」「GitHub」「公開サイト」を別々に思い浮かべると、報告が読みやすくなります。

作業環境だけに残るものもある

作業机の状態は、いつでも別の環境に引き継がれるとは限りません。クラウドの環境を作り直したとき、ローカルにだけ残していたファイルが使えないこともあります。どのデータがGitHubに保存され、何が作業環境にだけ残っているかを聞くことは、後から作業を続ける助けになります。

保存した変更はどうやって公開される？

変更を他の作業と混ぜずに進めるため、「ブランチ」という作業の分かれ道を使うことがあります。たとえばAI記事用のブランチに変更を保存し、内容を確認してから、基準となるmainというブランチに取り込む、という流れです。ブランチとmainは第7記事で詳しく扱います。

作業をまとめる方法はサイトごとに違う

もう一つ注意したいのは、作業をまとめる方法もサイトによって違うことです。プルリクエストという確認の場を使う場合もあれば、別の決められた手順を使う場合もあります。自分のサイトでは何が必要かを確かめ、他のサイトの手順をそのまま当てはめないようにします。

公開は別の段階

その後、公開用の仕組みを通して、読者が見るサイトに変更を反映します。この反映を「デプロイ」や「本番公開」と呼びます。どの操作をきっかけに公開されるかはサイトごとに異なり、自動で公開される設定も、手動で公開する設定もあります。

コツエイゴでは、作業ブランチへの保存、mainへの反映、本番公開を分けて扱います。たとえば「作業ブランチに保存しました」という報告は、変更を残したという意味であり、本番サイトへの掲載を意味しません。「公開まで」と頼んだ場合も、AIの報告と実際の公開画面を照らして確認しましょう。

プレビューと公開後の画面を確かめる

公開前にはプレビューという確認用の画面を見ることがあります。文章の読みやすさや画像の位置、リンク先などを確かめるためです。プレビューは読者向けの本番ページとは別の場合があります。どちらを見ているか、画面の説明やURLで確認しましょう。

また、公開サイトの内容が切り替わる時刻や、読者に見える画面は配信の仕組みでも変わります。作業の報告だけで判断しにくいときは、対象のページを開いて、意図した内容が表示されているかを確認しましょう。確認できない場合は、未確認のまま報告してもらいます。

ChatGPTの報告を確認してみよう

ChatGPTから「記事を作成し、作業ブランチに保存しました。プレビューを確認済みです。mainへの反映と本番公開はしていません」と報告されたとします。この場合、記事は作られ、作業ブランチに保存され、確認用画面も見られています。一方、mainへの取り込みと本番公開はまだです。

報告がわからないときの聞き方

専門用語がわからないときは、報告をそのまま貼って「この中のブランチとmainを初心者向けに説明して」と聞いて構いません。「どこに保存した？」「どの画面で確認した？」「本番サイトで読める？」と質問を分けると、必要な答えを得やすくなります。

未確認のことも教えてもらう

確認を頼むときは「成功したことだけでなく、未確認や失敗も教えて」と添えると、報告を判断しやすくなります。たとえば、文章はできているが画像は仮のまま、パソコンでは確認したがスマートフォンは未確認、といった違いを知ることで、次に何をするか選べます。

エラーが出たら、止まった場所を確認

エラーが出た場合は、どの段階で止まったかを確認します。たとえば記事の作成が終わっていても、保存だけ失敗しているかもしれません。すべてを最初からやり直す前に、完了したことと未完了のことを聞きましょう。操作結果が不明なときは、同じ操作を繰り返す前に現在の状態を確認することも大切です。

ここまでの流れを振り返る

次に進む前に、図の流れを声に出してみてください。「依頼して、作業し、保存して、必要な確認をしてから公開する」。それぞれの段階の名前を完璧に覚える必要はありません。まずは、違う段階があると知っていれば十分です。