Shopifyアプリを開発・販売するには？公開配布・課金状態・権限と削除対応の準備

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

Shopifyアプリを開発して販売するなら、最初に誰のストアへ配るか、どの契約で有料機能を使えるか、利用が終わった後に何を止めて消すかを決めましょう。商品一覧を表示できる試作品があっても、複数店舗への配布、料金変更、削除要求への対応が曖昧なままでは、店主が継続して使う製品として案内できません。

この記事は、Webアプリの基礎知識があり、独立した複数のShopifyマーチャントへ自作アプリを提供したい個人開発者向けです。商品説明と商品画像の不足を読み取り専用で点検する、架空の「商品点検アプリ」を一貫した設計例に使います。無料の手動点検と、有料の定期点検・履歴比較を想定し、配布、データ、課金、審査、削除、保守の順に準備します。

アプリ名、店、機能分け、判定表は説明用の仮定です。実在の商品、実装済みのシステム、実施済みの課金試験、審査合格や収益実績を示すものではありません。図版も生成した説明図で、Shopifyの公式画面ではありません。公式資料は2026年10月6日（日本時間）に確認しました。実装時は利用するAPI版と最新の公式仕様を照合してください。

どの店へ配るかを先に決め、公開配布とカスタム配布を選ぶ

店舗数に加えて、店どうしの関係を確認する

Shopifyアプリの配布方法は、使ってもらいたい店の関係から選びます。たとえば、経営者が異なる雑貨店A、文具店B、食品店Cに同じ商品点検機能を販売したいなら、独立した複数のマーチャントへの提供です。最初に声をかけられた店が一店だけでも、その後に別の店へ販売する計画なら、その範囲を配布の判断へ含めます。

現行のShopify公式の配布方式では、公開配布は複数のマーチャントへ提供する方式で、App Storeの審査を必要とします。カスタム配布は一つのストア、または同じShopify Plus組織に属する複数ストアなど、公式が定める範囲で使います。単に「三店舗だけだからカスタム」と数だけで決めることはできません。

同じ店名の支店でも、Shopify上で同一のPlus組織に属するかは別途確認が必要です。反対に、一社が複数ストアを持っている説明だけで、対象条件を満たしたと推測しないようにします。配布先を一覧にし、誰が管理するストアか、同じ組織か、どこまで確認できたかを書けば、営業上の呼び名と配布条件を切り分けられます。

※表は横にスクロールできます。

配布方式を選ぶ前に、変更できない条件を読む

公式資料では、選択した配布方式は後から変更できないとされています。ひとまずカスタムで作り、売れたらそのまま公開配布へ切り替える、という前提を置かないでください。別の構成が必要になる可能性を含め、将来配りたい相手まで整理したうえで決めます。本稿の架空アプリは独立した店へ販売するため、公開配布を前提に話を進めます。

また、古い教程に出てくる「ストア管理画面から新しいカスタムアプリを作る」手順を、そのまま現在の入口にしないことも重要です。現在の公式の配布表では、管理画面作成方式は既存のものに限る説明になっています。使う開発環境や作成経路は現行案内を読み、見つからないボタンを探して別の権限設定へ進まないようにします。

公開配布にはApp Storeへの登録費用も関係します。確認時点の公式案内は、Partnerアカウントごとに一回19米ドルです。アプリ一つごとの月額料金という意味ではありません。アカウントを新しく作るかどうかは、費用だけでなく所有・管理の条件にも関わるため、既存の所属や運営体制を確かめてから判断します。登録費を払っても、アプリの審査合格や販売数が保証されるわけではありません。

一枚の決定票に、決めた理由と未確認を残す

配布の決定票には「商品点検アプリ／独立した三店へ販売予定／公開配布／審査が必要／月額機能はShopify App Pricingを検討」と書けます。さらに、実際の配布設定は未実施、App Storeの提出条件は要確認、といった未完了事項を別欄へ置きます。方式名だけを記録するより、後から販売範囲が変わったときに、どの前提を見直すべきか分かります。

店主自身として商品を販売する準備を探している場合は、ネットショップ開業の始め方で商品の用意や運営の全体像を確認できます。本稿で販売するのは、店主が使うアプリの利用機能です。アプリの請求と、ストアのお客様が払う商品代金を、以後の試験でも混ぜないようにしましょう。

商品点検アプリの機能を、最小権限と保存データへ落とす

