App Store用スクリーンショットをClaude Codeのシミュレーター直接操作で作るのは不経済だったのでスクリプト化で解決した

Claude Code DesktopのiOSシミュレーター直接操作でApp Store用スクリーンショットを撮影したところ1ロケールでClaude Proの5時間リミット枠の約38%を消費した。XCUITestとfastlaneでスクリプト化し専用サブエージェントに実行させることでコストを削減できた話を紹介する。
和田健司
2026.08.31
1ヶ月ほど前、Claude DesktopにiOSシミュレーターパネルが追加され、Claudeが実機のようにiOSアプリを操作・確認できるようになった。この件は以下の記事で既に取り上げている。この機能は、Claude Desktop v1.24012.0以降で利用可能である。
https://dev.classmethod.jp/articles/ios-dev-weekly-changes-20260722/
これは便利そうだと思い、自分のアプリのApp Store Connect用スクリーンショットの撮影に使ってみることにした。本記事では、実際に試してみて分かった高コストな問題と、その回避策としてスクリプト化・専用サブエージェント化に落ち着いた経緯を紹介する。
 検証環境MacBook Pro 2021 (Apple M1 Pro)
macOS 26.5.2（25F84）
Xcode 26.6
iPhone 17 Pro Max / iOS 26.5 (シミュレータ)
Claude 1.40609.0 (f65e38)
 放置されていたスクリーンショット現在、私のアプリのスクリーンショットは、リリース直前に手動で撮影したものをそのまま置いているだけで、まったくメンテナンスしていない状態になっている。
App Storeのスクリーンショットには、説明文やキャッチコピーが追記されているものが一般的に多い。てっきりガイドライン的にはグレーな慣習なのかと思っていたのだが、調べてみるとApp Review ガイドラインの2.3.3で明確に許可されていた。「スクリーンショットはアプリの実際の使用状況を示すものでなければならず、タイトルアートやログイン画面、スプラッシュ画面だけであってはならない」とした上で、テキストや画像のオーバーレイを含めてよいと書かれている。つまりキャッチコピーの追加自体はむしろ想定内だった。なお、実際のUIと乖離した誇大な見せ方は2.3.3ではなく別の項目で禁止されているものであり、区別して捉える必要がある。たとえば存在しない機能を写すような誤解を招くマーケティングは2.3.1に、他プラットフォームの画面を使い回すような表記は2.3.10に、それぞれ該当する。ガイドライン上問題ないとわかったところで、あらためて自分のアプリのスクリーンショットを見返してみると、そのキャッチコピーが無いままだった。
そこで、Claude Codeにこのスクリーンショット撮影一式を任せてみようと思った。今はとても忙しくてPCの前にいること自体が稀なので、指示を出すだけで作業をやっておいてくれるAIの存在はありがたい。
 シミュレーター直接操作は高コストだった個人ではClaude Proを契約して使っている。日本語・英語・韓国語・中国語(簡体/繁体)・ドイツ語・フランス語・ポルトガル語(ポルトガル/ブラジル)の9ロケール分を撮ってもらうように依頼。時間がかかっていたので仮眠をとって起きたときには、5時間リミットの枠を使い切った上に、その超過分として利用クレジットから $44.71 分が追加で消費されている様子が見て取れた。[1]
あらためて1言語分のスクリーンショットを作成してもらったところ、Claude Proの5時間リミットの枠の約38%を消費していることが判明した。
シミュレーターをタップ・スワイプで操作させるということは、Claudeにスクリーンショットを見ながら「次にどこを押すべきか」を都度推測させることになる。9ロケール分・複数画面分となると、この推測のたびにモデルを呼び出すことになり、あっという間にコストが膨らむ。App Store用スクリーンショット撮影のような定型作業をこのやり方でやらせるのは、明らかに不経済だった。
 スクリプト化 + 専用サブエージェント化で解決最終的には、シミュレーターの手動操作をやめ、以下の構成に切り替えた。
