AIでサイトを作れるようになると、最初はかなり楽しいです。
「このページを作って」 「このボタンを直して」 「この文章を差し替えて」 「スマホで見やすくして」
こう伝えるだけで、AIがどんどんコードを書いてくれる。
これまでエンジニアに頼まないと触れなかったものを、自分で動かせるようになる感覚があります。
ただ、ここで多くの人がつまずく場所があります。
それは、コードの書き方ではありません。
作業場を戻せる状態にしていないことです。
AIが便利だからこそ、作業はどんどん進みます。
でも、どこからどこまでが終わった作業なのか。
どの変更が本番に出ているのか。
どの変更は途中なのか。
いらない作業を消しても大丈夫なのか。
変な状態になった時に、どこまで戻せるのか。
ここが分からないまま進めると、サイト開発は急に怖くなります。
バイブコーディングで怖いのは、AIが間違えることだけではない
AIで開発していると、「AIが変なコードを書くのが怖い」と思いがちです。
もちろん、それもあります。
でも実務で見ると、もっと怖いのは別のことです。
古い作業場のまま、次の作業を始めてしまうことです。
たとえば、ある日にホームページのデザインを直したとします。
その作業がまだ本番反映されていない。
でも、同じ作業場で今度は料金ページを直す。
さらにその次に、ブログの見た目を直す。
その途中で、記事本文も少し移動する。
こうなると、作業場の中にはいろいろな変更が混ざります。
- ホームの変更
- 料金ページの変更
- ブログの変更
- 記事データの移動
- もう本番に入ったはずの古い変更
- 途中でやめた変更
- AIが作ったけれど使わなかったファイル
この状態でAIに「この修正を本番に反映して」と頼むと、AIは見えている差分を前提に動いてしまいます。
AIは便利ですが、こちらの作業場が汚れていると、その汚れまで含めて「今の状態」として扱います。
だから、バイブコーディングで最初に覚えるべきなのは、かっこいいプロンプトよりも、作業場をきれいに保つことです。
GitHubは、エンジニアだけのものではない
GitHubという名前を聞くと、エンジニア向けの難しい場所に感じるかもしれません。
でも、AIでサイトを作る人にとってのGitHubは、もっとシンプルに理解して大丈夫です。
GitHubは、ざっくり言うと、
サイトの変更履歴を残しておく場所
です。
共同開発をするためだけのものではありません。
一人で開発していても、GitHubを使う意味はあります。
なぜなら、開発では「戻せること」が信頼性になるからです。
文章を書いている時も、下書きが残っていれば安心です。
スプレッドシートも、変更履歴があれば戻せます。
デザインも、前の案が残っていれば比較できます。
サイト開発も同じです。
今の状態が壊れた時に、昨日の状態へ戻せる。
いらない変更を消せる。
どの変更を本番に出したのか追える。
これがあるだけで、AIに作業を任せる怖さはかなり減ります。
mainは、いまの正本
GitHubやAI開発でよく出てくる言葉に、main があります。
難しく考えなくて大丈夫です。
main は、いまの正本です。
つまり、サイトの基準になる場所です。
本番サイトに反映されている状態、または本番に出す前提の最新状態に近いものだと考えると分かりやすいです。
AIで作業を始める時は、基本的にこの最新の main から始めるべきです。
なぜなら、古い状態から作業を始めると、すでに本番で直っている内容をまた古い状態へ戻してしまうことがあるからです。
たとえば、本番ではボタン文言が新しくなっている。
でも、ローカルの古い作業場では昔の文言のまま。
その古い作業場で別の修正をして本番に出すと、新しいボタン文言が昔に戻る可能性があります。
これはAIが悪いというより、作業場の基準が古いことが原因です。
branchは、別の作業机
branch という言葉もよく出ます。
これは、別の作業机だと思ってください。
正本である main を直接いじるのではなく、作業ごとに別の机を作る。
たとえば、
- ブログ本文の幅を直すbranch
- 特典ページを作るbranch
- ホームの導線を直すbranch
- 料金ページを直すbranch
このように分けます。
なぜ分けるのか。
理由は、作業を混ぜないためです。
ブログの幅を直しただけのつもりなのに、なぜかホームの文言まで変わっている。
料金ページの修正を頼んだら、昔のブログ修正まで混ざっている。
こうなると、確認する人も困ります。
AIにとっても、人間にとっても、1つのbranchには1つのテーマだけ入っている方が安全です。
commitは、セーブポイント
commit は、ゲームでいうセーブポイントに近いです。
「ここまでの変更を、ひとまとまりとして保存する」ということです。
たとえば、
- 特典ページを追加した
- ブログ本文の幅を調整した
- ホーム導線を改善した
このように、作業単位で保存しておきます。
commitがあると、後から見た時に「この時、何を変えたのか」が分かります。
逆に、commitせずに作業を積み上げ続けると、どこまでが完了で、どこからが途中なのか分からなくなります。
AIで開発している時ほど、commitは大事です。
AIは一気に多くのファイルを変えられるからです。
人間が手で1ファイルずつ変えている時よりも、気づかないうちに変更範囲が広がりやすい。
だから、こまめにセーブポイントを作る必要があります。
PRは、確認用の箱
PR は Pull Request の略です。
これも難しく考えなくて大丈夫です。
PRは、変更を本番側へ入れる前の確認用の箱です。
「このbranchでは、こういう変更をしました。問題なければmainへ入れてください」
という提出物です。
共同開発では、他の人に見てもらうために使います。
でも一人開発でも、PRは役に立ちます。
なぜなら、変更内容がまとまって見えるからです。
- どのファイルが変わったか
- 何行変わったか
- 何を目的にした変更か
- 本番に入れる前に確認すべきことは何か
これらを整理できます。
AIにコードを書かせるなら、PRは「AIがやったことを人間が確認する場所」として使えます。
dirtyは、机の上に紙が散らばっている状態
開発していると、dirty という言葉が出ることがあります。
これは、作業場に未整理の変更が残っている状態です。
たとえば、
- 変更したけれど保存地点にしていない
- 削除したファイルがある
- 新しく作ったけれど管理されていないファイルがある
- どの作業に属するか分からない差分が残っている
こういう状態です。
dirtyが少しあるだけなら問題ではありません。
作業中なら当然dirtyになります。
問題は、何のdirtyか分からないまま、次の作業を始めることです。
これは、机の上に前の仕事の紙が散らばったまま、新しい仕事を始めるようなものです。
最初はなんとかなります。
でも、3つ、4つと仕事が重なると、何を捨ててよくて、何を残すべきか分からなくなります。
AI開発では、dirtyを放置すると判断が重くなる
AI開発でdirtyが残ると、問題はコードだけでは終わりません。
判断が重くなります。
「これは本番に出ているんだっけ」 「これはClaude Codeが直している途中だっけ」 「これはCodexが別の作業で作ったやつだっけ」 「消していいのか、残すべきなのか」
こういう確認が増えます。
確認が増えると、開発が遅くなります。
そして、遅くなるだけならまだいいです。
本当に怖いのは、判断できない作業が増えることです。
決まっていない作業。
終わっていない作業。
誰が持っているか分からない作業。
必要か不要か分からない作業。
これが増えると、開発は前に進んでいるようで、実は足元がどんどん重くなります。
基本は「最新mainから、1テーマ1branch」
では、AIでサイト開発する人はどう進めればいいのか。
基本はこれです。
最新mainから、1テーマ1branch。
もう少し分かりやすく言うと、
最新の正本から、1つの作業机を作り、1つのテーマだけ直す。
これだけです。
たとえば、
- ブログ幅を直すなら、それだけ
- 特典ページを作るなら、それだけ
- ホーム導線を直すなら、それだけ
- 料金ページを直すなら、それだけ
この単位を守るだけで、かなり安全になります。
逆に、1つの作業机で何でもやろうとすると、どんどん危なくなります。
「ついでにここも」 「ついでにこの文言も」 「ついでにこの記事も」
このついでが積み重なると、PRが重くなります。
PRが重くなると、レビューが重くなります。
レビューが重くなると、本番反映が遅くなります。
そして、遅くなるほど、他の作業とぶつかりやすくなります。
作業が終わったら、机を片付ける
AI開発で大事なのは、作業することだけではありません。
作業が終わった後に、机を片付けることです。
たとえば、
- PRを作る
- 本番反映されたか確認する
- 使い終わったbranchやworktreeを整理する
- 残っているdirtyを確認する
- 必要なものはアーカイブする
- 次の作業は最新mainから始める
この流れです。
ここをやらないと、ローカルには古い作業場が溜まっていきます。
古い作業場が残ること自体が悪いわけではありません。
問題は、それが「今も必要な作業」なのか「ただの残骸」なのか分からなくなることです。
だから、使い終わったら片付ける。
迷うものは、消す前にpatchやstatusを保存してアーカイブする。
その上で、作業場は軽くしておく。
この習慣があるだけで、AI開発の安心感はかなり変わります。
GitHubを使う理由は、戻れるから
GitHubを使う理由は、エンジニアっぽいからではありません。
戻れるからです。
やり直せるからです。
誰が何を変えたか追えるからです。
AIに作業を任せるほど、この「戻れる」は重要になります。
AIは速いです。
だから、良い方向にも速く進みます。
でも、間違った方向にも速く進みます。
その時に、戻る場所があるかどうか。
これが、AI開発を安心して進められるかどうかを分けます。
小さな確認ワーク
今AIでサイト開発をしているなら、次の5つだけ確認してみてください。
1つ目。
いま触っている作業場は、最新のmainから始まっていますか。
2つ目。
その作業場には、1つのテーマだけが入っていますか。
3つ目。
git status を見た時に、何の変更か説明できますか。
4つ目。
本番に出す前に、PRとして変更内容を確認できますか。
5つ目。
いらない変更を消す前に、必要ならpatchやstatusを残せますか。
この5つが分からない場合、コードを書く力より先に、作業場の整理を覚えた方がいいです。
自分のサイトを育てるなら、作業場も育てる
AIでサイトを作る時、多くの人は「どう指示すればAIが良いコードを書いてくれるか」を考えます。
もちろん、それも大事です。
でも、本当に長く運用するなら、もっと大事なことがあります。
AIが安全に働ける作業場を用意すること。
これは、プロンプトの話ではありません。
GitHub。
main。
branch。
commit。
PR。
archive。
こういう仕組みを、専門用語としてではなく、自分の仕事を守るための道具として理解することです。
AIは、作業を速くしてくれます。
でも、速くなった分だけ、作業場が散らかるスピードも上がります。
だからこそ、バイブコーディングで最初に覚えるべきなのは、コードの書き方ではなく、作業場の戻し方です。
自分のサイトが今どの状態なのか。
何が本番に出ているのか。
何が途中なのか。
どこまでなら戻せるのか。
ここを見えるようにすることが、AI時代のサイト開発の土台になります。
関連して読んでおきたい記事
AIでサイトを作っていると、「作れるようになった」こと自体が楽しくなります。
でも、本当に大事なのは、作ったものを壊さず育てられることです。
もし今、自分のサイトやAI開発環境の中で、何が本番で、何が途中で、何を消していいのか分からなくなっているなら、一度、作業場の整理から見直した方が早いかもしれません。