ClaudeやCursorで作ったアプリに管理画面を追加する方法

この1年で何十回も見てきた、そして自分でも経験したパターンがあります。ClaudeやCursorを開いて、アプリを説明して、週末が終わる頃には本物の何かができている——ECサイト、予約ツール、コンテンツサイト、何ヶ月も作りたいと思っていたSaaS。AIがフロントエンドもルーティングもスキーマも全部書いてくれました。

そして誰も準備してくれなかった部分が来ます。管理画面です。

ユーザー向けサイトのことではありません——それはもう完成しています。バックオフィスのことです。返金を承認し、商品を編集し、今週誰が登録したか確認し、誰かに壊されたレコードを直し、昨日の数字を眺める画面群。エージェントでアプリを作ったなら、おそらくそのどれもありません。あるのはエージェントが作ったデータベースと、そこに増えていく本物のデータ。そしてそれを眺める良い手段がない、という状態です。

この記事では、その状況で実際に取れる選択肢と、私が何度も戻ってくる方法を紹介します。

なぜAI製アプリには管理画面がないのか

エージェントがアプリを構築するとき、最適化するのはあなたが頼んだもの、つまりユーザー向け体験です。ログインページも、顧客向けダッシュボードも、チェックアウトも、ユーザーが触る部分の丁寧なCRUDも喜んで生成します。しかし内部向けのインターフェース——ビジネスを回すための画面——は、明示的に頼まない限りほとんど生成しません。これはエージェントの失敗ではありません。人間が速く開発するときと同じです。管理画面は退屈で、目に見えず、後回しにしやすい。「あとで作る」が「あとで」= 半年間の手動データベース編集になるのです。

その間にデータベースには大事なものが積み上がります。注文、ユーザー、返金、サポートチケット、コンテンツ。どの行も待っている判断です——発送すべき注文、承認すべき返金、公開すべき下書き。そして行動を起こすための唯一の道具はSQLプロンプトか、status: "pending" を文脈なしで表示するだけの生のデータベースクライアント。

人がこの問題を解決する4つの方法（とその代償）

管理画面がない問題を、人が4つの方法で解決するのを見てきました。どれも機能します。どれにも代償があります。

方法1：CRUD画面を手書きする

古典的です。袖をまくり、ルーティングファイル、テーブルコンポーネント、フォームコンポーネントを作り、気になるテーブルごとに繰り返します。キャリアで一度はやったことがあるでしょう——AI以前の内部ツールはほとんどこうやって作られました。

長所：完全に制御できる。思い通りに見た目を作れる。ベンダーに金を払わないという意味で「無料」。

短所：時間がかかります。そして時間こそ、エージェントを使うことで節約したかったもの。テーブルごとに新しい画面群が必要で、スキーマが変わるたびに一連の修正が必要です。個人開発者ならアプリ1つにつき数日——しかもアプリ自体は週末でできたのに。AI製アプリの管理画面を手書きするのは、プロジェクトで最も安い部分を最も高い方法で仕上げることです。

方法2：フレームワークの組み込み管理画面を使う

DjangoにはDjango Admin、RailsにはActiveAdmin、LaravelにはFilamentがあります。エージェントがこれらのフレームワークでアプリを作ったなら、生成済みの管理画面を半日で有効にできることが多いです。

長所：存在する。モデルに紐づくのでスキーマを知っている。データはマシンから出ない。

短所：フレームワークに縛られます。スタックがDjango/Rails/Laravelではない瞬間——エージェント製アプリの多くはReact + API + Postgres、または静的フロントエンド＋サーバーレスバックエンド——有効にできるものはありません。しかもフレームワークの管理画面は開発者向けであり、「この返金を承認」というワークフロー向けではありません。結局カスタマイズします。

方法3：クラウド管理SaaSを採用する

Retool、Budibase、NocoDBのホスト版、Airtable——「内部ツールを数分で」と謳うツールたちです。データを向ければUIを生成してくれます。

長所：速い。洗練されている。チーム向き。

短所：本番データベースの認証情報を第三者に預け、運用データが彼らのサーバーを通ります。サイドプロジェクトなら面倒なだけ、実ユーザーがいるものなら、やりたくないコンプライアンスの話になります。しかも本質的にCRUDインターフェースにすぎないものに、席単位・エディタ単位で永久に支払い続けます——価格が変わったりサービスが終わったりすれば、管理画面も一緒に消えます。

