AIと安全に開発する

AIを使うと、これまでより短時間で多くのコードを変更できるようになります。

その一方で、AIが間違ったファイルを変更したり、既存機能を壊したり、本番環境へ影響を与えたりする可能性もあります。

そのためAI開発では、「速く作る」だけでなく安全に変更するための流れを作ることが重要です。

現在の状態を確認
↓
変更内容を決める
↓
Branchを作る
↓
AIに実装させる
↓
差分を確認
↓
テスト
↓
Previewで確認
↓
問題なければ本番へ反映

このページでは、AIと安全に開発するために最低限覚えておきたい考え方を説明します。

AI開発で一番大切なのは「変更を確認できる状態」にすること

AIは短時間で多くのファイルを変更できます。

便利ですが、何が変わったのか分からないまま本番へ反映すると危険です。

AIがコード変更
↓
そのまま公開

ではなく

AIがコード変更
↓
変更内容を確認
↓
動作確認
↓
問題がなければ公開

作業前に現在の状態を確認する

AIへ作業を依頼する前に、まず現在の状態を確認します。

pwd
git status
git branch --show-current

これによって、

• 正しいプロジェクトにいるか
• 未Commitの変更があるか
• どのBranchで作業しているか

を確認できます。

AIにも最初に同じ確認をさせると安全です。

作業前に現在の状態を確認してください。

確認項目:
・現在のディレクトリ
・現在のGit Branch
・git status
・未Commit変更
・最近のCommit

まだコード変更はしないでください。

git statusとは？

git status は、現在どのファイルが変更されているかなど、Gitの状態を確認するためのコマンドです。

git status

AI開発では特に重要です。

作業前と作業後に確認することで、AIがどのファイルを変更したか把握しやすくなります。

作業前
git status

↓

AIが変更

↓

作業後
git status

git diffとは？

git diff は、変更前と変更後の違いを確認するためのコマンドです。

git diff

AIが「修正しました」と報告しても、実際に何が変わったかは差分で確認できます。

AIの説明
↓
git diffで実際の変更を確認
↓
内容が一致しているか確認

Branchとは？

Branchは、現在のコードから作業用の分岐を作る仕組みです。

main
│
├─ feature/contact-form
│
└─ feature/login

本番用のコードを直接変更せず、機能ごとに別のBranchで作業できます。

たとえばお問い合わせフォームを変更するなら、

main
↓
feature/contact-form
↓
AIが実装
↓
確認・テスト
↓
問題なければmainへ統合

なぜmainを直接変更しない？

main は、本番公開に使われる重要なBranchとして運用されることが多くあります。

そこで直接実験的な変更をすると、そのまま本番へ反映される可能性があります。

避けたい例

main
↓
AIが大量変更
↓
そのままPush
↓
本番へ反映
↓
不具合

作業用Branchを使うと、確認してから本番へ進めやすくなります。

AIへBranchを確認させる

コード変更前にGit Branchを確認してください。

mainの場合はまだ変更を始めないでください。

作業内容に合うfeature Branch名を提案してください。

このように最初からルールを指定できます。

Commitとは？

Commitは、コードの変更をGitの履歴として記録する操作です。

変更
↓
確認
↓
Commit
↓
変更履歴として保存

たとえば、

feat: add contact form

のように、その変更で何をしたのか分かるメッセージを付けます。

問題が起きたときも、どの変更から不具合が発生したか追いやすくなります。

大きすぎる変更を一度にしない

AIは「サイト全体を改善して」と言うと、多数のファイルを変更することがあります。

変更が大きくなるほど、不具合が出たときの原因調査が難しくなります。

大きな変更

デザイン
+
認証
+
Database
+
SEO
+
フォーム

を一度に変更

↓

原因が分かりにくい

なるべく小さな単位に分けます。

① フォームUI
↓
確認

② バリデーション
↓
確認

③ メール送信
↓
確認

Previewとは？

Previewは、本番公開する前に変更後のWebサイトやアプリを確認するための環境として使われます。

開発
↓
GitHubへPush
↓
Preview
↓
ブラウザで確認
↓
問題なければ本番

Vercelなどでは、BranchやPull RequestごとにPreview URLを作れる場合があります。

Vercelの基本を見る →

本番環境とは？

本番環境は、実際のユーザーが使っている環境です。

Local
自分のパソコン

↓

Preview
公開前の確認

↓

Production
実際のユーザーが利用

本番環境では、すでにユーザーやデータが存在している場合があります。

そのため、開発環境と同じ感覚で操作しないように注意します。

本番Databaseは特に注意する

Webアプリでは、Databaseへユーザー情報や注文、投稿などが保存されています。

本番Databaseへ誤った変更をすると、コードのように簡単に元へ戻せない場合があります。

開発用Databaseと本番Databaseを分ける

可能であれば、開発やテストで使うDatabaseと、本番ユーザーのデータを保存するDatabaseを分けます。

Development Database
テストデータ

Production Database
本番データ

開発中のテストで本番データを誤って削除するリスクを減らせます。

Neonの基本を見る →

バックアップとは？

バックアップは、問題が起きた場合に復旧するためにデータや状態を保存しておくことです。

特に重要な変更をする場合は、事前に復旧方法を確認します。

変更前

現在の状態を確認
↓
バックアップ
↓
変更
↓
確認
↓
問題があれば復旧

Gitはコードの履歴管理に便利ですが、Databaseの中身まで自動的に保存してくれるわけではありません。

秘密情報をコードへ書かない