読み取る項目と、点検の意味を小さく定義する

架空アプリの初版は、商品の説明が空か、画像が付いているかを一覧で知らせる機能に絞ります。「商品ページを改善する」という大きな目的を、そのままAPIの権限へ置き換えないことが大切です。説明の内容を自動で書き直す、価格を変える、購入者ごとのおすすめを出す機能まで加えると、必要なデータと誤操作の影響が大きく変わります。

商品情報の取得では、GraphQL Admin APIのProductにあるid、title、descriptionHtml、mediaなどが確認対象になります。公式のアクセススコープ一覧とProduct定義を照合し、商品読取りにread_productsを使う設計から検討します。確認したProduct資料の版表示は2026-10です。ただし、関連先まで広く取得するクエリに変えた場合も同じ権限で足りる、という保証にはしません。実装した取得項目を一つずつ確認します。

「説明が空」の判定も具体化します。HTMLの文字列が存在していても、空の段落タグや空白だけなら、店主が読む説明はないことがあります。一方、画像だけで仕様を説明している商品を、機械的に誤りと決めつけるのは避けます。この例では「要確認の商品」を見つける補助にとどめ、商品の正しさや法令への適合を自動保証する機能にはしません。

画像の点検では、mediaに含まれるメディアを何でも写真一枚と数えると、動画だけの商品を画像ありと扱う可能性があります。この例ではmediaContentTypeがIMAGEの項目を対象にし、READYと、PROCESSING・UPLOADEDなど処理途中の状態を分けて検証します。最初のページに画像が見つからなくても、残りのメディアを取得していなければ「画像なし」と確定しません。APIで対象データを取得できたことと、ストアフロントの全画面で正しく見えたことは別の確認です。

※表は横にスクロールできます。

店ごとにデータを分離し、履歴の中身を必要最小限にする

複数の店へ配るなら、商品IDだけで点検結果を探す構成にしません。アプリ側のストア識別子と商品IDを組にし、利用者が現在アクセスできるストアの範囲でのみ取得・表示する設計にします。画面のURLに店IDが付いていることだけを許可の根拠にせず、サーバー側で認証された接続先と照合する必要があります。

履歴比較のために毎回の商品説明全文や画像ファイルを複製すると、保存量と削除対象が増えます。この設計例では、説明の有無、画像条件を満たすか、点検した時刻、判定ルールの版を中心に残す案を取ります。どの商品かを店主が識別するための名称も、保存する必要と更新方法を決めます。全文を保存しないと実現できない機能がある場合は、その理由と保存期限を改めて検討してください。

過去と現在の比較には、商品側の変更とアプリ側の判定変更という二つの原因があります。昨日まで画像ありだった商品が、今日から要確認になったとき、画像が消えたのか、判定対象の画像状態を変更したのかを区別できなければ、店主は判断に困ります。結果へ判定ルールの版を持たせ、ルールを変えた後の最初の点検を、単純な商品変更件数として表示しない設計が役立ちます。

取得途中と完了を分け、不要なログをためない

商品が複数ページに分かれるストアでは、最初に取得できた一部だけを全商品の結果として見せないようにします。点検の開始、取得済み件数、継続位置、完了時刻を管理し、通信に失敗した場合は「途中の結果」と分かる表示にします。前回完了した結果を残すなら、その日時を明示して、最新の点検が成功したように見せないことが重要です。

操作ログには、処理の種類、ストア識別子、所要時間、結果コードなど、原因調査に必要な情報を選びます。APIの応答本文、トークン、認証ヘッダーを丸ごと記録する方式は避けてください。不要な顧客情報を取得しない設計でも、サポート添付やログから別の情報が入り込むことがあります。点検履歴、短期キャッシュ、監視ログ、問い合わせ記録は、それぞれ別の保存物として削除の対象表へ載せます。

App PricingとBilling APIを分け、有料機能を契約状態で制御する

月額の定期点検は、対応する料金モデルから選ぶ

無料の手動点検と有料の定期点検・履歴比較を提供するなら、「どの機能をどの契約で利用できるか」を先に決めます。この例では月額の有料プランを主に考えますが、価格の相場や契約数を仮定して収益を予測するものではありません。点検の頻度、履歴の範囲、対象商品の制限を明示し、無料で使える機能との違いを店主が理解できる形にします。

