非エンジニアでもDeploy Nowで毎日デプロイできる体制の作り方――AI利用履歴から組み立てた実践運用
私はこれまで、AIで小さなアプリを作る方法、GitHubへ保存する方法、ロリポップ！デプロイナウで公開する方法、公開後に安全に更新する方法を個別に整理してきました。
しかし、過去のAI利用履歴を並べ直して見えてきたのは、便利なツールを増やすだけでは「毎日何かをデプロイする体制」にならないということでした。
本当に必要だったのは、次の4つを毎日同じ順番で回せるようにすることです。
- 人間が、その日に届ける最小の価値を1つ決める
- AIが、決めた範囲だけを実装・確認する
- GitHubへ、戻れる単位で変更を保存する
- Deploy Nowで公開し、利用者と同じURLで人間が確認する
この記事では、非エンジニアが「コードを全部理解してから公開する」のではなく、変更範囲、確認方法、停止条件を理解して毎日デプロイするための体制を、かなり細かく分解します。
なお、ここでいう「毎日デプロイ」は、毎日新しいアプリを量産することではありません。同じアプリへ説明を1行足す、入力時のエラー表示を直す、スマートフォン表示を整える、といった小さな改善も1回のデプロイです。
AI利用履歴を読み返して分かったこと
これまでの履歴では、作業方法が少しずつ変化していました。
最初は「AIにアプリを作ってもらい、公開する」という一続きの依頼でした。次に、公開中の状態を残してから修正する、1回に1つだけ変更する、少人数に試してもらう、複数AIが同じ原本を読む、といったルールが増えました。
この変化を整理すると、AIの性能よりも運用の境界が重要だったと分かります。
| 段階 | 最初の考え方 | 履歴から残ったルール |
|---|---|---|
| 作る | AIへ完成品を頼む | 今日の目的を1文にし、変更を1つに絞る |
| 保存する | 完成ファイルを置く | GitHubへ差分と理由をコミットする |
| 公開する | デプロイ成功を待つ | 公開URLで主要操作をやり直す |
| 改善する | 気になる点を全部直す | 事実と推測を分け、優先する1件だけ直す |
| 引き継ぐ | チャット履歴を探す | 現在地・禁止事項・次の作業を原本に残す |
今回読み返した主な履歴は、次の記事です。
- 初心者でもできる、AI・GitHub・ロリポップ！デプロイナウでアプリを公開する流れ
- AIにアプリ作りを頼むとき、依頼を小さく分ける方法
- AIで作った小さなアプリを毎日公開する「1日1デプロイ」の進め方
- 複数のAIを使う前に、原本を1つに決める理由
単体では公開手順、依頼の分け方、日次運用、原本管理の記事でした。今回は、その間に共通していた判断を1本の運用へつなぎ直しています。
つまり、毎日デプロイできた理由を「AIがコードを書けるから」だけで説明すると、大切な部分が抜けます。
AIは、計画、実装、テスト候補、差分説明を速くできます。しかし、今日は何を届けるのか、どこまでなら公開してよいのか、公開後の画面を合格とするかは人間が決めます。
「毎日新作」ではなく「毎日、公開可能な差分を1つ」
毎日デプロイと聞くと、毎日ゼロから新しいWebアプリを作る姿を想像しがちです。それでは、リポジトリ、公開URL、設定、確認項目が増え続け、非エンジニアほど現在地を見失います。
私が採用する単位は、1日1プロジェクトではなく、さらに小さな1日1公開可能差分です。
たとえば、次の変更はそれぞれ1日分になります。
- 初日は、タイトルと説明だけがある1画面を公開する
- 翌日は、入力欄と追加ボタンを付ける
- 次の日は、空欄のときの案内を追加する
- その次は、スマートフォン幅のボタン配置を直す
- 利用者の反応を見て、分かりにくい文言を1つ直す
1回の変更が小さいと、確認する項目も少なくなります。問題が起きたときも、直前のコミットとの差分を見れば原因候補を絞れます。
一方、「ログイン、決済、データベース、管理画面を今日まとめて追加する」のような依頼は、1日分として大きすぎます。技術的にAIが生成できても、人間が確認できないなら公開単位としては不適切です。
4つの役割を混ぜない
毎日デプロイする体制は、次の4役で考えると理解しやすくなります。
人間：目的と公開判断
人間は、今日の目的、完成条件、変更してよい範囲、公開してよい情報を決めます。コードをすべて書けなくても、「今日追加したボタンを押すと何が起きるべきか」は説明できる必要があります。
AI：計画、実装、確認の補助
AIは、目的をファイル変更へ分解し、コードを編集し、テストや確認項目を提案します。作業後は、変更したファイルと確認結果を説明させます。ただし、AIの「完了しました」は公開確認の代わりになりません。
GitHub：変更履歴の原本
GitHubには、現在公開するコードと、そこへ至る変更履歴を置きます。チャットの最後の回答ではなく、リポジトリのブランチとコミットを現在地にします。
Deploy Now：ビルドと公開
Deploy Nowは、GitHubの指定ブランチからコードを取得し、ビルドして公開URLへ反映する担当です。公式ドキュメントでは、GitHub Appでリポジトリを接続すると、指定ブランチへのpushをきっかけに自動でビルドとデプロイが始まります。
ここを分けると、問題の場所も見つけやすくなります。
要望が曖昧 → 人間の目的・完成条件を見直す
変更範囲が広い → AIへの依頼を小さくする
何を変えたか不明 → GitHubの差分とコミットを見る
ビルドが失敗 → Deploy Nowのビルドログを見る
公開後だけ動かない → 公開URL、パス、環境変数を確認する
最初に一度だけ作る「公開の土台」
毎日の作業を軽くするには、初日に接続と確認方法を固定します。
1. 1つのリポジトリと1つの公開URLから始める
練習用に、1画面の小さなアプリを1つ選びます。最初から複数のリポジトリや本番サービスを扱いません。
GitHub連携では、Deploy Nowの1プロジェクトにつき接続できるリポジトリは1つです。公開対象のブランチも選びます。初心者は、まずmainなど1本のブランチに決め、別ブランチの変更を誤って公開しないようにします。
GitHub Appのアクセス許可は、可能ならOnly select repositoriesで必要なリポジトリだけを選びます。すべてのリポジトリへ広く許可する必要がなければ、対象を狭くした方が確認しやすくなります。
2. フレームワークと入口を確認する
GitHubから新しいプロジェクトを作る場合、公式案内ではフレームワークは自動判別されません。アプリと異なるものを選ぶとビルドに失敗するため、AIへ次を説明させます。
このリポジトリをDeploy Nowで公開します。
使用しているフレームワーク、ビルドコマンド、公開される出力、
最初に表示される入口ファイルを、初心者向けに説明してください。
推測せず、package.jsonなど実際のファイルを根拠にしてください。
AIが回答したあと、package.json、設定ファイル、ファイル構成を自分でも照合します。
3. 秘密情報をコードから外す
APIキーやパスワードをコードや公開リポジトリへ書きません。Deploy Nowの公式案内では環境変数をダッシュボードから管理できます。
ただし、環境変数へ移せば何でも安全になるわけではありません。ブラウザへ配信されるコードから参照する値は、最終的に利用者から見える場合があります。秘密にする必要がある処理は、フロントエンドだけで完結させない設計が必要です。
4. 最初の正常な状態を記録する
初回デプロイが成功したら、次を残します。
公開URL：
公開対象ブランチ：
正常だったコミット：
確認日時：
確認した操作：
- トップ画面が表示される
- 主要ボタンが動く
- スマートフォン幅で読める
戻すときの基準：上記コミット
この記録が、翌日からの比較基準になります。
毎日の標準ループを固定する
毎日デプロイを続けるため、私は作業を7段階に分けます。
1. 公開中の状態を先に見る
作業開始時に公開URLを開きます。画面が表示され、昨日までの主要操作が動くことを確認します。
これを省くと、今日の変更前から壊れていた問題を、今日のAI作業が原因だと誤解することがあります。
2. 今日の価値を1文にする
「便利にする」ではなく、利用者の変化を書きます。
今日の価値：空欄で追加ボタンを押した人が、次に何を入力すればよいか分かる。
完成条件は、目で確認できる3項目以内にします。
- 空欄では一覧へ追加されない
- 入力を促すメッセージが表示される
- 正常な文字入力なら、これまでどおり追加できる
3. AIへ変更範囲と触らない範囲を渡す
AIへの依頼は、目的だけでなく境界を含めます。
今日の目的は、空欄送信時の案内を追加することです。
まず変更予定のファイルと理由を示してください。
データ保存方法、画面全体のデザイン、既存の削除機能は変更しないでください。
実装後は、変更差分と確認手順を報告してください。
秘密情報、外部送信、依存ライブラリの追加が必要なら作業を止めてください。
依存ライブラリの追加、認証、外部API、データ削除が出てきたら、その日の小変更から外れていないか見直します。
4. ローカルで変更前後を確認する
最低限、次を確認します。
- 今日の完成条件を満たす
- 変更していない主要操作が動く
- エラー文やテスト用データが残っていない
- APIキー、個人情報、ローカルの絶対パスが差分にない
- 予想していないファイルが変更されていない
テストがある場合は実行し、テスト名と結果を残します。テストがない小さな画面でも、自分で行った操作を記録します。
5. GitHubへ戻れる単位で保存する
コミットメッセージは、結果が分かる言葉にします。
空欄送信時の案内を追加
updateやfixだけでは、後から戻す場所を選びにくくなります。1つのコミットに、今日の目的と関係のない整形や別機能を混ぜません。
6. Deploy Nowの結果と公開URLを確認する
GitHub連携では、指定ブランチへpushすると自動デプロイが始まります。Deploy Nowの「デプロイ」画面で進行状況とビルドログを確認します。
成功表示のあと、必ず公開URLを開きます。
A. 新しい変更が見える
B. 今日の完成条件を操作で確認できる
C. 変更していない主要操作も動く
D. スマートフォン幅でも読める
ビルド成功は、利用者の操作成功を保証しません。だから、ログの成功と公開URLの確認を別々に行います。
7. 事実、判断、次の一手だけ残す
長い日報は不要です。翌日に別のAIが読んでも再開できる内容を残します。
日付：2026-11-02
目的：空欄送信時の案内を追加
公開コミット：abc1234
Deploy Now：成功
公開URL確認：完了
確認した操作：空欄、正常入力、削除
未確認：古いスマートフォンでの表示
次の候補：案内文を少人数に読んでもらう
30分・60分・90分の作業サイズを決める
毎日続けるには、作業量を時間で切る方法も有効です。
| 時間 | 向いている作業 | その日の完了 |
|---|---|---|
| 30分 | 文言、色、余白、説明、エラー表示 | 小さな差分を1つ公開して確認 |
| 60分 | 入力検証、単純な操作、1画面の改善 | 正常・異常の両方を確認して公開 |
| 90分 | 小さな新画面、既存機能の整理 | 実装、回帰確認、公開記録まで |
時間内に終わらない場合は、未完成を無理に公開しません。変更をさらに分けるか、公開対象ブランチへ入れずに翌日へ回します。
「毎日デプロイする」は品質基準を下げる命令ではなく、毎日完了できるサイズへ仕事を分ける訓練です。
失敗した日の標準手順も決める
毎日デプロイする体制では、失敗しないことより、失敗時に混乱しないことが重要です。
ビルドに失敗した場合
- 新しい変更を追加するのを止める
- Deploy Nowのビルドログで最初のエラーを見る
- 直前コミットの変更ファイルと照合する
- エラーから秘密情報を除いてAIへ渡す
- 修正するか、正常だったコミットへ戻すかを人間が決める
デプロイ成功後に画面が壊れた場合
ビルドの問題ではなく、公開後の実行時エラー、パス、環境変数、キャッシュなどを疑います。ブラウザの開発者ツールを使えなくても、どの操作で何が起きたかを記録できます。
公開URL：
操作：追加ボタンを1回押した
期待：一覧に1件増える
実際：反応なし
画面に出た文字：なし
直前の正常コミット：
AIには、この事実と差分を渡します。「何となく動かない」より原因候補を絞りやすくなります。
自動デプロイを止めたい場合
公式ドキュメントでは、GitHub接続後も設定画面から自動デプロイを停止・再開できます。停止しても公開中のサイトは止まりません。
大きな整理をするとき、連続して複数コミットをpushするとき、原因調査中に公開を更新したくないときは、自動デプロイを止める選択肢があります。再開条件と担当者を記録し、忘れたままにしないことが大切です。
AIに任せてよいこと、任せきらないこと
AIに任せやすい作業は、入力と期待する出力を確認できるものです。
- 今日の目的を実装タスクへ分解する
- 変更候補のファイルを列挙する
- コードを編集する
- テストケースや確認手順を作る
- 差分を初心者向けに説明する
- ビルドログから原因候補を整理する
- 日次記録の下書きを作る
人間が持つ判断は、外部への影響と価値に関するものです。
- 今日、本当に公開する価値は何か
- 変更範囲を十分に理解できるか
- 個人情報や秘密情報を扱ってよいか
- 未確認事項が残った状態で公開してよいか
- 公開後の画面を合格とするか
- 問題時に戻すか、利用を制限するか
特に、認証、決済、削除、外部送信、個人情報、顧客データが関係する変更は、単純な「1日1デプロイ」の練習と同じ扱いにしません。別のレビューとHuman Approvalを置きます。
週に一度、速度ではなく体制を見直す
毎日の成果数だけを見ると、無理に公開する方向へ寄ります。週次では次を確認します。
## 今週の確認
- デプロイ回数：
- 公開URLまで確認できた回数：
- 失敗・ロールバック回数：
- 1回の変更が大きすぎた日：
- AIが想定外に触ったファイル：
- 繰り返した手作業：
- 来週、手順へ追加する確認：
見るべき数字はデプロイ回数だけではありません。
- 公開後の確認まで終わった割合
- 問題発見から正常状態へ戻るまでの時間
- 予定外に変更されたファイル数
- 同じ原因の失敗が再発した回数
- 翌日に別のAIでも再開できた回数
同じ手作業が3回続いたら、自動化候補にします。ただし、公開可否やロールバックの判断まで自動化するのではなく、チェック一覧の生成、ログ取得、URL疎通確認など、結果を人間が確認できる部分から始めます。
最初の7日間はこう始める
非エンジニアが一気に体制を作ろうとすると、運用文書を作るだけで終わります。最初の1週間は、実際に公開しながら必要なルールだけ増やします。
| 日 | 作業 | 学ぶこと |
|---|---|---|
| 1 | 1画面を初回公開 | GitHub、Deploy Now、公開URLの関係 |
| 2 | 説明文を1行変更 | 差分、コミット、自動デプロイ |
| 3 | 入力の異常ケースを1つ追加 | 正常と異常の確認 |
| 4 | スマートフォン表示を修正 | 公開後の実機確認 |
| 5 | 1人に1操作だけ試してもらう | 事実と感想の分離 |
| 6 | 直前コミットへ戻す練習 | ロールバックの入口 |
| 7 | 1週間の記録を整理 | 続ける確認と削る手順 |
6日目の「戻す練習」は、障害を起こすという意味ではありません。練習用プロジェクトで、どのコミットが正常状態か、戻すときに誰が何を確認するかを言葉にします。
現在のDeploy Now公式仕様で確認しておく点
この記事の執筆時点（2026年11月2日）に、公式情報から確認した主な点は次のとおりです。
- GitHub Appでリポジトリを接続できる
- 指定ブランチへのpushで、自動ビルド・デプロイが始まる
- 1プロジェクトにつき接続できるリポジトリは1つ
- GitHub連携後に、対象ブランチの変更、自動デプロイの停止・再開、接続解除ができる
- 自動デプロイを停止しても、公開中のサイトは停止しない
- 公開URLはサブドメイン形式で、HTTPSへ自動対応する
- 環境変数をダッシュボードから管理できる
- GitHub以外に、CLI、AIエージェント、ドラッグ＆ドロップによる公開方法もある
サービスの対応フレームワーク、プラン、上限、提供状況は変わる可能性があります。実際に始めるときは、必ず公式ページとドキュメントを確認してください。
参考：
まとめ
非エンジニアが毎日デプロイするために必要なのは、毎日大量のコードを書く力ではありません。
- 毎日、新作ではなく公開可能な差分を1つ選ぶ
- 目的と完成条件を、人間が確認できる言葉にする
- AIへの依頼へ、変更範囲と触らない範囲を入れる
- GitHubを現在地と変更履歴の原本にする
- Deploy Nowの成功表示と、公開URLの動作確認を分ける
- 正常だったコミットと戻す基準を残す
- 失敗時は新しい変更を重ねず、事実、差分、ログを見る
- 日次記録は、事実、判断、次の一手へ絞る
- 外部へ影響する公開判断は、人間が持つ
過去のAI利用履歴を振り返ると、AIを増やしたことより、作る・保存する・公開する・確認するの境界を固定したことが、継続につながっていました。
毎日デプロイする体制とは、毎日必ず何かを世に出す根性論ではありません。毎日、安全に完了できる大きさへ仕事を分け、問題があれば戻れ、翌日に別のAIでも同じ現在地から再開できる仕組みです。
最初の1日は、説明文1行の変更でも構いません。小さな差分をGitHubへ保存し、Deploy Nowの結果を見て、公開URLを自分の手で確認する。その一周を短く回せたことが、毎日続く体制の最初の完成です。
次回は、毎日デプロイの記録が増えたとき、公開回数ではなく「利用者へ届いた価値」と「戻しやすさ」で週次レビューする方法を整理します。