業務アプリを作ったら検証依頼の前に必ずぶつかる壁｜JSパスコードで限定公開する最小構成

AIで作る業務システム

バイブコーディング（AIと一緒にコードを書く開発スタイル）の普及で、今まで個人では難しかった高度な業務アプリが、エンジニア一人でも作れる時代になりつつあります。

請求書管理ツール、在庫管理システム、顧客管理アプリ……。以前なら開発会社に数百万円を払って発注していたものが、AIと一緒なら個人でも形にできるようになってきました。

でも、いざアプリが動くようになったとき、必ずぶつかる壁があります。

「お客さんに試してもらいたい。でも、誰でも見られる状態で公開するのはまずい」

今回はその壁を、AWSの設定変更なし・追加費用ゼロ・JavaScriptだけで乗り越えた話をお伝えします。

📌 AI時事ネタ：個人開発SaaSが急増、「限定公開問題」も急増中

2026年に入り、バイブコーディングの普及で個人開発のアプリ・SaaSが急増しています。一方で「デモ環境を誰でも見られる状態にしてしまい、APIコストが月数万円になった」「開発中のサービスを競合に丸見えにしてしまった」という事故もX上で散見されます。作る力がついた分、公開の管理も重要になってきています。

バイブコーディング時代に起きる「限定公開の壁」

個人でアプリを作ったとき、こんな場面が来ます。

  • 取引先に「試しに使ってみてください」とデモを見せたい
  • 知り合いの会社に「外部検証をお願いしたい」と頼みたい
  • 営業先に「サンプルとして触ってもらいたい」
  • 開発チームの仲間だけにテスト版を配りたい

こういうとき、URLをそのまま渡すと誰でもアクセスできる状態になってしまいます。開発途中の画面、テスト用のデータ、まだ見せたくない機能——全部丸見えです。

「じゃあ認証をかけよう」となるのですが、ここで多くの個人開発者が詰まります。

よくある選択肢とその問題点

案① BASIC認証

BASIC認証とは、ページを開いたときにブラウザがIDとパスワードの入力ダイアログを表示する、昔ながらの認証方式です。素人目には「パスワードがかかっている＝安全」に見えますが、実はセキュリティ的に問題があります。

BASIC認証はIDとパスワードをBase64という方式でエンコードして送信しますが、これは暗号化ではなく単なる変換です。「鍵をかけた」つもりでも、知識のある人が解析すればすぐ見えてしまいます。また、AWSのS3＋CloudFront構成では標準では使えず、別途設定が必要です。

案② AWS Cognito

AWS Cognito（コグニート）とは、AWSが提供するユーザー認証サービスです（「アプリのログイン機能をAWSに丸投げできる仕組み」とイメージしてください）。GoogleアカウントやAppleアカウントでのログインも実装でき、本格的なSaaSには最適です。

ただし、設定が非常に複雑です。ユーザープールの作成・アプリクライアントの設定・コールバックURLの登録・JWTトークン（認証済みであることを証明するデジタルチケットのようなもの）の検証……。このブログでも「Cognito + Google OAuthで詰まる3つの罠」という記事を書いたくらい、ハマりどころが多いサービスです。

マンチーの正直な感想：「お試し公開にCognitoは重すぎる。設定している途中でイライラが頂点に達して、高確率で途中で折れる」。

本番サービスで100人・1000人のユーザーを管理するならCognitoが正解です。でも「特定の10社に試してもらいたいだけ」のケースには完全にオーバースペックです。

マンチーの解決策：JSパスコード＋Cookieで1時間実装

そこでたどり着いたのが、JavaScriptとCookieだけで実装する簡易パスコード認証です。

仕組みはシンプルです。

  1. ページを開いたとき、Cookieにパスコードが保存されているか確認する
  2. 保存されていなければパスコード入力フォームを表示する
  3. 正しいパスコードが入力されたらCookieに保存してページを表示する
  4. 次回アクセス時はCookieを確認してそのまま表示する