現行のShopifyアプリ課金の公式案内では、対応する料金モデルの新規公開アプリはShopify App Pricingが既定です。定額、従量、両者の組合せを扱います。料金プランをPartner Dashboard側で設定し、Shopifyが用意する料金選択・請求の仕組みを使う構成です。古い名称や教程だけで、料金モデルの対応範囲を判断しないようにしましょう。

一方、「一回だけ商品を診断し、その一回分を請求する」という単発購入は、同じ月額プラン設定に入れれば済む話ではありません。公式は単発購入や未対応の料金モデルなどに、Billing APIによるManual Pricingを案内しています。従量課金と単発購入も別です。点検回数に応じた継続課金なのか、一度だけ購入する診断なのかを、機能と利用期間から決めてください。

料金画面から戻ったことと、使える契約を分けて確認する

店主が料金画面からアプリへ戻ってきたとき、URLが開けたことだけを有料機能の利用許可にしません。戻りの画面は操作の経路であり、その時点でどの契約が有効かを確認する処理が必要です。現行のApp Pricingの統合・試験の説明では、Partner APIのactiveSubscriptionによって、アプリとストアの現在の契約を照会する方法が示されています。

契約照会は商品を読むAdmin APIとは別のPartner APIで、公式のactiveSubscriptionの要件には、公開アプリとPartner APIクライアントのManage apps権限が示されています。ストア側のread_productsを選べば契約も読める、とは考えないでください。必要な権限の確認と、実際に認証情報を作成・設定する作業を分けて計画します。

2026年4月28日以降のApp Pricingでは、以前の購読更新webhookが送られず、戻りURLにcharge_idが付く前提も使えません。以前のManaged Pricing向けに作った「webhookを待てば契約表が更新される」という説明を、新規アプリへそのまま移さないでください。イベント履歴の確認手段と、現在の利用権を判定する照会を区別して設計します。

照合するキーは、アプリを表すIDとストアを表すIDです。表示名やブラウザーから受け取った任意の文字列だけで対象を決めないようにします。照会時刻、現在のプラン、次回の変更予定、アプリ内で許可した機能を一緒に残すと、「店主は有料を選んだのに定期点検が動かない」という問い合わせを、画面の表示と契約の取得結果に分けて調べられます。

※表は横にスクロールできます。

既に有料プランを利用している店が、上位など別プランへの変更を承認しなかった場合も、拒否の操作だけで無料へ切り替えません。現在契約を再照会し、有効なプランの範囲で機能を判定します。初回に有料契約がない場合と、既存の有料契約を持つ店の変更拒否を、別の条件として扱ってください。

即時の変更と、将来の変更を別の列にする

プランの変更では、ボタンを押した瞬間から新しい機能へ切り替わると一律に考えません。公式が示す変更の適用条件を読み、現在有効な契約と、pendingUpdateに示される次の請求期間の変更を区別します。試用期間中はcurrentBillingCycleがnullでtrialEndsAtが設定される場合もあるため、請求周期が空という理由だけで未契約とは判定しません。アプリ画面では「現在利用中」と「変更予定」を別々に見せると、申し込んだプラン名だけが先に表示され、利用できる機能と食い違う問題を減らせます。

たとえば履歴を広く見られるプランから範囲の小さいプランへ変更する設計なら、いつ閲覧範囲が変わり、保存済み履歴をどう扱うかまで説明を用意します。料金変更の申込みだけをきっかけに履歴を即時削除すると、まだ利用できる期間の情報を失うかもしれません。契約に伴う機能制限と、データの保持・削除は、関連付けながらも別の処理として管理します。

凍結時の扱いも、独自にAPIの戻り値を決めつけないようにします。本稿は、凍結ならactiveSubscriptionが必ずnullになる、特定のstatus文字列が必ず返る、といった実装仕様を断定しません。利用するAPIの型と実際のテスト結果を確認し、凍結の通知や履歴から得た情報と、現在契約の照会結果をどう合わせるかを検証項目に残します。

照会できないときの待ち方を、店主へ説明する

通信エラーを「無料プランに変更された」と記録すると、料金を払っている店主の権利と表示が食い違います。反対に、過去に一度有料だった店を永久に有料扱いするのも適切ではありません。新しい有料ジョブを開始しない、再照合まで確認中と表示する、直近の判定を何のためにどの範囲で使うか決める、といった障害時の方針を設計します。具体的な待機時間は、機能の影響と運営体制に合わせて検証してください。

