Shopifyアプリを継続的に量産する仕組みを作ろうとすると、必ず「アプリの発行そのものを自動化できるのか」という壁にぶつかります。結論から言うと、アプリの作成・設定・拡張の配布まではコマンドラインから完全に自動化できますが、配布方式の選択とインストールリンクの生成はパートナーダッシュボードでの手動操作しか手段がありません。しかもこれは当社固有の制約ではなく、同種の海外サービスも同じ割り切りをしている業界共通の制約です。本記事では、どこまでが自動化でき、どこからが手作業として残るのか、そして残った手作業を利用者の体験に響かせないための運用設計を解説します。カスタムアプリを複数ストアへ継続的に提供するベンダーの技術者・PMに向けた内容です。

Partner APIにアプリを作る機能はない

まず誤解が多い点から。パートナー向けのAPIがあるのだから、そこからアプリを作れるだろう、と考えるのは自然です。しかし実際にスキーマ全体を精査すると、用意されているミューテーションはクレジットの発行とサブスクリプションのキャンセルの2つだけでした。アプリの作成も、スコープの設定も、配布方式の設定も、ミューテーションとして存在しません。

このAPIの性格は「パートナーダッシュボードのデータを読み取るためのもの」であり、取引情報やアプリイベントの取得が主用途です。書き込み系の自動化基盤としては設計されていません。ここを最初に理解しておかないと、存在しない機能を探して時間を溶かすことになります。

一方で、精査の過程で有用な副産物も見つかりました。アプリのイベントとしてインストール・アンインストールの発生を取得できるため、アンインストール通知Webhookの取りこぼしを検知するバックアップとして使えます。Webhookの配信は保証された仕組みではないので、独立した観測手段を持てるのは実務上ありがたい発見でした。

CLIで自動化できる範囲は思ったより広い

では自動化は諦めるのかというと、そうではありません。Shopify CLIはCI用のトークンを環境変数に渡すことで非対話実行でき、次の流れがすべてスクリプトから回せます。

アプリをパートナー組織上に新規作成し、クライアントIDとシークレットを発行させる
設定ファイル（TOML）にアプリ名・スコープ・アプリケーションURL・リダイレクトURL・購読するWebhookを記述する
デプロイコマンドで設定と拡張を配布する。ここにはShopify FunctionsやTheme app extensionの配布も含まれる
発行されたクライアントIDとシークレットを、アプリ本体の環境変数へ注入してインフラをデプロイする

当社で検証したところ、設定ファイルの反映によるアプリ名やスコープの書き換えは有効で、後述する保護顧客データの宣言はスコープを変更しても維持されることが確認できました。つまり「先に器だけ作っておいて、後から中身を書き換える」という運用が成立します。これは次に述べる制約への対処に直結する重要な事実です。

手作業として残る2つの操作

自動化できないのは次の2点です。

配布方式の選択。アプリを特定ストア向けのカスタムアプリとして配布するか、公開アプリにするかの選択は、パートナーダッシュボードのUIからしか行えません。しかも一度選択すると変更できません。

インストールリンクの生成。カスタムアプリとして配布する場合、対象ストアのドメインを入力してインストールリンクを生成する操作も、ダッシュボードのUIのみです。

「他社のサービスは自動化しているのでは」と疑って海外の類似サービスのドキュメントを精査しましたが、自動化されているのはアプリの作成と設定までで、配布方式については同様にダッシュボードへユーザーを誘導していました。同じ課題を尋ねる公開の質問スレッドも未回答のまま残っています。現時点では業界共通の制約と考えて設計するのが妥当です。ブラウザ自動化で突破する手も理屈上はありますが、規約上のリスクを負う価値はないと当社は判断しています。

カスタムアプリなら保護顧客データの審査は不要、ただし宣言は要る

もうひとつ、納期に直結する重要な事実があります。注文や顧客の情報にアクセスするアプリは「保護顧客データ」の扱いが問題になりますが、公開アプリが審査必須なのに対し、カスタムアプリは審査なしで常に利用可能です。数週間から2か月規模の審査待ちが発生しないため、納期リスクとしては消滅します。

ただし手放しではありません。制約が2つあります。

ひとつは、保護顧客データへのアクセス申請には、開発ストア上であっても事前に配布方式の選択が必要なこと。「配布方式は未選択のままテストして、納品直前に選ぶ」という順序は、顧客データを扱うアプリでは成立しません。

