はじめに

Supabase CLI が強力であるからこそ、ちょっとしたコマンドの打ち間違いで大きなダメージを受ける可能性もあります。

以下の記事にコメントがつき、ヒューマンエラーについてはどう対応したらいいのかという質問を受けました。

そこで回答した内容を他の方にも共有した方がためになると思いましたので、ここではそのリスクを最小化するための対策を中心にお話しします。
コメントした内容に加えていくつか追記していますので、ぜひ最後までご覧ください。

本記事の目的

Supabase CLI や Next.js での開発における、ヒューマンエラー（誤操作）を防止する方法を整理し、共有する。
実際の運用事例やシェルスクリプト、CI/CDの設定など、なるべく具体的な例を取り入れる。

対象読者（Next.js × Supabaseの開発者向け）

Supabase を活用して本番環境運用をしている / これから検討している開発者
Next.js × Vercel × Supabase × Prisma など近しい技術スタックで、環境管理や本番デプロイにおける安全性を向上させたい方
ヒューマンエラー対策に興味がある方

環境管理におけるヒューマンエラーのリスク

誤操作の具体例

本番環境へのマイグレーションコマンドを誤ってローカルから実行
例： supabase db push を意図せず本番プロジェクトに対して発行してしまい、データを壊す・削除する。
本番のAPIキーやデータベースURLを消してしまう
例： .env を書き換えて push してしまい、チーム全体で混乱が生じる。
機密情報を間違えてコミットしてしまう
例： .env ファイルをうっかりGit管理下に含めたまま公開。

誤操作が起きやすいポイント（Supabase CLIの特性）

プロジェクト単位で CLI が管理される
Supabase CLI は config.toml の project_ref を元にどのプロジェクトを操作するか判断します。意図したものと違う config.toml を使うだけで、本番環境に対してコマンドが飛んでしまうこともあり得ます。
supabase db push や supabase functions deploy などの強力なコマンド
裏ではデータベースに対する変更やサーバーレス関数の上書きを行うため、誤った環境で実行した場合の影響が大きいです。

誤操作を防ぐためのベストプラクティス

1. コマンド実行前の対話的確認を実装

シェルスクリプトを使った対話的な確認（confirm処理）の例

ローカル環境でコマンドを打つ前に、「本当に本番に対して実行していいですか？」のような対話的なステップを挟むことで、ヒューマンエラーを大幅に減らせます。
以下は簡易的なbashスクリプトのサンプルです。

#!/bin/bash

# Supabase の config.toml などから現在のプロジェクトrefを取得
ENVIRONMENT=$(grep project_ref supabase/config.toml | cut -d '"' -f2)

echo "現在の環境: $ENVIRONMENT"

# 本番の project_ref を適宜設定
PROD_REF="your-prod-project-ref"

if [ "$ENVIRONMENT" = "$PROD_REF" ]; then
  read -p "本番環境( $ENVIRONMENT )への操作です。実行してよろしいですか？ (yes/no): " ANSWER
  if [ "$ANSWER" != "yes" ]; then
    echo "操作を中断しました。"
    exit 1
  fi
fi

# このスクリプトを「supabase db push」の代わりに使用するイメージ
supabase db push

ポイント

project_ref が本番用であれば「yes」と回答しない限り実行しない。
本番環境への操作に心理的ハードルを設けるため、“YES” と明示的にタイプするようにする方法もアリ。

独自スクリプトの具体的な作成例（bashスクリプト）

上記のような confirm スクリプトを複数のコマンドに対して用意し、package.json の scripts で紐付ける、もしくは ./scripts ディレクトリにまとめてチームメンバーへ共有すると運用しやすいです。

2. CI/CDパイプラインを利用したガード施策

CI/CD経由でのみ本番環境を操作可能にする

本番環境への変更がローカルから直接打てる状態にすると、どうしてもヒューマンエラーのリスクが残ります。
「本番環境はCI/CDパイプライン経由でのみ操作可能」 とすることで、次のようなメリットを得られます。

本番用の認証情報がローカルになくても良い → 誤操作できない
Pull Request (PR) や Merge Request (MR) のレビュー段階で問題を発見しやすい → “なんでこんなMigrationを本番でやろうとしてるの？” と気付ける

Supabaseの設定をGitHub Actionsで管理する方法

GitHub Secrets に本番用のAPIキーや project_ref を登録し、ワークフロー内でのみ参照する。
supabase db push や supabase functions deploy などのコマンドを、本番デプロイ用のjob として定義する。
デプロイ時にはステージング環境で先に実行して問題ないことを確認 → 本番環境デプロイ という段階的パイプラインを構築する。

手動承認フローを入れて安全性を担保する

GitHub Actions の “環境 (Environment)” 機能 で “Production” へのデプロイには手動承認を設定する。
CircleCI や GitLab CI/CD の “Manual Approval” step などを利用する。
→ 最終的な人間による承認がないと本番操作がされないため、人的チェックポイント を設けることができる。

3. バックアップ・リストア戦略の整備

Supabase Backup & Restoreの活用法

Supabaseには、自動バックアップ機能（Proプラン以上など）や手動でのバックアップダンプ取得機能があります。本番環境のデータ消失リスクを低減するために、バックアップ機能を必ず有効活用しましょう。