定期点検は、画面を開いたときだけ契約を見ればよいとは限りません。ジョブを登録するとき、実行するとき、長い処理を継続するときのどこで利用状態を再確認するかを決めます。また、遅れて届いた古い照会結果が新しい結果を上書きしないよう、取得時刻や処理の順序を扱います。これらはShopifyの契約とアプリ側の処理をつなぐ設計上の注意点であり、この架空アプリで実装・動作確認した成果ではありません。

審査担当者が再現できる導入・課金変更の試験を用意する

試験ストアの所属と、無償で試せる条件をそろえる

実装の確認には、アプリの検証に使えるdev storeを用意し、販売中の実店舗とは分けます。確認時点のApp Pricingでは、アプリと同じPartner組織に属するdev storeは、その店で利用可能なプランを無償で試せます。他のPartner組織のdev storeでは、無料プランと、無償試験を認める設定の有料プランが対象です。「dev storeなら他者の全プランも無料」とひとまとめにしないでください。

この無償試験では、実効価格が0ドルの契約が作られると公式は説明しています。契約が一切存在しない無料状態と、課金額0ドルで有料プランの動きを確認する状態は同じではありません。テスト票にはストアの種類、所属組織、選んだプラン、試験条件を書き、本番向けの料金を0に変更した結果と混同しないようにします。

本稿ではストア作成、アプリ導入、料金承認などを実施していません。以下は実装後に行うための試験設計です。実際の試験では、その環境で使える正規の方法を確認し、他人の店、顧客データ、本物の支払いを練習の材料にしないでください。試験を始める前に、どの設定を変更し、どこへ影響するかが説明できる状態にします。

一つの成功操作から、別の成功まで推測しない

インストール画面を通過したら、まずアプリが起動し、対象ストアの商品を読めるかを確認します。これは導入の試験です。その後に料金を選び、契約を照会し、定期点検を利用できるかを確かめる課金の試験を行います。最初から有料フラグを手で入れた状態だけで画面を確認すると、店主が承認を拒否したときの動きを見落とします。

※表は横にスクロールできます。

この表を使うときは、期待結果の隣に、実際の画面、サーバーの判定、照会時刻を記録します。「問題なし」という一語では、どのプランで、いつ、どの機能を確認したかが残りません。認証情報やAPIの応答全文を貼り付ける代わりに、必要な識別子と結果を安全な範囲で残し、見返せる証拠の保管場所を決めてください。

商品点検にも固有のケースを用意します。説明が空の一商品、空白だけの説明、動画はあるが画像がない商品、画像処理中の商品、メディアが複数ページに分かれる商品を分けます。途中取得の失敗が全件点検完了と表示されないか、再実行で同じ商品を重複集計しないかも確認します。料金の試験だけが通っても、点検結果自体が誤っていれば提供する価値を説明できません。

審査担当者が、自分の説明だけで操作できるようにする

公式のApp Store要件では、料金承認・拒否や再導入時の再承認に対応し、アップグレードやダウングレードのためにサポート連絡や再インストールを必須にしないことなどが示されています。アプリ内で変更の入口を見つけられるか、拒否した後に行き止まりにならないかを、開発者の知識を前提にせず見直します。

提出のためには、導入と主要機能を示すデモ動画を英語または英語字幕付きで用意する要件も確認します。外部ログインが必要な場合は、審査で使える有効なテスト用認証情報と、必要な機能へのアクセスを準備します。緊急連絡先も含め、提出時点の要件へ合わせてください。実店舗の認証情報を渡すことを、この準備の代わりにしてはいけません。

料金ページの静止画像だけでは、拒否後の画面や変更の適用時点をたどれません。「このストアで無料から始める→料金を選ぶ→現在契約を確認する→定期点検を使う」という流れを、前提と操作を省略せず説明します。審査担当者が使うデータが必要なら、説明不足の商品などのダミーデータを用意し、個人情報や無断利用の素材が混ざらないようにします。

最後に、未実施の試験、仕様が決まっていない機能、再現できなかった不具合を一覧にします。審査へ提出できる状態かは、それらが主要機能や請求へどう影響するかで判断します。「審査へ送った」「修正を求められた」「承認された」は別の段階です。自分で試したことだけを事実として残し、これから行う作業を合格実績へ変えないようにしましょう。

