連載の現在地:Phase 1「公開」(4 / 4本目) — まずは小さく安全に世に出す
1. 公開 → 2. 費用と安定 → 3. 安全 → 4. 品質 → 5. 自動化

こんな悩みの人へ

Claude CodeやCursorで、動くアプリが一晩でできてしまった。でも、このまま本番に出して大丈夫なのか、自分では判断できない。試しに直すたびに、本番のデータや設定まで変わってしまいそうで怖い。そんな方に向けた記事です。

結論

まず、開発用と本番用の環境を分けます。 そのうえで、公開前のチェックリストを人が確認します。 この2つは、どこで動かすかに関係なく必要です。

動かす場所は、作ったものの形で選びます。TypeScript(JavaScript)で、APIを呼んで結果を返す形なら、Cloudflare Workersが向いています。設定ファイルだけで環境を分けられるからです。Pythonや、コンテナで動かす前提のコードであれば、Cloud Runなどのコンテナのほうが楽です。

なぜAIで作ったものは、本番が不安なのか

AIで作ったものを本番に出すのが不安になるのには、理由があります。

AIが書いたコードは動きます。ただ、「入力が空だったら」「APIが失敗したら」といった前提がどこまで考えられているかは、見ただけでは分かりにくいものです。

開発と本番が混ざりやすいのも問題です。同じAPIキーや同じデータベースを使っていると、試しに動かしたつもりで、本番のデータを書き換えてしまいます。

さらに、変更が速すぎて確認が追いつきません。AIに頼むと、一度に多くのファイルが変わります。どこを変えたのかを人が把握しないまま、公開してしまいがちです。

解決策の比較

方法

費用

手間

向いている状況

Cloudflare Workersの環境機能

無料から

少ない

TypeScriptで書いたAPI中心のアプリ

Vercelなどのプレビュー環境

無料から

少ない

Next.jsなどで画面まで作ったアプリ

Cloud Runなどで、サービスを分ける

使った分だけ

中くらい

Pythonなど、コンテナで動かすアプリ

別のサーバーを手作業で用意する

サーバー代

多い

ほかに方法がない場合

どれを選ぶか

TypeScriptで書かれているなら、WorkersやVercelなどを比較します。その際は、利用しているNode.js API、ファイルシステム、ネイティブ拡張、フレームワークの対応状況を確認してください。package.json があるかどうかだけでは判断できません。requirements.txt や Dockerfile があるなら、Cloud Runなどのコンテナが向いています。

どちらか分からない場合は、AIに「このプロジェクトはどの実行環境を前提にしているか」を聞き、その答えを自分で確かめましょう。

手順(Workersの場合)

この手順で作る構成は、次のとおりです。AIツールが触れるのは開発用のキーと検証環境だけで、本番には決まった経路でしか出しません。

[手元のPC・AIツール] --開発用キーだけ--> [staging環境]  ← Accessで関係者だけ
         |                                (検証用D1・検証用APIキー)
         |
         +-- git push --> [GitHub Actions] --mainブランチのみ--> [production環境]
                                                    (本番用D1・本番用APIキー)

1. 設定ファイルで、開発用と本番用を分ける

wrangler.jsonc に、環境ごとの設定を書きます。データベースやKVも、環境ごとに別のものを指定します。

{
  "name": "my-ai-app",
  "main": "src/index.ts",
  "compatibility_date": "2026-11-03",
  "env": {
    "staging": {
      "name": "my-ai-app-staging",
      "d1_databases": [{ "binding": "DB", "database_name": "app-staging", "database_id": "作成した検証用D1のID" }]
    },
    "production": {
      "name": "my-ai-app",
      "d1_databases": [{ "binding": "DB", "database_name": "app-prod", "database_id": "作成した本番用D1のID" }]
    }
  }
}

D1を使う場合は、npx wrangler d1 create app-staging と npx wrangler d1 create app-prod で別々のデータベースを作成し、各コマンドが返したIDを該当する database_id に設定します。

2. シークレットも環境ごとに登録する

APIキーは、開発用と本番用で別のものを発行し、それぞれ登録します。

npx wrangler secret put OPENAI_API_KEY --env staging
npx wrangler secret put OPENAI_API_KEY --env production

デプロイ先も npx wrangler deploy --env staging と npx wrangler deploy --env production で明示します。環境ごとのバインディングとシークレットは、それぞれの環境に設定します。

3. 検証環境は、関係者だけが開けるようにする

検証用のURLは、Cloudflare Accessで守ります。独自ドメインに加えて、workers.dev やバージョンURLなど別の入口も保護するか、使わないものを無効にします。

4. 公開前チェックリストを、人が確認する

AIに任せず、次の項目は自分の目で確認します。

  • ☐ APIキーがコードやGitの履歴に入っていない
  • ☐ 入力の長さや回数に上限がある(長文を送られてAPI費用が膨らまない)
  • ☐ 外部APIが失敗したとき、エラーの中身をそのまま画面に出していない
  • ☐ ログに、個人情報やAPIキーが出力されていない
  • ☐ LLMの予算通知と停止条件を設定し、通知だけでは止まらない設定になっていないか確認した
  • ☐ AIが追加したパッケージを確認し、心当たりのないものがない

