Claude Codeで作ったアプリを、非エンジニアがそのまま社内に公開できたら——。ファッションレンタルサービスのエアークローゼットが、その仕組みを実現しました。

この記事でわかること：

  • Sandbox MCPが解決する「作れるけど公開できない」問題
  • ワンコマンドでデプロイからSSL・認証まで完了する仕組み
  • データ分離とセキュリティの設計
  • 非エンジニア向けプラットフォームとして機能する理由

「作れるけど公開できない」という壁

https://zenn.dev/aircloset/articles/65efe9614f8e73

Claude Codeなどの AIコーディングエージェントが普及し、PdMやデザイナーでも「こういう画面を作って」と指示するだけでアプリが動くようになりました。エアークローゼットでも、モックアップやKPIダッシュボード、業務効率化ツールなど、非エンジニアからのアウトプットが増えています。

ただし、ローカルで動かすのと社内に公開するのとでは難易度がまるで違います。クラウドへのデプロイ、ドメイン取得、SSL証明書、OAuth認証、データベース設計——これらをすべてAIに書かせることは技術的には可能ですが、設定ミスによるセキュリティ事故のリスクがつきまといます。全世界に公開されていた、認証がバイパスされていた、本番DBに書き込めるサービスアカウントが渡されていた——こうした事故は、AIがコードを書くほど起きやすくなります。

Sandbox MCPは、この「作る」と「公開する」の間に立つプラットフォームです。

Sandbox MCPの仕組み

Sandbox MCPは、エアークローゼットのCTO辻氏が社内向けに開発したMCPサーバーです。Claude Codeから10個のツール（publish、status、schedule、list、delete、write_file、read_file、list_files、init_repo、unschedule）を呼び出すだけで、以下がすべて自動で完了します。

  • 社内UIキットを使った統一デザインのアプリ生成
  • https://sbx-{ニックネーム}--{アプリ名}.example.com/ へのデプロイ
  • CloudflareのGoogle SSOによる社内認証の強制
  • Firestoreの専用DBへのデータ分離保存

アプリ作者が責任を持つのは「機能」だけです。セキュリティ、認証、SSL、データ分離はプラットフォーム側が標準で担保します。

4種類のアプリ形態に対応

Sandbox MCPは、ソースファイルの種類を自動判定して適切なDockerfileを生成します。

PythonファイルがあればFlask＋gunicornで動かし、package.jsonがあればNode.jsとして扱います。HTMLだけならnginxで静的配信し、Dockerfileを含めれば任意のランタイム（Go、Rustなど）にも対応します。requirements.txtがなければ自動生成されるため、依存ライブラリの解決漏れも防げます。

さらにsandbox_scheduleツールを使えば、Cloud Schedulerによる定期実行も設定できます。「毎朝9時にSlackへレポートを投げる」といったバッチ処理を、cron文法やIaCを書くことなくワンコマンドで登録できます。

データベースの透過的フォールバック

「データを保存したいがDBの設定はしたくない」という要望に応えるのが、SandboxDB SDKです。同じコードがローカルではlocalStorage、デプロイ後はFirestoreで動きます。

SDKはホスト名を見て自動的に切り替えます。localhostならlocalStorageを使い、sbx-*.example.comにデプロイされた時点でFirestore REST APIに切り替わります。コード側の変更は一切不要です。

Firestoreのデータパスは sandbox_data/{ニックネーム}--{アプリ名}/{コレクション}/{ドキュメントID} の形式で厳密に分離されています。さらに、Sandbox専用にsandboxというnamed databaseを用意しているため、社内の他システムが使うデフォルトDBとは物理的に別のデータベースになっています。Sandboxアプリのコードがどう暴走しても、本番データには到達できない構造です。

インフラ設計のポイント

通常、新しいサブドメインを公開するにはDNSレコードの追加、SSL証明書の発行、ロードバランサの設定が必要です。Sandbox MCPはこれらをすべてスキップします。

DNSは *.example.com に対するワイルドカード設定とCloudflareプロキシで固定し、Universal SSLが全サブドメインを自動カバーします。Cloudflare Workerが全トラフィックを受け、サブドメインに応じてCloud Runのサービスにルーティングします。

URLにはOAuthセッションから取得したニックネームが含まれるため、sbx-ryan--todo-app.example.comのようにURLを見るだけで作者が分かります。社内でのオーナーシップが自然に明確になる設計です。

社内UIの統一

非エンジニアが個別にアプリを作ると、ReactやVue、素のHTMLが混在し、デザインもバラバラになりがちです。Sandbox MCPでは sandbox-ui-kit というUIライブラリを用意し、デザイントークン、glass morphismコンポーネント、ダーク/ライト対応のCSSを標準提供しています。

sandbox_publishツールのdescriptionに「まずread_fileでREADME.mdを読み、UI Kitを活用すること」と記載されており、Claude Codeはアプリ生成時にこのドキュメントを読んでからコードを書きます。人間がUIガイドラインを口頭で伝える代わりに、AI向けの仕様書を一箇所に集約している点がMCPらしいアプローチです。

「作る人」と「守る基盤」の責任分離

Sandbox MCPの本質は、責任の分離にあります。AIの普及で「作る」のハードルは下がりましたが、「安全に公開する」のハードルは変わっていません。認証、SSL、データ分離、URL管理——これらをアプリ作者に任せるのではなく、プラットフォームが標準で引き受ける設計です。

エアークローゼットでは2026年1月から約3か月でこの基盤を構築し、現在17個のMCPサーバーが社内で稼働しています（参考）。DB、インフラ、ドキュメント、プロジェクト管理からCI/CDまで、社内業務の広い領域をAIから操作できる状態になっています。

非エンジニアがAIでアプリを作る流れは今後も加速します。そのとき課題になるのは「作り方」ではなく「公開の安全性」です。Sandbox MCPが示したのは、MCPのツール設計とクラウドインフラを組み合わせることで、その課題をプラットフォームレベルで解決できるという実例です。