Cookieとは、ブラウザにちょっとしたデータを保存しておく仕組みです。「一度パスコードを入力したら、しばらくはまた聞かれない」状態を作れます。

実際のコードはこのようなものです。

// パスコードの設定（この値を知っている人だけアクセスできる）
const PASSCODE = 'your-passcode-here';
const COOKIE_NAME = 'site_access';
const COOKIE_DAYS = 7; // 7日間有効

function getCookie(name) {
  const value = `; ${document.cookie}`;
  const parts = value.split(`; ${name}=`);
  if (parts.length === 2) return parts.pop().split(';').shift();
}

function setCookie(name, value, days) {
  const expires = new Date(Date.now() + days * 864e5).toUTCString();
  document.cookie = `${name}=${value}; expires=${expires}; path=/`;
}

window.addEventListener('DOMContentLoaded', () => {
  if (getCookie(COOKIE_NAME) !== PASSCODE) {
    const input = prompt('パスコードを入力してください');
    if (input === PASSCODE) {
      setCookie(COOKIE_NAME, PASSCODE, COOKIE_DAYS);
    } else {
      document.body.innerHTML = '
アクセスが拒否されました。
';
    }
  }
});

HTMLファイルの<script>タグ内にこのコードを貼り付けるだけです。AWSの設定変更は不要、サーバー側の設定変更も不要、追加費用もゼロです。お客様に渡すパスコードを変えたいときは1行書き換えてデプロイするだけです。

なお、Cookie の有効期限（上記コードではCOOKIE_DAYS = 7）も自由に変えられます。1日だけ試してほしいなら1、1ヶ月なら30と数字を変えるだけです。営業デモなら「当日限り」、外部検証なら「2週間」など、用途に合わせて設定できます。

この方法のメリット・デメリット

メリット

  • 実装が簡単：HTMLにJavaScriptを追加するだけ。1時間以内に完成します。
  • 追加費用ゼロ：AWSの設定変更なし。Cognitoの利用料なし。
  • S3＋CloudFront構成でも使える：サーバー設定不要なので構成を選びません。
  • パスコード変更が簡単：コードの1行を書き換えてデプロイするだけです。

デメリット・限界

  • セキュリティは高くない：JavaScriptのソースコードを見るとパスコードが見えてしまいます。悪意を持って解析しようとする人には無力です。
  • 個人ごとの管理ができない：「A社はアクセス可、B社は不可」という細かい制御はできません。全員同じパスコードになります。
  • Cookieを削除されると再入力が必要：ブラウザのCookieをクリアすると、次回またパスコードを聞かれます。

つまり、この方法が向いているのは「悪意のある第三者ではなく、たまたまURLを知った人を弾く」レベルの用途です。お試し・検証・営業サンプルの段階なら、これで十分です。

バイブコーディング時代、こういう場面は必ず来る

これからAIを使った個人開発はさらに加速します。今まで「個人では無理」と思われていた高度な業務アプリが、AIとの協業でどんどん生まれてくるでしょう。

そのとき、「動くものができた → 誰かに試してもらいたい」という場面は必ず来ます。その「誰かに」が取引先・営業先・外部の検証者であれば、誰でもアクセスできる状態での公開は避けたいはずです。

かといって、お試し段階でCognitoを設定する時間と労力は勿体ない。そういうとき、このJSパスコード認証が役に立ちます。

まとめ：開発フェーズに合わせた認証を選ぶ

  • お試し・検証・営業サンプル段階 → JSパスコード＋Cookie（今回の方法）
  • 社内ツール・中規模サービス → BASIC認証（HTTPS必須）
  • 本番SaaS・ユーザー管理が必要 → AWS Cognito

「セキュリティは強ければ強いほどいい」と思いがちですが、強すぎる認証は実装コストと運用コストが跳ね上がります。開発フェーズに合った最小構成を選ぶことが、個人開発を前に進める鉄則です。

マンチーはこの方法でアプリのデモ環境や外部検証を乗り切っています。「とりあえず動かして試してもらいたい」段階では、これで十分です。

関連記事もどうぞ：

コメント

タイトルとURLをコピーしました