Random Circuits
Experiment log

Claudeで作った予約システムを自社サイトで本番運用するまでに必要だったこと

AI LAB / AI実験 BUILD / Web制作
2026.09.12 / random_admin

ClaudeやChatGPTなどの生成AIを使えば、以前なら専門のエンジニアに依頼しなければ難しかったWebシステムも、かなり簡単に形にできるようになりました。

「こんな予約システムを作りたい」と伝えれば、画面を作り、データベースを設計し、ログイン機能まで実装してくれる。

実際に動いている画面を見ると、

「これなら、そのまま会社のサイトで使えるのでは？」

と思ってしまいます。

ただ、実際の業務で使うWebシステムを確認していると、ここにはかなり大きな壁があります。

「動くシステム」と「本番環境で運用できるシステム」は同じではありません。

今回は、AIで作成した予約システムを実際のWebサイトで運用するとしたら、どんな部分を確認する必要があるのかを整理してみます。

AIでシステムを作ること自体はかなり簡単になった

少し前まで、Web上で動く予約システムを作るには、

など、さまざまな知識が必要でした。

現在はClaudeなどの生成AIに仕様を伝えながら開発すれば、これらをかなりのところまで作ることができます。

画面を確認しながら、

「ここに予約変更ボタンを付けて」

「管理者には一覧画面を表示して」

「登録されたら確認メールを送って」

といった形で修正を繰り返すこともできます。

個人でWeb制作をしている立場から見ても、この進化はかなり大きいと感じます。

一方で、AIが生成したコードを実際の業務で利用する場合には、別の視点が必要になります。

最初に確認するのは「どこで動くシステムなのか」

まず確認したいのがサーバー環境です。

AIにWebシステムを作ってもらった場合、最初はVercelやSupabaseなどのクラウドサービスを前提に作られていることがあります。

しかし、実際の会社のWebサイトは、

などで運用していることも多いでしょう。

ここで問題になるのが、システムの構成です。

例えばNode.jsで作られたシステムを、そのまま一般的なPHP中心のレンタルサーバーへ持っていけるとは限りません。

その場合は、

現在のサーバーで動かせる構成へ変更する

必要があります。

PHPへ作り直すのか、Node.jsが利用できるサーバーへ移動するのか、クラウド側をそのまま使うのか。

コードを見る前に、まずこの全体構成を確認する必要があります。

データベースをどこに置くのか

予約システムであれば、当然ながら予約情報を保存します。

氏名、メールアドレス、予約日時、場合によっては住所や電話番号などを扱うかもしれません。

そのデータが、

のどこに保存されているのかも重要です。

AIで作ったシステムでは、知らないうちに外部サービスへ依存しているケースがあります。

開発中は問題ありません。

しかし実際に運用するなら、

「この外部サービスを解約したらシステムは動くのか」

「無料プランの上限を超えたらどうなるのか」

「データはどこに保存されているのか」

まで確認しておく必要があります。

見た目だけでは分からない部分です。

メールが送れるだけでは不十分

予約システムではメールも重要です。

例えば、

などがあります。

開発環境からメールが1通届いたからといって、それだけで「メール機能は完成」とは言えません。

実際には、

なども確認する必要があります。

特に注意したいのが、メール送信に失敗しているのにシステム側では成功扱いになってしまうケースです。

ユーザー側には確認メールが届いていない。

しかし画面上では、

「メールを送信しました」

と表示される。

これでは実運用時に問い合わせが発生します。

単純にメール送信処理を書くだけでなく、

本当に送信できたのかをシステム側で判断できる仕組み

も重要になります。

メール確認前にログインできないか

ユーザー登録機能がある場合、メールアドレス認証も確認します。

理想的には、

  1. ユーザー登録
  2. 確認メール送信
  3. メール内のURLをクリック
  4. メールアドレス確認完了
  5. ログイン可能

という流れになります。

ところが、システムによっては登録した瞬間からログインできてしまう場合があります。

つまり確認メールをクリックしていなくても、そのアカウントが有効になっている状態です。

テスト段階では見逃しやすい部分です。

画面上では問題なく動くためです。

しかし本番運用では、

「メールアドレスの所有者確認を何のために行っているのか」

というところまで考える必要があります。

管理画面の認証は十分か

予約システムなら管理者が予約一覧を確認する画面もあるでしょう。

この管理画面についても注意が必要です。

例えば単純なURLだけで管理画面へアクセスできたり、簡単なパスワードだけで保護されていたりすると、業務システムとしては不安があります。

最低限、