もうひとつは、どのデータ項目をどんな理由で使うかを宣言するフォームがダッシュボードの手動操作のみで、設定ファイル経由の指定に対応していないことです。宣言さえ済めばカスタムアプリは審査提出なしでアクセスできますが、その宣言自体に人の手が要ります。

つまり手作業は、当初想定した「納品時の1回」ではなく「案件開始時にも1回」発生する構造になっていました。

事前プール方式で、手作業をユーザー体験から切り離す

ここが設計上の分かれ目です。案件が始まった瞬間に手作業が必要だと、利用者は「いつ始めるかわからない」のに対して、こちらは「すぐ手を動かせるとは限らない」という非対称が生じます。利用者から見れば、理由の分からない待ち状態やエラーとして現れます。これは避けたい。

そこで当社が採用しているのがアプリの事前プール方式です。

定期的なまとめ作業として、プレースホルダ名のアプリを必要数だけ作成し、配布方式の選択と保護顧客データの宣言（想定される全カテゴリを事前宣言）をまとめて済ませておきます。テスト用のアプリはこの時点でテストストアのドメインを入力してインストールリンクまで生成しておけます。テストストアは自社の固定資産なのでドメインが事前に判明しているからです。生成したクライアントIDやリンクはプールとして管理し、残数が一定を切ったらアラートで補充します。

案件が始まったら、プールから割り当てて設定ファイルの反映でアプリ名・URL・スコープを案件内容に書き換えるだけ。手作業ゼロで進行できます。前述した「後から書き換えられる」「宣言はスコープ変更後も維持される」という検証結果が、この方式を支えています。

残る手作業は、納品時に対象ストアのドメインを入力してリンクを生成する1分程度の操作だけです。これは納品というイベントに紐づくので、待たせている感覚は生まれません。

事前プールで気をつけていること

この方式には固有のリスクがあり、当社では次のように対処しています。

設定漏れの検知。手作業をまとめてバッチ化すると、配布方式の選択忘れやシークレットの転記ミスといった設定漏れが起きます。厄介なのは、それが案件のテスト実行時まで発覚しないことです。そこで、プールへ登録した直後に自動スモークテストを走らせています。テスト用アプリをテストストアへ自動インストールし、トークン交換を経て代表的なAPI呼び出しが通るかまで検証し、結果を「検証済み／要修正」としてプールの状態に持たせます。これで設定ミスを登録時点で潰せます。

シークレットの保管。クライアントシークレットを扱う以上、保管先は汎用のデータベースに平文で置かず、秘密情報の管理サービスに預けて参照だけを持つ構成にしています。登録画面自体も管理者専用の導線に分離します。

プール枯渇時の挙動。補充が人の手に依存する以上、枯渇はいつか起きます。幸いアプリが実際に必要になるのは受入テストの開始時点で、それより前の工程（要件確認や実装）はアプリなしで進みます。割り当てをテスト開始まで遅延させる設計にしておけば、枯渇時も案件を「テスト待ち」で保留にでき、利用者からは通常の進行に見えます。

使い終わったアプリの後始末。配布先ストアを後から変更できるかは公開情報がなく不確実なため、アプリの使い回しは前提にせず、案件終了後の削除・アーカイブを定期作業に組み込んでいます。放置するとパートナーアカウント上に無限に蓄積します。

事前宣言とデータ最小化のバランス

全カテゴリを事前宣言することは、データ最小化の原則との関係でグレーに見えるかもしれません。当社としては、実際のAPIアクセスは「宣言」と「スコープ」の両方で制限され、スコープは案件ごとに最小に保たれるため、実効的なアクセス範囲は最小のままであるという整理で許容と判断しています。宣言はあくまで上限の枠取りであり、実運用の権限はスコープが決めます。この整理が成り立つのは、スコープを案件ごとに最小化する仕組みが別途あることが前提です。

まとめ

Shopifyアプリの発行を自動化しようとすると、パートナー向けAPIには作成系のミューテーションが存在せず、CLIが唯一の自動化手段だと分かります。CLIでアプリの作成から設定・拡張の配布までは全自動にでき、残るのは配布方式の選択と保護顧客データの宣言、そしてインストールリンクの生成という、ダッシュボードでの数分の操作だけです。この制約は他社サービスも同じで、突破しようとするより受け入れて運用でずらすほうが筋が良いというのが当社の結論です。アプリを事前にプールし、手作業を利用者の進行から切り離す。それだけで、避けられない制約が利用者の体験を損なわなくなります。