0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【第5回補足】スクリーンショットを撮って、ストアに届けるまで――9月の画像更新と10月の再撮影・登録

0
Last updated at Posted at 2026-11-05

連載ストックリスト:Android版「見開きPDFビューア」開発記録

この記事は、ChatGPTと壁打ちしながら、Android Studio内のGeminiと、別に保存されたCodexの会話、Git履歴、保存画像と撮影記録を調べて作成しました。初回ストア登録画像の特定は、復元画像と筆者自身の確認を根拠に記載します。会話の引用は当時の記録であり、AIの完了報告だけで実行や公開を確認済みとはしていません。日付は2026年、日本時間です。

Android用「見開きPDFビューア」をストアで紹介するには、アイコンやフィーチャーグラフィックに加え、実際の画面を見せるスクリーンショットも必要でした。最初に用意した画像と、機能や言語が増えてから撮り直した画像では、作業の規模も確かめ方も変わっています。

この補足では、9月の初期画像の準備、クローズドテスト期間中の端末別画像の追加・更新、10月の再撮影・ストア登録を振り返ります。撮影したこと、正しい画面かを確かめたこと、掲載欄へ保存したことは、それぞれ別の作業でした。

1 初期の画像を撮り、ストア登録に使う

9月:まずREADMEに載せる画面を撮る

クローズドテストを始める前に、Play Consoleのストア情報の登録を進めると、スマートフォン向けのスクリーンショットを掲載する必要があることを確認しました。また、スクリーンショットを用意するならREADMEにも掲載するのがよいだろうと考えました。

Geminiのチャット履歴に、9月4日の撮影依頼が残っていました。最初からPlay Console用と指定した依頼ではなく、日英のREADMEへ画像を載せるためのものでした。

筆者のプロンプト(全文)

各言語のスクリーンショットを撮影して、README.md/README_en.mdのスクリーンショットに表示するよう修正してください。

続けて、権利に問題のないPDFを用意することと、横画面の見開きを見せることを依頼しました。その日の夜には、撮影する仮想端末とPDFを具体的に指定しています。

筆者のプロンプト(全文)

Pixel 10でスクリーンショットを撮影し直して。使うPDFファイルは、testdata/TestLightNovel.pdfを指定して。

Geminiの回答(抜粋)

testdata/TestLightNovel.pdf を使用し、Pixel 10 エミュレーターにて全てのスクリーンショットを撮影し直しました。

保存された操作ログには、PDFをエミュレーターへ転送し、画面を操作して画像を保存した記録があります。日本語の見開き画面は9月4日21時56分、検索・設定画面の差し替えは翌5日未明の記録と対応します。一部は撮影用にアプリのコードを一時的に変更して表示状態を用意しており、すべてを通常の利用者と同じ操作経路で撮ったとはいえません。

筆者のプロンプト(全文)

スクリーンショットの一部を差し替えてください。設定画面は端末を縦長の向きで撮影してください。検索画面は、端末を横長の向きのまま、検索ワードを'灯'にして、検索結果が表示された状態にしてください。

9月5日6時56分の最初のコミット(a5f229a)には、ホーム・見開き・検索・設定の4画面が、日本語と英語で計8枚残っています。READMEもこの8枚を参照していました。図1に見開き画面、図2に検索画面の保存画像を示します。

第5回補足 図1

図1 初期コミットに残る日本語の見開き画面。9月11日以前にストア登録した8枚の一つであることは、筆者自身の確認に基づきます。

第5回補足 図2

図2 同じコミットの検索画面。検索語「灯」、検索結果とハイライトが表示されています。

9月:登録した画像を、復元ファイルと照合する

手動でPlay Consoleにスクリーンショットを登録しようとしたときに、スクリーンショットを保存したフォルダがわからなかったので、9月6日には、登録するファイルについてGeminiに尋ねています。

筆者のプロンプト(全文)

スクリーンショットにはどのファイルを登録すればいいですか?

Geminiは、viewer、search、home、settingsの各画像について、日本語の掲載には末尾が_ja.png、英語の掲載には_en.pngのファイルを使うよう案内していました。これは当時の回答であり、現在のPlay Consoleの要件を検証した説明ではありません。

私は、この8枚を9月11日以前にPlay Consoleのストア情報へ登録しました。登録操作の記録は見つかっていませんが、復元したフォルダの画像が登録に使ったものだったことは、私自身で確認しています。

復元した8枚は、9月11日のコミット(37401de)および9月5日の初期コミットの画像とすべて一致します。登録画像の特定は筆者の確認、ファイルの一致はGitとの照合という、別々の根拠で確かめました。正確な登録日時や端末別の登録枠は未確認です。

