管理画面の作り方|非エンジニアの自作サービスを3つの画面に分け、/adminをBasic認証で隠す
結論から言います。自分のサービスに管理画面を作るときは、いきなり画面を作り始めず、サービス全体をログイン前・ログイン後・管理画面の3つに分けるところから始めてください。 3つに分けると、管理画面に何を置くべきかが決まります。そして管理画面は、利用者から見えない場所に置きます。
管理画面とは サービスの運営者だけが使う画面。利用者が使う画面とは別に用意し、ユーザー数・売上・利用状況の把握と、問い合わせ対応やお知らせ配信といった運営側の作業をここで行う。Webサービスでは
/adminのようなアドレスに置き、Basic認証などで外から開けないようにすることが多い。

この記事は、みやっち🧑💻が自社プロダクト「AIチャットつくーる」を立ち上げたときの設計をもとに、非エンジニアの経営者・個人事業主向けに整理したものです。セキュリティに関わる部分は、断定ではなく「まずここから始める」という形で書いています。
サービスは3つの画面でできている
AIで作ったアプリを人に使ってもらう段になると、作る対象が「アプリ1つ」から「サービス全体」に変わります(渡す相手の広さで増える仕事の全体は自作アプリの販売で増える仕事に整理しています)。サービス全体は、見る人の違いで3つに分かれます。
| # | 層 | 見る人 | 中身 |
|---|---|---|---|
| 1 | ログイン前 | 検索から来た人・見込み客 | サービスの紹介ページ、ブログ、開発日記 |
| 2 | ログイン後 | 利用者(お客様) | 実際にサービスを使う画面 |
| 3 | 管理画面 | 運営者(自分とスタッフ) | 数字の把握、問い合わせ対応、お知らせ配信 |
1のログイン前は検索に引っかかる面です。サービスの紹介ページだけでなく、ブログや開発日記もここに置きます。2のログイン後は、多くの人が「サービスそのもの」だと思っている部分で、利用者が実際に触る画面です。
抜けやすいのが3です。ユーザー画面が動くと完成した気持ちになりますが、運営として見る画面が無いままだと、ユーザー数も売上も、知りたくなるたびにデータベースを直接開いて数えることになります。作るべき画面は2種類ある——ここを最初に分けておくと、後から作り足す量が減ります。
管理画面には何を置くか
管理画面の中身は、運営として知りたいことと、運営としてやる作業で決まります。AIチャットつくーるの管理画面には、次のものを置いています。
| 置いたもの | 何が分かるか・何ができるか |
|---|---|
| ユーザー数・課金額・API原価から出す見込み利益 | サービスが今いくら残しているか |
| ユーザーの活動 | 誰がどれだけ使っているか |
| プラン別の人数 | どのプランが選ばれているか |
| 問い合わせチケット | 届いた問い合わせをその場で確認して返信する |
| メルマガ | 利用者へのお知らせを配信する |
数字で大事なのは、ユーザー数と課金額だけでなく、API原価まで同じ画面に並べているところです。AIを使ったサービスは、使われるほど原価が増えます。売上だけを見ていると、増えた分だけ利益も増えている気になります。原価を横に置けば、見込み利益がその場で出ます。
問い合わせを管理画面の中に入れたのには理由があります。メールで返信すると、問い合わせの文面はメールソフトに、その人の利用状況は管理画面に、と情報が分かれてしまうからです。同じ画面で問い合わせ内容を見て、そこからAIに返信させれば、確認と返信が1か所で終わります。みやっち🧑💻の言い方では「Zendeskを自分で作ったようなもので、秒でできる」。ただしこれは、問い合わせ管理ツールの機能全体を置き換えたという意味ではありません。自分のサービスに必要な範囲の機能を自分で作った、という話です。
Webサイトやサービスの管理画面は、どこに置くのか
管理画面は、別のサービスとして作るのではなく、同じサービスの中の別のアドレスとして作るのが一般的です。 慣習的によく使われるのが /admin です。サービスのアドレスの後ろに /admin を付けたページを管理画面にする、という形になります。
同じサービスの中に置く理由は単純で、利用者のデータと同じ場所にあるからです。ユーザー数の集計も、問い合わせへの返信も、データを別の場所へ渡す仕組みを作らずにそのまま書けます。
問題は、このアドレスが誰でも思いつくという点です。/admin は管理画面の置き場として広く使われているので、置いただけの状態では、アドレスを打ち込んだ人の前に管理画面が出てきます。ここで必要になるのが、次のBasic認証です。
Basic認証とは
Basic認証とは HTTPの仕組みを使ってページに鍵をかける方法。設定したページを開こうとすると、ブラウザがID・パスワードを尋ねる小さな窓を出し、正しく入力されるまで中身を表示しない。アプリの中に作る会員ログインとは別物で、サーバーやホスティングの設定で当てるほか、Vercelなどではアプリのミドルウェア(全ページの手前で動く短いコード)で当てる。HTTP Basic認証とも呼ばれる。
管理画面に当てるのが、このBasic認証です。アプリ側のログイン機能や権限を作り込む前でも、サーバーの設定か短いコードを足すだけで、管理画面を外から開けない状態にできます。公開前のサイト全体を関係者だけに見せたいときにも、同じ仕組みが使われます。
前提が1つあります。Basic認証は、入力されたID・パスワードを、暗号化されていない形(Base64という、誰でも元に戻せる変換をかけただけの形)で毎回送る方式です。通信が暗号化されていること、つまりHTTPSで配信されていることが前提になります。 主要なホスティングサービスは今はHTTPSが標準ですが、自分のサービスのアドレスが https:// で始まっているかは確認してください。
設定の手順は、使っているホスティングサービスやサーバーによって違います。ここで実際のIDやパスワードの例は書きませんが、他のサービスと使い回しのパスワードを当てないことだけは共通です。管理画面は、利用者全員のデータが見える場所です。
Basic認証を当てれば終わり、ではない
正直に書きます。Basic認証は「まずここから」の一手であって、当てれば安全、という性質のものではありません。 少なくとも次の3つは、Basic認証の外側に残ります。
- IDを共有すると、誰が操作したか分からない — Basic認証のID・パスワードは運営者どうしで共有して使うことが多く、操作の記録が個人にひもづきません。複数人で運営するなら、アプリ側にも管理者のログインと権限の区別が要ります
- データベース側の権限は別の話 — 画面を隠しても、データを取り出す側の権限が空いていれば意味が薄くなります。データベース側の設定はSupabaseのセキュリティ設定に分けて書いています
- 扱うデータによって必要な水準が変わる — 個人情報や決済に関わる情報を扱うなら、Basic認証に加えて、アクセスの制限や操作記録の保存など、別の対策を検討することになります
ここから先は、技術設定だけの話ではなくなります。どこまでの対策が必要かは、自社の社内規定・お客様との契約・利用しているサービスの規約で結論が変わります。顧客のデータをどこまでアプリに預けてよいかはAIに個人情報はどこまで入力していいかも参考にしつつ、判断に迷う箇所は情報システム担当や弁護士などの専門家に確認してください。本記事は一般的な考え方の整理であり、法的助言ではありません。
よくある質問
Basic認証とアプリのログイン機能は何が違いますか
Basic認証は、ページを開く前の段階でHTTPの仕組みを使って鍵をかける方法です。ブラウザが出す小さな窓にID・パスワードを入れると中身が表示されます。アプリのログイン機能は、サービスの中に作る利用者ごとのアカウントの仕組みで、誰がログインして何をしたかをアプリ側で把握できます。管理画面では、まず外から開けなくする目的でBasic認証を使い、記録や権限の細かい区別が必要になった段階でアプリ側の仕組みを足していきます。
管理画面はサービスと別に作ったほうがいいですか
同じサービスの中の /admin のような別アドレスに置くのが一般的です。利用者のデータと同じ場所にあるので、数字の集計も問い合わせ対応もそのまま書けます。別サービスとして分けると、データを受け渡す仕組みを別に用意することになり、一人で運営する規模では手間が増えます。
管理画面は最初から作るべきですか
利用者が自分だけのうちは、なくても構いません。みやっち🧑💻自身も「最初はなくてもいい」と前置きしたうえで、作れるかを試したくて早い段階で作りました。人に使ってもらう段になったら、利用者画面と一緒に、運営として何を見たいかを決めておくと、作り足しが少なく済みます。
運営する側の景色を、自分の手元に作る
管理画面が無い状態では、「今月は何人増えたのか」「誰が困っているのか」を知りたくなるたびに、データベースを開いて数えることになります。管理画面を1枚作ると、今の人数・プラン別の内訳・課金額・API原価・届いた問い合わせが、1つの画面にまとまります。作ったものが「動くアプリ」から「運営しているサービス」に変わるのは、この画面ができたときです。
そして、この画面は外注でも市販のツールでも埋めにくい場所です。どの数字を見たいか、問い合わせにどう答えたいかは、その事業をやっている本人にしか決められないからです。Claude Code・Codexのような実行型のAIエージェントを自分で動かせると、「この数字も並べて」「この問い合わせはAIに下書きさせて」を思いついたその日に足していけます。作る方法の全体像は業務アプリの作り方、何を作るかを決める段はAI開発の要件定義にまとめています。
AI Crewでは、自分の業務アプリを作るところから一緒に進めています。人に使ってもらう段の考え方も、AI週報などで情報としてお届けしています。まず無料セミナーでお会いしましょう。



