本命・Codex作業再開ログ

新しいデスクトップでCodex作業を再開する方法｜GitHub・/status・途中作業の確認手順

新しいPCに移った直後は、いきなり大きな作業を始めず、まず現在地を確認します。作業対象、前回ログ、GitHub、公開URL、触ってはいけないファイルを小さく確認してから、本命作業に進みます。

この記事では、サーバーパス、FTP情報、token、SSH鍵、.env、APIキー、個人情報、未確認予定、公式ロゴや公式画像は掲載しません。

結論：最初に作るのはページではなく現在地

新しいデスクトップでCodex作業を再開する時は、最初に記事を作るよりも、前回どこまで進んでいたかを確認することが大切です。

作業対象サイト、前回の作業ログ、GitHub repo、ブランチ、未コミット差分、公開URL、sitemap、robots、ads、AdSense、Search Consoleタグを見て、今どこにいるかを固めます。

新しいPCでは、ブラウザ、ターミナル、エディタ、FTP、GitHub連携、ローカル作業フォルダが前と同じとは限りません。環境が変わった直後に大きな横展開オーダーを投げると、途中作業や未反映ファイルを見落としやすくなります。

確認は短くても構いません。大切なのは順番です。

/status はOpenAIの障害情報ではなく、サイト運営側の現在地確認として扱います。直前の作業が完了済みか、未完了作業があるか、次に何をするべきか、停止条件がないかを見るための入口です。

実際に /status ページがない場合は、前回の完了報告、work-log、deploy report を代わりに使います。

新PCではGitHubの認証やローカルrepoの場所が変わっていることがあります。公開記事ではrepo名を出す場合も公開してよい範囲に留め、token、SSH鍵、.env、Secretsは絶対に出しません。

ブルーインパルス情報サイトや航空祭情報サイトのような公開中サイトでは、公式サイトと誤認される表現を避けます。公式ロゴや公式画像を使わず、未確認予定を断定せず、公開URLと内部リンクを確認します。

ここでは実例を一般化し、公共情報サイトや航空イベント情報サイトという表現で扱います。

新しいPCだからといって、いきなり大規模横展開、main直push、robotsやadsの変更、AdSenseコードやSearch Consoleタグの変更をしてはいけません。

確認で問題がなければ、小さな記事追加、既存ページからの内部リンク、sitemapへの新規URL追加、本番アップロード、公開URL確認へ進みます。通常のHTML追加とsitemap新規URL追加は止めず、本番確認までを完了条件にします。

新しいPCに移ったら、すぐ大きな作業を始めてもよいですか？

最初は小さな確認から始めます。作業対象サイト、GitHub、ブランチ、未コミット差分、公開URL、sitemap、robots、ads、前回ログを確認してから本命作業へ進む方が安全です。

/status はOpenAIの障害情報を見る場所ですか？

ここでいう /status は、各サイトや作業ログにある進行状況確認ページ、または直前作業メモを指します。OpenAI公式の障害情報と混同しないように扱います。

GitHubで最初に確認することは何ですか？

正しいrepo、作業ブランチ、未コミット差分、未マージPR、Secretsや.envを含めていないこと、mainへ直接pushしない運用を確認します。

公開中サイトの作業で触らない方がよいものはありますか？

通常の記事追加では robots.txt、ads.txt、.htaccess、DB、cron、AdSenseコード、Search Console確認タグ、DNS、news pipeline は触りません。必要になった場合は停止して報告します。

公共情報サイトを例にする時の注意点は？

公式サイトや公式発表と誤認される表現、公式ロゴ、公式画像、未確認予定の断定は避けます。公開中の情報サイトという一般化した例として扱います。