アプリの制作

最終更新: 2026年7月3日

自分で作った Web アプリを Market App としてマーケットプレイスに公開するには、まずアプリをビルドし、その成果物を用意する必要があります。この工程には、HTML・JavaScript で静的サイトをビルドし、コマンドラインでビルド成果物を確認する作業が含まれます。

Market App は、マーケットプレイスに公開して別の Space にインストールするアプリです。形態は Web Hosting と同じ静的 Web アプリです。あらかじめビルドしておいた画面ファイルの束を公開しておくと、訪問者が訪れたときにその画面がそのまま表示されます。

通常の Web アプリと異なる点が一つあり、そのためにビルド時に守らなければならない規則が一つ生まれます。このページでは、その違いと規則、そして公開前の検証を扱います。

インストールするとリソースがインストールした人の Space にコピーされる

Market App をインストールすると、アプリの画面だけでなく、公開時に一緒に選んだリソース(Content Type、Content、Media など)も インストールした人の Space にコピー されます。アパレルショップの商品カタログアプリを作って公開したと考えてみてください。誰かがそのアプリをインストールすると、アプリの画面とともに商品 Content Type と商品 Content がその人の Space にコピーされて入ります。

コピーされたリソースは、インストールした Space で 新しい識別子 を受け取ります。コンテンツを読み込むために使う Delivery Access Token も、インストールした Space に新しく作られます。そのため、インストールされたアプリは制作者の Space ではなく、インストールした人の Space にコピーされた自身のコピー を読み込みます。インストールが終わると、そのアプリはインストールした Space のリソースだけで動作します。

なぜアクセス情報をビルドに埋め込むのか

インストールされた Market App には サーバーがありません。 Web Hosting と同じ静的ホスティングなので、リクエストごとに画面を計算して返すサーバーランタイムがなく、コンテンツは ブラウザが直接 WEEGLOO の配信 API(CDA, Content Delivery API)を呼び出して取得します。そのため、ビルド成果物(画面ファイル)の中には、どの Space から何を、どの資格情報で読み込むか が文字として書かれていなければなりません。

問題は、前述のとおりインストールするとリソースが新しい識別子でコピーされるという点です。ビルドファイルに書かれた値は制作者 Space の識別子とトークンですが、インストールされた場所で読み込むべきものは新しくコピーされたコピーです。古い値のまま放置すると、アプリは見当違いの場所を指してしまいます。

そこで WEEGLOO が、インストール時にこれらの値を代わりに 差し替えてくれます。 公開時にビルドテキストの中で制作者 Space の識別子・トークン・リソース識別子が どこに書かれているかをあらかじめ探しておき、インストール時にその箇所をインストールした Space のコピーの新しい値に 置き換え ます。これにより、インストールされたアプリは自動的にインストールした Space を指すようになります。

この置き換えは アプリに同梱したリソースに対してのみ 起こります。ですから、画面が読み込むリソース(Content Type・Delivery Access Token など)は、公開時に漏れなく一緒に同梱しなければなりません。漏らすとその識別子は置き換えられず、インストールされた場所で見当違いの値のまま残ります。何を一緒に同梱すべきかは アプリの公開 のリソース選択で扱います。

この自動置き換えには前提が一つあります。値がビルドテキストの中に 一つの完全な文字列としてそのまま 入っていなければならない、ということです。公開段階がその文字列を 文字どおりに探して 位置を記録するためです。値を分割したり、実行中に組み立てて差し込んだり、外部から受け取るようにしておくと、公開段階がそれを見つけられず、すると インストール時に置き換えも起こらないため、インストールされたアプリが動作しません。

ビルドに埋め込む(そしてインストール時に置き換えられる)値は三つです。

  • 元の Space の sys.id(spaceId): どの Space から読み込むか。
  • 元の Space の Delivery Access Token: その Space の公開済みコンテンツを読み込める読み取り専用の資格情報。
  • アプリが参照するリソースの sys.id: たとえば商品を格納した Content Type の sys.id など、クライアントコードが指すリソース識別子。

値をリテラルでインラインにする

肝心なのは、上記の三つの値が ビルド成果物の中に一つの完全な文字列リテラル(intact literal substring)として現れなければならない ということです。ビルドされたテキストファイル(JS・HTML・JSON など)を開いたとき、値が分割されたり変形されたりせず、そのまま一塊で見えなければなりません。そうすることで、公開段階がその値を探して位置を記録し、インストール段階がその箇所を新しい値に置き換えられます。

以下は、クライアントコードに置いた設定の例です。値は形式だけを示す例であり、実際の資格情報に置き換える必要があります。

// weegloo.config.js: これらの値がビルド成果物にそのまま載る
export const WEEGLOO = {
  spaceId: "spc_xxxxxxxxxxxxxxxx",                 // 元の Space の sys.id
  deliveryAccessToken: "dat_xxxxxxxxxxxxxxxxxxxx",  // 元の Space の Delivery Access Token
  productContentTypeId: "ct_xxxxxxxxxxxx",          // アプリが読み込む Content Type の sys.id
};

ブラウザはこの値で CDA を直接呼び出します。

fetch(`https://cda.weegloo.com/v1/spaces/${WEEGLOO.spaceId}/contents`, {
  headers: { Authorization: `Bearer ${WEEGLOO.deliveryAccessToken}` },
});