2 クローズドテスト中に、端末別の画像を更新する

9月17日:プラットフォーム毎に5画面ずつ用意する

クローズドテストを進めて時間に余裕ができると、Play Consoleのストア情報にプラットフォーム別のスクリーンショットを登録する方がよいことに気づきました。私の記憶では、このとき端末の種類ごとのスクリーンショット撮影をGeminiに依頼しました。この時点のChromebook用画像は、実機で私が手動撮影したものです。

9月18日時点の復元フォルダには、初期8枚に加えて端末別の画像30枚がありました。スマートフォン・タブレット・Chromebookの3種類に、見開き・検索・パスワード入力・設定・応援の5画面を、日英それぞれで用意した構成です。追加の30枚は、9月17日21時49分のコミット(6afe832)に保存されていました。

全38枚はそのコミットの画像と一致し、翌18日にはassets/screenshots/へ移した履歴も確認できます。初期画像8枚を残しながら、端末の種類に合わせた素材を増やしていたことが分かりました。

ただし、画像があることと、紹介に適した画面を撮れていることは別です。スマートフォンとタブレットの応援画面には「Mock」と購入失敗のメッセージが写っていました。また、検索用の画像は検索欄が未入力で、検索結果を見せる状態にはなっていませんでした。

図3に、端末別30枚の構成と、保存画像に残っていた問題をまとめました。検索欄の未入力と応援画面の不要な表示は、該当する画像を赤枠と赤い太字で示しています。初期8枚を含む全38枚の保存確認と、ストアに掲載できる内容かどうかの確認は別です。

第5回補足 図3

図3 9月17日の端末別セットから、日本語の保存画像15枚を配置しました。各端末には英語版5枚もあり、日英で計30枚です。画像はGit 6afe832の保存ファイルを縮小したもので、9月27日の更新前の状態です。Geminiへの依頼は筆者の記憶、Chromebookの手動撮影は筆者自身の説明に基づきます。その他の画像の撮影担当・操作経路と、この30枚のPlay Consoleへの登録は、保存資料では未特定です。

9月27日:マンガで撮り直したら、古い画像が残る

サンプルPDFマンガを使ったスクリーンショットの方が、アピールしやすいと考えました。そこで、スクリーンショットを撮り直すことにしました。このときもChromebook用画像は実機で私が手動撮影しました。撮影前に画面下のタスクバーに表示されるアプリを減らしていました。

9月27日21時31分のコミット(62916b9)では、端末別30枚のうち22枚が更新されています。内訳はスマートフォン8枚、タブレット4枚、Chromebook10枚です。残る8枚は17日の画像と一致していました。

見開き・検索の画面は、それまでの日本語の小説から、日英それぞれのサンプルマンガへ変わっています。検索画像には、日本語では「放課後」、英語では「school」の入力と、結果表示・ハイライトが写っていました。9月17日の未入力の画像から、検索機能を見せる画像へ変わっています。マンガ自体の制作過程は、独立した記事で扱います。

応援画面にも違いがありました。スマートフォンとChromebookにはキャラクターのバッジ画像が写る一方、タブレット用は以前のメダル表示の画像のままです。同じセットの中でも、撮り直した画面と再利用した画面が混在していました。応援画面の「Mock」・購入失敗表示や、タブレット英語版の検索画面への入力ツールの写り込みも残っています。

翌28日には、store_listing/screenshots/以下へ端末別に整理し、5画面のファイル名へ連番を付けた構成になっています。10月1日時点の復元画像30枚は、同日のGitの画像とすべて一致しました。この時点のセットは、新しい画像22枚と、以前の画像8枚を合わせたものだったのです。

9月17日・27日のChromebook用画像は、前述のとおり私が手動で撮影しました。一方、その他の画像の撮影担当・操作経路と、端末別画像のどれをPlay Consoleへ登録したかは、今回のファイルとGitの照合では特定できていません。撮影についての私の説明と、保存資料から確認できる範囲を分けて扱います。

図4に、端末別30枚の更新・再利用の内訳と、画像に残っていた問題をまとめました。再利用自体は問題ではなく、更新した画像も含めて掲載に適した表示かどうかを確かめる必要がありました。

第5回補足 図4

図4 9月27日の日本語の保存画像15枚を一覧にし、右にタブレット英語版の検索画像を追加しました。青は更新、灰は9月17日と同一の再利用を示し、再利用自体は問題ではありません。問題のある応援画面と英語版検索画像は、赤枠・赤い太字で該当箇所を示しました。日英では更新22枚・再利用8枚。Chromebook用は筆者が実機で手動撮影しました。出典はGit 62916b9、再利用の判定は6afe832とのバイト一致です。

