コーディングエージェントからアプリをストア対応にする

始める前に

Claude Code と AppFoyer のアカウントが必要です。無料プランで十分です。アカウントを作成してください。作成するキーはありません。エージェントが初めて接続するときに、ブラウザで承認を求められます。

コーディングエージェントがまったくない場合は？ ブラウザで 6 つの項目に入力すれば、プラグインなしで同じ 5 つのページができます。

Claude Code を使っていない場合は？ プラグインには Claude Code が必要ですが、プライバシーポリシーと利用規約のページには必要ありません。ダッシュボードのそれぞれのエディタに、アプリの情報が入ったプロンプトがあり、どのアシスタントでも実行して貼り戻せます。全文はプライバシーポリシーのガイドと利用規約のガイドに掲載しています。

インストール

claude
/plugin marketplace add appfoyer/claude-plugin
/plugin install appfoyer@appfoyer

始めるのにアカウントは不要です。エージェントはあなたのマシン上でビルドを読み、見つけたものを示して質問し、保存するものができたときに初めて接続を求めます。初めて AppFoyer を呼び出すとき、ブラウザで承認ページが開きます。サインインするか無料アカウントを作成し、名前とブラウザの戻り先を確認して、承認してください。Claude Code は接続を保持し、自動で更新します。何もコピーせず、シェルにも何も保存しません。ブラウザが開かない場合は、/mcp を実行し、appfoyer を選んで Authenticate を選んでください。Claude Code デスクトップアプリでは、ターミナルからこの方法で一度接続してから、アプリで新しいセッションを開始してください。すでに実行中のセッションは新しい接続を認識しません。ダッシュボードの Agent ページで接続を解除すると、次の呼び出しはすぐに失敗します。Claude Code はサードパーティのマーケットプレイスを自動では更新しません。新しいバージョンを受け取るには、/plugin → Marketplaces → appfoyer で Enable auto-update を選んでください。

そのマシンにブラウザがない場合（リモートサーバー、コンテナ、スクリプトでの実行など）は、代わりに API キーを使います。Agent → API key — for CI and headless use でキーを作成し、ワークフローのために上と同じようにプラグインをインストールし、ヘッダーにキーを入れてサーバーをもう一度追加します：

export APPFOYER_API_KEY=cpk_…
claude mcp add --transport http appfoyer-key https://app.appfoyer.com/mcp --header "Authorization: Bearer $APPFOYER_API_KEY"

プラグインはその環境変数からのみキーを読みます。スキルがキーを目にすることはなく、キーは Claude Code が設定する Authorization ヘッダーでのみ送られます。

他の MCP クライアント（claude.ai、Claude Desktop、Cursor、VS Code）も、同じ承認ページを使って同じ方法で https://app.appfoyer.com/mcp に接続できます。ツールは使えますが、ビルドファイルを読む手順どおりのワークフローは Claude Code のプラグインに含まれています。

何と言うか

空のディレクトリではなく、アプリのリポジトリの中で実行してください：

例

自分の言葉で言って構いません。以下はスキルが対応するケースです。

アプリ 1 つ、初回の実行

> Make this app store-ready

• ビルドファイルで見つけたもの（SDK、パーミッション、バンドル ID）を、それぞれファイルと行番号つきで一覧表示します。
• 見つけられなかったことだけを尋ねます：会社名、サポートのメールアドレス、準拠法の地域、ストアのリンク。やりとりは最大 2 往復です。
• アプリを作成し、リポジトリからアイコンをアップロードし、5 つのページすべてを下書きします。
• 最後にレビュー用のリンクを返します。そこであなたが公開するまで、何も公開されません。

変更後にもう一度実行する

> Make this app store-ready

• アプリケーション ID で既存のアプリを見つけ、新しい事実を保存済みのものと比較します。
• 変更の影響を受けるページだけを書き直します。たとえば、新しいアナリティクス SDK を入れた後のプライバシーポリシーです。
• 頼まない限り、アイコンとアドレスはそのままにします。

複数のフレーバー、プロンプトで指定

> Make com.acme.weather.free and com.acme.weather.pro store-ready

• アプリを 2 つ作成し、選択については何も尋ねません。
• 各フレーバー自身のフォルダ、名前、依存関係を読みます。free フレーバーだけが使う広告 SDK を、pro フレーバーのプライバシーポリシーに入れることはありません。
• フレーバーごとに、レビュー用のリンクとコンソール用 URL の表を返します。

複数のフレーバー、指定なし

> Make this app store-ready

• フレーバーをアプリケーション ID とともに、すべて選択済みの状態で一覧表示し、どれにサイトを作るかをあなたが選びます。
• debug や staging などのビルドタイプは、選択肢としてではなく除外として表示されます。

ブランド × 環境のディメンション

> Make every brand store-ready

• 単一のフレーバーではなく、組み合わせ（brandAProd、brandBProd）を一覧表示します。
• 提案するのは本番環境だけです。dev と qa がストアに出ることはありません。
• ビルドがそこに置いている場合は、Gradle（resValue、manifestPlaceholders）や移動したソースセットからアプリ名を読みます。
• ディメンションが環境なのかブランドなのか判断できない場合は、尋ねます。

カスタムアドレス（Pro と Advanced）

> Make this app store-ready

