非エンジニアが毎日デプロイするための環境整備――AI・GitHub・デプロイナウを迷わず操作する手順
前回は、非エンジニアがAI、GitHub、デプロイナウを使い、毎日小さな差分をデプロイする体制を整理しました。
今回は、そこからさらに操作面へ踏み込みます。
毎日デプロイが止まる理由は、コードが書けないことだけではありません。
- どのフォルダを開けばよいか分からない
- GitHubのどのリポジトリが公開中なのか分からない
-
mainと作業用ブランチの違いが曖昧 - デプロイナウのどの画面で結果を見るのか分からない
- ローカルでは動くのに、公開すると環境変数が足りない
- 問題が起きたとき、最後に正常だった状態へ戻れない
このような小さな迷いが毎日積み重なると、AIが実装を終えても公開できません。
そこで、この記事では「今日の変更を作る方法」ではなく、毎日同じ順番で操作できる作業環境の整え方を扱います。
目標は、パソコンを開いたときに次の5つがすぐ分かる状態です。
1. 今日触るフォルダ
2. 公開中のGitHubリポジトリとブランチ
3. デプロイナウの対象プロジェクト
4. 公開URLと確認する操作
5. 問題時に戻るコミット
最初に「公開経路」を1本へ固定する
デプロイナウには、AIエージェント、CLI、ブラウザのドラッグ＆ドロップ、GitHub連携など複数の公開方法があります。
選択肢が多いことは便利ですが、毎日違う方法を使うと、どのファイルを公開したのか追いにくくなります。
この記事では、日常運用の経路を次の1本に固定します。
ローカルの作業フォルダ
↓
GitHubの作業用ブランチ
↓
プルリクエストのプレビューで確認
↓
mainへ反映
↓
デプロイナウが本番へ自動デプロイ
↓
公開URLで人間が確認
作業が非常に小さく、プレビューを使わない場合でも、少なくとも次の経路は固定します。
ローカル → GitHubのmain → デプロイナウ → 公開URL
「今日はGitHub、明日はフォルダを直接アップロード」という運用にすると、GitHubの内容と公開中の内容が一致しない日が生まれます。緊急時の代替経路は残しても、日常の正規経路は1つにします。
作業フォルダを迷わない形にする
非エンジニアの環境整備で最初に効くのは、高度な自動化ではなくフォルダ名です。
私は、1つのアプリを1つのフォルダに分け、公開対象と資料を混ぜない形を勧めます。
daily-app/
├── README.md
├── CURRENT_STATUS.md
├── package.json
├── src/
├── public/
├── tests/
├── docs/
│ ├── DAILY_CHECK.md
│ └── RECOVERY.md
├── .gitignore
└── .env.example
各ファイルの役割は次のとおりです。
| 場所 | 役割 |
|---|---|
README.md |
アプリの目的、起動方法、公開先の入口 |
CURRENT_STATUS.md |
現在地、最後の公開、次の作業 |
src/ |
主なアプリ本体 |
public/ |
公開する画像などの静的ファイル |
tests/ |
自動で確認できる項目 |
docs/DAILY_CHECK.md |
毎日の操作順 |
docs/RECOVERY.md |
問題時の停止・復旧手順 |
.gitignore |
GitHubへ保存しないファイル |
.env.example |
必要な環境変数名だけを示す見本 |
実際の.envには秘密情報が含まれることがあるため、GitHubへ保存しません。.env.exampleには値を書かず、次のように変数名と用途だけを残します。
PUBLIC_API_URL=
INTERNAL_API_TOKEN=
ただし、変数名にPUBLICと付いているから安全とは限りません。ブラウザへ渡る値か、サーバー内だけで使う秘密情報かをAIへ確認させ、人間が公開範囲を判断します。
毎日最初に読むファイルを2つに絞る
AIへ大量の過去ログを読ませる前に、現在地を短くします。
CURRENT_STATUS.mdには、次だけを書きます。
# Current Status
確認日：2026-11-03
公開URL：https://example.lolipop-now.app
本番ブランチ：main
最後の正常コミット：abc1234
最後の公開確認：2026-11-02 08:50 JST
## 現在地
- 入力と一覧表示は公開済み
- 空欄送信の案内は公開済み
## 今日の作業
- スマートフォンで追加ボタンが隠れないようにする
## 触らない範囲
- データ保存方法
- 環境変数
- 削除機能
docs/DAILY_CHECK.mdには、操作順だけを書きます。
1. 公開URLで昨日の状態を確認
2. CURRENT_STATUS.mdを読む
3. AIへ今日の1変更を依頼
4. ローカルで確認
5. GitHubへpush
6. デプロイナウのデプロイ画面を確認
7. 公開URLで再確認
8. CURRENT_STATUS.mdを更新
毎日の入口を2ファイルへ絞ると、AIを変えても同じ現在地から始められます。
GitHub側の名前を揃える
フォルダ名、リポジトリ名、デプロイナウのプロジェクト名が全部違うと、操作のたびに対応を思い出す必要があります。
完全に同じでなくても、共通部分を持たせます。
ローカルフォルダ：daily-memo
GitHubリポジトリ：daily-memo
デプロイナウ：daily-memo
公開URL：daily-memo.lolipop-now.app
名前には、顧客名、個人名、非公開の案件名を入れません。公開URLのサブドメインは第三者から見えるためです。
また、GitHubで次の3つを確認します。
所有者：どのアカウントまたはOrganizationか
リポジトリ：どれが公開元か
本番ブランチ：どのブランチへのpushで公開されるか
この3点はCURRENT_STATUS.mdにも残します。
GitHub Appの許可範囲を整える
デプロイナウとGitHubの接続にはGitHub Appを使います。
初回接続では、GitHubアカウントの連携と、リポジトリへのアクセス許可を行います。
操作手順は次の順です。
- デプロイナウのプロジェクト一覧で「新規作成」を開く
- GitHubからデプロイする方法を選ぶ
- GitHubアカウントの連携画面へ進む
- 対象リポジトリの所有者を選ぶ
- GitHub Appをインストールする
- アクセスを許可するリポジトリを選ぶ
- デプロイナウへ戻り、リポジトリ一覧を開き直す
許可範囲にはAll repositoriesとOnly select repositoriesがあります。
毎日デプロイする対象が1つなら、まずOnly select repositoriesで対象を限定すると、別のリポジトリを選ぶミスを減らせます。後で対象を増やす場合は、GitHub側で許可範囲へリポジトリを追加できます。
公式ドキュメントでは、GitHubアカウント連携の認可は約8時間で期限切れになります。期限が切れると、新しい接続の作成やリポジトリ一覧の表示前に再連携が必要です。一方、すでに接続済みのリポジトリの自動デプロイは続きます。
「昨日まで動いたのに、リポジトリ一覧が出ない」という場合は、GitHub Appをすぐ入れ直す前に、アカウントの再連携と許可範囲を確認します。
デプロイナウの新規作成画面で確認する4項目
リポジトリを選ぶと、プロジェクト作成画面へ進みます。ここで最低限確認するのは次の4項目です。
- プロジェクト名
- サブドメイン
- フレームワーク
- デプロイするブランチ
プロジェクト名
管理画面で識別しやすい短い名前にします。プロジェクトが増えたときも、何を公開しているか分かる名前にします。
サブドメイン
サブドメインは公開URLになります。入力時に、個人情報、顧客名、社内用語が入っていないか確認します。
フレームワーク
GitHubからプロジェクトを作る場合、公式ドキュメントではリポジトリ内容からフレームワークが自動判別されません。間違った選択はビルド失敗の原因になります。
作成前にAIへ次のように確認します。
このリポジトリをデプロイナウへ接続します。
package.jsonと設定ファイルを確認し、選択すべきフレームワークを答えてください。
根拠となるファイル名と記述を示してください。
推測だけで決めないでください。
デプロイするブランチ
ここで選んだブランチへのpushが、本番の自動デプロイを始めます。
通常はmainなど本番用ブランチを選びます。作業用ブランチを選ぶと、確認途中の変更が本番へ反映されるため、選択後にもう一度名前を読みます。
初回デプロイ後に見る画面を固定する
プロジェクトを作成すると、最初のデプロイが始まります。
毎回見る画面を、次の3つに固定します。
1. デプロイ画面
デプロイの進行状況とビルドログを確認します。
「成功」なら次へ進みます。「失敗」ならログの最初のエラーを読み、新しい変更を重ねません。
2. 設定画面
接続しているリポジトリ、本番ブランチ、自動デプロイ、プレビューの状態を確認します。
公式ドキュメントでは、ここから本番ブランチの切り替え、自動デプロイの停止・再開、プレビューの有効・無効、GitHub接続の解除を操作できます。
3. 公開URL
デプロイ成功後、公開URLを別タブで開きます。
表示：トップ画面が開く
操作：主要ボタンが動く
入力：正常入力と空欄を試す
幅：スマートフォン幅で確認
情報：テスト文字や秘密情報がない
デプロイ画面の成功だけで完了にしません。
環境変数はローカルと本番を別々に確認する
「ローカルでは動くのに、公開すると失敗する」原因の1つが環境変数です。
デプロイナウの公式ドキュメントでは、.envの内容はビルド時にも公開時にも参照されません。必要な値は、プロジェクト詳細の「環境変数」画面またはCLIから設定します。
そのため、次の表を作ります。
| 変数名 | 用途 | ローカル | 本番 | プレビュー | 秘密か |
|---|---|---|---|---|---|
PUBLIC_API_URL |
接続先URL | 設定済み | 設定済み | 検証用 | いいえ |
INTERNAL_API_TOKEN |
サーバー認証 | 設定済み | 設定済み | 別値 | はい |
値そのものは文書へ書かず、「設定済み」「未設定」だけを記録します。
本番とプレビューの環境変数は別です。本番の値はプレビューへ自動で引き継がれません。同じ変数名が必要なら、プレビュー側にも設定します。
環境変数を変更したあとの反映タイミングも違います。
- 本番：再デプロイ後に反映
- プレビュー：プルリクエストのブランチへ次にpushしたデプロイから反映
値を設定しただけで公開中のアプリが即座に変わるとは考えず、反映のためのデプロイと公開URLの確認まで行います。
.gitignoreを後から足せば安全、とは限らない
デプロイ対象のファイルにも注意が必要です。
公式ドキュメントでは、Git管理下のディレクトリでは、Gitが追跡しているファイルと、未追跡で.gitignoreに無視されていないファイルが対象になります。
重要なのは、すでにGitが追跡しているファイルは、後から.gitignoreへ書いても含まれ続ける点です。
秘密情報を誤ってコミットした場合は、.gitignoreを追加するだけで終わらせません。
- その値を無効化または再発行する
- Gitの追跡対象から外す
- 公開履歴やログへの影響を確認する
- デプロイナウの環境変数へ正しく設定する
- 再デプロイして確認する
秘密情報の漏えい対応は影響が大きいため、AIに自動処理を丸投げせず、人間が範囲を確認します。
プレビューを「本番前の操作場所」にする
GitHub連携では、プルリクエストの内容を本番と別のURLで公開するプレビューを利用できます。
操作は次の流れです。
-
mainから作業用ブランチを作る - AIと変更する
- 作業用ブランチへpushする
- GitHubでプルリクエストを作る
- デプロイナウがプレビューを作る
- プレビューURLで操作する
- 問題がなければ
mainへ反映する - 本番デプロイ後に公開URLを確認する
プレビューURLは、同じプルリクエストのブランチへpushするたび更新され、プルリクエストを閉じるまで同じURLを使えます。
ただし、公式ドキュメントでは、プレビューURLを知っていれば誰でもアクセスでき、デプロイナウ側にはプレビューへのアクセス制限機能がないと案内されています。
そのため、次をプレビューへ置きません。
- 個人情報
- 顧客の実データ
- 本番の秘密情報
- 公開前に第三者へ見せられない内容
本番とプレビューで環境変数を分け、検証用データを使います。
ブラウザのタブとブックマークを固定する
環境整備はコードだけではありません。
毎日使う画面を、同じ順番でブックマークフォルダへ入れます。
01 公開URL
02 GitHubリポジトリ
03 GitHubプルリクエスト
04 デプロイナウのプロジェクト
05 公式ドキュメント
作業開始時は01 公開URLから開きます。変更前の正常状態を確認するためです。
作業後は02または03で差分を確認し、04でデプロイ結果を見て、最後に01へ戻ります。
失敗時に開く復旧カードを用意する
問題が起きたとき、チャット履歴を探し始めると復旧が遅れます。
docs/RECOVERY.mdへ、次のカードを置きます。
# Recovery
## まず止める
- 新しい変更を追加しない
- 必要なら自動デプロイを停止する
- 公開中の状態と時刻を記録する
## 確認する
- 最後の正常コミット：
- 問題が出たコミット：
- デプロイ結果：成功 / 失敗
- 公開URLの症状：
- 影響する操作：
## 選ぶ
- 小さく修正する
- 正常コミットへ戻す
- 一部機能を使わない
- 公開更新を止めて調査する
## 再開条件
- ビルド成功
- 公開URLで主要操作を確認
- 人間が再開を承認
自動デプロイを停止しても、公式仕様では公開中のサイトとGitHub接続は残ります。原因調査中にpushで更新を重ねたくない場合の停止手段として使えます。
ただし、停止後は再開する担当と条件を必ず記録します。
AIへ渡す「環境確認プロンプト」
実装前に、AIへ環境の対応関係を確認させます。
このプロジェクトの公開環境を確認してください。
1. ローカルの作業フォルダ
2. GitHubリポジトリ名
3. 現在のブランチ
4. 本番へデプロイされるブランチ
5. 使用フレームワークと根拠ファイル
6. 必要な環境変数名。値は表示しない
7. デプロイ対象に含めてはいけないファイル
8. 変更後に確認する操作
確認できない項目は推測せず「未確認」としてください。
ファイルを変更せず、最初に確認結果だけを出してください。
環境確認と実装を一度に頼まないことが重要です。
対応関係が間違っていれば、コードが正しくても別のブランチや別のプロジェクトを更新する可能性があります。最初に読み取りだけを行い、人間が確認してから変更を依頼します。
毎日の操作チェックリスト
最後に、日次操作を1枚へまとめます。
## 開始前
- [ ] 公開URLで昨日の状態を確認した
- [ ] CURRENT_STATUS.mdを読んだ
- [ ] 本番リポジトリとブランチを確認した
- [ ] 今日の変更を1つに絞った
## 変更後
- [ ] 予想したファイルだけが変わった
- [ ] 秘密情報や個人情報が差分にない
- [ ] ローカルで正常・異常操作を確認した
- [ ] コミット名が変更内容を表している
## プレビュー
- [ ] プレビュー用の環境変数を確認した
- [ ] プレビューURLに公開不可情報がない
- [ ] 主要操作を確認した
## 本番
- [ ] mainへの反映を人間が承認した
- [ ] デプロイナウのビルド結果を確認した
- [ ] 公開URLで変更と既存機能を確認した
- [ ] 最後の正常コミットを記録した
公式仕様として確認した点
この記事の執筆時点（2026年11月3日）に、公式ドキュメントで次を確認しました。
- GitHubからプロジェクトを作るとき、プロジェクト名、サブドメイン、フレームワーク、デプロイするブランチを指定する
- GitHub連携ではフレームワークは自動判別されない
- 指定ブランチへのpushで自動デプロイが始まる
- GitHub Appのアクセス許可をリポジトリ単位で選べる
- デプロイ画面で進行状況とビルドログを確認できる
- 設定画面から本番ブランチ、自動デプロイ、プレビュー、接続を変更できる
-
.envはビルド時・公開時の環境変数として参照されない - 本番とプレビューの環境変数は別に設定する
- Git追跡済みのファイルは、後から
.gitignoreへ追加しても対象から外れない - プレビューURLはアクセス制限されず、URLを知る人が閲覧できる
参考：
まとめ
毎日デプロイするための環境整備は、特別な自動化を増やすことだけではありません。
- 日常の公開経路を1本に固定する
- 作業フォルダ、GitHub、デプロイナウの名前を対応させる
-
CURRENT_STATUS.mdと日次チェックを毎日の入口にする - GitHub Appの許可対象を必要なリポジトリへ絞る
- プロジェクト作成時に名前、URL、フレームワーク、本番ブランチを確認する
- デプロイ画面、設定画面、公開URLの3か所を毎回見る
-
.envではなくデプロイナウ側へ環境変数を設定する - 本番とプレビューの値を分ける
- プレビューを本番前の操作確認に使い、秘密情報は置かない
- 最後の正常コミットと復旧手順を先に用意する
非エンジニアに必要なのは、すべての技術用語を暗記することではありません。
「どこを開くか」「どの順で確認するか」「どこから先は公開か」「問題時にどこへ戻るか」を固定することです。
この操作環境が整うと、AIへ依頼する内容も短くなります。毎回プロジェクトを説明し直すのではなく、現在地を読ませ、今日の1変更だけを頼めるからです。
毎日デプロイする体制は、AIの速さだけでは続きません。人間が迷わず操作でき、公開前に止まれ、失敗しても戻れる作業台を作ること。その作業台こそが、非エンジニアにとって最初の開発環境です。
次回は、この環境で毎日残るデプロイ記録を、公開回数ではなく「利用者へ届いた価値」と「戻しやすさ」で週次レビューする方法を整理します。