アンインストール後の停止と、データ削除要求を別に処理する

使わなくなった店のジョブを、削除要求待ちにしない

有料の定期点検は、店主が画面を開かなくても動く設計です。そのためアプリを削除された後に、アプリ内の予約ジョブだけが残る可能性を考える必要があります。アンインストールに関する通知を受け、対象店の接続状態を更新し、次の点検を止める処理を用意します。通知が常に瞬時に届くことを前提にせず、ジョブ実行時の状態確認も組み合わせます。

Shopifyのapp/uninstalledのトピックは、アプリのアンインストールに関係する通知です。一方、保存しているストア情報の削除を求めるshop/redactは、別の目的の通知です。後者を待つ間も点検を続けてよい、という意味にはなりません。まず新しい取得や定期処理を速やかに止め、保存済みデータの処理は、受け取った要求と保持条件に沿って進めるように分けます。

削除された時点で、実行中の点検がある場合も考えます。店の停止状態を確認した後に、古いジョブが結果を再保存すれば、せっかく消したデータが戻ることがあります。新規実行の停止、処理中ジョブの継続可否、再試行キュー、結果保存の可否を同じ店の状態へ結び付けます。アンインストール後の再導入は新たに利用状態を確認し、古いジョブを黙って再開させない設計にします。

個人データを取得しない機能でも、必須の要求受付を用意する

現行のShopifyのプライバシー対応要件は、App Storeで配布するアプリに、customers/data_request、customers/redact、shop/redactへの対応を求めています。個人データを機能で収集しないアプリも対象です。商品点検だけだから受付を実装しなくてよい、とは判断しないでください。

customers/data_requestは顧客データの要求、customers/redactは顧客データの削除、shop/redactはストアデータの削除に関係します。届いた要求が自分のアプリに保存物を持つ対象か調べる必要があります。該当データが存在しないときも、受付を無視するのではなく、対象を照合して該当なしだった記録を残す設計にします。要求の本文には情報が含まれ得るため、無目的な全文ログ保存も避けます。

公式は、不正なShopify HMACを持つ要求には401を返し、正規の要求を受領した場合は2xxで応答することを説明しています。受領の応答が成功したことと、対象データの確認や削除が終わったことは別です。正当性の確認、受付記録、非同期の処理、処理結果の記録を分けると、通信の再送と削除の二重実行も扱いやすくなります。

データベースを消した後にも残る場所を調べる

データの棚卸しは、点検結果を入れるデータベースだけでは終わりません。短期キャッシュに商品名、障害ログに要求の一部、バックアップに古い点検履歴、問い合わせ添付に店の画面が残っている場合があります。機能として顧客情報を読まなくても、運用中に受け取る情報までゼロになるわけではないことを、保存先の一覧で確認します。

※表は横にスクロールできます。

台帳には受付時刻、要求の種類、対象ストア、処理期限、担当、処理結果を持たせます。調査中のものを完了へ動かさず、対象が見つからない場合も、調べた保存先が分かる記録にします。何を消したか証明するために、消すべき内容そのものをもう一組保存してしまわないよう、証拠として必要な項目を選んでください。

バックアップは特に、現在のデータベースを消しただけでは説明が足りない場所です。復旧で古い状態へ戻すときに、既に削除要求へ対応した店の情報を再び有効にしない仕組みを考えます。具体的な保存期間や削除方式は利用サービスと適用される義務によって異なるため、この記事の台帳を法令に万能なひな形として使わず、自分の構成へ合わせて確認します。

この章の試験では、正規要求、不正なHMAC、同じ要求の再送、途中失敗、アンインストール後に遅れて動いたジョブを別々に扱います。正規要求の200応答だけを見て削除試験が通ったとしないことが重要です。実際の保存先で対象がどうなったかを確かめ、残存や復活があれば原因を直してから完了と記録します。

API更新とサポートを引き受けられる費用・体制を確かめる

APIの指定版と、実際に応答した版を記録する

アプリを公開した後も、Shopifyの変更を追う仕事は続きます。APIバージョニングの公式案内では、原則として四半期ごとに版が出され、安定版は最低12か月サポートされます。確認時点のAdmin GraphQLの最新安定版は2026-10ですが、記事に最新と書かれた版を永久に使えるわけではありません。開発時の版、移行先、確認した日を記録します。