3 最新仕様・端末・言語に合わせて撮り直す

10月:最新仕様で撮り直そうとして、失敗を繰り返す

10月には、v2.0.0に向けた改善と並行して、スクリーンショットを撮り直していました。10月10〜11日のGeminiとの会話には、私からの具体的な指摘が残っています。

筆者のプロンプト(全文)

1_smartphone_screenshot_view_ja.pngが失敗しています。黒画面、縦長です。

別の画像では、PDF本文ではなく「PDFを開く」ボタンの画面が写っていたり、英語版のはずがシステム言語は日本語だったりしました。私は、こうした失敗条件を検査へ追加し、撮り直すよう依頼しています。その後も、閲覧・検索画像の下部に「The PDF cannot be opened or is damaged.」というエラーが表示されていると指摘しました。

Geminiの回答(抜粋)

ご指摘いただいた 「The PDF cannot be opened or is damaged」エラー の発生原因を究明し、対策をQA検査条件に追加した上で、全10枚のスクリーンショットを完璧に再撮影・検証いたしました。

これは当時の回答です。「完璧に」と報告されたことを、そのまま成果物の正しさとして扱うことはできませんでした。12日朝から昼の会話でも、同じ画像と判定されて処理が止まる問題を繰り返し相談しています。Geminiは、ダウンロード後のOpen、言語に依存しない操作対象の指定、重複したテスト用タグ、描画待ち時間などを修正したと回答していました。

後で保存コードを照合すると、旧テストには、検索後も「PDFが開かれている」ことを待つ処理や、設定画面への移動失敗を無視して撮影へ進む構造がありました。PDFを開いたことと、目的のページや検索結果が描画されたことは違います。ここでは確認できた検査条件の不足を扱い、Geminiが回答ごとに挙げた原因をすべて確定した根本原因とはしません。

図5に、撮影の準備中に保存されたホーム画面の例と、10月10〜12日に指摘・修正を繰り返した流れをまとめました。画像はGeminiのUI確認ツールの応答に残るもので、指摘した掲載用ファイルそのものとの同一性は未確認です。黒画面・言語違い・PDFエラーについては、該当時点の原画像を特定できていないため、会話の記録として示しています。

第5回補足 図5

図5 PDF画面を確認する操作に対して、保存画像とUI情報はホーム画面を示していました(左)。右は筆者の指摘とGeminiの修正・完了回答の流れです。完了報告や原因候補を、撮影の成功や根本原因の確定とは扱いません。

10月12日夜:撮影条件を整理し、ChatGPTで撮影する

私の記憶では、Geminiによる自動撮影がうまくいかないので、依頼先をChatGPTに変更しました。12日20時57分には、ChatGPT側の作業として確認したCodexの保存履歴に、次の依頼があります。対象端末、言語、PDF、失敗時の条件をまとめて指定していました。

筆者のプロンプト(全文)

アプリの最新の仕様に対応した、Play Consoleに登録するスクリーンショットの案を考えてください。

使う仮想デバイスは、Smartphone 6.3 / Tablet 7 / Tablet 10

デバイスのシステムの言語は、次の通りです。

言語 システム上の表示名

日本語 日本語

英語 (US) English

韓国語 한국어

中国語 (簡体字) 中文 (简体)

言語の注意点: 撮影の開始時、再開時にデバイスのシステムの言語を確認し、異なる場合は設定および再起動してください

デバイスの向き: 撮影の開始時、再開時に確認してください

撮影用ファイルの元の場所: testdata/tameshibu_episode1_2_[言語].pdf

言語は、ja, en, ko, zh_cn です。

撮影用PDFが元の場所に存在しない場合は、致命的エラーとして処理を中断してください。

撮影開始前にデバイスにファイルが転送済みか確認してください。

スクリーンショットのファイル保存場所: store_listing/screenshots/[デバイスの種類]/

撮影した画像が黒画面、白画面、エラー画面、ロック画面、ホーム画面、Signin画面などの場合は失敗なので、再撮影する。

検索するキーワードをページ6のセリフに含まれる言葉に変更してください。'ひと息マップ'など

続けて、自動撮影の実現方法を検討し、実装を進めるよう依頼しました。回答では、端末の管理、アプリ画面の準備、画面の保存・検査を組み合わせる構成が提案されています。

Codexの回答(抜粋)

自動撮影を実装し、3デバイス × 4言語 × 6枚=72枚の撮影・検品を完了しました。

