連載ストックリスト：Android版「見開きPDFビューア」開発記録
この記事は、ChatGPTとの壁打ちと、Android Studioに保存されたGeminiの会話履歴、Gitの変更履歴・ソースコード、手元に保存された実行ログの調査をもとに作成しました。
初稿について
この記事は、本編第4回から実機検証・記録の自動化を分けた補足記事の初稿です。公開後も説明や構成を推敲し、同じ記事を更新します。AIの完了報告、実装、個別ログから確認できた結果を分けて記述しています。
端末を増やすと、実際に試せる条件が増えます。同時に、各端末でどの版を動かし、何を確認したかを残す作業も増えていきました。この補足記事では、ビューアの2026年10月16〜17日の作業を中心に、実行・ログ保存・確認一覧の更新をまとめていった経緯を振り返ります。プロンプトは原文全文、回答は抜粋、日付・時刻は日本時間です。
図1 実機を増やして検証条件を広げると、端末ごとの実行・記録も増えます。USB接続した端末で一連の処理をまとめ、一覧更新の負担を減らそうとしました。全端末の一括実行やGitへの自動プッシュを示す図ではありません。
連載一覧
Android用「見開きPDFビューア」を、AIと開発した記録です。第1〜4回は主に時系列、第5〜6回は並行して進めた制作・配布をテーマ別に振り返ります。日付は2026年です。本編全6回に、第4回の補足記事を加えた構成です。
| 回 | 内容 | Qiita |
|---|---|---|
| 第1回 | iOS版からAndroid版へ：移植と最初の2日間 | 第1回を読む |
| 第2回 | クローズドテスト中の品質改善 | 第2回を読む |
| 第3回 | テスト完了から初回製品版公開まで | 第3回を読む |
| 第4回 | 公開後のサンプルPDFカタログとヘルプ | 第4回を読む |
| 第4回補足 | 実機検証と記録の自動化 | この記事 |
| 第5回 | アイコン・フィーチャーグラフィック・チップ画像の制作 | 第5回を読む |
| 第6回 | 記念バッジとプロモーションコードの配布 | 公開予定 |
第1〜5回と第4回補足は初稿として公開中です。第6回は公開待ちで、公開後にリンクを追加します。
第2回では、性能や画面、デバイスの種類を変えて確かめるため、実機を増やした経緯を紹介しました。その後も機材を追加したことで、端末ごとにテストを繰り返し、機種・OS・アプリ版・結果をVERIFICATION_LIST.mdへ書き戻す作業も増えました。そこで、検証の実行と記録をまとめ、一覧の更新を楽にする仕組みを用意しました。カタログやヘルプの改善と並行して進めた作業です。
アプリ内の機能ではなく、開発PCから実行したい
10月16日、Android StudioのGeminiには、まず次のように依頼しています。
実機を接続してテストを実施し、記録を保存する機能を追加してください。
Geminiはこれを、設定画面へ結果保存ボタンを追加する依頼と解釈しました。その変更を取り消した後、実行する場所を明示し直しています。
開発環境(Android StudioまたはTerminal)から実機を接続して可能な限り多くのテストを実施し、それらの結果を開発環境のlog/以下に保存する機能を追加する計画を立ててください。
続けて、保存先をlogs/へ変更し、Gitの管理対象外にするよう指定しました。実装後の回答には、次の説明があります。
接続された実機を検出し、デバイス診断情報 (
device_info.txt)、Logcat (logcat.log)、単体・結合テストの実行ログ、およびHTMLレポートをタイムスタンプ付きのセッションフォルダ (logs/<timestamp>_<serial>/) に自動保存します。
こうして作ったのが、scripts/run_device_tests_and_save.pyです。最初の依頼だけで意図どおりになったのではなく、「どこから実行し、どこへ結果を残すのか」を具体化していました。
実機へのインストールと、既存テストの実行範囲を確認する
実行後にも、含まれる処理を確認しました。
run_device_tests_and_save.pyの実行時に、アプリのインストールが含まれているように見えません。確認してください。
回答では、ビルド済みのデバッグAPKを検出して実機へインストールする処理を追加・強化したと報告されています。その後、クリーン再インストールや起動確認、既存の負荷・パフォーマンステストを含む端末テストの実行と、ログ収集へ広げています。
run_device_tests_and_save.pyに以下の機能が含まれているかを確認してください。
負荷テスト、パフォーマンステスト
さらに、含められる実装済みテストを確認しています。
run_device_tests_and_save.pyに追加できる実装済みのテストが残っているかを確認してください。
Geminiは、単体テスト、負荷・性能、アクセシビリティ、メタデータ、画面遷移、スクリーンショットに関するテストとPython QAを実行・収集対象として列挙しました。これは統合した対象の説明であり、この回答だけで、すべての実機ですべてが合格したとは扱いません。
「確認済みと表示する」から「表を実際に更新する」へ
図2 10月17日の公開一覧から5機種を抜粋し、読みやすく再配置しました。原表には8機種を掲載しています。端末の型番は更新する行の照合に使い、OS・アプリ版・結果・備考を残します。Chromebookの版が異なる理由は、この節の後半で説明します。
スクリプトの報告にVERIFIEDと出ていても、目的は一覧の更新まで行うことでした。そこで、変更すべき列を指定し直しています。綴りも当時の原文です。
run_device_tests_and_save.pyの
検証リスト & バージョン照合 ( VERIFICATION_LIST.md, versionCode = 32): VERIFIED
の機能は、VERIFICATION_LISTの更新をしたか確認してください。
正しい修正結果は、対応するDevice Name行のOS VersionとApp Versionが正しいことです。App Versioinは、VersionName(VersionCode)の形式です。成功したらResultがNo Issuesになり、失敗したらエラー数を書きます。
回答には、次の具体例が残っています。
接続中の実機 (
SM-T510) が検出され、VERIFICATION_LIST.md内の該当行の App Version が2.0.0(31)から2.0.0(32)へ正確に自動更新されました。
保存ログでも、この端末の行更新を確認できます。一方、aiwa tab AG10では、端末が返したモデル名JA3-TBA1003が表の名前と一致せず、最初は更新できなかった記録がありました。表へ型番を併記した後には更新成功の記録があります。機材を増やすだけでなく、自動処理が同じ端末を特定できる形に記録を整える必要もありました。
10月16日には、一覧とスクリプトなどをtesting・mainの両ブランチへプッシュした実行記録と、公開コミットを確認できます。コミット・プッシュは、スクリプトの中の自動処理ではなく、別途Geminiへ依頼した作業です。
10月17日には、SM-T510、SH-41A、AG10、XQ-ES44、Pixel 8a、SC-53D、XQ-GH44の7機種で、2.0.0(33)として実行・行更新したログが残っています。当時の表に掲載した8機種すべてで、このスクリプトを実行したことを示すものではありません。たとえば、この更新時点のChromebookの行は2.0.0(32)のままで、スマートフォン・タブレット7機種の記録と区別できます。ここでのアプリ版はスクリプトがビルド設定から読み取った値で、各実機のインストール済みAPKとの一致まで、この記録だけで確定したわけではありません。
Chromebookは配布と記録の手順を別に整える
Chromebookだけ版が異なっていた理由は、最初は検証の準備が足りなかったからです。このスクリプトは、Play Consoleへ登録する前のアプリをUSB接続した実機へインストールし、テストを実行してからVERIFICATION_LIST.mdを更新する運用でした。一方、ChromebookではUSB接続でAndroidアプリをインストールする機能を実現できず、当時は一覧の更新が遅れていました。
現在は、最新のアプリをPlay Consoleの内部テストで公開し、ChromebookのPlayストアから内部テスト版をインストール、または更新して動作を確認しています。その結果をVERIFICATION_LIST.mdへ手作業で反映することで、以前より早く更新できるようになりました。これは10月16〜17日のスクリプト開発後に整えた現在の運用として、当時の自動処理とは区別して記録します。開始日は今回の説明だけでは特定していません。
図3 検証を実行する仕組みと、実機で気づいた不足をテストへ反映する流れ。詳細ログは手元のlogs/に残し、確認一覧・スクリプト・説明文書をGitHubへ公開しました。コミット・プッシュは別途の作業です。図の具体例はビューアの作業から選んでいます。
補足：同じ仕組みを別のアプリへ展開する
この仕組みは、10月18日に「見開きPDFユーティリティ」へも移植しました。ユーティリティでは編集機能の試験など、ビューアとは異なるテストが必要です。共通化したのは実行・ログ保存・一覧更新の流れで、両アプリで同じ機能を同じ内容で検証したわけではありません。本稿では、別アプリへ展開した点までの補足にとどめます。
一覧の表示と、個別テストの結果を分けて読む
省力化はできましたが、一覧のNo issuesを全テスト合格の証明にはできません。当時のスクリプトは、一覧のResultをPython QAの成否だけで決めており、単体・端末テストのビルド失敗が残っていてもNo issuesと記入した例があります。失敗時も1を記入する実装で、依頼したエラー数の正確な集計にはなっていませんでした。
既存の負荷・パフォーマンステストを実行対象へ加えること、実際のインストールを確認すること、表の更新対象を特定し直すことは、それぞれ検証の抜けを減らすための変更でした。ただし、テスト内容を増やす工夫と、集約した結果の判定が十分かどうかは別に確認する必要があります。
この時点で確認できる成果は、端末を替えながら検証を実行し、結果を保存し、一覧更新を省力化する仕組みを作って利用したことです。信頼性を上げるためには、実際に動かした対象・画面・個別ログと、一覧の表示を対応付けて確認し続ける必要がありました。
本編の第4回では、同じ時期に進めたサンプルPDFカタログとヘルプの改善を扱います。実機を増やした理由と到着記録は、第2回で紹介しています。
前の記事（本編）：第4回
次の記事（本編）：第5回