非エンジニア向け「毎日デプロイ操作盤」の作り方――フォルダとブラウザを1本の動線にする
毎日デプロイするための手順書を作っても、作業中に開かなければ役に立ちません。
AIへの共通指示はどのフォルダだったか。今日の確認表は前回のものか。GitHubのどの画面で差分を見るのか。プレビューURLはどこにあるのか。デプロイナウの成功表示を見たあと、公開URLで何を試すのか。
一つひとつは難しくなくても、毎回探していると作業が止まります。
さらに危険なのは、途中の確認を飛ばしてしまうことです。
- AIとの会話だけを見て、変更ファイル一覧を見なかった
- GitHubでマージできたため、公開確認も終わったと思った
- デプロイナウで成功を見たが、利用者と同じURLを開かなかった
- 問題が起きてから、復旧手順の保存場所を探した
- 前日のタブを使い、別のプルリクエストのプレビューを確認した
そこで私は、作業に必要なファイルとブラウザ画面を、**開始から公開後確認まで順番に開ける「操作盤」**として配置します。
操作盤といっても、新しいアプリを開発するわけではありません。次の3つを組み合わせるだけです。
- プロジェクト直下の3ファイル
- 用途を固定したブラウザタブ
- 今いる段階が分かる短い進行表
この記事では、非エンジニアでも30分ほどで作れる最小構成と、毎日の操作順、迷ったときの戻り先、週次で整える方法まで説明します。
操作盤が解決するのは「判断」ではなく「迷子」
操作盤を作っても、何を公開するか、問題が許容できるか、本番へ進めるかは人間が決めます。
操作盤が助けるのは、判断材料へ迷わず移動することです。
どこから始めるか分からない
→ 開始ファイルを固定する
次に何を見るか分からない
→ タブの順番を固定する
終わったか分からない
→ 完了条件を画面ごとに書く
問題時に何を止めるか分からない
→ 復旧カードを常に同じ場所へ置く
すべてを自動化するのではなく、人間が判断する地点までの移動を短くします。
操作盤の全体像
操作盤は、ローカル側とブラウザ側に分けます。
ローカル側：作業の約束
project/
├── START_HERE.md # 今日の入口と進行状況
├── AI_REQUEST.md # AIへ渡す共通指示
├── DAILY_CHECK.md # 開始前・反映前・公開後の確認
└── RECOVERY.md # 停止・復旧・確認・再開
前回は3ファイルを最小構成としました。実際の操作では、入口となる START_HERE.md を1枚追加すると迷いにくくなります。
START_HERE.md は新しいルール集ではありません。残り3ファイルとブラウザ画面への案内板です。
ブラウザ側：事実と確認画面
左から次の順で並べます。
1. AIとの作業画面
2. GitHubのプルリクエスト
3. プレビューURL
4. デプロイナウのデプロイ履歴
5. 本番の公開URL
順番には意味があります。
AIの提案を見たらGitHubで実際の差分を確認します。差分を確認したらプレビューで操作します。本番へ反映したらデプロイ履歴を見ます。成功したら公開URLを利用者と同じ入口から確認します。
前の画面が次の画面の代わりにならないように並べます。
30分で最小の操作盤を作る
0〜5分：専用フォルダを決める
操作ファイルは、対象プロジェクトの入口から一段以内に置きます。
project/
├── ops/
│ ├── START_HERE.md
│ ├── AI_REQUEST.md
│ ├── DAILY_CHECK.md
│ └── RECOVERY.md
├── src/
└── README.md
深い場所へ置くと開かなくなります。複数のプロジェクトを運用する場合は、プロジェクトごとに分けます。別サイトの公開URL、ブランチ、復旧地点を同じファイルへ混ぜません。
ファイル名は英語でも日本語でも構いません。重要なのは、毎日同じ名前で同じ場所にあることです。
5〜12分：入口ファイルを書く
START_HERE.md は次の程度で十分です。
# 今日の操作盤
## 対象
- プロジェクト：自分のサイト名
- 本番ブランチ：main
- 今日の作業ブランチ：fix/form-message
- 今日届ける価値：空欄時に次の操作が分かる
## 開く順番
1. AI_REQUEST.md
2. AIとの作業画面
3. GitHubのプルリクエスト
4. プレビューURL
5. DAILY_CHECK.md の本番反映前
6. デプロイナウのデプロイ履歴
7. 本番の公開URL
8. DAILY_CHECK.md の公開後
## 現在地
- [x] 目的を決めた
- [ ] AIへ依頼した
- [ ] 差分を確認した
- [ ] プレビューを確認した
- [ ] 本番反映を承認した
- [ ] デプロイ成功を確認した
- [ ] 公開URLを確認した
- [ ] 記録を閉じた
## 異常時
新しい変更を止めて RECOVERY.md を開く。
URLや認証情報を全部ここへ貼る必要はありません。公開してよいURLと、GitHubのプルリクエストURL程度に留めます。パスワード、APIキー、環境変数の値は書きません。
12〜18分：3ファイルを短く整える
AI_REQUEST.md には、目的、変更可能範囲、変更禁止範囲、完了条件、停止条件を置きます。
DAILY_CHECK.md は開始前、本番反映前、公開後に分けます。
RECOVERY.md は検知、停止、正常地点の特定、復旧、確認、再開の順にします。
3ファイルをすべて開いた状態で、スクロールせずに最初の行動が分かるか確認します。長い背景説明は、週次記録や別の設計文書へ移します。
18〜24分：ブラウザタブを5つ並べる
タブの並びを毎回同じにします。
[AI] [GitHub PR] [プレビュー] [デプロイ履歴] [本番]
ブラウザがタブグループやウィンドウ保存に対応しているなら、プロジェクト名でまとめます。対応していなくても、左からこの順で開くだけで効果があります。
タブ名だけでは判別しにくい場合は、プルリクエスト番号、プレビュー、本番のホスト名を見てから操作します。前日のタブを使い回すときは、今日の対象と一致するか最初に確認します。
24〜30分：公開しない模擬操作をする
実際にマージやpushをせず、入口から順に移動します。
START_HERE.mdを開く
→ AI_REQUEST.mdを読む
→ AI画面を開く
→ GitHubの対象プルリクエストを確認する
→ プレビューの場所を確認する
→ デプロイナウの対象プロジェクトを確認する
→ 本番URLを開く
→ RECOVERY.mdへ戻れるか試す
3分以内に一周できなければ、リンク、ファイル名、並び順のどこで迷ったかを直します。
毎日の操作を8段階に固定する
1. START_HEREを開く
最初に今日の対象を確認します。
- プロジェクト名
- 本番ブランチ
- 作業ブランチ
- 今日届ける価値
- 現在地
前日の内容が残っている場合は、そのまま作業を始めません。今日の対象へ更新してから進みます。
2. AIへの依頼を組み立てる
AI_REQUEST.md を土台に、今日だけの目的を加えます。
目的：空欄時の案内を分かりやすくする
変更してよい範囲：入力フォームと対応テスト
変更しない範囲：認証、DB、環境変数、デプロイ設定
完了条件：空欄と正常入力の結果を示す
停止条件：範囲外変更や削除が必要
AIには、変更結果だけでなく、変更ファイル一覧、実行した確認、実行していない確認も出してもらいます。
3. GitHubで差分を見る
AIの説明をそのまま事実にしません。GitHubのプルリクエストで実際の差分を確認します。
見る順番を固定します。
タイトルと目的
→ 変更ファイル数
→ 予定外のファイル
→ 削除
→ 設定や環境変数に関する変更
→ テスト結果
内容の理解が難しくても、「頼んだ範囲と変更ファイルが一致するか」は確認できます。
予定外のファイルがあれば、次へ進まずAIへ説明を求めます。
4. プレビューを操作する
プレビューは、見た目を眺める画面ではなく、本番反映前に利用者の操作を試す場所です。
最低限、次を確認します。
正常な入力
空欄や誤入力
スマートフォン幅
主要リンク
秘密情報が表示されていないこと
デプロイナウのGitHub連携では、プレビューが有効なプロジェクトで対象条件を満たすプルリクエストを作ると、専用URLでビルド・デプロイされます。GitHub Appのコメントから状態とURLを確認でき、プロジェクト詳細の「デプロイ」タブでも本番とプレビューの履歴やビルドログを確認できます。
ただし、プレビューURLはURLを知る人がアクセスでき、デプロイナウ側にアクセス制限機能はありません。秘密情報や公開前の機密内容を置かないことを、操作盤の目立つ場所へ書きます。
5. 人間が本番反映を承認する
差分とプレビューを確認したあと、DAILY_CHECK.md の本番反映前を実行します。
[ ] 今日の目的と差分が一致する
[ ] 予定外の変更がない
[ ] プレビューで対象操作を確認した
[ ] 戻るコミットが分かる
[ ] 未確認事項を理解した
[ ] 本番反映を人間が承認した
チェックが埋まったことではなく、根拠を確認した人が承認することが重要です。
6. デプロイ履歴を見る
デプロイナウは、GitHubで接続した対象ブランチへのpushを受けると、自動でビルドとデプロイを始め、成功すると公開中のサイトへ反映します。
ここで確認するのは、次の4点です。
- 対象プロジェクトが正しい
- 本番のデプロイである
- 対象の変更に対応する履歴である
- ビルドとデプロイが成功している
失敗した場合は、何度も同じ操作を繰り返しません。ビルドログの先頭からすべて読むのではなく、失敗段階、最初の明確なエラー、直前の変更を記録します。
7. 本番URLを新しいタブで確認する
成功表示だけで完了にしません。
本番URLを新しいタブで開き、利用者と同じ入口から操作します。ログイン状態やキャッシュの影響が疑われる場合は、その条件も記録します。
[ ] トップが開く
[ ] 今日変更した操作が完了する
[ ] 変更していない主要操作が1つ動く
[ ] エラー表示が利用者向けになっている
[ ] 秘密情報が表示されない
8. 記録を閉じる
最後に START_HERE.md の現在地を完了へ更新し、日次記録を残します。
## 2026-11-06
- 届けた価値：空欄時に次の操作が分かる
- 本番コミット：短い識別子
- 確認：正常入力、空欄、390px幅
- 結果：完了
- 未確認：タブレット幅
- 戻り先：直前の正常コミット
- 所要時間：48分
「全部問題なし」だけでは、翌週の改善に使えません。何を確認し、何を確認していないかを分けます。
タブごとに役割と完了条件を書く
ブラウザタブは、開いているだけでは操作盤になりません。各タブの役割を一つにします。
| タブ | 役割 | 次へ進む条件 |
|---|---|---|
| AI | 作業案と確認結果を受け取る | 変更範囲と未実施確認が分かる |
| GitHub PR | 実際の差分を見る | 予定外変更がない |
| プレビュー | 本番前に操作する | 対象ケースが合格する |
| デプロイ履歴 | 反映処理を確認する | 対象の本番デプロイが成功する |
| 本番 | 利用者と同じ入口で確認する | 公開後チェックが完了する |
この表があると、「GitHubで緑だから本番も完了」「プレビューが動いたからデプロイ成功」という混同を減らせます。
迷子を防ぐ命名ルール
複数のブランチやプルリクエストを同時に開くと、対象を間違えやすくなります。難しい命名規則より、見ただけで目的が分かる形を選びます。
ブランチ：fix/form-empty-message
PRタイトル：空欄時の案内を分かりやすくする
日次記録：2026-11-06-form-empty-message.md
番号だけ、日付だけ、test2 のような名前だけにしません。
入口ファイルには、GitHubの対象プルリクエストと、本番ブランチを分けて書きます。
本番ブランチ：main
作業ブランチ：fix/form-empty-message
プルリクエスト：#42
プレビューと本番のタブを隣に置く場合も、URLのホスト名と画面内の内容を確認してから操作します。
URLを置いてよい場所、置かない場所
操作盤にはリンクが必要ですが、すべてをMarkdownへ保存してよいわけではありません。
置いてよいもの
- 公開されている本番URL
- GitHubのプルリクエストURL
- 公開して問題のない公式ドキュメント
- チーム内ルールに沿ったデプロイ管理画面への案内
置かないもの
- パスワード
- APIキーやアクセストークン
- 環境変数の値
- 個人情報を含むURL
- 一時的な認証情報を含むリンク
- 公開前の秘密情報を表示するプレビューURL
環境変数は、コードや操作盤へ値を書かず、デプロイナウ側の本番・プレビューそれぞれの設定場所で管理します。プレビューには本番用の環境変数が自動では渡らないため、プレビューに必要な値はプレビュー用として分けます。
操作盤には値ではなく、次のような確認だけを書きます。
[ ] 本番とプレビューの設定先を取り違えていない
[ ] 必要なキー名が存在する
[ ] 値をチャット、画像、ログへ貼っていない
異常が起きたら操作盤の順路を切り替える
通常時は左から右へ進みます。
AI → GitHub → プレビュー → 承認 → デプロイ履歴 → 本番
異常時は、新しい改善案を考える前に RECOVERY.md へ移動します。
異常を記録
→ 新しい変更を止める
→ 現在の本番コミットを確認
→ 最後の正常地点を確認
→ 承認した方法で復旧
→ 本番URLで確認
→ 人間が再開判断
異常時に開くタブも絞ります。
[RECOVERY.md] [GitHub履歴] [デプロイ履歴] [本番URL]
AIとの会話や新しいプレビューを増やし続けると、どの変更が本番へ入ったか分かりにくくなります。まず現状を固定します。
デプロイナウでは、自動デプロイを停止しても公開中のサイトとリポジトリ接続は残ります。ただし、停止は以前の正常状態へ戻す操作ではありません。停止、復旧、公開確認、再開を別々に扱います。
AIに操作盤の案内役を頼む
AIは操作の代わりではなく、現在地の整理役として使えます。
開始時の依頼例：
START_HERE.md、AI_REQUEST.md、DAILY_CHECK.md、RECOVERY.mdを読み、
今日の目的、変更可能範囲、停止条件、確認順を5項目以内で整理してください。
ファイルや外部サービスは変更せず、最初に人間が確認する点を示してください。
差分確認前の依頼例：
変更ファイル一覧を、許可範囲内、範囲外、判断が必要、の3つに分けてください。
実行済みの確認と未実施の確認を分けてください。
マージや公開は行わず、人間が見るべき差分を先に示してください。
終了時の依頼例：
今日の記録から、届けた価値、確認した証拠、未確認、戻り先、所要時間を整理してください。
推測で補わず、次回の操作盤へ反映する改善候補を最大1件だけ示してください。
AIに「次へ進んで」とだけ頼まず、現在の段階と、人間の承認が必要な境界を毎回示します。
操作盤を重くしない週次メンテナンス
毎週10分だけ、次を確認します。
リンク切れ
本番URL、GitHubリポジトリ、公式ドキュメントへの案内が現在も使えるか確認します。
古い対象
閉じたプルリクエスト、削除したブランチ、前週の日付を入口から外します。
重複
同じチェックが START_HERE.md と DAILY_CHECK.md の両方に詳しく書かれている場合、入口にはリンクだけを残します。
所要時間
操作盤を開いてから目的と停止条件を確認するまで、5分を超えていないか測ります。
実際に使ったか
1週間まったく開かなかったファイルは、場所が悪いか、内容が重複している可能性があります。ただし、復旧カードは使わなかっただけで削除しません。
よくある失敗
リンク集だけになる
URLだけ並べても、見る目的と次へ進む条件が分かりません。各リンクに役割を1行添えます。
タブを開きすぎる
参考資料、検索結果、複数のAI会話が並ぶと対象を誤ります。通常ルートの5タブと、必要な資料を分けます。
進行表を完璧に埋めることが目的になる
チェックは証拠の代わりではありません。「確認した」にチェックする前に、どの画面で何を見たかを言えるようにします。
古いタブを信用する
プレビューURLが同じでも内容は更新される場合があります。GitHubの対象ブランチ、最新のデプロイ履歴、表示内容を組み合わせて確認します。
復旧リンクが通常ルートの最後にある
異常時に探さないよう、START_HERE.md の先頭付近へ RECOVERY.md の案内を置きます。
操作盤へ秘密情報を集める
便利さのためにトークンやパスワードを貼ると、共有・画面撮影・AIへの貼り付けで漏れる可能性があります。操作盤は値ではなく、設定場所と確認行動を案内します。
最初の1週間の整え方
1日目：入口だけ作る
START_HERE.md を作り、対象、目的、開く順番、異常時の戻り先を書きます。
2日目：5タブを並べる
AI、GitHub、プレビュー、デプロイ履歴、本番を左から並べます。
3日目：タブの完了条件を書く
各画面で何が確認できたら次へ進むかを1行にします。
4日目：3分の模擬操作をする
公開せず、入口から本番確認、異常時ルートまで移動します。
5日目：1件だけ実際に使う
小さな文言修正など、影響範囲を説明しやすい変更で操作盤を使います。
6日目：迷った地点を直す
人の注意力ではなく、ファイル位置、タブ順、案内文を直します。
7日目：不要な案内を減らす
重複、古いリンク、長すぎる説明を整理し、入口を1画面程度へ戻します。
公式情報として確認した点
本記事では、デプロイナウの現行仕様について、2026年11月6日に公式ドキュメントで次を確認しました。
- 接続した対象ブランチへのpushで、自動的にビルドとデプロイが始まる
- デプロイの進行状況とビルドログは、プロジェクト詳細の「デプロイ」タブで確認できる
- 条件を満たすプルリクエストでは専用のプレビューURLが作られ、GitHub Appのコメントから状態とURLを確認できる
- プレビューURLを知る人へのアクセスを、デプロイナウ側で制限する機能はない
- 本番用とプレビュー用の環境変数は分かれている
- 自動デプロイ停止中も、公開中のサイトとリポジトリ接続は残る
仕様や画面は変わる可能性があります。実際に設定・公開するときは、最新の公式情報を確認してください。
参考：
まとめ
毎日デプロイの操作盤は、特別な管理システムではありません。
プロジェクト直下の短いファイルと、役割を固定したブラウザタブを、毎日同じ順番で使う仕組みです。
今回の要点は次のとおりです。
-
START_HERE.mdを入口にし、AI指示、日次確認、復旧カードへつなぐ - AI、GitHub、プレビュー、デプロイ履歴、本番を左から並べる
- 各画面の役割と、次へ進む条件を1つにする
- GitHubの差分、プレビュー、デプロイ成功、本番確認を別の段階として扱う
- 異常時は通常ルートを離れ、復旧カードへ切り替える
- 操作盤に秘密情報を置かず、設定場所と確認行動だけを書く
- 毎週、古いリンク、重複、使わない案内を減らす
操作盤の目的は、考えなくても公開できるようにすることではありません。
人間が判断すべき場所へ、迷わず、証拠を持って到着できるようにすることです。
最初の一歩は、プロジェクトの入口に START_HERE.md を作り、「今日の対象」「開く順番」「異常時の戻り先」の3つだけを書くことです。
次回は、この操作盤に残った日次記録を使い、作業時間、確認漏れ、やり直しの回数を見える化し、操作盤を軽くしていく方法を整理します。