22時5分のこの回答には、Play Consoleへのアップロードは未実施とも明記されています。撮影結果のレポートと実装には、対象端末の明示、言語・向きの確認、アプリが実際に読むPDFの照合、描画や検索結果を待つ処理、画像検査、撮影条件の記録が残っています。

Geminiへの修正依頼の後、Codexの保存履歴で撮影を進めた流れは確認できます。ただし、依頼文に切り替え理由は明記されていないため、その理由は私の記憶として記載しています。また、保存履歴から当時の利用画面をすべてChatGPTのWorkモードと断定することはできません。

図6に、10月12日夜に指定した撮影条件、自動化の相談から実装へ進む順番、撮影・検品の完了報告をまとめました。要求した条件と、レポート・実装で確認できる仕組みを分けて示しています。

第5回補足 図6

図6 撮影条件を整理してCodexへ渡し、72枚の撮影・検品へ進めた流れ。時刻は日本時間です。この時点ではPlay Consoleへのアップロードは未実施で、後日の登録作業とは区別します。

10月15〜16日:撮影対象と版を揃え直す

一度撮れれば終わりではありませんでした。目次を含めた画面構成、Chromebook向けの撮影、追加言語のPDFなど、対象が増えるたびに撮影と検品の条件も変わりました。

9月の実機Chromebookでの手動撮影とは異なり、10月はChromebook向けにも仮想端末を使いました。私の記憶では、仮想デバイスで撮影した画像をPlay Consoleのストア情報に使えるかChatGPTに相談し、使えるとの回答を受けて、Chromebook向けの撮影も依頼に追加しました。これは当時の相談についての記憶であり、現在のストア要件を検証した説明ではありません。

以下のcodeはversionCodeで、画面に表示するバージョン名とは別のビルド番号です。

時期 対象版 登録用スクリーンショットの枚数
10月12日 v2.0.0/code 29 3種類のAVD × 4言語 × 6画面=72枚
10月15日 v2.0.0/code 31 目次・Desktop AVDを追加。4言語で108枚
10月16日・追加撮影 既存31/追加32 繁体字・ドイツ語・フランス語81枚を追加し、計189枚。版は混在
10月16日夜・全体更新 v2.0.0/code 33 14言語・4種類のAVDで378枚へ統一

この表は、各時点でPlay Consoleへの登録用に用意したスクリーンショットの枚数です。検品用の一覧画像や撮影条件を記録したJSONは含みません。72枚・108枚・189枚・378枚をすべて足した累計ではなく、実際に登録・公開できた枚数とも区別します。

15日は、昼の実装・試験で16枚を確認した後、夜に本撮影を依頼しています。

筆者のプロンプト(全文)

本撮影作業をしてください。

Codexの回答(抜粋)

本撮影が完了しました。全4端末・4言語、計108枚が揃い、自動検査・一覧画像と検索原本の目視確認を終えています。

108枚の内訳は、スマートフォンと7インチ・10インチの各AVDが28枚ずつ、Desktop AVDが24枚です。試験で作った16枚は条件を照合して再利用し、残り92枚を新たに撮影した記録があります。Desktop AVDはChromebook向けのAndroid検証環境として使っており、実物のChromebookで撮影したという意味ではありません。

16日の追加撮影では、既存108枚はcode 31、追加81枚はcode 32でした。さらにPDFの差し替えや言語追加が進み、保存画像と、現在の撮影用PDF・アプリ版との対応を揃え直す必要が出ています。PDFの正本と配布用コピーを照合し、最終的にはcode 33で14言語・378枚のセットを作成しました。

当時の記録には、自動検査と目視確認を完了した旨が残っています。今回の追加確認では、現在保存されている378組のPNGとJSONの版・画像ハッシュ・寸法がすべて一致しました。これは保存画像と記録の整合性を確認した結果であり、今回378枚を改めて目視検品したり、最新版で撮影し直したりしたという意味ではありません。初回72枚やcode 31・32の成果物を、現在の378枚で代用して説明することもしません。

検品用の一覧画像も残っています。確認したscreenshot_reviewの60枚は、4端末×14言語の56枚と、端末ごとに全言語をまとめた4枚です。日本語の画面にはPDFの「Second edition, 2026-10-08」という情報があり、イタリア語版も含まれています。全60枚がGitの10月17日時点の一覧と一致するため、ここでは10月の撮影セットを確認する資料として扱います。

4 撮影した画像を、ストアの掲載欄へ登録する

10月17日:アップロードした画像を、掲載欄へ保存する