• アプリの英語名からアドレスを組み立てます。たとえば weather-now です。
• それが使用済みか、ブランド名に近すぎる場合は、次の候補（weather-now-app、acme-weather）を試します。最大 5 回試してから、あなたに尋ねます。
• 無料プランでは app-… のアドレスのままにし、カスタムアドレスは Pro で使えると伝えます。
• app-… のアドレスは引き続き同じサイトを配信します。

すでに使っているアドレスを変更する

> Change the address to weather-radar

• まず尋ねます。古いカスタムアドレスはすぐに解放され、それを記載したままのストアの掲載情報は機能しなくなります。
• あなたが承諾してから変更します。

アイコンを更新する

> Update the app icon

• ランチャーアイコンを見つけます：Play 用の 512 アイコン、最大の mipmap 画像、または iOS の AppIcon のマーケティング画像。フレーバー独自のものを優先します。
• 512 KB を超える場合は、一時フォルダでコピーを縮小します。リポジトリには触れません。
• どのファイルをアップロードしたかを伝えます。公開中のアプリでは、新しいアイコンがすぐに反映されます。

広告のあるアプリ

> Make this app store-ready. AdMob publisher id pub-0000000000000000

• あなたが渡した行から app-ads.txt を書きます。パブリッシャー ID はコードにないので、推測することは決してありません。
• ストアの掲載情報のデベロッパーのウェブサイトにサイトを設定するよう、念押しします。
• AdMob は私たちのアドレス上の app-ads.txt ファイルを検証済みです。クロールには最大 24 時間ほど見ておいてください。

ページをビルドと同期させる

> Add the AppFoyer drift check

• “make this app store-ready” を実行するたびに、リポジトリのルートに appfoyer.json を書き込みます。ページの根拠となった SDK、データの種類、パーミッションの記録です。チェックが使うのと同じスキャナーが書き込み、手書きされることはありません。
• このプロンプトは、無料の appfoyer/check-action を使う GitHub ワークフローを示し、あなたが承諾すると .github/workflows/appfoyer.yml を書き込みます。既存のものを上書きすることはありません。
• 以降、すべてのプルリクエストで、ページを書いた時点から追加・削除されたものが、ファイルと行番号つきで一覧表示されます。プラグインをもう一度実行すれば、下書きと appfoyer.json が更新されます。
• あなたの代わりにコミットすることはありません。詳細と他の CI システムでの設定は、プライバシーポリシーを同期させるガイドにあります。

何も変えずに確認する

> Is this app store-ready?

• 該当する各アプリについてチェックリストを実行し、足りないものを報告します。何も書き込みません。
• まだアプリのないフレーバーは、不足として報告されます。

アプリにリンクを入れる

> Wire the store-ready links into the app

• 公開済みのページが必要です。
• 設定画面や文字列リソースに入れるプライバシーとサポートのリンクを差分として提案します。適用するのはあなたが承諾したときだけで、コミットすることはありません。

あなたのマシンから外に出るもの

導き出した事実だけです：

• アプリの名前、プラットフォーム、バンドル ID またはアプリケーション ID
• ビルドファイルで見つかった SDK とパーミッションの名前
• あなたが確認した回答：会社名、サポートのメールアドレス、準拠法の地域、ストアの URL
• エージェントが下書きしたページのテキスト（下書きとしてアカウントに保存されます）
• アプリ自身のアイコン（使い捨てのアップロードリンクで一度だけ送信）

それ以外のファイルは送りません。ソースコードも、リポジトリで見つかったシークレットやキーも決して送りません。エージェントが送るのは、いずれにせよプライバシーポリシーに書かなければならない内容です。

リポジトリの中に書き込まれ、そのまま残るファイルが 1 つあります。appfoyer.json です。ページの根拠を記録したもので、プラグインに同梱されたスキャナーが作成します。どこにも送信されません。エージェントがそれやその他のものをコミットすることはなく、コミットするのはあなたです。

エージェントにできないこと

ブラウザ経由で接続しても API キーで接続しても、プラグインが持つのはエージェント用の認証情報です。そのため、公開はまったくできません。これはエージェントに丁寧にお願いすることではなく、サーバー側で強制されています：

• 公開ツールは存在しません。エージェントが書くのは下書きで、公開中のページは変わりません。
• 下書きのないものが 2 つあります：アイコンとカスタムアドレスです。公開中のアプリでは、これらは公開中のサイトをすぐに変更し、エージェントは設定したときにそう伝えます。すでに使っているカスタムアドレスを、あなたの承諾なしに置き換えることはできません。
• ページを公開する REST ルートは、エージェント用の認証情報を一切受け付けません。セッションのみです。
• どのページも、公開時には手で編集したものと同じコンテンツ審査を通ります。
• エージェントのすべての呼び出しは、それを行った接続またはキーとともに、アカウントの監査ログに記録されます。

つまり、接続やキーが漏えいした場合の最悪のケースは、破棄すべき下書き、間違ったアイコン、新しいアドレスです。あなたの名前でページが公開されることではありません。

エージェントが使えるツール

プラグインは、次のツールだけを公開する MCP エンドポイントに接続します：

うまくいかないとき

これでも変わらないこと

下書きはコードをもとに仕上げたテンプレートであり、法的助言ではありません。エージェントが素早く書いたからといって、内容が正しくなるわけではありません。公開する前に、特にアプリが収集するものの一覧を、エージェントが書いた内容を読んで確認してください。ストアが責任を問うのはあなたです。

ご質問は support@appfoyer.com まで。