APIキーやDatabase接続情報などをコードへ直接書き、そのままGitHubへPushすると外部へ漏れる危険があります。

• APIキー
• パスワード
• 秘密鍵
• Database URL
• Webhook Secret
• 外部サービスの認証情報

こうした情報は、環境変数などを使って管理します。

コード

API_KEY="秘密情報"

ではなく

環境変数
↓
コードから参照

.gitignoreを確認する

.env や .env.local のような秘密情報を含むファイルは、Gitで追跡しないよう設定します。

.env
.env.local

が .gitignore に含まれているか確認します。

AIにも秘密情報を不用意に渡さない

エラー調査のために設定ファイルをAIへ見せる場合でも、不要な秘密情報を貼り付けないようにします。

DATABASE_URL=postgresql://...

API_KEY=sk-...

などをそのまま共有する必要がない場合は、

DATABASE_URL=[REDACTED]
API_KEY=[REDACTED]

のように伏せて相談できます。

AIに作業範囲を明確に伝える

AIへ「直して」とだけ指示すると、必要以上に広い範囲を変更する場合があります。

そこで、変更範囲を指定します。

目的:
お問い合わせフォームのエラー修正

変更してよい範囲:
・フォーム関連ファイル
・送信API

変更しない:
・デザイン
・認証
・Database Schema
・他のページ

不要なリファクタリングは禁止。

まず原因調査だけしてください。

「やること」だけではなく、「やらないこと」も伝えるのがポイントです。

AIへいきなり修正させない

複雑な不具合では、まず原因を調査させます。

不具合を調査してください。

まだコードは変更しないでください。

報告してください:
・原因候補
・根拠
・影響範囲
・修正案
・変更予定ファイル
・リスク

調査
↓
人が確認
↓
実装
↓
確認

という段階を分けると、不要な変更を防ぎやすくなります。

テストとは？

テストは、変更した機能が期待どおり動くか確認する作業です。

• ボタンが動くか
• フォームが送信できるか
• エラー時に正しく表示されるか
• スマートフォンで崩れていないか
• 既存機能が壊れていないか

などを確認します。

自動テストだけでなく実際の画面も確認する

コード上のテストが成功しても、実際の画面で問題が起きる場合があります。

コードチェック
↓
テスト
↓
Build
↓
Preview
↓
実際の画面で確認

特にUI変更では、スマートフォンとPCの両方で確認しましょう。

lint・型チェック・buildとは？

プロジェクトによっては、本番公開前に複数のチェックを実行します。

Lint
コード上の問題を確認

Type Check
型の問題を確認

Build
本番用に正しく生成できるか確認

実際に使うコマンドはプロジェクトによって異なります。

分からない場合はAIへ、

このプロジェクトで
本番公開前に実行すべきチェックを調べてください。

package.jsonを確認し、
利用できるコマンドを説明してください。

まだ実行しないでください。

と確認させることもできます。

AIに「完了条件」を伝える

「完成したら教えて」だけでは、AIが何をもって完成と判断するか分かりません。

そこで完了条件を明確にします。

完成条件:

・指定した機能が動く
・既存機能を壊していない
・lintが通る
・型チェックが通る
・buildが成功
・変更ファイル一覧を報告
・git diffを確認
・秘密情報を追加していない

すべて確認後に完了報告してください。

これによって、「コードを書いた＝完了」になりにくくなります。

本番公開前のチェック

本番へ反映する前に、最低限次を確認します。

□ 正しいBranchか

□ git statusは想定どおりか

□ git diffを確認したか

□ 不要なファイル変更はないか

□ 秘密情報は入っていないか

□ テストは成功したか

□ Buildは成功したか

□ Previewで確認したか

□ スマホでも確認したか

□ 本番データへの影響はないか

□ 問題時に戻せるか

安全なAI開発の基本テンプレート

実際の開発では、次のテンプレートを使えます。

目的:
［実装・修正したい内容］

最初に確認:
・現在のディレクトリ
・Git Branch
・git status
・未Commit変更
・現在の実装

条件:
・既存機能を壊さない
・関係ないファイルを変更しない
・不要なリファクタリングをしない
・新しい依存関係を勝手に追加しない
・秘密情報を表示しない
・本番Databaseを変更しない

まず調査してください。

その後、
・原因 / 現状
・変更予定ファイル
・実装方針
・リスク
・確認方法

を報告してください。

まだ実装しないでください。

実装後の確認テンプレート

実装後に次を確認してください。

・git status
・変更ファイル一覧
・git diffの要約
・既存機能への影響
・秘密情報の混入
・利用可能なテスト
・lint
・型チェック
・build

失敗した項目がある場合は、
成功したとは報告しないでください。

最後に、
人間が確認するべき項目をまとめてください。

AI開発は「速さ」と「安全性」を両立する

AIを使えば、以前より速くコードを書けるようになります。

しかし、変更速度が上がるほど確認の重要性も高くなります。

速く作る
+
小さく変更する
+
差分を確認する
+
テストする
+
Previewで確認する
+
問題があれば戻せる

=

安全なAI開発

AIにすべてを任せるのではなく、AIの作業を人が確認できる仕組みを作ることが重要です。

開発入門の次へ

ここまでで、AI開発を始めるための基本となる4つを学びました。

AI開発とは？
↓
Webサイト・Webアプリの仕組み
↓
ターミナル・開発環境
↓
AIと安全に開発する

次は、これまで学んだ知識を使って実際に0からWebサービスを作って公開する実践編へ進みます。

Tutorialsを見る →