画像が揃うと、次は登録作業を減らしたくなりました。10月17日5時28分、ChatGPT側の作業として確認したCodexの保存履歴には、次の相談が残っています。Geminiへの相談ではなく、その後の登録作業もCodexとのやり取りとして確認できます。ただし、保存履歴だけでは当時の利用画面までは特定できません。

筆者のプロンプト(全文)

撮影したスクリーンショットを自動的にPlay Consoleに登録することはできますか?

当時の実装では、スマートフォン・7インチ・10インチ向けの294枚をAPIで未確定編集へ登録し、Chromebook向け84枚はブラウザから登録する構成になりました。認証設定に加え、APIの有効化、不足する掲載言語の追加、端末のロケールと掲載側の言語コードの違いにも対応しています。ここでの内訳は当時の実装に基づくもので、現在のAPI仕様を説明するものではありません。

作業フォルダの編集状態ファイルにはstaged-uncommittedと残っています。未確定編集へ画像を送れたことだけで、公開ストアに反映したとはいえません。

ブラウザでの登録にも別の落とし穴がありました。画像をアップロードしてアセットライブラリへ入れる操作と、そのカードを選んで掲載欄へ反映する操作が分かれていました。さらに保存と再読み込みの確認が必要です。保存したつもりでも別の言語へ戻っていたり、画像が残っていなかったりして、やり直しています。

イタリア語の登録では、私も画面を確認して次のように伝えました。

筆者のプロンプト(全文)

ブラウザで確認すると、スマートフォン用画像が登録されていましたが、保存されていなかったので、保存操作をしました。タブレット用画像は未登録でした。確認してから続けてください。

Codexの回答(抜粋)

イタリア語(it-IT)のスクリーンショットをPlay Consoleの下書きに登録し、再読み込み後も残っていることを確認しました。

この回答は、スマートフォン・7インチ・10インチへ各7枚を登録した結果で、審査への送信は行っていないと明記されています。その後も、複数言語の未登録画像を追加し、下書き保存後に再読み込みして確認した回答が続きます。

ここで確認できるのは、その時点の下書き登録と保存確認です。対象378枚すべての一般公開を確認した記録としては扱いません。アプリのv2.0.0が10月19日に公開されたことと、個々の画像がいつ公開ストアへ反映されたかは、分けて確認する必要があります。撮影レポートの「登録は未実施」も、撮影終了時点の記載であり、その後の登録作業まで行っていないことを意味するわけではありません。

図7に、画像をアップロードしてから掲載欄へ選び、下書き保存と再読み込みで確かめるまでの手順をまとめました。当時のAPI登録とブラウザ登録の分担、保存をやり直したイタリア語の例も示しています。

第5回補足 図7

図7 10月17日の登録・保存確認の流れ。Chromebook向け84枚はDesktop AVDで撮影した画像で、9月の実機での手動撮影分とは別です。アセットライブラリへの追加、掲載欄への反映、保存、再読み込みは別の操作でした。下書きの登録確認を、審査への送信や全画像の一般公開と同一視しない模式図です。

どこまで分かっているかを残す

根拠の種類 今回の記事での扱い
会話・実行ログ・保存ファイル 9月の初期8枚・端末別30枚の追加と更新、10月の撮影・検品・下書き登録を説明する
筆者自身の確認 初期8枚を9月11日以前にPlay Consoleへ登録したこと、9月17・27日のChromebook用画像を手動撮影したことは筆者の確認・説明に基づく
未確認 初期8枚の正確な登録日時・端末枠、9月17・27日のChromebook以外の画像の撮影担当・操作経路、端末別画像の登録状況は未確認
筆者の記憶 端末別撮影をGeminiに依頼した経緯と、10月12日に相談先を変更した理由は、筆者の記憶として扱う
未確認 全画像の審査・一般公開への反映時点や、後の全アプリ版への適合までは保証しない

画像が保存されていることと、目的の画面が写っていること。画像をアップロードしたことと、掲載欄へ保存されていること。作業を進めるたびに、それぞれの違いを確かめる必要がありました。

その後の操作動画では、正しい状態の画面を用意するだけでなく、そこへ至る操作の途中も見せる必要があります。10月下旬の動画制作と、静止画・動画の実装を比較して整理した教訓は、第7〜10回で扱います。

以下の関連リンクは編集用Googleドキュメントです。第7〜10回は未公開です。公開済みの記事は冒頭の連載ストックリストから参照できます。

関連する本編:【第5回】PDFビューアの顔と公開用画像を作る――アイコン、フィーチャーグラフィック、チップ画像の制作

関連する第7回:Geminiで操作動画を撮ろうとして、何が映らなかったか

関連する第9回:教材を渡しても、撮影結果を確認できなかった

0
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?