方法4：すでにあるデータベースに接続するローカル管理画面

私がBasevoltを構築する際に軸にしたアプローチであり、エージェントで出したすべてのアプリで実際に使っている方法です。デスクトップアプリで、アプリがすでに使っているデータベース——エージェントが作ったPostgreSQL、SQLite、MySQL、Cloudflare D1——に接続します。スキーマをそのまま読み、マイグレーションもエクスポートもせず、運用パネルに変えます。グリッド、カンバン、ギャラリー、ダッシュボード、Webhook。

長所：データがマシンから出ない。席課金なし、クラウドアカウントなし。すでにあるデータベースでそのまま動く——移行も再構築も不要。しかもアプリが話しているのと同じデータベースの上に載るので、パネルで見えるものはユーザーがアプリで見るものと完全に一致します。

短所：デスクトップアプリなので設計上シングルユーザーです。5人がログインしてブラウザで同じレコードを編集する必要があるなら、この製品ではありません。接続は自分で行う必要がありますが、1分ほどです。

私の考えを変えた部分：エージェントに設定させる

方法4が腑に落ちたのはここです。アプリはエージェントで作った——管理画面もエージェントに作らせればいいじゃないか、と。

Basevoltはマシン上でMCPサーバーを動かします。アプリを書いたのと同じClaudeやCursorが接続して、パネルを設定してくれます。フィールド型、テーブル間のリレーション、仕事の流れに合ったビュー。「注文のバックオフィスを設定して」と言えば、エージェントがスキーマを読み、あなたが手でやっていたクリックを代行します。

「エージェントに管理コードを書かせればいいじゃないか」と思うなら、違いはここです。エージェントがBasevoltを設定するのは、データベースを再実装するコードを生成することではなく、データベースを読むパネルを設定することです。保守する新コードも、デプロイも、実際のスキーマから乖離するものもありません。スキーマが変わればパネルが反映します。家の写真を生成することと、家の中に入ることの違いです。

セットアップ（約1時間、ほとんどはエージェントが作業）

実際の流れを、冒頭のストアアプリを例に見ていきます。

ステップ1——エージェントが作ったデータベースに接続。

Basevoltをダウンロードし、データソースを追加して、アプリが使っているのと同じデータベースに向けます。Postgresならホスト、ポート、DB名、ユーザー、パスワード。SQLiteなら.dbファイルを選ぶだけ。スキーマをそのまま読みます——マイグレーションも設定ファイルも不要。

ステップ2——MCPを有効にして、エージェントにパネルを設定させる。

Basevoltの設定を開き、MCPサーバーを有効にし、ClaudeかCursorに登録します（アプリが各クライアントの正確な設定を表示します）。そしてエージェントにこう頼みます：

ストアのデータをBasevoltに取り込んで、バックオフィスを設定して。顧客はIDではなく名前で表示して。ステータスは読みやすくして。対応待ちの注文を確認できるボードが欲しい。

エージェントはスキーマを読み、リレーションを結び、フィールドの型を付け、ビューを設定します。以前は一晩かかっていたクリック作業が、エージェントが数分で代行します——しかも変更のたびにパネルで確認できます。

ステップ3——実際にそこから運用する。

翌朝、SQLプロンプトを開く代わりにパネルを開きます。対応待ちの注文はボード、保留中の返金はキュー、昨日の数字はダッシュボード。判断が必要なとき——承認、発送、返金——ボタンをクリックすると、Webhookが既存のAPIへアクションを届けます。これが全体のループです。エージェントがアプリを構築し、パネルを設定し、あなたが運用する。

正直なトレードオフ

限界について率直に言います。チーム向けの内部ツールを作っているなら——5人にログインと権限と共有ブラウザワークスペースが必要なら——ローカルデスクトップアプリは正解ではなく、RetoolかセルフホストのNocoDBを見るべきです。アプリに管理面がまったくない場合、例えばデータベースのない静的サイトなら、パネルを取り付けるものもまだありません。

しかし、ますます一般的な*「エージェントでアプリを作って、今それを運用する必要がある」*というケース——本物のデータがあり、バックオフィスがない個人開発者——なら、既存データベースの上に載せるローカルパネルが最速の道であり、アプリを書いたのと同じエージェントに設定させることでループが閉じます。管理画面は誰も書きたがらないアプリの一部分です。このアプローチなら、書く必要すらありません。