Codex と Supabase を組み合わせてウェブアプリを作る方法
OpenAI Codex は、テキスト指示だけでコードを書き・テストし・コミットできる AI コーディングエージェントだ。一方、Supabase は PostgreSQL をベースにした認証・ストレージ・リアルタイム通信を提供するオープンソースのバックエンドプラットフォームで、2024 年後半から日本の個人開発者やスタートアップにも急速に広まっている。この 2 つを組み合わせると、データベーススキーマの設計から Row Level Security(RLS)の設定、TypeScript 型定義の生成まで、バックエンド実装の大半を Codex に任せられるようになる。本記事では、その具体的な手順と注意点を順を追って説明する。
Supabase は PostgreSQL を中心に認証・ストレージ・Edge Functions を束ねた BaaS(Backend as a Service)だ。そのドキュメントは整備されており、テーブル構造や RLS ポリシーの記述がパターン化されているため、Codex のような自然言語→コード変換が得意なエージェントとの相性がよい。Codex は Supabase CLI のコマンドを理解し、supabase migration new でマイグレーションファイルを作り、SQL を書き込むまでを一貫して行える。
実際に Codex に任せてみると、テーブル定義・外部キー制約・インデックスの追加といった反復作業は驚くほど速く終わる。しかしデータの権限設計(誰が何を読み書きできるか)は、ビジネスロジックの理解なしに Codex が正しいポリシーを推測することは難しい。RLS ポリシーだけは「このテーブルはログイン済みユーザーのみ自分のレコードを読める」のように要件を明示した指示書を用意すると、意図通りの SQL が生成される確率が上がる。
Codex との連携で最も効果が出やすいのは、Supabase の型定義を自動生成して TypeScript プロジェクトに組み込むステップだ。supabase gen types typescript コマンドで生成した型を参照しながら Codex がフロントエンドの fetch ロジックを書くと、型ミスマッチによるランタイムエラーが激減する。Codex が生成したコードのレビューポイントは「RLS をすり抜けていないか」と「Edge Functions のレスポンス形式がフロントエンドの期待値と合っているか」の 2 点に絞られるため、レビューコストも大幅に下がる。
目次 (11)
Supabase と Codex の組み合わせで何ができるか
Supabase はその設計思想として「PostgreSQL の機能をそのまま使う」ことを重視している。マイグレーションは SQL ファイルとして管理され、RLS ポリシーも生の PostgreSQL 構文で記述する。この「コードとしてのバックエンド」という特性が、Codex との相性を高めている。Codex はリポジトリ内のファイルを読み、変更し、コミットする能力を持つため、SQL ファイルや設定ファイルの管理をそのまま任せられるのだ。
具体的にどのタスクを Codex に委ねられるかを整理すると次のようになる。テーブル定義の作成とリファクタリング、外部キー制約・インデックスの追加、RLS ポリシーの実装、Supabase JavaScript クライアント(@supabase/supabase-js)を使った API 呼び出しロジックの実装、TypeScript 型定義の Supabase スキーマへの対応、そして Edge Functions の雛形生成だ。
これらの中でも、特にテーブル設計と RLS は「一度決まれば変更コストが高い」分野だ。Codex を使う最大のメリットは、設計の試行錯誤を素早く繰り返せる点にある。「この方針でテーブルを設計して SQL を生成してほしい」と指示すれば、数十秒でマイグレーションファイルが出来上がり、すぐに supabase db reset で動作確認できる。手で SQL を書く場合の数倍の速度でプロトタイプが進む。
Supabase 公式も AIによる開発補助ツールを積極的に整備しており、公式ドキュメント（https://supabase.com/docs）は構造化された形式で提供されているため、Codex がコンテキストとして取り込みやすい。また OpenAI Codex の公式情報はhttps://openai.com/ja-JP/codex/で確認できる。
Supabase プロジェクトを Codex に任せる前の準備
Codex に効果的な指示を出すためには、プロジェクトの構造と要件をあらかじめ整理しておく必要がある。Codex はリポジトリを読むが、何を作りたいかを自分で考えることはしない。「ユーザーが投稿した記事に対してコメントができる」という程度の要件でも、明文化されていないと Codex は推測で補うしかなくなる。
Step 1: Supabase プロジェクトをローカルに用意する
まず Supabase CLI をインストールし、supabase init でプロジェクトを初期化する。これにより supabase/ ディレクトリが作られ、migrations/ フォルダにマイグレーション SQL ファイルを蓄積していく構造になる。Supabase CLI の最新版は公式リポジトリ（https://github.com/supabase/cli）から取得できる。
初期化後のディレクトリ構造は以下のようになる。
project/
├── supabase/
│ ├── config.toml
│ ├── migrations/
│ │ └── 20260617000000_init.sql
│ └── seed.sql
└── src/
└── (フロントエンドコード)
ローカル開発環境では supabase start でローカルの PostgreSQL コンテナを起動し、supabase db reset でマイグレーションを一から適用し直すことができる。この「リセットして試す」サイクルが Codex と組み合わせると特に効果的だ。Codex がマイグレーションを生成し、ローカルで適用し、エラーがあれば Codex が修正する、というループを高速で回せる。
Step 2: AGENTS.md にデータベース構成を記述する
Codex は各リポジトリの AGENTS.md（または CLAUDE.md 等のエージェント指示ファイル）を読んで、プロジェクトの文脈を把握する。Supabase プロジェクトでは、このファイルにデータベース構成を記述しておくことで、Codex が毎回スキーマを推測する手間を省ける。
記述すべき情報の例を挙げると、使用中の Supabase バージョン、有効化している拡張機能（uuid-ossp、pgcrypto など）、テーブル命名規則（スネークケース）、タイムゾーンの扱い方（timestamptz の使用等）、そして RLS の基本方針（認証ユーザーに限定するか、公開読み取りを許可するかなど）がある。これらを AGENTS.md に 30〜50 行程度で書いておくと、Codex はそれを前提にして SQL を生成するようになる。
Step 3: Codex にマイグレーションファイルを作らせる
準備が整ったら、Codex に具体的な指示を出す。「users テーブルと posts テーブルを作成するマイグレーションを追加してほしい。users は Supabase の auth.users と紐づけ、posts は user_id, title, body, published_at カラムを持つ」という形の指示が効果的だ。
Codex はこの指示をもとに、supabase migration new create_users_and_posts コマンドを実行し、生成されたファイルに SQL を書き込み、supabase db reset で適用確認を行い、エラーがあれば修正するまでを自律的に行う。この一連のプロセスは、以前なら 20〜30 分かかっていた作業が 3〜5 分に短縮されることが多い。
Codex が得意とする Supabase 関連タスク
Codex を Supabase 開発に活用する際、特に効果が高いタスクがある。これらを理解しておくと、どこで Codex を使い、どこで自分が判断するかのバランスを取りやすくなる。
テーブル設計と RLS ポリシーの実装
テーブル設計はパターンが多く、一度経験者が設計方針を決めれば、実際の SQL 生成は反復作業だ。Codex にとって得意分野のひとつで、「1 対多のリレーションを張る」「カスケード削除を設定する」「インデックスを貼る」といった指示を自然言語で伝えるだけで、正確な SQL が生成される。
RLS ポリシーは少し難しい。Codex は標準的なパターン（「ログイン済みユーザーは自分のレコードのみ読み書きできる」）は素早く正しく実装できる。しかし「管理者ロールのユーザーは全レコードを読める」「特定の組織に属するユーザーのみ閲覧可能」のような複合条件は、要件の曖昧さが SQL の誤りに繋がりやすい。
この問題への対処法は、RLS ポリシーを 1 件ずつ個別に指示することだ。「まず認証ユーザーのみ SELECT を許可するポリシーを追加する。次に自分が作成したレコードのみ INSERT/UPDATE/DELETE を許可するポリシーを追加する」と分けて指示すると、Codex の出力精度が上がる。
Edge Functions の雛形作成
Supabase の Edge Functions は Deno ベースの TypeScript で書かれる。Codex は Deno の構文を理解しており、「ユーザー登録時にウェルカムメールを送る Edge Function を作ってほしい」と指示すれば、supabase/functions/welcome-email/index.ts を作成し、Supabase の @supabase/supabase-js クライアントを使った雛形コードを書いてくれる。
ただし外部 API（メール送信サービスなど）との連携部分は、APIキーの渡し方やエラーハンドリングをレビューする必要がある。Codex が生成したコードがどの環境変数を参照しているかを確認し、Supabase の Vault または環境変数設定に反映させることを忘れずに行おう。Edge Functions のデプロイ方法は Supabase 公式ドキュメント（https://supabase.com/docs/guides/functions）を参照するとよい。
TypeScript 型定義の生成と連携
Supabase CLI には supabase gen types typescript --local というコマンドがあり、現在のデータベーススキーマから TypeScript の型定義を自動生成できる。この型定義ファイルをプロジェクトの src/types/supabase.ts に保存しておくと、Codex がフロントエンドコードを書く際に参照できる。
Codex に「生成された型定義を使って posts テーブルから最新 10 件を取得する関数を書いてほしい」と指示すると、型安全なデータ取得コードが生成される。型定義が古くなったときも「スキーマが変わったので型定義を再生成して、影響を受けたファイルを更新してほしい」と Codex に頼める。型の更新と影響範囲の修正を人間が手作業でやると抜け漏れが発生しやすいが、Codex は静的解析的にファイルを検索して漏れなく対応する傾向がある。
Codex が苦手とする Supabase タスクと対処法
Codex が強力だからといって、すべてを任せてよいわけではない。苦手な領域を理解しておくことで、手戻りを防げる。
まず RLS の権限設計そのもの は Codex に決めさせてはいけない。どのロールがどのデータにアクセスできるべきかは、ビジネスロジックの判断だ。Codex は「与えられた要件を SQL に変換する」ことは得意だが、「セキュリティ要件を考える」ことは人間が行うべきだ。設計の穴があっても Codex は気づかない。
次に Supabase Realtime の設定 は、マルチテナント構成や大量のクライアント接続が絡む場合に設定が複雑になる。Codex は基本的なリアルタイム購読コードは書けるが、パフォーマンスチューニングや接続数の最適化は人間の判断が必要なケースが多い。
さらに ローカル環境固有のエラー対処 も苦手なことがある。Docker の起動問題や Supabase CLI のバージョン差異によるエラーは、環境情報を Codex に与えないと適切な修正を出せないことがある。supabase status の出力を Codex に貼り付けるなど、環境情報を明示すると診断精度が上がる。
また 既存の本番データが絡むマイグレーション では、Codex が提案する SQL をそのまま適用するのは危険だ。ゼロダウンタイムでのカラム追加・削除・型変更は、既存データへの影響を十分に確認した上で行う必要がある。Codex が生成したマイグレーションは、ローカルとステージング環境で動作確認してから本番に適用するという手順を厳守しよう。
まとめ
Codex と Supabase の組み合わせは、バックエンド実装の反復作業を大幅に高速化するポテンシャルを持つ。テーブル設計・マイグレーション・型定義生成・Edge Functions の雛形といったパターン化された作業は Codex に任せ、RLS の権限設計とセキュリティレビューは人間が担う、という役割分担が現時点では最も効果的だ。
Supabase は「SQL を書けるエンジニアには最高のツール」と言われてきたが、Codex と組み合わせることで「要件を言語化できる人なら素早くバックエンドを組み立てられるツール」へと変わりつつある。プロトタイピングの速度が上がれば、設計の試行錯誤が増え、最終的な品質が上がる。Codex を Supabase 開発のパートナーとして取り入れることを検討する価値は十分にある。
Codex の最新機能や料金体系については OpenAI 公式ページ（https://openai.com/ja-JP/codex/）で、Supabase の開発者向けリソースは公式ドキュメント（https://supabase.com/docs）で確認できる。
