Google Play Developer APIでストアの掲載情報を更新する
edits.insert)、その中で掲載テキストや画像を変更し(edits.listings.update、edits.images.upload)、最後にedits.commitで検証・公開するか、edits.abandonで破棄します。commitするまで何も公開されません。認証にはGoogle Cloudのサービスアカウントを使いますが、ほぼ全員がつまずくポイントがひとつあります。サービスアカウントはGoogle Cloud IAMでロールを与えるだけでなく、Play Consoleにも招待する必要があるという点です。Google Play Developer API(正式名称はAndroid Publisher API)を使うと、Play Consoleを開かずにストア掲載情報(タイトル、説明文、スクリーンショット、フィーチャーグラフィック)を変更できます。CMSからローカライズ済みのコピーを送り込みたい場合や、ビルドパイプラインからスクリーンショットを同期したい場合、あるいは何十もの言語の掲載情報を一斉に更新したい場合に役立ちます。ここでは、リファレンスドキュメントに埋もれがちな部分も含めて、正しい手順をエンドツーエンドで説明します。
editはライブへの書き込みではなくトランザクション
一番苦労を減らしてくれる考え方はこうです。ライブの掲載情報を直接編集することは決してありません。まずeditを開きます。これはアプリの現在のデプロイ状態(掲載情報、画像、トラック、すべて)をコピーした非公開のステージング領域です。変更はすべてそのコピーに対して行います。そして、まとめてcommitするか、abandonして何もなかったことにするかのどちらかです。
Google自身も明確にこう記しています。「editの中で行った変更は、editがcommitされるまでライブになりません」。commitすると、検証エラーがなければeditの中のすべての変更が一斉にライブになり、現在の状態を置き換えます。検証に失敗すればAPIはエラーを返し、ライブの掲載情報は無傷のままです。つまりライフサイクルは、正確には次の4つの動作だけです。
edits.insert— editを作成し、editIdを受け取る。- modify — 言語ごとのテキストには
edits.listings.update、スクリーンショットやグラフィックにはedits.images.upload/deleteallを使う。 edits.commit— すべてを検証したうえで、一括で公開する。edits.abandon— 下書きを破棄し、ライブの掲載情報は変わらない。
設計上考慮すべき厳格な制約がひとつあります。1つのアカウントが同時に開けるeditは1つだけで、誰かがeditをcommitしたり、Play ConsoleのUIからアプリを編集したりすると、そのアプリの他のすべての開いているeditは無効になります。editは短命なものとして扱いましょう。開いたら、書き込み、すぐにcommitする。人がConsoleをクリックし続けている間、何時間も開いたままにしないことです。
認証 — サービスアカウントと、みんなが忘れる招待
自動更新の仕組みには、ユーザーOAuthではなくサービスアカウントを使います。関わってくるシステムは2つあり、実際に別々のものです。
- Google Cloud。 サービスアカウントを作成し、プロジェクトでGoogle Play Android Developer APIを有効にして、JSONキーをダウンロードします。必要なスコープは
https://www.googleapis.com/auth/androidpublisherだけです。 - Play Console。 ユーザーと権限に移動し、新しいユーザーを招待をクリックして、サービスアカウントのメールアドレス(
...@...iam.gserviceaccount.com形式)を貼り付け、そのアプリへのアクセス権を付与します。これを済ませて初めて、そのキーが掲載情報を触れるようになります。
もうひとつ前提条件があります。アプリはすでに存在し、少なくとも1回はリリース済み(Consoleを通じて少なくとも1つのAPK/AABがアップロード済み)である必要があります。まったく新規のアプリをAPIだけで立ち上げることはできません。
4つの呼び出し(RESTの場合)
掲載テキストを更新する
edits.listings.updateはPUT — つまりその言語の掲載情報を完全に置き換える呼び出しです。送った内容がそのまま掲載情報になり、送らなかったフィールドは保持されず消去されます。ですから、短い説明だけを変えたい場合でも、タイトルと詳細な説明も一緒に送らなければ、それらが消えてしまいます。本当に部分的な変更をしたい場合は、指定したフィールドだけをマージする別のedits.listings.patchがあります。ほとんどのパイプラインでは、完全なPUTの方がすっきりしています。どうせソース・オブ・トゥルースから掲載情報全体をレンダリングしているので、丸ごと置き換える方が理にかなっています。
3つのテキストフィールドとその上限は次のとおりです。titleは最大30文字、shortDescriptionは最大80文字、fullDescriptionは最大4000文字。掲載情報リソースは言語ごとに1つで、URL内のBCP-47言語タグ(en-US、de-DE、ja-JPなど)で指定します。10言語を更新するなら、同じeditの中でlistings.updateを10回呼び出し、その後1回のcommitでまとめて公開します。
スクリーンショットとフィーチャーグラフィックをアップロードする
画像は言語ごと、画像タイプごとに紐づけられます。画像タイプは列挙型で、掲載情報の各アセット枠は次のいずれかの値に対応します。
phoneScreenshots、sevenInchScreenshots、tenInchScreenshots— スマートフォンとタブレットのスクリーンショットセット。tvScreenshots、wearScreenshots— Android TVとWear OS。featureGraphic— 掲載情報の上部に表示される1024×500のバナー。icon、tvBanner— アプリアイコンとTVバナー。
edits.images.uploadは、指定した言語とタイプの画像を1枚editに追加します。「配列全体を差し替える」呼び出しは存在しないため、スクリーンショットを置き換える確実な方法は、まずその言語・画像タイプに対してedits.images.deleteallを実行し、その後表示したい順序で新しいセットをアップロードすることです。edits.images.listはeditに現在含まれる内容を読み取り、edits.images.deleteはidを指定して1枚だけ削除できます。すべてcommitするまではeditの中にとどまります。
commitとは — そして「ライブになる」とはどういうことか
見落とされがちで、正確に理解しておく価値のある点がいくつかあります。
- 新しいビルドは不要。 掲載情報だけのeditをcommitするのに、新しいAPK/AABは必要ありません。テキストと画像はメタデータであり、既存のリリースに対して何度でも更新できます(アプリには過去のリリースが1回あれば十分です)。
- commitは検証してから公開する。 スクリーンショットの寸法が違っていたり、フィールドが長すぎたりすると、commitは失敗し、ライブの掲載情報は決して変わりません。修正して再度commitします。
- 即座には反映されない。 commitが成功した後、変更が反映されるまで数時間かかることがあります。これはPlay Consoleで手動編集した場合と同じです。commitで200が返ってきても、「すでにユーザーに見えている」とは考えないでください。
- abandonは無害。 ドライランの結果がおかしいと感じたら、
edits.abandonで下書きを破棄でき、ライブの掲載情報には一切影響しません。パイプラインをリスクなく検証するのに便利です。
ノーコードの道 — デザイン、翻訳、公開
上記のAPIは、割ける開発時間があり、同期元となるソース・オブ・トゥルースがある場合には正しい選択肢です。ただし、それがアセットを作るわけではありません。スクリーンショットのデザイン、タイトルと2種類の説明文の作成は、言語ごとに自分で用意する必要があります。APIは渡されたものをそのまま送るだけです。
その部分を引き受けるのがMokbiです。ブラウザ上でスクリーンショットをデザインし、タイトル・短い説明・詳細な説明を一緒に作成し、掲載情報全体を50言語にまとめて翻訳できます。これにより、先ほどの10回のlistings.update呼び出しには、仮のテキストではなく本物のローカライズされたコピーを渡せます。
そして公開そのものも、Mokbiが行います。Google Playに関しては、まさにこの流れ(edits.insert → listings.update → 画像アップロード → commit)を裏側で実行するので、上記のコードを一行も書かずに、ローカライズされた掲載情報とアセットがライブになります。App Storeについては、App Store Connect上でバージョンを準備し、提出できる状態にして待機させます。Appleでは最終的なSubmitを押して審査を通過するのはあなた自身である必要があるためです。スクリーンショットとフィーチャーグラフィックのデザイン、掲載情報の作成、50言語への翻訳、そして公開までが、ひと続きの作業になります。