定期的なバックアップスクリプトの導入

Proプランなどを利用していない場合でも、定期的に pg_dump や supabase db dump を使ってバックアップを取得する運用をおすすめします。

cron や GitHub Actions のスケジュール機能で定期ジョブを組む
データを暗号化し、外部ストレージ（AWS S3など）に保管

バックアップのリストア演習の重要性

いざというときにリストア手順を把握していないと、復旧に時間がかかり大きなダウンタイムになる可能性があります。
ステージング環境にバックアップをリストアしてみる演習をすると、実運用でも安心。

追加のガード施策

4. 権限の最小化（Least Privilege）

Supabaseダッシュボードにおける権限管理

Supabaseプロジェクトのダッシュボードから、チームメンバーに付与する権限を最小限にする。
例：
- 開発担当 → 開発環境のみフルアクセス
- 運用担当 → 本番環境のアクセス権
- 観察者（リードなど） → Read Only

開発環境での本番用キーを削除する

誤操作を防ぐために、本番の SUPABASE_ANON_KEY や SERVICE_KEY はローカル .env に置かない。
実機能テストが必要な場合でも、基本はステージングや開発用キーで行う。

Supabaseのロール管理（RLS）を利用した権限制御

Row Level Security (RLS) を使うと、アプリケーション側でさらに細かいデータアクセス制御が可能。
RLS を誤操作防止にも活用し、特定テーブルに対して誤った CRUD をできないようにする。

5. 環境変数の物理的な分離管理

`.env` ファイルを環境ごとに完全に分割する

例：
- .env.development
- .env.staging
- .env.production
“本番キーが入り込まないようにする” ために物理的にファイルを分け、Git管理には含めないようにする（.gitignore設定）。

dotenvなどを利用した環境ごとの設定読み込みの工夫

npm scripts で cp .env.production .env のようにコマンド実行前に切り替える。
あるいは cross-env NODE_ENV=production ... などを使い分ける。
「本番用ファイルをローカルにコピーする」フロー自体を作らず、CI/CD上でのみ .env.production を読み込むようにする方法も有効。

6. ロギングとアラートシステムの導入

誤操作検知のためのアラート設定（Slack通知）

データベースや Supabase Functions の変更時にSlack通知を送ると、万が一の誤操作をリアルタイムで検知できる。
GitHub Actions のジョブ通知、あるいはSupabase側のWebhooksなどを利用すると便利。

ログ監査（Audit Logs）による早期発見と対応の仕組み

Supabase でもダッシュボード上からAudit Logsを確認可能。誰がいつどんな操作をしたか、履歴を追えるようにする。
これらのログを定期的にモニタリングしたり、Slack や Datadog に集約することで、怪しい操作の早期発見が可能になる。

7. 作業環境の明示的な視覚化

CLIツールで環境名を色付きで表示

ターミナルのプロンプトや CLI スクリプトで、開発/本番で色を変えるようにしておく。
例：PS1 などで $ENVIRONMENT が production の時は赤文字で表示

VSCodeのステータスバーに環境名を表示する

VSCode の拡張機能や .env を読み込むプラグインなどを使って、エディタ上でも現在の作業環境を一目で把握できるようにする。

実践的な運用例（筆者が採用している方法）

実際の運用フロー

本番環境のキー情報はローカルに置かない
すべて CI/CD (GitHub Actions) の Secrets に格納し、ローカルからは操作不可にしている。
ステージング環境を用意し、デプロイフローも本番と同等に
ステージングでマイグレーション・動作検証を行い、OK であれば本番に手動承認付きでデプロイ。
バックアップは週1で自動取得
GitHub Actions の Scheduled workflow を使い、supabase db dump の成果物を暗号化のうえ S3 に保管。
VSCode で環境名をステータスバー表示
ENV=development と ENV=production で色を変えて警告が出るようにしている。

チーム内のルールや規約

「本番操作は必ず Pull Request (MR) 経由」 を徹底。
「誤操作が起きたら即共有」し、再発防止策を検討 → 失敗事例を隠さない文化づくり。

まとめ

各施策のポイントの再整理

対話的確認スクリプト
- コマンド実行前のワンクッションで誤操作を大幅に削減。
CI/CDパイプライン活用
- 本番環境への直接コマンドを原則禁止。手動承認を挟むことでさらに安全性UP。
バックアップ・リストアの定期運用
- 誤操作はゼロにできない前提で、すぐ復旧できる仕組みが大切。
権限の最小化（Least Privilege）
- Supabase ダッシュボードや RLS で可能な限り権限を絞る。
環境変数の分離管理
- .env.production と .env.development を別物として、誤操作できないようにする。
ロギング・アラート
- Slack通知やAudit Logsで不審な操作を早期キャッチ。
視覚的に環境を区別
- CLI・エディタで環境名をカラーやバナーで明示。

誤操作リスクを意識した開発文化の醸成の重要性

ヒューマンエラーは「人間がいる以上、必ず起こりうる」もの。
ツール的対策だけでなく、「誤操作を報告しやすい雰囲気」「小さなミスでも周知・再発防止策を考える」 など、チームの文化として根付かせることも大切。

参考資料