5. デプロイを、手元ではなく決まった手順で行う

GitHubのmainブランチに入ったら本番、それ以外は検証環境、のように決めます。GitHub Actionsから wrangler deploy --env production を実行すると、誰がいつ出したかが記録に残ります。

更新日:2026-11-03

つまずきやすい点

まず、AIツールに本番のキーを渡さないことです。開発中のAIツールが読めるのは、開発用のキーだけにします。データベースの変更も、本番で先に試してはいけません。テーブルの追加や変更(マイグレーション)は、検証環境で動かしてから本番に適用します。

「動いた」で終わらせないことも大切です。正常な入力だけでなく、空の入力、長すぎる入力、APIの失敗も試します。

そして、元に戻す方法を決めておきます。Workersのコードは以前のバージョンへロールバックできますが、D1や外部APIで変更したデータまでは戻りません。コードとデータベースの互換性、バックアップ、復旧手順を用意しておきましょう。

この記事のまとめ：Claude Codeなどで作ったものを本番に載せたい。悩み：動いたが公開は不安、本番データを守りたい、問題が出たら戻したい。解決の流れ：開発環境→検証環境→本番環境。進め方：環境を分ける→検証環境を守る→人が公開前に確認→決まった手順で公開。つまずきやすい点：本番キーをAIに渡さない、正常系だけで終えない、データは別に復旧設計この記事のまとめ：Claude Codeなどで作ったものを本番に載せたい。悩み：動いたが公開は不安、本番データを守りたい、問題が出たら戻したい。解決の流れ：開発環境→検証環境→本番環境。進め方：環境を分ける→検証環境を守る→人が公開前に確認→決まった手順で公開。つまずきやすい点：本番キーをAIに渡さない、正常系だけで終えない、データは別に復旧設計

次に出やすい悩み

本番に出す準備が整うと、次は「キーが漏れたら」「答えの品質は大丈夫か」といった、運用を始めてからの不安が出てきます。公開前チェックの「APIキー」の項目をもっと確実にしたいなら、Phase 3の「APIキーの漏えいが怖い」を、検証環境を関係者だけが開ける状態にするなら「デモを社内や特定の人だけに見せたい」を参考にしてください。「動いた」の次に答えの品質を確かめたくなったら、Phase 4の「AIの回答が不安定で、品質をどう測ればいいか分からない」が役に立ちます。

Phase 1「公開」は、この記事で一区切りです。使われ始めたら、Phase 2で費用と稼働を守ります。最初の1本は「LLM APIの請求額が読めない」です。

「AIで作ったコードが、そのまま本番に出せる状態か見てほしい」という段階でも構いません。公開前の構成・セキュリティ確認はCloudflareインフラ構築をご覧ください。

よくある質問

Q. AIが作ったコードが手元で動けば、そのまま本番へ公開できますか？

公開前に、人が認証・認可、入力の検証、秘密情報の扱い、エラー時の動作を確認します。正常な入力だけでなく、空入力、長文、APIの失敗も検証環境で試してください。業務で扱うデータと利用者の条件に合わせて、公開の可否を判断します。

Q. 開発環境と本番環境は、何を分ければよいですか？

少なくともシークレット、データベースなどの接続先、設定、アクセス権を分けます。本文のWorkersの例では、環境ごとに設定とシークレットを登録します。AIツールが触れる範囲も開発用に限定し、本番のキーやデータを使って試さない構成にします。

Q. 検証環境を、関係者だけに使ってもらうには？

Cloudflare Accessなどでログインと許可ルールを設定し、認めた人だけが開けるようにします。独自ドメイン以外のURLやAPIにも迂回できる入口が残っていないか確認してください。許可した人で開けることと、許可していない人が拒否されることの両方を試します。

Q. Workersをロールバックすれば、変更したデータも戻りますか？

コードのロールバックでは、D1や外部APIで変更したデータまで自動で元には戻りません。以前のコードが新しいデータ構造で動くかを確認し、バックアップや復旧の手順も別に用意します。ロールバックの対象と制限を確認してください。

執筆者情報

パブロフ株式会社

IT顧問、AI・業務アプリ開発、SESを通じて、企業のIT活用を支援しています。代表の藤澤 昌隆は、2007年からシステム開発・運用に携わり、アクセンチュアでの業務ITコンサルティングを経て、2019年にパブロフ株式会社を設立しました。

AI活用の支援事例として、営業工程を支える7つの業務別AIアプリの構築を公開しています。アプリの開発に加え、入力・出力の形式、評価基準、テストケースの整備にも取り組んでいます。

記事の内容に関するご質問や誤りのご指摘は、お問い合わせ窓口へお寄せください。

参考資料