Claude Codeでアプリ開発する手順【保存・認証・公開まで】

Claude Codeで開発するアプリと準備

今回の完成形は、自分のタスクを保存できるWebアプリ

作るのは、見積もり確認や資料作成などを登録し、「未着手・進行中・完了」に分けるアプリです。利用者ごとに自分のタスクだけを見られる設計にします。同僚との共同編集は今回の範囲外です。 スマホでもブラウザで使えます。アプリストアへ配布する手順ではありません。

自分のタスクを変更でき、再読み込み後も残り、別の利用者のタスクは読めない。ここまでを完成条件にします。データと依頼文は練習例です。顧客情報は使いません。自分用の個人開発にも同じ流れを使えます。 題材から考えたい人は最初の業務アプリの選び方を先に読んでください。

手順1：開発用フォルダとアカウントを用意する

Claude Codeの導入とログインは非エンジニア向けの使い方で済ませます。公式クイックスタートではネイティブインストールを推奨しています。Node.jsは今回、Next.jsを動かすために必要です。Claude Codeの導入条件と混同しないでください。

Next.jsは画面とサーバー側の処理をまとめて作る仕組みです。公式の必要条件はNode.js 20.9以上。対応するLTS版を導入し、文字でパソコンを操作するターミナルで次を実行します。Gitは変更履歴を残す道具として用意します。

node --version
git --version
npx create-next-app@latest work-tasks --typescript --tailwind --app --src-dir
cd work-tasks
claude

追加の選択肢は意味を確認して選び、設定を後でCLAUDE.mdに記録します。claude が始まる前はコマンド、始まった後はAIへの日本語の依頼を入力する場所です。作業場所が work-tasks か確認してください。 Claude、Supabase、GitHub、Vercelの利用には、それぞれ利用条件に合うアカウントを用意します。会社のパソコンでは導入と外部サービス利用のルールも確認します。

CLAUDE.mdに完成条件を書いて設計する

手順2：作る機能と確認方法を短い指示書にする

CLAUDE.mdは、プロジェクトの目的や約束をAIへ伝えるファイルです。公式のメモリ解説にあるように、会話に読み込まれる指示であり、操作を強制的に禁止する設定ではありません。 以下は本記事用の例です。

目的：仕事のタスクを、利用者ごとに保存・管理する練習用Webアプリ。
構成：Next.js App Router、TypeScript、Tailwind CSS、Supabase AuthとDB。
導入したバージョンはpackage.jsonを確認して記録する。
機能：メールとパスワードで登録・ログイン・ログアウト。
自分のタスクの追加、一覧、状態変更、削除、状態別の絞り込み。
状態はtodo / in_progress / done。画面では日本語で表示する。
完成条件：再読み込み後も保存され、他人のタスクを読み書きできない。
今回は作らない：部署共有、通知、決済、実データの取り込み。
確認：架空タスクと利用者A・Bで、件数・保存・アクセス権を照合する。
変更前に対象ファイルと理由を説明し、変更後に実施した確認を報告する。

「CLAUDE.mdに保存し、操作説明はREADMEに書いて」と依頼します。

計画を読んで、機能が広がっていないかを見る

悪い依頼は「仕事で使えるアプリを全部作って」です。よい依頼は「上の条件で、保存先・ログイン・画面をどうつなぐか説明して。まだ実装しないで」。Planモードではソースファイルを編集せず、調査と計画を進められます。切り替え後のモード表示を確認してください。 構成が合ったら編集可能なモードへ戻し、保存先、認証、画面の順に実装します。

計画が分からなければ、そのまま進めず、「ログインした人を、どの処理で確認する？」「入力はどこへ保存される？」と聞いてみてください。 画面は作れたのに中身が分からず仕事で使うのが怖いなら、この接続関係を学ぶ段階です。AIシフトコースの無料相談会で、今の理解と作りたい業務アプリから学ぶ順番を整理できます。

Supabaseで保存先とログインを作る

手順3：練習用の保存先とアクセス権を作る

Supabaseはデータベースとログイン機能を提供するサービスです。練習用のプロジェクトを作り、既存業務の保存先と分けます。管理画面のConnectでプロジェクトURLとpublishable keyを確認し、Next.js向け公式手順に沿って .env.local に設定します。環境変数は接続先などをコードと分ける設定です。

NEXT_PUBLIC_SUPABASE_URL=練習用プロジェクトのURL
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=練習用のpublishable key

右辺は自分の設定に置き換えます。管理者用のsecret keyやservice_roleキーを入れる場所ではありません。公式のキー解説でも、強い権限を持つキーをブラウザへ公開しないよう説明されています。AIへの依頼にはキーの値を貼らず、設定名と必要な作業を伝えます。

tasksテーブルを設計してください。
id: uuid、user_id: auth.usersを参照するuuid、title: 空白のみを禁止するtext。
description: 任意のtext、status: todo / in_progress / doneだけを許可。
created_at、updated_atを持ち、更新時にupdated_atも更新する。
RLSを有効にし、ログイン中の本人の行だけを読取・追加・更新・削除できるようにする。
追加・更新で他人のuser_idを指定しても通らないようにする。
必要なテーブル定義とポリシー、適用先と確認手順を先に提示してください。

