Claude CodeでWebアプリの画面ができたら、次は他の人にも使ってもらいたくなります。そのとき必要なのは、公開URLだけではありません。入力したデータをどこへ保存し、誰が操作でき、修正後に何を確認するかまで決める必要があります。
問い合わせの件名・内容・対応状況を記録する小さなアプリを題材に、作成から公開、修正後の確認までを考えます。AIへ渡す依頼に、保存先と確認方法を含めるのが出発点です。
完成形の参考として、管理画面付きサンプルをダウンロードできます。これは管理者自身がテストデータを登録するデモです。一般公開の問い合わせ受付フォームやメール通知は含みません。
この記事の内容
最初に、画面ではなく「できること」を決める
この題材では、次の4つができれば最初の版として確認できます。
- 管理者だけが画面とAPIを開ける。
- 件名と本文を登録できる。
- 未対応・対応済みを切り替えられる。
- アプリを再起動しても登録内容と状況が残る。
デザインの調整は、この流れが通った後に進めます。確認する基準を先に決めると、AIが機能を増やしすぎたり、見た目だけで完了と判断したりすることを防ぎやすくなります。
実在する問い合わせを扱う前には、利用者ごとの認証・権限、バックアップ、削除方針などを用途に合わせて追加します。この記事の共有パスワード方式は、テストデータで操作を学ぶための小さな構成です。
アプリの構成から、公開する方法を選ぶ
AIで作ったかどうかにかかわらず、公開先はアプリが必要とする処理で選びます。画面だけを配るのか、サーバーで処理するのか、DBへ保存するのかを、まずClaude Codeに説明させます。
| アプリに必要なもの | 公開方法の候補と公式の案内 | 判断すること |
|---|---|---|
| HTML・CSS・JavaScriptの配信 | Cloudflare PagesやRenderの静的配信 | ビルド時に出力した静的ファイルで足りるか。ブラウザへ秘密値を入れない構成か |
| APIや、DBを読み書きするサーバー | RenderのWebサービスやKamuiDashのWebサーバー | 実行する言語、DBの接続先、保存、認証、継続費用 |
| コンテナーを使うクラウド運用 | Google Cloud Runなど | ビルド・配置、IAM、課金、DB接続を自分の運用に組み込めるか |
表の静的配信リンクは、Next.jsの静的出力を公開する公式例です。この記事の問い合わせ管理サンプルはPythonでサーバー処理とDB保存を行うため、静的ファイルの配信だけでは動きません。サーバーとDBを置く構成が必要です。
公開先へAIツールを接続せず、Claude Codeにコード作成とローカル確認を任せ、人がダッシュボードで公開する方法もあります。自動化の接続は、使う公開先を決めてから準備します。後半では、東京リージョンのサーバーとPostgreSQLを使う具体例としてKamuiDashを取り上げます。
作成の依頼には、保存・認証・実行条件を入れる
次の依頼文は、公開先にかかわらず、保存と動作確認を具体化する出発点にできます。
問い合わせを管理する、小さなWebアプリを作ってください。
利用者は管理者1人です。画面から件名・内容を登録し、
一覧で未対応／対応済みを切り替えられるようにします。
最初はテストデータだけを使います。
Python / FastAPIとPostgreSQLを使ってください。
アプリの一時ファイルにはデータを保存しないでください。
画面と管理APIには認証を付け、入力の長さを検証してください。
秘密値はソース、ブラウザ配信用コード、ログへ入れず、
環境変数から読み込む構成にしてください。
公開先が指定するPORTでHTTP待ち受けし、/healthzを用意してください。
依存関係、DB初期化、起動のコマンドを分けて示してください。
まずローカルで動作確認し、コードと確認結果を見せてください。
GitHubへの保存と公開は、対象と料金を確認した後に進めます。
ここで渡しているのは、具体的な動作と制約です。「本番品質で全部よろしく」だけでは、AIも確認項目を決められません。特に、ブラウザへ送ってよい値と、サーバーだけで扱う秘密値を分けることが必要です。
手元で試すサンプルの構成
添付例はmain.py、init_db.py、index.html、requirements.txtで構成しています。管理者のユーザー名はadmin、パスワードはDEMO_ADMIN_PASSWORDから読みます。APIのSQLにはパラメーターを使い、一覧の文字はDOMのtextContentで表示します。
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
export DATABASE_URL='postgresql://demo_user:local_password@127.0.0.1:5432/contact_demo'
export DEMO_ADMIN_PASSWORD='local-demo-only-change-before-publication'
python init_db.py
python main.py
実行には、サンプル専用の空PostgreSQLが必要です。ブラウザでhttp://127.0.0.1:8000/を開くと、認証の入力を求められます。ローカル以外ではHTTPSのURLで使います。Basic認証はパスワードを暗号化して送る方式ではないため、通信の保護をHTTPSに頼ります。
メールアドレスや名前を入れなくても、「動作確認」「一覧に表示されるか確認」といった件名・本文で操作を試せます。
具体例：Claude CodeとKamuiDashを接続する
ここからは、KamuiDashへ公開する場合の設定と依頼例です。別の公開先を選んだ場合も、アプリの構成、料金、秘密値、公開後の保存・認証を確認する考え方は共通です。
現在のKamuiDashの接続ガイドでは、ClaudeのWeb画面のCustomize > Plugins > DiscoverでKamuiDashを追加し、同じアカウントを使うClaude Codeに同期する手順を案内しています。ガイドに記載された対象はClaude Code v2.1.273以降です。APIキーでのログインは、このアカウント同期の対象外です。
追加後は新しいClaude Codeセッションを開き、接続の案内に従います。Claude Code公式のPlugin追加資料でも、claude.aiアカウントのPluginが別の追加元として説明されています。Claudeのチャット用コネクターとClaude Code用Pluginは入口が異なるため、使っている製品に合う方を選びます。
まず「KamuiDashのプロジェクト一覧を確認してください」と、読み取りだけを依頼します。対象のアカウントとプロジェクトが分かってから、アプリを置く場所を決めます。GitHubから公開する場合は、KamuiDashのGitHub Appが対象リポジトリへアクセスできることも必要です。
公開前に、構成と費用を一度具体化する
ローカルで動いたら、次のように公開計画を依頼します。
このアプリをKamuiDashに公開する計画を示してください。
対象は <プロジェクト名>、ソースは <所有者/リポジトリ> の
<ブランチ名> です。
Webサーバー1レプリカとPostgreSQLを想定し、
現在の基本料金と、別途発生する料金を分けてください。
セットアップ・起動前・起動コマンド、ヘルスチェック、
DB接続、必要な環境変数の「名前」を一覧にしてください。
秘密値そのものの提示や読み上げは不要です。
このサンプルの設定は次のとおりです。DBを作成し、アプリへ接続するとDATABASE_URLが設定されます。
| 項目 | 設定例 |
|---|---|
| 種類・言語 | Webサーバー／Python |
| セットアップ | pip install -r requirements.txt |
| 起動前 | python init_db.py |
| 起動 | python main.py |
| ヘルスチェック | /healthz |
| アプリの追加環境変数 | DEMO_ADMIN_PASSWORD |
| データベース | サンプル用のPostgreSQLを選択 |
管理パスワードはダッシュボードで設定し、チャットへ貼らずに進めます。AI連携で実行できる操作と、人が設定する秘密値を分けてください。現行の連携仕様はKamuiDashのAI接続資料が確認先です。
また、AIツール自体の利用料金は、アプリやDBの料金と別です。公開先の見積もりに含まれていると思い込まないようにします。
デプロイ成功の後に、利用者として確認する
画面に「成功」と出たことと、問い合わせを管理できることは別の確認です。AIには、次の項目を実施し、できたこと・できなかったことを分けて返すよう依頼します。
| 確認 | 期待する結果 |
|---|---|
| 未認証で画面を開く | 認証が要求される |
| 未認証で管理APIへアクセス | 401で拒否される |
| テスト問い合わせを登録 | 一覧に件名と本文が表示される |
| 対応済みに変更 | 表示とDBの状態が更新される |
| ページを再読込 | 登録内容・状態が残る |
| 再デプロイ後に開く | 同じデータが読める |
| 存在しないIDを変更 | 404となり、別の問い合わせを変更しない |
今回のサンプルはローカルで認証・保存・状態変更・再起動後の読み取りを確認しています。この記事のためにKamuiDashへ新しいアプリを作成したり、問い合わせの実データを送信したりはしていません。
公開後の修正も、小さな完了条件で依頼する
最初の版が動いたら、たとえば次のように変更範囲を絞れます。
一覧を未対応だけに絞る機能を追加してください。
まず現在の登録・一覧・状態変更の動作を確認してください。
DBの既存データは維持し、変更点と確認方法を示してください。
修正後は未対応だけ表示されること、対応済みにすると
その一覧から外れること、全件表示には残ることを確認してください。
不具合が出た場合は、URL、操作、発生時刻、エラーの状況を渡します。「動かないので全部作り直して」より、再現できる小さな情報が役立ちます。ログを共有するときも、認証情報や問い合わせ本文を含める必要はありません。
よくある疑問
コードを理解していなくても任せられますか？
最初の構成はAIに作らせられますが、何が公開され、誰がアクセスでき、どこへ保存されるかは自分でも確認します。画面・API・DBの役割を分けるだけでも、確認が具体的になります。
このまま本物の問い合わせを受け付けられますか？
添付例は管理者用デモです。一般の人が投稿するフォーム、迷惑投稿への対策、通知、利用者ごとの権限はありません。受付フォームを追加する場合は、管理APIとの分離や入力・送信回数の制限も設計します。
Pluginが使えない場合はどうしますか？
AIにはコード作成とローカル確認を任せ、GitHub連携やアプリ作成をダッシュボードで行えます。接続方法を変えても、保存と公開後の確認項目は同じです。
AIへ依頼する内容を、画面の形から「利用者が何を完了できるか」へ広げる。公開後も同じ基準で確認すると、作成と運用を一続きにできます。
接続仕様・料金の確認日：2026年11月2日。接続の入口は変更されることがあるため、実際の追加時には最新の案内を確認してください。
あわせて読みたい
KamuiDashは、GitHubやAI連携からWebアプリを公開できる東京リージョンのPaaSです。