Claude Code で作ったアプリが、手元で一通り動くようになった。次は公開、という所で一度止まって確かめておきたいことがあります。
ログインや権限の確認のように、どの道具で作っても必要なことは「AIで作ったアプリの公開前チェック」に書きました。ここで扱うのは、Claude Code に入っている点検の機能と設定です。コマンドや画面は、2026年11月時点の公式ドキュメントに合わせています。
/security-review で変更を点検させる
Claude Code には、セキュリティの点検をするコマンドが最初から入っています。入力欄で /security-review と打つだけです。
公式の説明では、今のブランチと、リモート（origin）の既定のブランチとの差分を読みます。そのうえで、インジェクション（外から入れた文字で命令を書き換える攻撃）や認証の問題、データの露出といった危険を探します。差分を比べる仕組みなので、GitHub などにリポジトリがあり、origin が設定されている必要があります。
気をつけたいのは、見るのが差分だけだという点です。最初から main ブランチで作業して push まで済ませていると、比べる相手との差がなくなり、点検するものが残っていないことがあります。その場合は、「このリポジトリ全体を、同じ観点で見てほしい」と普通の言葉で頼んでください。
指摘が出たら、全部をそのまま直させる前に、一つずつ「なぜ危ないのか」「実際にどういう手順で悪用されるのか」を聞き返します。誤検知もありますし、指摘は正しくても今回の公開では問題にならないものもあります。直すかどうかを決めるのは、作った本人です。
GitHub のプルリクエストを使っているなら、同じ点検を自動にもできます。Anthropic が公開している GitHub Action（anthropics/claude-code-security-review）を入れると、プルリクエストのたびに点検が走ります。こちらは API キーが必要で、README には信頼できるプルリクエストだけに使うよう書かれています。一人で作っているうちは、手で /security-review を打つほうが手軽です。
ページと API ごとに「誰が開けるか」を書き出させる
/security-review は、差分の中にある危ない書き方を探すのは得意です。一方で、このアプリでは誰が何を見られるべきか、という決まりは知りません。そこは作った本人が決めることなので、Claude Code に一覧を作らせて、自分の考えと合っているかを照らし合わせます。
頼み方の例です。
このアプリのページと API を全部書き出して、表にしてください。
列は「パス」「ログインが必要か」「誰のデータを返すか」「どこで判定しているか（画面側 / サーバー / データベース）」です。
判定が画面側にしかないものには印を付けてください。見るのは最後の列です。画面側だけで判定しているもの、たとえばボタンを隠しているだけの管理画面は、URL を直接開けば通ってしまいます。表ができたら、テスト用のアカウントを2つ用意し、ログアウトした状態も含めて、印の付いたページを実際に開いてみます。Supabase を使っているなら、データベースの側の確認も要ります。手順は「Supabase の RLS が効いているか確認する方法」に書きました。
.env を Claude Code に読ませない
.env には、決済や AI の API の秘密の鍵が入っていることが多いです。Claude Code は作業の途中で必要なファイルを読みに行くので、何も設定していなければ .env の中身を読むこともあります。会話に鍵が一度出てしまうと、画面の共有やスクリーンショットから外に漏れる道が増えます。
公式の例にならって、プロジェクトの .claude/settings.json に次のように書くと、Claude Code は .env と .env.local などを読めなくなります。
{
"permissions": {
"deny": ["Read(./.env)", "Read(./.env.*)"]
}
}.claude/settings.json はリポジトリに入れて共有する前提の設定です。自分だけに効かせたいときは .claude/settings.local.json、すべてのプロジェクトに効かせたいときは ~/.claude/settings.json に書きます。
ただ、この設定には抜け道があります。公式のドキュメントによると、cat .env のようなコマンドには効きますが、Claude が書いた Python や Node のスクリプトが自分でファイルを開く場合までは止められません。コマンドの中まで OS の側で止めたいときは、サンドボックスを使うよう勧めています。サンドボックスは最初はオフで、/sandbox で有効にします。
いちばん確実なのは、本番の秘密の鍵を手元の .env に置かないことです。手元ではテスト用の鍵か、利用額の上限を低くした開発用の鍵を使い、本番の鍵は公開先の環境変数にだけ置く。こうしておけば、手元の .env が読まれても大きな被害にはなりません。
確認を飛ばすモードは、公開前の作業で使わない
Claude Code には、操作をどこまで任せるかを決める権限のモードがあります。ターミナルや VS Code で対話しながら使う新しいセッションは、2026年11月時点では Auto モードで始まり、操作が危なくないかを別のモデルが審査します。
確認を一切しないモードもあります。--dangerously-skip-permissions を付けて起動する方法です。公式のドキュメントは、このモードをインターネットにつながらないコンテナや仮想マシンのような、隔離された環境でだけ使うよう書いています。プロンプトインジェクション（読み込んだ文書に仕込まれた指示で AI が操られる攻撃）も防げないとしています。本番のデータベースの鍵や公開の設定が手元にある状態では使わないでください。
公開の前に使いたいのは、むしろ plan モードのほうです。Shift+Tab で切り替えるか、頼みごとの先頭に /plan を付けると、Claude はファイルを変えずに、調べた結果と手順だけを出します。データベースの表を変える、公開先の設定を変える、といった戻しにくい作業は、まず plan モードで手順を出させ、読んで納得してから実行させると安心です。
巻き戻しで戻るもの、戻らないもの
Claude Code には、作業を巻き戻す機能があります。入力欄が空の状態で Esc を2回押すか、/rewind と打つと、コードと会話を前の時点に戻せます。
ただし、戻るのは Claude がファイル編集の機能で変えたファイルだけです。Bash のコマンドで変わったファイルは戻りません。公式のドキュメントも、バージョン管理の代わりではないと書いています。手元のファイルの記録なので、データベースの中身や公開先の状態のように、手元の外で起きた変化も戻らないと考えておくほうが安全です。
だから、公開の直前には Git で区切りを残しておきます。その前に、.env が Git の管理から外れているかを確かめます。次のコマンドで .env と表示されれば外れています。
git check-ignore .env何も表示されなかったら、.gitignore に .env を足してから進めます。外れていれば、区切りを残します。
git add -A
git commit -m "公開前の状態"
git tag before-launch公開したあとに Claude Code に修正を頼んで何かが壊れても、この時点には確実に戻れます。データベースのほうは、バックアップの取り方と戻し方を、公開前に一度だけ試しておきます。
最後は自分の手で触って確かめる所
ここまでの点検は、どれも Claude Code の目を借りています。Claude Code に限らず AI は、頼んだ人の考えに合わせた答えを返しやすいので、判断まで任せきりにしないほうがいい所が残ります。私なら、次の3か所は自分で画面を触って確かめます。
一つは、お金が動く所です。決済が済んだかどうかを、決済の画面から戻ってきたことだけで判断していないか。Stripe を使っているなら、Webhook（決済サービスからの通知）を受けて確定しているかを見ます。二つめは、消す操作です。退会やデータの削除が、本人以外にもできてしまわないか。三つめはメールで、パスワードの再設定のようなメールが、本番の環境で本当に届くかを試します。
どれも、動かしてみれば数分で分かることです。それでも判断のつかない所が残ったら、そこだけ経験のある人に見てもらうのが早いと思います。