自分のサイト用にクラウド開発環境を準備する

最初にサイトとアカウントを確認

前の記事では、クラウド開発環境がネットの先にある作業場所で、GitHubがファイルや履歴を管理するサービスだと学びました。今回は、自分のサイトを対象に準備する流れを、OpenAIのCodex Cloudを例に見ていきます。

リポジトリを特定する

まず、作業したいサイトと、それに対応するGitHubリポジトリを特定します。複数のサイトを持っているなら、「どのサイトの、どのリポジトリか」を名前やURLで確認しましょう。似た名前の別のリポジトリを選ぶと、目的の変更には届きません。

たとえばコツエイゴなら、そのサイトの制作に使っているリポジトリを対象にします。今使っている環境を引き継ぐ場合も、新しい環境を作る場合も、ChatGPTに「今回の対象はどのサイトとリポジトリ？」と尋ねるところから始められます。

使える機能と権限を調べる

Codex Cloudを利用できるかは、契約プラン、アカウント、ワークスペースの設定などによって変わります。チームで管理された環境では管理者の設定が関係する場合もあります。画面に項目が見えなければ、まずログイン先や利用条件を確認しましょう。

GitHubへの接続には、対象リポジトリを扱う権限も必要です。GitHubに接続できたことと、すべてのリポジトリへアクセスできることは同じではありません。必要なアクセスを確認し、分からなければ管理者や所有者に尋ねます。

すでに環境がある場合

すでに使える環境があるなら、まずその環境の対象や状態を確認します。同じサイトの環境を必ず作り直す必要はありません。前の作業が残っている場合は、保存先や未完了の変更を調べてから進めましょう。

この記事の画面名は確認時点の公式案内に基づく例です。表示や順番は変更される可能性があるため、実際の画面と最新の案内を見ながら進めてください。

アカウントを複数使っていると、いつもサイトを管理するGitHubではなく別のアカウントで接続していることもあります。表示されたリポジトリが見つからないときは、対象とログイン先を確認することが出発点です。

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

Codex Cloudで環境を作成する

公式案内では、Codex Cloudの新しい環境は、デスクトップアプリまたはWebで作成します。ChatGPTアカウントでログインし、新しいタスク画面から作業先としてCloudを選び、環境の選択画面を開きます。

クラウドとリポジトリを選ぶ

環境選択の中に「Create environment」があれば、新しい環境の作成を選びます。公式案内には、設定画面の「Codex Cloud」から環境を作成する入り口も示されています。画面の言語や表示は変わりうるため、見当たらないときは最新の案内を確認します。

次に作業したいGitHubリポジトリを選びます。接続を求められたら画面の案内に従ってGitHubを接続し、対象が正しいことと必要な権限を確かめます。関係のないリポジトリまで選ぶ必要はありません。

準備の報告を読む

準備を開始すると、Codexがリポジトリを調べ、必要な道具や依存関係の準備、テストを進めます。途中で情報やアクセスが必要になったら、何に必要なのかを確認し、画面に沿って対応します。分からないコマンドを自分で書く必要はありません。

終わったら、準備の報告、設定、ファイルを確認します。「何をインストールした？ テストは成功した？ 未完了は？」と初心者向けの説明を頼めます。必要な準備が残っていれば、内容を確認して整えます。

環境の「公開」はサイト公開ではない

設定を保存し「Publish」で環境を公開すると、新しいタスクで再利用できる準備済み環境になります。ここでの「公開」は環境を利用できる状態にする操作で、サイトを読者向けに本番公開する意味ではありません。

公式案内では「Environment published」と表示された後、新しいタスクを開始できます。環境を共有するかどうかや、誰が使えるかは別の設定です。公開ボタンの言葉だけで、サイトやリポジトリが一般公開されたと判断しないようにします。

準備の報告には、成功した工程だけでなく、アクセス待ちや未実施の確認も含めてもらいましょう。「どの部分は使えて、どこはまだ？」と聞くことで、環境の準備が終わったか判断しやすくなります。

接続と設定は必要な範囲を確認

サイトには、それぞれ動かすために必要な道具があります。例えばNode.jsという実行環境や、サイトを作るためのパッケージが必要なことがあります。Codexはリポジトリの情報を手掛かりに準備を進めます。

道具とバージョン

サイトが指定するバージョンや実行方法を確認し、「このリポジトリの指示に従って準備して。何を実行したか教えて」と頼めます。報告を読んで、テストできた範囲と未確認の点も分けてもらいましょう。

OpenAIの案内では、準備した手順をインストール用の設定や、起動・確認用の指示として記録できます。利用者が最初からスクリプトを書く必要はなく、会話で不足や希望を伝えて調整できます。

接続や秘密情報の扱い

外部サービスとの接続やネットワークの利用範囲は、サイトに必要なものを確認して選びます。権限を広げる必要があると言われても、まず目的と影響を聞き、サイトや組織のルールに沿って判断しましょう。

パスワードやAPIキーなどの秘密情報を使う場合は、サービスが用意した正規の保存方法や接続機能を使います。記事やリポジトリに秘密の値を貼り付ける必要はありません。実際に設定が必要かどうかも、使うサイト次第です。

設定変更の範囲を確かめる

環境の設定を変更したからといって、すでに始めたタスクにすべて自動で反映されるとは限りません。公式案内では、環境を更新して再公開した設定は新しいタスクに使われ、既存のタスクはそれぞれの状態を保ちます。

設定の内容を覚える必要はありません。何のための設定で、どの作業に必要かを一つずつ聞けば大丈夫です。

新しいタスクで接続と状態を確認

準備した環境を公開したら、新しいタスクでその環境を選び、やりたい作業を伝えます。環境の作成・公開はデスクトップまたはWebで行い、準備済み環境の利用は対応する端末から行えると公式案内にあります。

作業を始める

最初は変更を伴わない確認を頼むと、何につながっているか把握しやすくなります。例えば「今のサイトとリポジトリ、作業ブランチ、作業中の変更を確認して。まだファイルは変更しないで」と依頼できます。

結果では、対象のリポジトリとブランチが想定どおりか、前回の作業があるかを確かめます。別の環境やタスクでは、同じ未保存の変更が見えない場合もあります。大切な変更はどこに保存されているか確認しましょう。

現在の状態を読む

GitHubに接続されていても、対象リポジトリの権限や環境の対象に含まれていなければ、読み取りやpushができない場合があります。「接続できない」だけでなく、選択、準備、取得、送信のどの段階で困っているかを分けて調べます。

その後は小さな作業を一つ頼み、プレビューやテストなど、サイトに合った方法で結果を確認します。変更をGitHubに保存するか、mainに反映するか、本番公開するかは、第12記事のように終了地点を指定します。

小さな確認から始める

困ったら「今できることと、できないこと、未確認を教えて」と尋ねましょう。環境の準備ができたことと、記事が本番公開されたことは別です。次の記事では、エラーや作業報告の読み解き方を詳しく扱います。

例えば「見出しの修正案を作成して、確認用に見せて。今回は本番公開しないで」と伝えれば、作業の内容と終了地点を分けて共有できます。実際にどこまで進んだかは、その後の報告で確かめます。