使えなくなった古い版を指定すると、Shopifyは利用可能な最古の安定版へ繰り上げる仕組みを説明しています。そのため、リクエストURLの版文字列が変わっていないことだけを、同じ挙動の証拠にしないようにします。X-Shopify-API-Versionなど、実際に応答した版を確認する情報を使い、指定版と応答版に差があった場合に調査できるようにします。

商品読取りのAdmin GraphQL、契約照会のPartner API、webhook、利用ライブラリは、すべてが同一の版と更新期限とは限りません。たとえば商品の取得クエリだけが新しい版で動いても、料金の照会や要求受付が未確認ならアプリ全体の移行完了とはいえません。依存先ごとに確認対象を分け、移行日にまとめて気付く状態を避けます。

※表は横にスクロールできます。

売上の表示から、収益分配と運営実費を分ける

Shopify App Storeの収入を考えるときは、収益分配、決済処理料、税や地域に関わる費用、アプリを動かす費用を別にします。確認時点の公式の収益分配条件では、標準条件を満たす開発者について、2025年1月1日以降の累計アプリ総収入の最初の100万米ドルまで収益分配0％、超過分15％とされています。毎年100万米ドルの枠が復活する説明ではありません。

この計算は複数のアプリや関連開発者アカウントをまとめて扱い、返金を差し引いた後の利益へ割合を掛ける意味でもありません。一定の大規模事業者には別の適格条件があります。また、2.9％の処理料、適用される税、対象地域の追加費用は収益分配と別です。「0％」という部分だけを取り出し、アプリ販売の費用がすべて無料になると考えないでください。最新条件と自分の適用区分を公式で確認します。

開発側の実費には、Webサーバー、定期ジョブ、データベース、監視、バックアップ、通知などがあります。この商品点検アプリなら、点検の回数だけでなく、一回で読む商品数、履歴の保持量、失敗後の再実行が費用に関係します。売上だけを毎月記録するより、点検の利用量と実際の請求明細を対応させた方が、どの機能の負担が増えたかを把握できます。

定額料金にする場合も、利用が集中したときにどの範囲まで提供するかを説明します。従量制にするなら、何を一回と数えるか、失敗した点検をどう扱うか、店主が利用量を確認できるかといった設計が増えます。どちらが必ず高収益かを決めるのではなく、計測と説明を含めて運営できる方式を選びます。単発の買い切り販売でも、継続してAPIへ接続する製品なら、その後の保守費は残ります。

問い合わせを、料金・データ・機能に分けて調べられるようにする

「点検できない」という問い合わせには、権限不足、取得失敗、契約確認中、処理の滞留など複数の原因があり得ます。店主に秘密情報や大量の商品データを最初から送ってもらうのではなく、発生時刻、画面の表示、対象となる操作など、最小限の情報で切り分けられる窓口を作ります。サポート記録も保存データになるため、前章の台帳に含めます。

障害が起きたときは、影響する店と機能、確認できた最終時刻、現在の対応状況を整理します。課金の照合が止まっているのに商品点検だけ再試行し続けると、料金と機能の不一致を広げる場合があります。機能別の停止条件と再開条件を決め、未確認の状態を「復旧済み」と案内しないようにします。実際に確認した範囲を伝えることが、問い合わせ対応の土台になります。

一人で開発する場合も、自分が長く対応できないときの連絡先、障害情報を受け取る方法、重要な設定を調べる場所を整理しておきます。何時でも必ず即対応できると約束する必要はありませんが、公開した対応条件を守れるかは確認が必要です。公開後の支援を引き受けられない機能は、初版の範囲や提供時期を見直してください。

最初の販売判断へ戻り、未確認を残したまま約束しない

ここまで作った六つの記録を並べると、作れた画面と、まだ決めていない条件を見分けられます。配布先が確定しているか、商品以外の不要な権限を求めていないか、契約状態に応じて機能が切り替わるか、審査担当者が再現できるか、停止と削除がつながるか、更新と問い合わせを続けられるかを確認します。

本稿の架空アプリは、これらを考えるための設計例です。実装、環境の用意、料金プランの設定、試験、審査はこれから行う工程として残っています。実際に販売へ進むときは、未実施欄を試験結果へ置き換え、問題の影響を評価してから判断してください。機能を足すたびに権限、保存、契約、試験、削除、保守への影響も見直すことで、小さな商品点検アプリを継続して提供する準備が整っていきます。