などを確認したいところです。

管理画面には一般ユーザーより重要な情報が集まります。

そのため、フロント側よりむしろ管理側を重点的に確認する必要があります。

CSRF対策が入っているか

Webシステムを確認するときにチェックしたいもののひとつがCSRF対策です。

CSRFは、ユーザーが意図しない操作を外部サイトなどから実行させられてしまう攻撃です。

予約の登録、変更、削除、会員情報変更など、データを書き換える処理では対策が必要です。

一般的にはCSRFトークンを利用して、

「この操作が正規の画面から送信されたものか」

を確認します。

生成AIは指示された機能を作ることには非常に強いのですが、こちらから指定していないセキュリティ対策については、実装が十分ではない場合があります。

そのため、

機能が動くかどうかとは別に、セキュリティの観点からコードを見る必要があります。

回数制限も意外と重要

ログインやメール送信などには回数制限も必要です。

例えば、

「パスワードを忘れた」

という機能があったとします。

このボタンを何百回でも押せる状態だと、大量のメールを送信できてしまいます。

ログイン画面も同じです。

パスワードを何万回でも試せる状態なら、ブルートフォース攻撃を受ける可能性があります。

そこで、

などを制限します。

通常の動作確認だけでは見えにくい部分ですが、本番運用では重要です。

APIキーやパスワードをコードに直接書かない

AIにコードを書いてもらいながら開発していると、設定を簡単にするため、

APIキーやデータベースのパスワードなどを直接コードへ記述してしまうことがあります。

開発中だけなら便利です。

しかし本番環境では、

などの扱いには注意が必要です。

設定ファイルをWebから直接閲覧できない場所へ置いたり、環境変数として管理したりする方法があります。

また、GitHubなどへコードを公開する場合は特に注意が必要です。

コードそのものだけではなく、

コードと一緒に何を公開しているのか

まで確認します。

Cookieや個人情報の扱いも考える

予約システムでは、多くの場合個人情報を扱います。

さらにログイン機能がある場合はCookieを使用することもあります。

そのためシステムだけではなく、

なども検討する必要があります。

ここまで来ると、もはや「プログラムが動くかどうか」だけの話ではありません。

実際のサービスとしてどう運用するか

という話になります。

決済を使うならWebhookにも注意

予約時にStripeなどのオンライン決済を利用する場合は、さらに確認項目が増えます。

例えばWebhookです。

決済サービスでは、

「支払いが完了した」

「定期購入が開始された」

といった情報をWebhookでWebサイトへ通知します。

ここで同じ通知が複数回届く可能性も考えなければなりません。

同じWebhookを2回処理してしまうと、

といったトラブルが起こる可能性があります。

そのため、

一度処理した通知を再度処理しない仕組み

も必要になります。

バックアップと復旧方法を決めておく

システムが完成すると、つい公開することばかり考えてしまいます。

しかし本番公開前に必ず考えたいのが、

壊れた場合にどう戻すか

です。

例えば、

などのバックアップが必要です。

さらに、

「バックアップがある」

だけでは十分ではありません。

そのバックアップから実際に復旧できるかも重要です。

WordPressでもよくありますが、バックアップファイルを持っていても復元手順が分からなければ、トラブル発生時に困ります。

本番公開前には「正常系以外」も試す

開発時には、

「予約できた」

「ログインできた」

「メールが届いた」

という正常な操作を中心に確認します。

本番前にはその逆もテストします。

例えば、

などです。

業務システムでは、正常に動いたときよりも、

失敗したときにどう動くか

の方が重要なことがあります。

AIがコードを書けることと、本番運用できることは別

ClaudeやChatGPTでWebシステムを作れるようになったことは、Web制作にとってかなり大きな変化だと思います。

以前なら開発会社へ依頼しなければ難しかった仕組みを、小規模な会社や個人でも作れるようになりました。

これは非常に面白い変化です。

ただし、

AIがコードを書いてくれることと、そのシステムを安全に業務で使えることは別です。

AIで作ったシステムが画面上で問題なく動いていたとしても、

など、本番運用では確認することがたくさんあります。

AIによって「作るハードル」は確実に下がりました。

これから重要になるのは、

AIが作ったものを確認し、実際に使える状態へ仕上げる力

なのかもしれません。

個人的にも、最近はWeb制作の仕事の中でこの部分が増えてきたように感じています。

AIにすべて任せるのではなく、

AIに作ってもらい、人間が運用できる形に整える。

これが、これからの小規模なWebシステム開発ではひとつの現実的な形になっていきそうです。