撮影は XCUITest経由で行う。UIテストなのでシミュレーターの座標をAIに推測させる必要がなく、再現性もある。
撮影自体は fastlane の snapshot を使っている。Snapfile にロケールと対象デバイスを列挙しておくと、ロケールごとにアプリを起動し直しながらUIテストを回し、screenshots/<ロケール>/ 以下にスクリーンショットを自動で集めてくれる。
撮影後の端末フレーム合成・キャッチコピーの合成には fastlane の frameit を使っている。生のスクリーンショットに実機フレームを重ね、Framefile.json で指定したキャッチコピーをオーバーレイして、そのままApp Store Connectに出せる状態の画像に仕上げてくれる。
Framefile.json{
  "default": {
    "background": "../_frameit_assets/background.png",
    "show_complete_frame": false,
    "title": {
      "color": "#FFFFFF",
      "font": "../_frameit_assets/SFNS.ttf",
      "font_size": 110
    },
    "padding": 40,
    "title_min_height": 420
  },
  "data": [
    {
      "filter": "/en-US/01_home",
      "title": {
        "text": "Import Switch\nScreenshots in Seconds"
      }
    },
    {
      "filter": "/en-US/02_detail",
      "title": {
        "text": "Auto-Detects\n19,000+ Game Titles"
      }
    },
    {
      "filter": "/en-US/03_share",
      "title": {
        "text": "Share to SNS with\nSmart Hashtags"
      }
    },
    {
      "filter": "/de-DE/03_share",
      "title": {
        "text": "Mit smarten Hashtags\nauf Social Media teilen"
      }
    },
    {
      "filter": "/ja/03_share",
      "title": {
        "text": "ゲームタグを自動追加\nSNSへ賢くシェア",
        "font": "../_frameit_assets/HiraginoKakuGothic.ttc"
      }
    }
  ]
}
他ロケール分のdata要素も同様に続く(全文は省略)。
これら一連の作業(UIテスト実行→フレーム合成)は fastlane/process_screenshots.sh としてスクリプト化し、この作業だけを行う専用のサブエージェントを作った。モデルは Haiku を指定した。
サブエージェントには、シミュレーターを直接タップ・スワイプ操作するツールの使用を明示的に禁止し、必ずUIテスト経由で撮影するよう指示している。撮影中に広告バナーやデータベース更新バナーが写り込まないよう、UIテスト側から -uitest-screenshot-mode という起動引数を渡し、アプリ側の UITestMode.isScreenshotCapture で課金状態を強制的に有効にしたりバナー表示を止めたりする仕組みも合わせて組んである。撮影に失敗した場合もサブエージェント自身がコードを直そうとはせず、失敗箇所とエラーメッセージだけを報告して呼び出し元(自分)に判断を委ねるようにした。
このサブエージェントの定義は以下の通り。
---
name: screenshot_capture
description: >
  NSEasyConnect のApp Storeマーケティング用スクリーンショットの撮影・加工を安価に行う
  サブエージェント。「スクリーンショットを撮り直して」「スクショを更新して」など、
  UIテスト経由でのスクリーンショット撮影・端末フレーム合成を依頼されたときに使用する。
  iOSシミュレータを対話的に操作するのではなく、`NSEasyConnectUITests` と
  `fastlane/process_screenshots.sh` を実行するだけ。コピー文言の変更・デザイン判断・
  コードの修正は行わない(結果報告のみ)。
tools: Bash, Read, Grep, Glob
model: haiku
color: purple
---
実際にこのサブエージェントに日本語版スクリーンショット3枚の撮り直しを依頼してみたところ、コストは $0.95、API呼び出し時間は2分8秒(wall time は33分45秒)で完了した。
シミュレーター直接操作では1ロケール分の作業だけでPro枠の5時間リミットの約38%を消費していたのに対し、スクリプト化後は日本語版3枚の撮り直しがAPI換算でわずか$0.95で済んだ。両者は単位が異なる数字だが、それだけ差が開いていることが分かる。
シミュレーターの手動操作をAIにやらせるのではなく、「撮影と加工の手順そのものをスクリプトに落とし込み、そのスクリプトを安いモデルに呼ばせる」という形にしたことで、コストは大幅に下がった。ロケール数や画面数が増えても、AIが都度画面を見て操作を推測するわけではないので、コストがほぼ線形にしか増えない。
 まとめClaude Codeがシミュレーターを直接操作できるようになったのは面白い進歩だが、App Store用スクリーンショットの撮影のような「毎回同じ手順を繰り返すだけの定型作業」には向いていなかった。良かった点としては、シミュレーター操作をスクリプトに落とし込むことで、ロケール数や画面数が増えてもコストがほぼ線形にしか増えなくなったことが挙げられる。一方で、そこに至るまでにClaude Pro枠を大きく消費してしまった点は課題だったと感じている。
こういう作業は素直にUIテストとfastlaneでスクリプト化し、AIには「そのスクリプトを実行して結果を報告する」という薄い役割だけを持たせる方が、コスト面でも再現性の面でも圧倒的に良い。Claude Codeに何でも直接操作させればいいというわけではなく、向き不向きを見極めて使い分ける必要があると実感した。同じようにシミュレーター操作のコストに悩んでいる方の参考になれば幸いだ。

脚注
今思えばこまめに実際のコストを確認しておくべきだった。最低限 /usage しておけばコスト面での比較ができたのに残念である。 ↩︎