次のような方式は 使ってはいけません。 いずれも値がビルド成果物に完全なリテラルとして残らないようにしてしまい、公開段階が値を見つけられなくなります。すると インストール時に置き換えが起こらず、インストールされたアプリが自身の Space のコピーを読み込めなくなります。

  • ランタイム環境変数の参照。 インストールされたアプリには値を注入するサーバーやランタイム環境がなく、ビルドテキストに値が文字として残ることもありません。

    // NG: インストールされた場所にこの環境変数は存在しない
deliveryAccessToken: process.env.DELIVERY_ACCESS_TOKEN

  • ランタイムの fetch で取得する。 値をどこかから受け取るようにすると、ビルドテキストに値が残らず、取得してくる先もありません。

  • 文字列結合で分割する。 値が一塊で現れず、公開段階が見つけられません。

    // NG: 成果物に "dat_xxxxxxxxxxxxxxxxxxxx" が一つの substring として残らない
deliveryAccessToken: "dat_" + "xxxxxxxxxxxxxxxxxxxx"

  • プレースホルダーや空欄のままにする。 値を埋める作業はインストール時に WEEGLOO がやってくれます。しかしその置き換えは、ビルドに埋め込まれた実際の値を探してその箇所を変えるものなので、空欄や仮表示のままにすると探すべき値がなく、置き換えの対象になれません。ビルド成果物を作る時点で、実際の値が文字どおりに入っていなければなりません。

値は必ず テキストファイル(JS・HTML・JSON など)に置いてください。画像・フォントのようなバイナリファイルに入れてはいけません。値を探して置き換える作業はテキストファイルでのみ起こります。

バンドラーも確認の対象です。一部のバンドラーは、文字列リテラルを最適化の過程で分割したり変形したりします。ソースコードだけを見て安心せず、実際のビルド成果物 を開いて、値が完全なリテラルとして残っているか確認してください(次節)。

トークンは最小権限で発行する

ビルドに埋め込む Delivery Access Token は、ブラウザにそのまま露出します。インストールした誰もがアプリのビルドファイルからこの値を見ることができます(インストール後にその Space に新しく作られるトークンも同様に露出します)。そのため、このトークンは アプリが実際に読み込む必要がある Content Type だけ を読み込める 最小権限の SpaceRole で発行しなければなりません。Administrator ロールで発行しないでください。 管理者権限のトークンがブラウザに露出すると、元の Space 全体が危険にさらされます。

最小権限の SpaceRole を作り、そのロールで Delivery Access Token を発行する方法は トークン で扱います。

公開前の検証

公開する前に、頭の中ではなく 実際のビルド成果物 で値が正しく入っているか確認してください。ビルドされたフォルダで元の spaceId、トークン、リソースの sys.id をそれぞれ grep して、完全なリテラルとして出てくるか見ます。

grep -r "DATxxxxxxxxxxxxxxxx" dist/

探したい値がビルド成果物の中で一塊として(分割されたり変形されたりせず)出てくれば大丈夫です。埋め込んだ三つの値(spaceId、Delivery Access Token、参照リソースの sys.id)すべてについて確認してください。一つでも grep に引っかからなければ、公開段階もその値を見つけられず、インストール時に置き換えられません(バンドラーが値を変形したか、ランタイム参照で抜けたかのいずれかです)。そのときは、前の「値をリテラルでインラインにする」を参照して、値が完全なリテラルとして残るように直してください。

静的ビルドの制約

Market App のビルド成果物は、Web Hosting と同じ静的制約に従います。

  • サーバーランタイムがありません。静的 export でビルドする必要があります(SSR なし)。
  • 圧縮を解いたときにファイルが 100 個以下でなければなりません。
  • 束の最上位(ルート)に index.html がなければなりません。
  • WEEGLOO API(CDA など)の呼び出しはブラウザから直接行います。

詳しい静的制約とファイル束の規則は Web サイトの公開 で扱います。

ビルドした画面は App Bundle に格納されます

検証を終えたビルド成果物は、公開時に App Bundle(アプリをバージョンごとにまとめた包み)に格納されます。公開画面で一緒に選んだリソースも同じ束に格納され、インストール時にインストールした Space にコピーされます。公開してバージョンを上げる手順は アプリの公開 で扱います。

アプリが独自の会員を受け入れる場合

ここまでは、誰でも読める公開コンテンツを CDA で読み込む場合です。もしアプリが 独自の会員登録・ログイン を受け入れるなら、ServiceLogin と 公式クライアント SDK を使います。この場合、ブラウザは CDA ではなく ACDA(App Content Delivery API)を会員のトークンで呼び出します。設定と連携方法は サービス会員ログイン で扱います。

インストールされた Market App の認証方式は App Auth が、インストールされたアプリにアクセス権限を持つユーザーは App Member が扱います。

次にやること

  • アプリの公開: 作ったアプリ(App Bundle)をマーケットプレイスに公開するコンテンツスタジオ手順を扱います。
  • Web サイトの公開: 静的ビルド、ファイル 100 個の制限、index.html ルートといった Web Hosting の基本を扱います。
  • トークン: ビルドにインラインする Delivery Access Token を最小権限の SpaceRole で発行する方法を扱います。
  • API リファレンス: アプリの画面がコンテンツを読み込むときに呼び出す CDA(配信 API)、独自の会員を受け入れるアプリであれば ACDA のリクエスト形式といった技術仕様を扱います。