RLSは、データベースの行ごとに読み書きを制限する仕組みです。Supabase公式では、追加時の条件を WITH CHECK、更新対象の条件を USING として説明しています。更新には読取のポリシーも必要です。 出てきた定義を理解できなければ、実データを入れる前に技術担当者へ確認します。適用する管理画面が練習用プロジェクトかを確かめてから進めてください。

登録とログインをつなぎ、保存の準備を確かめる

次は「公式のNext.js向け手順に沿って、メールとパスワードの登録、ログイン、ログアウトを実装して」と頼みます。@supabase/ssr を使う構成では、ブラウザ側とサーバー側のクライアントを用意します。サーバー側の本人確認は getClaims() など公式に沿った検証を使い、保存されたセッションを読むだけで本人と判断しないよう依頼してください。

メール確認が有効なら、確認後にログインします。届かない場合は送信設定・制限・戻り先URLを調べます。 未ログインで一覧URLを開くとログインへ戻り、ログアウト後にも一覧を読み出せないかを確かめます。画面の移動だけでなく、裏側のデータ取得にも制限が必要です。

タスク画面を作り、保存と権限を確かめる

手順4：タスクの追加・変更・削除を画面から動かす

ログインを確認したら、タスクを作成・表示・更新・削除する操作を実装します。この操作をCRUDと呼びます。まずボタン操作で完成させます。

自分のタスク一覧と追加フォームを実装してください。
件名は必須。未着手・進行中・完了で絞り込めるようにする。
状態変更はボタンで行い、削除は確認してから実行する。
Server Actionsで保存し、各処理で本人と入力値を検証する。
Supabaseへの操作にはその利用者のセッションを使い、管理者キーでRLSを迂回しない。
保存中は二重操作を防ぎ、失敗時は成功したように表示しない。
タスク未登録、絞り込み0件、読込失敗を別の文言で表示する。

Server Actionsは、画面からサーバー側の処理を呼ぶ仕組みです。Next.jsの公式ガイドが説明するように、画面のボタンを隠すだけでは保護になりません。変更を受け付ける処理でも本人と権限を確認します。 起動は別のターミナルで同じフォルダを開き、npm run dev。表示されたURLをブラウザで開きます。

手順5：件数、保存、利用者の分離を順に照合する

利用者Aで架空タスクを3件作り、未着手・進行中・完了を1件ずつにします。利用者Bでも別のタスクを2件作ります。表はその入力から決まる正解で、利用実績ではありません。操作は上から順に試します。

空欄の件名を送っても件数が増えず、保存に失敗したら理由が出ることも確認します。スマホ幅ではフォーム、絞り込み、削除の確認まで操作してください。 Bには別のブラウザかシークレットウィンドウでログインします。画面にAの行が出ないことに加え、AのタスクIDを指定してもBや未ログイン状態で取得・変更・削除できないテストをAIに作ってもらい、結果を読みます。

不具合は「Aで1件削除した。期待は2件、再読み込みすると3件に戻る」のように、入力・操作・期待・実際で伝えます。エラー文の秘密情報を除いて添え、原因と直す場所を説明してもらいます。修正後は同じ操作と、Bの件数が変わらないことを再確認します。 完了した工程ではGitに変更を記録しておくと、修正前のコードと比べられます。ただし、コードを戻しても削除したデータまで戻るわけではありません。

件数が合うようになったら、次は「他人のデータを触れない理由」を説明できるかが課題です。確認する場所が分からないまま公開するのを避けたい人は、AIシフトコースで保存・認証・権限をつなげて学べます。作ったアプリを題材に、どの理解を補うか相談してください。

Vercelへ公開し、業務で使う準備をする

手順6：公開先の設定をそろえて、同じ操作を試す

デプロイは、Webアプリをインターネット上で動かせる場所へ配置することです。「環境変数の名前だけを .env.example に整理し、秘密情報がGitに含まれていないか確認して、ビルドして」とClaude Codeに頼みます。ビルドは配信用のプログラムを作る処理で、npm run build を使います。成功しても権限テストの代わりにはなりません。

コードの保存先となるGitHubリポジトリを作り、Vercelで取り込みます。公開範囲を確認し、環境変数をVercel側にも設定します。Supabaseのログイン後の戻り先も公開URLに合わせて設定します。公式の環境説明ではPreviewとProductionを分けていますが、新規プロジェクトの最初のデプロイはProductionになります。最初から架空データだけにし、業務データを入れないでください。

Previewを使う段階でも、本番と同じデータベースを指定すれば本番データに接続します。環境名だけで分離できたと思わず、接続先を確認します。 公開URLでもログイン・タスク操作・保存・AとBの分離を確認してから共有します。会社の業務利用では、Hobbyが個人の非商用利用向けである点も含め、用途に合う契約を選びます。

業務利用へ進む前に、利用者と運用を決める

自由登録のまま業務に使わず、招待・利用者制限を設計し、会社の担当者と確認します。実データの保存先、削除時の復元、問い合わせ先も決めてから移行します。

READMEに起動方法、検証用データ、確認済みの操作と残った課題を書き、次は使う人に架空データで操作してもらいます。通知や部署共有は、別の完成条件として追加します。到達点は、保存とアクセス範囲を説明し、公開先でも結果を確認できることです。